MausTausch <-> RFC Gatewayregeln

Dies ist Edition 0.3 der Gatewayregeln, zuletzt ueberarbeitet am 12.3.1997.

Dieser Text fasst minimale Regeln fuer MausTausch <-> RFC Gateways zusammen. Einiges, wenn auch nicht alles, sollte auch fuer andere Gatewaytypen gelten.

Gatewayanforderungen

  1. Die Splittingkonvention muss eingehalten werden. Siehe section Standard fuer das Splitten von Nachrichten

    Rationale: Es war laengst genug Zeit sie einzubauen.

  2. Sender/Reply-To/Followup-To muessen unterstuetzt werden, sobald sie verfuegbar sind. Dies ist seit MAUS 7.95j der Fall.
  3. Mitteilungen, die beim Import so veraendert werden, daß ein Export nicht sinnvoll ist, muessen geeignet gekennzeichnet werden. Entsprechend gekennzeichnete Mitteilungen duerfen an anderen Gates nicht exportiert werden. Diese Kennzeichnung muss an der Stelle erfolgen, an der die Veraenderung vorgenommen wurde. Wann ist eine Nachricht als nicht-reexport-faehig zu markieren?
    * Crosspostings
    sind als NE zu markieren sobald Gruppenangaben weggeworfen werden.
    * PGP-Header-Signierung
    * Approved-Zeilen
    wenn die Nachricht eine Approved-Zeile enthaelt oder die Header mit PGP signiert wurden ist ein Reexport sinnlos.
    * Controlnachrichten
    kann man mit MausTausch nicht transportieren -> NE. Man erkennt sie an den Headerzeilen Control und Also-Control (son-of-1036, mittlerweile in INN implementiert).
    * Supersedes
    * Expires
    * Sender
    * Reply-To
    * Followup-To
    * Archive-Name (son-of-1036) ???
    * Article-Names (son-of-1036) ???
    * Article-Updates (son-of-1036) ???
    Wenn diese Header auftreten und die entsprechende Information nicht im MausNet vollstaendig transportiert werden kann, ist NE zu setzen. vollstaendig steht da mit Absicht: Selbst wenn MAUS Followup-To beherrscht kann sie immer noch nicht zwei Followup-To-Gruppen ....
    * Distributionen außer world
    sind definitiv ein Grund, die Nachricht nicht wieder zu exportieren.
    * Content-*Header
    Bei Auftreten irgendwelcher mit Content- beginnenden Header, die das Gateway nicht nach Mime-Convention in den Body setzt (z.B. weil es die Header nicht kennt) ist das NE-Flag zu setzen.
    Natuerlich kann ein Gateway beim Export grundsaetzlich noch restriktiver sein. Es ist ein wirkungsvoller Schleifenfilter, oeffentliche Fremdnetzmitteilungen grundsaetzlich nicht zu exportieren - aber die Entscheidung darueber kann am besten der lokale Sysop treffen.
  4. Der Pathhack (news.maus.de in den Path eintragen) wird nur noch fuer Fremdnetzmitteilungen gesetzt. Bei Mausmitteilungen wird er weggelassen. Statt dessen werden bei Mausmitteilungen beim Reimport aus der langen Message-ID die kurze Id ermittelt und als Temp-ID verwendet.

    Rationale: Der Pathhack ist fuer MausNetintern erzeugte Nachrichten komplett unnoetig dann man die kurze Message-ID (seit nunmehr ueber 2.5 Jahre, AFAIR) aus der langen ID zuverlaessig zurueckgewinnen kann.

    Fuer exportierte Fremdnetzmitteilungen ist er sinnvoll speziell fuer mit Fido und Usenet vernetzten Gruppen (Nachricht aus Fido via MausNet wird ueber irgendein Usenetgate exportiert und an einem anderen wieder importiert). [das schuetzt aber nur solange vor Dupes wie Usenet und Fido die Gruppe nicht direkt miteinander austauschen :-)]

  5. Als Absenderadressen sind die Angaben aus der D-Zeile im EXP zu verwenden.

    Das ist die domain, die laut Sysop@Box bevorzugt verwendet werden soll. Glaub' dem Sysop - er weiss hoffentlich was er tut. Und wenn nicht kann ein Programm das kaum erkennen.

  6. Nachrichten aus Boxen ohne D-Zeile im EXP werden nicht exportiert.

    Dadurch entfaellt die Notwendigkeit der Sperrliste - jener sowieso haeufig hoffnungslos veralteten Liste der Boxen, deren Nachrichten nicht exportiert werden duerfen.

  7. Transit von Mail, verursacht durch den PM-Forwarder (Usenet an MausNet weitergeleitet an Usenet) muß erlaubt sein.

    Artikel 4 der IN Netiquette trifft nicht zu. Er lautet:

    Es ist nicht zulaessig, auf Sites, die dem Individual Network angehoeren, Mailforwarder fuer Rechner oder Benutzer einzurichten, die nicht dem Individual Network angehoeren.

    Der Benutzer, der den Forwarder einrichtet, gehoert dem IN an (oder besser gesagt, er ist Zahler in einer Box, die wiederum einem Verein Geld ueberweist, der dem IN angehoert).

  8. Die Konventionen zur M-Zeile muessen implementiert sein (rudimentaere Mime-Unterstuetzung)

    Auch dafuer war mittlerweile genug Zeit.

  9. Das Bouncen von oeffentlichen Mitteilungen ist verboten.

    Es steht im Widerspruch zu jeder mir bekannten Gatewayvorschrift. Gateways duerfen oeffentliche Mitteilungen entweder gaten oder wegwerfen. Es ist nicht akzeptabel, den Absender mit Antworten, Warnungen oder Bounces zu quaelen (bei >40 Gateways im Netz koennte der Benutzer 40 Antworten fuer jeden geposteten Artikel erhalten - was ganz sicher unerwuenscht ist).

  10. quoted-printable muss, soweit mit vertretbarem Aufwand moeglich, konvertiert werden.

    vertretbarer Aufwand ist relativ. Eine on-the-fly Konvertierung des gesamten Textes und der Header sollte hinreichend trivial sein. Komplette Mime-Multipart-Parser fuer den Zweck, auch das im vierten von fuenf Bodyparts eingestreute q-p zu dekodieren duerfte allerdings zu aufwendig sein - es sei denn, man parst den Body sowieso schon.

    quoted-unreadable erfreut sich einer gewissen Unbeliebtheit. Es ist also Dienst am Benutzer, das soweit moeglich zu dekodieren.

    base64 ist ein anderes Problem - dahinter stecken in den allermeisten Faellen Binaries.

  11. Fortsetzungszeilen muessen korrekt verarbeitet werden. Es ist nicht tolerabel, z.B. References dieser Art falsch auszuwerten: 
    References: <1@A> <2@B>
	<3@C>
	<4@D>
    Der korrekte Inhalt der R-Zeile waere in diesem Fall 4@D. Bei Textheadern ohne besonderes Format (Subject z.B.) darf natuerlich nicht nur die letzte Zeile genommen werden.

