idnits 2.17.1
draft-resnick-2822upd-06.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** It looks like you're using RFC 3978 boilerplate. You should update this
to the boilerplate described in the IETF Trust License Policy document
(see https://trustee.ietf.org/license-info), which is required now.
-- Found old boilerplate from RFC 3978, Section 5.1 on line 17.
-- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on
line 2468.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2479.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2486.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2492.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
-- The draft header indicates that this document obsoletes RFC2822, but the
abstract doesn't seem to mention this, which it should.
-- The draft header indicates that this document updates RFC4021, but the
abstract doesn't seem to mention this, which it should.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust Copyright Line does not match the
current year
== The document seems to lack the recommended RFC 2119 boilerplate, even if
it appears to use RFC 2119 keywords.
(The document does seem to have the reference to RFC 2119 which the
ID-Checklist requires).
(Using the creation date from RFC4021, updated by this document, for
RFC5378 checks: 2002-05-06)
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (February 7, 2008) is 5924 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Missing Reference: 'CFWS' is mentioned on line 708, but not defined
-- Obsolete informational reference (is this intentional?): RFC 822
(Obsoleted by RFC 2822)
-- Obsolete informational reference (is this intentional?): RFC 1305
(Obsoleted by RFC 5905)
-- Obsolete informational reference (is this intentional?): RFC 2822
(Obsoleted by RFC 5322)
-- Obsolete informational reference (is this intentional?): RFC 4288
(Obsoleted by RFC 6838)
== Outdated reference: A later version (-11) exists of
draft-klensin-rfc2821bis-06
Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 13 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group P. Resnick, Ed.
3 Internet-Draft Qualcomm Incorporated
4 Obsoletes: 2822 (if approved) February 7, 2008
5 Updates: 4021 (if approved)
6 Intended status: Standards Track
7 Expires: August 10, 2008
9 Internet Message Format
10 draft-resnick-2822upd-06
12 Status of This Memo
14 By submitting this Internet-Draft, each author represents that any
15 applicable patent or other IPR claims of which he or she is aware
16 have been or will be disclosed, and any of which he or she becomes
17 aware will be disclosed, in accordance with Section 6 of BCP 79.
19 Internet-Drafts are working documents of the Internet Engineering
20 Task Force (IETF), its areas, and its working groups. Note that
21 other groups may also distribute working documents as Internet-
22 Drafts.
24 Internet-Drafts are draft documents valid for a maximum of six months
25 and may be updated, replaced, or obsoleted by other documents at any
26 time. It is inappropriate to use Internet-Drafts as reference
27 material or to cite them other than as "work in progress."
29 The list of current Internet-Drafts can be accessed at
30 http://www.ietf.org/ietf/1id-abstracts.txt.
32 The list of Internet-Draft Shadow Directories can be accessed at
33 http://www.ietf.org/shadow.html.
35 This Internet-Draft will expire on August 10, 2008.
37 Copyright Notice
39 Copyright (C) The IETF Trust (2008).
41 Abstract
43 This document specifies the Internet Message Format (IMF), a syntax
44 for text messages that are sent between computer users, within the
45 framework of "electronic mail" messages. This specification is a
46 revision of Request For Comments (RFC) 2822, which itself superseded
47 Request For Comments (RFC) 822, "Standard for the Format of ARPA
48 Internet Text Messages", updating it to reflect current practice and
49 incorporating incremental changes that were specified in other RFCs.
51 Editorial Note
53 Comments on this document are encouraged. Discussions take place on
54 the "IETF 822" mailing list. Information on the mailing list can be
55 found at
57 Table of Contents
59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
60 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
61 1.2. Notational conventions . . . . . . . . . . . . . . . . . . 5
62 1.2.1. Requirements notation . . . . . . . . . . . . . . . . 5
63 1.2.2. Syntactic notation . . . . . . . . . . . . . . . . . . 5
64 1.2.3. Structure of this document . . . . . . . . . . . . . . 5
65 2. Lexical Analysis of Messages . . . . . . . . . . . . . . . . . 6
66 2.1. General Description . . . . . . . . . . . . . . . . . . . 6
67 2.1.1. Line Length Limits . . . . . . . . . . . . . . . . . . 7
68 2.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 8
69 2.2.1. Unstructured Header Field Bodies . . . . . . . . . . . 8
70 2.2.2. Structured Header Field Bodies . . . . . . . . . . . . 8
71 2.2.3. Long Header Fields . . . . . . . . . . . . . . . . . . 8
72 2.3. Body . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
73 3. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
74 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 9
75 3.2. Lexical Tokens . . . . . . . . . . . . . . . . . . . . . . 10
76 3.2.1. Quoted characters . . . . . . . . . . . . . . . . . . 10
77 3.2.2. Folding white space and comments . . . . . . . . . . . 11
78 3.2.3. Atom . . . . . . . . . . . . . . . . . . . . . . . . . 12
79 3.2.4. Quoted strings . . . . . . . . . . . . . . . . . . . . 13
80 3.2.5. Miscellaneous tokens . . . . . . . . . . . . . . . . . 14
81 3.3. Date and Time Specification . . . . . . . . . . . . . . . 14
82 3.4. Address Specification . . . . . . . . . . . . . . . . . . 16
83 3.4.1. Addr-spec specification . . . . . . . . . . . . . . . 17
84 3.5. Overall message syntax . . . . . . . . . . . . . . . . . . 18
85 3.6. Field definitions . . . . . . . . . . . . . . . . . . . . 19
86 3.6.1. The origination date field . . . . . . . . . . . . . . 22
87 3.6.2. Originator fields . . . . . . . . . . . . . . . . . . 22
88 3.6.3. Destination address fields . . . . . . . . . . . . . . 23
89 3.6.4. Identification fields . . . . . . . . . . . . . . . . 24
90 3.6.5. Informational fields . . . . . . . . . . . . . . . . . 27
91 3.6.6. Resent fields . . . . . . . . . . . . . . . . . . . . 28
92 3.6.7. Trace fields . . . . . . . . . . . . . . . . . . . . . 29
93 3.6.8. Optional fields . . . . . . . . . . . . . . . . . . . 30
94 4. Obsolete Syntax . . . . . . . . . . . . . . . . . . . . . . . 30
95 4.1. Miscellaneous obsolete tokens . . . . . . . . . . . . . . 31
96 4.2. Obsolete folding white space . . . . . . . . . . . . . . . 32
97 4.3. Obsolete Date and Time . . . . . . . . . . . . . . . . . . 33
98 4.4. Obsolete Addressing . . . . . . . . . . . . . . . . . . . 34
99 4.5. Obsolete header fields . . . . . . . . . . . . . . . . . . 35
100 4.5.1. Obsolete origination date field . . . . . . . . . . . 36
101 4.5.2. Obsolete originator fields . . . . . . . . . . . . . . 36
102 4.5.3. Obsolete destination address fields . . . . . . . . . 37
103 4.5.4. Obsolete identification fields . . . . . . . . . . . . 37
104 4.5.5. Obsolete informational fields . . . . . . . . . . . . 37
105 4.5.6. Obsolete resent fields . . . . . . . . . . . . . . . . 37
106 4.5.7. Obsolete trace fields . . . . . . . . . . . . . . . . 38
107 4.5.8. Obsolete optional fields . . . . . . . . . . . . . . . 38
108 5. Security Considerations . . . . . . . . . . . . . . . . . . . 38
109 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
110 Appendix A. Example messages . . . . . . . . . . . . . . . . . 42
111 Appendix A.1. Addressing examples . . . . . . . . . . . . . . . 43
112 Appendix A.1.1. A message from one person to another with
113 simple addressing . . . . . . . . . . . . . . . . 43
114 Appendix A.1.2. Different types of mailboxes . . . . . . . . . . . 44
115 Appendix A.1.3. Group addresses . . . . . . . . . . . . . . . . . 44
116 Appendix A.2. Reply messages . . . . . . . . . . . . . . . . . . 44
117 Appendix A.3. Resent messages . . . . . . . . . . . . . . . . . 45
118 Appendix A.4. Messages with trace fields . . . . . . . . . . . . 46
119 Appendix A.5. White space, comments, and other oddities . . . . 47
120 Appendix A.6. Obsoleted forms . . . . . . . . . . . . . . . . . 47
121 Appendix A.6.1. Obsolete addressing . . . . . . . . . . . . . . . 48
122 Appendix A.6.2. Obsolete dates . . . . . . . . . . . . . . . . . . 48
123 Appendix A.6.3. Obsolete white space and comments . . . . . . . . 48
124 Appendix B. Differences from earlier specifications . . . . . 49
125 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . 50
126 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52
127 7.1. Normative References . . . . . . . . . . . . . . . . . . . 52
128 7.2. Informative References . . . . . . . . . . . . . . . . . . 52
130 1. Introduction
132 1.1. Scope
134 This document specifies the Internet Message Format (IMF), a syntax
135 for text messages that are sent between computer users, within the
136 framework of "electronic mail" messages. This specification is an
137 update to [RFC2822], which itself superseded [RFC0822], updating it
138 to reflect current practice and incorporating incremental changes
139 that were specified in other RFCs such as [RFC1123].
141 This document specifies a syntax only for text messages. In
142 particular, it makes no provision for the transmission of images,
143 audio, or other sorts of structured data in electronic mail messages.
144 There are several extensions published, such as the MIME document
145 series ([RFC2045], [RFC2046], [RFC2049]), which describe mechanisms
146 for the transmission of such data through electronic mail, either by
147 extending the syntax provided here or by structuring such messages to
148 conform to this syntax. Those mechanisms are outside of the scope of
149 this specification.
151 In the context of electronic mail, messages are viewed as having an
152 envelope and contents. The envelope contains whatever information is
153 needed to accomplish transmission and delivery. (See
154 [I-D.klensin-rfc2821bis] for a discussion of the envelope.) The
155 contents comprise the object to be delivered to the recipient. This
156 specification applies only to the format and some of the semantics of
157 message contents. It contains no specification of the information in
158 the envelope.
160 However, some message systems may use information from the contents
161 to create the envelope. It is intended that this specification
162 facilitate the acquisition of such information by programs.
164 This specification is intended as a definition of what message
165 content format is to be passed between systems. Though some message
166 systems locally store messages in this format (which eliminates the
167 need for translation between formats) and others use formats that
168 differ from the one specified in this specification, local storage is
169 outside of the scope of this specification.
171 Note: This specification is not intended to dictate the internal
172 formats used by sites, the specific message system features that
173 they are expected to support, or any of the characteristics of
174 user interface programs that create or read messages. In
175 addition, this document does not specify an encoding of the
176 characters for either transport or storage; that is, it does not
177 specify the number of bits used or how those bits are specifically
178 transferred over the wire or stored on disk.
180 1.2. Notational conventions
182 1.2.1. Requirements notation
184 This document occasionally uses terms that appear in capital letters.
185 When the terms "MUST", "SHOULD", "RECOMMENDED", "MUST NOT", "SHOULD
186 NOT", and "MAY" appear capitalized, they are being used to indicate
187 particular requirements of this specification. A discussion of the
188 meanings of these terms appears in [RFC2119].
190 1.2.2. Syntactic notation
192 This specification uses the Augmented Backus-Naur Form (ABNF)
193 [RFC5234] notation for the formal definitions of the syntax of
194 messages. Characters will be specified either by a decimal value
195 (e.g., the value %d65 for uppercase A and %d97 for lowercase A) or by
196 a case-insensitive literal value enclosed in quotation marks (e.g.,
197 "A" for either uppercase or lowercase A).
199 1.2.3. Structure of this document
201 This document is divided into several sections.
203 This section, section 1, is a short introduction to the document.
205 Section 2 lays out the general description of a message and its
206 constituent parts. This is an overview to help the reader understand
207 some of the general principles used in the later portions of this
208 document. Any examples in this section MUST NOT be taken as
209 specification of the formal syntax of any part of a message.
211 Section 3 specifies formal ABNF rules for the structure of each part
212 of a message (the syntax) and describes the relationship between
213 those parts and their meaning in the context of a message (the
214 semantics). That is, it describes the actual rules for the structure
215 of each part of a message (the syntax) as well as a description of
216 the parts and instructions for their interpretation (the semantics).
217 This includes analysis of the syntax and semantics of subparts of
218 messages that have specific structure. The syntax included in
219 section 3 represents messages as they MUST be created. There are
220 also notes in section 3 to indicate if any of the options specified
221 in the syntax SHOULD be used over any of the others.
223 Both sections 2 and 3 describe messages that are legal to generate
224 for purposes of this specification.
226 Section 4 of this document specifies an "obsolete" syntax. There are
227 references in section 3 to these obsolete syntactic elements. The
228 rules of the obsolete syntax are elements that have appeared in
229 earlier versions of this specification or have previously been widely
230 used in Internet messages. As such, these elements MUST be
231 interpreted by parsers of messages in order to be conformant to this
232 specification. However, since items in this syntax have been
233 determined to be non-interoperable or to cause significant problems
234 for recipients of messages, they MUST NOT be generated by creators of
235 conformant messages.
237 Section 5 details security considerations to take into account when
238 implementing this specification.
240 Appendix A lists examples of different sorts of messages. These
241 examples are not exhaustive of the types of messages that appear on
242 the Internet, but give a broad overview of certain syntactic forms.
244 Appendix B lists the differences between this specification and
245 earlier specifications for Internet messages.
247 Appendix C contains acknowledgements.
249 2. Lexical Analysis of Messages
251 2.1. General Description
253 At the most basic level, a message is a series of characters. A
254 message that is conformant with this specification is composed of
255 characters with values in the range 1 through 127 and interpreted as
256 US-ASCII [ANSI.X3-4.1986] characters. For brevity, this document
257 sometimes refers to this range of characters as simply "US-ASCII
258 characters".
260 Note: This document specifies that messages are made up of
261 characters in the US-ASCII range of 1 through 127. There are
262 other documents, specifically the MIME document series ([RFC2045],
263 [RFC2046], [RFC2047], [RFC2049], [RFC4288], [RFC4289]), that
264 extend this specification to allow for values outside of that
265 range. Discussion of those mechanisms is not within the scope of
266 this specification.
268 Messages are divided into lines of characters. A line is a series of
269 characters that is delimited with the two characters carriage-return
270 and line-feed; that is, the carriage return (CR) character (ASCII
271 value 13) followed immediately by the line feed (LF) character (ASCII
272 value 10). (The carriage-return/line-feed pair is usually written in
273 this document as "CRLF".)
274 A message consists of header fields (collectively called "the header
275 section of the message") followed, optionally, by a body. The header
276 section is a sequence of lines of characters with special syntax as
277 defined in this specification. The body is simply a sequence of
278 characters that follows the header section and is separated from the
279 header section by an empty line (i.e., a line with nothing preceding
280 the CRLF).
282 Note: Common parlance and earlier versions of this specification
283 use the term "header" to either refer to the entire header section
284 or to refer to an individual header field. To avoid ambiguity,
285 this document does not use the terms "header" or "headers" in
286 isolation, but instead always uses "header field" to refer to the
287 individual field and "header section" to refer to the entire
288 collection.
290 2.1.1. Line Length Limits
292 There are two limits that this specification places on the number of
293 characters in a line. Each line of characters MUST be no more than
294 998 characters, and SHOULD be no more than 78 characters, excluding
295 the CRLF.
297 The 998 character limit is due to limitations in many implementations
298 which send, receive, or store IMF messages that simply cannot handle
299 more than 998 characters on a line. Receiving implementations would
300 do well to handle an arbitrarily large number of characters in a line
301 for robustness sake. However, there are so many implementations
302 which (in compliance with the transport requirements of
303 [I-D.klensin-rfc2821bis]) do not accept messages containing more than
304 1000 characters including the CR and LF per line, it is important for
305 implementations not to create such messages.
307 The more conservative 78 character recommendation is to accommodate
308 the many implementations of user interfaces that display these
309 messages which may truncate, or disastrously wrap, the display of
310 more than 78 characters per line, in spite of the fact that such
311 implementations are non-conformant to the intent of this
312 specification (and that of [I-D.klensin-rfc2821bis] if they actually
313 cause information to be lost). Again, even though this limitation is
314 put on messages, it is incumbent upon implementations that display
315 messages to handle an arbitrarily large number of characters in a
316 line (certainly at least up to the 998 character limit) for the sake
317 of robustness.
319 2.2. Header Fields
321 Header fields are lines beginning with a field name, followed by a
322 colon (":"), followed by a field body, and terminated by CRLF. A
323 field name MUST be composed of printable US-ASCII characters (i.e.,
324 characters that have values between 33 and 126, inclusive), except
325 colon. A field body may be composed of printable US-ASCII characters
326 as well as the space (SP, ASCII value 32) and horizontal tab (HTAB,
327 ASCII value 9) characters (together known as the white space
328 characters, WSP). A field body MUST NOT include CR and LF except
329 when used in "folding" and "unfolding" as described in section 2.2.3.
330 All field bodies MUST conform to the syntax described in sections 3
331 and 4 of this specification.
333 2.2.1. Unstructured Header Field Bodies
335 Some field bodies in this specification are defined simply as
336 "unstructured" (which is specified in section 3.2.5 as any printable
337 US-ASCII characters plus white space characters) with no further
338 restrictions. These are referred to as unstructured field bodies.
339 Semantically, unstructured field bodies are simply to be treated as a
340 single line of characters with no further processing (except for
341 "folding" and "unfolding" as described in section 2.2.3).
343 2.2.2. Structured Header Field Bodies
345 Some field bodies in this specification have a syntax that is more
346 restrictive than the unstructured field bodies described above.
347 These are referred to as "structured" field bodies. Structured field
348 bodies are sequences of specific lexical tokens as described in
349 sections 3 and 4 of this specification. Many of these tokens are
350 allowed (according to their syntax) to be introduced or end with
351 comments (as described in section 3.2.2) as well as the white space
352 characters, and those white space characters are subject to "folding"
353 and "unfolding" as described in section 2.2.3. Semantic analysis of
354 structured field bodies is given along with their syntax.
356 2.2.3. Long Header Fields
358 Each header field is logically a single line of characters comprising
359 the field name, the colon, and the field body. For convenience
360 however, and to deal with the 998/78 character limitations per line,
361 the field body portion of a header field can be split into a
362 multiple-line representation; this is called "folding". The general
363 rule is that wherever this specification allows for folding white
364 space (not simply WSP characters), a CRLF may be inserted before any
365 WSP.
367 For example, the header field:
369 Subject: This is a test
371 can be represented as:
373 Subject: This
374 is a test
376 Note: Though structured field bodies are defined in such a way
377 that folding can take place between many of the lexical tokens
378 (and even within some of the lexical tokens), folding SHOULD be
379 limited to placing the CRLF at higher-level syntactic breaks. For
380 instance, if a field body is defined as comma-separated values, it
381 is recommended that folding occur after the comma separating the
382 structured items in preference to other places where the field
383 could be folded, even if it is allowed elsewhere.
385 The process of moving from this folded multiple-line representation
386 of a header field to its single line representation is called
387 "unfolding". Unfolding is accomplished by simply removing any CRLF
388 that is immediately followed by WSP. Each header field should be
389 treated in its unfolded form for further syntactic and semantic
390 evaluation. An unfolded header field has no length restriction and
391 therefore may be infinitely long.
393 2.3. Body
395 The body of a message is simply lines of US-ASCII characters. The
396 only two limitations on the body are as follows:
398 o CR and LF MUST only occur together as CRLF; they MUST NOT appear
399 independently in the body.
400 o Lines of characters in the body MUST be limited to 998 characters,
401 and SHOULD be limited to 78 characters, excluding the CRLF.
403 Note: As was stated earlier, there are other documents,
404 specifically the MIME documents ([RFC2045], [RFC2046], [RFC2049],
405 [RFC4288], [RFC4289]), that extend (and limit) this specification
406 to allow for different sorts of message bodies. Again, these
407 mechanisms are beyond the scope of this document.
409 3. Syntax
411 3.1. Introduction
413 The syntax as given in this section defines the legal syntax of
414 Internet messages. Messages that are conformant to this
415 specification MUST conform to the syntax in this section. If there
416 are options in this section where one option SHOULD be generated,
417 that is indicated either in the prose or in a comment next to the
418 syntax.
420 For the defined expressions, a short description of the syntax and
421 use is given, followed by the syntax in ABNF, followed by a semantic
422 analysis. The following primitive tokens that are used but otherwise
423 unspecified are taken from the "Core Rules" of [RFC5234], Appendix
424 B.1: CR, LF, CRLF, HTAB, SP, WSP, DQUOTE, DIGIT, ALPHA, and VCHAR.
426 In some of the definitions, there will be non-terminals whose names
427 start with "obs-". These "obs-" elements refer to tokens defined in
428 the obsolete syntax in section 4. In all cases, these productions
429 are to be ignored for the purposes of generating legal Internet
430 messages and MUST NOT be used as part of such a message. However,
431 when interpreting messages, these tokens MUST be honored as part of
432 the legal syntax. In this sense, section 3 defines a grammar for the
433 generation of messages, with "obs-" elements that are to be ignored,
434 while section 4 adds grammar for the interpretation of messages.
436 3.2. Lexical Tokens
438 The following rules are used to define an underlying lexical
439 analyzer, which feeds tokens to the higher-level parsers. This
440 section defines the tokens used in structured header field bodies.
442 Note: Readers of this specification need to pay special attention
443 to how these lexical tokens are used in both the lower-level and
444 higher-level syntax later in the document. Particularly, the
445 white space tokens and the comment tokens defined in section 3.2.2
446 get used in the lower-level tokens defined here, and those lower-
447 level tokens are in turn used as parts of the higher-level tokens
448 defined later. Therefore, white space and comments may be allowed
449 in the higher-level tokens even though they may not explicitly
450 appear in a particular definition.
452 3.2.1. Quoted characters
454 Some characters are reserved for special interpretation, such as
455 delimiting lexical tokens. To permit use of these characters as
456 uninterpreted data, a quoting mechanism is provided.
458 quoted-pair = ("\" (VCHAR / WSP)) / obs-qp
460 Where any quoted-pair appears, it is to be interpreted as the
461 character alone. That is to say, the "\" character that appears as
462 part of a quoted-pair is semantically "invisible".
464 Note: The "\" character may appear in a message where it is not
465 part of a quoted-pair. A "\" character that does not appear in a
466 quoted-pair is not semantically invisible. The only places in
467 this specification where quoted-pair currently appears are
468 ccontent, qcontent, and in obs-dtext in section 4.
470 3.2.2. Folding white space and comments
472 White space characters, including white space used in folding
473 (described in section 2.2.3), may appear between many elements in
474 header field bodies. Also, strings of characters that are treated as
475 comments may be included in structured field bodies as characters
476 enclosed in parentheses. The following defines the folding white
477 space (FWS) and comment constructs.
479 Strings of characters enclosed in parentheses are considered comments
480 so long as they do not appear within a "quoted-string", as defined in
481 section 3.2.4. Comments may nest.
483 There are several places in this specification where comments and FWS
484 may be freely inserted. To accommodate that syntax, an additional
485 token for "CFWS" is defined for places where comments and/or FWS can
486 occur. However, where CFWS occurs in this specification, it MUST NOT
487 be inserted in such a way that any line of a folded header field is
488 made up entirely of WSP characters and nothing else.
490 FWS = ([*WSP CRLF] 1*WSP) / obs-FWS
491 ; Folding white space
493 ctext = %d33-39 / ; Printable US-ASCII
494 %d42-91 / ; characters not including
495 %d93-126 / ; "(", ")", or "\"
496 obs-ctext
498 ccontent = ctext / quoted-pair / comment
500 comment = "(" *([FWS] ccontent) [FWS] ")"
502 CFWS = (1*([FWS] comment) [FWS]) / FWS
504 Throughout this specification, where FWS (the folding white space
505 token) appears, it indicates a place where folding, as discussed in
506 section 2.2.3, may take place. Wherever folding appears in a message
507 (that is, a header field body containing a CRLF followed by any WSP),
508 unfolding (removal of the CRLF) is performed before any further
509 semantic analysis is performed on that header field according to this
510 specification. That is to say, any CRLF that appears in FWS is
511 semantically "invisible".
513 A comment is normally used in a structured field body to provide some
514 human readable informational text. Since a comment is allowed to
515 contain FWS, folding is permitted within the comment. Also note that
516 since quoted-pair is allowed in a comment, the parentheses and
517 backslash characters may appear in a comment so long as they appear
518 as a quoted-pair. Semantically, the enclosing parentheses are not
519 part of the comment; the comment is what is contained between the two
520 parentheses. As stated earlier, the "\" in any quoted-pair and the
521 CRLF in any FWS that appears within the comment are semantically
522 "invisible" and therefore not part of the comment either.
524 Runs of FWS, comment or CFWS that occur between lexical tokens in a
525 structured header field are semantically interpreted as a single
526 space character.
528 3.2.3. Atom
530 Several productions in structured header field bodies are simply
531 strings of certain basic characters. Such productions are called
532 atoms.
534 Some of the structured header field bodies also allow the period
535 character (".", ASCII value 46) within runs of atext. An additional
536 "dot-atom" token is defined for those purposes.
538 Note: The "specials" token does not appear anywhere else in this
539 specification. It is simply the visible (i.e., non-control, non-
540 white space) characters which do not appear in atext. It is
541 provided only because it is useful for implementers who use tools
542 that lexically analyze messages. Each of the characters in
543 specials can be used to indicate a tokenization point in lexical
544 analysis.
546 atext = ALPHA / DIGIT / ; Printable US-ASCII
547 "!" / "#" / ; characters not including
548 "$" / "%" / ; specials. Used for atoms.
549 "&" / "'" /
550 "*" / "+" /
551 "-" / "/" /
552 "=" / "?" /
553 "^" / "_" /
554 "`" / "{" /
555 "|" / "}" /
556 "~"
558 atom = [CFWS] 1*atext [CFWS]
560 dot-atom-text = 1*atext *("." 1*atext)
562 dot-atom = [CFWS] dot-atom-text [CFWS]
564 specials = "(" / ")" / ; Special characters that do
565 "<" / ">" / ; not appear in atext
566 "[" / "]" /
567 ":" / ";" /
568 "@" / "\" /
569 "," / "." /
570 DQUOTE
572 Both atom and dot-atom are interpreted as a single unit, comprising
573 the string of characters that make it up. Semantically, the optional
574 comments and FWS surrounding the rest of the characters are not part
575 of the atom; the atom is only the run of atext characters in an atom,
576 or the atext and "." characters in a dot-atom.
578 3.2.4. Quoted strings
580 Strings of characters that include characters other than those
581 allowed in atoms can be represented in a quoted string format, where
582 the characters are surrounded by quote (DQUOTE, ASCII value 34)
583 characters.
585 qtext = %d33 / ; Printable US-ASCII
586 %d35-91 / ; characters not including
587 %d93-126 / ; "\" or the quote character
588 obs-qtext
590 qcontent = qtext / quoted-pair
592 quoted-string = [CFWS]
593 DQUOTE *([FWS] qcontent) [FWS] DQUOTE
595 [CFWS]
597 A quoted-string is treated as a unit. That is, quoted-string is
598 identical to atom, semantically. Since a quoted-string is allowed to
599 contain FWS, folding is permitted. Also note that since quoted-pair
600 is allowed in a quoted-string, the quote and backslash characters may
601 appear in a quoted-string so long as they appear as a quoted-pair.
603 Semantically, neither the optional CFWS outside of the quote
604 characters nor the quote characters themselves are part of the
605 quoted-string; the quoted-string is what is contained between the two
606 quote characters. As stated earlier, the "\" in any quoted-pair and
607 the CRLF in any FWS/CFWS that appears within the quoted-string are
608 semantically "invisible" and therefore not part of the quoted-string
609 either.
611 3.2.5. Miscellaneous tokens
613 Three additional tokens are defined, word and phrase for combinations
614 of atoms and/or quoted-strings, and unstructured for use in
615 unstructured header fields and in some places within structured
616 header fields.
618 word = atom / quoted-string
620 phrase = 1*word / obs-phrase
622 unstructured = (*([FWS] VCHAR) *WSP) / obs-unstruct
624 3.3. Date and Time Specification
626 Date and time values occur in several header fields. This section
627 specifies the syntax for a full date and time specification. Though
628 folding white space is permitted throughout the date-time
629 specification, it is RECOMMENDED that a single space be used in each
630 place that FWS appears (whether it is required or optional); some
631 older implementations will not interpret longer sequences of folding
632 white space correctly.
634 date-time = [ day-of-week "," ] date time [CFWS]
636 day-of-week = ([FWS] day-name) / obs-day-of-week
638 day-name = "Mon" / "Tue" / "Wed" / "Thu" /
639 "Fri" / "Sat" / "Sun"
641 date = day month year
643 day = ([FWS] 1*2DIGIT FWS) / obs-day
645 month = "Jan" / "Feb" / "Mar" / "Apr" /
646 "May" / "Jun" / "Jul" / "Aug" /
647 "Sep" / "Oct" / "Nov" / "Dec"
649 year = (FWS 4*DIGIT FWS) / obs-year
651 time = time-of-day zone
653 time-of-day = hour ":" minute [ ":" second ]
655 hour = 2DIGIT / obs-hour
657 minute = 2DIGIT / obs-minute
659 second = 2DIGIT / obs-second
661 zone = (FWS ( "+" / "-" ) 4DIGIT) / obs-zone
663 The day is the numeric day of the month. The year is any numeric
664 year 1900 or later.
666 The time-of-day specifies the number of hours, minutes, and
667 optionally seconds since midnight of the date indicated.
669 The date and time-of-day SHOULD express local time.
671 The zone specifies the offset from Coordinated Universal Time (UTC,
672 formerly referred to as "Greenwich Mean Time") that the date and
673 time-of-day represent. The "+" or "-" indicates whether the time-of-
674 day is ahead of (i.e., east of) or behind (i.e., west of) Universal
675 Time. The first two digits indicate the number of hours difference
676 from Universal Time, and the last two digits indicate the number of
677 additional minutes difference from Universal Time. (Hence, +hhmm
678 means +(hh * 60 + mm) minutes, and -hhmm means -(hh * 60 + mm)
679 minutes). The form "+0000" SHOULD be used to indicate a time zone at
680 Universal Time. Though "-0000" also indicates Universal Time, it is
681 used to indicate that the time was generated on a system that may be
682 in a local time zone other than Universal Time and that the date-time
683 contains no information about the local time zone.
685 A date-time specification MUST be semantically valid. That is, the
686 day-of-week (if included) MUST be the day implied by the date, the
687 numeric day-of-month MUST be between 1 and the number of days allowed
688 for the specified month (in the specified year), the time-of-day MUST
689 be in the range 00:00:00 through 23:59:60 (the number of seconds
690 allowing for a leap second; see [RFC1305]), and the last two digits
691 of the zone MUST be within the range 00 through 59.
693 3.4. Address Specification
695 Addresses occur in several message header fields to indicate senders
696 and recipients of messages. An address may either be an individual
697 mailbox, or a group of mailboxes.
699 address = mailbox / group
701 mailbox = name-addr / addr-spec
703 name-addr = [display-name] angle-addr
705 angle-addr = [CFWS] "<" addr-spec ">" [CFWS] /
706 obs-angle-addr
708 group = display-name ":" [group-list] ";" [CFWS]
710 display-name = phrase
712 mailbox-list = (mailbox *("," mailbox)) / obs-mbox-list
714 address-list = (address *("," address)) / obs-addr-list
716 group-list = mailbox-list / CFWS / obs-group-list
718 A mailbox receives mail. It is a conceptual entity which does not
719 necessarily pertain to file storage. For example, some sites may
720 choose to print mail on a printer and deliver the output to the
721 addressee's desk.
723 Normally, a mailbox is composed of two parts: (1) an optional display
724 name that indicates the name of the recipient (which can be a person
725 or a system) that could be displayed to the user of a mail
726 application, and (2) an addr-spec address enclosed in angle brackets
727 ("<" and ">"). There is an alternate simple form of a mailbox where
728 the addr-spec address appears alone, without the recipient's name or
729 the angle brackets. The Internet addr-spec address is described in
730 section 3.4.1.
732 Note: Some legacy implementations used the simple form where the
733 addr-spec appears without the angle brackets, but included the
734 name of the recipient in parentheses as a comment following the
735 addr-spec. Since the meaning of the information in a comment is
736 unspecified, implementations SHOULD use the full name-addr form of
737 the mailbox, instead of the legacy form, to specify the display
738 name associated with a mailbox. Also, because some legacy
739 implementations interpret the comment, comments generally SHOULD
740 NOT be used in address fields to avoid confusing such
741 implementations.
743 When it is desirable to treat several mailboxes as a single unit
744 (i.e., in a distribution list), the group construct can be used. The
745 group construct allows the sender to indicate a named group of
746 recipients. This is done by giving a display name for the group,
747 followed by a colon, followed by a comma separated list of any number
748 of mailboxes (including zero and one), and ending with a semicolon.
749 Because the list of mailboxes can be empty, using the group construct
750 is also a simple way to communicate to recipients that the message
751 was sent to one or more named sets of recipients, without actually
752 providing the individual mailbox address for any of those recipients.
754 3.4.1. Addr-spec specification
756 An addr-spec is a specific Internet identifier that contains a
757 locally interpreted string followed by the at-sign character ("@",
758 ASCII value 64) followed by an Internet domain. The locally
759 interpreted string is either a quoted-string or a dot-atom. If the
760 string can be represented as a dot-atom (that is, it contains no
761 characters other than atext characters or "." surrounded by atext
762 characters), then the dot-atom form SHOULD be used and the quoted-
763 string form SHOULD NOT be used. Comments and folding white space
764 SHOULD NOT be used around the "@" in the addr-spec.
766 Note: A liberal syntax for the domain portion of addr-spec is
767 given here. However, the domain portion contains addressing
768 information specified by and used in other protocols (e.g.,
769 [RFC1034], [RFC1035], [RFC1123], [I-D.klensin-rfc2821bis]). It is
770 therefore incumbent upon implementations to conform to the syntax
771 of addresses for the context in which they are used.
773 addr-spec = local-part "@" domain
775 local-part = dot-atom / quoted-string / obs-local-part
777 domain = dot-atom / domain-literal / obs-domain
779 domain-literal = [CFWS] "[" *([FWS] dtext) [FWS] "]" [CFWS]
781 dtext = %d33-90 / ; Printable US-ASCII
782 %d94-126 / ; characters not including
783 obs-dtext ; "[", "]", or "\"
785 The domain portion identifies the point to which the mail is
786 delivered. In the dot-atom form, this is interpreted as an Internet
787 domain name (either a host name or a mail exchanger name) as
788 described in [RFC1034], [RFC1035] and [RFC1123]. In the domain-
789 literal form, the domain is interpreted as the literal Internet
790 address of the particular host. In both cases, how addressing is
791 used and how messages are transported to a particular host is covered
792 in separate documents such as [I-D.klensin-rfc2821bis]. These
793 mechanisms are outside of the scope of this document.
795 The local-part portion is a domain dependent string. In addresses,
796 it is simply interpreted on the particular host as a name of a
797 particular mailbox.
799 3.5. Overall message syntax
801 A message consists of header fields, optionally followed by a message
802 body. Lines in a message MUST be a maximum of 998 characters
803 excluding the CRLF, but it is RECOMMENDED that lines be limited to 78
804 characters excluding the CRLF. (See the note in section 2.1.1 for
805 explanation.) In a message body, though all of the characters listed
806 in the text rule MAY be used, the use of US-ASCII control characters
807 (values 1 through 8, 11, 12, and 14 through 31) is discouraged since
808 their interpretation by receivers for display is not guaranteed.
810 message = (fields / obs-fields)
811 [CRLF body]
813 body = (*(*998text CRLF) *998text) / obs-body
815 text = %d1-9 / ; Characters excluding CR
816 %d11 / ; and LF
817 %d12 /
818 %d14-127
820 The header fields carry most of the semantic information and are
821 defined in section 3.6. The body is simply a series of lines of text
822 which are uninterpreted for the purposes of this specification.
824 3.6. Field definitions
826 The header fields of a message are defined here. All header fields
827 have the same general syntactic structure: A field name, followed by
828 a colon, followed by the field body. The specific syntax for each
829 header field is defined in the subsequent sections.
831 Note: In the ABNF syntax for each field in subsequent sections,
832 each field name is followed by the required colon. However, for
833 brevity sometimes the colon is not referred to in the textual
834 description of the syntax. It is, nonetheless, required.
836 It is important to note that the header fields are not guaranteed to
837 be in a particular order. They may appear in any order, and they
838 have been known to be reordered occasionally when transported over
839 the Internet. However, for the purposes of this specification,
840 header fields SHOULD NOT be reordered when a message is transported
841 or transformed. More importantly, the trace header fields and resent
842 header fields MUST NOT be reordered, and SHOULD be kept in blocks
843 prepended to the message. See sections 3.6.6 and 3.6.7 for more
844 information.
846 The only required header fields are the origination date field and
847 the originator address field(s). All other header fields are
848 syntactically optional. More information is contained in the table
849 following this definition.
851 fields = *(trace
852 *optional-field /
853 *(resent-date /
854 resent-from /
855 resent-sender /
856 resent-to /
857 resent-cc /
858 resent-bcc /
859 resent-msg-id))
860 *(orig-date /
861 from /
862 sender /
863 reply-to /
864 to /
865 cc /
866 bcc /
867 message-id /
868 in-reply-to /
869 references /
870 subject /
871 comments /
872 keywords /
873 optional-field)
875 The following table indicates limits on the number of times each
876 field may occur in the header section of a message as well as any
877 special limitations on the use of those fields. An asterisk ("*")
878 next to a value in the minimum or maximum column indicates that a
879 special restriction appears in the Notes column.
881 +----------------+--------+------------+----------------------------+
882 | Field | Min | Max number | Notes |
883 | | number | | |
884 +----------------+--------+------------+----------------------------+
885 | trace | 0 | unlimited | Block prepended - see |
886 | | | | 3.6.7 |
887 | resent-date | 0* | unlimited* | One per block, required if |
888 | | | | other resent fields are |
889 | | | | present - see 3.6.6 |
890 | resent-from | 0 | unlimited* | One per block - see 3.6.6 |
891 | resent-sender | 0* | unlimited* | One per block, MUST occur |
892 | | | | with multi-address |
893 | | | | resent-from - see 3.6.6 |
894 | resent-to | 0 | unlimited* | One per block - see 3.6.6 |
895 | resent-cc | 0 | unlimited* | One per block - see 3.6.6 |
896 | resent-bcc | 0 | unlimited* | One per block - see 3.6.6 |
897 | resent-msg-id | 0 | unlimited* | One per block - see 3.6.6 |
898 | orig-date | 1 | 1 | |
899 | from | 1 | 1 | See sender and 3.6.2 |
900 | sender | 0* | 1 | MUST occur with |
901 | | | | multi-address from - see |
902 | | | | 3.6.2 |
903 | reply-to | 0 | 1 | |
904 | to | 0 | 1 | |
905 | cc | 0 | 1 | |
906 | bcc | 0 | 1 | |
907 | message-id | 0* | 1 | SHOULD be present - see |
908 | | | | 3.6.4 |
909 | in-reply-to | 0* | 1 | SHOULD occur in some |
910 | | | | replies - see 3.6.4 |
911 | references | 0* | 1 | SHOULD occur in some |
912 | | | | replies - see 3.6.4 |
913 | subject | 0 | 1 | |
914 | comments | 0 | unlimited | |
915 | keywords | 0 | unlimited | |
916 | optional-field | 0 | unlimited | |
917 +----------------+--------+------------+----------------------------+
919 The exact interpretation of each field is described in subsequent
920 sections.
922 3.6.1. The origination date field
924 The origination date field consists of the field name "Date" followed
925 by a date-time specification.
927 orig-date = "Date:" date-time CRLF
929 The origination date specifies the date and time at which the creator
930 of the message indicated that the message was complete and ready to
931 enter the mail delivery system. For instance, this might be the time
932 that a user pushes the "send" or "submit" button in an application
933 program. In any case, it is specifically not intended to convey the
934 time that the message is actually transported, but rather the time at
935 which the human or other creator of the message has put the message
936 into its final form, ready for transport. (For example, a portable
937 computer user who is not connected to a network might queue a message
938 for delivery. The origination date is intended to contain the date
939 and time that the user queued the message, not the time when the user
940 connected to the network to send the message.)
942 3.6.2. Originator fields
944 The originator fields of a message consist of the from field, the
945 sender field (when applicable), and optionally the reply-to field.
946 The from field consists of the field name "From" and a comma-
947 separated list of one or more mailbox specifications. If the from
948 field contains more than one mailbox specification in the mailbox-
949 list, then the sender field, containing the field name "Sender" and a
950 single mailbox specification, MUST appear in the message. In either
951 case, an optional reply-to field MAY also be included, which contains
952 the field name "Reply-To" and a comma-separated list of one or more
953 addresses.
955 from = "From:" mailbox-list CRLF
957 sender = "Sender:" mailbox CRLF
959 reply-to = "Reply-To:" address-list CRLF
961 The originator fields indicate the mailbox(es) of the source of the
962 message. The "From:" field specifies the author(s) of the message,
963 that is, the mailbox(es) of the person(s) or system(s) responsible
964 for the writing of the message. The "Sender:" field specifies the
965 mailbox of the agent responsible for the actual transmission of the
966 message. For example, if a secretary were to send a message for
967 another person, the mailbox of the secretary would appear in the
968 "Sender:" field and the mailbox of the actual author would appear in
969 the "From:" field. If the originator of the message can be indicated
970 by a single mailbox and the author and transmitter are identical, the
971 "Sender:" field SHOULD NOT be used. Otherwise, both fields SHOULD
972 appear.
974 Note: The transmitter information is always present. The absence
975 of the "Sender:" field is sometimes mistakenly taken to mean that
976 the agent responsible for transmission of the message has not been
977 specified. This absence merely means that the transmitter is
978 identical to the author and is therefore not redundantly placed
979 into the "Sender:" field.
981 The originator fields also provide the information required when
982 replying to a message. When the "Reply-To:" field is present, it
983 indicates the address(es) to which the author of the message suggests
984 that replies be sent. In the absence of the "Reply-To:" field,
985 replies SHOULD by default be sent to the mailbox(es) specified in the
986 "From:" field unless otherwise specified by the person composing the
987 reply.
989 In all cases, the "From:" field SHOULD NOT contain any mailbox that
990 does not belong to the author(s) of the message. See also section
991 3.6.3 for more information on forming the destination addresses for a
992 reply.
994 3.6.3. Destination address fields
996 The destination fields of a message consist of three possible fields,
997 each of the same form: The field name, which is either "To", "Cc", or
998 "Bcc", followed by a comma-separated list of one or more addresses
999 (either mailbox or group syntax).
1001 to = "To:" address-list CRLF
1003 cc = "Cc:" address-list CRLF
1005 bcc = "Bcc:" [address-list / CFWS] CRLF
1007 The destination fields specify the recipients of the message. Each
1008 destination field may have one or more addresses, and the addresses
1009 indicate the intended recipients of the message. The only difference
1010 between the three fields is how each is used.
1012 The "To:" field contains the address(es) of the primary recipient(s)
1013 of the message.
1015 The "Cc:" field (where the "Cc" means "Carbon Copy" in the sense of
1016 making a copy on a typewriter using carbon paper) contains the
1017 addresses of others who are to receive the message, though the
1018 content of the message may not be directed at them.
1020 The "Bcc:" field (where the "Bcc" means "Blind Carbon Copy") contains
1021 addresses of recipients of the message whose addresses are not to be
1022 revealed to other recipients of the message. There are three ways in
1023 which the "Bcc:" field is used. In the first case, when a message
1024 containing a "Bcc:" field is prepared to be sent, the "Bcc:" line is
1025 removed even though all of the recipients (including those specified
1026 in the "Bcc:" field) are sent a copy of the message. In the second
1027 case, recipients specified in the "To:" and "Cc:" lines each are sent
1028 a copy of the message with the "Bcc:" line removed as above, but the
1029 recipients on the "Bcc:" line get a separate copy of the message
1030 containing a "Bcc:" line. (When there are multiple recipient
1031 addresses in the "Bcc:" field, some implementations actually send a
1032 separate copy of the message to each recipient with a "Bcc:"
1033 containing only the address of that particular recipient.) Finally,
1034 since a "Bcc:" field may contain no addresses, a "Bcc:" field can be
1035 sent without any addresses indicating to the recipients that blind
1036 copies were sent to someone. Which method to use with "Bcc:" fields
1037 is implementation dependent, but refer to the "Security
1038 Considerations" section of this document for a discussion of each.
1040 When a message is a reply to another message, the mailboxes of the
1041 authors of the original message (the mailboxes in the "From:" field)
1042 or mailboxes specified in the "Reply-To:" field (if it exists) MAY
1043 appear in the "To:" field of the reply since these would normally be
1044 the primary recipients of the reply. If a reply is sent to a message
1045 that has destination fields, it is often desirable to send a copy of
1046 the reply to all of the recipients of the message, in addition to the
1047 author. When such a reply is formed, addresses in the "To:" and
1048 "Cc:" fields of the original message MAY appear in the "Cc:" field of
1049 the reply, since these are normally secondary recipients of the
1050 reply. If a "Bcc:" field is present in the original message,
1051 addresses in that field MAY appear in the "Bcc:" field of the reply,
1052 but SHOULD NOT appear in the "To:" or "Cc:" fields.
1054 Note: Some mail applications have automatic reply commands that
1055 include the destination addresses of the original message in the
1056 destination addresses of the reply. How those reply commands
1057 behave is implementation dependent and is beyond the scope of this
1058 document. In particular, whether or not to include the original
1059 destination addresses when the original message had a "Reply-To:"
1060 field is not addressed here.
1062 3.6.4. Identification fields
1064 Though listed as optional in the table in section 3.6, every message
1065 SHOULD have a "Message-ID:" field. Furthermore, reply messages
1066 SHOULD have "In-Reply-To:" and "References:" fields as appropriate
1067 and as described below.
1069 The "Message-ID:" field contains a single unique message identifier.
1070 The "References:" and "In-Reply-To:" field each contain one or more
1071 unique message identifiers, optionally separated by CFWS.
1073 The message identifier (msg-id) syntax is a limited version of the
1074 addr-spec construct enclosed in the angle bracket characters, "<" and
1075 ">". Unlike addr-spec, this syntax only permits the dot-atom-text
1076 form on the left hand side of the "@" and does not have internal CFWS
1077 anywhere in the message identifier.
1079 Note: As with addr-spec, a liberal syntax is given for the right
1080 hand side of the "@" in a msg-id. However, later in this section,
1081 the use of a domain for the right hand side of the "@" is
1082 RECOMMENDED. Again, the syntax of domain constructs is specified
1083 by and used in other protocols (e.g., [RFC1034], [RFC1035],
1084 [RFC1123], [I-D.klensin-rfc2821bis]). It is therefore incumbent
1085 upon implementations to conform to the syntax of addresses for the
1086 context in which they are used.
1088 message-id = "Message-ID:" msg-id CRLF
1090 in-reply-to = "In-Reply-To:" 1*msg-id CRLF
1092 references = "References:" 1*msg-id CRLF
1094 msg-id = [CFWS] "<" id-left "@" id-right ">" [CFWS]
1096 id-left = dot-atom-text / obs-id-left
1098 id-right = dot-atom-text / no-fold-literal / obs-id-right
1100 no-fold-literal = "[" *dtext "]"
1102 The "Message-ID:" field provides a unique message identifier that
1103 refers to a particular version of a particular message. The
1104 uniqueness of the message identifier is guaranteed by the host that
1105 generates it (see below). This message identifier is intended to be
1106 machine readable and not necessarily meaningful to humans. A message
1107 identifier pertains to exactly one version of a particular message;
1108 subsequent revisions to the message each receive new message
1109 identifiers.
1111 Note: There are many instances when messages are "changed", but
1112 those changes do not constitute a new instantiation of that
1113 message, and therefore the message would not get a new message
1114 identifier. For example, when messages are introduced into the
1115 transport system, they are often prepended with additional header
1116 fields such as trace fields (described in section 3.6.7) and
1117 resent fields (described in section 3.6.6). The addition of such
1118 header fields does not change the identity of the message and
1119 therefore the original "Message-ID:" field is retained. In all
1120 cases, it is the meaning that the sender of the message wishes to
1121 convey (i.e., whether this is the same message or a different
1122 message) that determines whether or not the "Message-ID:" field
1123 changes, not any particular syntactic difference that appears (or
1124 does not appear) in the message.
1126 The "In-Reply-To:" and "References:" fields are used when creating a
1127 reply to a message. They hold the message identifier of the original
1128 message and the message identifiers of other messages (for example,
1129 in the case of a reply to a message which was itself a reply). The
1130 "In-Reply-To:" field may be used to identify the message (or
1131 messages) to which the new message is a reply, while the
1132 "References:" field may be used to identify a "thread" of
1133 conversation.
1135 When creating a reply to a message, the "In-Reply-To:" and
1136 "References:" fields of the resultant message are constructed as
1137 follows:
1139 The "In-Reply-To:" field will contain the contents of the
1140 "Message-ID:" field of the message to which this one is a reply (the
1141 "parent message"). If there is more than one parent message, then
1142 the "In-Reply-To:" field will contain the contents of all of the
1143 parents' "Message-ID:" fields. If there is no "Message-ID:" field in
1144 any of the parent messages, then the new message will have no "In-
1145 Reply-To:" field.
1147 The "References:" field will contain the contents of the parent's
1148 "References:" field (if any) followed by the contents of the parent's
1149 "Message-ID:" field (if any). If the parent message does not contain
1150 a "References:" field but does have an "In-Reply-To:" field
1151 containing a single message identifier, then the "References:" field
1152 will contain the contents of the parent's "In-Reply-To:" field
1153 followed by the contents of the parent's "Message-ID:" field (if
1154 any). If the parent has none of the "References:", "In-Reply-To:",
1155 or "Message-ID:" fields, then the new message will have no
1156 "References:" field.
1158 Note: Some implementations parse the "References:" field to
1159 display the "thread of the discussion". These implementations
1160 assume that each new message is a reply to a single parent and
1161 hence that they can walk backwards through the "References:" field
1162 to find the parent of each message listed there. Therefore,
1163 trying to form a "References:" field for a reply that has multiple
1164 parents is discouraged and how to do so is not defined in this
1165 document.
1167 The message identifier (msg-id) itself MUST be a globally unique
1168 identifier for a message. The generator of the message identifier
1169 MUST guarantee that the msg-id is unique. There are several
1170 algorithms that can be used to accomplish this. Since the msg-id has
1171 a similar syntax to addr-spec (identical except that quoted strings,
1172 comments and folding white space are not allowed), a good method is
1173 to put the domain name (or a domain literal IP address) of the host
1174 on which the message identifier was created on the right hand side of
1175 the "@" (since domain names and IP addresses are normally unique),
1176 and put a combination of the current absolute date and time along
1177 with some other currently unique (perhaps sequential) identifier
1178 available on the system (for example, a process id number) on the
1179 left hand side. Though other algorithms will work, it is RECOMMENDED
1180 that the right hand side contain some domain identifier (either of
1181 the host itself or otherwise) such that the generator of the message
1182 identifier can guarantee the uniqueness of the left hand side within
1183 the scope of that domain.
1185 Semantically, the angle bracket characters are not part of the
1186 msg-id; the msg-id is what is contained between the two angle bracket
1187 characters.
1189 3.6.5. Informational fields
1191 The informational fields are all optional. The "Subject:" and
1192 "Comments:" fields are unstructured fields as defined in section
1193 2.2.1, and therefore may contain text or folding white space. The
1194 "Keywords:" field contains a comma-separated list of one or more
1195 words or quoted-strings.
1197 subject = "Subject:" unstructured CRLF
1199 comments = "Comments:" unstructured CRLF
1201 keywords = "Keywords:" phrase *("," phrase) CRLF
1203 These three fields are intended to have only human-readable content
1204 with information about the message. The "Subject:" field is the most
1205 common and contains a short string identifying the topic of the
1206 message. When used in a reply, the field body MAY start with the
1207 string "Re: " (an abbreviation of the Latin "in re", meaning "in the
1208 matter of") followed by the contents of the "Subject:" field body of
1209 the original message. If this is done, only one instance of the
1210 literal string "Re: " ought to be used since use of other strings or
1211 more than one instance can lead to undesirable consequences. The
1212 "Comments:" field contains any additional comments on the text of the
1213 body of the message. The "Keywords:" field contains a comma-
1214 separated list of important words and phrases that might be useful
1215 for the recipient.
1217 3.6.6. Resent fields
1219 Resent fields SHOULD be added to any message that is reintroduced by
1220 a user into the transport system. A separate set of resent fields
1221 SHOULD be added each time this is done. All of the resent fields
1222 corresponding to a particular resending of the message SHOULD be
1223 together. Each new set of resent fields is prepended to the message;
1224 that is, the most recent set of resent fields appears earlier in the
1225 message. No other fields in the message are changed when resent
1226 fields are added.
1228 Each of the resent fields corresponds to a particular field elsewhere
1229 in the syntax. For instance, the "Resent-Date:" field corresponds to
1230 the "Date:" field and the "Resent-To:" field corresponds to the "To:"
1231 field. In each case, the syntax for the field body is identical to
1232 the syntax given previously for the corresponding field.
1234 When resent fields are used, the "Resent-From:" and "Resent-Date:"
1235 fields MUST be sent. The "Resent-Message-ID:" field SHOULD be sent.
1236 "Resent-Sender:" SHOULD NOT be used if "Resent-Sender:" would be
1237 identical to "Resent-From:".
1239 resent-date = "Resent-Date:" date-time CRLF
1241 resent-from = "Resent-From:" mailbox-list CRLF
1243 resent-sender = "Resent-Sender:" mailbox CRLF
1245 resent-to = "Resent-To:" address-list CRLF
1247 resent-cc = "Resent-Cc:" address-list CRLF
1249 resent-bcc = "Resent-Bcc:" [address-list / CFWS] CRLF
1251 resent-msg-id = "Resent-Message-ID:" msg-id CRLF
1253 Resent fields are used to identify a message as having been
1254 reintroduced into the transport system by a user. The purpose of
1255 using resent fields is to have the message appear to the final
1256 recipient as if it were sent directly by the original sender, with
1257 all of the original fields remaining the same. Each set of resent
1258 fields correspond to a particular resending event. That is, if a
1259 message is resent multiple times, each set of resent fields gives
1260 identifying information for each individual time. Resent fields are
1261 strictly informational. They MUST NOT be used in the normal
1262 processing of replies or other such automatic actions on messages.
1264 Note: Reintroducing a message into the transport system and using
1265 resent fields is a different operation from "forwarding".
1266 "Forwarding" has two meanings: One sense of forwarding is that a
1267 mail reading program can be told by a user to forward a copy of a
1268 message to another person, making the forwarded message the body
1269 of the new message. A forwarded message in this sense does not
1270 appear to have come from the original sender, but is an entirely
1271 new message from the forwarder of the message. Forwarding may
1272 also mean that a mail transport program gets a message and
1273 forwards it on to a different destination for final delivery.
1274 Resent header fields are not intended for use with either type of
1275 forwarding.
1277 The resent originator fields indicate the mailbox of the person(s) or
1278 system(s) that resent the message. As with the regular originator
1279 fields, there are two forms: a simple "Resent-From:" form which
1280 contains the mailbox of the individual doing the resending, and the
1281 more complex form, when one individual (identified in the "Resent-
1282 Sender:" field) resends a message on behalf of one or more others
1283 (identified in the "Resent-From:" field).
1285 Note: When replying to a resent message, replies behave just as
1286 they would with any other message, using the original "From:",
1287 "Reply-To:", "Message-ID:", and other fields. The resent fields
1288 are only informational and MUST NOT be used in the normal
1289 processing of replies.
1291 The "Resent-Date:" indicates the date and time at which the resent
1292 message is dispatched by the resender of the message. Like the
1293 "Date:" field, it is not the date and time that the message was
1294 actually transported.
1296 The "Resent-To:", "Resent-Cc:", and "Resent-Bcc:" fields function
1297 identically to the "To:", "Cc:", and "Bcc:" fields respectively,
1298 except that they indicate the recipients of the resent message, not
1299 the recipients of the original message.
1301 The "Resent-Message-ID:" field provides a unique identifier for the
1302 resent message.
1304 3.6.7. Trace fields
1306 The trace fields are a group of header fields consisting of an
1307 optional "Return-Path:" field, and one or more "Received:" fields.
1308 The "Return-Path:" header field contains a pair of angle brackets
1309 that enclose an optional addr-spec. The "Received:" field contains a
1310 (possibly empty) list of tokens followed by a semicolon and a date-
1311 time specification. Each token must be a word, angle-addr, addr-
1312 spec, or a domain. Further restrictions are applied to the syntax of
1313 the trace fields by specifications that provide for their use, such
1314 as [I-D.klensin-rfc2821bis].
1316 trace = [return]
1317 1*received
1319 return = "Return-Path:" path CRLF
1321 path = angle-addr / ([CFWS] "<" [CFWS] ">" [CFWS])
1323 received = "Received:" *received-token ";" date-time CRLF
1325 received-token = word / angle-addr / addr-spec / domain
1327 A full discussion of the Internet mail use of trace fields is
1328 contained in [I-D.klensin-rfc2821bis]. For the purposes of this
1329 specification, the trace fields are strictly informational, and any
1330 formal interpretation of them is outside of the scope of this
1331 document.
1333 3.6.8. Optional fields
1335 Fields may appear in messages that are otherwise unspecified in this
1336 document. They MUST conform to the syntax of an optional-field.
1337 This is a field name, made up of the printable US-ASCII characters
1338 except SP and colon, followed by a colon, followed by any text which
1339 conforms to unstructured.
1341 The field names of any optional-field MUST NOT be identical to any
1342 field name specified elsewhere in this document.
1344 optional-field = field-name ":" unstructured CRLF
1346 field-name = 1*ftext
1348 ftext = %d33-57 / ; Printable US-ASCII
1349 %d59-126 ; characters not including
1350 ; ":".
1352 For the purposes of this specification, any optional field is
1353 uninterpreted.
1355 4. Obsolete Syntax
1357 Earlier versions of this specification allowed for different (usually
1358 more liberal) syntax than is allowed in this version. Also, there
1359 have been syntactic elements used in messages on the Internet whose
1360 interpretations have never been documented. Though these syntactic
1361 forms MUST NOT be generated according to the grammar in section 3,
1362 they MUST be accepted and parsed by a conformant receiver. This
1363 section documents many of these syntactic elements. Taking the
1364 grammar in section 3 and adding the definitions presented in this
1365 section will result in the grammar to use for the interpretation of
1366 messages.
1368 Note: This section identifies syntactic forms that any
1369 implementation MUST reasonably interpret. However, there are
1370 certainly Internet messages which do not conform to even the
1371 additional syntax given in this section. The fact that a
1372 particular form does not appear in any section of this document is
1373 not justification for computer programs to crash or for malformed
1374 data to be irretrievably lost by any implementation. It is up to
1375 the implementation to deal with messages robustly.
1377 One important difference between the obsolete (interpreting) and the
1378 current (generating) syntax is that in structured header field bodies
1379 (i.e., between the colon and the CRLF of any structured header
1380 field), white space characters, including folding white space, and
1381 comments could be freely inserted between any syntactic tokens. This
1382 allowed many complex forms that have proven difficult for some
1383 implementations to parse.
1385 Another key difference between the obsolete and the current syntax is
1386 that the rule in section 3.2.2 regarding lines composed entirely of
1387 white space in comments and folding white space does not apply. See
1388 the discussion of folding white space in section 4.2 below.
1390 Finally, certain characters that were formerly allowed in messages
1391 appear in this section. The NUL character (ASCII value 0) was once
1392 allowed, but is no longer for compatibility reasons. Similarly, US-
1393 ASCII control characters other than CR, LF, SP, and HTAB (ASCII
1394 values 1 through 8, 11, 12, 14 through 31, and 127) were allowed to
1395 appear in header field bodies. CR and LF were allowed to appear in
1396 messages other than as CRLF; this use is also shown here.
1398 Other differences in syntax and semantics are noted in the following
1399 sections.
1401 4.1. Miscellaneous obsolete tokens
1403 These syntactic elements are used elsewhere in the obsolete syntax or
1404 in the main syntax. Bare CR, bare LF, and NUL are added to obs-qp,
1405 obs-body and obs-unstruct. US-ASCII control characters are added to
1406 obs-qp, obs-unstruct, obs-ctext, and obs-qtext. The period character
1407 is added to obs-phrase. The obs-phrase-list provides for a
1408 (potentially empty) comma-separated list of phrases which may include
1409 "null" elements. That is, there could be two or more commas in such
1410 a list with nothing in between them, or commas at the beginning or
1411 end of the list.
1413 Note: The "period" (or "full stop") character (".") in obs-phrase
1414 is not a form that was allowed in earlier versions of this or any
1415 other specification. Period (nor any other character from
1416 specials) was not allowed in phrase because it introduced a
1417 parsing difficulty distinguishing between phrases and portions of
1418 an addr-spec (see section 4.4). It appears here because the
1419 period character is currently used in many messages in the
1420 display-name portion of addresses, especially for initials in
1421 names, and therefore must be interpreted properly.
1423 obs-NO-WS-CTL = %d1-8 / ; US-ASCII control
1424 %d11 / ; characters that do not
1425 %d12 / ; include the carriage
1426 %d14-31 / ; return, line feed, and
1427 %d127 ; white space characters
1429 obs-ctext = obs-NO-WS-CTL
1431 obs-qtext = obs-NO-WS-CTL
1433 obs-utext = %d0 / obs-NO-WS-CTL / VCHAR
1435 obs-qp = "\" (%d0 / obs-NO-WS-CTL / LF / CR)
1437 obs-body = *((*LF *CR *((%d0 / text) *LF *CR)) / CRLF)
1439 obs-unstruct = *((*LF *CR *(obs-utext *LF *CR)) / FWS)
1441 obs-phrase = word *(word / "." / CFWS)
1443 obs-phrase-list = [phrase / CFWS] *("," [phrase / CFWS])
1445 Bare CR and bare LF appear in messages with two different meanings.
1446 In many cases, bare CR or bare LF are used improperly instead of CRLF
1447 to indicate line separators. In other cases, bare CR and bare LF are
1448 used simply as US-ASCII control characters with their traditional
1449 ASCII meanings.
1451 4.2. Obsolete folding white space
1453 In the obsolete syntax, any amount of folding white space MAY be
1454 inserted where the obs-FWS rule is allowed. This creates the
1455 possibility of having two consecutive "folds" in a line, and
1456 therefore the possibility that a line which makes up a folded header
1457 field could be composed entirely of white space.
1459 obs-FWS = 1*WSP *(CRLF 1*WSP)
1461 4.3. Obsolete Date and Time
1463 The syntax for the obsolete date format allows a 2 digit year in the
1464 date field and allows for a list of alphabetic time zone specifiers
1465 that were used in earlier versions of this specification. It also
1466 permits comments and folding white space between many of the tokens.
1468 obs-day-of-week = [CFWS] day-name [CFWS]
1470 obs-day = [CFWS] 1*2DIGIT [CFWS]
1472 obs-year = [CFWS] 2*DIGIT [CFWS]
1474 obs-hour = [CFWS] 2DIGIT [CFWS]
1476 obs-minute = [CFWS] 2DIGIT [CFWS]
1478 obs-second = [CFWS] 2DIGIT [CFWS]
1480 obs-zone = "UT" / "GMT" / ; Universal Time
1481 ; North American UT
1482 ; offsets
1483 "EST" / "EDT" / ; Eastern: - 5/ - 4
1484 "CST" / "CDT" / ; Central: - 6/ - 5
1485 "MST" / "MDT" / ; Mountain: - 7/ - 6
1486 "PST" / "PDT" / ; Pacific: - 8/ - 7
1487 ;
1488 %d65-73 / ; Military zones - "A"
1489 %d75-90 / ; through "I" and "K"
1490 %d97-105 / ; through "Z", both
1491 %d107-122 ; upper and lower case
1493 Where a two or three digit year occurs in a date, the year is to be
1494 interpreted as follows: If a two digit year is encountered whose
1495 value is between 00 and 49, the year is interpreted by adding 2000,
1496 ending up with a value between 2000 and 2049. If a two digit year is
1497 encountered with a value between 50 and 99, or any three digit year
1498 is encountered, the year is interpreted by adding 1900.
1500 In the obsolete time zone, "UT" and "GMT" are indications of
1501 "Universal Time" and "Greenwich Mean Time" respectively and are both
1502 semantically identical to "+0000".
1504 The remaining three character zones are the US time zones. The first
1505 letter, "E", "C", "M", or "P" stands for "Eastern", "Central",
1506 "Mountain" and "Pacific". The second letter is either "S" for
1507 "Standard" time, or "D" for "Daylight Savings" (or summer) time.
1508 Their interpretations are as follows:
1510 EDT is semantically equivalent to -0400
1511 EST is semantically equivalent to -0500
1512 CDT is semantically equivalent to -0500
1513 CST is semantically equivalent to -0600
1514 MDT is semantically equivalent to -0600
1515 MST is semantically equivalent to -0700
1516 PDT is semantically equivalent to -0700
1517 PST is semantically equivalent to -0800
1519 The 1 character military time zones were defined in a non-standard
1520 way in [RFC0822] and are therefore unpredictable in their meaning.
1521 The original definitions of the military zones "A" through "I" are
1522 equivalent to "+0100" through "+0900" respectively; "K", "L", and "M"
1523 are equivalent to "+1000", "+1100", and "+1200" respectively; "N"
1524 through "Y" are equivalent to "-0100" through "-1200" respectively;
1525 and "Z" is equivalent to "+0000". However, because of the error in
1526 [RFC0822], they SHOULD all be considered equivalent to "-0000" unless
1527 there is out-of-band information confirming their meaning.
1529 Other multi-character (usually between 3 and 5) alphabetic time zones
1530 have been used in Internet messages. Any such time zone whose
1531 meaning is not known SHOULD be considered equivalent to "-0000"
1532 unless there is out-of-band information confirming their meaning.
1534 4.4. Obsolete Addressing
1536 There are four primary differences in addressing. First, mailbox
1537 addresses were allowed to have a route portion before the addr-spec
1538 when enclosed in "<" and ">". The route is simply a comma-separated
1539 list of domain names, each preceded by "@", and the list terminated
1540 by a colon. Second, CFWS were allowed between the period-separated
1541 elements of local-part and domain (i.e., dot-atom was not used). In
1542 addition, local-part is allowed to contain quoted-string in addition
1543 to just atom. Third, mailbox-list and address-list were allowed to
1544 have "null" members. That is, there could be two or more commas in
1545 such a list with nothing in between them, or commas at the beginning
1546 or end of the list. Finally, US-ASCII control characters and quoted-
1547 pairs were allowed in domain literals and are added here.
1549 obs-angle-addr = [CFWS] "<" obs-route addr-spec ">" [CFWS]
1551 obs-route = obs-domain-list ":"
1553 obs-domain-list = *(CFWS / ",") "@" domain
1554 *("," [CFWS] ["@" domain])
1556 obs-mbox-list = *([CFWS] ",") mailbox *("," [mailbox / CFWS])
1558 obs-addr-list = *([CFWS] ",") address *("," [address / CFWS])
1560 obs-group-list = 1*([CFWS] ",") [CFWS]
1562 obs-local-part = word *("." word)
1564 obs-domain = atom *("." atom)
1566 obs-dtext = obs-NO-WS-CTL / quoted-pair
1568 When interpreting addresses, the route portion SHOULD be ignored.
1570 4.5. Obsolete header fields
1572 Syntactically, the primary difference in the obsolete field syntax is
1573 that it allows multiple occurrences of any of the fields and they may
1574 occur in any order. Also, any amount of white space is allowed
1575 before the ":" at the end of the field name.
1577 obs-fields = *(obs-return /
1578 obs-received /
1579 obs-orig-date /
1580 obs-from /
1581 obs-sender /
1582 obs-reply-to /
1583 obs-to /
1584 obs-cc /
1585 obs-bcc /
1586 obs-message-id /
1587 obs-in-reply-to /
1588 obs-references /
1589 obs-subject /
1590 obs-comments /
1591 obs-keywords /
1592 obs-resent-date /
1593 obs-resent-from /
1594 obs-resent-send /
1595 obs-resent-rply /
1596 obs-resent-to /
1597 obs-resent-cc /
1598 obs-resent-bcc /
1599 obs-resent-mid /
1600 obs-optional)
1602 Except for destination address fields (described in section 4.5.3),
1603 the interpretation of multiple occurrences of fields is unspecified.
1604 Also, the interpretation of trace fields and resent fields which do
1605 not occur in blocks prepended to the message is unspecified as well.
1606 Unless otherwise noted in the following sections, interpretation of
1607 other fields is identical to the interpretation of their non-obsolete
1608 counterparts in section 3.
1610 4.5.1. Obsolete origination date field
1612 obs-orig-date = "Date" *WSP ":" date-time CRLF
1614 4.5.2. Obsolete originator fields
1616 obs-from = "From" *WSP ":" mailbox-list CRLF
1618 obs-sender = "Sender" *WSP ":" mailbox CRLF
1620 obs-reply-to = "Reply-To" *WSP ":" address-list CRLF
1622 4.5.3. Obsolete destination address fields
1624 obs-to = "To" *WSP ":" address-list CRLF
1626 obs-cc = "Cc" *WSP ":" address-list CRLF
1628 obs-bcc = "Bcc" *WSP ":"
1629 address-list / (*([CFWS] ",") [CFWS]) CRLF
1631 When multiple occurrences of destination address fields occur in a
1632 message, they SHOULD be treated as if the address-list in the first
1633 occurrence of the field is combined with the address lists of the
1634 subsequent occurrences by adding a comma and concatenating.
1636 4.5.4. Obsolete identification fields
1638 The obsolete "In-Reply-To:" and "References:" fields differ from the
1639 current syntax in that they allow phrase (words or quoted strings) to
1640 appear. The obsolete forms of the left and right sides of msg-id
1641 allow interspersed CFWS, making them syntactically identical to
1642 local-part and domain respectively.
1644 obs-message-id = "Message-ID" *WSP ":" msg-id CRLF
1646 obs-in-reply-to = "In-Reply-To" *WSP ":" *(phrase / msg-id) CRLF
1648 obs-references = "References" *WSP ":" *(phrase / msg-id) CRLF
1650 obs-id-left = local-part
1652 obs-id-right = domain
1654 For purposes of interpretation, the phrases in the "In-Reply-To:" and
1655 "References:" fields are ignored.
1657 Semantically, none of the optional CFWS in the local-part and the
1658 domain is part of the obs-id-left and obs-id-right respectively.
1660 4.5.5. Obsolete informational fields
1662 obs-subject = "Subject" *WSP ":" unstructured CRLF
1664 obs-comments = "Comments" *WSP ":" unstructured CRLF
1666 obs-keywords = "Keywords" *WSP ":" obs-phrase-list CRLF
1668 4.5.6. Obsolete resent fields
1670 The obsolete syntax adds a "Resent-Reply-To:" field, which consists
1671 of the field name, the optional comments and folding white space, the
1672 colon, and a comma separated list of addresses.
1674 obs-resent-from = "Resent-From" *WSP ":" mailbox-list CRLF
1676 obs-resent-send = "Resent-Sender" *WSP ":" mailbox CRLF
1678 obs-resent-date = "Resent-Date" *WSP ":" date-time CRLF
1680 obs-resent-to = "Resent-To" *WSP ":" address-list CRLF
1682 obs-resent-cc = "Resent-Cc" *WSP ":" address-list CRLF
1684 obs-resent-bcc = "Resent-Bcc" *WSP ":"
1685 address-list / (*([CFWS] ",") [CFWS]) CRLF
1687 obs-resent-mid = "Resent-Message-ID" *WSP ":" msg-id CRLF
1689 obs-resent-rply = "Resent-Reply-To" *WSP ":" address-list CRLF
1691 As with other resent fields, the "Resent-Reply-To:" field is to be
1692 treated as trace information only.
1694 4.5.7. Obsolete trace fields
1696 The obs-return and obs-received are again given here as template
1697 definitions, just as return and received are in section 3. Their
1698 full syntax is given in [I-D.klensin-rfc2821bis].
1700 obs-return = "Return-Path" *WSP ":" path CRLF
1702 obs-received = "Received" *WSP ":" *received-token CRLF
1704 4.5.8. Obsolete optional fields
1706 obs-optional = field-name *WSP ":" unstructured CRLF
1708 5. Security Considerations
1710 Care needs to be taken when displaying messages on a terminal or
1711 terminal emulator. Powerful terminals may act on escape sequences
1712 and other combinations of US-ASCII control characters with a variety
1713 of consequences. They can remap the keyboard or permit other
1714 modifications to the terminal which could lead to denial of service
1715 or even damaged data. They can trigger (sometimes programmable)
1716 answerback messages which can allow a message to cause commands to be
1717 issued on the recipient's behalf. They can also affect the operation
1718 of terminal attached devices such as printers. Message viewers may
1719 wish to strip potentially dangerous terminal escape sequences from
1720 the message prior to display. However, other escape sequences appear
1721 in messages for useful purposes (cf. [ISO.2022.1994], [RFC2045],
1722 [RFC2046], [RFC2047], [RFC2049], [RFC4288], [RFC4289]) and therefore
1723 should not be stripped indiscriminately.
1725 Transmission of non-text objects in messages raises additional
1726 security issues. These issues are discussed in [RFC2045], [RFC2046],
1727 [RFC2047], [RFC2049], [RFC4288], and [RFC4289].
1729 Many implementations use the "Bcc:" (blind carbon copy) field
1730 described in section 3.6.3 to facilitate sending messages to
1731 recipients without revealing the addresses of one or more of the
1732 addressees to the other recipients. Mishandling this use of "Bcc:"
1733 may disclose confidential information which could eventually lead to
1734 security problems through knowledge of even the existence of a
1735 particular mail address. For example, if using the first method
1736 described in section 3.6.3, where the "Bcc:" line is removed from the
1737 message, blind recipients have no explicit indication that they have
1738 been sent a blind copy, except insofar as their address does not
1739 appear in the header section of a message . Because of this, one of
1740 the blind addressees could potentially send a reply to all of the
1741 shown recipients and accidentally reveal that the message went to the
1742 blind recipient. When the second method from section 3.6.3 is used,
1743 the blind recipient's address appears in the "Bcc:" field of a
1744 separate copy of the message. If the "Bcc:" field sent contains all
1745 of the blind addressees, all of the "Bcc:" recipients will be seen by
1746 each "Bcc:" recipient. Even if a separate message is sent to each
1747 "Bcc:" recipient with only the individual's address, implementations
1748 still need to be careful to process replies to the message as per
1749 section 3.6.3 so as not to accidentally reveal the blind recipient to
1750 other recipients.
1752 6. IANA Considerations
1754 This document updates the registrations that appeared in [RFC4021]
1755 which referred to the definitions in [RFC2822]. IANA is requested to
1756 update the Permanent Message Header Field Repository with the
1757 following header fields, in accordance with the procedures set out in
1758 [RFC3864].
1760 Header field name: Date
1761 Applicable protocol: Mail
1762 Status: standard
1763 Author/Change controller: IETF
1764 Specification document(s): This document (section 3.6.1)
1766 Header field name: From
1767 Applicable protocol: Mail
1768 Status: standard
1769 Author/Change controller: IETF
1770 Specification document(s): This document (section 3.6.2)
1772 Header field name: Sender
1773 Applicable protocol: Mail
1774 Status: standard
1775 Author/Change controller: IETF
1776 Specification document(s): This document (section 3.6.2)
1778 Header field name: Reply-To
1779 Applicable protocol: Mail
1780 Status: standard
1781 Author/Change controller: IETF
1782 Specification document(s): This document (section 3.6.2)
1784 Header field name: To
1785 Applicable protocol: Mail
1786 Status: standard
1787 Author/Change controller: IETF
1788 Specification document(s): This document (section 3.6.3)
1790 Header field name: Cc
1791 Applicable protocol: Mail
1792 Status: standard
1793 Author/Change controller: IETF
1794 Specification document(s): This document (section 3.6.3)
1796 Header field name: Bcc
1797 Applicable protocol: Mail
1798 Status: standard
1799 Author/Change controller: IETF
1800 Specification document(s): This document (section 3.6.3)
1802 Header field name: Message-ID
1803 Applicable protocol: Mail
1804 Status: standard
1805 Author/Change controller: IETF
1806 Specification document(s): This document (section 3.6.4)
1808 Header field name: In-Reply-To
1809 Applicable protocol: Mail
1810 Status: standard
1811 Author/Change controller: IETF
1812 Specification document(s): This document (section 3.6.4)
1814 Header field name: References
1815 Applicable protocol: Mail
1816 Status: standard
1817 Author/Change controller: IETF
1818 Specification document(s): This document (section 3.6.4)
1820 Header field name: Subject
1821 Applicable protocol: Mail
1822 Status: standard
1823 Author/Change controller: IETF
1824 Specification document(s): This document (section 3.6.5)
1826 Header field name: Comments
1827 Applicable protocol: Mail
1828 Status: standard
1829 Author/Change controller: IETF
1830 Specification document(s): This document (section 3.6.5)
1832 Header field name: Keywords
1833 Applicable protocol: Mail
1834 Status: standard
1835 Author/Change controller: IETF
1836 Specification document(s): This document (section 3.6.5)
1838 Header field name: Resent-Date
1839 Applicable protocol: Mail
1840 Status: standard
1841 Author/Change controller: IETF
1842 Specification document(s): This document (section 3.6.6)
1844 Header field name: Resent-From
1845 Applicable protocol: Mail
1846 Status: standard
1847 Author/Change controller: IETF
1848 Specification document(s): This document (section 3.6.6)
1850 Header field name: Resent-Sender
1851 Applicable protocol: Mail
1852 Status: standard
1853 Author/Change controller: IETF
1854 Specification document(s): This document (section 3.6.6)
1856 Header field name: Resent-To
1857 Applicable protocol: Mail
1858 Status: standard
1859 Author/Change controller: IETF
1860 Specification document(s): This document (section 3.6.6)
1862 Header field name: Resent-Cc
1863 Applicable protocol: Mail
1864 Status: standard
1865 Author/Change controller: IETF
1866 Specification document(s): This document (section 3.6.6)
1868 Header field name: Resent-Bcc
1869 Applicable protocol: Mail
1870 Status: standard
1871 Author/Change controller: IETF
1872 Specification document(s): This document (section 3.6.6)
1874 Header field name: Resent-Reply-To
1875 Applicable protocol: Mail
1876 Status: obsolete
1877 Author/Change controller: IETF
1878 Specification document(s): This document (section 4.5.6)
1880 Header field name: Resent-Message-ID
1881 Applicable protocol: Mail
1882 Status: standard
1883 Author/Change controller: IETF
1884 Specification document(s): This document (section 3.6.6)
1886 Header field name: Return-Path
1887 Applicable protocol: Mail
1888 Status: standard
1889 Author/Change controller: IETF
1890 Specification document(s): This document (section 3.6.7)
1891 Header field name: Received
1892 Applicable protocol: Mail
1893 Status: standard
1894 Author/Change controller: IETF
1895 Specification document(s): This document (section 3.6.7)
1896 Related information: [I-D.klensin-rfc2821bis]
1898 Appendix A. Example messages
1900 This section presents a selection of messages. These are intended to
1901 assist in the implementation of this specification, but should not be
1902 taken as normative; that is to say, although the examples in this
1903 section were carefully reviewed, if there happens to be a conflict
1904 between these examples and the syntax described in sections 3 and 4
1905 of this document, the syntax in those sections is to be taken as
1906 correct.
1908 In the text version of this document, messages in this section are
1909 delimited between lines of "----". The "----" lines are not part of
1910 the message itself.
1912 Appendix A.1. Addressing examples
1914 The following are examples of messages that might be sent between two
1915 individuals.
1917 Appendix A.1.1. A message from one person to another with simple
1918 addressing
1920 This could be called a canonical message. It has a single author,
1921 John Doe, a single recipient, Mary Smith, a subject, the date, a
1922 message identifier, and a textual message in the body.
1924 ----
1925 From: John Doe
1926 To: Mary Smith
1927 Subject: Saying Hello
1928 Date: Fri, 21 Nov 1997 09:55:06 -0600
1929 Message-ID: <1234@local.machine.example>
1931 This is a message just to say hello.
1932 So, "Hello".
1933 ----
1934 If John's secretary Michael actually sent the message, though John
1935 was the author and replies to this message should go back to him, the
1936 sender field would be used:
1938 ----
1939 From: John Doe
1940 Sender: Michael Jones
1941 To: Mary Smith
1942 Subject: Saying Hello
1943 Date: Fri, 21 Nov 1997 09:55:06 -0600
1944 Message-ID: <1234@local.machine.example>
1946 This is a message just to say hello.
1947 So, "Hello".
1948 ----
1950 Appendix A.1.2. Different types of mailboxes
1952 This message includes multiple addresses in the destination fields
1953 and also uses several different forms of addresses.
1955 ----
1956 From: "Joe Q. Public"
1957 To: Mary Smith , jdoe@example.org, Who?
1958 Cc: , "Giant; \"Big\" Box"
1959 Date: Tue, 1 Jul 2003 10:52:37 +0200
1960 Message-ID: <5678.21-Nov-1997@example.com>
1962 Hi everyone.
1963 ----
1965 Note that the display names for Joe Q. Public and Giant; "Big" Box
1966 needed to be enclosed in double-quotes because the former contains
1967 the period and the latter contains both semicolon and double-quote
1968 characters (the double-quote characters appearing as quoted-pair
1969 constructs). Conversely, the display name for Who? could appear
1970 without them because the question mark is legal in an atom. Notice
1971 also that jdoe@example.org and boss@nil.test have no display names
1972 associated with them at all, and jdoe@example.org uses the simpler
1973 address form without the angle brackets.
1975 Appendix A.1.3. Group addresses
1977 ----
1978 From: Pete
1979 To: A Group:Ed Jones ,joe@where.test,John ;
1980 Cc: Undisclosed recipients:;
1981 Date: Thu, 13 Feb 1969 23:32:54 -0330
1982 Message-ID:
1984 Testing.
1985 ----
1987 In this message, the "To:" field has a single group recipient named
1988 "A Group" which contains 3 addresses, and a "Cc:" field with an empty
1989 group recipient named Undisclosed recipients.
1991 Appendix A.2. Reply messages
1993 The following is a series of three messages that make up a
1994 conversation thread between John and Mary. John first sends a
1995 message to Mary, Mary then replies to John's message, and then John
1996 replies to Mary's reply message.
1998 Note especially the "Message-ID:", "References:", and "In-Reply-To:"
1999 fields in each message.
2001 ----
2002 From: John Doe
2003 To: Mary Smith
2004 Subject: Saying Hello
2005 Date: Fri, 21 Nov 1997 09:55:06 -0600
2006 Message-ID: <1234@local.machine.example>
2008 This is a message just to say hello.
2009 So, "Hello".
2010 ----
2011 When sending replies, the Subject field is often retained, though
2012 prepended with "Re: " as described in section 3.6.5.
2014 ----
2015 From: Mary Smith
2016 To: John Doe
2017 Reply-To: "Mary Smith: Personal Account"
2018 Subject: Re: Saying Hello
2019 Date: Fri, 21 Nov 1997 10:01:10 -0600
2020 Message-ID: <3456@example.net>
2021 In-Reply-To: <1234@local.machine.example>
2022 References: <1234@local.machine.example>
2024 This is a reply to your hello.
2025 ----
2027 Note the "Reply-To:" field in the above message. When John replies
2028 to Mary's message above, the reply should go to the address in the
2029 "Reply-To:" field instead of the address in the "From:" field.
2031 ----
2032 To: "Mary Smith: Personal Account"
2033 From: John Doe
2034 Subject: Re: Saying Hello
2035 Date: Fri, 21 Nov 1997 11:00:00 -0600
2036 Message-ID:
2037 In-Reply-To: <3456@example.net>
2038 References: <1234@local.machine.example> <3456@example.net>
2040 This is a reply to your reply.
2041 ----
2043 Appendix A.3. Resent messages
2045 Start with the message that has been used as an example several
2046 times:
2048 ----
2049 From: John Doe
2050 To: Mary Smith
2051 Subject: Saying Hello
2052 Date: Fri, 21 Nov 1997 09:55:06 -0600
2053 Message-ID: <1234@local.machine.example>
2055 This is a message just to say hello.
2056 So, "Hello".
2057 ----
2058 Say that Mary, upon receiving this message, wishes to send a copy of
2059 the message to Jane such that (a) the message would appear to have
2060 come straight from John; (b) if Jane replies to the message, the
2061 reply should go back to John; and (c) all of the original
2062 information, like the date the message was originally sent to Mary,
2063 the message identifier, and the original addressee, is preserved. In
2064 this case, resent fields are prepended to the message:
2066 ----
2067 Resent-From: Mary Smith
2068 Resent-To: Jane Brown
2069 Resent-Date: Mon, 24 Nov 1997 14:22:01 -0800
2070 Resent-Message-ID: <78910@example.net>
2071 From: John Doe
2072 To: Mary Smith
2073 Subject: Saying Hello
2074 Date: Fri, 21 Nov 1997 09:55:06 -0600
2075 Message-ID: <1234@local.machine.example>
2077 This is a message just to say hello.
2078 So, "Hello".
2079 ----
2081 If Jane, in turn, wished to resend this message to another person,
2082 she would prepend her own set of resent header fields to the above
2083 and send that. (Note that for brevity, trace fields are not shown.)
2085 Appendix A.4. Messages with trace fields
2087 As messages are sent through the transport system as described in
2088 [I-D.klensin-rfc2821bis], trace fields are prepended to the message.
2089 The following is an example of what those trace fields might look
2090 like. Note that there is some folding white space in the first one
2091 since these lines can be long.
2093 ----
2094 Received: from x.y.test
2095 by example.net
2096 via TCP
2097 with ESMTP
2098 id ABC12345
2099 for ; 21 Nov 1997 10:05:43 -0600
2100 Received: from node.example by x.y.test; 21 Nov 1997 10:01:22 -0600
2101 From: John Doe
2102 To: Mary Smith
2103 Subject: Saying Hello
2104 Date: Fri, 21 Nov 1997 09:55:06 -0600
2105 Message-ID: <1234@local.node.example>
2107 This is a message just to say hello.
2108 So, "Hello".
2109 ----
2111 Appendix A.5. White space, comments, and other oddities
2113 White space, including folding white space, and comments can be
2114 inserted between many of the tokens of fields. Taking the example
2115 from A.1.3, white space and comments can be inserted into all of the
2116 fields.
2118 ----
2119 From: Pete(A nice \) chap)
2120 To:A Group(Some people)
2121 :Chris Jones ,
2122 joe@example.org,
2123 John (my dear friend); (the end of the group)
2124 Cc:(Empty list)(start)Hidden recipients :(nobody(that I know)) ;
2125 Date: Thu,
2126 13
2127 Feb
2128 1969
2129 23:32
2130 -0330 (Newfoundland Time)
2131 Message-ID:
2133 Testing.
2134 ----
2136 The above example is aesthetically displeasing, but perfectly legal.
2137 Note particularly (1) the comments in the "From:" field (including
2138 one that has a ")" character appearing as part of a quoted-pair); (2)
2139 the white space absent after the ":" in the "To:" field as well as
2140 the comment and folding white space after the group name, the special
2141 character (".") in the comment in Chris Jones's address, and the
2142 folding white space before and after "joe@example.org,"; (3) the
2143 multiple and nested comments in the "Cc:" field as well as the
2144 comment immediately following the ":" after "Cc"; (4) the folding
2145 white space (but no comments except at the end) and the missing
2146 seconds in the time of the date field; and (5) the white space before
2147 (but not within) the identifier in the "Message-ID:" field.
2149 Appendix A.6. Obsoleted forms
2151 The following are examples of obsolete (that is, the "MUST NOT
2152 generate") syntactic elements described in section 4 of this
2153 document.
2155 Appendix A.6.1. Obsolete addressing
2157 Note in the below example the lack of quotes around Joe Q. Public,
2158 the route that appears in the address for Mary Smith, the two commas
2159 that appear in the "To:" field, and the spaces that appear around the
2160 "." in the jdoe address.
2162 ----
2163 From: Joe Q. Public
2164 To: Mary Smith <@node.test:mary@example.net>, , jdoe@test . example
2165 Date: Tue, 1 Jul 2003 10:52:37 +0200
2166 Message-ID: <5678.21-Nov-1997@example.com>
2168 Hi everyone.
2169 ----
2171 Appendix A.6.2. Obsolete dates
2173 The following message uses an obsolete date format, including a non-
2174 numeric time zone and a two digit year. Note that although the day-
2175 of-week is missing, that is not specific to the obsolete syntax; it
2176 is optional in the current syntax as well.
2178 ----
2179 From: John Doe
2180 To: Mary Smith
2181 Subject: Saying Hello
2182 Date: 21 Nov 97 09:55:06 GMT
2183 Message-ID: <1234@local.machine.example>
2185 This is a message just to say hello.
2186 So, "Hello".
2187 ----
2189 Appendix A.6.3. Obsolete white space and comments
2191 White space and comments can appear between many more elements than
2192 in the current syntax. Also, folding lines that are made up entirely
2193 of white space are legal.
2195 ----
2196 From : John Doe
2197 To : Mary Smith
2198 __
2199
2200 Subject : Saying Hello
2201 Date : Fri, 21 Nov 1997 09(comment): 55 : 06 -0600
2202 Message-ID : <1234 @ local(blah) .machine .example>
2204 This is a message just to say hello.
2205 So, "Hello".
2206 ----
2208 Note especially the second line of the "To:" field. It starts with
2209 two space characters. (Note that "__" represent blank spaces.)
2210 Therefore, it is considered part of the folding as described in
2211 section 4.2. Also, the comments and white space throughout
2212 addresses, dates, and message identifiers are all part of the
2213 obsolete syntax.
2215 Appendix B. Differences from earlier specifications
2217 This appendix contains a list of changes that have been made in the
2218 Internet Message Format from earlier specifications, specifically
2219 [RFC0822], [RFC1123], and [RFC2822]. Items marked with an asterisk
2220 (*) below are items which appear in section 4 of this document and
2221 therefore can no longer be generated.
2223 The following are the changes made from [RFC0822] and [RFC1123] to
2224 [RFC2822] that remain in this document:
2226 1. Period allowed in obsolete form of phrase.
2227 2. ABNF moved out of document, now in [RFC5234].
2228 3. Four or more digits allowed for year.
2229 4. Header field ordering (and lack thereof) made explicit.
2230 5. Encrypted header field removed.
2231 6. Specifically allow and give meaning to "-0000" time zone.
2232 7. Folding white space is not allowed between every token.
2233 8. Requirement for destinations removed.
2234 9. Forwarding and resending redefined.
2236 10. Extension header fields no longer specifically called out.
2237 11. ASCII 0 (null) removed.*
2238 12. Folding continuation lines cannot contain only white space.*
2239 13. Free insertion of comments not allowed in date.*
2240 14. Non-numeric time zones not allowed.*
2241 15. Two digit years not allowed.*
2242 16. Three digit years interpreted, but not allowed for generation.*
2243 17. Routes in addresses not allowed.*
2244 18. CFWS within local-parts and domains not allowed.*
2245 19. Empty members of address lists not allowed.*
2246 20. Folding white space between field name and colon not allowed.*
2247 21. Comments between field name and colon not allowed.
2248 22. Tightened syntax of in-reply-to and references.*
2249 23. CFWS within msg-id not allowed.*
2250 24. Tightened semantics of resent fields as informational only.
2251 25. Resent-Reply-To not allowed.*
2252 26. No multiple occurrences of fields (except resent and received).*
2253 27. Free CR and LF not allowed.*
2254 28. Line length limits specified.
2255 29. Bcc more clearly specified.
2257 The following are changes from [RFC2822].
2258 1. Assorted typographical/grammatical errors fixed and
2259 clarifications made.
2260 2. Changed "standard" to "document" or "specification" throughout.
2261 3. Made distinction between "header field" and "header section".
2262 4. Removed NO-WS-CTL from ctext, qtext, dtext, and unstructured.*
2263 5. Moved discussion of specials to the "Atom" section. Moved text
2264 to "Overall message syntax" section.
2265 6. Simplified CFWS syntax.
2266 7. Fixed unstructured syntax.
2267 8. Changed date and time syntax to deal with white space in
2268 obsolete date syntax.
2269 9. Removed quoted-pair from domain literals.*
2270 10. Clarified that other specifications limit domain syntax.
2271 11. Simplified "Bcc:" and "Resent-Bcc:" syntax.
2272 12. Allowed optional-field to appear within trace information.
2273 13. Removed no-fold-quote from msg-id. Clarified syntax
2274 limitations.
2275 14. Generalized "Received:" syntax to fix bugs and move definition
2276 out of this document.
2277 15. Simplified obs-qp. Fixed and simplified obs-utext (which now
2278 only appears in the obsolete syntax). Removed obs-text and obs-
2279 char, adding obs-body.
2280 16. Fixed obsolete date syntax to allow for more (or less) comments
2281 and white space.
2283 17. Fixed all obsolete list syntax (obs-domain-list, obs-mbox-list,
2284 obs-addr-list, obs-phrase-list, and the newly added obs-group-
2285 list).
2286 18. Fixed obs-reply-to syntax.
2287 19. Fixed obs-bcc and obs-resent-bcc to allow empty lists.
2288 20. Removed obs-path.
2290 Appendix C. Acknowledgements
2292 Many people contributed to this document. They included folks who
2293 participated in the Detailed Revision and Update of Messaging
2294 Standards (DRUMS) Working Group of the Internet Engineering Task
2295 Force (IETF), the chair of DRUMS, the Area Directors of the IETF, and
2296 people who simply sent their comments in via e-mail. The editor is
2297 deeply indebted to them all and thanks them sincerely. The below
2298 list includes everyone who sent e-mail concerning both this document
2299 and [RFC2822]. Hopefully, everyone who contributed is named here:
2301 +--------------------+----------------------+---------------------+
2302 | Matti Aarnio | Tanaka Akira | Russ Allbery |
2303 | Eric Allman | Harald Alvestrand | Ran Atkinson |
2304 | Jos Backus | Bruce Balden | Dave Barr |
2305 | Alan Barrett | John Beck | J Robert von Behren |
2306 | Jos den Bekker | D J Bernstein | James Berriman |
2307 | Oliver Block | Norbert Bollow | Raj Bose |
2308 | Antony Bowesman | Scott Bradner | Randy Bush |
2309 | Tom Byrer | Bruce Campbell | Larry Campbell |
2310 | W J Carpenter | Michael Chapman | Richard Clayton |
2311 | Maurizio Codogno | Jim Conklin | R Kelley Cook |
2312 | Nathan Coulter | Steve Coya | Mark Crispin |
2313 | Dave Crocker | Matt Curtin | Michael D'Errico |
2314 | Cyrus Daboo | Michael D Dean | Jutta Degener |
2315 | Mark Delany | Steve Dorner | Harold A Driscoll |
2316 | Michael Elkins | Frank Ellerman | Robert Elz |
2317 | Johnny Eriksson | Erik E Fair | Roger Fajman |
2318 | Patrik Faeltstroem | Claus Andre Faerber | Barry Finkel |
2319 | Erik Forsberg | Chuck Foster | Paul Fox |
2320 | Klaus M Frank | Ned Freed | Jochen Friedrich |
2321 | Randall C Gellens | Sukvinder Singh Gill | Tim Goodwin |
2322 | Philip Guenther | Arnt Gulbrandsen | Eric A Hall |
2323 | Tony Hansen | John Hawkinson | Philip Hazel |
2324 | Kai Henningsen | Robert Herriot | Paul Hethmon |
2325 | Jim Hill | Alfred Hoenes | Paul E Hoffman |
2326 | Steve Hole | Kari Hurtta | Marco S Hyman |
2327 | Ofer Inbar | Olle Jarnefors | Kevin Johnson |
2328 | Sudish Joseph | Maynard Kang | Prabhat Keni |
2329 | John C Klensin | Graham Klyne | Brad Knowles |
2330 | Shuhei Kobayashi | Peter Koch | Dan Kohn |
2331 | Christian Kuhtz | Anand Kumria | Steen Larsen |
2332 | Eliot Lear | Barry Leiba | Jay Levitt |
2333 | Bruce Lilly | Lars-Johan Liman | Charles Lindsey |
2334 | Pete Loshin | Simon Lyall | Bill Manning |
2335 | John Martin | Mark Martinec | Larry Masinter |
2336 | Denis McKeon | William P McQuillan | Alexey Melnikov |
2337 | Perry E Metzger | Steven Miller | S Moonesamy |
2338 | Keith Moore | John Gardiner Myers | Chris Newman |
2339 | John W Noerenberg | Eric Norman | Mike O'Dell |
2340 | Larry Osterman | Paul Overell | Jacob Palme |
2341 | Michael A Patton | Uzi Paz | Michael A Quinlan |
2342 | Robert Rapplean | Eric S Raymond | Sam Roberts |
2343 | Hugh Sasse | Bart Schaefer | Tom Scola |
2344 | Wolfgang Segmuller | Nick Shelness | John Stanley |
2345 | Einar Stefferud | Jeff Stephenson | Bernard Stern |
2346 | Peter Sylvester | Mark Symons | Eric Thomas |
2347 | Lee Thompson | Karel De Vriendt | Matthew Wall |
2348 | Rolf Weber | Brent B Welch | Dan Wing |
2349 | Jack De Winter | Gregory J Woodhouse | Greg A Woods |
2350 | Kazu Yamamoto | Alain Zahm | Jamie Zawinski |
2351 | Timothy S Zurcher | | |
2352 +--------------------+----------------------+---------------------+
2354 7. References
2356 7.1. Normative References
2358 [ANSI.X3-4.1986] American National Standards Institute,
2359 "Coded Character Set - 7-bit American
2360 Standard Code for Information Interchange",
2361 ANSI X3.4, 1986.
2363 [RFC1034] Mockapetris, P., "Domain names - concepts
2364 and facilities", STD 13, RFC 1034,
2365 November 1987.
2367 [RFC1035] Mockapetris, P., "Domain names -
2368 implementation and specification", STD 13,
2369 RFC 1035, November 1987.
2371 [RFC1123] Braden, R., "Requirements for Internet
2372 Hosts - Application and Support", STD 3,
2373 RFC 1123, October 1989.
2375 [RFC2119] Bradner, S., "Key words for use in RFCs to
2376 Indicate Requirement Levels", BCP 14,
2377 RFC 2119, March 1997.
2379 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF
2380 for Syntax Specifications: ABNF", STD 68,
2381 RFC 5234, January 2008.
2383 7.2. Informative References
2385 [RFC0822] Crocker, D., "Standard for the format of
2386 ARPA Internet text messages", STD 11,
2387 RFC 822, August 1982.
2389 [RFC1305] Mills, D., "Network Time Protocol (Version
2390 3) Specification, Implementation",
2391 RFC 1305, March 1992.
2393 [ISO.2022.1994] International Organization for
2394 Standardization, "Information technology -
2395 Character code structure and extension
2396 techniques", ISO Standard 2022, 1994.
2398 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose
2399 Internet Mail Extensions (MIME) Part One:
2400 Format of Internet Message Bodies",
2401 RFC 2045, November 1996.
2403 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose
2404 Internet Mail Extensions (MIME) Part Two:
2405 Media Types", RFC 2046, November 1996.
2407 [RFC2047] Moore, K., "MIME (Multipurpose Internet
2408 Mail Extensions) Part Three: Message Header
2409 Extensions for Non-ASCII Text", RFC 2047,
2410 November 1996.
2412 [RFC2049] Freed, N. and N. Borenstein, "Multipurpose
2413 Internet Mail Extensions (MIME) Part Five:
2414 Conformance Criteria and Examples",
2415 RFC 2049, November 1996.
2417 [RFC2822] Resnick, P., "Internet Message Format",
2418 RFC 2822, April 2001.
2420 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul,
2421 "Registration Procedures for Message Header
2422 Fields", BCP 90, RFC 3864, September 2004.
2424 [RFC4021] Klyne, G. and J. Palme, "Registration of
2425 Mail and MIME Header Fields", RFC 4021,
2426 March 2005.
2428 [RFC4288] Freed, N. and J. Klensin, "Media Type
2429 Specifications and Registration
2430 Procedures", BCP 13, RFC 4288,
2431 December 2005.
2433 [RFC4289] Freed, N. and J. Klensin, "Multipurpose
2434 Internet Mail Extensions (MIME) Part Four:
2435 Registration Procedures", BCP 13, RFC 4289,
2436 December 2005.
2438 [I-D.klensin-rfc2821bis] Klensin, J., "Simple Mail Transfer
2439 Protocol", draft-klensin-rfc2821bis-06
2440 (work in progress), November 2007.
2442 Author's Address
2444 Peter W. Resnick (editor)
2445 Qualcomm Incorporated
2446 5775 Morehouse Drive
2447 San Diego, CA 92121-1714
2448 US
2450 Phone: +1 858 651 4478
2451 EMail: presnick@qualcomm.com
2452 URI: http://www.qualcomm.com/~presnick/
2454 Full Copyright Statement
2456 Copyright (C) The IETF Trust (2008).
2458 This document is subject to the rights, licenses and restrictions
2459 contained in BCP 78, and except as set forth therein, the authors
2460 retain all their rights.
2462 This document and the information contained herein are provided on an
2463 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
2464 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
2465 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
2466 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
2467 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
2468 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
2470 Intellectual Property
2472 The IETF takes no position regarding the validity or scope of any
2473 Intellectual Property Rights or other rights that might be claimed to
2474 pertain to the implementation or use of the technology described in
2475 this document or the extent to which any license under such rights
2476 might or might not be available; nor does it represent that it has
2477 made any independent effort to identify any such rights. Information
2478 on the procedures with respect to rights in RFC documents can be
2479 found in BCP 78 and BCP 79.
2481 Copies of IPR disclosures made to the IETF Secretariat and any
2482 assurances of licenses to be made available, or the result of an
2483 attempt made to obtain a general license or permission for the use of
2484 such proprietary rights by implementers or users of this
2485 specification can be obtained from the IETF on-line IPR repository at
2486 http://www.ietf.org/ipr.
2488 The IETF invites any interested party to bring to its attention any
2489 copyrights, patents or patent applications, or other proprietary
2490 rights that may cover technology that may be required to implement
2491 this standard. Please address the information to the IETF at
2492 ietf-ipr@ietf.org.
2494 Acknowledgements
2496 Funding for the RFC Editor function is provided by the IETF
2497 Administrative Support Activity (IASA). This document was produced
2498 using xml2rfc v1.33pre5 (of http://xml.resource.org/) from a source
2499 in RFC-2629 XML format.