-
Notifications
You must be signed in to change notification settings - Fork 1
/
rfc2822.txt
2374 lines (1866 loc) · 109 KB
/
rfc2822.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
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
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
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
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
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
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<HTML>
<HEAD>
<TITLE>RFC 2822 (rfc2822) - Internet Message Format</TITLE>
<META name="description" content="RFC 2822 - Internet Message Format">
<META name="obsoletes" content="RFC0822">
<script language="JavaScript1.2">
function erfc(s)
{document.write("<A href=\"/rfccomment.php?rfcnum="+s+"\" target=\"_blank\" onclick=\"window.open('/rfccomment.php?rfcnum="+s+"','Popup','toolbar=no,location=no,status=no,menubar=no,scrollbars=yes,resizable=yes,width=680,height=530,left=30,top=43'); return false;\")>Comment on RFC "+s+"</A>\n");}
//-->
</script>
</HEAD>
<BODY BGCOLOR="#ffffff" TEXT="#000000">
<P ALIGN=CENTER><IMG SRC="/images/library.jpg" HEIGHT=62 WIDTH=150 BORDER="0" ALIGN="MIDDLE" ALT=""></P>
<H1 ALIGN=CENTER>RFC 2822 (RFC2822)</H1>
<P ALIGN=CENTER>Internet RFC/STD/FYI/BCP Archives</P>
<DIV ALIGN=CENTER>[ <a href="/rfcs/">RFC Index</a> | <A HREF="/rfcs/rfcsearch.html">RFC Search</A> | <a href="/faqs/">Usenet FAQs</a> | <a href="/contrib/">Web FAQs</a> | <a href="/docs/">Documents</a> | <a href="http://www.city-data.com/">Cities</a> ]
<P>
<STRONG>Alternate Formats:</STRONG>
<A HREF="/ftp/rfc/rfc2822.txt">rfc2822.txt</A> |
<A HREF="/ftp/rfc/pdf/rfc2822.txt.pdf">rfc2822.txt.pdf</A></DIV>
<p align=center><script language="JavaScript"><!--
erfc("2822");
// --></script></p>
<h3 align=center>RFC 2822 - Internet Message Format</h3>
<HR SIZE=2 NOSHADE>
<PRE>
Network Working Group P. Resnick, Editor
Request for Comments: 2822 QUALCOMM Incorporated
Obsoletes: 822 April 2001
Category: Standards Track
Internet Message Format
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
This standard specifies a syntax for text messages that are sent
between computer users, within the framework of "electronic mail"
messages. This standard supersedes the one specified in Request For
Comments (RFC) 822, "Standard for the Format of ARPA Internet Text
Messages", updating it to reflect current practice and incorporating
incremental changes that were specified in other RFCs.
Table of Contents
1. Introduction ............................................... 3
1.1. Scope .................................................... 3
1.2. Notational conventions ................................... 4
1.2.1. Requirements notation .................................. 4
1.2.2. Syntactic notation ..................................... 4
1.3. Structure of this document ............................... 4
2. Lexical Analysis of Messages ............................... 5
2.1. General Description ...................................... 5
2.1.1. Line Length Limits ..................................... 6
2.2. Header Fields ............................................ 7
2.2.1. Unstructured Header Field Bodies ....................... 7
2.2.2. Structured Header Field Bodies ......................... 7
2.2.3. Long Header Fields ..................................... 7
2.3. Body ..................................................... 8
3. Syntax ..................................................... 9
3.1. Introduction ............................................. 9
3.2. Lexical Tokens ........................................... 9
3.2.1. Primitive Tokens ....................................... 9
3.2.2. Quoted characters ......................................10
3.2.3. Folding white space and comments .......................11
3.2.4. Atom ...................................................12
3.2.5. Quoted strings .........................................13
3.2.6. Miscellaneous tokens ...................................13
3.3. Date and Time Specification ..............................14
3.4. Address Specification ....................................15
3.4.1. Addr-spec specification ................................16
3.5 Overall message syntax ....................................17
3.6. Field definitions ........................................18
3.6.1. The origination date field .............................20
3.6.2. Originator fields ......................................21
3.6.3. Destination address fields .............................22
3.6.4. Identification fields ..................................23
3.6.5. Informational fields ...................................26
3.6.6. Resent fields ..........................................26
3.6.7. Trace fields ...........................................28
3.6.8. Optional fields ........................................29
4. Obsolete Syntax ............................................29
4.1. Miscellaneous obsolete tokens ............................30
4.2. Obsolete folding white space .............................31
4.3. Obsolete Date and Time ...................................31
4.4. Obsolete Addressing ......................................33
4.5. Obsolete header fields ...................................33
4.5.1. Obsolete origination date field ........................34
4.5.2. Obsolete originator fields .............................34
4.5.3. Obsolete destination address fields ....................34
4.5.4. Obsolete identification fields .........................35
4.5.5. Obsolete informational fields ..........................35
4.5.6. Obsolete resent fields .................................35
4.5.7. Obsolete trace fields ..................................36
4.5.8. Obsolete optional fields ...............................36
5. Security Considerations ....................................36
6. Bibliography ...............................................37
7. Editor's Address ...........................................38
8. Acknowledgements ...........................................39
Appendix A. Example messages ..................................41
A.1. Addressing examples ......................................41
A.1.1. A message from one person to another with simple
addressing .............................................41
A.1.2. Different types of mailboxes ...........................42
A.1.3. Group addresses ........................................43
A.2. Reply messages ...........................................43
A.3. Resent messages ..........................................44
A.4. Messages with trace fields ...............................46
A.5. White space, comments, and other oddities ................47
A.6. Obsoleted forms ..........................................47
A.6.1. Obsolete addressing ....................................48
A.6.2. Obsolete dates .........................................48
A.6.3. Obsolete white space and comments ......................48
Appendix B. Differences from earlier standards ................49
Appendix C. Notices ...........................................50
Full Copyright Statement ......................................51
1. Introduction
1.1. Scope
This standard specifies a syntax for text messages that are sent
between computer users, within the framework of "electronic mail"
messages. This standard supersedes the one specified in Request For
Comments (RFC) 822, "Standard for the Format of ARPA Internet Text
Messages" [<A HREF="/rfcs/rfc822.html">RFC822</A>], updating it to reflect current practice and
incorporating incremental changes that were specified in other RFCs
[STD3].
This standard specifies a syntax only for text messages. In
particular, it makes no provision for the transmission of images,
audio, or other sorts of structured data in electronic mail messages.
There are several extensions published, such as the MIME document
series [<A HREF="/rfcs/rfc2045.html">RFC2045</A>, <A HREF="/rfcs/rfc2046.html">RFC2046</A>, <A HREF="/rfcs/rfc2049.html">RFC2049</A>], which describe mechanisms for the
transmission of such data through electronic mail, either by
extending the syntax provided here or by structuring such messages to
conform to this syntax. Those mechanisms are outside of the scope of
this standard.
In the context of electronic mail, messages are viewed as having an
envelope and contents. The envelope contains whatever information is
needed to accomplish transmission and delivery. (See [<A HREF="/rfcs/rfc2821.html">RFC2821</A>] for a
discussion of the envelope.) The contents comprise the object to be
delivered to the recipient. This standard applies only to the format
and some of the semantics of message contents. It contains no
specification of the information in the envelope.
However, some message systems may use information from the contents
to create the envelope. It is intended that this standard facilitate
the acquisition of such information by programs.
This specification is intended as a definition of what message
content format is to be passed between systems. Though some message
systems locally store messages in this format (which eliminates the
need for translation between formats) and others use formats that
differ from the one specified in this standard, local storage is
outside of the scope of this standard.
Note: This standard is not intended to dictate the internal formats
used by sites, the specific message system features that they are
expected to support, or any of the characteristics of user interface
programs that create or read messages. In addition, this standard
does not specify an encoding of the characters for either transport
or storage; that is, it does not specify the number of bits used or
how those bits are specifically transferred over the wire or stored
on disk.
1.2. Notational conventions
1.2.1. Requirements notation
This document occasionally uses terms that appear in capital letters.
When the terms "MUST", "SHOULD", "RECOMMENDED", "MUST NOT", "SHOULD
NOT", and "MAY" appear capitalized, they are being used to indicate
particular requirements of this specification. A discussion of the
meanings of these terms appears in [<A HREF="/rfcs/rfc2119.html">RFC2119</A>].
1.2.2. Syntactic notation
This standard uses the Augmented Backus-Naur Form (ABNF) notation
specified in [<A HREF="/rfcs/rfc2234.html">RFC2234</A>] for the formal definitions of the syntax of
messages. Characters will be specified either by a decimal value
(e.g., the value %d65 for uppercase A and %d97 for lowercase A) or by
a case-insensitive literal value enclosed in quotation marks (e.g.,
"A" for either uppercase or lowercase A). See [<A HREF="/rfcs/rfc2234.html">RFC2234</A>] for the full
description of the notation.
1.3. Structure of this document
This document is divided into several sections.
This section, section 1, is a short introduction to the document.
Section 2 lays out the general description of a message and its
constituent parts. This is an overview to help the reader understand
some of the general principles used in the later portions of this
document. Any examples in this section MUST NOT be taken as
specification of the formal syntax of any part of a message.
Section 3 specifies formal ABNF rules for the structure of each part
of a message (the syntax) and describes the relationship between
those parts and their meaning in the context of a message (the
semantics). That is, it describes the actual rules for the structure
of each part of a message (the syntax) as well as a description of
the parts and instructions on how they ought to be interpreted (the
semantics). This includes analysis of the syntax and semantics of
subparts of messages that have specific structure. The syntax
included in section 3 represents messages as they MUST be created.
There are also notes in section 3 to indicate if any of the options
specified in the syntax SHOULD be used over any of the others.
Both sections 2 and 3 describe messages that are legal to generate
for purposes of this standard.
Section 4 of this document specifies an "obsolete" syntax. There are
references in section 3 to these obsolete syntactic elements. The
rules of the obsolete syntax are elements that have appeared in
earlier revisions of this standard or have previously been widely
used in Internet messages. As such, these elements MUST be
interpreted by parsers of messages in order to be conformant to this
standard. However, since items in this syntax have been determined
to be non-interoperable or to cause significant problems for
recipients of messages, they MUST NOT be generated by creators of
conformant messages.
Section 5 details security considerations to take into account when
implementing this standard.
Section 6 is a bibliography of references in this document.
Section 7 contains the editor's address.
Section 8 contains acknowledgements.
Appendix A lists examples of different sorts of messages. These
examples are not exhaustive of the types of messages that appear on
the Internet, but give a broad overview of certain syntactic forms.
Appendix B lists the differences between this standard and earlier
standards for Internet messages.
Appendix C has copyright and intellectual property notices.
2. Lexical Analysis of Messages
2.1. General Description
At the most basic level, a message is a series of characters. A
message that is conformant with this standard is comprised of
characters with values in the range 1 through 127 and interpreted as
US-ASCII characters [ASCII]. For brevity, this document sometimes
refers to this range of characters as simply "US-ASCII characters".
Note: This standard specifies that messages are made up of characters
in the US-ASCII range of 1 through 127. There are other documents,
specifically the MIME document series [<A HREF="/rfcs/rfc2045.html">RFC2045</A>, <A HREF="/rfcs/rfc2046.html">RFC2046</A>, <A HREF="/rfcs/rfc2047.html">RFC2047</A>,
<A HREF="/rfcs/rfc2048.html">RFC2048</A>, <A HREF="/rfcs/rfc2049.html">RFC2049</A>], that extend this standard to allow for values
outside of that range. Discussion of those mechanisms is not within
the scope of this standard.
Messages are divided into lines of characters. A line is a series of
characters that is delimited with the two characters carriage-return
and line-feed; that is, the carriage return (CR) character (ASCII
value 13) followed immediately by the line feed (LF) character (ASCII
value 10). (The carriage-return/line-feed pair is usually written in
this document as "CRLF".)
A message consists of header fields (collectively called "the header
of the message") followed, optionally, by a body. The header is a
sequence of lines of characters with special syntax as defined in
this standard. The body is simply a sequence of characters that
follows the header and is separated from the header by an empty line
(i.e., a line with nothing preceding the CRLF).
2.1.1. Line Length Limits
There are two limits that this standard places on the number of
characters in a line. Each line of characters MUST be no more than
998 characters, and SHOULD be no more than 78 characters, excluding
the CRLF.
The 998 character limit is due to limitations in many implementations
which send, receive, or store Internet Message Format messages that
simply cannot handle more than 998 characters on a line. Receiving
implementations would do well to handle an arbitrarily large number
of characters in a line for robustness sake. However, there are so
many implementations which (in compliance with the transport
requirements of [<A HREF="/rfcs/rfc2821.html">RFC2821</A>]) do not accept messages containing more
than 1000 character including the CR and LF per line, it is important
for implementations not to create such messages.
The more conservative 78 character recommendation is to accommodate
the many implementations of user interfaces that display these
messages which may truncate, or disastrously wrap, the display of
more than 78 characters per line, in spite of the fact that such
implementations are non-conformant to the intent of this
specification (and that of [<A HREF="/rfcs/rfc2821.html">RFC2821</A>] if they actually cause
information to be lost). Again, even though this limitation is put on
messages, it is encumbant upon implementations which display messages
to handle an arbitrarily large number of characters in a line
(certainly at least up to the 998 character limit) for the sake of
robustness.
2.2. Header Fields
Header fields are lines composed of a field name, followed by a colon
(":"), followed by a field body, and terminated by CRLF. A field
name MUST be composed of printable US-ASCII characters (i.e.,
characters that have values between 33 and 126, inclusive), except
colon. A field body may be composed of any US-ASCII characters,
except for CR and LF. However, a field body may contain CRLF when
used in header "folding" and "unfolding" as described in section
2.2.3. All field bodies MUST conform to the syntax described in
sections 3 and 4 of this standard.
2.2.1. Unstructured Header Field Bodies
Some field bodies in this standard are defined simply as
"unstructured" (which is specified below as any US-ASCII characters,
except for CR and LF) with no further restrictions. These are
referred to as unstructured field bodies. Semantically, unstructured
field bodies are simply to be treated as a single line of characters
with no further processing (except for header "folding" and
"unfolding" as described in section 2.2.3).
2.2.2. Structured Header Field Bodies
Some field bodies in this standard have specific syntactical
structure more restrictive than the unstructured field bodies
described above. These are referred to as "structured" field bodies.
Structured field bodies are sequences of specific lexical tokens as
described in sections 3 and 4 of this standard. Many of these tokens
are allowed (according to their syntax) to be introduced or end with
comments (as described in section 3.2.3) as well as the space (SP,
ASCII value 32) and horizontal tab (HTAB, ASCII value 9) characters
(together known as the white space characters, WSP), and those WSP
characters are subject to header "folding" and "unfolding" as
described in section 2.2.3. Semantic analysis of structured field
bodies is given along with their syntax.
2.2.3. Long Header Fields
Each header field is logically a single line of characters comprising
the field name, the colon, and the field body. For convenience
however, and to deal with the 998/78 character limitations per line,
the field body portion of a header field can be split into a multiple
line representation; this is called "folding". The general rule is
that wherever this standard allows for folding white space (not
simply WSP characters), a CRLF may be inserted before any WSP. For
example, the header field:
Subject: This is a test
can be represented as:
Subject: This
is a test
Note: Though structured field bodies are defined in such a way that
folding can take place between many of the lexical tokens (and even
within some of the lexical tokens), folding SHOULD be limited to
placing the CRLF at higher-level syntactic breaks. For instance, if
a field body is defined as comma-separated values, it is recommended
that folding occur after the comma separating the structured items in
preference to other places where the field could be folded, even if
it is allowed elsewhere.
The process of moving from this folded multiple-line representation
of a header field to its single line representation is called
"unfolding". Unfolding is accomplished by simply removing any CRLF
that is immediately followed by WSP. Each header field should be
treated in its unfolded form for further syntactic and semantic
evaluation.
2.3. Body
The body of a message is simply lines of US-ASCII characters. The
only two limitations on the body are as follows:
- CR and LF MUST only occur together as CRLF; they MUST NOT appear
independently in the body.
- Lines of characters in the body MUST be limited to 998 characters,
and SHOULD be limited to 78 characters, excluding the CRLF.
Note: As was stated earlier, there are other standards documents,
specifically the MIME documents [<A HREF="/rfcs/rfc2045.html">RFC2045</A>, <A HREF="/rfcs/rfc2046.html">RFC2046</A>, <A HREF="/rfcs/rfc2048.html">RFC2048</A>, <A HREF="/rfcs/rfc2049.html">RFC2049</A>]
that extend this standard to allow for different sorts of message
bodies. Again, these mechanisms are beyond the scope of this
document.
3. Syntax
3.1. Introduction
The syntax as given in this section defines the legal syntax of
Internet messages. Messages that are conformant to this standard
MUST conform to the syntax in this section. If there are options in
this section where one option SHOULD be generated, that is indicated
either in the prose or in a comment next to the syntax.
For the defined expressions, a short description of the syntax and
use is given, followed by the syntax in ABNF, followed by a semantic
analysis. Primitive tokens that are used but otherwise unspecified
come from [<A HREF="/rfcs/rfc2234.html">RFC2234</A>].
In some of the definitions, there will be nonterminals whose names
start with "obs-". These "obs-" elements refer to tokens defined in
the obsolete syntax in section 4. In all cases, these productions
are to be ignored for the purposes of generating legal Internet
messages and MUST NOT be used as part of such a message. However,
when interpreting messages, these tokens MUST be honored as part of
the legal syntax. In this sense, section 3 defines a grammar for
generation of messages, with "obs-" elements that are to be ignored,
while section 4 adds grammar for interpretation of messages.
3.2. Lexical Tokens
The following rules are used to define an underlying lexical
analyzer, which feeds tokens to the higher-level parsers. This
section defines the tokens used in structured header field bodies.
Note: Readers of this standard need to pay special attention to how
these lexical tokens are used in both the lower-level and
higher-level syntax later in the document. Particularly, the white
space tokens and the comment tokens defined in section 3.2.3 get used
in the lower-level tokens defined here, and those lower-level tokens
are in turn used as parts of the higher-level tokens defined later.
Therefore, the white space and comments may be allowed in the
higher-level tokens even though they may not explicitly appear in a
particular definition.
3.2.1. Primitive Tokens
The following are primitive tokens referred to elsewhere in this
standard, but not otherwise defined in [<A HREF="/rfcs/rfc2234.html">RFC2234</A>]. Some of them will
not appear anywhere else in the syntax, but they are convenient to
refer to in other parts of this document.
Note: The "specials" below are just such an example. Though the
specials token does not appear anywhere else in this standard, it is
useful for implementers who use tools that lexically analyze
messages. Each of the characters in specials can be used to indicate
a tokenization point in lexical analysis.
NO-WS-CTL = %d1-8 / ; US-ASCII control characters
%d11 / ; that do not include the
%d12 / ; carriage return, line feed,
%d14-31 / ; and white space characters
%d127
text = %d1-9 / ; Characters excluding CR and LF
%d11 /
%d12 /
%d14-127 /
obs-text
specials = "(" / ")" / ; Special characters used in
"<" / ">" / ; other parts of the syntax
"[" / "]" /
":" / ";" /
"@" / "\" /
"," / "." /
DQUOTE
No special semantics are attached to these tokens. They are simply
single characters.
3.2.2. Quoted characters
Some characters are reserved for special interpretation, such as
delimiting lexical tokens. To permit use of these characters as
uninterpreted data, a quoting mechanism is provided.
quoted-pair = ("\" text) / obs-qp
Where any quoted-pair appears, it is to be interpreted as the text
character alone. That is to say, the "\" character that appears as
part of a quoted-pair is semantically "invisible".
Note: The "\" character may appear in a message where it is not part
of a quoted-pair. A "\" character that does not appear in a
quoted-pair is not semantically invisible. The only places in this
standard where quoted-pair currently appears are ccontent, qcontent,
dcontent, no-fold-quote, and no-fold-literal.
3.2.3. Folding white space and comments
White space characters, including white space used in folding
(described in section 2.2.3), may appear between many elements in
header field bodies. Also, strings of characters that are treated as
comments may be included in structured field bodies as characters
enclosed in parentheses. The following defines the folding white
space (FWS) and comment constructs.
Strings of characters enclosed in parentheses are considered comments
so long as they do not appear within a "quoted-string", as defined in
section 3.2.5. Comments may nest.
There are several places in this standard where comments and FWS may
be freely inserted. To accommodate that syntax, an additional token
for "CFWS" is defined for places where comments and/or FWS can occur.
However, where CFWS occurs in this standard, it MUST NOT be inserted
in such a way that any line of a folded header field is made up
entirely of WSP characters and nothing else.
FWS = ([*WSP CRLF] 1*WSP) / ; Folding white space
obs-FWS
ctext = NO-WS-CTL / ; Non white space controls
%d33-39 / ; The rest of the US-ASCII
%d42-91 / ; characters not including "(",
%d93-126 ; ")", or "\"
ccontent = ctext / quoted-pair / comment
comment = "(" *([FWS] ccontent) [FWS] ")"
CFWS = *([FWS] comment) (([FWS] comment) / FWS)
Throughout this standard, where FWS (the folding white space token)
appears, it indicates a place where header folding, as discussed in
section 2.2.3, may take place. Wherever header folding appears in a
message (that is, a header field body containing a CRLF followed by
any WSP), header unfolding (removal of the CRLF) is performed before
any further lexical analysis is performed on that header field
according to this standard. That is to say, any CRLF that appears in
FWS is semantically "invisible."
A comment is normally used in a structured field body to provide some
human readable informational text. Since a comment is allowed to
contain FWS, folding is permitted within the comment. Also note that
since quoted-pair is allowed in a comment, the parentheses and
backslash characters may appear in a comment so long as they appear
as a quoted-pair. Semantically, the enclosing parentheses are not
part of the comment; the comment is what is contained between the two
parentheses. As stated earlier, the "\" in any quoted-pair and the
CRLF in any FWS that appears within the comment are semantically
"invisible" and therefore not part of the comment either.
Runs of FWS, comment or CFWS that occur between lexical tokens in a
structured field header are semantically interpreted as a single
space character.
3.2.4. Atom
Several productions in structured header field bodies are simply
strings of certain basic characters. Such productions are called
atoms.
Some of the structured header field bodies also allow the period
character (".", ASCII value 46) within runs of atext. An additional
"dot-atom" token is defined for those purposes.
atext = ALPHA / DIGIT / ; Any character except controls,
"!" / "#" / ; SP, and specials.
"$" / "%" / ; Used for atoms
"&" / "'" /
"*" / "+" /
"-" / "/" /
"=" / "?" /
"^" / "_" /
"`" / "{" /
"|" / "}" /
"~"
atom = [CFWS] 1*atext [CFWS]
dot-atom = [CFWS] dot-atom-text [CFWS]
dot-atom-text = 1*atext *("." 1*atext)
Both atom and dot-atom are interpreted as a single unit, comprised of
the string of characters that make it up. Semantically, the optional
comments and FWS surrounding the rest of the characters are not part
of the atom; the atom is only the run of atext characters in an atom,
or the atext and "." characters in a dot-atom.
3.2.5. Quoted strings
Strings of characters that include characters other than those
allowed in atoms may be represented in a quoted string format, where
the characters are surrounded by quote (DQUOTE, ASCII value 34)
characters.
qtext = NO-WS-CTL / ; Non white space controls
%d33 / ; The rest of the US-ASCII
%d35-91 / ; characters not including "\"
%d93-126 ; or the quote character
qcontent = qtext / quoted-pair
quoted-string = [CFWS]
DQUOTE *([FWS] qcontent) [FWS] DQUOTE
[CFWS]
A quoted-string is treated as a unit. That is, quoted-string is
identical to atom, semantically. Since a quoted-string is allowed to
contain FWS, folding is permitted. Also note that since quoted-pair
is allowed in a quoted-string, the quote and backslash characters may
appear in a quoted-string so long as they appear as a quoted-pair.
Semantically, neither the optional CFWS outside of the quote
characters nor the quote characters themselves are part of the
quoted-string; the quoted-string is what is contained between the two
quote characters. As stated earlier, the "\" in any quoted-pair and
the CRLF in any FWS/CFWS that appears within the quoted-string are
semantically "invisible" and therefore not part of the quoted-string
either.
3.2.6. Miscellaneous tokens
Three additional tokens are defined, word and phrase for combinations
of atoms and/or quoted-strings, and unstructured for use in
unstructured header fields and in some places within structured
header fields.
word = atom / quoted-string
phrase = 1*word / obs-phrase
utext = NO-WS-CTL / ; Non white space controls
%d33-126 / ; The rest of US-ASCII
obs-utext
unstructured = *([FWS] utext) [FWS]
3.3. Date and Time Specification
Date and time occur in several header fields. This section specifies
the syntax for a full date and time specification. Though folding
white space is permitted throughout the date-time specification, it
is RECOMMENDED that a single space be used in each place that FWS
appears (whether it is required or optional); some older
implementations may not interpret other occurrences of folding white
space correctly.
date-time = [ day-of-week "," ] date FWS time [CFWS]
day-of-week = ([FWS] day-name) / obs-day-of-week
day-name = "Mon" / "Tue" / "Wed" / "Thu" /
"Fri" / "Sat" / "Sun"
date = day month year
year = 4*DIGIT / obs-year
month = (FWS month-name FWS) / obs-month
month-name = "Jan" / "Feb" / "Mar" / "Apr" /
"May" / "Jun" / "Jul" / "Aug" /
"Sep" / "Oct" / "Nov" / "Dec"
day = ([FWS] 1*2DIGIT) / obs-day
time = time-of-day FWS zone
time-of-day = hour ":" minute [ ":" second ]
hour = 2DIGIT / obs-hour
minute = 2DIGIT / obs-minute
second = 2DIGIT / obs-second
zone = (( "+" / "-" ) 4DIGIT) / obs-zone
The day is the numeric day of the month. The year is any numeric
year 1900 or later.
The time-of-day specifies the number of hours, minutes, and
optionally seconds since midnight of the date indicated.
The date and time-of-day SHOULD express local time.
The zone specifies the offset from Coordinated Universal Time (UTC,
formerly referred to as "Greenwich Mean Time") that the date and
time-of-day represent. The "+" or "-" indicates whether the
time-of-day is ahead of (i.e., east of) or behind (i.e., west of)
Universal Time. The first two digits indicate the number of hours
difference from Universal Time, and the last two digits indicate the
number of minutes difference from Universal Time. (Hence, +hhmm
means +(hh * 60 + mm) minutes, and -hhmm means -(hh * 60 + mm)
minutes). The form "+0000" SHOULD be used to indicate a time zone at
Universal Time. Though "-0000" also indicates Universal Time, it is
used to indicate that the time was generated on a system that may be
in a local time zone other than Universal Time and therefore
indicates that the date-time contains no information about the local
time zone.
A date-time specification MUST be semantically valid. That is, the
day-of-the-week (if included) MUST be the day implied by the date,
the numeric day-of-month MUST be between 1 and the number of days
allowed for the specified month (in the specified year), the
time-of-day MUST be in the range 00:00:00 through 23:59:60 (the
number of seconds allowing for a leap second; see [STD12]), and the
zone MUST be within the range -9959 through +9959.
3.4. Address Specification
Addresses occur in several message header fields to indicate senders
and recipients of messages. An address may either be an individual
mailbox, or a group of mailboxes.
address = mailbox / group
mailbox = name-addr / addr-spec
name-addr = [display-name] angle-addr
angle-addr = [CFWS] "<" addr-spec ">" [CFWS] / obs-angle-addr
group = display-name ":" [mailbox-list / CFWS] ";"
[CFWS]
display-name = phrase
mailbox-list = (mailbox *("," mailbox)) / obs-mbox-list
address-list = (address *("," address)) / obs-addr-list
A mailbox receives mail. It is a conceptual entity which does not
necessarily pertain to file storage. For example, some sites may
choose to print mail on a printer and deliver the output to the
addressee's desk. Normally, a mailbox is comprised of two parts: (1)
an optional display name that indicates the name of the recipient
(which could be a person or a system) that could be displayed to the
user of a mail application, and (2) an addr-spec address enclosed in
angle brackets ("<" and ">"). There is also an alternate simple form
of a mailbox where the addr-spec address appears alone, without the
recipient's name or the angle brackets. The Internet addr-spec
address is described in section 3.4.1.
Note: Some legacy implementations used the simple form where the
addr-spec appears without the angle brackets, but included the name
of the recipient in parentheses as a comment following the addr-spec.
Since the meaning of the information in a comment is unspecified,
implementations SHOULD use the full name-addr form of the mailbox,
instead of the legacy form, to specify the display name associated
with a mailbox. Also, because some legacy implementations interpret
the comment, comments generally SHOULD NOT be used in address fields
to avoid confusing such implementations.
When it is desirable to treat several mailboxes as a single unit
(i.e., in a distribution list), the group construct can be used. The
group construct allows the sender to indicate a named group of
recipients. This is done by giving a display name for the group,
followed by a colon, followed by a comma separated list of any number
of mailboxes (including zero and one), and ending with a semicolon.
Because the list of mailboxes can be empty, using the group construct
is also a simple way to communicate to recipients that the message
was sent to one or more named sets of recipients, without actually
providing the individual mailbox address for each of those
recipients.
3.4.1. Addr-spec specification
An addr-spec is a specific Internet identifier that contains a
locally interpreted string followed by the at-sign character ("@",
ASCII value 64) followed by an Internet domain. The locally
interpreted string is either a quoted-string or a dot-atom. If the
string can be represented as a dot-atom (that is, it contains no
characters other than atext characters or "." surrounded by atext
characters), then the dot-atom form SHOULD be used and the
quoted-string form SHOULD NOT be used. Comments and folding white
space SHOULD NOT be used around the "@" in the addr-spec.
addr-spec = local-part "@" domain
local-part = dot-atom / quoted-string / obs-local-part
domain = dot-atom / domain-literal / obs-domain
domain-literal = [CFWS] "[" *([FWS] dcontent) [FWS] "]" [CFWS]
dcontent = dtext / quoted-pair
dtext = NO-WS-CTL / ; Non white space controls
%d33-90 / ; The rest of the US-ASCII
%d94-126 ; characters not including "[",
; "]", or "\"
The domain portion identifies the point to which the mail is
delivered. In the dot-atom form, this is interpreted as an Internet
domain name (either a host name or a mail exchanger name) as
described in [STD3, STD13, STD14]. In the domain-literal form, the
domain is interpreted as the literal Internet address of the
particular host. In both cases, how addressing is used and how
messages are transported to a particular host is covered in the mail
transport document [<A HREF="/rfcs/rfc2821.html">RFC2821</A>]. These mechanisms are outside of the
scope of this document.
The local-part portion is a domain dependent string. In addresses,
it is simply interpreted on the particular host as a name of a
particular mailbox.
3.5 Overall message syntax
A message consists of header fields, optionally followed by a message
body. Lines in a message MUST be a maximum of 998 characters
excluding the CRLF, but it is RECOMMENDED that lines be limited to 78
characters excluding the CRLF. (See section 2.1.1 for explanation.)
In a message body, though all of the characters listed in the text
rule MAY be used, the use of US-ASCII control characters (values 1
through 8, 11, 12, and 14 through 31) is discouraged since their
interpretation by receivers for display is not guaranteed.
message = (fields / obs-fields)
[CRLF body]
body = *(*998text CRLF) *998text
The header fields carry most of the semantic information and are
defined in section 3.6. The body is simply a series of lines of text
which are uninterpreted for the purposes of this standard.
3.6. Field definitions
The header fields of a message are defined here. All header fields
have the same general syntactic structure: A field name, followed by
a colon, followed by the field body. The specific syntax for each
header field is defined in the subsequent sections.
Note: In the ABNF syntax for each field in subsequent sections, each
field name is followed by the required colon. However, for brevity
sometimes the colon is not referred to in the textual description of
the syntax. It is, nonetheless, required.
It is important to note that the header fields are not guaranteed to
be in a particular order. They may appear in any order, and they
have been known to be reordered occasionally when transported over
the Internet. However, for the purposes of this standard, header
fields SHOULD NOT be reordered when a message is transported or
transformed. More importantly, the trace header fields and resent
header fields MUST NOT be reordered, and SHOULD be kept in blocks
prepended to the message. See sections 3.6.6 and 3.6.7 for more
information.
The only required header fields are the origination date field and
the originator address field(s). All other header fields are
syntactically optional. More information is contained in the table
following this definition.
fields = *(trace
*(resent-date /
resent-from /
resent-sender /
resent-to /
resent-cc /
resent-bcc /
resent-msg-id))
*(orig-date /
from /
sender /
reply-to /
to /
cc /
bcc /
message-id /
in-reply-to /
references /
subject /
comments /
keywords /
optional-field)
The following table indicates limits on the number of times each
field may occur in a message header as well as any special
limitations on the use of those fields. An asterisk next to a value
in the minimum or maximum column indicates that a special restriction
appears in the Notes column.
Field Min number Max number Notes
trace 0 unlimited Block prepended - see
3.6.7
resent-date 0* unlimited* One per block, required
if other resent fields
present - see 3.6.6
resent-from 0 unlimited* One per block - see
3.6.6
resent-sender 0* unlimited* One per block, MUST
occur with multi-address
resent-from - see 3.6.6
resent-to 0 unlimited* One per block - see
3.6.6
resent-cc 0 unlimited* One per block - see
3.6.6
resent-bcc 0 unlimited* One per block - see
3.6.6
resent-msg-id 0 unlimited* One per block - see
3.6.6
orig-date 1 1
from 1 1 See sender and 3.6.2
sender 0* 1 MUST occur with multi-
address from - see 3.6.2
reply-to 0 1
to 0 1
cc 0 1
bcc 0 1
message-id 0* 1 SHOULD be present - see
3.6.4
in-reply-to 0* 1 SHOULD occur in some
replies - see 3.6.4
references 0* 1 SHOULD occur in some
replies - see 3.6.4
subject 0 1
comments 0 unlimited
keywords 0 unlimited
optional-field 0 unlimited
The exact interpretation of each field is described in subsequent
sections.
3.6.1. The origination date field
The origination date field consists of the field name "Date" followed
by a date-time specification.
orig-date = "Date:" date-time CRLF
The origination date specifies the date and time at which the creator
of the message indicated that the message was complete and ready to
enter the mail delivery system. For instance, this might be the time
that a user pushes the "send" or "submit" button in an application
program. In any case, it is specifically not intended to convey the
time that the message is actually transported, but rather the time at
which the human or other creator of the message has put the message
into its final form, ready for transport. (For example, a portable
computer user who is not connected to a network might queue a message
for delivery. The origination date is intended to contain the date
and time that the user queued the message, not the time when the user
connected to the network to send the message.)
3.6.2. Originator fields
The originator fields of a message consist of the from field, the
sender field (when applicable), and optionally the reply-to field.
The from field consists of the field name "From" and a
comma-separated list of one or more mailbox specifications. If the
from field contains more than one mailbox specification in the
mailbox-list, then the sender field, containing the field name
"Sender" and a single mailbox specification, MUST appear in the
message. In either case, an optional reply-to field MAY also be
included, which contains the field name "Reply-To" and a
comma-separated list of one or more addresses.
from = "From:" mailbox-list CRLF
sender = "Sender:" mailbox CRLF
reply-to = "Reply-To:" address-list CRLF