F I D O N E W S -- Vol.10 No.35 (30-Aug-1993) +----------------------------+-----------------------------------------+ | A newsletter of the | | | FidoNet BBS community | Published by: | | _ | | | / \ | "FidoNews" BBS | | /|oo \ | +1-519-570-4176 1:1/23 | | (_| /_) | | | _`@/_ \ _ | Editors: | | | | \ \\ | Sylvia Maxwell 1:221/194 | | | (*) | \ )) | Donald Tees 1:221/192 | | |__U__| / \// | Tim Pozar 1:125/555 | | _//|| _\ / | | | (_/(_|(____/ | | | (jm) | Newspapers should have no friends. | | | -- JOSEPH PULITZER | +----------------------------+-----------------------------------------+ | Submission address: editors 1:1/23 | +----------------------------------------------------------------------+ | Internet addresses: | | | | Sylvia -- max@exlibris.tdkcs.waterloo.on.ca | | Donald -- donald@exlibris.tdkcs.waterloo.on.ca | | Tim -- pozar@kumr.lns.com | | Both Don & Sylvia (submission address) | | editor@exlibris.tdkcs.waterloo.on.ca | +----------------------------------------------------------------------+ | For information, copyrights, article submissions, | | obtaining copies and other boring but important details, | | please refer to the end of this file. | +----------------------------------------------------------------------+ ======================================================================== Table of Contents ======================================================================== 1. Editorial..................................................... 2 2. Articles...................................................... 2 Zone 1 Echopol - Introduction to the new draft.............. 2 Zone 1 Backbone Echomail Policy - proposed Draft............ 3 The Church of Elvis......................................... 19 The Simulation & Gaming Echo, filling a gap................. 24 Standards? We don't need no steekin' Standard!............. 25 SEX -- HOW TO GET IT ON THE NET!............................ 26 "ZIP as FidoNet Standard Archiver".......................... 28 "Tired of People Misusing Policy? Use It Yourself!"........ 30 HST and ZYX Nodelist Flags.................................. 32 *** The RC 24 @FidoClassic is elected ***................... 32 This is Matt Giwer speaking................................. 49 CONTROLLING ECHO ACTIVITY................................... 51 ARJ, ZIP, et al stupidity................................... 53 NEWSLETTERS AND THE FIDONET................................. 53 3. Fidonews Information.......................................... 54 FidoNews 10-35 Page: 2 30 Aug 1993 ======================================================================== Editorial ======================================================================== You may notice a lack of articles about the holy war in this issue. We received SO many jousts and rebuttals, that we're not printing any of them. Thanks to all participants for providing an enjoyable spectacle. Personally, I could never figure out why someone would want to carry an echo moderated by someone they did not like. It is a bit like going to a party hosted by someone that you cannot stand, and then complaining because you did not enjoy yourself. Maybe they just go because they like to pick fights. Maybe they think that anything they do not like is a threat to them. Perhaps they are just control freaks. If an old hippy may offer some advice, hang out with people you like. It is more fun, and you will digest your food better. On another note, the week here has been spent converting a wretched old fence in one of Kitchener's seedier neighbourhoods (the one we live in), into an art gallery. It has been a bit of a revelation to this spectator. I have had wino's come up and give me poigniant speaches about the human condition, and police officers make cracks that were worthy of a nine-year-old smart-ass. Ten foot tall toughs have said how much they appreciated the work, while a seemingly harmless couple mistook an art reporter for an undercover police officer and rather violently grabbed his camera to arrest his picture taking. A small boy in a baseball cap stole one of the paintings. People are endlessly fascinating, and that, after all, is what Fidonet is all about. Anything that limits the eclecticism of the participants can only be for the worse. ======================================================================== Articles ======================================================================== Zone 1 Echopol - Introduction to the new draft ZONE 1 ECHOPOL - INTRODUCTION TO THE NEW DRAFT by Adrian Walker 1:153/752 Echopol Committee Chairman This Zone 1 Echomail Policy is an attempt to document the way the Zone 1 echomail backbone operates. The intent is to gain consistency in the decisions which are made, thereby helping to make the backbone as fair and smooth in operation as possible. It is not a rework of previous Echopol documents, but a completely new text. This is not a finished document. It is a draft of the best ideas of the Echopol Committee appointed in May 1993 by the Z1EC, and the results were then reviewed and amended by the 10 Z1 RECs in August. Detailed input has been received from FidoNews 10-35 Page: 3 30 Aug 1993 across the zone from sysops, moderators, coordinators, and hubs, and while we feel the last 3 months have yielded a very workable document, it now has to be tailored to reflect accurately the way Zone 1 sysops want their backbone echomail system to operate. The ZEC has agreed to the use of the Z1_ELECTION echo for discussion of this Echopol draft, and while it is planned that an RC review and final zone-wide voting will take place in October, this date is only a projection as long as there is a need for further public discussion. The nature of the final vote has been left open for a concensus to emerge from public sysop discussion. The options include a full vote of the thousands of Zone 1 sysops participating in backbone echomail, or a vote by the 375 Zone NECs on behalf of their Nets, or a vote by the 10 RECs on behalf of their regions, and a variety of other options. No doubt the mechanics of counting the vote will play a part in how the concensus is arrived at. The main thing now is to gather constructive ideas from everyone to make it a better document - one which provides the minimum level of restriction needed - to keep the echomail distribution running effectively - to give a balance between the needs and responsibilities of moderators, sysops, and echomail coordinators - and to provide the basis for fair decisions in handling problems relating to echomail. Let's make this a team effort. ---------------------------------------------------------------------- Zone 1 Backbone Echomail Policy - proposed Draft ZONE 1 BACKBONE ECHOMAIL POLICY - DRAFT by the Zone 1 Echopol Committee 1:153/752 This document is the second draft of a revised ECHOPOL prepared by the Zone 1 Echopol Committee, and reviewed by all Zone 1 RECs. 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) FidoNews 10-35 Page: 4 30 Aug 1993 2.3 Zone Echomail Hubs (ZHubs) 2.4 Region Echomail Hubs (RHubs) 2.5 Net Echomail Hubs (NHubs) 2.6 Conference Moderators (Moderators) 2.7 Nodelist Designations 3. ORGANIZATION 3.0 Backbone Echo lists 3.1 Autonomy of Regions and Nets 3.2 Guarantees 3.3 Echomail Coordinator Removal 3.4 Moderator recognition & authority 4. DISTRIBUTION SYSTEM 4.0 Participation 4.1 Charging for distribution 4.2 Restricted distribution 4.3 Cross-Net/Region feeds 4.4 Emergency backup planning 4.5 Advanced technology feeds 4.6 Security 5. CONTENT 5.0 Routing of echomail & Netmail 5.1 InterNetwork goals 5.2 Encryption 5.3 Routed files 6. SOFTWARE STANDARDS 6.0 Technical references 6.1 Monitoring responsibility 6.2 Message Size 7. DISPUTES 7.0 Use of judgement 7.1 Complaint settling 7.2 Wilful disregard 7.3 Sanctions 7.4 Removal of echoes for cause 7.5 Feed cuts 7.6 Moderator appeal committee 8. DEFINITIONS 8.0 Backbone 8.1 Backbone Echolist 8.2 CRP 8.3 Downlink 8.4 Echo 8.5 FidoNet Policy FidoNews 10-35 Page: 5 30 Aug 1993 8.6 Gateway 8.7 Illegal 8.8 International Echolist 8.9 Low and high ASCII characters 8.10 Routine Operating Information (R.O.I.) 8.11 Secure mail 8.12 Secure node 8.13 *EC --------------------------------------------------------- GENERAL ECHOMAIL POLICY 1. OVERVIEW 1.0 Basis of policy This Echomail Policy document (Echopol) has been drafted by the Echomail Coordinators to extend but not contradict FidoNet Policy as intended by Sections 1 and 9.9 of Policy 4. Should any part of this document be in disagreement with the FidoNet Policy current at the time of dispute, that policy shall take precedence. Terms used in this document are defined in Section 8. 1.1 Purpose of policy This document establishes the echomail policy for the FidoNet echomail Backbone (Zone 1). Its purpose is to define, standardize and provide guidance for decisions required in the operation of the Backbone echomail distribution system, 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. Its purpose is to promote communication in echomail conferences in a lawful, friendly manner consistent with the general principles of FidoNet. 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. Since FidoNet is an amateur network promoting communication, all messages entered onto any FidoNet Backbone echo are considered to be in the public domain unless the echo has been defined by the moderator as 'closed' or 'restricted'. 1.4 Amendments FidoNews 10-35 Page: 6 30 Aug 1993 Amendments to all or part of Echopol are ratified by a simple majority of Zone 1 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 published in FidoNews for comment Public discussion in Zone-wide echo for minimum of three weeks RECs review and recommend any changes to revised draft RCs review for impact on general policy and recommend any changes Final draft published in FidoNews Zone-wide vote by all to accept/reject revision Results published in FidoNews Where Echopol makes reference to a specific version of FidoNet Policy or to a specific paragraph within that document, if such version or paragraph number changes, the ZEC may without further approval or vote update Echopol to reflect the altered number provided that the original sense of the paragraph referred to has not significantly changed. To allow for timely modification of routine procedures, the ZEC may direct that a Zone 1 Backbone Routine Operating Information (R.O.I.) document be established. Drafting and modification of an R.O.I. document is subject only to approval by a majority vote of RECs. 2. APPOINTMENTS 2.0 Zone Echomail Coordinator (ZEC) The ZEC is responsible for coordination of echomail, routing, and schedules at the Zone level to ensure reliable and efficient availability of Backbone echoes while avoiding creation of duplicate messages. The ZEC is appointed by the ZC on the advice of the Zone 1 RECs and acts as Chairman of the council of RECs. The ZEC should be actively involved in hubbing echomail in order that he remain in touch with routine hubbing issues. 2.1 Region Echomail Coordinator (REC) An REC is responsible for coordination of 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 regardless of a Net's feed source. FidoNews 10-35 Page: 7 30 Aug 1993 An REC is appointed by that Region's RC on the advice of the regional NECs. An REC should be actively involved in hubbing echomail in order that he remain in touch with routine hubbing issues. 2.2 Net Echomail Coordinator (NEC) An NEC is responsible for coordination of 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 regardless of a node's feed source. An NEC is appointed by that Net's NC on the advice of the Net's sysops. An NEC should be actively involved in hubbing echomail in order that he remain in touch with routine hubbing issues. 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 carries such authority on policy matters as the REC may delegate. An RHub is appointed by the REC in accordance with regional echomail policy. 2.5 Net Echomail Hubs (NHubs) An NHub distributes echomail at the Net level, normally connects to an RHub, and provides connections to Net sysops as determined by the NEC for the Net. Each NHub carries Backbone echoes to the extent deemed appropriate by the NEC and carries such authority on policy matters as the NEC may FidoNews 10-35 Page: 8 30 Aug 1993 delegate. An NHub is appointed by the NEC in accordance with Net echomail policy. 2.6 Conference Moderators (Moderators) Moderators preside over echoes and are responsible to the ZEC for the smooth operation of their echoes. The duties and method of appointment of Moderators are defined in Section 3.4. 2.7 Nodelist Designations To prevent an unnecessary burden on the nodelist and to assist in identifying echomail coordinators, a separate entry for the ZEC, REC or NEC is not recommended. Echomail coordinators shall be identified by the UZEC, UREC, and UNEC user flags on the coordinator's personal node number entry. 3. ORGANIZATION 3.0 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.. 3.1 Autonomy of Regions and Nets 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. There is no attempt in this document to determine the distribution arrangements within individual Nets. Where policy in this document relates to Nets it is designed to protect the Backbone technically and to protect the sysop from unreasonable demands by his Net. 3.2 Guarantees While the Backbone attempts to provide the best service possible, it provides no guarantee of mail delivery. Messages which require sensitive or timely handling should not be sent through the Backbone. The receiving of Backbone echomail should in all cases be considered a privilege, not a right. 3.3 Echomail Coordinator Removal The ZEC shall be removed from his position by the ZC on the advice of a simple majority of the Zone 1 RECs. An REC shall be removed from his position by his RC on the advice of a simple majority of the FidoNews 10-35 Page: 9 30 Aug 1993 regional NECs. An NEC shall be removed from his position by his NC on the advice of a simple majority of the Net sysops. A ZHub may be removed from his position by the ZEC, an RHub may be removed from his position by his REC, and an NHub may be removed from his position by his NEC. The ZEC, an REC or an NEC may only be removed for failure to carry out his duties properly as described above, for continued violations of policy, for gross misconduct, or if he is no longer a member of FidoNet. With reasonable notice a ZHub, RHub or NHub appointment may be transferred to allow for development of Zone, Region or Net expertise in Hubbing. 3.4 Moderator recognition & authority The Backbone has no desire to interfere with the internal affairs of a Backbone conference as long as it does not disturb the operation of the Backbone, either technically, or through dispute. 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. When the Backbone places an echo on its distribution system, the moderator may maintain whatever private distribution or gating he wishes, provided that this does not adversely affect Backbone topology, or local CRPs. A Moderator need not be either a Sysop or a member of FidoNet but must be readily accessible via netmail through a FidoNet node number. A Moderator is recognized 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 define how the new Moderator is selected. c. Should a conference which originates inside of FidoNet be without a moderator for over thirty days, the ZEC may cause an interim Moderator to be appointed for a period of up to 12 months. If during that time the original Moderator does not return, the appointment shall become permanent. Where a person takes over official moderation of an echo without the previous moderator's approval, or in its absence without the ZEC's approval, such action will be deemed to be excessively annoying. 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 FidoNews 10-35 Page: 10 30 Aug 1993 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. e. designating a proxy if unable to perform duties for a period of more than 10 days. Moderators are encouraged to appoint Co-Moderators to assist them in their responsibilities and to stand in for them in their absence. f. authorizing that the feed to a Node be severed if the Moderator believes that the Node is violating an echo rule. Such a request will conform to the feed-cut policy of section 7.5 below. The ZEC shall remove an echo from the Backbone Echolist upon the request of the official moderator. 4. DISTRIBUTION SYSTEM 4.0 Participation All active 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 or Fidonet Policy. Submission by a node of a request for echomail to its NEC, or voluntary payment of a cost-recovery plan contribution does not automatically require that the NEC approve such a feed. Such approval will normally be given except where the node has not provided requested system data or has not met the requirements of a CRP. A node should allow at least two weeks for a feed request to be processed. 4.1 Charging for distribution Cost recovery plans (CRPs) shall be limited to recovering the true cost of collecting/delivering echomail and may include a reasonable amount for contingencies. The Net membership and any other nodes or Nets which contribute to a CRP shall have the right to reliable public reporting of the cost recovery balances at reasonable time intervals, but should not expect formal auditing procedures. The administrators of a CRP at their option may prohibit any node which obtains a feed from their distribution system from sub-feeding a node outside that CRP, but must not require that a node obtain its echomail only through that CRP. 4.2 Restricted distribution FidoNews 10-35 Page: 11 30 Aug 1993 If an echo is designated as restricted distribution, no node may feed that echo to any node not clearly on the distribution list without specific permission from the moderator of that echo. 4.3 Cross-Net/Region feeds In general the only inter-Region links are between ZHubs and RHubs. Experience has shown that the ZHub/RHub/NHub structure minimizes technical problems associated with circular feeds and promotes minimum cost to participating systems. A node or a Net is expected to obtain any desired Backbone echomail feed from the appropriate NHub or RHub respectively. Cross-Net or cross-regional feeds are discouraged due to the known potential for unrecorded sub-feeds to occur, but may be approved where the cost to a node is significantly reduced or where the node can obtain Backbone echomail not available in its Net, in which case the following criteria will be applied: a. the node or Net must not be attempting to bypass a reasonable Net or Region cost recovery plan. b. for nodes, if the feed is out-of-Net, the NECs of all involved Nets must approve or disapprove the link based on its technical merits. c. for nodes or Nets, if the feed is out-of-Region, the RECs of all involved Regions must also approve or disapprove the link based on its technical merits. d. any cross-Net or cross-Region echomail feed must dead-end, in the case of a node on the node's system, and in the case of a Net within that Net (ie, no further re-distribution). 4.4 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. 4.5 Advanced technology feeds The use of advanced technology (eg: satellite feeds) which substantially alters the distribution or cost of Backbone echomail feeds will be subject to prior coordination with the appropriate NECs and RECs of the nodes involved. This provision is not intended to restrict the implementation of new technology but rather to ensure that unforeseen distribution methods are adequately examined for their implications prior to use. FidoNews 10-35 Page: 12 30 Aug 1993 In general, any legal form of distribution technology which lowers costs, and improves speed of communication, while avoiding circular feeds which cause duplicate messages, will be encouraged. Details for handling specific types of distribution methods will be specified in R.O.I. 4.6 Security To prevent deliberate disruption of echoes by various forms of mail dumping, each ZHub, RHub and NHub must operate in a secure manner so 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. 5. CONTENT 5.0 Routing of echomail & netmail Due to the costs involved echomail is not normally routed. Routing of echomail without prior agreement between all nodes involved in the routing is considered annoying. The Backbone accepts and delivers Echomail Routed netmail (ERN) at all levels above the Net level, and all Region and Zone Hubs agree to support such routing. It is understood that some Nets may choose not to include outgoing netmail with their echomail transfers, but in such cases the Net should make arrangements for disposition of incoming ERN from the appropriate RHub. 5.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. 5.2 Encryption The language of FidoNet is English, and all Backbone echomail traffic must be in this language unless the echo moderator specifies otherwise. FidoNews 10-35 Page: 13 30 Aug 1993 All Backbone echomail and Backbone-routed netmail messages must be in human-readable language. None of the text may be encoded, encrypted, enciphered or otherwise rendered unreadable; it must be possible for all sysops through whose systems the messages are routed to read each message or part thereof without having to use any form of special program or treatment. The use of high or low ASCII characters is not permitted in the header, tearline, or origin line of a message. Echo moderators may permit high or low ASCII characters in the body of the message only if they have so indicated in the International Echolist. Moderators may also approve the inclusion of small segments of code and/or of uuencoded (or equivalent) text, but are subject to Backbone judgement as to when these segments become excessive and are limited by the section in this policy on routed files. 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. 5.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. For the above reason uuencoded or similar message-format files are considered to be routed files and are therefore treated as described above. Short pieces of programming code, no longer than a typical message and infrequently sent, may be routed subject to any restrictions provided by individual echo rules. 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.. 6. SOFTWARE STANDARDS 6.0 Technical references Current technical standards for Backbone echomail and routed netmail are detailed in R.O.I.. When handling Backbone echomail the use of echomail software which does not conform to the above standard is considered annoying. 6.1 Monitoring responsibility To reduce costs and system malfunctions for sysops participating in FidoNews 10-35 Page: 14 30 Aug 1993 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. 6.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. 7. DISPUTES 7.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, FidoNet Policy, precedent and his own good judgement to resolve a dispute. 7.1 Complaint settling Complaints referred to in this section (7) 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 must 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. 7.2 Wilful disregard A person who engages in disruptive behaviour such as posting multiple copies of identical messages or flooding an echo with messages to render communication difficult or to increase costs will be considered excessively annoying. A person who alters quoted extracts in an echomail message so as to misrepresent the original author's text will be considered annoying. 7.3 Sanctions FidoNews 10-35 Page: 15 30 Aug 1993 The only sanction which may be applied to a node 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. Any situation which is believed to warrant stronger action such as a node being considered 'excessively annoying' will be referred to the *C chain for a decision. The only sanctions which may be applied to users by a Backbone echo moderator for contravention of the echo's rules are requests for apology, restrictions of echo privileges, or feed cuts. Any other sanction applied by a moderator may be grounds for removal of the echo from the Backbone, as detailed in section 7.4 c.. 7.4 Removal of echoes for cause An echo may be removed from Backbone distribution by the ZEC in the following cases: a. inadequate traffic or distribution. b. carriage of commercial or illegal content. c. unwillingness of the moderator to abide by Echopol. d. inability of the moderator to accept or respond to netmail. e. moderator behaviour judged excessively annoying. 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.5 Feed cuts To ensure fairness to both the Moderator and the users of an echo, where 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 with a copy to the Sysop's NEC directing that the user's access to the echo be severed. This netmail will include: a. instructions to cut the access for a specific user. b. copy of the echo rules section which was violated. c. copy of the user's message(s) which constituted the initial violation. d. copy of the Moderator's subsequent warning to the user not to repeat the violation. e. copy of the user's repeat violation. Where the violation is of sufficient seriousness to warrant no warning, provisions d. and e. above may be disregarded. This should be an unusual occurrence. Provided that all of this evidence is attached the Sysop will FidoNews 10-35 Page: 16 30 Aug 1993 immediately and without question terminate the user's access as directed. If he/she fails to do so the NEC will terminate the Sysop's feed of the echo. If the NEC fails to terminate the sysop's feed the REC will terminate the NHub's feed. If the REC fails to terminate the NHub's feed the ZEC will terminate the RHub's feed. Knowingly feeding an echo to a Node whose feed has been cut for violations of this policy or at the request of the Moderator, is considered annoying. Appeals of feed-cut instructions which contain the above evidence may be made only after the feed-cut has been honoured. 7.6 Moderator appeal committee The ZEC may appoint and act as Chairman of a Moderator Appeal Committee which hears complaints or appeals from users, moderators and coordinators relating to the moderation of Backbone echoes. The committee's members may include moderators and coordinators. Current membership will be detailed in R.O.I.. The committee may make recommendations to the ZEC for resolution of disputes concerning: a. sysops or users removed from echoes by moderators. b. NHubs removed from echoes by RECs. c. RHubs removed from echoes by the ZEC. d. echoes removed from Backbone distribution for reasons other than low traffic or demand. The committee may only make recommendations with respect to appeals brought before it. It should not originate policy for moderators or coordinators. The committee's recommendation for resolution of each issue will normally be accepted by the ZEC. Since the Backbone attaches its name, distribution system, and funding arrangements to Backbone echoes, if the moderator of an echo involved in such a dispute disagrees with the ZEC's decision, the ZEC may recommend removal of such an echo from the Backbone in accordance with Section 7.4. This will allow the moderator the freedom to operate the echo without further reference to this policy. 8. DEFINITIONS 8.0 Backbone The Backbone echomail distribution system (the 'Backbone'), to which this policy applies, incorporates all Zone, regional and Net level distribution as well as inter-regional and inter-Net links of Backbone echomail. The distribution system includes Backbone coordinators, echomail conferences, conference moderators, and distribution FidoNews 10-35 Page: 17 30 Aug 1993 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 non-profit cost-sharing arrangement agreed to by nodes directly participating in an echomail delivery arrangement in which phone and other direct costs of importing and distributing echomail are shared by all 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 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 International Echolist The International Echolist is an informal, international listing of Echomail conferences as described and submitted by each conference's FidoNews 10-35 Page: 18 30 Aug 1993 moderator. It contains descriptions and other data for all Backbone and many non-Backbone echoes. 8.9 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.10 Routine Operating Information (R.O.I.) 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.11 Secure mail Secure mail is considered to be mail (netmail or echomail) received from nodes with which distribution arrangements have been pre-arranged, thereby providing greater assurance that the sender has authorized access to Backbone echomail areas or other services. 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' refers to the Zone 1 ZEC, RECs, and NECs. It does not refer to any Hub or to any 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 Dave James 209/209 ---ooo000ooo--- FidoNews 10-35 Page: 19 30 Aug 1993 The Church of Elvis --=== THE CHURCH OF ELVIS ===-- Preface and Preamble: "If there is any fixed star in our constitutional constellation, it is that NO official, high or petty, can prescribe what shall be orthodox in politics, nationalism, religion or other matters of opinion or force citizens to confess by word or act their faith therein. If there ARE any circumstances which permit an exception, they do not now occur to us." Ref: U.S.Supreme Court (1943) West Virginia State Board of Education v. Barnette, 319 US 624. XXXXXXXXXXXXXXXXXXXXX "XXXXXXXXXXXXXXXXXXXXXXXXXV,,. "/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX", ,"XXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXX", ,"XXXX// /X/ //////XXXXXXXXXXX", ,"XXXXXXX XXXX XXXX XXXXXXXXXXXXXXXXXXX"", XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX", XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX", /XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXV, /"XXXXXXXXXXX X X XXXXX XX XX XXXXXXXXXXXXXV, /"XXX X X X XXX X X XXX X XX XXXXXXXXXXXXXXXV, /"XXX X X X XXX X XX X XX XXXXX XXXXXXXXXXXXXXXV, /"XXX XX XX XXXX XXXX XX XX XXXX XXXXXXXXXXXXXXXXV, /,XXXX XX X XX X X X XXX XX XXXXX XXXXXXXXXXXXXXXXXV, //XXX XXX X XXXX XX X XX X XXXXXXXXXXXXXXXXXXV, //XXX XXX X XXXXX XX XXXX XXXXXXXXXXXXXXXXXV, /XX XXX X XXXXXX XX XXXX XXXXXXXXXXXXXXXXV /XX XXXXX XXX X XXXX XXXXXXXXXXXXXXXXV /XX XXXXX XXX XXX XXXXXXXXXXXXXV, //XX XXXXX XX XX XXXXXXXXXXXXXV, //XX XXXX XX X XXXXXXXXXXXXV, //X XXX X XXXXXXXXXXXXXV /X XX XXXXXXXXXXXXV /X ,,,,,XXXXXXX,, XXXXXXXXXXXV /XXXXXXXXXX, "XXXXXXXXXXXXXXXX XXXXXXXXXXXV /X" "" "" XXXXX XXV H ,""""""""",, ,"""""""""",, XXXX XXX " "" """ / "" "" XXXX / XX " " // XXX // XX " // XXX / XX " // /XXX / XX " // /XXX XX " /// /XXX / XXX " /// ,, /XXXXXXXXX " // / /XXXXXXXXXX " """ "" /XXXXXXXXX/ " ", ,,,, ,,,, , FidoNews 10-35 Page: 20 30 Aug 1993 " ""IIII IIIIIIII"", // / / " " """""""""""" " // / " " , ," // / // " " "IIIWWIII" // // / / / ", " """" /// / / / / / ", // " //// // / / // " // " //// / / // / "", // / ", "// / / / // " // / ", ////// / // // " // / ", // // // // """ // / "" " " ""/// / // " " // // "" "" "/ / / // " // ", ","", "," / // // "" ELVIS thinks you're NEAT! %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%% %%% %%% U N I V E R S A L L I F E C H U R C H %%% %%% International Headquarters * Modesto California %%% %%% %%% %%% %%% %%% It is hereby declared that ELVIS ARON PRESLEY %%% %%% %%% %%% has been named S A I N T of the %%% %%% %%% %%% Universal Life Church this day of November 8, 1988 %%% %%% %%% %%% %%% %%% U L C %%% %%% S E A L Signed: Kirby J. Hensley, D.D. %%% %%% I H Q President %%% %%% %%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Upon duly submitted and approved petition to the International Headquarters of the Universal Life Church, Inc., Elvis Aron Presley was named Saint of the Universal Life Church in November, 1988. The petition to the church read as follows: Elvis exhibited faith and hope when, as a youngster, he pursued his talent as an entertainer despite the odds against rising from his humble beginnings. He exhibited charity by his obvious and documented generosity. All of these attributes of character are believed to have been present to an extraordinary degree by his followers. ***************************************************************** ECCLESIASTICAL PROCLAMATION WHEREAS the beliefs on matters of death and resurrection are FidoNews 10-35 Page: 21 30 Aug 1993 especially promulgated during the weekend of the First Sunday after the first full moon after the Verna