Zone One Backbone Operating Procedures ======================================== Revision: 1.03 Effective Date: October 1, 1991 Table of Contents =================== 1.0 Purpose of this Document 2.0 Zone Echomail Coordinator 2.1 Zone Echolist Coordinator 2.2 Zone Hubs 3.0 Region Echomail Coordinators 3.1 Region Hubs 4.0 Backbone Conference Moderators 4.1 Duties of Moderators 4.2 Recognition of Moderators 5.0 Operating Procedures 5.1 Echomail Message Standards 5.2 Banned Messages 5.3 Censorship 5.4 Adding Conferences to the Backbone 5.5 Removing Conferences from the Backbone 5.6 Echomail Gateways 5.7 Routed Netmail 6.0 Changes to this Document 1.0 Purpose of this Document ============================= The Zone One Backbone Echomail System consists of the Zone Echomail Hubs (commonly referred to as "Stars"), Region Echomail Hubs and Net Echomail Hubs who help to distribute the Zone One Backbone echomail conferences. This system 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. Echomail Hubs are nodes who distribute echomail. The Echomail Hubs are hereafter referred to simply as Hubs. Zone Hubs distribute echomail at the zone level. Region Hubs distribute echomail at the region level. Net Hubs distribute echomail at the net level. This document sets forth the operating procedures used by the Backbone at the zone level. It describes how the Zone Hubs, and those Region Hubs who connect directly to them, operate. The operation of the Backbone within a region or net is not covered by this document. If any item in this document is in conflict with any existing or subsequent General Fidonet Policy, then General Fidonet Policy will be in effect. 2.0 Zone Echomail Coordinator ============================== The Zone Echomail Coordinator (ZEC) oversees the operation of the Backbone at the zone level. The ZEC coordinates routing and schedules to ensure reliable and efficient availability of Backbone echomail while avoiding creation of duplicate messages. The current ZEC can be identified from the 1/200 listing in the Nodelist. 2.1 Zone Echolist Coordinator ------------------------------ The ZEC is responsible for maintaining a list of Backbone conferences (Echolist). To assist in this effort, the ZEC appoints the Zone Echolist Coordinator. The current Zone Echolist Coordinator can be identified from the 1/201 listing in the Nodelist. The Zone Echolist Coordinator compiles and publishes the Echolist monthly. It is distributed through the Software Distribution System (SDS) in the ECHOLIST area. The content and format of the Echolist are at the discretion of the Zone Echolist Coordinator, except that it includes the conference's name, the Moderator's name, a netmail address listed in a publicly available nodelist of any network where the Moderator can be reached, a general description of the conference topic, any eligibility requirements for restricted conferences, and the network of origin for conferences which originate outside of Fidonet. The ZEC personally maintains a text file called FIDONET.NA. This is a list of the Backbone conferences in such a format that it can be used as a forward-list by programs such as AreaFix. The ZEC distributes this list to the Zone Hubs whenever it changes. 2.2 Zone Hubs -------------- The ZEC appoints Zone Hubs (Stars) to distribute Backbone echomail at the zone level. The ZEC may also serve as a Zone Hub if [s]he so desires. The ZEC makes available a minimum of one connection from each of the Zone Hubs to each region. A region may choose to not use all of the connections available to it. Each Zone Hub carries all of the Backbone conferences. Each also distribute the FIDONET.NA file, as received from the ZEC, to the Region Hubs they connect with. The ZEC and Zone Hubs maintain an emergency backup plan should one of the Zone Hubs experience problems. Nothing in this provision requires that a ZEC or Zone Hub must import any conference to the extent of adverse economic impact. 3.0 Region Echomail Coordinators ================================= The Region Echomail Coordinator (REC) oversees the operation of the Backbone at the region level. The REC coordinates routing and schedules to ensure reliable and efficient availability of Backbone echomail while avoiding creation of duplicate messages. The current RECs can be identified from the 1/2xx (where "xx" = the region number) listings in the Nodelist. 3.1 Region Hubs ---------------- The REC appoints Region Hubs to distribute Backbone echomail at the region level. The REC may also serve as a Region Hub if [s]he so desires. The REC decides which Region Hub connects to each of the Zone Hubs. If a REC feels that [s]he needs more than one connection to each of the Zone Hubs, [s]he may request extra connections from the ZEC. Region Hubs do not necessarily carry all of the Backbone conferences, but all of the Backbone conferences are available through them. They also distribute the FIDONET.NA file, as received from the Zone Hubs, to those they connect with. Nothing in this provision requires that a REC or Region Hub must import any conference to the extent of adverse economic impact. 4.0 Backbone Conference Moderators =================================== Backbone 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. If the Moderator is not a member of Fidonet, [s]he must list an address in a publicly available Nodelist of any network, so that he can be contacted if the need arises. 4.1 Duties of Moderators ------------------------- Moderators are responsible for: 1) Seeing that messages in their conference correspond to the conference's theme. 2) Updating their conference listing in Echolist at least every six months. If a Moderator believes that a node is violating a conference rule, [s]he may authorize the feed to that node be severed. This authorization is made in direct written form (netmail), to the Hub feeding the offending node, with a copy to the offending node. 4.2 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) Should a conference which originates inside of FidoNet be without a moderator for over 30 days, the ZEC may cause a Moderator to be selected. Moderators are encouraged to appoint Co-Moderators to assist them in their duties and to stand in for them in their absence. 5.0 Operating Procedures ========================= 5.1 Echomail Message Standards ------------------------------- FTSC specifications FTS-0001 and FTS-0004 are followed. All Backbone nodes use the pathline option. 5.2 Banned Messages -------------------- The Backbone does not distribute any conference which routinely contains messages which are encrypted, 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 would result in criminal prosecution. The Backbone does not distribute any conference 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. 5.3 Censorship --------------- It is not allowed to delete a message from a conference, or alter its contents, in the passing or distribution of Backbone echomail. Exceptions to this provision are the deletion of messages, by any node, which may lead to legal action against that node or which do not meet the echomail message standards in Section 5.1. 5.4 Adding Conferences to the Backbone --------------------------------------- The ZEC adds a conference to the Backbone when all of these requirements are met: 1) The conference is listed in the Echolist. 2) The moderator sends a netmail request to the ZEC. [S]he should include a copy of the Echolist confirmation message if the conference does not appear in the currently published Echolist. 3) Two RECs request that the Backbone carry the conference to their regions. 5.5 Removing Conferences from the Backbone ------------------------------------------- The ZEC may drop a conference from the Backbone when any of these situations occur: 1) The conference is not listed in the Echolist. 2) The moderator sends a netmail request to the ZEC. The ZEC always honors this request. 3) There are no longer two RECs requesting that the Backbone carry the conference to their regions. 4) The Moderator fails to properly carry out his duties, as described in Section 4.1. 5) The conference is without a Moderator for over 30 days. 6) The traffic level in the conference falls below 5 messages over a two month period). 5.6 Echomail Gateways ---------------------- Echomail Gateways are nodes whose systems are used to exchange mail with other groups. The term Gateway, as used hereafter, includes all forms of gating including, but not limited to, zone-gating, inter-network gating, and domain-gating. Gateways remove foreign distribution identifiers (including seen-bys) which might adversely affect the distribution of the conference on the Backbone. Gateways also pass netmail into the other network, unless it is technically impossible to do so. 5.7 Routed Netmail ------------------- Backbone nodes 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 echomail paths or to a ZC, RC, or NC who has agreed to handle such mail. 6.0 Changes to this Document ============================= A change to this document may be proposed by any REC. Anyone else desiring to propose a change should find a REC who is willing to sponsor their proposal. If a second REC concurs with a proposal, the proposed change is voted on by all of the RECs. Notice of such a vote is posted both in the REC conference and in FidoNews, at least 14 days prior to the start of the voting period. The RECs are expected to assess the opinions of the members of their regions, and to vote accordingly. The voting period is 7 days. More than 50 percent of those voting must vote for a change for it to be accepted. - end -