===================================== == North American Backbone == == General Information & == == Frequently Asked Questions == ===================================== BOFAQ.TXT - 01 May 2003 Terms used throughout this file ================================= North American Backbone - FidoNet hubs who distribute echomail and routed netmail in North America (FidoNet Zone 1). 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. 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.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 and distributed in the BACKBONE file area. BACKSTAT.NA - A North American Backbone newsletter published weekly which lists echoes which have been added to or dropped from the North American Backbone, as well as listing the Zone and Region Hubs. It is published weekly 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. BOFAQ.TXT - This file. It is published as needed 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 regularly by the Zone 1 EchoList Coordinator (1:1/21). 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 file? This 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. It is NOT a set of rules or required laws that involved hubs are forced to follow. Q2 ======================================================================== How are Backbone Hubs selected? ZHubs are selected by the other Backbone ZHubs. Q3 ======================================================================== Are all of the echoes listed in BACKBONE.NA available from all of the Backbone ZHubs? The Backbone ZHubs make available all echoes which are listed in in BACKBONE.NA. Nobody else is obligated to carry all listed echoes. Of course, no Backbone ZHub 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) Maintaining their echo's listing in the Echolist on a regular basis. 2) Be accessible via netmail or email through known channels. 3) Be responsible for the operation of their echo. 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 links so that he or she is made aware of such problems 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? At this time, the Backbone refers to the current EchoList in order to identify an echo's moderator. 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 assistant or 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 agree to 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 ZHubs do not delete or alter messages as they are distributed, except for technical reasons, such as mail tracking. If a Backbone ZHub 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 ZHub 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 ZHubs 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) Due to the limitations of some current software, the Backbone can not guarantee delivery of messages in excess of 13,000 bytes. Backbone ZHubs are encouraged to use message processing software which allows larger messages, preferably up to 64K bytes, to be handled. Backbone ZHubs 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, encrypted, and "grunged" messages. Such messages are generally not returned. Backbone ZHubs operate in a secure fashion. They automatically process inbound messages only from those nodes with which prior connection agreements have been made. Normally this means that Backbone ZHubs 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 ZHub 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 Backbone generally adds an echo to the Backbone when the following requirements are met: 1) The moderator lists the echo in the EchoList. Refer to the EchoList operator for information about how to do this, and then 2) The moderator requests that the echo be distributed by the Backbone. The request should be sent from one of the moderator addresses listed in the EchoList, via one of the following methods, preferably "A". A) Echomail: To "Backbone", in the Z1_BACKBONE echo B) Netmail: To "Backbone", at any Backbone ZHub's address C) Netmail: To "NAB Robot" at it's nodelisted address, presently 1:1/20. The body of the request should consist of a current copy of the EchoList listing for the echo. This could be taken from a recent message from the EchoList (netmail, email or echomail) or be an excerpt from the current EchoList itself. The moderator is also to arrange a connection from his/her system to one of the ZHubs to transport the echo to the backbone. The echo is then listed in BACKSTAT.NA and BACKBONE.NA as being available. 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 Backbone generally drops an echo from distribution when: 1) the moderator sends a direct request to any NAB Coordinator or the NAB Robot the echo be removed. The request should be sent from one of the moderator addresses listed in the BACKSTAT.NAfile: A) Echomail: Z1_BACKBONE echo, to "Backbone" B) Netmail: To any Backbone ZHub's address C) Netmail: To "NAB Robot" at it's nodelisted address, presently 1:1/20. 2) When the Backbone ZHubs decide that the distribution of an echo is no longer in the best interest of the Backbone. All changes in status of echoes are noted in BACKSTAT.NA. Q13 ======================================================================= How do Backbone ZHubs 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 ZHubs 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/encrypted" files, pyramid letters, or chain letters. These are normally deleted without warning, nor are returned. The Backbone treats netmail as private mail. Backbone ZHubs normally 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 ======================================================================= 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. 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 Sunday. 3) Spread the word of the impending name change. Do so in the affected echo, the Z1_BACKBONE echo, and via netmail to each of the listed Backbone ZHub(s). 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 Backbone 6) The change occurs. The new echo name is added to BACKBONE.NA and the old echo name is removed. Q16 ======================================================================= 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 ZHubs 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. Q17 ======================================================================= Does the Backbone carry encrypted messages? Backbone ZHubs do not allow encrypted messages to flow through their systems. The Backbone does not agree to handle encrypted messages. Q18 ======================================================================= What administrative areas does the Backbone use? The Backbone uses one echo area and one file area for its business. The Z1_BACKBONE echo is open to any node having business with the Backbone. The BACKBONE file area is available to all but hatching is restricted to ONLY Backbone ZHubs. Q19 ======================================================================= 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. Q20 ======================================================================= 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) Alternate routing to bypass a down ZHub. Q21 ======================================================================= 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. ================================== 30 +==================================== 05/01/2003