============================================================
Die "GENERAL ECHOMAIL POLICY 1", Stand von 1. Februar 1989
------------------------------------------------------------
Deutsche Uebersetzung von Dirk Richartz aka 2:2433/601.7
Release: EP1-D-02.TXT, vom 25.8.96
============================================================

INHALTS-UEBERSICHT
------------------

a.1.          Vorwort des Uebersetzers

a.2.          prologue

1.1.       I. history

1.2.      II. definitions
1.2.1      1. echomail
1.2.2      2. echomail conferences
1.2.3      3. moderated conference
1.2.4      4. sysop-only conference
1.2.5      5. restricted distribution conferences
1.2.6      6. zone echomail coordinator (ZEC)
1.2.7      7. regional echomail coordinator (REC)
1.2.8      8. net echomail coordinator (NEC)
1.2.9      9. echomail backbone
1.2.10    10. national echomail list
1.2.11    11. automated censorship
1.2.12    12. fidonet policy
1.2.13    13. open access conference
1.2.14    14. terminal node

1.3.     III. duties of echomail coordinators
1.3.1      1. general
1.3.2      2. duties of zone echomail coordinator
1.3.3      3. duties of regional echomail coordinator
1.3.4      4. duties of net echomail coordinator
1.3.5      5. duties of echolist coordinator
1.3.6      6. duties of echomail conference moderator

1.4.      IV. appointment and election of echomail
              coordinators and moderators.
1.4.1      1. grandfather clause
1.4.2      2. election of zone echomail coordinator
1.4.3      3. election of regional echomail coordinator
1.4.4      4. net echomail coordinator
1.4.5      5. removal of a *EC
1.4.6      6. recognition of conferences
1.4.7      7. removal of an echomail conference moderator

1.5.       V. statement of policies
1.5.1      1. basic echomail policy
1.5.2      2. prohibition on illegal activities
1.5.3      3. automated censorship
1.5.4      4. inter-network conferences
1.5.5      5. charging for distribution
1.5.6      6. restricted distribution conferences
1.5.7      7. path required
1.5.8      8. seen-by line
1.5.9      9. counterfeit messages
1.5.10    10. sysop's responsibility
1.5.11    11. echomail software
1.5.12    12. host routing of echomail
1.5.13    13. sending of echomail during zone mail hour
1.5.14    14. inter-network conferences
1.5.15    15. defamatory posting
1.5.16    16. adding or removing conferences from backbone
1.5.17    17. topology and duplicate messages
1.5.18    18. message standards

1.6.      VI. enforcement

1.7.     VII. adoption of policy
1.7.1      1. adoption
1.7.2      2. grandfather clause

1.8.    VIII. backbone structure

============================================================

a.1.    VORWORT DES UEBERSETZERS

In diesem Text sind einige Kuerzel enthalten. (Verzeiht
mir:) Einige der verwendeten Kurzbezeichnungen:

EP1     = General Echomail Policy
EM      = Echomail
NM      = Netmail
MOD     = Echomail-Moderator
Echo    = Echomail-Konferenz
P3      = General Fidonet Policy, Version 3.x
P4      = General Fidonet Policy, Version 4.07
BB      = Backbone structure
ZEC     = Zone Echomail Coordinator
REC     = Region Echomail Coordinator
NEC     = Net Echomail Coordinator

"Diese Uebersetzung erhebt keinen Anspruch darauf, perfekt
zu werden. Weite Abschnitte werden lediglich meine
Interpretation sein.

Es ist mein Ziel, den Wortlaut der EP1 fuer diejenigen
FIDO-Teilnehmer verstaendlich zu machen, die in der
englischen Sprache nicht firm sind, wobei ich mich so nahe
wie moeglich am eigentlichen Wortlaut halten werde.

Diese Uebersetzung ist nicht dazu gedacht, bei
Streitigkeiten eventuelle fidorechtliche Spitzfindigkeiten
zu beweisen; dafuer sollte das jeweils gueltige, englische
Original herangezogen werden.

Moenchengladbach, April 1996,
Dirk Richartz, aka 2:2433/601.7"


a.2.    EINLEITUNG

Die EP1 ist die Fortsetzung der Bestimmungen ueber Echomail
in der aktuellen General Fidonet Policy.

EP1 betrifft Echos und deren Verteilung. Sie ist fuer alle
Echos der Zone 1 gueltig, die im "Backbone" gelistet sind
und fuer jedes andere Echo, fuer das der Moderator es so
bestimmt.

Zukuenftige Aenderungen koennen nur durch einfachen
Mehrheitsbeschluss der RECs eingebracht werden. Ueber einen
entsprechenden Vorschlag der REC-Struktur stimmen ZEC, RECs,
NECs, NCs, RCs und IC ab. Nur eine Stimme pro Person ist
erlaubt. Eine Annahme der Aenderungsvorschlaege bedarf einer
einfachen Mehrheit der Wahlberechtigten.

In diesem Dokument bedeutet eine "einfache Mehrheit" mehr
als 50% der Waehler [50% + 1 Stimme]. Alle potentionellen
Waehler muessen nach besten Kraeften [und fruehzeitig]
darueber informiert werden, dass eine Wahl stattfindet, und
es muss jede Information darueber verfuegbar gemacht werden.

1.1.    I. HISTORY

"Echomail" (EM) ist der Austausch von Nachrichtenpaketen
oder Konferenzen zwischen verschiedenen, unabhaengigen
Netzwerkadressen.

