Zusammenfassung

  • RFC 821 definierte drei optionale Transaktionsanfänge, die Terminalanzeige, Postfachablage oder beides zu SMTP-Zustellsemantik machten.
  • Erfolg bedeutete je nach Verb etwas anderes: SEND hing vom Terminal ab, SOML akzeptierte eines der Ziele, und SAML hing trotz zusätzlichem Anzeigeversuch vom Postfach ab.
  • Ein MX-Relay konnte die Mailroute kennen, ohne den Bildschirm des Nutzers zu kontrollieren; spätere SMTP-Standards stuften die Verben deshalb als obsolet ein und ließen nur enge Kompatibilität bestehen.

Drei Ankunftsarten vor dem Nachrichtentext

Auf einem gemeinsam genutzten Host des Jahres 1982 konnte ein Empfänger angemeldet sein und Terminalnachrichten zulassen. Der entfernte SMTP-Client eröffnete seine Sitzung und wählte statt des üblichen MAIL einen von drei Befehlen.

SEND verlangte die Zustellung zum Terminal. War der Nutzer nicht aktiv oder lehnte solche Nachrichten ab, durfte der Server für diesen Empfänger vorübergehend scheitern. SOML, Send Or MaiL, versuchte das Terminal und wich bei Abwesenheit auf das Postfach aus. SAML, Send And MaiL, versuchte die Anzeige und legte in jedem Fall eine Kopie im Postfach ab.

Im RFC 821 waren das keine unverbindlichen Hinweise. Jeder Befehl eröffnete die Transaktion, vor RCPT und DATA. Der Absender wählte die Art der Ankunft, bevor Empfänger und Inhalt übertragen wurden.

Damit sollte die Transportschicht beurteilen, ob ein Mensch gerade erreichbar war, eine Unterbrechung akzeptierte und ob eine flüchtige Anzeige oder eine gespeicherte Kopie als Erfolg galt.

Ein Erfolg mit drei Beweiswerten

SEND war nur erfolgreich, wenn die Daten das Terminal erreichten; eine Postfachkopie war kein automatischer Rückfall. Bei SOML waren Terminal und Postfach Alternativen, von denen eine genügte. Bei SAML war das Postfach verpflichtend und die Anzeige zusätzlich; der Erfolg hing von der Ablage ab.

Ein erfolgreiches SEND konnte daher ohne dauerhafte Kopie enden. Ein erfolgreiches SOML verriet ohne weitere Telemetrie nicht zwingend, welcher Zweig abgeschlossen wurde. Ein erfolgreiches SAML belegte die Postfachseite, aber nicht, dass der Nutzer die Anzeige gesehen hatte.

Die Grammatik erkannte den Unterschied zwischen Aufmerksamkeit und Obhut. Ihr Autoritätsproblem lag darin, dass der Absender das Verb bestimmte, während Empfänger und empfangender Host Unterbrechung und Haltbarkeit tragen mussten.

Anwesenheit war lokal und vergänglich

RFC 821 verlangte für die Terminalzustellung, dass der Nutzer auf diesem Host aktiv war und Terminalnachrichten annahm. Beides war kein dauerhaftes Merkmal der E-Mail-Adresse, sondern Zustand einer bestimmten Sitzung.

Die Adresse blieb gültig, wenn der Nutzer sich abmeldete, das Gerät wechselte oder Unterbrechungen sperrte. Die Route blieb gültig, wenn der annehmende Host die interaktive Sitzung nicht mehr kontrollierte. Selbst zwischen Empfängerprüfung und Datenende konnte sich der Zustand ändern.

Der Client durfte SEND verlangen, aber keine Anwesenheit erklären. Eine EHLO-Anzeige bewies, dass der Server die Syntax implementiert hatte; sie bewies weder Verfügbarkeit noch Einwilligung einer bestimmten Person.

MX trennte Routingwissen von Bildschirmkontrolle

Der RFC 1123 machte die drei Befehle für Sender und Empfänger optional. Seine Bemerkung zum MX-Relay benennt die entscheidende Grenze.

Ein Mail Exchanger kann im Namen eines Ziels annehmen und den weiteren Weg kennen, ohne direkt auf das Terminal des Nutzers schreiben zu können. Für einen Empfänger nach SEND durfte er 251 User Not Local antworten und damit auf mögliche Verzögerung hinweisen.

