F I D O N E W S -- Vol.10 No.12 (22-Mar-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...................................................... 3 === downLoad! === neurozine................................. 3 Policy 5 - Nice Try; but No Democracy Here.................. 4 NEW FidoNet Policy 5 DRAFT report!.......................... 8 Another view of Caller ID and BBS access.................... 39 Yet another Fidonet packet format proposal.................. 43 Caller ID and "The Right to Privacy"........................ 51 Original to: Zone 1 Sysops at 1:141/730.(Election results).. 52 3. Fidonews Information.......................................... 53 FidoNews 10-12 Page: 2 22 Mar 1993 ======================================================================== Editorial ======================================================================== We were up all night because the cat, Binkley, was gone, so we're writing quickly. i didn't know whether he had *decided* to go away, which would be more or less ok, or if he had been inadvertently shut outside during comings and goings of visitors, which would be worry-making. This morning, he is here, proud of whatever excursion he'd had. So-k. This week there's another caller-id article, and an anonymous refutation of a "policy five" proposal. i must apologize and confess i haven't read the "policy five" document end to end. It is VERY long. It might seem odd that the "policy five" document follows its refutation; that's because we print the articles in the order they're received . It's confusing that caller-id seems more of an issue than message content. Is the identity of a person talking more important than what gets said? Perhaps that is the real issue ... real names are useful for controlling discussion. Is preventing abuse of the medium more important than allowing unfettered expression? It has been stated in several articles that aliases are only required if the speaker has something to hide. What never gets explained is why having something to hide means that one has nothing useful to say? Much, including much of importance, would never be said at all without the protection from retribution afforded by privacy. There is also the other side of the coin. We have heard professional writers express a reluctance to publish electronicly because the potential for loss of control, and loss of copyright once things are on the net. Caller id could rectify some of that. The entire issue requires more thought and more balance. Simple polemic is not the answer. Fidonet started as a grand experiment. Experimentation requires anarchy ... too much rigour results in tunnel vision. Control and vitality can been seen as opposite ends of the spectrum. Quoting Mikael Cardell in the latest issue of "PRACTICAL ANARCHY: "the idea is, therefore, to publish the texts under copyleft instead of copy-right and allow copying. i mean, copying is the way these texts are distributed in the first place so there's no possibility to stop it". Editor's note: In keeping with this philosopy, the above is reprinted without permission. Editor's P.S.: The Zone 1 election results came in at the last moment, and are at the end of the issue. FidoNews 10-12 Page: 3 22 Mar 1993 ======================================================================== Articles ======================================================================== === downLoad! === neurozine === downLoad! === neurozine Call for contributions downLoad!, a completely non-profit co=operative 'zine for your neurons, is seeking contributions for our inaugral issue. Our goal is to get information that's available on the net out on paper so those here in Sydney who aren't hardwired in can access it. The general style of information we're looking for is ... well, intelligent, quirky, progressive, weird, strange, paranoid, oddball, serious, alternative, learned, left-wing, modern, frivilous, postmodern, critical, structuralist, sub-genius, anarchist, or irreverent. The subject matter? That's for you to decide, but examples of current articles include, an article about the unanswered questions of the Jonestown "suicide"; speculation on UFOs (the wierder the better here); virtual reality; CIA brainwashing techniques & MK Ultra, the nature of the networks we use, where their political power lies, what are the forces behind their development; raves and dance parties; education, television, and video games; pros and cons of smart drugs, "extasy", and other popular designer drugs; electronic media art; alternative culture on the net; and so on. Length: generally under 1000 words. You should also state whether you want your name credited, or whether we should use a handle of some form, and what this is. downLoad! will be released in a no copyright "ShareRight" form, that is, it can be freely reproduced unless for profit. We'll also accept stuff forwarded from netnews or echomail. Please email your contributions to: Scot Art 3:712/634@fidonet scot@asstdc.oz.au You can also leave mail by using your computer and modem to call System-X on +(61-2)361-4063. or send an IBM or Macintosh formatted disk with your contribution in plain ASCII text, Word for Windows, or Word 5 for the Mac to me via snail-mail: PO Box E253 FidoNews 10-12 Page: 4 22 Mar 1993 St. James NSW 2000 Australia And remember, "information wants to be free". ---------------------------------------------------------------------- Policy 5 - Nice Try; but No Democracy Here Since the NY-NJ crowd introduced a Policy proposal (version 4.1C), it seems that other people have jumped on the policy revision bandwagon. Another NJ sysop named Bob Germer submitted a document called Policy 5, and now we have another entry distributed by Christopher Baker, RC18, ALSO called Policy 5. How we're going to know which Policy 5 we're talking about should be interesting :) The point of this article is to make a comparison between 4.1C and the Policy 5 distributed by Baker. The FIRST Policy 5, (the Germer version), doesn't even merit discussion IMHO. The 4.1C proposal appears to very strong support in Zones around the world, and very little support in Zone 1. This is probably more due to the unpopularity of the authors of it with some Zone 1 coordinators, than the actual text of the document, or at least it would seem so. The Policy 5 distributed by Baker is brand new, and how it will fare around the world remains to be seen, although in this author's opinion, it probably won't get very far. So we don't get confused with which Policy 5 we're talking about, we'll refer to the one distributed by Baker as BAKERPOL. Comparison of BAKERPOL with Draft Policy 4.1C Quick Summary: BAKERPOL 4.1C NC,RC selection not specific, each net Democratic has its own method elections one sysop one vote. Term is No term two years (The 4.1C proposal requires that all coordinators up to and including Zone Coordinator be elected by majority vote of the SYSOPS of the area involved, and places a two year term of office on the successful candidate. BAKERPOL is not specific. It does not incorporate a term of office, and does not GUARANTEE the right of the sysops to vote. Nets, Regions and Zones can have wildly differing election methods and terms of office, IF any. BAKERPOL also does not REQUIRE elections.) FidoNews 10-12 Page: 5 22 Mar 1993 IC selection ZC's by absolute ZC's 2/3rds majority, else RC's if ZC's "unable to" (Policy 4.1C requires a 2/3 majority of the Zone Coordinators to elect an Internation Coordinator. BAKERPOL requires just a majority of the ZCs and give control of the election to the RCs if the ZCs can't seem to come up with a winner.) Replacement of By RC,ZC regardless 20% below can call NC,RC of sysops a sysop election. wishes. to replace, limited (This is an important contrast. The Policy 4.1C proposal gives SYSOPS the authority to recall or replace coordinators whom they feel are not performing. BAKERPOL on the other hand, gives unlimited authority to the RCs to replace an NC, and unlimited authority to the ZC to replace an RC. Under BAKERPOL, all 2000 sysops in a Region could object to the removal of their RC, yet the ZC would still have the authority to do so.) Local policies OK if "procedural" Can't contradict like coordinator policy 4.1, uniform. selection, excessively One network, one annoying is a local policy. definition (2.1.2) (This is another sore point. The 4.1C proposal keeps a unified Fidonet under one basic set of guidelines. It also provides for the implementation of local policies provided that they are not more RESTRICTIVE than 4.1C itself. BAKERPOL allows for local definition of what should be net-wide. Like what "excessively annoying" is.) Points Access can be refused no change from existing Excommunications Notice to next level no change from required existing Policy Ratification Can be selectively Whole document changed by section. must be presented (Fidonet has always adopted entire policy documents, not amendments by section. The reasons why are even stated in current policy. The 4.1C proposal doesn't change that. However, BAKERPOL would allow sections of policy to be amended, and has no provisions for preventing approval of an amendment that would clearly contradict another existing section. If this were to happen, we could end up with a totally ambiguous policy!) Policy Ratification RC's must approve NC's must approve to allow a vote to allow a vote (A significant change in 4.1C over current policy is that it moves the FidoNews 10-12 Page: 6 22 Mar 1993 level of approval of policy referendums DOWN a notch to the NC level. BAKERPOL still gives complete control over policy referendums to the RCs) Excessively examples, including no change Annoying defying a moderator (4.1C doesn't change the current definition of excessively annoying. The BAKERPOL proposal offers examples of what excessively annoying is, by talking about disrupting a conference after the moderator has ordered a link cut. However, the document doesn't define what a conference is, or what a moderator is or how he gets to BE a moderator, etc. The document uses echomail as a reference yet doesn't define it) Examples removed removed (Both documents have removed the case histories currently found in our current policy) Non-referenced three, a sample election none Appendix "procedure",FTSC and standard file names? (There are three appendices; 2, 4 and 5 in BAKERPOL that are referenced nowhere in the document. Appendix 5 talks about file naming conventions and looks like it came from the Binkleyterm manual. Appendix 2 gives a SAMPLE election procedure, and note that its a sample so it therefore isn't binding. And Appendix 3 talks about Fidonet Technical Standards. Again, these appendices are referenced NOWHERE in the policy itself!) echomail separated from NETMAIL just a flavor of links are consentual NETMAIL (Again, BAKERPOL gives echomail as an example, and doesn't define it. While No echomail policy can be recognized by Fidonet unless it is ratified in a manner similar to the way our current policy was ratified, it makes no sense at all to use echomail as an example when you don't define what it is or what its rules are or how its structured, etc.) Detail: Both version allows local procedures to be issued at every level as long as there is no contradiction, however 4.1c requires democratic elections, BAKERPOL allows any method. How local policy comes into existence is not specified in BAKERPOL, yet the *C structure is required to abide by it when judging "excessively annoying". What is excessive in net 1234 may not be excessive in net 6789. Multiple policies are unworkable. BAKERPOL is not specific as to elections however it gives a "sample procedure" whatever a sample procedure is good for. 4.1C requires a vote of the sysops and the terms of the *C's are set at two years. Under BAKERPOL the terms can vary at random. Imagine an RC with 30 nets each having random terms and procedures. Then FidoNews 10-12 Page: 7 22 Mar 1993 having to decide a controversy as to a "procedure" when 6 people, each claim a different procedure. The good ole boys network is still preserved at the ZC level. Only NC's and RC's vote. In BAKERPOL there is warm and fuzzy language asking the NC to poll the net. All in Zone one has witnessed the recent 4 month fiasco, selecting a ZC. Now, even if a net chooses an NC or RC, BAKERPOL allows the RC or ZC to replace the person. Granted it references the responsibilities in policy, but they can be interpreted. So the NC the sysops elect may be replaced without their consent. 4.1C requires a replacement election with 20% of those "below" and then the sysops vote. To protect against harassment, only two of these elections are allowed AND the replacement may not be replaced. How is policy changed. 4.1C lowers the vote threshold to the NC's and provided a 5% of the NC's may trip a referendum. BAKERPOL still allows the RC's 50% control. BAKERPOL has three appendices, which are not referenced in the policy. One on a sample election procedure ????? another on FTS standards and one on file names. They seem to be tacked on without any reference as to use. (ref: appendix 2,4 and 5). BAKERPOL also has a "sample" appeal process, but as a sample, its not binding. Overall summary: BAKERPOL introduces more uncertainty into Fidonet as there can be as many "policies" on a local level as there are nets+regions+zones and they may CONFLICT with each other. The is a reference to "elections" but no REQUIRED specifics and then the *C above can override the elected choice based on his/her opinion. There is no appeal process indicated for this. (What policy allows can never be annoying). Any small problems that BAKERPOL tries to solve will be offset by the generalities introduced. It seems that this document consolidates control at the RC level even more than our existing policy does. And by allowing multiple local policies which could conflict with each other, you'd find that the "Fidonet rules" are different in any given place; it can incite chaos. If democratic reform is what you're looking for, its not here. Elections aren't mandatory, and its perfectly OK to elect a coordinator who serves for life and the sysops have no recourse. No question that whoever wrote the Policy 5 that Chris Baker is promoting, put some work into it. But is more of the same what we really want? FidoNews 10-12 Page: 8 22 Mar 1993 NEW FidoNet Policy 5 DRAFT report! Christopher Baker Rights On! 1:374/14 Here's a REAL Policy 5 Proposal This article consists of the original Netmail message sent to all the ZCs, the IC, the Zone 1 RCs and others concerning a new DRAFT proposal for FidoNet Policy 5. It contains all the original text of that message and the entire text of the DRAFT. [The margins have been changed to accomodate FidoNews formatting and excess linefeeds have been removed to make it as small as possible.] The message was also cross-posted to the SYSOP, SYSOP18, Z1_ELECTION, and REGCON Echos for maximum distribution. The DRAFT is available as DRAFT-P5 from 1:374/98 and from 1:374/14 for those who don't want to chop it out of FidoNews. [grin] The editor and DRAFTScribe is Ken Tuley of 1:374/98. ALL comments and suggestions should be sent to him via Netmail or in one of the afore- mentioned Echos. Msg # 155 Kill/Sent, Direct, W/File, $0.18 Date: 14 Mar 93 17:35:36 From: Christopher Baker on 1:374/14 Rights On! in Titusville FL To: George Peace on 1:13/13 Backbone Collection in Bensalem PA Subj: \mail\policys\draft008.zip _______________________________________________________________________ CC: Matt Whelan, Ron Dwight, Gamey Garcia, Henk Wolsink CC: Honlin Lue, David Garrett, Mark Lynch, Fred Ennis CC: Bill Andrus, Tim Pearson, Marv Carson, D Dawson, Bob Satti CC: B Davis, John Souvestre, Dave James, Steve Cross, Carl Neal CC: Arthur Greenberg, Wes Cowley, Larry Squire, Bob Hirschfeld CC: Al&Linda Thompson, Mike Riddle, Bob Germer, Bob Moravsik CC: Rich Wood, Glen Johnson, Dan Buda, Ken Tuley [This Netmail msg will be cross-posted in several Regional and FidoNet- wide Echos for maximum effect and coverage. It may be further distributed by anyone who wishes to do so to anyone they wish to send it to without restrictions of any kind. It is not flagged Private nor intended to be any kind of 'backroom' process.] [This msg will also be sent to FidoNews as an article for next week's edition along with the DRAFT text.] [Coordinators are encouraged to forward this msg and the attached file to the Coordinators below them in FidoNet and in the Echomail Coordination structures. It has already been sent to all ZCs, Zone 1 RCs, the IC, and the Echomail Stars and ZEC1 and REC18 by direct Netmail from this system.] [Please Note: the word DRAFT is in caps intentionally. It is ONLY a DRAFT and should not be considered anything else at anytime.] Please find attached the DRAFT for a new FidoNet Policy version 5. FidoNews 10-12 Page: 9 22 Mar 1993 This DRAFT was developed and edited by Ken Tuley at 1:374/98 [NC374] with input from me [RC18] based on Policy4 and current FidoNet practices. It has been working for some time as you can tell from the version number. [grin] It addresses old and new concepts of FidoNet Policy and incorporates much of the daily operation now practiced within FidoNet. This DRAFT provides specific process and procedure that is lacking from the recently circulated policy drafts from Bob Germer and Wood/Johnson/Morasvik known as P5DRAFT and 4.1c, respectively. This DRAFT also provides a new Appendix section with samples of elections, Policy Complaint due process, FTSC Standards, standard magic filename conventions and updating of the Zone Mail Hour chart to include Zones 4, 5, & 6. This DRAFT organizes and stipulates much of what is common practice and provides structure for future changes lacking from other drafts. Since several people have asked in various Echos and in Netmail what kind of a Policy draft I would support, this is my answer. Please read it at your convenience and distribute it among your fellow Cs and/or contacts, as you please. It will always be available here as DRAFT-P5. Only the magic name will be supported since the version numbers will probably change as input comes in. [grin] Major thanks to Ken Tuley for taking the time and interest to develop this DRAFT and for accepting input and modifying it as we go along. All input should be sent to Ken at 1:374/98 for consideration and discussion. We can utilize several Echos for discussion such as SYSOP or any other ones appropriate to such discussion. I will apply to the Moderator of Z1_ELECTION for permission to use that Echo during the next election lull as well. He is cc:d on this send of the DRAFT and the msg. We await your responses. You may route Netmail thru me for Ken since he is a local call to me, if you wish, or you may use direct mail or standard routing. Thanks. TTFN. Chris grunt Sysop RC18 [in that order] [grin] p.s. Region Coordinators may also be interested in looking at the current Region 18 Policy DRAFT for future or current reference. It is FidoNews 10-12 Page: 10 22 Mar 1993 available as R18DRAFT from here and from Ken Tuley [1:374/98]. C. ----------------------------------------------------------------------- FidoNet Policy Document Version 5 Draft 008 03/12/93 1 Overview This document establishes the policy for sysops who are members of the FidoNet organization of electronic mail systems. FidoNet is defined by a NodeList issued weekly by the International Coordinator. Separate policy documents may be issued at the zone, region, or net level to provide additional detail on local procedures. Ordinarily, these lower-level policies may not contradict this policy, but will add procedural information specific to those areas, such as methods of coordinator selection. However, with the approval of the International Coordinator, local policy can be used to implement differences required due to local conditions. These local policies may not place additional restrictions on membership in FidoNet beyond those included in this document, other than enforcement of local mail periods. 1.0 Language To facilitate the largest possible readership, all international Fidonet documents will be written in English. Translation into other languages is encouraged. 1.1 Introduction FidoNet is an amateur electronic mail system. As such, all of its participants and operators are unpaid volunteers. From its early beginning as a few friends swapping messages back and forth (1984), it now (1993) includes over 20,000 systems on six continents. FidoNet is not a common carrier or a value-added service network and is a public network only in as much as the independent, constituent nodes may individually provide public access to the network through their systems. FidoNet is large enough that it would quickly fall apart of its own weight unless some sort of structure and control were imposed on it. Multi-net operation provides the structure. Decentralized management provides the control. This document describes the procedures which have been developed to manage the network. 1.2 Organization FidoNet systems are grouped on several levels, and administration is decentralized to correspond to these groupings. This overview provides a summary of the structure; specific duties of the coordinator FidoNews 10-12 Page: 11 22 Mar 1993 positions are given later in the document. 1.2.1 Individual Systems and System Operators The smallest subdivision of FidoNet is the individual system, corresponding to a single entry in the nodelist. The system operator (sysop) formulates a policy for running the board and dealing with users if the sysop provides access to others through that node. The sysop must mesh with the rest of the FidoNet system to send and receive mail, and the local policy must be consistent with other levels of FidoNet. BBS operation is not required to be a Fidonet sysop. 1.2.1.1 Users The sysop is responsible for the actions of any user when they affect the rest of FidoNet. (If a user is annoying, the sysop is annoying.) Any traffic entering FidoNet via a given node, if not from the sysop, is considered to be from a user and is the responsibility of the sysop. (See section 2.1.3.) 1.2.1.2 Points A point is a FidoNet-compatible system that is not in the nodelist, but communicates with FidoNet through a node referred to as a bossnode. A point is generally regarded in the same manner as a user, for example, the bossnode is responsible for mail from the point. (See section 2.1.3.) Points are addressed by using the bossnode's nodelist address; for example, a point system with a bossnode of 114/15 might be known as 114/15.12. Mail destined for the point is sent to the bossnode, which then routes it to the point. In supporting points, the bossnode may make use of a private net number which should not be generally visible outside of the bossnode-point relationship. Unfortunately, should the point call another system directly (to do a file request, for example), the private network number will appear as the caller's address. In this way, points are different from users, since they operate FidoNet-compatible mailers which are capable of contacting systems other than the bossnode. Outside the local bossnode, a point may be refused access to other Fidonet systems since points are considered users and sysops have full control over users' access to their systems. 1.2.2 Networks and Network Coordinators A network is a collection of nodes in a local geographic area, usually defined by an area of convenient telephone calling. Networks coordinate their mail activity to decrease cost. The Network Coordinator is responsible for maintaining the list of nodes for the network, and for forwarding netmail sent to members of the network from other FidoNet nodes. The Network Coordinator may make arrangements to handle outgoing netmail, but is not required to do so. The Network Coordinator is selected by the nodes of that net. Nets are encouraged to formulate policies regarding the mechanism for FidoNews 10-12 Page: 12 22 Mar 1993 accomplishing this. 1.2.2.1 Network Routing Hubs Network Routing Hubs exist only in some networks. They may be appointed by the Network Coordinator, in order to assist in the management of a large network. The exact duties and procedures are a matter for the Network Coordinator and local policy to arrange, and will not be discussed here, except that a network coordinator may not delegate responsibility to mediate disputes. 1.2.3 Regions and Regional Coordinators A region is a well-defined geographic area containing nodes which may or may not be combined into networks. A typical region will contain many nodes in networks, and a few independent nodes which are not a part of any network. The Regional Coordinator maintains the list of independent nodes in the region and accepts nodelist segments from the Network Coordinators in the region. These are compiled to create a regional nodelist, which is then sent to the Zone Coordinator. A Regional Coordinator does not perform message-forwarding services for any nodes in the region. The Regional Coordinator may participate in netmail routing between the coordinator levels, but is not required to do so. Regional Coordinators are selected by the nodes of that region. Regions are encouraged to formulate policies regarding the mechanism for accomplishing this. 1.2.4 Zones and Zone Coordinators A zone is a large geographic area containing many regions, covering one or more countries and/or continents. The Zone Coordinator compiles the nodelist segments from all of the regions in the zone, and creates the master nodelist and difference file, which is then distributed over FidoNet in the zone. A Zone Coordinator does not perform message-forwarding services for any nodes in the zone. The Zone Coordinator may participate in netmail routing among the coordinator levels, but is not required to do so. Zone Coordinators are selected by the Net and Regional Coordinators in that zone as representatives of the nodes to whom they provide service (see section 8.3). 1.2.5 Zone Coordinator Council In certain cases, the Zone Coordinators work as a council to provide advice to the International Coordinator. The arrangement is similar to that between a president and advisors. In particular, this council considers inter-zone issues. This includes, but is not limited to: working out the details of nodelist production, mediating inter-zone disputes, and such issues not addressed at a lower level of FidoNet. FidoNews 10-12 Page: 13 22 Mar 1993 1.2.6 International Coordinator The International Coordinator coordinates the joint production of the master nodelist by the Zone Coordinators. The International Coordinator acts as the chair of the Zone Coordinator Council and as the overseer of Fidonet-wide elections -- arranging the announcement of referenda, the collection and counting of the ballots, and announcing the results for those issues that affect FidoNet as a whole. The International Coordinator is selected by the Zone Coordinators. See section 7.2. 1.2.7 Top-down Organization. Checks and Balances. These levels act to distribute the administration and control of FidoNet to the lowest possible level, while still allowing for coordinated action over the entire mail system. Administration is made possible by operating in a top-down manner. That is, a person at any given level is responsible to the level above, and responsible for the level below. For example, a Regional Coordinator is responsible to the Zone Coordinator for anything that happens in the region. From the point of view of the Zone Coordinator, the Regional Coordinator is completely responsible for the smooth operation of the region. Likewise, from the point of view of the Regional Coordinator, the Network Coordinator is completely responsible for the smooth operation of the network. If a person at any level above sysop is unable to properly perform their duties, the coordinator at the next level may replace them. For example, a Regional Coordinator who fails to perform may be replaced by the Zone Coordinator. Interim replacements will be appointed until such time as a formal replacement can be selected under the local or regional policies. Such appointments will be considered final in the absence of such policies. To provide for checks and balances at the highest level of FidoNet, there is an exception to this top-down organization. The International Coordinator is selected by a majority vote of the coordinators of the Zone Coordinators (see section 7.2). Similarly, decisions made by the International Coordinator can be reversed by the Zone Coordinator Council. Decisions made by other coordinators are not subject to reversal by a vote of the lower level, but instead are subject to the appeal process described in section 9.5. 1.3 Definitions 1.3.1 FidoNews FidoNews is a weekly newsletter distributed in electronic form throughout the network. It is an important medium by which FidoNet sysops communicate with each other. FidoNews provides a sense of being a community of people with common interests. Accordingly, sysops and FidoNews 10-12 Page: 14 22 Mar 1993 users are encouraged to contribute to FidoNews. Contributions are submitted to the node listed in Fidonews and in the nodelist for that purpose; a file describing the format to be used is available from that and many other systems. 1.3.2 Geography Each level of FidoNet is geographically contained by the level immediately above it. A given geographic location is covered by one zone and one region within that zone, and is either in one network or not in a network. There are never two zones, two regions, or two networks which cover the same geographic area. If a node is in the area of a network, it should be listed in that network, not as an independent in the region. (The primary exception to this is a node receiving inordinate amounts of host-routed mail; see section 4.2). Network boundaries are based on calling areas as defined by the local telephone company. Even in the case of areas where node density is so great that more than one network is needed to serve one local calling area, a geographic guideline is used to decide which nodes belong to what network. Network membership is based on geographic or other purely technical rationale. It is not based on personal or social factors. There are cases in which the local calling areas lead to situations where logic dictates that a node physically in one FidoNet Region should be assigned to another. In those cases, with the agreement of the Regional Coordinators and Zone Coordinator involved, exemptions may be granted. Such exemptions are described in section 5.6. 1.3.3 Zone Mail Hour Zone Mail Hour (ZMH) is a defined time during which all nodes in a zone are required to be able to accept netmail. Each Fidonet zone defines a ZMH and publishes the time of its ZMH to all other Fidonet zones. See sections 2.1.8 and Appendix 1. 1.3.4 Nodelist The nodelist is a file updated weekly which contains the addresses of all recognized FidoNet nodes. This file is currently made available by the Zone Coordinator not later than Zone Mail Hour each Friday, and is available electronically for download or file request at no charge. To be included in the nodelist, a system must meet the requirements defined by this document. No other requirements may be imposed. Partial nodelists (single-zone, for example) may be made available at different levels in FidoNet. The full list as published by the International Coordinator is regarded as the official FidoNet nodelist, and is used in circumstances such as determination of eligibility for voting. All parts that make up the full nodelist are available on each Zone Coordinator's and each Regional Coordinator's system. 1.3.5 Excessively Annoying Behavior FidoNews 10-12 Page: 15 22 Mar 1993 There are references throughout this policy to "excessively annoying behavior", especially in section 9 (Resolution of Disputes). It is difficult to define this term, as it is based upon the judgement of the coordinator structure. Generally speaking, annoying behavior irritates, bothers, or causes harm to some other person. It is not necessary to break a law to be annoying. There is a distinction between excessively annoying behavior and (simply) annoying behavior. For example, there is a learning curve that each new sysop must climb, both in the technical issues of how to set up the software and the social issues of how to interact with FidoNet. It is a rare sysop who, at some point in this journey, does not manage to annoy others. Only when such behavior persists, after being pointed out to the sysop, does it becomes excessively annoying. This does not imply that it is not possible to be excessively annoying without repetition (for example, deliberate falsification of mail would likely be excessively annoying on the very first try), but simply illustrates that a certain amount of tolerance is extended. See section 9 for more information. 1.3.6 Commercial Use FidoNet is an amateur network. Participants spend their own time and money to make it work for the good of all the users. It is not appropriate for a commercial enterprise to take advantage of these volunteer efforts to further their own business interests. On the other hand, FidoNet provides a convenient and effective means for companies and users to exchange information, to the mutual benefit of all. Network Coordinators could be forced to subsidize commercial operations by forwarding host-routed netmail, and could even find themselves involved in a lawsuit if any guarantee was suggested for mail delivery. It is therefore FidoNet policy that commercial mail is not to be routed. "Commercial mail" includes mail which furthers specific business interests without being of benefit to the net as a whole. Examples include company-internal mail, inter-corporate mail, specific product inquiries (price quotes, for instance), orders and their follow-ups, and all other subjects specifically related to business. 2 Sysop Procedures 2.1 General 2.1.1 The Basics As the sysop of an individual node, you can generally do as you please, as long as you operate a mailer compatible with FTS-0001 specifications, observe mail events, are not excessively annoying to other nodes in FidoNet, and do not promote or participate in the distribution of pirated copyrighted software or other illegal behavior via FidoNet. 2.1.2 Familiarity with Policy FidoNews 10-12 Page: 16 22 Mar 1993 In order to understand the meaning of "excessively annoying", it is incumbent upon all sysops to occasionally re-read FidoNet policy. New sysops must familiarize themselves with this policy and any applicable local, regional or zone policies before requesting a node number. 2.1.3 Responsible for All Traffic Entering FidoNet Via the Node The sysop listed in the nodelist entry is responsible for all traffic entering FidoNet via that system. This includes (but is not limited to) traffic entered by users, points, and any other networks for which the system might act as a gateway. If a sysop allows "outside" messages to enter FidoNet via the system, the gateway system must be clearly identified by FidoNet node number as the point of origin of that message, and it must act as a gateway in the reverse direction. Should such traffic result in a violation of Policy, the sysop must rectify the situation as soon as notified. 2.1.4 Encryption and Review of Mail FidoNet is an amateur system. Our technology is such that the privacy of messages cannot be guaranteed. As a sysop, you have the right to review traffic flowing through your system, if for no other reason than to ensure that the system is not being used for illegal or commercial purposes. Encryption obviously makes this review impossible. Therefore, encrypted and/or commercial traffic that is routed without the express permission of all the links in the delivery path constitutes annoying behavior. See section 1.3.6 for a definition of commercial traffic. 2.1.5 No Alteration of Routed Mail You may not modify, other than as required for routing or other technical purposes, any message, netmail or echomail, passing through the system from one FidoNet node to another. If you are offended by the content of a message, the procedure described in section 2.1.7 must be used. 2.1.6 Private Netmail The word "private" should be used with great care, especially with users of a BBS. Some countries have laws which deal with "private mail", and it should be made clear that the word "private" does not imply that no person other than the recipient can read messages. Sysops who cannot provide this distinction should consider not offering users the option of "private mail". If a user sends a "private message", the user has no control over the number of intermediate systems through which that message is routed. A sysop who sends a message to another sysop can control this aspect by sending the message direct to the recipient's system, thus guaranteeing that only the recipient or another individual to whom that sysop has given authorization can read the message. Thus, a sysop may have different expectations than a casual user. 2.1.6.1 No Disclosure of in-transit mail FidoNews 10-12 Page: 17 22 Mar 1993 Disclosing or in any way using information contained in private netmail traffic not addressed to you or written by you is considered annoying behavior, unless the traffic has been released by the author or the recipient or is a part of a formal policy complaint. This does not apply to echomail which is by definition a broadcast medium, and where private mail is often used to keep a sysop-only area restricted. 2.1.6.2 Private mail addressed to you The issue of private mail which is addressed to you is more difficult than the in-transit question treated in the previous section. A common legal opinion holds that when you receive a message it becomes your property and you have a legal right to do with it what you wish. Your legal right does not excuse you from annoying others. In general, sensitive material should not be sent using FidoNet. This ideal is often compromised, as FidoNet is our primary mode of communication. In general, if the sender of a message specifically requests in the text of the message that the contents be kept confidential, release of the message into a public forum may be considered annoying. There are exceptions. If someone is saying one thing in public and saying the opposite in private mail, the recipient of the private mail should not be subjected to harassment simply because the sender requests that the message not be released. Judgement and common sense should be used in this area as in all other aspects of FidoNet behavior. 2.1.7 Not Routing Mail You are not required to route traffic if you have not agreed to do so. You are not obligated to route traffic for all if you route it for any, except as required of a Net Coordinator if you hold that position. Routing traffic through a node not obligated to perform routing without the permission of that node may be annoying behavior. This includes unsolicited echomail. If you do not forward a message when you previously agreed to perform such routing, the message must be returned to the sysop of the node at which it entered FidoNet with an explanation of why it was not forwarded. (It is not necessary to return messages which are addressed to a node which is not in the current nodelist.) Intentionally stopping an in-transit message without following this procedure constitutes annoying behavior. In the case of a failure to forward traffic due to a technical problem, it does not become annoying unless it persists after being pointed out to the sysop. 2.1.8 Exclusivity of Zone Mail Hour Zone Mail Hour is the heart of FidoNet, as this is when network mail is passed between systems. Any system which wishes to be a part of FidoNet must be able to receive mail during this time using the protocol defined in the current FidoNet Technical Standards Committee publication (FTS-0001 at this writing). It is permissible to have FidoNews 10-12 Page: 18 22 Mar 1993 greater capability (for example, to support additional protocols or extended mail hours), but the minimum requirement is FTS-0001 capability during this one hour of the day. This time is exclusively reserved for netmail. Many phone systems charge on a per-call basis, regardless of whether a connect, no connect, or busy signal is encountered. For this reason, any activity other than normal network mail processing that ties up a system during ZMH is considered annoying behavior. Echomail should not be transferred during ZMH. User (BBS) access to a system is prohibited during ZMH. File requests should not be honored during ZMH. A system which is a member of a local network may also be required to observe additional mail events, as defined by the Network Coordinator. Access restrictions during local network periods are left to the discretion of the Network Coordinator as defined in local policy. 2.1.9 Private Nodes The rare exception to ZMH compliance is private nodes. Persons requesting private nodes should be supported as points if possible. A private listing is justified when the system must interface with many others, such as an echomail distributor. In these cases, the exact manner and timing of mail delivery is arranged between the private node and other systems. Such an agreement between a private system and a hub is not binding on any replacement for that hub. A private node must be a part of a network (they cannot be independents in the region.) Private listings affect each member of FidoNet, since they take up space in everyone's nodelist. Private listings which are for the convenience of one sysop (at the expense of every other sysop in FidoNet) are a luxury which is no longer possible. Non-essential redundant listings (more than one listing for the same telephone number, except as mandated by FTSC standards) also fall into this category. Sysops requesting private or redundant listings must justify them with a statement explaining how they benefit the local net or FidoNet as a whole. The Network Coordinator or Regional Coordinator may review this statement at any time and listings which are not justified will be removed. 2.1.10 Observing Mail Events Failure to observe the proper mail events is grounds for any node to be dropped from FidoNet without notice (since notice is generally given by netmail). 2.1.11 Use of Current Nodelist Network mail systems generally operate unattended, and place calls at odd hours of the night. If a system tries to call an incorrect or out-of-date number, it could cause some poor citizen's phone to ring in the wee hours of the morning, much to the annoyance of innocent bystanders and civil authorities. For this reason, a sysop who sends mail is obligated to obtain and use the most recent edition of the nodelist as is practical. FidoNews 10-12 Page: 19 22 Mar 1993 2.1.12 Excommunication A system which has been dropped from the network is said to be excommunicated (i.e. denied communication). If you find that you have been excommunicated without warning, your coordinator was unable to contact you. You should rectify the problem