3. Syntax
3.1. Einleitung
Die in diesem Abschnitt angegebene Syntax definiert die zulässige Syntax von Internet-Nachrichten. Nachrichten, die mit dieser Spezifikation konform sind, müssen (MUST) der Syntax in diesem Abschnitt entsprechen. Wenn es in diesem Abschnitt Optionen gibt, bei denen eine Option generiert werden sollte (SHOULD), so wird dies entweder im Text oder in einem Kommentar neben der Syntax angegeben.
Für die definierten Ausdrücke wird eine kurze Beschreibung der Syntax und ihrer Verwendung angegeben, gefolgt von der Syntax in ABNF, gefolgt von einer semantischen Analyse. Die folgenden primitiven Token, die verwendet, aber ansonsten nicht spezifiziert werden, sind den "Core Rules" von [RFC5234], Anhang B.1, entnommen: CR, LF, CRLF, HTAB, SP, WSP, DQUOTE, DIGIT, ALPHA und VCHAR.
In einigen der Definitionen gibt es Non-Terminale, deren Namen mit "obs-" beginnen. Diese "obs-"-Elemente beziehen sich auf Token, die in der veralteten Syntax in Abschnitt 4 definiert sind. In allen Fällen sind diese Produktionen für die Zwecke der Generierung zulässiger Internet-Nachrichten zu ignorieren und dürfen nicht (MUST NOT) als Teil einer solchen Nachricht verwendet werden. Bei der Interpretation von Nachrichten müssen diese Token jedoch als Teil der zulässigen Syntax berücksichtigt werden (MUST). In diesem Sinne definiert Abschnitt 3 eine Grammatik für die Generierung von Nachrichten, wobei "obs-"-Elemente zu ignorieren sind, während Abschnitt 4 eine Grammatik für die Interpretation von Nachrichten hinzufügt.
3.2. Lexikalische Token
Die folgenden Regeln werden verwendet, um einen zugrunde liegenden lexikalischen Analysator zu definieren, der den übergeordneten Parsern Token zuführt. Dieser Abschnitt definiert die Token, die in strukturierten Header-Feld-Körpern verwendet werden.
Hinweis: Leser dieser Spezifikation müssen besonders darauf achten, wie diese lexikalischen Token sowohl in der Syntax niedrigerer Ebene als auch in der Syntax höherer Ebene weiter unten im Dokument verwendet werden. Insbesondere werden die Leerzeichen-Token und die in Abschnitt 3.2.2 definierten Kommentar-Token in den hier definierten Token niedrigerer Ebene verwendet, und diese Token niedrigerer Ebene werden wiederum als Teile der später definierten Token höherer Ebene verwendet. Daher können Leerzeichen und Kommentare in den Token höherer Ebene zulässig sein, auch wenn sie in einer bestimmten Definition nicht ausdrücklich erscheinen.
3.2.1. Quotierte Zeichen
Einige Zeichen sind für eine spezielle Interpretation reserviert, etwa zur Abgrenzung lexikalischer Token. Um die Verwendung dieser Zeichen als uninterpretierte Daten zu ermöglichen, wird ein Quoting-Mechanismus bereitgestellt.
quoted-pair = ("\" (VCHAR / WSP)) / obs-qp
Wo ein quoted-pair erscheint, ist es als das Zeichen allein zu interpretieren. Das heißt, das Zeichen "", das als Teil eines quoted-pair erscheint, ist semantisch "unsichtbar".
Hinweis: Das Zeichen "" kann in einer Nachricht erscheinen, wo es nicht Teil eines quoted-pair ist. Ein Zeichen "", das nicht in einem quoted-pair erscheint, ist nicht semantisch unsichtbar. Die einzigen Stellen in dieser Spezifikation, an denen quoted-pair derzeit erscheint, sind ccontent, qcontent und obs-dtext in Abschnitt 4.
3.2.2. Faltbare Leerzeichen und Kommentare
Leerzeichen, einschließlich der beim Folding verwendeten Leerzeichen (beschrieben in Abschnitt 2.2.3), können zwischen vielen Elementen in Header-Feld-Körpern erscheinen. Außerdem können Zeichenketten, die als Kommentare behandelt werden, in strukturierten Feldkörpern als in Klammern eingeschlossene Zeichen enthalten sein. Das Folgende definiert die faltbaren Leerzeichen (folding white space, FWS) und die Kommentar-Konstrukte.
Zeichenketten, die in Klammern eingeschlossen sind, gelten als Kommentare, solange sie nicht innerhalb eines "quoted-string" erscheinen, wie in Abschnitt 3.2.4 definiert. Kommentare können verschachtelt sein.
Es gibt mehrere Stellen in dieser Spezifikation, an denen Kommentare und FWS frei eingefügt werden dürfen. Um dieser Syntax gerecht zu werden, wird ein zusätzliches Token für "CFWS" für Stellen definiert, an denen Kommentare und/oder FWS auftreten können. Wo CFWS jedoch in dieser Spezifikation auftritt, darf es nicht (MUST NOT) so eingefügt werden, dass eine beliebige Zeile eines gefalteten Header-Felds ausschließlich aus WSP-Zeichen und sonst nichts besteht.
FWS = ([*WSP CRLF] 1*WSP) / obs-FWS
; Folding white space
ctext = %d33-39 / ; Printable US-ASCII
%d42-91 / ; characters not including
%d93-126 / ; "(", ")", or "\"
obs-ctext
ccontent = ctext / quoted-pair / comment
comment = "(" *([FWS] ccontent) [FWS] ")"
CFWS = (1*([FWS] comment) [FWS]) / FWS
Überall in dieser Spezifikation zeigt FWS (das Token für faltbare Leerzeichen), wo Folding, wie in Abschnitt 2.2.3 erörtert, stattfinden kann. Wo immer Folding in einer Nachricht auftritt (das heißt, ein Header-Feld-Körper, der ein CRLF gefolgt von beliebigem WSP enthält), wird Unfolding (Entfernung des CRLF) durchgeführt, bevor gemäß dieser Spezifikation eine weitere semantische Analyse dieses Header-Felds erfolgt. Das heißt, jedes CRLF, das in FWS erscheint, ist semantisch "unsichtbar".
Ein Kommentar wird üblicherweise in einem strukturierten Feldkörper verwendet, um einen für Menschen lesbaren Informationstext bereitzustellen. Da ein Kommentar FWS enthalten darf, ist Folding innerhalb des Kommentars zulässig. Beachten Sie auch, dass, da quoted-pair in einem Kommentar zulässig ist, die Klammern- und Backslash-Zeichen in einem Kommentar erscheinen dürfen, solange sie als quoted-pair erscheinen. Semantisch sind die einschließenden Klammern nicht Teil des Kommentars; der Kommentar ist das, was zwischen den beiden Klammern enthalten ist. Wie bereits erwähnt, sind das "" in jedem quoted-pair und das CRLF in jedem FWS, das innerhalb des Kommentars erscheint, semantisch "unsichtbar" und daher ebenfalls nicht Teil des Kommentars.
Folgen von FWS, Kommentar oder CFWS, die zwischen lexikalischen Token in einem strukturierten Header-Feld auftreten, werden semantisch als ein einzelnes Leerzeichen interpretiert.
3.2.3. Atom
Mehrere Produktionen in strukturierten Header-Feld-Körpern sind einfach Zeichenketten bestimmter Grundzeichen. Solche Produktionen werden Atome genannt.
Einige der strukturierten Header-Feld-Körper erlauben außerdem das Punktzeichen (".", ASCII-Wert 46) innerhalb von Folgen von atext. Zu diesem Zweck wird ein zusätzliches Token "dot-atom" definiert.
Hinweis: Das Token "specials" erscheint nirgendwo sonst in dieser Spezifikation. Es besteht einfach aus den sichtbaren (d. h. nicht steuernden, nicht leeren) Zeichen, die nicht in atext erscheinen. Es wird nur bereitgestellt, weil es für Implementierer nützlich ist, die Werkzeuge verwenden, die Nachrichten lexikalisch analysieren. Jedes der Zeichen in specials kann verwendet werden, um einen Tokenisierungs-Punkt in der lexikalischen Analyse anzugeben.
atext = ALPHA / DIGIT / ; Printable US-ASCII
"!" / "#" / ; characters not including
"$" / "%" / ; specials. Used for atoms.
"&" / "'" /
"*" / "+" /
"-" / "/" /
"=" / "?" /
"^" / "_" /
"`" / "{" /
"|" / "}" /
"~"
atom = [CFWS] 1*atext [CFWS]
dot-atom-text = 1*atext *("." 1*atext)
dot-atom = [CFWS] dot-atom-text [CFWS]
specials = "(" / ")" / ; Special characters that do
"<" / ">" / ; not appear in atext
"[" / "]" /
":" / ";" /
"@" / "\" /
"," / "." /
DQUOTE
Sowohl atom als auch dot-atom werden als eine einzelne Einheit interpretiert, die aus der Zeichenkette besteht, die sie bildet. Semantisch sind die optionalen Kommentare und FWS, die den Rest der Zeichen umgeben, nicht Teil des Atoms; das Atom ist nur die Folge von atext-Zeichen in einem atom oder die atext- und "."-Zeichen in einem dot-atom.
3.2.4. Quotierte Zeichenketten
Zeichenketten, die andere Zeichen als die in Atomen zulässigen enthalten, können in einem quoted-string-Format dargestellt werden, bei dem die Zeichen von Anführungszeichen (DQUOTE, ASCII-Wert 34) umgeben sind.
qtext = %d33 / ; Printable US-ASCII
%d35-91 / ; characters not including
%d93-126 / ; "\" or the quote character
obs-qtext
qcontent = qtext / quoted-pair
quoted-string = [CFWS]
DQUOTE *([FWS] qcontent) [FWS] DQUOTE
[CFWS]
Ein quoted-string wird als eine Einheit behandelt. Das heißt, quoted-string ist semantisch identisch mit atom. Da ein quoted-string FWS enthalten darf, ist Folding zulässig. Beachten Sie auch, dass, da quoted-pair in einem quoted-string zulässig ist, die Anführungszeichen- und Backslash-Zeichen in einem quoted-string erscheinen dürfen, solange sie als quoted-pair erscheinen.
Semantisch sind weder das optionale CFWS außerhalb der Anführungszeichen noch die Anführungszeichen selbst Teil des quoted-string; der quoted-string ist das, was zwischen den beiden Anführungszeichen enthalten ist. Wie bereits erwähnt, sind das "" in jedem quoted-pair und das CRLF in jedem FWS/CFWS, das innerhalb des quoted-string erscheint, semantisch "unsichtbar" und daher ebenfalls nicht Teil des quoted-string.
3.2.5. Verschiedene Token
Es werden drei zusätzliche Token definiert: word und phrase für Kombinationen von Atomen und/oder quoted-strings sowie unstructured zur Verwendung in unstrukturierten Header-Feldern und an einigen Stellen innerhalb strukturierter Header-Felder.
word = atom / quoted-string
phrase = 1*word / obs-phrase
unstructured = (*([FWS] VCHAR) *WSP) / obs-unstruct
3.3. Datums- und Zeitangabe
Datums- und Zeitwerte treten in mehreren Header-Feldern auf. Dieser Abschnitt spezifiziert die Syntax für eine vollständige Datums- und Zeitangabe. Obwohl faltbare Leerzeichen in der gesamten Datums-/Zeitangabe zulässig sind, wird empfohlen (RECOMMENDED), an jeder Stelle, an der FWS erscheint (ob erforderlich oder optional), ein einzelnes Leerzeichen zu verwenden; einige ältere Implementierungen interpretieren längere Folgen faltbarer Leerzeichen nicht korrekt.
date-time = [ day-of-week "," ] date time [CFWS]
day-of-week = ([FWS] day-name) / obs-day-of-week
day-name = "Mon" / "Tue" / "Wed" / "Thu" /
"Fri" / "Sat" / "Sun"
date = day month year
day = ([FWS] 1*2DIGIT FWS) / obs-day
month = "Jan" / "Feb" / "Mar" / "Apr" /
"May" / "Jun" / "Jul" / "Aug" /
"Sep" / "Oct" / "Nov" / "Dec"
year = (FWS 4*DIGIT FWS) / obs-year
time = time-of-day zone
time-of-day = hour ":" minute [ ":" second ]
hour = 2DIGIT / obs-hour
minute = 2DIGIT / obs-minute
second = 2DIGIT / obs-second
zone = (FWS ( "+" / "-" ) 4DIGIT) / obs-zone
Der Tag ist der numerische Tag des Monats. Das Jahr ist ein beliebiges numerisches Jahr ab 1900.
Die Tageszeit (time-of-day) spezifiziert die Anzahl der Stunden, Minuten und optional Sekunden seit Mitternacht des angegebenen Datums.
Datum und Tageszeit sollten (SHOULD) die lokale Zeit ausdrücken.
Die Zone spezifiziert den Versatz von der Koordinierten Weltzeit (Coordinated Universal Time, UTC, früher als "Greenwich Mean Time" bezeichnet), den Datum und Tageszeit darstellen. Das "+" oder "-" gibt an, ob die Tageszeit vor (d. h. östlich von) oder hinter (d. h. westlich von) der Weltzeit liegt. Die ersten beiden Ziffern geben die Anzahl der Stunden Differenz zur Weltzeit an, und die letzten beiden Ziffern geben die Anzahl der zusätzlichen Minuten Differenz zur Weltzeit an. (Somit bedeutet +hhmm +(hh * 60 + mm) Minuten und -hhmm bedeutet -(hh * 60 + mm) Minuten.) Die Form "+0000" sollte (SHOULD) verwendet werden, um eine Zeitzone bei Weltzeit anzugeben. Obwohl "-0000" ebenfalls Weltzeit angibt, wird es verwendet, um anzugeben, dass die Zeit auf einem System generiert wurde, das sich in einer anderen lokalen Zeitzone als der Weltzeit befinden kann, und dass die Datums-/Zeitangabe keine Informationen über die lokale Zeitzone enthält.
Eine Datums-/Zeitangabe muss (MUST) semantisch gültig sein. Das heißt, der Wochentag (falls enthalten) muss (MUST) der durch das Datum implizierte Tag sein, der numerische Tag des Monats muss (MUST) zwischen 1 und der Anzahl der für den angegebenen Monat (im angegebenen Jahr) zulässigen Tage liegen, die Tageszeit muss (MUST) im Bereich 00:00:00 bis 23:59:60 liegen (die Anzahl der Sekunden unter Berücksichtigung einer Schaltsekunde; siehe [RFC1305]), und die letzten beiden Ziffern der Zone müssen (MUST) im Bereich 00 bis 59 liegen.
3.4. Adressangabe
Adressen treten in mehreren Nachrichten-Header-Feldern auf, um Absender und Empfänger von Nachrichten anzugeben. Eine Adresse kann entweder eine einzelne Mailbox oder eine Gruppe von Mailboxen sein.
address = mailbox / group
mailbox = name-addr / addr-spec
name-addr = [display-name] angle-addr
angle-addr = [CFWS] "<" addr-spec ">" [CFWS] /
obs-angle-addr
group = display-name ":" [group-list] ";" [CFWS]
display-name = phrase
mailbox-list = (mailbox *("," mailbox)) / obs-mbox-list
address-list = (address *("," address)) / obs-addr-list
group-list = mailbox-list / CFWS / obs-group-list
Eine Mailbox empfängt Mail. Sie ist eine konzeptionelle Entität, die nicht notwendigerweise mit Dateispeicherung zusammenhängt. Beispielsweise können einige Standorte wählen, Mail auf einem Drucker auszugeben und die Ausgabe an den Schreibtisch des Adressaten zuzustellen.
Normalerweise besteht eine Mailbox aus zwei Teilen: (1) einem optionalen Anzeigenamen (display name), der den Namen des Empfängers angibt (der eine Person oder ein System sein kann) und dem Benutzer einer Mail-Anwendung angezeigt werden könnte, und (2) einer in spitzen Klammern ("<" und ">") eingeschlossenen addr-spec-Adresse. Es gibt eine alternative einfache Form einer Mailbox, bei der die addr-spec-Adresse allein erscheint, ohne den Namen des Empfängers oder die spitzen Klammern. Die Internet-addr-spec-Adresse wird in Abschnitt 3.4.1 beschrieben.
Hinweis: Einige ältere Implementierungen verwendeten die einfache Form, bei der die addr-spec ohne die spitzen Klammern erscheint, aber den Namen des Empfängers in Klammern als Kommentar nach der addr-spec enthielten. Da die Bedeutung der Informationen in einem Kommentar nicht spezifiziert ist, sollten (SHOULD) Implementierungen die vollständige name-addr-Form der Mailbox anstelle der älteren Form verwenden, um den mit einer Mailbox verbundenen Anzeigenamen anzugeben. Da einige ältere Implementierungen den Kommentar interpretieren, sollten (SHOULD NOT) Kommentare außerdem im Allgemeinen nicht in Adressfeldern verwendet werden, um eine Verwirrung solcher Implementierungen zu vermeiden.
Wenn es wünschenswert ist, mehrere Mailboxen als eine einzelne Einheit zu behandeln (d. h. in einer Verteilerliste), kann das group-Konstrukt verwendet werden. Das group-Konstrukt ermöglicht es dem Absender, eine benannte Gruppe von Empfängern anzugeben. Dies geschieht, indem ein Anzeigename für die Gruppe angegeben wird, gefolgt von einem Doppelpunkt, gefolgt von einer kommagetrennten Liste beliebig vieler Mailboxen (einschließlich null und eins) und endend mit einem Semikolon. Da die Liste der Mailboxen leer sein kann, ist die Verwendung des group-Konstrukts außerdem eine einfache Möglichkeit, Empfängern mitzuteilen, dass die Nachricht an eine oder mehrere benannte Gruppen von Empfängern gesendet wurde, ohne tatsächlich die individuelle Mailbox-Adresse eines dieser Empfänger anzugeben.
3.4.1. Addr-Spec-Angabe
Eine addr-spec ist ein spezifischer Internet-Bezeichner, der eine lokal interpretierte Zeichenkette enthält, gefolgt vom At-Zeichen ("@", ASCII-Wert 64), gefolgt von einer Internet-Domain. Die lokal interpretierte Zeichenkette ist entweder ein quoted-string oder ein dot-atom. Wenn die Zeichenkette als dot-atom dargestellt werden kann (das heißt, wenn sie keine anderen Zeichen als atext-Zeichen oder "." enthält, das von atext-Zeichen umgeben ist), dann sollte (SHOULD) die dot-atom-Form verwendet und die quoted-string-Form nicht (SHOULD NOT) verwendet werden. Kommentare und faltbare Leerzeichen sollten nicht (SHOULD NOT) um das "@" in der addr-spec verwendet werden.
Hinweis: Hier wird eine liberale Syntax für den Domain-Teil der addr-spec angegeben. Der Domain-Teil enthält jedoch Adressinformationen, die durch andere Protokolle spezifiziert und in ihnen verwendet werden (z. B. [RFC1034], [RFC1035], [RFC1123], [RFC5321]). Es obliegt daher den Implementierungen, der Syntax von Adressen für den Kontext zu entsprechen, in dem sie verwendet werden.
addr-spec = local-part "@" domain
local-part = dot-atom / quoted-string / obs-local-part
domain = dot-atom / domain-literal / obs-domain
domain-literal = [CFWS] "[" *([FWS] dtext) [FWS] "]" [CFWS]
dtext = %d33-90 / ; Printable US-ASCII
%d94-126 / ; characters not including
obs-dtext ; "[", "]", or "\"
Der Domain-Teil identifiziert den Punkt, an den die Mail zugestellt wird. In der dot-atom-Form wird dies als Internet-Domainname interpretiert (entweder ein Hostname oder ein Mail-Exchanger-Name), wie in [RFC1034], [RFC1035] und [RFC1123] beschrieben. In der domain-literal-Form wird die Domain als die wörtliche Internet-Adresse des betreffenden Hosts interpretiert. In beiden Fällen wird, wie Adressierung verwendet wird und wie Nachrichten zu einem bestimmten Host transportiert werden, in separaten Dokumenten behandelt, etwa [RFC5321]. Diese Mechanismen liegen außerhalb des Geltungsbereichs dieses Dokuments.
Der local-part-Teil ist eine domain-abhängige Zeichenkette. In Adressen wird er auf dem betreffenden Host einfach als Name einer bestimmten Mailbox interpretiert.
3.5. Gesamtsyntax der Nachricht
Eine Nachricht besteht aus Header-Feldern, optional gefolgt von einem Nachrichtenkörper. Zeilen in einer Nachricht dürfen maximal (MUST) 998 Zeichen ohne das CRLF umfassen, aber es wird empfohlen (RECOMMENDED), dass Zeilen auf 78 Zeichen ohne das CRLF begrenzt werden. (Siehe Abschnitt 2.1.1 zur Erläuterung.) In einem Nachrichtenkörper dürfen zwar alle in der text-Regel aufgeführten Zeichen verwendet werden (MAY), die Verwendung von US-ASCII-Steuerzeichen (Werte 1 bis 8, 11, 12 und 14 bis 31) wird jedoch nicht empfohlen, da ihre Interpretation durch Empfänger zur Anzeige nicht garantiert ist.
message = (fields / obs-fields)
[CRLF body]
body = (*(*998text CRLF) *998text) / obs-body
text = %d1-9 / ; Characters excluding CR
%d11 / ; and LF
%d12 /
%d14-127
Die Header-Felder tragen den größten Teil der semantischen Informationen und sind in Abschnitt 3.6 definiert. Der Körper ist einfach eine Reihe von Textzeilen, die für die Zwecke dieser Spezifikation uninterpretiert bleiben.
3.6. Felddefinitionen
Die Header-Felder einer Nachricht werden hier definiert. Alle Header-Felder haben die gleiche allgemeine syntaktische Struktur: einen Feldnamen, gefolgt von einem Doppelpunkt, gefolgt vom Feldkörper. Die spezifische Syntax für jedes Header-Feld ist in den nachfolgenden Abschnitten definiert.
Hinweis: In der ABNF-Syntax für jedes Feld in den nachfolgenden Abschnitten folgt auf jeden Feldnamen der erforderliche Doppelpunkt. Der Kürze halber wird der Doppelpunkt in der textlichen Beschreibung der Syntax jedoch manchmal nicht erwähnt. Er ist nichtsdestoweniger erforderlich.
Es ist wichtig zu beachten, dass die Header-Felder nicht garantiert in einer bestimmten Reihenfolge vorliegen. Sie können in beliebiger Reihenfolge erscheinen, und es ist bekannt, dass sie beim Transport über das Internet gelegentlich neu angeordnet werden. Für die Zwecke dieser Spezifikation sollten (SHOULD NOT) Header-Felder jedoch nicht neu angeordnet werden, wenn eine Nachricht transportiert oder umgewandelt wird. Wichtiger noch: Die Trace-Header-Felder und die Resent-Header-Felder dürfen nicht (MUST NOT) neu angeordnet werden und sollten (SHOULD) in Blöcken zusammengehalten werden, die der Nachricht vorangestellt werden. Siehe die Abschnitte 3.6.6 und 3.6.7 für weitere Informationen.
Die einzigen erforderlichen Header-Felder sind das Feld für das Erstellungsdatum und die Adressfelder des Erstellers. Alle anderen Header-Felder sind syntaktisch optional. Weitere Informationen enthält die Tabelle nach dieser Definition.
fields = *(trace
*optional-field /
*(resent-date /
resent-from /
resent-sender /
resent-to /
resent-cc /
resent-bcc /
resent-msg-id))
*(orig-date /
from /
sender /
reply-to /
to /
cc /
bcc /
message-id /
in-reply-to /
references /
subject /
comments /
keywords /
optional-field)
Die folgende Tabelle gibt Grenzen für die Häufigkeit an, mit der jedes Feld im Header-Abschnitt einer Nachricht auftreten darf, sowie etwaige besondere Einschränkungen für die Verwendung dieser Felder. Ein Sternchen ("*") neben einem Wert in der Spalte Minimum oder Maximum gibt an, dass in der Spalte Hinweise eine besondere Einschränkung erscheint.
+----------------+--------+------------+----------------------------+
| Field | Min | Max number | Notes |
| | number | | |
+----------------+--------+------------+----------------------------+
| trace | 0 | unlimited | Block prepended - see |
| | | | 3.6.7 |
| resent-date | 0* | unlimited* | One per block, required if |
| | | | other resent fields are |
| | | | present - see 3.6.6 |
| resent-from | 0 | unlimited* | One per block - see 3.6.6 |
| resent-sender | 0* | unlimited* | One per block, MUST occur |
| | | | with multi-address |
| | | | resent-from - see 3.6.6 |
| resent-to | 0 | unlimited* | One per block - see 3.6.6 |
| resent-cc | 0 | unlimited* | One per block - see 3.6.6 |
| resent-bcc | 0 | unlimited* | One per block - see 3.6.6 |
| resent-msg-id | 0 | unlimited* | One per block - see 3.6.6 |
| orig-date | 1 | 1 | |
| from | 1 | 1 | See sender and 3.6.2 |
| sender | 0* | 1 | MUST occur with |
| | | | multi-address from - see |
| | | | 3.6.2 |
| reply-to | 0 | 1 | |
| to | 0 | 1 | |
| cc | 0 | 1 | |
| bcc | 0 | 1 | |
| message-id | 0* | 1 | SHOULD be present - see |
| | | | 3.6.4 |
| in-reply-to | 0* | 1 | SHOULD occur in some |
| | | | replies - see 3.6.4 |
| references | 0* | 1 | SHOULD occur in some |
| | | | replies - see 3.6.4 |
| subject | 0 | 1 | |
| comments | 0 | unlimited | |
| keywords | 0 | unlimited | |
| optional-field | 0 | unlimited | |
+----------------+--------+------------+----------------------------+
Die genaue Interpretation jedes Felds wird in den nachfolgenden Abschnitten beschrieben.
3.6.1. Das Feld für das Erstellungsdatum
Das Feld für das Erstellungsdatum besteht aus dem Feldnamen "Date", gefolgt von einer Datums-/Zeitangabe.
orig-date = "Date:" date-time CRLF
Das Erstellungsdatum gibt das Datum und die Uhrzeit an, zu der der Ersteller der Nachricht angegeben hat, dass die Nachricht fertig und bereit war, in das Mail-Zustellungssystem eingegeben zu werden. Dies könnte beispielsweise der Zeitpunkt sein, zu dem ein Benutzer in einem Anwendungsprogramm auf die Schaltfläche "send" oder "submit" drückt. In jedem Fall soll damit ausdrücklich nicht die Zeit vermittelt werden, zu der die Nachricht tatsächlich transportiert wird, sondern vielmehr die Zeit, zu der der menschliche oder sonstige Ersteller der Nachricht die Nachricht in ihre endgültige, transportsbereite Form gebracht hat. (Ein Benutzer eines tragbaren Computers, der nicht mit einem Netzwerk verbunden ist, könnte beispielsweise eine Nachricht zur Zustellung einreihen. Das Erstellungsdatum soll das Datum und die Uhrzeit enthalten, zu der der Benutzer die Nachricht eingereiht hat, nicht die Zeit, zu der der Benutzer sich mit dem Netzwerk verbunden hat, um die Nachricht zu senden.)
3.6.2. Absenderfelder
Die Absenderfelder (originator fields) einer Nachricht bestehen aus dem From-Feld, dem Sender-Feld (sofern anwendbar) und optional dem Reply-To-Feld. Das From-Feld besteht aus dem Feldnamen "From" und einer kommagetrennten Liste mit einer oder mehreren Mailbox-Spezifikationen. Wenn das From-Feld mehr als eine Mailbox-Spezifikation in der mailbox-list enthält, muss (MUST) das Sender-Feld, das den Feldnamen "Sender" und eine einzelne Mailbox-Spezifikation enthält, in der Nachricht erscheinen. In beiden Fällen darf (MAY) außerdem ein optionales Reply-To-Feld enthalten sein, das den Feldnamen "Reply-To" und eine kommagetrennte Liste mit einer oder mehreren Adressen enthält.
from = "From:" mailbox-list CRLF
sender = "Sender:" mailbox CRLF
reply-to = "Reply-To:" address-list CRLF
Die Absenderfelder geben die Mailbox(en) der Quelle der Nachricht an. Das Feld "From:" spezifiziert den Autor (die Autoren) der Nachricht, das heißt die Mailbox(en) der Person(en) oder Systeme, die für das Verfassen der Nachricht verantwortlich sind. Das Feld "Sender:" spezifiziert die Mailbox des Agenten, der für die tatsächliche Übertragung der Nachricht verantwortlich ist. Wenn beispielsweise eine Sekretärin eine Nachricht für eine andere Person senden würde, würde die Mailbox der Sekretärin im Feld "Sender:" erscheinen und die Mailbox des tatsächlichen Autors im Feld "From:". Wenn der Ersteller der Nachricht durch eine einzelne Mailbox angegeben werden kann und Autor und Übermittler identisch sind, sollte (SHOULD NOT) das Feld "Sender:" nicht verwendet werden. Andernfalls sollten (SHOULD) beide Felder erscheinen.
Hinweis: Die Übermittler-Informationen sind immer vorhanden. Das Fehlen des Felds "Sender:" wird manchmal fälschlich dahingehend verstanden, dass der für die Übertragung der Nachricht verantwortliche Agent nicht angegeben wurde. Dieses Fehlen bedeutet lediglich, dass der Übermittler mit dem Autor identisch ist und daher nicht redundant in das Feld "Sender:" gesetzt wird.
Die Absenderfelder liefern außerdem die Informationen, die beim Antworten auf eine Nachricht erforderlich sind. Wenn das Feld "Reply-To:" vorhanden ist, gibt es die Adresse(n) an, an die nach Vorschlag des Autors der Nachricht Antworten gesendet werden sollen. Beim Fehlen des Felds "Reply-To:" sollten (SHOULD) Antworten standardmäßig an die Mailbox(en) gesendet werden, die im Feld "From:" angegeben sind, sofern nicht die Person, die die Antwort verfasst, etwas anderes angibt.
In allen Fällen sollte (SHOULD NOT) das Feld "From:" keine Mailbox enthalten, die nicht zum Autor (zu den Autoren) der Nachricht gehört. Siehe auch Abschnitt 3.6.3 für weitere Informationen zum Bilden der Zieladressen für eine Antwort.
3.6.3. Felder für Zieladressen
Die Zielfelder einer Nachricht bestehen aus drei möglichen Feldern, jedes von derselben Form: der Feldname, der entweder "To", "Cc" oder "Bcc" lautet, gefolgt von einer kommagetrennten Liste mit einer oder mehreren Adressen (entweder Mailbox- oder Gruppen-Syntax).
to = "To:" address-list CRLF
cc = "Cc:" address-list CRLF
bcc = "Bcc:" [address-list / CFWS] CRLF
Die Zielfelder spezifizieren die Empfänger der Nachricht. Jedes Zielfeld kann eine oder mehrere Adressen haben, und die Adressen geben die beabsichtigten Empfänger der Nachricht an. Der einzige Unterschied zwischen den drei Feldern besteht darin, wie jedes verwendet wird.
Das Feld "To:" enthält die Adresse(n) des primären Empfängers (der primären Empfänger) der Nachricht.
Das Feld "Cc:" (wobei "Cc" "Carbon Copy" bedeutet, im Sinne des Anfertigens einer Kopie auf einer Schreibmaschine mit Kohlepapier) enthält die Adressen anderer Personen, die die Nachricht erhalten sollen, auch wenn der Inhalt der Nachricht möglicherweise nicht an sie gerichtet ist.
Das Feld "Bcc:" (wobei "Bcc" "Blind Carbon Copy" bedeutet) enthält Adressen von Empfängern der Nachricht, deren Adressen anderen Empfängern der Nachricht nicht offenbart werden sollen. Es gibt drei Arten, wie das Feld "Bcc:" verwendet wird. Im ersten Fall wird, wenn eine Nachricht mit einem Feld "Bcc:" zum Senden vorbereitet wird, die Zeile "Bcc:" entfernt, obwohl allen Empfängern (einschließlich der im Feld "Bcc:" angegebenen) eine Kopie der Nachricht gesendet wird. Im zweiten Fall erhält jeder in den Zeilen "To:" und "Cc:" angegebene Empfänger eine Kopie der Nachricht mit wie oben entfernter Zeile "Bcc:", aber die Empfänger der Zeile "Bcc:" erhalten eine separate Kopie der Nachricht, die eine Zeile "Bcc:" enthält. (Wenn mehrere Empfängeradressen im Feld "Bcc:" vorhanden sind, senden einige Implementierungen tatsächlich eine separate Kopie der Nachricht an jeden Empfänger, wobei "Bcc:" nur die Adresse dieses jeweiligen Empfängers enthält.) Schließlich kann, da ein Feld "Bcc:" keine Adressen enthalten darf, ein Feld "Bcc:" ohne Adressen gesendet werden, was den Empfängern anzeigt, dass Blindkopien an jemanden gesendet wurden. Welche Methode für Felder "Bcc:" zu verwenden ist, hängt von der Implementierung ab, aber beachten Sie den Abschnitt "Sicherheitsüberlegungen" dieses Dokuments für eine Erörterung jeder Methode.
Wenn eine Nachricht eine Antwort auf eine andere Nachricht ist, dürfen (MAY) die Mailboxen der Autoren der ursprünglichen Nachricht (die Mailboxen im Feld "From:") oder die im Feld "Reply-To:" angegebenen Mailboxen (falls vorhanden) im Feld "To:" der Antwort erscheinen, da diese normalerweise die primären Empfänger der Antwort wären. Wenn eine Antwort auf eine Nachricht gesendet wird, die Zielfelder hat, ist es oft wünschenswert, zusätzlich zum Autor eine Kopie der Antwort an alle Empfänger der Nachricht zu senden. Wenn eine solche Antwort gebildet wird, dürfen (MAY) Adressen in den Feldern "To:" und "Cc:" der ursprünglichen Nachricht im Feld "Cc:" der Antwort erscheinen, da diese normalerweise sekundäre Empfänger der Antwort sind. Wenn ein Feld "Bcc:" in der ursprünglichen Nachricht vorhanden ist, dürfen (MAY) Adressen in diesem Feld im Feld "Bcc:" der Antwort erscheinen, sie sollten (SHOULD NOT) jedoch nicht in den Feldern "To:" oder "Cc:" erscheinen.
Hinweis: Einige Mail-Anwendungen haben automatische Antwortbefehle, die die Zieladressen der ursprünglichen Nachricht in die Zieladressen der Antwort aufnehmen. Wie sich diese Antwortbefehle verhalten, hängt von der Implementierung ab und liegt außerhalb des Geltungsbereichs dieses Dokuments. Insbesondere wird hier nicht behandelt, ob die ursprünglichen Zieladressen aufgenommen werden sollen oder nicht, wenn die ursprüngliche Nachricht ein Feld "Reply-To:" hatte.
3.6.4. Identifikationsfelder
Obwohl in der Tabelle in Abschnitt 3.6 als optional aufgeführt, sollte (SHOULD) jede Nachricht ein Feld "Message-ID:" haben. Darüber hinaus sollten (SHOULD) Antwortnachrichten die Felder "In-Reply-To:" und "References:" enthalten, wie jeweils angebracht und unten beschrieben.
Das Feld "Message-ID:" enthält eine einzelne eindeutige Nachrichtenkennung. Die Felder "References:" und "In-Reply-To:" enthalten jeweils eine oder mehrere eindeutige Nachrichtenkennungen, optional durch CFWS getrennt.
Die Syntax der Nachrichtenkennung (msg-id) ist eine eingeschränkte Version des addr-spec-Konstrukts, das in die spitzen Klammern "<" und ">" eingeschlossen ist. Anders als addr-spec erlaubt diese Syntax auf der linken Seite des "@" nur die Form dot-atom-text und enthält nirgendwo innerhalb der Nachrichtenkennung internes CFWS.
Hinweis: Wie bei addr-spec wird für die rechte Seite des "@" in einer msg-id eine liberale Syntax angegeben. Später in diesem Abschnitt wird jedoch die Verwendung einer Domain für die rechte Seite des "@" empfohlen (RECOMMENDED). Auch hier wird die Syntax von Domain-Konstrukten durch andere Protokolle spezifiziert und in ihnen verwendet (z. B. [RFC1034], [RFC1035], [RFC1123], [RFC5321]). Es obliegt daher den Implementierungen, der Syntax von Adressen für den Kontext zu entsprechen, in dem sie verwendet werden.
message-id = "Message-ID:" msg-id CRLF
in-reply-to = "In-Reply-To:" 1*msg-id CRLF
references = "References:" 1*msg-id CRLF
msg-id = [CFWS] "<" id-left "@" id-right ">" [CFWS]
id-left = dot-atom-text / obs-id-left
id-right = dot-atom-text / no-fold-literal / obs-id-right
no-fold-literal = "[" *dtext "]"
Das Feld "Message-ID:" liefert eine eindeutige Nachrichtenkennung, die sich auf eine bestimmte Version einer bestimmten Nachricht bezieht. Die Eindeutigkeit der Nachrichtenkennung wird vom Host garantiert, der sie erzeugt (siehe unten). Diese Nachrichtenkennung soll maschinenlesbar und nicht notwendigerweise für Menschen sinnvoll sein. Eine Nachrichtenkennung gehört zu genau einer Version einer bestimmten Nachricht; nachfolgende Überarbeitungen der Nachricht erhalten jeweils neue Nachrichtenkennungen.
Hinweis: Es gibt viele Fälle, in denen Nachrichten "geändert" werden, diese Änderungen jedoch keine neue Instanziierung dieser Nachricht darstellen und die Nachricht daher keine neue Nachrichtenkennung erhält. Wenn Nachrichten beispielsweise in das Transportsystem eingebracht werden, wird ihnen oft zusätzliche Header-Felder vorangestellt, etwa Trace-Felder (beschrieben in Abschnitt 3.6.7) und Resent-Felder (beschrieben in Abschnitt 3.6.6). Das Hinzufügen solcher Header-Felder ändert die Identität der Nachricht nicht, und daher bleibt das ursprüngliche Feld "Message-ID:" erhalten. In allen Fällen ist es die Bedeutung, die der Absender der Nachricht vermitteln möchte (d. h., ob dies dieselbe Nachricht oder eine andere Nachricht ist), die bestimmt, ob sich das Feld "Message-ID:" ändert, und nicht irgendein bestimmter syntaktischer Unterschied, der in der Nachricht erscheint (oder nicht erscheint).
Die Felder "In-Reply-To:" und "References:" werden beim Erstellen einer Antwort auf eine Nachricht verwendet. Sie enthalten die Nachrichtenkennung der ursprünglichen Nachricht und die Nachrichtenkennungen anderer Nachrichten (beispielsweise im Fall einer Antwort auf eine Nachricht, die selbst eine Antwort war). Das Feld "In-Reply-To:" kann verwendet werden, um die Nachricht (oder Nachrichten) zu identifizieren, auf die die neue Nachricht eine Antwort ist, während das Feld "References:" verwendet werden kann, um einen "Thread" einer Konversation zu identifizieren.
Beim Erstellen einer Antwort auf eine Nachricht werden die Felder "In-Reply-To:" und "References:" der resultierenden Nachricht wie folgt gebildet:
Das Feld "In-Reply-To:" enthält den Inhalt des Felds "Message-ID:" der Nachricht, auf die diese eine Antwort ist (die "Elternnachricht"). Wenn es mehr als eine Elternnachricht gibt, enthält das Feld "In-Reply-To:" die Inhalte der Felder "Message-ID:" aller Eltern. Wenn in keiner der Elternnachrichten ein Feld "Message-ID:" vorhanden ist, hat die neue Nachricht kein Feld "In-Reply-To:".
Das Feld "References:" enthält den Inhalt des Felds "References:" des Elternteils (falls vorhanden), gefolgt vom Inhalt des Felds "Message-ID:" des Elternteils (falls vorhanden). Wenn die Elternnachricht kein Feld "References:" enthält, aber ein Feld "In-Reply-To:" mit einer einzelnen Nachrichtenkennung hat, enthält das Feld "References:" den Inhalt des Felds "In-Reply-To:" des Elternteils, gefolgt vom Inhalt des Felds "Message-ID:" des Elternteils (falls vorhanden). Wenn beim Elternteil keines der Felder "References:", "In-Reply-To:" oder "Message-ID:" vorhanden ist, hat die neue Nachricht kein Feld "References:".
Hinweis: Einige Implementierungen parsen das Feld "References:", um den "Thread der Diskussion" anzuzeigen. Diese Implementierungen nehmen an, dass jede neue Nachricht eine Antwort auf einen einzelnen Elternteil ist, und daher, dass sie rückwärts durch das Feld "References:" gehen können, um den Elternteil jeder dort aufgeführten Nachricht zu finden. Daher wird davon abgeraten, ein Feld "References:" für eine Antwort mit mehreren Eltern zu bilden; wie dies zu tun ist, ist in diesem Dokument nicht definiert.
Die Nachrichtenkennung (msg-id) selbst muss (MUST) ein global eindeutiger Bezeichner für eine Nachricht sein. Der Erzeuger der Nachrichtenkennung muss (MUST) garantieren, dass die msg-id eindeutig ist. Es gibt mehrere Algorithmen, die verwendet werden können, um dies zu erreichen. Da die msg-id eine ähnliche Syntax wie addr-spec hat (identisch, außer dass quoted strings, Kommentare und faltbare Leerzeichen nicht zulässig sind), besteht eine gute Methode darin, den Domainnamen (oder eine Domain-Literal-IP-Adresse) des Hosts, auf dem die Nachrichtenkennung erstellt wurde, auf die rechte Seite des "@" zu setzen (da Domainnamen und IP-Adressen normalerweise eindeutig sind) und auf die linke Seite eine Kombination des aktuellen absoluten Datums und der aktuellen absoluten Uhrzeit zusammen mit einem anderen derzeit eindeutigen (vielleicht sequentiellen) auf dem System verfügbaren Bezeichner (beispielsweise eine Prozess-ID-Nummer) zu setzen. Obwohl auch andere Algorithmen funktionieren, wird empfohlen (RECOMMENDED), dass die rechte Seite einen Domain-Bezeichner enthält (entweder des Hosts selbst oder anderweitig), sodass der Erzeuger der Nachrichtenkennung die Eindeutigkeit der linken Seite innerhalb des Geltungsbereichs dieser Domain garantieren kann.
Semantisch sind die spitzen Klammern nicht Teil der msg-id; die msg-id ist das, was zwischen den beiden spitzen Klammern enthalten ist.
3.6.5. Informationsfelder
Die Informationsfelder sind alle optional. Die Felder "Subject:" und "Comments:" sind unstrukturierte Felder, wie in Abschnitt 2.2.1 definiert, und dürfen daher Text oder faltbare Leerzeichen enthalten. Das Feld "Keywords:" enthält eine kommagetrennte Liste mit einem oder mehreren Wörtern oder quoted-strings.
subject = "Subject:" unstructured CRLF
comments = "Comments:" unstructured CRLF
keywords = "Keywords:" phrase *("," phrase) CRLF
Diese drei Felder sollen nur für Menschen lesbaren Inhalt mit Informationen über die Nachricht enthalten. Das Feld "Subject:" ist am gebräuchlichsten und enthält eine kurze Zeichenkette, die das Thema der Nachricht angibt. Bei Verwendung in einer Antwort darf (MAY) der Feldkörper mit der Zeichenkette "Re: " beginnen (eine Abkürzung des lateinischen "in re", was "in der Sache" bedeutet), gefolgt vom Inhalt des Feldkörpers "Subject:" der ursprünglichen Nachricht. Wenn dies geschieht, sollte nur ein Vorkommen der Literalzeichenkette "Re: " verwendet werden, da die Verwendung anderer Zeichenketten oder mehr als eines Vorkommens zu unerwünschten Folgen führen kann. Das Feld "Comments:" enthält alle zusätzlichen Kommentare zum Text des Körpers der Nachricht. Das Feld "Keywords:" enthält eine kommagetrennte Liste wichtiger Wörter und Phrasen, die für den Empfänger nützlich sein könnten.
3.6.6. Resent-Felder
Resent-Felder sollten (SHOULD) jeder Nachricht hinzugefügt werden, die von einem Benutzer wieder in das Transportsystem eingebracht wird. Jedes Mal, wenn dies geschieht, sollte (SHOULD) ein separater Satz von Resent-Feldern hinzugefügt werden. Alle Resent-Felder, die zu einem bestimmten erneuten Senden der Nachricht gehören, sollten (SHOULD) gruppiert werden. Jeder neue Satz von Resent-Feldern wird der Nachricht vorangestellt; das heißt, der zuletzt hinzugefügte Satz von Resent-Feldern erscheint früher in der Nachricht. Andere Felder in der Nachricht werden beim Hinzufügen von Resent-Feldern nicht geändert.
Jedes der Resent-Felder entspricht einem bestimmten Feld an anderer Stelle in der Syntax. Beispielsweise entspricht das Feld "Resent-Date:" dem Feld "Date:" und das Feld "Resent-To:" dem Feld "To:". In jedem Fall ist die Syntax für den Feldkörper identisch mit der zuvor für das entsprechende Feld angegebenen Syntax.
Wenn Resent-Felder verwendet werden, müssen (MUST) die Felder "Resent-From:" und "Resent-Date:" gesendet werden. Das Feld "Resent-Message-ID:" sollte (SHOULD) gesendet werden. "Resent-Sender:" sollte nicht (SHOULD NOT) verwendet werden, wenn "Resent-Sender:" identisch mit "Resent-From:" wäre.
resent-date = "Resent-Date:" date-time CRLF
resent-from = "Resent-From:" mailbox-list CRLF
resent-sender = "Resent-Sender:" mailbox CRLF
resent-to = "Resent-To:" address-list CRLF
resent-cc = "Resent-Cc:" address-list CRLF
resent-bcc = "Resent-Bcc:" [address-list / CFWS] CRLF
resent-msg-id = "Resent-Message-ID:" msg-id CRLF
Resent-Felder werden verwendet, um eine Nachricht als von einem Benutzer wieder in das Transportsystem eingebracht zu kennzeichnen. Der Zweck der Verwendung von Resent-Feldern besteht darin, dass die Nachricht für den endgültigen Empfänger so erscheint, als wäre sie direkt vom ursprünglichen Absender gesendet worden, wobei alle ursprünglichen Felder unverändert bleiben. Jeder Satz von Resent-Feldern entspricht einem bestimmten erneuten Sendeereignis. Das heißt, wenn eine Nachricht mehrfach erneut gesendet wird, liefert jeder Satz von Resent-Feldern identifizierende Informationen für jedes einzelne Mal. Resent-Felder sind ausschließlich informativ. Sie dürfen nicht (MUST NOT) bei der normalen Verarbeitung von Antworten oder anderen derartigen automatischen Aktionen auf Nachrichten verwendet werden.
Hinweis: Das erneute Einbringen einer Nachricht in das Transportsystem und die Verwendung von Resent-Feldern ist ein anderer Vorgang als "Forwarding". "Forwarding" hat zwei Bedeutungen: Die eine Bedeutung von Forwarding ist, dass ein Mail-Programm von einem Benutzer angewiesen werden kann, eine Kopie einer Nachricht an eine andere Person weiterzuleiten, wobei die weitergeleitete Nachricht den Körper der neuen Nachricht bildet. Eine in diesem Sinne weitergeleitete Nachricht erscheint nicht so, als käme sie vom ursprünglichen Absender, sondern ist eine völlig neue Nachricht des Weiterleitenden. Forwarding kann auch bedeuten, dass ein Mail-Transportprogramm eine Nachricht erhält und sie für die endgültige Zustellung an ein anderes Ziel weiterleitet. Resent-Header-Felder sind nicht für die Verwendung mit einer dieser beiden Arten von Forwarding gedacht.
Die Resent-Absenderfelder geben die Mailbox der Person(en) oder Systeme an, die die Nachricht erneut gesendet haben. Wie bei den regulären Absenderfeldern gibt es zwei Formen: eine einfache Form "Resent-From:", die die Mailbox der Person enthält, die das erneute Senden durchführt, und die komplexere Form, bei der eine Person (im Feld "Resent-Sender:" angegeben) eine Nachricht im Namen eines oder mehrerer anderer (im Feld "Resent-From:" angegeben) erneut sendet.
Hinweis: Beim Antworten auf eine erneut gesendete Nachricht verhalten sich Antworten genauso wie bei jeder anderen Nachricht und verwenden die ursprünglichen Felder "From:", "Reply-To:", "Message-ID:" und andere Felder. Die Resent-Felder sind nur informativ und dürfen nicht (MUST NOT) bei der normalen Verarbeitung von Antworten verwendet werden.
Das Feld "Resent-Date:" gibt das Datum und die Uhrzeit an, zu der die erneut gesendete Nachricht vom erneuten Absender der Nachricht abgesandt wird. Wie beim Feld "Date:" ist es nicht das Datum und die Uhrzeit, zu der die Nachricht tatsächlich transportiert wurde.
Die Felder "Resent-To:", "Resent-Cc:" und "Resent-Bcc:" funktionieren identisch zu den Feldern "To:", "Cc:" bzw. "Bcc:", außer dass sie die Empfänger der erneut gesendeten Nachricht angeben, nicht die Empfänger der ursprünglichen Nachricht.
Das Feld "Resent-Message-ID:" liefert eine eindeutige Kennung für die erneut gesendete Nachricht.
3.6.7. Trace-Felder
Die Trace-Felder sind eine Gruppe von Header-Feldern, die aus einem optionalen Feld "Return-Path:" und einem oder mehreren Feldern "Received:" bestehen. Das Header-Feld "Return-Path:" enthält ein Paar spitzer Klammern, die eine optionale addr-spec einschließen. Das Feld "Received:" enthält eine (möglicherweise leere) Liste von Token, gefolgt von einem Semikolon und einer Datums-/Zeitangabe. Jedes Token muss ein word, angle-addr, addr-spec oder eine domain sein. Weitere Einschränkungen gelten für die Syntax der Trace-Felder durch Spezifikationen, die deren Verwendung vorsehen, etwa [RFC5321].
trace = [return]
1*received
return = "Return-Path:" path CRLF
path = angle-addr / ([CFWS] "<" [CFWS] ">" [CFWS])
received = "Received:" *received-token ";" date-time CRLF
received-token = word / angle-addr / addr-spec / domain
Eine vollständige Erörterung der Verwendung von Trace-Feldern in der Internet-Mail ist in [RFC5321] enthalten. Für die Zwecke dieser Spezifikation sind die Trace-Felder ausschließlich informativ, und jede formale Interpretation von ihnen liegt außerhalb des Geltungsbereichs dieses Dokuments.
3.6.8. Optionale Felder
In Nachrichten können Felder erscheinen, die in diesem Dokument ansonsten nicht spezifiziert sind. Sie müssen (MUST) der Syntax eines optional-field entsprechen. Dies ist ein Feldname, der aus den druckbaren US-ASCII-Zeichen außer SP und Doppelpunkt besteht, gefolgt von einem Doppelpunkt, gefolgt von beliebigem Text, der der unstrukturierten Syntax entspricht.
Die Feldnamen eines beliebigen optionalen Felds dürfen nicht (MUST NOT) mit einem Feldnamen identisch sein, der an anderer Stelle in diesem Dokument spezifiziert ist.
optional-field = field-name ":" unstructured CRLF
field-name = 1*ftext
ftext = %d33-57 / ; Printable US-ASCII
%d59-126 ; characters not including
; ":".
Für die Zwecke dieser Spezifikation ist jedes optionale Feld uninterpretiert.