FidoNet Guidelines Document Version 1.00 March 11, 2000 This document is offered to Fidonet sysops as a set of guidelines. It is hoped that sysops will find at least some of the guidelines here useful and it is also hoped that sysops will contribute to the contents of this document in such a manner as to make this document useful to as many as possible. It is also hoped that this document in some way represents the spirit of Fidonet's free and open communications heritage and the helpful nature of Fidonet's members. The purpose of this document is not to force any sysop to conform to anyone's preconceived ideas of how Fidonet must be run, including those of policies, past and present. Rather, the purpose of this document is to provide information and to offer suggestions for resolution of everyday problems and to serve as a set of guidelines for everyday operations. TABLE OF CONTENTS 1.0 GENERAL INFORMATION 1.1 Commercial Use 1.2 Language 1.3 Time Considerations 1.4 Geography 1.5 The Internet 2.0 THE NODELIST 2.1 Availability 2.2 Use of Current Nodelist 3.0 FEATURES 3.1 FidoNews 3.2 Mail 3.2.1 Netmail 3.2.1.1 Private Netmail 3.2.2 No Disclosure or alteration of in-transit mail 3.2.3. Private mail addressed to you 3.3 Echomail 3.4 Mail Routing 4.0 MEMBERS 4.1 Sysops 4.1.1 Resolution of Disputes 4.1.1.1 Excessively Annoying Behavior 4.2 Coordinators 4.2.1 International Coordinator 4.2.2 Zone Coordinator 4.2.3 Regional Coordinator 4.2.4 Network Coordinator 4.3 Elections 5.0 NODES, NETS, REGIONS, ZONES 5.1 How to join Fidonet 5.2 How to obtain a node number 5.3 If You are Going Down 5.4 Nets and Network Coordinators 5.4.1 How to Form a Net 5.5 Regions and Regional Coordinators 5.6 Zones and Zone Coordinators 6.0 APPENDICES 6.1 Credits, acknowledgments, etc. 1.0 GENERAL INFORMATION FidoNet is an amateur electronic mail system. As such, all of its participants and operators are unpaid volunteers. 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 on their system. 1.1 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. 1.2 Language Fidonet was created in the United States of America and the common language of Fidonet is English. However, Fidonet does not restrict membership based on language and it is hoped that this and all documents related to Fidonet will be translated into as many languages as possible. 1.3 Time Considerations Fidonet does not observe daylight savings time. 1.4 Geography Things have certainly changed from the early days of Fidonet. We now exist in an ever-closer world influenced by things such as the Internet and ever decreasing costs of communication in some parts of the world. POTS (Plain Old Telephone System) is now only one method of connectivity for Fidonet sysops, however, that is certainly not the case everywhere. Therefore it is preferable for sysops with POTS capability to be listed in a local net if possible. This need not apply to Internet-Only Nodes (ION) as their means of connectivity is not as dependant on geography as POTS nodes are. 1.5 The Internet The Internet continues to have an ever-increasing impact on Fidonet. Sysops now transfer large volumes of mail via the Internet. We have nodes that exist as Internet Only Nodes and we have systems that are completely set up on the Internet complete with Telnettable BBSs, Web-based systems, etc. A search of the World Wide Web will produce many Fidonet systems, and mail, nodelists, nodelist segments, Fidonet-related files such as the FidoNews, Fidonet utilities, and Fidonet programs all can be found on the Internet. There are now even BBS Web-rings. An indepth discussion of Internet programs and protocols are beyond the scope of this document however some of these methods will be mentioned from time to time such as Email, FTP, Telnet, Vmodem, BinkD, Irex, TransX, etc. 2.0 THE NODELIST A NodeList issued weekly by the International Coordinator defines FidoNet. 2.1 Availability The nodelist is a file updated weekly which contains the addresses of all FidoNet nodes. This file is available electronically for download or file request from most systems and from many Internet sites via FTP. Partial nodelists (single-zone, for example) may also be made available. All parts that make up the full nodelist are available on each Zone Coordinator's and each Regional Coordinator's system. 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. 2.2 Use of Current Nodelist Fidonet systems generally operate unattended, and in the case of POTS systems may place calls at odd hours of the night. If a system tries to dial 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 by POTS means is obligated to obtain and use the most recent edition of the nodelist as is practical. 3.0 FEATURES 3.1 FidoNews FidoNews is a weekly newsletter distributed throughout Fidonet. 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 users are encouraged to contribute to FidoNews. Contributions are submitted to the FidoNews editor and a file describing the format to be used is available from the editor and many other systems. 3.2 Mail 3.2.1 Netmail 3.2.1.1 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. 3.2.2 No Disclosure or alteration of in-transit mail Disclosing, altering, 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. 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. 3.2.3. 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. 3.3 Echomail Echomail is an important and powerful force in Fidonet and is essential for our long-term survival. Sysops that want a feed for echomail can apply to an ever increasing number of sources both POTS and via the Internet. Some echomail feeds are free, some are not, but availability is not generally a problem. More information about echomail can be found in documents/files such as the nodelist, routelst, elist, ftsc, backbone or fidonews as well as from other sysops. 3.4 Mail Routing 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. 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 should 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 that are addressed to a node that 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. 4.0 MEMBERS 4.1 Sysops As the sysop of an individual node, you can generally do as you please, as long as you 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. As a sysop you are generally responsible for all traffic entering your system and in turn entering Fidonet. Sysops are sysops, whether they be ccordinators, Fidonews editors, mail movers, etc. For instance, one sysop equals one vote. No one voice is greater or less than another. No one sysop has authority over another. We are all in this together working for the betterment and enjoyment of our hobby. 4.1.1 Resolution of Disputes The FidoNet judicial philosophy can be summed up in two rules: 1) Thou shalt not excessively annoy others. 2) Thou shalt not be too easily annoyed. In other words, there are no hard and fast rules of conduct, but reasonably polite behavior is expected. The first step in any dispute between sysops is for the sysops to attempt to communicate directly, at least by netmail or email, and preferably by voice. If this results in no resolution to the dispute, the next step is to talk it over with your peers, the fellow sysops of your net, and make a decision as to how to settle the dispute. For example, in an extreme case of excessively annoying behaviour due to software piracy, a vote may be taken and in the case of an excessively annoying sysop, that sysop may be asked to leave the net and the Net Coordinator instructed to remove the excessively annoying sysop from the net's nodelist segment. Such a sysop would of course be free to join another net provided that net will have them. In this way, sysops of a net are free to protect themselves from the harmful behaviour of a sysop in a timely manner. 4.1.1.1 Excessively Annoying Behavior Generally speaking, annoying behavior irritates, bothers, or causes harm to some other person. 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. 4.2 Coordinators 4.2.1 International Coordinator The International Coordinator (IC) issues the weekly NodeList. The International Coordinator has the primary task of coordinating the creation of the master nodelist by managing the distribution between the Zones of the Zone nodelists. The International Coordinator is responsible for definition of new zones and for negotiation of agreements for communication with other networks. ("Other network" in this context means other networks with which FidoNet communicates as peer-to-peer, not "network" in the sense of the FidoNet organizational level (Net)). The International Coordinator is also responsible for coordinating the distribution of FidoNews to the Zone Coordinators. The International Coordinator is elected by a vote of the sysops. The sysops may choose to delegate voting privileges to a third party to aid in the efficient and timely processing of the election. 4.2.2 Zone Coordinator A Zone Coordinator for FidoNet has the primary task of maintaining the nodelist for the Zone, sharing it with the other Zone Coordinators, and ensuring the distribution of the master nodelist (or difference file) to the Regions in the Zone. The Zone Coordinator is also responsible for coordinating the distribution of FidoNews to the Regional Coordinators in the zone. The Zone Coordinator is responsible for the maintenance of the nodelist for the administrative region. The Administrative Region has the same number as the zone, and consists of nodes assigned for administrative purposes not related to the sending and receiving of normal network mail. The Zone Coordinator is elected by a vote of the sysops within the zone. The sysops may choose to delegate voting privileges to a third party to aid in the efficient processing of an election. 4.2.3 Regional Coordinator A Regional Coordinator has the following responsibilities: 1) To assign node numbers to independent nodes in the region. 2) To assign Net numbers to Nets in the region. 3) To compile a nodelist of all of the Nets and independents in the region, and to send a copy of it to the Zone Coordinator whenever it changes. The RC should receive the nodelists from the Net Coordinators within the region. The RC will need to maintain a set of nodelists for each Net within the region, since the RC cannot count on getting an update from each Net Coordinator every week, the RC should assemble a master nodelist for the region every week and send it to the Zone Coordinator by the day and time designated. It is suggested that the RC do this as late as practical, so as to accommodate late changes, balanced with the risk of missing the connection with the Zone Coordinator and thus losing a week. 4) To make new nodelist difference files (nodediff), and issues of FidoNews available to the Net Coordinators in the region as soon as is practical. The nodelist is posted weekly on Saturday by the Zone Coordinator, and FidoNews is published weekly on Monday by the editor. It is the RC's responsibility to make these available to all Net Coordinators in the region as soon as is practical after receiving them. The method of distribution is left to the RC's discretion. The RC is not required to distribute them to any independent nodes in your region. The RC is encouraged to make all these documents available for downloading by the general public. The Regional Coordinator is elected by a vote of the sysops within the Region. The sysops may choose to delegate voting privileges to a third party to aid in the efficient processing of an election, although regions are sufficiently small in numbers that this is not generally required nor desirable. Whenever possible, sysops themselves should have the opportunity to elect their RC in a timely manner within a reasonable term frequency. RCs generally are elected every year or two. 4.2.4 Net Coordinator A Net Coordinator has the following responsibilities: 1) To assign node numbers to nodes in the Net. The NC may also change the numbers of existing nodes in the Net, though the NC should check with the member nodes before doing so. The NC may assign any numbers desired, so long as each node has a unique number within the Net. 2) To maintain the nodelist for the Net, and to send a copy of it to the Regional Coordinator whenever it changes. The NC should implement name changes, phone number changes, and so forth in the segment of the nodelist as soon as possible after the information is received. The NC may distribute a portion of this workload to routing hubs. In this case, the NC should receive the nodelists from the Hub Coordinators within the Net. The NC will need to maintain a set of nodelists for each hub within the Net, since the NC cannot count on getting an update from each Hub Coordinator every week. The NC should assemble a master nodelist for the Net every week and send it to the Regional Coordinator by the day and time designated. It is suggested that this be done as late as is practical, so as to accommodate any late changes, balanced with the risk of missing the connection with the Regional Coordinator and thus losing a week. 3) Making Available Nodelists and FidoNews The Net Coordinator should obtain a new issue of FidoNews and a new nodelist difference file every week from the Regional Coordinator or an accepted distribution point. The nodelist difference file is currently made available each Saturday, and FidoNews is published each Monday. The NC should make these files available to all nodes in the Net, and is encouraged to make them available to the general public for download. The Net Coordinator is elected by a vote of the sysops within the Net. The sysops may choose to delegate voting privileges to a third party to aid in the efficient processing of an election, although Nets are sufficiently small in numbers that this is not generally not required nor desirable. Whenever possible, sysops themselves should have the opportunity to elect their NC in a timely manner within a reasonable term frequency. NCs generally are elected every year or two. 4.3 Elections A coordinator does not have power beyond that of any other sysop. A coordinator is simply a sysop with more work to do, ie. manage the nodelist for the net, region, zone, etc. A coordinator position is one of service and carries with it the trust of the sysops to perform the duties for which they have been selected. To prevent abuse of sysops by those that would seek to centralize power in the hands of a few, as well as those that would seek to obtain power for themselves, it is accepted practice for sysops to elect one of their peers to a coordinator position. In this way, a coordinator of the sysops choosing is selected to serve those sysops, and those sysops are free to de-select that coordinator and install a replacement should they so desire. The exact methods of selection and recall are left to the sysops of that net, region, zone, etc. and are beyond the scope of this document, but it is the responsibility of those sysops to ensure that an abusive coordinator is replaced quickly so as to minimize the damage such a coordinator might do to that net, region, zone, etc. and indeed, Fidonet as a whole. In a case of dispute over an election result, such as suspicions of fixed votes or ballot stuffing, etc., a neutral third party of the sysops choosing may be appointed to oversee the election in order to render a fair result. Due to time constraints and the importance of prompt nodelist submissions, there could arise a situation where there are disputes over the nodelist process being executed by the incumbent coordinator. In such a case, sysops may instruct a third party of their choosing to make nodelist submissions on their behalf to the appropriate coordinator. The point here is that sysops retain all control and authority over how their net, region, or zone is coordinated, the details of which are to be articulated by the sysops themselves. 5.0 NODES, NETS, REGIONS, ZONES 5.1 How to join Fidonet To find out how to join FidoNet find a Fidonet nodelist and locate a net that you might want to join and contact the NC or one of the other listed system. One of the best ways to gain the knowledge necessary to be Fidonet sysop is to both participate as a user on an existing Fido-BBS, and to set up your own not-yet-linked-to-Fidonet BBS. Once you have a basic understanding of what Fidonet provides and how your software does this, you are ready to proceed with joining as a member. Don't let this scare you -- virtually nobody knows what's going on when they first join. There will be plenty of time for questions and usually tons of help available to you later. Waiting until you have a little bit of understanding will simply ease the process for both yourself and your fellow sysops. Remember that your NC is just a hobbyist too, has plenty of work to do already, and often has several other newcomers like yourself needing help at any given time. How To Join Fidonet (Step-by-Step) 1. Gain a basic understanding of Fidonet and your software. You will also need a current copy of the Fidonet Nodelist. This is available from most Fidonet systems as well as the Internet. 2. Set up your Fidonet compatible mailer. Make sure it operates correctly, to the best of your knowledge. 3. Contact a Fidonet sysop and/or a Fidonet coordinator. They will help you. 4. Be patient. It may take some time for your request to be fully processed and appear in the Nodelist. Once you are in, you can then make arrangements with other sysops to get your mail. In practice, it can be a little more complicated, of course. Some software is well documented, some is not; some is a beast to configure, some is not; some is free, some is not. Assembling all of the bits and pieces takes time and technical savvy. (The analogy to ham radio is not accidental.) Your best bet is to ask questions of the other sysops in your area via their BBSs or possibly by email. Most are quite eager to help, and will have all of the software and utilities you need available for you to download. 5.2 How to obtain a node number You should first obtain a current nodelist so that you can send mail. You do not need a node number to send mail, but you should have one in order for others to send mail to you. The first step in obtaining a current nodelist is to locate a FidoNet bulletin board or find a current one on the Internet. Most bulletin board lists include at least a few FidoNet systems, and usually identify them as such. If you are a POTS-only system use a local source to obtain documents because many Nets have detailed information available which explains the coverage area of the Net and any special requirements or procedures. Regions are numbered 1-99; Net numbers are greater than 99. You should set up your software so that the from-address in your message does not cause problems for the coordinator who receives it. If you pick the address of an existing system, this will cause obvious problems. If your software is capable of using address -1/-1, this is the traditional address used by potential sysops. Otherwise use net/9999 (e.g. if you are applying to net 123, set your system up as 123/9999). Many nets have specific instructions available to potential sysops and these procedures may indicate a preference for the from-address. The message you send should include at least the following information: 1) Your name. 2) Your voice telephone number 3) The name of your system. 4) The city and state where your system is located. 5) The phone number to be used when calling your system. 6) Your hours of operation, netmail and BBS. 7) The maximum baud rate you can support. 8) The type of mailer software and modem you are using. Your coordinator may contact you for additional information. All information submitted will be kept confidential and will not be supplied to anyone except the person who assumes the coordinator position at the resignation of the current coordinator. If you send your request to a Regional Coordinator, it may forwarded to the appropriate Net Coordinator. 5.3 If You are Going Down If your node will be down for an extended period (more than a day or two), inform your coordinator as soon as possible. It is not your coordinator's responsibility to chase you down for a status report, and if your system stops accepting mail it may be removed from the nodelist. If you will be leaving your system unattended for an extended period of time (such as while you are on vacation), you should notify your coordinator. Systems have a tendency to "crash" now and then, so you will probably want your coordinator to know that it is a temporary condition if it happens while you are away. 5.4 Nets and Net Coordinators A Net is a collection of nodes. The Net Coordinator (NC) is responsible for maintaining the list of nodes for the Net. 5.4.1 How to Form a Net You should decide which nodes will comprise the net, and which of those nodes you would like to be the Net Coordinator. Then consult your Regional Coordinator. You should send the following information: 1) The region number(s), or net number(s) if a net is splitting up, that are affected by the formation of your net. The Regional Coordinator will inform the Zone Coordinator and the coordinators of any affected nets that a new net is in formation. 2) A copy of the proposed Net's nodelist segment. This file should be attached to the message of application for a Net number, and should use the nodelist format described in the current version of the appropriate FTSC publication. Please elect a name that relates to your grouping. 5.5 Regions and Regional Coordinators A region is a collection of nets and may contain independent nodes that are not a part of any Net. The Regional Coordinator (RC) maintains the list of independent nodes in the Region and accepts nodelists from the Net Coordinators in the region. These are compiled to create a regional nodelist, which is then sent to the Zone Coordinator. 5.6 Zones and Zone Coordinators A zone is a collection of regions. The Zone Coordinator (ZC) compiles the nodelists 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. 6.0 Appendices 6.1 Credits, acknowledgments, etc. Fido and FidoNet are registered trademarks of Fido Software, Inc.