* * * F I N A L D R A F T P R O P O S A L * * * May 14, 1994 * * * Zone One Mail Backbone Operating Procedures ============================================= Revision: 1.05 Effective Date: July 1, 1994 Table of Contents =================== 1.0 Introduction 1.1 Purpose of this Document 1.2 Definitions 2.0 Zone Level Operations 2.1 Zone Backbone Coordinator 2.2 Zone Hubs 3.0 Conference Moderators 3.1 Recognition of Moderators 3.2 Responsibilities of Moderators 4.0 Other Operating Procedures 4.1 Administrative Areas 4.2 Message Technical Standards 4.3 Adding Conferences to the Backbone 4.4 Removing Conferences from the Backbone 4.5 Routed Netmail 5.0 Changes to this Document 1.0 Introduction ================= 1.1 Purpose of this Document ----------------------------- This document sets forth the operating procedures used, and defines the services offered, by the Zone One Mail Backbone at the zone level. It describes how the Zone Backbone Coordinator is selected. It also describes how the Zone Hubs operate. The operation of the Backbone within regions and nets is not covered by this document. Participation in the Zone One Mail Backbone is voluntary. Those Coordinators, Hubs, Nodes and Moderators who participate, agree to operate by the procedures, and offer the services, as described in this document. The services offered by the Zone One Mail Backbone are in addition to any which are required of, or due to, members of FidoNet by FidoNet Policy. Use of these services should be viewed as a privilege, not a right. Although the Zone One Mail Backbone attempts to provide the best service possible, there is no guarantee provided. Specifically, messages which require sensitive or timely handling should not be sent through the Zone One Mail Backbone. This document is not a part of FidoNet Policy. Should any part of this document conflict with FidoNet Policy then FidoNet Policy shall prevail. 1.2 Definitions ---------------- The Zone One Mail Backbone consists of the Coordinators, Hubs and Nodes who agree to operate by the procedures, and offer the services, as described in this document, to help distribute the Zone One Mail Backbone echomail conferences and routed netmail to end users, other distribution services and other networks. The Zone One Mail Backbone is hereafter referred to simply as the Backbone. An echomail conference is a message base or forum, distributed under a specified echomail conference name, dealing with a defined area of interest. Echomail conferences are hereafter referred to simply as conferences. The Zone Backbone Coordinator (ZBC) functions at the zone level. It is assumed that Backbone Coordinators of some sort exist at the region level. Hence this document refers to them as Region Backbone Coordinators (RBCs) with the understanding that this might vary within any given region. Regions select their RBCs however they choose. RBCs function at the regional level, providing regional input and direction to the operation of the Backbone at the zone level, as described elsewhere in this document. Hubs are Nodes who distribute mail to other Nodes. Zone Hubs (ZHubs) distribute mail at the zone level. It is assumed that Hubs of some sort exist at the region level. Hence this document refers to them as Region Hubs (RHubs) with the understanding that this might vary within any given region. 2.0 Zone Level Operations ========================== 2.1 Zone Backbone Coordinator ------------------------------ The Zone Backbone Coordinator (ZBC) oversees the operation of the Backbone at the zone level. The ZBC coordinates routing and schedules to ensure reliable and efficient availability of Backbone mail while avoiding creation of duplicate messages. The current ZBC can be identified from his[her] listing in the FIDOSTAT.NA file. The ZBC maintains a list of Backbone conferences in a text file called FIDONET.NA. He[she] also maintains a list of temporary Backbone conferences, in a text file called FIDONET.NO. These files are formatted so that they can be used as forward-lists by programs such as AreaFix. The ZBC distributes these files on a weekly basis via the BACKBONE file area. The ZBC maintains a text file called FIDOSTAT.NA. This file contains a list of conferences seeking to be added to the Backbone. It also contains a list of the ZBC, ZHubs, RBCs and RHubs. The ZBC distributes this file on a weekly basis via the BACKBONE file area. The ZBC is selected by a vote of the RBCs. A mutually agreeable RBC serves as the election chairman. An election is held when any of the following occur: 1) The ZBC position becomes vacant. 2) More than one-fourth of the RBCs 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. 2.2 Zone Hubs -------------- The ZBC appoints Zone Hubs (ZHubs) to distribute Backbone mail at the zone level. The ZBC may also serve as a ZHub if [s]he so desires. Each ZHub offers a minimum of one connection to each region. Each ZHub makes available all of the Backbone conferences, routed netmail and the BACKBONE file area. Nothing in this provision requires that a ZHub carry any conference to the extent of adverse economic impact. The ZHubs maintain an emergency backup plan should one of them experience problems. 3.0 Conference Moderators ========================== Conference Moderators (Moderators) preside over conferences. The Backbone has no desire to interfere with the internal affairs of a conference in so much as they do not disturb the operation of the Backbone. A Moderator need not be either a SysOp or a member of FidoNet. 3.1 Recognition of Moderators ------------------------------ A Moderator is recognized as follows: 1) Upon formation of a conference, the person who forms the conference is the Moderator. 2) Upon resignation or replacement of an existing Moderator, the conference's rules define how the new Moderator is selected. 3) The Moderator and Co-Moderators, if any, are listed in the Echolist entry for the conference since it serves as the guide for Hubs needing this information. Moderators are encouraged to appoint Co-Moderators to assist them in their responsibilities and to stand in for them in their absence. 3.2 Responsibilities of Moderators ----------------------------------- Moderators are responsible for: 1) Maintaining a netmail address in the Echolist, at which they can be reached from FidoNet. 2) Seeing that messages in their conference correspond to the conference's theme. 3) Seeing that messages in their conference do not contain illegal information or promote illegal activities. 4) Posting the conference rules or policies in the conference at least every month. 5) Updating their conference listing in the Echolist at least every six months. If a Moderator determines that a Node persists in violating a conference rule, [s]he may direct the feed to that Node be severed. Such a directive, listing the conference rule violated, is made in a netmail message to the Hub feeding the offending Node, with a copy to the offending Node. After verifying the Moderator in the Echolist, the Hub severs the feed. Should the Hub not comply with the Moderator's directive then the Moderator may direct the feed to that Hub be severed, and so on. Such a directive, listing the procedure followed, is made in a netmail message to the Hub feeding the offending Hub, with a copy to the offending Hub. After verifying the information, the Hub severs the feed of the offending Hub. 4.0 Other Operating Procedures =============================== 4.1 Administrative Areas ------------------------- The Z1_BACKBONE and Z1_RBC conferences are used to conduct Backbone business. Z1_BACKBONE is open to any Node having business with the Backbone. Z1_RBC is restricted for use by region and zone level Backbone Coordinators and Hubs. The ZBC serves as Moderator for both conferences. 4.2 Message Technical Standards -------------------------------- FTSC specification FTS-0001 is followed. Only ASCII characters are used in a message's control fields. Pathlines are used. Due to the limitations of some current software, the Backbone can not guarantee delivery of messages in excess of 13,000 bytes. Hubs are encouraged to use message processing software which allows larger messages, preferably up to 64K bytes, to be handled. The Backbone does not agree to handle encrypted messages in conferences, excepting digital signatures and occasional demonstration and/or test messages. Hubs may delete messages which do not conform to the technical standards set forth in this Section when such messages might be harmful to the technical operation of the Backbone. This includes duplicate messages, "grunged" messages and echomail messages over 20 days old. Such messages are generally not returned. 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 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 Hub may choose not to provide services to a Node which does not operate in a secure fashion if this Node has a history of causing problems due to this lack of security. 4.3 Adding Conferences to the Backbone --------------------------------------- A conference is added to the Backbone and listed in the FIDONET.NA file when all of these requirements are met: 1) The conference is listed in the published Echolist. 2) The Moderator either sends a netmail request to the ZBC or an echomail request, addressed to "Backbone", in the Z1_BACKBONE conference. The ZBC normally requires that the conference has achieved some degree of distribution before accepting this request. See the FIDOSTAT.NA file for current limits. 3) At least three RBCs request that the Backbone distribute the conference to their regions. Also, any conference removed temporarily from the Backbone is restored to regular Backbone distribution when it again qualifies. 4.4 Removing Conferences from the Backbone ------------------------------------------- A conference is removed temporarily from the Backbone, with its listing moved from the FIDONET.NA file to the FIDONET.NO file, when any of these situations occur: 1) The conference is no longer listed in the published Echolist. 2) The conference is without a Moderator. 3) There are no longer three RBCs requesting that the Backbone distribute the conference to their regions. A conference is removed entirely from the Backbone, with its listing removed from both the FIDONET.NA file and the FIDONET.NO file, when any of these situations occur: 1) The Moderator either sends a netmail request to the ZBC or an echomail request, addressed to "Backbone", in the Z1_BACKBONE conference. 2) The Moderator does not carry out his[her] responsibilities, as described in Section 3.2 and determined by the ZBC. 3) The traffic level in the conference falls below ten messages over a two month period. 4) A conference which was removed temporarily from the Backbone does not qualify to be restored to regular Backbone distribution within two months of being removed. 5) When such an excessive number of complaints about the conference or its Moderator are received by the RBCs that a majority of them vote to remove the conference from the Backbone. 4.5 Routed Netmail ------------------- Hubs accept routed netmail from any Node who connects with them for Backbone conferences. Any netmail message with a valid FidoNet destination, regardless of its origin, is accepted. Routed netmail may be routed along Backbone paths or to a ZC, RC, or NC who has agreed to handle such messages. Routed netmail is for personal messages. It is not for commercial messages, conferences, mailing lists, news groups, file-attaches, or "encoded" files. Some Hubs do not allow encrypted messages to flow through their systems. Therefore, the Backbone does not agree to handle encrypted routed netmail messages, excepting digital signatures. 5.0 Changes to this Document ============================= A change to this document may be proposed by any RBC. If a second RBC concurs, the proposed change is voted on by all of the RBCs. Notice of such a vote, including the proposed change, is posted in the Z1_RBC conference, the Z1_BACKBONE conference and the FIDOSTAT.NA file, at least fourteen days prior to the start of the voting period. The RBCs are expected to assess the opinions of the Backbone Coordinators, Hubs and Nodes in their regions, and to vote accordingly. More than fifty percent of those voting must vote for a change for it to be accepted. - end - * * * F I N A L D R A F T P R O P O S A L * * *