2002 << Back To iNDUSTRIA fLASHERA iNC nº 8

Next file: file_id.diz >>

GENERAL ECHOMAIL POLICY 1 February 1, 1989 PROLOGUE This document sets forth policy governing Echomail conferences and their distribution. This Policy applies to Zone One Backbone Echomail conferences and to any other conferences for which the Moderator desires it to be applicable. Future changes to Echo Policy may be proposed only by a simple majority vote of the Regional Echomail Coordinators. Those eligible to vote on any proposals made by the REC structure will be the ZEC, RECs, NECs, NCs, RCs and IC. Only one vote per person is allowed. Adoption of changes will require a simple majority of those voting to pass. In this document, "a simple majority" means more than 50 percent of those voting. A good faith attempt must be made to make all potential voters aware that a vote is occurring and make available all necessary information. 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, a national Echomail Backbone formed whose primary purpose is the distribution of Echomail at a national level. Of recent introduction to the Backbone system has been the generous contribution of the Echomail Stars. 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. ECHOMAIL: The process of sharing message bases between independent systems with unique net/node addresses. 2. ECHOMAIL CONFERENCES: An Echomail conference is a message base of forum design distributed under a specified conference name dealing with a defined area of interest. Notable examples include TECH, the National Technical Conference and COMM, the National Telecommunications Conference. 3. MODERATED CONFERENCE: A moderated conference is an Echomail conference for which a moderator has been appointed to supervise the flow and content of the conference. All conferences carried on the Backbone must be moderated. 4. SYSOP-ONLY CONFERENCE: A Sysop-Only Conference is one in which the Moderator has decided that the conference will be made available only to Sysops and not to users. 5. RESTRICTED DISTRIBUTION CONFERENCES: A restricted distribution conference is one which is restricted only to eligible recipients. Notable examples include REGCON, the Regional Coordinators Conference, COORD, the National Echomail Coordinators Conference, and MAGICK, a pre-register Echomail Conference. 6. ZONE ECHOMAIL COORDINATOR (ZEC): This individual is responsible for coordination of Echomail on a FidoNet Zone level. 7. REGIONAL ECHOMAIL COORDINATOR (REC): This individual is responsible for coordination of Echomail within his region. 8. NET ECHOMAIL COORDINATOR (NEC): This individual is responsible for coordination of Echomail at the Local Net level. 9. ECHOMAIL Backbone: The Echomail Backbone consists of voluntary members who provide services to enhance the national distribution of Echomail. The Backbone consists of nodes which handle a high volume of Echomail traffic and are responsible for distribution of Echomail down to the regional level. 10. NATIONAL ECHOMAIL LIST: The National Echomail List identifies the available national conferences, the conference moderator and requirements of the specified conference. The ZEC will appoint the keeper of the National Echomail List. 11. AUTOMATED CENSORSHIP: The term Automated Censorship refers to programs which cause messages to be removed from the intended conference or have their content altered. 12. FIDONET POLICY: The document which governs Fidonet as adopted by Fidonet. The document as of this writing is Policy3 and is subject to change. This policy is intended to become a part of general Fidonet policy. Until it is incorporated into General Fidonet policy, this document shall serve to define policy violations occurring in Echomail. 13. OPEN ACCESS CONFERENCE: This is a non-restricted conference open to all users who are willing to follow the posted conference rules. 14. TERMINAL NODE: A system which does not process echomail for pickup by another system. III. DUTIES OF ECHOMAIL COORDINATORS 1. GENERAL: It is the duty of the *ECs to make available to any Fidonet Sysop, any conference which the Sysop is not prohibited from receiving by not meeting requirements as mandated by the conference moderator. If for any reason the *EC does not have access via recognized distribution channels to a specific conference, they can not be expected to pass it on. If a *EC fails to make available any conference to qualified lower distribution levels, this shall be deemed to have violated the outlined duties of the position held. Such violation is cause for the removal as provided by this document. Nothing in this provision requires that a *EC must import any conference to the extent of adverse economic impact. It is recommended that cost sharing arrangements be employed. Where financially feasible for the supplier any conference on the Backbone must be made available (other than restricted conferences) when requested. An exception is when a *EC cuts a link to end unauthorized distribution of a conference. In this case, some otherwise authorized nodes may temporarily lose their link. A *EC shall do everything in their power to insure that: 1. All downstream links are educated as to this policy. 2. Downstream links know how to properly link into conferences. 3. Acceptable and unacceptable behavior in echomail conferences is explained. 4. Downstream links are not engaging in topologies that increase the risk of duplicate messages. 2. DUTIES OF ZONE ECHOMAIL COORDINATOR: It is the duty of the ZEC to coordinate the connections between the Echomail Backbone on both an inter-Zone and intra-Zone level as well as coordination of inter-regional connections. The ZEC will coordinate transmission of Echomail and to provide for routing in a manner that will avoid the transmission of duplicate messages within the same conference. It is also the duty of the ZEC to monitor compliance with this policy on both a national and international basis. 3. DUTIES OF REGIONAL ECHOMAIL COORDINATOR: It is the duty of the REC to provide for regional Echomail distribution. In addition, the REC will coordinate any inter-regional cross- linking of conference feeds with the REC of the participating region with the direct knowledge of the ZEC. The REC will provide for transmission and routing of Echomail within his/her region in a manner to avoid creation of duplicate messages within the same conference. It is the duty of the REC to monitor compliance with this policy at a regional level. 4. DUTIES OF NET ECHOMAIL COORDINATOR: It is the duty of the NEC to coordinate the intra-net Echomail and to cooperate with the REC and NECs of other nets to arrange for the inter-net transmittal of echomail. The REC may require the NEC to provide links for independent (regional) nodes. The NEC shall maintain a list of available Echomail Conferences within the net as well as the requirements of each Conference area as supplied by the conference moderator (Echolist). The NEC shall also monitor compliance with this policy at a net level. 5. DUTIES OF ECHOLIST COORDINATOR: It is the duty of the Echolist Coordinator to compile and make available a listing of national and international Echomail conferences and optionally, conferences at various local levels. The content and format of the Echomail listing shall be at the sole discretion of the Echolist Coordinator, but shall include the conference name and moderator for each conference. The Echolist Coordinator shall also maintain a list of requirements applicable to each listed conference. 6. DUTIES OF ECHOMAIL CONFERENCE MODERATOR: It shall be the duty of the Echomail Conference Moderator to make in good faith every reasonable effort to insure that the moderated conference does not distribute or promote illegal activities or information as defined below in Section V Paragraph 2. The Moderator shall be responsible for insuring that messages contained in the conference corresponds to the conference theme. The Moderator shall report any violations of this policy to the proper Echomail coordinators and lodge any appropriate policy complaints as provided for in policy documents adopted by Fidonet. The Moderator shall post the conference rules in the conference at least once a month. The Moderator is to authorize the disconnection of the conference feed. Any Sysop the moderator believes is violating policy shall be reported to the offending node's nearest local echomail coordinator (may be a NEC, REC or in extreme situations a ZEC); and the moderator shall formally authorize the feed to the offending node to be severed. The conference moderator is the sole judge - subject to review only by the ZEC (or his delegates) if a complaint is filed by the banished party. The Moderator may request in direct written form (netmail) that the *ECs disconnect a node from the conference when that node refuses to follow the published conference rules after at least 3 warnings. Knowingly feeding a conference to a node that has been severed by the Moderator is considered a violation of this echomail policy and is subject to suspension. The length of this suspension will be determined by a joint decision of the conference moderator and the nearest local echo coordinator of the node illegally feeding the conference to the original offending node or point. Echo conference complaints from a Sysop should be filed at the net level (NEC) or if the complaining party is an independent node then with their REC. The NEC or REC receiving such a complaint must take action in accordance with the provisions of this echomail policy. For severe or chronic infractions the NEC, REC or ZEC may file a complaint under general Fidonet policy for excessively annoying behaviour. IV. APPOINTMENT AND ELECTION OF ECHOMAIL COORDINATORS AND MODERATORS. 1. GRANDFATHER CLAUSE: Those Zone, Regional, and Net Echomail Coordinators and Echomail Coordinators currently holding these positions as of the date of acceptance of this Echomail Policy shall continue to service in said capacity until resignation or replacement under this policy. 2. ELECTION OF ZONE ECHOMAIL COORDINATOR: The ZEC shall be elected as follows: a) upon resignation or replacement of the existing ZEC, the FidoNet Zone Coordinator (ZC) shall nominate at least five individuals to be voted upon. b) 10 days after the nominees are selected, an election shall be held. The ZEC will be elected by a simple majority of IC, ZC, RCs, NCs, RECs, and NECs in their Fidonet zone. An individual holding more than one position can only cast one vote. That is, if an individual is both a NC and a NEC, they may cast only one vote. 3. ELECTION OF REGIONAL ECHOMAIL COORDINATOR: The REC shall be elected as follows: a) upon resignation or replacement of an existing REC, the ZEC shall nominate at least 3 individuals for election. b) 10 days after the nominees are selected, an election shall be held. The REC will be elected by a simple majority of the RC, NCs and NECs in their FidoNet Region. An individual holding more than one position may only cast one vote. 4. NET ECHOMAIL COORDINATOR: The NEC shall be appointed by the FidoNet Net Coordinator (NC) or in such alternative manner as determined by the NC. If a NEC is not appointed within 30 days, the REC will appoint the NEC. 5. REMOVAL OF A *EC: A *EC may be removed from their position by a simple majority of those allowed to vote for their successor. For a NEC, the members of the Net may vote by simple majority to remove the NEC. The position directly above (in the *EC structure) will oversee the recall election in the same manner as prescribed for electing successors. A *EC may only be subject to recall for failure to properly carry out their duties described above, or if they are no longer a member of Fidonet. A promise of 'free' echomail delivery from another source is *not* considered an acceptable reason for recall. 6. RECOGNITION OF CONFERENCES: The *EC corresponding to the appropriate leve recognizes a conference at his level. Examples: The NEC recognizes a conference as local. The REC recognizes a conference to be regional. A ZEC recognizes a conference to be zonal. The IC recognizes a conference to be inter-zonal. 7. REMOVAL OF AN ECHOMAIL CONFERENCE MODERATOR: An Echomail Conference Moderator may be removed from their position by a three fourths (3/4) vote of the *EC structure voting. This vote must be carried out in a fair and decent manner while giving at least ten (10) days notice to the entire *EC structure of the upcoming vote. Notice mediums acceptable are: Netmail from the ZEC, usage of international postings in such conferences as COORD. Or in extreme instances, by REC to NEC written notification. An Echomail Conference Moderator may only be subject to recall for failure to properly carry out their duties described above or continued pre-meditated violation of this documents section V. Statement of Policies as seen below. Failing to perform the above duties of a conference moderator for a period of 3 or more months and/or failing to designate a proxy in his absence shall be in violation of this policy and be subject to recall. A vote may only be callable by the ZEC (or his delegate). This delegate should not be from the region or net of the affected conference moderator. Membership in Fidonet need not be a paramount issue, but is highly recommended. V. STATEMENT OF POLICIES 1. BASIC ECHOMAIL POLICY: The basic policy of Echomail is to promote communication in Echomail Conferences in a lawful, friendly manner consistent with the general principles of FidoNet. 2. PROHIBITION ON ILLEGAL ACTIVITIES: Any Node which knowingly distributes or allows to be entered into echomail conferences any messages containing or promoting illegal activities or information shall be deemed to have violated general FidoNet policy as being excessively annoying. 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. AUTOMATED CENSORSHIP: The use of Automated Censorship in the passing or distribution of echomail will be considered a violation of this policy and will not be tolerated. Disciplinary action will be as referred to in General Fidonet policy as being excessively annoying. An exception to this provision shall be the deletion and not censorship of messages by any Sysop which may lead to legal action against that Sysop. No echomail shall be modified in any manner which could potentially cause duplicates. 4. INTER-NETWORK CONFERENCES: Inter-Net conferences shall conform to general Fidonet policy as well as the provisions of this policy document in addition to any foreign network's provisions. 5. CHARGING FOR DISTRIBUTION: Any entity which makes a profit from the distribution (passing from system to system) of echomail shall be deemed to be excessively annoying and in violation of Fidonet policy subject to enforcement under existing Fidonet policy. Profit as defined in this paragraph is the charging for echomail distribution that exceeds actual cost to obtain and distribute the Echomail over a sustained period. The cost of the equipment used to obtain and distribute echomail may not be recovered. A Sysop that charges users for access to their BBS 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 and points shall be a violation of this echomail policy and result in suspension of the violated echo in accordance with the above paragraph in Section III Duties of the Echomail Conference Moderators. A SYSOP only conference shall be made available only to the Sysops or Co-Sysops of Fidonet or other nets with which inter-net conferences exist. 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 and specified the restrictions governing the conference. 7. PATH REQUIRED: The PATHline, originally implemented by SEA in the MGM package, is required except for terminal nodes. If your current Echomail scanner supports the pathline you must enable it NOW. If your current Echomail scanner does not support the pathline, and if there is no alternative scanner, then enforcement of this paragraph will be deferred for 60 days. After that date, the *ECs may refuse to accept/supply echomail to any node that is not supporting the pathline. 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 respective ZECs feel topology will allow their use. Nor will the stripping of SEEN-BYs (except Zone-Gates and Inter-Network EchoGates) be allowed unless approved by the ZEC. Violation of the above shall be excessively annoying behavior enforceable under general Fidonet policy. Zone-Gates and Inter- Network EchoGates SHOULD strip the SEEN-BYs of the exporting Zone or Network to reduce addressing conflicts. 9. COUNTERFEIT MESSAGES: Entering or knowingly distributing counterfeit messages shall be considered excessively annoying and a violation of Fidonet policy enforceable under the terms of Fidonet policy. As used in this paragraph, 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. 10. SYSOP'S RESPONSIBILITY: It is the responsibility of each Sysop to make every reasonable effort to assure that the users on his board conform to the provisions of this policy document. A Sysop may be held responsible for the acts of his users unless the Sysop can show that a reasonable attempt was made to conform to this policy document. 11. ECHOMAIL SOFTWARE: EchoMail exchanges may consist of any type of archival storage format agreed upon by both parties. SEA's ARC 5.1 (non-Squashing) archival storage format will be the "fallback" if either party is unable or unwilling to support an alternate method. The continued use of Echomail software without prior agreement of both the sending and receiving nodes which interferes with the distribution of echomail shall lead to disciplinary action as described previously in this document. See Section III. Examples of prohibited software would include the use of non-standard echomail packets which can not be processed by the receiving system. Another example would be the use of poorly implemented scanners or tossers that cause duplicates or fail to forward messages to downstream links. A further example is the use of Tiny seenby options and the use of ^A hidden SEEN-BY lines. Use of Echomail software which does not conform to the minimum acceptable standards as defined by the Fidonet Technical Standards Committee (FTSC) shall lead to disciplinary action as described previously in this document. The Software Certification Committee is authorized to determine whether software meets minimum standards for use on the net. 12. HOST ROUTING OF ECHOMAIL: Host routing of Echomail without the prior consent of both the Sending and Receiving Hosts shall lead to disciplinary action as described previously in this document. See Section III. 13. SENDING OF ECHOMAIL DURING ZONE MAIL HOUR: Transmission of echomail during Zone Mail Hour as defined in Fidonet policy without the consent of the receiving system shall lead to disciplinary action as described previously in this document. See Section III. 14. INTER-NETWORK CONFERENCES: It is the general policy of Fidonet to encourage the development of INTER-NETWORK CONFERENCES. It shall be the duty of those providing the INTER- NETWORK CONFERENCE links to remove foreign net distribution identifiers which will adversely effect the distribution of the Echomail Conference while in Fidonet. The INTER-NETWORK CONFERENCE links maintained in Fidonet shall be operated in a manner not to interfere with the foreign network's distribution of Echomail. 15. DEFAMATORY POSTING: The posting of any DEFAMATORY MESSAGE other than in conferences dedicated to this purpose (i.e. FLAME) shall lead to disciplinary action as described previously in this document. See Section III. The posting of substantiated facts shall not be considered a violation under this section. 16. ADDING OR REMOVING CONFERENCES FROM THE Backbone: A conference may be added to the Backbone only by request of the RECOGNIZED Conference Moderator. A conference may be removed from the Backbone by lack of traffic. A committee composed of the ZEC and 4 RECs shall review the status of backbone echos every 6 months. At which time those echos which have not maintained a minimum 10 messages a week over the preceeding 6 months will be noted and their Conference moderators will be contacted. These conferences will be given 3 months to improve their traffic or withdraw from Fidonet backbone distribution. The recognized conference moderator may request removal of their conference from the Fidonet backbone distribution at their discretion. 17. TOPOLOGY and DUPLICATE MESSAGES: Cross Regional links should be avoided as they increase the risk of improper linking and generation of duplicate messages. Cross Regional links may be established only with the permission of the REC in each region. Each REC will do their best to make available high speed hubs, out of state hubs, PC Pursuit hubs, etc, to facilitate the low cost, efficient movement of mail within their respective Region. If either REC has reason to believe duplicates are being introduced into the system, an existing Cross Regional link must be immediately cut pending resolution. Any Sysop who willfully and knowingly establishes links that either create duplicate loops (topology that creates circular feeds), increase the risk of such loops or who refuses to break those links upon request by their NEC, REC or ZEC shall be subject to disciplinary action as described previously in this document. See Section III. 18. MESSAGE STANDARDS: Until the adoption of a superceding standard by the Fidonet Technical Standards Committee, the following Echomail message standards will apply: a) Eight-bit characters (ASCII 128-255) and non-printing low-order codes (ASCII 2-31) are prohibited, except the use of 8Dh(soft <CR> 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) Origin lines are limited to 79 characters including the required ending of a proper network address (i.e. Zone:Net/Node.Point with zone and point being optional). c) Tear lines are limited to 35 characters including the required "--- " lead-in. These may 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. d) "Extra" origin lines (ZoneGating) are limited to essential information only. This consists of the required lead-in plus the network name "Gateway" and optionally the software ID followed by a Zone:Net/Node address. Example: " * Origin: FidoNet Gateway (TComm 88:372/666)" e) SEEN-BY addresses must be in sorted order. Multiple 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 should be followed. VI. ENFORCEMENT Enforcement of this policy document shall be under the provisions of General FidoNet policy. Complaints concerning Echomail violations defined under this policy may be filed by the aggrieved individual, the conference moderator or by any level of Echomail Coordinator. 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 Fidonet Policy, with a copy to the respective *EC. Enforcement is immediate, with any currently existing software allowed 60 days to conform (from the date EchoPol1 goes into effect). A 30-day extension 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 shall be deemed excessively annoying. VII. ADOPTION OF POLICY 1. ADOPTION: This policy shall become effective upon ratification by a simple majority of those voting. Those eligible to vote shall be the IC, ZCs, RCs, NCs, ZECs, RECs, and NECs. Those individuals holding more than one position can cast only one vote. 2. GRANDFATHER CLAUSE: Within 60 days of adoption of this policy, moderators shall be appointed for all existing Echomail Conferences which do not now have a moderator. Moderators shall be appointed by the ZEC from those volunteering as moderator or if no volunteer is available then the ZEC shall request and appoint a moderator for the conference. In the case where more than one individual claims to be the conference moderator and no agreement can be reached, the ZEC may order the conference retired and ban the further use of the specific conference name. Failure of the individuals to retire the conference name shall be deemed excessively annoying behavior. VI. 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 document. At the top of the Echomail distribution network, there are systems commonly called Stars. These systems are usually dedicated to passing Echomail. The stars operate at the discretion and direction of the ZEC. At the time of this writing there are 3 stars, each has a backup system/plan in the event of a failure. In general, the Stars link to one another and feed the RECs. The RECs are then responsible for distribution of the echomail within their Region. Normally, the REC will feed the NECs in that region. The NEC is responsible for distribution of Echomail to the individual Sysops within a net. Note that the RECs and NECs can appoint Hubs to help in the distribution of Echomail. That is, they do not have to directly feed the lower level. This is the distribution GOAL. Because of less expensive phone rates and other reasons, this distribution method is not followed exactly. Any change to the above requires agreement of the *EC's involved. All *ECs will use all the tools at their disposal, such as hubs, high speed modems, ROA, Wide Area Calling plans, PC Pursuit, corporate sponsorship, etc., to provide fast, efficient, and cost effective movement of echomail. Echopol Committee Mike Ratledge Norm Henke Rick McWilliams Barry Shatswell