From: urlichs@smurf.sub.org (Matthias Urlichs)
Newsgroups: de.comm.gateways
Subject: Re: Ein paar Facts zu Gateko &
Date: 29 Sep 1992 18:14:29 +0100
Organization: University of Karlsruhe, FRG
NNTP-Posting-Host: 127.0.0.1

In de.comm.gateways, article <A48740@MS.maus.de>,
  Kai_Henningsen@ms.maus.de (Kai Henningsen) writes:
> hC> Von : heiko@Harpo.Chemie.FU-Berlin.DE (Di, 22.09.92 15:47)
> hC> Name: Heiko Schlichting
> 
> hC>> Fuer mich als Z-Netz-Programmierer ist ZCONNECT wesentlich einfacher
> hC>> in meine Software zu implementieren als RFC 822/1026. Das ist ein Fact.
> 
> hC> Das ist kein Fakt, sondern falsch. Vielleicht ist das Login-Verfahren
> 
> Ich weiss ja nicht, wieviel entsprechende Software Du schon programmiert hast,
> Heiko. Aber dieser Satz zeugt leider nicht gerade von Kompetenz.
> 
Moment...

> Das liegt primaer daran, dass diese Protokolle besonders mit Blick auf leichte
> Implementierbarkeit entwickelt worden sind, waehrend RFC 821/822 offensichtlich
> diesen Aspekt als eher nebensaechlich angesehen haben. Wohlgemerkt, das ist ein
> Standpunkt, der durchaus seine Berechtigung hat! Andererseits muss man nicht
> notwendigerweise derselben Meinung sein ...
> 
Stimmt wohl. Das hat aber auch seinen Grund: Implementieren musst du den Kram
nur einmal, aber funktionieren in den verschiedensten Situationen muss das
Teil n jahre lang.

> hC> Format nicht. Egal, was Du mir darauf jetzt antwortest, ich kann einfach
> hC> nicht glauben, dass es leichter ist, ein deutsches Schluesselwort zu
> hC> erkennen als ein englisches. Um viel mehr unterschieden sich die Format
> hC> ja nicht, wenn man davon absieht, dass eben die Envelopeadresse fehlt und
> hC> ein paar andere Dinge.
> 
> Und da ist eben der grosse Irrtum! Die Unterschiede sind recht erheblich. Das
> faengt an mit den white-space-und-Umbruch-Vorschriften in RFC822 (-> LWSP), geht
> weiter ueber die Formate der Adressfelder (Name <adresse>, oder adresse und Name
> via () als Kommentar; Gruppen/Listen/einfach nur mehrere Namen; Source-Routing
> ...) bis hin zu den Datumsformaten (die, wie eine spaetere RFC zugibt (1123),
> dank teilweise falscher Beschreibung in diesem Bereich voellig unbrauchbar
> geworden ist); nicht zu vergessen die komplizierte Interaktion von Feldern wie
> Sender:/From:/Reply-To: ...
> 
Mal ne dumme Frage: Wen interessieren diese Teile eigentlich ueberhaupt?

Die Header kann man innerhalb eines Netzes unbesehen durchreichen.
(Im Envelope kommt der ganze Schlonz eh nicht vor.) Die Datumsparserei loest
man dadurch, dass man sich auf das Standardformat festlegt, das eh von 99%
aller Systeme gefahren wird [Tue, 29 Sep 1992 17:35:00 +0100] -- parsbar
durch zehn Zeilen C, unwesentlich aufwendiger als das einzelne sscanf im
ZCONNECT -- und den Rest notfalls von den Gates ins Netz umwandeln laesst.
Diese Arbeit faellt dort ohnehin an.
Uebrigens: Das einzige, was (durch einen Vorzeichenfehler) unbrauchbar
wurde, sind die militaerischen Zeitzonenangaben, die eh keiner verwendet
hat.

Sender:/From:/etc. interagieren ueberhaupt nicht kompliziert. In den RFCs
stehen ein paar Regeln, wann welcher Header verwendet wird, aber die
lassen sich auch aus der Intention der Header an sich ableiten. Im uebrigen
sind das eh _Header_adressen, die fuer den _Transport_ von Mail absolut
uninteressant sind. Sie spielen nur fuer den Benutzer eine Rolle, und da
ist es eine wohl ziemlich einfache Uebung, ein Multiple-Choice-Menu
anzubieten, wohin eine Antwort gehen soll (Reply-To, wenn vorhanden; From;
To; Cc, wenn vorhanden; Sender, wenn vorhanden; andere Adressen).

