(Part 2 of 6)

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.

2.1.6.1  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.

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, 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
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 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.


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 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.

---