< draft-ietf-emailcore-rfc5322bis-00.txt   draft-ietf-emailcore-rfc5322bis-01.txt >
Network Working Group P. Resnick, Ed. Network Working Group P. Resnick, Ed.
Internet-Draft Episteme Internet-Draft Episteme
Obsoletes: 5322 (if approved) 6 October 2020 Obsoletes: 5322 (if approved) 29 March 2021
Updates: 4021 (if approved) Updates: 4021 (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: 9 April 2021 Expires: 30 September 2021
Internet Message Format Internet Message Format
draft-ietf-emailcore-rfc5322bis-00 draft-ietf-emailcore-rfc5322bis-01
Abstract Abstract
This document specifies the Internet Message Format (IMF), a syntax This document specifies the Internet Message Format (IMF), a syntax
for text messages that are sent between computer users, within the for text messages that are sent between computer users, within the
framework of "electronic mail" messages. This specification is a framework of "electronic mail" messages. This specification is a
revision of Request For Comments (RFC) 5322, itself a revision of revision of Request For Comments (RFC) 5322, itself a revision of
Request For Comments (RFC) 2822, all of which supersede Request For Request For Comments (RFC) 2822, all of which supersede Request For
Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Comments (RFC) 822, "Standard for the Format of ARPA Internet Text
Messages", updating it to reflect current practice and incorporating Messages", updating it to reflect current practice and incorporating
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 9 April 2021. This Internet-Draft will expire on 30 September 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
skipping to change at page 3, line 10 skipping to change at page 3, line 10
3.5. Overall Message Syntax . . . . . . . . . . . . . . . . . 18 3.5. Overall Message Syntax . . . . . . . . . . . . . . . . . 18
3.6. Field Definitions . . . . . . . . . . . . . . . . . . . . 19 3.6. Field Definitions . . . . . . . . . . . . . . . . . . . . 19
3.6.1. The Origination Date Field . . . . . . . . . . . . . 22 3.6.1. The Origination Date Field . . . . . . . . . . . . . 22
3.6.2. Originator Fields . . . . . . . . . . . . . . . . . . 22 3.6.2. Originator Fields . . . . . . . . . . . . . . . . . . 22
3.6.3. Destination Address Fields . . . . . . . . . . . . . 23 3.6.3. Destination Address Fields . . . . . . . . . . . . . 23
3.6.4. Identification Fields . . . . . . . . . . . . . . . . 25 3.6.4. Identification Fields . . . . . . . . . . . . . . . . 25
3.6.5. Informational Fields . . . . . . . . . . . . . . . . 28 3.6.5. Informational Fields . . . . . . . . . . . . . . . . 28
3.6.6. Resent Fields . . . . . . . . . . . . . . . . . . . . 29 3.6.6. Resent Fields . . . . . . . . . . . . . . . . . . . . 29
3.6.7. Trace Fields . . . . . . . . . . . . . . . . . . . . 31 3.6.7. Trace Fields . . . . . . . . . . . . . . . . . . . . 31
3.6.8. Optional Fields . . . . . . . . . . . . . . . . . . . 32 3.6.8. Optional Fields . . . . . . . . . . . . . . . . . . . 32
4. Obsolete Syntax . . . . . . . . . . . . . . . . . . . . . . . 32 4. Obsolete Syntax . . . . . . . . . . . . . . . . . . . . . . . 33
4.1. Miscellaneous Obsolete Tokens . . . . . . . . . . . . . . 33 4.1. Miscellaneous Obsolete Tokens . . . . . . . . . . . . . . 34
4.2. Obsolete Folding White Space . . . . . . . . . . . . . . 34 4.2. Obsolete Folding White Space . . . . . . . . . . . . . . 35
4.3. Obsolete Date and Time . . . . . . . . . . . . . . . . . 34 4.3. Obsolete Date and Time . . . . . . . . . . . . . . . . . 35
4.4. Obsolete Addressing . . . . . . . . . . . . . . . . . . . 36 4.4. Obsolete Addressing . . . . . . . . . . . . . . . . . . . 37
4.5. Obsolete Header Fields . . . . . . . . . . . . . . . . . 37 4.5. Obsolete Header Fields . . . . . . . . . . . . . . . . . 37
4.5.1. Obsolete Origination Date Field . . . . . . . . . . . 38 4.5.1. Obsolete Origination Date Field . . . . . . . . . . . 38
4.5.2. Obsolete Originator Fields . . . . . . . . . . . . . 38 4.5.2. Obsolete Originator Fields . . . . . . . . . . . . . 38
4.5.3. Obsolete Destination Address Fields . . . . . . . . . 38 4.5.3. Obsolete Destination Address Fields . . . . . . . . . 38
4.5.4. Obsolete Identification Fields . . . . . . . . . . . 39 4.5.4. Obsolete Identification Fields . . . . . . . . . . . 39
4.5.5. Obsolete Informational Fields . . . . . . . . . . . . 39 4.5.5. Obsolete Informational Fields . . . . . . . . . . . . 39
4.5.6. Obsolete Resent Fields . . . . . . . . . . . . . . . 40 4.5.6. Obsolete Resent Fields . . . . . . . . . . . . . . . 40
4.5.7. Obsolete Trace Fields . . . . . . . . . . . . . . . . 40 4.5.7. Obsolete Trace Fields . . . . . . . . . . . . . . . . 40
4.5.8. Obsolete optional fields . . . . . . . . . . . . . . 40 4.5.8. Obsolete optional fields . . . . . . . . . . . . . . 40
5. Security Considerations . . . . . . . . . . . . . . . . . . . 41 5. Security Considerations . . . . . . . . . . . . . . . . . . . 41
skipping to change at page 4, line 27 skipping to change at page 4, line 27
There are several extensions published, such as the MIME document There are several extensions published, such as the MIME document
series ([RFC2045], [RFC2046], [RFC2049]), which describe mechanisms series ([RFC2045], [RFC2046], [RFC2049]), which describe mechanisms
for the transmission of such data through electronic mail, either by for the transmission of such data through electronic mail, either by
extending the syntax provided here or by structuring such messages to extending the syntax provided here or by structuring such messages to
conform to this syntax. Those mechanisms are outside of the scope of conform to this syntax. Those mechanisms are outside of the scope of
this specification. this specification.
In the context of electronic mail, messages are viewed as having an In the context of electronic mail, messages are viewed as having an
envelope and contents. The envelope contains whatever information is envelope and contents. The envelope contains whatever information is
needed to accomplish transmission and delivery. (See needed to accomplish transmission and delivery. (See
[I-D.klensin-rfc5321bis] for a discussion of the envelope.) The [I-D.ietf-emailcore-rfc5321bis] for a discussion of the envelope.)
contents comprise the object to be delivered to the recipient. This The contents comprise the object to be delivered to the recipient.
specification applies only to the format and some of the semantics of This specification applies only to the format and some of the
message contents. It contains no specification of the information in semantics of message contents. It contains no specification of the
the envelope. information in the envelope.
However, some message systems may use information from the contents However, some message systems may use information from the contents
to create the envelope. It is intended that this specification to create the envelope. It is intended that this specification
facilitate the acquisition of such information by programs. facilitate the acquisition of such information by programs.
This specification is intended as a definition of what message This specification is intended as a definition of what message
content format is to be passed between systems. Though some message content format is to be passed between systems. Though some message
systems locally store messages in this format (which eliminates the systems locally store messages in this format (which eliminates the
need for translation between formats) and others use formats that need for translation between formats) and others use formats that
differ from the one specified in this specification, local storage is differ from the one specified in this specification, local storage is
skipping to change at page 7, line 50 skipping to change at page 7, line 50
characters in a line. Each line of characters MUST be no more than characters in a line. Each line of characters MUST be no more than
998 characters, and SHOULD be no more than 78 characters, excluding 998 characters, and SHOULD be no more than 78 characters, excluding
the CRLF. the CRLF.
The 998 character limit is due to limitations in many implementations The 998 character limit is due to limitations in many implementations
that send, receive, or store IMF messages which simply cannot handle that send, receive, or store IMF messages which simply cannot handle
more than 998 characters on a line. Receiving implementations would more than 998 characters on a line. Receiving implementations would
do well to handle an arbitrarily large number of characters in a line do well to handle an arbitrarily large number of characters in a line
for robustness sake. However, there are so many implementations that for robustness sake. However, there are so many implementations that
(in compliance with the transport requirements of (in compliance with the transport requirements of
[I-D.klensin-rfc5321bis]) do not accept messages containing more than [I-D.ietf-emailcore-rfc5321bis]) do not accept messages containing
1000 characters including the CR and LF per line, it is important for more than 1000 characters including the CR and LF per line, it is
implementations not to create such messages. important for implementations not to create such messages.
The more conservative 78 character recommendation is to accommodate The more conservative 78 character recommendation is to accommodate
the many implementations of user interfaces that display these the many implementations of user interfaces that display these
messages which may truncate, or disastrously wrap, the display of messages which may truncate, or disastrously wrap, the display of
more than 78 characters per line, in spite of the fact that such more than 78 characters per line, in spite of the fact that such
implementations are non-conformant to the intent of this implementations are non-conformant to the intent of this
specification (and that of [I-D.klensin-rfc5321bis] if they actually specification (and that of [I-D.ietf-emailcore-rfc5321bis] if they
cause information to be lost). Again, even though this limitation is actually cause information to be lost). Again, even though this
put on messages, it is incumbent upon implementations that display limitation is put on messages, it is incumbent upon implementations
messages to handle an arbitrarily large number of characters in a that display messages to handle an arbitrarily large number of
line (certainly at least up to the 998 character limit) for the sake characters in a line (certainly at least up to the 998 character
of robustness. limit) for the sake of robustness.
2.2. Header Fields 2.2. Header Fields
Header fields are lines beginning with a field name, followed by a Header fields are lines beginning with a field name, followed by a
colon (":"), followed by a field body, and terminated by CRLF. A colon (":"), followed by a field body, and terminated by CRLF. A
field name MUST be composed of visible US-ASCII characters (i.e., field name MUST be composed of visible US-ASCII characters (i.e.,
characters that have values between 33 and 126, inclusive), except characters that have values between 33 and 126, inclusive), except
colon. A field body may be composed of visible US-ASCII characters colon. A field body may be composed of visible US-ASCII characters
as well as the space (SP, ASCII value 32) and horizontal tab (HTAB, as well as the space (SP, ASCII value 32) and horizontal tab (HTAB,
ASCII value 9) characters (together known as the white space ASCII value 9) characters (together known as the white space
skipping to change at page 18, line 8 skipping to change at page 18, line 8
string can be represented as a dot-atom (that is, it contains no string can be represented as a dot-atom (that is, it contains no
characters other than atext characters or one or more of "." characters other than atext characters or one or more of "."
surrounded by atext characters), then the dot-atom form SHOULD be surrounded by atext characters), then the dot-atom form SHOULD be
used and the quoted-string form SHOULD NOT be used. Comments and used and the quoted-string form SHOULD NOT be used. Comments and
folding white space SHOULD NOT be used around the "@" in the addr- folding white space SHOULD NOT be used around the "@" in the addr-
spec. spec.
| Note: A liberal syntax for the domain portion of addr-spec is | Note: A liberal syntax for the domain portion of addr-spec is
| given here. However, the domain portion contains addressing | given here. However, the domain portion contains addressing
| information specified by and used in other protocols (e.g., | information specified by and used in other protocols (e.g.,
| [STD13], [RFC1123], [I-D.klensin-rfc5321bis]). It is therefore | [STD13], [RFC1123], [I-D.ietf-emailcore-rfc5321bis]). It is
| incumbent upon implementations to conform to the syntax of | therefore incumbent upon implementations to conform to the
| addresses for the context in which they are used. | syntax of addresses for the context in which they are used.
addr-spec = local-part "@" domain addr-spec = local-part "@" domain
local-part = dot-atom / quoted-string / obs-local-part local-part = dot-atom / quoted-string / obs-local-part
domain = dot-atom / domain-literal / obs-domain domain = dot-atom / domain-literal / obs-domain
domain-literal = [CFWS] "[" *([FWS] dtext) [FWS] "]" [CFWS] domain-literal = [CFWS] "[" *([FWS] dtext) [FWS] "]" [CFWS]
dtext = %d33-90 / ; Visible US-ASCII dtext = %d33-90 / ; Visible US-ASCII
%d94-126 / ; characters not including %d94-126 / ; characters not including
obs-dtext ; "[", "]", or "\" obs-dtext ; "[", "]", or "\"
The domain portion identifies the point to which the mail is The domain portion identifies the point to which the mail is
delivered. In the dot-atom form, this is interpreted as an Internet delivered. In the dot-atom form, this is interpreted as an Internet
domain name (either a host name or a mail exchanger name) as domain name (either a host name or a mail exchanger name) as
described in [STD13] and [RFC1123]. In the domain-literal form, the described in [STD13] and [RFC1123]. In the domain-literal form, the
domain is interpreted as the literal Internet address of the domain is interpreted as the literal Internet address of the
particular host. In both cases, how addressing is used and how particular host. In both cases, how addressing is used and how
messages are transported to a particular host is covered in separate messages are transported to a particular host is covered in separate
documents, such as [I-D.klensin-rfc5321bis]. These mechanisms are documents, such as [I-D.ietf-emailcore-rfc5321bis]. These mechanisms
outside of the scope of this document. are outside of the scope of this document.
The local-part portion is a domain-dependent string. In addresses, The local-part portion is a domain-dependent string. In addresses,
it is simply interpreted on the particular host as a name of a it is simply interpreted on the particular host as a name of a
particular mailbox. particular mailbox.
3.5. Overall Message Syntax 3.5. Overall Message Syntax
A message consists of header fields, optionally followed by a message A message consists of header fields, optionally followed by a message
body. Lines in a message MUST be a maximum of 998 characters body. Lines in a message MUST be a maximum of 998 characters
excluding the CRLF, but it is RECOMMENDED that lines be limited to 78 excluding the CRLF, but it is RECOMMENDED that lines be limited to 78
skipping to change at page 20, line 29 skipping to change at page 20, line 29
cc / cc /
bcc / bcc /
message-id / message-id /
in-reply-to / in-reply-to /
references / references /
subject / subject /
comments / comments /
keywords / keywords /
optional-field) optional-field)
// Ticket #7 (https://trac.ietf.org/trac/emailcore/ticket/7)
// regarding the definition of trace might require updating ABNF at
// top. See also 3.6.7.
// Should there be a 1 in front of the resent fields as per erratum // Should there be a 1 in front of the resent fields as per erratum
// 2950 (https://www.rfc-editor.org/errata/eid2950)? // 2950 (https://www.rfc-editor.org/errata/eid2950), ticket #39
// (https://trac.ietf.org/trac/emailcore/ticket/39)?
The following table indicates limits on the number of times each The following table indicates limits on the number of times each
field may occur in the header section of a message as well as any field may occur in the header section of a message as well as any
special limitations on the use of those fields. An asterisk ("*") special limitations on the use of those fields. An asterisk ("*")
next to a value in the minimum or maximum column indicates that a next to a value in the minimum or maximum column indicates that a
special restriction appears in the Notes column. special restriction appears in the Notes column.
+================+========+============+==========================+ +================+========+============+==========================+
| Field | Min | Max number | Notes | | Field | Min | Max number | Notes |
| | number | | | | | number | | |
skipping to change at page 25, line 35 skipping to change at page 25, line 39
addr-spec construct enclosed in the angle bracket characters, "<" and addr-spec construct enclosed in the angle bracket characters, "<" and
">". Unlike addr-spec, this syntax only permits the dot-atom-text ">". Unlike addr-spec, this syntax only permits the dot-atom-text
form on the left-hand side of the "@" and does not have internal CFWS form on the left-hand side of the "@" and does not have internal CFWS
anywhere in the message identifier. anywhere in the message identifier.
| Note: As with addr-spec, a liberal syntax is given for the | Note: As with addr-spec, a liberal syntax is given for the
| right-hand side of the "@" in a msg-id. However, later in this | right-hand side of the "@" in a msg-id. However, later in this
| section, the use of a domain for the right-hand side of the "@" | section, the use of a domain for the right-hand side of the "@"
| is RECOMMENDED. Again, the syntax of domain constructs is | is RECOMMENDED. Again, the syntax of domain constructs is
| specified by and used in other protocols (e.g., [STD13], | specified by and used in other protocols (e.g., [STD13],
| [RFC1123], [I-D.klensin-rfc5321bis]). It is therefore | [RFC1123], [I-D.ietf-emailcore-rfc5321bis]). It is therefore
| incumbent upon implementations to conform to the syntax of | incumbent upon implementations to conform to the syntax of
| addresses for the context in which they are used. | addresses for the context in which they are used.
message-id = "Message-ID:" msg-id CRLF message-id = "Message-ID:" msg-id CRLF
in-reply-to = "In-Reply-To:" 1*msg-id CRLF in-reply-to = "In-Reply-To:" 1*msg-id CRLF
references = "References:" 1*msg-id CRLF references = "References:" 1*msg-id CRLF
msg-id = [CFWS] "<" msg-id-internal ">" [CFWS] msg-id = [CFWS] "<" msg-id-internal ">" [CFWS]
skipping to change at page 31, line 26 skipping to change at page 31, line 26
The "Resent-To:", "Resent-Cc:", and "Resent-Bcc:" fields function The "Resent-To:", "Resent-Cc:", and "Resent-Bcc:" fields function
identically to the "To:", "Cc:", and "Bcc:" fields, respectively, identically to the "To:", "Cc:", and "Bcc:" fields, respectively,
except that they indicate the recipients of the resent message, not except that they indicate the recipients of the resent message, not
the recipients of the original message. the recipients of the original message.
The "Resent-Message-ID:" field provides a unique identifier for the The "Resent-Message-ID:" field provides a unique identifier for the
resent message. resent message.
3.6.7. Trace Fields 3.6.7. Trace Fields
// The syntactic description in the first paragraph and the semantic
// description in the last paragraph have been updated to indicate
// that there can be other fields that are treated as trace, as per
// ticket #7 (https://trac.ietf.org/trac/emailcore/ticket/7).
// However, the ABNF has not yet been updated pending list consensus.
The trace fields are a group of header fields consisting of an The trace fields are a group of header fields consisting of an
optional "Return-Path:" field, and one or more "Received:" fields. optional "Return-Path:" field, and one or more "Received:" fields or
The "Return-Path:" header field contains a pair of angle brackets other fields (indicated by "optional-field" below) that are defined
that enclose an optional addr-spec. The "Received:" field contains a by other specifications as belonging within the trace fields
(possibly empty) list of tokens followed by a semicolon and a date- grouping. The "Return-Path:" header field contains a pair of angle
time specification. Each token must be a word, angle-addr, addr- brackets that enclose an optional addr-spec. The "Received:" field
spec, or a domain. Further restrictions are applied to the syntax of contains a (possibly empty) list of tokens followed by a semicolon
the trace fields by specifications that provide for their use, such and a date- time specification. Each token must be a word, angle-
as [I-D.klensin-rfc5321bis]. addr, addr- spec, or a domain. Further restrictions are applied to
the syntax of the trace fields by specifications that provide for
their use, such as [I-D.ietf-emailcore-rfc5321bis].
trace = [return] trace = [return]
1*received 1*received
return = "Return-Path:" path CRLF return = "Return-Path:" path CRLF
path = angle-addr / ([CFWS] "<" [CFWS] ">" [CFWS]) path = angle-addr / ([CFWS] "<" [CFWS] ">" [CFWS])
received = "Received:" received = "Received:"
[1*received-token / CFWS] ";" date-time CRLF [1*received-token / CFWS] ";" date-time CRLF
received-token = word / angle-addr / addr-spec / domain received-token = word / angle-addr / addr-spec / domain
A full discussion of the Internet mail use of trace fields is The trace fields document actions taken as a message moves through
contained in [I-D.klensin-rfc5321bis]. For the purposes of this the transport system. A full discussion of the Internet mail use of
specification, the trace fields are strictly informational, and any the "Return-Path:" and "Received:" trace fields is contained in
formal interpretation of them is outside of the scope of this [I-D.ietf-emailcore-rfc5321bis]; other specifications describe the
document. use of other fields that are to be interpreted as trace fields. For
the purposes of this specification, the trace fields are strictly
informational, and any formal interpretation of them is outside of
the scope of this document.
3.6.8. Optional Fields 3.6.8. Optional Fields
Fields may appear in messages that are otherwise unspecified in this Fields may appear in messages that are otherwise unspecified in this
document. They MUST conform to the syntax of an optional-field. document. They MUST conform to the syntax of an optional-field.
This is a field name, made up of the visible US-ASCII characters This is a field name, made up of the visible US-ASCII characters
except colon, followed by a colon, followed by any text that conforms except colon, followed by a colon, followed by any text that conforms
to the unstructured syntax. to the unstructured syntax.
The field names of any optional field MUST NOT be identical to any The field names of any optional field MUST NOT be identical to any
field name specified elsewhere in this document. field name specified elsewhere in this document.
optional-field = field-name ":" unstructured CRLF optional-field = field-name ":" unstructured CRLF
field-name = 1*ftext field-name = 1*ftext ; Limit to 77 characters to
; stay within 78 char-per-
; line recommendation
ftext = %d33-57 / ; Visible US-ASCII ftext = %d33-57 / ; Visible US-ASCII
%d59-126 ; characters not including %d59-126 ; characters not including
; ":". ; ":".
// Erratum 5918 (https://www.rfc-editor.org/errata/eid5918) basically
// suggests changing field-name to 1*77ftext (leaving room for the
// colon and folding white space). That's probably what was
// intended, but it probably also requires an obs-field-name, and
// there's no indication that the current text has ever caused a
// problem. The editor is ambivalent.
For the purposes of this specification, any optional field is For the purposes of this specification, any optional field is
uninterpreted. uninterpreted.
4. Obsolete Syntax 4. Obsolete Syntax
Earlier versions of this specification allowed for different (usually Earlier versions of this specification allowed for different (usually
more liberal) syntax than is allowed in this version. Also, there more liberal) syntax than is allowed in this version. Also, there
have been syntactic elements used in messages on the Internet whose have been syntactic elements used in messages on the Internet whose
interpretations have never been documented. Though these syntactic interpretations have never been documented. Though these syntactic
forms MUST NOT be generated according to the grammar in section 3, forms MUST NOT be generated according to the grammar in section 3,
skipping to change at page 40, line 29 skipping to change at page 40, line 29
obs-resent-cc = "Resent-Cc" *WSP ":" address-list CRLF obs-resent-cc = "Resent-Cc" *WSP ":" address-list CRLF
obs-resent-bcc = "Resent-Bcc" *WSP ":" obs-resent-bcc = "Resent-Bcc" *WSP ":"
(address-list / (*([CFWS] ",") [CFWS])) CRLF (address-list / (*([CFWS] ",") [CFWS])) CRLF
obs-resent-mid = "Resent-Message-ID" *WSP ":" msg-id CRLF obs-resent-mid = "Resent-Message-ID" *WSP ":" msg-id CRLF
obs-resent-rply = "Resent-Reply-To" *WSP ":" address-list CRLF obs-resent-rply = "Resent-Reply-To" *WSP ":" address-list CRLF
As with other resent fields, the "Resent-Reply-To:" field is to be As with other resent fields, the "Resent-Reply-To:" field is to be
treated as trace information only. treated as informational only.
4.5.7. Obsolete Trace Fields 4.5.7. Obsolete Trace Fields
The obs-return and obs-received are again given here as template The obs-return and obs-received are again given here as template
definitions, just as return and received are in section 3. Their definitions, just as return and received are in section 3. Their
full syntax is given in [I-D.klensin-rfc5321bis]. full syntax is given in [I-D.ietf-emailcore-rfc5321bis].
obs-return = "Return-Path" *WSP ":" path CRLF obs-return = "Return-Path" *WSP ":" path CRLF
obs-received = "Received" *WSP ":" obs-received = "Received" *WSP ":"
[1*received-token / CFWS] [ ";" date-time CRLF ] [1*received-token / CFWS] [ ";" date-time CRLF ]
4.5.8. Obsolete optional fields 4.5.8. Obsolete optional fields
obs-optional = field-name *WSP ":" unstructured CRLF obs-optional = field-name *WSP ":" unstructured CRLF
skipping to change at page 45, line 5 skipping to change at page 45, line 5
Applicable protocol Mail Applicable protocol Mail
Status standard Status standard
Author/Change controller IETF Author/Change controller IETF
Specification document(s) This document (section 3.6.7) Specification document(s) This document (section 3.6.7)
Header field name Received Header field name Received
Applicable protocol Mail Applicable protocol Mail
Status standard Status standard
Author/Change controller IETF Author/Change controller IETF
Specification document(s) This document (section 3.6.7) Specification document(s) This document (section 3.6.7)
Related information [I-D.klensin-rfc5321bis] Related information [I-D.ietf-emailcore-rfc5321bis]
7. References 7. References
7.1. Normative References 7.1. Normative References
[ANSI.X3-4.1986] [ANSI.X3-4.1986]
American National Standards Institute, "Coded Character American National Standards Institute, "Coded Character
Set - 7-bit American Standard Code for Information Set - 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986. Interchange", ANSI X3.4, 1986.
skipping to change at page 47, line 13 skipping to change at page 47, line 13
2005, <https://www.rfc-editor.org/info/rfc4021>. 2005, <https://www.rfc-editor.org/info/rfc4021>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008, DOI 10.17487/RFC5322, October 2008,
<https://www.rfc-editor.org/info/rfc5322>. <https://www.rfc-editor.org/info/rfc5322>.
[RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized
Email Headers", RFC 6532, DOI 10.17487/RFC6532, February Email Headers", RFC 6532, DOI 10.17487/RFC6532, February
2012, <https://www.rfc-editor.org/info/rfc6532>. 2012, <https://www.rfc-editor.org/info/rfc6532>.
[I-D.klensin-rfc5321bis] [I-D.ietf-emailcore-rfc5321bis]
Klensin, J., "Simple Mail Transfer Protocol", Work in Klensin, J., "Simple Mail Transfer Protocol", Work in
Progress, Internet-Draft, draft-klensin-rfc5321bis-02, 27 Progress, Internet-Draft, draft-ietf-emailcore-rfc5321bis-
December 2019, 01, 25 December 2020, <https://tools.ietf.org/html/draft-
<https://tools.ietf.org/html/draft-klensin-rfc5321bis-02>. ietf-emailcore-rfc5321bis-01>.
Appendix A. Example Messages Appendix A. Example Messages
This section presents a selection of messages. These are intended to This section presents a selection of messages. These are intended to
assist in the implementation of this specification, but should not be assist in the implementation of this specification, but should not be
taken as normative; that is to say, although the examples in this taken as normative; that is to say, although the examples in this
section were carefully reviewed, if there happens to be a conflict section were carefully reviewed, if there happens to be a conflict
between these examples and the syntax described in sections 3 and 4 between these examples and the syntax described in sections 3 and 4
of this document, the syntax in those sections is to be taken as of this document, the syntax in those sections is to be taken as
correct. correct.
skipping to change at page 51, line 8 skipping to change at page 51, line 8
This is a message just to say hello. This is a message just to say hello.
So, "Hello". So, "Hello".
If Jane, in turn, wished to resend this message to another person, If Jane, in turn, wished to resend this message to another person,
she would prepend her own set of resent header fields to the above she would prepend her own set of resent header fields to the above
and send that. (Note that for brevity, trace fields are not shown.) and send that. (Note that for brevity, trace fields are not shown.)
A.4. Messages with Trace Fields A.4. Messages with Trace Fields
As messages are sent through the transport system as described in As messages are sent through the transport system as described in
[I-D.klensin-rfc5321bis], trace fields are prepended to the message. [I-D.ietf-emailcore-rfc5321bis], trace fields are prepended to the
The following is an example of what those trace fields might look message. The following is an example of what those trace fields
like. Note that there is some folding white space in the first one might look like. Note that there is some folding white space in the
since these lines can be long. first one since these lines can be long.
Received: from x.y.test Received: from x.y.test
by example.net by example.net
via TCP via TCP
with ESMTP with ESMTP
id ABC12345 id ABC12345
for <mary@example.net>; 21 Nov 1997 10:05:43 -0600 for <mary@example.net>; 21 Nov 1997 10:05:43 -0600
Received: from node.example by x.y.test; 21 Nov 1997 10:01:22 -0600 Received: from node.example by x.y.test; 21 Nov 1997 10:01:22 -0600
From: John Doe <jdoe@node.example> From: John Doe <jdoe@node.example>
To: Mary Smith <mary@example.net> To: Mary Smith <mary@example.net>
skipping to change at page 55, line 40 skipping to change at page 55, line 40
include the space character (erratum 4692 (https://www.rfc- include the space character (erratum 4692 (https://www.rfc-
editor.org/errata/eid4692)). editor.org/errata/eid4692)).
10. Clarify midnight in time-of-day (erratum 5905 (https://www.rfc- 10. Clarify midnight in time-of-day (erratum 5905 (https://www.rfc-
editor.org/errata/eid5905)). editor.org/errata/eid5905)).
11. Allow for date-time in obs-received (erratum 5867 11. Allow for date-time in obs-received (erratum 5867
(https://www.rfc-editor.org/errata/eid5867)).* (https://www.rfc-editor.org/errata/eid5867)).*
12. Separated out "msg-id-internal" in "msg-id". 12. Separated out "msg-id-internal" in "msg-id".
13. Updated references to STD 13, STD 68, BCP 13, and BCP 14, and 13. Updated references to STD 13, STD 68, BCP 13, and BCP 14, and
reference for leap seconds to RFC 3339. reference for leap seconds to RFC 3339.
14. Fixed typo in daylight saving time in description of obs-zone.* 14. Fixed typo in daylight saving time in description of obs-zone.*
15. Added comment to field-name ABNF to remind that length can't be
greater than 77 (erratum 5918 (https://www.rfc-
editor.org/errata/eid5918)).
16. Clarified description in 4.5.6.
There are also 3 errata that were "Held For Document Update" that There are also 2 errata that were "Held For Document Update" that
have not been addressed. See the comments in the following document have not been addressed. See the comments in the following document
sections: sections:
1. Erratum 2950: Section 3.6 1. Erratum 2950: Section 3.6
2. Erratum 3135: Section 3.2.4 2. Erratum 3135: Section 3.2.4
3. Erratum 5918: Section 3.6.8
Appendix C. Acknowledgements Appendix C. Acknowledgements
Many people contributed to this document. They included folks who Many people contributed to this document. They included folks who
participated in the Detailed Revision and Update of Messaging participated in the Detailed Revision and Update of Messaging
Standards (DRUMS) Working Group of the Internet Engineering Task Standards (DRUMS) Working Group of the Internet Engineering Task
Force (IETF), the chair of DRUMS, the Area Directors of the IETF, Force (IETF), the chair of DRUMS, the Area Directors of the IETF,
reporters of errata on earlier versions of this document, and people reporters of errata on earlier versions of this document, and people
who simply sent their comments in via email. The editor is deeply who simply sent their comments in via email. The editor is deeply
indebted to them all and thanks them sincerely. (The list of these indebted to them all and thanks them sincerely. (The list of these
 End of changes. 28 change blocks. 
65 lines changed or deleted 79 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/