Im aktuellen Issue 31 nehmen wir uns für das Protokolle-Ressort zwei alte Memoranden vor, die selten zusammen gelesen werden, obwohl sie zusammen gehören: RFC 821 von Jonathan B. Postel (Simple Mail Transfer Protocol, August 1982) und RFC 822 von Dave Crocker (Standard for the Format of ARPA Internet Text Messages, August 1982, gleicher Monat). Diese beiden RFCs zusammen definieren, was im August 1982 als „Email” auf dem ARPANET im Begriff war, sich endgültig zu konsolidieren — RFC 821 beschreibt das Transport-Protokoll auf der Leitung, RFC 822 beschreibt die Struktur der übermittelten Nachricht selbst. Wir lesen beide nebeneinander, Postel auf der linken Schreibtisch-Hälfte, Crocker auf der rechten, und der Befund ist, dass beide Spezifikationen so stabil sind, dass 44 Jahre später jede laufende SMTP-Konversation auf jedem Internet-Mailserver in der Welt noch erkennbar denselben Befehlssatz spricht.

Die Vorgeschichte — Email auf dem ARPANET ab 1971

Vor RFC 821 existierte Email auf dem ARPANET bereits gut elf Jahre, aber als ein loses Bündel inkompatibler Protokolle und Konventionen. Ray Tomlinson schreibt im Sommer 1971 bei BBN auf einer DEC PDP-10 mit TENEX-Betriebssystem das erste Programm, das eine Nachricht zwischen zwei vernetzten Hosts zustellen kann — der Versand erfolgt über eine modifizierte Version von CPYNET, einem Datei-Transfer-Tool. Tomlinson wählt das @-Zeichen als Trenner zwischen Benutzer-Name und Host-Name, weil es auf seinem Model-33-Teletype als einziges Sonderzeichen nicht für andere Zwecke belegt war und weil es semantisch passte — der Benutzer ist „at” einem bestimmten Host. Die erste Test-Mail geht von einer PDP-10 an die danebenstehende zweite PDP-10 im selben BBN-Raum; was Tomlinson dabei eintippt, hat er nie verraten, er erinnert sich nur an „something like QWERTYUIOP”.

In den 1970er Jahren wachsen verschiedene konkurrierende Mail-Protokolle nebeneinander her — MMDF (Multi-Channel Memo Distribution Facility) im Bereich der University of Delaware, MAILER auf MULTICS, HERMES auf BBN-internen Systemen, ein eigenes Mail-System auf den Xerox PARC-Maschinen. Postel und Crocker hatten bereits 1977 mit RFC 733 einen ersten Versuch unternommen, ein einheitliches Message-Format festzuschreiben. RFC 821 und 822 sind die Konsolidierung, die nach fünf Jahren weiterer Praxis möglich war. Postel bezieht sich in RFC 821 explizit auf den älteren Standard NCP MAIL aus den 1970ern, aber er schreibt SMTP als saubere Schicht über TCP — der Übergang vom NCP zum TCP/IP-Stack ist am 1. Januar 1983, also fünf Monate nach der RFC-821-Publikation, fest angekündigt, und Postel weiß das.

Die fünf Basis-Befehle

RFC 821 ist in seiner technischen Mitte erstaunlich knapp. Die Spezifikation listet 14 SMTP-Befehle, davon sind fünf die obligatorischen Basis-Verben für jeden Mail-Versand:

HELO — der Verbindungs-Eröffnungs-Gruß. Der sendende Server identifiziert sich mit seinem Hostnamen. Eine SMTP-Konversation beginnt nach dem TCP-Connect auf Port 25 mit einem 220-Banner des Servers; dann antwortet der Client mit HELO mailhost.example.de. Erst nach dieser Identifikation wird die Sitzung als gültig anerkannt.

MAIL FROM — die Angabe des Absenders. Format MAIL FROM <user@host>, mit den spitzen Klammern als Begrenzern. Der Server antwortet auf eine valide Adresse mit 250 OK.

RCPT TO — die Angabe des Empfängers. Format RCPT TO <user@host>. Mehrfache RCPT-TO-Befehle hintereinander erzeugen die Liste der Empfänger für dieselbe Nachricht. Auch hier antwortet der Server mit 250 OK pro angenommenem Empfänger.

DATA — der Übergang in den Nachrichten-Body. Nach dem DATA-Befehl antwortet der Server mit 354 Start mail input; end with <CRLF>.<CRLF>. Der Client überträgt anschließend die Nachricht, einschließlich der Header nach RFC 822, und beendet sie mit der Sequenz aus CRLF, einzelnem Punkt, CRLF. Der Server quittiert die Annahme mit 250 OK.

QUIT — der Sitzungs-Abschluss. Der Server antwortet mit 221 und schließt die TCP-Verbindung.

Diese fünf Verben reichen für eine vollständige Mail-Übergabe. Die übrigen neun Befehle aus RFC 821 (RSET, NOOP, HELP, VRFY, EXPN, TURN, SEND, SOML, SAML) sind entweder Diagnose-Hilfen oder spezielle Modi, die in der Praxis schon Mitte der 1980er kaum noch genutzt wurden. VRFY (Verify) und EXPN (Expand) sind aus heutiger Sicht aus Spam-Schutz-Gründen abgeschaltet, weil sie es erlauben würden, gültige Adressen auf einem Server zu erraten.

