🚀 go-pugleaf

Gatebau 1991 Arbeitsprotokoll

Arbeitsgruppe ¯Kontrollmechanismen und Strukturen®

Die Arbeitsgruppe hat sich dem Problem in zwei Wegen genaehert. Zum einen 
wurde postuliert, wie ein Gatesystem mit Nachrichten zu verfahren hat; auf 
der anderen Seite wurde ein Standard ueberlegt, mit dem Gates kontrolliert 
werden koennen (nichts aus dem Beduerfnis einer Ueberwachung heraus, sondern 
um es Benutzern und Systembetreuern zu ermoeglichen, Nachrichten hinterher zu 
forschen. Dabei ist zu beachten, dass saemtliche nun folgenden Ergebnisse sich 
lediglich auf Mail beziehen, nicht aber auf News. Es muss noch getrennt 
ueberlegt werden, inwieweit die Ergebnisse auch auf News erweitert werden. Das 
ist nicht Gegenstand dieses Protokolls!

Postulat eines geordneten Nachrichtentransfers
- Nachrichten duerfen nicht verloren gehen!
- Im Gateway und den beiden ueber das Gateway primaer vernetzten Systemen 
muss ein kompetenter Ansprechpartner verfuebar und auch allgemein bekannt 
sein. Der Einfachheit halber sollte ein einheitlicher Adressat verwendet 
werden; aus Gewohnheit waere anzuraten das ohnehin schon einschlaegig 
bekannte Synonym postmaster zu verwenden.
- Der normale Ablauf eines Nachrichtentransfers hat folgendermassen 
auszusehen: Eine Nachricht wird entweder in Richtung des naechsten 
zustaendigen Adressaten weitergeleitet. Ist dieses nicht der durchfuehrbar, 
wird die Mail mit einem entsprechenden Vermerk zurueckgeschickt. Vermerk 
und Nachricht werden in getrennten Mails versandt. Sollte auch das 
scheitern, so wird die Nachricht zwischengelagert und es wird Postmaster 
des entsprechenden Systems informiert (Anmerkung: Postmaster ist jetzt ein 
Synonym fuer einen kompetenten Ansprechpartner im Gateway oder den 
beiden am Gateway vernetzten Systemen sein).
- Sollte eine Nachricht nicht weiterbefoerdert werden koennen, weil sie 
physikalischen Gegebenheiten des Netzwerkes nicht entspricht (die 
Nachricht ist beispielsweise zu gross), so wird der urspruengliche Empfaenger 
darueber informiert, dass er sich auf einem genannten System (einem der 
beiden dem Gateway angeschlossenen Systemen) die Nachricht in originaler 
Form innerhalb einer gewissen, noch festzulegendenen Frist, manuell 
abholen kann.
  Wird die Nachricht nicht in der genannten Frist abgeholt, so wird der 
Absender darueber informiert. Es ist dem Gatewaybetreiber freigestellt, den 
Absender auch zeitgleich mit dem Empfaenger zu benachrichtigen.
  Die physikalische Grenze (z.B. Plattenkapazitaet) kann natuerlich auch die 
Loeschung der Nachricht bewirken, dies ist aber aus der Sicht des 
Zumutbarkeitsverhaeltnisses des Gateways zu betrachten. Dann allerdings 
werden auch Absender und Empfaenger automatisch informiert!
- Eine automatische Nachricht, die vom Gateway generiert wird, erhaelt 
automatisch den Absender einer kompetenten, realen Person (siehe zweiten 
Gedankenstrich). Nicht zulaessig waere beispielsweise ELIZA@GATE.
- Sollte eine Nachricht nicht transportiert werden koennen, so wird der 
Absender ueber diesen Umstand informiert und auch darueber informiert, wie 
er die Ruecksendung seiner Nachricht per Mail (Gatewayfunktion!) 
veranlassen kann. Da die Nachricht die Befoerderung bis zum Gate 
ueberstanden hat, ist auch die Ruecksendung gedanklich gewaehrleistet.
- Sollte eine Nachricht weder zustellbar noch ruecksendbar sein (aus welchen 
Gruenden, das bleibt noch festzulegen), so hat sich der Postmaster um die 
Benachrichtigung des Absenders zu kuemmern, um ihm mitzuteilen, dass die 
Nachricht weder zugestellt noch zurueckgesendet werden konnte!
- Sollte in einer gegateten Nachricht ein "Return-receipt-to:Adresse" 
enthalten, so hat das Gate an der Adresse das Ueberschreiten des Gateways 
zu melden. Sollte das Zielnetz eine Empfangsbestaetigung zulassen, so hat 
das Gateways das Kommando auch fuer das Zielnetz zu uebersetzen.


Definition von Verkehrsdaten und deren automatischer Austausch, bzw. deren 
Abfrage

- Die wichtigsten Verkehrsdaten eines Gates muessen aufbewahrt werden (auch 
dies gilt wiederum nur fuer den Mailtransfer, News werden hiervon nicht 
erfasst!)
- Die Verkehrsdaten werden 28 Tage aufbewahrt.
- Es werden zwei unterschiedliche Dateien fuer die Verkehrsdaten gefuehrt. Die 
Eingangs- und die Ausgangsdaten werden separat gehalten!
- In den Eingangsdaten sind zwingend zu fuehren: Msg-Id, Absendesystem, 
Eingangsuhrzeit, Absendedatum, -uhrzeit und der Pfad
- In den Ausgangsdaten sind zu fuehren: Msg-Id, Ausgangsuhrzeit und -datum.
- In Rechnernamen und Msg-Ids duerfen keine Leerzeichen vorkommen (sollte 
dies unumgaenglich sein, so koennen diese escaped werden).
- Aufbau eines Logfile-Eintrages (hey, Martin, hier musst Du noch mal 
ergaenzen, ich habe da nur unzusammenhaengende Daten in meinem 
Laptop drueber gefunden!)
- Eine Zeile pro Eintrag - jede Zeile enthaelt an festgelegten Stellen 
festgelegte Eintraege
- Zeilen, die mit einem Leerzeichen (Whitespace) beginnen, sind 
Kommentarzeilen, die der vorangehenden, Nicht-Kommentarzeile 
zugehoerig gerechnet werden.
- Das erste Zeichen einer Zeile bestimmt ob es sich um Eingangs- oder 
Ausgangsdaten handelt. From / To Zeichen. From ist "<", To ist ">".
- Aufbau des Datumseintrages: (als Beispiel wird jetzt das Datum der 
Gatebau 1991 angezeigt): "19911214 170140"
  Anmerkungen/Erklaerungen: Jahr (4-stellig), Monat (2-stellig), Tag 
(2-stellig), Whitespace, Stunden (24h), Minuten, Sekunden.
- Datum und Uhrzeit werden als getrennte Eintraege gewertet (daher auch 
die Trennung mit einem Whitespace). Bei Eingang- und Ausgang einer 
Nachricht am Gateway muss das Datums und die Uhrzeit auf Konsistenz 
geprueft werden.
- Im ausgehenden Logfile wird immer die Original-Msg-Id abgelegt UND 
(wenn die Msg-Id sich durch netzimmanente Bedingungen geaendert haben 
kann) auch die Ausgangsid. Sollte durch die Charakteristika der zwei 
gegateten Netze eine Konvertierung nicht notwendig sein, so kann ein 
Gleichheitszeichen als Ausgangsmsg-Id verwendet werden.
- Steuerung / Abfrage von Logfiles
- Info-Request zur Abforderung von Logfiles
- Es wird immer darauf ueberprueft, ob der Absender des Info-Request mit 
den entsprechenden Logfile-Eintraegen uebereinstimmt. Sollte dies der Fall 
sein, so wird der Nachrichtentext des Info-Request auf Inhalt ueberprueft, 
der dann die die Auswahl der Logfile-Eintraege auf Uebereinstimmung in 
der Spalte "Msg-Id" reduziert. Die gefundenen Logfile-Eintraege werden 
dem Info-Requester zugesandt (entweder alle auf den Absender 
passenden oder die auf Absender und Msg-Id passenden)
- Sollten zu einem Info-Requester keine Logfileeintraege vorhanden sein, so 
wird auch darueber der Info-Requester informiert.
- Ein Nachforschungsantrag wird folgendermassen gestellt:
  Eine Nachricht mit Betreff "///INFO-REQUEST:LOGFILE") wird an den 