Das eigentliche "Echomail-Konzept" startete mit einer Reihe
von Programmen von Jeff Rush. Seither haben viele Autoren
Programme geschrieben, die die originale Idee verfolgen.

Ganz entgegen den Befuerchtungen, das Aufkommen der Echomail
wuerde die Netmail derart aufblaehen, dass das Netz unter
seinem eigenen Gewicht zusammenbraeche, war [und ist]
Echomail ein grosser Erfolg.

Um die Verteilung von EM zu vereinfachen, wurde ein
nationaler Echomail-Backbone geformt, dessen vorrangiger
Zweck die Verteilung auf nationaler Ebene ist. Zur Sprache
gebracht werden muss der generoese Beitrag zum Backbone, den
die "Echomail Star Systeme" geleistet haben.

Als Resultat steigenden Wachstums und EM Volumens wurde es
noetig, eine formelle Police, die EM betreffend,
festzulegen. (EP1)


1.2.    II. DEFINITIONEN

1.2.1   1. ECHOMAIL:
Der Prozess, Nachrichtenpakete zwischen unabhaengigen
Systemen mit eindeutigen Netzadressen auszutauschen.

1.2.2   2. ECHOMAIL KONFERENZ:
Dies ist ein Forum oeffentlicher Nachrichten, das unter
einem spezifizierten Konferenznamen, aus der sich das
definierte Interessengebiet ergibt, verbreitet wird. (*1)

1.2.3   3. MODERIERTE KONFERENZ:
Eine moderierte Konferenz ist ein Echo, fuer die ein MOD
berufen wurde, der den Fluss und den Inhalt des Echo
ueberwachen soll. Alle Echos, die auf dem Backbone
aufliegen, muessen moderiert sein.

1.2.4   4. KONFERENZEN NUR FUER SYSOP:
Bei einem solchen Echo hat der MOD entschieden, dass es nur
Sysops zugaenglich gemacht wird, und nicht allen Usern.

1.2.5   5. KONFERENZEN MIT BESCHRAENKTER VERTEILUNG
Eine solches Echo ist nur ausgesuchten Empfaengern
zugaenglich. Beispiel: MODERATOR.GER

1.2.6   6. ZONE ECHOMAIL COORDINATOR (ZEC):
Diese Person ist verantwortlich fuer die Koordination der EM
auf zonaler FIDO-Ebene.

1.2.7   7. REGIONAL ECHOMAIL COORDINATOR (REC):
Diese Person ist verantwortlich fuer die Koordination der EM
in seiner Region.

1.2.8   8. NET ECHOMAIL COORDINATOR (NEC):
Diese Person ist verantwortlich fuer die Koordination der EM
auf lokaler Netzebene. (*2)

1.2.9   9. ECHOMAIL Backbone:
Der BB besteht aus freiwilligen Mitgliedern, die Dienste
anbieten um die nationale EM-Verteilung zu optimieren. Der
BB umfasst Nodes, die ein hohes EM-Aufkommen verarbeiten und
fuer die Verteilung der EM zu den naechstunteren regionalen
Leveln verantwortlich sind.

1.2.10  10. NATIONALE ECHOMAIL LISTE:
Diese Liste zeigt die verfuegbaren, nationalen Konferenzen
auf, ihren Moderator und besondere Anforderungen der
jeweiligen Konferenz. Der ZEC ernennt die Person, die die
Nationale Echoliste verwaltet.

1.2.11  11. AUTOMATISCHE ZENSUR:
Der Ausdruck automatische Zensur bezieht sich auf Programme,
die Nachrichten aus den entsprechenden Konferenzen entfernen
oder deren Inhalt manipulieren.

1.2.12  12. FIDONET POLICY:
Das Dokument, das Fidonet regelt (leitet), so wie es vom
Fidonet angenommen (bestimmt) wurde. Dies ist momentan die
Version 3 und wird gerade geaendert. Diese EP1 soll ein
Bestandteil der P3 werden. Bis das geschehen ist, soll
dieses Dokument dazu dienen, in EM auftretende
Policy-Verletzungen zu definieren. [aktuell ist zur Zeit die
Version 4.07 (P4)]

1.2.13  13. OPEN ACCESS CONFERENCE:
(Konferenz ohne Zugriffsbeschraenkung) Dies ist eine
Konferenz, die fuer alle Teilnehmer zugaenglich ist, die
sich an die veroeffentlichten Konferenzregeln halten.

1.2.14  14. TERMINAL NODE:
Ein System, das keine EM fuer andere Systeme zur Abholung
bereitlegt.


1.3.    III. Pflichten der Echomail Koordinatoren (*EC)

1.3.1   1. ALLGEMEINES:
Es ist die Pflicht der *EC, jedes Echo jedem SysOp zur
Verfuegung zu stellen, der nicht vom jeweiligen Moderator
vom Bezug dieses Echos ausgeschlossen ist.

Sollte der *EC aus irgendeinem Grund ein bestimmtes Echo
ueber die bekannten Kanaele nicht bekommen koennen, so darf
nicht von ihm erwartet werden, es zu
besorgen/weiterzureichen.

Ist ein *EC nicht in der Lage einem berechtigten Empfaenger
jedes (ein, irgendein, irgendwelche?) Echo/s zu verschaffen,
wird das als Verletzung der aufgetragenen Pflichten seines
Amtes angesehen. Dies ist Grund fuer eine Absetzung, wie in
diesem Dokument beschrieben.

