Uwe Ohse

Artikel

Header/Envelope-Trennung

Immer wieder f�llt mir auf da� viele Leute, obwohl sie teilweise jahrelang mit dem Medium Email umgehen, vielleicht sogar Mailboxen betreiben oder bei einem Internetprovider besch�ftigt sind, dennoch nicht wissen was der Envelope einer Nachricht ist. Dies ist ein Versuch ihn zu erl�utern.

Das Leben ohne Envelope

Fangen wir vorne an: Sender A verschickt eine Nachricht an Empf�nger B. So k�nnte sie aussehen:

          From: A
          To: B
          Subject: Eine Nachricht

          Inhalt der Nachricht

Das ist, auf das Wesentliche reduziert, was wir im Allgemeinen von den Nachrichten sehen: Einen Header und den Body (Nachrichteninhalt).
Das reicht soweit auch aus, damit k�nnte man ein einfaches Mailtransportsystem aufbauen (und in der Tat haben die meisten Mailboxnetze auch nicht mehr getan).

Dieses einfache Verfahren st��t ungl�cklicherweise schnell an seine Grenzen. Nehmen wir mal folgende F�lle:

B ist verreist und l��t sich die Nachricht an die Adresse C weiterleiten. Was passiert nun? To: mu� nat�rlich ver�ndert werden, From: bleibt unver�ndert (unter anderem weil, wenn `C' nicht erreichbar ist, es auch ziemlich witzlos ist eine Fehlermeldung an `B' zu senden, die dann wieder an `C' zu senden w�re. Oops. Schleife).
Das funktioniert, ist aber nicht gerade elegant - schlie�lich kann der Empf�nger so nicht nicht mal erkennen an wen die Nachricht urspr�nglich gegangen ist (was m�glicherweise wichtig ist wenn er mehrere Adressen auf `C' umleiten l��t).
B ist eine Mailingliste mit einigen tausend Empf�ngern. Man kann dann davon ausgehen da� immer einige Empf�nger nicht erreichbar sind. Es d�rfte einsehbar sein da� nicht `A' die Fehlermeldungen bekommen sollte, sondern der Listenverwalter. Also vielleicht so?
```
          From: listenverwalter
          To: D
          Subject: Eine Nachricht

          Inhalt der Nachricht
  
```
Aber was passiert wenn jetzt jemand antwortet? Der Listenverwalter w�rde dann sehr schnell ungl�cklich werden. Also besser so?
```
          From: B (zur Erinnerung: B ist die Adresse der Liste)
          To: D
          Subject: Eine Nachricht

          Inhalt der Nachricht
  
```
Aber dann geht der urspr�ngliche Absender verloren - auch nicht gut.
In der Praxis l�st man das h�ufig so (zum Beispiel im MausNet):
```
          From: B
          To: D (irgendein Empf�nger)
          Subject: Eine Nachricht

          Dies ist eine Nachricht von A

          Inhalt der Nachricht
  
```
Sprich man versucht die Informationen im Text unterzubringen - was allerdings mit PGP-Signaturen problematisch wird. Andererseits kann man mit dieser L�sung sowieso keinen Sch�nheitspreis gewinnen ... vergessen wir sie besser.

Durch den Einsatz der Reply-To:-Zeile kann man die Probleme zwar entsch�rfen, aber nicht sauber l�sen. Im Falle der Mailingliste k�nnte man dann so vorgehen:

          From: listenverwalter
          To: D (irgendein Empf�nger)
          Reply-To: liste
          Subject: Eine Nachricht

          Dies ist eine Nachricht von A

          Inhalt der Nachricht

Sch�n ist das allerdings nicht - was passiert wenn der Absender selbst Reply-To: E gesetzt hatte, weil er im Begriff ist seinen Wohnort/Provider/Urlaubsort zu wechseln?
Und warum zum Henker kann ohne Verrenkungen (manuelles Eintippen der Empf�ngeradresse) keine Antwort nur an den Absender gesendet werden?

Offensichtlich geht hier etwas schief - so wie es aussieht ist die Vermengungen der Informationen im Header mit den Transportinformationen problematisch.

Die L�sung - der Envelope

Wenn einfache L�sungen nicht ausreichen, was tun? Nun, man macht die Sache so kompliziert wie n�tig - man f�gt eine weitere Informationsschicht hinzu, die nur f�r Transportzwecke verwendet wird. In Anlehnung an das Briefwesen nennt man sie Envelope (Umschlag). Die Analogie ist nicht ganz perfekt - Internetmailsysteme verewigen den Weg, den die Nachricht nimmt, im Header der Nachricht (was ich durchaus f�r einen konzeptionellen Fehler halte - w�rde diese Information im Envelope �bertragen k�nnte man problemlos ganze Nachrichten signieren statt nur den Inhalt und, siehe PGP-signierte Controlmessages im Usenet, ausgew�hlte Header. Ausserdem w�re es logischer alle Transportinformationen, inclusive der beigef�gten Debuginformationen, an einer Stelle aufzubewahren).

Wie versenden jetzt wieder eine Nachricht. Der Darstellung willen habe ich die Envelope-Informationen einfach vor die Nachricht gestellt, praktisch funktioniert das etwas anders.

          Envelope-From: A
          Envelope-To: B
          From: A
          To: B
          Subject: Eine Nachricht

          Inhalt der Nachricht

Was entsteht daraus?

sei `B' ein Nachrichtenweiterleiter auf `C':

          Envelope-From: A
          Envelope-To: C
          From: A
          To: B
          Subject: Eine Nachricht

          Inhalt der Nachricht

Je nachdem wie das Weiterleiten durchgef�hrt wird kann auch schon mal `B' (oder etwas anderes was der Besitzer von `B' oder seine Programme dort eintragen) im Envelope-From: stehen, aber das ist Sache von `B'.

sei `B' eine Mailingliste, und `D' ein Leser:

          Envelope-From: listenverwalter
          Envelope-To: D
          From: A
          To: B
          Subject: Eine Nachricht

          Inhalt der Nachricht

Elegant, nicht? `listenverwalter' kann nun auch noch ein Programm sein ...

Aber ich brauche das nicht, es geht auch ohne

Gem�nzt auf J�rg wir brauchen diese Internetbesonderheit nicht Stattaus.

Nat�rlich geht es auch ohne - aber mit geht es besser. Viel besser.
Denn selbst wenn man, wie im MausNet, Mailinglisten lieber nicht sieht (jedenfalls offiziell - praktisch gibt es genug davon!) - der Rest der Welt benutzt sie trotzdem, und nat�rlich wollen MausNet-Benutzer daran teilnehmen. Nicht jeder vielleicht - aber das sollte man den Leuten selbst �berlassen.

Was passiert denn beim �bergang ins MausNet mit dem Envelope?

Im Prinzip ist das Sache der Gatewaysoftware. Es gibt allerdings nur eine L�sung mit minimalen Problemen (im Vergleich zu anderen L�sungen ohne Envelope. Nicht im Vergleich zu einer optimalen L�sung).
Wenn diese Nachricht aus dem Internet k�me:

          Envelope-From: A
          Envelope-To: B
          From: C
          To: D
          Subject: Eine Nachricht

          Inhalt der Nachricht

dann macht das Gateway (mindestens mauscon) daraus:

          From: C
          To: B
          Subject: Eine Nachricht
  
          Inhalt der Nachricht

(tats�chlich schreibt mauscon noch eine X-To: D-Zeile in den Body [woanders kann es die, dank MausTausch, nicht unterbringen])

Das bringt einige Probleme mit sich - die eigentlich oben schon beschrieben worden sind:

so kann der Empf�nger im Mausnet nicht mehr erkennen da� die Nachricht an eine Mailingliste gegangen ist (naja, dank Mauscons X-To:-Zeile k�nnen es die Empf�nger von Nachrichten, die �ber Mauscon-Gateways gelaufen sind, doch, aber das ist nur ein Hack und keine saubere L�sung).
gehen so eventuelle Fehlermeldungen (z.B. wenn B nicht existiert) an den Absender der Nachrichten - nicht an den Mailinglistenverwalter.

�brigens gibt es an einer Stelle ein Envelope-To im MausNet

Wenn in der Box des Empf�ngers einer Nachricht diese Nachricht durch einen Weiterleiter l�uft (ich bin mir jetzt nicht sicher ob das auch f�r FWD_PM gilt oder nur f�r Chef Gruppe, Sysop oder die Aliasse der Quark) und der Empf�nger der weitergeleiteten Nachricht in derselben Box ist, dann wird die Nachricht mit der urspr�nglichen Empf�ngeradresse weitergeleitet. Das ist m�glich weil bei der lokalen Speicherung die Nachricht im Postfach des Zielbenutzer abgespeichert wird, also keine Notwendigkeit besteht den Empf�nger im Header zu �berschreiben.

Besteht Hoffnung?

F�r das MausNet? Wohl kaum ...
Davon mal abgesehen: Wollte man eine Header/Envelopetrennung alleine im MausTausch einbauen w�rde dies eine massive �nderung des Formats notwendig machen. Boxen benutzen die Absenderzeile bisher als Zieladresse f�r Fehlermeldungen (na gut, die MAUS macht es sich noch einfacher - sie �berl��t einfach den Gates und �ber MausTausch angeschlossenen Boxen unter ihr die Generierung der Fehlermeldungen).
Benutzer bzw. Frontendprogramme benutzen den Inhalt der From-Zeile als Antwortadresse.
Eine der beiden Programmgruppen mu� massiv ver�ndert werden. MAUS und mausnet.exe nicht zu vergessen - in jedem Fall w�rde das reichlich viel Arbeit ... wobei noch die Frage w�re ob man nicht einfacher die Transportebene im MausNet auf RFC-Technik umstellt, und nur noch zum Benutzer hin MausTausch anbietet. Jedenfalls d�rfte das mittelfristig weniger Arbeit sein als die notwendigen �nderungen in die jetzige Infrastruktur einzuhacken.
Nat�rlich kann man sich die Arbeit der �nderung an der Software machen. Allerdings kann man es dann gleich richtig machen, und die fr�her so hochgelobten und effektiv vorhandenen Vorteile der MausNettechnik, insbesondere die Geschwindigkeit, sind l�ngst Geschichte.