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.