(Z1 EP 3.1) Draft ----- Draft ----- Draft ----- Draft ----- Draft ----- Draft Draft 1 Prepared by Echopol Committee 15 May - 16 Jul 1993 Draft 1 Reviewed by Zone 1 RECs 16 Jul - 27 Aug 1993 Version 3.0 Discussed publicly in Z1_ELECTION 27 Aug - 12 Sep 1993 Draft 2 Rewritten by Echopol Committee 12 Sep - 19 Sep 1993 Draft 2 Reviewed by Zone 1 RECs 19 Sep - 07 Oct 1993 Version 3.1 Discussed publicly in Z1_ELECTION 08 Oct - ZONE 1 BACKBONE ECHOMAIL POLICY Version 3.1 08 October 1993 --------------------------------------------------------- TABLE OF CONTENTS 1. OVERVIEW 1.0 Basis of policy 1.1 Purpose of policy 1.2 Backbone goal 1.3 Agreement 1.4 Amendments 2. APPOINTMENTS 2.0 Zone Echomail Coordinator (ZEC) 2.1 Region Echomail Coordinator (REC) 2.2 Net Echomail Coordinator (NEC) 2.3 Zone Echomail Hubs (ZHubs) 2.4 Region Echomail Hubs (RHubs) 2.5 Change of Appointments 2.6 Conference Moderators (Moderators) 2.7 Nodelist Designations 3. DISTRIBUTION SYSTEM 3.0 Participation 3.1 Alternate feeds 3.2 Guarantees 3.3 Charging for distribution 3.4 Backbone Echo Lists 3.5 Restricted distribution 3.6 Autonomy of Nets 3.7 Emergency backup planning 3.8 Security 4. CONTENT 4.0 Routing 4.1 InterNetwork goals 4.2 Encryption 4.3 Routed files 5. SOFTWARE STANDARDS 5.0 Technical references 5.1 Monitoring responsibility 5.2 Message Size 6. DISPUTES 6.0 Use of judgement 6.1 Complaint settling 6.2 Sanctions 6.3 Removal of echoes for cause 7. MODERATOR APPEAL COMMITTEE 7.0 Interim Procedure 7.1 Feed Cuts 8. DEFINITIONS 8.0 Backbone 8.1 Backbone Echolist 8.2 CRP 8.3 Downlink 8.4 Echo 8.5 FidoNet Policy 8.6 Gateway 8.7 Illegal 8.8 Insecure mail 8.9 International Echolist 8.10 Low and high ASCII characters 8.11 Routine Operating Information 8.12 Secure node 8.13 *EC --------------------------------------------------------- 1. OVERVIEW 1.0 Basis of policy This Echomail Policy document (Echopol) has been drafted by the Echomail Coordinators (*ECs) to detail the principles on which the Zone 1 Echomail Backbone Distribution System (the Backbone) operates. This policy may not be enforced under the terms of Fidonet Policy since the Backbone is not a Fidonet issue. The Terms used in this document are defined in Section 8. Separate policy documents may be issued at the Region or Net level to provide additional detail on local procedures. Ordinarily these lower-level policies may not contradict this policy. However, with the approval of the ZEC or REC as appropriate, local policy can be used to implement differences required due to local conditions. 1.1 Purpose of policy This document establishes the echomail policy for the Backbone. Its purpose is to define, standardize and provide guidance for decisions required in the operation of the Backbone, and to define the Echomail Coordinator structure. This policy applies only to services provided by the Backbone such as echomail listed on the Backbone Echolist, and Netmail routed through the Backbone. 1.2 Backbone goal The Backbone was designed to simplify the distribution of echomail at the Zone level to provide echomail to each Net. Its purpose is to promote communication in echomail conferences in a lawful, friendly manner consistent with the general principles of FidoNet. The Backbone is run on the basis of 'organized anarchy'. It functions solely as a carrier of echomail, though not in the legal sense. This policy is written around the principles of 'notification rather than approval', and 'coordination rather than control'. 1.3 Agreement Any node accepting a feed of Backbone echomail or routing netmail through the Backbone agrees to the provisions of this policy. All Echomail Coordinators will ensure that downlinks receiving a Backbone feed are educated concerning this policy. The author of any message entered onto any Zone 1 Backbone echo is considered to have retained ownership of his message, but to have granted permission for its non-profit use. 1.4 Amendments Amendments to all or part of Echopol are ratified by a simple majority of casting votes in a policy referendum. Suggestions for amendment to Echopol may be submitted at any time to the ZEC or to an REC who will present the proposal to the RECs for discussion. The ZEC will call a policy referendum either on the request of 5% of Zone 1 sysops presented to the ZEC or if a majority of RECs request a referendum. Multiple amendments may be considered during a single referendum, but will be voted on individually. Changes to this policy are to be made as follows: Draft amendment circulated via a backbone file echo for comment Public discussion in Zone-wide echo for minimum of three weeks RECs review and recommend any changes to revised draft Final draft circulated via a backbone file echo Vote by all to accept/reject revision Voting results published in Zone-wide echo To allow for timely modification of routine procedures, the ZEC may establish and maintain a Zone 1 Backbone Routine Operating Information (R.O.I.) document. Drafting and modification of R.O.I. is subject only to approval by a majority vote of RECs. 2. APPOINTMENTS 2.0 Zone Echomail Coordinator (ZEC) A ZEC is selected by the Zone, as coordinated by the ZC, on whatever basis the Zone chooses, and is responsible to the Zone, as coordinated by the ZC. The ZEC coordinates echomail, routing and schedules at the Zone level to ensure reliable and efficient availability of Backbone echoes while avoiding creation of duplicate messages. 2.1 Region Echomail Coordinator (REC) An REC is selected by his Region, as coordinated by the RC, on whatever basis the Region chooses, and is responsible to the Region, as coordinated by the RC. The REC coordinates echomail, routing and schedules at the Region level to ensure reliable and efficient availability of Backbone echoes while avoiding creation of duplicate messages. The REC is responsible for the technical integrity of all echomail sent from his Region into the Backbone system. 2.2 Net Echomail Coordinator (NEC) An NEC is selected by his Net, as coordinated by the NC, on whatever basis the Net chooses, and is responsible to the Net, as coordinated by the NC. The NEC coordinates echomail, routing and schedules at the Net level to ensure reliable and efficient availability of Backbone echoes while avoiding creation of duplicate messages. The NEC is responsible for the technical integrity of all echomail sent from his Net into the Backbone system. 2.3 Zone Echomail Hubs (ZHubs) A ZHub distributes echomail at the Zone level, connecting to other ZHubs as determined by the ZEC and providing a minimum of one connection to each Region. A ZHub acts as an unlanned extension of the ZEC's computer system. The ZHub does not make decisions on feed cuts, echo termination or other echomail policy matters. Each ZHub carries all Backbone echoes and appropriate related file echoes. Where such a requirement would have an adverse economic impact on the ZHub, it will pre-arrange any variance from this requirement with the ZEC. A ZHub is appointed by the ZEC. 2.4 Region Echomail Hubs (RHubs) An RHub distributes echomail at the regional level, normally connects to a ZHub, and provides connections to regional Nets as determined by the REC for the Region. Each RHub carries Backbone echoes to the extent deemed appropriate by the REC and and its function and limitations are the equivalent of a ZHub. An RHub is appointed by the REC in accordance with regional echomail policy. 2.5 Change of Appointment The Zone, a Region, or a Net, as coordinated by the ZC, RC or NC respectively, may choose to replace the appropriate *EC on whatever basis it decides. A ZHub, RHub or NHub appointment may be transferred at any time by the *EC level which appointed it. 2.6 Conference Moderators (Moderators) Moderators preside over echoes, and the Backbone recognizes that a moderator has complete authority over his/her echo in regards to the echo's policy, standards of conduct and participation. The Backbone accepts the International Echolist entry as defining the moderator of an echo. A Moderator is responsible to the ZEC for the smooth operation of his echo while on Backbone distribution, and he shall be readily accessible via netmail through a FidoNet node number.. When the Backbone agrees to carry an echo on the Zone 1 distribution system, the Moderator in return agrees to the provisions of this policy and to accept the following responsibilities: a. seeing that messages in the echo correspond to the echo's theme as expressed in the International Echolist. b. ensuring that the echo does not distribute or promote illegal activities or information. c. updating the echo listing in the International Echolist at least every six months. d. monthly posting of echo rules or policy. 2.7 Nodelist Designations To assist in identifying echomail coordinators, it is suggested that Echomail coordinators be identified by the UZEC, UREC, and UNEC user flags on the coordinator's personal node number entry. This does not prevent a Net from asking the NC for a unique (admin) node number for the Net-sponsored system which imports echomail. 3. DISTRIBUTION SYSTEM 3.0 Participation All nodelisted systems are eligible to be considered for a feed of Backbone echomail unless barred from receiving a feed under the terms of this policy. No one shall knowingly feed Backbone echomail to a node whose feed has been cut for violations of Echopol. 3.1 Alternate feeds Any node may obtain a feed of Backbone echomail from any source willing to feed it, and may subdistribute that echomail to other nodes at its discretion. In general, any legal form of distribution which lowers costs, and improves speed of communication, while avoiding circular feeds which cause duplicate messages, will be encouraged. New technology will be explored and will not be accepted or rejected out of hand. No Echomail Coordinator shall prohibit a node from obtaining a Backbone echomail feed or from distributing that feed provided no technical problems are being created by that feed or distribution. A node or Net receiving a feed of one or more Backbone echoes from other than conventional ZHub/RHub/NHub connections shall advise the NEC or REC of the routing and subdistribution topology being used. This should include the use of advanced technology (eg: satellite). An Echomail Coordinator does not control non-standard feeds, but must know about them in order to coordinate them. Procedures for handling specific types of distribution methods will be specified in R.O.I. 3.2 Guarantees While the Backbone attempts to provide the best service possible, it provides no guarantee of either echomail or routed netmail delivery. Messages which require sensitive or timely handling should not be sent through the Backbone. The receiving of Backbone echomail is a privilege, not a right. 3.3 Charging for distribution The Backbone exercises no control over Cost Recovery Plans (CRPs). Decisions regarding the sharing of costs, nature of the costs, participation and/or subdistribution of echomail which a CRP has imported are matters which concern only the sysops involved. 3.4 Backbone Echo Lists The ZEC is responsible for the maintainance of a list of available echoes at the Zone level (Backbone Echolist). The ZEC may also appoint a Zone Echolist Coordinator to be responsible for the maintenance of a detailed list of echo descriptions (International Echolist), with terms of reference set out in R.O.I.. The ZEC shall remove an echo from the Backbone Echolist upon the request of the official moderator. 3.5 Restricted distribution The Backbone Echolist only lists echoes which are freely available to all sysops. BBS users, however, may be restricted from participation in some of these echoes. 3.6 Autonomy of Nets Since the Backbone exists to distribute echomail to each Net, the Net's NEC forms the final level of the Backbone organization, and acts as the interface between the Net and the Backbone. There is no attempt in this document to determine the distribution arrangements within individual Nets. 3.7 Emergency backup planning To allow the Backbone distribution system to continue to operate with a minimum of disruption in the event of long-term power failures, equipment failures or loss of volunteers, the ZEC will coordinate an emergency backup plan for the ZHubs. It is recommended that each REC maintain a regional emergency backup plan. 3.8 Security To prevent deliberate disruption of echoes by various forms of mail dumping, each ZHub and RHub shall operate in such a manner that only mail arriving from nodes with which distribution arrangements have been pre-arranged is processed automatically. Any reasonable method of ensuring that insecure mail does not enter the Backbone without review is acceptable, such as software capable of separating the mail automatically, subroutines prepared by the hub, packet-level passwords, visual examination or other methods. An echomail hub may choose not to accept inbound mail from a downlink which does not operate as a secure node, but at its discretion may continue to feed Backbone mail to that downlink. 4. CONTENT 4.0 Routing Due to the costs involved echomail is not normally routed. Echomail shall not be routed without prior agreement between all nodes involved. The Backbone's primary purpose is to distribute echomail. As a courtesy, the Backbone accepts and delivers Echomail Routed Netmail (ERN) and all Region and Zone Hubs agree to support such routing. If the netmail load from any Net becomes too onerous, the Backbone may choose not to accept ERN from that Net. Where a Net does not support outgoing netmail with its echomail transfers it should make arrangements for disposition of incoming ERN with the appropriate RHub. 4.1 Inter-network goals It is the general policy of FidoNet to encourage communication between FidoNet and all other networks through the development of inter-network echoes. Inter-network echoes shall conform to the provisions of this policy while being distributed by the Backbone. The ZEC may direct that an echomail gateway operating procedures document be established to provide a technical base for increasing contact between various networks. Drafting and modification of a gateway operating procedures document is subject only to approval by a majority vote of RECs. 4.2 Encryption The language of FidoNet is English, and all Backbone echomail traffic shall be in this language unless the echo moderator specifies otherwise. With the exceptions listed below, no Backbone echomail or Echomail Routed Netmail message may be encoded, encrypted, public-key encrypted, enciphered or otherwise rendered unreadable. The use of high or low ASCII characters is not permitted in the header, tearline, or origin line of a message. Uuencoded or similar message-format files are considered to be routed files and may not be routed in netmail. Short pieces of programming code, no longer than a typical message and infrequently sent, may be routed in netmail. Provided that an echo moderator has so indicated in the International Echolist, a moderator may permit high or low ASCII characters in the body of the message, and also small segments of recognized programming language or of uuencoded text, but is subject to Backbone judgement as to when these segments become excessive. A sysop has the right to require that the originator of any apparently encrypted or otherwise unreadable message being routed through his system provide him with satisfactory evidence that the message is neither commercial nor illegal in content. 4.3 Routed files Due to the large size and additional cost of transmission the Backbone does not accept routed files. It accepts no responsibility for returning such files or for advising the originator of their non-transmission. The Backbone distributes essential administrative files containing information on echo areas. These files are regularly routed to all mail hubs for public distribution. All Backbone systems have agreed to transport these files. The current names of the files, the file areas and the routing software used are listed in R.O.I.. 5. SOFTWARE STANDARDS 5.0 Technical references Current technical standards for Backbone echomail and routed netmail are listed in R.O.I.. Nodes sending messages via the Backbone shall ensure that such messages conform to the above standard. 5.1 Monitoring responsibility To reduce costs and system malfunctions for sysops participating in the Backbone distribution system, proven message tracking or monitoring software may be employed by echomail hubs at all levels. This may include the use of 'grunged message' detection software and the return or notified-deletion of damaged or out-of-specification messages. 5.2 Message Size Due to the limitations of older software the Backbone can not guarantee delivery of long messages. The currently accepted maximum message size handled by ZHubs is specified in R.O.I.. Downlinks and software programmers are encouraged to use this standard so that all messages up to this length are routed without interruption. 6. DISPUTES 6.0 Use of judgement The application of Echomail policy in the resolution of disputes requires the use of good judgement by the echomail coordinators involved. Decisions should be made in a consistent manner with a genuine attempt made to obtain both sides of any issue. Where this policy does not appear to forsee a particular situation the echomail coordinator is expected to use a combination of this policy, precedent and his own good judgement to resolve a dispute. 6.1 Complaint settling Complaints referred to in this section (6) are those dealing with technical issues where a decision may be made under the terms of this Echomail Policy. If a complaint is filed under the terms of FidoNet Policy it shall be referred instead to the appropriate NC, RC or ZC for resolution. Where a node is unable to obtain satisfactory handling of an echomail complaint from his NEC he may address the complaint to his Region's REC and failing a satisfactory response from the REC, he may address the complaint to the ZEC who shall be the final arbiter in such matters. 6.2 Sanctions The only sanction which may be applied to a node or a Net by an Echomail Coordinator for contravention of this policy is removal of its access to Backbone services such as echomail and outgoing routed netmail feeds. Where a node is unable to correct a technical problem of which there is proof, and which is disrupting the smooth operation of the Backbone, the appropriate Echomail Coordinator may request that the feed of the node be cut. The only sanction which may be applied by the Backbone to a moderator is removal of his echo from Backbone distribution. 6.3 Removal of echoes for cause The Backbone has no desire to interfere with the internal affairs of a Backbone conference as long as it does not disturb the smooth operation of the Backbone. An echo may be removed from Backbone distribution by the ZEC in the following cases: a. inadequate traffic or distribution. b. failure to meet technical standards. c. inability of the moderator to accept or respond to netmail. d. violation of Backbone Echopol. The ZEC may remove an echo automatically in the case of a. above. Removal for any other reason requires the prior approval of a majority of RECs and evidence that the moderator has been given sufficient warning and an opportunity to present his point of view to the ZEC. 7. MODERATOR APPEAL COMMITTEE 7.0 Interim Procedure It is the intent of the Backbone eventually to leave all matters concerning the appointment of moderators and disputes arising out of the internal operation of echoes to a Moderator Appeal Committee, appointed and run by the moderators independently from the Backbone, and recognized by the moderator community in a manner similar to current recognition of moderators. Until such time as the moderators establish such a committee, the Backbone will handle such matters as detailed below. Once such a committee is established, it is intended that section 7 be deleted from this policy. The ZEC will appoint a Backbone Appeal Committee (B.A.C.) from among the 10 Zone 1 RECs. Current membership will be detailed in R.O.I.. The B.A.C. will only hear appeals from users, sysops, Hubs and moderators concerning moderator-requested feed cuts. All other types of internal echo disputes will be the responsibility of the parties concerned to resolve. 7.1 Feed Cuts A moderator shall not unreasonably remove a user or node from participation in an echo. When a moderator wishes to terminate a user's participation for violation of the echo's published rules, the Moderator will send netmail to the user's Sysop directing that the user's access to the echo be severed. This netmail will include advice that the ruling may be appealed to the B.A.C., and will also include the ZEC's name and node number. The Sysop will immediately terminate the user's access as directed. If he fails to do so the moderator may request of the ZEC that the Sysop's feed of the echo be terminated, or failing that the NHub's feed, or failing that the RHub's feed. Where a user or node appeals a feed cut to the B.A.C., the committee will request evidence from the appellant and from the moderator to support their arguments. Should the committee find that there is insufficient evidence to support the cut, or should it find in favour of the appellant, the moderator shall reconnect the appellant to the echo. No node shall knowingly feed an echo to a node whose feed has been cut at the request of the Moderator. 8. DEFINITIONS 8.0 Backbone The Zone 1 Echomail Backbone Distribution System (the 'Backbone') is an independent organization separate from Fidonet, whose Echomail Coordinators and Hubs have Fidonet node numbers. It incorporates all Backbone Zone and Region level distribution to individual Nets. The distribution system includes Backbone Echomail Coordinators, echomail conferences, conference moderators, and distribution arrangements. 8.1 Backbone Echolist The Backbone Echolist is a listing of area tag names for all current Backbone echomail conferences, and is maintained in a format usable for automatic processing of feed requests. 8.2 CRP A Cost Recovery Plan (CRP) is a cost-sharing arrangement between nodes participating in an echomail delivery system in which costs of importing and distributing echomail are shared by members of the system. 8.3 Downlink A downlink is a system, whether node or hub at any level, which receives Backbone mail from a distribution source above it (its uplink). 8.4 Echo An Echo, also called an Echomail Conference, or Conference, is a message base or forum distributed under a specified echo name, or TAG, dealing with a defined area of interest. 8.5 FidoNet Policy The current ratified FidoNet Policy is Policy 4 and is referred to in this document as FidoNet Policy. 8.6 Gateway A gateway is a system of computers equipped to pass electronic mail messages of various types between FidoNet and a non-FidoNet network. A Gateway acts as a translator, allowing messages entered on a system in the other network and addressed to a destination within FidoNet to be translated into a form which is technically acceptable to and compatible with FidoNet, and vice versa. 8.7 Illegal In addition to illegal behaviour referred to in FidoNet Policy, the term 'illegal' in this document will be taken as referring to behaviour considered illegal via the criminal justice system in the jurisdiction of the coordinator, hub, sysop or moderator who must take responsibility for such behaviour. It is recognized that this definition will result in varying definitions of 'illegal' depending on the location of the person on whom such responsibility rests. 8.8 Insecure mail Insecure mail is considered to be mail (netmail or echomail) received from nodes with which distribution arrangements have not been pre-arranged, thereby lacking assurance that the sender has authorized access to Backbone echomail areas or other services. 8.9 International Echolist The International Echolist is an informal, international listing of Echomail conferences as described and submitted by each conference's moderator. It contains descriptions and other data for all Backbone and many non-Backbone echoes. 8.10 Low and high ASCII characters In this document, high ASCII characters are considered the Eight-bit characters (ASCII 128-255), while low ASCII characters are considered the non-printing low-order codes (ASCII 2-31), with the exception of the 8Dh(soft character). 8.11 Routine Operating Information The Zone 1 Backbone Routine Operating Information (R.O.I.) file provides functional details for the application of this Policy and normally contain non-policy matters to clarify, standardize, or ensure smoothness in the Backbone's distribution system. 8.12 Secure node A secure node is one which processes inbound mail automatically only from nodes with which prior agreement has been made to accept such mail. 8.13 *EC For the purpose of the Zone 1 Backbone echomail system, the term '*EC' or 'Echomail Coordinator' refers to the Zone 1 ZEC, RECs, and NECs. It does not refer to any Hub or other use of the term 'Echomail Coordinator'. --------------------------------------------------------- "FidoNet" is a U.S. registered trademark of Tom Jennings. --------------------------------------------------------- Echopol Committee: Adrian Walker 153/752 Miles Hoover 109/25 Tony Wagner 105/2 John Mudge 352/111 Larry Squire 3620/2 Mark Astarita 2605/10 Dixon Kenner 243/5 Dallas Hinton 153/715 Michael Walsh 273/10 ---ooo000ooo---