4. Veraltete Syntax
Frühere Versionen dieser Spezifikation erlaubten eine andere (meist liberalere) Syntax als die in dieser Version zulässige. Außerdem wurden im Internet syntaktische Elemente in Nachrichten verwendet, deren Interpretationen nie dokumentiert wurden. Obwohl diese syntaktischen Formen gemäß der Grammatik in Abschnitt 3 nicht (MUST NOT) generiert werden dürfen, müssen (MUST) sie von einem konformen Empfänger akzeptiert und geparst werden. Dieser Abschnitt dokumentiert viele dieser syntaktischen Elemente. Nimmt man die Grammatik in Abschnitt 3 und fügt die in diesem Abschnitt dargestellten Definitionen hinzu, so ergibt sich die Grammatik, die für die Interpretation von Nachrichten zu verwenden ist.
Hinweis: Dieser Abschnitt identifiziert syntaktische Formen, die jede Implementierung vernünftigerweise interpretieren muss (MUST). Es gibt jedoch sicherlich Internet-Nachrichten, die nicht einmal der in diesem Abschnitt angegebenen zusätzlichen Syntax entsprechen. Die Tatsache, dass eine bestimmte Form in keinem Abschnitt dieses Dokuments erscheint, ist keine Rechtfertigung dafür, dass Computerprogramme abstürzen oder dass fehlerhafte Daten von einer Implementierung unwiederbringlich verloren gehen. Es obliegt der Implementierung, Nachrichten robust zu behandeln.
Ein wichtiger Unterschied zwischen der veralteten (interpretierenden) und der aktuellen (generierenden) Syntax besteht darin, dass in strukturierten Header-Feld-Körpern (d. h. zwischen dem Doppelpunkt und dem CRLF eines beliebigen strukturierten Header-Felds) Leerzeichen, einschließlich faltbarer Leerzeichen, und Kommentare frei zwischen beliebigen syntaktischen Token eingefügt werden durften. Dies erlaubte viele komplexe Formen, die sich für einige Implementierungen als schwierig zu parsen erwiesen haben.
Ein weiterer wesentlicher Unterschied zwischen der veralteten und der aktuellen Syntax besteht darin, dass die Regel in Abschnitt 3.2.2 bezüglich Zeilen, die in Kommentaren und faltbaren Leerzeichen vollständig aus Leerzeichen bestehen, nicht gilt. Siehe die Erörterung faltbarer Leerzeichen in Abschnitt 4.2 unten.
Schließlich erscheinen in diesem Abschnitt bestimmte Zeichen, die früher in Nachrichten zulässig waren. Das NUL-Zeichen (ASCII-Wert 0) war einst zulässig, ist es aber aus Kompatibilitätsgründen nicht mehr. Ebenso durften US-ASCII-Steuerzeichen außer CR, LF, SP und HTAB (ASCII-Werte 1 bis 8, 11, 12, 14 bis 31 und 127) in Header-Feld-Körpern erscheinen. CR und LF durften in Nachrichten auch anders als als CRLF erscheinen; diese Verwendung wird hier ebenfalls gezeigt.
Weitere Unterschiede in Syntax und Semantik sind in den folgenden Abschnitten vermerkt.
4.1. Verschiedene veraltete Token
Diese syntaktischen Elemente werden an anderer Stelle in der veralteten Syntax oder in der Hauptsyntax verwendet. Bare CR, bare LF und NUL werden zu obs-qp, obs-body und obs-unstruct hinzugefügt. US-ASCII-Steuerzeichen werden zu obs-qp, obs-unstruct, obs-ctext und obs-qtext hinzugefügt. Das Punktzeichen wird zu obs-phrase hinzugefügt. Die obs-phrase-list sieht eine (möglicherweise leere) kommagetrennte Liste von Phrasen vor, die "null"-Elemente enthalten darf. Das heißt, es könnten zwei oder mehr Kommata in einer solchen Liste stehen, ohne dass etwas dazwischen steht, oder Kommata am Anfang oder Ende der Liste.
Hinweis: Das Zeichen "period" (oder "full stop") (".") in obs-phrase ist keine Form, die in früheren Versionen dieser oder irgendeiner anderen Spezifikation zulässig war. Der Punkt (und auch kein anderes Zeichen aus specials) war in phrase nicht zulässig, weil er eine Parsing-Schwierigkeit einführte, zwischen Phrasen und Teilen einer addr-spec zu unterscheiden (siehe Abschnitt 4.4). Er erscheint hier, weil das Punktzeichen derzeit in vielen Nachrichten im display-name-Teil von Adressen verwendet wird, insbesondere für Initialen in Namen, und daher korrekt interpretiert werden muss.
obs-NO-WS-CTL = %d1-8 / ; US-ASCII control
%d11 / ; characters that do not
%d12 / ; include the carriage
%d14-31 / ; return, line feed, and
%d127 ; white space characters
obs-ctext = obs-NO-WS-CTL
obs-qtext = obs-NO-WS-CTL
obs-utext = %d0 / obs-NO-WS-CTL / VCHAR
obs-qp = "\" (%d0 / obs-NO-WS-CTL / LF / CR)
obs-body = *((*LF *CR *((%d0 / text) *LF *CR)) / CRLF)
obs-unstruct = *((*LF *CR *(obs-utext *LF *CR)) / FWS)
obs-phrase = word *(word / "." / CFWS)
obs-phrase-list = [phrase / CFWS] *("," [phrase / CFWS])
Bare CR und bare LF erscheinen in Nachrichten mit zwei verschiedenen Bedeutungen. In vielen Fällen werden bare CR oder bare LF unsachgemäß anstelle von CRLF verwendet, um Zeilentrenner anzugeben. In anderen Fällen werden bare CR und bare LF einfach als US-ASCII-Steuerzeichen mit ihren traditionellen ASCII-Bedeutungen verwendet.
4.2. Veraltete faltbare Leerzeichen
In der veralteten Syntax darf (MAY) eine beliebige Menge faltbarer Leerzeichen überall dort eingefügt werden, wo die Regel obs-FWS zulässig ist. Dies schafft die Möglichkeit, zwei aufeinanderfolgende "Folds" in einer Zeile zu haben, und daher die Möglichkeit, dass eine Zeile, die ein gefaltetes Header-Feld bildet, vollständig aus Leerzeichen bestehen kann.
obs-FWS = 1*WSP *(CRLF 1*WSP)
4.3. Veraltetes Datum und veraltete Zeit
Die Syntax für das veraltete Datumsformat erlaubt ein zweistelliges Jahr im Datumsfeld und erlaubt eine Liste alphabetischer Zeitzonenbezeichner, die in früheren Versionen dieser Spezifikation verwendet wurden. Sie erlaubt außerdem Kommentare und faltbare Leerzeichen zwischen vielen der Token.
obs-day-of-week = [CFWS] day-name [CFWS]
obs-day = [CFWS] 1*2DIGIT [CFWS]
obs-year = [CFWS] 2*DIGIT [CFWS]
obs-hour = [CFWS] 2DIGIT [CFWS]
obs-minute = [CFWS] 2DIGIT [CFWS]
obs-second = [CFWS] 2DIGIT [CFWS]
obs-zone = "UT" / "GMT" / ; Universal Time
; North American UT
; offsets
"EST" / "EDT" / ; Eastern: - 5/ - 4
"CST" / "CDT" / ; Central: - 6/ - 5
"MST" / "MDT" / ; Mountain: - 7/ - 6
"PST" / "PDT" / ; Pacific: - 8/ - 7
;
%d65-73 / ; Military zones - "A"
%d75-90 / ; through "I" and "K"
%d97-105 / ; through "Z", both
%d107-122 ; upper and lower case
Wo ein zwei- oder dreistelliges Jahr in einem Datum vorkommt, ist das Jahr wie folgt zu interpretieren: Wird ein zweistelliges Jahr angetroffen, dessen Wert zwischen 00 und 49 liegt, wird das Jahr interpretiert, indem 2000 addiert wird, was zu einem Wert zwischen 2000 und 2049 führt. Wird ein zweistelliges Jahr mit einem Wert zwischen 50 und 99 angetroffen oder irgendein dreistelliges Jahr angetroffen, wird das Jahr interpretiert, indem 1900 addiert wird.
In der veralteten Zeitzone sind "UT" und "GMT" Hinweise auf "Universal Time" bzw. "Greenwich Mean Time" und beide semantisch identisch mit "+0000".
Die verbleibenden Drei-Zeichen-Zonen sind die US-Zeitzonen. Der erste Buchstabe, "E", "C", "M" oder "P", steht für "Eastern", "Central", "Mountain" und "Pacific". Der zweite Buchstabe ist entweder "S" für "Standard"-Zeit oder "D" für "Daylight Savings"-Zeit (oder Sommerzeit). Ihre Interpretationen sind wie folgt:
EDT is semantically equivalent to -0400 EST is semantically equivalent to -0500 CDT is semantically equivalent to -0500 CST is semantically equivalent to -0600 MDT is semantically equivalent to -0600 MST is semantically equivalent to -0700 PDT is semantically equivalent to -0700 PST is semantically equivalent to -0800
Die einzeichigen militärischen Zeitzonen wurden in [RFC0822] auf nicht standardisierte Weise definiert und sind daher in ihrer Bedeutung unvorhersehbar. Die ursprünglichen Definitionen der militärischen Zonen "A" bis "I" sind äquivalent zu "+0100" bzw. "+0900"; "K", "L" und "M" sind äquivalent zu "+1000", "+1100" bzw. "+1200"; "N" bis "Y" sind äquivalent zu "-0100" bis "-1200"; und "Z" ist äquivalent zu "+0000". Aufgrund des Fehlers in [RFC0822] sollten (SHOULD) sie jedoch alle als äquivalent zu "-0000" betrachtet werden, sofern es keine out-of-band-Informationen gibt, die ihre Bedeutung bestätigen.
Andere mehrzeichige (üblicherweise zwischen 3 und 5 Zeichen lange) alphabetische Zeitzonen wurden in Internet-Nachrichten verwendet. Jede solche Zeitzone, deren Bedeutung nicht bekannt ist, sollte (SHOULD) als äquivalent zu "-0000" betrachtet werden, sofern es keine out-of-band-Informationen gibt, die ihre Bedeutung bestätigen.
4.4. Veraltete Adressierung
Es gibt vier Hauptunterschiede bei der Adressierung. Erstens durften Mailbox-Adressen einen Route-Teil vor der addr-spec haben, wenn sie in "<" und ">" eingeschlossen waren. Die Route ist einfach eine kommagetrennte Liste von Domainnamen, denen jeweils "@" vorangestellt ist, und die Liste wird durch einen Doppelpunkt abgeschlossen. Zweitens war CFWS zwischen den durch Punkte getrennten Elementen von local-part und domain zulässig (d. h. dot-atom wurde nicht verwendet). Darüber hinaus darf local-part neben atom auch quoted-string enthalten. Drittens durften mailbox-list und address-list "null"-Elemente enthalten. Das heißt, es konnten zwei oder mehr Kommata in einer solchen Liste stehen, ohne dass etwas dazwischen stand, oder Kommata am Anfang oder Ende der Liste. Schließlich waren US-ASCII-Steuerzeichen und quoted-pairs in domain literals zulässig und werden hier hinzugefügt.
obs-angle-addr = [CFWS] "<" obs-route addr-spec ">" [CFWS]
obs-route = obs-domain-list ":"
obs-domain-list = *(CFWS / ",") "@" domain
*("," [CFWS] ["@" domain])
obs-mbox-list = *([CFWS] ",") mailbox *("," [mailbox / CFWS])
obs-addr-list = *([CFWS] ",") address *("," [address / CFWS])
obs-group-list = 1*([CFWS] ",") [CFWS]
obs-local-part = word *("." word)
obs-domain = atom *("." atom)
obs-dtext = obs-NO-WS-CTL / quoted-pair
Bei der Interpretation von Adressen sollte (SHOULD) der Route-Teil ignoriert werden.
4.5. Veraltete Header-Felder
Syntaktisch besteht der Hauptunterschied in der veralteten Feld-Syntax darin, dass sie mehrfaches Vorkommen jedes der Felder erlaubt und diese in beliebiger Reihenfolge auftreten können. Außerdem ist eine beliebige Menge Leerraum vor dem ":" am Ende des Feldnamens zulässig.
obs-fields = *(obs-return /
obs-received /
obs-orig-date /
obs-from /
obs-sender /
obs-reply-to /
obs-to /
obs-cc /
obs-bcc /
obs-message-id /
obs-in-reply-to /
obs-references /
obs-subject /
obs-comments /
obs-keywords /
obs-resent-date /
obs-resent-from /
obs-resent-send /
obs-resent-rply /
obs-resent-to /
obs-resent-cc /
obs-resent-bcc /
obs-resent-mid /
obs-optional)
Mit Ausnahme der Zielfelder für Adressen (beschrieben in Abschnitt 4.5.3) ist die Interpretation mehrfachen Vorkommens von Feldern nicht spezifiziert. Auch die Interpretation von Trace-Feldern und Resent-Feldern, die nicht in Blöcken auftreten, die der Nachricht vorangestellt sind, ist nicht spezifiziert. Sofern in den folgenden Abschnitten nichts anderes vermerkt ist, ist die Interpretation anderer Felder identisch mit der Interpretation ihrer nicht veralteten Gegenstücke in Abschnitt 3.
4.5.1. Veraltetes Feld für das Erstellungsdatum
obs-orig-date = "Date" *WSP ":" date-time CRLF
4.5.2. Veraltete Absenderfelder
obs-from = "From" *WSP ":" mailbox-list CRLF
obs-sender = "Sender" *WSP ":" mailbox CRLF
obs-reply-to = "Reply-To" *WSP ":" address-list CRLF
4.5.3. Veraltete Felder für Zieladressen
obs-to = "To" *WSP ":" address-list CRLF
obs-cc = "Cc" *WSP ":" address-list CRLF
obs-bcc = "Bcc" *WSP ":"
(address-list / (*([CFWS] ",") [CFWS])) CRLF
Wenn mehrere Vorkommen von Zielfeldern für Adressen in einer Nachricht auftreten, sollten (SHOULD) sie so behandelt werden, als würde die Adressliste im ersten Vorkommen des Felds mit den Adresslisten der nachfolgenden Vorkommen kombiniert, indem ein Komma hinzugefügt und verkettet wird.
4.5.4. Veraltete Identifikationsfelder
Die veralteten Felder "In-Reply-To:" und "References:" unterscheiden sich von der aktuellen Syntax dadurch, dass sie das Auftreten von phrase (Wörter oder quoted strings) erlauben. Die veralteten Formen der linken und rechten Seite der msg-id erlauben eingestreutes CFWS, wodurch sie syntaktisch mit local-part bzw. domain identisch werden.
obs-message-id = "Message-ID" *WSP ":" msg-id CRLF
obs-in-reply-to = "In-Reply-To" *WSP ":" *(phrase / msg-id) CRLF
obs-references = "References" *WSP ":" *(phrase / msg-id) CRLF
obs-id-left = local-part
obs-id-right = domain
Für Zwecke der Interpretation werden die Phrasen in den Feldern "In-Reply-To:" und "References:" ignoriert.
Semantisch ist keines der optionalen CFWS in der local-part bzw. der domain Teil der obs-id-left bzw. obs-id-right.
4.5.5. Veraltete Informationsfelder
obs-subject = "Subject" *WSP ":" unstructured CRLF
obs-comments = "Comments" *WSP ":" unstructured CRLF
obs-keywords = "Keywords" *WSP ":" obs-phrase-list CRLF
4.5.6. Veraltete Resent-Felder
Die veraltete Syntax fügt ein Feld "Resent-Reply-To:" hinzu, das aus dem Feldnamen, den optionalen Kommentaren und faltbaren Leerzeichen, dem Doppelpunkt und einer kommagetrennten Liste von Adressen besteht.
obs-resent-from = "Resent-From" *WSP ":" mailbox-list CRLF
obs-resent-send = "Resent-Sender" *WSP ":" mailbox CRLF
obs-resent-date = "Resent-Date" *WSP ":" date-time CRLF
obs-resent-to = "Resent-To" *WSP ":" address-list CRLF
obs-resent-cc = "Resent-Cc" *WSP ":" address-list CRLF
obs-resent-bcc = "Resent-Bcc" *WSP ":"
(address-list / (*([CFWS] ",") [CFWS])) CRLF
obs-resent-mid = "Resent-Message-ID" *WSP ":" msg-id CRLF
obs-resent-rply = "Resent-Reply-To" *WSP ":" address-list CRLF
Wie bei anderen Resent-Feldern ist das Feld "Resent-Reply-To:" nur als Trace-Information zu behandeln.
4.5.7. Veraltete Trace-Felder
Die obs-return und obs-received werden hier erneut als Vorlagendefinitionen angegeben, ebenso wie return und received in Abschnitt 3. Ihre vollständige Syntax ist in [RFC5321] angegeben.
obs-return = "Return-Path" *WSP ":" path CRLF
obs-received = "Received" *WSP ":" *received-token CRLF
4.5.8. Veraltete optionale Felder
obs-optional = field-name *WSP ":" unstructured CRLF