Standard fuer das Splitten von Nachrichten

Wenn eine Nachricht gesplittet werden muß (was man besser vermeiden sollte), dann muessen den einzelnen Teilen Message-IDs nach folgendem Verfahren gegeben werden:

  1. Die Nachricht wird in N Teile zerlegt.
  2. Die n Teile erhalten folgende N IDs: 
    abcd@x.y.z
abcd@x.y.z:2
...
abcd@x.y.z:{N-1}
abcd@x.y.z:N
  3. N darf dabei auch eine Zahl > 9 sein. Es gilt N > 1, N Element "unsigned int". N als Byte zu deklarieren ist ein Verstoß gegen diesen Standard.
  4. N wird im Dezimalsystem ohne fuehrende Nullen codiert, also z.b.: abcd@x.y.z:12345
  5. Die Teile 2 bis N duerfen untereinander verkettet werden.
  6. Saemtliche Headerzeilen sind in allen Teilen der Nachricht zu duplizieren. Ausnahmen sind ID-Zeile und R/--Zeile.

Ein Programm, das gesplittete Nachrichten wieder zusammensetzen will, kann einen Teil einer gesplitteten Nachricht daran erkennen, daß im Domainpart der ID nach dem letzten Punkt (so einer vorhanden ist - RFC822-Mail zeichnet sich durch unschoene Überraschungen aus) ein Doppelpunkt kommt, dem nur noch Ziffern folgen.

Wenn das zusammensetzende Programm merkt, daß Teile fehlen, ist je nach Typ der Nachricht unterschiedlich zu verfahren:

* News (oeffentliche Nachrichten)
Es ist auf den flood-fill-mechanismus des Usenets zu hoffen. Die Nachricht darf keineswegs weitergeleitet werden. Der Implementation steht es allerdings frei, ein paar Tage zu warten, ob der Rest der Nachricht noch eintrifft.
* Mail (persoenliche Nachrichten)
Nach einer angemessen (kurzen) Zeit des Warten auf die fehlenden Teile sollte der Rest der Nachricht weitergeleitet werden, moeglichst mit einem Hinweis im Text. Das ist eigentlich ein "this should not happen", aber es *kann* passieren wenn aus irgendwelchen Gruenden ein Teil einer Mail ueber einen anderen Weg geroutet wurde. Es ist nicht akzeptabel, daß Mails verschwinden.

Dieselbe Software, die Nachrichten wieder zusammensetzt, muß auch dafuer sorgen, daß Kommentarverkettungsinformationen, die sich auf Teile von gesplitteten Nachrichten beziehen, angepaßt werden (durch Entfernen des :N am Ende der Referenz-ID).

Das Verfahren zeichnet aus:

Haken:

Literaturhinweise

Fuer Mausnetgateways weniger interessant (der Vollstaendigkeit halber erwaehnt):

Erhaeltlich sind alle genannten RFCs (und die meisten anderen) in der DU3, unter ftp://tirka.ohse.de/pub/doc/rfc/ (der Pfad entspricht dem im lokalen Programmteil).

This document was generated on 16 June 1997 using the texi2html translator version 1.51(uo).