Das heisst aber nicht, dass ein *EC jede Konferenz
ungeachtet einer oekonomischen Verhaeltnismaessigkeit
importieren muss. Es wird angeraten, dass eine
Kostenbeteiligung vereinbart wird. Wo es finanziell fuer den
Verteiler vertretbar ist, muss jede Konferenz, die auf dem
Backbone gelistet ist, zur Verfuegung gestellt werden, wenn
sie angefordert wird (im Gegensatz zu eingeschraenkten
Konferenzen)

Eine Ausnahme liegt dann vor, wenn ein *EC einen Link
unterbricht um den nichtauthorisierten Emfpang einer
Konferenz zu beenden. In diesem Fall koennen authorisierte
Nodes zeitweise ihren Link verlieren.

Ein *EC soll nach besten Kraeften sicherstellen, dass:
1. Alle downlinks von EP1 unterrichtet werden.
2. Downlinks wissen, wie sie sich korrekt in ein Echo
   einlinken
3. Akzeptables und unankzeptables Benehmen in Echos erklaert
   wurde
4. Downlinks keine Routingwege aufbauen, die das Risiko
   doppelter Nachrichten erhoehen.


1.3.2   2. DUTIES OF ZONE ECHOMAIL COORDINATOR:
(Pflichten des ZEC)

Es ist die Pflicht eines ZEC, die Verbindung zwischen den
BB-Systemen sowohl zwischen den Zonen sowie innerhalb der
Zone zu koordinieren, als auch die inter-regionalen
Verbindungen zu koordinieren.

Der ZEC wird die Uebermittlung der EM koordinieren und fuer
ein Routing sorgen, das eine Uebermittlung von doppelten
Nachrichten innerhalb der gleichen Konferenz verhindert. Es
ist weiterhin die Pflicht des ZEC, die Einhaltung der EP1
auf nationaler sowie internationaler Ebene zu ueberwachen.

1.3.3   3. DUTIES OF REGIONAL ECHOMAIL COORDINATOR:
(Pflichten des REC)

Es ist die Pflicht des REC, Massnahmen fuer die regionale
EM-Versorgung vorzusehen. Zusaetzlich wird der REC (mit
Wissen des ZEC) alle inter-regionalen Verbindungen von
EM-Zufuhr mit dem REC der teilhabenden Region koordinieren.

Der REC wird fuer eine solche Uebermittlung und Routing der
EM sorgen, das eine Uebermittlung von doppelten Nachrichten
innerhalb der gleichen Konferenz verhindert. Es ist die
Pflicht des ZEC, die Einhaltung der EP1 auf nationaler sowie
internationaler Ebene zu ueberwachen.

1.3.4   4. DUTIES OF NET ECHOMAIL COORDINATOR:
(Pflichten des NEC)

Es ist die Pflicht des NEC, die EM innerhalb des Netzes zu
koordinieren und mit den REC und NEC der anderen Netze
kooperieren um die EM-Verteilung zu arrangieren. Der REC
kann den NEC anweisen, Verbindungen fuer unabhaengige Nodes
bereitzustellen.

Der NEC muss eine Liste der Echos des Netzes, sowie der
noetigen Informationen ueber jedes echo wie vom Moderator
beschrieben (Echolist), verwalten. Der NEC hat die
Einhaltung von EP1 auf Netzebene zu ueberwachen.

1.3.5   5. DUTIES OF ECHOLIST COORDINATOR:
(Pflichten des Echolist-Koordinator)

Es ist die Pflicht des Echolisten-Koordinators, eine Liste
aller nationaler und internationaler Echos - und optional
von Konferenzen auf verschiedenen lokalen Ebenen - zu
erstellen und verfuegbar zu machen.

Der Inhalt und das Format der Echomaillistung bleibt dem ELC
ueberlassen, aber der jeweilige Konferenzname und der
Moderator muessen enthalten sein. Der ELC soll auch eine
Liste der notwendigen Voraussetzungen jeder gelisteten
Konferenz pflegen.

1.3.6   6. DUTIES OF ECHOMAIL CONFERENCE MODERATOR:
(Pflichten des MOD)

Die Pflichten des Moderators sind:

Dafuer zu sorgen, dass keine illegalen Aktivitaeten oder
Informationen, die in Sektion V Absatz 2 beschrieben sind,
in dem von ihm moderierten Echo verbreitet bzw. verherrlicht
werden.

Dafuer zu sorgen, dass die Nachrichten im Echo dem Thema der
Konferenz (topic) entsprechen.

Verletzungen von EP1 dem entsprechenden *EC anzuzeigen und
in adaequater Form eine foermliche Beschwerde, wie sie in
den jeweils geltenden Policies definiert ist, einzureichen.

Die Regeln des Echos (Echorules) wenigstens einmal pro Monat
im Echo zu veroeffentlichen.

Der Moderator hat den Ausschluss eines Teilnehmers vom Bezug
des Echos anzuordnen.

Jeder Sysop (von dem der Moderator annimmt, dass) der die
Policy verletzt, muss dem lokalen *EC (NEC, REC oder in
Extremfaellen auch der ZEC) gemeldet werden, der dem
betreffenden Node am naechsten ist; und der Moderator muss
foermlich veranlassen, dass der veraergernde Node vom Bezug
des Echos ausgeschlossen wird. (*3)

Der Moderator ist der alleinige Richter. [Bei Streitigkeiten
innerhalb des Echos hat der MOD das letzte Wort] Seine
Entscheidung kann lediglich vom ZEC, oder einem von ihm
delegierten, ueberprueft werden, wenn die ausgeschlossene
Partei sich beschwert.

