GENERAL ECHOMAIL POLICY
February 1, 1989
PROLOGUE
This document sets forth policy governing Echomail conferences
and their distribution.
This Policy applies to Zone One Backbone Echomail conferences and
to any other conferences for which the Moderator desires it to be
applicable. Future changes to Echo Policy may be proposed only
by a simple majority vote of the Regional Echomail Coordinators.
Those eligible to vote on any proposals made by the REC structure
will be the ZEC, RECs, NECs, NCs, RCs and IC. Only one vote per
person is allowed. Adoption of changes will require a simple
majority of those voting to pass.
In this document, "a simple majority" means more than 50 percent
of those voting. A good faith attempt must be made to make all
potential voters aware that a vote is occurring and make
available all necessary information.
I. HISTORY
Echomail consists of the sharing of message bases or conferences
between various independent network addresses. The Echomail
concept started with a series of programs by Jeff Rush. Since
the original implementation, many authors have written programs
improving on the original idea. In spite of worries that the
flow of Echomail would increase Netmail traffic to the point that
the Network would collapse under its own weight, Echomail has
been a success. To simplify the distribution of Echomail, a
national Echomail Backbone formed whose primary purpose is the
distribution of Echomail at a national level. Of recent
introduction to the Backbone system has been the generous
contribution of the Echomail Stars. As a result of the growth of
Fidonet and the increase in the volume of Echomail, it has become
necessary to set forth a formal policy governing Echomail.
II. DEFINITIONS
1. ECHOMAIL: The process of sharing message bases between
independent systems with unique net/node addresses.
2. ECHOMAIL CONFERENCES: An Echomail conference is a message
base of forum design distributed under a specified conference
name dealing with a defined area of interest. Notable examples
include TECH, the National Technical Conference and COMM, the
National Telecommunications Conference.
3. MODERATED CONFERENCE: A moderated conference is an Echomail
conference for which a moderator has been appointed to supervise
the flow and content of the conference. All conferences carried
on the Backbone must be moderated.
4. SYSOP-ONLY CONFERENCE: A Sysop-Only Conference is one in
which the Moderator has decided that the conference will be made
available only to Sysops and not to users.
5. RESTRICTED DISTRIBUTION CONFERENCES: A restricted
distribution conference is one which is restricted only to
eligible recipients. Notable examples include REGCON, the
Regional Coordinators Conference, COORD, the National Echomail
Coordinators Conference, and MAGICK, a pre-register Echomail
Conference.
6. ZONE ECHOMAIL COORDINATOR (ZEC): This individual is
responsible for coordination of Echomail on a FidoNet Zone level.
7. REGIONAL ECHOMAIL COORDINATOR (REC): This individual is
responsible for coordination of Echomail within his region.
8. NET ECHOMAIL COORDINATOR (NEC): This individual is
responsible for coordination of Echomail at the Local Net level.
9. ECHOMAIL Backbone: The Echomail Backbone consists of
voluntary members who provide services to enhance the national
distribution of Echomail. The Backbone consists of nodes which
handle a high volume of Echomail traffic and are responsible for
distribution of Echomail down to the regional level.
10. NATIONAL ECHOMAIL LIST: The National Echomail List
identifies the available national conferences, the conference
moderator and requirements of the specified conference. The ZEC
will appoint the keeper of the National Echomail List.
11. AUTOMATED CENSORSHIP: The term Automated Censorship refers
to programs which cause messages to be removed from the intended
conference or have their content altered.
12. FIDONET POLICY: The document which governs Fidonet as
adopted by Fidonet. The document as of this writing is Policy3
and is subject to change. This policy is intended to become a
part of general Fidonet policy. Until it is incorporated into
General Fidonet policy, this document shall serve to define
policy violations occurring in Echomail.
13. OPEN ACCESS CONFERENCE: This is a non-restricted conference
open to all users who are willing to follow the posted conference
rules.
14. TERMINAL NODE: A system which does not process echomail for
pickup by another system.
III. DUTIES OF ECHOMAIL COORDINATORS
1. GENERAL: It is the duty of the *ECs to make available to
any Fidonet Sysop, any conference which the Sysop is not
prohibited from receiving by not meeting requirements as mandated
by the conference moderator. If for any reason the *EC does not
have access via recognized distribution channels to a specific
conference, they can not be expected to pass it on. If a *EC
fails to make available any conference to qualified lower
distribution levels, this shall be deemed to have violated the
outlined duties of the position held. Such violation is cause
for the removal as provided by this document. Nothing in this
provision requires that a *EC must import any conference to the
extent of adverse economic impact. It is recommended that cost
sharing arrangements be employed. Where financially feasible for
the supplier any conference on the Backbone must be made
available (other than restricted conferences) when requested.
An exception is when a *EC cuts a link to end unauthorized
distribution of a conference. In this case, some otherwise
authorized nodes may temporarily lose their link.
A *EC shall do everything in their power to insure that:
1. All downstream links are educated as to this policy.
2. Downstream links know how to properly link into
conferences.
3. Acceptable and unacceptable behavior in echomail
conferences is explained.
4. Downstream links are not engaging in topologies that
increase the risk of duplicate messages.
2. DUTIES OF ZONE ECHOMAIL COORDINATOR: It is the duty of the
ZEC to coordinate the connections between the Echomail Backbone
on both an inter-Zone and intra-Zone level as well as
coordination of inter-regional connections. The ZEC will
coordinate transmission of Echomail and to provide for routing
in a manner that will avoid the transmission of duplicate
messages within the same conference. It is also the duty of the
ZEC to monitor compliance with this policy on both a national and
international basis.
3. DUTIES OF REGIONAL ECHOMAIL COORDINATOR: It is the duty of
the REC to provide for regional Echomail distribution. In
addition, the REC will coordinate any inter-regional cross-
linking of conference feeds with the REC of the participating
region with the direct knowledge of the ZEC. The REC will
provide for transmission and routing of Echomail within his/her
region in a manner to avoid creation of duplicate messages
within the same conference. It is the duty of the REC to monitor
compliance with this policy at a regional level.
4. DUTIES OF NET ECHOMAIL COORDINATOR: It is the duty of the
NEC to coordinate the intra-net Echomail and to cooperate with
the REC and NECs of other nets to arrange for the inter-net
transmittal of echomail. The REC may require the NEC to provide
links for independent (regional) nodes. The NEC shall maintain a
list of available Echomail Conferences within the net as well as
the requirements of each Conference area as supplied by the
conference moderator (Echolist). The NEC shall also monitor
compliance with this policy at a net level.
5. DUTIES OF ECHOLIST COORDINATOR: It is the duty of the
Echolist Coordinator to compile and make available a listing of
national and international Echomail conferences and optionally,
conferences at various local levels. The content and format of
the Echomail listing shall be at the sole discretion of the
Echolist Coordinator, but shall include the conference name and
moderator for each conference. The Echolist Coordinator shall
also maintain a list of requirements applicable to each listed
conference.
6. DUTIES OF ECHOMAIL CONFERENCE MODERATOR: It shall be the
duty of the Echomail Conference Moderator to make in good faith
every reasonable effort to insure that the moderated conference
does not distribute or promote illegal activities or information
as defined below in Section V Paragraph 2. The Moderator shall
be responsible for insuring that messages contained in the
conference corresponds to the conference theme. The Moderator
shall report any violations of this policy to the proper Echomail
coordinators and lodge any appropriate policy complaints as
provided for in policy documents adopted by Fidonet. The
Moderator shall post the conference rules in the conference at
least once a month. The Moderator is to authorize the
disconnection of the conference feed. Any Sysop the moderator
believes is violating policy shall be reported to the offending
node's nearest local echomail coordinator (may be a NEC, REC or
in extreme situations a ZEC); and the moderator shall formally
authorize the feed to the offending node to be severed. The
conference moderator is the sole judge - subject to review only
by the ZEC (or his delegates) if a complaint is filed by the
banished party. The Moderator may request in direct written form
(netmail) that the *ECs disconnect a node from the conference
when that node refuses to follow the published conference rules
after at least 3 warnings. Knowingly feeding a conference to a
node that has been severed by the Moderator is considered a
violation of this echomail policy and is subject to suspension.
The length of this suspension will be determined by a joint
decision of the conference moderator and the nearest local echo
coordinator of the node illegally feeding the conference to the
original offending node or point.
Echo conference complaints from a Sysop should be filed at the
net level (NEC) or if the complaining party is an independent
node then with their REC. The NEC or REC receiving such a
complaint must take action in accordance with the provisions of
this echomail policy.
For severe or chronic infractions the NEC, REC or ZEC may file
a complaint under general Fidonet policy for excessively annoying
behaviour.
IV. APPOINTMENT AND ELECTION OF ECHOMAIL COORDINATORS AND
MODERATORS.
1. GRANDFATHER CLAUSE: Those Zone, Regional, and Net Echomail
Coordinators and Echomail Coordinators currently holding these
positions as of the date of acceptance of this Echomail Policy
shall continue to service in said capacity until resignation or
replacement under this policy.
2. ELECTION OF ZONE ECHOMAIL COORDINATOR: The ZEC shall be
elected as follows:
a) upon resignation or replacement of the existing ZEC, the
FidoNet Zone Coordinator (ZC) shall nominate at least five
individuals to be voted upon.
b) 10 days after the nominees are selected, an election
shall be held. The ZEC will be elected by a simple majority
of IC, ZC, RCs, NCs, RECs, and NECs in their Fidonet zone.
An individual holding more than one position can only cast
one vote. That is, if an individual is both a NC and a NEC,
they may cast only one vote.
3. ELECTION OF REGIONAL ECHOMAIL COORDINATOR: The REC shall be
elected as follows:
a) upon resignation or replacement of an existing REC, the
ZEC shall nominate at least 3 individuals for election.
b) 10 days after the nominees are selected, an election
shall be held. The REC will be elected by a simple majority
of the RC, NCs and NECs in their FidoNet Region. An
individual holding more than one position may only cast one
vote.
4. NET ECHOMAIL COORDINATOR: The NEC shall be appointed by the
FidoNet Net Coordinator (NC) or in such alternative manner as
determined by the NC. If a NEC is not appointed within 30 days,
the REC will appoint the NEC.
5. REMOVAL OF A *EC: A *EC may be removed from their position
by a simple majority of those allowed to vote for their
successor. For a NEC, the members of the Net may vote by simple
majority to remove the NEC. The position directly above (in the
*EC structure) will oversee the recall election in the same
manner as prescribed for electing successors.
A *EC may only be subject to recall for failure to properly carry
out their duties described above, or if they are no longer a
member of Fidonet. A promise of 'free' echomail delivery from
another source is *not* considered an acceptable reason for
recall.
6. RECOGNITION OF CONFERENCES: The *EC corresponding to the
appropriate leve recognizes a conference at his level. Examples:
The NEC recognizes a conference as local. The REC recognizes a
conference to be regional. A ZEC recognizes a conference to be
zonal. The IC recognizes a conference to be inter-zonal.
7. REMOVAL OF AN ECHOMAIL CONFERENCE MODERATOR: An Echomail
Conference Moderator may be removed from their position by a
three fourths (3/4) vote of the *EC structure voting. This vote
must be carried out in a fair and decent manner while giving at
least ten (10) days notice to the entire *EC structure of the
upcoming vote. Notice mediums acceptable are: Netmail from the
ZEC, usage of international postings in such conferences as
COORD. Or in extreme instances, by REC to NEC written
notification.
An Echomail Conference Moderator may only be subject to recall
for failure to properly carry out their duties described above or
continued pre-meditated violation of this documents section V.
Statement of Policies as seen below. Failing to perform the
above duties of a conference moderator for a period of 3 or more
months and/or failing to designate a proxy in his absence shall
be in violation of this policy and be subject to recall. A vote
may only be callable by the ZEC (or his delegate). This delegate
should not be from the region or net of the affected conference
moderator.
Membership in Fidonet need not be a paramount issue, but is
highly recommended.
V. STATEMENT OF POLICIES
1. BASIC ECHOMAIL POLICY: The basic policy of Echomail is to
promote communication in Echomail Conferences in a lawful,
friendly manner consistent with the general principles of
FidoNet.
2. PROHIBITION ON ILLEGAL ACTIVITIES: Any Node which knowingly
distributes or allows to be entered into echomail conferences any
messages containing or promoting illegal activities or
information shall be deemed to have violated general FidoNet
policy as being excessively annoying. As used in this paragraph,
"illegal activities" includes activities which are a violation of
civil law as well as activities which would result in criminal
prosecution.
3. AUTOMATED CENSORSHIP: The use of Automated Censorship in the
passing or distribution of echomail will be considered a
violation of this policy and will not be tolerated. Disciplinary
action will be as referred to in General Fidonet policy as being
excessively annoying.
An exception to this provision shall be the deletion and not
censorship of messages by any Sysop which may lead to legal
action against that Sysop.
No echomail shall be modified in any manner which could
potentially cause duplicates.
4. INTER-NETWORK CONFERENCES: Inter-Net conferences shall
conform to general Fidonet policy as well as the provisions of
this policy document in addition to any foreign network's
provisions.
5. CHARGING FOR DISTRIBUTION: Any entity which makes a profit
from the distribution (passing from system to system) of echomail
shall be deemed to be excessively annoying and in violation of
Fidonet policy subject to enforcement under existing Fidonet
policy. Profit as defined in this paragraph is the charging for
echomail distribution that exceeds actual cost to obtain and
distribute the Echomail over a sustained period. The cost of the
equipment used to obtain and distribute echomail may not be
recovered. A Sysop that charges users for access to their BBS
shall NOT be in violation of this paragraph.
6. RESTRICTED DISTRIBUTION CONFERENCES: Participating Nodes
shall honor and support the restrictions placed upon restricted
distribution conferences. Violation of this restriction by
individual nodes and points shall be a violation of this echomail
policy and result in suspension of the violated echo in
accordance with the above paragraph in Section III Duties of the
Echomail Conference Moderators.
A SYSOP only conference shall be made available only to the
Sysops or Co-Sysops of Fidonet or other nets with which inter-net
conferences exist.
A violation of the restrictions placed on a RESTRICTED
DISTRIBUTION CONFERENCE will be a violation of this policy if and
only if the moderator has posted and specified the restrictions
governing the conference.
7. PATH REQUIRED: The PATHline, originally implemented by SEA
in the MGM package, is required except for terminal nodes. If
your current Echomail scanner supports the pathline you must
enable it NOW. If your current Echomail scanner does not support
the pathline, and if there is no alternative scanner, then
enforcement of this paragraph will be deferred for 60 days.
After that date, the *ECs may refuse to accept/supply echomail to
any node that is not supporting the pathline.
8. SEEN-BY LINE: Under the current technology and topology (the
routing structure of echomail), SEEN-BY lines play an important
part in reducing duplicate messages. Tiny SEEN-BYs will not be
allowed until the respective ZECs feel topology will allow their
use. Nor will the stripping of SEEN-BYs (except Zone-Gates and
Inter-Network EchoGates) be allowed unless approved by the ZEC.
Violation of the above shall be excessively annoying behavior
enforceable under general Fidonet policy. Zone-Gates and Inter-
Network EchoGates SHOULD strip the SEEN-BYs of the exporting Zone
or Network to reduce addressing conflicts.
9. COUNTERFEIT MESSAGES: Entering or knowingly distributing
counterfeit messages shall be considered excessively annoying and
a violation of Fidonet policy enforceable under the terms of
Fidonet policy. As used in this paragraph, a counterfeit message
is defined as any message entered using another person's name,
handle or node address with the intent of deceiving others about
the true author of the message. No handles shall be used to
enter messages to knowingly provoke, inflame, or upset
participants in a conference with the purpose of deceiving others
about the true identity of the author.
10. SYSOP'S RESPONSIBILITY: It is the responsibility of each
Sysop to make every reasonable effort to assure that the users on
his board conform to the provisions of this policy document. A
Sysop may be held responsible for the acts of his users unless
the Sysop can show that a reasonable attempt was made to conform
to this policy document.
11. ECHOMAIL SOFTWARE: EchoMail exchanges may consist of any
type of archival storage format agreed upon by both parties.
SEA's ARC 5.1 (non-Squashing) archival storage format will be the
"fallback" if either party is unable or unwilling to support an
alternate method. The continued use of Echomail software without
prior agreement of both the sending and receiving nodes which
interferes with the distribution of echomail shall lead to
disciplinary action as described previously in this document.
See Section III. Examples of prohibited software would include
the use of non-standard echomail packets which can not be
processed by the receiving system. Another example would be the
use of poorly implemented scanners or tossers that cause
duplicates or fail to forward messages to downstream links. A
further example is the use of Tiny seenby options and the use of
^A hidden SEEN-BY lines. Use of Echomail software which does not
conform to the minimum acceptable standards as defined by the
Fidonet Technical Standards Committee (FTSC) shall lead to
disciplinary action as described previously in this document.
The Software Certification Committee is authorized to determine
whether software meets minimum standards for use on the net.
12. HOST ROUTING OF ECHOMAIL: Host routing of Echomail without
the prior consent of both the Sending and Receiving Hosts shall
lead to disciplinary action as described previously in this
document. See Section III.
13. SENDING OF ECHOMAIL DURING ZONE MAIL HOUR: Transmission of
echomail during Zone Mail Hour as defined in Fidonet policy
without the consent of the receiving system shall lead to
disciplinary action as described previously in this document.
See Section III.
14. INTER-NETWORK CONFERENCES: It is the general policy of
Fidonet to encourage the development of INTER-NETWORK
CONFERENCES. It shall be the duty of those providing the INTER-
NETWORK CONFERENCE links to remove foreign net distribution
identifiers which will adversely effect the distribution of the
Echomail Conference while in Fidonet. The INTER-NETWORK
CONFERENCE links maintained in Fidonet shall be operated in a
manner not to interfere with the foreign network's distribution
of Echomail.
15. DEFAMATORY POSTING: The posting of any DEFAMATORY MESSAGE
other than in conferences dedicated to this purpose (i.e. FLAME)
shall lead to disciplinary action as described previously in this
document. See Section III. The posting of substantiated facts
shall not be considered a violation under this section.
16. ADDING OR REMOVING CONFERENCES FROM THE Backbone: A
conference may be added to the Backbone only by request of the
RECOGNIZED Conference Moderator. A conference may be removed
from the Backbone by lack of traffic. A committee composed of the
ZEC and 4 RECs shall review the status of backbone echos every 6
months. At which time those echos which have not maintained a
minimum 10 messages a week over the preceeding 6 months will be
noted and their Conference moderators will be contacted. These
conferences will be given 3 months to improve their traffic or
withdraw from Fidonet backbone distribution. The recognized
conference moderator may request removal of their conference from
the Fidonet backbone distribution at their discretion.
17. TOPOLOGY and DUPLICATE MESSAGES: Cross Regional links
should be avoided as they increase the risk of improper linking
and generation of duplicate messages. Cross Regional links may
be established only with the permission of the REC in each
region. Each REC will do their best to make available high speed
hubs, out of state hubs, PC Pursuit hubs, etc, to facilitate the
low cost, efficient movement of mail within their respective
Region. If either REC has reason to believe duplicates are being
introduced into the system, an existing Cross Regional link must
be immediately cut pending resolution.
Any Sysop who willfully and knowingly establishes links that
either create duplicate loops (topology that creates circular
feeds), increase the risk of such loops or who refuses to break
those links upon request by their NEC, REC or ZEC shall be
subject to disciplinary action as described previously in this
document. See Section III.
18. MESSAGE STANDARDS: Until the adoption of a superceding
standard by the Fidonet Technical Standards Committee, the
following Echomail message standards will apply:
a) Eight-bit characters (ASCII 128-255) and non-printing
low-order codes (ASCII 2-31) are prohibited, except the use
of 8Dh(soft character) per FTS-0004. This is not
intended to discourage participation of foreign zones or
networks, which may permit said characters. Any echomail
processor should pass information exactly as it was
received, without stripping any non-standard characters.
b) Origin lines are limited to 79 characters including the
required ending of a proper network address (i.e.
Zone:Net/Node.Point with zone and point being optional).
c) Tear lines are limited to 35 characters including the
required "--- " lead-in. These may ONLY contain packer or
editor program identification. Tear lines for message
editors are discouraged. If an editor adds a tear line, it
should also add an origin line to avoid multiple tear lines.
d) "Extra" origin lines (ZoneGating) are limited to
essential information only. This consists of the required
lead-in plus the network name "Gateway" and optionally the
software ID followed by a Zone:Net/Node address.
Example: " * Origin: FidoNet Gateway (TComm 88:372/666)"
e) SEEN-BY addresses must be in sorted order. Multiple
AKA's are not allowed in SEEN-BY lines unless you have more
than one address which processes mail. Or for one month
during change of an existing address (to avoid duplicates to
the previous address). Node 0 addresses should not be used
for echomail distribution.
f) All current FTSC specifications should be followed.
VI. ENFORCEMENT
Enforcement of this policy document shall be under the provisions
of General FidoNet policy. Complaints concerning Echomail
violations defined under this policy may be filed by the
aggrieved individual, the conference moderator or by any level of
Echomail Coordinator. All complaints made pursuant to this
policy must be made within 60 days of the date of occurrence or
discovery. Complaints shall be filed under the provisions of
Fidonet Policy, with a copy to the respective *EC.
Enforcement is immediate, with any currently existing software
allowed 60 days to conform (from the date EchoPol1 goes into
effect). A 30-day extension may be granted solely at the
discretion of the ZEC if efforts to bring about compliance are
clear. Continued use of aberrant software after this period
shall be deemed excessively annoying.
VII. ADOPTION OF POLICY
1. ADOPTION: This policy shall become effective upon
ratification by a simple majority of those voting. Those
eligible to vote shall be the IC, ZCs, RCs, NCs, ZECs, RECs, and
NECs. Those individuals holding more than one position can cast
only one vote.
2. GRANDFATHER CLAUSE: Within 60 days of adoption of this
policy, moderators shall be appointed for all existing Echomail
Conferences which do not now have a moderator. Moderators shall
be appointed by the ZEC from those volunteering as moderator or
if no volunteer is available then the ZEC shall request and
appoint a moderator for the conference. In the case where more
than one individual claims to be the conference moderator and no
agreement can be reached, the ZEC may order the conference
retired and ban the further use of the specific conference name.
Failure of the individuals to retire the conference name shall be
deemed excessively annoying behavior.
VI. BACKBONE STRUCTURE
This section is for information purposes only. It gives a plain
English description of the current structure and operation of the
Backbone. The ZEC may change this structure without amending
this document.
At the top of the Echomail distribution network, there are
systems commonly called Stars. These systems are usually
dedicated to passing Echomail. The stars operate at the
discretion and direction of the ZEC. At the time of this writing
there are 3 stars, each has a backup system/plan in the event of
a failure. In general, the Stars link to one another and feed
the RECs.
The RECs are then responsible for distribution of the echomail
within their Region. Normally, the REC will feed the NECs in
that region.
The NEC is responsible for distribution of Echomail to the
individual Sysops within a net.
Note that the RECs and NECs can appoint Hubs to help in the
distribution of Echomail. That is, they do not have to directly
feed the lower level.
This is the distribution GOAL. Because of less expensive phone
rates and other reasons, this distribution method is not followed
exactly. Any change to the above requires agreement of the *EC's
involved. All *ECs will use all the tools at their disposal,
such as hubs, high speed modems, ROA, Wide Area Calling plans, PC
Pursuit, corporate sponsorship, etc., to provide fast, efficient,
and cost effective movement of echomail.
Echopol Committee
Mike Ratledge
Norm Henke
Rick McWilliams
Barry Shatswell