; --------------------------------------------------------------------------
;
; The FLAME Disk, Sample File for ROUTE.CFG
; for FLAME v. 1.1
;
; Copyright 1994, Chris Anderson
;
; --------------------------------------------------------------------------
;
; Command Reference:
;
; DEFINE <constant> <expression>
;
; This is an exceptionally nice way to keep your ROUTE.CFG
; file readable. You can DEFINE whole groups of nodes and
; then reference them by the single name elsewhere in this
; file. Busy hub systems can make particularly good use
; of this feature. For example, if you were to
;
; DEFINE MYHUBEES 1:104/120 1:104/122 1:104/123 1:104/125
;
; then FLAME will recognize the use of the expression MYHUBEES
; in this ROUTE.CFG file as representing the list of nodes
; shown above. For example, SEND HOLD MYHUBEES would cause
; mail for the list of four nodes above to be packed as HOLD
; mail.
;
; FORWARD-TO [FILE] <to-nodes...>
;
; This defines those nodes to whom you are willing to
; forward NetMail messages. If another system leaves a
; message on your system that isn't to your primary or
; AKA addresses (in essence, to "somebody else"), you
; determine here which destinations you are willing to
; forward them to on behalf of another system.
;
; If you specify FILE in the line, you are also agreeing
; to forward attached files to the specified node(s).
; The file is left untouched after sending. Although
; this should be able to be controlled by the FLAME.CFG
; "Keep_Forwarded_Files" statement, it appears that at
; the time of writing, commenting out that line does not
; cause such files to be deleted as one would expect.
;
; Note that other, downstream mail processors may not
; permit the routing of files, so ROUTE of such forwarded
; files may not be successful at the next system. Good
; manners requires that you set up such services with the
; intermediate system in any case.
;
; FORWARD-FROM [FILE] <from-nodes...>
;
; The inverse of the above, this identifies the nodes
; that are allowed to leave mail with your system for
; forwarding elsewhere.
;
; If you specify FILE in the line, you are also agreeing
; to forward attached files received from the specified
; nodes(s).
;
; You may wish to exercise some care in the forwarding of
; files for other nodes where long distance charges could
; make this practice expensive!
;
; FORWARD-ALWAYS [FILE] <from-nodes...>
;
; Here you agree to forward mail received from the listed
; nodes regardless of whether or not the destination systems
; are included in your FORWARD-TO list.
;
; This can be useful if you wish to provide all services to
; only selected nodes. For example, if you want to provide
; forwarding from "anywhere" into Net104, and from Net104 to
; "anywhere", you would use:
;
; FORWARD-TO 1:104/ALL
; FORWARD-FROM 1:ALL/ALL 2:ALL/ALL 3:ALL/ALL 4:ALL/ALL
; 5:ALL/ALL 6:ALL/ALL
; FORWARD-ALWAYS 1:104/ALL
;
; This prevents you from forwarding to everywhere from just
; any node that drops mail on your system, but allows you to
; provide worldwide service for 1:104/ALL. Note that the line
; that appears "split" above should be a single line. Also
; note that ALL is not permitted as a zone number for this
; command.
;
;
;
; SCHED <tag> <day> [<start_time> <end_time>]
;
; If you wish the operation of your ROUTE.CFG file to be
; the same at all times, you should start your file by
; specifying
;
; SCHED sometag ALL (the "times" are optional)
;
; and use no other SCHED commands. Note that at least one
; SCHED command is necessary or FLAME ever won't do anything
; that you have asked it to in your ROUTE.CFG! ROUTE, SEND
; and all of the other commands that follow in this document
; should be placed *inside* of a SCHEDule.
;
; On the other hand, if you wish the ROUTE.CFG to perform
; differently at different times or days, create unique
; "tag" names for each schedule, and specify the days and
; times for each schedule you create. Only the first 32
; characters are used, and each schedule tag must be unique
; from all others. The tag may not contain any spaces.
;
; "Day" may be any of SUN, MON, TUE, WED, THU, FRI, SAT,
; for a day of the week, or WEEK to represent the weekdays
; (Monday thru Friday) or WKEND to represent the weekend
; days (Saturday and Sunday), or ALL for all days of the week.
; Placing the bar character "|" between any of these
; days allows you to create a schedule that is effective on
; more than one day. For example, MON|WED|WKEND would be
; effective on Monday, Wednesday, Saturday and Sunday.
;
; The start and stop times for each schedule are in 24 hour
; format, and if omitted, default to 00:00 24:00.
;
; Exercise care in creating schedules that overlap in some
; fashion. The first SCHED whose date and time (if given)
; contains the current date and time will be used.
;
; SEND [NoArc] <verb> <nodes...>
;
; SEND and ROUTE are the heart of the ROUTE.CFG file. You
; must first understand that any mail that is packed by a
; SEND or ROUTE as "Hold", "Crash" or "Direct" is unavailable
; to be touched again by a subsequent SEND or ROUTE. Note that
; "Normal" mail is an exception to this. If you SEND NORMAL,
; this mail can later be ROUTEd elsewhere if a ROUTE command
; would cover the node in question.
;
; Each line of the FLAME.CFG file is processed *in sequence*.
; As a result, it is often best to place all of your SEND
; statements first in the file, then any ROUTE statements.
;
; For nodes for which you do not wish archives created from
; mail packets, specify "NoArc" as shown above. Mail for
; these nodes will be left in packet form. This is a
; common practice for nodes with which you have no session
; password, as most sysops will not, for security
; reasons, automatically unpack archived mail from systems
; with whom no session password is shared. Don't forget
; that FLAME will use a default archiver (as defined or
; defaulted to in FLAME.CFG) for nodes not listed in your
; "pack" statements in the FLAME.CFG file unless NoArc is
; specified here.
;
; If no SEND or ROUTE commands exist that cover the mail
; for a particular node, mail to that node will NOT be
; archived, regardless of what you may have requested for
; an archiver for that node in a FLAME.CFG "Pack" statement.
; Remember therefore, that FLAME.CFG says *what* to use,
; but ROUTE.CFG says *when and if* to use it.
;
; ROUTE [NoArc] <verb> <hub_node> <nodes...>
;
; ROUTE is used to send mail to some intermediate system rather
; than directly to the final destination. By doing this, you
; are expecting the intermediate system (called "hub_node"
; here) to forward the mail you send it that belongs to
; the nodes you specify. You should not do this unless you
; have arranged with the "hub_node" to do this forwarding
; task for you.
;
; As is described for SEND, you may use NoArc where it is
; appropriate to avoid archiving.
;
; Since SEND and ROUTE are so often misunderstood, an example is
; provided at the end of this file that will help you to understand
; how these two commands interact.
;
; HOSTROUTE [max_bytes]
;
; If you specify HOSTROUTE, all normal flavored NetMail found
; when HOSTROUTE appears in your SCHED that is destined for all
; other systems is routed to the zone:net/0 system matching that
; of the actual destination for your message, expecting that the
; Network Coordinator at zone:net/0 will forward the message to
; its final destination. This is called "host routing". You
; may also specify the maximum size of message that will be
; routed in this fashion.
;
; HOSTROUTE will only route mail that is "normal" flavored.
; Therefore, placing it at the bottom of your file, after
; your SEND and ROUTE commands, can cause it to catch mail
; not already grabbed by one of those commands, and if used,
; this is probably what you will wish to do.
;
; HOSTROUTEEXCLUDE <z:n z:n z:n...>
;
; If you have specified "HOSTROUTE", ALL NetMail *except* that
; for nodes excluded here will go to the zone:net/0 node
; matching that of the destination system. The effect is to
; selectively undo the global effects of HOSTROUTE for certain
; addresses.
;
; GATEROUTE <verb> <zonegate> <nodes...>
;<Z>
; There should rarely be reason to use this command, as what
; needs to be done can be handled easily enough by simple
; ROUTE commands. However, if you do so, mail to zones other
; than your own will be sent to the gateway system for the
; other zone, whose address (if it is an "official zonegate"
; for your network) is often identified as yourzone:1/otherzone.
; These are often found at the beginning of your network
; nodelist.
;
; CHANGE <from_verb> <to_verb> <nodes...>
;
; This permits you to change the flavor of mail packets
; (*.?UT) and file lists (*.?LO) for one or more nodes
; during the schedule. You may also do this from within
; a RESTRICT block in your TIMS.CTL file by using a DOTBBS
; CHANGE statement to perform a similar function.
;
; POLL <verb> <nodes...>
;
; This will generate a "dummy" (empty) message that can be used
; to cause your system to call another system. Of course, this
; will occur each time that the schedule in which it occurs is
; used by FLAME. You may find it more appropriate to use a
; DOTBBS POLL in your TIMS.CTL file within a RESTRICT block.
; This may keep you from having yet more complex schedules,
; relying instead upon the ones in TIMS.
;
; ATTACH <verb> <file1+file2+file3...> <nodes...>
;
; Each time the schedule in which this command occurs is
; used by FLAME, the file(s) indicated will be set up for
; transmission to the node(s) listed. You may find it
; more appropriate to use a DOTBBS SEND in your TIMS.CTL
; file within a RESTRICT block.
;
; GET <verb> <file1+file2+file3...> <nodes...>
;
; Each time the schedule in which this command occurs is
; used by FLAME, the file(s) indicated will be requested
; from the node(s) indicated. A *.REQ file is generated or
; appended to for the target node. You may find it more
; appropriate to use a DOTBBS GET in your TIMS.CTL file
; within a RESTRICT block.
;
; UPDATE <verb> <filespec> <nodes...>
;
; This command operates in the same manner as GET, but
; is designed to receive the requested file only if it
; has a later date/time stamp on it than an existing
; version of the file in your inbound files area.
;
; Note that neither GET nor UPDATE permit a path to be
; included. If you specify a path in addition to the filename,
; it is ignored, and the files are placed into the appropriate
; inbound directory as defined in your TIMS "Files" commmand.
; At the time of writing, the path is *not* included before
; the filename in the *.REQ file that this function generates.
; It is not known if this was the intention of the author.
; However, this requires that the file whose date stamp is to
; be matched exists in your inbound file area.
;
; Note that although TIMS includes a GET function, it does
; not include an "UPDATE" function such as this.
;
; DOS <command> [arguments]
;
; Each time the schedule in which this command occurs is used by
; FLAME, the command and arguments (if any) specified will be
; passed to DOS for execution. This can be used to execute
; batch files or programs.
;
; LEAVE <nodes...>
;
; LEAVE changes the first letter of *.?LO file list files and
; *.?UT packets for the listed nodes such that they are no
; longer recognized as file list files or packets. As a
; result TIMS will not attempt to mail them nor will it allow
; such packets or files to be picked up by a calling system
; when such naming has occurred on its files due to use of LEAVE.
;
; For example, *.HLO files are changed to *.NHO, and *.CLO
; files are changed to *.NCO. As you can see, the flavor
; information is retained in the second letter, and is used
; restore the correct extension during an "UNLEAVE" (below).
;
; UNLEAVE <nodes...>
;
; Reverses the LEAVE process, changing the file extensions back
; to their original form, making them again recognizable to
; TIMS as file lists and packets that can be given to other
; systems when calling them or being called by them.
;
; NETMAIL_SCAN [<directory>]
;
; Normally, FLAME does not scan the "Mail" directory (as defined
; in FLAME.CFG) for outbound NetMail during a SCAN operation.
; Because of this, it won't toss any *.MSG mail that may exist
; there to the TBBS message base, either. To cover such
; situations, it is recommended that you include this statement
; and point it to your "Mail" directory.
;
; Note that this has nothing to do with scanning out new
; messages entered directly into the *TBBS* message base. These
; are scanned normally regardless of how you use this command.
;
; TBBS_IMPORT_FILE <filename> <TBBS message board or topic> [<options>]
;
; This is in some ways similar to the old SEA "TELL" program,
; only with a great deal more functionality. Its primary
; purpose is to use a text file to create a message for
; someone and to add it to your TBBS message base. FLAME will
; then see this new message and if placed in an echo or
; NetMail, FLAME will send it as though it had been entered
; locally by a user. Unless you specify that the file is to
; be used as an enclosed file, it is obvious that the file
; must be a text file that is readable as a TBBS message (see
; "ENCL" option, below).
;
; "filename" may include the full path with the name of the file
;
; The "TBBS message board or topic" parameter is the TBBS
; message board name, or board number, or topic name. If you
; use a topic board, you must include the full topic path,
; beginning with the root. If the topic or board name
; includes spaces, you must place it within quotes or use the
; number instead.
;
; Options
;
; ENCL The file that you specify is not used as the
; body of a message, but rather, a dummy message
; is created and the file is "enclosed" so that
; the reader can download it. Any kind of file
; can be enclosed.
;
; PVT Set the private flag on the message such that
; it can only be read by sender, receiver (and
; the sysop).
;
; FROM= Followed by a name, this inserts this data into
; the "From:" field of the message. The name for
; the "From:" field otherwise defaults to "FLAME".
; If, as is typical, the name contains a space,
; you must enclose it in quotes. From the command
; line (as opposed to within this file), only
; single quotes are allowed.
;
; TO= Followed by a name, this inserts this data into
; the "To:" field of the message. If not provided,
; it defaults to the "Name" found in FLAME.CFG
; (typically yours!) Again, quotes will be needed
; if the name contains a space.
;
; SUBJ= Followed by a subject, this inserts this data
; into the "Subj:" field of the message. If
; not provided, it defaults to "FILE DELIVERY".
; Spaces must be handled with quotes.
;
; NODE= IF you specify the name of the NET MAIL board
; or its board number, you must also specify a
; node number for the message. It will be treated
; as would any manually entered NetMail message.
; If no node number is specified, some random
; sequence of digits will be used for zone, net
; node and point ... not a good situation.
;
; If a NetMail message is created successfully, it
; will show your own primary address as the origin
; of the message - as you would expect if you had
; entered the message manually.
;
;
; The commands SEND, ROUTE, CHANGE, POLL, LEAVE, UNLEAVE, ATTACH, GET,
; UPDATE, HOSTROUTE, NETMAIL_SCAN and TBBS_IMPORT_FILE may all also be
; called directly from the FLAME command line. See FLAME Command Line
; documentation for any further details and restrictions.
;
;
; The following three "Busy" commands are relevant ONLY if you are
; using a "nanny machine" to process your mail separately from your
; BBS machine, and you are using FLAME to do that mail processing.
; They are here to duplicate the functionality of the COPYMAIL utility
; but to do so within FLAME itself. These are used to deal with the
; fact that two machines may both have access to the same outbound
; files area at once when nanny machine processing is employed, and
; these commands be used can prevent attempts at simultaneous access
; by both machines to packet and file list files. Clearly, you don't
; want attempts to modify such files while, for example, they are
; being transmitted to their destination.
;
; Note that the *CREATION* of both *.BSY and *.?$T as a means for FLAME
; to warn TIMS away from fiddling such files can be disabled from the
; command line (see "FLAME NOBUSY"), although invoking this option would
; normally be inappropriate.
;
; BUSY_WAIT [<minutes>]
;
; This command causes FLAME to pause for a maximum of the
; specified number of minutes if a *.BSY flag is discovered
; for nodes whose outbound mail packets or file lists need
; to be created or appended to by FLAME. FLAME must not
; alter files that are part of an active mail session being
; conducted by TIMS.
;
; If no time limit is specified, FLAME will wait continuously
; for any existing busy flags to clear for nodes whose mail
; needs to be moved to the appropriate OUTBOUND area. As each
; node's *.BSY flag clears, its mail is moved, and FLAME looks
; again to see what remains.
;
; If a time is specified, FLAME will keep trying to process
; mail (pack packets or create file list files) until the time
; limit expires, at which time FLAME will give up on the whole
; file moving process and exit.
;
; BUSY_NOWAIT
;
; Advises FLAME not to wait if a *.BSY flag is found for the
; node whose mail is being packed, but instead to simply move
; on to the next node's mail. FLAME will not again attempt
; to process the busy node's mail during this invocation of FLAME.
; Any packets remain in the directory where FLAME was invoked
; for processing at some later time.
;
; BUSY_NO_OUT
;
; If specified, *.OUT files on the nanny machine will be
; ignored and not copied to the outbound area (often on
; the other machine). This does not prevent the moving
; of *.CUT, *.HUT or *.DUT packets.
;
;
; REDRAW
;
; Causes FLAME status screen to be redrawn if you have told
; FLAME to exit to do some DOS function during the pass. See
; 'DOS' command, above.
;
;
; Key:
;
; <tag> ....... Any text, up to 32 characters in length (no spaces).
;
; <verb> ...... Any one of the following verbs:
; NORMAL ....... (creates *.FLO or *.OUT)
; CRASH ........ (creates *.CLO or *.CUT)
; HOLD ......... (creates *.HLO or *.HUT)
; DIRECT ....... (creates *.DLO or *.DUT)
;
; <nodes> ..... Full 'zone:net/node' number. If 'zone' or 'net' are
; ommited, they will default to the previous entry on
; the line, if one exists. If not, your own primary
; or AKA address will be used.
;
; <hub_node> .. Hub node routed mail is sent to.
;
; <day> ....... Any combination of the following, may be joined by
; the '|' symbol (i.e. "Sun|Mon"). Valid options are
;
; All Week WkEnd Sun Mon Tue
; Wed Thu Fri Sat
;
; <minutes> ... The number of minutes to wait for a BuSY flag to
; clear. The number must be between 1 (default)
; and 120.
;
; We promised you an example of SEND and ROUTE to help you to understand
; how these two commands will deal with your outbound mail.
;
; RULES TO REMEMBER:
;
; FLAME will look in the currently valid SCHEDule for all of your
; SEND and ROUTE commands. It checks on the possibility of using
; these, starting from the top of the list, and attempts to use
; each one found in the currently valid SCHEDule until it reaches
; the end of the SCHEDule. As each command is found, the mail
; presently sitting around for each node is checked to see if the
; command can be validly applied to a given node's mail. The rules
; for whether or not a command will be applied to a specific node's
; mail are:
;
; a) Is the node either specifically mentioned, or included due to
; the use of an ALL, somewhere in the list of nodes for that
; command? If not, then the SEND or ROUTE command will not be
; applied to that node's mail.
;
; b) Is the mail for a specific node already packed? If so, no
; SEND command will be able to again touch that mail during this
; SCHEDule.
;
; c) Is the mail for a specific node already packed as Crash, Hold
; or Direct flavor? If so, then no ROUTE command will be able
; to again touch that mail during this SCHEDule unless the
; flavor is first changed to Normal.
;
; d) Is the mail for a specific node already packed as Normal? If
; so, then any ROUTE command whose list of nodes includes the
; node in question will be allowed to route the mail that has
; already been packed for this node.
;
; Let's see how these rules actually play out in a sample using the
; SEND and ROUTE commands. Note that the *sequence* of your commands
; plays a big role in correct preparation of the mail. You will find
; that often you will be wanting to create your SEND's first, and
; then later your ROUTEs.
;
;
; Assume that mail has been created for nodes
; 1:104/1 1:104/2 1:104/3 1:104/4
; 1:128/1 1:128/2 1:128/3
; 1:130/1
; 1:140/1
; 2:255/1 2:255/2 2:255/112
;
; and that the following exist in this order in the current SCHED
; SEND NORMAL 1:104/3
; SEND DIRECT 1:104/ALL
; SEND HOLD 1:130/1
; ROUTE CRASH 2:255/1 2:ALL/ALL
; ROUTE HOLD 1:104/0 ALL:ALL/ALL
;
; Step 1: SEND NORMAL 1:104/3
;
; Creates packet 00680003.OUT using mail for 1:104/3
; No other nodes are covered by the address 1:104/3, so this is
; all that happens here.
;
; Step 2: SEND DIRECT 1:104/ALL
;
; Creates packets 00680001.DUT, 00680002.DUT and 00680004.DUT for
; nodes 104/1, 104/2 and 104/4, respectively. Mail to 104/3 has
; already been packed, and is therefore not touched by the SEND,
; even though it would otherwise be covered by the 1:104/ALL.
; Since this mail is flavored "direct", calls will be placed to
; 104/1, 104/2 and 104/4 if the TIMS.CTL file indicates that it
; is permissable to do so. Note that TIMS treats "direct" flavor
; mail in the same fashion as it does "normal" with regard to
; the SEND verbs in your TIMS.CTL file.
;
; Step 3: SEND HOLD 1:130/1
;
; Creates packet 00820001.HUT from the mail for 1:130/1. No
; other nodes are effected. Since the mail is placed on hold,
; 1:130/1 is being expected to call and pick it up.
;
; Step 4: ROUTE CRASH 2:255/1 2:ALL/ALL
;
; The mail for 2:255/1, 2:255/2 and 2:255/112 are all packed
; together in a packet for 2:255/1 called 00FF0001.CUT. Of
; course, arrangements were made in advance with 2:255/1 to
; forward any mail it receives from us for any zone 2 address.
; Since this mail is flavored "crash", a call will be placed
; to this system if the TIMS.CTL file indicates that it is
; permitted to do so.
;
; Step 5: ROUTE HOLD 1:104/0 ALL:ALL/ALL
;
; The mail that was created for 1:104/3 was created as "Normal"
; flavored mail, and is therefore available to be routed along with
; all other remaining mail to 1:104/0. So why did we use the
; original SEND NORMAL 1:104/3? This was used to prevent this mail
; from being sent DIRECT by the next statement, SEND DIRECT
; 1:104/ALL. We "hid" the mail from any other SEND commands so that
; we could catch it in this ROUTE command later.
;
; FLAME isn't capable of understanding commands in the form of
;
; SEND stuff EXCEPT thisstuff
;
; so you have to create the exceptions yourself. This is what
; we caused by the technique shown.
;
; So, the mail for 1:104/3, and all remaining mail for anyone,
; which includes mail for several 1:128 nodes and for 1:140/1,
; is all sent in one packet to 1:104/0 (00680001.HUT) for forwarding
; by 1:104/0. This mail is placed on hold, however, so 1:104/0
; is being expected to come and pick it up.
;
; The non-"Normal" flavored mail that was already created with a
; SEND is not available to FLAME for ROUTEing in this step. That
; includes all of the 1:104 mail that was sent DIRECT in Step 2,
; and the mail that we placed on HOLD for 1:130/1 in Step 3.