Der Moderator kann in direkter Form (Netmail) verlangen,
dass die *ECs einen Node vom Bezug des Echo ausschliessen,
wenn der sich nach mindestens 3 Warnungen immer noch
weigert, den publizierten Echorules zu folgen.

Wissentlich einen Node, der vom Moderator vom Echobezug
ausgeschlossen ist, mit einem Echo zu versorgen, stellt eine
Verletzung dieser EP1 dar, und kann mit einer Sperre
[einstweiliger Ausschluss] geahndet werden. Die Dauer dieser
Sperre wird gemeinsam zwischen dem Moderator und dem lokalen
*EC des Node beschlossen, der den originalen und
veraergernden Node (oder Point) mit dem Echo versorgt.

(EM-)Beschwerden eines Sysops muessen auf Netzebene
eingereicht werden (NEC) oder bei Status "independant node"
beim REC. Der *EC muss nach Vorgabe dieser EP1 in Aktion
treten.

Bei wiederholten oder eklatanten Verstoessen kann der NEC,
REC oder ZEC eine foermliche Beschwerde wegen nachhaltig
veraergerndem Benehmen (XAB) einreichen. (echomail
complaint)


1.4.    IV. APPOINTMENT AND ELECTION OF ECHOMAIL
COORDINATORS AND MODERATORS.
(Benennung und Wahl von *EC und Moderatoren)

1.4.1   1. GRANDFATHER CLAUSE: (UEBERGANGSREGELUNG)

Die Koordinatoren (ZEC, REC, NEC und ELC) die zum Stichtag
der Ratifizierung dieses Amt innehalten, sollen es
weiterfuehren bis zu ihrem Ruecktritt oder bis sie aufgrund
von EP1 ersetzt werden.

1.4.2   2. ELECTION OF ZONE ECHOMAIL COORDINATOR:
(Wahl des ZEC)

Der ZEC wird folgendermassen gewaehlt:

a) Bei Ruecktritt oder Absetzung des amtierenden ZEC, muss
der ZC mindestens fuenf Personen fuer diesen Posten zur Wahl
vorschlagen.

b) 10 Tage, nachdem die Kandidaten benannt wurden, muss eine
Wahl abgehalten werden. Der ZEC wird durch eine einfache
Mehrheit der IC, ZC, RC, NC, REC und NEC ihrer Fidonet-Zone
gewaehlt. (Wenn eine Person mehr als ein Amt bekleidet, hat
sie dennoch nur eine Stimme)

1.4.3   3. ELECTION OF REGIONAL ECHOMAIL COORDINATOR:
(Wahl des REC)

Der REC wird folgendermassen gewaehlt:

a) Bei Ruecktritt oder Ersetzung des amtierenden REC, muss
der ZEC mindestens drei Personen fuer diesen Posten zur Wahl
vorschlagen.

b) 10 Tage, nachdem die Kandidaten benannt wurden, muss eine
Wahl abgehalten werden. Der REC wird durch eine einfache
Mehrheit der RC, NC und NEC ihrer Fidonet-Zone gewaehlt.
(Wenn eine Person mehr als ein Amt bekleidet, hat sie
dennoch nur eine Stimme)

1.4.4   4. NET ECHOMAIL COORDINATOR:

Ein NEC wird entweder durch den NC direkt benannt, oder auf
alternative Weise, wie vom NC bestimmt. Wenn ein NEC nicht
innerhalb von 30 Tagen ernannt wurde, wird der REC den NEC
bestimmen.

1.4.5   5. REMOVAL OF A *EC: (Absetzung eines *EC)

Ein *EC kann durch eine einfache Mehrheit der
Wahlberechtigten, das sind jeweils die Personen, die auch
seinen Nachfolger waehlen duerfen, abgewaehlt werden. Das
sind bei einem NEC z.B. alle Mitglieder des entsprechenden
Netzes. Die *EC der jeweils hoeheren Hierarchieebene werden
die Abwahlen in gleicher Weise wie die Wahlen kontrollieren.

Ein *EC kann lediglich abgewaehlt werden, wenn er seine oben
beschriebenen Pflichten nicht mehr ausreichend erfuellen
kann, oder wenn er nicht mehr laenger FIDO-Mitglied ist. Ein
Versprechen von "freier" EM aus einer anderen Quelle ist
KEIN akzeptabler Grund fuer eine Abwahl.

1.4.6   6. RECOGNITION OF CONFERENCES:
(Anerkennung von Konferenzen)

Ein *EC erkennt eine Konferenz entsprechend seiner
Hierarchieebene an. Beispiel: Der NEC betrachtet eine
Konferenz als lokal. Der Rec betrachtet sie als regional.
Der ZEC betrachtet sie als zonal und der IC als interzonal.

1.4.7   7. REMOVAL OF AN ECHOMAIL CONFERENCE MODERATOR:
(Absetzung des MOD)

Der Moderator kann seines Postens enthoben werden, wenn eine
3/4-Mehrheit der abstimmenden *EC-Struktur dafuer stimmt.

Diese Abwahl muss fair und gerecht ablaufen, und sie muss
der gesamten *EC-Struktur ueber einen Zeitraum von
mindestens 10 Tage bekannt gemacht werden. Akzeptable Medien
sind: NM vom ZEC oder Nachrichten in internationaelen Echos
wie z.B. COORD. In Ausnahmefaellen koennen die NEC auch vom
REC direkt benachrichtigt werden.

