1. Introduction (Einführung)
1.1. Scope (Geltungsbereich)
Dieses Dokument definiert das Internet-Nachrichtenformat (IMF, Internet Message Format), eine Syntax für Textnachrichten, die zwischen Computerbenutzern im Rahmen von „E-Mail"-Nachrichten gesendet werden. Diese Spezifikation ist eine Überarbeitung von RFC 2822, das selbst RFC 822 ersetzte, um den aktuellen Praktiken zu entsprechen und inkrementelle Änderungen aus anderen RFCs zu integrieren.
Dieses Dokument spezifiziert eine Syntax nur für Textnachrichten. Insbesondere trifft es keine Vorkehrungen für die Übertragung von Bildern, Audio oder anderen Arten strukturierter Daten in E-Mail-Nachrichten. Es wurden mehrere Erweiterungen veröffentlicht, wie die MIME-Dokumentenreihe (RFC 2045, RFC 2046, RFC 2049), die Mechanismen zur Übertragung solcher Daten per E-Mail beschreiben.
Im Kontext von E-Mails werden Nachrichten als etwas betrachtet, das einen Umschlag und Inhalt hat. Der Umschlag enthält Informationen, die zur Durchführung der Übertragung und Zustellung erforderlich sind (siehe RFC 5321 für eine Diskussion über den Umschlag). Der Inhalt umfasst das Objekt, das an den Empfänger zugestellt werden soll. Diese Spezifikation gilt nur für das Format und einige der Semantik des Nachrichteninhalts. Sie enthält keine Spezifikation der Informationen im Umschlag.
Einige Nachrichtensysteme können jedoch Informationen aus dem Inhalt verwenden, um den Umschlag zu erstellen. Diese Spezifikation soll es Programmen erleichtern, solche Informationen zu erwerben.
Diese Spezifikation ist als Definition des Nachrichteninhaltsformats gedacht, das zwischen Systemen übergeben werden soll. Obwohl einige Nachrichtensysteme Nachrichten lokal in diesem Format speichern (wodurch die Notwendigkeit einer Übersetzung zwischen Formaten entfällt), verwenden andere unterschiedliche native Formate. Die lokale Speicherung liegt außerhalb des Geltungsbereichs dieser Spezifikation.
Hinweis: Diese Spezifikation ist nicht dazu gedacht, die von Standorten verwendeten internen Formate, die spezifischen Nachrichtensystemfunktionen, die sie unterstützen sollen, oder irgendwelche Eigenschaften von Benutzeroberflächenprogrammen, die Nachrichten erstellen oder lesen, vorzuschreiben. Darüber hinaus spezifiziert dieses Dokument nicht die für die Übertragung oder Speicherung verwendete Zeichencodierung.
1.2. Notational Conventions (Notationskonventionen)
1.2.1. Requirements Notation (Anforderungsnotation)
Dieses Dokument verwendet gelegentlich Begriffe, die in Großbuchstaben erscheinen. Wenn die Begriffe „MUST", „SHOULD", „RECOMMENDED", „MUST NOT", „SHOULD NOT" und „MAY" groß geschrieben werden, werden sie verwendet, um bestimmte Anforderungen dieser Spezifikation anzugeben. Eine Diskussion der Bedeutungen dieser Begriffe erscheint in RFC 2119.
Schlüsselwort-Referenz:
| Begriff | Bedeutung |
|---|---|
| MUST | muss (Absolute Anforderung) |
| MUST NOT | darf nicht (Absolutes Verbot) |
| SHOULD | sollte (Starke Empfehlung) |
| SHOULD NOT | sollte nicht (Starke Gegenempfehlung) |
| RECOMMENDED | empfohlen (Empfohlene Praxis) |
| MAY | kann/darf (Optional) |
1.2.2. Syntactic Notation (Syntaxnotation)
Diese Spezifikation verwendet die Notation der Erweiterten Backus-Naur-Form (ABNF, Augmented Backus-Naur Form), wie in RFC 5234 beschrieben. Zeichen werden entweder durch Dezimalwerte (z.B. %d65 für Großbuchstaben A, %d97 für Kleinbuchstaben a) oder durch in Anführungszeichen eingeschlossene, nicht zwischen Groß- und Kleinschreibung unterscheidende Literalwerte (z.B. „A" repräsentiert entweder Groß- oder Kleinbuchstaben A) angegeben.
ABNF-Grundlagen:
- Literale:
"From:"- nicht zwischen Groß-/Kleinschreibung unterscheidend - Dezimalwerte:
%d65- ASCII-Code 65 (Zeichen A) - Bereiche:
%d48-57- Ziffern 0-9 - Wiederholung:
*(null oder mehr),1*(eins oder mehr),2*4(2 bis 4 mal) - Optional:
[OPTIONAL]- Elemente in eckigen Klammern sind optional - Gruppierung:
()- runde Klammern gruppieren Elemente - Alternativen:
/- eins auswählen
1.2.3. Structure of This Document (Struktur dieses Dokuments)
Dieses Dokument ist in mehrere Abschnitte unterteilt.
Dieser Abschnitt (Abschnitt 1) ist eine kurze Einführung in das Dokument.
Abschnitt 2 legt die allgemeine Beschreibung einer Nachricht und ihrer Bestandteile dar. Dies ist eine Übersicht, um dem Leser zu helfen, einige der allgemeinen Prinzipien zu verstehen, die in späteren Teilen dieses Dokuments verwendet werden. Alle Beispiele in diesem Abschnitt dürfen nicht (MUST NOT) als formale Spezifikation eines Teils der Nachricht betrachtet werden.
Abschnitt 3 spezifiziert die formalen ABNF-Regeln für die Struktur (Syntax) jedes Teils einer Nachricht und beschreibt die Beziehung zwischen diesen Teilen und ihre Bedeutung (Semantik) im Kontext von Nachrichten. Er listet die tatsächlichen Regeln (Syntax) für die Struktur jedes Teils einer Nachricht sowie Beschreibung und erläuternde Notizen dazu (Semantik). Dies umfasst sowohl syntaktische als auch semantische Analyse von Nachrichten-Unterteilen, die spezifische Struktur haben. Die Syntax in Abschnitt 3 stellt dar, wie Nachrichten erstellt werden müssen (MUST). Es gibt auch Notizen in Abschnitt 3, die anzeigen, ob Optionen in der Syntax gegenüber anderen Optionen verwendet werden sollten (SHOULD).
Sowohl Abschnitt 2 als auch Abschnitt 3 beschreiben Nachrichten, die gemäß dieser Spezifikation legal zu generieren sind.
Abschnitt 4 spezifiziert „veraltete" (Obsolete) Syntax. Diese veralteten Syntaxelemente werden in Abschnitt 3 referenziert. Die Regeln der veralteten Syntax sind Elemente, die in früheren Versionen dieser Spezifikation erschienen sind oder im Internet weit verbreitet waren, aber nicht mehr bei der Generierung von Nachrichten verwendet werden dürfen. Daher müssen (MUST) konforme Nachrichten-Parser diese Elemente interpretieren. Da jedoch festgestellt wurde, dass Elemente in dieser Syntax nicht interoperabel sind oder erhebliche Probleme für Nachrichtenempfänger verursachen, dürfen (MUST NOT) konforme Nachrichtenersteller sie nicht generieren.
Abschnitt 5 beschreibt Sicherheitsüberlegungen bei der Implementierung dieser Spezifikation.
Anhang A listet Beispiele verschiedener Arten von Nachrichten auf. Diese Beispiele sind nicht erschöpfend für die Arten von Nachrichten, die im Internet erscheinen, geben aber einen breiten Überblick über bestimmte syntaktische Formen.
Anhang B listet die Unterschiede zwischen dieser Spezifikation und früheren Internet-Nachrichtenspezifikationen auf.
Anhang C enthält Danksagungen.
Zusammenfassung der Kernkonzepte
Nachrichtenstruktur
+-------------------------+
| Kopfzeilenabschnitt | ← Definiert durch diese Spec
| - From: alice@... |
| - To: bob@... |
| - Subject: Hello |
| - Date: ... |
+-------------------------+
| Leerzeile (CRLF) | ← Erforderlicher Trenner
+-------------------------+
| Körperabschnitt | ← Diese Spec (Klartext)
| Hello World! | MIME erweitert (Multimedia)
+-------------------------+
Spezifikationsumfang
| Inhalt | Diese Spezifikation | Andere Spezifikationen |
|---|---|---|
| Nachrichteninhaltsformat | ✅ Definiert | - |
| Nachrichtentransport (SMTP) | ❌ Nicht abgedeckt | RFC 5321 |
| Umschlag-Informationen | ❌ Nicht abgedeckt | RFC 5321 |
| Multimedia-Inhalt | ❌ Nicht abgedeckt | RFC 2045-2049 (MIME) |
| Lokales Speicherformat | ❌ Nicht abgedeckt | Systemspezifisch |
| Zeichencodierung | ❌ Nicht spezifiziert | Transportschicht |
Beziehung zu verwandten RFCs
RFC 5322 (Dieses RFC)
↓ definiert
Nachrichtenformat (IMF)
↓ erweitert durch
MIME-Serie (RFC 2045-2049)
↓ transportiert durch
SMTP (RFC 5321)
Dokument-Leseleitfaden
- Schnelles Verständnis: Lesen Sie die Abschnitte 1-2 (Übersicht)
- Implementierungsspezifikation: Studieren Sie Abschnitt 3 (Nachrichtengenerierung)
- Legacy-Kompatibilität: Referenzieren Sie Abschnitt 4 (Nachrichtenanalyse)
- Sicherheit: Überprüfen Sie Abschnitt 5
- Praktische Beispiele: Durchsuchen Sie Anhang A
Weiter: 2. Lexical Analysis of Messages (Lexikalische Analyse von Nachrichten)