From Enric Lleal Serra@2:343/107.1 to All on Thu Jul 19 14:23:00 2007
FidoNet Policy Document Version 4.07
June 9, 1989
This policy document has been accepted by vote of the FidoNet coordinator structure, and is the current FidoNet policy document until superceded.
(There are no differences between this version and 4.06 except the statement above.)
This document establishes the policy for sysops who are members of the
FidoNet organization of electronic bulletin board 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. 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 members of FidoNet beyond those included in this document, other than enforcement of local mail periods.
The official language of FidoNet is English. All documents must exist in English. Translation into other languages is encouraged.
FidoNet is an amateur electronic mail system. As such, all of its partici- pants and operators are unpaid volunteers. From its early beginning as a few friends swapping messages back and forth (1984), it now (1989) includes over 5,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 on their system.
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. Multinet operation provides the structure. Decentralized management provides the control. This document describes the procedures which have been developed to manage the network.
FidoNet systems are grouped on several levels, and administration is decen- tralized to correspond with these groupings. This overview provides a
summary of the structure; specific duties of the coordinator 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. 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.
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 consid- ered to be from a user and is the responsibility of the sysop. (See section 2.1.3.)
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 makes 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.
1.2.3 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 appointed by the Regional Coordinator.
22.214.171.124 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 net- work. The exact duties and procedures are a matter for the Network Coordina- tor and the hubs to arrange, and will not be discussed here, except that a network coordinator cannot delegate responsibility to mediate disputes.
1.2.4 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 nodelists 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.
Regional Coordinators are appointed by the Zone Coordinator.
1.2.5 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 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. A Zone Coordinator does not perform message-forwarding services for any nodes in the zone.
Zone Coordinators are selected by the Regional Coordinators in that zone.
1.2.6 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-zonal issues. This includes, but is not limited to: working out the details of nodelist production, mediating inter-zonal disputes, and such issues not addressed at a lower level of FidoNet.
1.2.7 International Coordinator
The International Coordinator is the "first among equals" Zone Coordinator,
and 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 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.
1.2.8 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 person at the next level may replace them. For example, if a Regional Coordinator fails to perform, the Zone Coordinator can replace him.
To provide for checks and balances at the highest level of FidoNet, there are two exceptions to this top-down organization. Zone Coordinators and the International Coordinator are selected by a majority vote of the coordinators at the level below. Similarly, decisions made by the International Coordina- tor can be reversed by the Zone Coordinator Council, and decisions made by a Zone Coordinator can be reversed by the Regional Coordinators. See sections
6 and 7 for details. 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.
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 users are encouraged to contribute to FidoNews. Contributions are submitted to node 1:1/1; a file describing
the format to be used is available from 1:1/1 and many other systems.
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 geo- graphic guideline is used to decide which nodes belong to what network.
Network membership is based on geographic or other purely technical ratio- nale. 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 10.2.
Zone Mail Hour has previously been referred to as National Mail Hour and Network Mail hour. The term Zone Mail Hour is more accurate.
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 Saturday, 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
There are references throughout this policy to "excessively annoying behav- ior", 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 falsifi- cation of mail would likely be excessively annoying on the very first try),
but simply illustrates that a certain amount of tolerance is extended.
Refer to section 9 and the case studies (section 10.3) 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 informa- tion, 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 in- stance), orders and their follow-ups, and all other subjects specifically related to business.
2 Sysop Procedures
2.1.1 The Basics
As the sysop of an individual node, you can generally do as you please, as
long as you 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
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 policy 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.
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 system 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.
126.96.36.199 No Disclosure of in-transit mail
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 as 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.
188.8.131.52 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, unless
you hold a Network Coordinator or Hub Coordinator 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 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.
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.
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 replace- ment for that hub. A private node must be a part of a network (they cannot
be independents in the region.)
Private listings impact 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
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 authori- ties. For this reason, a sysop who sends mail is obligated to obtain and use the most recent edition of the nodelist as is practical.
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 and contact your coordinator.
Systems may also be dropped from the nodelist for cause. See section 9, and sections 4.3 and 5.2.
It is considered annoying behavior to assist a system which was excommuni- cated in circumventing that removal from the nodelist. For example, if you decide to provide an echomail feed to your friend who has been excommuni- cated, it is likely that your listing will also be removed.
2.1.13 Timing of Zone Mail Hour
The exact timing of Zone Mail Hour for each zone is set by the Zone Coordina- tor. See section 10.2.
2.1.14 Non-observance of Daylight Savings Time
FidoNet does not observe daylight savings time. In areas which observe daylight savings time the FidoNet mail schedules must be adjusted in the same direction as the clock change. Alternatively, you can simply leave your
system on standard time.
2.2 How to obtain a node number
You must first obtain a current nodelist so that you can send mail. You do
not need a node number to send mail, but you must 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. Most bulletin board lists include at least a few FidoNet systems, and usually identify them as such. Use a local source to obtain documents because many networks have detailed information available which explains the coverage area of the network and any special requirements or procedures.
Once you have a nodelist, you must determine which network or region covers your area. Regions are numbered 1-99; network numbers are greater than 99. Networks are more restricted in area than regions, but are preferred since
they improve the flow of mail and provide more services to their members. If you cannot find a network which covers your area, then pick the region which does.
Once you have located the network or region in your area, send a message containing a request for a node number to node zero of that network or
region. The request must be sent by netmail, as this indicates that your system has FidoNet capability.
You must 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 must 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.
You must indicate that you have read, and agree to abide by, this document
and all the current policies of FidoNet.
Please allow at least two weeks for a node number request to be processed.
If you send your request to a Regional Coordinator, it may forwarded to the appropriate Network Coordinator.
2.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 will be removed from the nodelist.
Never put an answering machine or any other device which answers the phone on your phone line while you are down. If you do, calling systems will get the machine repeatedly, racking up large phone bills, which is very annoying. In short, the only thing which should ever answer the telephone during periods when the nodelist indicates that your node will accept mail is FidoNet- compatible software which accepts mail.
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.
2.4 How to Form a Network
If there are several nodes in your area, but no network, a new network can be formed. This has advantages to both you and to the rest of FidoNet. You receive better availability of nodelist difference files and FidoNews, and everyone else can take advantage of host-routing netmail to the new network.
The first step is to contact the other sysops in your area. You must decide which nodes will comprise the network, and which of those nodes you would
like to be the Network Coordinator. Then consult your Regional Coordinator. You must send the following information:
1) The region number(s), or network number(s) if a network is splitting
up, that are affected by the formation of your network. The Regional
Coordinator will inform the Zone Coordinator and the coordinators of any
affected networks that a new network is in formation.
2) A copy of the proposed network's nodelist segment. This file should
be attached to the message of application for a network 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, for example SoCalNet for nodes in the Southern California Area
and MassNet West for the Western Massachusetts Area. Remember if you
call yourself DOGNET it doesn't identify your area.
Granting a network number is not automatic. Even if the request is granted, the network might not be structured exactly as you request. Your Regional Coordinator will review your application and inform you of the decision.
Do not send a network number request to the Zone Coordinator. All network number requests must be processed by the Regional Coordinator.
3 General Procedures for All Coordinators
3.1 Make Available Difference Files and FidoNews
Any Coordinator is responsible for obtaining and making available, on a
weekly basis, nodelist difference files and FidoNews.
3.2 Processing Nodelist Changes and Passing Them Upstream
Each coordinator is responsible for obtaining nodelist information from the level below, processing it, and passing the results to the level above. The timing of this process is determined by the requirements imposed by the level above.
3.3 Ensure the Latest Policy is Available
A Coordinator is responsible to make the current version of this document available to the level below, and to encourage familiarity with it.
In addition, a coordinator is required to forward any local policies received to the level above, and to review such policies. Although not required,
common courtesy dictates that when formulating a local policy, the participa- tion of the level above should be solicited.
3.4 Minimize the Number of Hats Worn
Coordinators are encouraged to limit the number of FidoNet functions they perform. A coordinator who holds two different positions compromises the appeal process. For example, if the Network Coordinator is also the Regional Coordinator, sysops in that network are denied one level of appeal.
Coordinators are discouraged from acting as echomail and software-distri- bution hubs. If they do so, they should handle echomail (or other volume distribution) on a system other than the administrative system. A coordina- tor's system should be readily available to the levels immediately above and below.
Another reason to discourage multiple hats is the difficulty of replacing services if someone leaves the network. For example, if a coordinator is the echomail hub and the software-distribution hub, those services will be difficult to restore when that person resigns.
Sigue en el siguiente mensaje... 1/3
--- FMail/Win32 1.60
* Origin: "Vigile su cordura" (Gritos en el Pasillo) (2:343/107.1)