idnits 2.17.1 draft-ietf-drums-msg-fmt-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 1656 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 510 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 98: '...section MUST NOT be taken as specifica...' RFC 2119 keyword, line 108: '...they MUST be created. There are also n...' RFC 2119 keyword, line 109: '...ed in the syntax SHOULD be used over a...' RFC 2119 keyword, line 228: '...tokens), folding SHOULD be limited to ...' RFC 2119 keyword, line 245: '...- CR and LF MUST only occur together a...' (62 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (November 21, 1997) is 9651 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 section? 'RFC-822' on line 1451 looks like a reference -- Missing reference section? 'RFC-2045' on line 1453 looks like a reference -- Missing reference section? 'RFC-2046' on line 1455 looks like a reference -- Missing reference section? 'RFC-2049' on line 1461 looks like a reference -- Missing reference section? 'SMTP' on line 1463 looks like a reference -- Missing reference section? 'RFC-2119' on line 1465 looks like a reference -- Missing reference section? 'RFC-2234' on line 1467 looks like a reference -- Missing reference section? 'ASCII' on line 1469 looks like a reference -- Missing reference section? 'RFC-2047' on line 1457 looks like a reference -- Missing reference section? 'RFC-2048' on line 1459 looks like a reference -- Missing reference section? 'FWS' on line 612 looks like a reference -- Missing reference section? 'CFWS' on line 1627 looks like a reference -- Missing reference section? 'STD-12' on line 1471 looks like a reference -- Missing reference section? 'DNS' on line 1473 looks like a reference -- Missing reference section? 'ISO-2022' on line 1475 looks like a reference -- Missing reference section? 'TBD' on line 1493 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 2 warnings (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group P. Resnick, Editor 2 Internet-Draft QUALCOMM Incorporated 3 November 21, 1997 5 Internet Message Format Standard 7 0. Status of this memo 9 This document is an Internet-Draft. Internet-Drafts are working documents of 10 the Internet Engineering Task Force (IETF), its areas, and its working groups. 11 Note that other groups may also distribute working documents as Internet- 12 Drafts. 14 Internet-Drafts are draft documents valid for a maximum of six months and may 15 be updated, replaced, or obsoleted by other documents at any time. It is 16 inappropriate to use Internet-Drafts as reference material or to cite them 17 other than as "work in progress." 19 To learn the current status of any Internet-Draft, please check the "1id- 20 abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on 21 ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), 22 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 24 1. Introduction 26 1.1 Scope 28 This standard specifies a syntax for text messages that are sent between 29 computer users, within the framework of ''electronic mail'' messages. This 30 standard supersedes the one specified in Request For Comments 822, ''Standard 31 for the Format of ARPA Internet Text Messages'' [RFC-822], updating it to 32 reflect current practice and incorporating incremental changes that were 33 specified in other RFCs. 35 This standard only specifies a syntax for text messages. In particular, it 36 makes no provision for the transmission of images, audio, or other sorts of 37 structured data in electronic mail messages. There are several extensions 38 published, such as the MIME document series [RFC-2045, RFC-2046, RFC-2049], 39 which describe mechanisms for the transmission of such data through electronic 40 mail, either by extending the syntax provided here or by structuring such 41 messages to conform to this syntax. These mechanisms are outside of the scope 42 of this standard. 44 In the context of electronic mail, messages are viewed as having an envelope 45 and contents. The envelope contains whatever information is needed to 46 accomplish transmission and delivery. (See [SMTP] for a discussion of the 47 envelope.) The contents comprise the object to be delivered to the recipient. 48 This standard applies only to the format and some of the semantics of message 49 contents. It contains no specification of the information in the envelope. 51 However, some message systems may use information from the contents to create 52 the envelope. It is intended that this standard facilitate the acquisition of 53 such information by programs. 55 Some message systems may store messages in formats that differ from the one 56 specified in this standard. This specification is intended strictly as a 57 definition of what message content format is to be passed BETWEEN hosts. 59 Note: This standard is NOT intended to dictate the internal formats used by 60 sites, the specific message system features that they are expected to support, 61 or any of the characteristics of user interface programs that create or read 62 messages. In addition, this standard does not specify an encoding of the 63 characters for either transport or storage; that is, it does not specify the 64 number of bits used or how those bits are specifically transferred over the 65 wire or stored on disk. 67 1.2 Notational conventions 69 1.2.1 Requirements notation 71 This document occasionally uses terms that appear in capital letters. When the 72 terms "MUST", "SHOULD", "MUST NOT", "SHOULD NOT", and "MAY" appear 73 capitalized, 74 they are being used to indicate particular requirements of this specification. 75 A discussion of the meanings of these terms appears in [RFC-2119]. 77 1.2.2 Syntactic notation 79 This standard uses the Augmented Backus-Naur Form (ABNF) notation specified in 80 [RFC-2234] for the formal definitions of the syntax of messages. Characters 81 will be specified either by a decimal value (e.g., the value %d65 for 82 uppercase 83 A and %d97 for lowercase A) or by a case-insensitive literal value enclosed in 84 quotation marks (e.g., "A" for either uppercase or lowercase A). See 85 [RFC-2234] 86 for the full description of the notation. 88 1.3 Structure of this document 90 This document is divided into several sections. 92 This section, section 1, is a short introduction to the document. 94 Section 2 will lay out the general description of a message and its 95 constituent 96 parts. This is an overview to help the reader understand some of the general 97 principles used in the later portions of this document. Any examples in this 98 section MUST NOT be taken as specification of the formal syntax of any part of 99 a message. 101 Section 3 will give the formal syntax and semantics for each of the parts of a 102 message. That is, it will describe the actual rules for the structure of each 103 part of a message (the syntax) as well as a description of the parts and 104 instructions on how they ought to be interpreted (the semantics). This will 105 include analysis of the syntax and semantics of subparts of messages which 106 have 107 specific structure. The syntax included in section 3 represents messages as 108 they MUST be created. There are also notes in section 3 to indicate if any of 109 the options specified in the syntax SHOULD be used over any of the others. 111 Both sections 2 and 3 describe messages which are legal to generate for 112 purposes of this standard. 114 Section 4 of this document specifies an "obsolete" syntax. There are 115 references 116 in section 3 to these obsolete syntactic elements. The rules of the obsolete 117 syntax are elements that have appeared in earlier revisions of this 118 standard or 119 have previously been widely used in Internet messages. As such, these elements 120 MUST be interpreted by parsers of messages in order to be conformant to this 121 standard. However, since items in this syntax have been determined to be non- 122 interoperable or cause significant problems for recipients of messages, they 123 MUST NOT be generated by creators of conformant messages. 125 Section 5 details security considerations to take into account when 126 implementing this standard. 128 Section 6 is a bibliography of references in this document. 130 Section 7 contains the author's address and instructions on where to send 131 comments. 133 Section 8 contains acknowledgements. 135 Appendix A lists examples of different sorts of messages. These examples are 136 not exhaustive of the types of messages that appear on the Internet, but 137 give a 138 broad overview of certain syntactic forms. 140 Appendix B lists the differences between this standard and earlier standards 141 for Internet messages. 143 2. Lexical Analysis of Messages 145 2.1 General Description 147 At the most basic level, a message is a series of characters. A message 148 that is 149 conformant with this standard is comprised of characters with values in the 150 range 1 through 127 and interpreted as US-ASCII characters [ASCII]. For 151 brevity, this document sometimes refers to this range of characters as simply 152 "US-ASCII characters". Messages are divided into lines of characters. A 153 line is 154 a series of characters which is delimited with the two characters carriage- 155 return and line-feed; that is, the carriage return (CR) character (ASCII value 156 13) followed immediately by the line feed (LF) character (ASCII value 10). 157 (The 158 carriage-return/line-feed pair is usually written in this document as "CRLF".) 160 Note: This standard specifies that messages are made up of characters in the 161 US-ASCII range of 1 through 127. There are other documents, specifically the 162 MIME document series [RFC-2045, RFC-2046, RFC-2047, RFC-2048, RFC-2049], which 163 extend this standard to allow for values outside of that range. Discussion of 164 these mechanisms is not within the scope of this standard. 166 A message consists of header fields (collectively called the header of the 167 message) followed, optionally, by a body. The header is a sequence of lines of 168 characters with special syntax as defined in this standard. The body is simply 169 a sequence of characters that follows the header and is separated from the 170 header by an empty line (i.e., a line with nothing preceding the CRLF). 172 2.2 Header Fields 174 Header fields are lines which have a specific syntax. Header fields are all 175 composed of a field name, followed by a colon (":"), followed by a field body, 176 and terminated by CRLF. A field name must be composed of printable US-ASCII 177 characters (i.e., characters that have values between 33 and 126), except 178 colon. A field body may be composed of any US-ASCII characters, except for CR 179 and LF. However, a field body may contain CRLF when used in header "folding" 180 and "unfolding" as described in section 2.2.3. All field bodies must 181 conform to 182 the syntax described in sections 3 and 4 of this standard. 184 2.2.1 Unstructured Header Field Bodies 186 Some field bodies in this standard are defined simply as "unstructured" (which 187 is specified below as any US-ASCII characters, except for CR and LF) with no 188 further restrictions. These are referred to as unstructured field bodies. 189 Semantically, unstructured field bodies are simply to be treated as a single 190 line of characters with no further processing (except for header "folding" and 191 "unfolding" as described in section 2.2.3). 193 2.2.2 Structured Header Field Bodies 195 Some field bodies in this standard have specific lexical structure more 196 restrictive than the unstructured field bodies described above. These are 197 referred to as "structured" field bodies. Structured field bodies are lines of 198 specific lexical tokens as described in sections 3 and 4 of this standard. 199 Many 200 of these tokens are allowed (according to their syntax) to be freely 201 surrounded 202 by comments (as described in section 3.2.4) as well as space (SP, ASCII value 203 32) and horizontal tab (HTAB, ASCII value 9) characters, and those surrounding 204 SP and HTAB characters are subject to header "folding" and "unfolding" as 205 described in section 2.2.3. Semantic analysis of structured field bodies is 206 given along with their syntax. 208 2.2.3 Long Header Fields 210 Each header field is logically a single line of characters comprising the 211 field 212 name, the colon, and the field body. For convenience however, the field body 213 portion of a header field can be split into a multiple line representation; 214 this is called "folding". The general rule is that wherever this standard 215 allows for folding white-space (not simply SP or HTAB), a CRLF followed by AT 216 LEAST one SP or HTAB may instead be inserted. For example, the header field: 218 Subject: This is a test 220 can be represented as: 222 Subject: This 223 is a test 225 Note: Though structured field bodies are defined in such a way that folding 226 can 227 take place between many of the lexical tokens (and even within some of the 228 lexical tokens), folding SHOULD be limited to placing the CRLF at higher-level 229 syntactic breaks. For instance, if a field body is defined as comma-separated 230 values, it is recommended that folding occur after the comma separating the 231 structured items, even if it is allowed elsewhere. 233 The process of moving from this folded multiple-line representation of a 234 header 235 field to its single line representation is called "unfolding". Unfolding is 236 accomplished by simply removing any CRLF that is immediately followed by SP or 237 HTAB. Each header field should be treated in its unfolded form for syntactic 238 and semantic evaluation. 240 2.3 Body 242 The body of a message is simply lines of US-ASCII characters. The only two 243 limitations on the body are as follows: 245 - CR and LF MUST only occur together as CRLF; they MUST NOT appear 246 independently in the body. 248 - Lines of characters in the body MUST be limited to 998 characters, and 249 SHOULD 250 be limited to 78 characters, excluding the CRLF. 252 Note: As was stated earlier, there are other standards documents, specifically 253 the MIME documents [RFC-2045, RFC-2046, RFC-2048, RFC-2049] which extend this 254 standard to allow for different sorts of message bodies. Again, these 255 mechanisms are beyond the scope of this document. 257 3. Syntax 259 3.1 Introduction 261 The syntax as given in this section defines the legal syntax of Internet 262 messages. Messages which are conformant to this standard MUST conform to the 263 syntax in this section. If there are options in this section where one option 264 SHOULD be generated, that is indicated either in the prose or in a comment 265 next 266 to the syntax. 268 For the defined tokens, a short description of the syntax and use is given, 269 followed by the syntax in ABNF, followed by a semantic analysis. Primitive 270 tokens that are used but otherwise unspecified come from [RFC-2234]. 272 In some of the token definitions, there will be elements whose names start 273 with 274 "obs-". These "obs-" elements refer to tokens defined in the obsolete 275 syntax in 276 section 4. In all cases, these tokens are to be ignored for the purposes of 277 generating legal Internet messages and MUST NOT be used as part of such a 278 message. However, when interpreting messages, these tokens MUST be honored as 279 part of the legal syntax. In this sense, section 3 defines a grammar for 280 generation of messages, with "obs-" elements which must be ignored, while 281 section 4 adds grammar for interpretation of messages. 283 3.2 Lexical Tokens 285 The following rules are used to define an underlying lexical analyzer, which 286 feeds tokens to the higher level parsers. This section is basically devoted to 287 defining tokens used in structured header field bodies. 289 3.2.1 Primitive Tokens 291 The following are primitive tokens referred to elsewhere in this standard, but 292 are not otherwise defined in [RFC-2234]. Some of them will not appear anywhere 293 else in the syntax, but they are convenient to refer to in other parts of this 294 document. 296 Note: The "specials" below are just such an example. Though the specials token 297 does not appear anywhere else in this standard, it is useful for implementors 298 who use tools which lexically analyze messages. Each of the characters in 299 specials can be used to indicate a tokenization point in lexical analysis. 301 NO-WS-CTL = %d1-8 / ; US-ASCII control characters 302 %d11 / ; which do not include the 303 %d12 / ; carriage return, line feed, 304 %d14-31 / ; and whitespace characters 305 %d127 307 text = %d1-9 / ; Characters excluding CR and LF 308 %d11-12 / 309 %d14-127 / 310 obs-text 312 specials = "(" / ")" / ; Special characters used in other 313 "<" / ">" / ; parts of the syntax 314 "[" / "]" / 315 ":" / ";" / 316 "@" / "\" / 317 "," / "." / 318 DQUOTE 320 No special semantics attaches to these tokens. They are simply single 321 characters. 323 3.2.2 Quoted characters 325 Some characters are reserved for special interpretation, such as delimiting 326 lexical tokens. To permit use of these characters as uninterpreted data, a 327 quoting mechanism is provided. 329 quoted-pair = ("\" text) / obs-qp 331 Where any quoted-pair appears, it should be interpreted as the text character 332 alone. 334 3.2.3 Whitespace 336 The following define the white-space characters used in this standard. See 337 section 3.2.4 for more information on the use of white-space in the rest of 338 this standard. 340 WSP = SP / HTAB ; Whitespace characters 341 FWS = ([*WSP CRLF] 1*WSP) / ; Folding white-space 342 obs-FWS 344 Throughout this standard, where FWS (the folding white-space token) 345 appears, it 346 indicates a place where header folding, as discussed in section 2.2.3, may 347 take 348 place. Wherever header folding appears in a message (that is, a header field 349 body containing a CRLF followed by any WSP), header unfolding (removal of the 350 CRLF) should be performed before any further lexical analysis is performed on 351 that header field according to this standard. That is to say, any CRLF that 352 appears in FWS is semantically "invisible." 354 Runs of FWS that occur between lexical tokens are semantically interpreted as 355 identical to a single space character. 357 3.2.4 Comments 359 Strings of characters which are treated as comments may be included in 360 structured field bodies as characters enclosed in parenthesis. Strings of 361 characters enclosed in parenthesis are considered comments so long as they do 362 not appear within a "quoted-string", as defined in section 3.2.6. Comments may 363 nest. 365 There are several places in this standard where comments and FWS may be freely 366 inserted. To accommodate that syntax, an additional token for "CFWS" is 367 defined 368 for places where comments and/or FWS can occur. However, where CFWS occurs in 369 this standard, it MUST NOT be inserted in such a way that any line of a folded 370 header field is made up entirely of WSP characters and nothing else. 372 ctext = NO-WS-CTL / ; Non-white-space controls 374 %d33-39 / ; The rest of the US-ASCII 375 %d42-91 / ; characters not including "(", 376 %d93-127 ; ")", or "\" 378 comment = "(" *([FWS] (ctext / quoted-pair / comment)) [FWS] ")" 380 CFWS = *([FWS] comment) (([FWS] comment) / FWS) 382 A comment is normally used in a structured field body to provide some human 383 readable informational text. A comment is semantically interpreted as a single 384 SP. Since a comment is allowed to contain FWS, folding is permitted. Also note 385 that since quoted-pair is allowed in a comment, the parentheses and backslash 386 characters may appear in a comment so long as they appear as a quoted-pair. 387 Semantically, the enclosing parentheses are not part of the comment token; the 388 token is what is contained between the two parentheses. 390 Runs of CFWS are semantically interpreted as a single space character. 392 3.2.5 Atom 394 Several tokens in structured header field bodies are simply strings of certain 395 basic characters. Such tokens are represented as atoms. Two atoms must be 396 separated by some other token, since putting two atoms next to each other 397 would 398 create a single atom. 400 Some of the structured header field bodies also allow the period character 401 (".", ASCII value 46) within runs of atext. An additional "dot-atom" token is 402 defined for those purposes. 404 atext = ALPHA / DIGIT / ; Any character except controls, 405 "!" / "#" / ; SP, and specials. 406 "$" / "%" / ; Used for atoms 407 "&" / "'" / 408 "*" / "+" / 409 "-" / "/" / 410 "=" / "?" / 411 "^" / "_" / 412 "`" / "{" / 413 "|" / "}" / 414 "~" 416 atom = [CFWS] 1*atext [CFWS] 418 dot-atom = [CFWS] dot-atom-text [CFWS] 420 dot-atom-text = 1*atext *("." 1*atext) 422 Both atom and dot-atom are interpreted as a single unit, comprised of the 423 string of characters that make it up. Semantically, the optional comments and 424 FWS surrounding the rest of the characters are not part of the token; the 425 token 426 is only the run of atext characters in an atom, or the atext and "." 427 characters 428 in a dot-atom. 430 3.2.6 Quoted strings 432 Strings of characters which include characters other than those allowed in 433 atoms may be represented in a quoted string format, where the characters are 434 surrounded by quote characters. 436 qtext = NO-WS-CTL / ; Non-white-space controls 438 %d33 / ; The rest of the US-ASCII 439 %d35-91 / ; characters not including "\" 440 %d93-127 ; or the quote character 442 quoted-string = [CFWS] 443 DQUOTE *([FWS] (qtext / quoted-pair)) [FWS] DQUOTE 444 [CFWS] 446 A quoted-string is treated as a single symbol. That is, quoted-string is 447 identical to atom, semantically. Since a quoted-string is allowed to contain 448 FWS, folding is permitted. Also note that since quoted-pair is allowed in a 449 quoted-string, the quote and backslash characters may appear in a 450 quoted-string 451 so long as they appear as a quoted-pair. 453 Semantically, neither the optional CFWS outside of the quote characters nor 454 the 455 quote characters themselves are part of the quoted-string token; the token is 456 what is contained between the two quote characters. 458 3.2.7 Miscellaneous tokens 460 Three additional tokens are defined, word and phrase for combinations of atoms 461 and/or quoted-strings, and unstructured for use in unstructured header fields 462 and in some places within structured header fields. 464 word = atom / quoted-string 466 phrase = 1*word / obs-phrase 468 unstructured = *([FWS] text) 470 3.3 Date and Time Specification 472 Date and time occur in several header fields of a message. This section 473 specifies the syntax for a full date and time specification. Though comments 474 and folding whitespace are permitted throughout the date-time 475 specification, it 476 is recommended that only a single space be used where CFWS is required, and 477 that comments be limited to the end of the date-time specification; some older 478 implementations may not interpret other occurrences of comments and folding 479 whitespace correctly. 481 date-time = [ day-of-week "," ] date CFWS time [CFWS] 483 day-of-week = CFWS day-name CFWS 485 day-name = "Mon" / "Tue" / "Wed" / "Thu" / 486 "Fri" / "Sat" / "Sun" 488 date = day month year 490 year = ([CFWS] 4*DIGIT [CFWS]) / obs-year 492 month = CFWS month-name CFWS 494 month-name = "Jan" / "Feb" / "Mar" / "Apr" / 495 "May" / "Jun" / "Jul" / "Aug" / 496 "Sep" / "Oct" / "Nov" / "Dec" 498 day = [CFWS] 1*2DIGIT [CFWS] 500 time = time-of-day CFWS zone 502 time-of-day = hour ":" minute [ ":" second ] 504 hour = [CFWS] 2DIGIT [CFWS] 506 minute = [CFWS] 2DIGIT [CFWS] 508 second = [CFWS] 2DIGIT [CFWS] 510 zone = (( "+" / "-" ) 4DIGIT) / obs-zone 512 The day is the numeric day of the month. The year is any numeric year in the 513 common era. 515 The time-of-day specifies the number of hours, minutes, and optionally seconds 516 since midnight of the date indicated. 518 The date and time-of-day SHOULD express local time. 520 The zone specifies the offset from Coordinated Universal Time (UTC, formerly 521 referred to as "Greenwich Mean Time") that the date and time-of-day represent. 522 The "+" or "-" indicates whether the time-of-day is ahead of or behind 523 Universal Time. The first two digits indicate the number of hours difference 524 from Universal Time, and the last two digits indicate the number of minutes 525 difference from Universal Time. (Hence, +hhmm means +(hh * 60 + mm) minutes, 526 and -hhmm means -(hh * 60 + mm) minutes). The form "+0000" SHOULD be used to 527 indicate a time zone at Universal Time. Though "-0000" also indicates 528 Universal 529 Time, it is used to indicate that the time was generated on a system that may 530 be in a local time zone other than Universal Time. 532 A date-time specification MUST be semantically valid. That is, the day-of-the 533 week (if included) MUST be the day implied by the date, the numeric day-of- 534 month MUST be between 1 and the number of days allowed for the specified month 535 (in the specified year), the time-of-day MUST be in the range 00:00:00 through 536 23:59:60 (the number of seconds allowing for a leap second; see [STD-12]), and 537 the zone MUST be within the range -9959 through +9959. 539 3.4 Address Specification 541 Addresses occur in several message header fields to indicate senders and 542 recipients of messages. An address may either be an individual mailbox, or a 543 group of mailboxes. 545 address = mailbox / group 547 mailbox = name-addr / addr-spec / obs-mailbox 549 name-addr = [display-name] [CFWS] "<" addr-spec ">" [CFWS] 551 group = group-name ":" [mailbox-list] ";" [CFWS] 553 display-name = phrase 555 group-name = phrase 557 mailbox-list = (mailbox *("," mailbox)) / obs-mbox-list 559 address-list = address *("," address) / obs-addr-list 561 A mailbox receives mail. It is a conceptual entity which does not necessarily 562 pertain to file storage. For example, some sites may choose to print mail on a 563 printer and deliver the output to the addressee's desk. Normally, a mailbox is 564 comprised of two parts: (1) an optional display name which indicates the name 565 of the recipient (which could be a person or a system) that could be displayed 566 to the user of a mail application, and (2) an addr-spec address enclosed in 567 angle brackets ("<" and ">"). There is also an alternate simple form of a 568 mailbox where the addr-spec address appears alone, without the recipient's 569 name 570 or the angle brackets. The Internet addr-spec address is described in section 571 3.4.1. 573 Note: Some legacy implementations used the simple form where the addr-spec 574 appears without the angle brackets, but included the name of the recipient in 575 parentheses as a comment following the addr-spec. Since the meaning of the 576 information in a comment is unspecified, implementations SHOULD use the full 577 name-addr form of the mailbox if a name of the recipient is being used instead 578 of the legacy form. Also, because some legacy implementations interpret the 579 comment, comments SHOULD NOT generally be used in address fields to avoid 580 confusion. 582 When it is desirable to treat several mailboxes as a single unit (i.e., in a 583 distribution list), the group construct can be used. The group construct 584 allows 585 the sender to indicate a named group of recipients. This is done by giving a 586 group name, followed by a colon, followed by a comma separated list of any 587 number of mailboxes (including zero and one), and ending with a semicolon. 588 Because the list of mailboxes can be empty, using the group construct is 589 also a 590 simple way to indicate in the message that a set of recipients was sent the 591 message without actually providing the individual mailbox address for each of 592 the recipients. 594 3.4.1 Addr-spec specification 596 An addr-spec is a specific Internet identifier that contains both a locally 597 interpreted string followed by the at-sign character ("@", ASCII value 64) 598 followed by an Internet domain. The locally interpreted string is either a 599 quoted-string or a dot-atom. If the string can be represented as a dot-atom 600 (that is, it contains no characters other than atext characters or "." 601 surrounded by atext characters), then the dot-atom form SHOULD be used and the 602 quoted-string form SHOULD NOT be used. Comments and folding whitespace SHOULD 603 NOT be used around the "@" in the addr-spec. 605 addr-spec = local-part "@" domain 607 local-part = dot-atom / quoted-string / obs-local-part 609 domain = dot-atom / domain-literal / obs-domain 611 domain-literal = [CFWS] 612 "[" *([FWS] (dtext / quoted-pair)) [FWS] "]" 613 [CFWS] 615 dtext = NO-WS-CTL / ; Non-white-space controls 617 %d33-90 / ; The rest of the US-ASCII 618 %d94-127 ; characters not including "[", 619 ; "]", or "\" 621 The domain portion is a fully qualified identifier for an Internet host. For 622 example, in a mailbox address, it is the host on which the particular mailbox 623 resides. In the dot-atom form, this is interpreted as an Internet domain name 624 (either a host name or a mail exchanger name) as described in [DNS]. In the 625 domain-literal form, the domain is interpreted as the literal Internet address 626 of the particular host. In both cases, how addressing is used and how messages 627 are transported to a particular host is covered in the mail transport document 628 [SMTP]. These mechanisms are outside of the scope of this document. 630 The local-part portion is a domain dependent string. In addresses, it is 631 simply 632 interpreted on the particular host as a name of a particular mailbox. In a 633 message identifier (described in section 3.6.4), it is an identifying string 634 that is unique to a message generated on a particular host. It is otherwise 635 uninterpreted in this standard. 637 3.5 Overall message syntax 639 A message consists of header fields, optionally followed by a message body. In 640 a message body, though all of the characters listed in the text rule MAY be 641 used, the US-ASCII control characters(values 1 through 8, 11, 12, and 14 642 through 31) SHOULD NOT be used. Also, though the lines in the body MAY be a 643 maximum of 998 characters excluding the CRLF, lines SHOULD be limited to 78 644 characters excluding the CRLF. 646 message = (fields / obs-fields) 647 [CRLF body] 649 body = *(*998text CRLF) *998text 651 The header fields carry most of the semantic information and are defined in 652 section 3.6. The body is simply a series of lines of text which are 653 uninterpreted for the purposes of this standard. 655 3.6 Field definitions 657 The header fields of a message are defined here. All header fields have the 658 same general syntactic structure: A field name, followed by a colon, followed 659 by the field body. The specific syntax for each header field is defined in the 660 subsequent sections. 662 Note: In the ABNF syntax for each field in subsequent sections, each field 663 name 664 is followed by the required colon. However, for brevity sometimes the colon is 665 not referred to in the textual description of the syntax. It is, nonetheless, 666 required. 668 It is important to note that the header fields are not guaranteed to be in a 669 particular order. They may appear in any order, and they have been known to be 670 reordered occasionally when transported over the Internet. However, for the 671 purposes of this standard, header fields SHOULD NOT be reordered when a 672 message 673 is transported or transformed. More importantly, the trace header fields and 674 resent header fields MUST NOT be reordered, and SHOULD be kept in blocks 675 prepended to the message. See sections 3.6.6 and 3.6.7 for more information. 677 The only required header fields are the origination date field and the 678 originator address field(s). All other header fields are syntactically 679 optional. More information is contained in the table following this definition. 681 fields = *(trace 682 *(resent-date / 683 resent-from / 684 resent-sender / 685 resent-to / 686 resent-cc / 687 resent-bcc / 688 resent-id)) 689 *(orig-date / 690 from / 691 sender / 692 reply-to / 693 to / 694 cc / 695 bcc / 696 message-id / 697 in-reply-to / 698 references / 699 subject / 700 comments / 701 keywords / 702 optional-field) 704 The following table indicates limits on the number of times each field may 705 occur in a message header as well as any special limitations on the use of 706 those fields. An asterisk next to a value in the minimum or maximum column 707 indicates that a special restriction appears in the Notes column. 709 Field Min number Max number Notes 711 trace 0 infinite Block prepended - see 3.6.7 713 resent-date 0* infinite* One per block, required if 714 other resent fields present 715 - see 3.6.6 717 resent-from 0 infinite* One per block - see 3.6.6 719 resent-sender 0* infinite* One per block, MUST occur 720 with multi-address 721 resent-from - see 3.6.6 723 resent-to 0 infinite* One per block - see 3.6.6 725 resent-cc 0* infinite* One per block, SHOULD only 726 occur with resent-to - see 727 3.6.6 729 resent-bcc 0 infinite* One per block - see 3.6.6 731 resent-id 0 infinite* One per block - see 3.6.6 733 orig-date 1 1 735 from 1 1 See sender and 3.6.2 737 sender 0* 1 MUST occur with multi-address 738 from - see 3.6.2 740 reply-to 0 1 742 to 0 1 744 cc 0 1* SHOULD occur only with to - 745 see 3.6.3 746 bcc 0 1 748 message-id 0* 1 SHOULD be present - see 3.6.4 750 in-reply-to 0* 1 SHOULD occur in some replies 751 - see 3.6.4 753 references 0* 1 SHOULD occur in some replies 754 - see 3.6.4 755 subject 0 1 757 comments 0 1 759 keywords 0 1 761 optional-field 0 infinite 763 The exact interpretation of each field is described in subsequent sections. 765 3.6.1 The origination date field 767 The origination date field consists of the field name "Date" followed by a 768 date-time specification. 770 orig-date = "Date:" date-time CRLF 772 The origination date specifies the date and time at which the creator of the 773 message indicated that the message was complete and ready to enter the mail 774 delivery system. For instance, this might be the time that a user pushes the 775 "send" or "submit" button in an application program. In any case, it is 776 specifically not intended to convey the time that the message is actually 777 transported, but rather the time at which the human or other creator of the 778 message has put the message in its final form, ready for transport. (For 779 example, a laptop user who is not connected to a network might queue a message 780 for delivery. The origination date should contain the date and time that the 781 user queued the message, not the time when the user connected to the 782 network to 783 send the message.) 785 3.6.2 Originator fields 787 The originator fields of a message consist of the from field, the sender field 788 (when applicable) and optionally the reply-to field. The from field 789 consists of 790 the field name "From" and comma-separated list of one or more mailbox 791 specifications. If the from field contains more than one mailbox specification 792 in the mailbox-list, then the sender field, containing the field name "Sender" 793 and a single mailbox specification, MUST appear in the message. In either 794 case, 795 an optional reply-to field may also be included, which contains the field name 796 "Reply-To" and a comma-separated list of one or more mailboxes. 798 from = "From:" mailbox-list CRLF 800 sender = "Sender:" mailbox CRLF 802 reply-to = "Reply-To:" mailbox-list CRLF 804 The originator fields indicate the mailbox(es) of the source of the message. 805 The "From:" field specifies the author(s) of the message, that is, the 806 mailbox(es) of the person(s) or system(s) responsible for the writing of the 807 message. The "Sender:" field specifies the mailbox of the agent responsible 808 for 809 the actual transmission of the message. For example, if a secretary were to 810 send a message for another person, the mailbox of the secretary would go in 811 the 812 "Sender:" field and the mailbox of the actual author would go in the "From:" 813 field. If the originator of the message can be indicated by a single mailbox 814 and the author and transmitter are identical, the "From:" field SHOULD be used 815 and the "Sender:" field SHOULD NOT be used. Otherwise, both fields SHOULD 816 appear. 818 The originator fields also provide the information required to reply to a 819 message. When the "Reply-To:" field is present, it indicates the 820 mailbox(es) to 821 which the author of the message suggests that replies be sent. In the absence 822 of the "Reply-To:" field, replies SHOULD be sent to the mailbox(es) specified 823 in the "From:" field. 825 In all cases, the "From:" field SHOULD NOT contain any mailbox which does not 826 belong to the author(s) of the message. See also section 3.6.3 for more 827 information on forming the destination addresses for a reply. 829 3.6.3 Destination address fields 831 The destination fields of a message consist of three possible fields, each of 832 the same form: The field name, which is either "To", "Cc", or "Bcc", followed 833 by a comma-separated list of one or more addresses (either mailbox or group 834 syntax). Both the "To:" field and the "Bcc:" field MAY occur alone, but the 835 "Cc:" field SHOULD only be present if the "To:" field is also present. 837 to = "To:" address-list CRLF 839 cc = "Cc:" address-list CRLF 841 bcc = "Bcc:" (address-list / [CFWS]) CRLF 843 The destination fields specify the recipients of the message. Each destination 844 field may have one or more addresses, and each of the addresses receives a 845 copy 846 of the message. The only difference between the three fields is how each is 847 used. 849 The "To:" field contains the address(es) of the primary recipient(s) of the 850 message. 852 The "Cc:" field (where the "Cc" means "Carbon Copy" in the sense of making a 853 copy on a typewriter using carbon paper) contains the addresses of others who 854 should receive the message, though the content of the message may not be 855 directed at them. 857 The "Bcc:" field (where the "Bcc" means "Blind Carbon Copy) contains addresses 858 of recipients of the message whose addresses should not be revealed to other 859 recipients of the message. There are three ways in which the "Bcc:" field is 860 used. In the first case, when a message containing a "Bcc:" field is prepared 861 to be sent, the "Bcc:" line is removed even though all of the recipients 862 (including those specified in the "Bcc:" field) are sent a copy of the 863 message. 864 In the second case, recipients specified in the "To:" and "Cc:" lines each are 865 sent a copy of the message with the "Bcc:" line removed as above, but the 866 recipients on the "Bcc:" line get a separate copy of the message containing a 867 "Bcc:" line. (When there are multiple recipient addresses in the "Bcc:" field, 868 some implementations actually send a separate copy of the message to each 869 recipient with a "Bcc:" containing only the address of that particular 870 recipient.) Finally, since a "Bcc:" field may contain no addresses, a "Bcc:" 871 field can be sent without any addresses indicating to the recipients that 872 blind 873 copies were sent to someone. Which method to use with "Bcc:" fields is 874 implementation dependent, but refer to the "Security Considerations" 875 section of 876 this document for a discussion of each. 878 When a message is a reply to another message, the mailboxes of the authors of 879 the original message (the mailboxes in the "From:" or "Reply-To:" fields) MAY 880 appear in the "To:" field of the reply, since that would normally be the 881 primary recipient. If a reply is sent to a message that has destination 882 fields, 883 it is often desirable to send a copy of the reply to all of the recipients of 884 the message in addition to the author. When such a reply is formed, addresses 885 in the "To:" and "Cc:" fields of the original message MAY appear in the "Cc:" 886 field of the reply, since these are normally secondary recipients of the 887 reply. 888 If a "Bcc:" field is present in the original message, addresses in that field 889 MAY appear in the "Bcc:" field of the reply, but SHOULD NOT appear in the 890 "To:" 891 or "Cc:" fields. 893 Note: Some mail applications have automatic reply commands that include the 894 destination addresses of the original message in the destination addresses of 895 the reply. How those reply commands behave is implementation dependent and is 896 beyond the scope of this document. In particular, whether or not to include 897 the 898 original destination addresses when the original message had a "Reply-To:" 899 field is not addressed here. 901 3.6.4 Identification fields 903 Though optional, every message SHOULD have a "Message-ID:" field. Furthermore, 904 reply messages SHOULD have "In-Reply-To:" and "References:" fields as 905 appropriate, as described below. 907 The "Message-ID:" and "In-Reply-To:" field each contain a single unique 908 message 909 identifier. The "References:" field contains one or more unique message 910 identifiers, optionally separated by CFWS. 912 The message identifier is simply the same syntax as an addr-spec construct 913 enclosed in the angle bracket characters, "<" and ">". 915 message-id = "Message-ID:" identifier CRLF 917 in-reply-to = "In-Reply-To:" identifier CRLF 919 references = "References:" identifier *([CFWS] identifier) CRLF 921 identifier = "<" id-left-side "@" id-right-side ">" 923 id-left-side = dot-atom-text / no-fold-quote / obs-id-left-side 925 id-right-side = dot-atom-text / no-fold-literal / obs-id-right-side 927 no-fold-quote = DQUOTE *(qtext / quoted-pair) DQUOTE 929 The "Message-ID:" field provides a unique identifier which refers to a 930 particular version of a particular message. The uniqueness of the message 931 identifier is guaranteed by the host which generates it (see below). This 932 identifier is intended to be machine readable and not necessarily 933 meaningful to 934 humans. A message identifier pertains to exactly one instantiation of a 935 particular message; subsequent revisions to the message should each receive 936 new 937 message identifiers. 939 The "In-Reply-To:" and "References:" fields are used when creating a reply 940 to a 941 message. They hold the message identifier of the original message and the 942 message identifiers of other messages (for example, in the case of a reply 943 to a 944 message which was itself a reply). If the original message contains a "Message- 945 ID:" field, the contents of that field body should be copied into the body of 946 an "In-Reply-To:" field and into the body of a "References:" field in the new 947 message. If the original message contains a "References:" field and/or an "In- 948 Reply-To:" field already (hence a reply to a reply), the contents of the old 949 "References:" field should be copied to the "References:" field in the new 950 message, appending to it the contents of the old "In-Reply-To:" field (if its 951 identifier was not already in the "References:" field) and the contents of the 952 "Message-ID:" field of the original message. In this way, a "thread" of 953 conversation can be established. 955 The message identifier itself is a domain-dependent unique identifier. The 956 domain portion of the identifier SHOULD be the domain name of the host on 957 which 958 it was created, to guarantee uniqueness. The local-part portion of the 959 identifier MAY be any dot-atom or quoted-string. However, the entire 960 identifier 961 MUST be globally unique. In order to do this, a common practice is to form the 962 local-part by using a combination of the current absolute time and some other 963 currently unique identifier on the host (for example a system process 964 identifier). 966 The message identifier itself MUST be a globally unique identifier for a 967 message. The generator of the identifier MUST guarantee that the identifier is 968 unique. There are several algorithms that can be used to accomplish this. 969 Since 970 the identifier has an similar syntax to addr-spec (identical except that 971 comments and folding whitespace are not allowed), a good method is to put the 972 domain name or a domain literal IP address of the host on which the identifier 973 was created on the right hand side of the "@", and on the left hand side, 974 put a 975 combination of the current absolute date and time along with some other 976 currently unique (perhaps sequential) identifier available on the system (for 977 example, a process id number). Using a date on the left hand side and a domain 978 name or domain literal on the right hand side makes it possible to guarantee 979 uniqueness since no two hosts should be using the same domain name or IP 980 address at the same time. Though other algorithms will work, it is RECOMMENDED 981 that the right hand side contain some domain identifier (either of the host 982 itself or otherwise) such that the generator of the message identifier can 983 guarantee the uniqueness of the left hand side within the scope of that domain. 985 3.6.5 Informational fields 987 The informational fields are all optional. The "Keywords:" field contains a 988 comma-separated list of one or more words or quoted-strings. The "Subject:" 989 and 990 "Comments:" fields are unstructured fields as defined in section 2.2.1, and 991 therefore may contain text or folding white-space. 993 subject = "Subject:" unstructured CRLF 995 comments = "Comments:" unstructured CRLF 997 keywords = "Keywords:" phrase *("," phrase) CRLF 999 These three fields are only intended to have human-readable content with 1000 information about the message. The "Subject:" field is the most common and 1001 contains a short string identifying the topic of the message. When used in a 1002 reply, the field body MAY start with the string "Re: " (from the Latin "res", 1003 in the matter of) followed by the contents of the "Subject:" field body of the 1004 original message. The "Comments:" field contains any additional comments on 1005 the 1006 text of the body of the message. The "Keywords:" field contains a comma- 1007 separated list of important words and phrases that might be useful for the 1008 recipient. 1010 3.6.6 Resent fields 1012 Resent fields SHOULD be added to any message which is reintroduced by a user 1013 into the transport system. A separate set of resent fields SHOULD be added if 1014 this occurs multiple times. All of the resent fields corresponding to a 1015 particular resending of the message SHOULD be together. Each new set of resent 1016 fields should be prepended to the message; that is, the most recent set of 1017 resent fields should appear earlier in the message. No other fields in the 1018 message should be changed when resent fields are added. 1020 Each of the resent fields corresponds to a particular field elsewhere in the 1021 syntax. For instance, the "Resent-Date:" field corresponds to the "Date:" 1022 field 1023 and the "Resent-To:" field corresponds to the "To:" field. In each case, the 1024 syntax for the field body is identical to the syntax given previously for the 1025 corresponding field. 1027 When resent fields are used, the "Resent-From:" and "Resent-Date:" fields MUST 1028 be sent. The "Resent-Cc:" field SHOULD NOT be sent if the "Resent-To:" 1029 field is 1030 not present. The "Resent-Message-ID:" field SHOULD be sent. "Resent-Sender:" 1031 SHOULD NOT be used if "Resent-Sender:" would be identical to "Resent-From:". 1033 resent-date = "Resent-Date:" date-time CRLF 1035 resent-from = "Resent-From:" mailbox-list CRLF 1037 resent-sender = "Resent-Sender:" mailbox CRLF 1039 resent-to = "Resent-To:" address-list CRLF 1041 resent-cc = "Resent-Cc:" address-list CRLF 1043 resent-bcc = "Resent-Bcc:" (address-list / [CFWS]) CRLF 1045 resent-msg-id = "Resent-Message-ID:" identifier CRLF 1047 Resent fields are used to identify a message as having been reintroduced into 1048 the transport system by a user. The purpose of using resent fields is to have 1049 the message appear to the final recipient as if it were sent directly by the 1050 original sender, with all of the original fields remaining the same. Each set 1051 of resent fields correspond to a particular resending event. That is, if a 1052 message is resent multiple times, each set of resent fields gives identifying 1053 information for each individual time. Resent fields are strictly 1054 informational. 1055 They MUST NOT be used in the normal processing of replies or other such 1056 actions 1057 on messages. 1059 Note: Reintroducing a message into the transport system and using resent 1060 fields 1061 is a different operation from "forwarding". Forwarding a message is to make it 1062 the body of a new message. A forwarded message does not appear to have come 1063 from the original sender, but is an entirely new message from the forwarder of 1064 the message. Resent headers are not intended for use with forwarding. 1066 The resent originator fields indicate the mailbox of the person(s) or 1067 system(s) 1068 that resent the message. As with the regular originator fields, there are two 1069 forms; a simple "Resent-From:" form which contains the mailbox of the 1070 individual doing the resending, and the more complex form, when one individual 1071 (identified in the "Resent-Sender:" field) resends a message on behalf of one 1072 or more others (identified in the "Resent-From:" field). 1074 Note: When replying to a resent message, replies should behave just as they 1075 would with any other message, using the original "From:", "Reply-To:", 1076 "Message-ID:", and other fields. The resent fields are only informational and 1077 MUST NOT be used when forming replies. 1079 The "Resent-Date:" indicates the date and time at which the resent message is 1080 dispatched by the resender of the message. Like the "Date:" field, it is not 1081 the date and time that the message was actually transported. 1083 The "Resent-To:", "Resent-Cc:", and "Resent-Bcc:" fields function identically 1084 to the "To:", "Cc:", and "Bcc:" fields respectively, except that they indicate 1085 the recipients of the resent message, not the recipients of the original 1086 message. 1088 The "Resent-Message-ID:" field provides a unique identifier for the resent 1089 message. 1091 3.6.7 Trace fields 1093 The trace fields are a group of header fields consisting of an optional 1094 "Return-Path:" field, and one or more "Received:" fields. The "Return-Path:" 1095 header field contains a pair of angle brackets which enclose an optional addr- 1096 spec. The "Received:" field contains a series of token-value pairs followed by 1097 a semicolon and a date-time specification. The first item of the token value 1098 pair is defined by token-name and the second item is either an atom or a 1099 quoted-string. Further restrictions may be applied to the syntax of the trace 1100 fields by standards which provide for their use, such as [SMTP]. 1102 trace = [return] 1103 1*received 1105 return = "Return-Path:" path CRLF 1107 path = [CFWS] "<" ([CFWS] / addr-spec) ">" [CFWS] 1109 received = "Received:" [CFWS] *token-value ";" date-time CRLF 1111 token-value = [CFWS] token-name CFWS word 1113 token-name = ALPHA *(["-"] (ALPHA / DIGIT)) 1115 A full discussion of the Internet mail use of trace fields is contained in 1116 [SMTP]. For the purposes of this standard, the trace fields are strictly 1117 informational, and any formal interpretation of them is outside of the 1118 scope of 1119 this document. 1121 3.6.8 Optional fields 1123 Fields may appear in messages that are otherwise unspecified in this standard. 1124 They must conform to the syntax of an optional-field. This is basically a 1125 field 1126 name, made up of the printable US-ASCII characters except SP and colon, 1127 followed by a colon, followed by unstructured text. 1129 The field names of any optional-field MUST NOT be identical to any field name 1130 specified elsewhere in this standard. 1132 optional-field = field-name ":" unstructured 1134 field-name = 1*ftext 1136 ftext = %d33-57 / ; Any character except 1137 %d59-126 ; controls, SP, and ":". 1139 For the purposes of this standard, the meaning of any optional field is 1140 uninterpreted. 1142 4. Obsolete Syntax 1144 Earlier versions of this standard allowed for different (usually more liberal) 1145 syntax than is allowed in this version. Also, there have been syntactic 1146 elements used in messages on the Internet that have never been documented. 1147 Though these syntactic forms MUST NOT be generated according to the grammar in 1148 section 3, they MUST be accepted and parsed by a conformant receiver. This 1149 section documents these syntactic elements. Taking the grammar in section 3 1150 and 1151 adding the definitions presented in this section will result in the grammar to 1152 use for interpretation of messages. 1154 One important difference between the obsolete (interpreting) and the current 1155 (generating) syntax is that in structured header field bodies (i.e., between 1156 the colon and the CRLF of any structured header field), white-space 1157 characters, 1158 including folding white-space, and comments could be freely inserted between 1159 any syntactic tokens. This allowed many complex forms that have proven 1160 difficult for some implementations to parse. 1162 Another key difference between the obsolete and the current syntax is that the 1163 rule in section 3.2.4 regarding comments and folding whitespace does not 1164 apply. 1165 See the discussion of folding whitespace in section 4.2 below. 1167 Finally, certain characters which were formerly allowed in messages appear in 1168 this section. The NUL character (ASCII value 0) was once allowed, but is no 1169 longer for compatibility reasons. CR and LF were allowed to appear in messages 1170 other than as CRLF. This use is also shown here. 1172 Other differences in syntax and semantics are noted in the following sections. 1174 4.1 Miscellaneous obsolete tokens 1176 These syntactic elements are used elsewhere in the obsolete syntax or in the 1177 main syntax. The obs-char and obs-qp elements each add ASCII value 0. Bare CR 1178 and bare LF are added to obs-text. The period character is added to obs-phrase. 1180 obs-qp = "\" (%d0-127) 1182 obs-text = *(*LF *CR obs-char) 1184 obs-char = %d0-9 / %d11 / ; %d0-127 except CR and LF 1185 %d12 / %d14-127 1187 obs-phrase = word *(word / "." / CFWS) 1189 4.2 Obsolete folding whitespace 1191 In the obsolete syntax, any amount of folding whitespace MAY be inserted where 1192 the obs-FWS rule is allowed. This creates the possibility of having two 1193 consecutive "folds" in a line, and therefore the possibility that a line which 1194 makes up a folded header field could be composed entirely of whitespace. 1196 obs-FWS = 1*WSP *(CRLF 1*WSP) 1198 4.3 Obsolete Date and Time 1200 The syntax for the obsolete date format allows a 2 digit year in the date 1201 field 1202 and allows for a list of alphabetic time zone specifications which were 1203 used in 1204 earlier versions of this standard. 1206 obs-year = [CFWS] 2*DIGIT [CFWS] 1208 obs-zone = "UT" / "GMT" / ; Universal Time 1209 ; North American UT offsets 1210 "EST" / "EDT" / ; Eastern: - 5/ - 4 1211 "CST" / "CDT" / ; Central: - 6/ - 5 1212 "MST" / "MDT" / ; Mountain: - 7/ - 6 1213 "PST" / "PDT" / ; Pacific: - 8/ - 7 1215 %d65-73 / ; Military zones - "A" 1216 %d75-90 / ; through "I" and "K" through 1217 %d97-105 / ; "Z", both upper and lower 1218 %d107-122 ; case 1220 Where a two or three digit year occurs in a date, the year should be 1221 interpreted as follows: If a two digit year is encountered whose value is 1222 between 00 and 49, the year should be interpreted by adding 2000, ending up 1223 with a value between 2000 and 2049. If a two digit year is encountered with a 1224 value between 50 and 99, or any three digit year is encountered, the year 1225 should be interpreted by adding 1900. 1227 In the obsolete time zone, "UT" and "GMT" are indications of "Universal Time" 1228 and "Greenwich Mean Time" respectively and are both semantically identical to 1229 "+0000". The remaining three character zones are the US time zones. The "T" is 1230 simply "Time" and the "E", "C", "M", and "P" are "Eastern", "Central", 1231 "Mountain" and "Pacific". When followed by "S" (for "Standard"), each of these 1232 are equivalent to "-0500", "-0600", "-0700", and "-0800" respectively. When 1233 followed by "D" (for "Daylight" or summer time), the each add an hour and are 1234 therefore "-0400", "-0500", "-0600", and "-0700" respectively. The 1 character 1235 military time zones were defined in a non-standard way in [RFC-822] and are 1236 therefore unpredictable in their meaning. The original definitions of the 1237 military zones "A" through "I" are equivalent to "+0100" through "+0900" 1238 respectively; "K", "L", and "M" are equivalent to "+1000", "+1100", and 1239 "+1200" respectively; "N" through "Y" are equivalent to "-0100" through 1240 "-1200" 1241 respectively; and "Z" is equivalent to "+0000". However, because of the error 1242 in [RFC-822], they SHOULD all be considered equivalent to "-0000". 1244 Other multi-character (usually between 3 and 5) alphabetic time zones have 1245 been 1246 used in Internet messages. Any of these time zones SHOULD be considered 1247 equivalent too "-0000". 1249 4.4 Obsolete Addressing 1251 There are three primary differences in addressing. First, mailbox addresses 1252 were allowed to have a route portion before the addr-spec when enclosed in "<" 1253 and ">". The route is simply a comma-separated list of domain names, each 1254 preceded by "@", and the list terminated by a colon. Second, CFWS were allowed 1255 between the period-separated elements of local-part and domain (i.e., dot-atom 1256 was not used). Finally, mailbox-list and address-list were allowed to have 1257 "null" members. That is, there could be two or more commas in such a list with 1258 nothing in between them. 1260 obs-mailbox = addr-spec / [display-name] obs-route-addr 1262 obs-route-addr = [CFWS] "<" [obs-route] addr-spec ">" [CFWS] 1264 obs-route = [CFWS] obs-domain-list ":" [CFWS] 1266 obs-domain-list = "@" domain *(*(CFWS / "," ) [CFWS] "@" domain) 1268 obs-local-part = atom *("." atom) 1270 obs-domain = atom *("." atom) 1272 obs-mbox-list = *([mailbox] [CFWS] "," [CFWS]) 1274 obs-addr-list = *([address] [CFWS] "," [CFWS]) 1276 When interpreting addresses, the route portion SHOULD be ignored. 1278 4.5 Obsolete header fields 1280 Syntactically, the primary difference in the obsolete field syntax is that it 1281 allows multiple occurrences of any of the fields and they may occur in any 1282 order. Also, any amount of whitespace is allowed before the ":" at the end of 1283 the field name. 1285 obs-fields = *(obs-return / 1286 obs-received / 1287 obs-orig-date / 1288 obs-from / 1289 obs-sender / 1290 obs-reply-to / 1291 obs-to / 1292 obs-cc / 1293 obs-bcc / 1294 obs-message-id / 1295 obs-in-reply-to / 1296 obs-references / 1297 obs-subject / 1298 obs-comments / 1299 obs-keywords / 1300 obs-resent-from / 1301 obs-resent-send / 1302 obs-resent-rply / 1303 obs-resent-to / 1304 obs-resent-cc / 1305 obs-resent-bcc / 1306 obs-resent-mid / 1307 obs-optional) 1309 Except for destination address fields (described in section 4.5.3), the 1310 interpretation of multiple occurrences of fields is unspecified. Also, the 1311 interpretation of trace fields and resent fields which do not occur in blocks 1312 prepended to the message is unspecified as well. Unless otherwise noted in the 1313 following sections, interpretation of other fields is identical to the 1314 interpretation of their non-obsolete counterparts in section 3. 1316 4.5.1 Obsolete origination date field 1318 obs-orig-date = "Date" *WSP ":" date-time CRLF 1320 4.5.2 Obsolete originator fields 1322 obs-from = "From" *WSP ":" mailbox-list CRLF 1324 obs-sender = "Sender" *WSP ":" mailbox CRLF 1326 obs-reply-to = "Reply-To" *WSP ":" mailbox-list CRLF 1328 4.5.3 Obsolete destination address fields 1330 obs-to = "To" *WSP ":" address-list CRLF 1332 obs-cc = "Cc" *WSP ":" address-list CRLF 1334 obs-bcc = "Bcc" *WSP ":" (address-list / [CFWS]) CRLF 1336 When multiple occurrences of destination address fields occur in a message, 1337 they SHOULD be treated as if the address-list in the first occurrence of the 1338 field is combined with the address lists of the subsequent occurrences by 1339 adding a comma and concatenating. 1341 4.5.4 Obsolete identification fields 1343 The obsolete "In-Reply-To:" and "References:" fields differ from the current 1344 syntax in that they allow phrase (words or quoted strings) to appear. The 1345 obsolete forms of the left and right sides of identifier allow interspersed 1346 CFWS, making them syntactically identical to local-part and domain 1347 respectively. 1349 obs-message-id = "Message-ID" *WSP ":" identifier CRLF 1351 obs-in-reply-to = "In-Reply-To" *WSP ":" *(phrase / identifier) CRLF 1353 obs-references = "References" *WSP ":" *(phrase / identifier) CRLF 1355 obs-id-left = local-part 1357 obs-id-right = domain 1359 For purposes of interpretation, the phrases in the "In-Reply-To:" and 1360 "References:" fields may be ignored. 1362 4.5.5 Obsolete informational fields 1364 obs-subject = "Subject" *WSP ":" unstructured CRLF 1366 obs-comments = "Comments" *WSP ":" unstructured CRLF 1368 obs-keywords = "Keywords" *WSP ":" *([phrase] ",") CRLF 1370 4.5.6 Obsolete resent fields 1372 The obsolete syntax adds a "Resent-Reply-To:" field, which consists of the 1373 field name, the optional comments and folding whitespace, the colon, and a 1374 comma separated list of addresses. 1376 obs-resent-from = "Resent-From" *WSP ":" mailbox-list CRLF 1378 obs-resent-send = "Resent-Sender" *WSP ":" mailbox CRLF 1380 obs-resent-date = "Resent-Date" *WSP ":" date-time CRLF 1382 obs-resent-to = "Resent-To" *WSP ":" address-list CRLF 1384 obs-resent-cc = "Resent-Cc" *WSP ":" address-list CRLF 1386 obs-resent-bcc = "Resent-Bcc" *WSP ":" (address-list / [CFWS]) CRLF 1388 obs-resent-mid = "Resent-Message-ID" *WSP ":" identifier CRLF 1390 obs-resent-rply = "Resent-Reply-To" *WSP ":" address-list CRLF 1392 As with other resent fields, the "Resent-Reply-To:" field should be treated as 1393 trace information only. 1395 4.5.7 Obsolete trace fields 1397 The obs-return and obs-received are again given here as template definitions, 1398 just as return and received are in section 3. Their full syntax is given in 1399 [SMTP]. 1401 obs-return = "Return-Path" *WSP ":" *([CFWS] text) CRLF 1403 obs-received = "Received" *WSP ":" *([CFWS] text) CRLF 1405 4.5.8 Obsolete optional fields 1407 obs-optional = field-name *WSP ":" unstructured CRLF 1409 5. Security Considerations 1411 Care should be taken when displaying messages on a terminal or terminal 1412 emulator. Powerful terminals may act on escape sequences and other 1413 combinations 1414 of ASCII control characters which remap the keyboard or permit other 1415 modifications to the terminal which could lead to denial of service or even 1416 damaged data. Message viewers may wish to strip potentially dangerous terminal 1417 escape sequences from the message prior to display. However, other escape 1418 sequences appear in messages for useful purposes (cf. [RFC-2045, RFC-2046, RFC- 1419 2047, RFC-2048, RFC-2049], [ISO-2022]) and therefore should not be stripped 1420 indiscriminately. 1422 Transmission of non-text objects in messages raises additional security 1423 issues. 1424 These issues are discussed is [RFC-2045, RFC-2046, RFC-2047, RFC-2048, RFC- 1425 2049]. 1427 Many implementations use the "Bcc:" (blind carbon copy) field described in 1428 section 3.6.3 to facilitate sending messages to recipients without revealing 1429 the addresses of one or more of the addressees to the other recipients. 1430 Mishandling this use of "Bcc:" has implications for confidential information 1431 that might be revealed, which could eventually lead to security problems 1432 through knowledge of even the existence of a particular mail address. For 1433 example, if using the first method described in section 3.6.3, where the 1434 "Bcc:" 1435 line is removed from the message, blind recipients have no explicit indication 1436 that they have been sent a blind copy, except insofar as their address does 1437 not 1438 appear in the message header. Because of this, one of the blind addressees 1439 could potentially send a reply to all of the shown recipients and accidentally 1440 revealing that the message went to the blind recipient. When the second method 1441 from section 3.6.3 is used, the blind recipients address appears in the "Bcc:" 1442 field of a separate copy of the message. If the "Bcc:" field sent contains all 1443 of the blind addressees, all of the "Bcc:" recipients will be seen by each 1444 "Bcc:" recipient. Even if a separate message is sent to each "Bcc:" recipient 1445 with only the individual's address, implementations must still be careful to 1446 process replies to the message as per section 3.6.3 so as not to accidentally 1447 reveal the blind recipient to other recipients. 1449 6. Bibliography 1451 [RFC-822] 1453 [RFC-2045] 1455 [RFC-2046] 1457 [RFC-2047] 1459 [RFC-2048] 1461 [RFC-2049] 1463 [SMTP] 1465 [RFC-2119] 1467 [RFC-2234] 1469 [ASCII] 1471 [STD-12] 1473 [DNS] 1475 [ISO-2022] 1477 7. Author's Address 1479 Peter W. Resnick 1480 QUALCOMM Incorporated 1481 6455 Lusk Boulevard 1482 San Diego, CA 92121-2779 1483 Phone: +1 619 651 4478 1484 FAX: +1 619 651 5334 1485 e-mail: presnick@qualcomm.com 1487 Grammar and syntax comments are welcome. Substantive comments on this document 1488 should be directed to the DRUMS working group. The subscription address is 1489 . 1491 8. Acknowledgements 1493 [TBD] 1495 Appendix A - Examples messages 1497 This section presents a selection of messages. These are intended to assist in 1498 the implementation of this standard, but should not be taken as normative; 1499 that 1500 is to say, although the examples in this section were carefully reviewed, if 1501 there happens to be a conflict between these examples and the syntax described 1502 in sections 3 and 4 of this document, the syntax in those sections is to be 1503 taken as correct. 1505 Messages are delimited in this section between lines of "----". The "----" 1506 lines are not part of the message itself. 1508 A.1 Adressing examples 1510 The following are examples of messages which might be sent between two 1511 individuals. 1513 A.1.1 A message from one person to another with simple addressing 1515 This could be called a canonical message. It has a single author, John Doe, a 1516 single recipient, Mary Smith, a subject, the date, a message identifier, and a 1517 textual message in the body. 1519 ---- 1520 From: John Doe 1521 To: Mary Smith 1522 Subject: Saying Hello 1523 Date: Fri, 21 Nov 1997 09:55:06 -0600 1524 Message-ID: <1234@local.machine.tld> 1526 This is a message just to say hello. 1527 So, "Hello". 1528 ---- 1530 A.1.2 Different types of mailboxes 1532 This message includes multiple addresses in the destination fields and also 1533 uses several different forms of addresses. 1535 ---- 1536 From: "Joe Q. Public" 1537 To: Mary Smith , jdoe@machine.tld, Who? 1538 Cc: , "System Service's Box" 1539 Date: Tue, 1 Jul 2003 10:52:37 +0200 1540 Message-ID: <5678.21-Nov-1997@hiccup.tld> 1542 Hi everyone. 1543 ---- 1545 Note that the display names for Joe Q. Public and System Service's Box needed 1546 to be enclosed in double-quotes because the contain the period and 1547 single-quote 1548 characters, while the display name for Who? could appear without them because 1549 the question mark is legal in an atom. Notice also that jdoe@machine.tld and 1550 boss@test.nil have no display names associated with them at all, and 1551 joe@machine.tld uses the simpler address form without the angle brackets. 1553 A.1.3 Group addresses 1555 ---- 1556 From: Pete 1557 To: A Group:Chris Jones ,joe@where.nil,John ; 1558 Cc: Undisclosed recipients:; 1559 Date: Sat, 15 May 1869 23:32:54 -0330 1560 Message-ID: 1562 Testing. 1563 ---- 1565 In this message, the "To:" field has a single group recipient named A Group 1566 which contains 3 addresses, and a "Cc:" field with an empty group recipient 1567 named Undisclosed recipients. 1569 A.2 Whitespace and comments 1571 A.3 Reply messages 1573 ---- 1574 From: John Doe 1575 To: Mary Smith 1576 Subject: Saying Hello 1577 Date: Fri, 21 Nov 1997 09:55:06 -0600 1578 Message-ID: <1234@local.machine.tld> 1580 This is a message just to say hello. 1581 So, "Hello". 1582 ---- 1584 ---- 1585 From: Mary Smith 1586 To: John Doe 1587 Subject: Re: Saying Hello 1588 Date: Fri, 21 Nov 1997 10:01:10 -0600 1589 Message-ID: <3456@harry.nil> 1590 In-Reply-To: <1234@local.machine.tld> 1591 References: <1234@local.machine.tld> 1593 This is a reply to your hello. 1594 ---- 1596 ---- 1597 To: Mary Smith 1598 From: John Doe 1599 Subject: Re: Saying Hello 1600 Date: Fri, 21 Nov 1997 11:00:00 -0600 1601 Message-ID: 1602 In-Reply-To: <3456@harry.nil> 1603 References: <1234@local.machine.tld> <3456@harry.nil> 1605 This is a reply to your reply. 1606 ---- 1608 A.4 Resent messages 1610 A.5 Messages with trace fields 1612 A.6 Other obsoleted forms 1614 Appendix B - Differences from earlier standards 1616 [Editor's Note: This will be real eventually, for now just changes in this 1617 draft. 1619 1. Fix FWS, CFWS, comment, obs-text, dot-atom, and atom. 1620 2. Change "unknown time zone" wording 1621 3. NUL character, not NULL 1622 4. Got rid of CHAR 1623 5. should -> SHOULD in 4.5.3 1624 6. null elements in domain-list 1625 7. Added obs-mailbox-list and obs-address-list for null elements 1626 8. null elements in obs-keywords 1627 9. Change [CFWS] to *WSP before ":" in obs-fields 1628 10. Change name-domain to addr-spec 1629 11. Typos 1630 12. Unstructured FWS is optional. 1631 13. Re: 1632 14. identifier -> message-id in 3.6 1633 15. Resent-Message-ID - address-list -> identifier 1634 16. FWS optional in quoted-string, domain-literal, atom, and comment 1635 17. Identifier redefined 1636 18. Message-ID text added 1637 19. Clarifications in folding 1638 20. Changed title (*shrug*) 1639 21. Clarified References and In-Reply-To formation 1640 22. Added "group-name" and "display-name" in addressing 1641 23. Added some examples 1642 24. Bcc may be empty. 1643 25. Added some Reply-To text in lieu of something new 1645 To do list: 1647 Specifically talk about X-* headers. 1648 Change reply-to yet again? 1649 Bibliography 1650 Acknowledgements 1651 Examples 1652 Differences 1654 ]