Die Reply-Code-Hierarchie

Eine der eleganten Eigenschaften von RFC 821 ist das dreistellige Reply-Code-Schema. Jede Server-Antwort beginnt mit einer dreistelligen Nummer, deren erste Stelle die Kategorie kodiert:

• 2xx — Erfolg. Die Operation ist akzeptiert.
• 3xx — Zwischenstand. Der Server erwartet weitere Eingabe vom Client (klassisch nach DATA).
• 4xx — Temporärer Fehler. Der Client soll es später noch einmal versuchen — typisch bei vollem Disk-Buffer, kurzfristig nicht erreichbarem Empfänger-System.
• 5xx — Permanenter Fehler. Die Operation wird abgelehnt; der Client soll nicht wiederholt versuchen.

Die zweite Stelle kodiert das Subsystem (0 — Syntax, 1 — Information, 2 — Connection, 5 — Mail), die dritte Stelle ist eine fortlaufende Detail-Unterscheidung. Wer einen klassischen 550 No such user here-Bounce gelesen hat, hat die Hierarchie gesehen: 5 (permanent), 5 (Mail-Subsystem), 0 (Detail). Das Schema ist 1982 fixiert und ist seither in RFC 2821 (2001, John Klensin), RFC 5321 (2008) und allen späteren Revisionen unverändert übernommen worden.

Das Robustness Principle

Im Anhang von RFC 821 — genauer gesagt in RFC 793, das Postel ein Jahr früher als TCP-Spezifikation veröffentlicht hatte — steht der Satz, der Postels eigentliches Vermächtnis ist und der heute als Postel’s Law zitiert wird: „be conservative in what you do, be liberal in what you accept from others.” Auf RFC 821 angewandt bedeutet das: ein SMTP-Sender soll exakt nach Spezifikation senden — alle CRLF-Sequenzen korrekt, alle Befehle in Großbuchstaben, alle Adressen in spitzen Klammern. Ein SMTP-Receiver soll dagegen auch dann noch versuchen, die Nachricht anzunehmen, wenn der Sender kleinere Fehler macht — kleingeschriebene Befehle, fehlende Klammern, zusätzliche Whitespace.

Diese Asymmetrie hat das Internet groß werden lassen. Ein Server, der pedantisch jede syntaktische Abweichung mit 5xx ablehnte, hätte die organische Vielfalt der frühen Mail-Implementierungen erstickt. Ein Sender dagegen, der bewusst Spezifikations-Verletzungen begänge, würde die Interoperabilität unterminieren. 35 Jahre später, in der RFC-3117-Reflexion von Marshall Rose (2001), wird das Robustness Principle kritisch hinterfragt — die Praxis hat gezeigt, dass tolerantes Annehmen auch Sicherheitslücken und Spam-Vektoren erzeugen kann. Aber für 1982, im Übergang von NCP zu TCP/IP, war es die richtige Setzung, und Postel hat es als Lebensthema getragen.

Wo SMTP 2026 noch hält und wo es bricht

In der Mai-2026-Praxis ist RFC 821 in seiner Direkt-Form überall noch live. Jeder Mailserver — Postfix 3.8 auf den meisten Linux-Distributionen, Exim 4.97 auf vielen Hostern, Sendmail 8.18 in Legacy-Umgebungen — spricht im Kern noch immer dieselben fünf Verben und antwortet mit denselben dreistelligen Codes. Wer mit telnet mail.example.de 25 eine SMTP-Sitzung manuell führt, sieht 2026 dasselbe Protokoll wie Postel 1982.

Was bricht und nicht in RFC 821 stand, sind die Auth- und TLS-Schichten. Port 25 ist heute praktisch nur noch für Server-zu-Server-Relay offen; Mail-Submission vom Client läuft auf Port 587 (mit obligatorischem STARTTLS und SMTP-AUTH nach RFC 4954) oder auf Port 465 (mit implizitem TLS, ursprünglich „SMTPS” genannt, in RFC 8314 von 2018 endgültig kanonisiert). Spam-Filterung, SPF (RFC 7208), DKIM (RFC 6376), DMARC (RFC 7489) — das alles sind Schichten, die Postel 1982 nicht antizipieren konnte und nicht antizipieren musste. Die Aufgabe von RFC 821 war, ein Protokoll zu schreiben, das funktioniert. Die Aufgabe der nachfolgenden 250 Mail-RFCs ist es, dieses Protokoll gegen die kommerzielle Realität des heutigen Mail-Verkehrs abzudichten.

Postel ist am 16. Oktober 1998 in Santa Monica an einer Komplikation nach einer Herzoperation gestorben. Sein Nachruf in RFC 2468 von Vint Cerf ist eines der bewegendsten Dokumente in der RFC-Reihe. Im Mai 2026 lesen wir RFC 821 in der Erinnerung daran, dass die fünf Verben — HELO, MAIL FROM, RCPT TO, DATA, QUIT — eine Praxis tragen, die ihren Autor um knapp drei Jahrzehnte überlebt hat.