< draft-resnick-2822upd-05.txt   draft-resnick-2822upd-06.txt >
Network Working Group P. Resnick, Ed. Network Working Group P. Resnick, Ed.
Internet-Draft Qualcomm Incorporated Internet-Draft Qualcomm Incorporated
Obsoletes: 2822 (if approved) January 28, 2008 Obsoletes: 2822 (if approved) February 7, 2008
Updates: 4021 (if approved) Updates: 4021 (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: July 31, 2008 Expires: August 10, 2008
Internet Message Format Internet Message Format
draft-resnick-2822upd-05 draft-resnick-2822upd-06
Status of This Memo Status of This Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 31, 2008. This Internet-Draft will expire on August 10, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
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
skipping to change at page 2, line 47 skipping to change at page 2, line 47
3.4. Address Specification . . . . . . . . . . . . . . . . . . 16 3.4. Address Specification . . . . . . . . . . . . . . . . . . 16
3.4.1. Addr-spec specification . . . . . . . . . . . . . . . 17 3.4.1. Addr-spec specification . . . . . . . . . . . . . . . 17
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 . . . . . . . . . . . . . . . . 24 3.6.4. Identification fields . . . . . . . . . . . . . . . . 24
3.6.5. Informational fields . . . . . . . . . . . . . . . . . 27 3.6.5. Informational fields . . . . . . . . . . . . . . . . . 27
3.6.6. Resent fields . . . . . . . . . . . . . . . . . . . . 28 3.6.6. Resent fields . . . . . . . . . . . . . . . . . . . . 28
3.6.7. Trace fields . . . . . . . . . . . . . . . . . . . . . 30 3.6.7. Trace fields . . . . . . . . . . . . . . . . . . . . . 29
3.6.8. Optional fields . . . . . . . . . . . . . . . . . . . 30 3.6.8. Optional fields . . . . . . . . . . . . . . . . . . . 30
4. Obsolete Syntax . . . . . . . . . . . . . . . . . . . . . . . 31 4. Obsolete Syntax . . . . . . . . . . . . . . . . . . . . . . . 30
4.1. Miscellaneous obsolete tokens . . . . . . . . . . . . . . 32 4.1. Miscellaneous obsolete tokens . . . . . . . . . . . . . . 31
4.2. Obsolete folding white space . . . . . . . . . . . . . . . 33 4.2. Obsolete folding white space . . . . . . . . . . . . . . . 32
4.3. Obsolete Date and Time . . . . . . . . . . . . . . . . . . 33 4.3. Obsolete Date and Time . . . . . . . . . . . . . . . . . . 33
4.4. Obsolete Addressing . . . . . . . . . . . . . . . . . . . 34 4.4. Obsolete Addressing . . . . . . . . . . . . . . . . . . . 34
4.5. Obsolete header fields . . . . . . . . . . . . . . . . . . 35 4.5. Obsolete header fields . . . . . . . . . . . . . . . . . . 35
4.5.1. Obsolete origination date field . . . . . . . . . . . 36 4.5.1. Obsolete origination date field . . . . . . . . . . . 36
4.5.2. Obsolete originator fields . . . . . . . . . . . . . . 36 4.5.2. Obsolete originator fields . . . . . . . . . . . . . . 36
4.5.3. Obsolete destination address fields . . . . . . . . . 37 4.5.3. Obsolete destination address fields . . . . . . . . . 37
4.5.4. Obsolete identification fields . . . . . . . . . . . . 37 4.5.4. Obsolete identification fields . . . . . . . . . . . . 37
4.5.5. Obsolete informational fields . . . . . . . . . . . . 37 4.5.5. Obsolete informational fields . . . . . . . . . . . . 37
4.5.6. Obsolete resent fields . . . . . . . . . . . . . . . . 38 4.5.6. Obsolete resent fields . . . . . . . . . . . . . . . . 37
4.5.7. Obsolete trace fields . . . . . . . . . . . . . . . . 38 4.5.7. Obsolete trace fields . . . . . . . . . . . . . . . . 38
4.5.8. Obsolete optional fields . . . . . . . . . . . . . . . 38 4.5.8. Obsolete optional fields . . . . . . . . . . . . . . . 38
5. Security Considerations . . . . . . . . . . . . . . . . . . . 38 5. Security Considerations . . . . . . . . . . . . . . . . . . . 38
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
Appendix A. Example messages . . . . . . . . . . . . . . . . . 43 Appendix A. Example messages . . . . . . . . . . . . . . . . . 42
Appendix A.1. Addressing examples . . . . . . . . . . . . . . . 43 Appendix A.1. Addressing examples . . . . . . . . . . . . . . . 43
Appendix A.1.1. A message from one person to another with Appendix A.1.1. A message from one person to another with
simple addressing . . . . . . . . . . . . . . . . 43 simple addressing . . . . . . . . . . . . . . . . 43
Appendix A.1.2. Different types of mailboxes . . . . . . . . . . . 44 Appendix A.1.2. Different types of mailboxes . . . . . . . . . . . 44
Appendix A.1.3. Group addresses . . . . . . . . . . . . . . . . . 45 Appendix A.1.3. Group addresses . . . . . . . . . . . . . . . . . 44
Appendix A.2. Reply messages . . . . . . . . . . . . . . . . . . 45 Appendix A.2. Reply messages . . . . . . . . . . . . . . . . . . 44
Appendix A.3. Resent messages . . . . . . . . . . . . . . . . . 46 Appendix A.3. Resent messages . . . . . . . . . . . . . . . . . 45
Appendix A.4. Messages with trace fields . . . . . . . . . . . . 48 Appendix A.4. Messages with trace fields . . . . . . . . . . . . 46
Appendix A.5. White space, comments, and other oddities . . . . 49 Appendix A.5. White space, comments, and other oddities . . . . 47
Appendix A.6. Obsoleted forms . . . . . . . . . . . . . . . . . 49 Appendix A.6. Obsoleted forms . . . . . . . . . . . . . . . . . 47
Appendix A.6.1. Obsolete addressing . . . . . . . . . . . . . . . 50 Appendix A.6.1. Obsolete addressing . . . . . . . . . . . . . . . 48
Appendix A.6.2. Obsolete dates . . . . . . . . . . . . . . . . . . 50 Appendix A.6.2. Obsolete dates . . . . . . . . . . . . . . . . . . 48
Appendix A.6.3. Obsolete white space and comments . . . . . . . . 51 Appendix A.6.3. Obsolete white space and comments . . . . . . . . 48
Appendix B. Differences from earlier specifications . . . . . 51 Appendix B. Differences from earlier specifications . . . . . 49
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . 53 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . 50
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52
7.1. Normative References . . . . . . . . . . . . . . . . . . . 54 7.1. Normative References . . . . . . . . . . . . . . . . . . . 52
7.2. Informative References . . . . . . . . . . . . . . . . . . 55 7.2. Informative References . . . . . . . . . . . . . . . . . . 52
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 [RFC2822], which itself superseded [RFC0822], updating it update to [RFC2822], which itself superseded [RFC0822], updating it
to reflect current practice and incorporating incremental changes to reflect current practice and incorporating incremental changes
skipping to change at page 5, line 19 skipping to change at page 5, line 19
This document occasionally uses terms that appear in capital letters. This document occasionally uses terms that appear in capital letters.
When the terms "MUST", "SHOULD", "RECOMMENDED", "MUST NOT", "SHOULD When the terms "MUST", "SHOULD", "RECOMMENDED", "MUST NOT", "SHOULD
NOT", and "MAY" appear capitalized, they are being used to indicate NOT", and "MAY" appear capitalized, they are being used to indicate
particular requirements of this specification. A discussion of the particular requirements of this specification. A discussion of the
meanings of these terms appears in [RFC2119]. meanings of these terms appears in [RFC2119].
1.2.2. Syntactic notation 1.2.2. Syntactic notation
This specification uses the Augmented Backus-Naur Form (ABNF) This specification uses the Augmented Backus-Naur Form (ABNF)
[I-D.crocker-rfc4234bis] notation for the formal definitions of the [RFC5234] notation for the formal definitions of the syntax of
syntax of messages. Characters will be specified either by a decimal messages. Characters will be specified either by a decimal value
value (e.g., the value %d65 for uppercase A and %d97 for lowercase A) (e.g., the value %d65 for uppercase A and %d97 for lowercase A) or by
or by a case-insensitive literal value enclosed in quotation marks a case-insensitive literal value enclosed in quotation marks (e.g.,
(e.g., "A" for either uppercase or lowercase A). "A" for either uppercase or lowercase A).
1.2.3. Structure of this document 1.2.3. Structure of this document
This document is divided into several sections. This document is divided into several sections.
This section, section 1, is a short introduction to the document. This section, section 1, is a short introduction to the document.
Section 2 lays out the general description of a message and its Section 2 lays out the general description of a message and its
constituent parts. This is an overview to help the reader understand constituent parts. This is an overview to help the reader understand
some of the general principles used in the later portions of this some of the general principles used in the later portions of this
skipping to change at page 10, line 11 skipping to change at page 10, line 11
The syntax as given in this section defines the legal syntax of The syntax as given in this section defines the legal syntax of
Internet messages. Messages that are conformant to this Internet messages. Messages that are conformant to this
specification MUST conform to the syntax in this section. If there specification MUST conform to the syntax in this section. If there
are options in this section where one option SHOULD be generated, are options in this section where one option SHOULD be generated,
that is indicated either in the prose or in a comment next to the that is indicated either in the prose or in a comment next to the
syntax. syntax.
For the defined expressions, a short description of the syntax and For the defined expressions, a short description of the syntax and
use is given, followed by the syntax in ABNF, followed by a semantic use is given, followed by the syntax in ABNF, followed by a semantic
analysis. Primitive tokens that are used but otherwise unspecified analysis. The following primitive tokens that are used but otherwise
are taken from the "Core Rules" of [I-D.crocker-rfc4234bis], Appendix unspecified are taken from the "Core Rules" of [RFC5234], Appendix
B.1. B.1: CR, LF, CRLF, HTAB, SP, WSP, DQUOTE, DIGIT, ALPHA, and VCHAR.
In some of the definitions, there will be non-terminals whose names In some of the definitions, there will be non-terminals whose names
start with "obs-". These "obs-" elements refer to tokens defined in start with "obs-". These "obs-" elements refer to tokens defined in
the obsolete syntax in section 4. In all cases, these productions the obsolete syntax in section 4. In all cases, these productions
are to be ignored for the purposes of generating legal Internet are to be ignored for the purposes of generating legal Internet
messages and MUST NOT be used as part of such a message. However, messages and MUST NOT be used as part of such a message. However,
when interpreting messages, these tokens MUST be honored as part of when interpreting messages, these tokens MUST be honored as part of
the legal syntax. In this sense, section 3 defines a grammar for the the legal syntax. In this sense, section 3 defines a grammar for the
generation of messages, with "obs-" elements that are to be ignored, generation of messages, with "obs-" elements that are to be ignored,
while section 4 adds grammar for the interpretation of messages. while section 4 adds grammar for the interpretation of messages.
skipping to change at page 11, line 52 skipping to change at page 11, line 52
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
section 2.2.3, may take place. Wherever folding appears in a message section 2.2.3, may take place. Wherever folding appears in a message
(that is, a header field body containing a CRLF followed by any WSP), (that is, a header field body containing a CRLF followed by any WSP),
unfolding (removal of the CRLF) is performed before any further unfolding (removal of the CRLF) is performed before any further
semantic analysis is performed on that header field according to this semantic analysis is performed on that header field according to this
specification. That is to say, any CRLF that appears in FWS is specification. That is to say, any CRLF that appears in FWS is
semantically "invisible." semantically "invisible".
A comment is normally used in a structured field body to provide some A comment is normally used in a structured field body to provide some
human readable informational text. Since a comment is allowed to human readable informational text. Since a comment is allowed to
contain FWS, folding is permitted within the comment. Also note that contain FWS, folding is permitted within the comment. Also note that
since quoted-pair is allowed in a comment, the parentheses and since quoted-pair is allowed in a comment, the parentheses and
backslash characters may appear in a comment so long as they appear backslash characters may appear in a comment so long as they appear
as a quoted-pair. Semantically, the enclosing parentheses are not as a quoted-pair. Semantically, the enclosing parentheses are not
part of the comment; the comment is what is contained between the two part of the comment; the comment is what is contained between the two
parentheses. As stated earlier, the "\" in any quoted-pair and the parentheses. As stated earlier, the "\" in any quoted-pair and the
CRLF in any FWS that appears within the comment are semantically CRLF in any FWS that appears within the comment are semantically
"invisible" and therefore not part of the comment either. "invisible" and therefore not part of the comment either.
skipping to change at page 16, line 13 skipping to change at page 16, line 13
used to indicate that the time was generated on a system that may be used to indicate that the time was generated on a system that may be
in a local time zone other than Universal Time and that the date-time in a local time zone other than Universal Time and that the date-time
contains no information about the local time zone. contains no information about the local time zone.
A date-time specification MUST be semantically valid. That is, the A date-time specification MUST be semantically valid. That is, the
day-of-week (if included) MUST be the day implied by the date, the day-of-week (if included) MUST be the day implied by the date, the
numeric day-of-month MUST be between 1 and the number of days allowed numeric day-of-month MUST be between 1 and the number of days allowed
for the specified month (in the specified year), the time-of-day MUST for the specified month (in the specified year), the time-of-day MUST
be in the range 00:00:00 through 23:59:60 (the number of seconds be in the range 00:00:00 through 23:59:60 (the number of seconds
allowing for a leap second; see [RFC1305]), and the last two digits allowing for a leap second; see [RFC1305]), and the last two digits
of zone MUST be within the range 00 through 59. of the zone MUST be within the range 00 through 59.
3.4. Address Specification 3.4. Address Specification
Addresses occur in several message header fields to indicate senders Addresses occur in several message header fields to indicate senders
and recipients of messages. An address may either be an individual and recipients of messages. An address may either be an individual
mailbox, or a group of mailboxes. mailbox, or a group of mailboxes.
address = mailbox / group address = mailbox / group
mailbox = name-addr / addr-spec mailbox = name-addr / addr-spec
skipping to change at page 21, line 52 skipping to change at page 22, line 5
| | | | replies - see 3.6.4 | | | | | replies - see 3.6.4 |
| subject | 0 | 1 | | | subject | 0 | 1 | |
| comments | 0 | unlimited | | | comments | 0 | unlimited | |
| keywords | 0 | unlimited | | | keywords | 0 | unlimited | |
| optional-field | 0 | unlimited | | | optional-field | 0 | unlimited | |
+----------------+--------+------------+----------------------------+ +----------------+--------+------------+----------------------------+
The exact interpretation of each field is described in subsequent The exact interpretation of each field is described in subsequent
sections. sections.
Table 1
3.6.1. The origination date field 3.6.1. The origination date field
The origination date field consists of the field name "Date" followed The origination date field consists of the field name "Date" followed
by a date-time specification. by a date-time specification.
orig-date = "Date:" date-time CRLF orig-date = "Date:" date-time CRLF
The origination date specifies the date and time at which the creator The origination date specifies the date and time at which the creator
of the message indicated that the message was complete and ready to of the message indicated that the message was complete and ready to
enter the mail delivery system. For instance, this might be the time enter the mail delivery system. For instance, this might be the time
skipping to change at page 24, line 50 skipping to change at page 24, line 50
Note: Some mail applications have automatic reply commands that Note: Some mail applications have automatic reply commands that
include the destination addresses of the original message in the include the destination addresses of the original message in the
destination addresses of the reply. How those reply commands destination addresses of the reply. How those reply commands
behave is implementation dependent and is beyond the scope of this behave is implementation dependent and is beyond the scope of this
document. In particular, whether or not to include the original document. In particular, whether or not to include the original
destination addresses when the original message had a "Reply-To:" destination addresses when the original message had a "Reply-To:"
field is not addressed here. field is not addressed here.
3.6.4. Identification fields 3.6.4. Identification fields
Though listed as optional in the table (Table 1) in section 3.6, Though listed as optional in the table in section 3.6, every message
every message SHOULD have a "Message-ID:" field. Furthermore, reply SHOULD have a "Message-ID:" field. Furthermore, reply messages
messages SHOULD have "In-Reply-To:" and "References:" fields as SHOULD have "In-Reply-To:" and "References:" fields as appropriate
appropriate and as described below. and as described below.
The "Message-ID:" field contains a single unique message identifier. The "Message-ID:" field contains a single unique message identifier.
The "References:" and "In-Reply-To:" field each contain one or more The "References:" and "In-Reply-To:" field each contain one or more
unique message identifiers, optionally separated by CFWS. unique message identifiers, optionally separated by CFWS.
The message identifier (msg-id) syntax is a limited version of the The message identifier (msg-id) syntax is a limited version of the
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.
skipping to change at page 30, line 50 skipping to change at page 30, line 50
conforms to unstructured. conforms to unstructured.
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
ftext = %d33-57 / ; Printable US-ASCII ftext = %d33-57 / ; Printable US-ASCII
%d59-126 / ; characters not including %d59-126 ; characters not including
; ":". ; ":".
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
skipping to change at page 32, line 11 skipping to change at page 32, line 11
Other differences in syntax and semantics are noted in the following Other differences in syntax and semantics are noted in the following
sections. sections.
4.1. Miscellaneous obsolete tokens 4.1. Miscellaneous obsolete tokens
These syntactic elements are used elsewhere in the obsolete syntax or These syntactic elements are used elsewhere in the obsolete syntax or
in the main syntax. Bare CR, bare LF, and NUL are added to obs-qp, in the main syntax. Bare CR, bare LF, and NUL are added to obs-qp,
obs-body and obs-unstruct. US-ASCII control characters are added to obs-body and obs-unstruct. US-ASCII control characters are added to
obs-qp, obs-unstruct, obs-ctext, and obs-qtext. The period character obs-qp, obs-unstruct, obs-ctext, and obs-qtext. The period character
is added to obs-phrase. The obs-commas construct is added to provide is added to obs-phrase. The obs-phrase-list provides for a
for "empty" elements in a comma-separated list, such as in obs- (potentially empty) comma-separated list of phrases which may include
phrase-list and addressing lists in section 4.4. "null" elements. That is, there could be two or more commas in such
a list with nothing in between them, or commas at the beginning or
end of the list.
Note: The "period" (or "full stop") character (".") in obs-phrase Note: The "period" (or "full stop") character (".") in obs-phrase
is not a form that was allowed in earlier versions of this or any is not a form that was allowed in earlier versions of this or any
other specification. Period (nor any other character from other specification. Period (nor any other character from
specials) was not allowed in phrase because it introduced a specials) was not allowed in phrase because it introduced a
parsing difficulty distinguishing between phrases and portions of parsing difficulty distinguishing between phrases and portions of
an addr-spec (see section 4.4). It appears here because the an addr-spec (see section 4.4). It appears here because the
period character is currently used in many messages in the period character is currently used in many messages in the
display-name portion of addresses, especially for initials in display-name portion of addresses, especially for initials in
names, and therefore must be interpreted properly. names, and therefore must be interpreted properly.
skipping to change at page 32, line 45 skipping to change at page 32, line 47
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 = *((*LF *CR *((%d0 / text) *LF *CR)) / CRLF) obs-body = *((*LF *CR *((%d0 / text) *LF *CR)) / CRLF)
obs-unstruct = *((*LF *CR *(obs-utext *LF *CR)) / FWS) obs-unstruct = *((*LF *CR *(obs-utext *LF *CR)) / FWS)
obs-phrase = word *(word / "." / CFWS) obs-phrase = word *(word / "." / CFWS)
obs-commas = [CFWS] "," *([CFWS] ",") [CFWS] obs-phrase-list = [phrase / CFWS] *("," [phrase / CFWS])
obs-phrase-list = [phrase / CFWS] *(obs-commas phrase) [obs-commas]
Bare CR and bare LF appear in messages with two different meanings. Bare CR and bare LF appear in messages with two different meanings.
In many cases, bare CR or bare LF are used improperly instead of CRLF In many cases, bare CR or bare LF are used improperly instead of CRLF
to indicate line separators. In other cases, bare CR and bare LF are to indicate line separators. In other cases, bare CR and bare LF are
used simply as US-ASCII control characters with their traditional used simply as US-ASCII control characters with their traditional
ASCII meanings. ASCII meanings.
4.2. Obsolete folding white space 4.2. Obsolete folding white space
In the obsolete syntax, any amount of folding white space MAY be In the obsolete syntax, any amount of folding white space MAY be
skipping to change at page 35, line 4 skipping to change at page 35, line 4
There are four primary differences in addressing. First, mailbox There are four primary differences in addressing. First, mailbox
addresses were allowed to have a route portion before the addr-spec addresses were allowed to have a route portion before the addr-spec
when enclosed in "<" and ">". The route is simply a comma-separated when enclosed in "<" and ">". The route is simply a comma-separated
list of domain names, each preceded by "@", and the list terminated list of domain names, each preceded by "@", and the list terminated
by a colon. Second, CFWS were allowed between the period-separated by a colon. Second, CFWS were allowed between the period-separated
elements of local-part and domain (i.e., dot-atom was not used). In elements of local-part and domain (i.e., dot-atom was not used). In
addition, local-part is allowed to contain quoted-string in addition addition, local-part is allowed to contain quoted-string in addition
to just atom. Third, mailbox-list and address-list were allowed to to just atom. Third, mailbox-list and address-list were allowed to
have "null" members. That is, there could be two or more commas in have "null" members. That is, there could be two or more commas in
such a list with nothing in between them. Finally, US-ASCII control such a list with nothing in between them, or commas at the beginning
characters and quoted-pairs were allowed in domain literals and are or end of the list. Finally, US-ASCII control characters and quoted-
added here. pairs were allowed in domain literals and are added here.
obs-angle-addr = [CFWS] "<" obs-route addr-spec ">" [CFWS] obs-angle-addr = [CFWS] "<" obs-route addr-spec ">" [CFWS]
obs-route = obs-domain-list ":" obs-route = obs-domain-list ":"
obs-domain-list = [obs-commas] obs-domain-list = *(CFWS / ",") "@" domain
[CFWS] "@" domain *(obs-commas "@" domain) *("," [CFWS] ["@" domain])
[obs-commas]
obs-mbox-list = [obs-commas] obs-mbox-list = *([CFWS] ",") mailbox *("," [mailbox / CFWS])
mailbox *(obs-commas mailbox)
[obs-commas]
obs-addr-list = [obs-commas] obs-addr-list = *([CFWS] ",") address *("," [address / CFWS])
address *(obs-commas address)
[obs-commas]
obs-group-list = obs-commas obs-group-list = 1*([CFWS] ",") [CFWS]
obs-local-part = word *("." word) obs-local-part = word *("." word)
obs-domain = atom *("." atom) obs-domain = atom *("." atom)
obs-dtext = obs-NO-WS-CTL / quoted-pair obs-dtext = obs-NO-WS-CTL / quoted-pair
When interpreting addresses, the route portion SHOULD be ignored. When interpreting addresses, the route portion SHOULD be ignored.
4.5. Obsolete header fields 4.5. Obsolete header fields
skipping to change at page 37, line 12 skipping to change at page 37, line 12
obs-reply-to = "Reply-To" *WSP ":" address-list CRLF obs-reply-to = "Reply-To" *WSP ":" address-list CRLF
4.5.3. Obsolete destination address fields 4.5.3. Obsolete destination address fields
obs-to = "To" *WSP ":" address-list CRLF obs-to = "To" *WSP ":" address-list CRLF
obs-cc = "Cc" *WSP ":" address-list CRLF obs-cc = "Cc" *WSP ":" address-list CRLF
obs-bcc = "Bcc" *WSP ":" obs-bcc = "Bcc" *WSP ":"
[address-list / CFWS / obs-commas] CRLF address-list / (*([CFWS] ",") [CFWS]) CRLF
When multiple occurrences of destination address fields occur in a When multiple occurrences of destination address fields occur in a
message, they SHOULD be treated as if the address-list in the first message, they SHOULD be treated as if the address-list in the first
occurrence of the field is combined with the address lists of the occurrence of the field is combined with the address lists of the
subsequent occurrences by adding a comma and concatenating. subsequent occurrences by adding a comma and concatenating.
4.5.4. Obsolete identification fields 4.5.4. Obsolete identification fields
The obsolete "In-Reply-To:" and "References:" fields differ from the The obsolete "In-Reply-To:" and "References:" fields differ from the
current syntax in that they allow phrase (words or quoted strings) to current syntax in that they allow phrase (words or quoted strings) to
skipping to change at page 38, line 22 skipping to change at page 38, line 22
obs-resent-send = "Resent-Sender" *WSP ":" mailbox CRLF obs-resent-send = "Resent-Sender" *WSP ":" mailbox CRLF
obs-resent-date = "Resent-Date" *WSP ":" date-time CRLF obs-resent-date = "Resent-Date" *WSP ":" date-time CRLF
obs-resent-to = "Resent-To" *WSP ":" address-list CRLF obs-resent-to = "Resent-To" *WSP ":" address-list CRLF
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 / obs-commas] 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 trace information only.
4.5.7. Obsolete trace fields 4.5.7. Obsolete trace fields
skipping to change at page 43, line 21 skipping to change at page 43, line 21
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.
Messages are delimited in this section between lines of "----" in the In the text version of this document, messages in this section are
text version of this document. The "----" lines are not part of the delimited between lines of "----". The "----" lines are not part of
message itself. the message itself.
Appendix A.1. Addressing examples Appendix A.1. Addressing examples
The following are examples of messages that might be sent between two The following are examples of messages that might be sent between two
individuals. individuals.
Appendix A.1.1. A message from one person to another with simple Appendix A.1.1. A message from one person to another with simple
addressing addressing
This could be called a canonical message. It has a single author, This could be called a canonical message. It has a single author,
skipping to change at page 51, line 43 skipping to change at page 50, line 43
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], and [RFC2822]. Items marked with an asterisk [RFC0822], [RFC1123], and [RFC2822]. Items marked with an asterisk
(*) below are items which appear in section 4 of this document and (*) below are items which appear in section 4 of this document and
therefore can no longer be generated. 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] that remain in this document:
1. Period allowed in obsolete form of phrase. 1. Period allowed in obsolete form of phrase.
2. ABNF moved out of document, now in [I-D.crocker-rfc4234bis]. 2. ABNF moved out of document, now in [RFC5234].
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.
10. Extension header fields no longer specifically called out. 10. Extension header fields no longer specifically called out.
11. ASCII 0 (null) removed.* 11. ASCII 0 (null) removed.*
skipping to change at page 52, line 31 skipping to change at page 51, line 31
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].
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, domain literals, and 4. Removed NO-WS-CTL from ctext, qtext, dtext, and unstructured.*
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. 7. Fixed unstructured syntax.
8. Changed date and time syntax to deal with white space in 8. Changed date and time syntax to deal with white space in
obsolete date syntax. obsolete date syntax.
9. Added group-list. 9. Removed quoted-pair from domain literals.*
10. Removed quoted-pair from domain literals.* 10. Clarified that other specifications limit domain syntax.
11. Clarified that other specifications limit domain syntax. 11. Simplified "Bcc:" and "Resent-Bcc:" syntax.
12. Simplified "Bcc:" and "Resent-Bcc:" syntax. 12. Allowed optional-field to appear within trace information.
13. Allowed optional-field to appear within trace information. 13. Removed no-fold-quote from msg-id. Clarified syntax
14. Removed no-fold-quote from msg-id. Clarified syntax
limitations. limitations.
15. Generalized "Received:" syntax to fix bugs and move definition 14. Generalized "Received:" syntax to fix bugs and move definition
out of this document. out of this document.
16. Simplified obs-qp. Fixed and simplified obs-utext (which now 15. Simplified obs-qp. Fixed and simplified obs-utext (which now
only appears in the obsolete syntax). Removed obs-text and obs- only appears in the obsolete syntax). Removed obs-text and obs-
char, adding obs-body. char, adding obs-body.
16. Fixed obsolete date syntax to allow for more (or less) comments
17. Fixed obsolete date syntax to allow for more (or less) comments
and white space. and white space.
18. Fixed all obsolete list syntax (obs-phrase-list, obs-domain-
list, obs-mbox-list, obs-addr-list, and adding obs-group-list). 17. Fixed all obsolete list syntax (obs-domain-list, obs-mbox-list,
19. Fixed obs-reply-to syntax. obs-addr-list, obs-phrase-list, and the newly added obs-group-
20. Fixed obs-bcc and obs-resent-bcc to allow empty lists. list).
21. Removed obs-path. 18. Fixed obs-reply-to syntax.
19. Fixed obs-bcc and obs-resent-bcc to allow empty lists.
20. Removed obs-path.
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, and Force (IETF), the chair of DRUMS, the Area Directors of the IETF, and
people who simply sent their comments in via e-mail. The editor is people who simply sent their comments in via e-mail. The editor is
deeply indebted to them all and thanks them sincerely. The below deeply indebted to them all and thanks them sincerely. The below
list includes everyone who sent e-mail concerning both this document list includes everyone who sent e-mail concerning both this document
skipping to change at page 55, line 5 skipping to change at page 54, line 5
RFC 1035, November 1987. RFC 1035, November 1987.
[RFC1123] Braden, R., "Requirements for Internet [RFC1123] Braden, R., "Requirements for Internet
Hosts - Application and Support", STD 3, Hosts - Application and Support", STD 3,
RFC 1123, October 1989. RFC 1123, October 1989.
[RFC2119] Bradner, S., "Key words for use in RFCs to [RFC2119] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14, Indicate Requirement Levels", BCP 14,
RFC 2119, March 1997. RFC 2119, March 1997.
[I-D.crocker-rfc4234bis] Crocker, D. and P. Overell, "Augmented BNF [RFC5234] Crocker, D. and P. Overell, "Augmented BNF
for Syntax Specifications: ABNF", for Syntax Specifications: ABNF", STD 68,
draft-crocker-rfc4234bis-01 (work in RFC 5234, January 2008.
progress), October 2007.
7.2. Informative References 7.2. Informative References
[RFC0822] Crocker, D., "Standard for the format of [RFC0822] Crocker, D., "Standard for the format of
ARPA Internet text messages", STD 11, ARPA Internet text messages", STD 11,
RFC 822, August 1982. RFC 822, August 1982.
[RFC1305] Mills, D., "Network Time Protocol (Version [RFC1305] Mills, D., "Network Time Protocol (Version
3) Specification, Implementation", 3) Specification, Implementation",
RFC 1305, March 1992. RFC 1305, March 1992.
skipping to change at page 57, line 49 skipping to change at page 56, line 49
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgements Acknowledgements
Funding for the RFC Editor function is provided by the IETF Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA). This document was produced Administrative Support Activity (IASA). This document was produced
using xml2rfc v1.33pre3+wcf (of http://xml.resource.org/) from a using xml2rfc v1.33pre5 (of http://xml.resource.org/) from a source
source in RFC-2629 XML format. in RFC-2629 XML format.
 End of changes. 35 change blocks. 
87 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/