2. Lexical Analysis of Messages (Lexikalische Analyse von Nachrichten)
2.1. General Description (Allgemeine Beschreibung)
Auf der grundlegendsten Ebene ist eine Nachricht eine Folge von Zeichen. Eine mit dieser Spezifikation konforme Nachricht besteht aus Zeichen mit Werten im Bereich von 1 bis 127 und wird als US-ASCII-Zeichen interpretiert. Der Einfachheit halber bezeichnet dieses Dokument diesen Zeichenbereich manchmal einfach als „US-ASCII-Zeichen".
Hinweis: Diese Spezifikation legt fest, dass Nachrichten aus Zeichen im US-ASCII-Bereich von 1 bis 127 bestehen. Es gibt andere Dokumente, insbesondere die MIME-Dokumentenreihe (RFC 2045, RFC 2046, RFC 2047, RFC 2049, RFC 4288, RFC 4289), die diese Spezifikation erweitern, um Werte außerhalb dieses Bereichs zu ermöglichen. Die Diskussion dieser Mechanismen liegt außerhalb des Geltungsbereichs dieser Spezifikation.
Nachrichten sind in Zeichenzeilen unterteilt. Eine Zeile ist eine Folge von Zeichen, die durch zwei Zeichen begrenzt wird - Wagenrücklauf und Zeilenvorschub; das heißt, das Wagenrücklaufzeichen (CR, Carriage Return) (ASCII-Wert 13), unmittelbar gefolgt vom Zeilenvorschubzeichen (LF, Line Feed) (ASCII-Wert 10). (Das Wagenrücklauf/Zeilenvorschub-Paar wird in diesem Dokument üblicherweise als „CRLF" geschrieben.)
Eine Nachricht besteht aus Kopfzeilenfeldern (zusammenfassend als „Kopfzeilenabschnitt der Nachricht" bezeichnet), optional gefolgt von einem Körper. Der Kopfzeilenabschnitt ist eine Sequenz von Zeichenzeilen mit spezieller Syntax, wie in dieser Spezifikation definiert. Der Körper ist einfach eine Zeichenfolge, die dem Kopfzeilenabschnitt folgt und durch eine Leerzeile (d.h. eine Zeile ohne etwas vor dem CRLF) vom Kopfzeilenabschnitt getrennt ist.
Hinweis: Die Umgangssprache und frühere Versionen dieser Spezifikation verwenden den Begriff „header", um sich entweder auf den gesamten Kopfzeilenabschnitt oder auf ein einzelnes Kopfzeilenfeld zu beziehen. Um Mehrdeutigkeiten zu vermeiden, verwendet dieses Dokument die Begriffe „header" oder „headers" nicht isoliert, sondern verwendet immer „header field" (Kopfzeilenfeld), um sich auf ein einzelnes Feld zu beziehen, und „header section" (Kopfzeilenabschnitt), um sich auf die gesamte Sammlung zu beziehen.
Nachrichtenstruktur-Diagramm
Nachricht (Message)
├── Kopfzeilenabschnitt (Header Section)
│ ├── From: [email protected] CRLF
│ ├── To: [email protected] CRLF
│ ├── Subject: Hello CRLF
│ └── Date: ... CRLF
├── Leerzeile (Empty Line)
│ └── CRLF
└── Körper (Body)
├── This is the message body. CRLF
└── Second line. CRLF
2.1.1. Line Length Limits (Zeilenlängenbeschränkungen)
Diese Spezifikation setzt zwei Grenzen für die Anzahl der Zeichen in einer Zeile. Jede Zeichenzeile muss (MUST) nicht mehr als 998 Zeichen lang sein und sollte (SHOULD) nicht mehr als 78 Zeichen lang sein, ohne CRLF.
Die 998-Zeichen-Grenze existiert aufgrund von Einschränkungen in vielen Implementierungen, die IMF-Nachrichten senden, empfangen oder speichern und einfach nicht mehr als 998 Zeichen pro Zeile verarbeiten können. Empfangende Implementierungen sollten aus Gründen der Robustheit eine beliebig große Anzahl von Zeichen in einer Zeile verarbeiten können. Es gibt jedoch so viele Implementierungen, die (in Übereinstimmung mit den Transportanforderungen von RFC 5321) keine Nachrichten mit mehr als 1000 Zeichen einschließlich CR und LF pro Zeile akzeptieren, dass es wichtig ist, dass Implementierungen solche Nachrichten nicht erstellen.
Die konservativere 78-Zeichen-Empfehlung dient dazu, die vielen Implementierungen von Benutzeroberflächen zu berücksichtigen, die diese Nachrichten anzeigen und die Anzeige von mehr als 78 Zeichen pro Zeile abschneiden oder katastrophal umbrechen können, obwohl solche Implementierungen nicht der Absicht dieser Spezifikation entsprechen (und der von RFC 5321, wenn sie tatsächlich Informationsverlust verursachen). Auch wenn diese Einschränkung für Nachrichten gilt, liegt es in der Verantwortung der Implementierungen, die Nachrichten anzeigen, aus Robustheitsgründen eine beliebig große Anzahl von Zeichen in einer Zeile zu verarbeiten (sicherlich mindestens bis zur 998-Zeichen-Grenze).
Zusammenfassung der Zeilenlängenbeschränkungen:
| Grenztyp | Länge (ohne CRLF) | Anforderung | Grund |
|---|---|---|---|
| Harte Grenze | 998 Zeichen | muss (MUST) | Viele Implementierungen können längere Zeilen nicht verarbeiten |
| Empfohlene Grenze | 78 Zeichen | sollte (SHOULD) | Anpassung an Anzeigeabschneidung in UIs |
Zeilenlängenbeispiele:
✅ Empfehlungskonform (innerhalb von 78 Zeichen):
Subject: This is a short subject line
✅ Konform aber über Empfehlung (78-998 Zeichen):
Subject: This is a very long subject line that exceeds the recommended 78 character limit but is still within the required 998 character maximum limit
❌ Nicht konform (überschreitet 998 Zeichen):
Subject: [Inhalt, der 998 Zeichen überschreitet...]
2.2. Header Fields (Kopfzeilenfelder)
Kopfzeilenfelder sind Zeilen, die mit einem Feldnamen beginnen, gefolgt von einem Doppelpunkt („:"), gefolgt von einem Feldkörper und mit CRLF abgeschlossen. Ein Feldname muss (MUST) aus druckbaren US-ASCII-Zeichen bestehen (d.h. Zeichen mit Werten zwischen 33 und 126, einschließlich), außer Doppelpunkt. Ein Feldkörper kann aus druckbaren US-ASCII-Zeichen sowie Leerzeichen (SP, ASCII-Wert 32) und horizontalen Tabulatorzeichen (HTAB, ASCII-Wert 9) (zusammen als Leerraumzeichen, WSP bekannt) bestehen. Ein Feldkörper darf (MUST NOT) CR und LF enthalten, außer wenn sie beim „Falten" (Folding) und „Entfalten" (Unfolding) verwendet werden, wie in Abschnitt 2.2.3 beschrieben. Alle Feldkörper müssen (MUST) der in den Abschnitten 3 und 4 dieser Spezifikation beschriebenen Syntax entsprechen.
Kopfzeilenfeld-Format:
Field-Name: Field-BodyCRLF
↑ ↑ ↑ ↑
| | | +--- Zeilenabschluss
| | +---------- Feldinhalt
| +----------------- Doppelpunkt-Trennzeichen
+------------------------- Feldname
Beispiel:
From: [email protected]
Subject: Meeting Tomorrow
Date: Mon, 20 Dec 2025 10:00:00 +0800
2.2.1. Unstructured Header Field Bodies (Unstrukturierte Kopfzeilenfeld-Körper)
Einige Feldkörper in dieser Spezifikation sind einfach als „unstrukturiert" (Unstructured) definiert (in Abschnitt 3.2.5 als beliebige druckbare US-ASCII-Zeichen plus Leerraumzeichen spezifiziert) ohne weitere Einschränkungen. Diese werden als unstrukturierte Feldkörper bezeichnet. Semantisch werden unstrukturierte Feldkörper einfach als einzelne Zeichenzeile ohne weitere Verarbeitung behandelt (außer „Falten" und „Entfalten", wie in Abschnitt 2.2.3 beschrieben).
Beispiele für unstrukturierte Felder:
Subject: This is any text I want to write
Comments: Here's a free-form comment
Merkmale:
- Freier Inhalt, beliebige druckbare ASCII-Zeichen
- Keine spezifische Syntaxstruktur erforderlich
- Nur Falten/Entfalten muss verarbeitet werden
2.2.2. Structured Header Field Bodies (Strukturierte Kopfzeilenfeld-Körper)
Einige Feldkörper in dieser Spezifikation haben eine restriktivere Syntax als die oben beschriebenen unstrukturierten Feldkörper. Diese werden als „strukturierte" Feldkörper bezeichnet. Strukturierte Feldkörper sind Sequenzen spezifischer lexikalischer Token, wie in den Abschnitten 3 und 4 dieser Spezifikation beschrieben. Viele dieser Token dürfen (gemäß ihrer Syntax) mit Kommentaren (wie in Abschnitt 3.2.2 beschrieben) sowie Leerraumzeichen eingeleitet oder beendet werden, und diese Leerraumzeichen unterliegen dem „Falten" und „Entfalten", wie in Abschnitt 2.2.3 beschrieben. Die semantische Analyse strukturierter Feldkörper wird zusammen mit ihrer Syntax gegeben.
Beispiele für strukturierte Felder:
From: Alice Smith <[email protected]>
To: [email protected], [email protected]
Date: Mon, 20 Dec 2025 10:00:00 +0800
Merkmale:
- Muss strengen Syntaxregeln folgen
- Enthält spezifische lexikalische Token (z.B. E-Mail-Adressen, Datum-Zeit)
- Kann Kommentare und Leerräume enthalten
- Erfordert Analyse gemäß Syntax
Vergleich:
| Typ | Syntaxstrenge | Verarbeitung | Typische Beispiele |
|---|---|---|---|
| Unstrukturiert | Locker, freier Text | Als ganze Zeichenkette | Subject, Comments |
| Strukturiert | Streng, spezifische Syntax | Nach lexikalischen Token analysieren | From, To, Date |
2.2.3. Long Header Fields (Lange Kopfzeilenfelder)
Jedes Kopfzeilenfeld ist logisch eine einzelne Zeichenzeile, die den Feldnamen, den Doppelpunkt und den Feldkörper umfasst. Aus Bequemlichkeit und um die 998/78-Zeichen-Beschränkungen pro Zeile zu bewältigen, kann der Feldkörperteil eines Kopfzeilenfeldes jedoch in eine mehrzeilige Darstellung aufgeteilt werden; dies wird „Falten" (Folding) genannt. Die allgemeine Regel ist, dass überall dort, wo diese Spezifikation faltbaren Leerraum (nicht einfach WSP-Zeichen) erlaubt, ein CRLF vor jedem WSP eingefügt werden kann.
Faltungsbeispiel:
Ursprüngliches Kopfzeilenfeld:
Subject: This is a test
Kann dargestellt werden als (gefaltet):
Subject: This
is a test
Hinweis: Obwohl strukturierte Feldkörperdefinitionen das Falten überall dort erlauben, wo faltbarer Leerraum erlaubt ist (und sogar innerhalb lexikalischer Token), sollte (SHOULD) das Falten auf das Platzieren des CRLF an syntaktischen Bruchpunkten höherer Ebene beschränkt werden. Wenn beispielsweise ein Feldkörper als durch Kommas getrennte Werte definiert ist, wird empfohlen, dass das Falten nach dem Komma erfolgt, das die strukturierten Elemente trennt, anstatt innerhalb der Elemente selbst, auch wenn es anderswo erlaubt ist.
Faltungsregeln:
- Einfügepunkt: CRLF vor jedem WSP (Leerzeichen oder Tabulator) einfügen
- Fortsetzungszeile: Nächste Zeile muss mit WSP beginnen
- Empfohlene Position: An syntaktischen Bruchpunkten hoher Ebene (z.B. nach Kommas)
Beispiel für Faltung mehrerer Adressen:
Empfohlene Faltung (nach Kommas):
To: [email protected],
[email protected],
[email protected]
Nicht empfohlen aber legal:
To: [email protected], bob@
example.com, [email protected]
Entfalten (Unfolding) ist der umgekehrte Prozess, diese gefaltete mehrzeilige Darstellung in ihre einzelne Zeilendarstellung zu überführen. Das Entfalten erfolgt durch einfaches Entfernen jedes CRLF, dem unmittelbar WSP folgt. Jedes Kopfzeilenfeld sollte in seiner entfalteten Form für weitere syntaktische und semantische Auswertung behandelt werden. Ein entfaltetes Kopfzeilenfeld hat keine Längenbeschränkung und kann daher unbestimmt lang sein.
Entfaltungsprozess:
Vor Faltung (logisch):
Subject: This is a very long subject line
Nach Faltung (Übertragung):
Subject: This is a
very long subject line
Nach Entfaltung (Analyse):
Subject: This is a very long subject line
Entfaltungsalgorithmus:
1. Identifizieren: CRLF + WSP-Muster finden
2. Entfernen: CRLF löschen, WSP behalten
3. Ergebnis: Durchgehende einzelne Zeichenzeile
2.3. Body (Körper)
Der Körper einer Nachricht besteht einfach aus Zeilen von US-ASCII-Zeichen. Die einzigen zwei Einschränkungen für den Körper sind:
- CR und LF müssen (MUST) nur zusammen als CRLF auftreten; sie dürfen (MUST NOT) unabhängig im Körper erscheinen.
- Zeichenzeilen im Körper müssen (MUST) auf 998 Zeichen begrenzt sein und sollten (SHOULD) auf 78 Zeichen begrenzt sein, ohne CRLF.
Hinweis: Wie erwähnt, gibt es andere Dokumente, insbesondere die MIME-Dokumente (RFC 2045, RFC 2046, RFC 2049, RFC 4288, RFC 4289), die diese Spezifikation erweitern (und einschränken), um verschiedene Arten von Nachrichtenkörpern zu ermöglichen. Auch hier liegen diese Mechanismen außerhalb des Geltungsbereichs dieses Dokuments.
Zusammenfassung der Körpereinschränkungen:
| Einschränkungstyp | Anforderung | Beschreibung |
|---|---|---|
| Zeilenabschluss | muss CRLF verwenden (MUST) | CR und LF können nicht unabhängig erscheinen |
| Zeilenlänge (Hart) | muss ≤ 998 Zeichen (MUST) | Ohne CRLF |
| Zeilenlänge (Empfohlen) | sollte ≤ 78 Zeichen (SHOULD) | Ohne CRLF |
Legales Körperbeispiel:
Hello Bob,CRLF
CRLF
Let's meet tomorrow at 10am.CRLF
CRLF
Best regards,CRLF
Alice CRLF
Illegale Körperbeispiele:
❌ Enthält unabhängiges CR oder LF:
Hello BobCR (LF fehlt)
LineLF (CR fehlt)
❌ Zeile zu lang (überschreitet 998 Zeichen):
[Durchgehender Text über 998 Zeichen...]
Zusammenfassung Kapitel 2
Kernkonzepte
- Zeichensatz: US-ASCII (1-127)
- Zeilenabschluss: CRLF (CR+LF)
- Nachrichtenstruktur: Kopfzeilenabschnitt + Leerzeile + Körper
- Zeilenlänge: 998 Zeichen (MUST), 78 Zeichen (SHOULD)
Vergleich der Kopfzeilenfeldtypen
Unstrukturierte Felder Strukturierte Felder
↓ ↓
Subject: Any text From: user@domain
Comments: ... To: user1, user2
Date: Day, DD Mon YYYY
↓ ↓
Als Ganzes Nach Syntax analysieren
verarbeiten
Faltungsmechanismus
Langes Feld Faltung
↓ ↓
To: [email protected], To: [email protected],
[email protected] --> [email protected]
↑ ↑
Einzelne Zeile (logisch) Mehrere Zeilen (Übertragung)
←--- Entfaltung ---
Nächste Schritte
Kapitel 2 bietet einen lexikalischen Überblick über Nachrichten. Abschnitt 3 wird präzise ABNF-Syntaxregeln für die Erstellung konformer Nachrichten definieren.
Weiter: 3. Syntax (Syntaxe)
Zurück: 1. Introduction (Einführung)