Eine Abwahl eines Moderators kommt ausschliesslich in Frage,
wenn er seine oben beschriebenen Pflichten nicht erfuellt,
oder fortgesetzt gegen die Bestimmung der Sektion V der EP1
verstoesst.

Wenn der Moderator seinen Pflichten ueber einen Zeitraum von
3 Monaten oder mehr nicht nachkommt und auch keinen
Vertreter fuer den Zeitraum seiner Abwesenheit bestellt,
verletzt er die Bestimmungen der EP1 und kann abgewaehlt
werden.

Eine Abwahl des Moderators kann ausschliesslich vom ZEC
(oder seinem Delegierten) ausgerufen werden. Dieser
Delegierte soll/darf nicht aus dem Netzbereich stammen, aus
dem der betreffende Moderator stammt.

Die Mitgliedschaft des Moderators im FIDO-Netz ist keine
zwingende Voraussetzung, wird aber empfohlen.


1.5.    V. STATEMENT OF POLICIES (Aussagen der Police)

1.5.1   1. BASIC ECHOMAIL POLICY:

Die grundsaetzliche Politik von EM ist es, die Kommunikation
in Echos auf eine rechtmaessige, freundliche Art und im
Einklang mit den generellen Prinzipien des FIDOnetzes zu
foerdern.

1.5.2   2. PROHIBITION ON ILLEGAL ACTIVITIES:
(Verbot illegaler Aktivitaeten)

Jeder Node, der wissentlich Nachrichten mit illegalem, bzw.
eine Strafverfolgung nach sich ziehenden, Inhalt oder
Aufforderungen oder Verabredungen zu illegalen Handlungen in
das Echo leitet, handelt gemaess der EP1 nachhaltig
veraegernd (excessively annoying behavior).

Mit "illegalen Aktivitaeten" sind alle strafbewehrte
Handlungen gemeint, ebenso zivilrechtlich relevante
Handlungen wie Aktivitaeten, die zu einer Strafverfolgung
fuehren koennen.

1.5.3   3. AUTOMATED CENSORSHIP: (Automatische Zensur)

Die Anwendung automatischer Zensur bei Weiterleitung oder
Zustellung von EM wird als Verletzung von EP1 angesehen und
darf nicht toleriert werden. "Erzieherische Massnahmen"
werden mit Verweis auf P4 als XAB angesehen.

Eine Ausnahme bilden hier Loeschen, und nicht Zensieren, von
Nachrichten durch einen Sysop, die rechtliche Schritte gegen
diesen Sysop nach sich ziehen koennten.

Eine EM darf nicht derart veraendert werden, dass
moeglicherweise Duplikate erzeugt werden.

1.5.4   4. INTER-NETWORK CONFERENCES:
(Inter-Netz-Konferenzen)

Bei mit anderen Netzen verknuepften Konferenzen muessen die
P4 diese P1, sowie jede andere, eventuelle Policy des
anderen Netzes eingehalten werden.

1.5.5   5. CHARGING FOR DISTRIBUTION:
(Kostenberechnung fuer Verteilung)

Jede Person, die mit der Verteilung von EM von einem System
zum anderen Profit macht, handelt nach Massgaben der Fidonet
Police XAB.

Mit "Profit machen" ist hier gemeint, Kosten fuer die
EM-Verteilung zu berechnen, die die aktuellen Kosten der
Mailbeschaffung und -verteilung ueber einen bestimmten
Zeitraum ueberschreitet. Kosten fuer das Equipment, das fuer
EM-beschaffung und -verteilung benoetigt wird, duerfen nicht
gedeckt werden.

Ein Sysop, der seinen Usern den Zugang zu seiner Mailbox
berechnet, verstoesst nicht gegen diese Bestimmung.


1.5.6   6. RESTRICTED DISTRIBUTION CONFERENCES:
(Konferenzen mit eingeschraenkter Verbreitung)

Teilnehmende Nodes haben die Beschraenkungen solcher
Konferenzen zu achten und zu unterstuetzen.

Verletzungen dieser Einschraenkungen durch Nodes oder Points
stellen eine Verletzung von EP1 dar und ziehen den
Ausschluss aus dem jeweiligen Echo durch den MOD nach sich
(Siehe Sektion III, Pflichten des MOD).

Eine nur auf SYSOP beschraenkte Konferenz darf nur Sysops
oder Co-Sysops des Fidonetzes, oder anderen Netzen, mit
denen Inter-Netz Verbindungen (Zwischen-Netz-Echos?)
existieren, zugaenglich gemacht werden.

Eine Verletzung der Beschraenkungen einer solchen Konferenz
ist eine Verletzung von EP1, wenn - und nur dann - der MOD
die jeweiligen Beschraenkungen definiert und veroeffentlicht
hat.

1.5.7   7. PATH REQUIRED: ("PATH"-Zeile erforderlich)

Die PATH-Zeile, die urspruenglich von SEA in dem MGM-Paket
eingefuehrt wurde, ist unbedingt erforderlich. Das gilt
nicht fuer Terminal Nodes.

Wenn Deine aktuelle Software die PATH-Zeile unterstuetzt,
musst Du sie JETZT aktivieren. Unterstuetzt Deine Software
diese Zeile nicht, dann wird diese Bestimmung fuer 60 Tage
ausgesetzt.

Danach koennen die *EC sich weigern, EM von/an Nodes zu
akzeptieren/verteilen, die diese PATH-Zeile nicht
unterstuetzen.

