Draft ----- Draft ----- Draft ----- Draft ----- Draft ----- Draft
Draft 1 Prepared by Echopol Committee 15 May - 16 Jul 1993
Draft 1 Reviewed by Zone 1 RECs 16 Jul - 27 Aug 1993
Version 3.0 Discussed publicly in Z1_ELECTION 27 Aug - 12 Sep 1993
Draft 2 Rewritten by Echopol Committee 12 Sep - 19 Sep 1993
Draft 2 Reviewed by Zone 1 RECs 19 Sep - 07 Oct 1993
Version 3.1 Discussed publicly in Z1_ELECTION 08 Oct -
ZONE 1 BACKBONE ECHOMAIL POLICY
Version 3.1
08 October 1993
---------------------------------------------------------
TABLE OF CONTENTS
1. OVERVIEW
1.0 Basis of policy
1.1 Purpose of policy
1.2 Backbone goal
1.3 Agreement
1.4 Amendments
2. APPOINTMENTS
2.0 Zone Echomail Coordinator (ZEC)
2.1 Region Echomail Coordinator (REC)
2.2 Net Echomail Coordinator (NEC)
2.3 Zone Echomail Hubs (ZHubs)
2.4 Region Echomail Hubs (RHubs)
2.5 Change of Appointments
2.6 Conference Moderators (Moderators)
2.7 Nodelist Designations
3. DISTRIBUTION SYSTEM
3.0 Participation
3.1 Alternate feeds
3.2 Guarantees
3.3 Charging for distribution
3.4 Backbone Echo Lists
3.5 Restricted distribution
3.6 Autonomy of Nets
3.7 Emergency backup planning
3.8 Security
4. CONTENT
4.0 Routing
4.1 InterNetwork goals
4.2 Encryption
4.3 Routed files
5. SOFTWARE STANDARDS
5.0 Technical references
5.1 Monitoring responsibility
5.2 Message Size
6. DISPUTES
6.0 Use of judgement
6.1 Complaint settling
6.2 Sanctions
6.3 Removal of echoes for cause
7. MODERATOR APPEAL COMMITTEE
7.0 Interim Procedure
7.1 Feed Cuts
8. DEFINITIONS
8.0 Backbone
8.1 Backbone Echolist
8.2 CRP
8.3 Downlink
8.4 Echo
8.5 FidoNet Policy
8.6 Gateway
8.7 Illegal
8.8 Insecure mail
8.9 International Echolist
8.10 Low and high ASCII characters
8.11 Routine Operating Information
8.12 Secure node
8.13 *EC
---------------------------------------------------------
1. OVERVIEW
1.0 Basis of policy
This Echomail Policy document (Echopol) has been drafted by the Echomail
Coordinators (*ECs) to detail the principles on which the Zone 1
Echomail Backbone Distribution System (the Backbone) operates. This
policy may not be enforced under the terms of Fidonet Policy since the
Backbone is not a Fidonet issue. The Terms used in this document are
defined in Section 8.
Separate policy documents may be issued at the 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 ZEC or REC as appropriate, local policy can be used to
implement differences required due to local conditions.
1.1 Purpose of policy
This document establishes the echomail policy for the Backbone. Its
purpose is to define, standardize and provide guidance for decisions
required in the operation of the Backbone, and to define the Echomail
Coordinator structure. This policy applies only to services provided
by the Backbone such as echomail listed on the Backbone Echolist, and
Netmail routed through the Backbone.
1.2 Backbone goal
The Backbone was designed to simplify the distribution of echomail at
the Zone level to provide echomail to each Net. Its purpose is to
promote communication in echomail conferences in a lawful, friendly
manner consistent with the general principles of FidoNet.
The Backbone is run on the basis of 'organized anarchy'. It functions
solely as a carrier of echomail, though not in the legal sense. This
policy is written around the principles of 'notification rather than
approval', and 'coordination rather than control'.
1.3 Agreement
Any node accepting a feed of Backbone echomail or routing netmail
through the Backbone agrees to the provisions of this policy. All
Echomail Coordinators will ensure that downlinks receiving a Backbone
feed are educated concerning this policy.
The author of any message entered onto any Zone 1 Backbone echo is
considered to have retained ownership of his message, but to have
granted permission for its non-profit use.
1.4 Amendments
Amendments to all or part of Echopol are ratified by a simple majority
of <voters to be decided> casting votes in a policy referendum.
Suggestions for amendment to Echopol may be submitted at any time to the
ZEC or to an REC who will present the proposal to the RECs for
discussion. The ZEC will call a policy referendum either on the request
of 5% of Zone 1 sysops presented to the ZEC or if a majority of RECs
request a referendum. Multiple amendments may be considered during a
single referendum, but will be voted on individually.
Changes to this policy are to be made as follows:
Draft amendment circulated via a backbone file echo for comment
Public discussion in Zone-wide echo for minimum of three weeks
RECs review and recommend any changes to revised draft
Final draft circulated via a backbone file echo
Vote by all <voters to be decided> to accept/reject revision
Voting results published in Zone-wide echo
To allow for timely modification of routine procedures, the ZEC may
establish and maintain a Zone 1 Backbone Routine Operating Information
(R.O.I.) document. Drafting and modification of R.O.I. is subject only
to approval by a majority vote of RECs.
2. APPOINTMENTS
2.0 Zone Echomail Coordinator (ZEC)
A ZEC is selected by the Zone, as coordinated by the ZC, on whatever
basis the Zone chooses, and is responsible to the Zone, as
coordinated by the ZC.
The ZEC coordinates echomail, routing and schedules at the Zone level
to ensure reliable and efficient availability of Backbone echoes while
avoiding creation of duplicate messages.
2.1 Region Echomail Coordinator (REC)
An REC is selected by his Region, as coordinated by the RC, on whatever
basis the Region chooses, and is responsible to the Region, as
coordinated by the RC.
The REC coordinates echomail, routing and schedules at the Region level
to ensure reliable and efficient availability of Backbone echoes while
avoiding creation of duplicate messages. The REC is responsible for the
technical integrity of all echomail sent from his Region into the
Backbone system.
2.2 Net Echomail Coordinator (NEC)
An NEC is selected by his Net, as coordinated by the NC, on whatever
basis the Net chooses, and is responsible to the Net, as
coordinated by the NC.
The NEC coordinates echomail, routing and schedules at the Net level
to ensure reliable and efficient availability of Backbone echoes while
avoiding creation of duplicate messages. The NEC is responsible for the
technical integrity of all echomail sent from his Net into the
Backbone system.
2.3 Zone Echomail Hubs (ZHubs)
A ZHub distributes echomail at the Zone level, connecting to other ZHubs
as determined by the ZEC and providing a minimum of one connection to
each Region.
A ZHub acts as an unlanned extension of the ZEC's computer system. The
ZHub does not make decisions on feed cuts, echo termination or other
echomail policy matters.
Each ZHub carries all Backbone echoes and appropriate related file
echoes. Where such a requirement would have an adverse economic impact
on the ZHub, it will pre-arrange any variance from this requirement with
the ZEC.
A ZHub is appointed by the ZEC.
2.4 Region Echomail Hubs (RHubs)
An RHub distributes echomail at the regional level, normally connects to
a ZHub, and provides connections to regional Nets as determined by the
REC for the Region.
Each RHub carries Backbone echoes to the extent deemed appropriate by
the REC and and its function and limitations are the equivalent of a
ZHub.
An RHub is appointed by the REC in accordance with regional echomail
policy.
2.5 Change of Appointment
The Zone, a Region, or a Net, as coordinated by the ZC, RC or NC
respectively, may choose to replace the appropriate *EC on whatever
basis it decides.
A ZHub, RHub or NHub appointment may be transferred at any time by the
*EC level which appointed it.
2.6 Conference Moderators (Moderators)
Moderators preside over echoes, and the Backbone recognizes that a
moderator has complete authority over his/her echo in regards to the
echo's policy, standards of conduct and participation. The Backbone
accepts the International Echolist entry as defining the moderator of
an echo.
A Moderator is responsible to the ZEC for the smooth operation of his
echo while on Backbone distribution, and he shall be readily accessible
via netmail through a FidoNet node number..
When the Backbone agrees to carry an echo on the Zone 1 distribution
system, the Moderator in return agrees to the provisions of this policy
and to accept the following responsibilities:
a. seeing that messages in the echo correspond to the echo's theme
as expressed in the International Echolist.
b. ensuring that the echo does not distribute or promote illegal
activities or information.
c. updating the echo listing in the International Echolist at least
every six months.
d. monthly posting of echo rules or policy.
2.7 Nodelist Designations
To assist in identifying echomail coordinators, it is suggested that
Echomail coordinators be identified by the UZEC, UREC, and UNEC user
flags on the coordinator's personal node number entry. This does not
prevent a Net from asking the NC for a unique (admin) node number for
the Net-sponsored system which imports echomail.
3. DISTRIBUTION SYSTEM
3.0 Participation
All nodelisted systems are eligible to be considered for a feed
of Backbone echomail unless barred from receiving a feed under the terms
of this policy.
No one shall knowingly feed Backbone echomail to a node whose feed has
been cut for violations of Echopol.
3.1 Alternate feeds
Any node may obtain a feed of Backbone echomail from any source willing
to feed it, and may subdistribute that echomail to other nodes at its
discretion.
In general, any legal form of distribution which lowers costs, and
improves speed of communication, while avoiding circular feeds which
cause duplicate messages, will be encouraged. New technology will be
explored and will not be accepted or rejected out of hand.
No Echomail Coordinator shall prohibit a node from obtaining a Backbone
echomail feed or from distributing that feed provided no technical
problems are being created by that feed or distribution.
A node or Net receiving a feed of one or more Backbone echoes from other
than conventional ZHub/RHub/NHub connections shall advise the NEC or REC
of the routing and subdistribution topology being used. This should
include the use of advanced technology (eg: satellite). An Echomail
Coordinator does not control non-standard feeds, but must know about
them in order to coordinate them.
Procedures for handling specific types of distribution methods will be
specified in R.O.I.
3.2 Guarantees
While the Backbone attempts to provide the best service possible, it
provides no guarantee of either echomail or routed netmail delivery.
Messages which require sensitive or timely handling should not be sent
through the Backbone. The receiving of Backbone echomail is a privilege,
not a right.
3.3 Charging for distribution
The Backbone exercises no control over Cost Recovery Plans (CRPs).
Decisions regarding the sharing of costs, nature of the costs,
participation and/or subdistribution of echomail which a CRP has
imported are matters which concern only the sysops involved.
3.4 Backbone Echo Lists
The ZEC is responsible for the maintainance of a list of available
echoes at the Zone level (Backbone Echolist). The ZEC may also appoint
a Zone Echolist Coordinator to be responsible for the maintenance of a
detailed list of echo descriptions (International Echolist), with terms
of reference set out in R.O.I..
The ZEC shall remove an echo from the Backbone Echolist upon the request
of the official moderator.
3.5 Restricted distribution
The Backbone Echolist only lists echoes which are freely available to
all sysops. BBS users, however, may be restricted from participation in
some of these echoes.
3.6 Autonomy of Nets
Since the Backbone exists to distribute echomail to each Net, the Net's
NEC forms the final level of the Backbone organization, and acts as the
interface between the Net and the Backbone. There is no attempt in this
document to determine the distribution arrangements within individual
Nets.
3.7 Emergency backup planning
To allow the Backbone distribution system to continue to operate with a
minimum of disruption in the event of long-term power failures,
equipment failures or loss of volunteers, the ZEC will coordinate an
emergency backup plan for the ZHubs.
It is recommended that each REC maintain a regional emergency backup
plan.
3.8 Security
To prevent deliberate disruption of echoes by various forms of mail
dumping, each ZHub and RHub shall operate in such a manner that only
mail arriving from nodes with which distribution arrangements have been
pre-arranged is processed automatically.
Any reasonable method of ensuring that insecure mail does not enter the
Backbone without review is acceptable, such as software capable of
separating the mail automatically, subroutines prepared by the hub,
packet-level passwords, visual examination or other methods.
An echomail hub may choose not to accept inbound mail from a downlink
which does not operate as a secure node, but at its discretion may
continue to feed Backbone mail to that downlink.
4. CONTENT
4.0 Routing
Due to the costs involved echomail is not normally routed. Echomail
shall not be routed without prior agreement between all nodes involved.
The Backbone's primary purpose is to distribute echomail. As a
courtesy, the Backbone accepts and delivers Echomail Routed Netmail
(ERN) and all Region and Zone Hubs agree to support such routing. If
the netmail load from any Net becomes too onerous, the Backbone may
choose not to accept ERN from that Net.
Where a Net does not support outgoing netmail with its echomail
transfers it should make arrangements for disposition of incoming ERN
with the appropriate RHub.
4.1 Inter-network goals
It is the general policy of FidoNet to encourage communication between
FidoNet and all other networks through the development of inter-network
echoes. Inter-network echoes shall conform to the provisions of this
policy while being distributed by the Backbone.
The ZEC may direct that an echomail gateway operating procedures
document be established to provide a technical base for increasing
contact between various networks. Drafting and modification of a
gateway operating procedures document is subject only to approval by a
majority vote of RECs.
4.2 Encryption
The language of FidoNet is English, and all Backbone echomail traffic
shall be in this language unless the echo moderator specifies otherwise.
With the exceptions listed below, no Backbone echomail or Echomail
Routed Netmail message may be encoded, encrypted, public-key encrypted,
enciphered or otherwise rendered unreadable. The use of high or low
ASCII characters is not permitted in the header, tearline, or origin
line of a message.
Uuencoded or similar message-format files are considered to be routed
files and may not be routed in netmail. Short pieces of programming
code, no longer than a typical message and infrequently sent, may be
routed in netmail.
Provided that an echo moderator has so indicated in the International
Echolist, a moderator may permit high or low ASCII characters in the
body of the message, and also small segments of recognized programming
language or of uuencoded text, but is subject to Backbone judgement as
to when these segments become excessive.
A sysop has the right to require that the originator of any apparently
encrypted or otherwise unreadable message being routed through his
system provide him with satisfactory evidence that the message is
neither commercial nor illegal in content.
4.3 Routed files
Due to the large size and additional cost of transmission the Backbone
does not accept routed files. It accepts no responsibility for
returning such files or for advising the originator of their
non-transmission.
The Backbone distributes essential administrative files containing
information on echo areas. These files are regularly routed to all mail
hubs for public distribution. All Backbone systems have agreed to
transport these files. The current names of the files, the file areas
and the routing software used are listed in R.O.I..
5. SOFTWARE STANDARDS
5.0 Technical references
Current technical standards for Backbone echomail and routed netmail are
listed in R.O.I..
Nodes sending messages via the Backbone shall ensure that such messages
conform to the above standard.
5.1 Monitoring responsibility
To reduce costs and system malfunctions for sysops participating in the
Backbone distribution system, proven message tracking or monitoring
software may be employed by echomail hubs at all levels. This may
include the use of 'grunged message' detection software and the return
or notified-deletion of damaged or out-of-specification messages.
5.2 Message Size
Due to the limitations of older software the Backbone can not guarantee
delivery of long messages.
The currently accepted maximum message size handled by ZHubs is
specified in R.O.I.. Downlinks and software programmers are encouraged
to use this standard so that all messages up to this length are routed
without interruption.
6. DISPUTES
6.0 Use of judgement
The application of Echomail policy in the resolution of disputes
requires the use of good judgement by the echomail coordinators
involved. Decisions should be made in a consistent manner with a
genuine attempt made to obtain both sides of any issue.
Where this policy does not appear to forsee a particular situation the
echomail coordinator is expected to use a combination of this policy,
precedent and his own good judgement to resolve a dispute.
6.1 Complaint settling
Complaints referred to in this section (6) are those dealing with
technical issues where a decision may be made under the terms of this
Echomail Policy. If a complaint is filed under the terms of FidoNet
Policy it shall be referred instead to the appropriate NC, RC or ZC for
resolution.
Where a node is unable to obtain satisfactory handling of an echomail
complaint from his NEC he may address the complaint to his Region's REC
and failing a satisfactory response from the REC, he may address the
complaint to the ZEC who shall be the final arbiter in such matters.
6.2 Sanctions
The only sanction which may be applied to a node or a Net by an Echomail
Coordinator for contravention of this policy is removal of its access to
Backbone services such as echomail and outgoing routed netmail feeds.
Where a node is unable to correct a technical problem of which there is
proof, and which is disrupting the smooth operation of the Backbone, the
appropriate Echomail Coordinator may request that the feed of the node
be cut.
The only sanction which may be applied by the Backbone to a moderator is
removal of his echo from Backbone distribution.
6.3 Removal of echoes for cause
The Backbone has no desire to interfere with the internal affairs of a
Backbone conference as long as it does not disturb the smooth operation
of the Backbone.
An echo may be removed from Backbone distribution by the ZEC in the
following cases:
a. inadequate traffic or distribution.
b. failure to meet technical standards.
c. inability of the moderator to accept or respond to netmail.
d. violation of Backbone Echopol.
The ZEC may remove an echo automatically in the case of a. above.
Removal for any other reason requires the prior approval of a majority
of RECs and evidence that the moderator has been given sufficient
warning and an opportunity to present his point of view to the ZEC.
7. MODERATOR APPEAL COMMITTEE
7.0 Interim Procedure
It is the intent of the Backbone eventually to leave all matters
concerning the appointment of moderators and disputes arising out of the
internal operation of echoes to a Moderator Appeal Committee, appointed
and run by the moderators independently from the Backbone, and
recognized by the moderator community in a manner similar to current
recognition of moderators.
Until such time as the moderators establish such a committee, the
Backbone will handle such matters as detailed below. Once such a
committee is established, it is intended that section 7 be deleted from
this policy.
The ZEC will appoint a Backbone Appeal Committee (B.A.C.) from among the
10 Zone 1 RECs. Current membership will be detailed in R.O.I.. The
B.A.C. will only hear appeals from users, sysops, Hubs and moderators
concerning moderator-requested feed cuts. All other types of internal
echo disputes will be the responsibility of the parties concerned to
resolve.
7.1 Feed Cuts
A moderator shall not unreasonably remove a user or node from
participation in an echo. When a moderator wishes to terminate a user's
participation for violation of the echo's published rules, the Moderator
will send netmail to the user's Sysop directing that the user's access
to the echo be severed. This netmail will include advice that the
ruling may be appealed to the B.A.C., and will also include the ZEC's
name and node number.
The Sysop will immediately terminate the user's access as directed. If
he fails to do so the moderator may request of the ZEC that the Sysop's
feed of the echo be terminated, or failing that the NHub's feed, or
failing that the RHub's feed.
Where a user or node appeals a feed cut to the B.A.C., the committee
will request evidence from the appellant and from the moderator to
support their arguments. Should the committee find that there is
insufficient evidence to support the cut, or should it find in favour of
the appellant, the moderator shall reconnect the appellant to the echo.
No node shall knowingly feed an echo to a node whose feed has been cut
at the request of the Moderator.
8. DEFINITIONS
8.0 Backbone
The Zone 1 Echomail Backbone Distribution System (the 'Backbone') is an
independent organization separate from Fidonet, whose Echomail
Coordinators and Hubs have Fidonet node numbers. It incorporates all
Backbone Zone and Region level distribution to individual Nets. The
distribution system includes Backbone Echomail Coordinators, echomail
conferences, conference moderators, and distribution arrangements.
8.1 Backbone Echolist
The Backbone Echolist is a listing of area tag names for all current
Backbone echomail conferences, and is maintained in a format usable for
automatic processing of feed requests.
8.2 CRP
A Cost Recovery Plan (CRP) is a cost-sharing arrangement between nodes
participating in an echomail delivery system in which costs of importing
and distributing echomail are shared by members of the system.
8.3 Downlink
A downlink is a system, whether node or hub at any level, which
receives Backbone mail from a distribution source above it (its
uplink).
8.4 Echo
An Echo, also called an Echomail Conference, or Conference, is a
message base or forum distributed under a specified echo name, or
TAG, dealing with a defined area of interest.
8.5 FidoNet Policy
The current ratified FidoNet Policy is Policy 4 and is referred to
in this document as FidoNet Policy.
8.6 Gateway
A gateway is a system of computers equipped to pass electronic mail
messages of various types between FidoNet and a non-FidoNet network. A
Gateway acts as a translator, allowing messages entered on a system in
the other network and addressed to a destination within FidoNet to be
translated into a form which is technically acceptable to and compatible
with FidoNet, and vice versa.
8.7 Illegal
In addition to illegal behaviour referred to in FidoNet Policy, the term
'illegal' in this document will be taken as referring to behaviour
considered illegal via the criminal justice system in the jurisdiction
of the coordinator, hub, sysop or moderator who must take responsibility
for such behaviour. It is recognized that this definition will result
in varying definitions of 'illegal' depending on the location of the
person on whom such responsibility rests.
8.8 Insecure mail
Insecure mail is considered to be mail (netmail or echomail) received
from nodes with which distribution arrangements have not been
pre-arranged, thereby lacking assurance that the sender has authorized
access to Backbone echomail areas or other services.
8.9 International Echolist
The International Echolist is an informal, international listing of
Echomail conferences as described and submitted by each conference's
moderator. It contains descriptions and other data for all Backbone and
many non-Backbone echoes.
8.10 Low and high ASCII characters
In this document, high ASCII characters are considered the Eight-bit
characters (ASCII 128-255), while low ASCII characters are considered
the non-printing low-order codes (ASCII 2-31), with the exception of the
8Dh(soft <CR> character).
8.11 Routine Operating Information
The Zone 1 Backbone Routine Operating Information (R.O.I.) file provides
functional details for the application of this Policy and normally
contain non-policy matters to clarify, standardize, or ensure smoothness
in the Backbone's distribution system.
8.12 Secure node
A secure node is one which processes inbound mail automatically only
from nodes with which prior agreement has been made to accept such mail.
8.13 *EC
For the purpose of the Zone 1 Backbone echomail system, the term '*EC'
or 'Echomail Coordinator' refers to the Zone 1 ZEC, RECs, and NECs. It
does not refer to any Hub or other use of the term 'Echomail
Coordinator'.
---------------------------------------------------------
"FidoNet" is a U.S. registered trademark of Tom Jennings.
---------------------------------------------------------
Echopol Committee:
Adrian Walker 153/752 Miles Hoover 109/25
Tony Wagner 105/2 John Mudge 352/111
Larry Squire 3620/2 Mark Astarita 2605/10
Dixon Kenner 243/5 Dallas Hinton 153/715
Michael Walsh 273/10
---ooo000ooo---