RFC 5322 · Oktober 2008 · Draft Standard

Die Anatomie einer E-Mail, und warum die From-Zeile lügen kann.

Der offizielle Titel lautet "Internet Message Format." Worüber der RFC wirklich entscheidet: über den Aufbau einer E-Mail-Nachricht, die Header, den Body und darüber, wie eine echte Adresse aussehen darf. Er definiert das Dokument selbst, lange bevor SMTP es irgendwohin transportiert.

Status: ✓ Weiterhin gültig
Ersetzt: RFC 2822
Aktualisiert durch: RFC 6854

Geschrieben von Noel Lang · IT-Trainer

Kurzfassung

RFC 5322 definiert das Format einer E-Mail-Nachricht. Er legt die Header-Felder fest (From, To, Subject, Date, Message-ID), die Leerzeile, den Body und die Grammatik einer gültigen Adresse. Über die Zustellung sagt er nichts: Die Nachricht zu bewegen ist Aufgabe von SMTP (RFC 5321). Weil 5322 nur beschreibt, wie ein Header aussieht, nicht ob er wahr ist, kann die From-Zeile alles Mögliche behaupten, und genau deshalb ist E-Mail-Spoofing möglich. Er ersetzte 2008 den RFC 2822.

Welches Problem er löst

E-Mail funktioniert nur, weil sich jedes Mailprogramm der Welt auf dasselbe Layout einigt: wo die Header enden und der Body beginnt, wie ein Datum geschrieben wird, was eine Adresse enthalten darf. Ohne eine gemeinsame Grammatik wäre eine in Outlook verfasste Nachricht in Gmail unlesbar, und eine Mailingliste von 1995 wäre heute Kauderwelsch.

RFC 5322 ist diese Grammatik. Er ist bewusst, fast stur, vom Transport getrennt. Er sagt nichts darüber, wie eine Nachricht reist, nur was sie ist: ein Block Header-Felder, eine einzelne Leerzeile und ein Body aus reinem US-ASCII-Text. Diese saubere Trennung, Format hier, Zustellung in RFC 5321 , ist der Grund, warum dieselbe Nachrichtenform vier Jahrzehnte wechselnder Mailserver, Programme und Netze überlebt hat.

Der Umschlag und der Brief

Hier ist das Wichtigste, was man über E-Mail verstehen muss, und die Quelle der meisten Verwirrung darum. Eine Nachricht zu versenden umfasst zwei getrennte Standards, die Leute ständig zu einem verschmelzen.

RFC 5321 ist SMTP: die Post. Es trägt einen Umschlag mit eigenem Absender und Empfänger (die Kommandos MAIL FROM und RCPT TO), und es entscheidet tatsächlich, wohin die Mail geht. RFC 5322 ist der Brief in diesem Umschlag: das From:, To: und Subject:, das du in deinem Mailprogramm liest.

Der Kniff, der ein Jahrzehnt an Sicherheitskopfschmerzen erklärt: nichts in den Basis-Standards zwingt Umschlag und Brief dazu, übereinzustimmen. Ein Server routet deine Mail über den Umschlag-Absender. Deine Augen lesen den From:-Header im Brief. Ein Angreifer kann die eine Adresse auf den Umschlag schreiben und eine völlig andere, vertrauenswürdig wirkende in den Brief. Die Mail wird von der ersten zugestellt und der zweiten geglaubt. Diese Diskrepanz ist E-Mail-Spoofing, und deshalb wurden SPF, DKIM und DMARC später erfunden, um zu prüfen, ob der Absender der ist, den der Brief behauptet.

Warum die From-Zeile lügen kann

Zwei Standards, zwei Absender. SMTP stellt über die Umschlag-Adresse zu; du vertraust der im Brief gedruckten Adresse. Auf dieser Ebene prüft nichts, ob sie übereinstimmen.

Das ist kein Fehler in RFC 5322, es ist eine Grenze. 5322 definiert, wie From aussieht, nicht dass es ehrlich ist. SPF, DKIM und DMARC existieren, um die Lücke zu schließen.

Die Anatomie einer rohen E-Mail

Das ist eine Nachricht wirklich, sobald man das Mailprogramm wegzieht: ein Stapel Name: Wert-Header-Felder, eine Leerzeile, dann der Body. Alles, was dein Programm dir zeigt, wird daraus geparst.

Öffne in einem beliebigen Mailprogramm “Original anzeigen”, und du schaust auf genau das: reinen Text, Zeile für Zeile definiert von RFC 5322.

Was RFC 5322 nicht tut

Der Standard ist enger, als man annimmt. Fast alles, was moderne E-Mail reich wirken lässt, lebt in anderen RFCs, obendrauf auf eine 5322-Nachricht aus reinem Text gelegt:

Anhänge nicht hier

Nein. Ein 5322-Body ist ein Textblock. Das PDF, das du angehängt hast, wird Base64-kodiert und von MIME (RFC 2045) in den Body gepackt. Für 5322 ist es nur mehr Text.
HTML und Bilder nicht hier