Info-Request-Server im Gateway gestellt, in der ersten Zeile des 
Nachrichtentextes kann die zu beforschende Original-Msg-Id angegeben 
werden (im Absender-Netz Format!).
  Es werden beide Logfiles (Eingangs- und Ausgangs) zu der angegebenen 
Msg-Id durchsucht. Automatische Erlaeuterungen oder Kommentare zu den 
Logfile-Eintraegen koennen durch die Kommentarzeilenklausel eingefuegt 
werden (fuehrendes Whitespace).

Abschliessende Anregungen
Gates versenden jeweils zum Monats-ersten eine Kurz-Statistik ueber Anzahl 
und kb persoenliche und oeffentliche Nachrichten (Mail, News). Sollte ein Gate 
diese Moeglichkeit nutzen, so hat es folgendes Format zu verwenden:
Absender:GATEWAY@DOMAIN, Betreff:STATISTIK
Ansprechpartner fuer z.B. Info-Requests und Gatewayprobleme muessen in den 
Gates existieren, werden aber Netzadaequat festgelegt (exakte Adresse) und 
muessen veroeffentlicht werden!
Mit der Funktion Info-Request erhaelt man auf jeden Fall die Moeglichkeit - 
wenn nicht den Befehlen weiter oben entsprechend - Informationen ueber die 
verfuegbaren Gateways auf dem entsprechenden System und die verschiedenen 
Adressierungen zu erhalten.