9 Obsoletes: RFC #733 (NIC #41952)
22 STANDARD FOR THE FORMAT OF
24 ARPA INTERNET TEXT MESSAGES
43 Dept. of Electrical Engineering
44 University of Delaware, Newark, DE 19711
45 Network: DCrocker @ UDel-Relay
61 Standard for ARPA Internet Text Messages
67 PREFACE .................................................... ii
69 1. INTRODUCTION ........................................... 1
71 1.1. Scope ............................................ 1
72 1.2. Communication Framework .......................... 2
74 2. NOTATIONAL CONVENTIONS ................................. 3
76 3. LEXICAL ANALYSIS OF MESSAGES ........................... 5
78 3.1. General Description .............................. 5
79 3.2. Header Field Definitions ......................... 9
80 3.3. Lexical Tokens ................................... 10
81 3.4. Clarifications ................................... 11
83 4. MESSAGE SPECIFICATION .................................. 17
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
93 5. DATE AND TIME SPECIFICATION ............................ 26
95 5.1. Syntax ........................................... 26
96 5.2. Semantics ........................................ 26
98 6. ADDRESS SPECIFICATION .................................. 27
100 6.1. Syntax ........................................... 27
101 6.2. Semantics ........................................ 27
102 6.3. Reserved Address ................................. 33
104 7. BIBLIOGRAPHY ........................................... 34
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
115 August 13, 1982 - i - RFC #822
120 Standard for ARPA Internet Text Messages
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.
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.
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
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.
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.
174 August 13, 1982 - ii - RFC #822
178 Standard for ARPA Internet Text Messages
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-
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
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.
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.
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
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.
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.
232 August 13, 1982 - 1 - RFC #822
236 Standard for ARPA Internet Text Messages
239 1.2. COMMUNICATION FRAMEWORK
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.
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.
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.
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.
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.
290 August 13, 1982 - 2 - RFC #822
294 Standard for ARPA Internet Text Messages
297 2. NOTATIONAL CONVENTIONS
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.
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.
313 2.2. RULE1 / RULE2: ALTERNATIVES
315 Elements separated by slash ("/") are alternatives. There-
316 fore "foo / bar" will accept foo or bar.
318 2.3. (RULE1 RULE2): LOCAL ALTERNATIVES
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".
324 2.4. *RULE: REPETITION
326 The character "*" preceding an element indicates repetition.
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.
336 2.5. [RULE]: OPTIONAL
338 Square brackets enclose optional elements; "[foo bar]" is
339 equivalent to "*1(foo bar)".
341 2.6. NRULE: SPECIFIC REPETITION
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.
348 August 13, 1982 - 3 - RFC #822
352 Standard for ARPA Internet Text Messages
357 A construct "#" is defined, similar to "*", as follows:
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.
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
406 August 13, 1982 - 4 - RFC #822
410 Standard for ARPA Internet Text Messages
413 3. LEXICAL ANALYSIS OF MESSAGES
415 3.1. GENERAL DESCRIPTION
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).
422 3.1.1. LONG HEADER FIELDS
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
433 To: "Joe & J. Harvey" <ddd @Org>, JJV @ BBN
435 can be represented as:
437 To: "Joe & J. Harvey" <ddd @ Org>,
442 To: "Joe & J. Harvey"
449 J. Harvey" <ddd @ Org>, JJV @ BBN
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.
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
464 August 13, 1982 - 5 - RFC #822
468 Standard for ARPA Internet Text Messages
471 between addresses, after the separating comma.
473 3.1.2. STRUCTURE OF HEADER FIELDS
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.)
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
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-
496 Field-names, unstructured field bodies and structured
497 field bodies each are scanned by their own, independent
500 3.1.3. UNSTRUCTURED FIELD BODIES
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
509 3.1.4. STRUCTURED FIELD BODIES
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
522 August 13, 1982 - 6 - RFC #822
526 Standard for ARPA Internet Text Messages
529 composing the body of the field as a sequence of lexical sym-
534 - individual special characters
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.)
548 So, for example, the folded body of an address field
550 ":sysmail"@ Some-Group. Some-Org,
551 Muhammed.(I am the greatest) Ali @(the)Vegas.WBA
580 August 13, 1982 - 7 - RFC #822
584 Standard for ARPA Internet Text Messages
587 is analyzed into the following lexical symbols and types:
589 :sysmail quoted string
597 (I am the greatest) comment
605 The canonical representations for the data in these addresses
606 are the following strings:
608 ":sysmail"@Some-Group.Some-Org
612 Muhammed.Ali@Vegas.WBA
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.
638 August 13, 1982 - 8 - RFC #822
642 Standard for ARPA Internet Text Messages
645 3.2. HEADER FIELD DEFINITIONS
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.
652 field = field-name ":" [ field-body ] CRLF
654 field-name = 1*<any CHAR, excluding CTLs, SPACE, and ":">
656 field-body = field-body-contents
657 [CRLF LWSP-char field-body]
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>
696 August 13, 1982 - 9 - RFC #822
700 Standard for ARPA Internet Text Messages
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.
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.)
724 LWSP-char = SPACE / HTAB ; semantics = SPACE
726 linear-white-space = 1*([CRLF] LWSP-char) ; semantics = SPACE
729 specials = "(" / ")" / "<" / ">" / "@" ; Must be in quoted-
730 / "," / ";" / ":" / "\" / <"> ; string, to use
731 / "." / "[" / "]" ; within a word.
733 delimiters = specials / linear-white-space / comment
735 text = <any CHAR, including bare ; => atoms, specials,
736 CR & bare LF, but NOT ; comments and
737 including CRLF> ; quoted-strings are
740 atom = 1*<any CHAR except specials, SPACE and CTLs>
742 quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or
745 qtext = <any CHAR excepting <">, ; => may be folded
746 "\" & CR, and including
749 domain-literal = "[" *(dtext / quoted-pair) "]"
754 August 13, 1982 - 10 - RFC #822
758 Standard for ARPA Internet Text Messages
761 dtext = <any CHAR excluding "[", ; => may be folded
762 "]", "\" & CR, & including
765 comment = "(" *(ctext / quoted-pair / comment) ")"
767 ctext = <any CHAR excluding "(", ; => may be folded
768 ")", "\" & CR, & including
771 quoted-pair = "\" CHAR ; may quote any char
773 phrase = 1*word ; Sequence of words
775 word = atom / quoted-string
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 ("\").
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:
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
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:
807 is not legal and must be specified as:
812 August 13, 1982 - 11 - RFC #822
816 Standard for ARPA Internet Text Messages
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.
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
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.
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.
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
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.
866 If a comment is to be "folded" onto multiple lines, then the
867 syntax for folding must be adhered to. (See the "Lexical
870 August 13, 1982 - 12 - RFC #822
874 Standard for ARPA Internet Text Messages
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.
888 3.4.4. DELIMITING AND QUOTING CHARACTERS
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.,
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.
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
919 3.4.5. QUOTED-STRINGS
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
928 August 13, 1982 - 13 - RFC #822
932 Standard for ARPA Internet Text Messages
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.
949 3.4.6. BRACKETING CHARACTERS
951 There is one type of bracket which must occur in matched pairs
952 and may have pairs nested within each other:
954 o Parentheses ("(" and ")") are used to indicate com-
957 There are three types of brackets which must occur in matched
958 pairs, and which may NOT be nested:
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.
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.
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.
974 3.4.7. CASE INDEPENDENCE
976 Except as noted, alphabetic strings may be represented in any
977 combination of upper and lower case. The only syntactic units
986 August 13, 1982 - 14 - RFC #822
990 Standard for ARPA Internet Text Messages
993 which requires preservation of case information are:
1000 - local-part, except "Postmaster"
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-
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.
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".
1016 3.4.8. FOLDING LONG HEADER FIELDS
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.
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
1033 3.4.9. BACKSPACE CHARACTERS
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.
1044 August 13, 1982 - 15 - RFC #822
1048 Standard for ARPA Internet Text Messages
1051 3.4.10. NETWORK-SPECIFIC TRANSFORMATIONS
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.
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:
1066 o Transformation Reversal
1068 The "current" network's idiosyncracies are removed and
1069 the message is returned to the canonical form speci-
1070 fied in this standard.
1074 The "next" network's local idiosyncracies are imposed
1078 From ==> | Remove Net-A |
1079 Net-A | idiosyncracies |
1088 | Impose Net-B | ==> To
1089 | idiosyncracies | Net-B
1102 August 13, 1982 - 16 - RFC #822
1106 Standard for ARPA Internet Text Messages
1109 4. MESSAGE SPECIFICATION
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",
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.
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
1133 message = fields *( CRLF *text ) ; Everything after
1137 fields = dates ; Creation time,
1138 source ; author id & one
1139 1*destination ; address required
1140 *optional-field ; others optional
1142 source = [ trace ] ; net traversals
1143 originator ; original mail
1144 [ resent ] ; forwarded
1146 trace = return ; path to sender
1147 1*received ; receipt tags
1149 return = "Return-path" ":" route-addr ; return address
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
1160 August 13, 1982 - 17 - RFC #822
1164 Standard for ARPA Internet Text Messages
1167 ";" date-time ; time received
1169 originator = authentic ; authenticated addr
1170 [ "Reply-To" ":" 1#address] )
1172 authentic = "From" ":" mailbox ; Single author
1173 / ( "Sender" ":" mailbox ; Actual submittor
1174 "From" ":" 1#mailbox) ; Multiple authors
1177 resent = resent-authentic
1178 [ "Resent-Reply-To" ":" 1#address] )
1181 = "Resent-From" ":" mailbox
1182 / ( "Resent-Sender" ":" mailbox
1183 "Resent-From" ":" 1#mailbox )
1185 dates = orig-date ; Original
1186 [ resent-date ] ; Forwarded
1188 orig-date = "Date" ":" date-time
1190 resent-date = "Resent-Date" ":" date-time
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
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
1211 msg-id = "<" addr-spec ">" ; Unique message id
1218 August 13, 1982 - 18 - RFC #822
1222 Standard for ARPA Internet Text Messages
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-">
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>
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
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.
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.
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
1266 In the remainder of this specification, occurrence of legal
1267 "Resent-" fields are treated identically with the occurrence of
1276 August 13, 1982 - 19 - RFC #822
1280 Standard for ARPA Internet Text Messages
1283 fields whose names do not contain this prefix.
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.
1291 The list of known "via" and "with" values are registered
1292 with the Network Information Center, SRI International, Menlo
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.
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-
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.
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.
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-
1325 Note: Several "with" parameters may be included, to fully
1326 specify the set of protocols that were used.
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
1334 August 13, 1982 - 20 - RFC #822
1338 Standard for ARPA Internet Text Messages
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.
1347 4.4. ORIGINATOR FIELDS
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.
1353 4.4.1. FROM / RESENT-FROM
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
1366 4.4.2. SENDER / RESENT-SENDER
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.
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.
1392 August 13, 1982 - 21 - RFC #822
1396 Standard for ARPA Internet Text Messages
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-
1407 4.4.3. REPLY-TO / RESENT-REPLY-TO
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
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.
1430 4.4.4. AUTOMATIC USE OF FROM / SENDER / REPLY-TO
1432 For systems which automatically generate address lists for
1433 replies to messages, the following recommendations are made:
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.
1440 o The "Sender" field mailbox should NEVER be used
1441 automatically, in a recipient's reply message.
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.
1450 August 13, 1982 - 22 - RFC #822
1454 Standard for ARPA Internet Text Messages
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.
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.
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.
1471 Examples are provided in Appendix A.
1473 4.5. RECEIVER FIELDS
1475 4.5.1. TO / RESENT-TO
1477 This field contains the identity of the primary recipients of
1480 4.5.2. CC / RESENT-CC
1482 This field contains the identity of the secondary (informa-
1483 tional) recipients of the message.
1485 4.5.3. BCC / RESENT-BCC
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
1495 4.6. REFERENCE FIELDS
1497 4.6.1. MESSAGE-ID / RESENT-MESSAGE-ID
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
1508 August 13, 1982 - 23 - RFC #822
1512 Standard for ARPA Internet Text Messages
1515 each receive new message identifiers.
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.
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.
1532 This field contains keywords or phrases, separated by
1539 This is intended to provide a summary, or indicate the
1540 nature, of the message.
1544 Permits adding text comments onto the message without
1545 disturbing the contents of the message's body.
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.
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
1566 August 13, 1982 - 24 - RFC #822
1570 Standard for ARPA Internet Text Messages
1573 sensitive information, this requirement limits total
1576 Names of encryption software are registered with the Net-
1577 work Information Center, SRI International, Menlo Park, Cali-
1580 4.7.4. EXTENSION-FIELD
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
1589 Names of Extension-fields are registered with the Network
1590 Information Center, SRI International, Menlo Park, California.
1592 4.7.5. USER-DEFINED-FIELD
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
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.
1624 August 13, 1982 - 25 - RFC #822
1628 Standard for ARPA Internet Text Messages
1631 5. DATE AND TIME SPECIFICATION
1635 date-time = [ day "," ] date time ; dd mm yy
1638 day = "Mon" / "Tue" / "Wed" / "Thu"
1639 / "Fri" / "Sat" / "Sun"
1641 date = 1*2DIGIT month 2DIGIT ; day month year
1644 month = "Jan" / "Feb" / "Mar" / "Apr"
1645 / "May" / "Jun" / "Jul" / "Aug"
1646 / "Sep" / "Oct" / "Nov" / "Dec"
1648 time = hour zone ; ANSI and Military
1650 hour = 2DIGIT ":" 2DIGIT [":" 2DIGIT]
1651 ; 00:00:00 - 23:59:59
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
1667 If included, day-of-week must be the day implied by the date
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.
1682 August 13, 1982 - 26 - RFC #822
1686 Standard for ARPA Internet Text Messages
1689 6. ADDRESS SPECIFICATION
1693 address = mailbox ; one addressee
1694 / group ; named list
1696 group = phrase ":" [#mailbox] ";"
1698 mailbox = addr-spec ; simple address
1699 / phrase route-addr ; name & addr-spec
1701 route-addr = "<" [route] addr-spec ">"
1703 route = 1#("@" domain) ":" ; path-relative
1705 addr-spec = local-part "@" domain ; global address
1707 local-part = word *("." word) ; uninterpreted
1710 domain = sub-domain *("." sub-domain)
1712 sub-domain = domain-ref / domain-literal
1714 domain-ref = atom ; symbolic reference
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.
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.
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.
1740 August 13, 1982 - 27 - RFC #822
1744 Standard for ARPA Internet Text Messages
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.
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.
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.
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.
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:
1776 person@registry.organization
1778 Note that "organization" is a logical entity, separate from
1779 any particular communication network.
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.
1789 The latter, network-oriented case permits simple, direct,
1790 attachment-related address specification, such as:
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
1798 August 13, 1982 - 28 - RFC #822
1802 Standard for ARPA Internet Text Messages
1805 the user name, placing the message in the user's mailbox.
1807 6.2.2. ABBREVIATED DOMAIN SPECIFICATION
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:
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.
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.
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.
1833 For example, if a sender's address is:
1835 sender@registry-A.registry-1.organization-X
1837 and one recipient's address is:
1839 recipient@registry-B.registry-1.organization-X
1843 recipient@registry-C.registry-2.organization-X
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.
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
1856 August 13, 1982 - 29 - RFC #822
1860 Standard for ARPA Internet Text Messages
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.
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
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.
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.
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:
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
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.
1908 6.2.4. DOMAIN-DEPENDENT LOCAL STRING
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
1914 August 13, 1982 - 30 - RFC #822
1918 Standard for ARPA Internet Text Messages
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.
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-
1935 For example, the address:
1937 First.Last@Registry.Org
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.
1945 6.2.5. BALANCING LOCAL-PART AND DOMAIN
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
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:
1959 mailbox.sub1.sub2@this-domain
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.
1966 Also, some sub-domains have a specification syntax which does
1967 not conform to this standard. For example:
1969 sub-net.mailbox@sub-domain.domain
1972 August 13, 1982 - 31 - RFC #822
1976 Standard for ARPA Internet Text Messages
1979 uses a different parsing sequence for local-part than for
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.
1989 6.2.6. MULTIPLE MAILBOXES
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.
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.
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
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.
2020 6.2.7. EXPLICIT PATH SPECIFICATION
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
2030 August 13, 1982 - 32 - RFC #822
2034 Standard for ARPA Internet Text Messages
2037 services that are to be traversed. Both domain-refs and
2038 domain-literals may be used.
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-
2045 6.3. RESERVED ADDRESS
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.
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:
2060 so that "Postmaster@domain" is required to be valid.
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.
2088 August 13, 1982 - 33 - RFC #822
2092 Standard for ARPA Internet Text Messages
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-
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).
2108 Bemer, R.W., "Time and the Computer." In: Interface Age (Feb.
2111 Bennett, C.J. "JNT Mail Protocol". Joint Network Team, Ruther-
2112 ford and Appleton Laboratory: Didcot, England.
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).
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.
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
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).
2133 Harary, F. "Graph Theory". Addison-Wesley: Reading, Mass.
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.
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).
2146 August 13, 1982 - 34 - RFC #822
2150 Standard for ARPA Internet Text Messages
2153 NBS. "Specification of Message Format for Computer Based Message
2154 Systems, Recommended Federal Information Processing Standard."
2155 National Bureau of Standards: Gaithersburg, Maryland
2158 NIC. Internet Protocol Transition Workbook. Network Information
2159 Center, SRI-International, Menlo Park, California (March
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,
2167 Postel, J.B. "Assigned Numbers," ARPANET Request for Comments,
2168 No. 820. SRI International: Menlo Park (August 1982).
2170 Postel, J.B. "Simple Mail Transfer Protocol," ARPANET Request
2171 for Comments, No. 821. SRI International: Menlo Park (August
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.
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).
2204 August 13, 1982 - 35 - RFC #822
2208 Standard for ARPA Internet Text Messages
2218 A.1.1. Alfred Neuman <Neuman@BBN-TENEXA>
2220 A.1.2. Neuman@BBN-TENEXA
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-
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
2237 A.1.3. "George, Ted" <Shared@Group.Arpanet>
2239 This form might be used to indicate that a single mailbox
2240 is shared by several users. The quoted string is ignored by
2241 the originating host's mailer, because "Shared@Group.Arpanet"
2242 completely specifies the destination mailbox.
2244 A.1.4. Wilt . (the Stilt) Chamberlain@NBA.US
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
2252 A.1.5. Address Lists
2254 Gourmets: Pompous Person <WhoZiWhatZit@Cordon-Bleu>,
2255 Childs@WGBH.Boston, Galloping Gourmet@
2256 ANT.Down-Under (Australian National Television),
2257 Cheapie@Discount-Liquors;,
2258 Cruisers: Port@Portugal, Jones@SEA;,
2259 Another@Somewhere.SomeOrg
2262 August 13, 1982 - 36 - RFC #822
2266 Standard for ARPA Internet Text Messages
2269 This group list example points out the use of comments and the
2270 mixing of addresses and groups.
2272 A.2. ORIGINATOR ITEMS
2276 George Jones logs into his host as "Jones". He sends
2279 From: Jones@Group.Org
2283 From: George Jones <Jones@Group.Org>
2285 A.2.2. Secretary-sent
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.
2291 From: George Jones <Jones@Group>
2292 Sender: Secy@Other-Group
2294 A.2.3. Secretary-sent, for user of shared directory
2296 George Jones' secretary sends mail for George. Replies
2297 should go to George.
2299 From: George Jones<Shared@Group.Org>
2300 Sender: Secy@Other-Group
2302 Note that there need not be a space between "Jones" and the
2303 "<", but adding a space enhances readability (as is the case
2306 A.2.4. Committee activity, with one author
2308 George is a member of a committee. He wishes to have any
2309 replies to his message go to all committee members.
2311 From: George Jones <Jones@Host.Net>
2313 Reply-To: The Committee: Jones@Host.Net,
2317 Note that if George had not included himself in the
2320 August 13, 1982 - 37 - RFC #822
2324 Standard for ARPA Internet Text Messages
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"
2332 A.2.5. Secretary acting as full agent of author
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.
2338 From: George Jones <Group@Host>
2342 A.2.6. Agent for user without online mailbox
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
2349 From: Sarah Friendly <Secy@Registry>
2350 Sender: Secy-Name <Secy@Registry>
2351 Reply-To: Jones@Registry.
2353 A.2.7. Agent for member of a committee
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.
2378 August 13, 1982 - 38 - RFC #822
2382 Standard for ARPA Internet Text Messages
2385 A.3. COMPLETE HEADERS
2387 A.3.1. Minimum required
2389 Date: 26 Aug 76 1429 EDT Date: 26 Aug 76 1429 EDT
2390 From: Jones@Registry.Org or From: Jones@Registry.Org
2391 Bcc: To: Smith@Registry.Org
2393 Note that the "Bcc" field may be empty, while the "To" field
2394 is required to have at least one address.
2396 A.3.2. Using some of the additional fields
2398 Date: 26 Aug 76 1430 EDT
2399 From: George Jones<Group@Host>
2401 To: "Al Neuman"@Mad-Host,
2402 Sam.Irving@Other-Host
2403 Message-ID: <some.string@SHOST>
2405 A.3.3. About as complex as you're going to get
2407 Date : 27 Aug 76 0932 PDT
2408 From : Ken Davis <KDavis@This-Host.This-net>
2409 Subject : Re: The Syntax in the RFC
2410 Sender : KSecy@Other-Host
2411 Reply-To : Sam.Irving@Reg.Organization
2412 To : George Jones <Group@Some-Reg.An-Org>,
2413 Al.Neuman@MAD.Publisher
2414 cc : Important folk:
2415 Tom Softwood <Balsa@Tree.Root>,
2416 "Sam Irving"@Other-Host;,
2417 Standard Distribution:
2418 /main/davis/people/standard@Other-Host,
2419 "<Jones>standard.dist.3"@Tops-20-Host>;
2420 Comment : Sam is away on business. He asked me to handle
2421 his mail for him. He'll be able to provide a
2422 more accurate explanation when he returns
2424 In-Reply-To: <some.string@DBM.Group>, George's message
2425 X-Special-action: This is a sample of user-defined field-
2426 names. There could also be a field-name
2427 "Special-action", but its name might later be
2429 Message-ID: <4231.629.XYzi-What@Other-Host>
2436 August 13, 1982 - 39 - RFC #822
2440 Standard for ARPA Internet Text Messages
2443 B. SIMPLE FIELD PARSING
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:
2450 o Header fields from the message body,
2452 o Beginnings of fields from lines which continue fields,
2454 o Field-names from field-contents.
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:
2465 message = *field *(CRLF *text)
2467 field = field-name ":" [field-body] CRLF
2469 field-name = 1*<any CHAR, excluding CTLs, SPACE, and ":">
2471 field-body = *text [CRLF LWSP-char field-body]
2476 Headers occur before the message body and are terminated by
2477 a null line (i.e., two contiguous CRLFs).
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.
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.
2494 August 13, 1982 - 40 - RFC #822
2498 Standard for ARPA Internet Text Messages
2501 C. DIFFERENCES FROM RFC #733
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.
2509 C.1. FIELD DEFINITIONS
2513 These now must be a sequence of printable characters. They
2514 may not contain any LWSP-chars.
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.
2530 Atoms may not contain SPACE.
2534 ctext and qtext have had backslash ("\") added to the list of
2535 prohibited characters.
2539 The lexical tokens <domain-literal> and <dtext> have been
2542 C.3. MESSAGE SPECIFICATION
2546 The "Return-path:" and "Received:" fields have been specified.
2552 August 13, 1982 - 41 - RFC #822
2556 Standard for ARPA Internet Text Messages
2561 The "From" field must contain machine-usable addresses (addr-
2562 spec). Multiple addresses may be specified, but named-lists
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.
2573 A message must contain at least one destination address field.
2574 "To" and "CC" are required to contain at least one address.
2578 The field-body is no longer a comma-separated list, although a
2579 sequence is still permitted.
2583 The field-body is no longer a comma-separated list, although a
2584 sequence is still permitted.
2588 A field has been specified that permits senders to indicate
2589 that the body of a message has been encrypted.
2591 C.3.8. EXTENSION-FIELD
2593 Extension fields are prohibited from beginning with the char-
2596 C.4. DATE AND TIME SPECIFICATION
2598 C.4.1. SIMPLIFICATION
2600 Fewer optional forms are permitted and the list of three-
2601 letter time zones has been shortened.
2603 C.5. ADDRESS SPECIFICATION
2610 August 13, 1982 - 42 - RFC #822
2614 Standard for ARPA Internet Text Messages
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.
2626 Group lists are now required to to have a name. Group lists
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.
2635 C.5.4. ROUTE ADDRESSING
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.
2647 The string " at " no longer is used as an address delimiter.
2648 Only at-sign ("@") serves the function.
2652 Hierarchical, logical name-domains have been added.
2654 C.6. RESERVED ADDRESS
2656 The local-part "Postmaster" has been reserved, so that users can
2657 be guaranteed at least one valid address at a site.
2668 August 13, 1982 - 43 - RFC #822
2672 Standard for ARPA Internet Text Messages
2675 D. ALPHABETICAL LISTING OF SYNTAX RULES
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
2688 CHAR = <any ASCII character> ; ( 0-177, 0.-127.)
2689 comment = "(" *(ctext / quoted-pair / comment) ")"
2690 CR = <ASCII CR, carriage return> ; ( 15, 13.)
2692 ctext = <any CHAR excluding "(", ; => may be folded
2693 ")", "\" & CR, & including
2695 CTL = <any ASCII control ; ( 0- 37, 0.- 31.)
2696 character and DEL> ; ( 177, 127.)
2697 date = 1*2DIGIT month 2DIGIT ; day month year
2699 dates = orig-date ; Original
2700 [ resent-date ] ; Forwarded
2701 date-time = [ day "," ] date time ; dd mm yy
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
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-">
2726 August 13, 1982 - 44 - RFC #822
2730 Standard for ARPA Internet Text Messages
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
2753 local-part = word *("." word) ; uninterpreted
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
2761 month = "Jan" / "Feb" / "Mar" / "Apr"
2762 / "May" / "Jun" / "Jul" / "Aug"
2763 / "Sep" / "Oct" / "Nov" / "Dec"
2764 msg-id = "<" addr-spec ">" ; Unique message id
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
2784 August 13, 1982 - 45 - RFC #822
2788 Standard for ARPA Internet Text Messages
2791 qtext = <any CHAR excepting <">, ; => may be folded
2792 "\" & CR, and including
2794 quoted-pair = "\" CHAR ; may quote any char
2795 quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or
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
2806 resent = resent-authentic
2807 [ "Resent-Reply-To" ":" 1#address] )
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
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
2842 August 13, 1982 - 46 - RFC #822
2846 Standard for ARPA Internet Text Messages
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.)
2900 August 13, 1982 - 47 - RFC #822
projects / ~andy / fetchmail / blob