Nein. Fettschrift, Buttons und eingebettete Bilder sind ebenfalls MIME, obendrauf gelegt. RFC 5322 kennt nur reinen Text mit Subject und Body. Alles Reichere reist als kodierter Inhalt darin mit.
Umlaute im Header braucht Hilfe

Nicht direkt. Ein roher 5322-Header ist reines US-ASCII. Ein Subject wie Grüße wird von RFC 2047 in ASCII-Kauderwelsch kodiert und von deinem Programm dekodiert. Der Header sieht schlicht aus, die Anzeige nicht.
Zustellung nicht seine Aufgabe

Nein. Wie eine Nachricht reist, es erneut versucht und zurückkommt, ist SMTP (RFC 5321). 5322 beschreibt den Brief, der auf dem Schreibtisch liegt, nie den Postweg, den er dorthin genommen hat.

Das Muster ist immer dasselbe: 5322 definiert einen Container aus reinem Text, und MIME (RFC 2045, 2047) packt das moderne Web als kodierten Text hinein.

Was der RFC wirklich sagt

Das Original ist lesbar und größtenteils Grammatik. Hier die Landkarte, falls du die Quelle besuchen willst:

Abschnitt	In einfachen Worten
2 · Message format	Die Form des Ganzen: Header-Felder, dann eine Leerzeile, dann der Body. Zeilen sind US-ASCII und laut Regel höchstens 998 Zeichen lang.
2.2 · Header fields	Ein Feld ist ein Name, ein Doppelpunkt und ein Wert (From: jemand@example.com). Die Grammatik der Teile, aus denen jede Nachricht gebaut ist.
2.2.3 · Lange Zeilen (Folding)	Wie ein Header, der zu lang für eine Zeile ist, über mehrere gebrochen wird, indem vor einem Leerzeichen ein Umbruch eingefügt wird, und auf der anderen Seite wieder zusammengesetzt wird.
3.4 · Address specification	Der berühmte Teil: wie eine Mailbox und eine Adressgruppe aussehen dürfen. Die Quelle jeder "Ist das eine gültige E-Mail?"-Diskussion.
3.6 · Field definitions	Welche Header existieren und welche Pflicht sind. Jede Nachricht MUSS ein Absende-Datum und ein From haben. Alles andere ist optional.
4 · Obsolete syntax	Die Altlasten: Formen, die ein Parser aus alter Mail noch akzeptieren muss, aber nie erzeugen darf. Jahrzehnte Rückwärtskompatibilität, aufgeschrieben.

Was Leute falsch verstehen

"Die Adresse im From-Header ist verifiziert."

Ist sie nicht. RFC 5322 definiert, wie das From-Feld aussieht, nie dass es wahr ist. Jeder kann From: Deine Bank <security@bank.example> in eine Nachricht schreiben. Die Adresse, die die Mail tatsächlich geroutet hat, ist der SMTP-Umschlag-Absender, ein separater Wert, der nicht übereinstimmen muss. Diese Lücke ist die Wurzel des E-Mail-Spoofings und der ganze Grund, warum SPF, DKIM und DMARC existieren.
"RFC 5322 steuert, wie E-Mail zugestellt wird."

Er steuert an der Zustellung gar nichts. 5322 beschreibt das Dokument: Header, Body, Adressen. Es von einem Server zum nächsten zu bewegen, zu wiederholen, zurückzuweisen, das ist alles SMTP (RFC 5321). Beide wurden am selben Tag veröffentlicht und ständig vertauscht, aber das eine ist der Brief und das andere die Post.
"Anhänge stehen in RFC 5322."

Sie sind überhaupt nicht Teil von 5322. Der Standard kennt nur reinen Text: eine Menge Header und einen Body. Anhänge, HTML und Bilder sind MIME (RFC 2045), das sie als Text kodiert und in den 5322-Body steckt. RFC 5322 trägt die Fracht, ohne sie je zu verstehen.
"RFC 822 ist tot und begraben."

Seine Nummer ist ausgemustert, sein Text nicht. RFC 822 (1982) definierte das Nachrichtenformat so sauber, dass 2822 und dann 5322 es meist nur neu formulierten. Der Kern, Header-Doppelpunkt-Wert, Leerzeile, Body, steht fast wortgleich noch da. Wenn Leute von "822-Format" für ein Datum oder einen Header sprechen, beschreiben sie etwas sehr Lebendiges.

Wo dir RFC 5322 begegnet

Du berührst diesen Standard ständig, ohne ihn zu benennen. Ein Feldführer, um ihn zu erkennen:

Du siehst	Du schaust vermutlich auf
"Original anzeigen" / "Quelltext"	Jedes Mailprogramm verbirgt einen Knopf, der die rohe 5322-Nachricht zeigt: die Header und den Body genau so, wie dieser RFC sie definiert.
Eine Message-ID im Support-Ticket	Der Message-ID:-Header, ein weltweit eindeutiges Kennzeichen, das 5322 jeder Mail gibt. Support-Teams finden damit deine exakte Nachricht in den Logs.
date -R auf der Kommandozeile	Der -R-Schalter gibt das Datum im RFC-5322-Format aus, genau weil E-Mail (und vieles mehr) dieses Format erwartet.
Eine .patch-Datei aus git	git format-patch schreibt jeden Commit als 5322-Nachricht, mit From und Subject, sodass ein Patch buchstäblich per Mail verschickt und angewendet werden kann.
Received:-Header übereinandergestapelt	Jeder Mailserver, der die Nachricht bearbeitet hat, fügt einen Trace-Header hinzu. Es sind 5322-Header-Felder, aber unterwegs von SMTP-Stationen (RFC 5321) geschrieben.
Ein From, das nicht zum Absender passt	Der Anzeigename sagt deine Bank, die Adresse darunter ist ein Fremder. 5322 erlaubt beides, weshalb die Worte und die Adresse sich widersprechen können.

Fragen, die wirklich gestellt werden

Was ist RFC 5322? +

RFC 5322 ist der Internet-Standard, der das Format einer E-Mail-Nachricht definiert: die Header-Felder (From, To, Subject, Date und mehr), die Leerzeile, den Body und die genaue Syntax einer gültigen Adresse. Über die Zustellung sagt er nichts, das ist Aufgabe von SMTP. Veröffentlicht 2008, ersetzte er RFC 2822.

Was ist der Unterschied zwischen RFC 5322 und RFC 5321? +

RFC 5322 definiert, wie eine E-Mail-Nachricht aussieht: ihre Header und ihren Body. RFC 5321 definiert SMTP, das Protokoll, das diese Nachricht zwischen Servern transportiert. Das eine ist der Brief, das andere ist die Post samt Umschlag. Beide wurden 2008 gemeinsam veröffentlicht und werden ständig verwechselt, lösen aber zwei verschiedene Probleme.

Was ist RFC 5322 einfach erklärt? +

Es ist die gemeinsame Grammatik, mit der sich alle Mailprogramme auf die Form einer Nachricht einigen: wo die Header enden und der Body beginnt, wie ein Datum geschrieben wird, was eine Adresse enthalten darf. Ohne sie wäre eine in einem Programm verfasste Mail in einem anderen unlesbar. Er definiert die Nachricht, nicht ihre Zustellung.

Was zählt unter RFC 5322 als gültige E-Mail-Adresse? +

Weit mehr, als die meisten erwarten. Der lokale Teil vor dem @ darf Zeichenketten in Anführungszeichen, Punkte und viele Sonderzeichen enthalten, und die Grammatik erlaubt sogar Kommentare in Klammern. In der Praxis akzeptiert fast jedes System eine strengere Teilmenge, weshalb der berüchtigte vollständige RFC-5322-Adress-Regex tausende Zeichen lang ist und fast nie benutzt wird.

Warum kann die From-Adresse in einer E-Mail gefälscht sein? +

Weil RFC 5322 nur definiert, wie der From-Header aussieht, nicht ob er wahr ist. Die Adresse, die die Mail tatsächlich zustellt, ist der SMTP-Umschlag-Absender (MAIL FROM in RFC 5321), und nichts in den Basis-Standards zwingt beide dazu, übereinzustimmen. Genau diese Lücke ermöglicht Spoofing, und deshalb wurden SPF, DKIM und DMARC nachträglich ergänzt, um den Absender zu prüfen.

Hat RFC 5322 den RFC 2822 ersetzt? +

Ja. RFC 5322 macht RFC 2822 obsolet, der wiederum das ursprüngliche RFC 822 abgelöst hatte. Er ist der aktuelle Standard für das Nachrichtenformat, später in einem engen Bereich durch RFC 6854 aktualisiert, um Gruppen-Syntax in einigen Header-Feldern zu erlauben. Der Kern aus RFC 822 lebt fast wortwörtlich weiter.

Sind Anhänge und HTML-Mail in RFC 5322 definiert? +

Nein. RFC 5322 kennt nur reinen US-ASCII-Text: Header und einen Body. Anhänge, HTML-Teile, Bilder und Nicht-ASCII-Zeichen kommen alle von MIME (RFC 2045 und Verwandte), das alles als strukturierten Text in einen 5322-Body packt. RFC 5322 trägt MIME, ohne zu wissen, was es ist.

Verweise hierher

Andere Erklärseiten auf dieser Website, die auf diesen RFC zurückverweisen:

Wie RFC 5322 zusammenhängt

Was vorher kam

RFC 822 RFC 822 definierte das E-Mail-Format so gut, dass sein Kern bis heute fast wortgleich überlebt. RFC 5322 ist dasselbe Dokument, zweimal überarbeitet und modernisiert.
RFC 2822 Die Überarbeitung von 2001, die zwischen 822 und 5322 stand. RFC 5322 macht sie obsolet. Ihre Nummer, 2822, war selbst eine bewusste Hommage an 822.

Womit es zusammenspielt

Seine Gegenstücke

Teil eines geführten Clusters: Die E-Mail-RFCs, erklärt