What is GT Netmail? GT Netmail is a function found in the newest release of GT (tentatively called GT Power 13.00) that allows a regularly scheduled and automatic exchange of messages between systems that are designated as being a part of the network of systems so engaged. This exchange takes place without human intervention. Concepts A network of computers consists of any number of systems that may be located anywhere so long as they are each able to connect with each other via a modem. Each such system, if it is to be designated as part of the network, has a unique set of numbers assigned to it so that any other system that is also designated as part of that network may 'know' of it and know how to communicate with it. These numbers are called the 'Net/Node' for the system. The 'Net' part of the designator refers to the set of systems that are presumed to be within local dialing distance of all others bearing that same 'Net' designator. For example, the GT Net which is numbered 001 is the set of all systems located in the greater Houston, Texas area. Within that 'Net', each system is given a unique 'Node' number. Net and Node numbers are separated with a slash for convenience. Thus, 001/000 is the designation of a system known as Node number zero on Net number 001. Net numbers range from 001 to 999 while Node numbers range from 000 to 999. Unless a system is designated as part of the network, it is thought to have a Net/Node number of 000/000. The National GT Network reserves all Net numbers from 001 through 899. Net numbers from 900 through 999 may be used for private networks or other Local networks that are NOT part of the National GT Network. Node number 000 is significant only in that by convention it refers to the Local Net Coordinator. This person has the responsibility of assigning all Node numbers within his/her Net and for assuring the security of those Nodes (more about that later). Net numbers are assigned by the National Network Coordinator (James Davis at this time). In order for a message to enter the stream of messages that are automatically routed from Net/Node to Net/Node by the system, those messages must be created with a destination (Net/Node) along with an addressee. This is only possible at this time within message areas that are specifically established for Netmail. Within your GTMDIR.BBS file, which is located within your GT directory, is a list of all message bases known to your system. A typical entry contains an authorization level, a pathname, and a brief description of that message base. You may specify as many Netmail message bases as you wish. In order to do so all that is necessary is that you add a tilde (~) to the beginning of the pathname for that message base in this file. For example, (GTMDIR.BBS contents:) B C:\GT\BETA Beta test message base. =C C:\GT\PRIVATE Private message base. *D ~C:\GT\NETMAIL Netmail CONFERENCE - restricted access. F C:\GT\GENERAL General public message base. Line one shows a message base that requires at least an access level of 'B' in order to gain access. Line two shows a private message base available only to those users that have access level 'C' assigned to them. Line three shows a conference message base. This means that so long as the user has at least an access level of 'D' he/she will be able to see that the message base exists, but until the Sysop changes the BAN flag that is set in the user record (GTMAIL.CTL) when the user first tries to access this base (applies for access), the user may not actually get into the message area. Also, because the pathname starts with a tilde (~), the message base is used to send and receive messages over the Netmail network. Of course, line four shows a message base that anyone with at least an access level of 'F' may enter. There is actually one additional control symbol that the Sysop | may use with a Netmail message base entry in GTMDIR.BBS; it is | the carrot (^) and it indicates that NO PRIVATE messages are | allowed by any user, even if those users have private message | capability. The symbol is placed in front of the tilde (~) | in the GTMDIR entry for that message base. For those of you that | wish to have more than one message base, and to prevent private | messages in ALL Netmail directories, you may use this symbol in | your GT.CNF file (via Alt-I) entry that specifies the main | message base. | When a user has been authorized to enter into the Netmail message base he may create and read messages just as in the other message areas (and with the same restrictions - namely, Private mail only if authorized). When entering a message in this area, however, when he is asked to enter the 'To:' name, and does so, he will then be asked to enter the Net/Node number where that message is to be delivered. If the user does not know the correct Net/Node number he is given the ability to List all Net/Nodes known to the system. Further, he may have the system scan the list of Net/Nodes looking for either a part of the BBS name or the addressee's name. In any event, the user must input a valid Net/Node number in order to proceed. (Incidentally, you may specify only the significant digits in a Net/Node number. ie, 1/0 is the same as 001/000). Recall that all nodes with the same Net number are presumed to be local calls from any other Node in that Net. Thus, it is presumed that these calls do not cost anything to place. For that reason, if the user specifies a Net/Node that is 'local' and it is found that that Net/Node exists, no further checking is performed. However, if the Net is other than the one he is using as he prepares the message, then because the call will involve (by assumption) long distance charges to the Sysop, a method of cost control has been implemented that may deny the user the right to create the message. That is, if the user has been assigned some number of CREDITS (units, not dollars), he is allowed to create the message for the 'out-of-net' destination. Otherwise he is not allowed to do so. There is a GTMAIL.CTL file associated with each message base. The message base that is called the 'default message base' is where the main user file (GTMAIL.CTL) exists. It is this file that is used to determine if a user is to be allowed access to the system at time of logon. This main message base user file is NOT the one in which CREDITS are assigned relative to the use of Netmail. In order to provide a user with a CREDIT balance, you must use GTCTL and change to the Netmail message base. Then, using GTCTL's 'Update User' function (Option 4), you may change the user's CREDIT balance. Scheduled 'events' are a function of GT that are Sysop defined. That is, there is a new file called SCHEDULE.BBS that is located in the GT directory. Besides certain control information, there is an entry for each 'event' that the Sysop wishes GT to become aware of and to cause to happen at a specified time. An 'event' is merely a program or a batch file name. For example, the following entry might be used to specify that an event called 'MAIL' is to occur at 4:00 a.m.: 04:00-04:15 MAIL (start range) 'MAIL', of course, is either the name of a program or a batch that DOS can find via its PATH. Let us suppose that it is the name of a batch file (MAIL.BAT). This batch file would contain DOS commands such as the following: MBAGGER MDRIVER XXXX-YYYY sss eee /D5 | MDIST Thus, at 4:00 a.m. GT would cease all communications activity (gracefully, and in fact, about five minutes earlier) and then Shell to the MAIL batch file. DOS would, in turn, invoke the MBAGGER program and when that completed it would invoke the MDRIVER program, then the MDIST program. When that third program was finished, DOS would return to the scheduler program within GT and GT would resume normal communications. This is exactly how you should setup for Netmail. Now it is time to discuss the parts of Netmail to make it clearer as to what is happening. There are several new directories that must exist on the drive that contains your GT programs. You do not have to create these directories as when they are needed the Netmail programs will create them automatically if they do not exist. The first is called \MAILWORK. This directory is used as workspace for the various Netmail programs and normally contains nothing in it. The next two are: \MAILOUT and \MAILIN. These are used for temporarily storing messages that have been 'bagged' to get ready for delivery to another Net/Node or which have been received from other Net/Nodes prior to being 'un-bagged' and distributed to a message base, respectively. Bagging a message merely means ARChiving it into an ARC file with a name that contains routing information along with all other messages to be delivered to that same destination. Please note, IT IS ASSUMED THAT YOU HAVE A COPY OF PKARC AND PKXARC SOMEWHERE IN THE DOS PATH FOR NETMAIL TO WORK!!!! MBAGGER This is a standalone program that finds all Netmail message areas that you have defined (by reading your GTMDIR.BBS file and looking for those tildes). It then looks at each message in those message bases looking for those that have not yet been 'MAILED'. A message has been 'MAILED' as a result of the actions of the MBAGGER program, not because it has actually been sent over a telephone line. If the message is destined for your own system (has YOUR Net/Node as a destination), then MBAGGER marks it MAILED, 'bags' it, and moves that bag to your \MAILIN directory. If it is for any other Net/Node then this program creates or updates an ARChive file with a name that insures that it will be sent to the proper Net/Node and places all messages destined to that same Net/Node into this file (the 'bag') before placing the bag into your \MAILOUT directory. When all messages have been 'bagged' and marked 'MAILED', MBAGGER is complete and returns control to the batch file processor. MDRIVER This is the heart of the Netmail system. This program is told the start and end time of the Netmail run (normally an hour) and it will wait in memory until the start time before beginning to do anything. When the start time is reached, MDRIVER wakes up and begins alternating between listening for the phone to ring and making outgoing calls. Please note, start time and end time (sss and eee) is to be specified in pseudo military time. That is, using a 24 hour clock and using 24:00 to mean midnight rather than 00:00. Whole numbers may be used (ie, 23 is the same as 23:00). In an effort to insure that all nodes do not get into synch and try calling each other at precisely the same time as the other nodes are trying, there is a random time duration generator within this program. Thus, you will see that some variable number of seconds (usually between 1 and 30) will lapse between attempts by your system to make a call out. Should your phone ring, the program will answer it and try to determine who has called. If it is a human or a system operating in terminal mode (still considered a human) then the caller will be told that your system is in the middle of a Netmail run and asked to call back later before the connection is broken. If, and only if, it is a Netmail Node that is calling, then this program will insure it is a valid Net/Node (authorized) before progressing. If not, it will disconnect and await the next call. If it is a valid Net/Node Netmail caller, then the program will accept mail from it (putting the received bags of mail into your \MAILIN directory). It may also then deliver mail you have on your system with the caller's Net/Node as a destination at that time. Recall that if the Net number is the same as your own, it is a local call. In that case, the calling system will be forced to accept delivery of mail destined for it as there is presumed to be no extra costs involved. Interestingly, if the call came in via PC-Pursuit, it is also assumed that there is no additional cost and the caller will be required to accept delivery from you. In any other situation, your system will not force delivery upon the caller. When all messages have been sent and/or received, the session will end and the program will once again begin the alternating between listening for the phone to ring and making calls. (There is also the possibility that the caller may ask for a file to be sent to him or to attach a file to a message. These situations are discussed later). Your system will place calls to all Net/Nodes that have Bags of mail to be delivered to them. (If you wish to place a call to | a Net/Node, even if you do not have any mail to deliver to that | Net/Node, you may force the system to do so by including an | OUTBOUND NODE entry in your ROUTING INSTRUCTIONS.) These calls | are simply the reverse of the receipt of a call. When all bags that are to be sent have been forwarded to their destinations, or if the mail hour end time occurs, this program terminates and returns control to the batch processor. One of the additional functions of the MDRIVER program is to help | the sysop avoid 'stale mail' collecting in his MAILOUT directory. | This is done via the inclusion of a command line parameter on the | MDRIVER command line. The format of this 'switch' is: /Dxx where | xx is the number of days a mailbag will be allowed to age before | it is removed from the MAILOUT directory. In a very real sense, | such a mailbag contains dead-letters. Thus, MDRIVER renames the | bag by replacing the first letter (B) with an 'X' and, if it was | originated on your system, moving the bag to a subdirectory on | your system called \MAILOUT\DEADLTR. If the bag originated on | some other system, then the system will create a message to the | sysop of the originating Net/Node telling him you were unable to | deliver the bag and the bag will be File Attached to it. | MDIST This program gets control and looks into the \MAILIN directory to see if any mail has been delivered to you. If so, the mail bags are unARCed and the resulting messages are placed into the first Netmail message area. (In a future release we may have implemented a method for distributing to various message bases, but not at this time. Note that all messages that pass through the Netmail system have the ORIGIN Net/Node number and BBS name suffixed to them so that the recipients of them will know where they came from. When this program is completed control returns back to the batch processor which, in this example, will then return control to the GT scheduler and cause GT to return to the mode it was in prior to the event. File Transfers Netmail uses two 'dot commands' similar to those found in WordStar to indicate that a file is attached or requested. These dot commands are '.FA' and '.FR' respectively. The period MUST be found in column one of any line of the message text, and the FA or FR are to immediately follow (without intervening blanks). Also, following one or more blanks, there is to be a file name. Thus, if a message contained the following line in it: .FR NODELIST.BBS Then the recipient of that message would understand that it is to look for a file called 'NODELIST.BBS' in a directory that is specifically set up for the purpose (\MAILOUT\FILEOUT) and if it finds that file it is to send it to the caller (via Megalink). | It is EXTREMELY important for you to recognize that a File | Request (.FR) requests an immediate file transfer of the | requested file rather than just requesting that a message be sent | back to the originator that contains that file. Consider that as | a significant difference, File Requests are not simply one-way | transactions. One-way transactions allow Netmail to be effective | over PCP, and, as a result, provides for (in conjunction with the | implementation of Local and Continental Hubs) cost free traffic | from coast to coast. Let me be even more specific, ALL messages | that contain a File Request (.FR) will be sent DIRECT from your | Net/Node to the destination Net/Node (WITHOUT using HUBS). Thus, | if you are in New Your and request a file from a node in Florida, | the MDRIVER program will call Florida (ie, a Long Distance call). | Thus, when they connect, the File Request can be honored. For | this reason we have provided you the ability to prevent your | users from using either .FA or .FR capabilities. | Similarly, if the '.FR' had been a '.FA', then the caller will send a file to the receiver (host) and it will be placed into a directory called \MAILIN\FILEIN when received. The method used | here is quite different than in the case of File Requests. File | Attaches are detected by the MBAGGER program which looks into the | \MAILOUT\FILEOUT directory on your system for the specified file. | Finding it, MBAGGER then archives that file (using PKARC) into | the same mailbag as the message which contains the .FA message. | It is expected that the SYSOP will control access to these file transfer functions via new authorizations in the GTPASSWD.BBS file. 'FR' is the authorization code for use within the password | file that allows a user with that authorization to use the .FA | and .FR commands. | Security A Prime objective in the design of the GT Netmail function is security. It would be a disaster, for example, if any user of GT should 'pretend' to be a valid Net/Node and call other valid Net/Nodes requesting mail to be delivered. For this reason we have developed a concept called the CRC that must be used with the MDRIVER command. Without a valid CRC, the MDRIVER is not capable of establishing a Netmail session. The CRC codes are assigned by the National Network Coordinator. Like passwords, the CRC code for a Net/Node is CONFIDENTIAL!!!!!! In the example MDRIVER command shown above, the XXXX-YYYY is the CRC code assigned for the node that is running the code. (The 'sss' and 'eee' are start time and end time of the session). Additional Control There are two more files associated with GT Netmail; ROUTING.BBS and NODELIST.BBS. Like the others, these must be located in the GT directory. NODELIST.BBS This file contains the valid Net/Nodes for the network along with telephone numbers, baud rates, City, BBS name and Sysop name. It is usually provided by the Network Coordinator. It is necessary to be running with the most current NODELIST.BBS at all times!! ROUTING.BBS This file contains as many as seven 'sections' at this time, | though there may be others added over time. The first is used | to define the PC-Pursuit numbers so that your system will use | PCP for those Net/Nodes where it is appropriate. The documen- | tation which accompanies your Netmail programs contains a complete example of this section of the ROUTING.BBS file. Note that you need only include those PCP numbers that are a part of your network. Also please note that the city name in the NODELIST.BBS must match identically those listed in this section of ROUTING.BBS in order to recognize that a call is to be placed via PCP. Note that each section of the ROUTING.BBS file must start | with the section name (in this case, 'PURSUIT'), and end with a | line that contains the single word 'END'. | The second section of this file is called the INBOUND NODES section. This is used in order to tell your MDRIVER program that it is NOT to place calls to the Net/Nodes specified. For example, some Net/Nodes have access to PCP and, thus, they may call you without additional cost. These same Net/Nodes may not be Pursuitable. Thus, you mark them as INBOUND NODES and you will receive calls from them but not place calls. And, recall that if they are via PCP your mail to them will be forced upon them as there is no additional cost to the caller to do so. The entries in this section are in the following format: | Net/Node-Node where Net is the Net number and | Node-Node is a range of Node numbers (even the same one). The next section, like all of them, is optional and is named | 'LONG DISTANCE'. It is used to override the default rules used | by MDRIVER to determine if a number is local or long distance. | (Default has it that all nodes on the same Net are local. That | is, any number that has an area code that matches the one {or more} specified in your SCHEDULER.BBS file is assumed to be local and | will result in a dialing string like this: ATDTxxx-xxxx|). There | are times, however, when a node may have the same area code but | still be considered long distance by your local telephone company.| In such a case your dialing string would have to be constructed | like this: ATDT1,xxx-xxx| so we have provided this section to | allow you to specify which nodes those are. The format of each | entry in this section is identical to that of the INBOUND NODES | section; NET/Node-Node. | Next, there is a section called 'OUTBOUND NODES'. This is used, | to specify those Nodes that are to be called during each Netmail | session at least once, whether there are any mailbags to be sent | or not. Note, in this section only, a range of nodes is not used | along with the Net number. That is, valid entries contain only | only the specific Net/Node desired. | Another section is called 'PREFIXES'. Within this section you | may tell MDRIVER if you wish it to prepend prefixes and/or to | append suffixes to the dialing strings it creates. There are two | kinds of numbers as far as MDRIVER is concerned; Local and Long | Distant. Each may have prefixes and/or suffixes and these may be | different as between the two types of numbers. Within this | section, you specify LOCAL prefixes with the keyword 'LOCAL' | followed immediately with the symbols for the prefixes and | suffixes desired enclosed in parenthese. The symbols are the same| as used in your GT.CNF file and MDRIVER extracts from that file | what the symbols mean. | For example: LOCAL(-) or LOCAL(*,+) or LOCAL(,!) | The first example shows MDRIVER being told to add a prefix to all | local calls. The second example shows it being told to add both | a prefix and a suffix to all local calls. The third example | shows it being instructed to add only a suffix to all local calls.| Similarly, you may control the dialing string for all long distance calls. The keyword in that case is 'DISTANT'. | Note, if you specify a prefix for long distance calls then MDRIVER| WILL NOT automatically insert a leading '1,' in front of the area | code. It becomes your responsibility to do so. | ROUTING INSTRUCTIONS is the next section. It is conceptually | rather easy to understand, but is probably the single greatest | source of trouble to new users of NetMail. The purpose of this | section is to tell MDRIVER where to send mailbags that it finds in| your MAILOUT directory that are not destined to your own system. | Further, it also specifies how your system will respond if asked | by another Netmail system to accept mailbags for destinations that| are not yours (this is called mail forwarding). | In the simplest of cases, you will not have anything in this | section ofyour ROUTING.BBS file, but that would prevent you from | benefiting from one of the best features of NetMail; the ability | to send and receive messages from coast to coast without cost | - utilizing Hubs. A Hub is merely a GT Netmail system that has been established and | setup in such a way that it will accept mail for other Net/Nodes. | At the present time, there are two kinds of Hubs: Local and | Continental. A Local Hub is established in each Net (usually the | Hub coordinator's system). These Hubs accept mail for any Node | within the Hub and will forward those mailbags to the destinations| desired. Thus, any node can send all mail to all nodes in the Net| by placing only one call (to the Local Hub) and sending ALL | outbound mail to it. The Hub, in turn, will place all local calls| necessary to deliver that mail. | The Continental Hubs are established as clearing houses for the | Local Hubs. These Continental Hubs accept Mail for ANY Net/Node | on the Network. Local Hubs may call a Continental Hub and forward| ALL mail destined out of their own Net. The Continentala Hubs | have been established in such a way as to have certain Local Hubs | assigned to them. Thus, when a Local Hub calls its Continental | Hub it can receive all mail destined to that Net as well as make | deliveries. Continental Hubs will forward (or arrange to have | forwarded) all mail that belongs to other Continental Hubs | automatically. Thus, a Local Hub can 'deliver' ALL of its out-of-| net mail with one phone call to its assigned Continental Hub. | All of the above explains why we have included the ROUTING | INSTRUCTIONS section. There are two kinds of entries within it. | The first utilizes the keyword 'FORWARD' while the second uses | 'ACCEPT'. The FORWARD keyword is used primarily by non-Hub Nodes.| These tell the MDRIVER program where to send all mailbags. These | entries may utilize re-direction or not. Re-direction is merely | an alternate address to which a mailbag will be sent RATHER THAN | the actual destination. Specifically, in the case of a non-Hub | node, every Net/Node address that the sysop of that system wishes | to communicate with (usually the entire network), should have a | FORWARD entry that tells the MDRIVER to re-direct those mailbags | to the Local Net Hub rather than directly to their destinations. | In this way, the non-Hub nodes can 'deliver' all mail with but a | single phone call (a local one) to their Local Net Hub. Following | is a set of FORWARD entries that shows this for a non-Hub node | identified as 004/009 where the Local Net Hub has an address of | 004/000: | ROUTING INSTRUCTIONS | FORWARD 001/000-999 -> 004/000 | FORWARD 002/000-999 -> 004/000 | FORWARD 003/000-999 -> 004/000 | FORWARD 004/000-000 | FORWARD 004/001-008 -> 004/000 | FORWARD 004/010-999 -> 004/000 | FORWARD 005/000-999 -> 004/000 | etc. | END | The first three lines tell MDRIVER that if it should attempt to | deliver mail for any node within Nets 001 through 003, it should | re-direct delivery to the Local Net Hub (004/000). Line four says| that mail addressed to 004/000 is to be sent directly (without | re-direction) to that Net/Node. The fifth line says re-directs | mail destined for nodes 001 through 008 of Net 004 to the Local | Net Hub. 004/009 needs no FORWARD nor re-direction because the | messages to that net/node are already at their destination and | MDRIVER will never see them. The sixth line re-directs all the | rest of the mail for Net 004 to the Local Net Hub. | What, then, does an ACCEPT entry do that is different from a | FORWARD entry? Only one thing: It allows your MDRIVER to ACCEPT | re-directed mail for those net/nodes and to show what to do with | it. That is, if you are accepting delivery of mail for some other| net/node (you are acting as a Hub), then you must specify via | ACCEPT statements rather than FORWARD statements that you will | allow receipt of such mail. In all other aspects the ACCEPT | statement is identical to the FORWARD statement. | One GOLDEN RULE to remember about these entries: The same address | must NOT appear on both sides of a re-direction command. | For example, ACCEPT 004/000-999 -> 004/000 is in error, since | 004/000 is found on both sides of the re-direction symbol (->). | Why? Well, when MDRIVER attempts to re-direct mail for 004/000 | to net/node 004/000, then it will do so with a forwarding request | of the receiving system. This means that the receiving system is | to accept the delivery of mailbags and place them into its MAILOUT| directory rather than its MAILIN directory. Since it goes into | the MAILOUT directory, when the session completes, MDRIVER re- | organizes itself so that it can attempt to make delivery of all | mailbags in its MAILOUT area. Recall that MBAGGER shortcircuited | this step for all mail destined for the system they are already | on. MDRIVER is not designed to handle bags of mail destined for | itself. Without the re-direction symbol, MDRIVER sends mail to | the destination directly and the receiving system puts it into its| MAILIN directory. | The last currently defined section of ROUTING.BBS is called | 'PICKUP OVERRIDES'. Here, we have provided a method for the | sysop to override MDRIVERS cost control functions. Local calls | and those that are made over PC-Pursuit will always first deliver | the mail that they have to deliver, then they will automatically | request delivery of all mail destined (or forwarded) to it. This, | because there is no extra cost to the caller if the duration of | the call is slightly extended. Long distance calls made without | the benefit of PCP, however, do not automatically request delivery| of all mail. Thus, only the purpose of that call (sending of | mail) is attempted during such a session. If, however, you want | mail to be delivered during such a call, you would use this | section to so specify. The format of such an entry is identical | to that used LONG DISTANCE and INBOUND NODES sections described | above (ranges included). Note that specifying a Net/Node here | will NOT automatically result in a call to the specified | Net/Node(s) unless there is mail to be sent to that node. To | force a call, you must use the OUTBOUND NODES section. | Setting it all up Assuming you are running the latest version of GT, these steps will get you set for participation on the Netmail network: 1) Obtain a Net/Node number from your Local Net Coordinator along with the CRC code to be used with it. 2) Create a Netmail message base via modification of your GTMDIR.BBS file (The tilde character before the pathname). 3) Create a SCHEDULE.BBS file. It should contain the following lines: NET=xxx NODE=yyy AREA=zzz (may contain multiple #'s. ie, =713,510) | NAME=BBS name CITY=your city (same spelling as in PCP list in ROUTING.BBS) 04:00-04:15 MAIL (Will start anytime in range 4:00-4:15) Obviously, the event shown scheduled for 04:00 should be the actual time of the event as specified by your Net Coordinator. 4) Create the MAIL.BAT file: MBAGGER MDRIVER XXXX-YYYY 4 5 /D10 (XXXX-YYYY being the CRC code) | MDIST 5) Create the ROUTING.BBS file as described above. 6) Copy the NODELIST.BBS file into your GT directory. 7) TEST IT - TEST IT - TEST IT GOLDEN RULES!!! If you have a Net/Node number assigned then you must follow these two simple rules: 1) Your system MUST be running Netmail during the same hours as everyone else on the Network! 2) If for any reason your system is not running Netmail during those hours, YOU MUST NOT ANSWER THE PHONE DURING THOSE HOURS!!!! The Immediate Future The volume of Netmail traffic will increase quite rapidly as we add | new Nets and Nodes to the Network. We have already seen during the | testing period preceeding the formal release of Netmail that each | Hub can handle upwards of 100 mailbag transfers per hour, assuming | faithful adhearance to the concept that only Local Net Hubs call | Continental Hubs and that there are a resulting multiple mailbags | per call that increased the efficiency of the sessions. Soon, | however, we will surpass that capability and we will be forced | to add more Continental Hubs. At the time of the release of Netmail| there were only two Continental Hubs. Paul Meiner's has a second | system that will become the third Continental Hub immediately | (001/003). And a fourth will come on-line as necessary. In the | very near future we will add one more level of Hubs to the | architecture: the Regional Hub. It is expected that there will be | an Eastern and a Western Regional Hub in the near future. These | Hubs will accept mail from any Local Net Hub within their | geographical area of interest and forward (re-direct) mail to THE | Continental Hub they are assigned to, or to Local Net Hubs within | their areas, or to the other Regional Hub. What does not change is | that these Regional Hubs must place at least one call per Netmail- | day to their designated Continental Hubs in order to insure the | receipt mail from other places around the country. As plans firm | up for these Regional Hubs we will have much greater flexibility in | routing mail. This will be facilitated with new capability in | MDRIVER that will allow the user to specify ALTERNATE ROUTING of | mail should it not be able to deliver mail via the route of | preference. | In a very real sense, the dynamics of Netmail will determine where | we go from here in terms of design and implementation. What is | certain, however, is that users of Netmail are to follow the design | faithfully in order that it be as efficient as possible. Providing | coast to coast mail capability without cost to the users was done | with an architecture in mind. To not use that architecture as | designed will damage the success of the effort. | Enjoy the facility and please send any feedback you would like us | to consider. |