===================================== == North American Backbone == == General Information & == == Frequently Asked Questions == ===================================== BOFAQ711.TXT - 01 Nov 97 (Items noted by the "|" are changes from the previous version.) Terms used throughout this file ================================= North American Backbone - A group of volunteer FidoNet hubs who help distribute echomail and routed netmail in North America (FidoNet Zone 1). The structure is customarily recognized as a set of tiers with the intention of distributing echomail in an accurate and expeditious manner. Hereafter in this file the North American Backbone is referred to simply as the Backbone. Echo or Conference - An echomail conference is a message base or forum, distributed under a specified echomail conference name, dealing with a defined area of interest. Hereafter in this file echomail conferences are referred to simply as echoes. Backbone Hub - A hub who helps to distribute mail within the North American Backbone. Backbone Zone Hubs (ZHubs) distribute mail at the zone level. Backbone Region Hubs (RHubs) distribute mail at the region level. Backbone Net Hubs (NHubs) distribute mail at the net level. Overseer of Backbone Operations (OBO) - Person responsible for the day-to-day operation of the North American Backbone at the zone level. He coordinates routing to ensure reliable and efficient transport of echomail and Backbone-routed netmail while avoiding creation of duplicate messages. He also serves as liaison to the ZEC and to other distribution systems. Backbone Robot Keeper - Person responsible for the maintenance and operation of the Backbone Robot program. This program automates certain aspects of Backbone operation, as described in this file. The Backbone Robot Keeper is appointed by the OBO. Echomail Coordinators (ECs) - Echomail Coordinators have been recognized by Fidonet since 1987. The Zone Echomail Coordinator (ZEC) coordinates echomail at the zone level. Region Echomail Coordinators (RECs) coordinate echomail at the region level. Net Echomail Coordinators (NECs) coordinate echomail at the net level. Backbone Council - An advisory group of RECs who represent the interests of the zone. They provide input and perspective to the Backbone. BACKBONE.NA - A text file listing all echoes, and their descriptions, that are presently carried on the North American Backbone. This text file is formatted in a manner which makes it easily readable by echomail distribution software to use as a "forward list". It is published weekly at the direction of the OBO and distributed in the BACKBONE file area. BACKBONE.NO - A file, distributed along with BACKBONE.NA, which acts as a buffer for echoes which are in the process of being removed from Backbone distribution. Echoes are customarily queued in this file for a period of 90 days. It is published weekly at the direction of the OBO and distributed in the BACKBONE file area. BACKSTAT.NA - A North American Backbone newsletter published weekly which, among other things, itemizes echoes which are in the process of being added to the North American Backbone as well as listing the OBO and the Backbone Zone and Region Hubs. It is published weekly at the direction of the OBO and distributed in the BACKBONE file area. It is advisable that those who rely on the North American Backbone get in the habit of reading this file. BOFAQxxx.TXT (xxx = version) - This file. It is published monthly by the OBO and distributed in the BACKBONE file area. Moderator - Person(s) responsible for an echo and its liaison with the Backbone. Zone 1 EchoList - A database containing a list of echoes, published monthly by the Zone 1 EchoList Coordinator (1:1/201). It customarily contains echo names, moderator names and addresses, and descriptions of the echoes. Hereafter in this file the Zone 1 EchoList is referred to simply as the EchoList. Gateways - Echomail Gateways are nodes whose systems are used to exchange mail with other groups. The term Gateway, as used here, includes all forms of gating including, but not limited to, zone-gating, inter-network gating, intra-network gating, and domain-gating. Q1 ======================================================================== What is the purpose of this help file? This help file has been assembled as a means to provide answers to frequently asked questions regarding how the Backbone operates and to provide an insight into its internal administration. Q2 ======================================================================== How are Backbone Hubs selected? ZHubs are selected by a vote of the OBO and the other ZHubs. RHubs are recognized by the OBO upon application by their respective RECs. An applicant should connect to either a ZHub or another RHub and route netmail and/or echomail for at least a few nets other than their own. NHub selection is left up to the individual nets. Q3 ======================================================================== Are all of the echoes listed in BACKBONE.NA available from all of the Backbone Hubs? The ZHubs make available all echoes which are listed in in BACKBONE.NA. RHubs and NHubs are not obligated to carry all listed echoes. However, no Backbone Hub is required to carry any echo which, in their opinion, could subject them to consequences which might have a negative effect on their well being. Q4 ======================================================================== What are the responsibilities of a moderator of an echo which the Backbone carries? 1) Seeing that messages in their echo correspond to the echo's theme. 2) Updating their echo's listing in the Echolist at least every six months. 3) Preventing the distribution of their echo from interfering with the operation of the Backbone. 4) Must be accessible via netmail through known channels. | 5) Seeing that messages in their echo do not violate the standards set | in Q8, Q20 and Q26. | Q5 ======================================================================== What "tools" does the Backbone provide to a moderator in order to help him/her carry out their responsibilities? If a moderator believes that a node is violating an echo rule, he/she may request the feed to that node be severed. This request is made in written form (netmail), to the hub feeding the offending node, with a copy to the offending node. It is recommended that a copy also be sent to the node's NEC so that he or she is aware of such problems in the net and can provide information and assistance. Some important points to remember regarding feed cut requests: 1) Feed cuts should be initiated with an effort to cause the least amount of disruption to the echo. 2) In most cases, the main goal of a feed cut is to remove a REPEAT offender who is likely to cause future echo disruption. 3) Echo rule offenders are, in most cases, PEOPLE - not systems. 4) SYSTEMS should not be cut until efforts to remove the PERSON have failed. Moderators should attempt to resolve problems as close to the root of the problem as possible, i.e., user first, SysOp second, hub third, etc. 5) Feed cuts at the Zone level are taken very seriously. Only use them as a last resort after all other means have failed. Have proper documentation ready to support a link cut request at the Zone level showing that all other efforts have failed. 6) Feed cut requests are just that - requests. Communications should be polite and not demanding as you are REQUESTING help from another system. Q6 ======================================================================== What means does the Backbone use to recognize the moderator of an echo? A moderator is recognized as follows: 1) Upon formation of an echo, the person who forms the echo is the moderator. 2) Upon resignation or replacement of an existing moderator, the echo's rules define how the new moderator is selected. 3) The Backbone refers to the current EchoList in order to identify an echo's moderator. As far as the Backbone is concerned, all individuals listed as moderators of a particular echo are equal. In case of disagreement, the moderator listed first has priority. Q7 ======================================================================== I am the moderator of an echo, but I may be away from my computer for long periods of time. What does the Backbone suggest that I do to ensure that my echo is properly maintained? Moderators are encouraged to appoint co-moderators to assist them in their duties and to stand in for them in their absence. Q8 ======================================================================== What is the Backbone's position on illegal activities conducted within echoes? The Backbone does not distribute any echo which routinely contains messages which contain illegal information, or promote illegal activities. As used in this paragraph, "illegal activities" includes activities which are a violation of civil law as well as activities which could result in criminal prosecution. Q9 ======================================================================== What is the Backbone's position on the censorship of messages as they pass through the distribution system? Backbone Hubs do not delete or alter messages as they are distributed, except for technical reasons. If a Backbone Hub feels that netmail messages may lead to legal action against him then he may decline to handle such messages, as per FidoNet Policy. If a Backbone Hub feels that echomail messages may lead to legal action against him then he may decline to handle that echo in its entirety, notifying the echo's moderator. The Backbone does not distribute any echo which routinely contains counterfeit messages. A counterfeit message is any message entered using another person's name, handle, or node address with the intent of deceiving others about the true author of the message. Q10 ======================================================================= What technical standards does the Backbone observe? FTSC specifications FTS-0001 and FSC-0074 are followed. Notes: 1) All Backbone Hubs use the pathline. 2) The Backbone considers the "toUserName" and "fromUserName" to be control information lines, thus character set restrictions apply. 3) The requirement that control information lines shall contain only ASCII characters, from 32 to 126, is extended to include hi-bit alphabetic characters, including 128 to 168, 173 and 224 to 240. 4) Echomail messages older than 20 days are considered to be dupes. 5) Due to the limitations of some current software, the Backbone can not guarantee delivery of messages in excess of 13,000 bytes. Backbone Hubs are encouraged to use message processing software which allows larger messages, preferably up to 64K bytes, to be handled. Backbone Hubs may delete messages which do not conform to these technical standards when such messages might be harmful to the technical operation of the Backbone. This includes duplicate messages and "grunged" messages. Such messages are generally not returned. Backbone Hubs operate in a secure fashion. They automatically process inbound messages only from those nodes with which prior agreements have been made. Normally this means that Backbone Hubs use session passwords and secure ("protected") inbound areas. However, any reasonable method of ensuring that non-secure messages do not enter the Backbone is acceptable. A Backbone Hub may choose not to provide services to a node which does not operate in a secure fashion. Q11 ======================================================================= How does one go about getting an echo added to Backbone distribution? The OBO generally adds an echo to the Backbone when all of these requirements are met: 1) The echo is listed in the EchoList. See the EchoList FAQ for information about how to do this. 2) The moderator sends a request to the Backbone Robot Keeper that the echo be distributed by the Backbone. The echo is then listed in BACKSTAT.NA. The moderator should send his request to the Backbone Robot Keeper using one of the following methods: A) Echomail, in the Z1_BACKBONE echo, to "Backbone", subject "-" B) Netmail, to "Backbone", at the Backbone Robot Keeper's address (see BACKSTAT.NA), subject "-" C) Internet E-Mail, to the Backbone Robot Keeper's address (see BACKSTAT.NA), subject "Backbone" The request must be from the moderator, and at the address, as listed in the EchoList's "Last changed" line. Requests from others will be ignored. Included in the request must be an UNQUOTED, UNALTERED copy of the Reply message received from an EchoList Update request. Either the | netmail or Internet e-mail format will suffice. Do not send the | EchoList application, an extract from the EchoList, a Query | response, or the message from the ECHOLIST echo. None of these | contain the formatted lines which the robot needs. Thus, requests missing the required information can not be processed automatically. 3) Within one month of being listed in BACKSTAT.NA, two RECs send requests to the Backbone Robot Keeper that the Backbone carry the echo. Each request is noted in BACKSTAT.NA. Prior to its expiring, the moderator may request a one month extension from the Backbone Robot Keeper. The RECs should send their requests to the Backbone Robot Keeper using one of the following methods: A) Echomail, in the Z1_BACKBONE echo, to "Backbone", subject "-" B) Netmail, to "Backbone", at the Backbone Robot Keeper's address (see BACKSTAT.NA), subject "-" When all of the above requirements are fulfilled, the echo is added to BACKBONE.NA and this is noted in BACKSTAT.NA. A welcome message is sent in the echo to help establish links. At this time any private links to the echo should be switched to the Backbone. Q12 ======================================================================= When does the Backbone remove an echo from its distribution system? The OBO generally drops an echo from the Backbone when any of these situations occur: 1) The echo is not listed in the EchoList. The echo is first moved to BACKBONE.NO for up to 3 months, then it is dropped entirely. During these 3 months, weekly warning messages are posted in the echo alerting the moderator and the users as to the echo's status. If at any time during these 3 months it is re-listed in the EchoList then it is returned to BACKBONE.NA. 2) Unconditionally when the moderator sends a direct request to the OBO that the echo be removed. 3) The moderator fails to properly carry out his responsibilities (see Q4). 4) The echo is without a moderator for over 30 days. 5) The traffic level in the echo falls below 5 messages for any month. The echo is first moved to BACKBONE.NO for up to 6 months, then it is dropped entirely. If at any time during these 6 months the traffic level rises to or above 10 messages for any month then it returned to BACKBONE.NA. 6) When the OBO and ZHubs decide that the distribution of an echo is no longer in the best interest of the Backbone. All movements of echoes between BACKBONE.NA and BACKBONE.NO, or out of BACKBONE.NA or BACKBONE.NO, are noted in BACKSTAT.NA. Q13 ======================================================================= How do Backbone Hubs handle netmail that lands on their systems? The Backbone encourages the use of "echo routed netmail" as a means of keeping echo volume and off-topic posts to a minimum. Backbone Hubs accept routed netmail from any node who connects with them. Any netmail message with a deliverable destination within FidoNet, regardless of its origin, is accepted. The Backbone routes netmail according to the wishes of the individual nets. The Backbone depends on regional routing maps provided by the RECs to represent these wishes. Routed netmail may be routed along echomail paths or to a ZC, RC, or NC who has agreed to handle such mail. Routed netmail is for personal messages. It is not for commercial messages, echoes, mailing lists, news groups, file-attaches, "encoded" files, pyramid letters, or chain letters. The Backbone treats netmail as private mail. Backbone Hubs do not read routed netmail which passes through their systems except as required for technical or legal reasons. Q14 ======================================================================= What does the Backbone expect of nodes who operate as "Gateways"? Gateways must remove foreign distribution identifiers (including seen-bys) which might adversely affect the distribution of the echo on the Backbone. Pathlines, however, should be left intact. The origin line should be that of the Gateway. Gateways also pass netmail into the other network, unless it is technically impossible to do so. Q15 ======================================================================= What obligation does the Backbone have to those who desire to get their mail feed from it? To strive to distribute mail in the most accurate and expeditious manner possible within its means. Although the Backbone attempts to provide the best service possible, there is no guarantee of service provided. Messages which require sensitive or timely handling should not be sent through the Backbone. The Backbone is operated by volunteers and is not obligated to handle any echo which could take the fun out of the hobby. Use of Backbone services should be viewed as a privilege, not a right. Any or all of these services may be terminated at any time, without any prior notice. Q16 ======================================================================= What is the update procedure for this file? The OBO may update this help file anytime that he/she feels that it would be in the best interest of the Backbone and those people it voluntarily serves or in order to more accurately reflect its current operation. Q17 ======================================================================= I need to change the name of my Backboned echo. Is it necessary for me to go through the entire "approval process" all over again? The current echo is well established on the Backbone. In order to change the name of an existing echo without the necessity of reapproval, you should: 1) EchoList the new echo name. (See ELMOD) 2) Set a date for the change to occur. This date should give all concerned plenty of time to prepare. Generally, a 3-4 week notice should suffice. The proposed date for the change should fall on a Saturday. 3) Spread the word of the impending name change. Do so in the affected echo, the Z1_BACKBONE echo, and via netmail to the OBO and each ZHub. 4) Item 3 should be repeated at least once per week before the name change is to occur. 5) On the day before the change is to occur, send a netmail reminder to the OBO. 6) The change occurs. The new echo name is added to BACKBONE.NA and the old echo name is removed. 7) Send a MOD DEL message to the EchoList software to delete the old echo from the EchoList. Q18 ======================================================================= What is the Backbone's position on the use of "Anonymous Remailers"? An "Anonymous Remailer" (AR) is software which conceals the identity of a message's author. Use within an echo is up to the moderator of that echo. However, an AR should not be used in an echo until the echo's moderator has informed the operator of the AR that such messages would be welcome. The burden of proof that such a request has been granted is carried by the operator of the AR. Q19 ======================================================================= I notice that an echo's description in the EchoList places limitations on those who are permitted to access the echo. Does the Backbone enforce those restrictions? No. When moderators place their echoes on the Backbone they must realize that Backbone Hubs distribute publicly available echoes and that the job of enforcing any kind of access restrictions remains with the moderator. These restrictions, as well as the echo's rules, are usually available in the EchoList so that any Sysop interested in the echo may review them prior to actually carrying the echo on his or her system. Q20 ======================================================================= Does the Backbone carry encrypted messages? Some Backbone Hubs do not allow encrypted messages to flow through their systems. Therefore, the Backbone does not agree to handle encrypted messages in routed netmail or in echoes, excepting digital signatures and occasional demonstration and/or test messages. Q21 ======================================================================= How is the OBO selected? The OBO is selected by a vote of the ZHubs. He must then be confirmed by a vote of the RHubs. An election is held when any of the following occur: 1) The OBO position becomes vacant. 2) A majority of the ZHubs, request that an election be held and it has been more than six months since the last election. 3) It has been more than 2 years since the last election. Note: The term of the present OBO is 1 year and expires on June 10, 1998. Q22 ======================================================================= What administrative areas does the Backbone use? The Backbone uses two echo areas and one file area for its business. The Z1_BACKBONE echo is open to any node having business with the Backbone. The Z1_RBC echo is restricted to zone and region level Backbone personnel. The BACKBONE file area is available to all but hatching is restricted. Q23 ======================================================================= Is the Backbone part of FidoNet? The Backbone is indeed part of FidoNet. It's made up of a voluntary group of FidoNet members. It exists within FidoNet and must abide by FidoNet Policy, just as any other FidoNet node or group of FidoNet nodes. However, the Backbone is not an entity or sub-division of FidoNet in the sense that it is not mandated or defined by FidoNet Policy and is not operated by FidoNet officials. There is no requirement for the Backbone to offer services and there is no requirement for anyone to use the Backbone's services. This file is not a part of FidoNet Policy. Should any part of this file conflict with FidoNet Policy then FidoNet Policy shall prevail. Q24 ======================================================================= What emergency plans, if any, does the Backbone have? The ZHubs maintain emergency backup plans should one of them experience problems. These plans include: 1) Quick availability of replacement equipment. 2) Adequate backups of necessary control information. 3) Standby nodes capable of assuming the load. 4) Alternate routing to bypass a down ZHub. Q25 ======================================================================= Why does the Backbone drop echoes when the traffic level falls below a minimum? 1) To encourage the formation of new echoes, like pruning dead branches off a tree. 2) To save the SysOps and users from the frustration of setting up areas only to find that they are dead. Q26 ======================================================================= What is the Backbone's position on encoded files sent via echomail? Echomail is not an efficient method of transporting files. There are many File Distribution Networks which can be used instead. Thus the Backbone does not distribute any echo which routinely contains large (multi-message) encoded files. The use of an echo for small or occasional encoded files is left up to the discretion of its moderator. ================================== End ====================================