NETMAIL COORDINATION *** DRAFT *** rev. 05/29/90 Jim Rash, 004/000 ============== PURPOSE We shall start with the premise that individual sysops should be provided with information concerning how their network is organized. This information is intended to be a source for both new and existing sysops. It must document the guidelines, procedures, and rationale for the following: I. NET/NODE assignments II. NETMAIL ROUTING III. NODELIST.BBS maintenance OBJECTIVES 1) Insure that decisions relative to network operation promote the OVERALL efficiency and reliability of the network. 2) Provide options and alternatives, with flexibility, to better meet the needs and requests of the INDIVIDUAL sysop. 3) Provide regular and accurate nodelist and hublist updates. =========================================================================== I. NET/NODE ASSIGNMENTS -------------------- 1) EXISTING LOCAL NET If a net exists in a sysop's location it is preferred that a node within that net be assigned, subject to approval of the local net. It is desirable that a net contain only those systems that can call each other via local phone calls. However, there is nothing to prevent the defining of a net to include an entire area code, or applying other criteria. 2) INDEPENDENT NET If a sysop wishes to start in an area where there is no existing net, or does not wish to affiliate with an existing net then that sysop may be assigned a node in an "independent net". An INDEPENDENT NET is one in which all sysops operate independent point nodes (explained below). The use of an independent net will allow remote areas to come online without having to use an entire net/node block. At such time as additional nodes wish to come online in the same location, then a new specific net can be established. 2) EXISTING LOCAL NET IN ANOTHER LOCATION A sysop may affiliate with any existing net. Consideration should be given to area code, cost of connecting with an intra-state hubs vs. inter-state hub, etc. In assigning a node within a remote net, it is understood that the sysop may later request a change to another net or that a new net be created should the number of nodes increase. Other conditions may also justify the net change. 3) INDEPENDENT NODE An "independent node" is a node that is assigned a node number 900 or greater. Generally it will be the responsibility of an independent node sysop to make special arrangements to collect netmail. Mail for 900+ nodes is not sent automatically by the netmail software (MDRIVER) unless provision is made to do so within the ROUTING.BBS. 4) INDEPENDENT POINT NODE A "point node" is an "independent node" who has some other node designated to be their "point server". This designation of who is the "point server" is made within the NODELIST.BBS. The result is that other systems' netmail software will route netmail for the "point node" to the node indicated in NODELIST.BBS as the "point server". II. NETMAIL ROUTING --------------- 1) ROUTING BY NET Netmail is generally routed through the network per NET and not by individual node. This allows the ROUTING.BBS to be maintained by each sysop on a broader level. It is not realistic to expect each sysop to maintain a routing.bbs that provides for different routings for each node within a net. This becomes more evident as a network grows in size. The netmail softwre handles INDEPENDENT POINT NODES by placing their mail in a bag designated for the POINT SERVER indicated in the nodelist. The point server's bag then follows routing instructions. 2) CALLING RESPONSIBILITIES It is normally the responsibility of the individual node to call their HUB for both the sending and pickup of netmail, however any arrangement may be agreed to between the sysops of two nodes. Generally HUBS will place local calls to deliver mail, but they are under no obligation to do so. HUBS generally shall make their own arrangements with other HUBS for the exchange of mail. 3) LOCAL HUBS All netmail for a node may be routed to the LOCAL HUB for that net. This is regardless of the actual location of the nodes within that net. There are some nets that have nodes widely scattered geographically. When a LOCAL HUB chooses to accept the assignment of a node that is remote, the LOCAL HUB must also accept mail on behalf of that node. (Anything else regarding local net operation should remain the option of the individual sysops of the local net.) 4) REGIONAL HUBS The general definition of a "regional hubs" is a net/node that is the primary source of netmail for a LOCAL HUB. The current regional hubs have emerged via a natural process of being used by one or more local hubs. 5) HUBLIST.BBS This HUBLIST will be updated and distributed along with the nodelist. It serves as a DEFAULT for ACCEPTABLE routings. When complete, it will indicate the LOCAL hub for each net, and which REGIONAL hub that the LOCAL depends on. This default listing is not intended to limit a sysop from establishing any connect desired, but rather to provide guidance when in doubt. III. NODELIST.BBS MAINTENANCE ------------------------ 1) UPDATES Updates will be distributed to REGIONAL HUBS, normally weekly. (Holiday weekends may prevent or delay a regular update). REGIONAL HUBS usually forward updates to LOCAL HUBS, but may make their own arrangements, such as notification only that the file is available for a "file request" (.FR). Information regarding updates to nodes and routes will be accepted from anyone via netmail or the nodelist echo and applied to the nodelist or hublist. Please be aware that occasional errors appear in the nodelist echo that are subsequently corrected in the nodelist. It is advisable to use the updated nodelist and rely on the echo only between the nodelist distributions. This procedure should accomplish TIMELY updates. Should an unacceptable number of inaccurate changes be received, then a process of verification with individual nodes before applying the change will be implemented. 2) ACTIVE NODE The node is operational and listed in the NODELIST.BBS with a valid telephone number. Any node so listed is EXPECTED to be available to receive calls during the network's standard "netmail hour". (The netmail hour in the continental United States is from 0400-0500 Central Time.) If a system is unable to accept calls during the netmail hour, it is preferred that it be an "unlisted" number. The system MUST not answer the phone during netmail unless under the control of MDRIVER so as to avoid wasted telephone charges to the calling system. 3) UNLISTED The node is operational but is listed in the NODELIST.BBS with **UNLISTED** as a phone number. Such a node makes individual arrangements for netmail transfers. The phone number may be provided to those systems that must complete a pre-arranged call. This designation is appropriate for sysops who operate part-time or secondary test systems. 4) PENDING This is a node that is about to enter the network. It is indicated in the NODELIST.BBS as **PND_yymmdd. When the node is active, the new sysop should send a netmail message to the coordinator so that the status of the node can be changed to ACTIVE. If a node does not become ACTIVE or UNLISTED within 60 days, then the PENDING is changed to RETIRED and eventually dropped from the nodelist until the sysop again requests a listing. This procedure is for "housekeeping" purposes and is not intended to impose any deadlines for joining the network. 5) TEMP DOWN This is a formerly operational node that anticipates being down for some extended period. The sysop however, has expressed an intent to again become operational. The NODELIST.BBS listing for this node is **DWN_yymmdd. For the purpose of housekeeping, the nodelist listing will be removed after 180 days. 6) RETIRED This is a node where the sysop has announced that they are discontinuing operation permanently or is no longer recognized as being a part of the network. The designation will be **RET_yymmdd and the listing will be dropped from the nodelist after 60 days. At this time, RETIRED net/node numbers will not be reused except by the same sysop unless a change of network CRCs has occurred. 7) CRASHABLE A node that can accept Crash!Mail calls will be indicated with a "*" or a "+" in column 39 of the NODELIST.BBS. The "+" will be used to identify only HUBS that are crushable. (Local HUBS that are NOT crushable may be identified with a "-").