< draft-ietf-emailcore-rfc5322bis-02.txt   draft-ietf-emailcore-rfc5322bis-03.txt >
Network Working Group P. Resnick, Ed. Network Working Group P. Resnick, Ed.
Internet-Draft Episteme Internet-Draft Episteme
Obsoletes: 5322 (if approved) 29 September 2021 Obsoletes: 5322 (if approved) 4 April 2022
Updates: 4021 (if approved) Updates: 4021 (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: 2 April 2022 Expires: 6 October 2022
Internet Message Format Internet Message Format
draft-ietf-emailcore-rfc5322bis-02 draft-ietf-emailcore-rfc5322bis-03
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 2 April 2022. This Internet-Draft will expire on 6 October 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 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 Revised BSD License text as
as described in Section 4.e of the Trust Legal Provisions and are 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 Revised BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
skipping to change at page 3, line 6 skipping to change at page 3, line 6
3.2.5. Miscellaneous Tokens . . . . . . . . . . . . . . . . 15 3.2.5. Miscellaneous Tokens . . . . . . . . . . . . . . . . 15
3.3. Date and Time Specification . . . . . . . . . . . . . . . 15 3.3. Date and Time Specification . . . . . . . . . . . . . . . 15
3.4. Address Specification . . . . . . . . . . . . . . . . . . 17 3.4. Address Specification . . . . . . . . . . . . . . . . . . 17
3.4.1. Addr-Spec Specification . . . . . . . . . . . . . . . 18 3.4.1. Addr-Spec Specification . . . . . . . . . . . . . . . 18
3.5. Overall Message Syntax . . . . . . . . . . . . . . . . . 19 3.5. Overall Message Syntax . . . . . . . . . . . . . . . . . 19
3.6. Field Definitions . . . . . . . . . . . . . . . . . . . . 20 3.6. Field Definitions . . . . . . . . . . . . . . . . . . . . 20
3.6.1. The Origination Date Field . . . . . . . . . . . . . 23 3.6.1. The Origination Date Field . . . . . . . . . . . . . 23
3.6.2. Originator Fields . . . . . . . . . . . . . . . . . . 23 3.6.2. Originator Fields . . . . . . . . . . . . . . . . . . 23
3.6.3. Destination Address Fields . . . . . . . . . . . . . 24 3.6.3. Destination Address Fields . . . . . . . . . . . . . 24
3.6.4. Identification Fields . . . . . . . . . . . . . . . . 26 3.6.4. Identification Fields . . . . . . . . . . . . . . . . 26
3.6.5. Informational Fields . . . . . . . . . . . . . . . . 29 3.6.5. Informational Fields . . . . . . . . . . . . . . . . 28
3.6.6. Resent Fields . . . . . . . . . . . . . . . . . . . . 30 3.6.6. Resent Fields . . . . . . . . . . . . . . . . . . . . 29
3.6.7. Trace Fields . . . . . . . . . . . . . . . . . . . . 32 3.6.7. Trace Fields . . . . . . . . . . . . . . . . . . . . 31
3.6.8. Optional Fields . . . . . . . . . . . . . . . . . . . 33 3.6.8. Optional Fields . . . . . . . . . . . . . . . . . . . 32
4. Obsolete Syntax . . . . . . . . . . . . . . . . . . . . . . . 33 4. Obsolete Syntax . . . . . . . . . . . . . . . . . . . . . . . 32
4.1. Miscellaneous Obsolete Tokens . . . . . . . . . . . . . . 34 4.1. Miscellaneous Obsolete Tokens . . . . . . . . . . . . . . 33
4.2. Obsolete Folding White Space . . . . . . . . . . . . . . 35 4.2. Obsolete Folding White Space . . . . . . . . . . . . . . 34
4.3. Obsolete Date and Time . . . . . . . . . . . . . . . . . 36 4.3. Obsolete Date and Time . . . . . . . . . . . . . . . . . 34
4.4. Obsolete Addressing . . . . . . . . . . . . . . . . . . . 37 4.4. Obsolete Addressing . . . . . . . . . . . . . . . . . . . 36
4.5. Obsolete Header Fields . . . . . . . . . . . . . . . . . 38 4.5. Obsolete Header Fields . . . . . . . . . . . . . . . . . 37
4.5.1. Obsolete Origination Date Field . . . . . . . . . . . 39 4.5.1. Obsolete Origination Date Field . . . . . . . . . . . 38
4.5.2. Obsolete Originator Fields . . . . . . . . . . . . . 39 4.5.2. Obsolete Originator Fields . . . . . . . . . . . . . 38
4.5.3. Obsolete Destination Address Fields . . . . . . . . . 39 4.5.3. Obsolete Destination Address Fields . . . . . . . . . 38
4.5.4. Obsolete Identification Fields . . . . . . . . . . . 40 4.5.4. Obsolete Identification Fields . . . . . . . . . . . 39
4.5.5. Obsolete Informational Fields . . . . . . . . . . . . 40 4.5.5. Obsolete Informational Fields . . . . . . . . . . . . 39
4.5.6. Obsolete Resent Fields . . . . . . . . . . . . . . . 41 4.5.6. Obsolete Resent Fields . . . . . . . . . . . . . . . 40
4.5.7. Obsolete Trace Fields . . . . . . . . . . . . . . . . 41 4.5.7. Obsolete Trace Fields . . . . . . . . . . . . . . . . 40
4.5.8. Obsolete optional fields . . . . . . . . . . . . . . 41 4.5.8. Obsolete optional fields . . . . . . . . . . . . . . 40
5. Security Considerations . . . . . . . . . . . . . . . . . . . 42 5. Security Considerations . . . . . . . . . . . . . . . . . . . 41
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 46 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 45
7.1. Normative References . . . . . . . . . . . . . . . . . . 46 7.1. Normative References . . . . . . . . . . . . . . . . . . 45
7.2. Informative References . . . . . . . . . . . . . . . . . 46 7.2. Informative References . . . . . . . . . . . . . . . . . 45
Appendix A. Example Messages . . . . . . . . . . . . . . . . . . 48 Appendix A. Example Messages . . . . . . . . . . . . . . . . . . 47
A.1. Addressing Examples . . . . . . . . . . . . . . . . . . . 48 A.1. Addressing Examples . . . . . . . . . . . . . . . . . . . 47
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 . . . . . . . . . . . . . . . . . . . . . 48 Addressing . . . . . . . . . . . . . . . . . . . . . 47
A.1.2. Different Types of Mailboxes . . . . . . . . . . . . 49 A.1.2. Different Types of Mailboxes . . . . . . . . . . . . 48
A.1.3. Group Addresses . . . . . . . . . . . . . . . . . . . 49 A.1.3. Group Addresses . . . . . . . . . . . . . . . . . . . 48
A.2. Reply Messages . . . . . . . . . . . . . . . . . . . . . 50 A.2. Reply Messages . . . . . . . . . . . . . . . . . . . . . 49
A.3. Resent Messages . . . . . . . . . . . . . . . . . . . . . 51 A.3. Resent Messages . . . . . . . . . . . . . . . . . . . . . 50
A.4. Messages with Trace Fields . . . . . . . . . . . . . . . 52 A.4. Messages with Trace Fields . . . . . . . . . . . . . . . 51
A.5. White Space, Comments, and Other Oddities . . . . . . . . 52 A.5. White Space, Comments, and Other Oddities . . . . . . . . 51
A.6. Obsoleted Forms . . . . . . . . . . . . . . . . . . . . . 53 A.6. Obsoleted Forms . . . . . . . . . . . . . . . . . . . . . 52
A.6.1. Obsolete Addressing . . . . . . . . . . . . . . . . . 53 A.6.1. Obsolete Addressing . . . . . . . . . . . . . . . . . 52
A.6.2. Obsolete Dates . . . . . . . . . . . . . . . . . . . 53 A.6.2. Obsolete Dates . . . . . . . . . . . . . . . . . . . 52
A.6.3. Obsolete White Space and Comments . . . . . . . . . . 54 A.6.3. Obsolete White Space and Comments . . . . . . . . . . 53
Appendix B. Differences from Earlier Specifications . . . . . . 54 Appendix B. Differences from Earlier Specifications . . . . . . 53
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 57 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 56
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 57 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 56
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 35 skipping to change at page 6, line 35
| that these syntactic elements no longer be generated, it also | that these syntactic elements no longer be generated, it also
| mandates that conformant parsers be able to support them. One | mandates that conformant parsers be able to support them. One
| reason for this latter requirement is that there are long- | reason for this latter requirement is that there are long-
| established sites on the Internet with mail archives that go | established sites on the Internet with mail archives that go
| back decades, archives with messages containing these elements. | back decades, archives with messages containing these elements.
| Similarly, many people have decades-old messages in their | Similarly, many people have decades-old messages in their
| personal message stores, and for various reasons it is | personal message stores, and for various reasons it is
| occasionally useful to not only read such messages but also | occasionally useful to not only read such messages but also
| resend or forward them to others. While these archives may | resend or forward them to others. While these archives may
| only be mined occasionally, and messages from these personal | only be mined occasionally, and messages from these personal
| messages rarely resent, they are nonetheless still in use, | stores rarely resent, they are nonetheless still in use, making
| making "obsolete" the incorrect term to describe these | "obsolete" the incorrect term to describe these elements.
| elements.
| |
| Later efforts to revise this specification contemplated | Later efforts to revise this specification contemplated
| changing the term to "legacy" or something that would more | changing the term to "legacy" or something that would more
| accurately describe the elements, but such a change was | accurately describe the elements, but such a change was
| rejected due to fears that it would result in unnecessary | rejected due to fears that it would result in unnecessary
| confusion, especially among long-time users and implementers of | confusion, especially among long-time users and implementers of
| the specification. | 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.
skipping to change at page 8, line 37 skipping to change at page 8, line 37
specification (and that of [I-D.ietf-emailcore-rfc5321bis] if they specification (and that of [I-D.ietf-emailcore-rfc5321bis] if they
actually cause information to be lost). Again, even though this actually cause information to be lost). Again, even though this
limitation is put on messages, it is incumbent upon implementations limitation is put on messages, it is incumbent upon implementations
that display messages to handle an arbitrarily large number of that display messages to handle an arbitrarily large number of
characters in a line (certainly at least up to the 998 character characters in a line (certainly at least up to the 998 character
limit) for the sake 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 (":", ASCII value 58), followed by a field body, and terminated
field name MUST be composed of visible US-ASCII characters (i.e., by CRLF. A field name MUST be composed of printable US-ASCII
characters that have values between 33 and 126, inclusive), except characters except for space (SP, ASCII value 32) (i.e., characters
colon. A field body may be composed of visible US-ASCII characters that have values between 33 and 126, inclusive) excluding colon. A
as well as the space (SP, ASCII value 32) and horizontal tab (HTAB, field body may be composed of printable US-ASCII characters,
ASCII value 9) characters (together known as the white space including the space character, plus the horizontal tab (HTAB, ASCII
characters, WSP). A field body MUST NOT include CR and LF except value 9) character. (Together, SP and HTAB are known as the white
when used in "folding" and "unfolding", as described in section space characters, WSP). A field body MUST NOT include CR and LF
2.2.3. All field bodies MUST conform to the syntax described in except when used in "folding" and "unfolding", as described in
sections 3 and 4 of this specification. section 2.2.3. All field bodies MUST conform to the syntax described
in sections 3 and 4 of this specification.
2.2.1. Unstructured Header Field Bodies 2.2.1. Unstructured Header Field Bodies
Some field bodies in this specification are defined simply as Some field bodies in this specification are defined simply as
"unstructured" (which is specified in section 3.2.5 as any visible "unstructured" (which is specified in section 3.2.5 as any printable
US-ASCII characters plus white space characters) with no further US-ASCII characters, including the space character, plus the
restrictions. These are referred to as unstructured field bodies. horizontal tab character) with no further restrictions. These are
Semantically, unstructured field bodies are simply to be treated as a referred to as unstructured field bodies. Semantically, unstructured
single line of characters with no further processing (except for field bodies are simply to be treated as a single line of characters
"folding" and "unfolding" as described in section 2.2.3). with no further processing (except for "folding" and "unfolding" as
described in section 2.2.3).
2.2.2. Structured Header Field Bodies 2.2.2. Structured Header Field Bodies
Some field bodies in this specification have a syntax that is more Some field bodies in this specification have a syntax that is more
restrictive than the unstructured field bodies described above. restrictive than the unstructured field bodies described above.
These are referred to as "structured" field bodies. Structured field These are referred to as "structured" field bodies. Structured field
bodies are sequences of specific lexical tokens as described in bodies are sequences of specific lexical tokens as described in
sections 3 and 4 of this specification. Many of these tokens are sections 3 and 4 of this specification. Many of these tokens are
allowed (according to their syntax) to be introduced or end with allowed (according to their syntax) to be introduced or end with
comments (as described in section 3.2.2) as well as the white space comments (as described in section 3.2.2) as well as the white space
skipping to change at page 12, line 26 skipping to change at page 12, line 26
section 3.2.4. Comments may nest. section 3.2.4. Comments may nest.
There are several places in this specification where comments and FWS There are several places in this specification where comments and FWS
may be freely inserted. To accommodate that syntax, an additional may be freely inserted. To accommodate that syntax, an additional
token for "CFWS" is defined for places where comments and/or FWS can token for "CFWS" is defined for places where comments and/or FWS can
occur. However, where CFWS occurs in this specification, it MUST NOT occur. However, where CFWS occurs in this specification, it MUST NOT
be inserted in such a way that any line of a folded header field is be inserted in such a way that any line of a folded header field is
made up entirely of WSP characters and nothing else. made up entirely of WSP characters and nothing else.
FWS = ([*WSP CRLF] 1*WSP) / obs-FWS FWS = ([*WSP CRLF] 1*WSP) / obs-FWS
; Folding white space ; Folding white space
ctext = %d33-39 / ; Visible US-ASCII ctext = %d33-39 / ; VCHAR characters not including
%d42-91 / ; characters not including %d42-91 / ; "(", ")", or "\"
%d93-126 / ; "(", ")", or "\" %d93-126 /
obs-ctext obs-ctext
ccontent = ctext / quoted-pair / comment ccontent = ctext / quoted-pair / comment
comment = "(" *([FWS] ccontent) [FWS] ")" comment = "(" *([FWS] ccontent) [FWS] ")"
CFWS = (1*([FWS] comment) [FWS]) / FWS CFWS = (1*([FWS] comment) [FWS]) / FWS
Throughout this specification, where FWS (the folding white space Throughout this specification, where FWS (the folding white space
token) appears, it indicates a place where folding, as discussed in token) appears, it indicates a place where folding, as discussed in
skipping to change at page 13, line 25 skipping to change at page 13, line 25
Several productions in structured header field bodies are simply Several productions in structured header field bodies are simply
strings of certain basic characters. Such productions are called strings of certain basic characters. Such productions are called
atoms. atoms.
Some of the structured header field bodies also allow the period Some of the structured header field bodies also allow the period
character (".", ASCII value 46) within runs of atext. An additional character (".", ASCII value 46) within runs of atext. An additional
"dot-atom" token is defined for those purposes. "dot-atom" token is defined for those purposes.
| Note: The "specials" token does not appear anywhere else in | Note: The "specials" token does not appear anywhere else in
| this specification. It is simply the visible (i.e., non- | this specification. It is simply the VCHAR characters that do
| control, non-white space) characters that do not appear in | not appear in atext. It is provided only because it is useful
| atext. It is provided only because it is useful for | for implementers who use tools that lexically analyze messages.
| implementers who use tools that lexically analyze messages.
| Each of the characters in specials can be used to indicate a | Each of the characters in specials can be used to indicate a
| tokenization point in lexical analysis. | tokenization point in lexical analysis.
atext = ALPHA / DIGIT / ; Visible US-ASCII atext = ALPHA / DIGIT / ; VCHAR characters not including
"!" / "#" / ; characters not including "!" / "#" / ; specials. Used for atoms.
"$" / "%" / ; specials. Used for atoms. "$" / "%" /
"&" / "'" / "&" / "'" /
"*" / "+" / "*" / "+" /
"-" / "/" / "-" / "/" /
"=" / "?" / "=" / "?" /
"^" / "_" / "^" / "_" /
"`" / "{" / "`" / "{" /
"|" / "}" / "|" / "}" /
"~" "~"
atom = [CFWS] 1*atext [CFWS] atom = [CFWS] 1*atext [CFWS]
dot-atom-text = 1*atext *("." 1*atext) dot-atom-text = 1*atext *("." 1*atext)
dot-atom = [CFWS] dot-atom-text [CFWS] dot-atom = [CFWS] dot-atom-text [CFWS]
specials = "(" / ")" / ; Special characters that do specials = "(" / ")" / ; Special characters that do
"<" / ">" / ; not appear in atext "<" / ">" / ; not appear in atext
"[" / "]" / "[" / "]" /
":" / ";" / ":" / ";" /
"@" / "\" / "@" / "\" /
"," / "." / "," / "." /
DQUOTE DQUOTE
Both atom and dot-atom are interpreted as a single unit, comprising Both atom and dot-atom are interpreted as a single unit, comprising
the string of characters that make it up. Semantically, the optional the string of characters that make it up. Semantically, the optional
comments and FWS surrounding the rest of the characters are not part comments and FWS surrounding the rest of the characters are not part
of the atom; the atom is only the run of atext characters in an atom, of the atom; the atom is only the run of atext characters in an atom,
or the atext and "." characters in a dot-atom. or the atext and "." characters in a dot-atom.
3.2.4. Quoted Strings 3.2.4. Quoted Strings
Strings of characters that include characters other than those Strings of characters that include characters other than those
allowed in atoms can be represented in a quoted string format, where allowed in atoms can be represented in a quoted string format, where
the characters are surrounded by quote (DQUOTE, ASCII value 34) the characters are surrounded by quote (DQUOTE, ASCII value 34)
characters. characters.
qtext = %d33 / ; Visible US-ASCII qtext = %d33 / ; VCHAR characters not including
%d35-91 / ; characters not including %d35-91 / ; "\" or the quote character
%d93-126 / ; "\" or the quote character %d93-126 /
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]
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
skipping to change at page 19, line 20 skipping to change at page 19, line 20
| syntax of 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 / ; VCHAR characters not including
%d94-126 / ; characters not including %d94-126 / ; "[", "]", or "\"
obs-dtext ; "[", "]", or "\" obs-dtext
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.ietf-emailcore-rfc5321bis]. These mechanisms documents, such as [I-D.ietf-emailcore-rfc5321bis]. These mechanisms
are outside of the scope of this document. are outside of the scope of this document.
skipping to change at page 20, line 10 skipping to change at page 20, line 10
In a message body, though all of the characters listed in the text In a message body, though all of the characters listed in the text
rule MAY be used, the use of US-ASCII control characters (values 1 rule MAY be used, the use of US-ASCII control characters (values 1
through 8, 11, 12, and 14 through 31) is discouraged since their through 8, 11, 12, and 14 through 31) is discouraged since their
interpretation by receivers for display is not guaranteed. interpretation by receivers for display is not guaranteed.
message = (fields / obs-fields) message = (fields / obs-fields)
[CRLF body] [CRLF body]
body = (*(*998text CRLF) *998text) / obs-body body = (*(*998text CRLF) *998text) / obs-body
text = %d1-9 / ; Characters excluding CR text = %d1-9 / ; Characters excluding CR
%d11 / ; and LF %d11 / ; and LF
%d12 / %d12 /
%d14-127 %d14-127
The header fields carry most of the semantic information and are The header fields carry most of the semantic information and are
defined in section 3.6. The body is simply a series of lines of text defined in section 3.6. The body is simply a series of lines of text
that are uninterpreted for the purposes of this specification. that are uninterpreted for the purposes of this specification.
3.6. Field Definitions 3.6. Field Definitions
The header fields of a message are defined here. All header fields The header fields of a message are defined here. All header fields
skipping to change at page 21, 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 21, line 28 skipping to change at page 21, 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)
// Should there be a 1 in front of the resent fields as per erratum
// 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 33, line 15 skipping to change at page 32, line 15
[I-D.ietf-emailcore-rfc5321bis]; other specifications describe the [I-D.ietf-emailcore-rfc5321bis]; other specifications describe the
use of other fields that are to be interpreted as trace fields. For use of other fields that are to be interpreted as trace fields. For
the purposes of this specification, the trace fields are strictly the purposes of this specification, the trace fields are strictly
informational, and any formal interpretation of them is outside of informational, and any formal interpretation of them is outside of
the scope of this document. 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 VCHAR characters except colon,
except colon, followed by a colon, followed by any text that conforms followed by a colon, followed by any text that conforms to the
to the unstructured syntax. 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 ; Limit to 77 characters to field-name = 1*ftext ; Limit to 77 characters to
; stay within 78 char-per- ; stay within 78 char-per-
; line recommendation ; line recommendation
ftext = %d33-57 / ; Visible US-ASCII ftext = %d33-57 / ; VCHAR characters not including
%d59-126 ; characters not including %d59-126 ; ":".
; ":".
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
skipping to change at page 35, line 9 skipping to change at page 34, line 8
| phrase is not a form that was allowed in earlier versions of | phrase is not a form that was allowed in earlier versions of
| this or any other specification. Period (nor any other | this or any other specification. Period (nor any other
| character from specials) was not allowed in phrase because it | character from specials) was not allowed in phrase because it
| introduced a parsing difficulty distinguishing between phrases | introduced a parsing difficulty distinguishing between phrases
| and portions of an addr-spec (see section 4.4). It appears | and portions of an addr-spec (see section 4.4). It appears
| here because the period character is currently used in many | here because the period character is currently used in many
| messages in the display-name portion of addresses, especially | messages in the display-name portion of addresses, especially
| for initials in names, and therefore must be interpreted | for initials in names, and therefore must be interpreted
| properly. | properly.
obs-NO-WS-CTL = %d1-8 / ; US-ASCII control obs-NO-WS-CTL = %d1-8 / ; US-ASCII control
%d11 / ; characters that do not %d11 / ; characters that do not
%d12 / ; include the carriage %d12 / ; include the carriage
%d14-31 / ; return, line feed, and %d14-31 / ; return, line feed, and
%d127 ; white space characters %d127 ; white space characters
obs-ctext = obs-NO-WS-CTL obs-ctext = obs-NO-WS-CTL
obs-qtext = obs-NO-WS-CTL obs-qtext = obs-NO-WS-CTL
obs-utext = %d0 / obs-NO-WS-CTL / VCHAR obs-utext = %d0 / obs-NO-WS-CTL / VCHAR
obs-qp = "\" (%d0 / obs-NO-WS-CTL / LF / CR) obs-qp = "\" (%d0 / obs-NO-WS-CTL / LF / CR)
obs-body = *(%d0 / LF / CR / text) obs-body = *(%d0 / LF / CR / text)
skipping to change at page 36, line 24 skipping to change at page 35, line 17
obs-day = [CFWS] 1*2DIGIT [CFWS] obs-day = [CFWS] 1*2DIGIT [CFWS]
obs-year = [CFWS] 2*DIGIT [CFWS] obs-year = [CFWS] 2*DIGIT [CFWS]
obs-hour = [CFWS] 2DIGIT [CFWS] obs-hour = [CFWS] 2DIGIT [CFWS]
obs-minute = [CFWS] 2DIGIT [CFWS] obs-minute = [CFWS] 2DIGIT [CFWS]
obs-second = [CFWS] 2DIGIT [CFWS] obs-second = [CFWS] 2DIGIT [CFWS]
obs-zone = "UT" / "GMT" / ; Universal Time obs-zone = "UT" / "GMT" / ; Universal Time
; North American UT ; North American UT
; offsets ; offsets
"EST" / "EDT" / ; Eastern: - 5/ - 4 "EST" / "EDT" / ; Eastern: - 5/ - 4
"CST" / "CDT" / ; Central: - 6/ - 5 "CST" / "CDT" / ; Central: - 6/ - 5
"MST" / "MDT" / ; Mountain: - 7/ - 6 "MST" / "MDT" / ; Mountain: - 7/ - 6
"PST" / "PDT" / ; Pacific: - 8/ - 7 "PST" / "PDT" / ; Pacific: - 8/ - 7
; ;
%d65-73 / ; Military zones - "A" %d65-73 / ; Military zones - "A"
%d75-90 / ; through "I" and "K" %d75-90 / ; through "I" and "K"
%d97-105 / ; through "Z", both %d97-105 / ; through "Z", both
%d107-122 ; upper and lower case %d107-122 ; upper and lower case
Where a two or three digit year occurs in a date, the year is to be Where a two or three digit year occurs in a date, the year is to be
interpreted as follows: If a two digit year is encountered whose interpreted as follows: If a two digit year is encountered whose
value is between 00 and 49, the year is interpreted by adding 2000, value is between 00 and 49, the year is interpreted by adding 2000,
ending up with a value between 2000 and 2049. If a two digit year is ending up with a value between 2000 and 2049. If a two digit year is
encountered with a value between 50 and 99, or any three digit year encountered with a value between 50 and 99, or any three digit year
is encountered, the year is interpreted by adding 1900. is encountered, the year is interpreted by adding 1900.
In the obsolete time zone, "UT" and "GMT" are indications of In the obsolete time zone, "UT" and "GMT" are indications of
"Universal Time" and "Greenwich Mean Time", respectively, and are "Universal Time" and "Greenwich Mean Time", respectively, and are
skipping to change at page 43, line 7 skipping to change at page 42, line 7
separate copy of the message. If the "Bcc:" field contains all of separate copy of the message. If the "Bcc:" field contains all of
the blind addressees, all of the "Bcc:" recipients will be seen by the blind addressees, all of the "Bcc:" recipients will be seen by
each "Bcc:" recipient. Even if a separate message is sent to each each "Bcc:" recipient. Even if a separate message is sent to each
"Bcc:" recipient with only the individual's address, implementations "Bcc:" recipient with only the individual's address, implementations
still need to be careful to process replies to the message as per still need to be careful to process replies to the message as per
section 3.6.3 so as not to accidentally reveal the blind recipient to section 3.6.3 so as not to accidentally reveal the blind recipient to
other recipients. other recipients.
6. IANA Considerations 6. IANA Considerations
This document updates the registrations that appeared in [RFC4021] This document updates the registrations that first appeared in
that referred to the definitions in [RFC2822]. IANA is requested to [RFC4021] and were subsequently updated by [RFC5322]. IANA is
update the Permanent Message Header Field Repository with the requested to update the Permanent Message Header Field Repository
following header fields, in accordance with the procedures set out in with the following header fields, in accordance with the procedures
[RFC3864]. set out in [RFC3864].
Header field name Date Header field name Date
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.1) Specification document(s) This document (section 3.6.1)
Header field name From Header field name From
Applicable protocol Mail Applicable protocol Mail
Status standard Status standard
skipping to change at page 54, line 38 skipping to change at page 53, line 38
Appendix B. Differences from Earlier Specifications Appendix B. Differences from Earlier Specifications
This appendix contains a list of changes that have been made in the This appendix contains a list of changes that have been made in the
Internet Message Format from earlier specifications, specifically Internet Message Format from earlier specifications, specifically
[RFC0822], [RFC1123], [RFC2822], and [RFC5322]. Items marked with an [RFC0822], [RFC1123], [RFC2822], and [RFC5322]. Items marked with an
asterisk (*) below are items which appear in section 4 of this asterisk (*) below are items which appear in section 4 of this
document and therefore can no longer be generated. document and therefore can no longer be generated.
The following are the changes made from [RFC0822] and [RFC1123] to The following are the changes made from [RFC0822] and [RFC1123] to
[RFC2822] that remain in this document: [RFC2822]t:
1. Period allowed in obsolete form of phrase. 1. Period allowed in obsolete form of phrase.
2. ABNF moved out of document, now in [STD68]. 2. ABNF moved out of document, now in [STD68].
3. Four or more digits allowed for year. 3. Four or more digits allowed for year.
4. Header field ordering (and lack thereof) made explicit. 4. Header field ordering (and lack thereof) made explicit.
5. Encrypted header field removed. 5. Encrypted header field removed.
6. Specifically allow and give meaning to "-0000" time zone. 6. Specifically allow and give meaning to "-0000" time zone.
7. Folding white space is not allowed between every token. 7. Folding white space is not allowed between every token.
8. Requirement for destinations removed. 8. Requirement for destinations removed.
9. Forwarding and resending redefined. 9. Forwarding and resending redefined.
skipping to change at page 55, line 21 skipping to change at page 54, line 21
21. Comments between field name and colon not allowed. 21. Comments between field name and colon not allowed.
22. Tightened syntax of in-reply-to and references.* 22. Tightened syntax of in-reply-to and references.*
23. CFWS within msg-id not allowed.* 23. CFWS within msg-id not allowed.*
24. Tightened semantics of resent fields as informational only. 24. Tightened semantics of resent fields as informational only.
25. Resent-Reply-To not allowed.* 25. Resent-Reply-To not allowed.*
26. No multiple occurrences of fields (except resent and received).* 26. No multiple occurrences of fields (except resent and received).*
27. Free CR and LF not allowed.* 27. Free CR and LF not allowed.*
28. Line length limits specified. 28. Line length limits specified.
29. Bcc more clearly specified. 29. Bcc more clearly specified.
The following are changes from [RFC2822]. The following are changes from [RFC2822] to [RFC5322]:
1. Assorted typographical/grammatical errors fixed and 1. Assorted typographical/grammatical errors fixed and
clarifications made. clarifications made.
2. Changed "standard" to "document" or "specification" throughout. 2. Changed "standard" to "document" or "specification" throughout.
3. Made distinction between "header field" and "header section". 3. Made distinction between "header field" and "header section".
4. Removed NO-WS-CTL from ctext, qtext, dtext, and unstructured.* 4. Removed NO-WS-CTL from ctext, qtext, dtext, and unstructured.*
5. Moved discussion of specials to the "Atom" section. Moved text 5. Moved discussion of specials to the "Atom" section. Moved text
to "Overall message syntax" section. to "Overall message syntax" section.
6. Simplified CFWS syntax. 6. Simplified CFWS syntax.
7. Fixed unstructured syntax (erratum 373 (https://www.rfc- 7. Fixed unstructured syntax (erratum 373 (https://www.rfc-
skipping to change at page 56, line 29 skipping to change at page 55, line 29
5. Fixed comments within addresses in A.5 (errata 2515 5. Fixed comments within addresses in A.5 (errata 2515
(https://www.rfc-editor.org/errata/eid2515) and 2579 (https://www.rfc-editor.org/errata/eid2515) and 2579
(https://www.rfc-editor.org/errata/eid2579)). (https://www.rfc-editor.org/errata/eid2579)).
6. Fixed time zone description (erratum 2726 (https://www.rfc- 6. Fixed time zone description (erratum 2726 (https://www.rfc-
editor.org/errata/eid2726)). editor.org/errata/eid2726)).
7. Removed inappropriate uses of "sent" in 3.6.3, 3.6.6, and 5 7. Removed inappropriate uses of "sent" in 3.6.3, 3.6.6, and 5
(erratum 3048 (https://www.rfc-editor.org/errata/eid3048)). (erratum 3048 (https://www.rfc-editor.org/errata/eid3048)).
8. Allow for CFWS in otherwise empty list of "Received:" field 8. Allow for CFWS in otherwise empty list of "Received:" field
tokens (erratum 3979 (https://www.rfc-editor.org/errata/ tokens (erratum 3979 (https://www.rfc-editor.org/errata/
eid3979)). eid3979)).
9. Changed "printable" to "visible" to clarify that it doesn't 9. Clarified that "printable" includes space, and replaced
include the space character (erratum 4692 (https://www.rfc- "printable" with "VCHAR" in ABNF comments to clarify that it
editor.org/errata/eid4692)). doesn't include the space character (erratum 4692
(https://www.rfc-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 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-
 End of changes. 30 change blocks. 
127 lines changed or deleted 124 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/