(Part 5 of 6)

9.9  Echomail

Echomail is an important and powerful force in FidoNet.  For the purposes of
Policy Disputes, echomail is simply a different flavor of netmail, and is
therefore covered by Policy.  By its nature, echomail places unique technical
and social demands on the net over and above those covered by this version of
Policy.  In recognition of this, an echomail policy which extends (and does
not contradict) general Policy, maintained by the Echomail Coordinators, and
ratified by a process similar to that of this document, is recognized by the
FidoNet Coordinators as a valid structure for dispute resolution on matters
pertaining to echomail.  At some future date the echomail policy document may
be merged with this one.


9.10  Case Histories

Most of FidoNet Policy is interpretive in nature.  No one can see what is to
come in our rapidly changing environment.  Policy itself is only a part of
what is used as the ground rules for mediating disputes -- as or more impor-
tant are the precedents.

In order to accommodate this process, case histories may be added to or
removed from this document by the International Coordinator, with such a
revision subject to reversal by the Zone Coordinator Council.  Should Policy
be amended in such a way to invalidate a precedent, Policy supersedes said
precedent.  (A carefully prepared amendment would address this by removing
the precedent reference as a part of the amendment.)

Although a case may be removed, the text of a case history may not be modi-
fied by any mechanism.  Case history is written close to the time of the
decision, by those involved with it.  Amending the text of a case history is
the same as revising history, something quite inappropriate in an organiza-
tion dedicated to moving information.



10  Appendices

10.1  General

The Appendices of this document are exceptions to the normal ratification
process.  Section 10.2 can be changed by the appropriate Zone Coordinator,
and section 10.3 may be modified by the International Coordinator (see
Section 9.10).


10.2  Timing of Zone Mail Hour

Zone Mail Hour is observed each day, including weekends and holidays.  The
time is based upon Universal Coordinated Time (UTC), also known as Greenwich
Mean time (GMT).  In areas which observe Daylight Savings Time during part of
the year, the local time of zone mail hour will change because FidoNet does
not observe Daylight Savings Time. The exact timing of Zone Mail Hour is set
for each zone by the Zone Coordinator.

In FidoNet Zone 1, Zone Mail Hour is observed from 0900 to 1000 UTC.  In each
of the time zones, this is:

     Eastern Standard Time          4 AM to 5 AM
     Central Standard Time          3 AM to 4 AM
     Mountain Standard Time          2 AM to 3 AM
     Pacific Standard Time          1 AM to 2 AM
     Hawaii Standard Time          11 PM to Midnight

In FidoNet Zone 2, Zone Mail Hour is observed from 0230 to 0330 UTC.

In Fidonet Zone 3, Zone Mail Hour is observed from 1800 to 1900 UTC.  In each
of the time Zones involved this is:


  GMT +12 Zone                        6:00 AM to 7:00 AM
  (New Zealand)

  GMT +10 Zone                        4:00 AM to 5:00 AM
  (East Australia)
  (Papua New Guinea)
  (Micronesia)

  GMT +9.5 Zone                       3:30 AM to 4:30 AM
  (Central Australia)

  GMT +9 Zone                         3:00 AM to 4:00 AM
  (Japan)
  (Korea)
  (Eastern Indonesia)

  GMT +8 Zone                         2:00 AM to 3:00 AM
  (Hong Kong)
  (Taiwan)
  (Central Indonesia)
  (Philippines)
  (Western Australia)

  GMT +7 Zone                         1:00 AM to 2:00 AM
  (Malaysia)
  (Singapore)
  (Thailand)
  (Western Indonesia)


10.3  Case Histories


Case histories of past disputes are instructive to show general procedures
and methods.  Any decision may be included in this document by a majority
vote of either the Zone Coordinator Council or the Regional Coordinators.

Policy4 significantly changes the functions of the Zone and International
Coordinators.  In the following cases which were decided using Policy3,
substitute "Zone Coordinator" for all occurrences of
"International Coordina-
tor(*)".


