Gate's 91 (ein Rueckblick)

[m.hus...@bionic.zer.de]

Gateways 1991: ein Jahr nach der 1. GateBau

Vor einigen Tagen ging die zweite Gate-Bau Konferenz in Hannover
zu ende. Obwohl viele sich mehr und konkretere Beschluesse erhofft
hatten (insbesondere die, die noch an ihrer Erstvergatung
arbeiten), war es ein fruchtbares Treffen.

Herausgekommen sind aus meiner Sicht fuenf Dinge:

1. Klaerendes zu bereits existierenden GateBau-Standards bzw.
Standardisierung einiger praktizierter Verfahren.
2. Ein Verfahren sowie die Definition eines Pflicht-
Logbuches, das es ermoeglicht, automatisch Mail-Verluste
in Gate's zu erkennen.
3. Der Beschluss, zur besseren netzpolitischen Zusammenarbeit
eine global vernetzte Gruppe "Netzwesen" einzurichten.
4. Eine voruebergehende Notloesung fuer die Umstellung des
Berliner Z-NETZ <--> Internet Gates auf der Pericont.
5. Ein Erreichbarkeits/Zuverlaessigkeitstest fuer die interne
Gateway-Arbeitsgruppe "Gate-Bau".

All das wird in den Protokollen der einzelnen Arbeitsgruppen noch
genauer erklaert und veroeffentlicht werden.

Ich moechte diesen Anlass nutzen, in typischer Endjahresmanier
einmal auf das Jahr nach der ersten GateBau zurueckzublicken. Es
hat mehr gebracht, als ich erwartet hatte:

- Es hat NICHT das neue Zerberus-Netcall-Format (ZCONNECT)
gebracht, das schon zur letzten GateBau erwartet wurde.
- Es hat zum dritten Mal eine Umstellung der Message-ID
Erzeugung in meinem Gate erfordert: von meinem eigenen
Verfahren auf das GateBau'90 Verfahren, dann auf die
aktuelle CRC-Version mit der Unix-Timestamp und jetzt
noch einmal auf das GateBau'91 Verfahren.
- Es fuehrte zum ersten netzverbindenden System das
ausdruecklich KEIN GATE ist - aber genau wie ein Gate
Dupes produzieren kann.
- Der running-gag des Jahres:

`Ich weiss warum UZERCP-Nachrichten bei mir im
Unzustellbar (junk) landen: der schreibt "Message-ID:"
statt "Message-Id:" '
- Es hat einen entscheidenden Besuch bei Uni-Dortmund
gebracht, der schliesslich zur Gruendung des IN und damit
zur Moeglichkeit der Domains ".zer.de", ".ccc.de" und
".comlink.de" fuehrte.
- Es hat eine Z-NETZ Sysop-Konferenz gegeben, die blind den
Entschluessen der GateBau'91 vertraute und beschloss, alle
wild wuchernden Gates bis zum 1.3.1992 abzuschalten.
Bravo!
- Es hat mir nette Spendenaufrufe von lieben Netzkollegen
eingebracht, die mir zwar ihre Bankverbindung nannten -
aber dank einer falschen/ungeschickten
"From: pe...@cybnet.UUCP"-Zeile am Anfang der Nachricht
jeden Mail-Kontakt wirkungsvoll unterdrueckten.
- Und es fuehrte zur deutschen Mail-Wiedervereinigung
zwischen Sub- und DNet. Daran haette ich als hartnaeckiger
Optimist wirklich nicht mehr geglaubt...

Neben solchen mehr oder weniger einschneidenden Ereignissen gab es
natuerlich den ueblichen Zank und Streit sowie diverse Soloeinlagen
unter der Rubrik "mein Gateway macht mehr Dupes als Deiner!". Auch
mein Gate hat dabei einige excelente Soli vorgefuehrt.

Die wichtigste Einsicht ist meiner Meinung nach aber die
Wiederentdeckung des Voice-Telefones zur Pflege der Netzkultur.
Neben ihren Gator-Abschnitten (E-Mail Adressen) tauschen Gate-
Betreiber nunmehr auch Postalische Adressen sowie Telefonnummern
aus. Und oft hat ein klaerendes Gespraech sehr schnell zu einer
allseits befriedigenden Loesung gefuehrt.

Juengstes persoenliches Beispiel dieser Art: Pericont. Seit geraumer
Zeit hatte dieser Gate weit ueber seine urspruengliche Konzeption
als Point hinaus wichtige Serveraufgaben uebernommen. Allerdings
war Michael aus verschiedenen Gruenden bisher nicht in der Lage,
die existierende Software soweit zu verbiegen, das sie GateBau
konform war. Schon gar nicht im laufenden Server-Betrieb. Als wir
uns auf der GateBau'91 trafen, konnten wir binnen kurzer Zeit eine
Uebergangsloesung entwickeln, die Pericont zunaechst von seinen
Serveraufgaben entlastet und damit Zeit gibt fuer die Anpassung
oder Neuimplementierung eines GateBau konformen Gates. Michael hat
nicht lange gezoegert und seinen Gate auf lokalen Betrieb
heruntergefahren. Hut ab!

Ebenso wichtig finde ich den Beschluss der Z-NETZ Sysops, kuenftig
nur noch GateBau konforme Gates zuzulassen. Dies ist sehr wichtig,
da der einzelne Sysop vor Ort gar nicht absehen kann, welche
Folgen bestimmte Macken oder Unarten eines Gates haben. Oft
funktioniert fuer den Menschen vor Ort der Gate perfekt, erst wenn
die Nachricht durch einen weiteren Gate aus dem Netz hinaus und
durch einen dritten Gate wieder hineinging und ploetzlich ganz
anders aussieht (incl. neuer Message-ID) muss irgendeinem dieser
drei Gates die Schuld zugewiesen werden.

Auch dazu ein praktisches Beispiel:

URANUS.ZER ist ein Z-NETZ System, an dem einige Points per UUCP
angeschlossen sind. URANUS ist also (zumindest technisch gesehen)
ein Gate zwischen UUCP und Z-NETZ. Da die UUCP-Points keine
weitere Verbindung ausser URANUS nach draussen haben, betrachtet
URANUS sich nur als lokaler Gate und nimmt daher die GateBau
Richtlinien fuer UUCP<-->Z-NETZ nicht fuer sich an. Er erzeugt aber
einen grossen Teil der GateBau-Textheader. Z.B. wird der User
"peter" auf dem Point "cybnet" als "PETER%CYB...@URANUS.ZER"
adressiert. URANUS schreibt nun in den Text als erste Zeile
"From: pe...@cybnet.UUCP". Aus Sicht der URANUS ist das richtig:
dort funktioniert genau diese Adresse. Allerdings nur dort: jedes
UUCP-System jenseits der URANUS kann mit dieser Adresse ueberhaupt
etwas anfangen. Gueltig waere z.B.
"From: peter%cyb...@uranus.zer.sub.org".

Weiterhin wandelt URANUS die UUCP-Message-ID nicht nach dem
GateBau-Verfahren, sodass die Text-Zeile "Message-Id: <...>" nicht
mit der Z-NETZ Message-Id zusammenpasst.
Soweit - so gut. Aus lokaler Sicht (bzw. wenn URANUS der einzige
Gate des Z-NETZes waere) funktioniert alles wunderbar.

Nun hat aber das Z-NETZ weitere Gates. Z.B. die BI-LINK. Diese
geht hin, analysiert die Text-Headerzeilen im Z-NETZ Format und
erzeugt daraus eine Nachricht von "pe...@cybnet.UUCP" mit der
Message-ID, die diese Nachricht urspruenglich beim Eintreffen auf
der URANUS hatte. Wunderbar, koennte man meinen, die Nachricht ist
trotz Verstuemmelung auf Z-NETZ Format doch sauber durch das Z-NETZ
transportiert worden und hat nun wieder genau ihr originales
Format.

Dann gibt es aber weitere Gateways, z.B. UZERCP. Dieser bekommt
die cybnet-Nachricht im UUCP-Format von der BI-LINK. Die Nachricht
ist dabei EINDEUTIG (@cybnet.UUCP) eine Nachricht, die NICHT aus
dem Z-NETZ, sondern aus dem SubNet/DNet kommt. Also wird sie ins
Z-NETZ gegatet, und zwar GateBau-konform. Dazu wird die Message-ID
durch einen CRC ueber die Original-Message-ID gebildet. Heraus
kommt eine Nachricht von "peter%cyb...@uzercp.zer" bzw. demnaechst
"peter%cyb...@uucp.zer". Diese Nachricht hat eine gaenzlich andere
Message-ID als die von URANUS dafuer vergebene (da UZERCP nach
GateBau-CRC-Methode arbeitet, URANUS aber nicht).

Und schon sind Dupes da. Neben den zwei Methoden zur Erzeugung
einer Message-ID fuehrt die falsche "From: ..." Zeile im Text auch
dazu, dass auf diese Nachricht nicht geantwortet werden kann.

Und wer ist nun Schuld? Wir haben zwei GateBau-konforme Gates und
einen nur-lokalen-Gate. Jeder fuer sich arbeitet korrekt.

Aber: das Problem traete nicht auf, wenn URANUS GateBau-konform
waere. Standards einhalten bedeutet Berechenbarkeit. Und gerade im
Bereich der Gateways ist die Auswirkung einer Entscheidung fuer
einen einzelnen Programmierer oder Betreiber selten global
absehbar.

In der Hoffnung, dass die neue Gruppe "Netzwesen" uns die
Zusammenarbeit erleichtern wird

Gruss & Guten Rutsch

Martin.

[sy...@uranus.zer.sub.org]

Hallo Martin Husemann !

[...]
#Weiterhin wandelt URANUS die UUCP-Message-ID nicht nach dem
#GateBau-Verfahren, sodass die Text-Zeile "Message-Id: <...>" nicht
#mit der Z-NETZ Message-Id zusammenpasst.
[...]
#Nun hat aber das Z-NETZ weitere Gates. Z.B. die BI-LINK. Diese
#geht hin, analysiert die Text-Headerzeilen im Z-NETZ Format und
#erzeugt daraus eine Nachricht von "pe...@cybnet.UUCP" mit der
#Message-ID, die diese Nachricht urspruenglich beim Eintreffen auf
#der URANUS hatte. [...]

Genau das ist der Punkt !

Die BI-LINK darf lt. Gatebau eben NICHT einfach den Gatewayheader der
URANUS benutzen ! Zunaechst musz die BI-LINK unbedingt sicherstellen,
dasz die URANUS einen CRC ueber die Id gebildet hat. Ist dieses nicht
der Fall, darf die BI-LINK den Header nicht benutzen. So steht es in
der Gatebau.

Ich bitte Dich, Deine Software dahingehend umzugestalten, damit solche
Probleme nicht mehr auftreten.

Schoen waere es, wenn wir gemeinsam versuchen wuerden, auftretende Probleme
zu loesen - anstatt lesen zu muessen, dasz Mails von der URANUS von der
BI-LINK nicht mehr gegatet werden.

Guten Rutsch,
MfG. Goetz Schuchart

[Peter Much]

In article <965532...@BIONIC.zer>, m.hus...@bionic.zer writes:
>
> Und wer ist nun Schuld? Wir haben zwei GateBau-konforme Gates und
> einen nur-lokalen-Gate. Jeder fuer sich arbeitet korrekt.
>
> Aber: das Problem traete nicht auf, wenn URANUS GateBau-konform
> waere. Standards einhalten bedeutet Berechenbarkeit. Und gerade im
> Bereich der Gateways ist die Auswirkung einer Entscheidung fuer
> einen einzelnen Programmierer oder Betreiber selten global
> absehbar.

Okay, Stellungnahme dazu:

In der Form, wie ich die bei der Uranus in den Zerberus
abgehenden Messages abgesegnet habe, hatten sie ueberhaupt
keinen zusaetzlichen Header ausser einer Zeile:
Realname: ...

Sie sahen also so aus wie von einem Point. Somit traf auch
das obengesagte zu bezueglich Points und nur lokalem Betrieb;
und das beschriebene Problem waere nicht aufgetreten.

Nun hat aber Goetz (sysop@uranus) von verschiedenen Seiten
aus dem Z-Netz Druck bekommen, er moege Gatebau-konforme
Nachrichten erzeugen, weil er anderenfalls vom Netz
abgeklemmt wuerde.
Somit hat er die selben Headerzeilen implementiert, wie sie
auch von echten uucp-Gates erzeugt werden, so gut dies eben
in diesem Fall geht, und obwohl es voellig unangebracht und
ungeeignet war.

Dass dieses eine Netzkatastrophe bedeuten koennte, konnte ich
in diesem Moment leider nicht absehen. Da aber der ganze
Unfall letztlich nicht groesser ist, als dass genau meine
persoenlichen Postings zweimal durchs Netz kreisten (und
vielleicht ein paar vom Osgo), und andererseits das
Problembewusstsein in diesen Zusammenhaengen netzweit
erheblich geschaerft wurde, koennte das ganze vielleicht
sogar als sinnvoll angesehen werden.

In jedem Fall halte ich die Vorgehensweise, einen
Programmierer eines fehlersicheren lokalen Gates solange
unter Druck zu setzen, unsinniges Zeug einzubauen, bis dieses
Zeug anderswo Fehler produziert, fuer reichlich daneben.

> In der Hoffnung, dass die neue Gruppe "Netzwesen" uns die
> Zusammenarbeit erleichtern wird

Hoffentlich gibts ein bischen mehr eindeutige Kommunikation ...

Gruss

Peter

--
Peter Much, Koelnische Str. 22, 3500 Kassel, 0561/774961 Voice, 775177 Data
P.M...@ASCO.ZER | PETER%CYB...@URANUS.ZER | uucp: pm...@veeble.han.sub.org
ACHTUNG: cybnet kann nicht direkt aus dem subnet oder Dnet adressiert werden!!