From: heiko@Harpo.Chemie.FU-Berlin.DE (Heiko Schlichting)
Subject: Re: Ein paar Facts zu Gateko & ZCONNECT
Organization: Free University of Berlin, Dept. of Chemistry
Date: Tue, 15 Sep 1992 05:36:10 GMT

p.mandrella@sps-hh.zer.de writes:

>KRIS%TPKI.TOPPOINT.DE@UUCP.ZER meinte am 11.09.92 in <U5G6oGF+Ld@UUCP>:
>
>KT> Header der Nachricht beim Transport veraendert.  Zusaetzliche
>KT> Empfaengerangaben werden herausgekuerzt, wenn die Nachricht
>KT> sich auf dem Weg verzweigt.
>
>Nein, sie werden in der Headerzeile "KOP" mit uebergeben.

Das verringert aber die Information entscheidend. Der Empfaenger einer
Nachricht kann nicht mehr feststellen, ob er das Original oder die Kopie
bekommen hat. Das ist aber in vielen Faellen wichtig zu wissen, da
meist nur auf das Original geantwortet werden muss und die Kopien
nur zur Information gedacht sind.

Das groesste Problem, welches ich beim ZCONNECT Message-Format sehe:
es fehlt die Envelope-Adresse. Wie sollen dann Mailing-Listen und
BCCs (blind carbon copy) richtig behandelt werden koennen?

Beispiel:

Nehmen wir mal an, dass in der Mailingliste des Individual Networks 
Teilnehmer enthalten waeren, die ueber ZCONNECT-Systeme zu erreichen sind 
oder selbst ein ZCONNECT-System betreiben. Zum Beispiel die fiktive
Adresse USER@SYSTEM (im Z-NETZ) bzw. user@system.zer.de (im Internet).

Wenn jetzt eine Mail an die Liste geht, so steht in dem RFC-Header als
Adressat die Mailingliste:

To: in@IN-Berlin.DE (Administration Individual Network)

und als Empfaenger steht in der Envelope-Adresse (in SMTP-Schreibweise):

RCPT TO: user@system.zer.de

Wie will ZCONNECT das umsetzen? Sicher ist, dass diese Nachricht an
USER@SYSTEM weitergeleitet werden muss, aber dabei muss ja
weiterhin als Adressat die IN-Mailingliste erkennbar bleiben, denn
sonst wuerde der Empfaenger ja nicht feststellen koennen, dass es
sich um eine Mail an die IN-Mailingliste handelt und seine Antwort
wuerde an den Absender der Nachricht und nicht in die IN-Mailingliste
gehen.
Die Attribute "OAB" und "OEM" bei ZCONNECT sind ja dafuer nicht geeignet,
denn ZCONNECT kann ja nicht erkennen, dass es sich um eine Mailing-Liste
handelt. Ausser gehe ich aufgrund der Beschreibung davon aus, dass
bei einem (G)roup Reply [wie heisst das im Z-Netz?] diese Adresse
nicht an Zieladresse benutzt wuerde, sondern die Adresse im Header-
Feld "ABS".

Das gleiche gilt fuer den Absender. Dort ist im Header der echte
Absender eingetragen, aber im Envelope der Mailinglistenverwalter.
Das ist zwingend notwenig, da Fehlermeldungen ja unbedingt an den
Verwalter der Mailingliste zurueck gehen muessen und nicht an den,
der die Mail in die Liste geschickt hat. Wenn das nicht funktioniert,
wuerde der arme Mensch, der in eine Mailingliste schreibt, die auch
ueber ZCONNECT-Systeme verteilt werden, ja Fehlermeldungen bekommen,
was natuerlich eine enorme Belaestigung (und teuer) sein kann, wenn
man an die Mailinglisten mit Tausenden Mitgliedern im Internet/Bitnet
denkt. Ausserdem kann derjenige, der die Mail an die Liste geschickt
hat, den Eintrag in der Liste ja nicht korrigieren. Das kann nur der
Mailinglistenverwalter und dessen Adresse steht im Envelope. Dieser
muss hingegen die Fehlermeldung bekommen. Wie will ZCONNECT das machen
ohne Envelope-Adresse? 
Die Spezifikation, dass Mailinglisten so organisiert sein muessen, wie
ich es beschrieben habe, steht uebrigens noch mal ausdruecklich in 
RFC1211 und benutzt ausschliesslich Features von RFC822 (Envelope-
Adressen)

1211  Problems with the maintenance of large mailing lists.  Westine, A.; 
      Postel, J.B.  1991 March; 54 p. (Format: TXT=96167 bytes)

Hier mal ein Zitat aus RFC822, Kapitel 1: "INTRODUCTION":

[...]
In this context, messages are viewed as having an envelope
and contents. The envelope contains whatever information is
needed to accomplish transmission and delivery. The contents
compose the object to be delivered to the recipient.
[...]

Mir scheint es nach dem Lesen des ZCONNECT-Textes nicht plausibel, wie
es ZCONNECT gelingen soll, dieses in der jetzigen Form zu realisieren
und Mails wie die oben geschilderte, richtig auszuliefern.

Ausserdem bin ich ein wenig ueber die Stellung des "ROT" Headers
bei Mail (=PM) verwundert. Nach der Spezifikation kann eine Mail
nicht zweimal ueber das gleiche System laufen. Das klingt fuer
fuer News vernuenftig, aber gibt es im Z-Netz denn keine ".forward"
Funktionalitaet (=Nachsenden der Mails)? In dem Fall ist es ja voellig
normal, dass eine Mail mehrfach den gleichen Rechner durchlaeuft. Und
selbst wenn es das jetzt nicht gibt, halten es die ZCONNECT-Programmierer
fuer sinnvoll, eine solches Feature auch in Zukunft nicht mehr ein-
bauen zu koennen, weil sie es durch die "ROT" Spezifikation unmoeglich
gemacht haben? Eine Limit von 1 fuer News und 5 fuer Mails wuerde mir
wesentlich sinnvoller erscheinen. Das wuerde auch verhindern, dass
im Falle einer Routinganderung die Mails, die einen Rechner deshalb
doppelt durchlaufen muessen, nicht ausgeliefert werden, sondern an
den 'Sysop' gehen. 

Heiko

PS: auch wenn ZCONNECT-Programmierer diesen Text fuer die Langform von
    "Heiko mag ZCONNECT nicht." interpretieren, so waere mir mit einer
    sachlichen Darstellung, wie ZCONNECT mit Envelope-Adressen umgehen
    soll, mehr geholfen.
-- 
Heiko Schlichting                     | Freie Universitaet Berlin
heiko@groucho.chemie.fu-berlin.de     | Institut fuer Kristallographie
Newsgroups: de.comm.gateways