1.5.8   8. SEEN-BY LINE:

Bei der aktuellen Technik und Topologie (die routende
Struktur der EM), spielen SEEN-BY Zeilen eine wichtige Rolle
in der Vermeidung doppelter Nachrichten.

Sogenannte 'kleine' SEEN-BYs sind nicht erlaubt, bis die
entsprechen- den ZECs der Meinung sind, dass die Topologie
ihren Gebrauch erlaubt. Ebenso ist das Entfernen der
SEEN-BYs (Ausnahmen von Zone-Gates und Inter-Network
EchoGates) nicht erlaubt, bis der ZEC es billigt.

Verletzungen dieser Bestimmung ist XAB und wird nach P4
geahndet. Zone-Gates und Inter-Network Echo Gates muessen
die SEEN-BY-Zeilen der exportierten Zone oder Netzwerke
entfernen, um Adressenkonflikte zu vermeiden.

1.5.9   9. COUNTERFEIT MESSAGES: (Gefaelschte Nachrichten)

Wissentlich eine gefaelschte Nachricht einzugeben oder zu
verbreiten muss als nachhaltig veraergernd, und als
Verletzung der FIDONET-Policen verurteilt und mit den
Mitteln der FIDONET-Policen geahndet werden.

Mit "gefaelschter Nachricht" ist eine solche gemeint, die
unter dem Namen, Handle (handle = Deck-/Zugriffs-Namen,
Pseudonym??) oder Nodeadresse einer anderen Person
eingegeben wird, in der Absicht, die anderen ueber den
wahren Verfasser der Nachricht zu taeuschen.

Es duerfen keine Handles benutzt werden um Nachrichten
einzugeben, die wissentlich provozieren, angreifen, oder
Teilnehmer einer Konferenz zu veraergern mit der Absicht,
die anderen ueber den wahren Verfasser der Nachricht zu
taeuschen.

1.5.10  10. SYSOP'S RESPONSIBILITY:
(Verantwortlichkeit des Sysop)

Jeder SysOp {Node} ist dafuer verantwortlich, jede zumutbare
Anstrengung aufzubringen, dass sich die User seiner Box {und
Subsysteme} entsprechend der Bestimmungen von EP1 verhalten.

Jeder SysOp kann fuer die Handlungen seiner User
verantwortlich gemacht werden, es sei denn, dass er einen
ernsthaften Versuch nachweisen kann, der EP1 zu entsprechen.

1.5.11  11. ECHOMAIL SOFTWARE:

Der Austausch von EM kann aus jedem moeglichen Archivtyp
bestehen, wenn diesem beide Seiten zugestimmt haben. Es ist
auf SEA's ARC 5.1 (nicht-komprimierend) Archivierungsformat
zurueckzugreifen, wenn die Parteien sich nicht auf eine
Methode einigen koennen.

Die fortgesetzte Benutzung von Echomail Software ohne vorher
eingeholtes Einverstaendnis von beiden, dem sendenden und
dem empfangenden Node, die dadurch die Verteilung von EM
stoeren, fuehrt zu disziplinarischen Massnahmen, wie in EP1
beschrieben. Siehe Abschnitt III.

Ein Beispiel untersagter Software ist das Benutzen von nicht
standardgerechten Echomailpaketen, welche vom empfangenden
System nicht verarbeitet werden koennen. Ein anderes
Beispiel waere der Gebrauch von schlecht eingestellten
Scannern oder Tossern die Duplikate erzeugen oder daran
scheitern, Nachrichten an abwaertsgerichtete Links zu
verteilen. Ein weiteres Beispiel ist der Gebrauch der
Tiny-SEENby Option und der Gebrauch von durch "^A"
verborgenen SEEN-BY Zeilen.

Der Gebrauch von Echomail Software, die nicht dem Minimum an
akzeptablem Standard entspricht, wie sie vom FTSC (Fidonet
Technical Standards Committee) definiert wurden, fuehrt zu
disziplinarischen Massnahmen, wie in EP1 vorher beschrieben.

Das Software-Zertifizierungs-Komitee ist autorisiert, zu
entscheiden, ob eine Software den minimalen Anforderungen
entspricht, um im Netz eingesetzt zu werden.

1.5.12  12. HOST ROUTING OF ECHOMAIL:

Hostrouting von EM ohne vorherige Zustimmung beider, dem
sendenden und empfangenden, Host soll zu disziplinarischen
Massnahmen fuehren, wie sie in EP1 vorher beschrieben sind.
Siehe Abschnitt III.

1.5.13  13. SENDING OF ECHOMAIL DURING ZONE MAIL HOUR:
(Senden von EM waehrend der ZMH)

Das Senden von EM waehrend der ZMH (wie in der Fidonet
Police beschrieben) ohne die Zustimmung des Empfaengers,
fuehrt zu disziplinarischen Massnahmen, wie schon in diesem
Dokument beschrieben. Siehe Sektion III.

1.5.14  14. INTER-NETWORK CONFERENCES:

Es ist die generelle Politik des FIDOnetzes, die Entwicklung
von Konferenzen zu foerdern, die verschiedene Netzwerke
verbinden.

Es ist die Pflicht desjenigen, der das Inter-Netztwerk-Echo
verteilt, alle Steuerzeichen, die der Verteilung im fremden
Netzwerk dienen, und die moeglicherweise die Verteilung des
Echos innerhalb des FIDOnetzes beeintraechtigen, zu
entfernen.