10.3.1  The Case of the Crooked Node

A sysop of a local node was using network mail to engage in unethical busi-
ness practices.  The Network Coordinator became very annoyed at this, and
dropped the local from the nodelist.

The local appealed to the Regional Coordinator for assignment as an indepen-
dent node.  The Regional Coordinator, after checking with the Network Coordi-
nator, decided that the Network Coordinator was right to be annoyed.  Inde-
pendent status was denied.

The International Coordinator(*) did not intervene.


10.3.2  The Case of the Hacker Mailer

A sysop of a local node made use of file attaches for extra users to mail
himself the USER.BBS file from several local boards.  The sysops of these
boards felt annoyed at this, and appealed to their Network Coordinator, who
agreed and dropped the offending node from the nodelist.

The Regional Coordinator was not consulted.

The International Coordinator(*) did not intervene.


10.3.3  The Case of the Bothered Barker

A local node became annoyed with the Network Coordinator for failing to
provide services.  Repeated complaints to the Network Coordinator did not
satisfy him, so he appealed to the International Coordinator(*).

The International Coordinator(*) dismissed the complaint because the Regional
Coordinator had not been consulted.

The local node submitted the complaint to his Regional Coordinator, who
investigated the case and discovered that there was some justice to the
complaint.  He advised and assisted the Network Coordinator in configuring
his system to provide an improved level of service to the local nodes.

The Regional Coordinator also decided that the local node was being too
easily annoyed, in that he was expecting services not normally required of a
Network Coordinator.  The local node was informed as to the true duties of a
Network Coordinator, and was advised to lower his expectations.


10.3.4  The Case of the Busy Beaver

A local node which was operated by a retail establishment was engaged in
making "bombing runs" to mail advertisements over FidoNet.  The Network
Coordinator felt annoyed and handling the outgoing traffic for a commercial
operation, and asked the local node to leave the network.

The local node applied to the Regional Coordinator, and was granted status as
an independent node in the region.


10.3.5  The Mark of the Devil

A local sysop whose board was used in conjunction with voodoo rites, hacking,
phreaking, and obscene material applied to a Network Coordinator for a node
number.  The Network Coordinator deemed that this board was exceptionally
annoying, and denied the request.

The Regional Coordinator was not consulted.

The International Coordinator(*), on seeing that the Regional Coordinator had
not been consulted, dismissed the case out of hand.  No further appeals were
made.


10.3.6  The Case of the Sysop Twit

A patron of various local nodes had been roundly recognized by all sysops as
a twit.  The user obtained his own system, became a sysop, and applied for a
node number.  The Network Coordinator denied the request.  No appeals were
made.


10.3.7  The Case of the Echomail Junkie

A local node became enamored with echomail and joined several conferences,
routing mail through his network.  He then started an echomail conference of
his own and began relaying echomail between several systems, again routing it
all through the network.

His Network Coordinator observed that network performance was becoming
seriously impaired.  The offending node was told to hold it down.  A compro-
mise was reached whereby much of the echomail traffic was no longer routed
through the network, and routed echomail was limited to twenty messages per
night.  No appeals were made.


10.3.8  The Case of the Bouncing Board

A local user decided to establish a node to promote a worthy charity.  The
machine being used was also used for various other activities during the day,
and the sysop was often called away.  His coworkers would often forget to
bring the board up at the end of the day while he was away, so the node was
often down for extended periods.  The Network Coordinator, finding the node
unable to receive mail, would mark it down.  The sysop would return, restart
the board, and ask to be reinstated.

The Network Coordinator eventually decided that the sysop was not able to
maintain a reliable system, and removed him from the nodelist completely.
Subsequent requests for a node number from the same sysop were turned down.
No appeals were made.


10.5  Credits, acknowledgments, etc.

Fido and FidoNet are registered trademarks of Fido Software, Inc.

---