Text 3672, 294 rader
Skriven 2004-12-20 03:52:26 av FidoNews Robot (2:2/2.0)
Ärende: FidoNews 21:51 [04/09]: General Articles
================================================
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 <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
--- Azure/NewsPrep 3.0
* Origin: Home of the Fidonews (2:2/2.0)
|