============================================================ Die "GENERAL ECHOMAIL POLICY 1", Stand von 1. Februar 1989 ------------------------------------------------------------ Deutsche Uebersetzung von Dirk Richartz aka 2:2433/601.7 Release: EP1-D-04.TXT, vom 9.9.96 ============================================================ Index 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 "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 an den 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" Einige der in diesem Text verwendeten Kurzbezeichnungen: EP1 = General Echomail Policy 1 EM = Echomail NM = Netmail MOD = Echomail-Moderator Echo = Echomail-Konferenz P3 = General Fidonet Policy 3.x P4 = General Fidonet Policy 4.07 BB = Backbone structure ZEC = Zone Echomail Coordinator REC = Region Echomail Coordinator NEC = Net Echomail Coordinator "DOWNLINK/UPLINK" Der Begriff "downlink" leitet sich aus dem Ausdruck "downstream link" ab. Vor dem Bild des "Mail-Flusses" (ZEC - REC - NEC - NODE) ist damit der fluss-abwaerts gerichtete Verteilungs-Fluss gemeint. Davon wiederum leitet sich der Ausdruck "upstream link" (uplink) ab. Damit ist der fluss-aufwaerts gerichtete Mail-Fluss gemeint. Im Normalfall sollte man dort, wo man seine EM HOLT auch seine EM ABLIEFERN. a.2. PROLOGUE (EINLEITUNG) Dies Dokument legt die Politik bei der Verwaltung von Echomail Konferenzen und deren Verteilung dar. Es ist fuer alle Echos der Zone 1 anzuwenden, die im "Backbone" gelistet sind und fuer jedes andere Echo, fuer das der Moderator es anzuwenden wuenscht. Zukuenftige Aenderungen koennen nur durch einfachen Mehrheitsbeschluss der RECs vorgeschlagen werden. Die Stimmberechtigten, die ueber entsprechende Vorschlaege der REC-Struktur abstimmen, sind der ZEC, die RECs, die NECs, die NCs, die RCs und der IC. 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. Alle potentionellen Waehler muessen nach besten Kraeften [und fruehzeitig] darueber informiert werden, dass eine Wahl stattfinden soll, und es muss jede Information darueber verfuegbar gemacht werden. 1.1. I. HISTORY (GESCHICHTE) Echomail 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 andere Programme geschrieben, die die originale Idee verfolgen und verbessern. Ganz entgegen den Befuerchtungen, das Aufkommen der EM wuerde das Netmailaufkommen derart aufblaehen, dass das Netz unter seinem eigenen Gewicht zusammenbraeche, war [und ist] EM 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 foermliche Police fuer die EM-Verwaltung darzulegen. (EP1) 1.2. II. DEFINITIONEN 1.2.1 1. ECHOMAIL Der Prozess, Nachrichtenpakete zwischen unabhaengigen Systemen mit eindeutigen Netzadressen auszutauschen. (1*) 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. (2*) 1.2.3 3. MODERATED CONFERENCE (MODERIERTE KONFERENZ) Eine moderierte Konferenz ist ein Echo, fuer die ein MOD ernannt 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. SYSOP-ONLY CONFERENCE (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. RESTRICTED DISTRIBUTION CONFERENCES (KONFERENZEN MIT EINGESCHRAENKTER VERTEILUNG) Konferenzen mit eingeschraenkter Verteilung sind auf ausgesuchte Empfaenger beschraenkt. Beispiel: MODERATOR.GER (3*) 1.2.6 6. ZONE ECHOMAIL COORDINATOR (ZEC) Diese Person ist verantwortlich fuer die Koordination der EM auf FIDO-Zonen-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. (4*) 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-Echomail-Liste verwaltet. 1.2.11 11. AUTOMATED CENSORSHIP (AUTOMATISCHE ZENSUR) Der Ausdruck automatische Zensur bezieht sich auf Programme, die Nachrichten aus den zugedachten Konferenzen entfernen oder deren Inhalt manipulieren. 1.2.12 12. FIDONET POLICY Das Verwaltungsdokument fuer das Fidonet, so wie es vom Fidonet angenommen worden ist. 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 dabei helfen, in EM auftretende Policy-Verletzungen zu definieren. (5*) 1.2.13 13. OPEN ACCESS CONFERENCE (KONFERENZ OHNE ZUGRIFFSBESCHRAENKUNG) Dies ist eine Konferenz, die nicht eingeschraenkt und 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 verarbeitet. 1.3. III. DUTIES OF ECHOMAIL COORDINATORS (PFLICHTEN DER ECHOMAIL KOORDINATOREN (*EC)) 1.3.1 1. ALLGEMEINES: Es ist die Pflicht der *EC, jedem Fidonet-SysOp jedes Echo verfuegbar zu machen, wenn der nicht vom Bezug des Echos ausgeschlossen worden ist weil er den festgelegten Anforderungen des MOD nicht gerecht wurde. Sollten die *EC aus irgendeinem Grund auf ein bestimmtes Echo nicht ueber die bekannten Kanaele zugreifen koennen, kann nicht von ihnen erwartet werden, es weiterzureichen. Wenn es einem *EC nicht gelingt, einem berechtigten Empfaenger irgendein Echo verfuegbar zu machen, dann wird das als Verletzung der aufgetragenen Pflichten seines Amtes angesehen. Solch eine Pflichtverletzung ist Grund fuer eine Absetzung, wie in diesem Dokument beschrieben. Diese Bestimmung verlangt nicht, dass ein *EC irgendeine 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, (im Gegensatz zu eingeschraenkten Konferenzen) wenn sie angefordert wird. Eine Ausnahme liegt dann vor, wenn ein *EC einen Link unterbricht um den nichtauthorisierten Emfpang einer Konferenz zu beenden. In diesem Fall koennen durchaus authorisierte Nodes zeitweise ihre Anbindung verlieren. Ein *EC soll nach besten Kraeften sicherstellen, dass: 1. Alle downlinks von EP1 unterrichtet werden. 2. Downlinks wissen, wie sie sich korrekt an ein Echo anbinden 3. Akzeptables und unakzeptables Benehmen in Echos erklaert wurde 4. Downlinks sich nicht auf Routingwege einlassen, 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 in der Art sorgen, dass eine Uebermittlung von doppelten Nachrichten innerhalb der gleichen Konferenz verhindert wird. 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 Kreuzverbindungen von EM-Zufuhr mit dem REC der teilhabenden Region koordinieren. Der REC wird fuer eine solche Uebermittlung und Routing der EM in der Art sorgen, dass eine Uebermittlung von doppelten Nachrichten innerhalb der gleichen Konferenz verhindert wird. Es ist die Pflicht des REC, die Einhaltung der EP1 auf regionaler 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 verfuegbaren 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: (ELC) (PFLICHTEN DES ECHOLISTEN-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: (MOD) (PFLICHTEN DES MOD) Es ist die Pflicht des MOD, in gutem Glauben jede vernuenftige Anstrengung zu unternehmen, um dafuer zu sorgen, dass keine illegalen Aktivitaeten oder Informationen, die in Abschnitt V Absatz 2 beschrieben sind, in dem von ihm moderierten Echo verbreitet oder unterstuetzt werden. Der Mod hat dafuer zu sorgen, dass die Nachrichten im Echo dem Thema der Konferenz (topic) entsprechen. Der MOD hat Verletzungen von EP1 dem entsprechenden *EC anzuzeigen und eine foermliche Beschwerde, wie sie in den vom Fidonetz angenommenen Policen vorgesehen ist, einzureichen. Der MOD hat die Regeln des Echos (Echorules) wenigstens einmal pro Monat im Echo zu veroeffentlichen. Der Moderator hat den Ausschluss vom Bezug des Echos anzuordnen. Jeder Sysop, von dem der Moderator glaubt, 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. (6*) Der Moderator ist der alleinige Richter. [Bei Streitigkeiten innerhalb des Echos hat der MOD das letzte Wort, oder besser noch - Hausrecht] Seine Entscheidung kann lediglich vom ZEC, oder einem von ihm Beauftragten, ueberprueft werden, wenn die ausgeschlossene Partei eine Beschwerde einreicht. Der Moderator kann in direkter Form (Netmail) verlangen, dass die *ECs einen Node vom Bezug des Echo ausschliessen, wenn der sich auch nach mindestens 3 Warnungen 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 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. Beschwerden eines Sysops (echo complaints) muessen auf Netzebene eingereicht werden (NEC) oder, wenn die sich beschwerende Partei ein "independant node" ist, beim REC. Der *EC muss nach den Vorgaben dieser EP1 in Aktion treten. Bei schweren oder wiederholten Uebertretungen kann der NEC, REC oder ZEC nach der General Fidonet Policy eine foermliche Beschwerde wegen nachhaltig veraergerndem Benehmen (XAB) einreichen. 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 innehaben, 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 ausgewaehlt 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 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 ausgewaehlt wurden, muss eine Wahl abgehalten werden. Der REC wird durch eine einfache Mehrheit der RC, NC und NEC ihrer Fidonet-Region gewaehlt. Wenn eine Person mehr als ein Amt bekleidet, hat sie dennoch nur eine Stimme. 1.4.4 4. NET ECHOMAIL COORDINATOR (NEC) 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. Der IC betrachtet sie 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 Abstimmung 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 Absetzung eines Moderators kommt ausschliesslich in Frage, wenn er seine oben beschriebenen Pflichten nicht erfuellt, oder fortgesetzt vorsaetzlich gegen die Bestimmung des Abschnitts V der EP1, wie unten beschrieben, 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 deswegen abgesetzt werden. Eine Abstimmung ueber den Moderators kann ausschliesslich vom ZEC (oder seinem Beauftragten) ausgerufen werden. Dieser Beauftragte sollte nicht aus der Region oder aus dem Netzbereich des betreffenden Moderator stammen. Die Mitgliedschaft [des Moderators] im FIDO-Netz ist keine zwingende Voraussetzung, wird aber dringend empfohlen. 1.5. V. STATEMENT OF POLICIES (AUSSAGEN DER POLICE) 1.5.1 1. BASIC ECHOMAIL POLICY (GRUNDSAETZLICHE ECHOMAIL POLITIK) Die grundsaetzliche Politik von EM ist es, die Kommunikation in Echos auf eine rechtmaessige, freundliche Art und im Einklang mit den generellen Prinzipien des Fidonetz 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 Aufforderung oder Verabredung 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 auch 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 wird nicht toleriert. "Erzieherische Massnahmen" werden, mit Verweis auf P4, als XAB angesehen. Eine Ausnahme bildet hier Loeschen, und nicht Zensieren, von Nachrichten durch einen Sysop, die rechtliche Schritte gegen diesen Sysop nach sich ziehen koennten. Keine EM darf derart veraendert werden, dass moeglicherweise Duplikate entstehen koennen. 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 Vorgabe des fremden 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. Da er die FIDO-Politik verletzt, sollen gegen ihn Sanktionen, wie durch P4 vorgesehen, erfolgen. 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 ubersteigen. Kosten fuer das Equipment, das fuer EM-beschaffung und -verteilung benoetigt wird, duerfen nicht abgedeckt 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 VERTEILUNG) Teilnehmende Nodes haben die Einschraenkungen 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 Abschnitt III, Pflichten des MOD). Eine nur auf SYSOP beschraenkte Konferenz darf nur Sysops oder Co-Sysops des Fidonetz, oder anderen Netzen, mit denen Inter-Netz Verbindungen bestehen, zur Verfuegung gestellt 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 ("PFAD"-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. Wenn Deine Software diese Zeile nicht unterstuetzt, und Du keine Alternative hast, 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 ("WURDE-GESEHEN-VON"-Zeile) Bei der aktuellen Technik und Topologie (die routende Struktur der EM), spielen SEEN-BY Zeilen eine wichtige Rolle dabei, doppelte Nachrichten zu reduzieren. Sogenannte "kleine" [verkuerzte] 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 Nachricht definiert, die unter dem Namen, "Handle" 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 ist dafuer verantwortlich, jede zumutbare Anstrengung aufzubringen, dass sich die User seiner Mail-Box entsprechend der Bestimmungen von EP1 verhalten. (7*) Jeder SysOp kann fuer die Handlungen seiner User verantwortlich gemacht werden, es sei denn, dass er ernsthafte Bemuehungen nachweisen kann, der EP1 zu entsprechen. 1.5.11 11. ECHOMAIL SOFTWARE: Der Austausch von EM kann jeden moeglichen Archivtyp enthalten, wenn diesem beide Seiten zugestimmt haben. Es ist auf SEA's ARC 5.1 (nicht-komprimierend) Archivierungsformat zurueckzugreifen, wenn eine Partei die alternative Methode nicht verwenden kann oder will. 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 Abschnitt III. 1.5.14 14. INTER-NETWORK CONFERENCES: Es ist die generelle Politik des Fidonetz, die Entwicklung von Konferenzen zu foerdern, die verschiedene Netzwerke verbinden. Es ist die Pflicht desjenigen, der das Inter-Netztwerk-Echo verteilt, alle Steuerzeichen zu entfernen, die der Verteilung im fremden Netzwerk dienen, und die moeglicherweise die Verteilung des Echos innerhalb des Fidonetz beeintraechtigen. Die Verbindungen die ein solches Echo innerhalb FIDO unterhaelt, muessen derart betrieben werden, dass sie die EM-Verteilung im fremden Netz nicht beeintraechtigen. 1.5.15 15. DEFAMATORY POSTING (VERLEUMDERISCHE NACHRICHT) 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 Abschnitt III. Das Verkuenden belegbarer 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 Komitee aus ZEC und 4 REC hat den Status der BB-Echos alle 6 Monate zu ueberpruefen. Wenn diese Echos ueber die letzten sechs Monate verteilt nicht wenigstens 10 Nachrichten pro Woche aufweisen, werden sie notiert und deren 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: (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 einer Region eingerichtet werden. Jeder REC wird sein Bestes tun, um "Hochgeschwindigkeits Hubs", "Hubs ausserhalb des Staates", "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, das Risiko solcher Schleifen erhoeht oder sich auf Aufforderung durch seinen NEC, REC, oder ZEC weigert solche Verbindungen zu unterbrechen, soll disziplinarischen Massnahmen unterworfen werden, wie in EP1 beschrieben. Siehe Abschnitt 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) sind lt. FTS-0004 verboten (ausser 8Dh, dem "Soft-Return") Das ist nicht dazu gedacht, anderen Zonen oder Netzwerke von der Teilnahme abzuhalten, die diese Zeichen erlauben koennen. 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. (Beispiel: Zone:Netz/Node.Point, wobei Zone und Point optional sind). (8*) c) "Tearlines" sind, inkl. den Vorzeichen "--- ", auf 35 Zeichen begrenzt. 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 (ZoneGating) muessen auf die noetigen Informationen beschraenkt sein. Dies beinhaltet das entsprechende Vorzeichen, plus den Netzwerknamen "Gateway", optional eine Software-Produktinfo gefolgt von einer Adresse in der Form Zone:Netz/Node. (Beispiel: " * Origin: FidoNet Gateway (TCOMM 88:372/666) e) SEEN-BY-Adressen 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 sollten nicht fuer die EM-Verteilung benutzt werden. f) Alle gueltigen FTS-Spezifikationen muessen eingehalten werden. 1.6. VI. ENFORCEMENT (GELTENDMACHUNG UND DURCHFUEHRUNG) Die Geltendmachung und Durchfuehrung von EP1 hat unter der Vorgaben der "General Fidonet Policy" zu geschehen. Beschwerden betreff EM-Verletzungen, wie in dieser Policy beschrieben, koennen von der betroffenen Person, dem Moderator oder jeder Ebene der *EC-Struktur eingereicht werden. Alle Beschwerden gemaess EP1 muessen innerhalb 60 Tage nach Bekanntwerden oder Auftreten des Beschwerdegrundes eingereicht werden. Beschwerden haben nach den Bestimmungen der FIDONET POLICY eingereicht zu werden, mit einer Kopie an den entsprechenden *EC. 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 Anstrengungen um Einhaltung erkennbar sind. 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 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, von ihm eingesetzt 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 zukuenftige 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 Unterstuetzung 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*) Echomail wird - im Gegensatz zu NetMail - an alle dem entsprechenden Echo angeschlossenen Systeme verteilt und erreicht dadurch viele Empfaenger, die ihrerseits wahlweise mit einer Netmail oder Echomail antworten koennen. (2*) (z.B. LARP.GER oder EBBAUSER.GER ;) (3*) {Der MOD hat die Moeglichkeit, Lese- und Schreibberechtigungen fuer ein Echo einzuschraenken, und auf einen bestimmten Teilnehmerkreis zu begrenzen.} (4*) [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.] (5*) [aktuell ist zur Zeit die Version 4.07 (P4)] (6*) [Aus der Definition des "downstream links" ergibt sich, dass ein Ausschluss vom downlink ebenso den uplink einschliesst. Der Zugriff auf das jeweilige Echo wird - in beide Richtungen - gesperrt.] (7*) [Die Policy spricht hier von "Sysop" und "board". Da aber zu einem Node nicht unbedingt eine Mail-Box gehoert, sollte hier folgendermassen gelesen werden: Sysop = Hauptsystem (Node), "board-user" = Subsystem (Point oder OnlineUser) (8*) [und dem Vorzeichen " * Origin: "] ------------------------------------------------------------ Sachliche Kritik und Verbesserungsvorschlaege erwuenscht! ------------------------------------------------------------ Letzte Aenderung: | Kontakt: 5.9.96 | FIDO: 2:2433/601.7 Dirk Richartz | e-mail: drr@big-biz.gun.de ------------------------------------------------------------