Routing-Erreichbarkeit bedeutete, Verantwortung zu übernehmen und weiterzuleiten. Präsentations-Erreichbarkeit bedeutete, die aktive Nutzersitzung zu beherrschen. Ein MX konnte das Erste besitzen und das Zweite nicht.

Store-and-forward verteilte die Verantwortung für Nachrichten. Es verteilte nicht automatisch das Recht, menschliche Aufmerksamkeit zu beanspruchen.

EHLO entdeckte Grammatik, nicht Anwesenheit

Mit dem RFC 1425 kamen die drei Befehle als optionale Dienste in das erste SMTP-Erweiterungsregister; ihre Namen dienten zugleich als EHLO-Schlüsselwörter.

Der Client konnte nun erkennen, ob der Server das Verb verstand. Er wusste weiterhin nicht, ob der Empfänger angemeldet war, Terminalnachrichten erlaubte, ob dieser Server endgültig zustellte oder die Anzeige gelingen würde.

Eine Fähigkeit wird in Oberflächen leicht zur grünen Schaltfläche und dann zum Versprechen. EHLO beschrieb den Wortschatz des Servers, nicht den Zustand eines Menschen.

Kompatibilität blieb, die Zusage wurde kleiner

2001 nannte der RFC 2821 SEND, SAML und SOML obsolet. Sie seien selten implementiert worden; veränderte Arbeitsplatztechnik und andere Protokolle könnten sie selbst dort entbehrlich gemacht haben, wo Code existierte.

Alte Gegenstellen wurden nicht einfach abgeschnitten. Clients sollten diese Dienste nicht mehr anbieten. Server durften sie kompatibilitätshalber implementieren, mussten dann aber das Modell des RFC 821 einhalten und die Namen über EHLO bekanntgeben.

Der RFC 5321 bewahrt diese Ordnung. Die alten Verben bleiben erkennbar, während gewöhnliches SMTP um MAIL und den formellen Verantwortungsübergang nach erfolgreicher Datenannahme gebaut ist.

Diese Obhut ist nachprüfbar: Wer annimmt, muss zustellen oder einen Fehler melden. Sie behauptet nicht, dass ein Mensch in einem bestimmten Moment auf einen Bildschirm sah. Die Deprecation verkleinerte die Zusage des Transports, ohne jede alte Kompatibilität zu brechen.

Das IANA-Register misst keine Nutzung

Die SMTP-Register der IANA führen SEND, SOML und SAML weiterhin mit RFC-821-Verweis, Deprecation-Hinweis und MUST NOT für Message Submission.

Die Einträge erhalten interoperable Namen. Sie belegen keine heutige Verbreitung, keine Empfängeranwesenheit und keinen konkreten Anzeigeerfolg. Registrierung koordiniert Vokabular; sie belebt seine sozialen Voraussetzungen nicht wieder.

Fähigkeit, Anwesenheit, Einwilligung, Darstellung, Speicherung und Verantwortung sind sechs getrennte Tatsachen. Frühes SMTP verband mehrere in einer Transaktionswahl. Späteres SMTP löste Aufmerksamkeit nicht technisch; es nahm sie aus dem Kern seines Transportversprechens.

Schneller war nicht stärker zugestellt

In einer kleinen Gruppe eng gekoppelter Hosts waren die Befehle nachvollziehbar. SOML bot einen sinnvollen Rückfall, SAML bewahrte eine Kopie. Die Entwickler hatten einen echten Unterschied zwischen Zeigen und Aufbewahren erkannt.

Mit Relays, unterschiedlichen Workstations und eigenständigen Nutzerprogrammen verschob sich die Zuständigkeit. Der Transport konnte Warteschlangen und Obhut kontrollieren, nicht den aktuellen Bildschirm oder die Bereitschaft zur Unterbrechung.

Ein Bildschirm kann sofort leuchten und spurlos erlöschen. Ein stilles Postfach kann später geöffnet werden und trotzdem Verantwortung bewahren. Die Nachricht, die vor dem Postfach ankam, gewann vielleicht Zeit; einen Ort zum Bleiben hatte sie damit noch nicht.

Quellen