Die Verbindungen zu anderen Netzwerken, die in FIDO
unterhalten werden, muessen derart betrieben werden, dass
sie die EM-Verteilung im fremden Netz nicht
beeintraechtigen.

1.5.15  15. DEFAMATORY POSTING: (verleumderische Nachrichten)

Das Eingeben von verleumderischen Nachrichten fuehrt zu
disziplinarischen Massnahmen wie vorher in EP1 beschrieben,
es sei denn, dies geschieht in einer extra dafuer
eingerichteten Konferenz (z.B. FLAME). Siehe dazu Sektion
III.

Das Verkuenden belegbarer (oder belegender?) Fakten wird
nicht als Verstoss gegen diesen Abschnitt erachtet.

1.5.16  16. ADDING OR REMOVING CONFERENCES FROM THE Backbone:
(Echos vom BB nehmen/dem BB zufuegen)

Eine Konferenz kann nur auf Verlangen des ANERKANNTEN MOD
dem BB hinzugefuegt werden.

Eine Konferenz kann wegen mangelndem Nachrichtenaufkommen
vom BB genommen werden. Ein Kommittee aus ZEC und 4 REC
muessen den Status der BB-Echos alle 6 Monate ueberpruefen.

Die Echos, durch die ueber die letzten sechs Monate verteilt
nicht wenigstens 10 Nachrichten pro Woche durchgelaufen
sind, werden notiert und die MOD kontaktet.

Diesen Echos wird 3 Monate Zeit gegeben, ihr Mailaufkommen
zu erhoehen oder sie werden aus der BB-Verteilung
herausgenommen. Der anerkannte MOD kann jederzeit verlangen,
dass sein Echo vom BB genommen wird.

1.5.17  17. TOPOLOGY and DUPLICATE MESSAGES:
(Aufbau der Routingwege und Nachrichtendoubletten)

Regionale Kreuzverbindungen sollen vermieden werden, da sie
das Risiko ungenauer Verknuepfungen und der Erzeugung von
Doubletten erhoehen. Solche Kreuzverbindungen duerfen nur
mit Genehmigung des REC jeder Region eingerichtet werden.

Jeder REC wird sein Bestes tun, um "Hochgeschwindigkeits
Hubs" "out of state Hubs" "PC Pursuit Hubs" etc, eine
kostenguenstige, effiziente Mailversorgung in seiner Region
zu ermoeglichen.

Wenn einer der REC Gruende hat, anzunehmen, dass Doubletten
in das System eingespeisst werden, muss eine existierende
regionale Kreuzverbindung sofort geschlossen werden, bis
eine Loesung gefunden ist.

Jeder Sysop, der vorsaetzlich und wissentlich links
einrichtet, die entweder doppelte Schleifen (eine Topologie
die kreisfoermige Einspeisungen hervorruft) oder das Risiko
solcher Schleifen erhoeht oder sich auf Aufforderung durch
seinen NEC, REC, oder ZEC weigert solche links zu
unterbrechen, soll disziplinarischen Massnahmen unterworfen
werden, wie in EP1 beschrieben. Siehe Sektion III.

1.5.18  18. MESSAGE STANDARDS: (Nachrichten-Standards)

Bis zur Uebernahme eines uebergreifenden Standards durch das
FTSC, gilt der folgende Standard fuer EM-Nachrichten:

a) Der erweiterte Acht-Bit-Zeichensatz (ASCII 128-255) und
die Steuerzeichen (ASCII 2-31) duerfen lt. FTS-0004 nicht
benutzt werden (ausser 8Dh, dem "Soft-Return")

Das ist nicht dazu gedacht, anderen Zonen, die diese Zeichen
erlauben koennen, von der Teilnahme abzuhalten.

Jeder EM-Processor muss Informationen exakt so wiedergeben,
wie er sie empfaengt, ohne irgendwelche nicht
standardisierten Zeichen herauszufiltern.

b) ORIGIN-Zeilen sind auf 79 Zeichen beschraenkt, inkl. der
gueltigen Netzadresse (z.B.: Zone:Netz/Node.Point, wobei
Zone und Point optional sind) [und dem Vorzeichen " *
Origin: "]

c) "Tearlines" sind, inkl. den Vorzeichen "--- " auf 35
Zeichen beschraenkt. Sie darf NUR Produktinformationen ueber
Packer oder Editor enthalten. Auf "Tearlines" fuer
Texteditoren sollte verzichtet werden. Sollte ein Editor
eine Tearline anfuegen, dann muss er auch die ORIGIN-Zeile
anfuegen, um mehrfache tearlines zu vermeiden.

d) Zusaetzliche ORIGIN-Zeilen muessen auf die noetigsten
Informationen beschraenkt sei. Dies beinhaltet das
entsprechende Vorzeichen, plus den Netzwerknamen "Gateway",
optional eine Software-Produktinfo und einer Adresse in der
Form Zone:Netz/Node. (Beispiel: " * Origin: FidoNet Gateway
(TCOMM 88:372/666)

e) SEEN-BY-Zeilen muessen sortiert sein. Mehrere AKA's sind
nicht erlaubt, es sei denn, Du hast mehr als eine Adresse,
die Mail transportiert, oder - fuer die Dauer eines Monats -
bei Umstellung auf eine andere Adresse (um Duplikate an
diese Adresse zu vermeiden). Node-0-Adressen duerfen nicht
benutzt werden.

f) Alle gueltigen FTS-Spezifikationen muessen eingehalten
werden.

1.6.    VI. ENFORCEMENT (Geltendmachung und Durchfuehrung)

