Draft -:- Draft -:- Draft -:- Draft -:- Draft -:- Draft
Draft Revision 2.008
Changes by John Souvestre, 1:396/1, on February 26, 1991
Draft -:- Draft -:- Draft -:- Draft -:- Draft -:- Draft
ZONE ONE BACKBONE ECHOMAIL POLICY 2.0
PROLOGUE
This document sets forth policy governing Zone One Backbone
Echomail Conferences and any other echomail conferences for
which the Moderator desires it to be applicable.
If any item in this policy is in conflict with any existing or
subsequent General Fidonet Policy, then General Fidonet Policy
will be in effect. At the time it is written, this policy is
an extension to Fidonet Policy 4, Section 9.9.
This policy addresses echomail at the zone level. Regions may
issue their own echomail policies, except that they may not
conflict with this one. Nets may also issue their own echomail
policies, except that they may not conflict with their region's
echomail policy or with this one.
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 at the zone level, the
Backbone was formed. 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. GENERAL FIDONET POLICY: The document which governs Fidonet
as adopted by Fidonet. The document as of this writing is Policy
4 and is subject to change. This Echomail Policy is intended to
become a part of General Fidonet Policy, as it pertains to
echomail in Zone One. Until it is incorporated into General
Fidonet Policy, this policy shall serve to define policy
violations occurring in echomail.
2. NODE: A Fidonet member, as per General Fidonet Policy.
3. ECHOMAIL: A form of mail in which message bases are shared
between independent systems with unique Net/Node addresses.
4. ECHOMAIL CONFERENCES: An echomail conference is a message
base or forum, distributed under a specified echomail conference
name, dealing with a defined area of interest. Echomail
conferences are hereafter referred to simply as conferences.
Examples include COMM, an inter-zone telecommunications
conference, and POLITICS, a zone level political conference.
5. ZONE ECHOMAIL COORDINATOR: This individual is responsible
for coordination of echomail at the zone level. The Zone
Echomail Coordinator is hereafter referred to simply as the ZEC.
6. REGION ECHOMAIL COORDINATOR: This individual is responsible
for coordination of echomail at the region level. The Region
Echomail Coordinator is hereafter referred to simply as the REC.
7. ECHOMAIL HUBS: These are individuals who distribute
echomail. The Echomail Hubs are hereafter referred to simply as
Hubs. The Zone Hubs distribute echomail at the zone level. The
Region Hubs distribute echomail at the region level. The Net
Hubs distribute echomail at the net level.
8. CONFERENCE MODERATORS: These individuals preside over
conferences. Conference Moderators are hereafter referred to
simply as Moderators.
9. RESTRICTED DISTRIBUTION CONFERENCE: A restricted
distribution conference is one which is restricted only to
eligible recipients. Examples include MODERATOR, a pre-register
conference for Moderators, and MEADOW, a conference for Opus
Sysops.
10. ZONE ONE ECHOMAIL BACKBONE: The Zone One Echomail Backbone
consists of Zone Hubs who distribute echomail to the region
level. The Zone One Echomail Backbone is hereafter referred to
simply as the Backbone.
11. ZONE ONE ECHOMAIL CONFERENCE LIST: The Zone One Echomail
Conference List identifies the registered zone level conferences.
The Zone One Echomail Conference List is hereafter referred to
simply as the Echolist.
12. ZONE ONE ECHOMAIL CONFERENCE LIST COORDINATOR: This
individual is responsible for the Zone One Echomail Conference
List. The Zone One Echomail Conference List Coordinator is
hereafter referred to simply as the Zone Echolist Coordinator.
13. ECHOMAIL GATEWAYS: These are Fidonet members whose systems
are used to exchange mail with other groups. The term Echomail
Gateway, as used hereafter, shall include all forms of gating,
including, but not limited to, zone-gating, inter-network gating,
and domain-gating.
14. VOTE: Any vote must be carried out in a fair and decent
manner while giving at least 14 days notice to those eligible to
vote, of the upcoming vote. A good faith attempt must be made to
make all eligible voters aware that a vote is occurring and make
available all necessary information.
15. SIMPLE MAJORITY: The term simple majority means more than
50 percent of those voting.
III. DUTIES OF ZONE ECHOMAIL COORDINATOR, ZONE ECHOLIST
COORDINATOR AND MODERATORS
1. DUTIES OF ZONE ECHOMAIL COORDINATOR: The ZEC shall
coordinate echomail distribution at the zone level. This
includes coordinating the transmission and routing of echomail so
that it is done in a manner so as to avoid creation of duplicate
messages within a conference.
The ZEC shall make available, to any region, any conference which
that region is eligible to receive. If for any reason the ZEC
does not have access via recognized distribution channels to a
specific conference, he can not be expected to provide it.
An exception is that the ZEC is not required to make available
any conference which routinely contains messages which are
encrypted or illegal.
Nothing in this provision requires that a ZEC or Zone Hub must
import any conference to the extent of adverse economic impact.
The ZEC shall recognize conferences at the zone level. The ZEC
shall maintain a list of available conferences at the zone level
as well as the requirements of each conference as supplied by the
Moderator (Echolist).
The ZEC shall appoint Zone Hubs to distribute echomail at the
zone level. The ZEC may also serve as a Zone Hub, but is not
required to do so. A Zone Hub takes on that subset of the ZEC's
duties, as defined by the ZEC, for those Nodes he feeds.
The ZEC shall insure that all downstream links are educated as to
this policy and shall monitor compliance with this policy at the
zone level.
2. DUTIES OF ZONE ECHOLIST COORDINATOR: The Zone Echolist
Coordinator shall compile and make available the Echolist. This
is a registry of zone level and inter-zone conferences, updated
monthly, and optionally, conferences at various other levels.
The content and format of the Echolist will be at the sole
discretion of the Zone Echolist Coordinator, except that it shall
include the conference name, the Moderator's name, the
Moderator's Fidonet address, a general description of the
conference topic, eligibility requirements for restricted
conferences, network of origin for conferences which originate
outside of Fidonet, distribution plan if other than via the
Backbone, and rules for each conference.
3. DUTIES OF MODERATORS: Moderators shall make, in good faith,
every reasonable effort to insure that their conferences do not
distribute or promote illegal activities or information as
defined in Section V, Paragraph 2.
Moderators shall publish the conference rules in their
conferences at least once a month.
Moderators shall be responsible for seeing that messages
contained in their conferences correspond to the conference's
theme.
Moderators shall not fail to perform their duties for a period of
more than 10 days without failing to designate proxies.
Moderators shall report any violations of this policy to the
proper Echomail Coordinators and lodge any appropriate policy
complaints as provided for in General Fidonet Policy.
If a Moderator believes that a Node is violating a conference
rule, he may may authorize the feed to that Node be severed.
This authorization shall be made in direct written form
(netmail), to the Hub feeding the offending Node, with a copy to
the offending Node.
IV. SELECTION OF ZONE ECHOMAIL COORDINATOR, ZONE ECHOLIST
COORDINATOR AND MODERATORS
1. GRANDFATHER CLAUSE: The ZEC, Zone Echolist Coordinator and
Moderators currently holding these positions as of the date of
acceptance of this Echomail Policy shall continue to serve in
said capacity until resignation or replacement under this policy.
For the purpose of calculating the term of office, such term will
be deemed to have started on the date that this policy goes into
effect.
2. SELECTION OF THE ZONE ECHOMAIL COORDINATOR: The ZEC shall
serve for a term of 1 year. He shall be elected as follows:
A) Upon resignation or replacement of the existing ZEC,
the Zone Coordinator (ZC) shall oversee the election of
the new ZEC.
B) 14 days after the nominees are selected, an election
shall be held. The ZEC will be elected by a simple
majority of the RECs.
The current ZEC can be identified from the 1/200 listing in the
Nodelist.
3. REMOVAL OF THE ZEC: The ZEC may be removed from his position
by a simple majority of the RECs. The ZC will oversee the recall
election in the same manner as prescribed for electing the ZEC.
The ZEC may only be subject to recall for failure to properly
carry out his duties described above, or if he is no longer a
member of Fidonet. A promise of "free" echomail delivery from
another source is not considered an acceptable reason for recall.
A ZEC may be removed by the ZC for continued violations of policy
or for gross misconduct.
4. SELECTION OF THE ZONE ECHOLIST COORDINATOR: The ZEC shall
appoint the Zone Echolist Coordinator.
The current Zone Echolist Coordinator can be identified from the
1/201 listing in the Nodelist.
5. SELECTION OF A MODERATOR: A Moderator shall be selected as
follows:
A) Upon formation of a conference, the person who forms
the conference is the Moderator.
B) Upon resignation or replacement of an existing
Moderator, the conference's rules shall define how the
new Moderator is selected.
A Moderator need not be a member of Fidonet, but it is highly
recommended. A Moderator should have access to netmail.
V. STATEMENT OF POLICIES
1. BASIC ECHOMAIL POLICY: The basic policy of echomail is to
promote communication in conferences in a lawful, friendly manner
consistent with the general principles of Fidonet.
2. PROHIBITION ON ILLEGAL ACTIVITIES: Knowingly distributing,
or allowing to be entered into conferences any messages
containing or promoting illegal activities or information, is a
serious violation of this policy. 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. CENSORSHIP: Removing a message from a conference, or
altering its contents, in the passing or distribution of
echomail, is considered a serious violation of this policy.
An exception to this provision is the deletion of messages, by
any Node, which may lead to legal action against that Node.
Textual changes to such messages are not allowed.
An additional exception to this provision is the deletion of
messages, by any Node, which do not meet the echomail message
standards in Section V, Paragraph 14. Textual changes to such
messages are not allowed.
Under no circumstances shall echomail be modified in any manner
which could potentially cause duplicates.
4. COUNTERFEIT MESSAGES: Entering or knowingly distributing
counterfeit messages is a serious violation of this policy. 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.
5. CHARGING FOR DISTRIBUTION: Any entity which makes a profit
from the passing or distribution of echomail shall be deemed to
be excessively annoying and in violation of General Fidonet
Policy. Profit is defined as the charging for echomail
distribution in excess of the actual cost to obtain and
distribute the echomail over a sustained period. The cost of the
equipment used to obtain and distribute echomail may only be
recovered on a strictly voluntary basis. Nodes who charge users
for access to their BBSs 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 is a violation of this policy and shall result
in suspension of that Node from the violated echo in accordance
with Section III.
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 the restrictions governing
the conference both in the conference and in the EchoList.
A Sysop-only conference shall be made available only to the
Sysops or Co-Sysops of Fidonet or other networks with which
inter-network conferences exist. Operators of Point systems are
not considered Sysops.
7. PATHLINE OPTION: The PATHline (as defined in FTS-0004), is
recommended for all Nodes. If your current echomail scanner
supports the pathline you should enable it. While the pathline
does not eliminate duplicate messages, it can be a very useful
tool in determining where a topology problem exists.
Hubs must implement the PATHline option. Since these Nodes are
operating beyond the scope of the typical Node, they are required
to implement features that are otherwise optional.
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 ZEC feels that the topology allows their use.
The stripping of SEEN-BYs (except by Echomail Gateways) is not
allowed unless approved by the ZEC. Echomail Gateways shall
strip the SEEN-BYs of the exporting group to reduce addressing
conflicts.
9. NODE'S RESPONSIBILITY: It is the responsibility of each
Node to make every reasonable effort to assure that the users on
his board conform to the provisions of this Policy. A Node may
be held responsible for the acts of his users unless the Node can
show that a reasonable attempt was made to conform to this
policy.
10. ECHOMAIL SOFTWARE: using echomail software which does not
conform to the minimum acceptable standards as defined by the
Fidonet Technical Standards Committee (FTSC), and by this
Section, is a violation of this policy.
11. INTER-NETWORK CONFERENCES: It is the general policy of
Fidonet to encourage the development of Inter-Network
Conferences. Inter-Network Conferences shall conform to General
Fidonet Policy, as well as the provisions of this policy, in
addition to any foreign network's provisions.
It shall be the duty of those providing the Inter-Network
Conference links to remove foreign network distribution
identifiers which will adversely effect the distribution of the
conference while in Fidonet. The Inter-Network Conference links
maintained in Fidonet shall be operated such that they do not
interfere with the foreign network's distribution of echomail.
Conferences which originate outside of Fidonet must be designated
as such in the Echolist.
Echomail Gateways must be able to pass netmail through the
Gateway into the other network, unless it is technically
impossible to do so.
12. ADDING OR REMOVING CONFERENCES FROM THE BACKBONE: A
conference may be added to the Backbone only at the request of
the Moderator. A conference must have a Moderator, be listed in
the Echolist, and its addition requested by two or more RECs,
before it is added to the Backbone by the ZEC.
The Moderator may, at his discretion, remove his conference from
the Backbone.
A conference will be removed from the Backbone when fewer than 2
RECs carry it. A conference may also be removed from the
Backbone due to lack of traffic (under 10 messages per month,
averaged over a two month period).
A conference is subject to removal from the Backbone when the
Moderator fails to properly carry out his duties, as described as
described in Section III, or violates Section V.
13. TOPOLOGY and DUPLICATE MESSAGES: Cross-region links should
be avoided as they increase the risk of improper linking and
generation of duplicate messages. Cross-region links may only be
established with the prior knowledge of the RECs in both regions.
If a REC determines that a cross-region link is contributing to
the creation of duplicate messages, the REC may require that the
link be terminated.
The use of the PATHline option is required for all out-of-region
links.
The ZEC shall use all the tools at his disposal, such as high
speed Hubs, out-of-state Hubs, packet switching network Hubs,
Wide Area Calling plans, corporate sponsorship, etc., to
facilitate fast, efficient and cost effective movement of
echomail.
Willfully and knowingly establishing links that either create
duplicate loops (topology that creates circular feeds) or
refusing to break such links upon request by the ZEC is a serious
violation of this policy.
14. ECHOMAIL MESSAGE STANDARDS: Until the adoption of a
superseding standard by the Fidonet Technical Standards
Committee, the following echomail message standards are
recommended:
A) Eight-bit characters (ASCII 128-255) and non-printing
low-order codes (ASCII 2-31) are prohibited, except the
use of 8Dh(soft <CR> 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) There should be only one tear line in a message. Tear
lines should be limited to 25 characters including the
required "--- " lead-in. Tear lines should 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.
C) There should be only one origin line in a message,
except as noted in the next paragraph. Origin lines
should be limited to 79 characters including the
required " * Origin: " lead-in and ending of a proper
network address (i.e. Zone:Net/Node.Point with zone and
point being optional), enclosed in parenthesis.
D) "Extra" origin lines are allowed when a message is
gated. The original origin line's lead-in should be
changed to " # Origin: ", and the Echomail Gateway's
origin line added. There may be more than one extra
origin line in the case that a message passes through
multiple Echomail Gateways. The Echomail Gateway's
origin line is limited to essential information only.
This consists of the required lead-in, the network name,
"Gateway", a proper Fidonet address (i.e. Zone:Net/Node
with zone being optional), enclosed in parenthesis.
Example: " * Origin: TComm Gateway (1:372/666)".
E) SEEN-BY addresses should be in sorted order. 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 must be followed.
15. NETMAIL ROUTING: It is important that users have access to
routed netmail in order to facilitate private replies to echomail
messages. This helps reduce overall echomail message volume by
allowing off-topic replies, flames and other types of messages
which don't belong in the conference, to be sent via routed
netmail.
Until such time as a new General Fidonet Policy is adopted which
defines and codifies the routed netmail scheme, the following
shall be in effect:
A) Zone Hubs shall accept routed netmail from any Node
or Hub who exchanges Backbone conferences with them.
Routed netmail may be routed along echomail paths, or to
a ZC, RC, or NC who has agreed to handle such mail.
B) At the present time, routed netmail is provided by
both the Coordinator and Echo Coordinator structures.
The ZEC shall cooperate with the Coordinators and the
Echo Coordinators in further developing and maintaining
a routed netmail scheme.
16. FEEDING SEVERED NODE: Knowingly feeding a conference to a
Node who has been severed for violations of this policy or at
the request of the Moderator, where such feed is intended to
subvert either the provisions of this policy or the authority of
the moderator, is considered a serious violation of this policy.
VI. ENFORCEMENT
Enforcement of this policy shall be under the provisions of
General Fidonet Policy. Serious violations of this policy shall
be considered excessively annoying under General Fidonet Policy.
Complaints concerning violations defined under this policy may be
filed by the aggrieved individual, the Moderator or by any level
of Echomail Coordinator to the appropriate IC, ZC, RC or NC
level. 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 General Fidonet
Policy, with a copy to the ZEC or respective REC, as appropriate.
Enforcement of this policy is immediate, with any currently
existing software allowed 90 days to conform (from the date this
policy goes into effect). 30 day extensions 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 is a serious violation of this policy.
VII. CHANGES
Future changes to Echo Policy may be proposed by any Node, by
submitting the proposal to their REC. The REC will then
determine if the proposal should be brought before the rest of
the RECs. If an REC decides not to bring a proposed change
before the rest of the RECs, a message stating why must be sent
to the Node. If 10% or more of the NECs in a region request that
a proposal be brought before the RECs, then that proposal must be
submitted to the RECs.
A simple majority vote of the RECs is required in order for a
proposal to be formally voted on. If 10% or more of the NECs in
the zone request that a proposal be formally voted on, then that
proposal must be formally voted on.
Those eligible to vote on any proposals made by the REC structure
will be the ZEC, RECs and NECs. Those individuals holding more
than one position can cast only one vote. Adoption of changes
will require a two thirds (2/3) majority of those voting to pass.
VIII. 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 policy.
At the top of the echomail distribution network, there are two or
three Zone Hubs, sometimes called Stars. These Nodes are usually
dedicated to distributing echomail. Each has a backup plan in
the event of a failure. The Zone Hubs link to one another and
feed the Region Hubs.
Ideally, each region would have a Region Hub feeding from each of
the Zone Hubs. This provides redundancy and allows quick
recovery in the case of a Zone Hub or Region Hub failure.
IX. REGION AND NET ECHOMAIL POLICIES
Regions and nets may issue their own echomail policies, within
the constraints described in the Prologue of this policy. In the
absence of any such policy, the following defaults shall apply.
These defaults should not be viewed as constraints on a region or
net policy.
A) The duties of the REC and NEC (Net Echo Coordinator)
shall be similar to the duties of the ZEC, as defined in
Section III, except that the scope will be the region or
net, as appropriate. The same is true for Region and
Net Hubs. There is no need for a Region or Net Echolist
Coordinator. but the REC and NEC shall maintain lists of
available conferences.
B) A REC and NEC shall make available any conference to
qualified lower distribution levels. Nothing in this
provision requires that a REC or NEC must import any
conference to the extent of adverse economic impact. A
Node should expect to share expenses incurred on his
benefit. It is recommended that cost sharing
arrangements be employed. When expenses are reimbursed,
any conference on the Backbone must be made available
(other than restricted conferences) when requested.
C) Grandfathering, and the selection and removal of the
REC and NEC shall be similar to the grandfathering and
selection and removal of the ZEC, as defined in Section
IV, except that the scope will be the region or net, as
appropriate. The current RECs can be identified from
the 1/2xx ("xx" is the region number) listings in the
Nodelist. They can also be identified from the REC user
flags in the Nodelist. The current NECs can be
identified from the NEC user flags in the Nodelist.
D) Region and Net Hubs shall accept routed netmail from
any Node or Hub who exchanges Backbone conferences with
them. Routed netmail may be routed along echomail
paths, or to a ZC, RC, or NC who has agreed to handle
such mail.
Draft -:- Draft -:- Draft -:- Draft -:- Draft -:- Draft
Suggestions are welcome!
Please send to your REC or to 1:396/1.
Draft -:- Draft -:- Draft -:- Draft -:- Draft -:- Draft