Share Gallery 1

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

/ Share Gallery 1 / share_gal_1.zip / share_gal_1 / CO / CO003A.ZIP / NETMAIL.ARC / NETMAIL.DOC < prev next >

Wrap

Text File | 1988-04-26 | 64.1 KB | 1,713 lines

GT POWER - 14.00 Copyright (c) 1987, 1988: by P & M Software Co. All rights are reserved. GT Netmail System Release 1.00: 9-27-87 1.10: 11-07-87 1.20: 12-14-87 1.30: 1-09-88 1.40: 5-01-88 P & M Software Company 9350 Country Creek #30 Houston, Texas 77036 U.S.A Voice Phone: (713) 778-9471 Modem Phone: (713) 772-2090 1 Table of Contents ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ An Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Netmail vs. Echomail . . . . . . . . . . . . . . . . . . . . . . . 3 The Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 MBAGGER . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 MDIST . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 MDRIVER . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 FILE ATTACH, FILE REQUEST, & DIRECT XPRESS . . . . . . . 10 NODELIST.BBS . . . . . . . . . . . . . . . . . . . . . . 11 Control Files . . . . . . . . . . . . . . . . . . . . . . 11 Message Areas . . . . . . . . . . . . . . . . . . . . . . 11 The Schedule . . . . . . . . . . . . . . . . . . . . . . 12 Command Line Usage . . . . . . . . . . . . . . . . . . . 13 Stale mail . . . . . . . . . . . . . . . . . . . . . . . 13 Additional MDRIVER options . . . . . . . . . . . . . . . 14 ROUTING.BBS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 PURSUIT . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 INBOUND NODES . . . . . . . . . . . . . . . . . . . . . . . . 16 LONG DISTANCE . . . . . . . . . . . . . . . . . . . . . . . . 16 OUTBOUND NODES . . . . . . . . . . . . . . . . . . . . . . . . 17 PREFIXES . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 PICKUP OVERRIDES . . . . . . . . . . . . . . . . . . . . . . . 18 ROUTING INSTRUCTIONS . . . . . . . . . . . . . . . . . . . . . 19 REQUEST ECHOMAIL CONFERENCES . . . . . . . . . . . . . . . . . 21 MESSAGE DISTRIBUTION . . . . . . . . . . . . . . . . . . . . . 22 ECHOMAIL HOURS . . . . . . . . . . . . . . . . . . . . . . . . 22 EXCLUDED NODES . . . . . . . . . . . . . . . . . . . . . . . . 23 HINTS FOR ECHOMAIL . . . . . . . . . . . . . . . . . . . . . . . . 23 Sample Echomail ROUTING.BBS . . . . . . . . . . . . . . . . . 23 2 An Overview ~~~~~~~~~~~ The GT Netmail System is a companion product for GT POWER. It allows GT host mode systems to send messages from one to another over dial-up phone lines, unattended, in the middle of the night. Alternate long distance carriers, such as PC Pursuit, are supported and used whenever possible to control cost. A system of "hub" systems has begun to grow. These "hub" systems collect and concentrate message traffic, enabling fewer phone calls to be made and a greater amount of message traffic to be passed with each call. Central hubs, known as "Continental Hubs", have been established to facilitate the flow of message traffic to/from parts of the country not reachable via PC Pursuit. The "Continental Hubs" act as store and forward sites for their designated sections of the country. The GT Netmail Coordinator must be contacted to gain access to the GT Netmail System. One must apply through the GT Netmail Coordinator (or his designated representative) for a net/node number and related CRC Identification Number. The CRC Identification Number allows the netmail system to tell the good guys from the bad guys. The CRC Identification Number will not only verify you to the other members of the network, but will allow separate non-overlapping networks to be established, each with their own different CRC Identification Numbers, so we will be able to tell the difference between net/node 001/010 in network A and net/node 001/010 in network B. Without the identification number, it would be easy to outsiders to impersonate other members of the network. When you receive your CRC Identification Number, it is to be held in the strictest confidence. +---------------------------------------------------------------------+ | | | To learn the name of the GT Netmail Coordinator (or his | | designated representative, call P & M Software Co. via voice | | line at (713) 778-9471. | | | +---------------------------------------------------------------------+ Netmail vs. Echomail ~~~~~~~~~~~~~~~~~~~~ Echomail conferences are designated differently than Netmail nodes are, but the mechanism is very similar. Netmail nodes are assigned net/node numbers by the GT Netmail Coordinator, 001/002 is the net/node number for Private Sector, a BBS in Houston. On the other hand, Echomail conference numbers are assigned by the Echomail Coordinator and always begin with the letter "E" to distinguish them from Netmail net/node numbers. For example, 001/002 is the sponsoring system for the Sysop Tools Echomail Conference, which is designated E00/033. If one wished to get the Sysop Tools Echomail Conference from 001/002, then a routing instruction would have to be coded to tell the system where to get it (explained below). Netmail is a mechanism which allows communications to be directly addressed to a particular destination system and person, which may be 3 on the other side of the world. As such, Netmail is inherently one-to- one. Echomail, on the other hand, is one-to-many. You may address message to any person, or to all persons, but any system which "subscribes" to an Echomail conference will be able to get your message. In effect, Echomail allows the duplication of conferences across many systems and is called Echomail, because of the action the mail takes upon reaching the "sponsor" system -- it echoes back to all the subscriber systems! The terms "sponsor", "subscribe" and "subscriber" are not used to indicate monetary exchange. Echomail is provided on request (no money is involved), the terms merely describe who is the service provider and who is the service requestor. The service involved is the storage and distribution of a Echomail message database. 4 The Programs ~~~~~~~~~~~~ The GT Netmail System is comprised of three programs (four actually, but the fourth is the CRC calculator and it is for network coordinators only): MBAGGER ....... Mail Bagger Program MDRIVER ....... Mail Driver Program MDIST ......... Mail Distributor Program MBAGGER ~~~~~~~ The MBAGGER program is responsible for taking message traffic from the GT host system and preparing it for transmission over the netmail system. The process is called "bagging". For each destination you have message traffic the MBAGGER program will create a mail bag. A mail bag in this sense is an ARC file that contains all the messages for a particular destination. Mail bags have a rather interesting file naming convention: Netmail Bag Naming Convention. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Position Description ~~~~~~~~ ~~~~~~~~~~~ 1 File Id: "B". 2 File generation number: 0 - current. 1 - 1 cycle old. 2 - 2 cycles old. 3-5 Bag number. Usually "001". 6-8 Destination node number. 9 "." 10-12 Destination net number. Echomail Bag Naming Convention. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Position Description ~~~~~~~~ ~~~~~~~~~~~ 1 File Id: "E". 2-5 Julian date of bag creation. 1-1-87 is day 0. 6-8 Echomail conference number. 9 "." 10-12 Echomail net number. NOTE: even though the mail bags do not have the ARC extension, they ARE ARC files and you will need a copy of PKARC/PKXARC on your system to be able to process mail bags. The operation of MBAGGER is semi-automatic. It goes through the GT host system message bases finding messages that need to be bagged and does its thing. Once a message has been bagged, MBAGGER will mark the message as (MAILED). This does not mean that the message has actually been sent or received, but that it has entered into the GT Netmail System. The MBAGGER uses this mark to keep from bagging the same 5 message over and over again. The MBAGGER program must be run at or before the start of a netmail session, to insure that all outgoing message traffic is properly prepared for transmission. The MBAGGER program examines the ROUTING.BBS file or the designated alternate routing file (designated via command line switch) and uses several bits of information located there to control the bagging of Echomail. First, the necessary ACCEPTs for Echomail must be present and if your system is to act as the "sponsor" for an Echomail conference, the ACCEPT for your conference must NOT have any redirection shown. The system identifies you as the "sponsor" of an Echomail conference by the lack of redirection for your conference. In addition, the MBAGGER program will examine the MESSAGE DISTRIBUTION section of the ROUTING.BBS file. The MESSAGE DISTRIBUTION section must contain entries for each Echomail conference that is present on your system, so MBAGGER will know where to look to get Echomail to bag. If the ACCEPT statements or MESSAGE DISTRIBUTION section of the ROUTING.BBS file are incorrect, then MBAGGER cannot successfully do its job. Here are some sample ACCEPT statements: ACCEPT E00/033-033 -> 001/002 This statement would indicate to MBAGGER that you were routing Echomail for E00/033 (Sysop Tools) through node 001/002 (Private Sector). If you were the "sponsor" of an Echomail conference, say E00/020, then your ROUTING.BBS file would contain the following ACCEPT for your conference: ACCEPT E00/020 $xxxx This shows your system to be the "sponsor" of Echomail conference E00/020. And the $xxxx is the Echomail CRC number assigned by the Echomail Coordinator. The MBAGGER program uses the MESSAGE DISTRIBUTION section of the ROUTING.BBS file to find the message areas which contain Echomail. So each Echomail conference must have a valid entry in the MESSAGE DISTRIBUTION section. As follows: MESSAGE DISTRIBUTION E00/004-004 -> C:\FOOBAR1 E00/009-009 -> C:\FOOBAR2 END The idea here is to relate each Echomail conference that you want to have on your system listed with a corresponding message area in your GT Host system. The names FOOBAR1 and FOOBAR2 you will replace with the actual directory names you use on your system. The Echomail message areas in the GT Host system are setup as normal message areas, without 6 any private mail (use the ^ in the GTMDIR.BBS file). The MBAGGER program supports several command line options, as follows: /N ...... This option enables MBAGGER to be run more than once per day. On the first run of MBAGGER, this option is not used, but all subsequent runs on that day MUST use the /N command line switch. /N stands for NEXT RUN. /Dn ..... This option specifies the number of days you wish to retain old bags of Echomail. These bags must be retained for awhile so that they are available for newcomers and for people who miss a day or two of the conference. The system defaults to 14 days, I would not advise a shorter period, but this mechanism can be used to lengthen the period. I use /D31 on my system at 001/003, but I have no crunch on disk space at the moment. /R ...... This option is used to specify an alternative routing file. If not specified, the program will process the standard ROUTING.BBS, but with this option, any routing file may be named for input. For example: /R:foo.bar In this case, the routing instructions would be read from the file 'foo.bar'. MDIST ~~~~~ The MDIST program runs at the conclusion of a netmail session, taking the message traffic received from other systems and distributes it to the GT host message base. This process involves unARCing all the mail bags received and taking the resulting messages and entering them into the GT host message base system, thus allowing the BBS users to read and respond to the messages. The operation of this program is semi-automatic. The program uses the ROUTING.BBS file, or designated alternate, to determine the MESSAGE DISTRIBUTION and the ROUTING INSTRUCTIONS to determine which Echomail conferences you might be sponsoring. The requirement for the ROUTING INSTRUCTIONS is very important to MDIST, since to perform properly MDIST must be able to distinguish Echomail "sponsors" from "subscribers". This is done by examining the ACCEPT statments. For example a Echomail "sponsor" will show no redirection for his conference: ACCEPT E00/001 $xxxx This would identify your system as the "sponsor" for the Echomail conference E00/001 (which of course is sponsored by 001/003, so do not do this unless you are an Echomail "sponsor"). The $xxxx is the Echomail CRC number assigned by the Echomail Coordinator. 7 A Echomail "subscriber" would also code an ACCEPT statement, it would list the node from which he obtains the conference. For example, if you subscribed to E00/003-003, you would code the following ROUTING INSTRUCTION: ACCEPT E00/003-003 -> 001/003 Of course, the 001/003 is variable and will be replaced with the actual source of the conference for you. You may receive an Echomail conference from the sponsor of the conference or from anyone who already subscribes to the conference. Of course, the MESSAGE DISTRIBUTION section is extremely important to the MDIST program. It informs MDIST where to place messages you have received. Here is the format: MESSAGE DISTRIBUTION E00/001-001 -> C:\GT_ECHO E00/002-002 -> C:\RELIGION END This example only shows two lines, but the pattern should be clear. You must indicate which Echomail conferences get routed to which message bases on your system. NOTE: the Echomail message bases must NOT be netmail areas, they are setup as regular message bases. You may also route regular netmail message traffic from specific net/node addresses via this mechanism. If regular netmail traffic is routed this way, then of course the message areas involved would be setup as normal netmail areas. The MDIST program supports 1 command line argument, the /R switch. This allows the user to specify the use of an alternate routing file instead of the standard ROUTING.BBS file. For example: MDIST /r:hay.stk In this example, MDIST would read the required routing instructions from the file 'hay.stk', instead of the ROUTING.BBS file. MDRIVER ~~~~~~~ The MDRIVER program is the heart and soul of the GT Netmail System. It receives and transmits mail bags. It routes the message traffic, as instructed by the user, through the various "hub" systems to the final destination. The operation of this program can be rather complex, if user lets it be. Remember when setting up this program: "KISS: Keep It Simple Stupid". The system automatically creates a system of sub-directories on the default drive, as follows: \MAILWORK ........... Usually empty. Temporary work area. \MAILOUT ............ Outgoing mail bags. 8 \MAILOUT\FILEOUT .... Outgoing files for use with "File Attach" and "File Request". \MAILOUT\DEADLTR .... Stale mail. Put here when can't deliver. \MAILIN ............. Incoming mail bags. \MAILIN\FILEIN ...... Incoming files sent via "File Attach" or as a result of a "File Request". When you create a netmail message, it can include a "File Attach", "File Request" or "Direct Xpress" command within it. The "File Attach" command will cause the indicated file to be "bagged" with the message and delivered with the message to the indicated destination. The "File Request" command will cause a request for the indicated file to be sent with the message to the destination system. If the requested file is available, it will be returned to the reqesting system. The "Direct Xpress" command will cause the message to be routed direct from your system to the addressee's system, avoiding all intermediate hub systems. +--------------------------------------------------------------------+ | | | Please note that the FILE REQUEST and FILE ATTACH | | mechanism should be used with extreme care. Abuse | | of these functions will cause degradation of the net- | | mail system. Large files should not be attached or | | requested unless absolutely necessary. | | | +--------------------------------------------------------------------+ 9 FILE ATTACH, FILE REQUEST, & DIRECT XPRESS ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ To be "attached" to a message, the file must be placed into the \MAILOUT\FILEOUT sub-directory. The user then places a "dot command" into the message referencing this file. A "dot command" is a command beginning in the first column of a line with a ".". Here is an example of a "File Attach" command: .FA foo.bar This would cause the file "foo.bar" to be attached to the message containing the ".FA" command. To be "requested" by a message, the file requested must be available on the destination system in the \MAILOUT\FILEOUT sub-directory. The user then places a "dot command" into the message referencing the desired file. Here is an example of a "File Request" command: .FR nodelist.arc This would cause the file "nodelist.arc" to be requested from the destination system when the message containing the ".FR" command is delivered. Here is an example of a "Direct Xpress" command. .DX This would cause the message which contains the .DX to be routed directly to the addressee's system, without any store and forward operation. The .FR, .FA and .DX commands are not processed in an Echomail transaction. They are only applicable to regular Netmail. 10 NODELIST.BBS ~~~~~~~~~~~~ The NODELIST.BBS file is maintained by the GT Netmail Coordinator. Each system on the netmail system must have a copy of the NODELIST.BBS to be able to deliver message traffic over the network. Usually, the GT Netmail Coordinator has the nodelist available for "File Request" as the file NODE????.ARC. The format of the nodelist is simple, an example entry would be: 001/001 713-772-2090 96 Houston "Programmer's Workshop" "Paul Meiners" The first column of each line in the nodelist begins with the net/node address of the indicated system, in this case net = 001 and node = 001. That is followed by the phone number, the maximum baud rate (without trailing zeros), the city, the name of the system, and the name of the operator. One need not modify this information, it is maintained by the GT Netmail Coordinator. If any information in the nodelist needs to be changed, please notify the coordinator. Control Files ~~~~~~~~~~~~~ Various control files are built by the GT Netmail System in the mail directories. These control files are 0 byte files and all filenames begin with the letter "C" and/or "F". Do not disturb these files, as they are 0 byte files, they occupy very little space on your disk. Message Areas ~~~~~~~~~~~~~ At least one message area must be designated to participate in the netmail system. This message base is indicated in the GTMDIR.BBS file by placing a ~ before the pathname. For example: E ~C:\GTBBS\GENERAL The Netmail Message Area. When MBAGGER runs he will search for outgoing messages only in areas marked with the ~ character. When MDIST runs, the incoming message traffic will be entered into the first netmail message area found in the GTMDIR.BBS file or if an entry is found in the MESSAGE DISTRIBUTION section, netmail from specified addresses can be split into different message areas. If you decide to run Echomail, you must set aside a message area for each Echomail conference you wish to participate in. They should be normal message areas, DO NOT designate them with the ~ as shown above. It is recommended that Echomail areas are totally public areas, since Echomail will ignore any private message left in an Echomail area. You may use the ^ character in front of the pathname to prohibit private messages, as follows: E ^C:\GTBBS\SYS_ECHO The SYSOP Echomail Conference. 11 The Schedule ~~~~~~~~~~~~ The SCHEDULE.BBS file has several important entries for the proper operation of the netmail programs. As follows: NET=xxx Net number. Assigned by coordinator. NODE=xxx Node number. Assigned by coordinator. AREA=xxx Local areacode. Assigned by phone company. CITY=cityname This city name. Assigned by city council. OFFICE=99:99-99:99 Specifies when a caller can use the P)age function. For example: OFFICE=08:00-17:00 The time is specified using 24 hour notation and leading zeros are significant. NAME=bbsname This BBS name. Assigned by sysop. This name is used to identify the system on the .ORIGIN line by MBAGGER (be creative with it). These should be the first entries in the SCHEDULE.BBS file. The AREA entry can contain multiple local areacodes, if there are more than one areacode that is local in an area. For example: AREA=212,718 or AREA=713 The 1st example indicates that areacode 212 and 718 are local areacodes and that 212 is the primary areacode. There can be several areacodes listed after the primary areacode. The 2nd example shows a simple 1 areacode situation. Following the netmail entries in the SCHEDULE.BBS file will come the actual schedule entries. Only one entry is required to run netmail, the one that starts the NETMAIL.BAT runstream. For example: 04:00-05:00 netmail Please note that the midnight hour is 24:00 - 24:59, the hour roles to 01:00 at 1 a.m. This would start the NETMAIL.BAT runstream at 4 a.m. local time. The actual time to be used is set by the coordinator. A range of times is indicated to start netmail, so that in case the system were to miss the exact start time, then netmail would still start late, but it would start. If your system does not have enough memory to run netmail and GT in memory at the same time, due to DDOS or other multi-tasking software, you can "QUIT n" from the scheduler and exit GT entirely. Then in the runstream controlling GT there should appear a command as follows: IF ERRORLEVEL n NETMAIL The QUIT command will set the requested ERRORLEVEL upon exit from GT. For example if one "QUIT 4" then the statement would be: IF ERRORLEVEL 4 NETMAIL Having quit GT, the NETMAIL.BAT file must be sure to restart the GT 12 host system after the netmail session is complete. NOTE: there are sample batch file runstreams to look at in the ARC file that this documentation came from. Please examine HOST.BAT, AUTOEXEC.BAT, and NETMAIL.BAT. Command Line Usage ~~~~~~~~~~~~~~~~~~ There are several command line parameters for the MDRIVER program. They are as follows: The netmail CRC Identification number. The session start time. The session end time. The latest start time for the session. These are the basic parameters and must be specified and must be specified in the order listed. For example: MDRIVER XXXX-YYYY 4 5 0455 The above example would run the Netmail from 4 am to 5 am. And the latest start time would be 4:55 am. MDRIVER AAAA-BBBB 4:30 5:25 5:20 The above example would run the Netmail from 4:30 am to 5:25 am. And the latest start time would be 5:20 am. In the above examples, the XXXX-YYYY and AAAA-BBBB are the CRC Identification Number pairs obtained from the GT Netmail Coordinator. Without these numbers the programs cannot communicate with other programs on the network. Call P & M Software Co. via voice line at (713) 778-7481, to find out who to contact to get a CRC Identification Number pair for your node. In addition to the CRC Identification Number, the start/stop times, and the latest start time, a 5th parameter can be added to the command line. It is the number of days a message can age before being considered "stale mail". It goes on the command line following the scheduled times. And is in the format "/Dn", where the "n" is a number of days. For example: MDRIVER 32ED-5E2C 0400 0500 0455 /D10 This would indicate that any bag over 10 days old was to be marked as stale. The bag's name will be changed to begin with the "X" character instead of the "B" character, later the MDIST program will dispose of the bag. The MDIST program will process the "X" bags created as a result of MDRIVER finding stale mail bags. These stale mail bags will be examined by MDIST to determine the system of origin. If they originate on the local system, they will be moved to the \MAILOUT\DEADLTR directory and a message to the local sysop will be placed in the first netmail message area listed in GTMDIR.BBS, informing the local sysop of 13 this fact. If MDIST determines that the stale mail bag originates on another node, then it will move the bag to the \MAILOUT\FILEOUT directory and .FA (file attach) it to a message going to the remote destination informing the remote sysop that his mail was undeliverable and hereby returned to him. The MBAGGER program will delete "X0" files from the \MAILOUT\FILEOUT directory, after they have been attached. +---------------------------------------------------------------------+ | | | WARNING: this could be dangerous to the heath of your files. | | DO NOT PUT ANY FILE BEGINNING WITH THE LETTERS X0 INTO THE | | FILEOUT DIRECTORY. | | | +---------------------------------------------------------------------+ Additional MDRIVER options ~~~~~~~~~~~~~~~~~~~~~~~~~~ /R Allows for the use of alternate routing files, instead of the standard ROUTING.BBS file. /R:some.rte The MDRIVER will get routing instructions from the file 'some.rte', instead of ROUTING.BBS. /H Allows for the specification of a custom "Human Notice". Instead of the default notice, you can customize the notice you system uses to notify human callers of the netmail processing in progress. For example: /H:foo.bar The file 'foo.bar' will be displayed to human callers. /Q Instructs the MDRIVER program to quit as soon as all outbound calls have been completed. /E Allows the user to specify the maximum number of errors to allow during a netmail transfer before aborting the session. Very useful to keep from wasting time on a bad connection. Values below 3 are not recommended. For example: /E3 This would allow 3 errors to occur before the session would terminate. ROUTING.BBS ~~~~~~~~~~~ The ROUTING.BBS file is the heart of the control files for the GT Netmail System. It contains the instructions necessary for the MDRIVER 14 program to deliver the mail. There are 11 sections in the ROUTING.BBS file, as follows: PURSUIT PC Pursuit instructions. INBOUND NODES Node list not to be called. LONG DISTANCE Node list defined to be Long Distance. OUTBOUND NODES Node list to be called. PREFIXES Phone No. prefixes to used with MDRIVER. ROUTING INSTRUCTIONS Forwarding instructions. PICKUP OVERRIDES Tell MDRIVER to pickup Long Distance mail. REQUEST ECHO CONFERENCES Tell MDRIVER to pickup Echomail conferences. MESSAGE DISTRIBUTION Tell all programs where messages are to be stored/retrieved. ECHOMAIL HOURS Tell MDRIVER what the hours are for making Echomail requests. EXCLUDED NODES Tell MDRIVER to deny access to listed nodes. None of these sections is required. That is, all of these things have defaults. They need be specified only if the defaults must be overriden. For example, the default is not to use PC Pursuit, if PC Pursuit should be used, then include the PURSUIT section. Here is an explanation of each section: PURSUIT ~~~~~~~ The PURSUIT section of the ROUTING.BBS file has a rigid format. One simply fills in the blanks. Here is the outline to follow: PURSUIT ACCESS= The local Telenet access number. USERID= Your PC Pursuit user id code. PASSWORD= Your PC Pursuit password. CITIES The PC Pursuit cities, listed 1 per line. 201,NJNEW-Newark 216,OHCLV-Cleveland 202,DCWAS-Washington In order to be effective the 305,FLMIA-Miami names must be spelled as in the 206,WASEA-Seattle nodelist. The codes following . the areacode must be as needed . by PC Pursuit, i.e. the case . *IS* significant! END There are thirty-three odd PC Pursuit cities, they should all be 15 included in this table. See the sample ROUTING.BBS file for a complete list. INBOUND NODES ~~~~~~~~~~~~~ The INBOUND NODES listing is included in the ROUTING.BBS file so that one can prevent MDRIVER from placing calls to particular destinations. Usually this is a cost control measure. If one has mail for a destination listed in this section, then that system must call to pick up the mail addressed to it. The format of the section is: INBOUND NODES 001/000-999 002/010-020 END This example would inbound all of net 001. The range of nodes after the net number being 000 through 999. The line for net 002 would inbound nodes 010 through 020 in that net. A range of nodes can be listed on each line, but only 1 net can be listed per line. Up to 200 lines can be present in the INBOUND NODES list. Please note that it is only necessary to INBOUND nodes that you physically place calls to. For example, if you are routing mail for several destinations thru a hub system and you wish to INBOUND all of this traffic, you would need to INBOUND only the hub system, not the individual destinations, since you never call them anyway (so why INBOUND them??). LONG DISTANCE ~~~~~~~~~~~~~ The LONG DISTANCE area of the ROUTING.BBS file is used to override the default rules that the MDRIVER program uses to determine if a number is a local call or long distance. The cost of a message is based in GT upon the net number, i.e. if the destination net is the same a the local net then the call is considered to be free, if the local net is different from the destination net, the call is considered chargeable. The LONG DISTANCE section only controls the construction of the modem dialing string, not the the charge made for the message. Normally any number which has an areacode matching a local areacode from the AREA= list in the SCHEDULE.BBS file is dialed as a local number. Any number which has a different areacode is dialed as a long distance number. Now, it is entirely possible, that these rules are not adequate to govern all circumstances. For example, some long distance calls, within a given areacode, are dialed as 1 + the 7 digit phone number. To allow MDRIVER to construct a dialing string with 1 + 7 digit phone number, the user must list this node in the LONG DISTANCE section. The syntax for this section is the same as the INBOUND NODES list above. For example: LONG DISTANCE 001/002-005 002/020-022 END 16 Up to 100 entries can be placed into the LONG DISTANCE section, each of which can be a range of nodes within 1 net area. Sample dialing strings: ATDT772-2090| Local call. ATDT1,713-772-2090| Regular long distance call. ATDT1,772-2090| LONG DISTANCE: 1 + 7 digit number. OUTBOUND NODES ~~~~~~~~~~~~~~ The OUTBOUND NODES list of the ROUTING.BBS file is a list of nodes that the user wishes MDRIVER to call to pickup mail, even if there is no mail waiting to be sent to these nodes. It is a very handy way to force MDRIVER to call central hub locations to pickup your mail. The syntax is the same as for LONG DISTANCE above, except that a range may not be specified. For example: OUTBOUND NODES 001/000 005/000 [2,5] 006/000 END This list would cause MDRIVER to call each fo the listed nodes and pickup any mail awaiting delivery to your node. On the 3rd example, where 005/000 is listed, you will notice the "[2,5]" listed on the line after the node number. This is a day schedule for the OUTBOUND to become active. The numbers are days of the week, for example 1=Sunday, 2=Monday, etc. This command indicates that the OUTBOUND for 005/000 is done on Monday and Thursday only. If a OUTBOUND is scheduled for a day of the week, it may be INBOUNDed -- that is, the schedule will override the INBOUND. This will allow you to accumulate mail for a destination, then force the call to be made on a specific day of the week. Here is an example: OUTBOUND NODES 001/000 [1] 005/000 [3] 006/000 [2] END INBOUND NODES 001/000 005/000 006/000 END This coding will cause mail to be accumulated for the 3 nodes: 001/000, 005/000 and 006/000, since they are all INBOUNDed. On Monday, 001/000 will be called to deliver and pickup mail. On Tuesday, 006/000 will be called to deliver and pickup mail. On Wednesday, 005/000 will be called to deliver and pickup mail. You will not need to change a thing, the INBOUNDs will be automatically overridden when the scheduled day arrives. 17 There can be 100 entries in the OUTBOUND NODES list. PREFIXES ~~~~~~~~ The PREFIXES allow the MDRIVER user to specify prefixes and postfixes for use both with local and long distance calls. This enables the use of alternate long distance carriers and supports PBX usage. The syntax is simple: PREFIXES LOCAL(xx,xx) DISTANT(xx,xx) Within the (...) the first two characters are the prefix characters the two characters after the comma are the postfixes. Two prefixes and postfixes may be given for local and long distance. The possible prefix/postfix characters are the -/+/*/! characters, the same used in GT. MDRIVER will get the prefixes from the GT.CNF file. An actual example might be: PREFIXES LOCAL(-) DISTANT(*,+!) Where: - ..... 9, * ..... 9,1 + ..... W ! ..... PASS NOTE: if a prefix for long distance is specified, then GT will not automatically insert the "1," in the dialing string, the user must put that into his prefix. PICKUP OVERRIDES ~~~~~~~~~~~~~~~~ Normally when MDRIVER places a out-of-net call to deliver mail, using non PC Pursuit means, mail will be delivered but no pickup of mail will be done. The PICKUP OVERRIDES listing provides a way to defeat this procedure and force MDRIVER to pickup your mail on out-of-net calles to specific destinations. The syntax for the list is exactly like the LONG DISTANCE list shown above. For example: PICKUP OVERRIDES 002/001-001 005/000-001 END If you were in net 001 and had these lines in your PICKUP OVERRIDES you would force MDRIVER to pickup your mail whenever delivering mail the Net/Node 002/001, 005/000, 005/001. Listing a node in the PICKUP OVERRIDES list DOES NOT force a call to be placed, a message must be entered or the node must be in the OUTBOUND NODES list for a call to be placed. But once in contact with the listed nodes, any mail present on the listed nodes for you will be collected. There can be 200 entries in the PICKUP OVERRIDES list. 18 ROUTING INSTRUCTIONS ~~~~~~~~~~~~~~~~~~~~ Probably the simplest, yet the most complex of all the options in the ROUTING.BBS file. An example first: ROUTING INSTRUCTIONS FORWARD 001/001-999 -> 001/010,001/000 ACCEPT 002/001-999 -> 002/000 ACCEPT 002/000 ACCEPT 001/000 END The FORWARD command specifies that any message addressed to nodes in the range 1-999 of net 001 will be forwarded to Net/Node 001/010, with 001/000 as an alternate destination. +--------------------------------------------------------------------+ | | | Nodes 001/010, 001/000 and 002/000 must have complimentary | | ACCEPTs in their ROUTING.BBS files, or the forward will not be | | done. | | | +--------------------------------------------------------------------+ NOTE: Please do not attempt to forward mail unless you are sure that the intermediate node is setup to accept mail for forwarding to the final destination. The ACCEPT acts as permission to accept mail to be passed thru and may also indicate further forwarding that may be necessary. The first ACCEPT command (previous page) specifies that mail will be accepted for the nodes in the range 1-999 for net 002 and will be forwarded to Net/Node 002/000. The final two ACCEPT commands (previous page) indicate that mail will be accepted for Net/Node 002/000 and 001/000. Mail will be sent directly to these nodes without intermediate steps. Most users of the netmail system need not worry about these FORWARD and ACCEPT commands. They need only specify that message traffic be sent through their local hub. For example, I have in my ROUTING INSTRUCTIONS the following: FORWARD 001/002-002 -> 001/000 FORWARD 001/004-999 -> 001/000 FORWARD 002/000-999 -> 001/000 FORWARD 003/000-999 -> 001/000 . . etc In effect, I have routed all my message traffic through my local hub, 001/000. Simple. Since I do not run a hub system, I have no ACCEPT statements at all. One interesting thing to notice, you should not 19 FORWARD mail for yourself to someone else. My net/node number is 001/001, so you can see above that I have not redirected traffic for 001/001 to the hub system. Also, it is important not to include any address on both sides of the redirection symbol, "->". For example: FORWARD 001/000-999 -> 001/000 Would be WRONG, WRONG, WRONG! The right way would be: FORWARD 001/001-999 -> 001/000 Which would insure that 001/000 was not listed on the left side of the redirection symbol. For operators of hub systems: the ACCEPT works like a FORWARD and you need *not* have ACCEPT and FORWARD statements for the same addresses. Either ACCEPT or FORWARD will do the job. The ACCEPT is used on hub systems since they are expected to accept message traffic for delivery to others. The ACCEPT grants permission to do this, if MDRIVER does not have permission to accept message traffic for a requested destination, then the traffic will be denied and messages will not flow. It is important to note that the ACCEPT does not always require the redirection symbol. In other words, if you ACCEPT message traffic for direct delivery to the final destination without further forwarding through 3rd parties, the ACCEPT should be coded without the redirection symbol. For example: ACCEPT 001/000 This command would allow the hub to accept message traffic for delivery to 001/000. The traffic would not be re-routed to an intermediate, but would be directly delivered to 001/000. It is possible to specify ranges for the net numbers, in addition to the ranges for node numbers, shown above. Here is an example: ACCEPT 001-005/000-999 -> 001/010 With this single routing instruction, all mail for nets 001 thru 005 is routed thru the hub at 001/010. Please note that net ranges can only be used with routing instructions for netmail. There is an additional function for ACCEPT statments. They play a critical role in the processing and routing of Echomail. On the sponsor system for an Echomail conference, there must appear an ACCEPT statement for the sponsored conference without any redirection indicated: ACCEPT E00/002 $xxxx Would indicate that the system was the sponsoring system for the E00/002 Echomail conference. And that the $xxxx is the Echomail CRC number assigned by the Echomail Coordinator. 20 On the system of subscribers to an Echomail conference, there must appear ACCEPT statments for each Echomail conference subscribed to: ACCEPT E00/004-004 -> 001/003 ACCEPT E00/033-033 -> 001/002 These ACCEPTs must show redirection (to distinguish between sponsor and subscriber). The redirection should point to the system where it is intended to pickup the Echomail conference. NOTE: you can pickup an Echomail conference from virtually any system that carries the conference you are interested in. If you are already picking up a conference, be careful when changing your pickup point -- make sure that the person you get it from is not calling you to get the conference (if he does then you will have a closed loop which doesn't include the sponsoring system, hence you will get nothing). Alternate destinations may be listed on either ACCEPT or FORWARD statements. The listing of an alternate destination allows the MDRIVER program to let some other node pickup the mail. This is useful if the primary node is out-of-service for some reason. Then if the alternate calls, the system will pass the mail along to him. Note that the alternate destination is *not* automatically called. So if you want to insure that the mail is passed, it would be appropriate to list the alternate destination in the OUTBOUND NODES section. Alternate destinations are listed on the ACCEPT/FORWARD statements following the primary destination separated by commas, for example: ACCEPT 001/001-999 -> 001/000,001/003,001/008 In the above example, 001/000 is the primary destination, 001/003 and 001/008 are alternate destinations. This routing would allow the mail for net 001 to move to any of three destinations, whichever calls first will get the mail. REQUEST ECHOMAIL CONFERENCES ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This section should be filled out when you decide to carry Echomail conferences sponsored by another node. Listing the conference ID in this section alerts MDRIVER to pickup the conference whenever in comes in contact with the node designated in the ACCEPT for the conference. For example: REQUEST ECHOMAIL CONFERENCES E00/001 E00/006 END Would cause MDRIVER to pickup echo conferences E00/001 and E00/006. The MDRIVER program would call the listed destinations for these conferences, as shown in the routing instructions. For example, if the routing instructions were: ROUTING INSTRUCTIONS 21 ACCEPT E00/001 -> 006/001 ACCEPT E00/006 -> 001/003 END Then calls to pickup echomail would be placed to nodes 006/001 and 001/003. If you wished to suppress those calls, you should INBOUND the destination nodes, 006/001 and 001/003 (in which case, the MDRIVER program would pickup the conference when 006/001 and 001/003 called you). Unfortunately, most of the time, you will have to make the call to pickup, you will not be lucky enough to be able to wait for a call, if you want a timely conference input. In many respects, the REQUEST ECHOMAIL CONFERENCES section acts like the OUTBOUND NODES section. For instance, the REQUEST Echomail CONFERENCES can be scheduled for a particular day of the week, just like the OUTBOUND NODES. One may consider the REQUEST Echomail CONFERENCES to be an extension of the OUTBOUND NODES section that is dealing with echomail conferences, instead of node addresses. MESSAGE DISTRIBUTION ~~~~~~~~~~~~~~~~~~~~ The MESSAGE DISTRIBUTION section is used to tell the netmail programs where you wish to have message stored/retrieved. It is primarily of interest to folks who use Echomail, but can be used by anyone who wishes to have multiple netmail areas. Here is an example: MESSAGE DISTRIBUTION E00/000-000 -> C:\GTPOWER E00/001-001 -> C:\RELIGION 007/000-999 -> C:\PACNW END The entry in the MESSAGE DISTRIBUTION equates Echomail or netmail addresses to physical pathnames on your disk system. Notice how net 007 is redirected to C:\PACNW, all other network addresses will be directed to the primary (first) netmail area encountered in the GTMDIR.BBS file. Echomail conferences MUST be listed in this section, otherwise the MDIST program will not know where to store them, and the MBAGGER program will not know where to pickup the latest message traffic for delivery to the Echomail sponsor. ECHOMAIL HOURS ~~~~~~~~~~~~~~ The purpose of the ECHOMAIL HOURS section is to limit the placement of outgoing Echomail calls, i.e. so that they do not interfere with the processing of normal netmail. If there was no way to govern Echomail, it would soon leave no time for regular netmail to be processed. This section is simply one line, as follows: ECHOMAIL HOURS 0400-0500 The times are listed with a dash between. It is permissible for netmail to occur during the Echomail hours, but the reverse is not 22 authorized. EXCLUDED NODES ~~~~~~~~~~~~~~ The EXCLUDED NODES section may be used to keep designated nodes (of your choice) from calling your system. This is another SYSOP tool to guard his system against unauthorized usage. The banned nodes are put in a simple list, one node per line, as follows: EXCLUDED NODES 001/534 002/467 END It is not good practice to exclude a node from your netmail system without reason. Normally, one would have no need for this section at all. But certain circumstances, for example a person who has abused your system, may require complete banning. This section will give you the flexibility to completely lock out anyone of your choice. NOTE: Do not use this section lightly or in jest. This is very serious and potentially damaging to the network. HINTS FOR ECHOMAIL ~~~~~~~~~~~~~~~~~~ When setting up Echomail, the user will notice that it will be necessary to have two or more ROUTING.BBS files. One to use for each scheduled Echomail event and another to use with the Netmail hour. These ROUTING.BBS files should be nearly identical in every aspect, except for two areas: INBOUND NODES and ECHOMAIL HOURS. The INBOUND NODES should be used to control which calls you do not want to be placed during certain sessions. For example, your normal netmail destinations should be INBOUNDed during an Echomail session (if needed) so that you do not place netmail calls to systems which might be running BBS software instead of the netmail software at that hour. The ECHOMAIL HOURS section should contain the appropriate hours for each session of Echomail, and should not overlap the time reserved for netmail. For example, if the netmail time period is 0400-0500 then during that time period, the ECHOMAIL HOURS should be something else, for instance 0300-0400. If in addition, 0300-0400 was reserved for Echomail on your system, then the ROUTING.BBS file in use at that time should contain the following statement: ECHOMAIL HOURS 0300-0400 Sample Echomail ROUTING.BBS ~~~~~~~~~~~~~~~~~~~~~~~~~~~ PURSUIT ACCESS=227-1018 USERID=YUYP2422 PASSWORD=6324RWBG 23 CITIES 201,NJNEW-Newark 216,OHCLV-Cleveland 202,DCWAS-Washington 305,FLMIA-Miami 206,WASEA-Seattle 408,CASJO-San_Jose 212,NYNYO-New_York 718,NYNYO+New_York 414,WIMIL-Milwaukee 213,CALAN-Los_Angeles 503,ORPOR-Portland 214,TXDAL-Dallas 602,AZPHO-Phoenix 215,PAPHI-Philadelphia 612,MNMIN-Minneapolis 303,CODEN-Denver 801,UTSLC-Salt_Lake 312,ILCHI-Chicago 813,FLTAM-Tampa 313,MIDET-Detroit 818,CAGLE-Glendale 404,GAATL-Atlanta 415,CASFA-San_Fransisco 713,TXHOU-Houston 617,MABOS-Boston END REQUEST ECHOMAIL CONFERENCES E00/002 E00/003 E00/004 E00/005 E00/006 E00/007 E00/008 E00/009 E00/010 END INBOUND NODES 001/001 001/002 001/008 002/000 005/000 006/000 006/001 008/000 010/000 016/000 024/000 026/000 END ROUTING INSTRUCTIONS ACCEPT 001/000-001 ACCEPT 001/002-002 -> 001/000 24 ACCEPT 001/004-007 -> 001/000 ACCEPT 001/008-008 ACCEPT 001/009-009 -> 001/000 ACCEPT 001/010-010 ACCEPT 001/011-999 -> 001/000 ACCEPT 002/000-000 -> 001/008 ACCEPT 002/001-999 -> 001/008,002/000 ACCEPT 003/000-000 -> 001/008 ACCEPT 003/001-999 -> 001/008,003/000 ACCEPT 004-005/000-999 -> 001/010 ACCEPT 006/000-000 -> 008/000,008/001 ACCEPT 006/001-999 -> 008/000,008/001,006/000 ACCEPT 007/000-000 -> 001/010 ACCEPT 007/001-999 -> 001/010,007/000 ACCEPT 008/000-000 ACCEPT 008/001-001 -> 008/000 ACCEPT 008/002-999 -> 008/000,008/001 ACCEPT 009/000-000 -> 001/010 ACCEPT 009/001-999 -> 001/010,009/000 ACCEPT 010/000-000 -> 008/000,008/001 ACCEPT 010/001-999 -> 008/000,008/001,010/000 ACCEPT 011/000-000 -> 008/000,008/001 ACCEPT 011/001-999 -> 008/000,008/001,011/000 ACCEPT 012/000-999 -> 008/000,008/001 ACCEPT 013/000-000 -> 001/008 ACCEPT 013/001-999 -> 001/008,013/000 ACCEPT 014/000-000 -> 001/010,007/000 ACCEPT 014/001-999 -> 001/010,007/000,014/000 ACCEPT 015/000-000 -> 001/008,002/000 ACCEPT 015/001-999 -> 001/008,002/000,015/000 ACCEPT 016/000-000 ACCEPT 016/001-999 -> 016/000 ACCEPT 017/000-000 -> 001/008 ACCEPT 017/001-999 -> 001/008,017/000 ACCEPT 018/000-000 -> 001/010,007/000 ACCEPT 018/001-999 -> 001/010,007/000,018/000 ACCEPT 019/000-000 -> 001/010,007/000 ACCEPT 019/001-999 -> 001/010,007/000,019/000 ACCEPT 020/000-000 -> 001/010,007/000 ACCEPT 020/001-999 -> 001/010,007/000,020/000 ACCEPT 021/000-000 -> 001/010 ACCEPT 021/001-999 -> 001/010,021/000 ACCEPT 022/000-000 -> 008/000,008/001 ACCEPT 022/001-999 -> 008/000,008/001,022/000 ACCEPT 023/000-000 -> 001/010 ACCEPT 023/001-999 -> 001/010,023/000 ACCEPT 024/000-000 ACCEPT 024/001-999 -> 024/000 ACCEPT 025/000-000 -> 008/000,008/001 ACCEPT 025/001-000 -> 008/000,008/001,025/000 ACCEPT 026/000-000 ACCEPT 026/001-999 -> 026/000 ACCEPT 027/000-000 -> 001/010,007/000 ACCEPT 027/001-999 -> 001/010,007/000,027/000 ACCEPT 028/000-000 -> 001/010 25 ACCEPT 028/001-999 -> 001/010,028/000 ACCEPT 800/000-000 -> 001/008,013/000 ACCEPT 800/001-999 -> 001/008,013/000,800/000 ACCEPT 801/000-000 -> 001/008,013/000 ACCEPT 801/001-999 -> 001/008,013/000,801/000 ACCEPT E00/001-001 $xxxx ACCEPT E00/002-002 -> 001/019 ACCEPT E00/003-003 -> 001/000 ACCEPT E00/004-004 -> 006/001 ACCEPT E00/005-005 -> 005/000 ACCEPT E00/006-006 -> 002/000 ACCEPT E00/007-007 -> 001/010 ACCEPT E00/008-008 -> 001/008 ACCEPT E00/009-009 -> 001/002 ACCEPT E00/010-010 -> 002/000 END MESSAGE DISTRIBUTION E00/001-001 -> D:\GT_ECHO E00/002-002 -> D:\RELIGION E00/003-003 -> D:\FINANCE E00/004-004 -> D:\TRADIN E00/005-005 -> D:\DOORS E00/006-006 -> D:\SYSOP E00/007-007 -> D:\GENEALGY E00/008-008 -> D:\SAT_TV E00/009-009 -> D:\SOFTECH E00/010-010 -> D:\DOCTORS END ECHOMAIL HOURS 0100-0400 The sample ROUTING.BBS file above shows how all the regular netmail destinations are INBOUNDed. Since this is the ROUTING.BBS file for the sponsor of E00/001, there is no request for that Echomail conference. There are ACCEPT statements for all nodes in the network, since this came from one of the Continental Hub systems -- notice the extensive use of alternate routing to help move the mail along. All Echomail conferences that are carried have ACCEPT statements, and the ACCEPT statement for E00/001 has no redirection indicated, since this is the sponsoring hub for that conference. Note the OUTBOUNDed nodes, these are present so that calls to these hub systems will be forced, if need be during this session (care should be taken here, that these systems must be operating in netmail mode during this time period, otherwise these calls might be wasted). During this period, calls to pick-up the following conferences will be made: E00/002,E00/003,E00/007. [ fini ] 26