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.