rfc822.txt (106299B)
1 2 3 4 5 6 7 RFC # 822 8 9 Obsoletes: RFC #733 (NIC #41952) 10 11 12 13 14 15 16 17 18 19 20 21 22 STANDARD FOR THE FORMAT OF 23 24 ARPA INTERNET TEXT MESSAGES 25 26 27 28 29 30 31 August 13, 1982 32 33 34 35 36 37 38 Revised by 39 40 David H. Crocker 41 42 43 Dept. of Electrical Engineering 44 University of Delaware, Newark, DE 19711 45 Network: DCrocker @ UDel-Relay 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 Standard for ARPA Internet Text Messages 62 63 64 TABLE OF CONTENTS 65 66 67 PREFACE .................................................... ii 68 69 1. INTRODUCTION ........................................... 1 70 71 1.1. Scope ............................................ 1 72 1.2. Communication Framework .......................... 2 73 74 2. NOTATIONAL CONVENTIONS ................................. 3 75 76 3. LEXICAL ANALYSIS OF MESSAGES ........................... 5 77 78 3.1. General Description .............................. 5 79 3.2. Header Field Definitions ......................... 9 80 3.3. Lexical Tokens ................................... 10 81 3.4. Clarifications ................................... 11 82 83 4. MESSAGE SPECIFICATION .................................. 17 84 85 4.1. Syntax ........................................... 17 86 4.2. Forwarding ....................................... 19 87 4.3. Trace Fields ..................................... 20 88 4.4. Originator Fields ................................ 21 89 4.5. Receiver Fields .................................. 23 90 4.6. Reference Fields ................................. 23 91 4.7. Other Fields ..................................... 24 92 93 5. DATE AND TIME SPECIFICATION ............................ 26 94 95 5.1. Syntax ........................................... 26 96 5.2. Semantics ........................................ 26 97 98 6. ADDRESS SPECIFICATION .................................. 27 99 100 6.1. Syntax ........................................... 27 101 6.2. Semantics ........................................ 27 102 6.3. Reserved Address ................................. 33 103 104 7. BIBLIOGRAPHY ........................................... 34 105 106 107 APPENDIX 108 109 A. EXAMPLES ............................................... 36 110 B. SIMPLE FIELD PARSING ................................... 40 111 C. DIFFERENCES FROM RFC #733 .............................. 41 112 D. ALPHABETICAL LISTING OF SYNTAX RULES ................... 44 113 114 115 August 13, 1982 - i - RFC #822 116 117 118 119 120 Standard for ARPA Internet Text Messages 121 122 123 PREFACE 124 125 126 By 1977, the Arpanet employed several informal standards for 127 the text messages (mail) sent among its host computers. It was 128 felt necessary to codify these practices and provide for those 129 features that seemed imminent. The result of that effort was 130 Request for Comments (RFC) #733, "Standard for the Format of ARPA 131 Network Text Message", by Crocker, Vittal, Pogran, and Henderson. 132 The specification attempted to avoid major changes in existing 133 software, while permitting several new features. 134 135 This document revises the specifications in RFC #733, in 136 order to serve the needs of the larger and more complex ARPA 137 Internet. Some of RFC #733's features failed to gain adequate 138 acceptance. In order to simplify the standard and the software 139 that follows it, these features have been removed. A different 140 addressing scheme is used, to handle the case of inter-network 141 mail; and the concept of re-transmission has been introduced. 142 143 This specification is intended for use in the ARPA Internet. 144 However, an attempt has been made to free it of any dependence on 145 that environment, so that it can be applied to other network text 146 message systems. 147 148 The specification of RFC #733 took place over the course of 149 one year, using the ARPANET mail environment, itself, to provide 150 an on-going forum for discussing the capabilities to be included. 151 More than twenty individuals, from across the country, partici- 152 pated in the original discussion. The development of this 153 revised specification has, similarly, utilized network mail-based 154 group discussion. Both specification efforts greatly benefited 155 from the comments and ideas of the participants. 156 157 The syntax of the standard, in RFC #733, was originally 158 specified in the Backus-Naur Form (BNF) meta-language. Ken L. 159 Harrenstien, of SRI International, was responsible for re-coding 160 the BNF into an augmented BNF that makes the representation 161 smaller and easier to understand. 162 163 164 165 166 167 168 169 170 171 172 173 174 August 13, 1982 - ii - RFC #822 175 176 177 178 Standard for ARPA Internet Text Messages 179 180 181 1. INTRODUCTION 182 183 1.1. SCOPE 184 185 This standard specifies a syntax for text messages that are 186 sent among computer users, within the framework of "electronic 187 mail". The standard supersedes the one specified in ARPANET 188 Request for Comments #733, "Standard for the Format of ARPA Net- 189 work Text Messages". 190 191 In this context, messages are viewed as having an envelope 192 and contents. The envelope contains whatever information is 193 needed to accomplish transmission and delivery. The contents 194 compose the object to be delivered to the recipient. This stan- 195 dard applies only to the format and some of the semantics of mes- 196 sage contents. It contains no specification of the information 197 in the envelope. 198 199 However, some message systems may use information from the 200 contents to create the envelope. It is intended that this stan- 201 dard facilitate the acquisition of such information by programs. 202 203 Some message systems may store messages in formats that 204 differ from the one specified in this standard. This specifica- 205 tion is intended strictly as a definition of what message content 206 format is to be passed BETWEEN hosts. 207 208 Note: This standard is NOT intended to dictate the internal for- 209 mats used by sites, the specific message system features 210 that they are expected to support, or any of the charac- 211 teristics of user interface programs that create or read 212 messages. 213 214 A distinction should be made between what the specification 215 REQUIRES and what it ALLOWS. Messages can be made complex and 216 rich with formally-structured components of information or can be 217 kept small and simple, with a minimum of such information. Also, 218 the standard simplifies the interpretation of differing visual 219 formats in messages; only the visual aspect of a message is 220 affected and not the interpretation of information within it. 221 Implementors may choose to retain such visual distinctions. 222 223 The formal definition is divided into four levels. The bot- 224 tom level describes the meta-notation used in this document. The 225 second level describes basic lexical analyzers that feed tokens 226 to higher-level parsers. Next is an overall specification for 227 messages; it permits distinguishing individual fields. Finally, 228 there is definition of the contents of several structured fields. 229 230 231 232 August 13, 1982 - 1 - RFC #822 233 234 235 236 Standard for ARPA Internet Text Messages 237 238 239 1.2. COMMUNICATION FRAMEWORK 240 241 Messages consist of lines of text. No special provisions 242 are made for encoding drawings, facsimile, speech, or structured 243 text. No significant consideration has been given to questions 244 of data compression or to transmission and storage efficiency, 245 and the standard tends to be free with the number of bits con- 246 sumed. For example, field names are specified as free text, 247 rather than special terse codes. 248 249 A general "memo" framework is used. That is, a message con- 250 sists of some information in a rigid format, followed by the main 251 part of the message, with a format that is not specified in this 252 document. The syntax of several fields of the rigidly-formated 253 ("headers") section is defined in this specification; some of 254 these fields must be included in all messages. 255 256 The syntax that distinguishes between header fields is 257 specified separately from the internal syntax for particular 258 fields. This separation is intended to allow simple parsers to 259 operate on the general structure of messages, without concern for 260 the detailed structure of individual header fields. Appendix B 261 is provided to facilitate construction of these parsers. 262 263 In addition to the fields specified in this document, it is 264 expected that other fields will gain common use. As necessary, 265 the specifications for these "extension-fields" will be published 266 through the same mechanism used to publish this document. Users 267 may also wish to extend the set of fields that they use 268 privately. Such "user-defined fields" are permitted. 269 270 The framework severely constrains document tone and appear- 271 ance and is primarily useful for most intra-organization communi- 272 cations and well-structured inter-organization communication. 273 It also can be used for some types of inter-process communica- 274 tion, such as simple file transfer and remote job entry. A more 275 robust framework might allow for multi-font, multi-color, multi- 276 dimension encoding of information. A less robust one, as is 277 present in most single-machine message systems, would more 278 severely constrain the ability to add fields and the decision to 279 include specific fields. In contrast with paper-based communica- 280 tion, it is interesting to note that the RECEIVER of a message 281 can exercise an extraordinary amount of control over the 282 message's appearance. The amount of actual control available to 283 message receivers is contingent upon the capabilities of their 284 individual message systems. 285 286 287 288 289 290 August 13, 1982 - 2 - RFC #822 291 292 293 294 Standard for ARPA Internet Text Messages 295 296 297 2. NOTATIONAL CONVENTIONS 298 299 This specification uses an augmented Backus-Naur Form (BNF) 300 notation. The differences from standard BNF involve naming rules 301 and indicating repetition and "local" alternatives. 302 303 2.1. RULE NAMING 304 305 Angle brackets ("<", ">") are not used, in general. The 306 name of a rule is simply the name itself, rather than "<name>". 307 Quotation-marks enclose literal text (which may be upper and/or 308 lower case). Certain basic rules are in uppercase, such as 309 SPACE, TAB, CRLF, DIGIT, ALPHA, etc. Angle brackets are used in 310 rule definitions, and in the rest of this document, whenever 311 their presence will facilitate discerning the use of rule names. 312 313 2.2. RULE1 / RULE2: ALTERNATIVES 314 315 Elements separated by slash ("/") are alternatives. There- 316 fore "foo / bar" will accept foo or bar. 317 318 2.3. (RULE1 RULE2): LOCAL ALTERNATIVES 319 320 Elements enclosed in parentheses are treated as a single 321 element. Thus, "(elem (foo / bar) elem)" allows the token 322 sequences "elem foo elem" and "elem bar elem". 323 324 2.4. *RULE: REPETITION 325 326 The character "*" preceding an element indicates repetition. 327 The full form is: 328 329 <l>*<m>element 330 331 indicating at least <l> and at most <m> occurrences of element. 332 Default values are 0 and infinity so that "*(element)" allows any 333 number, including zero; "1*element" requires at least one; and 334 "1*2element" allows one or two. 335 336 2.5. [RULE]: OPTIONAL 337 338 Square brackets enclose optional elements; "[foo bar]" is 339 equivalent to "*1(foo bar)". 340 341 2.6. NRULE: SPECIFIC REPETITION 342 343 "<n>(element)" is equivalent to "<n>*<n>(element)"; that is, 344 exactly <n> occurrences of (element). Thus 2DIGIT is a 2-digit 345 number, and 3ALPHA is a string of three alphabetic characters. 346 347 348 August 13, 1982 - 3 - RFC #822 349 350 351 352 Standard for ARPA Internet Text Messages 353 354 355 2.7. #RULE: LISTS 356 357 A construct "#" is defined, similar to "*", as follows: 358 359 <l>#<m>element 360 361 indicating at least <l> and at most <m> elements, each separated 362 by one or more commas (","). This makes the usual form of lists 363 very easy; a rule such as '(element *("," element))' can be shown 364 as "1#element". Wherever this construct is used, null elements 365 are allowed, but do not contribute to the count of elements 366 present. That is, "(element),,(element)" is permitted, but 367 counts as only two elements. Therefore, where at least one ele- 368 ment is required, at least one non-null element must be present. 369 Default values are 0 and infinity so that "#(element)" allows any 370 number, including zero; "1#element" requires at least one; and 371 "1#2element" allows one or two. 372 373 2.8. ; COMMENTS 374 375 A semi-colon, set off some distance to the right of rule 376 text, starts a comment that continues to the end of line. This 377 is a simple way of including useful notes in parallel with the 378 specifications. 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 August 13, 1982 - 4 - RFC #822 407 408 409 410 Standard for ARPA Internet Text Messages 411 412 413 3. LEXICAL ANALYSIS OF MESSAGES 414 415 3.1. GENERAL DESCRIPTION 416 417 A message consists of header fields and, optionally, a body. 418 The body is simply a sequence of lines containing ASCII charac- 419 ters. It is separated from the headers by a null line (i.e., a 420 line with nothing preceding the CRLF). 421 422 3.1.1. LONG HEADER FIELDS 423 424 Each header field can be viewed as a single, logical line of 425 ASCII characters, comprising a field-name and a field-body. 426 For convenience, the field-body portion of this conceptual 427 entity can be split into a multiple-line representation; this 428 is called "folding". The general rule is that wherever there 429 may be linear-white-space (NOT simply LWSP-chars), a CRLF 430 immediately followed by AT LEAST one LWSP-char may instead be 431 inserted. Thus, the single line 432 433 To: "Joe & J. Harvey" <ddd @Org>, JJV @ BBN 434 435 can be represented as: 436 437 To: "Joe & J. Harvey" <ddd @ Org>, 438 JJV@BBN 439 440 and 441 442 To: "Joe & J. Harvey" 443 <ddd@ Org>, JJV 444 @BBN 445 446 and 447 448 To: "Joe & 449 J. Harvey" <ddd @ Org>, JJV @ BBN 450 451 The process of moving from this folded multiple-line 452 representation of a header field to its single line represen- 453 tation is called "unfolding". Unfolding is accomplished by 454 regarding CRLF immediately followed by a LWSP-char as 455 equivalent to the LWSP-char. 456 457 Note: While the standard permits folding wherever linear- 458 white-space is permitted, it is recommended that struc- 459 tured fields, such as those containing addresses, limit 460 folding to higher-level syntactic breaks. For address 461 fields, it is recommended that such folding occur 462 463 464 August 13, 1982 - 5 - RFC #822 465 466 467 468 Standard for ARPA Internet Text Messages 469 470 471 between addresses, after the separating comma. 472 473 3.1.2. STRUCTURE OF HEADER FIELDS 474 475 Once a field has been unfolded, it may be viewed as being com- 476 posed of a field-name followed by a colon (":"), followed by a 477 field-body, and terminated by a carriage-return/line-feed. 478 The field-name must be composed of printable ASCII characters 479 (i.e., characters that have values between 33. and 126., 480 decimal, except colon). The field-body may be composed of any 481 ASCII characters, except CR or LF. (While CR and/or LF may be 482 present in the actual text, they are removed by the action of 483 unfolding the field.) 484 485 Certain field-bodies of headers may be interpreted according 486 to an internal syntax that some systems may wish to parse. 487 These fields are called "structured fields". Examples 488 include fields containing dates and addresses. Other fields, 489 such as "Subject" and "Comments", are regarded simply as 490 strings of text. 491 492 Note: Any field which has a field-body that is defined as 493 other than simply <text> is to be treated as a struc- 494 tured field. 495 496 Field-names, unstructured field bodies and structured 497 field bodies each are scanned by their own, independent 498 "lexical" analyzers. 499 500 3.1.3. UNSTRUCTURED FIELD BODIES 501 502 For some fields, such as "Subject" and "Comments", no struc- 503 turing is assumed, and they are treated simply as <text>s, as 504 in the message body. Rules of folding apply to these fields, 505 so that such field bodies which occupy several lines must 506 therefore have the second and successive lines indented by at 507 least one LWSP-char. 508 509 3.1.4. STRUCTURED FIELD BODIES 510 511 To aid in the creation and reading of structured fields, the 512 free insertion of linear-white-space (which permits folding 513 by inclusion of CRLFs) is allowed between lexical tokens. 514 Rather than obscuring the syntax specifications for these 515 structured fields with explicit syntax for this linear-white- 516 space, the existence of another "lexical" analyzer is assumed. 517 This analyzer does not apply for unstructured field bodies 518 that are simply strings of text, as described above. The 519 analyzer provides an interpretation of the unfolded text 520 521 522 August 13, 1982 - 6 - RFC #822 523 524 525 526 Standard for ARPA Internet Text Messages 527 528 529 composing the body of the field as a sequence of lexical sym- 530 bols. 531 532 These symbols are: 533 534 - individual special characters 535 - quoted-strings 536 - domain-literals 537 - comments 538 - atoms 539 540 The first four of these symbols are self-delimiting. Atoms 541 are not; they are delimited by the self-delimiting symbols and 542 by linear-white-space. For the purposes of regenerating 543 sequences of atoms and quoted-strings, exactly one SPACE is 544 assumed to exist, and should be used, between them. (Also, in 545 the "Clarifications" section on "White Space", below, note the 546 rules about treatment of multiple contiguous LWSP-chars.) 547 548 So, for example, the folded body of an address field 549 550 ":sysmail"@ Some-Group. Some-Org, 551 Muhammed.(I am the greatest) Ali @(the)Vegas.WBA 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 August 13, 1982 - 7 - RFC #822 581 582 583 584 Standard for ARPA Internet Text Messages 585 586 587 is analyzed into the following lexical symbols and types: 588 589 :sysmail quoted string 590 @ special 591 Some-Group atom 592 . special 593 Some-Org atom 594 , special 595 Muhammed atom 596 . special 597 (I am the greatest) comment 598 Ali atom 599 @ atom 600 (the) comment 601 Vegas atom 602 . special 603 WBA atom 604 605 The canonical representations for the data in these addresses 606 are the following strings: 607 608 ":sysmail"@Some-Group.Some-Org 609 610 and 611 612 Muhammed.Ali@Vegas.WBA 613 614 Note: For purposes of display, and when passing such struc- 615 tured information to other systems, such as mail proto- 616 col services, there must be NO linear-white-space 617 between <word>s that are separated by period (".") or 618 at-sign ("@") and exactly one SPACE between all other 619 <word>s. Also, headers should be in a folded form. 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 August 13, 1982 - 8 - RFC #822 639 640 641 642 Standard for ARPA Internet Text Messages 643 644 645 3.2. HEADER FIELD DEFINITIONS 646 647 These rules show a field meta-syntax, without regard for the 648 particular type or internal syntax. Their purpose is to permit 649 detection of fields; also, they present to higher-level parsers 650 an image of each field as fitting on one line. 651 652 field = field-name ":" [ field-body ] CRLF 653 654 field-name = 1*<any CHAR, excluding CTLs, SPACE, and ":"> 655 656 field-body = field-body-contents 657 [CRLF LWSP-char field-body] 658 659 field-body-contents = 660 <the ASCII characters making up the field-body, as 661 defined in the following sections, and consisting 662 of combinations of atom, quoted-string, and 663 specials tokens, or else consisting of texts> 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 August 13, 1982 - 9 - RFC #822 697 698 699 700 Standard for ARPA Internet Text Messages 701 702 703 3.3. LEXICAL TOKENS 704 705 The following rules are used to define an underlying lexical 706 analyzer, which feeds tokens to higher level parsers. See the 707 ANSI references, in the Bibliography. 708 709 ; ( Octal, Decimal.) 710 CHAR = <any ASCII character> ; ( 0-177, 0.-127.) 711 ALPHA = <any ASCII alphabetic character> 712 ; (101-132, 65.- 90.) 713 ; (141-172, 97.-122.) 714 DIGIT = <any ASCII decimal digit> ; ( 60- 71, 48.- 57.) 715 CTL = <any ASCII control ; ( 0- 37, 0.- 31.) 716 character and DEL> ; ( 177, 127.) 717 CR = <ASCII CR, carriage return> ; ( 15, 13.) 718 LF = <ASCII LF, linefeed> ; ( 12, 10.) 719 SPACE = <ASCII SP, space> ; ( 40, 32.) 720 HTAB = <ASCII HT, horizontal-tab> ; ( 11, 9.) 721 <"> = <ASCII quote mark> ; ( 42, 34.) 722 CRLF = CR LF 723 724 LWSP-char = SPACE / HTAB ; semantics = SPACE 725 726 linear-white-space = 1*([CRLF] LWSP-char) ; semantics = SPACE 727 ; CRLF => folding 728 729 specials = "(" / ")" / "<" / ">" / "@" ; Must be in quoted- 730 / "," / ";" / ":" / "\" / <"> ; string, to use 731 / "." / "[" / "]" ; within a word. 732 733 delimiters = specials / linear-white-space / comment 734 735 text = <any CHAR, including bare ; => atoms, specials, 736 CR & bare LF, but NOT ; comments and 737 including CRLF> ; quoted-strings are 738 ; NOT recognized. 739 740 atom = 1*<any CHAR except specials, SPACE and CTLs> 741 742 quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or 743 ; quoted chars. 744 745 qtext = <any CHAR excepting <">, ; => may be folded 746 "\" & CR, and including 747 linear-white-space> 748 749 domain-literal = "[" *(dtext / quoted-pair) "]" 750 751 752 753 754 August 13, 1982 - 10 - RFC #822 755 756 757 758 Standard for ARPA Internet Text Messages 759 760 761 dtext = <any CHAR excluding "[", ; => may be folded 762 "]", "\" & CR, & including 763 linear-white-space> 764 765 comment = "(" *(ctext / quoted-pair / comment) ")" 766 767 ctext = <any CHAR excluding "(", ; => may be folded 768 ")", "\" & CR, & including 769 linear-white-space> 770 771 quoted-pair = "\" CHAR ; may quote any char 772 773 phrase = 1*word ; Sequence of words 774 775 word = atom / quoted-string 776 777 778 3.4. CLARIFICATIONS 779 780 3.4.1. QUOTING 781 782 Some characters are reserved for special interpretation, such 783 as delimiting lexical tokens. To permit use of these charac- 784 ters as uninterpreted data, a quoting mechanism is provided. 785 To quote a character, precede it with a backslash ("\"). 786 787 This mechanism is not fully general. Characters may be quoted 788 only within a subset of the lexical constructs. In particu- 789 lar, quoting is limited to use within: 790 791 - quoted-string 792 - domain-literal 793 - comment 794 795 Within these constructs, quoting is REQUIRED for CR and "\" 796 and for the character(s) that delimit the token (e.g., "(" and 797 ")" for a comment). However, quoting is PERMITTED for any 798 character. 799 800 Note: In particular, quoting is NOT permitted within atoms. 801 For example when the local-part of an addr-spec must 802 contain a special character, a quoted string must be 803 used. Therefore, a specification such as: 804 805 Full\ Name@Domain 806 807 is not legal and must be specified as: 808 809 "Full Name"@Domain 810 811 812 August 13, 1982 - 11 - RFC #822 813 814 815 816 Standard for ARPA Internet Text Messages 817 818 819 3.4.2. WHITE SPACE 820 821 Note: In structured field bodies, multiple linear space ASCII 822 characters (namely HTABs and SPACEs) are treated as 823 single spaces and may freely surround any symbol. In 824 all header fields, the only place in which at least one 825 LWSP-char is REQUIRED is at the beginning of continua- 826 tion lines in a folded field. 827 828 When passing text to processes that do not interpret text 829 according to this standard (e.g., mail protocol servers), then 830 NO linear-white-space characters should occur between a period 831 (".") or at-sign ("@") and a <word>. Exactly ONE SPACE should 832 be used in place of arbitrary linear-white-space and comment 833 sequences. 834 835 Note: Within systems conforming to this standard, wherever a 836 member of the list of delimiters is allowed, LWSP-chars 837 may also occur before and/or after it. 838 839 Writers of mail-sending (i.e., header-generating) programs 840 should realize that there is no network-wide definition of the 841 effect of ASCII HT (horizontal-tab) characters on the appear- 842 ance of text at another network host; therefore, the use of 843 tabs in message headers, though permitted, is discouraged. 844 845 3.4.3. COMMENTS 846 847 A comment is a set of ASCII characters, which is enclosed in 848 matching parentheses and which is not within a quoted-string 849 The comment construct permits message originators to add text 850 which will be useful for human readers, but which will be 851 ignored by the formal semantics. Comments should be retained 852 while the message is subject to interpretation according to 853 this standard. However, comments must NOT be included in 854 other cases, such as during protocol exchanges with mail 855 servers. 856 857 Comments nest, so that if an unquoted left parenthesis occurs 858 in a comment string, there must also be a matching right 859 parenthesis. When a comment acts as the delimiter between a 860 sequence of two lexical symbols, such as two atoms, it is lex- 861 ically equivalent with a single SPACE, for the purposes of 862 regenerating the sequence, such as when passing the sequence 863 onto a mail protocol server. Comments are detected as such 864 only within field-bodies of structured fields. 865 866 If a comment is to be "folded" onto multiple lines, then the 867 syntax for folding must be adhered to. (See the "Lexical 868 869 870 August 13, 1982 - 12 - RFC #822 871 872 873 874 Standard for ARPA Internet Text Messages 875 876 877 Analysis of Messages" section on "Folding Long Header Fields" 878 above, and the section on "Case Independence" below.) Note 879 that the official semantics therefore do not "see" any 880 unquoted CRLFs that are in comments, although particular pars- 881 ing programs may wish to note their presence. For these pro- 882 grams, it would be reasonable to interpret a "CRLF LWSP-char" 883 as being a CRLF that is part of the comment; i.e., the CRLF is 884 kept and the LWSP-char is discarded. Quoted CRLFs (i.e., a 885 backslash followed by a CR followed by a LF) still must be 886 followed by at least one LWSP-char. 887 888 3.4.4. DELIMITING AND QUOTING CHARACTERS 889 890 The quote character (backslash) and characters that delimit 891 syntactic units are not, generally, to be taken as data that 892 are part of the delimited or quoted unit(s). In particular, 893 the quotation-marks that define a quoted-string, the 894 parentheses that define a comment and the backslash that 895 quotes a following character are NOT part of the quoted- 896 string, comment or quoted character. A quotation-mark that is 897 to be part of a quoted-string, a parenthesis that is to be 898 part of a comment and a backslash that is to be part of either 899 must each be preceded by the quote-character backslash ("\"). 900 Note that the syntax allows any character to be quoted within 901 a quoted-string or comment; however only certain characters 902 MUST be quoted to be included as data. These characters are 903 the ones that are not part of the alternate text group (i.e., 904 ctext or qtext). 905 906 The one exception to this rule is that a single SPACE is 907 assumed to exist between contiguous words in a phrase, and 908 this interpretation is independent of the actual number of 909 LWSP-chars that the creator places between the words. To 910 include more than one SPACE, the creator must make the LWSP- 911 chars be part of a quoted-string. 912 913 Quotation marks that delimit a quoted string and backslashes 914 that quote the following character should NOT accompany the 915 quoted-string when the string is passed to processes that do 916 not interpret data according to this specification (e.g., mail 917 protocol servers). 918 919 3.4.5. QUOTED-STRINGS 920 921 Where permitted (i.e., in words in structured fields) quoted- 922 strings are treated as a single symbol. That is, a quoted- 923 string is equivalent to an atom, syntactically. If a quoted- 924 string is to be "folded" onto multiple lines, then the syntax 925 for folding must be adhered to. (See the "Lexical Analysis of 926 927 928 August 13, 1982 - 13 - RFC #822 929 930 931 932 Standard for ARPA Internet Text Messages 933 934 935 Messages" section on "Folding Long Header Fields" above, and 936 the section on "Case Independence" below.) Therefore, the 937 official semantics do not "see" any bare CRLFs that are in 938 quoted-strings; however particular parsing programs may wish 939 to note their presence. For such programs, it would be rea- 940 sonable to interpret a "CRLF LWSP-char" as being a CRLF which 941 is part of the quoted-string; i.e., the CRLF is kept and the 942 LWSP-char is discarded. Quoted CRLFs (i.e., a backslash fol- 943 lowed by a CR followed by a LF) are also subject to rules of 944 folding, but the presence of the quoting character (backslash) 945 explicitly indicates that the CRLF is data to the quoted 946 string. Stripping off the first following LWSP-char is also 947 appropriate when parsing quoted CRLFs. 948 949 3.4.6. BRACKETING CHARACTERS 950 951 There is one type of bracket which must occur in matched pairs 952 and may have pairs nested within each other: 953 954 o Parentheses ("(" and ")") are used to indicate com- 955 ments. 956 957 There are three types of brackets which must occur in matched 958 pairs, and which may NOT be nested: 959 960 o Colon/semi-colon (":" and ";") are used in address 961 specifications to indicate that the included list of 962 addresses are to be treated as a group. 963 964 o Angle brackets ("<" and ">") are generally used to 965 indicate the presence of a one machine-usable refer- 966 ence (e.g., delimiting mailboxes), possibly including 967 source-routing to the machine. 968 969 o Square brackets ("[" and "]") are used to indicate the 970 presence of a domain-literal, which the appropriate 971 name-domain is to use directly, bypassing normal 972 name-resolution mechanisms. 973 974 3.4.7. CASE INDEPENDENCE 975 976 Except as noted, alphabetic strings may be represented in any 977 combination of upper and lower case. The only syntactic units 978 979 980 981 982 983 984 985 986 August 13, 1982 - 14 - RFC #822 987 988 989 990 Standard for ARPA Internet Text Messages 991 992 993 which requires preservation of case information are: 994 995 - text 996 - qtext 997 - dtext 998 - ctext 999 - quoted-pair 1000 - local-part, except "Postmaster" 1001 1002 When matching any other syntactic unit, case is to be ignored. 1003 For example, the field-names "From", "FROM", "from", and even 1004 "FroM" are semantically equal and should all be treated ident- 1005 ically. 1006 1007 When generating these units, any mix of upper and lower case 1008 alphabetic characters may be used. The case shown in this 1009 specification is suggested for message-creating processes. 1010 1011 Note: The reserved local-part address unit, "Postmaster", is 1012 an exception. When the value "Postmaster" is being 1013 interpreted, it must be accepted in any mixture of 1014 case, including "POSTMASTER", and "postmaster". 1015 1016 3.4.8. FOLDING LONG HEADER FIELDS 1017 1018 Each header field may be represented on exactly one line con- 1019 sisting of the name of the field and its body, and terminated 1020 by a CRLF; this is what the parser sees. For readability, the 1021 field-body portion of long header fields may be "folded" onto 1022 multiple lines of the actual field. "Long" is commonly inter- 1023 preted to mean greater than 65 or 72 characters. The former 1024 length serves as a limit, when the message is to be viewed on 1025 most simple terminals which use simple display software; how- 1026 ever, the limit is not imposed by this standard. 1027 1028 Note: Some display software often can selectively fold lines, 1029 to suit the display terminal. In such cases, sender- 1030 provided folding can interfere with the display 1031 software. 1032 1033 3.4.9. BACKSPACE CHARACTERS 1034 1035 ASCII BS characters (Backspace, decimal 8) may be included in 1036 texts and quoted-strings to effect overstriking. However, any 1037 use of backspaces which effects an overstrike to the left of 1038 the beginning of the text or quoted-string is prohibited. 1039 1040 1041 1042 1043 1044 August 13, 1982 - 15 - RFC #822 1045 1046 1047 1048 Standard for ARPA Internet Text Messages 1049 1050 1051 3.4.10. NETWORK-SPECIFIC TRANSFORMATIONS 1052 1053 During transmission through heterogeneous networks, it may be 1054 necessary to force data to conform to a network's local con- 1055 ventions. For example, it may be required that a CR be fol- 1056 lowed either by LF, making a CRLF, or by <null>, if the CR is 1057 to stand alone). Such transformations are reversed, when the 1058 message exits that network. 1059 1060 When crossing network boundaries, the message should be 1061 treated as passing through two modules. It will enter the 1062 first module containing whatever network-specific transforma- 1063 tions that were necessary to permit migration through the 1064 "current" network. It then passes through the modules: 1065 1066 o Transformation Reversal 1067 1068 The "current" network's idiosyncracies are removed and 1069 the message is returned to the canonical form speci- 1070 fied in this standard. 1071 1072 o Transformation 1073 1074 The "next" network's local idiosyncracies are imposed 1075 on the message. 1076 1077 ------------------ 1078 From ==> | Remove Net-A | 1079 Net-A | idiosyncracies | 1080 ------------------ 1081 || 1082 \/ 1083 Conformance 1084 with standard 1085 || 1086 \/ 1087 ------------------ 1088 | Impose Net-B | ==> To 1089 | idiosyncracies | Net-B 1090 ------------------ 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 August 13, 1982 - 16 - RFC #822 1103 1104 1105 1106 Standard for ARPA Internet Text Messages 1107 1108 1109 4. MESSAGE SPECIFICATION 1110 1111 4.1. SYNTAX 1112 1113 Note: Due to an artifact of the notational conventions, the syn- 1114 tax indicates that, when present, some fields, must be in 1115 a particular order. Header fields are NOT required to 1116 occur in any particular order, except that the message 1117 body must occur AFTER the headers. It is recommended 1118 that, if present, headers be sent in the order "Return- 1119 Path", "Received", "Date", "From", "Subject", "Sender", 1120 "To", "cc", etc. 1121 1122 This specification permits multiple occurrences of most 1123 fields. Except as noted, their interpretation is not 1124 specified here, and their use is discouraged. 1125 1126 The following syntax for the bodies of various fields should 1127 be thought of as describing each field body as a single long 1128 string (or line). The "Lexical Analysis of Message" section on 1129 "Long Header Fields", above, indicates how such long strings can 1130 be represented on more than one line in the actual transmitted 1131 message. 1132 1133 message = fields *( CRLF *text ) ; Everything after 1134 ; first null line 1135 ; is message body 1136 1137 fields = dates ; Creation time, 1138 source ; author id & one 1139 1*destination ; address required 1140 *optional-field ; others optional 1141 1142 source = [ trace ] ; net traversals 1143 originator ; original mail 1144 [ resent ] ; forwarded 1145 1146 trace = return ; path to sender 1147 1*received ; receipt tags 1148 1149 return = "Return-path" ":" route-addr ; return address 1150 1151 received = "Received" ":" ; one per relay 1152 ["from" domain] ; sending host 1153 ["by" domain] ; receiving host 1154 ["via" atom] ; physical path 1155 *("with" atom) ; link/mail protocol 1156 ["id" msg-id] ; receiver msg id 1157 ["for" addr-spec] ; initial form 1158 1159 1160 August 13, 1982 - 17 - RFC #822 1161 1162 1163 1164 Standard for ARPA Internet Text Messages 1165 1166 1167 ";" date-time ; time received 1168 1169 originator = authentic ; authenticated addr 1170 [ "Reply-To" ":" 1#address] ) 1171 1172 authentic = "From" ":" mailbox ; Single author 1173 / ( "Sender" ":" mailbox ; Actual submittor 1174 "From" ":" 1#mailbox) ; Multiple authors 1175 ; or not sender 1176 1177 resent = resent-authentic 1178 [ "Resent-Reply-To" ":" 1#address] ) 1179 1180 resent-authentic = 1181 = "Resent-From" ":" mailbox 1182 / ( "Resent-Sender" ":" mailbox 1183 "Resent-From" ":" 1#mailbox ) 1184 1185 dates = orig-date ; Original 1186 [ resent-date ] ; Forwarded 1187 1188 orig-date = "Date" ":" date-time 1189 1190 resent-date = "Resent-Date" ":" date-time 1191 1192 destination = "To" ":" 1#address ; Primary 1193 / "Resent-To" ":" 1#address 1194 / "cc" ":" 1#address ; Secondary 1195 / "Resent-cc" ":" 1#address 1196 / "bcc" ":" #address ; Blind carbon 1197 / "Resent-bcc" ":" #address 1198 1199 optional-field = 1200 / "Message-ID" ":" msg-id 1201 / "Resent-Message-ID" ":" msg-id 1202 / "In-Reply-To" ":" *(phrase / msg-id) 1203 / "References" ":" *(phrase / msg-id) 1204 / "Keywords" ":" #phrase 1205 / "Subject" ":" *text 1206 / "Comments" ":" *text 1207 / "Encrypted" ":" 1#2word 1208 / extension-field ; To be defined 1209 / user-defined-field ; May be pre-empted 1210 1211 msg-id = "<" addr-spec ">" ; Unique message id 1212 1213 1214 1215 1216 1217 1218 August 13, 1982 - 18 - RFC #822 1219 1220 1221 1222 Standard for ARPA Internet Text Messages 1223 1224 1225 extension-field = 1226 <Any field which is defined in a document 1227 published as a formal extension to this 1228 specification; none will have names beginning 1229 with the string "X-"> 1230 1231 user-defined-field = 1232 <Any field which has not been defined 1233 in this specification or published as an 1234 extension to this specification; names for 1235 such fields must be unique and may be 1236 pre-empted by published extensions> 1237 1238 4.2. FORWARDING 1239 1240 Some systems permit mail recipients to forward a message, 1241 retaining the original headers, by adding some new fields. This 1242 standard supports such a service, through the "Resent-" prefix to 1243 field names. 1244 1245 Whenever the string "Resent-" begins a field name, the field 1246 has the same semantics as a field whose name does not have the 1247 prefix. However, the message is assumed to have been forwarded 1248 by an original recipient who attached the "Resent-" field. This 1249 new field is treated as being more recent than the equivalent, 1250 original field. For example, the "Resent-From", indicates the 1251 person that forwarded the message, whereas the "From" field indi- 1252 cates the original author. 1253 1254 Use of such precedence information depends upon partici- 1255 pants' communication needs. For example, this standard does not 1256 dictate when a "Resent-From:" address should receive replies, in 1257 lieu of sending them to the "From:" address. 1258 1259 Note: In general, the "Resent-" fields should be treated as con- 1260 taining a set of information that is independent of the 1261 set of original fields. Information for one set should 1262 not automatically be taken from the other. The interpre- 1263 tation of multiple "Resent-" fields, of the same type, is 1264 undefined. 1265 1266 In the remainder of this specification, occurrence of legal 1267 "Resent-" fields are treated identically with the occurrence of 1268 1269 1270 1271 1272 1273 1274 1275 1276 August 13, 1982 - 19 - RFC #822 1277 1278 1279 1280 Standard for ARPA Internet Text Messages 1281 1282 1283 fields whose names do not contain this prefix. 1284 1285 4.3. TRACE FIELDS 1286 1287 Trace information is used to provide an audit trail of mes- 1288 sage handling. In addition, it indicates a route back to the 1289 sender of the message. 1290 1291 The list of known "via" and "with" values are registered 1292 with the Network Information Center, SRI International, Menlo 1293 Park, California. 1294 1295 4.3.1. RETURN-PATH 1296 1297 This field is added by the final transport system that 1298 delivers the message to its recipient. The field is intended 1299 to contain definitive information about the address and route 1300 back to the message's originator. 1301 1302 Note: The "Reply-To" field is added by the originator and 1303 serves to direct replies, whereas the "Return-Path" 1304 field is used to identify a path back to the origina- 1305 tor. 1306 1307 While the syntax indicates that a route specification is 1308 optional, every attempt should be made to provide that infor- 1309 mation in this field. 1310 1311 4.3.2. RECEIVED 1312 1313 A copy of this field is added by each transport service that 1314 relays the message. The information in the field can be quite 1315 useful for tracing transport problems. 1316 1317 The names of the sending and receiving hosts and time-of- 1318 receipt may be specified. The "via" parameter may be used, to 1319 indicate what physical mechanism the message was sent over, 1320 such as Arpanet or Phonenet, and the "with" parameter may be 1321 used to indicate the mail-, or connection-, level protocol 1322 that was used, such as the SMTP mail protocol, or X.25 tran- 1323 sport protocol. 1324 1325 Note: Several "with" parameters may be included, to fully 1326 specify the set of protocols that were used. 1327 1328 Some transport services queue mail; the internal message iden- 1329 tifier that is assigned to the message may be noted, using the 1330 "id" parameter. When the sending host uses a destination 1331 address specification that the receiving host reinterprets, by 1332 1333 1334 August 13, 1982 - 20 - RFC #822 1335 1336 1337 1338 Standard for ARPA Internet Text Messages 1339 1340 1341 expansion or transformation, the receiving host may wish to 1342 record the original specification, using the "for" parameter. 1343 For example, when a copy of mail is sent to the member of a 1344 distribution list, this parameter may be used to record the 1345 original address that was used to specify the list. 1346 1347 4.4. ORIGINATOR FIELDS 1348 1349 The standard allows only a subset of the combinations possi- 1350 ble with the From, Sender, Reply-To, Resent-From, Resent-Sender, 1351 and Resent-Reply-To fields. The limitation is intentional. 1352 1353 4.4.1. FROM / RESENT-FROM 1354 1355 This field contains the identity of the person(s) who wished 1356 this message to be sent. The message-creation process should 1357 default this field to be a single, authenticated machine 1358 address, indicating the AGENT (person, system or process) 1359 entering the message. If this is not done, the "Sender" field 1360 MUST be present. If the "From" field IS defaulted this way, 1361 the "Sender" field is optional and is redundant with the 1362 "From" field. In all cases, addresses in the "From" field 1363 must be machine-usable (addr-specs) and may not contain named 1364 lists (groups). 1365 1366 4.4.2. SENDER / RESENT-SENDER 1367 1368 This field contains the authenticated identity of the AGENT 1369 (person, system or process) that sends the message. It is 1370 intended for use when the sender is not the author of the mes- 1371 sage, or to indicate who among a group of authors actually 1372 sent the message. If the contents of the "Sender" field would 1373 be completely redundant with the "From" field, then the 1374 "Sender" field need not be present and its use is discouraged 1375 (though still legal). In particular, the "Sender" field MUST 1376 be present if it is NOT the same as the "From" Field. 1377 1378 The Sender mailbox specification includes a word sequence 1379 which must correspond to a specific agent (i.e., a human user 1380 or a computer program) rather than a standard address. This 1381 indicates the expectation that the field will identify the 1382 single AGENT (person, system, or process) responsible for 1383 sending the mail and not simply include the name of a mailbox 1384 from which the mail was sent. For example in the case of a 1385 shared login name, the name, by itself, would not be adequate. 1386 The local-part address unit, which refers to this agent, is 1387 expected to be a computer system term, and not (for example) a 1388 generalized person reference which can be used outside the 1389 network text message context. 1390 1391 1392 August 13, 1982 - 21 - RFC #822 1393 1394 1395 1396 Standard for ARPA Internet Text Messages 1397 1398 1399 Since the critical function served by the "Sender" field is 1400 identification of the agent responsible for sending mail and 1401 since computer programs cannot be held accountable for their 1402 behavior, it is strongly recommended that when a computer pro- 1403 gram generates a message, the HUMAN who is responsible for 1404 that program be referenced as part of the "Sender" field mail- 1405 box specification. 1406 1407 4.4.3. REPLY-TO / RESENT-REPLY-TO 1408 1409 This field provides a general mechanism for indicating any 1410 mailbox(es) to which responses are to be sent. Three typical 1411 uses for this feature can be distinguished. In the first 1412 case, the author(s) may not have regular machine-based mail- 1413 boxes and therefore wish(es) to indicate an alternate machine 1414 address. In the second case, an author may wish additional 1415 persons to be made aware of, or responsible for, replies. A 1416 somewhat different use may be of some help to "text message 1417 teleconferencing" groups equipped with automatic distribution 1418 services: include the address of that service in the "Reply- 1419 To" field of all messages submitted to the teleconference; 1420 then participants can "reply" to conference submissions to 1421 guarantee the correct distribution of any submission of their 1422 own. 1423 1424 Note: The "Return-Path" field is added by the mail transport 1425 service, at the time of final deliver. It is intended 1426 to identify a path back to the orginator of the mes- 1427 sage. The "Reply-To" field is added by the message 1428 originator and is intended to direct replies. 1429 1430 4.4.4. AUTOMATIC USE OF FROM / SENDER / REPLY-TO 1431 1432 For systems which automatically generate address lists for 1433 replies to messages, the following recommendations are made: 1434 1435 o The "Sender" field mailbox should be sent notices of 1436 any problems in transport or delivery of the original 1437 messages. If there is no "Sender" field, then the 1438 "From" field mailbox should be used. 1439 1440 o The "Sender" field mailbox should NEVER be used 1441 automatically, in a recipient's reply message. 1442 1443 o If the "Reply-To" field exists, then the reply should 1444 go to the addresses indicated in that field and not to 1445 the address(es) indicated in the "From" field. 1446 1447 1448 1449 1450 August 13, 1982 - 22 - RFC #822 1451 1452 1453 1454 Standard for ARPA Internet Text Messages 1455 1456 1457 o If there is a "From" field, but no "Reply-To" field, 1458 the reply should be sent to the address(es) indicated 1459 in the "From" field. 1460 1461 Sometimes, a recipient may actually wish to communicate with 1462 the person that initiated the message transfer. In such 1463 cases, it is reasonable to use the "Sender" address. 1464 1465 This recommendation is intended only for automated use of 1466 originator-fields and is not intended to suggest that replies 1467 may not also be sent to other recipients of messages. It is 1468 up to the respective mail-handling programs to decide what 1469 additional facilities will be provided. 1470 1471 Examples are provided in Appendix A. 1472 1473 4.5. RECEIVER FIELDS 1474 1475 4.5.1. TO / RESENT-TO 1476 1477 This field contains the identity of the primary recipients of 1478 the message. 1479 1480 4.5.2. CC / RESENT-CC 1481 1482 This field contains the identity of the secondary (informa- 1483 tional) recipients of the message. 1484 1485 4.5.3. BCC / RESENT-BCC 1486 1487 This field contains the identity of additional recipients of 1488 the message. The contents of this field are not included in 1489 copies of the message sent to the primary and secondary reci- 1490 pients. Some systems may choose to include the text of the 1491 "Bcc" field only in the author(s)'s copy, while others may 1492 also include it in the text sent to all those indicated in the 1493 "Bcc" list. 1494 1495 4.6. REFERENCE FIELDS 1496 1497 4.6.1. MESSAGE-ID / RESENT-MESSAGE-ID 1498 1499 This field contains a unique identifier (the local-part 1500 address unit) which refers to THIS version of THIS message. 1501 The uniqueness of the message identifier is guaranteed by the 1502 host which generates it. This identifier is intended to be 1503 machine readable and not necessarily meaningful to humans. A 1504 message identifier pertains to exactly one instantiation of a 1505 particular message; subsequent revisions to the message should 1506 1507 1508 August 13, 1982 - 23 - RFC #822 1509 1510 1511 1512 Standard for ARPA Internet Text Messages 1513 1514 1515 each receive new message identifiers. 1516 1517 4.6.2. IN-REPLY-TO 1518 1519 The contents of this field identify previous correspon- 1520 dence which this message answers. Note that if message iden- 1521 tifiers are used in this field, they must use the msg-id 1522 specification format. 1523 1524 4.6.3. REFERENCES 1525 1526 The contents of this field identify other correspondence 1527 which this message references. Note that if message identif- 1528 iers are used, they must use the msg-id specification format. 1529 1530 4.6.4. KEYWORDS 1531 1532 This field contains keywords or phrases, separated by 1533 commas. 1534 1535 4.7. OTHER FIELDS 1536 1537 4.7.1. SUBJECT 1538 1539 This is intended to provide a summary, or indicate the 1540 nature, of the message. 1541 1542 4.7.2. COMMENTS 1543 1544 Permits adding text comments onto the message without 1545 disturbing the contents of the message's body. 1546 1547 4.7.3. ENCRYPTED 1548 1549 Sometimes, data encryption is used to increase the 1550 privacy of message contents. If the body of a message has 1551 been encrypted, to keep its contents private, the "Encrypted" 1552 field can be used to note the fact and to indicate the nature 1553 of the encryption. The first <word> parameter indicates the 1554 software used to encrypt the body, and the second, optional 1555 <word> is intended to aid the recipient in selecting the 1556 proper decryption key. This code word may be viewed as an 1557 index to a table of keys held by the recipient. 1558 1559 Note: Unfortunately, headers must contain envelope, as well 1560 as contents, information. Consequently, it is neces- 1561 sary that they remain unencrypted, so that mail tran- 1562 sport services may access them. Since names, 1563 addresses, and "Subject" field contents may contain 1564 1565 1566 August 13, 1982 - 24 - RFC #822 1567 1568 1569 1570 Standard for ARPA Internet Text Messages 1571 1572 1573 sensitive information, this requirement limits total 1574 message privacy. 1575 1576 Names of encryption software are registered with the Net- 1577 work Information Center, SRI International, Menlo Park, Cali- 1578 fornia. 1579 1580 4.7.4. EXTENSION-FIELD 1581 1582 A limited number of common fields have been defined in 1583 this document. As network mail requirements dictate, addi- 1584 tional fields may be standardized. To provide user-defined 1585 fields with a measure of safety, in name selection, such 1586 extension-fields will never have names that begin with the 1587 string "X-". 1588 1589 Names of Extension-fields are registered with the Network 1590 Information Center, SRI International, Menlo Park, California. 1591 1592 4.7.5. USER-DEFINED-FIELD 1593 1594 Individual users of network mail are free to define and 1595 use additional header fields. Such fields must have names 1596 which are not already used in the current specification or in 1597 any definitions of extension-fields, and the overall syntax of 1598 these user-defined-fields must conform to this specification's 1599 rules for delimiting and folding fields. Due to the 1600 extension-field publishing process, the name of a user- 1601 defined-field may be pre-empted 1602 1603 Note: The prefatory string "X-" will never be used in the 1604 names of Extension-fields. This provides user-defined 1605 fields with a protected set of names. 1606 1607 1608 1609 1610 1611 1612 1613 1614 1615 1616 1617 1618 1619 1620 1621 1622 1623 1624 August 13, 1982 - 25 - RFC #822 1625 1626 1627 1628 Standard for ARPA Internet Text Messages 1629 1630 1631 5. DATE AND TIME SPECIFICATION 1632 1633 5.1. SYNTAX 1634 1635 date-time = [ day "," ] date time ; dd mm yy 1636 ; hh:mm:ss zzz 1637 1638 day = "Mon" / "Tue" / "Wed" / "Thu" 1639 / "Fri" / "Sat" / "Sun" 1640 1641 date = 1*2DIGIT month 2DIGIT ; day month year 1642 ; e.g. 20 Jun 82 1643 1644 month = "Jan" / "Feb" / "Mar" / "Apr" 1645 / "May" / "Jun" / "Jul" / "Aug" 1646 / "Sep" / "Oct" / "Nov" / "Dec" 1647 1648 time = hour zone ; ANSI and Military 1649 1650 hour = 2DIGIT ":" 2DIGIT [":" 2DIGIT] 1651 ; 00:00:00 - 23:59:59 1652 1653 zone = "UT" / "GMT" ; Universal Time 1654 ; North American : UT 1655 / "EST" / "EDT" ; Eastern: - 5/ - 4 1656 / "CST" / "CDT" ; Central: - 6/ - 5 1657 / "MST" / "MDT" ; Mountain: - 7/ - 6 1658 / "PST" / "PDT" ; Pacific: - 8/ - 7 1659 / 1ALPHA ; Military: Z = UT; 1660 ; A:-1; (J not used) 1661 ; M:-12; N:+1; Y:+12 1662 / ( ("+" / "-") 4DIGIT ) ; Local differential 1663 ; hours+min. (HHMM) 1664 1665 5.2. SEMANTICS 1666 1667 If included, day-of-week must be the day implied by the date 1668 specification. 1669 1670 Time zone may be indicated in several ways. "UT" is Univer- 1671 sal Time (formerly called "Greenwich Mean Time"); "GMT" is per- 1672 mitted as a reference to Universal Time. The military standard 1673 uses a single character for each zone. "Z" is Universal Time. 1674 "A" indicates one hour earlier, and "M" indicates 12 hours ear- 1675 lier; "N" is one hour later, and "Y" is 12 hours later. The 1676 letter "J" is not used. The other remaining two forms are taken 1677 from ANSI standard X3.51-1975. One allows explicit indication of 1678 the amount of offset from UT; the other uses common 3-character 1679 strings for indicating time zones in North America. 1680 1681 1682 August 13, 1982 - 26 - RFC #822 1683 1684 1685 1686 Standard for ARPA Internet Text Messages 1687 1688 1689 6. ADDRESS SPECIFICATION 1690 1691 6.1. SYNTAX 1692 1693 address = mailbox ; one addressee 1694 / group ; named list 1695 1696 group = phrase ":" [#mailbox] ";" 1697 1698 mailbox = addr-spec ; simple address 1699 / phrase route-addr ; name & addr-spec 1700 1701 route-addr = "<" [route] addr-spec ">" 1702 1703 route = 1#("@" domain) ":" ; path-relative 1704 1705 addr-spec = local-part "@" domain ; global address 1706 1707 local-part = word *("." word) ; uninterpreted 1708 ; case-preserved 1709 1710 domain = sub-domain *("." sub-domain) 1711 1712 sub-domain = domain-ref / domain-literal 1713 1714 domain-ref = atom ; symbolic reference 1715 1716 6.2. SEMANTICS 1717 1718 A mailbox receives mail. It is a conceptual entity which 1719 does not necessarily pertain to file storage. For example, some 1720 sites may choose to print mail on their line printer and deliver 1721 the output to the addressee's desk. 1722 1723 A mailbox specification comprises a person, system or pro- 1724 cess name reference, a domain-dependent string, and a name-domain 1725 reference. The name reference is optional and is usually used to 1726 indicate the human name of a recipient. The name-domain refer- 1727 ence specifies a sequence of sub-domains. The domain-dependent 1728 string is uninterpreted, except by the final sub-domain; the rest 1729 of the mail service merely transmits it as a literal string. 1730 1731 6.2.1. DOMAINS 1732 1733 A name-domain is a set of registered (mail) names. A name- 1734 domain specification resolves to a subordinate name-domain 1735 specification or to a terminal domain-dependent string. 1736 Hence, domain specification is extensible, permitting any 1737 number of registration levels. 1738 1739 1740 August 13, 1982 - 27 - RFC #822 1741 1742 1743 1744 Standard for ARPA Internet Text Messages 1745 1746 1747 Name-domains model a global, logical, hierarchical addressing 1748 scheme. The model is logical, in that an address specifica- 1749 tion is related to name registration and is not necessarily 1750 tied to transmission path. The model's hierarchy is a 1751 directed graph, called an in-tree, such that there is a single 1752 path from the root of the tree to any node in the hierarchy. 1753 If more than one path actually exists, they are considered to 1754 be different addresses. 1755 1756 The root node is common to all addresses; consequently, it is 1757 not referenced. Its children constitute "top-level" name- 1758 domains. Usually, a service has access to its own full domain 1759 specification and to the names of all top-level name-domains. 1760 1761 The "top" of the domain addressing hierarchy -- a child of the 1762 root -- is indicated by the right-most field, in a domain 1763 specification. Its child is specified to the left, its child 1764 to the left, and so on. 1765 1766 Some groups provide formal registration services; these con- 1767 stitute name-domains that are independent logically of 1768 specific machines. In addition, networks and machines impli- 1769 citly compose name-domains, since their membership usually is 1770 registered in name tables. 1771 1772 In the case of formal registration, an organization implements 1773 a (distributed) data base which provides an address-to-route 1774 mapping service for addresses of the form: 1775 1776 person@registry.organization 1777 1778 Note that "organization" is a logical entity, separate from 1779 any particular communication network. 1780 1781 A mechanism for accessing "organization" is universally avail- 1782 able. That mechanism, in turn, seeks an instantiation of the 1783 registry; its location is not indicated in the address specif- 1784 ication. It is assumed that the system which operates under 1785 the name "organization" knows how to find a subordinate regis- 1786 try. The registry will then use the "person" string to deter- 1787 mine where to send the mail specification. 1788 1789 The latter, network-oriented case permits simple, direct, 1790 attachment-related address specification, such as: 1791 1792 user@host.network 1793 1794 Once the network is accessed, it is expected that a message 1795 will go directly to the host and that the host will resolve 1796 1797 1798 August 13, 1982 - 28 - RFC #822 1799 1800 1801 1802 Standard for ARPA Internet Text Messages 1803 1804 1805 the user name, placing the message in the user's mailbox. 1806 1807 6.2.2. ABBREVIATED DOMAIN SPECIFICATION 1808 1809 Since any number of levels is possible within the domain 1810 hierarchy, specification of a fully qualified address can 1811 become inconvenient. This standard permits abbreviated domain 1812 specification, in a special case: 1813 1814 For the address of the sender, call the left-most 1815 sub-domain Level N. In a header address, if all of 1816 the sub-domains above (i.e., to the right of) Level N 1817 are the same as those of the sender, then they do not 1818 have to appear in the specification. Otherwise, the 1819 address must be fully qualified. 1820 1821 This feature is subject to approval by local sub- 1822 domains. Individual sub-domains may require their 1823 member systems, which originate mail, to provide full 1824 domain specification only. When permitted, abbrevia- 1825 tions may be present only while the message stays 1826 within the sub-domain of the sender. 1827 1828 Use of this mechanism requires the sender's sub-domain 1829 to reserve the names of all top-level domains, so that 1830 full specifications can be distinguished from abbrevi- 1831 ated specifications. 1832 1833 For example, if a sender's address is: 1834 1835 sender@registry-A.registry-1.organization-X 1836 1837 and one recipient's address is: 1838 1839 recipient@registry-B.registry-1.organization-X 1840 1841 and another's is: 1842 1843 recipient@registry-C.registry-2.organization-X 1844 1845 then ".registry-1.organization-X" need not be specified in the 1846 the message, but "registry-C.registry-2" DOES have to be 1847 specified. That is, the first two addresses may be abbrevi- 1848 ated, but the third address must be fully specified. 1849 1850 When a message crosses a domain boundary, all addresses must 1851 be specified in the full format, ending with the top-level 1852 name-domain in the right-most field. It is the responsibility 1853 of mail forwarding services to ensure that addresses conform 1854 1855 1856 August 13, 1982 - 29 - RFC #822 1857 1858 1859 1860 Standard for ARPA Internet Text Messages 1861 1862 1863 with this requirement. In the case of abbreviated addresses, 1864 the relaying service must make the necessary expansions. It 1865 should be noted that it often is difficult for such a service 1866 to locate all occurrences of address abbreviations. For exam- 1867 ple, it will not be possible to find such abbreviations within 1868 the body of the message. The "Return-Path" field can aid 1869 recipients in recovering from these errors. 1870 1871 Note: When passing any portion of an addr-spec onto a process 1872 which does not interpret data according to this stan- 1873 dard (e.g., mail protocol servers). There must be NO 1874 LWSP-chars preceding or following the at-sign or any 1875 delimiting period ("."), such as shown in the above 1876 examples, and only ONE SPACE between contiguous 1877 <word>s. 1878 1879 6.2.3. DOMAIN TERMS 1880 1881 A domain-ref must be THE official name of a registry, network, 1882 or host. It is a symbolic reference, within a name sub- 1883 domain. At times, it is necessary to bypass standard mechan- 1884 isms for resolving such references, using more primitive 1885 information, such as a network host address rather than its 1886 associated host name. 1887 1888 To permit such references, this standard provides the domain- 1889 literal construct. Its contents must conform with the needs 1890 of the sub-domain in which it is interpreted. 1891 1892 Domain-literals which refer to domains within the ARPA Inter- 1893 net specify 32-bit Internet addresses, in four 8-bit fields 1894 noted in decimal, as described in Request for Comments #820, 1895 "Assigned Numbers." For example: 1896 1897 [10.0.3.19] 1898 1899 Note: THE USE OF DOMAIN-LITERALS IS STRONGLY DISCOURAGED. It 1900 is permitted only as a means of bypassing temporary 1901 system limitations, such as name tables which are not 1902 complete. 1903 1904 The names of "top-level" domains, and the names of domains 1905 under in the ARPA Internet, are registered with the Network 1906 Information Center, SRI International, Menlo Park, California. 1907 1908 6.2.4. DOMAIN-DEPENDENT LOCAL STRING 1909 1910 The local-part of an addr-spec in a mailbox specification 1911 (i.e., the host's name for the mailbox) is understood to be 1912 1913 1914 August 13, 1982 - 30 - RFC #822 1915 1916 1917 1918 Standard for ARPA Internet Text Messages 1919 1920 1921 whatever the receiving mail protocol server allows. For exam- 1922 ple, some systems do not understand mailbox references of the 1923 form "P. D. Q. Bach", but others do. 1924 1925 This specification treats periods (".") as lexical separators. 1926 Hence, their presence in local-parts which are not quoted- 1927 strings, is detected. However, such occurrences carry NO 1928 semantics. That is, if a local-part has periods within it, an 1929 address parser will divide the local-part into several tokens, 1930 but the sequence of tokens will be treated as one uninter- 1931 preted unit. The sequence will be re-assembled, when the 1932 address is passed outside of the system such as to a mail pro- 1933 tocol service. 1934 1935 For example, the address: 1936 1937 First.Last@Registry.Org 1938 1939 is legal and does not require the local-part to be surrounded 1940 with quotation-marks. (However, "First Last" DOES require 1941 quoting.) The local-part of the address, when passed outside 1942 of the mail system, within the Registry.Org domain, is 1943 "First.Last", again without quotation marks. 1944 1945 6.2.5. BALANCING LOCAL-PART AND DOMAIN 1946 1947 In some cases, the boundary between local-part and domain can 1948 be flexible. The local-part may be a simple string, which is 1949 used for the final determination of the recipient's mailbox. 1950 All other levels of reference are, therefore, part of the 1951 domain. 1952 1953 For some systems, in the case of abbreviated reference to the 1954 local and subordinate sub-domains, it may be possible to 1955 specify only one reference within the domain part and place 1956 the other, subordinate name-domain references within the 1957 local-part. This would appear as: 1958 1959 mailbox.sub1.sub2@this-domain 1960 1961 Such a specification would be acceptable to address parsers 1962 which conform to RFC #733, but do not support this newer 1963 Internet standard. While contrary to the intent of this stan- 1964 dard, the form is legal. 1965 1966 Also, some sub-domains have a specification syntax which does 1967 not conform to this standard. For example: 1968 1969 sub-net.mailbox@sub-domain.domain 1970 1971 1972 August 13, 1982 - 31 - RFC #822 1973 1974 1975 1976 Standard for ARPA Internet Text Messages 1977 1978 1979 uses a different parsing sequence for local-part than for 1980 domain. 1981 1982 Note: As a rule, the domain specification should contain 1983 fields which are encoded according to the syntax of 1984 this standard and which contain generally-standardized 1985 information. The local-part specification should con- 1986 tain only that portion of the address which deviates 1987 from the form or intention of the domain field. 1988 1989 6.2.6. MULTIPLE MAILBOXES 1990 1991 An individual may have several mailboxes and wish to receive 1992 mail at whatever mailbox is convenient for the sender to 1993 access. This standard does not provide a means of specifying 1994 "any member of" a list of mailboxes. 1995 1996 A set of individuals may wish to receive mail as a single unit 1997 (i.e., a distribution list). The <group> construct permits 1998 specification of such a list. Recipient mailboxes are speci- 1999 fied within the bracketed part (":" - ";"). A copy of the 2000 transmitted message is to be sent to each mailbox listed. 2001 This standard does not permit recursive specification of 2002 groups within groups. 2003 2004 While a list must be named, it is not required that the con- 2005 tents of the list be included. In this case, the <address> 2006 serves only as an indication of group distribution and would 2007 appear in the form: 2008 2009 name:; 2010 2011 Some mail services may provide a group-list distribution 2012 facility, accepting a single mailbox reference, expanding it 2013 to the full distribution list, and relaying the mail to the 2014 list's members. This standard provides no additional syntax 2015 for indicating such a service. Using the <group> address 2016 alternative, while listing one mailbox in it, can mean either 2017 that the mailbox reference will be expanded to a list or that 2018 there is a group with one member. 2019 2020 6.2.7. EXPLICIT PATH SPECIFICATION 2021 2022 At times, a message originator may wish to indicate the 2023 transmission path that a message should follow. This is 2024 called source routing. The normal addressing scheme, used in 2025 an addr-spec, is carefully separated from such information; 2026 the <route> portion of a route-addr is provided for such occa- 2027 sions. It specifies the sequence of hosts and/or transmission 2028 2029 2030 August 13, 1982 - 32 - RFC #822 2031 2032 2033 2034 Standard for ARPA Internet Text Messages 2035 2036 2037 services that are to be traversed. Both domain-refs and 2038 domain-literals may be used. 2039 2040 Note: The use of source routing is discouraged. Unless the 2041 sender has special need of path restriction, the choice 2042 of transmission route should be left to the mail tran- 2043 sport service. 2044 2045 6.3. RESERVED ADDRESS 2046 2047 It often is necessary to send mail to a site, without know- 2048 ing any of its valid addresses. For example, there may be mail 2049 system dysfunctions, or a user may wish to find out a person's 2050 correct address, at that site. 2051 2052 This standard specifies a single, reserved mailbox address 2053 (local-part) which is to be valid at each site. Mail sent to 2054 that address is to be routed to a person responsible for the 2055 site's mail system or to a person with responsibility for general 2056 site operation. The name of the reserved local-part address is: 2057 2058 Postmaster 2059 2060 so that "Postmaster@domain" is required to be valid. 2061 2062 Note: This reserved local-part must be matched without sensi- 2063 tivity to alphabetic case, so that "POSTMASTER", "postmas- 2064 ter", and even "poStmASteR" is to be accepted. 2065 2066 2067 2068 2069 2070 2071 2072 2073 2074 2075 2076 2077 2078 2079 2080 2081 2082 2083 2084 2085 2086 2087 2088 August 13, 1982 - 33 - RFC #822 2089 2090 2091 2092 Standard for ARPA Internet Text Messages 2093 2094 2095 7. BIBLIOGRAPHY 2096 2097 2098 ANSI. "USA Standard Code for Information Interchange," X3.4. 2099 American National Standards Institute: New York (1968). Also 2100 in: Feinler, E. and J. Postel, eds., "ARPANET Protocol Hand- 2101 book", NIC 7104. 2102 2103 ANSI. "Representations of Universal Time, Local Time Differen- 2104 tials, and United States Time Zone References for Information 2105 Interchange," X3.51-1975. American National Standards Insti- 2106 tute: New York (1975). 2107 2108 Bemer, R.W., "Time and the Computer." In: Interface Age (Feb. 2109 1979). 2110 2111 Bennett, C.J. "JNT Mail Protocol". Joint Network Team, Ruther- 2112 ford and Appleton Laboratory: Didcot, England. 2113 2114 Bhushan, A.K., Pogran, K.T., Tomlinson, R.S., and White, J.E. 2115 "Standardizing Network Mail Headers," ARPANET Request for 2116 Comments No. 561, Network Information Center No. 18516; SRI 2117 International: Menlo Park (September 1973). 2118 2119 Birrell, A.D., Levin, R., Needham, R.M., and Schroeder, M.D. 2120 "Grapevine: An Exercise in Distributed Computing," Communica- 2121 tions of the ACM 25, 4 (April 1982), 260-274. 2122 2123 Crocker, D.H., Vittal, J.J., Pogran, K.T., Henderson, D.A. 2124 "Standard for the Format of ARPA Network Text Message," 2125 ARPANET Request for Comments No. 733, Network Information 2126 Center No. 41952. SRI International: Menlo Park (November 2127 1977). 2128 2129 Feinler, E.J. and Postel, J.B. ARPANET Protocol Handbook, Net- 2130 work Information Center No. 7104 (NTIS AD A003890). SRI 2131 International: Menlo Park (April 1976). 2132 2133 Harary, F. "Graph Theory". Addison-Wesley: Reading, Mass. 2134 (1969). 2135 2136 Levin, R. and Schroeder, M. "Transport of Electronic Messages 2137 through a Network," TeleInformatics 79, pp. 29-33. North 2138 Holland (1979). Also as Xerox Palo Alto Research Center 2139 Technical Report CSL-79-4. 2140 2141 Myer, T.H. and Henderson, D.A. "Message Transmission Protocol," 2142 ARPANET Request for Comments, No. 680, Network Information 2143 Center No. 32116. SRI International: Menlo Park (1975). 2144 2145 2146 August 13, 1982 - 34 - RFC #822 2147 2148 2149 2150 Standard for ARPA Internet Text Messages 2151 2152 2153 NBS. "Specification of Message Format for Computer Based Message 2154 Systems, Recommended Federal Information Processing Standard." 2155 National Bureau of Standards: Gaithersburg, Maryland 2156 (October 1981). 2157 2158 NIC. Internet Protocol Transition Workbook. Network Information 2159 Center, SRI-International, Menlo Park, California (March 2160 1982). 2161 2162 Oppen, D.C. and Dalal, Y.K. "The Clearinghouse: A Decentralized 2163 Agent for Locating Named Objects in a Distributed Environ- 2164 ment," OPD-T8103. Xerox Office Products Division: Palo Alto, 2165 CA. (October 1981). 2166 2167 Postel, J.B. "Assigned Numbers," ARPANET Request for Comments, 2168 No. 820. SRI International: Menlo Park (August 1982). 2169 2170 Postel, J.B. "Simple Mail Transfer Protocol," ARPANET Request 2171 for Comments, No. 821. SRI International: Menlo Park (August 2172 1982). 2173 2174 Shoch, J.F. "Internetwork naming, addressing and routing," in 2175 Proc. 17th IEEE Computer Society International Conference, pp. 2176 72-79, Sept. 1978, IEEE Cat. No. 78 CH 1388-8C. 2177 2178 Su, Z. and Postel, J. "The Domain Naming Convention for Internet 2179 User Applications," ARPANET Request for Comments, No. 819. 2180 SRI International: Menlo Park (August 1982). 2181 2182 2183 2184 2185 2186 2187 2188 2189 2190 2191 2192 2193 2194 2195 2196 2197 2198 2199 2200 2201 2202 2203 2204 August 13, 1982 - 35 - RFC #822 2205 2206 2207 2208 Standard for ARPA Internet Text Messages 2209 2210 2211 APPENDIX 2212 2213 2214 A. EXAMPLES 2215 2216 A.1. ADDRESSES 2217 2218 A.1.1. Alfred Neuman <Neuman@BBN-TENEXA> 2219 2220 A.1.2. Neuman@BBN-TENEXA 2221 2222 These two "Alfred Neuman" examples have identical seman- 2223 tics, as far as the operation of the local host's mail sending 2224 (distribution) program (also sometimes called its "mailer") 2225 and the remote host's mail protocol server are concerned. In 2226 the first example, the "Alfred Neuman" is ignored by the 2227 mailer, as "Neuman@BBN-TENEXA" completely specifies the reci- 2228 pient. The second example contains no superfluous informa- 2229 tion, and, again, "Neuman@BBN-TENEXA" is the intended reci- 2230 pient. 2231 2232 Note: When the message crosses name-domain boundaries, then 2233 these specifications must be changed, so as to indicate 2234 the remainder of the hierarchy, starting with the top 2235 level. 2236 2237 A.1.3. "George, Ted" <Shared@Group.Arpanet> 2238 2239 This form might be used to indicate that a single mailbox 2240 is shared by several users. The quoted string is ignored by 2241 the originating host's mailer, because "Shared@Group.Arpanet" 2242 completely specifies the destination mailbox. 2243 2244 A.1.4. Wilt . (the Stilt) Chamberlain@NBA.US 2245 2246 The "(the Stilt)" is a comment, which is NOT included in 2247 the destination mailbox address handed to the originating 2248 system's mailer. The local-part of the address is the string 2249 "Wilt.Chamberlain", with NO space between the first and second 2250 words. 2251 2252 A.1.5. Address Lists 2253 2254 Gourmets: Pompous Person <WhoZiWhatZit@Cordon-Bleu>, 2255 Childs@WGBH.Boston, Galloping Gourmet@ 2256 ANT.Down-Under (Australian National Television), 2257 Cheapie@Discount-Liquors;, 2258 Cruisers: Port@Portugal, Jones@SEA;, 2259 Another@Somewhere.SomeOrg 2260 2261 2262 August 13, 1982 - 36 - RFC #822 2263 2264 2265 2266 Standard for ARPA Internet Text Messages 2267 2268 2269 This group list example points out the use of comments and the 2270 mixing of addresses and groups. 2271 2272 A.2. ORIGINATOR ITEMS 2273 2274 A.2.1. Author-sent 2275 2276 George Jones logs into his host as "Jones". He sends 2277 mail himself. 2278 2279 From: Jones@Group.Org 2280 2281 or 2282 2283 From: George Jones <Jones@Group.Org> 2284 2285 A.2.2. Secretary-sent 2286 2287 George Jones logs in as Jones on his host. His secre- 2288 tary, who logs in as Secy sends mail for him. Replies to the 2289 mail should go to George. 2290 2291 From: George Jones <Jones@Group> 2292 Sender: Secy@Other-Group 2293 2294 A.2.3. Secretary-sent, for user of shared directory 2295 2296 George Jones' secretary sends mail for George. Replies 2297 should go to George. 2298 2299 From: George Jones<Shared@Group.Org> 2300 Sender: Secy@Other-Group 2301 2302 Note that there need not be a space between "Jones" and the 2303 "<", but adding a space enhances readability (as is the case 2304 in other examples. 2305 2306 A.2.4. Committee activity, with one author 2307 2308 George is a member of a committee. He wishes to have any 2309 replies to his message go to all committee members. 2310 2311 From: George Jones <Jones@Host.Net> 2312 Sender: Jones@Host 2313 Reply-To: The Committee: Jones@Host.Net, 2314 Smith@Other.Org, 2315 Doe@Somewhere-Else; 2316 2317 Note that if George had not included himself in the 2318 2319 2320 August 13, 1982 - 37 - RFC #822 2321 2322 2323 2324 Standard for ARPA Internet Text Messages 2325 2326 2327 enumeration of The Committee, he would not have gotten an 2328 implicit reply; the presence of the "Reply-to" field SUPER- 2329 SEDES the sending of a reply to the person named in the "From" 2330 field. 2331 2332 A.2.5. Secretary acting as full agent of author 2333 2334 George Jones asks his secretary (Secy@Host) to send a 2335 message for him in his capacity as Group. He wants his secre- 2336 tary to handle all replies. 2337 2338 From: George Jones <Group@Host> 2339 Sender: Secy@Host 2340 Reply-To: Secy@Host 2341 2342 A.2.6. Agent for user without online mailbox 2343 2344 A friend of George's, Sarah, is visiting. George's 2345 secretary sends some mail to a friend of Sarah in computer- 2346 land. Replies should go to George, whose mailbox is Jones at 2347 Registry. 2348 2349 From: Sarah Friendly <Secy@Registry> 2350 Sender: Secy-Name <Secy@Registry> 2351 Reply-To: Jones@Registry. 2352 2353 A.2.7. Agent for member of a committee 2354 2355 George's secretary sends out a message which was authored 2356 jointly by all the members of a committee. Note that the name 2357 of the committee cannot be specified, since <group> names are 2358 not permitted in the From field. 2359 2360 From: Jones@Host, 2361 Smith@Other-Host, 2362 Doe@Somewhere-Else 2363 Sender: Secy@SHost 2364 2365 2366 2367 2368 2369 2370 2371 2372 2373 2374 2375 2376 2377 2378 August 13, 1982 - 38 - RFC #822 2379 2380 2381 2382 Standard for ARPA Internet Text Messages 2383 2384 2385 A.3. COMPLETE HEADERS 2386 2387 A.3.1. Minimum required 2388 2389 Date: 26 Aug 76 1429 EDT Date: 26 Aug 76 1429 EDT 2390 From: Jones@Registry.Org or From: Jones@Registry.Org 2391 Bcc: To: Smith@Registry.Org 2392 2393 Note that the "Bcc" field may be empty, while the "To" field 2394 is required to have at least one address. 2395 2396 A.3.2. Using some of the additional fields 2397 2398 Date: 26 Aug 76 1430 EDT 2399 From: George Jones<Group@Host> 2400 Sender: Secy@SHOST 2401 To: "Al Neuman"@Mad-Host, 2402 Sam.Irving@Other-Host 2403 Message-ID: <some.string@SHOST> 2404 2405 A.3.3. About as complex as you're going to get 2406 2407 Date : 27 Aug 76 0932 PDT 2408 From : Ken Davis <KDavis@This-Host.This-net> 2409 Subject : Re: The Syntax in the RFC 2410 Sender : KSecy@Other-Host 2411 Reply-To : Sam.Irving@Reg.Organization 2412 To : George Jones <Group@Some-Reg.An-Org>, 2413 Al.Neuman@MAD.Publisher 2414 cc : Important folk: 2415 Tom Softwood <Balsa@Tree.Root>, 2416 "Sam Irving"@Other-Host;, 2417 Standard Distribution: 2418 /main/davis/people/standard@Other-Host, 2419 "<Jones>standard.dist.3"@Tops-20-Host>; 2420 Comment : Sam is away on business. He asked me to handle 2421 his mail for him. He'll be able to provide a 2422 more accurate explanation when he returns 2423 next week. 2424 In-Reply-To: <some.string@DBM.Group>, George's message 2425 X-Special-action: This is a sample of user-defined field- 2426 names. There could also be a field-name 2427 "Special-action", but its name might later be 2428 preempted 2429 Message-ID: <4231.629.XYzi-What@Other-Host> 2430 2431 2432 2433 2434 2435 2436 August 13, 1982 - 39 - RFC #822 2437 2438 2439 2440 Standard for ARPA Internet Text Messages 2441 2442 2443 B. SIMPLE FIELD PARSING 2444 2445 Some mail-reading software systems may wish to perform only 2446 minimal processing, ignoring the internal syntax of structured 2447 field-bodies and treating them the same as unstructured-field- 2448 bodies. Such software will need only to distinguish: 2449 2450 o Header fields from the message body, 2451 2452 o Beginnings of fields from lines which continue fields, 2453 2454 o Field-names from field-contents. 2455 2456 The abbreviated set of syntactic rules which follows will 2457 suffice for this purpose. It describes a limited view of mes- 2458 sages and is a subset of the syntactic rules provided in the main 2459 part of this specification. One small exception is that the con- 2460 tents of field-bodies consist only of text: 2461 2462 B.1. SYNTAX 2463 2464 2465 message = *field *(CRLF *text) 2466 2467 field = field-name ":" [field-body] CRLF 2468 2469 field-name = 1*<any CHAR, excluding CTLs, SPACE, and ":"> 2470 2471 field-body = *text [CRLF LWSP-char field-body] 2472 2473 2474 B.2. SEMANTICS 2475 2476 Headers occur before the message body and are terminated by 2477 a null line (i.e., two contiguous CRLFs). 2478 2479 A line which continues a header field begins with a SPACE or 2480 HTAB character, while a line beginning a field starts with a 2481 printable character which is not a colon. 2482 2483 A field-name consists of one or more printable characters 2484 (excluding colon, space, and control-characters). A field-name 2485 MUST be contained on one line. Upper and lower case are not dis- 2486 tinguished when comparing field-names. 2487 2488 2489 2490 2491 2492 2493 2494 August 13, 1982 - 40 - RFC #822 2495 2496 2497 2498 Standard for ARPA Internet Text Messages 2499 2500 2501 C. DIFFERENCES FROM RFC #733 2502 2503 The following summarizes the differences between this stan- 2504 dard and the one specified in Arpanet Request for Comments #733, 2505 "Standard for the Format of ARPA Network Text Messages". The 2506 differences are listed in the order of their occurrence in the 2507 current specification. 2508 2509 C.1. FIELD DEFINITIONS 2510 2511 C.1.1. FIELD NAMES 2512 2513 These now must be a sequence of printable characters. They 2514 may not contain any LWSP-chars. 2515 2516 C.2. LEXICAL TOKENS 2517 2518 C.2.1. SPECIALS 2519 2520 The characters period ("."), left-square bracket ("["), and 2521 right-square bracket ("]") have been added. For presentation 2522 purposes, and when passing a specification to a system that 2523 does not conform to this standard, periods are to be contigu- 2524 ous with their surrounding lexical tokens. No linear-white- 2525 space is permitted between them. The presence of one LWSP- 2526 char between other tokens is still directed. 2527 2528 C.2.2. ATOM 2529 2530 Atoms may not contain SPACE. 2531 2532 C.2.3. SPECIAL TEXT 2533 2534 ctext and qtext have had backslash ("\") added to the list of 2535 prohibited characters. 2536 2537 C.2.4. DOMAINS 2538 2539 The lexical tokens <domain-literal> and <dtext> have been 2540 added. 2541 2542 C.3. MESSAGE SPECIFICATION 2543 2544 C.3.1. TRACE 2545 2546 The "Return-path:" and "Received:" fields have been specified. 2547 2548 2549 2550 2551 2552 August 13, 1982 - 41 - RFC #822 2553 2554 2555 2556 Standard for ARPA Internet Text Messages 2557 2558 2559 C.3.2. FROM 2560 2561 The "From" field must contain machine-usable addresses (addr- 2562 spec). Multiple addresses may be specified, but named-lists 2563 (groups) may not. 2564 2565 C.3.3. RESENT 2566 2567 The meta-construct of prefacing field names with the string 2568 "Resent-" has been added, to indicate that a message has been 2569 forwarded by an intermediate recipient. 2570 2571 C.3.4. DESTINATION 2572 2573 A message must contain at least one destination address field. 2574 "To" and "CC" are required to contain at least one address. 2575 2576 C.3.5. IN-REPLY-TO 2577 2578 The field-body is no longer a comma-separated list, although a 2579 sequence is still permitted. 2580 2581 C.3.6. REFERENCE 2582 2583 The field-body is no longer a comma-separated list, although a 2584 sequence is still permitted. 2585 2586 C.3.7. ENCRYPTED 2587 2588 A field has been specified that permits senders to indicate 2589 that the body of a message has been encrypted. 2590 2591 C.3.8. EXTENSION-FIELD 2592 2593 Extension fields are prohibited from beginning with the char- 2594 acters "X-". 2595 2596 C.4. DATE AND TIME SPECIFICATION 2597 2598 C.4.1. SIMPLIFICATION 2599 2600 Fewer optional forms are permitted and the list of three- 2601 letter time zones has been shortened. 2602 2603 C.5. ADDRESS SPECIFICATION 2604 2605 2606 2607 2608 2609 2610 August 13, 1982 - 42 - RFC #822 2611 2612 2613 2614 Standard for ARPA Internet Text Messages 2615 2616 2617 C.5.1. ADDRESS 2618 2619 The use of quoted-string, and the ":"-atom-":" construct, have 2620 been removed. An address now is either a single mailbox 2621 reference or is a named list of addresses. The latter indi- 2622 cates a group distribution. 2623 2624 C.5.2. GROUPS 2625 2626 Group lists are now required to to have a name. Group lists 2627 may not be nested. 2628 2629 C.5.3. MAILBOX 2630 2631 A mailbox specification may indicate a person's name, as 2632 before. Such a named list no longer may specify multiple 2633 mailboxes and may not be nested. 2634 2635 C.5.4. ROUTE ADDRESSING 2636 2637 Addresses now are taken to be absolute, global specifications, 2638 independent of transmission paths. The <route> construct has 2639 been provided, to permit explicit specification of transmis- 2640 sion path. RFC #733's use of multiple at-signs ("@") was 2641 intended as a general syntax for indicating routing and/or 2642 hierarchical addressing. The current standard separates these 2643 specifications and only one at-sign is permitted. 2644 2645 C.5.5. AT-SIGN 2646 2647 The string " at " no longer is used as an address delimiter. 2648 Only at-sign ("@") serves the function. 2649 2650 C.5.6. DOMAINS 2651 2652 Hierarchical, logical name-domains have been added. 2653 2654 C.6. RESERVED ADDRESS 2655 2656 The local-part "Postmaster" has been reserved, so that users can 2657 be guaranteed at least one valid address at a site. 2658 2659 2660 2661 2662 2663 2664 2665 2666 2667 2668 August 13, 1982 - 43 - RFC #822 2669 2670 2671 2672 Standard for ARPA Internet Text Messages 2673 2674 2675 D. ALPHABETICAL LISTING OF SYNTAX RULES 2676 2677 address = mailbox ; one addressee 2678 / group ; named list 2679 addr-spec = local-part "@" domain ; global address 2680 ALPHA = <any ASCII alphabetic character> 2681 ; (101-132, 65.- 90.) 2682 ; (141-172, 97.-122.) 2683 atom = 1*<any CHAR except specials, SPACE and CTLs> 2684 authentic = "From" ":" mailbox ; Single author 2685 / ( "Sender" ":" mailbox ; Actual submittor 2686 "From" ":" 1#mailbox) ; Multiple authors 2687 ; or not sender 2688 CHAR = <any ASCII character> ; ( 0-177, 0.-127.) 2689 comment = "(" *(ctext / quoted-pair / comment) ")" 2690 CR = <ASCII CR, carriage return> ; ( 15, 13.) 2691 CRLF = CR LF 2692 ctext = <any CHAR excluding "(", ; => may be folded 2693 ")", "\" & CR, & including 2694 linear-white-space> 2695 CTL = <any ASCII control ; ( 0- 37, 0.- 31.) 2696 character and DEL> ; ( 177, 127.) 2697 date = 1*2DIGIT month 2DIGIT ; day month year 2698 ; e.g. 20 Jun 82 2699 dates = orig-date ; Original 2700 [ resent-date ] ; Forwarded 2701 date-time = [ day "," ] date time ; dd mm yy 2702 ; hh:mm:ss zzz 2703 day = "Mon" / "Tue" / "Wed" / "Thu" 2704 / "Fri" / "Sat" / "Sun" 2705 delimiters = specials / linear-white-space / comment 2706 destination = "To" ":" 1#address ; Primary 2707 / "Resent-To" ":" 1#address 2708 / "cc" ":" 1#address ; Secondary 2709 / "Resent-cc" ":" 1#address 2710 / "bcc" ":" #address ; Blind carbon 2711 / "Resent-bcc" ":" #address 2712 DIGIT = <any ASCII decimal digit> ; ( 60- 71, 48.- 57.) 2713 domain = sub-domain *("." sub-domain) 2714 domain-literal = "[" *(dtext / quoted-pair) "]" 2715 domain-ref = atom ; symbolic reference 2716 dtext = <any CHAR excluding "[", ; => may be folded 2717 "]", "\" & CR, & including 2718 linear-white-space> 2719 extension-field = 2720 <Any field which is defined in a document 2721 published as a formal extension to this 2722 specification; none will have names beginning 2723 with the string "X-"> 2724 2725 2726 August 13, 1982 - 44 - RFC #822 2727 2728 2729 2730 Standard for ARPA Internet Text Messages 2731 2732 2733 field = field-name ":" [ field-body ] CRLF 2734 fields = dates ; Creation time, 2735 source ; author id & one 2736 1*destination ; address required 2737 *optional-field ; others optional 2738 field-body = field-body-contents 2739 [CRLF LWSP-char field-body] 2740 field-body-contents = 2741 <the ASCII characters making up the field-body, as 2742 defined in the following sections, and consisting 2743 of combinations of atom, quoted-string, and 2744 specials tokens, or else consisting of texts> 2745 field-name = 1*<any CHAR, excluding CTLs, SPACE, and ":"> 2746 group = phrase ":" [#mailbox] ";" 2747 hour = 2DIGIT ":" 2DIGIT [":" 2DIGIT] 2748 ; 00:00:00 - 23:59:59 2749 HTAB = <ASCII HT, horizontal-tab> ; ( 11, 9.) 2750 LF = <ASCII LF, linefeed> ; ( 12, 10.) 2751 linear-white-space = 1*([CRLF] LWSP-char) ; semantics = SPACE 2752 ; CRLF => folding 2753 local-part = word *("." word) ; uninterpreted 2754 ; case-preserved 2755 LWSP-char = SPACE / HTAB ; semantics = SPACE 2756 mailbox = addr-spec ; simple address 2757 / phrase route-addr ; name & addr-spec 2758 message = fields *( CRLF *text ) ; Everything after 2759 ; first null line 2760 ; is message body 2761 month = "Jan" / "Feb" / "Mar" / "Apr" 2762 / "May" / "Jun" / "Jul" / "Aug" 2763 / "Sep" / "Oct" / "Nov" / "Dec" 2764 msg-id = "<" addr-spec ">" ; Unique message id 2765 optional-field = 2766 / "Message-ID" ":" msg-id 2767 / "Resent-Message-ID" ":" msg-id 2768 / "In-Reply-To" ":" *(phrase / msg-id) 2769 / "References" ":" *(phrase / msg-id) 2770 / "Keywords" ":" #phrase 2771 / "Subject" ":" *text 2772 / "Comments" ":" *text 2773 / "Encrypted" ":" 1#2word 2774 / extension-field ; To be defined 2775 / user-defined-field ; May be pre-empted 2776 orig-date = "Date" ":" date-time 2777 originator = authentic ; authenticated addr 2778 [ "Reply-To" ":" 1#address] ) 2779 phrase = 1*word ; Sequence of words 2780 2781 2782 2783 2784 August 13, 1982 - 45 - RFC #822 2785 2786 2787 2788 Standard for ARPA Internet Text Messages 2789 2790 2791 qtext = <any CHAR excepting <">, ; => may be folded 2792 "\" & CR, and including 2793 linear-white-space> 2794 quoted-pair = "\" CHAR ; may quote any char 2795 quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or 2796 ; quoted chars. 2797 received = "Received" ":" ; one per relay 2798 ["from" domain] ; sending host 2799 ["by" domain] ; receiving host 2800 ["via" atom] ; physical path 2801 *("with" atom) ; link/mail protocol 2802 ["id" msg-id] ; receiver msg id 2803 ["for" addr-spec] ; initial form 2804 ";" date-time ; time received 2805 2806 resent = resent-authentic 2807 [ "Resent-Reply-To" ":" 1#address] ) 2808 resent-authentic = 2809 = "Resent-From" ":" mailbox 2810 / ( "Resent-Sender" ":" mailbox 2811 "Resent-From" ":" 1#mailbox ) 2812 resent-date = "Resent-Date" ":" date-time 2813 return = "Return-path" ":" route-addr ; return address 2814 route = 1#("@" domain) ":" ; path-relative 2815 route-addr = "<" [route] addr-spec ">" 2816 source = [ trace ] ; net traversals 2817 originator ; original mail 2818 [ resent ] ; forwarded 2819 SPACE = <ASCII SP, space> ; ( 40, 32.) 2820 specials = "(" / ")" / "<" / ">" / "@" ; Must be in quoted- 2821 / "," / ";" / ":" / "\" / <"> ; string, to use 2822 / "." / "[" / "]" ; within a word. 2823 sub-domain = domain-ref / domain-literal 2824 text = <any CHAR, including bare ; => atoms, specials, 2825 CR & bare LF, but NOT ; comments and 2826 including CRLF> ; quoted-strings are 2827 ; NOT recognized. 2828 time = hour zone ; ANSI and Military 2829 trace = return ; path to sender 2830 1*received ; receipt tags 2831 user-defined-field = 2832 <Any field which has not been defined 2833 in this specification or published as an 2834 extension to this specification; names for 2835 such fields must be unique and may be 2836 pre-empted by published extensions> 2837 word = atom / quoted-string 2838 2839 2840 2841 2842 August 13, 1982 - 46 - RFC #822 2843 2844 2845 2846 Standard for ARPA Internet Text Messages 2847 2848 2849 zone = "UT" / "GMT" ; Universal Time 2850 ; North American : UT 2851 / "EST" / "EDT" ; Eastern: - 5/ - 4 2852 / "CST" / "CDT" ; Central: - 6/ - 5 2853 / "MST" / "MDT" ; Mountain: - 7/ - 6 2854 / "PST" / "PDT" ; Pacific: - 8/ - 7 2855 / 1ALPHA ; Military: Z = UT; 2856 <"> = <ASCII quote mark> ; ( 42, 34.) 2857 2858 2859 2860 2861 2862 2863 2864 2865 2866 2867 2868 2869 2870 2871 2872 2873 2874 2875 2876 2877 2878 2879 2880 2881 2882 2883 2884 2885 2886 2887 2888 2889 2890 2891 2892 2893 2894 2895 2896 2897 2898 2899 2900 August 13, 1982 - 47 - RFC #822 2901