(Z1 EP 2.0) Draft -:- Draft -:- Draft -:- Draft -:- Draft -:- Draft Draft Revision 2.008 Changes by John Souvestre, 1:396/1, on February 26, 1991 Draft -:- Draft -:- Draft -:- Draft -:- Draft -:- Draft ZONE ONE BACKBONE ECHOMAIL POLICY 2.0 PROLOGUE This document sets forth policy governing Zone One Backbone Echomail Conferences and any other echomail conferences for which the Moderator desires it to be applicable. If any item in this policy is in conflict with any existing or subsequent General Fidonet Policy, then General Fidonet Policy will be in effect. At the time it is written, this policy is an extension to Fidonet Policy 4, Section 9.9. This policy addresses echomail at the zone level. Regions may issue their own echomail policies, except that they may not conflict with this one. Nets may also issue their own echomail policies, except that they may not conflict with their region's echomail policy or with this one. I. HISTORY Echomail consists of the sharing of message bases or conferences between various independent network addresses. The echomail concept started with a series of programs by Jeff Rush. Since the original implementation, many authors have written programs improving on the original idea. In spite of worries that the flow of echomail would increase netmail traffic to the point that the network would collapse under its own weight, echomail has been a success. To simplify the distribution of echomail at the zone level, the Backbone was formed. As a result of the growth of Fidonet and the increase in the volume of echomail, it has become necessary to set forth a formal policy governing echomail. II. DEFINITIONS 1. GENERAL FIDONET POLICY: The document which governs Fidonet as adopted by Fidonet. The document as of this writing is Policy 4 and is subject to change. This Echomail Policy is intended to become a part of General Fidonet Policy, as it pertains to echomail in Zone One. Until it is incorporated into General Fidonet Policy, this policy shall serve to define policy violations occurring in echomail. 2. NODE: A Fidonet member, as per General Fidonet Policy. 3. ECHOMAIL: A form of mail in which message bases are shared between independent systems with unique Net/Node addresses. 4. ECHOMAIL CONFERENCES: 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. Examples include COMM, an inter-zone telecommunications conference, and POLITICS, a zone level political conference. 5. ZONE ECHOMAIL COORDINATOR: This individual is responsible for coordination of echomail at the zone level. The Zone Echomail Coordinator is hereafter referred to simply as the ZEC. 6. REGION ECHOMAIL COORDINATOR: This individual is responsible for coordination of echomail at the region level. The Region Echomail Coordinator is hereafter referred to simply as the REC. 7. ECHOMAIL HUBS: These are individuals who distribute echomail. The Echomail Hubs are hereafter referred to simply as Hubs. The Zone Hubs distribute echomail at the zone level. The Region Hubs distribute echomail at the region level. The Net Hubs distribute echomail at the net level. 8. CONFERENCE MODERATORS: These individuals preside over conferences. Conference Moderators are hereafter referred to simply as Moderators. 9. RESTRICTED DISTRIBUTION CONFERENCE: A restricted distribution conference is one which is restricted only to eligible recipients. Examples include MODERATOR, a pre-register conference for Moderators, and MEADOW, a conference for Opus Sysops. 10. ZONE ONE ECHOMAIL BACKBONE: The Zone One Echomail Backbone consists of Zone Hubs who distribute echomail to the region level. The Zone One Echomail Backbone is hereafter referred to simply as the Backbone. 11. ZONE ONE ECHOMAIL CONFERENCE LIST: The Zone One Echomail Conference List identifies the registered zone level conferences. The Zone One Echomail Conference List is hereafter referred to simply as the Echolist. 12. ZONE ONE ECHOMAIL CONFERENCE LIST COORDINATOR: This individual is responsible for the Zone One Echomail Conference List. The Zone One Echomail Conference List Coordinator is hereafter referred to simply as the Zone Echolist Coordinator. 13. ECHOMAIL GATEWAYS: These are Fidonet members whose systems are used to exchange mail with other groups. The term Echomail Gateway, as used hereafter, shall include all forms of gating, including, but not limited to, zone-gating, inter-network gating, and domain-gating. 14. VOTE: Any vote must be carried out in a fair and decent manner while giving at least 14 days notice to those eligible to vote, of the upcoming vote. A good faith attempt must be made to make all eligible voters aware that a vote is occurring and make available all necessary information. 15. SIMPLE MAJORITY: The term simple majority means more than 50 percent of those voting. III. DUTIES OF ZONE ECHOMAIL COORDINATOR, ZONE ECHOLIST COORDINATOR AND MODERATORS 1. DUTIES OF ZONE ECHOMAIL COORDINATOR: The ZEC shall coordinate echomail distribution at the zone level. This includes coordinating the transmission and routing of echomail so that it is done in a manner so as to avoid creation of duplicate messages within a conference. The ZEC shall make available, to any region, any conference which that region is eligible to receive. If for any reason the ZEC does not have access via recognized distribution channels to a specific conference, he can not be expected to provide it. An exception is that the ZEC is not required to make available any conference which routinely contains messages which are encrypted or illegal. Nothing in this provision requires that a ZEC or Zone Hub must import any conference to the extent of adverse economic impact. The ZEC shall recognize conferences at the zone level. The ZEC shall maintain a list of available conferences at the zone level as well as the requirements of each conference as supplied by the Moderator (Echolist). The ZEC shall appoint Zone Hubs to distribute echomail at the zone level. The ZEC may also serve as a Zone Hub, but is not required to do so. A Zone Hub takes on that subset of the ZEC's duties, as defined by the ZEC, for those Nodes he feeds. The ZEC shall insure that all downstream links are educated as to this policy and shall monitor compliance with this policy at the zone level. 2. DUTIES OF ZONE ECHOLIST COORDINATOR: The Zone Echolist Coordinator shall compile and make available the Echolist. This is a registry of zone level and inter-zone conferences, updated monthly, and optionally, conferences at various other levels. The content and format of the Echolist will be at the sole discretion of the Zone Echolist Coordinator, except that it shall include the conference name, the Moderator's name, the Moderator's Fidonet address, a general description of the conference topic, eligibility requirements for restricted conferences, network of origin for conferences which originate outside of Fidonet, distribution plan if other than via the Backbone, and rules for each conference. 3. DUTIES OF MODERATORS: Moderators shall make, in good faith, every reasonable effort to insure that their conferences do not distribute or promote illegal activities or information as defined in Section V, Paragraph 2. Moderators shall publish the conference rules in their conferences at least once a month. Moderators shall be responsible for seeing that messages contained in their conferences correspond to the conference's theme. Moderators shall not fail to perform their duties for a period of more than 10 days without failing to designate proxies. Moderators shall report any violations of this policy to the proper Echomail Coordinators and lodge any appropriate policy complaints as provided for in General Fidonet Policy. If a Moderator believes that a Node is violating a conference rule, he may may authorize the feed to that Node be severed. This authorization shall be made in direct written form (netmail), to the Hub feeding the offending Node, with a copy to the offending Node. IV. SELECTION OF ZONE ECHOMAIL COORDINATOR, ZONE ECHOLIST COORDINATOR AND MODERATORS 1. GRANDFATHER CLAUSE: The ZEC, Zone Echolist Coordinator and Moderators currently holding these positions as of the date of acceptance of this Echomail Policy shall continue to serve in said capacity until resignation or replacement under this policy. For the purpose of calculating the term of office, such term will be deemed to have started on the date that this policy goes into effect. 2. SELECTION OF THE ZONE ECHOMAIL COORDINATOR: The ZEC shall serve for a term of 1 year. He shall be elected as follows: A) Upon resignation or replacement of the existing ZEC, the Zone Coordinator (ZC) shall oversee the election of the new ZEC. B) 14 days after the nominees are selected, an election shall be held. The ZEC will be elected by a simple majority of the RECs. The current ZEC can be identified from the 1/200 listing in the Nodelist. 3. REMOVAL OF THE ZEC: The ZEC may be removed from his position by a simple majority of the RECs. The ZC will oversee the recall election in the same manner as prescribed for electing the ZEC. The ZEC may only be subject to recall for failure to properly carry out his duties described above, or if he is no longer a member of Fidonet. A promise of "free" echomail delivery from another source is not considered an acceptable reason for recall. A ZEC may be removed by the ZC for continued violations of policy or for gross misconduct. 4. SELECTION OF THE ZONE ECHOLIST COORDINATOR: The ZEC shall appoint the Zone Echolist Coordinator. The current Zone Echolist Coordinator can be identified from the 1/201 listing in the Nodelist. 5. SELECTION OF A MODERATOR: A Moderator shall be selected as follows: A) Upon formation of a conference, the person who forms the conference is the Moderator. B) Upon resignation or replacement of an existing Moderator, the conference's rules shall define how the new Moderator is selected. A Moderator need not be a member of Fidonet, but it is highly recommended. A Moderator should have access to netmail. V. STATEMENT OF POLICIES 1. BASIC ECHOMAIL POLICY: The basic policy of echomail is to promote communication in conferences in a lawful, friendly manner consistent with the general principles of Fidonet. 2. PROHIBITION ON ILLEGAL ACTIVITIES: Knowingly distributing, or allowing to be entered into conferences any messages containing or promoting illegal activities or information, is a serious violation of this policy. 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. 3. CENSORSHIP: Removing a message from a conference, or altering its contents, in the passing or distribution of echomail, is considered a serious violation of this policy. An exception to this provision is the deletion of messages, by any Node, which may lead to legal action against that Node. Textual changes to such messages are not allowed. An additional exception to this provision is the deletion of messages, by any Node, which do not meet the echomail message standards in Section V, Paragraph 14. Textual changes to such messages are not allowed. Under no circumstances shall echomail be modified in any manner which could potentially cause duplicates. 4. COUNTERFEIT MESSAGES: Entering or knowingly distributing counterfeit messages is a serious violation of this policy. A counterfeit message is defined as 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. No handles shall be used to enter messages to knowingly provoke, inflame, or upset participants in a conference with the purpose of deceiving others about the true identity of the author. 5. CHARGING FOR DISTRIBUTION: Any entity which makes a profit from the passing or distribution of echomail shall be deemed to be excessively annoying and in violation of General Fidonet Policy. Profit is defined as the charging for echomail distribution in excess of the actual cost to obtain and distribute the echomail over a sustained period. The cost of the equipment used to obtain and distribute echomail may only be recovered on a strictly voluntary basis. Nodes who charge users for access to their BBSs shall not be in violation of this paragraph. 6. RESTRICTED DISTRIBUTION CONFERENCES: Participating Nodes shall honor and support the restrictions placed upon restricted distribution conferences. Violation of this restriction by individual Nodes is a violation of this policy and shall result in suspension of that Node from the violated echo in accordance with Section III. A violation of the restrictions placed on a restricted distribution conference will be a violation of this policy if and only if the Moderator has posted the restrictions governing the conference both in the conference and in the EchoList. A Sysop-only conference shall be made available only to the Sysops or Co-Sysops of Fidonet or other networks with which inter-network conferences exist. Operators of Point systems are not considered Sysops. 7. PATHLINE OPTION: The PATHline (as defined in FTS-0004), is recommended for all Nodes. If your current echomail scanner supports the pathline you should enable it. While the pathline does not eliminate duplicate messages, it can be a very useful tool in determining where a topology problem exists. Hubs must implement the PATHline option. Since these Nodes are operating beyond the scope of the typical Node, they are required to implement features that are otherwise optional. 8. SEEN-BY LINE: Under the current technology and topology (the routing structure of echomail), SEEN-BY lines play an important part in reducing duplicate messages. Tiny SEEN-BYs will not be allowed until the ZEC feels that the topology allows their use. The stripping of SEEN-BYs (except by Echomail Gateways) is not allowed unless approved by the ZEC. Echomail Gateways shall strip the SEEN-BYs of the exporting group to reduce addressing conflicts. 9. NODE'S RESPONSIBILITY: It is the responsibility of each Node to make every reasonable effort to assure that the users on his board conform to the provisions of this Policy. A Node may be held responsible for the acts of his users unless the Node can show that a reasonable attempt was made to conform to this policy. 10. ECHOMAIL SOFTWARE: using echomail software which does not conform to the minimum acceptable standards as defined by the Fidonet Technical Standards Committee (FTSC), and by this Section, is a violation of this policy. 11. INTER-NETWORK CONFERENCES: It is the general policy of Fidonet to encourage the development of Inter-Network Conferences. Inter-Network Conferences shall conform to General Fidonet Policy, as well as the provisions of this policy, in addition to any foreign network's provisions. It shall be the duty of those providing the Inter-Network Conference links to remove foreign network distribution identifiers which will adversely effect the distribution of the conference while in Fidonet. The Inter-Network Conference links maintained in Fidonet shall be operated such that they do not interfere with the foreign network's distribution of echomail. Conferences which originate outside of Fidonet must be designated as such in the Echolist. Echomail Gateways must be able to pass netmail through the Gateway into the other network, unless it is technically impossible to do so. 12. ADDING OR REMOVING CONFERENCES FROM THE BACKBONE: A conference may be added to the Backbone only at the request of the Moderator. A conference must have a Moderator, be listed in the Echolist, and its addition requested by two or more RECs, before it is added to the Backbone by the ZEC. The Moderator may, at his discretion, remove his conference from the Backbone. A conference will be removed from the Backbone when fewer than 2 RECs carry it. A conference may also be removed from the Backbone due to lack of traffic (under 10 messages per month, averaged over a two month period). A conference is subject to removal from the Backbone when the Moderator fails to properly carry out his duties, as described as described in Section III, or violates Section V. 13. TOPOLOGY and DUPLICATE MESSAGES: Cross-region links should be avoided as they increase the risk of improper linking and generation of duplicate messages. Cross-region links may only be established with the prior knowledge of the RECs in both regions. If a REC determines that a cross-region link is contributing to the creation of duplicate messages, the REC may require that the link be terminated. The use of the PATHline option is required for all out-of-region links. The ZEC shall use all the tools at his disposal, such as high speed Hubs, out-of-state Hubs, packet switching network Hubs, Wide Area Calling plans, corporate sponsorship, etc., to facilitate fast, efficient and cost effective movement of echomail. Willfully and knowingly establishing links that either create duplicate loops (topology that creates circular feeds) or refusing to break such links upon request by the ZEC is a serious violation of this policy. 14. ECHOMAIL MESSAGE STANDARDS: Until the adoption of a superseding standard by the Fidonet Technical Standards Committee, the following echomail message standards are recommended: A) Eight-bit characters (ASCII 128-255) and non-printing low-order codes (ASCII 2-31) are prohibited, except the use of 8Dh(soft character) per FTS-0004. This is not intended to discourage participation of foreign zones or networks, which may permit said characters. Any echomail processor should pass information exactly as it was received, without stripping any non-standard characters. B) There should be only one tear line in a message. Tear lines should be limited to 25 characters including the required "--- " lead-in. Tear lines should only contain packer or editor program identification. Tear lines for message editors are discouraged. If an editor adds a tear line, it should also add an origin line, to avoid multiple tear lines. C) There should be only one origin line in a message, except as noted in the next paragraph. Origin lines should be limited to 79 characters including the required " * Origin: " lead-in and ending of a proper network address (i.e. Zone:Net/Node.Point with zone and point being optional), enclosed in parenthesis. D) "Extra" origin lines are allowed when a message is gated. The original origin line's lead-in should be changed to " # Origin: ", and the Echomail Gateway's origin line added. There may be more than one extra origin line in the case that a message passes through multiple Echomail Gateways. The Echomail Gateway's origin line is limited to essential information only. This consists of the required lead-in, the network name, "Gateway", a proper Fidonet address (i.e. Zone:Net/Node with zone being optional), enclosed in parenthesis. Example: " * Origin: TComm Gateway (1:372/666)". E) SEEN-BY addresses should be in sorted order. AKA's are not allowed in SEEN-BY lines unless you have more than one address which processes mail. Or for one month during change of an existing address (to avoid duplicates to the previous address). Node 0 addresses should not be used for echomail distribution. F) All current FTSC specifications must be followed. 15. NETMAIL ROUTING: It is important that users have access to routed netmail in order to facilitate private replies to echomail messages. This helps reduce overall echomail message volume by allowing off-topic replies, flames and other types of messages which don't belong in the conference, to be sent via routed netmail. Until such time as a new General Fidonet Policy is adopted which defines and codifies the routed netmail scheme, the following shall be in effect: A) Zone Hubs shall accept routed netmail from any Node or Hub who exchanges Backbone conferences with them. Routed netmail may be routed along echomail paths, or to a ZC, RC, or NC who has agreed to handle such mail. B) At the present time, routed netmail is provided by both the Coordinator and Echo Coordinator structures. The ZEC shall cooperate with the Coordinators and the Echo Coordinators in further developing and maintaining a routed netmail scheme. 16. FEEDING SEVERED NODE: Knowingly feeding a conference to a Node who has been severed for violations of this policy or at the request of the Moderator, where such feed is intended to subvert either the provisions of this policy or the authority of the moderator, is considered a serious violation of this policy. VI. ENFORCEMENT Enforcement of this policy shall be under the provisions of General Fidonet Policy. Serious violations of this policy shall be considered excessively annoying under General Fidonet Policy. Complaints concerning violations defined under this policy may be filed by the aggrieved individual, the Moderator or by any level of Echomail Coordinator to the appropriate IC, ZC, RC or NC level. All complaints made pursuant to this policy must be made within 60 days of the date of occurrence or discovery. Complaints shall be filed under the provisions of General Fidonet Policy, with a copy to the ZEC or respective REC, as appropriate. Enforcement of this policy is immediate, with any currently existing software allowed 90 days to conform (from the date this policy goes into effect). 30 day extensions may be granted solely at the discretion of the ZEC if efforts to bring about compliance are clear. Continued use of aberrant software after this period is a serious violation of this policy. VII. CHANGES Future changes to Echo Policy may be proposed by any Node, by submitting the proposal to their REC. The REC will then determine if the proposal should be brought before the rest of the RECs. If an REC decides not to bring a proposed change before the rest of the RECs, a message stating why must be sent to the Node. If 10% or more of the NECs in a region request that a proposal be brought before the RECs, then that proposal must be submitted to the RECs. A simple majority vote of the RECs is required in order for a proposal to be formally voted on. If 10% or more of the NECs in the zone request that a proposal be formally voted on, then that proposal must be formally voted on. Those eligible to vote on any proposals made by the REC structure will be the ZEC, RECs and NECs. Those individuals holding more than one position can cast only one vote. Adoption of changes will require a two thirds (2/3) majority of those voting to pass. VIII. BACKBONE STRUCTURE This section is for information purposes only. It gives a plain English description of the current structure and operation of the Backbone. The ZEC may change this structure without amending this policy. At the top of the echomail distribution network, there are two or three Zone Hubs, sometimes called Stars. These Nodes are usually dedicated to distributing echomail. Each has a backup plan in the event of a failure. The Zone Hubs link to one another and feed the Region Hubs. Ideally, each region would have a Region Hub feeding from each of the Zone Hubs. This provides redundancy and allows quick recovery in the case of a Zone Hub or Region Hub failure. IX. REGION AND NET ECHOMAIL POLICIES Regions and nets may issue their own echomail policies, within the constraints described in the Prologue of this policy. In the absence of any such policy, the following defaults shall apply. These defaults should not be viewed as constraints on a region or net policy. A) The duties of the REC and NEC (Net Echo Coordinator) shall be similar to the duties of the ZEC, as defined in Section III, except that the scope will be the region or net, as appropriate. The same is true for Region and Net Hubs. There is no need for a Region or Net Echolist Coordinator. but the REC and NEC shall maintain lists of available conferences. B) A REC and NEC shall make available any conference to qualified lower distribution levels. Nothing in this provision requires that a REC or NEC must import any conference to the extent of adverse economic impact. A Node should expect to share expenses incurred on his benefit. It is recommended that cost sharing arrangements be employed. When expenses are reimbursed, any conference on the Backbone must be made available (other than restricted conferences) when requested. C) Grandfathering, and the selection and removal of the REC and NEC shall be similar to the grandfathering and selection and removal of the ZEC, as defined in Section IV, except that the scope will be the region or net, as appropriate. The current RECs can be identified from the 1/2xx ("xx" is the region number) listings in the Nodelist. They can also be identified from the REC user flags in the Nodelist. The current NECs can be identified from the NEC user flags in the Nodelist. D) Region and Net Hubs shall accept routed netmail from any Node or Hub who exchanges Backbone conferences with them. Routed netmail may be routed along echomail paths, or to a ZC, RC, or NC who has agreed to handle such mail. Draft -:- Draft -:- Draft -:- Draft -:- Draft -:- Draft Suggestions are welcome! Please send to your REC or to 1:396/1. Draft -:- Draft -:- Draft -:- Draft -:- Draft -:- Draft