Beijing Paradise BBS Backup/PARADISE.ISO/software/BBSDOORW/ECHOPOL1.ZIP/ECHOPOL1.TXT

Text File | 1989-02-27 | 29.7 KB | 617 lines

                   GENERAL ECHOMAIL POLICY 1
                        March 1st, 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
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  <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)   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