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