![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to rfc822.lpr CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSDTahoe / usr.lib / sendmail / doc|
Return to rfc822.lpr CVS log | Up to [CSRG BSD Unix] / 43BSDTahoe / usr.lib / sendmail / doc |
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.