Die Geltendmachung und Durchfuehrung von EP1 muss unter der
Vorgaben der "General Fidonet Policy" geschehen.

Foermliche Beschwerden betreff EM-Verletzungen
(echomail-complaint) koennen von der betroffenen Person, dem
Moderator oder jedem Level der *EC-Struktur eingereicht
werden. Alle Beschwerden gemaess EP1 muessen innerhalb 60
Tage nach Bekanntwerden des Beschwerdegrundes eingereicht
werden. Beschwerden muessen nach den Bestimmungen der
FIDONET POLICY eingereicht und eine Kopie an den
entsprechenden *EC gesandt werden.

Diese Police wird sofort gueltig. Jede existierende Software
hat 60 Tage Zeit (ab dem Datum, an dem die EP gueltig wird)
sich daran anzupassen. Eine 30-taegige Verlaengerung durch
den ZEC ist moeglich, wenn ausreichende Gruende fuer eine
Verlaengerung vorgebracht werden. Nach dieser Periode wird
es als XAB angesehen, immer noch abweichende Software zu
benutzen.

1.7.    VII. ADOPTION OF POLICY (Uebernahme der Police)

1.7.1   1. UEBERNAHME:
Diese Police erlangt durch die Zustimmung einer einfachen
Mehrheit der Abstimmenden Gueltigkeit. Wahlberechtigt sind
die IC, ZCs, RCs, NCs, ZECs, RECs und NECs. Jede Person, die
mehr als eine Position innehat, besitzt dennoch nur eine
Stimme.

1.7.2   2. GRANDFATHER CLAUSE: (UEBERGANGS-REGELUNG)
Innerhalb von 60 Tagen nach Inkrafttreten von EP1 muss in
jedem Echo ein Moderator eingesetzt sein, wenn das bis dahin
noch nicht der Fall war. Die Moderatoren koennen vom ZEC
unter eventuellen Kandidaten ausgesucht oder, wenn keine
Kandidaten zur Verfuegung stehen, bestimmt werden.

Wenn mehr als eine Person den Anspruch darauf erhebt,
Moderator eines bestimmten Echos zu sein und kein
Uebereinkommen getroffen wird, kann der ZEC das Echo
aufloesen und die zukuemftige Benutzung des speziellen
Konferenz-Namen verbieten. Sollten die Personen die
betreffende Konferenz nicht aufloesen, wird das als XAB
angesehen.

1.8.    VIII. BACKBONE STRUCTURE: (Der Aufbau des BB)

Dieser Abschnitt dient lediglich der allgemeinen
Information. Er umreisst in kurzen Worten den aktuellen
Aufbau und die Arbeit des Backbones. Der ZEC kann diesen
Aufbau aendern ohne dieses Dokument zu aendern.

An der Spitze der EM Verteilung stehen Systeme, die
"Sternsysteme" genannt werden. Diese Systeme reichen
gewoehnlich EM weiter. Die Sternsysteme arbeiten nach
Belieben und Anweisung ZEC.

Zu Zeit der Erstellung dieses Dokumentes gibt es 3
Sternsysteme, die fuer den Fall des Versagens alle ueber ein
Sicherungssystem und -plan verfuegen.

Im Allgemeinen sind die Sternsysteme untereinander verbunden
und versorgen die RECs. Danach sind die RECs dann fuer die
Verteilung der EM innerhalb der Region verantwortlich.
Normalerweise, werden die REC die NECs in ihrer Region
versorgen. Fuer die Verteilung der EM an jeden einzelnen
Sysops im Netz ist der NEC verantwortlich.

Beachte, dass die RECs und NECs zu ihrer Unterstuetzunng bei
der Verbreitung der EM HUBs einsetzen koennen, damit sie das
untere Level nicht direkt versorgen muessen.

Dies ist das zu erreichende ZIEL bei der Verteilung. Durch
guenstigere Telefongebuehren und andere Gruende wird diese
Verteilungsmethode nicht immer genau befolgt.

Jede Aenderung des beschriebenen Vorgehens erfordert die
Einwilligung der beteiligten *EC's. Die *ECs werden alle
moeglichen Hilfsmittel (HUBs, Hochgeschwindigkeitmodems, ROA
(?), Wide Area Calling plans (?), PC Pursuit (?), gemeinsame
Patenschaften (?) etc.) einsetzen, um eine schnelle,
wirkungsvolle und kosteneffektive Verteilung der EM zu
erreichen.

Danke an das "Echopol Committee":
Mike Ratledge, Norm Henke, Rick McWilliams, Barry Shatswell

------------------------------------------------------------
Fussnoten des Uebersetzers:

(*1) (z.B. LARP.GER oder EBBAUSER.GER ;)

(*2) [Die logische Fortsetzung waere:
ECHOMAIL CONFERENCE MODERATOR (MOD): This individual is
responsible for coordination of Echomail in his confernce.
Der MOD ist verantwortlich fuer die Koordination der EM in
seinem Echo.]

(*3) [Aus der Definierung des "downstream links" ergibt
sich, dass ein Ausschluss vom downlink ebenso den uplink
einschliesst.]

------------------------------------------------------------
Sachliche Kritik und Verbesserungsvorschlaege erwuenscht!
------------------------------------------------------------
Letzte Aenderung:               | Kontakt:
25.8.96                         | FIDO: 2:2433/601.7
Dirk Richartz                   | e-mail: drr@big-biz.gun.de
------------------------------------------------------------
