|
|
1.1 ! root 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: [email protected] ! 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: [email protected] ! 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: [email protected] ! 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: [email protected] ! 1836: ! 1837: and one recipient's address is: ! 1838: ! 1839: [email protected] ! 1840: ! 1841: and another's is: ! 1842: ! 1843: [email protected] ! 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: [email protected] ! 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: [email protected] ! 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" <[email protected]> ! 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 "[email protected]" ! 2242: completely specifies the destination mailbox. ! 2243: ! 2244: A.1.4. Wilt . (the Stilt) [email protected] ! 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: [email protected], Galloping Gourmet@ ! 2256: ANT.Down-Under (Australian National Television), ! 2257: Cheapie@Discount-Liquors;, ! 2258: Cruisers: Port@Portugal, Jones@SEA;, ! 2259: [email protected] ! 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: [email protected] ! 2280: ! 2281: or ! 2282: ! 2283: From: George Jones <[email protected]> ! 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<[email protected]> ! 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 <[email protected]> ! 2312: Sender: Jones@Host ! 2313: Reply-To: The Committee: [email protected], ! 2314: [email protected], ! 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: [email protected] or From: [email protected] ! 2391: Bcc: To: [email protected] ! 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 <[email protected]> ! 2409: Subject : Re: The Syntax in the RFC ! 2410: Sender : KSecy@Other-Host ! 2411: Reply-To : [email protected] ! 2412: To : George Jones <[email protected]>, ! 2413: [email protected] ! 2414: cc : Important folk: ! 2415: Tom Softwood <[email protected]>, ! 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: <[email protected]>, 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:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.