< draft-ietf-emailcore-rfc5322bis-01.txt   draft-ietf-emailcore-rfc5322bis-02.txt >
Network Working Group P. Resnick, Ed. Network Working Group P. Resnick, Ed.
Internet-Draft Episteme Internet-Draft Episteme
Obsoletes: 5322 (if approved) 29 March 2021 Obsoletes: 5322 (if approved) 29 September 2021
Updates: 4021 (if approved) Updates: 4021 (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: 30 September 2021 Expires: 2 April 2022
Internet Message Format Internet Message Format
draft-ietf-emailcore-rfc5322bis-01 draft-ietf-emailcore-rfc5322bis-02
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 30 September 2021. This Internet-Draft will expire on 2 April 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 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
skipping to change at page 2, line 29 skipping to change at page 2, line 29
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Notational Conventions . . . . . . . . . . . . . . . . . 5 1.2. Notational Conventions . . . . . . . . . . . . . . . . . 5
1.2.1. Requirements Notation . . . . . . . . . . . . . . . . 5 1.2.1. Requirements Notation . . . . . . . . . . . . . . . . 5
1.2.2. Syntactic Notation . . . . . . . . . . . . . . . . . 5 1.2.2. Syntactic Notation . . . . . . . . . . . . . . . . . 5
1.2.3. Structure of This Document . . . . . . . . . . . . . 5 1.2.3. Structure of This Document . . . . . . . . . . . . . 5
2. Lexical Analysis of Messages . . . . . . . . . . . . . . . . 6 2. Lexical Analysis of Messages . . . . . . . . . . . . . . . . 7
2.1. General Description . . . . . . . . . . . . . . . . . . . 6 2.1. General Description . . . . . . . . . . . . . . . . . . . 7
2.1.1. Line Length Limits . . . . . . . . . . . . . . . . . 7 2.1.1. Line Length Limits . . . . . . . . . . . . . . . . . 8
2.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 8 2.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1. Unstructured Header Field Bodies . . . . . . . . . . 8 2.2.1. Unstructured Header Field Bodies . . . . . . . . . . 9
2.2.2. Structured Header Field Bodies . . . . . . . . . . . 8 2.2.2. Structured Header Field Bodies . . . . . . . . . . . 9
2.2.3. Long Header Fields . . . . . . . . . . . . . . . . . 9 2.2.3. Long Header Fields . . . . . . . . . . . . . . . . . 9
2.3. Body . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.3. Body . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 10 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 10
3.2. Lexical Tokens . . . . . . . . . . . . . . . . . . . . . 10 3.2. Lexical Tokens . . . . . . . . . . . . . . . . . . . . . 11
3.2.1. Quoted characters . . . . . . . . . . . . . . . . . . 11 3.2.1. Quoted characters . . . . . . . . . . . . . . . . . . 11
3.2.2. Folding White Space and Comments . . . . . . . . . . 11 3.2.2. Folding White Space and Comments . . . . . . . . . . 12
3.2.3. Atom . . . . . . . . . . . . . . . . . . . . . . . . 12 3.2.3. Atom . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.4. Quoted Strings . . . . . . . . . . . . . . . . . . . 13 3.2.4. Quoted Strings . . . . . . . . . . . . . . . . . . . 14
3.2.5. Miscellaneous Tokens . . . . . . . . . . . . . . . . 14 3.2.5. Miscellaneous Tokens . . . . . . . . . . . . . . . . 15
3.3. Date and Time Specification . . . . . . . . . . . . . . . 15 3.3. Date and Time Specification . . . . . . . . . . . . . . . 15
3.4. Address Specification . . . . . . . . . . . . . . . . . . 16 3.4. Address Specification . . . . . . . . . . . . . . . . . . 17
3.4.1. Addr-Spec Specification . . . . . . . . . . . . . . . 17 3.4.1. Addr-Spec Specification . . . . . . . . . . . . . . . 18
3.5. Overall Message Syntax . . . . . . . . . . . . . . . . . 18 3.5. Overall Message Syntax . . . . . . . . . . . . . . . . . 19
3.6. Field Definitions . . . . . . . . . . . . . . . . . . . . 19 3.6. Field Definitions . . . . . . . . . . . . . . . . . . . . 20
3.6.1. The Origination Date Field . . . . . . . . . . . . . 22 3.6.1. The Origination Date Field . . . . . . . . . . . . . 23
3.6.2. Originator Fields . . . . . . . . . . . . . . . . . . 22 3.6.2. Originator Fields . . . . . . . . . . . . . . . . . . 23
3.6.3. Destination Address Fields . . . . . . . . . . . . . 23 3.6.3. Destination Address Fields . . . . . . . . . . . . . 24
3.6.4. Identification Fields . . . . . . . . . . . . . . . . 25 3.6.4. Identification Fields . . . . . . . . . . . . . . . . 26
3.6.5. Informational Fields . . . . . . . . . . . . . . . . 28 3.6.5. Informational Fields . . . . . . . . . . . . . . . . 29
3.6.6. Resent Fields . . . . . . . . . . . . . . . . . . . . 29 3.6.6. Resent Fields . . . . . . . . . . . . . . . . . . . . 30
3.6.7. Trace Fields . . . . . . . . . . . . . . . . . . . . 31 3.6.7. Trace Fields . . . . . . . . . . . . . . . . . . . . 32
3.6.8. Optional Fields . . . . . . . . . . . . . . . . . . . 32 3.6.8. Optional Fields . . . . . . . . . . . . . . . . . . . 33
4. Obsolete Syntax . . . . . . . . . . . . . . . . . . . . . . . 33 4. Obsolete Syntax . . . . . . . . . . . . . . . . . . . . . . . 33
4.1. Miscellaneous Obsolete Tokens . . . . . . . . . . . . . . 34 4.1. Miscellaneous Obsolete Tokens . . . . . . . . . . . . . . 34
4.2. Obsolete Folding White Space . . . . . . . . . . . . . . 35 4.2. Obsolete Folding White Space . . . . . . . . . . . . . . 35
4.3. Obsolete Date and Time . . . . . . . . . . . . . . . . . 35 4.3. Obsolete Date and Time . . . . . . . . . . . . . . . . . 36
4.4. Obsolete Addressing . . . . . . . . . . . . . . . . . . . 37 4.4. Obsolete Addressing . . . . . . . . . . . . . . . . . . . 37
4.5. Obsolete Header Fields . . . . . . . . . . . . . . . . . 37 4.5. Obsolete Header Fields . . . . . . . . . . . . . . . . . 38
4.5.1. Obsolete Origination Date Field . . . . . . . . . . . 38 4.5.1. Obsolete Origination Date Field . . . . . . . . . . . 39
4.5.2. Obsolete Originator Fields . . . . . . . . . . . . . 38 4.5.2. Obsolete Originator Fields . . . . . . . . . . . . . 39
4.5.3. Obsolete Destination Address Fields . . . . . . . . . 38 4.5.3. Obsolete Destination Address Fields . . . . . . . . . 39
4.5.4. Obsolete Identification Fields . . . . . . . . . . . 39 4.5.4. Obsolete Identification Fields . . . . . . . . . . . 40
4.5.5. Obsolete Informational Fields . . . . . . . . . . . . 39 4.5.5. Obsolete Informational Fields . . . . . . . . . . . . 40
4.5.6. Obsolete Resent Fields . . . . . . . . . . . . . . . 40 4.5.6. Obsolete Resent Fields . . . . . . . . . . . . . . . 41
4.5.7. Obsolete Trace Fields . . . . . . . . . . . . . . . . 40 4.5.7. Obsolete Trace Fields . . . . . . . . . . . . . . . . 41
4.5.8. Obsolete optional fields . . . . . . . . . . . . . . 40 4.5.8. Obsolete optional fields . . . . . . . . . . . . . . 41
5. Security Considerations . . . . . . . . . . . . . . . . . . . 41 5. Security Considerations . . . . . . . . . . . . . . . . . . . 42
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 46
7.1. Normative References . . . . . . . . . . . . . . . . . . 45 7.1. Normative References . . . . . . . . . . . . . . . . . . 46
7.2. Informative References . . . . . . . . . . . . . . . . . 45 7.2. Informative References . . . . . . . . . . . . . . . . . 46
Appendix A. Example Messages . . . . . . . . . . . . . . . . . . 47 Appendix A. Example Messages . . . . . . . . . . . . . . . . . . 48
A.1. Addressing Examples . . . . . . . . . . . . . . . . . . . 47 A.1. Addressing Examples . . . . . . . . . . . . . . . . . . . 48
A.1.1. A Message from One Person to Another with Simple A.1.1. A Message from One Person to Another with Simple
Addressing . . . . . . . . . . . . . . . . . . . . . 47 Addressing . . . . . . . . . . . . . . . . . . . . . 48
A.1.2. Different Types of Mailboxes . . . . . . . . . . . . 48 A.1.2. Different Types of Mailboxes . . . . . . . . . . . . 49
A.1.3. Group Addresses . . . . . . . . . . . . . . . . . . . 48 A.1.3. Group Addresses . . . . . . . . . . . . . . . . . . . 49
A.2. Reply Messages . . . . . . . . . . . . . . . . . . . . . 49 A.2. Reply Messages . . . . . . . . . . . . . . . . . . . . . 50
A.3. Resent Messages . . . . . . . . . . . . . . . . . . . . . 50 A.3. Resent Messages . . . . . . . . . . . . . . . . . . . . . 51
A.4. Messages with Trace Fields . . . . . . . . . . . . . . . 51 A.4. Messages with Trace Fields . . . . . . . . . . . . . . . 52
A.5. White Space, Comments, and Other Oddities . . . . . . . . 51 A.5. White Space, Comments, and Other Oddities . . . . . . . . 52
A.6. Obsoleted Forms . . . . . . . . . . . . . . . . . . . . . 52 A.6. Obsoleted Forms . . . . . . . . . . . . . . . . . . . . . 53
A.6.1. Obsolete Addressing . . . . . . . . . . . . . . . . . 52 A.6.1. Obsolete Addressing . . . . . . . . . . . . . . . . . 53
A.6.2. Obsolete Dates . . . . . . . . . . . . . . . . . . . 52 A.6.2. Obsolete Dates . . . . . . . . . . . . . . . . . . . 53
A.6.3. Obsolete White Space and Comments . . . . . . . . . . 53 A.6.3. Obsolete White Space and Comments . . . . . . . . . . 54
Appendix B. Differences from Earlier Specifications . . . . . . 53 Appendix B. Differences from Earlier Specifications . . . . . . 54
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 56 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 57
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 56 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 57
1. Introduction 1. Introduction
1.1. Scope 1.1. Scope
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 an framework of "electronic mail" messages. This specification is an
update to [RFC5322], itself a revision of [RFC2822], all of which update to [RFC5322], itself a revision of [RFC2822], all of which
supersede [RFC0822], updating it to reflect current practice and supersede [RFC0822], updating it to reflect current practice and
incorporating incremental changes that were specified in other RFCs incorporating incremental changes that were specified in other RFCs
skipping to change at page 6, line 23 skipping to change at page 6, line 23
references in section 3 to these obsolete syntactic elements. The references in section 3 to these obsolete syntactic elements. The
rules of the obsolete syntax are elements that have appeared in rules of the obsolete syntax are elements that have appeared in
earlier versions of this specification or have previously been widely earlier versions of this specification or have previously been widely
used in Internet messages. As such, these elements MUST be used in Internet messages. As such, these elements MUST be
interpreted by parsers of messages in order to be conformant to this interpreted by parsers of messages in order to be conformant to this
specification. However, since items in this syntax have been specification. However, since items in this syntax have been
determined to be non-interoperable or to cause significant problems determined to be non-interoperable or to cause significant problems
for recipients of messages, they MUST NOT be generated by creators of for recipients of messages, they MUST NOT be generated by creators of
conformant messages. conformant messages.
| Note: The dictionary definition of "obsolete" is "no longer in
| use or no longer useful". While this specification mandates
| that these syntactic elements no longer be generated, it also
| mandates that conformant parsers be able to support them. One
| reason for this latter requirement is that there are long-
| established sites on the Internet with mail archives that go
| back decades, archives with messages containing these elements.
| Similarly, many people have decades-old messages in their
| personal message stores, and for various reasons it is
| occasionally useful to not only read such messages but also
| resend or forward them to others. While these archives may
| only be mined occasionally, and messages from these personal
| messages rarely resent, they are nonetheless still in use,
| making "obsolete" the incorrect term to describe these
| elements.
|
| Later efforts to revise this specification contemplated
| changing the term to "legacy" or something that would more
| accurately describe the elements, but such a change was
| rejected due to fears that it would result in unnecessary
| confusion, especially among long-time users and implementers of
| the specification.
Section 5 details security considerations to take into account when Section 5 details security considerations to take into account when
implementing this specification. implementing this specification.
Appendix A lists examples of different sorts of messages. These Appendix A lists examples of different sorts of messages. These
examples are not exhaustive of the types of messages that appear on examples are not exhaustive of the types of messages that appear on
the Internet, but give a broad overview of certain syntactic forms. the Internet, but give a broad overview of certain syntactic forms.
Appendix B lists the differences between this specification and Appendix B lists the differences between this specification and
earlier specifications for Internet messages. earlier specifications for Internet messages.
skipping to change at page 14, line 16 skipping to change at page 15, line 16
%d35-91 / ; characters not including %d35-91 / ; characters not including
%d93-126 / ; "\" or the quote character %d93-126 / ; "\" or the quote character
obs-qtext obs-qtext
qcontent = qtext / quoted-pair qcontent = qtext / quoted-pair
quoted-string = [CFWS] quoted-string = [CFWS]
DQUOTE *([FWS] qcontent) [FWS] DQUOTE DQUOTE *([FWS] qcontent) [FWS] DQUOTE
[CFWS] [CFWS]
// Erratum 3135 (https://www.rfc-editor.org/errata/eid3135) wanted to
// disallow empty quoted strings. There doesn't appear to be
// consensus for that (e.g., see discussion starting at
// https://mailarchive.ietf.org/arch/msg/ietf-
// 822/9NByCGWq7_dOLRNhrPkZR24074g) and therefore this erratum
// probably should have been rejected.
A quoted-string is treated as a unit. That is, quoted-string is A quoted-string is treated as a unit. That is, quoted-string is
identical to atom, semantically. Since a quoted-string is allowed to identical to atom, semantically. Since a quoted-string is allowed to
contain FWS, folding is permitted. Also note that since quoted-pair contain FWS, folding is permitted. Also note that since quoted-pair
is allowed in a quoted-string, the quote and backslash characters may is allowed in a quoted-string, the quote and backslash characters may
appear in a quoted-string so long as they appear as a quoted-pair. appear in a quoted-string so long as they appear as a quoted-pair.
Semantically, neither the optional CFWS outside of the quote Semantically, neither the optional CFWS outside of the quote
characters nor the quote characters themselves are part of the characters nor the quote characters themselves are part of the
quoted-string; the quoted-string is what is contained between the two quoted-string; the quoted-string is what is contained between the two
quote characters. As stated earlier, the "\" in any quoted-pair and quote characters. As stated earlier, the "\" in any quoted-pair and
skipping to change at page 20, line 6 skipping to change at page 21, line 6
header fields MUST NOT be reordered, and SHOULD be kept in blocks header fields MUST NOT be reordered, and SHOULD be kept in blocks
prepended to the message. See sections 3.6.6 and 3.6.7 for more prepended to the message. See sections 3.6.6 and 3.6.7 for more
information. information.
The only required header fields are the origination date field and The only required header fields are the origination date field and
the originator address field(s). All other header fields are the originator address field(s). All other header fields are
syntactically optional. More information is contained in the table syntactically optional. More information is contained in the table
following this definition. following this definition.
fields = *(trace fields = *(trace
*optional-field /
*(resent-date / *(resent-date /
resent-from / resent-from /
resent-sender / resent-sender /
resent-to / resent-to /
resent-cc / resent-cc /
resent-bcc / resent-bcc /
resent-msg-id)) resent-msg-id))
*(orig-date / *(orig-date /
from / from /
sender / sender /
skipping to change at page 20, line 29 skipping to change at page 21, line 28
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), ticket #39 // 2950 (https://www.rfc-editor.org/errata/eid2950), ticket #39
// (https://trac.ietf.org/trac/emailcore/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.
skipping to change at page 31, line 26 skipping to change at page 32, 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 or optional "Return-Path:" field, and/or one or more "Received:" fields
other fields (indicated by "optional-field" below) that are defined or other fields (indicated by "optional-field" below) that are
by other specifications as belonging within the trace fields defined by other specifications as belonging within the trace fields
grouping. The "Return-Path:" header field contains a pair of angle grouping. The "Return-Path:" header field contains a pair of angle
brackets that enclose an optional addr-spec. The "Received:" field brackets that enclose an optional addr-spec. The "Received:" field
contains a (possibly empty) list of tokens followed by a semicolon contains a (possibly empty) list of tokens followed by a semicolon
and a date- time specification. Each token must be a word, angle- and a date-time specification. Each token must be a word, angle-
addr, addr- spec, or a domain. Further restrictions are applied to addr, addr-spec, or a domain. Further restrictions are applied to
the syntax of the trace fields by specifications that provide for the syntax of the trace fields by specifications that provide for
their use, such as [I-D.ietf-emailcore-rfc5321bis]. their use, such as [I-D.ietf-emailcore-rfc5321bis].
trace = [return] trace = [return]
1*received *(received / optional-field)
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
skipping to change at page 33, line 13 skipping to change at page 33, line 43
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,
they MUST be accepted and parsed by a conformant receiver. This they MUST be accepted and parsed by a conformant receiver. This
section documents many of these syntactic elements. Taking the section documents many of these syntactic elements. (See the note in
Section 1.2.3 for an explanation of the term "obsolete".) Taking the
grammar in section 3 and adding the definitions presented in this grammar in section 3 and adding the definitions presented in this
section will result in the grammar to use for the interpretation of section will result in the grammar to use for the interpretation of
messages. messages.
| Note: This section identifies syntactic forms that any | Note: This section identifies syntactic forms that any
| implementation MUST reasonably interpret. However, there are | implementation MUST reasonably interpret. However, there are
| certainly Internet messages that do not conform to even the | certainly Internet messages that do not conform to even the
| additional syntax given in this section. The fact that a | additional syntax given in this section. The fact that a
| particular form does not appear in any section of this document | particular form does not appear in any section of this document
| is not justification for computer programs to crash or for | is not justification for computer programs to crash or for
skipping to change at page 47, line 16 skipping to change at page 48, line 16
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.ietf-emailcore-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-ietf-emailcore-rfc5321bis- Progress, Internet-Draft, draft-ietf-emailcore-rfc5321bis-
01, 25 December 2020, <https://tools.ietf.org/html/draft- 01, 25 December 2020,
ietf-emailcore-rfc5321bis-01>. <https://datatracker.ietf.org/doc/html/draft-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 55, line 43 skipping to change at page 56, line 43
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 15. Added comment to field-name ABNF to remind that length can't be
greater than 77 (erratum 5918 (https://www.rfc- greater than 77 (erratum 5918 (https://www.rfc-
editor.org/errata/eid5918)). editor.org/errata/eid5918)).
16. Clarified description in 4.5.6. 16. Clarified description in 4.5.6 as "trace information"".
17. Explained the use of the term "obsolete" in Section 1.2.3.
18. Updated syntactic and semantic descriptions of trace in 3.6.7
that there can be other fields that are treated as trace, and
allow return without any received. Moved optional-field syntax
into this section and out of 3.6 to accommodate this.
// This last part to be removed before publication.
There are also 2 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:
sections:
1. Erratum 2950: Section 3.6 1. Erratum 2950 (https://www.rfc-editor.org/errata/eid2950): As per
2. Erratum 3135: Section 3.2.4 ticket #39 (https://trac.ietf.org/trac/emailcore/ticket/39),
there is no need to change the resent fields from "*" to "1*" in
3.6 as it doesn't really affect the syntax.
2. Erratum 3135 (https://www.rfc-editor.org/errata/eid3135): As per
ticket #35 (https://trac.ietf.org/trac/emailcore/ticket/35),
discussion of empty quoted-string will appear in
https://datatracker.ietf.org/doc/draft-ietf-emailcore-as/
Appendix C. Acknowledgements Appendix C. Acknowledgements
Many people contributed to this document. They included folks who Many people contributed to this document. They included participants
participated in the Detailed Revision and Update of Messaging in and chairs of the Detailed Revision and Update of Messaging
Standards (DRUMS) Working Group of the Internet Engineering Task Standards (DRUMS) and Revision of Core Email Specifications
Force (IETF), the chair of DRUMS, the Area Directors of the IETF, (EMAILCORE) Working Groups of the Internet Engineering Task Force
reporters of errata on earlier versions of this document, and people (IETF), the Area Directors of the IETF, reporters of errata on
who simply sent their comments in via email. The editor is deeply earlier versions of this document, and people who simply sent their
indebted to them all and thanks them sincerely. (The list of these comments in via email. The editor is deeply indebted to them all and
people has been temporarily removed to try to bring it up to date.) thanks them sincerely. (The list of these people has been
temporarily removed to try to bring it up to date.)
Author's Address Author's Address
Peter W. Resnick (editor) Peter W. Resnick (editor)
Episteme Technology Consulting LLC Episteme Technology Consulting LLC
503 West Indiana Avenue 503 West Indiana Avenue
Urbana, IL 61801-4941 Urbana, IL 61801-4941
United States of America United States of America
Phone: +1 217 337 1905 Phone: +1 217 337 1905
 End of changes. 27 change blocks. 
98 lines changed or deleted 118 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/