ProfitPress Mega CDROM2 Shareware Freeware (MSDOS)(1992)(Eng)

home *** CD-ROM | disk | FTP | other *** search

/ ProfitPress Mega CDROM2 …eeware (MSDOS)(1992)(Eng) / ProfitPress-MegaCDROM2.B6I / BBS / NETMAIL / RAID0121.ZIP / RAID_121.PRN next >

Wrap

Text File | 1991-07-11 | 120.8 KB | 4,091 lines

Raid version 1.21 *test* July, 1991 Copyright 1989-91 by George Peace -- All Rights Reserved RAID is a companion utility for Barry Geller's TICK program. It offers facilities for command- line and NetMail driven maintenance of the Tick operating environment. "Tick without Raid is like watchmaking without a sledgehammer" -- Unclaimed Raid v1.21 *test* July, 1991 The Disclaimer This software is not guaranteed to do anything except take up space on your computer's disk. Any benefit you might derive from use of this software is welcome but not implied by its release. The author of this software shall not be held responsible for any damages, either directly or indirectly, from its use. This software must not be sold. If it is repackaged for distribution, all original files must be included. No additional files may be included and original files may not be modified. Contents What Is Raid, Anyway?................................................5 Manual Mode..........................................................7 Command Line Switches..............................................7 FIND...............................................................8 ADD................................................................9 DELETE............................................................11 CREATE............................................................13 REMOVE............................................................14 NOTIFY............................................................15 REPORT............................................................16 NETREPORT.........................................................17 AREAREPORT........................................................18 NETAREAREPORT.....................................................19 AUTOCREATE........................................................20 ANNOUNCE..........................................................21 Response Mode.......................................................22 NetMail Processing in Response Mode...............................23 NetMail Message Format.........................................23 Processing Security Levels........................................25 Response mode off..............................................26 Inquiry only...................................................26 Updates enabled................................................26 The Configuration File..............................................27 Access to RAID.CFG................................................27 Configuration Directives..........................................28 Address........................................................28 Sysop..........................................................29 Origin.........................................................29 Tick...........................................................29 Log............................................................30 NetMail........................................................30 Pkt_Path.......................................................30 InfoFile.......................................................31 ErrorSuffix....................................................31 PasswordSuffix.................................................31 Copyright 1989-91 by George Peace - All rights reserved page 2 Raid v1.21 *test* July, 1991 Def_Password...................................................32 Def_Flags......................................................33 Def_Key........................................................33 Open_System....................................................33 Access_Default.................................................34 Access.........................................................34 Area...........................................................36 AreaDefault....................................................36 HideArea.......................................................37 HideProtected..................................................37 WildCard.......................................................37 Global_WildCard................................................37 NetMailBehavior................................................38 KillReceived...................................................38 Force_Intl.....................................................38 AlertNode......................................................39 TearLine.......................................................39 PointNet.......................................................39 Notifying Your Connections of Their Status.....................40 NotifyPrefix.................................................40 NotifyExclude................................................40 NotifyThreshold..............................................40 NotifyMinimum................................................41 NotifyMaximum................................................41 NotifyBehavior...............................................41 Announcing New File Arrivals...................................42 Announce_Msg.................................................42 Announce_From................................................42 Announce_To..................................................43 Announce_Subject.............................................43 Announce_Origin..............................................43 Announce_Only................................................43 Announce_Area................................................44 Announce_Header..............................................45 Announce_Trailer.............................................45 Announce_Cont_Header.........................................45 Announce_Cont_Trailer........................................45 Announce_Template............................................46 Announce_Format..............................................46 Announce_Dest_Format.........................................46 Creating New File Echo Areas...................................47 Newarea_Process..............................................47 Newarea_Path.................................................47 Newarea_Create...............................................47 Newarea_Node.................................................48 Newarea_Msg..................................................48 Newarea_From.................................................49 Newarea_To...................................................49 Newarea_Subject..............................................49 Newarea_Origin...............................................49 Reporting File Echo Connections................................50 Report_File..................................................50 Report_Msg...................................................50 Report_Prefix................................................51 Copyright 1989-91 by George Peace - All rights reserved page 3 Raid v1.21 *test* July, 1991 Report_From..................................................51 Report_To....................................................51 Report_Subject...............................................51 Report_Origin................................................52 Changing the Tick Control File Appearance......................53 TidyNodes....................................................53 Add_Template.................................................53 Tidy_Template................................................54 SortNodes....................................................54 SortAreas....................................................55 Controlling File Area Lists....................................56 AreasPerLine.................................................56 Available....................................................56 NotifyAvailable..............................................57 Active_Marker................................................57 Priv_Marker_Left.............................................57 Priv_Marker_Right............................................58 The Log File........................................................59 MS-DOS Errorlevels Returned.........................................61 Other Topics........................................................62 Release Information...............................................62 A Few Words About Raid and Zones..................................62 Trouble Reports and Support.......................................63 Testing Raid......................................................63 Credits...........................................................64 Copyright 1989-91 by George Peace - All rights reserved page 4 Raid v1.21 *test* July, 1991 What Is Raid, Anyway? Raid is a utility intended to complement Barry Geller's Tick program. It offers both manual and automated maintenance capabilities for the Tick control file (typically TIC.CFG). Raid accepts commands from the command line (manual mode) and from remotely entered NetMail (response mode). Manual mode operations are... FIND - search the Tick control file for connections matching a requested network address. ADD - insert a network address in an existing AREA block DELETE - remove a network address from an AREA block NOTIFY - generate NetMail connection notification messages to all or selected network addresses. CREATE - create a new file echo area by making the subdirectory and generating the skeleton AREA block REMOVE - delete an AREA block and notify all affected network addresses. [NET]REPORT - create an EchoMail message (NETmail with NET prefix) summarizing current file echo connections by address [NET]AREAREPORT - create an EchoMail message (NETmail with NET prefix) summarizing current file echo connections by area Two additional manual mode commands are available for on-request or unattended operation. They can be used separately or together as well as with response mode (-R) operation... AUTOCREATE - scans unprocessed TK*.TIC files for new file echo areas and creates them automatically. ANNOUNCE - scans unprocessed TK*.TIC files and generates arrival announcements in a message area. Response mode operations are... QUERY - locate requestor's network address in Tick control file and report connections ADD - insert or update a connection for requestor's network address DELETE - remove a connection for requestor's network address Copyright 1989-91 by George Peace - All rights reserved page 5 Raid v1.21 *test* July, 1991 Use of Raid is closely linked to Tick. Familiarity with Tick operation and its control file is necessary for successful operation of Raid. Copyright 1989-91 by George Peace - All rights reserved page 6 Raid v1.21 *test* July, 1991 Manual Mode The Raid command line offers access to the Tick control file maintenance functions most frequently required by System Operators. These functions are performed in Raid's manual mode. Day to day changes can all be made directly from the command line. 'Switches' in the following command descriptions, though shown as '- switch', can be entered as '/switch'. Switches can be upper or lower case. Command Line Switches These command line switches are recognized for all manual mode Raid executions... -Cd:\directory\file.ext This optional switch forces Raid to point to the Raid configuration file identified. This switch overrides the default search sequence. If the file identified by the switch cannot be located the program will not continue. -Ld:\directory\file.ext or -L This optional dual action switch changes the default log file destination. -L by itself turns off all log file activity. -L followed by any filespec overrides the log file destination from that identified by the "Log" configuration file directive to d:directory\file.ext. If the log file defined by this switch cannot be accessed the program will continue without a log file. -Mx This optional switch causes NetMail responses to be sent to network address z:net/node as provided on the Raid command line. The optional modifier 'x' can be C (crash), D (direct), H (hold) and K (kill/sent) to override NetMail behavior defined in the configuration file. -Td:\directory\file.ext This optional switch forces Raid to point to the Tick control file identified. This switch overrides the filename defined by the "Tick" configuration directive in Raid.Cfg (see page 27). If the file identified by the switch cannot be located the program will not continue. Copyright 1989-91 by George Peace - All rights reserved page 7 Raid v1.21 *test* July, 1991 FIND This function searches all AREA blocks for the network address string provided on the command line. 'Finds' are listed to the screen. If the -M command line switch is present a NetMail message will be generated to [z:][net/]node even if the address is not found. RAID FIND <-switch ...> z:net/node switch: -C, -L, -M, and -T (see page 7) z:net/node This parameter defines the search argument for the find. In local mode (-M not present) any area block entry containing the address field string represented by the z:net/node (or a partial address) is displayed. If omitted, all entries in all area blocks will be displayed. If a partial network address is provided as net/node, node, or .point the missing components are extracted from your primary "address" and "pointnet" as defined in raid.cfg. Examples: RAID FIND 1:999/999 -m locates all occurrences of network address 1:999/999 in the Tick control file and sends the resulting list to address 1:999/999. RAID FIND 999 locates node 999 of your primary zone and net in the Tick control file. NetMail is not generated. RAID FIND lists all connections for all AREA blocks in the Tick configuration file. NetMail is not generated. Copyright 1989-91 by George Peace - All rights reserved page 8 Raid v1.21 *test* July, 1991 ADD This function updates the Tick control file by adding a network address to the distribution list for one or more areas. An ADD request for an existing connection is treated as an UPDATE request, allowing password and flag changes to existing connections. RAID ADD <-switch ...> z:net/node area-1 ... area-n RAID ADD <-switch ...> z:net/node <wildcard> switch: -C, -L, -M, and -T (see page 7) -Fflags This optional switch overrides flags field definitions in the Raid configuration file. "flags" will be added to any area block additions made. No editing is done on the field. If -F is not provided, the flags for all connections added will be determined by "access" or "def_password" configuration file directives. -Ppassword This optional switch forces <password> to be used for all area block additions made. This overrides the any password definitions in the Raid configuration file. If -P is not provided, the password for all connections added will be determined by "access" or "def_password" configuration file directives. z:net/node This parameter defines the network address for the add operation. If a partial network address is provided as net/node, node, or .point the missing components are extracted from your primary "address" and "pointnet" as defined in raid.cfg. area This is the (required) list of one or several area blocks. z:net/node is added to each of the area names. If an area name does not exist that area is omitted and the remaining area names are processed. Partial area names are recognized and expanded if the last character is an asterisk (*). In that case the command will be executed as if all matching area names had been provided on the command line. <wildcard> This is one of the 'wild card' area names. If included as one of or the only area name z:net/node will be added to some or all area blocks defined in the Tick control file. The "wildcard" and "global_wildcard" configuration file directives can be used to redefine the wildcards. Examples: RAID ADD 1:999/999 SOFTDIST SDSRBBS SDSBINK PDN* adds network address 1:999/999 to area blocks SOFTDIST, SDSRBBS, and SDSBINK in the Tick control file. In addition, all areas with PDN in the first 3 characters will be added for the specified address. Copyright 1989-91 by George Peace - All rights reserved page 9 Raid v1.21 *test* July, 1991 RAID ADD 1:999/999 ALL -M adds network address 1:999/999 to all area blocks defined in the Tick control file. The results are sent to network address 1:999/999. Copyright 1989-91 by George Peace - All rights reserved page 10 Raid v1.21 *test* July, 1991 DELETE This function updates the Tick control file by deleting a network address from the distribution list for one or more areas. RAID DELETE <-switch ...> z:net/node area-1 ... area-n RAID DELETE <-switch ...> z:net/node <wildcard> switch: -C, -L, -M, and -T (see page 7) -O This optional switch forces an override of strict z:net/node matching for delete requests. In this case all network addresses in the Tick control file containing the partial z:net/node address will be deleted. -O and -M cannot be used in combination. z:net/node This parameter defines the network address for the delete operation. All areas deleted by this Raid execution will match this address. If a partial network address is provided as net/node, node, or .point the missing components are extracted from your primary "address" and "pointnet" as defined in raid.cfg. area This is the (required) list of one or several area blocks. z:net/node is deleted from each of the area names. If an area name does not exist that area is omitted and the remaining area names are processed. Partial area names are recognized and expanded if the last character is an asterisk (*). In that case the command will be executed as if all matching area names had been provided on the command line. <wildcard> This is one of the configured 'wild card' area names. If included as one of or the only area name z:net/node will be deleted from all area blocks defined in the Tick control file. The "wildcard" and "global_wildcard" configuration file directives can be used to redefine the wildcards. Examples: RAID DELETE 1:999/999 SOFTDIST SDSRBBS SDSBINK PDN* deletes network address 1:999/999 from area blocks SOFTDIST, SDSRBBS, and SDSBINK in the Tick control file. In addition, all areas with PDN in the first 3 characters will be deleted for the specified address. RAID DELETE 1:999/999 ALL -M deletes network address 1:999/999 from all area blocks defined in the Tick control file. The results are sent to network address 1:999/999. Copyright 1989-91 by George Peace - All rights reserved page 11 Raid v1.21 *test* July, 1991 RAID DELETE 1:999/ ALL -O deletes all connections for all zone 1, net 999 network addresses from the Tick control file. Copyright 1989-91 by George Peace - All rights reserved page 12 Raid v1.21 *test* July, 1991 CREATE The create function accepts one or more file echo area names to create. RAID CREATE <-switch ...> <areaname ... areaname> switch: -C, -L, and -T (see page 7) An area block is created in tic.cfg and a new subdirectory is allocated for each area name specified. Area blocks are inserted at the end of the tic.cfg file with connections to network addresses defined on "newarea_node" directives. Copyright 1989-91 by George Peace - All rights reserved page 13 Raid v1.21 *test* July, 1991 REMOVE The remove function deletes a file echo area and all its connections. RAID REMOVE <-switch ...> [area-1 ... area-n switch: -C, -L, and -T (see page 7) This function operates internally as if individual "RAID DELETE net/node areaname" were issued for all active connections to a list of file echo areas. Partial area names are recognized and expanded if the last character is an asterisk (*). In that case the command will be executed as if all matching area names had been provided on the command line. NetMail response messages are issued to all affected netword addresses. Examples: RAID REMOVE SOFTDIST deletes all network addresses from area blocks SOFTDIST in the Tick control file. Examples: RAID REMOVE SOFTDIST SDS* deletes all network addresses from area blocks SOFTDIST and all areas with SDS in the first 3 characters. Copyright 1989-91 by George Peace - All rights reserved page 14 Raid v1.21 *test* July, 1991 NOTIFY This function triggers an automatic "FIND" operation for all (global) network address with connections in effect in the Tick control file or for a list of network addresses (directed). Network addresses can be excluded from the global notify operation by using the "NotifyExclude" configuration directive. RAID NOTIFY <-switch ...> <z:net/node ... z:net/node> switch: -C, -L, and -T (see page 7) -Mx This optional switch can be used to override the configured behavior of connection status notification NetMail messages. Modifier 'x' can be C (crash), D (direct), or H (hold) and K (kill/sent). This value overrides the default message behavior defined in the configuration file for all addresses. The notify process searches for a text file defined by the "notifyprefix" configuration directive before generating messages. That file, if found, is copied into the body of each notification message as introductory text. The file is transferred directly with no attempt to format, translate or validate its contents other than to delete the trailing control Z (^Z) if present. File size and content must conform to NetMail processing software restrictions and limitations. If "notifyprefix" is not defined or the file cannot be opened a default introduction will be used. The -M directive can be used to control the outbound behavior of notification NetMail messages. Absence of the -M switch results in use of the flags (C, D, H or N) defined on "access" or "def_flags" configuration directives. If an "access" directive exists for a network address the value in the "mail" field will be used to determine outbound behavior for that address. If that field is missing the C or H (or their absence) from the directive's "flags" field will determine the behavior. If no "access" directive exists for the network address, the C, D, or H (or no flag) defined by the "def_flags" configuration directive will determine the behavior of the message. If a list of network addresses is provided Raid will generate connection notification messages for each address provided. All configuration file checks for excluding ("NotifyExclude" and skipping ("NotifyThreshold", "NotifyMinimum", and "NotifyMaximum") will be bypassed. Up to 100 addresses can be provided for the directed mode notify.. Copyright 1989-91 by George Peace - All rights reserved page 15 Raid v1.21 *test* July, 1991 REPORT Generate a file and/or an EchoMail message listing current file echo connections from TIC.CFG. The report destination is determined by the "report_file" and report_msg" configuration directives. RAID REPORT <-switch ...> switch: -C, -L, and -T (see page 7) If "report_file" is defined Raid will write the connection summary to a file. If "report_msg" is defined Raid will write the connection summary in EchoMail format. If both directives are defined Raid will write the connection summary to both places. If neither "report_file" nor "report_msg" is defined this command line manual operation will fail. Raid can generate two 'special' reports to list file areas and network addresses that appear in the Tic.Cfg file but are not configured in Raid.Cfg. The list(s) generated are displayed only on-screen. RAID REPORT ORPHAN AREAS RAID REPORT ORPHAN NODES Copyright 1989-91 by George Peace - All rights reserved page 16 Raid v1.21 *test* July, 1991 NETREPORT Generates one or more NetMail messages listing current file echo connections from TIC.CFG. Messages are placed in the directory indicated by the "netmail_path" configuration directive. RAID NETREPORT <-switch ...> <z:net/node ... z:net/node> switch: -C, -L, and -T (see page 7) This variation of the "report" manual mode command does not require or use the "report_file" or "report_msg" directives. The report is written only as a NetMail message. "netmail_path" must be defined. If no network address is provided, Raid will address the connection list to your primary network "address". If a list of network addresses is provided Raid will generate a connection summary addressed to each address provided. Up to 100 addresses can be provided for the directed mode netreport. See "REPORT" for a description of the message. Copyright 1989-91 by George Peace - All rights reserved page 17 Raid v1.21 *test* July, 1991 AREAREPORT Generate a file and/or an EchoMail message listing current file echo connections from TIC.CFG. This report displays distribution information by file area. The report destination is determined by the "report_file" and report_msg" configuration directives. RAID AREAREPORT <-switch ...> [areaname ... areaname] switch: -C, -L, and -T (see page 7) If no area name fields are supplied on the command line all areas defined in Tic.Cfg are reported. If supplied, only those file areas area reported. Partial area names are recognized and expanded if the last character is an asterisk (*). In that case the command will be executed as if all matching area names had been provided on the command line. If "report_file" is defined Raid will write the area connection summary to a file. If "report_msg" is defined Raid will write the area connection summary in EchoMail format. If both directives are defined Raid will write the connection summary to both places. If neither "report_file" nor "report_msg" is defined this command line manual operation will fail. Copyright 1989-91 by George Peace - All rights reserved page 18 Raid v1.21 *test* July, 1991 NETAREAREPORT Generates one NetMail message listing current file echo connections from TIC.CFG. This report Messages are placed in the directory indicated by the "netmail_path" configuration directive. RAID NETREPORT <-switch ...> z:net/node [areaname ... areaname] switch: -C, -L, and -T (see page 7) This variation of the "areareport" manual mode command does not require or use the "report_file" or "report_msg" directives. The report is written only as a NetMail message. "netmail_path" must be defined. If no area name fields are supplied on the command line all areas defined in Tic.Cfg are reported. If supplied, only those file areas area reported. Partial area names are recognized and expanded if the last character is an asterisk (*). In that case the command will be executed as if all matching area names had been provided on the command line. If no network address is provided, Raid will address the connection list to your primary network "address". If a list of network addresses is provided Raid will generate a connection summary addressed to each address provided. Up to 100 addresses can be provided for the directed mode netreport. See "AREAREPORT" for a description of the message. Copyright 1989-91 by George Peace - All rights reserved page 19 Raid v1.21 *test* July, 1991 AUTOCREATE The autocreate function scans TK*.TIC files in the inbound directory and creates new file echo areas. RAID AUTOCREATE <-switch ...> switch: -C, -L, and -T (see page 7) This function reads all TK*.TIC files in the directory defined by the IN directive in tic.cfg. Raid will create a new subdirectory and add a new area block for each new area it finds. Raid will (optionally) generate a new area creation notice as an echomail message. Information includes the file area and feed address. Information for file area creation is gathered from the .TIC file and Raid's "newarea_" series of configuration directives. If the file pointed to by the .TIC file cannot be found or if it is zero length autocreate will not create the area. Autocreate can be used alone or in conjunction with announce and response mode processing. Copyright 1989-91 by George Peace - All rights reserved page 20 Raid v1.21 *test* July, 1991 ANNOUNCE The announce function scans TK*.TIC files in the inbound directory and creates new file arrival notices. RAID ANNOUNCE <-switch ...> switch: -C, -L, and -T (see page 7) This function processes all TK??????.TIC files in the directory defined by the tic.cfg IN directive. It also processes all TK??????.RAD files in the directory defined by the tic.cfg HOLD directive in order to announce locally HATCHed files. Raid generates messages announcing the arrival of each file pointed to by a .TIC/.RAD. Message contents can include file name, size, and description as well as areaname, area description, origin address, feed address, and the path the file travelled. Information for arrival announcements is gathered from the .TIC/.RAD file and Raid's "announce_" series of configuration directives. The directives are used to define an overall default destination as well as destinations for individual file areas. If the file pointed to by a .TIC file is zero length or cannot be found Raid will not generate the announcement. .RADs will be processed unconditionally. The .RAD files will be deleted after information is extracted from them. Announce can be used alone or in conjunction with autocreate and response mode processing. Refer to the "announce_..." series of configuration directives for operational control and output message customization. Copyright 1989-91 by George Peace - All rights reserved page 21 Raid v1.21 *test* July, 1991 Response Mode Response mode offers remote users the convenience of making inquiries and connection updates to the Tick control file without directly involving the distribution site System Operator. Remote operations can be disabled or engaged to whatever extent necessary for secure operation of the distribution site. Password access and multiple security privilege levels are supported. Response mode is activated by the program call: RAID -Rx <-switch ...> This call will typically be used in a batch file on the distribution system following the mail import operation. The -R switch triggers Raid to scan the NetMail message area for messages addressed to "Raid" or an alias defined by the "alias" configuration directive. The optional modifier 'x' can be C (crash), D (direct), H (hold) and K (kill/sent). This will unconditionally override behavior flags defined in the Raid configuration file for response messages generated by Raid. Additional switch values recognized in response mode are... switch: -Cd:\directory\file.ext This optional switch forces Raid to point to the Raid configuration file identified. -Fflags This optional switch overrides flags field definitions in the Raid configuration file. "flags" will be added to any area block additions requested. No editing is done on the field. If -F is not provided, the flags for all connections added will be determined by "access" configuration file directives. -Ppassword This optional switch forces <password> to be used for all area block additions made. This overrides any password definitions in the Raid configuration file. In this case the "access" directive password will be used only for initial security validation. If -P is not provided, the password for all connections added will be determined by "access" configuration file directives. -Ld:\directory\file.ext or -L This optional dual action switch changes the default log file destination. -L by itself turns off all log file activity. -L followed by any filespec overrides the log file destination from that identified by the "log" configuration file directive to d:directory\file.ext. Copyright 1989-91 by George Peace - All rights reserved page 22 Raid v1.21 *test* July, 1991 -Td:\directory\file.ext This optional switch forces Raid to point to the Tick control file identified. This switch overrides the filename defined by the "Tick" configuration directive. If the file identified by the switch cannot be located the program will not continue. NetMail Processing in Response Mode In order for Raid to process a NetMail message on the distribution system several conditions must be satisfied: - The Raid configuration file "netmail" directive must be present and must point to the distribution system NetMail message directory. - The message must be addressed to the zone:net/node of the distribution system as determined by the "address" configuration directives. - The message must be addressed To: RAID (exactly 4 characters, case-insensitive) or any alias defined by "alias" configuration directives. - The LOCAL and RECEIVED message attributes must both be clear (not set) to prevent Raid from processing its own outbound messages (local attribute set) or processing inbound messages more than once. Raid sets the received attribute when it processes an inbound message. Once these conditions are met Raid continues processing the netmail message. Security will be validated and a response generated according to the processing level and lock/key settings in effect for the requesting address and area. If security requirements are satisfied, each line in the message body is interpreted and processed as an individual add/delete request. Once all lines in the message body have been processed Raid will list area connections for the requesting network address and display all area names available on the distribution system. NetMail Message Format NetMail messages addressed to Raid can be created by any FidoNet compatible message editor. A typical Response mode request might be: Copyright 1989-91 by George Peace - All rights reserved page 23 Raid v1.21 *test* July, 1991 To: Raid (1:270/101) From: Sysop (1:987/654) Subj: Mypasswd -I -Q Attr: privileged ------------------------------------------ DAZZLE -SWIZZLE --- Raid uses several message components to validate and process the request. To: Raid processes NetMail messages addressed To: Raid or to any one-word alias defined by the "alias" configuration directive. In addition, the To: network address must match the zone:net/node defined by one of the "address" configuration directives. If no INTL kludge line exists in the message body Raid assumes the To: zone is the same as the primary "address" zone. If an INTL kludge line is located the destination address from that line is used as the To: zone:net/node. From: Raid checks the net/node portion of the from field for access validation. If an "access" configuration directive does not exist for the address the request is rejected. The name portion of the from field is not used for validation. That field is used only to create the response. Kludge lines (INTL and MSGID) in the message body always override the From: network address. Subj: This field defines the security validation password as well as request flags from the requestor. The first "word", which must be eight characters or less, must match the password field on the "access" configuration directive corresponding to the From: network address. Case is ignored. The request flags are: -I (information) requests Raid to file-attach an information file to the NetMail response if the request passes security validation. The file is defined by the "raidinfo" configuration directive. -Q (query) requests Raid to add descriptions to the list of file echo areas available on the distribution system. The descriptions are provided on "area" configuration directives. See the section titled "Controlling the Available Area Display" for additional information. Attr: If either the "local" and "received" flag is set Raid will ignore the request. The "local" flag is always set on NetMail generated locally and so could not be a valid Raid remote request. The "received" flag is set by Raid when after it completes security validation but before it processes the message body. Copyright 1989-91 by George Peace - All rights reserved page 24 Raid v1.21 *test* July, 1991 Body: The message body defines the list of file echo areas to be added, deleted, and updated in the Tick control file. Each area request must begin a new line. The message body scan ends when it finds a blank line or a "tear line" (a line beginning with three dashes) If the message body contains an ^AINTL or ^AMSGID: line the originating network address from that line will replace the From: network address for validation and processing. In addition, the ^AINTL destination address will replace the To: network address. Processing Security Levels Response mode is activated at one of three processing levels for each network address connected to the distribution site: Response mode off Inquiry only Updates enabled Response mode access privileges are determined by the existence and content of "access" and "area" directives in the Raid configuration file. This file and the directives are described in another section. Copyright 1989-91 by George Peace - All rights reserved page 25 Raid v1.21 *test* July, 1991 Response mode off This is the "default" mode for Raid. Only manual requests (command line operation) are executed. All remote NetMail requests are declined with an appropriate response to the requestor. This mode is determined by a lack of network address "access" definitions in the Raid configuration file. This mode is intended to allow the distribution system SysOp to decline all remote requests or to screen remote requests before applying them manually. Inquiry only Inquiry only mode is triggered when the security levels defined on all "access" configuration directives are lower than the levels defined on all "area" directives. This results from the fact that the "area" security level must be equal to or lower than "access" security level for updates to be accepted. In this case NetMail messages addressed to RAID will be processed as inquiries since add/delete access will be denied. If security requirements are met Raid will respond with a list of area connections and optionally -- see the "available" configuration directive -- list of areas available on the distribution system. Updates enabled Update mode is determined on a node by node basis according to the "access" directive security level. Once security requirements are met Raid will process the NetMail message body. Each line is processed as a separate request to add an area connection to or delete one from the Tick control file on the distribution system. Each "area" security level is compared to the network address's "access" security level. If the "access" level is equal to or higher than the "area level the request is processed. "Access" security can be overridden through use of the "open_system" and "access_default" configuration directives. Copyright 1989-91 by George Peace - All rights reserved page 26 Raid v1.21 *test* July, 1991 The Configuration File The Raid configuration file (RAID.CFG) provides the distribution system operator the flexibility and power to direct Raid operation according to individual processing requirements: - Location of all files and directories necessary for Raid operation on the distribution system - Inquiry and update capabilities for individual network addresses - Access levels for file areas - Lock/Key protection using 32 settings for address/area matching. - Default Tic.Cfg password and flag fields for additions - Control of NetMail message behavior (Crash / Direct / Hold / KillSent) - Definition of text to accompany connection status notification messages - Definition of the wildcard "all areas" operator - Options to control information provided in Raid NetMail responses - Zone and point and support Access to RAID.CFG Raid offers flexibility in Raid.Cfg location and access. Raid will search several locations in sequence in order to locate the configuration file. - The file and directory defined by the RAID environment variable: (SET RAID=d:\direct\file.ext) - The current directory - RAID.CFG in the directory defined by the BBS environment variable - RAID.CFG in the directory defined by the MAIL environment variable - RAID.CFG anywhere in the program search PATH - If the configuration file search is not successful Raid execution will not continue. Copyright 1989-91 by George Peace - All rights reserved page 27 Raid v1.21 *test* July, 1991 The configuration file location can be overridden with the command line -C switch. See page 7 for -C definition. Configuration Directives The following paragraphs describe configuration directives available in RAID.CFG. Additional information and examples of configuration directive use are available in the sample RAID.CFG provided in the Raid distribution package. All directives are described in four parts -- Directive name; description and usage nodes; Default value if the directive is not provided; and At least one example. The only REQUIRED directive is ADDRESS. All others are optional according to features and parameters you need to customize Raid to your unique requirements. Unused and optional commands can be "commented out" in Raid.Cfg. Comment lines (beginning with ; or * or %) can be removed for a slight performance improvement. The underline character (_) is optional in all Raid configuration directives. Use as few or as many as you like to make directives 'readable'. Address Defines the network addresses of the distribution system. At least one address directive must be provided. Additional addresses (akas) can be defined by providing multiple "address" directives. Full zone:net/node syntax is required. The first address directive MUST be the primary net address. That address will be used on all NetMail generated in manual node (except as noted elsewhere). That address will also be used in response mode replies in multiple zone situations requiring different zones for NetMail routing. Response mode operation in multiple zones is defined through this directive. Response mode NetMail requests can be addressed to any of the addresses defined. Though not required for successful operation in a multiple zone environment, best results will be achieved if INTL or MSGID kludge lines are included in NetMail addressed to Raid. Copyright 1989-91 by George Peace - All rights reserved page 28 Raid v1.21 *test* July, 1991 An additional optional field is available for assignment of an "aka" to response mode ADD requests. A single hexadecimal digit added to an address definition will force Raid to append A<hexdigit> to the flags field of area distribution lines ADDed in response mode. If an aka is already defined by "access" or "def_flags" directives the field is ignored. Please see the Tick documentation for use and implications of akas. Default: no default available -- REQUIRED Example: ADDRESS 1:270/101 ADDRESS 2:123/456 ADDRESS 1:2/1 ADDRESS 1:1/2 Sysop Defines your name for NetMail messages generated by Raid in manual mode. This directive simply "personalizes" NetMail you direct Raid to generate rather than using the default. Response mode NetMail replies always use the Raid id rather than the System Operator name. Default: Sysop Example: SYSOP George Peace Origin Defines the default "origin line" text to be displayed in all local EchoMail messages generated. Raid will insert the " * origin " and "(z:n/n)" fields as it generates the messages. This field must be 60 characters or less. Default: blank Example: ORIGIN Support your local file echo links Tick Defines the path and filename for the Tick control file. If this directive is not provided Raid looks for TIC.CFG in the current directory. The -T command line switch overrides this directive. See page 7 for -T definition. Copyright 1989-91 by George Peace - All rights reserved page 29 Raid v1.21 *test* July, 1991 Default: TIC.CFG in the default directory or as identified by the -T command line switch. Example: TICK C:\BBS\TIC.CFG Log Defines the path and filename for the Raid log file. If This directive is not provided Raid updates RAID.LOG in the current directory. The command line -L switch overrides this directive. If Raid cannot read or update the log file (whether defined in Raid.Cfg or -L) execution proceeds without a log file. See page 7 for -L definition. Default: RAID.LOG in the default directory Example: LOG C:\BBS\RAID.LOG LOG CON NetMail Defines the path for the NetMail message area. This directive must be provided if Raid will be operated in response mode or if NetMail is generated in manual mode ([AUTO]CREATE, NETREPORT, NOTIFY, -M command line switch, etc.). The path can terminate with or without a backslash (\). An optional second field controls generation of NetMail response messages. If the field is specified as "PKT" all NetMail responses generated by Raid will be written to a .PKT rather than to the defined NetMail directory. The destination of the .PKT is determined by the Pkt_Path directive. Default: no default available Example: NETMAIL C:\MSG\NETMAIL NETMAIL C:\MSG_NETMAIL PKT Pkt_Path Defines the path outbound .Pkt format messages. If the path is not defined Raid will use the inbound path defined by the Tick control file IN directive. The path can terminate with or without a backslash (\). Default: IN directory from Tic.Cfg Copyright 1989-91 by George Peace - All rights reserved page 30 Raid v1.21 *test* July, 1991 Example: PKT_PATH C:\INBOUND InfoFile This file will be file-attached to a response mode NetMail reply message if the remote requestor included the -I (information request) modifier after the access password on the message subject line. If the filename contains wildcard characters (* ?) the first filename matching the specification will be attached. If the "infofile" directive is not provided or no matching filename is found -I requests will be ignored. An example RAIDINFO.TXT is provided with the Raid release. Default: none -- -I on remote requests is disabled Example: INFOFILE C:\BBS\INFOFILE.TXT INFOFILE C:\BBS\RAIDINFO.??? ErrorSuffix Defines the file to be transferred to the body of response mode rejection replies if the requestor's network address is not defined on an "access" configuration directive. If the filename contains wildcard characters (* ?) the first filename matching the specification will be used. If the "errorsuffix" directive is not provided or no matching filename is found the response will include only a one line error notification. An example RAIDERR.TXT is provided with the Raid release. Default: none Example: ERRORSUFFIX C:\BBS\RAIDERR.TXT ERRORSUFFIX C:\BBS\RAIDERR.??? PasswordSuffix Defines the file to be transferred to the body of response mode rejection replies if the requestor's password does not match the one defined on the "access" configuration directive for that network address. Copyright 1989-91 by George Peace - All rights reserved page 31 Raid v1.21 *test* July, 1991 If the filename contains wildcard characters (* ?) the first filename matching the specification will be used. If the "passwordsuffix" directive is not provided or no matching filename is found the response will include only a one line error notification. An example RAIDPWD.TXT is provided with the Raid release. Default: none Example: PASSWORDSUFFIX C:\BBS\RAIDPWD.TXT PASSWORDSUFFIX C:\BBS\RAIDPWD.??? Alias Defines names Raid will recognize in addition to "Raid" in the To: field of incoming NetMail messages. Each "alias" must be a single word up to 32 characters in length with no embedded punctuation, blanks, or tabs. Case is ignored. Up to 100 "alias" directives can be defined. Default: none Example ALIAS TICKFIX ALIAS TICK ALIAS FIXTICK Def_Password Defines the default password to be used for manual add requests (add) when no "access" definition exists for the target network address. The password value can be any password string accepted by Tick. The -P command line switch overrides this directive (and the access password). The password length is limited to a maximum of eight characters. Default: PASSWORD Example: DEF_PASSWORD PassWord Copyright 1989-91 by George Peace - All rights reserved page 32 Raid v1.21 *test* July, 1991 Def_Flags Defines the default flags to be used for manual add requests when no "access" definition exists for the target network address. The flags value can be any string accepted by Tick. This will also determine the routing behavior of NetMail generated as a result of manual find/add/delete requests when no "access" definition exists for the target network address. "C" forces crash or express priority, "D" forces direct delivery (where supported via packer software) and "H" forces the message to be held for pickup. If neither is present in the default flags field generated messages will be flagged for "normal" routing. "NetMailBehavior" and "NotifyBehavior" directives as well as the command line -M switch override the "Def_Flags" C and H settings. Default: none Example: DEF_FLAGS *H Def_Key Defines the default keys to be used for manual add requests when no "access" definition exists for the target network address. This value is also used for nonconfigured remote requestors along with the "def_password" and "def_flags" values. Default: none Example: DEF_KEY A*9P Open_System Configures Raid to accept NetMail requests from any network address. Requests from addresses not configured in raid.cfg ("access" configuration directive) will be processed as if configured. Response mode processing will be adjusted such that requests will be honored for file areas with security levels equal to or lower than the "access_default" defined level. Open processing can be set up as "open" or as restrictive as the SysOp requires. A totally open system might be configured with no "access" or "area" directives and (in addition to required directives): Copyright 1989-91 by George Peace - All rights reserved page 33 Raid v1.21 *test* July, 1991 Open_System Access_Default 0 Area_Default 0 Def_Password PASSWORD Def_Flags H Def_Key This configuration will allow any network address to add/change/delete any file echo area defined in the tick control file. Unattended automation can be extended somewhat by adding "autocreate" to the Raid command line: RAID -R AUTOCREATE Default: disabled Example: OPEN_SYSTEM Access_Default Defines the default access level assigned to network addresses not defined by "access" configuration directives. This directive is used in conjunction with the "open_system" directive to define how "open" a system should be. Default: 0 Example: ACCESS_DEFAULT 10 Access Defines all security access and control parameters for a network address. Access directives must be present for any network addresss accessing Raid remotely. The directives are optional for other network addresses but will enable increased control and ensure consistent manual operations if provided. Up to 500 network addresses can be defined. All "access" fields are "positional". As a result, all fields to the left of any field specified are necessary for proper use. For example, if you want to use the sysop entry the mail and flags fields are also required. The required net address field specifies the full network address. It must be in zone:net/node format. Copyright 1989-91 by George Peace - All rights reserved page 34 Raid v1.21 *test* July, 1991 The required password entry is the password a remote requestor must use as the NetMail subject for security validation. It is also the default password for manual and remote ADD requests unless overridden by a remote request or the command line -P switch. The password field is case-insensitive. The required security level entry is used to define update capabilities for the network address. A value of 0 disables remote updates but allows inquiries if other security requirements are satisfied. The field is also used by the manual mode NOTIFY function in order to list accessible area names. Each of the following optional fields must be provided in a specific sequence in order to be recognized and processed. Blank or unnecessary (for your application) can be replaced by a single period (.) to hold the place. The optional key field defines a list of 0 to 33 permission flags that can be set (present) or clear (not present) for a network address. Permission keys can be selected from A-Z, 0-5, and *. The first 32 permission keys can be set individually or in combination to build a "key". If a lock is in place for an area any network address issuing a remote request to add/delete/change that area must have at least every corresponding permission flag set or access is denied. "Access" key 'AXP' will open "area" locks 'A', 'AX', and 'AXP' but will fail to open 'AXP2'. The optional flags entry is used to build connection entries generated by manual and remote ADD requests unless overridden by the command line -F switch. If the field is blank, the value defined by the DEF_FLAGS directive will be used. The optional mail entry defines the outbound behavior of any NetMail Raid generates to a network address. Allowable values are C (Crash or Express delivery), D (Direct routing), H (Hold for pickup) and N (Normal routing as defined by the packer and mailer). The mail value can be overridden by the -Mx and -Rx command line switches. If the mail value is omitted, the flags field contents (or "def_flags") determines outbound NetMail behavior. The optional system operator field allows Raid to "personalize" netmail generated to a network address by Raid. NetMail message format limitations require that only first 36 characters be used. Default: none Example: net address password level key flags mail sysop ----------- -------- ----- --- ----- ---- ----- Access 1:13/0 Password 4095 ABC *C N George Peace Access 1:270/102 Plugh 10 . H H Access 99:999/999 xYzzY 1 1F* . C Who Are You? Copyright 1989-91 by George Peace - All rights reserved page 35 Raid v1.21 *test* July, 1991 Area Defines the response mode access security level for a Tick area block. Up to 500 areas can be defined. The required security level field identifies the lowest network address "Access" security level able to add itself for distribution of this file area. A value of 0 defines the area for "unrestricted" access. The area security level is not used for response mode delete requests. All file areas not explicitly defined with "Area" directives are assigned the security level provided on the "AreaDefault" directive. Each of the following optional fields must be provided in a specific sequence in order to be recognized and processed. Blank or unnecessary (for your application) can be replaced by a single period (.) to hold the place. The optional lock field defines a list of 0 to 33 permission flags that can be set (present) or clear (not present) for a file area. Permission flags can be selected from A-Z, 0-5, and *. The first 32 permission flags can be set individually or in combination to build a "lock". If a lock is in place for an area any network address issuing a remote request to add/delete/change that area must have at least every corresponding permission flag set or access is denied. "Access" key 'AXP' will open "area" locks 'A', 'AX', and 'AXP' but will fail to open 'AXP2'. The optional description field describes the contents or purpose of the file area. Remote callers who include the -Q modifier after the password on the message subject line will receive a specially formatted "available areas" display that includes this description. Only the first 60 characters are used. See the section titled "Controlling the Available Area Display" for additional information. Default: none Example: areaname level lock Description -------- ----- ---- ---------1---------2---------3------- Area DAZZLE 200 9A4 Distribution of DAZZLE software Area SWIZZLE 100 *1 Software to stir a crowd AreaDefault Defines the default area access security level for Tick area blocks not explicitly defined by "Area" directives. A value of 0 defines an area for "unrestricted" access. Copyright 1989-91 by George Peace - All rights reserved page 36 Raid v1.21 *test* July, 1991 Default: 0 Example: AREADEFAULT 20 HideArea Defines the lowest file "area" security level to hide from remote requestors. Any area defined with a security level equal to or higher than "hidearea" will not be displayed in the list of available areas in NetMail response messages. This offers protection for "private" areas that are accessible only by special arrangement but would otherwise be visible to all requestors. Default: none Example: HIDEAREA 1000 HideProtected Instructs Raid to limit the availabe area display to only file areas that are available for unrestricted access by the target address. Default: display all areas at or below HideArea security level Example: HideProtect WildCard Defines the "process ALLOWED file areas" literal for manual mode add requests. Manual mode delete requests using the wildcard literal will delete ALL file areas for the target network address. The wildcard literal is not accepted in response mode NetMail update requests. Default: ALL Example: WILDCARD SOME Global_WildCard Defines the "process ALL file areas" literal for manual mode add and delete requests. The global wildcard literal is not accepted in response mode NetMail update requests. Copyright 1989-91 by George Peace - All rights reserved page 37 Raid v1.21 *test* July, 1991 Default: WORLD Example: WILDCARD EVERYTHING NetMailBehavior Sets the default behavior of NetMail generated in "response mode" and in "manual mode" with the -M command line switch. Values accepted are C (crash priority), D (direct routing), or H (hold for pickup) and K (kill message when sent). The "K" value can be used in combination with "C" or "D" or "H" to cause all non-Notify NetMail messages to be deleted after being sent. It has the same function and meaning as the -MK command line switch (RAID -MK <request...>). The "C", "D", and "H" values take precedence over C, D, and H flag values assigned by "Access" configuration directives (only for NetMail generation). Both "Access" flags and "NetMailBehavior" flags will be overridden by command line switch -MC, -MD, or -MH. Be careful! Unless you are local to all your connections, "NETMAILBEHAVIOR C" can be expensive. Default: none Example: NETMAILBEHAVIOR KH KillReceived Causes all Response mode NetMail requests to be deleted from the NetMail message area after being processed by Raid. If the request is rejected by Raid it will not be deleted. Default: NO Example: KILLRECEIVED YES Force_Intl Forces generation of an ^AINTL line in each NetMail response message generated by Raid regardless of the destination zone. This overrides the normal operation in which an ^AINTL line is generated only when the destination (requestor) zone is different from either the home zone or the zone the request message was addressed to. Copyright 1989-91 by George Peace - All rights reserved page 38 Raid v1.21 *test* July, 1991 Default: NO Example: FORCE_INTL YES AlertNode Triggers generation of copies of all response mode NetMail messages (.MSG format only) to a list of one network addresses. Default: no alert messages generated Example: ALERTNODE 1:13/13 TearLine Causes all Response mode NetMail requests to be deleted from the NetMail message area after being processed by Raid. If the request is rejected by Raid it will not be deleted. Default: No tearline generated Example: TEARLINE PointNet Defines the private point network number assigned to the distribution system. If PointNet is configured (and not zero) and response mode requests are received from one of the distribution system's points the "pointnet" network will be used for access validation and add/delete requests. Traffic from a point is defined as netmail both from and to the distribution system network address with "^AFMPT #" in the message body. As a result, "yourzone:pointnet/pointnumber" will be used for remote update requests from your points. Manual mode requests that accept addresses will translate the z:net/node.point format to pointnet/point when the net/node on the request are your primary address net and node. Default: none Example: POINTNET 30000 Copyright 1989-91 by George Peace - All rights reserved page 39 Raid v1.21 *test* July, 1991 Notifying Your Connections of Their Status NotifyPrefix Defines the file to be transferred to the body of each status notification (notify) NetMail message. This descriptive text message is displayed as the introductory text in all connection status notification messages. This message might describe your file distribution setup and provide instructions for remote access to Raid's response mode. If the filename contains wildcard characters (* ?) the first filename matching the specification will be inserted. If the "notifyprefix" directive is not found or no matching filename is found a brief default notify prefix will be inserted. An example RAIDNOTE.TXT is provided with the Raid release. Default: RAIDNOTE.TXT in the default directory Example: NOTIFYPREFIX C:\BBS\RAIDNOTE.TXT NotifyExclude Defines individual network addresses (z:net/node format) to exclude from connection status notification mass mailings (RAID NOTIFY). Each occurrence of the directive excludes one address. Up to 500 addresses can be excluded. Default: none Example: NOTIFYEXCLUDE 1:13/0 NOTIFYEXCLUDE 2:123/456 NotifyThreshold Network addresses must have at least this number of active area connections in TIC.CFG to be included in a normal notify operation (RAID NOTIFY). The default value of one excludes all network addresses with no active connections listed. Default: 1 Example: NOTIFYTHRESHOLD 0 Copyright 1989-91 by George Peace - All rights reserved page 40 Raid v1.21 *test* July, 1991 NotifyMinimum Specifies the lowest "access" security level that will be processed by notify requests. Any network address with a lower "access" security level will be bypassed. The default value of zero implies that all addresses listed in TIC.CFG that pass other tests will receive notification messages. Any other value causes notification messages to be generated only for network addresses with "access" directives because the default security level without "access" is zero. Default: 0 Example: NOTIFYMINIMUM 10 NotifyMaximum Specifies the highest "access" security level that will be processed by "notify" requests. Any network address with a higher "access" security level will be bypassed. Default: 4095 Example: NOTIFYMAXIMUM 999 NotifyBehavior Sets the default behavior of NetMail generated by the Notify command. Values accepted are C (crash priority), D (direct routing), or H (hold for pickup) and K (kill message when sent). The "K" value can be used in combination with "C" or "D" or "H" to cause all Notify NetMail messages to be deleted after being sent. It has the same function and meaning as the -MK command line switch (RAID -MK NOTIFY). The "C", "D", and "H" values take precedence over C, D, and H mail values assigned by "Access" configuration directives (only for NetMail generation). Both "Access" flags and "NotifyBehavior" flags will be overridden by command line switch -MC, -MD, or -MH. Be careful! Unless you are local to all your connections, "NOTIFYHEHAVIOR C" can be expensive. Default: none Example: NOTIFYBEHAVIOR K Copyright 1989-91 by George Peace - All rights reserved page 41 Raid v1.21 *test* July, 1991 Announcing New File Arrivals Several directives are available to activate and customize new file arrival notices. This is a powerful and flexible announcement facility that allows multiple announce destinations and custom announcement formats and contents. This facility can be intimidating at first glance. The easiest (and recommended) way to get started is to define only the Announce_Msg directive. All other announce directives can remain in their default conditions. This will direct Raid to generate file arrival announcement messages for all files received. Announce_Msg This directive activates the announce facility and defines the default destinations for new arrival announcements. If a field contains a colon (:) and at least one backslash (\) Raid interprets the destination as a .MSG subdirectory. If one or both are missing Raid writes messages in EchoMail format using the field contents as the area name. In this case messages are written to .PKTs in the directory defined by the Tick control file "IN" directive. Disposition of the .PKT is left to the sysop and tossing software. A directive with no destination field causes the default announce destination to NetMail as defined by the "netmail" directive. NetMail can be indicated along with other requests by adding an asterisk (*) to the list. If the asterisk is followed by a net address (z:net/node) a copy of the message is netmailed to the indicated address. If no address is provided the message is addressed to the primary configured address. Any number of "announce_msg" directives can be used. Default announce messages will be written to all areas and paths listed in all "announce_msg". Default: disabled Example: ANNOUNCE_MSG C:\MSG\NEWFILES ANNOUNCE_MSG C:\MSG\GENERAL\ NEWFILES ANNOUNCE_MSG NEWFILES * GENERAL *1:270/101 Announce_From Personalizes the "from" field in new arrival announcement messages. This field must be 35 characters or less. Copyright 1989-91 by George Peace - All rights reserved page 42 Raid v1.21 *test* July, 1991 Default: the name from the "sysop" directive" Example: ANNOUNCE_FROM File Echo Manager Announce_To Personalizes the "to" field in new arrival announcement messages. This field must be 35 characters or less. Default: All Example: ANNOUNCE_TO File Echo Fanatics Announce_Subject Personalizes the "subject" field in new arrival announcement messages. This field must be 71 characters or less. Default: File arrival announcement Example: ANNOUNCE_SUBJECT Files received at My BBS Announce_Origin Defines the "origin line" text to be displayed in file arrival notice messages. Raid will insert the " * origin " and "(z:n/n)" strings as it generates messages. The string must be 60 characters or less. Default: blank Example: ANNOUNCE_ORIGIN Brought to you by your friendly file feed Announce_Only Defines an exclusive list of file areas that will be reported by the announce facility. If at least one "announce_only" directive is present, only file arrivals in areas defined by the directive(s) will be announced. Announce_Area directives will be ignored. Copyright 1989-91 by George Peace - All rights reserved page 43 Raid v1.21 *test* July, 1991 The directive has optional fields to control the destination of announcement messages for the file area. If a field contains at least one colon (:) and at least one backslash (\) Raid interprets the destination as a .MSG subdirectory. If one or both are missing Raid writes messages in EchoMail format using the field contents as the area name. In this case messages are written to .PKTs in the directory defined by the Tick control file "IN" directive. Disposition of the .PKT is left to the sysop and tossing software. A directive with no destination field causes the announce message to be written to NetMail as defined by the "netmail" directive. NetMail can be indicated along with other requests by adding an asterisk (*) to the list. Partial file area names are recognized and expanded if the last character is an asterisk (*). In that case the directive will be interpreted as if all area names whose initial characters match the characters preceding the asterisk had been provided. Default: none Example: ANNOUNCE_ONLY FIDONEWS ANNOUNCE_ONLY NODEDIFF V:\NetMail ANNOUNCE_ONLY RAIDBETA * PRIVATE Announce_Area Defines destinations of announce messages for individual file areas. The directive has optional fields to control the destination of announcement messages for the file area. If a field contains at least one colon (:) and at least one backslash (\) Raid interprets the destination as a .MSG subdirectory. If one or both are missing Raid writes messages in EchoMail format using the field contents as the area name. In this case messages are written to .PKTs in the directory defined by the Tick control file "IN" directive. Disposition of the .PKT is left to the sysop and tossing software. A directive with no destination field causes the announce message to be written to NetMail as defined by the "netmail" directive. NetMail can be indicated along with other requests by adding an asterisk (*) to the list. Partial file area names are recognized and expanded if the last character is an asterisk (*). In that case the directive will be interpreted as if all area names whose initial characters match the characters preceding the asterisk had been provided. Default: none Copyright 1989-91 by George Peace - All rights reserved page 44 Raid v1.21 *test* July, 1991 Example: ANNOUNCE_AREA DVNET GENERAL ANNOUNCE_AREA NODEDIFF V:\PRIVATE Announce_Header Defines the content of the header that is written at the start of each announcement. Default: see sample configuration file Example: see sample configuration file Announce_Trailer Defines the content of the trailer that is written at the end of announcement messages. Default: see sample configuration file Example: see sample configuration file Announce_Cont_Header Defines the content of the header that is written at the start of each announcement continuation message. Default: see sample configuration file Example: see sample configuration file Announce_Cont_Trailer Defines the content of the trailer that is written at the end of each announcement continuation message. Default: see sample configuration file Example: see sample configuration file Copyright 1989-91 by George Peace - All rights reserved page 45 Raid v1.21 *test* July, 1991 Announce_Template Defines any number of announce message content and layout formats. Default: see sample configuration file Example: see sample configuration file Announce_Format Identifies which message template format will be used for a list of file areas. Partial file area names are recognized and expanded if the last character is an asterisk (*). In that case the directive will be interpreted as if all area names whose initial characters match the characters preceding the asterisk had been provided. Default: The first Announce_Template defined. Example: ANNOUNCE_FORMAT rfp SDS* SOFTDIST ANNOUNCE_FORMAT trace NODEDIFF Announce_Dest_Format Identifies which message template format will be used for a list of announce message destinations (subdirectory, echo tag, address). The first parameter is the template format. It can be followed by one or more message destinations as defined on Announce_Only and Announce_Area directives. If this directive is used it will override all other format definitions and defaults for the specified message destination. Default: None Example: ANNOUNCE_DEST_FORMAT full *270/101 ANNOUNCE_DEST_FORMAT rfp SOFTWARE SWCOORD Copyright 1989-91 by George Peace - All rights reserved page 46 Raid v1.21 *test* July, 1991 Creating New File Echo Areas Several directives are available to activate and customize creation of new file echo areas Newarea_Process This directive allows Raid to process previously unknown file echo areas. It is the master "switch" that activates all "newarea_???" directive processing. Default: disabled Example: NEWAREA_PROCESS Newarea_Path Defines the base path for subdirectory creation. Each new area is created as <newarea_path><areaname>. The trailing slash following the base path will be added if missing. If path is preceded by a + character, the path given will be used for all create/autocreate operations rather than apending <areaname>. Default: none -- required if Newarea_Process is defined Example: NEWAREA_PATH C:\FILES\ NEWAREA_PATH O: NEWAREA_PATH +D:\ALLAREAS Newarea_Create Defines network addresses that can create new areas. The "from" field in incoming .TIC files is compared to this list. If the area is not defined and arrived from a "newarea_create" address it is processed. An optional list of wildcarded area names can follow the address. Raid will use that list to decide which new areas the address can create. No list implies unrestricted create capability. One address can be specified on each directive. Any number of addressed can be defined. Default: none Copyright 1989-91 by George Peace - All rights reserved page 47 Raid v1.21 *test* July, 1991 Example: NEWAREA_CREATE 1:234/567 NEWAREA_CREATE 2:1234/5678 D?N* SD* Newarea_Node Defines network addresses that will be automatically added to areas created by CREATE and AUTOCREATE functions. An optional list of wildcarded area names can follow the address. Raid will use the list to decide whether the address should be added to newly created areas. No list implies all new areas. One address can be specified on each directive. Any number of addressed can be defined. If an "access" directive is found for the address, the password and flag fields from that directive will be used for the automatic add. Otherwise the "def_password" and "def_flags" values will be used. Default: none Example: NEWAREA_NODE 1:234/567 NEWAREA_NODE 2:1234/5678 SDS* SDN* Newarea_Msg Defines the destination for new area creation announcements. The directive defines the destinations of create/autocreate announcements. If a field contains a colon (:) and at least one backslash (\) Raid interprets the destination as a .MSG subdirectory. If one or both are missing Raid writes messages in EchoMail format using the field contents as the area name. In this case messages are written to .PKTs in the directory defined by the Tick control file "IN" directive. Disposition of the .PKT is left to the sysop and tossing software. A directive with no destination field causes the announcement to be written to NetMail as defined by the "netmail" directive. NetMail can be indicated along with other requests by adding an asterisk (*) to the list. If the asterisk is followed by a net address (z:net/node) a copy of the message is netmailed to the indicated address. If no address is provided the message is addressed to the primary configured address. Default: disabled Copyright 1989-91 by George Peace - All rights reserved page 48 Raid v1.21 *test* July, 1991 Example: NEWAREA_MSG C:\MSG\NEWFILES NEWAREA_MSG C:\MSG\GENERAL\ * NEWAREA_MSG NEWFILES *1:270/101 Newarea_From Personalizes the "from" field in new file area creation messages. This field must be 35 characters or less. Default: the name from the "sysop" directive" Example: NEWAREA_FROM File Echo Manager Newarea_To Personalizes the "to" field in new file area creation messages. This field must be 35 characters or less. Default: All Example: NEWAREA_TO File Echo Fanatics Newarea_Subject Personalizes the "subject" field in new file area creation messages. This field must be 71 characters or less. Default: File creation announcement Example: NEWAREA_SUBJECT Another NEW FILE AREA at My BBS! Newarea_Origin Defines the "origin line" text to be displayed in new area creation messages. Raid will insert the " * Origin " and "(z:n/n)" strings as it generates the messages. The string must be 60 characters or less. Default: blank Example: NEWAREA_ORIGIN Another file echo from the SDS Copyright 1989-91 by George Peace - All rights reserved page 49 Raid v1.21 *test* July, 1991 Reporting File Echo Connections Report_File This directive defines a file where file echo area connection lists will be written. If the filename is not defined Raid will not attempt to generate the list as a file. Either "report_file" or "report_msg" (or both) must be defined in order to use "RAID REPORT" from the command line. "RAID NETREPORT" is not affected by this directive. Default: disabled Example: REPORT_MSG C:\MSG\R13SDS REPORT_MSG C:\MSG\GENERAL\ Report_Msg This directive defines the destination for file area connection report messages. The directive controls the destination of report messages. If the field contains at least one colon (:) and at least one backslash (\) Raid interprets the destination as a .MSG subdirectory. If one or both are missing Raid writes messages in EchoMail format using the field contents as the area name. In this case messages are written to .PKTs in the directory defined by the Tick control file "IN" directive. Disposition of the .PKT is left to the sysop and tossing software. A directive with no destination field causes the message to be written to NetMail as defined by the "netmail" directive. NetMail can be indicated by using a single asterisk (*). Either "report_file" or "report_msg" (or both) must be defined in order to use "RAID REPORT" from the command line. "RAID NETREPORT" is not affected by this directive. Default: disabled Example: REPORT_MSG C:\MSG\R13SDS REPORT_MSG C:\MSG\GENERAL\ REPORT_MSG PRIVATE Copyright 1989-91 by George Peace - All rights reserved page 50 Raid v1.21 *test* July, 1991 Report_Prefix Defines the file to be transferred to the body of each file area connection summary ([net]report) generated. If the filename contains wildcard characters (* ?) the first filename matching the specification will be inserted. If the "report_prefix" directive is not found or no matching filename is found a brief default prefix message will be inserted. An example RAIDRPT.TXT is provided with the Raid release. Default: RAIDRPT.TXT in the default directory Example: REPORT_PREFIX C:\BBS\RAIDRPT.TXT Report_From Personalizes the "from" field in report EchoMail messages. This field must be 35 characters or less. Default: the name from the "sysop" directive" Example: REPORT_FROM File Echo Manager Report_To Personalizes the "to" field in report EchoMail messages. This field must be 35 characters or less. Default: All Example: REPORT_TO File Echo Fanatics Report_Subject Personalizes the "subject" field in report messages. This field must be 71 characters or less. Default: File area distribution report Example: REPORT_SUBJECT Where The File Areas Are Going Copyright 1989-91 by George Peace - All rights reserved page 51 Raid v1.21 *test* July, 1991 Report_Origin Defines the "origin line" text to be displayed in report messages. Raid will insert the " * origin " and "(z:n/n)" strings as it generates the messages. The string must be 60 characters or less. Default: blank Example: REPORT_ORIGIN Another file echo from the SDS Copyright 1989-91 by George Peace - All rights reserved page 52 Raid v1.21 *test* July, 1991 Changing the Tick Control File Appearance The appearance of the Tick control file can be adjusted with this directive. The directive will direct Raid to write the control file in different formats following update operations. TidyNodes Activates a "tidying up" of the Tick control file when it is written back to disk following update operations. All active address lines in all AREA blocks in the Tick control file will be aligned vertically on 16 character boundaries. An area block like this: AREA C:\FILES FILEAREA 1:123/456 PassWord *H 2:123/654 PASSWORD HA2 will look like this after tidying: AREA C:\FILES FILEAREA 1:123/456 PassWord *H 2:123/654 PASSWORD HA2 Default: none Example: TIDYNODES Add_Template Defines the location of address, password, and flag fields for add/update operations affecting tic.cfg. The string must begin and end with the " (double-quote) character and must include three 'C' language style string definition fields. Tabs or other special characters must be entered as a the true character rather than the \t etc. Minimal error checking is performed on this string. If the string contains errors the results are "unpredictable". Default: " %-15s %-15s %s" Example: ADD_TEMPLATE "%s %s %s" Copyright 1989-91 by George Peace - All rights reserved page 53 Raid v1.21 *test* July, 1991 Tidy_Template Defines the location of address, password, and flag fields when "tidynodes" is activated and the Tick contril file is rewritten. The string must begin and end with the " (double-quote) character and must include three 'C' language style string definition fields. Tabs or other special characters must be entered as a the true character rather than the \t etc. Minimal error checking is performed on this string. If the string contains errors the results are "unpredictable". Default: " %-15s %-15s %s" Example: TIDY_TEMPLATE "%s %s %s" SortNodes Activates a sort of each AREA block in the Tick control file as it is written back to disk following update operations. All active address lines in all AREA blocks in the Tick control file will be sorted in ascending numeric order by zone, net, and node. The "tidynodes" directive must be active if this directive is used. Area blocks like this: AREA C:\NODEDIFF NODEDIFF 3:191/282 PassWord *H 1:123/654 PASSWORD HA2 1:123/456 PassWord *H 2:123/654 PASSWORD HA2 AREA C:\SOFTDIST SOFTDIST ListFmt %100:31%3:-12 %1:48.2 2:123/654 PASSWORD HA2 1:456/123 PassWord *H will look like this after the sort: AREA C:\NODEDIFF NODEDIFF 1:123/456 PassWord *H 1:123/654 PASSWORD HA2 2:123/654 PASSWORD HA2 3:191/282 PassWord *H AREA C:\SOFTDIST SOFTDIST ListFmt %100:31%3:-12 %1:48.2 1:456/123 PassWord *H 2:123/654 PASSWORD HA2 Default: none Copyright 1989-91 by George Peace - All rights reserved page 54 Raid v1.21 *test* July, 1991 Example: SORTNODES SortAreas Activates a sort of all AREA block in the Tick control file as they are written back to disk following update operations. All REAA blocks are sorted in ascending sequence according to the area name. Area blocks like this: AREA C:\SOFTDIST SOFTDIST ListFmt %100:31%3:-12 %1:48.2 2:123/654 PASSWORD HA2 AREA C:\NODEDIFF NODEDIFF 3:191/282 PassWord *H will look like this after the AREA block sort: AREA C:\NODEDIFF NODEDIFF 1:123/456 PassWord *H AREA C:\SOFTDIST SOFTDIST ListFmt %100:31%3:-12 %1:48.2 1:456/123 PassWord *H Default: none Example: SORTAREAS Copyright 1989-91 by George Peace - All rights reserved page 55 Raid v1.21 *test* July, 1991 Controlling File Area Lists Several directives are available to control the available area list Raid appends to NetMail response messages. The display width, amount of information, and special notation characters can all be defined. The available area list can displayed in either short or long format. "Short" format simply lists area names with active and protection indicators. Multiple area names are displayed on one line. "Long" format is always exactly one area per line. The first 60 characters of "area" directive description data is displayed following the area name. AreasPerLine Defines the number of area names to display per line when reporting available areas in short format. Each area name requires 12 character positions so the maximum practical value for an 80 column line width is 6 (12 x 6 = 72). Higher values (up to 4095) can e defined for a "wrap" effect. Default: 5 Example: AREASPERLINE 4 Available Provides control of the available area display format in NetMail response messages (except NOTIFY function messages). Six variations are available ranging from no display to unconditionally providing long format displays. - NEVER Unconditionally disable the available area display. The -Q request modifier is ignored. - NORMAL Display a short format available area list unless the remote requestor used the -Q request modifier. Display the long format list if -Q was used. - REQUEST SHORT Disable the available area display unless the remote requestor used the -Q request modifier. Display the short format area list if -Q was used. - REQUEST LONG Disable the available area display unless the remote requestor used the -Q request modifier. Display the long format area list if -Q was used. Copyright 1989-91 by George Peace - All rights reserved page 56 Raid v1.21 *test* July, 1991 - ALWAYS SHORT Ignore the -Q request modifier and always display the short format area list. - ALWAYS LONG Ignore the -Q request modifier and always display the long format area list. Default: NORMAL Example: AVAILABLE ALWAYS LONG AVAILABLE NEVER NotifyAvailable Provides control of the available area display format in NetMail messages generated by the NOTIFY function. Three variations are available. - NEVER Unconditionally disable the available area display. The -Q request modifier is ignored. - ALWAYS SHORT Always display the short format area list. - ALWAYS LONG Always display the long format area list. Default: ALWAYS SHORT Example: NOTIFYAVAILABLE ALWAYS LONG NOTIFYAVAILABLE NEVER Active_Marker Defines the character used to mark "active" file echo area names in the available areas summary displayed in NetMail messages. Default: * Example: ACTIVE_MARKER $ Priv_Marker_Left Defines the character used to offset the left end of restricted or private file echo area names displayed in the available areas list appended to all Raid NetMail messages. Default: < Copyright 1989-91 by George Peace - All rights reserved page 57 Raid v1.21 *test* July, 1991 Example: PRIV_MARKER_LEFT { Priv_Marker_Right Defines the character used to offset the right end of restricted or private file echo area names displayed in the available areas list appended to all Raid NetMail messages. Default: > Example: PRIV_MARKER_RIGHT } Copyright 1989-91 by George Peace - All rights reserved page 58 Raid v1.21 *test* July, 1991 The Log File Raid maintains an audit trail of every significant operation performed and error encountered. Redundant and trivial log entries are avoided in order to keep the log file size to a minimum. This speeds up log file data reduction and reduces disk storage overhead. The log file defaults to a name of RAID.LOG in the default directory (where you were when you executed Raid). The command line -L switch can be used to change the log destination or to eliminate it entirely... -Ld:\directory\file.ext This format overrides the log file destination defined in the "log" configuration directive to d:\directory\file.ext. -L This format disables all log file activity. The same effect (with slightly higher execution time overhead) can be achieved by defining NUL as the logfile destination on the "log" configuration directive. If Raid cannot write to the log file for any reason the program will disable all log file activity as if -L was present on the command line. Raid appends new entries to the log file and terminates the file with a control Z (^Z) after each session. Log entries are formatted similarly to those generated by Opus, BinkleyTerm, and Tick as: 20 Oct 23:42:49 RAID <data to be logged> Errors will be logged with an exclamation point in column one and a text explaining the error in the data area. Normal Raid operation log entries will consist of a unique six character keyword followed by additional information as required. Keywords and data fields include: ADDNOF zone:net/node area password Zone:net/node was not added because area was not located. ADDREQ zone:net/node area password flags Zone:net/node was added to area with password and flags. CREATE filearea fromnode New file area created. Copyright 1989-91 by George Peace - All rights reserved page 59 Raid v1.21 *test* July, 1991 DELNOF zone:net/node area Zone:net/node was not active in area. DELREQ zone:net/node area password flags Zone:net/node was deleted from area. MSGECH path An EchoMail reply was generated in path. MSGNET zone:net/node behavior A NetMail reply was generated to zone:net/node with the indicated NetMail behavior. NETNOF zone:net/node password Zone:net/node was not found in the "access" table. NETPAS zone:net/node password The access password used by zone:net/node was not valid. NETREP zone:net/node password A response mode NetMail message was received from zone:net/node (point) using the indicated access password. NETREQ zone:net/node password A response mode NetMail message was received from zone:net/node using the indicated access password. NETSEC zone:net/node password security Zone:net/node was found in the "access" table and was not authorized to use response mode. NEWFIL filename (size) filearea origin from File arrival announcement NOTIFY zone:net/node behavior A connection notification NetMail message was generated for zone:net/node with the indicated NetMail behavior. Copyright 1989-91 by George Peace - All rights reserved page 60 Raid v1.21 *test* July, 1991 MS-DOS Errorlevels Returned In addition to information provided in its log file, Raid sets the MS- DOS errorlevel to one of several values. 0 No updates to the TICK control file and no NetMail messages generated with -M switch set. 1 NetMail was generated in RESPONSE mode or in command line mode with the -M switch set. 5 An error was encountered reading the TICK control file. Processing is terminated without applying updates. 6 An error was encountered writing the updated TICK control file. Processing is terminated without applying updates. 7 A critical error occurred renaming the temporary (updated) TICK control file to overlay the actual file. Though this error should be extremely rare, it will require immediate attention if it occurs since the original Tick control file has been renamed to TIC.OLD (or d:\filename.OLD as provided by the command line -C switch). 8 An error has occurred accessing the NetMail directory for read or write. This includes failure to locate the directory as defined in TIC.CFG (MAIL directive) and errors reading and writing NetMail messages in that directory. 9 At least one fatal error was encountered while processing the Raid configuration file. 10 Raid ran out of available memory to store data from its own configuration file or data from the Tick control file. Either reduce the amount of optional configuration data (area descriptions and sysop names) or increase the memory partition size. 11 Raid ran out of memory while processing a manual or remote request. The name of the routine where the failure occurred will be displayed to assist in problem analysis. Either reduce the amount of optional configuration data (area descriptions and sysop names) or increase the memory partition size. 99 Miscellaneous errors causing Raid to terminate prematurely. As with the other error conditions, Raid will not apply updates. Copyright 1989-91 by George Peace - All rights reserved page 61 Raid v1.21 *test* July, 1991 Other Topics Release Information Public releases of Raid will always be "whole" numbers such as 1.00, 2.00, etc. Intermediate test and special function releases will always be "fractional" such as 1.02, 2.20, etc. The latest public release of Raid will always be requestable from 1:270/101 as RAID. A Few Words About Raid and Zones Zone support within Raid doesn't pretend to be all-knowing or entirely without fault. Raid does attempt to be zone-smart rather than merely zone-aware. But there are a few things that technical standards and some current message packers will just not let us do. If you select a non-(N)ormal outbound behavior value -- (C)rash or (D)irect or (H)old -- your packer might not transfer mail for another zone to that zone's outbound area. That may be because the packer / router acts only on Normal mail (.OUT files). NetMail response messages generated by Raid must contain a ^AINTL "kludge" line when origin and destination zones differ. That is because there are no standard fields in .MSG headers to support zone information. Be careful though. Your packer / router might not recognize the kludge line and so might not route the message to the correct zone as it converts the .MSG to a .?UT. All this contributes to problems with inter-zonal Raid response message routing and delivery. Some folks necessarily want Raid response NetMail to take different paths than EchoMail for security of password data. Simply setting a non-(N)ormal response behavior might not be the solution. Instead, a special routing "schedule" might be required for the packer / router to adjust response message behavior and flow. The Raid exit errorlevels can help with that process. Raid will always exit with errorlevel 1 if NetMail was generated. As a result, something like this might work... Copyright 1989-91 by George Peace - All rights reserved page 62 Raid v1.21 *test* July, 1991 RAID -R IF ERRORLEVEL 2 GOTO FINISH IF ERRORLEVEL 1 GOTO REPACK IF ERRORLEVEL 0 GOTO FINISH REPACK: COMMAND /C MASH REPROCESS_RAID_MAIL FINISH: The "reprocess_raid_mail" schedule might include packer / router directives to change the mail behavior to Normal and to route it directly to its intended destination. Trouble Reports and Support Assistance with use of public releases of Raid will be provided as time and phone bill permit. If you take time to document and report a bug by netmail (1:270/101 717-657-2223) I'll take time to research the trouble and offer a workaround or a fix. I can't promise immediate turnaround or a reply to every NetMail but I can assure you I'll pay attention to your comments and reports. No dedicated message conference exists [other than the beta conference] for Raid support and information exchange. As a result, I hope you'll help me to minimize Raid help desk activities in International conferences where moderators restrict topic or volume of data. Thank you. Testing Raid The Raid Beta Test Team is a generous group of folks who dare to operate unstable development versions of Raid on their systems. My hat is off to each and every one of them. Raid wouldn't be what it is today without their reports and friendly advice <grin>. If you have the qualities we're looking for (daring, BBS fanatic, and a little silly) you too can join the Team. Drop me a note at 1:270/101 (717-657-2223) if you're interested. Or, better yet, search out the RAIDBETA message conference and file echo area in a region near you. There's no application fee and no waiting. Copyright 1989-91 by George Peace - All rights reserved page 63 Raid v1.21 *test* July, 1991 Credits The permission lock/key mechanism idea and some of the code to support it originated in the Opus Utility Programmer's Tool Kit Function Library. Thanks for your support. Copyright 1989-91 by George Peace - All rights reserved page 64