Das Vorhandensein von Sourcerouten in Envelopeadressen erkennen wir mit 
dem simplen Test, ob das erste Zeichen ein Klammeraffe ist, und senden 
dann an den durch den zwischen diesem und dem naechsten Komma oder
Doppelpunkt angegebenen Rechner die restliche Adresse nach besagtem
Komma oder Doppelpunkt.  Nichts einfacher als das.
Im uebrigen sind Sourcerouten eh optional -- Billigversion:
 if(*adresse == '@') {
   if((p = strchr(adresse,':')) == NULL)
     return FEHLER;
   adresse = p+1;
 }

> Ich schaetze mal, dass eine korrekte Implementation von RFC 821+822+1123 - bis
> hier nur fuer Mails, nicht fuer News! - bestimmt mindestens 5 mal soviel Programm
> braucht wie eine von ZConnect oder MausTausch.

Wenn du den Kram vollstaendig implementieren, alle Header parsen und auf
822-Konformitaet untersuchen willst, hast du vielleicht recht.

Aber insbesondere innerhalb eines Netzes sehe ich zwischen RFC822 und 
meinetwegen ZCONNECT keinerlei Unterschiede im Schwierigkeitsgrad.

Die Header brauchst du nur dort parsen, wo ein Benutzer eine Mail an sein
Transportsystem uebergibt, das dann die Headeradressen evtl. domainisieren 
und in gueltige Envelope-Adressen umkopieren muss (moeglicherweise unter
Konsultation einer lokalen Alias- oder Mailingliste).  Beschraenke dich an 
dieser Stelle auf die in RFC1036 beschriebene Adressformen, und du hast
so gut wie keinen Aufwand und bist trotzdem in der Lage, irgendwann auf
ein System umzustellen, das RFC822 vollstaendig beherrscht. Es _zwingt_ dich
ja niemand, Cc:- und Bcc:- und Resent-XXX:-Header korrekt zu generieren.
Solange alles in Domainform vorliegt (dafuer sorgen im Zweifelsfall eh die
Unixsysteme, die die RFC->ZCONNECT-Gates versorgen ;-) braucht sich niemand
mehr um die Adressen zu kuemmern und die Frage nach dem korrekten Parsen 
derselben stellt sich gar nicht erst. Die ganzen LWSP-Regeln kannst du in
Version 1 erstmal vergessen, Header-Fortsetzungszeilen in der Benutzer-
schnittstelle durch Leerzeichen ersetzen und unbekannte Adressen dem User
zur Aufloesung ueberlassen. Da so gut wie alle Adressen bis auf evtl. Quoting
(wieder zehn Zeilen C, um das richtig aufzuloesen) sowieso den RFC1036-
Einschraenkungen entsprechen, ist das kein ernsthaftes Problem.

> Eine ganz andere Frage ist, wie man die diversen Mailbox-Protokolle
> modifiziert, so dass sie mit der RFC821/822-Welt korrekt zusammenarbeiten
> koennen (Stichwort zB: korrekte Behandlung von Envelope-Adressen). Da muessen die
> Leute aus der RFC-Welt aber auch lernen, essentielle Features von einfach nur
> netten zu unterscheiden!
> 
Schoen. Du sagst mir, welche Features von RFC 822 aus diesem Bereich du fuer
"nett" haelst (im Gegensatz zu "essentiell" und/oder zu "wird im realen
Mailverkehr nunmal benoetigt, um die Intention des Absenders oder des
Betreibers einer Mailingliste darzustellen"), und ich bin gerne bereit, zu
lernen.

PS: Ein wichtiger Punkt ist, dass die Headeradressen im ZCONNECT keine
solchen sind -- es sind Transportadressen, die von Transitsystemen beliebig
gekappt werden koennen (Mail an zwei Adressaten auf verschiedenen Systemen).
Deshalb auch mein Vorschlag, die RFC-Adressheader im ZCONNECT als "RFC-From:"
und "RFC-To:" o.ae. mitzusenden und so die oben beschriebene Methode zumin-
dest auf Transportebene quasi durch die Hintertuer einzufuehren.

-- 
Mosher's Law of Software Engineering:
	Don't worry if it doesn't work right.  If everything did, you'd
	be out of a job.
-- 
Matthias Urlichs  --  urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de   /(o\
Humboldtstrasse 7 -- 7500 Karlsruhe 1 -- Germany  --  +49-721-9612521     \o)/