Zusammenfassung

  • Die Revision vom August 1982 definierte SMTP als zuverlässigen Stromdialog, der Mail auch dann weiterleiten konnte, wenn die Endpunkte keinen Transportdienst teilten.
  • MAIL enthielt einen Rückweg, RCPT einen oder mehrere Empfängerpfade; RFC 822 regelte das Textformat separat. Eine angenommene SMTP-Sitzung beweist daher weder Ablage im Postfach noch Lesen.

Eine E-Mail kann eine Netzwerkgrenze passieren, ohne dass ihr Text weiß, welches Netz sie transportiert hat. Genau dieses Entwurfsproblem wird in Simple Mail Transfer Protocol von Jonathan B. Postel von August 1982 sichtbar. RFC 821 band SMTP nicht an ein bestimmtes Übertragungssystem. Gefordert war ein zuverlässiger, geordneter Datenstrom; darüber tauschten SMTP-Prozesse Befehle und Antworten aus.

Relaying gehörte ausdrücklich zum Modell. Wenn Quell- und Zielhost denselben Transportdienst nutzten, konnte der Sender direkt mit dem empfangenden SMTP-Prozess sprechen. Andernfalls konnten ein oder mehrere Zwischenserver verschiedene Transportumgebungen verbinden. Postel grenzte den Begriff genau ab: Ein Transportdienst konnte ein Netz, mehrere Netze oder nur einen Teil eines Netzes umfassen. „Netz“ und „Transportumgebung“ waren also keine austauschbaren Kästen.

Die Transaktion machte die Übergabe Schritt für Schritt sichtbar. Der Sender öffnete einen bidirektionalen Kanal, der Empfänger antwortete. MAIL begann mit einem Rückweg, über den etwa Nichtzustellungsnachrichten zurücklaufen konnten. Jeder RCPT-Befehl nannte einen Empfängerpfad und durfte wiederholt werden. DATA übertrug anschließend die Nachricht. Numerische Antworten zeigten, ob einzelne Befehle angenommen oder abgelehnt wurden. Der SMTP-Umschlag enthielt Zustellanweisungen, nicht denselben Inhalt wie der sichtbare Nachrichtentext.

Der Vergleich mit RFC 822, ebenfalls im August 1982 erschienen, trennt die Zuständigkeiten. RFC 822 standardisierte das Format von ARPA-Internet-Textnachrichten; RFC 821 spezifizierte den Transferdialog. Ein From:-Feld gehört zur Nachrichtendarstellung, MAIL FROM zur SMTP-Transaktion. Wer beides gleichsetzt, liest eine im Text angegebene Adresse als Beweis für tatsächlichen Pfad oder Zustellentscheidung. Das garantieren die Spezifikationen nicht.

RFC 821 war eine Revision und nicht die Geburtsurkunde von SMTP. Im Kopf heißt es, sie ersetze RFC 788, 780 und 772; RFC 788 vom November 1981 hatte SMTP bereits beschrieben. RFC 801 erwähnt den SMTP-Dienst im Kontext eines Netzübergangsplans, nennt aber weder Installationszahlen noch erfolgreiche Zustellungen an Nutzer. Das Veröffentlichungsdatum einer Revision verrät nicht, wann jeder Host sie übernahm.

Das Modell war auch nicht TCP-exklusiv. Die Anhänge von RFC 821 behandeln unter anderem NCP, TCP und NITS; der TCP-Anhang weist SMTP die Socketnummer 25 zu. Das macht die Umsetzung konkret, aber ein offener Port belegt keinen funktionierenden Maildienst. Dafür braucht es einen aktiven Empfangsprozess, angenommene Befehle, korrekte Pfade, eine abgeschlossene DATA-Transaktion und lokale Verarbeitung danach.

Der historische Beitrag war eine übertragbare Dienstgrenze. SMTP definierte einen gemeinsamen Dialog für Mailtransfer und erlaubte Relays zwischen Transportumgebungen; Nachrichtenformat und lokales Postfachverhalten blieben eigene Fragen. Mit Note 64 von Heng Lu als späterer analytischer Linse lässt sich darin eine schmale gemeinsame Spezifikation erkennen: Interoperabilität präzise machen und Transport- sowie Einführungsentscheidungen den laufenden Systemen überlassen. Das ist eine Interpretation, keine Aussage über die Absicht des Autors.

Sources