7
Network Working Group P. Resnick, Editor
8
Request for Comments: 2822 QUALCOMM Incorporated
9
Obsoletes: 822 April 2001
10
Category: Standards Track
13
Internet Message Format
17
This document specifies an Internet standards track protocol for the
18
Internet community, and requests discussion and suggestions for
19
improvements. Please refer to the current edition of the "Internet
20
Official Protocol Standards" (STD 1) for the standardization state
21
and status of this protocol. Distribution of this memo is unlimited.
25
Copyright (C) The Internet Society (2001). All Rights Reserved.
29
This standard specifies a syntax for text messages that are sent
30
between computer users, within the framework of "electronic mail"
31
messages. This standard supersedes the one specified in Request For
32
Comments (RFC) 822, "Standard for the Format of ARPA Internet Text
33
Messages", updating it to reflect current practice and incorporating
34
incremental changes that were specified in other RFCs.
38
1. Introduction ............................................... 3
39
1.1. Scope .................................................... 3
40
1.2. Notational conventions ................................... 4
41
1.2.1. Requirements notation .................................. 4
42
1.2.2. Syntactic notation ..................................... 4
43
1.3. Structure of this document ............................... 4
44
2. Lexical Analysis of Messages ............................... 5
45
2.1. General Description ...................................... 5
46
2.1.1. Line Length Limits ..................................... 6
47
2.2. Header Fields ............................................ 7
48
2.2.1. Unstructured Header Field Bodies ....................... 7
49
2.2.2. Structured Header Field Bodies ......................... 7
50
2.2.3. Long Header Fields ..................................... 7
51
2.3. Body ..................................................... 8
52
3. Syntax ..................................................... 9
53
3.1. Introduction ............................................. 9
54
3.2. Lexical Tokens ........................................... 9
58
Resnick Standards Track [Page 1]
60
RFC 2822 Internet Message Format April 2001
63
3.2.1. Primitive Tokens ....................................... 9
64
3.2.2. Quoted characters ......................................10
65
3.2.3. Folding white space and comments .......................11
66
3.2.4. Atom ...................................................12
67
3.2.5. Quoted strings .........................................13
68
3.2.6. Miscellaneous tokens ...................................13
69
3.3. Date and Time Specification ..............................14
70
3.4. Address Specification ....................................15
71
3.4.1. Addr-spec specification ................................16
72
3.5 Overall message syntax ....................................17
73
3.6. Field definitions ........................................18
74
3.6.1. The origination date field .............................20
75
3.6.2. Originator fields ......................................21
76
3.6.3. Destination address fields .............................22
77
3.6.4. Identification fields ..................................23
78
3.6.5. Informational fields ...................................26
79
3.6.6. Resent fields ..........................................26
80
3.6.7. Trace fields ...........................................28
81
3.6.8. Optional fields ........................................29
82
4. Obsolete Syntax ............................................29
83
4.1. Miscellaneous obsolete tokens ............................30
84
4.2. Obsolete folding white space .............................31
85
4.3. Obsolete Date and Time ...................................31
86
4.4. Obsolete Addressing ......................................33
87
4.5. Obsolete header fields ...................................33
88
4.5.1. Obsolete origination date field ........................34
89
4.5.2. Obsolete originator fields .............................34
90
4.5.3. Obsolete destination address fields ....................34
91
4.5.4. Obsolete identification fields .........................35
92
4.5.5. Obsolete informational fields ..........................35
93
4.5.6. Obsolete resent fields .................................35
94
4.5.7. Obsolete trace fields ..................................36
95
4.5.8. Obsolete optional fields ...............................36
96
5. Security Considerations ....................................36
97
6. Bibliography ...............................................37
98
7. Editor's Address ...........................................38
99
8. Acknowledgements ...........................................39
100
Appendix A. Example messages ..................................41
101
A.1. Addressing examples ......................................41
102
A.1.1. A message from one person to another with simple
103
addressing .............................................41
104
A.1.2. Different types of mailboxes ...........................42
105
A.1.3. Group addresses ........................................43
106
A.2. Reply messages ...........................................43
107
A.3. Resent messages ..........................................44
108
A.4. Messages with trace fields ...............................46
109
A.5. White space, comments, and other oddities ................47
110
A.6. Obsoleted forms ..........................................47
114
Resnick Standards Track [Page 2]
116
RFC 2822 Internet Message Format April 2001
119
A.6.1. Obsolete addressing ....................................48
120
A.6.2. Obsolete dates .........................................48
121
A.6.3. Obsolete white space and comments ......................48
122
Appendix B. Differences from earlier standards ................49
123
Appendix C. Notices ...........................................50
124
Full Copyright Statement ......................................51
130
This standard specifies a syntax for text messages that are sent
131
between computer users, within the framework of "electronic mail"
132
messages. This standard supersedes the one specified in Request For
133
Comments (RFC) 822, "Standard for the Format of ARPA Internet Text
134
Messages" [RFC822], updating it to reflect current practice and
135
incorporating incremental changes that were specified in other RFCs
138
This standard specifies a syntax only for text messages. In
139
particular, it makes no provision for the transmission of images,
140
audio, or other sorts of structured data in electronic mail messages.
141
There are several extensions published, such as the MIME document
142
series [RFC2045, RFC2046, RFC2049], which describe mechanisms for the
143
transmission of such data through electronic mail, either by
144
extending the syntax provided here or by structuring such messages to
145
conform to this syntax. Those mechanisms are outside of the scope of
148
In the context of electronic mail, messages are viewed as having an
149
envelope and contents. The envelope contains whatever information is
150
needed to accomplish transmission and delivery. (See [RFC2821] for a
151
discussion of the envelope.) The contents comprise the object to be
152
delivered to the recipient. This standard applies only to the format
153
and some of the semantics of message contents. It contains no
154
specification of the information in the envelope.
156
However, some message systems may use information from the contents
157
to create the envelope. It is intended that this standard facilitate
158
the acquisition of such information by programs.
160
This specification is intended as a definition of what message
161
content format is to be passed between systems. Though some message
162
systems locally store messages in this format (which eliminates the
163
need for translation between formats) and others use formats that
164
differ from the one specified in this standard, local storage is
165
outside of the scope of this standard.
170
Resnick Standards Track [Page 3]
172
RFC 2822 Internet Message Format April 2001
175
Note: This standard is not intended to dictate the internal formats
176
used by sites, the specific message system features that they are
177
expected to support, or any of the characteristics of user interface
178
programs that create or read messages. In addition, this standard
179
does not specify an encoding of the characters for either transport
180
or storage; that is, it does not specify the number of bits used or
181
how those bits are specifically transferred over the wire or stored
184
1.2. Notational conventions
186
1.2.1. Requirements notation
188
This document occasionally uses terms that appear in capital letters.
189
When the terms "MUST", "SHOULD", "RECOMMENDED", "MUST NOT", "SHOULD
190
NOT", and "MAY" appear capitalized, they are being used to indicate
191
particular requirements of this specification. A discussion of the
192
meanings of these terms appears in [RFC2119].
194
1.2.2. Syntactic notation
196
This standard uses the Augmented Backus-Naur Form (ABNF) notation
197
specified in [RFC2234] for the formal definitions of the syntax of
198
messages. Characters will be specified either by a decimal value
199
(e.g., the value %d65 for uppercase A and %d97 for lowercase A) or by
200
a case-insensitive literal value enclosed in quotation marks (e.g.,
201
"A" for either uppercase or lowercase A). See [RFC2234] for the full
202
description of the notation.
204
1.3. Structure of this document
206
This document is divided into several sections.
208
This section, section 1, is a short introduction to the document.
210
Section 2 lays out the general description of a message and its
211
constituent parts. This is an overview to help the reader understand
212
some of the general principles used in the later portions of this
213
document. Any examples in this section MUST NOT be taken as
214
specification of the formal syntax of any part of a message.
216
Section 3 specifies formal ABNF rules for the structure of each part
217
of a message (the syntax) and describes the relationship between
218
those parts and their meaning in the context of a message (the
219
semantics). That is, it describes the actual rules for the structure
220
of each part of a message (the syntax) as well as a description of
221
the parts and instructions on how they ought to be interpreted (the
222
semantics). This includes analysis of the syntax and semantics of
226
Resnick Standards Track [Page 4]
228
RFC 2822 Internet Message Format April 2001
231
subparts of messages that have specific structure. The syntax
232
included in section 3 represents messages as they MUST be created.
233
There are also notes in section 3 to indicate if any of the options
234
specified in the syntax SHOULD be used over any of the others.
236
Both sections 2 and 3 describe messages that are legal to generate
237
for purposes of this standard.
239
Section 4 of this document specifies an "obsolete" syntax. There are
240
references in section 3 to these obsolete syntactic elements. The
241
rules of the obsolete syntax are elements that have appeared in
242
earlier revisions of this standard or have previously been widely
243
used in Internet messages. As such, these elements MUST be
244
interpreted by parsers of messages in order to be conformant to this
245
standard. However, since items in this syntax have been determined
246
to be non-interoperable or to cause significant problems for
247
recipients of messages, they MUST NOT be generated by creators of
250
Section 5 details security considerations to take into account when
251
implementing this standard.
253
Section 6 is a bibliography of references in this document.
255
Section 7 contains the editor's address.
257
Section 8 contains acknowledgements.
259
Appendix A lists examples of different sorts of messages. These
260
examples are not exhaustive of the types of messages that appear on
261
the Internet, but give a broad overview of certain syntactic forms.
263
Appendix B lists the differences between this standard and earlier
264
standards for Internet messages.
266
Appendix C has copyright and intellectual property notices.
268
2. Lexical Analysis of Messages
270
2.1. General Description
272
At the most basic level, a message is a series of characters. A
273
message that is conformant with this standard is comprised of
274
characters with values in the range 1 through 127 and interpreted as
275
US-ASCII characters [ASCII]. For brevity, this document sometimes
276
refers to this range of characters as simply "US-ASCII characters".
282
Resnick Standards Track [Page 5]
284
RFC 2822 Internet Message Format April 2001
287
Note: This standard specifies that messages are made up of characters
288
in the US-ASCII range of 1 through 127. There are other documents,
289
specifically the MIME document series [RFC2045, RFC2046, RFC2047,
290
RFC2048, RFC2049], that extend this standard to allow for values
291
outside of that range. Discussion of those mechanisms is not within
292
the scope of this standard.
294
Messages are divided into lines of characters. A line is a series of
295
characters that is delimited with the two characters carriage-return
296
and line-feed; that is, the carriage return (CR) character (ASCII
297
value 13) followed immediately by the line feed (LF) character (ASCII
298
value 10). (The carriage-return/line-feed pair is usually written in
299
this document as "CRLF".)
301
A message consists of header fields (collectively called "the header
302
of the message") followed, optionally, by a body. The header is a
303
sequence of lines of characters with special syntax as defined in
304
this standard. The body is simply a sequence of characters that
305
follows the header and is separated from the header by an empty line
306
(i.e., a line with nothing preceding the CRLF).
308
2.1.1. Line Length Limits
310
There are two limits that this standard places on the number of
311
characters in a line. Each line of characters MUST be no more than
312
998 characters, and SHOULD be no more than 78 characters, excluding
315
The 998 character limit is due to limitations in many implementations
316
which send, receive, or store Internet Message Format messages that
317
simply cannot handle more than 998 characters on a line. Receiving
318
implementations would do well to handle an arbitrarily large number
319
of characters in a line for robustness sake. However, there are so
320
many implementations which (in compliance with the transport
321
requirements of [RFC2821]) do not accept messages containing more
322
than 1000 character including the CR and LF per line, it is important
323
for implementations not to create such messages.
325
The more conservative 78 character recommendation is to accommodate
326
the many implementations of user interfaces that display these
327
messages which may truncate, or disastrously wrap, the display of
328
more than 78 characters per line, in spite of the fact that such
329
implementations are non-conformant to the intent of this
330
specification (and that of [RFC2821] if they actually cause
331
information to be lost). Again, even though this limitation is put on
332
messages, it is encumbant upon implementations which display messages
338
Resnick Standards Track [Page 6]
340
RFC 2822 Internet Message Format April 2001
343
to handle an arbitrarily large number of characters in a line
344
(certainly at least up to the 998 character limit) for the sake of
349
Header fields are lines composed of a field name, followed by a colon
350
(":"), followed by a field body, and terminated by CRLF. A field
351
name MUST be composed of printable US-ASCII characters (i.e.,
352
characters that have values between 33 and 126, inclusive), except
353
colon. A field body may be composed of any US-ASCII characters,
354
except for CR and LF. However, a field body may contain CRLF when
355
used in header "folding" and "unfolding" as described in section
356
2.2.3. All field bodies MUST conform to the syntax described in
357
sections 3 and 4 of this standard.
359
2.2.1. Unstructured Header Field Bodies
361
Some field bodies in this standard are defined simply as
362
"unstructured" (which is specified below as any US-ASCII characters,
363
except for CR and LF) with no further restrictions. These are
364
referred to as unstructured field bodies. Semantically, unstructured
365
field bodies are simply to be treated as a single line of characters
366
with no further processing (except for header "folding" and
367
"unfolding" as described in section 2.2.3).
369
2.2.2. Structured Header Field Bodies
371
Some field bodies in this standard have specific syntactical
372
structure more restrictive than the unstructured field bodies
373
described above. These are referred to as "structured" field bodies.
374
Structured field bodies are sequences of specific lexical tokens as
375
described in sections 3 and 4 of this standard. Many of these tokens
376
are allowed (according to their syntax) to be introduced or end with
377
comments (as described in section 3.2.3) as well as the space (SP,
378
ASCII value 32) and horizontal tab (HTAB, ASCII value 9) characters
379
(together known as the white space characters, WSP), and those WSP
380
characters are subject to header "folding" and "unfolding" as
381
described in section 2.2.3. Semantic analysis of structured field
382
bodies is given along with their syntax.
384
2.2.3. Long Header Fields
386
Each header field is logically a single line of characters comprising
387
the field name, the colon, and the field body. For convenience
388
however, and to deal with the 998/78 character limitations per line,
389
the field body portion of a header field can be split into a multiple
390
line representation; this is called "folding". The general rule is
394
Resnick Standards Track [Page 7]
396
RFC 2822 Internet Message Format April 2001
399
that wherever this standard allows for folding white space (not
400
simply WSP characters), a CRLF may be inserted before any WSP. For
401
example, the header field:
403
Subject: This is a test
405
can be represented as:
410
Note: Though structured field bodies are defined in such a way that
411
folding can take place between many of the lexical tokens (and even
412
within some of the lexical tokens), folding SHOULD be limited to
413
placing the CRLF at higher-level syntactic breaks. For instance, if
414
a field body is defined as comma-separated values, it is recommended
415
that folding occur after the comma separating the structured items in
416
preference to other places where the field could be folded, even if
417
it is allowed elsewhere.
419
The process of moving from this folded multiple-line representation
420
of a header field to its single line representation is called
421
"unfolding". Unfolding is accomplished by simply removing any CRLF
422
that is immediately followed by WSP. Each header field should be
423
treated in its unfolded form for further syntactic and semantic
428
The body of a message is simply lines of US-ASCII characters. The
429
only two limitations on the body are as follows:
431
- CR and LF MUST only occur together as CRLF; they MUST NOT appear
432
independently in the body.
434
- Lines of characters in the body MUST be limited to 998 characters,
435
and SHOULD be limited to 78 characters, excluding the CRLF.
437
Note: As was stated earlier, there are other standards documents,
438
specifically the MIME documents [RFC2045, RFC2046, RFC2048, RFC2049]
439
that extend this standard to allow for different sorts of message
440
bodies. Again, these mechanisms are beyond the scope of this
450
Resnick Standards Track [Page 8]
452
RFC 2822 Internet Message Format April 2001
459
The syntax as given in this section defines the legal syntax of
460
Internet messages. Messages that are conformant to this standard
461
MUST conform to the syntax in this section. If there are options in
462
this section where one option SHOULD be generated, that is indicated
463
either in the prose or in a comment next to the syntax.
465
For the defined expressions, a short description of the syntax and
466
use is given, followed by the syntax in ABNF, followed by a semantic
467
analysis. Primitive tokens that are used but otherwise unspecified
470
In some of the definitions, there will be nonterminals whose names
471
start with "obs-". These "obs-" elements refer to tokens defined in
472
the obsolete syntax in section 4. In all cases, these productions
473
are to be ignored for the purposes of generating legal Internet
474
messages and MUST NOT be used as part of such a message. However,
475
when interpreting messages, these tokens MUST be honored as part of
476
the legal syntax. In this sense, section 3 defines a grammar for
477
generation of messages, with "obs-" elements that are to be ignored,
478
while section 4 adds grammar for interpretation of messages.
482
The following rules are used to define an underlying lexical
483
analyzer, which feeds tokens to the higher-level parsers. This
484
section defines the tokens used in structured header field bodies.
486
Note: Readers of this standard need to pay special attention to how
487
these lexical tokens are used in both the lower-level and
488
higher-level syntax later in the document. Particularly, the white
489
space tokens and the comment tokens defined in section 3.2.3 get used
490
in the lower-level tokens defined here, and those lower-level tokens
491
are in turn used as parts of the higher-level tokens defined later.
492
Therefore, the white space and comments may be allowed in the
493
higher-level tokens even though they may not explicitly appear in a
494
particular definition.
496
3.2.1. Primitive Tokens
498
The following are primitive tokens referred to elsewhere in this
499
standard, but not otherwise defined in [RFC2234]. Some of them will
500
not appear anywhere else in the syntax, but they are convenient to
501
refer to in other parts of this document.
506
Resnick Standards Track [Page 9]
508
RFC 2822 Internet Message Format April 2001
511
Note: The "specials" below are just such an example. Though the
512
specials token does not appear anywhere else in this standard, it is
513
useful for implementers who use tools that lexically analyze
514
messages. Each of the characters in specials can be used to indicate
515
a tokenization point in lexical analysis.
517
NO-WS-CTL = %d1-8 / ; US-ASCII control characters
518
%d11 / ; that do not include the
519
%d12 / ; carriage return, line feed,
520
%d14-31 / ; and white space characters
523
text = %d1-9 / ; Characters excluding CR and LF
529
specials = "(" / ")" / ; Special characters used in
530
"<" / ">" / ; other parts of the syntax
537
No special semantics are attached to these tokens. They are simply
540
3.2.2. Quoted characters
542
Some characters are reserved for special interpretation, such as
543
delimiting lexical tokens. To permit use of these characters as
544
uninterpreted data, a quoting mechanism is provided.
546
quoted-pair = ("\" text) / obs-qp
548
Where any quoted-pair appears, it is to be interpreted as the text
549
character alone. That is to say, the "\" character that appears as
550
part of a quoted-pair is semantically "invisible".
552
Note: The "\" character may appear in a message where it is not part
553
of a quoted-pair. A "\" character that does not appear in a
554
quoted-pair is not semantically invisible. The only places in this
555
standard where quoted-pair currently appears are ccontent, qcontent,
556
dcontent, no-fold-quote, and no-fold-literal.
562
Resnick Standards Track [Page 10]
564
RFC 2822 Internet Message Format April 2001
567
3.2.3. Folding white space and comments
569
White space characters, including white space used in folding
570
(described in section 2.2.3), may appear between many elements in
571
header field bodies. Also, strings of characters that are treated as
572
comments may be included in structured field bodies as characters
573
enclosed in parentheses. The following defines the folding white
574
space (FWS) and comment constructs.
576
Strings of characters enclosed in parentheses are considered comments
577
so long as they do not appear within a "quoted-string", as defined in
578
section 3.2.5. Comments may nest.
580
There are several places in this standard where comments and FWS may
581
be freely inserted. To accommodate that syntax, an additional token
582
for "CFWS" is defined for places where comments and/or FWS can occur.
583
However, where CFWS occurs in this standard, it MUST NOT be inserted
584
in such a way that any line of a folded header field is made up
585
entirely of WSP characters and nothing else.
587
FWS = ([*WSP CRLF] 1*WSP) / ; Folding white space
590
ctext = NO-WS-CTL / ; Non white space controls
592
%d33-39 / ; The rest of the US-ASCII
593
%d42-91 / ; characters not including "(",
594
%d93-126 ; ")", or "\"
596
ccontent = ctext / quoted-pair / comment
598
comment = "(" *([FWS] ccontent) [FWS] ")"
600
CFWS = *([FWS] comment) (([FWS] comment) / FWS)
602
Throughout this standard, where FWS (the folding white space token)
603
appears, it indicates a place where header folding, as discussed in
604
section 2.2.3, may take place. Wherever header folding appears in a
605
message (that is, a header field body containing a CRLF followed by
606
any WSP), header unfolding (removal of the CRLF) is performed before
607
any further lexical analysis is performed on that header field
608
according to this standard. That is to say, any CRLF that appears in
609
FWS is semantically "invisible."
611
A comment is normally used in a structured field body to provide some
612
human readable informational text. Since a comment is allowed to
613
contain FWS, folding is permitted within the comment. Also note that
614
since quoted-pair is allowed in a comment, the parentheses and
618
Resnick Standards Track [Page 11]
620
RFC 2822 Internet Message Format April 2001
623
backslash characters may appear in a comment so long as they appear
624
as a quoted-pair. Semantically, the enclosing parentheses are not
625
part of the comment; the comment is what is contained between the two
626
parentheses. As stated earlier, the "\" in any quoted-pair and the
627
CRLF in any FWS that appears within the comment are semantically
628
"invisible" and therefore not part of the comment either.
630
Runs of FWS, comment or CFWS that occur between lexical tokens in a
631
structured field header are semantically interpreted as a single
636
Several productions in structured header field bodies are simply
637
strings of certain basic characters. Such productions are called
640
Some of the structured header field bodies also allow the period
641
character (".", ASCII value 46) within runs of atext. An additional
642
"dot-atom" token is defined for those purposes.
644
atext = ALPHA / DIGIT / ; Any character except controls,
645
"!" / "#" / ; SP, and specials.
646
"$" / "%" / ; Used for atoms
656
atom = [CFWS] 1*atext [CFWS]
658
dot-atom = [CFWS] dot-atom-text [CFWS]
660
dot-atom-text = 1*atext *("." 1*atext)
662
Both atom and dot-atom are interpreted as a single unit, comprised of
663
the string of characters that make it up. Semantically, the optional
664
comments and FWS surrounding the rest of the characters are not part
665
of the atom; the atom is only the run of atext characters in an atom,
666
or the atext and "." characters in a dot-atom.
674
Resnick Standards Track [Page 12]
676
RFC 2822 Internet Message Format April 2001
679
3.2.5. Quoted strings
681
Strings of characters that include characters other than those
682
allowed in atoms may be represented in a quoted string format, where
683
the characters are surrounded by quote (DQUOTE, ASCII value 34)
686
qtext = NO-WS-CTL / ; Non white space controls
688
%d33 / ; The rest of the US-ASCII
689
%d35-91 / ; characters not including "\"
690
%d93-126 ; or the quote character
692
qcontent = qtext / quoted-pair
694
quoted-string = [CFWS]
695
DQUOTE *([FWS] qcontent) [FWS] DQUOTE
698
A quoted-string is treated as a unit. That is, quoted-string is
699
identical to atom, semantically. Since a quoted-string is allowed to
700
contain FWS, folding is permitted. Also note that since quoted-pair
701
is allowed in a quoted-string, the quote and backslash characters may
702
appear in a quoted-string so long as they appear as a quoted-pair.
704
Semantically, neither the optional CFWS outside of the quote
705
characters nor the quote characters themselves are part of the
706
quoted-string; the quoted-string is what is contained between the two
707
quote characters. As stated earlier, the "\" in any quoted-pair and
708
the CRLF in any FWS/CFWS that appears within the quoted-string are
709
semantically "invisible" and therefore not part of the quoted-string
712
3.2.6. Miscellaneous tokens
714
Three additional tokens are defined, word and phrase for combinations
715
of atoms and/or quoted-strings, and unstructured for use in
716
unstructured header fields and in some places within structured
719
word = atom / quoted-string
721
phrase = 1*word / obs-phrase
730
Resnick Standards Track [Page 13]
732
RFC 2822 Internet Message Format April 2001
735
utext = NO-WS-CTL / ; Non white space controls
736
%d33-126 / ; The rest of US-ASCII
739
unstructured = *([FWS] utext) [FWS]
741
3.3. Date and Time Specification
743
Date and time occur in several header fields. This section specifies
744
the syntax for a full date and time specification. Though folding
745
white space is permitted throughout the date-time specification, it
746
is RECOMMENDED that a single space be used in each place that FWS
747
appears (whether it is required or optional); some older
748
implementations may not interpret other occurrences of folding white
751
date-time = [ day-of-week "," ] date FWS time [CFWS]
753
day-of-week = ([FWS] day-name) / obs-day-of-week
755
day-name = "Mon" / "Tue" / "Wed" / "Thu" /
756
"Fri" / "Sat" / "Sun"
758
date = day month year
760
year = 4*DIGIT / obs-year
762
month = (FWS month-name FWS) / obs-month
764
month-name = "Jan" / "Feb" / "Mar" / "Apr" /
765
"May" / "Jun" / "Jul" / "Aug" /
766
"Sep" / "Oct" / "Nov" / "Dec"
768
day = ([FWS] 1*2DIGIT) / obs-day
770
time = time-of-day FWS zone
772
time-of-day = hour ":" minute [ ":" second ]
774
hour = 2DIGIT / obs-hour
776
minute = 2DIGIT / obs-minute
778
second = 2DIGIT / obs-second
780
zone = (( "+" / "-" ) 4DIGIT) / obs-zone
786
Resnick Standards Track [Page 14]
788
RFC 2822 Internet Message Format April 2001
791
The day is the numeric day of the month. The year is any numeric
794
The time-of-day specifies the number of hours, minutes, and
795
optionally seconds since midnight of the date indicated.
797
The date and time-of-day SHOULD express local time.
799
The zone specifies the offset from Coordinated Universal Time (UTC,
800
formerly referred to as "Greenwich Mean Time") that the date and
801
time-of-day represent. The "+" or "-" indicates whether the
802
time-of-day is ahead of (i.e., east of) or behind (i.e., west of)
803
Universal Time. The first two digits indicate the number of hours
804
difference from Universal Time, and the last two digits indicate the
805
number of minutes difference from Universal Time. (Hence, +hhmm
806
means +(hh * 60 + mm) minutes, and -hhmm means -(hh * 60 + mm)
807
minutes). The form "+0000" SHOULD be used to indicate a time zone at
808
Universal Time. Though "-0000" also indicates Universal Time, it is
809
used to indicate that the time was generated on a system that may be
810
in a local time zone other than Universal Time and therefore
811
indicates that the date-time contains no information about the local
814
A date-time specification MUST be semantically valid. That is, the
815
day-of-the-week (if included) MUST be the day implied by the date,
816
the numeric day-of-month MUST be between 1 and the number of days
817
allowed for the specified month (in the specified year), the
818
time-of-day MUST be in the range 00:00:00 through 23:59:60 (the
819
number of seconds allowing for a leap second; see [STD12]), and the
820
zone MUST be within the range -9959 through +9959.
822
3.4. Address Specification
824
Addresses occur in several message header fields to indicate senders
825
and recipients of messages. An address may either be an individual
826
mailbox, or a group of mailboxes.
828
address = mailbox / group
830
mailbox = name-addr / addr-spec
832
name-addr = [display-name] angle-addr
834
angle-addr = [CFWS] "<" addr-spec ">" [CFWS] / obs-angle-addr
836
group = display-name ":" [mailbox-list / CFWS] ";"
842
Resnick Standards Track [Page 15]
844
RFC 2822 Internet Message Format April 2001
847
display-name = phrase
849
mailbox-list = (mailbox *("," mailbox)) / obs-mbox-list
851
address-list = (address *("," address)) / obs-addr-list
853
A mailbox receives mail. It is a conceptual entity which does not
854
necessarily pertain to file storage. For example, some sites may
855
choose to print mail on a printer and deliver the output to the
856
addressee's desk. Normally, a mailbox is comprised of two parts: (1)
857
an optional display name that indicates the name of the recipient
858
(which could be a person or a system) that could be displayed to the
859
user of a mail application, and (2) an addr-spec address enclosed in
860
angle brackets ("<" and ">"). There is also an alternate simple form
861
of a mailbox where the addr-spec address appears alone, without the
862
recipient's name or the angle brackets. The Internet addr-spec
863
address is described in section 3.4.1.
865
Note: Some legacy implementations used the simple form where the
866
addr-spec appears without the angle brackets, but included the name
867
of the recipient in parentheses as a comment following the addr-spec.
868
Since the meaning of the information in a comment is unspecified,
869
implementations SHOULD use the full name-addr form of the mailbox,
870
instead of the legacy form, to specify the display name associated
871
with a mailbox. Also, because some legacy implementations interpret
872
the comment, comments generally SHOULD NOT be used in address fields
873
to avoid confusing such implementations.
875
When it is desirable to treat several mailboxes as a single unit
876
(i.e., in a distribution list), the group construct can be used. The
877
group construct allows the sender to indicate a named group of
878
recipients. This is done by giving a display name for the group,
879
followed by a colon, followed by a comma separated list of any number
880
of mailboxes (including zero and one), and ending with a semicolon.
881
Because the list of mailboxes can be empty, using the group construct
882
is also a simple way to communicate to recipients that the message
883
was sent to one or more named sets of recipients, without actually
884
providing the individual mailbox address for each of those
887
3.4.1. Addr-spec specification
889
An addr-spec is a specific Internet identifier that contains a
890
locally interpreted string followed by the at-sign character ("@",
891
ASCII value 64) followed by an Internet domain. The locally
892
interpreted string is either a quoted-string or a dot-atom. If the
893
string can be represented as a dot-atom (that is, it contains no
894
characters other than atext characters or "." surrounded by atext
898
Resnick Standards Track [Page 16]
900
RFC 2822 Internet Message Format April 2001
903
characters), then the dot-atom form SHOULD be used and the
904
quoted-string form SHOULD NOT be used. Comments and folding white
905
space SHOULD NOT be used around the "@" in the addr-spec.
907
addr-spec = local-part "@" domain
909
local-part = dot-atom / quoted-string / obs-local-part
911
domain = dot-atom / domain-literal / obs-domain
913
domain-literal = [CFWS] "[" *([FWS] dcontent) [FWS] "]" [CFWS]
915
dcontent = dtext / quoted-pair
917
dtext = NO-WS-CTL / ; Non white space controls
919
%d33-90 / ; The rest of the US-ASCII
920
%d94-126 ; characters not including "[",
923
The domain portion identifies the point to which the mail is
924
delivered. In the dot-atom form, this is interpreted as an Internet
925
domain name (either a host name or a mail exchanger name) as
926
described in [STD3, STD13, STD14]. In the domain-literal form, the
927
domain is interpreted as the literal Internet address of the
928
particular host. In both cases, how addressing is used and how
929
messages are transported to a particular host is covered in the mail
930
transport document [RFC2821]. These mechanisms are outside of the
931
scope of this document.
933
The local-part portion is a domain dependent string. In addresses,
934
it is simply interpreted on the particular host as a name of a
937
3.5 Overall message syntax
939
A message consists of header fields, optionally followed by a message
940
body. Lines in a message MUST be a maximum of 998 characters
941
excluding the CRLF, but it is RECOMMENDED that lines be limited to 78
942
characters excluding the CRLF. (See section 2.1.1 for explanation.)
943
In a message body, though all of the characters listed in the text
944
rule MAY be used, the use of US-ASCII control characters (values 1
945
through 8, 11, 12, and 14 through 31) is discouraged since their
946
interpretation by receivers for display is not guaranteed.
954
Resnick Standards Track [Page 17]
956
RFC 2822 Internet Message Format April 2001
959
message = (fields / obs-fields)
962
body = *(*998text CRLF) *998text
964
The header fields carry most of the semantic information and are
965
defined in section 3.6. The body is simply a series of lines of text
966
which are uninterpreted for the purposes of this standard.
968
3.6. Field definitions
970
The header fields of a message are defined here. All header fields
971
have the same general syntactic structure: A field name, followed by
972
a colon, followed by the field body. The specific syntax for each
973
header field is defined in the subsequent sections.
975
Note: In the ABNF syntax for each field in subsequent sections, each
976
field name is followed by the required colon. However, for brevity
977
sometimes the colon is not referred to in the textual description of
978
the syntax. It is, nonetheless, required.
980
It is important to note that the header fields are not guaranteed to
981
be in a particular order. They may appear in any order, and they
982
have been known to be reordered occasionally when transported over
983
the Internet. However, for the purposes of this standard, header
984
fields SHOULD NOT be reordered when a message is transported or
985
transformed. More importantly, the trace header fields and resent
986
header fields MUST NOT be reordered, and SHOULD be kept in blocks
987
prepended to the message. See sections 3.6.6 and 3.6.7 for more
990
The only required header fields are the origination date field and
991
the originator address field(s). All other header fields are
992
syntactically optional. More information is contained in the table
993
following this definition.
1010
Resnick Standards Track [Page 18]
1012
RFC 2822 Internet Message Format April 2001
1026
The following table indicates limits on the number of times each
1027
field may occur in a message header as well as any special
1028
limitations on the use of those fields. An asterisk next to a value
1029
in the minimum or maximum column indicates that a special restriction
1030
appears in the Notes column.
1032
Field Min number Max number Notes
1034
trace 0 unlimited Block prepended - see
1037
resent-date 0* unlimited* One per block, required
1038
if other resent fields
1041
resent-from 0 unlimited* One per block - see
1044
resent-sender 0* unlimited* One per block, MUST
1045
occur with multi-address
1046
resent-from - see 3.6.6
1048
resent-to 0 unlimited* One per block - see
1051
resent-cc 0 unlimited* One per block - see
1054
resent-bcc 0 unlimited* One per block - see
1057
resent-msg-id 0 unlimited* One per block - see
1062
from 1 1 See sender and 3.6.2
1066
Resnick Standards Track [Page 19]
1068
RFC 2822 Internet Message Format April 2001
1071
sender 0* 1 MUST occur with multi-
1072
address from - see 3.6.2
1082
message-id 0* 1 SHOULD be present - see
1085
in-reply-to 0* 1 SHOULD occur in some
1088
references 0* 1 SHOULD occur in some
1093
comments 0 unlimited
1095
keywords 0 unlimited
1097
optional-field 0 unlimited
1099
The exact interpretation of each field is described in subsequent
1102
3.6.1. The origination date field
1104
The origination date field consists of the field name "Date" followed
1105
by a date-time specification.
1107
orig-date = "Date:" date-time CRLF
1109
The origination date specifies the date and time at which the creator
1110
of the message indicated that the message was complete and ready to
1111
enter the mail delivery system. For instance, this might be the time
1112
that a user pushes the "send" or "submit" button in an application
1113
program. In any case, it is specifically not intended to convey the
1114
time that the message is actually transported, but rather the time at
1115
which the human or other creator of the message has put the message
1116
into its final form, ready for transport. (For example, a portable
1117
computer user who is not connected to a network might queue a message
1122
Resnick Standards Track [Page 20]
1124
RFC 2822 Internet Message Format April 2001
1127
for delivery. The origination date is intended to contain the date
1128
and time that the user queued the message, not the time when the user
1129
connected to the network to send the message.)
1131
3.6.2. Originator fields
1133
The originator fields of a message consist of the from field, the
1134
sender field (when applicable), and optionally the reply-to field.
1135
The from field consists of the field name "From" and a
1136
comma-separated list of one or more mailbox specifications. If the
1137
from field contains more than one mailbox specification in the
1138
mailbox-list, then the sender field, containing the field name
1139
"Sender" and a single mailbox specification, MUST appear in the
1140
message. In either case, an optional reply-to field MAY also be
1141
included, which contains the field name "Reply-To" and a
1142
comma-separated list of one or more addresses.
1144
from = "From:" mailbox-list CRLF
1146
sender = "Sender:" mailbox CRLF
1148
reply-to = "Reply-To:" address-list CRLF
1150
The originator fields indicate the mailbox(es) of the source of the
1151
message. The "From:" field specifies the author(s) of the message,
1152
that is, the mailbox(es) of the person(s) or system(s) responsible
1153
for the writing of the message. The "Sender:" field specifies the
1154
mailbox of the agent responsible for the actual transmission of the
1155
message. For example, if a secretary were to send a message for
1156
another person, the mailbox of the secretary would appear in the
1157
"Sender:" field and the mailbox of the actual author would appear in
1158
the "From:" field. If the originator of the message can be indicated
1159
by a single mailbox and the author and transmitter are identical, the
1160
"Sender:" field SHOULD NOT be used. Otherwise, both fields SHOULD
1163
The originator fields also provide the information required when
1164
replying to a message. When the "Reply-To:" field is present, it
1165
indicates the mailbox(es) to which the author of the message suggests
1166
that replies be sent. In the absence of the "Reply-To:" field,
1167
replies SHOULD by default be sent to the mailbox(es) specified in the
1168
"From:" field unless otherwise specified by the person composing the
1171
In all cases, the "From:" field SHOULD NOT contain any mailbox that
1172
does not belong to the author(s) of the message. See also section
1173
3.6.3 for more information on forming the destination addresses for a
1178
Resnick Standards Track [Page 21]
1180
RFC 2822 Internet Message Format April 2001
1183
3.6.3. Destination address fields
1185
The destination fields of a message consist of three possible fields,
1186
each of the same form: The field name, which is either "To", "Cc", or
1187
"Bcc", followed by a comma-separated list of one or more addresses
1188
(either mailbox or group syntax).
1190
to = "To:" address-list CRLF
1192
cc = "Cc:" address-list CRLF
1194
bcc = "Bcc:" (address-list / [CFWS]) CRLF
1196
The destination fields specify the recipients of the message. Each
1197
destination field may have one or more addresses, and each of the
1198
addresses indicate the intended recipients of the message. The only
1199
difference between the three fields is how each is used.
1201
The "To:" field contains the address(es) of the primary recipient(s)
1204
The "Cc:" field (where the "Cc" means "Carbon Copy" in the sense of
1205
making a copy on a typewriter using carbon paper) contains the
1206
addresses of others who are to receive the message, though the
1207
content of the message may not be directed at them.
1209
The "Bcc:" field (where the "Bcc" means "Blind Carbon Copy") contains
1210
addresses of recipients of the message whose addresses are not to be
1211
revealed to other recipients of the message. There are three ways in
1212
which the "Bcc:" field is used. In the first case, when a message
1213
containing a "Bcc:" field is prepared to be sent, the "Bcc:" line is
1214
removed even though all of the recipients (including those specified
1215
in the "Bcc:" field) are sent a copy of the message. In the second
1216
case, recipients specified in the "To:" and "Cc:" lines each are sent
1217
a copy of the message with the "Bcc:" line removed as above, but the
1218
recipients on the "Bcc:" line get a separate copy of the message
1219
containing a "Bcc:" line. (When there are multiple recipient
1220
addresses in the "Bcc:" field, some implementations actually send a
1221
separate copy of the message to each recipient with a "Bcc:"
1222
containing only the address of that particular recipient.) Finally,
1223
since a "Bcc:" field may contain no addresses, a "Bcc:" field can be
1224
sent without any addresses indicating to the recipients that blind
1225
copies were sent to someone. Which method to use with "Bcc:" fields
1226
is implementation dependent, but refer to the "Security
1227
Considerations" section of this document for a discussion of each.
1234
Resnick Standards Track [Page 22]
1236
RFC 2822 Internet Message Format April 2001
1239
When a message is a reply to another message, the mailboxes of the
1240
authors of the original message (the mailboxes in the "From:" field)
1241
or mailboxes specified in the "Reply-To:" field (if it exists) MAY
1242
appear in the "To:" field of the reply since these would normally be
1243
the primary recipients of the reply. If a reply is sent to a message
1244
that has destination fields, it is often desirable to send a copy of
1245
the reply to all of the recipients of the message, in addition to the
1246
author. When such a reply is formed, addresses in the "To:" and
1247
"Cc:" fields of the original message MAY appear in the "Cc:" field of
1248
the reply, since these are normally secondary recipients of the
1249
reply. If a "Bcc:" field is present in the original message,
1250
addresses in that field MAY appear in the "Bcc:" field of the reply,
1251
but SHOULD NOT appear in the "To:" or "Cc:" fields.
1253
Note: Some mail applications have automatic reply commands that
1254
include the destination addresses of the original message in the
1255
destination addresses of the reply. How those reply commands behave
1256
is implementation dependent and is beyond the scope of this document.
1257
In particular, whether or not to include the original destination
1258
addresses when the original message had a "Reply-To:" field is not
1261
3.6.4. Identification fields
1263
Though optional, every message SHOULD have a "Message-ID:" field.
1264
Furthermore, reply messages SHOULD have "In-Reply-To:" and
1265
"References:" fields as appropriate, as described below.
1267
The "Message-ID:" field contains a single unique message identifier.
1268
The "References:" and "In-Reply-To:" field each contain one or more
1269
unique message identifiers, optionally separated by CFWS.
1271
The message identifier (msg-id) is similar in syntax to an angle-addr
1272
construct without the internal CFWS.
1274
message-id = "Message-ID:" msg-id CRLF
1276
in-reply-to = "In-Reply-To:" 1*msg-id CRLF
1278
references = "References:" 1*msg-id CRLF
1280
msg-id = [CFWS] "<" id-left "@" id-right ">" [CFWS]
1282
id-left = dot-atom-text / no-fold-quote / obs-id-left
1284
id-right = dot-atom-text / no-fold-literal / obs-id-right
1286
no-fold-quote = DQUOTE *(qtext / quoted-pair) DQUOTE
1290
Resnick Standards Track [Page 23]
1292
RFC 2822 Internet Message Format April 2001
1295
no-fold-literal = "[" *(dtext / quoted-pair) "]"
1297
The "Message-ID:" field provides a unique message identifier that
1298
refers to a particular version of a particular message. The
1299
uniqueness of the message identifier is guaranteed by the host that
1300
generates it (see below). This message identifier is intended to be
1301
machine readable and not necessarily meaningful to humans. A message
1302
identifier pertains to exactly one instantiation of a particular
1303
message; subsequent revisions to the message each receive new message
1306
Note: There are many instances when messages are "changed", but those
1307
changes do not constitute a new instantiation of that message, and
1308
therefore the message would not get a new message identifier. For
1309
example, when messages are introduced into the transport system, they
1310
are often prepended with additional header fields such as trace
1311
fields (described in section 3.6.7) and resent fields (described in
1312
section 3.6.6). The addition of such header fields does not change
1313
the identity of the message and therefore the original "Message-ID:"
1314
field is retained. In all cases, it is the meaning that the sender
1315
of the message wishes to convey (i.e., whether this is the same
1316
message or a different message) that determines whether or not the
1317
"Message-ID:" field changes, not any particular syntactic difference
1318
that appears (or does not appear) in the message.
1320
The "In-Reply-To:" and "References:" fields are used when creating a
1321
reply to a message. They hold the message identifier of the original
1322
message and the message identifiers of other messages (for example,
1323
in the case of a reply to a message which was itself a reply). The
1324
"In-Reply-To:" field may be used to identify the message (or
1325
messages) to which the new message is a reply, while the
1326
"References:" field may be used to identify a "thread" of
1329
When creating a reply to a message, the "In-Reply-To:" and
1330
"References:" fields of the resultant message are constructed as
1333
The "In-Reply-To:" field will contain the contents of the "Message-
1334
ID:" field of the message to which this one is a reply (the "parent
1335
message"). If there is more than one parent message, then the "In-
1336
Reply-To:" field will contain the contents of all of the parents'
1337
"Message-ID:" fields. If there is no "Message-ID:" field in any of
1338
the parent messages, then the new message will have no "In-Reply-To:"
1346
Resnick Standards Track [Page 24]
1348
RFC 2822 Internet Message Format April 2001
1351
The "References:" field will contain the contents of the parent's
1352
"References:" field (if any) followed by the contents of the parent's
1353
"Message-ID:" field (if any). If the parent message does not contain
1354
a "References:" field but does have an "In-Reply-To:" field
1355
containing a single message identifier, then the "References:" field
1356
will contain the contents of the parent's "In-Reply-To:" field
1357
followed by the contents of the parent's "Message-ID:" field (if
1358
any). If the parent has none of the "References:", "In-Reply-To:",
1359
or "Message-ID:" fields, then the new message will have no
1360
"References:" field.
1362
Note: Some implementations parse the "References:" field to display
1363
the "thread of the discussion". These implementations assume that
1364
each new message is a reply to a single parent and hence that they
1365
can walk backwards through the "References:" field to find the parent
1366
of each message listed there. Therefore, trying to form a
1367
"References:" field for a reply that has multiple parents is
1368
discouraged and how to do so is not defined in this document.
1370
The message identifier (msg-id) itself MUST be a globally unique
1371
identifier for a message. The generator of the message identifier
1372
MUST guarantee that the msg-id is unique. There are several
1373
algorithms that can be used to accomplish this. Since the msg-id has
1374
a similar syntax to angle-addr (identical except that comments and
1375
folding white space are not allowed), a good method is to put the
1376
domain name (or a domain literal IP address) of the host on which the
1377
message identifier was created on the right hand side of the "@", and
1378
put a combination of the current absolute date and time along with
1379
some other currently unique (perhaps sequential) identifier available
1380
on the system (for example, a process id number) on the left hand
1381
side. Using a date on the left hand side and a domain name or domain
1382
literal on the right hand side makes it possible to guarantee
1383
uniqueness since no two hosts use the same domain name or IP address
1384
at the same time. Though other algorithms will work, it is
1385
RECOMMENDED that the right hand side contain some domain identifier
1386
(either of the host itself or otherwise) such that the generator of
1387
the message identifier can guarantee the uniqueness of the left hand
1388
side within the scope of that domain.
1390
Semantically, the angle bracket characters are not part of the
1391
msg-id; the msg-id is what is contained between the two angle bracket
1402
Resnick Standards Track [Page 25]
1404
RFC 2822 Internet Message Format April 2001
1407
3.6.5. Informational fields
1409
The informational fields are all optional. The "Keywords:" field
1410
contains a comma-separated list of one or more words or
1411
quoted-strings. The "Subject:" and "Comments:" fields are
1412
unstructured fields as defined in section 2.2.1, and therefore may
1413
contain text or folding white space.
1415
subject = "Subject:" unstructured CRLF
1417
comments = "Comments:" unstructured CRLF
1419
keywords = "Keywords:" phrase *("," phrase) CRLF
1421
These three fields are intended to have only human-readable content
1422
with information about the message. The "Subject:" field is the most
1423
common and contains a short string identifying the topic of the
1424
message. When used in a reply, the field body MAY start with the
1425
string "Re: " (from the Latin "res", in the matter of) followed by
1426
the contents of the "Subject:" field body of the original message.
1427
If this is done, only one instance of the literal string "Re: " ought
1428
to be used since use of other strings or more than one instance can
1429
lead to undesirable consequences. The "Comments:" field contains any
1430
additional comments on the text of the body of the message. The
1431
"Keywords:" field contains a comma-separated list of important words
1432
and phrases that might be useful for the recipient.
1434
3.6.6. Resent fields
1436
Resent fields SHOULD be added to any message that is reintroduced by
1437
a user into the transport system. A separate set of resent fields
1438
SHOULD be added each time this is done. All of the resent fields
1439
corresponding to a particular resending of the message SHOULD be
1440
together. Each new set of resent fields is prepended to the message;
1441
that is, the most recent set of resent fields appear earlier in the
1442
message. No other fields in the message are changed when resent
1445
Each of the resent fields corresponds to a particular field elsewhere
1446
in the syntax. For instance, the "Resent-Date:" field corresponds to
1447
the "Date:" field and the "Resent-To:" field corresponds to the "To:"
1448
field. In each case, the syntax for the field body is identical to
1449
the syntax given previously for the corresponding field.
1451
When resent fields are used, the "Resent-From:" and "Resent-Date:"
1452
fields MUST be sent. The "Resent-Message-ID:" field SHOULD be sent.
1453
"Resent-Sender:" SHOULD NOT be used if "Resent-Sender:" would be
1454
identical to "Resent-From:".
1458
Resnick Standards Track [Page 26]
1460
RFC 2822 Internet Message Format April 2001
1463
resent-date = "Resent-Date:" date-time CRLF
1465
resent-from = "Resent-From:" mailbox-list CRLF
1467
resent-sender = "Resent-Sender:" mailbox CRLF
1469
resent-to = "Resent-To:" address-list CRLF
1471
resent-cc = "Resent-Cc:" address-list CRLF
1473
resent-bcc = "Resent-Bcc:" (address-list / [CFWS]) CRLF
1475
resent-msg-id = "Resent-Message-ID:" msg-id CRLF
1477
Resent fields are used to identify a message as having been
1478
reintroduced into the transport system by a user. The purpose of
1479
using resent fields is to have the message appear to the final
1480
recipient as if it were sent directly by the original sender, with
1481
all of the original fields remaining the same. Each set of resent
1482
fields correspond to a particular resending event. That is, if a
1483
message is resent multiple times, each set of resent fields gives
1484
identifying information for each individual time. Resent fields are
1485
strictly informational. They MUST NOT be used in the normal
1486
processing of replies or other such automatic actions on messages.
1488
Note: Reintroducing a message into the transport system and using
1489
resent fields is a different operation from "forwarding".
1490
"Forwarding" has two meanings: One sense of forwarding is that a mail
1491
reading program can be told by a user to forward a copy of a message
1492
to another person, making the forwarded message the body of the new
1493
message. A forwarded message in this sense does not appear to have
1494
come from the original sender, but is an entirely new message from
1495
the forwarder of the message. On the other hand, forwarding is also
1496
used to mean when a mail transport program gets a message and
1497
forwards it on to a different destination for final delivery. Resent
1498
header fields are not intended for use with either type of
1501
The resent originator fields indicate the mailbox of the person(s) or
1502
system(s) that resent the message. As with the regular originator
1503
fields, there are two forms: a simple "Resent-From:" form which
1504
contains the mailbox of the individual doing the resending, and the
1505
more complex form, when one individual (identified in the
1506
"Resent-Sender:" field) resends a message on behalf of one or more
1507
others (identified in the "Resent-From:" field).
1509
Note: When replying to a resent message, replies behave just as they
1510
would with any other message, using the original "From:",
1514
Resnick Standards Track [Page 27]
1516
RFC 2822 Internet Message Format April 2001
1519
"Reply-To:", "Message-ID:", and other fields. The resent fields are
1520
only informational and MUST NOT be used in the normal processing of
1523
The "Resent-Date:" indicates the date and time at which the resent
1524
message is dispatched by the resender of the message. Like the
1525
"Date:" field, it is not the date and time that the message was
1526
actually transported.
1528
The "Resent-To:", "Resent-Cc:", and "Resent-Bcc:" fields function
1529
identically to the "To:", "Cc:", and "Bcc:" fields respectively,
1530
except that they indicate the recipients of the resent message, not
1531
the recipients of the original message.
1533
The "Resent-Message-ID:" field provides a unique identifier for the
1538
The trace fields are a group of header fields consisting of an
1539
optional "Return-Path:" field, and one or more "Received:" fields.
1540
The "Return-Path:" header field contains a pair of angle brackets
1541
that enclose an optional addr-spec. The "Received:" field contains a
1542
(possibly empty) list of name/value pairs followed by a semicolon and
1543
a date-time specification. The first item of the name/value pair is
1544
defined by item-name, and the second item is either an addr-spec, an
1545
atom, a domain, or a msg-id. Further restrictions may be applied to
1546
the syntax of the trace fields by standards that provide for their
1547
use, such as [RFC2821].
1552
return = "Return-Path:" path CRLF
1554
path = ([CFWS] "<" ([CFWS] / addr-spec) ">" [CFWS]) /
1557
received = "Received:" name-val-list ";" date-time CRLF
1559
name-val-list = [CFWS] [name-val-pair *(CFWS name-val-pair)]
1561
name-val-pair = item-name CFWS item-value
1563
item-name = ALPHA *(["-"] (ALPHA / DIGIT))
1565
item-value = 1*angle-addr / addr-spec /
1566
atom / domain / msg-id
1570
Resnick Standards Track [Page 28]
1572
RFC 2822 Internet Message Format April 2001
1575
A full discussion of the Internet mail use of trace fields is
1576
contained in [RFC2821]. For the purposes of this standard, the trace
1577
fields are strictly informational, and any formal interpretation of
1578
them is outside of the scope of this document.
1580
3.6.8. Optional fields
1582
Fields may appear in messages that are otherwise unspecified in this
1583
standard. They MUST conform to the syntax of an optional-field.
1584
This is a field name, made up of the printable US-ASCII characters
1585
except SP and colon, followed by a colon, followed by any text which
1586
conforms to unstructured.
1588
The field names of any optional-field MUST NOT be identical to any
1589
field name specified elsewhere in this standard.
1591
optional-field = field-name ":" unstructured CRLF
1593
field-name = 1*ftext
1595
ftext = %d33-57 / ; Any character except
1596
%d59-126 ; controls, SP, and
1599
For the purposes of this standard, any optional field is
1604
Earlier versions of this standard allowed for different (usually more
1605
liberal) syntax than is allowed in this version. Also, there have
1606
been syntactic elements used in messages on the Internet whose
1607
interpretation have never been documented. Though some of these
1608
syntactic forms MUST NOT be generated according to the grammar in
1609
section 3, they MUST be accepted and parsed by a conformant receiver.
1610
This section documents many of these syntactic elements. Taking the
1611
grammar in section 3 and adding the definitions presented in this
1612
section will result in the grammar to use for interpretation of
1615
Note: This section identifies syntactic forms that any implementation
1616
MUST reasonably interpret. However, there are certainly Internet
1617
messages which do not conform to even the additional syntax given in
1618
this section. The fact that a particular form does not appear in any
1619
section of this document is not justification for computer programs
1620
to crash or for malformed data to be irretrievably lost by any
1621
implementation. To repeat an example, though this document requires
1622
lines in messages to be no longer than 998 characters, silently
1626
Resnick Standards Track [Page 29]
1628
RFC 2822 Internet Message Format April 2001
1631
discarding the 999th and subsequent characters in a line without
1632
warning would still be bad behavior for an implementation. It is up
1633
to the implementation to deal with messages robustly.
1635
One important difference between the obsolete (interpreting) and the
1636
current (generating) syntax is that in structured header field bodies
1637
(i.e., between the colon and the CRLF of any structured header
1638
field), white space characters, including folding white space, and
1639
comments can be freely inserted between any syntactic tokens. This
1640
allows many complex forms that have proven difficult for some
1641
implementations to parse.
1643
Another key difference between the obsolete and the current syntax is
1644
that the rule in section 3.2.3 regarding lines composed entirely of
1645
white space in comments and folding white space does not apply. See
1646
the discussion of folding white space in section 4.2 below.
1648
Finally, certain characters that were formerly allowed in messages
1649
appear in this section. The NUL character (ASCII value 0) was once
1650
allowed, but is no longer for compatibility reasons. CR and LF were
1651
allowed to appear in messages other than as CRLF; this use is also
1654
Other differences in syntax and semantics are noted in the following
1657
4.1. Miscellaneous obsolete tokens
1659
These syntactic elements are used elsewhere in the obsolete syntax or
1660
in the main syntax. The obs-char and obs-qp elements each add ASCII
1661
value 0. Bare CR and bare LF are added to obs-text and obs-utext.
1662
The period character is added to obs-phrase. The obs-phrase-list
1663
provides for "empty" elements in a comma-separated list of phrases.
1665
Note: The "period" (or "full stop") character (".") in obs-phrase is
1666
not a form that was allowed in earlier versions of this or any other
1667
standard. Period (nor any other character from specials) was not
1668
allowed in phrase because it introduced a parsing difficulty
1669
distinguishing between phrases and portions of an addr-spec (see
1670
section 4.4). It appears here because the period character is
1671
currently used in many messages in the display-name portion of
1672
addresses, especially for initials in names, and therefore must be
1673
interpreted properly. In the future, period may appear in the
1674
regular syntax of phrase.
1676
obs-qp = "\" (%d0-127)
1678
obs-text = *LF *CR *(obs-char *LF *CR)
1682
Resnick Standards Track [Page 30]
1684
RFC 2822 Internet Message Format April 2001
1687
obs-char = %d0-9 / %d11 / ; %d0-127 except CR and
1688
%d12 / %d14-127 ; LF
1690
obs-utext = obs-text
1692
obs-phrase = word *(word / "." / CFWS)
1694
obs-phrase-list = phrase / 1*([phrase] [CFWS] "," [CFWS]) [phrase]
1696
Bare CR and bare LF appear in messages with two different meanings.
1697
In many cases, bare CR or bare LF are used improperly instead of CRLF
1698
to indicate line separators. In other cases, bare CR and bare LF are
1699
used simply as ASCII control characters with their traditional ASCII
1702
4.2. Obsolete folding white space
1704
In the obsolete syntax, any amount of folding white space MAY be
1705
inserted where the obs-FWS rule is allowed. This creates the
1706
possibility of having two consecutive "folds" in a line, and
1707
therefore the possibility that a line which makes up a folded header
1708
field could be composed entirely of white space.
1710
obs-FWS = 1*WSP *(CRLF 1*WSP)
1712
4.3. Obsolete Date and Time
1714
The syntax for the obsolete date format allows a 2 digit year in the
1715
date field and allows for a list of alphabetic time zone
1716
specifications that were used in earlier versions of this standard.
1717
It also permits comments and folding white space between many of the
1720
obs-day-of-week = [CFWS] day-name [CFWS]
1722
obs-year = [CFWS] 2*DIGIT [CFWS]
1724
obs-month = CFWS month-name CFWS
1726
obs-day = [CFWS] 1*2DIGIT [CFWS]
1728
obs-hour = [CFWS] 2DIGIT [CFWS]
1730
obs-minute = [CFWS] 2DIGIT [CFWS]
1732
obs-second = [CFWS] 2DIGIT [CFWS]
1734
obs-zone = "UT" / "GMT" / ; Universal Time
1738
Resnick Standards Track [Page 31]
1740
RFC 2822 Internet Message Format April 2001
1745
"EST" / "EDT" / ; Eastern: - 5/ - 4
1746
"CST" / "CDT" / ; Central: - 6/ - 5
1747
"MST" / "MDT" / ; Mountain: - 7/ - 6
1748
"PST" / "PDT" / ; Pacific: - 8/ - 7
1750
%d65-73 / ; Military zones - "A"
1751
%d75-90 / ; through "I" and "K"
1752
%d97-105 / ; through "Z", both
1753
%d107-122 ; upper and lower case
1755
Where a two or three digit year occurs in a date, the year is to be
1756
interpreted as follows: If a two digit year is encountered whose
1757
value is between 00 and 49, the year is interpreted by adding 2000,
1758
ending up with a value between 2000 and 2049. If a two digit year is
1759
encountered with a value between 50 and 99, or any three digit year
1760
is encountered, the year is interpreted by adding 1900.
1762
In the obsolete time zone, "UT" and "GMT" are indications of
1763
"Universal Time" and "Greenwich Mean Time" respectively and are both
1764
semantically identical to "+0000".
1766
The remaining three character zones are the US time zones. The first
1767
letter, "E", "C", "M", or "P" stands for "Eastern", "Central",
1768
"Mountain" and "Pacific". The second letter is either "S" for
1769
"Standard" time, or "D" for "Daylight" (or summer) time. Their
1770
interpretations are as follows:
1772
EDT is semantically equivalent to -0400
1773
EST is semantically equivalent to -0500
1774
CDT is semantically equivalent to -0500
1775
CST is semantically equivalent to -0600
1776
MDT is semantically equivalent to -0600
1777
MST is semantically equivalent to -0700
1778
PDT is semantically equivalent to -0700
1779
PST is semantically equivalent to -0800
1781
The 1 character military time zones were defined in a non-standard
1782
way in [RFC822] and are therefore unpredictable in their meaning.
1783
The original definitions of the military zones "A" through "I" are
1784
equivalent to "+0100" through "+0900" respectively; "K", "L", and "M"
1785
are equivalent to "+1000", "+1100", and "+1200" respectively; "N"
1786
through "Y" are equivalent to "-0100" through "-1200" respectively;
1787
and "Z" is equivalent to "+0000". However, because of the error in
1788
[RFC822], they SHOULD all be considered equivalent to "-0000" unless
1789
there is out-of-band information confirming their meaning.
1794
Resnick Standards Track [Page 32]
1796
RFC 2822 Internet Message Format April 2001
1799
Other multi-character (usually between 3 and 5) alphabetic time zones
1800
have been used in Internet messages. Any such time zone whose
1801
meaning is not known SHOULD be considered equivalent to "-0000"
1802
unless there is out-of-band information confirming their meaning.
1804
4.4. Obsolete Addressing
1806
There are three primary differences in addressing. First, mailbox
1807
addresses were allowed to have a route portion before the addr-spec
1808
when enclosed in "<" and ">". The route is simply a comma-separated
1809
list of domain names, each preceded by "@", and the list terminated
1810
by a colon. Second, CFWS were allowed between the period-separated
1811
elements of local-part and domain (i.e., dot-atom was not used). In
1812
addition, local-part is allowed to contain quoted-string in addition
1813
to just atom. Finally, mailbox-list and address-list were allowed to
1814
have "null" members. That is, there could be two or more commas in
1815
such a list with nothing in between them.
1817
obs-angle-addr = [CFWS] "<" [obs-route] addr-spec ">" [CFWS]
1819
obs-route = [CFWS] obs-domain-list ":" [CFWS]
1821
obs-domain-list = "@" domain *(*(CFWS / "," ) [CFWS] "@" domain)
1823
obs-local-part = word *("." word)
1825
obs-domain = atom *("." atom)
1827
obs-mbox-list = 1*([mailbox] [CFWS] "," [CFWS]) [mailbox]
1829
obs-addr-list = 1*([address] [CFWS] "," [CFWS]) [address]
1831
When interpreting addresses, the route portion SHOULD be ignored.
1833
4.5. Obsolete header fields
1835
Syntactically, the primary difference in the obsolete field syntax is
1836
that it allows multiple occurrences of any of the fields and they may
1837
occur in any order. Also, any amount of white space is allowed
1838
before the ":" at the end of the field name.
1840
obs-fields = *(obs-return /
1850
Resnick Standards Track [Page 33]
1852
RFC 2822 Internet Message Format April 2001
1873
Except for destination address fields (described in section 4.5.3),
1874
the interpretation of multiple occurrences of fields is unspecified.
1875
Also, the interpretation of trace fields and resent fields which do
1876
not occur in blocks prepended to the message is unspecified as well.
1877
Unless otherwise noted in the following sections, interpretation of
1878
other fields is identical to the interpretation of their non-obsolete
1879
counterparts in section 3.
1881
4.5.1. Obsolete origination date field
1883
obs-orig-date = "Date" *WSP ":" date-time CRLF
1885
4.5.2. Obsolete originator fields
1887
obs-from = "From" *WSP ":" mailbox-list CRLF
1889
obs-sender = "Sender" *WSP ":" mailbox CRLF
1891
obs-reply-to = "Reply-To" *WSP ":" mailbox-list CRLF
1893
4.5.3. Obsolete destination address fields
1895
obs-to = "To" *WSP ":" address-list CRLF
1897
obs-cc = "Cc" *WSP ":" address-list CRLF
1899
obs-bcc = "Bcc" *WSP ":" (address-list / [CFWS]) CRLF
1906
Resnick Standards Track [Page 34]
1908
RFC 2822 Internet Message Format April 2001
1911
When multiple occurrences of destination address fields occur in a
1912
message, they SHOULD be treated as if the address-list in the first
1913
occurrence of the field is combined with the address lists of the
1914
subsequent occurrences by adding a comma and concatenating.
1916
4.5.4. Obsolete identification fields
1918
The obsolete "In-Reply-To:" and "References:" fields differ from the
1919
current syntax in that they allow phrase (words or quoted strings) to
1920
appear. The obsolete forms of the left and right sides of msg-id
1921
allow interspersed CFWS, making them syntactically identical to
1922
local-part and domain respectively.
1924
obs-message-id = "Message-ID" *WSP ":" msg-id CRLF
1926
obs-in-reply-to = "In-Reply-To" *WSP ":" *(phrase / msg-id) CRLF
1928
obs-references = "References" *WSP ":" *(phrase / msg-id) CRLF
1930
obs-id-left = local-part
1932
obs-id-right = domain
1934
For purposes of interpretation, the phrases in the "In-Reply-To:" and
1935
"References:" fields are ignored.
1937
Semantically, none of the optional CFWS surrounding the local-part
1938
and the domain are part of the obs-id-left and obs-id-right
1941
4.5.5. Obsolete informational fields
1943
obs-subject = "Subject" *WSP ":" unstructured CRLF
1945
obs-comments = "Comments" *WSP ":" unstructured CRLF
1947
obs-keywords = "Keywords" *WSP ":" obs-phrase-list CRLF
1949
4.5.6. Obsolete resent fields
1951
The obsolete syntax adds a "Resent-Reply-To:" field, which consists
1952
of the field name, the optional comments and folding white space, the
1953
colon, and a comma separated list of addresses.
1955
obs-resent-from = "Resent-From" *WSP ":" mailbox-list CRLF
1957
obs-resent-send = "Resent-Sender" *WSP ":" mailbox CRLF
1962
Resnick Standards Track [Page 35]
1964
RFC 2822 Internet Message Format April 2001
1967
obs-resent-date = "Resent-Date" *WSP ":" date-time CRLF
1969
obs-resent-to = "Resent-To" *WSP ":" address-list CRLF
1971
obs-resent-cc = "Resent-Cc" *WSP ":" address-list CRLF
1973
obs-resent-bcc = "Resent-Bcc" *WSP ":"
1974
(address-list / [CFWS]) CRLF
1976
obs-resent-mid = "Resent-Message-ID" *WSP ":" msg-id CRLF
1978
obs-resent-rply = "Resent-Reply-To" *WSP ":" address-list CRLF
1980
As with other resent fields, the "Resent-Reply-To:" field is to be
1981
treated as trace information only.
1983
4.5.7. Obsolete trace fields
1985
The obs-return and obs-received are again given here as template
1986
definitions, just as return and received are in section 3. Their
1987
full syntax is given in [RFC2821].
1989
obs-return = "Return-Path" *WSP ":" path CRLF
1991
obs-received = "Received" *WSP ":" name-val-list CRLF
1993
obs-path = obs-angle-addr
1995
4.5.8. Obsolete optional fields
1997
obs-optional = field-name *WSP ":" unstructured CRLF
1999
5. Security Considerations
2001
Care needs to be taken when displaying messages on a terminal or
2002
terminal emulator. Powerful terminals may act on escape sequences
2003
and other combinations of ASCII control characters with a variety of
2004
consequences. They can remap the keyboard or permit other
2005
modifications to the terminal which could lead to denial of service
2006
or even damaged data. They can trigger (sometimes programmable)
2007
answerback messages which can allow a message to cause commands to be
2008
issued on the recipient's behalf. They can also effect the operation
2009
of terminal attached devices such as printers. Message viewers may
2010
wish to strip potentially dangerous terminal escape sequences from
2011
the message prior to display. However, other escape sequences appear
2012
in messages for useful purposes (cf. [RFC2045, RFC2046, RFC2047,
2013
RFC2048, RFC2049, ISO2022]) and therefore should not be stripped
2018
Resnick Standards Track [Page 36]
2020
RFC 2822 Internet Message Format April 2001
2023
Transmission of non-text objects in messages raises additional
2024
security issues. These issues are discussed in [RFC2045, RFC2046,
2025
RFC2047, RFC2048, RFC2049].
2027
Many implementations use the "Bcc:" (blind carbon copy) field
2028
described in section 3.6.3 to facilitate sending messages to
2029
recipients without revealing the addresses of one or more of the
2030
addressees to the other recipients. Mishandling this use of "Bcc:"
2031
has implications for confidential information that might be revealed,
2032
which could eventually lead to security problems through knowledge of
2033
even the existence of a particular mail address. For example, if
2034
using the first method described in section 3.6.3, where the "Bcc:"
2035
line is removed from the message, blind recipients have no explicit
2036
indication that they have been sent a blind copy, except insofar as
2037
their address does not appear in the message header. Because of
2038
this, one of the blind addressees could potentially send a reply to
2039
all of the shown recipients and accidentally reveal that the message
2040
went to the blind recipient. When the second method from section
2041
3.6.3 is used, the blind recipient's address appears in the "Bcc:"
2042
field of a separate copy of the message. If the "Bcc:" field sent
2043
contains all of the blind addressees, all of the "Bcc:" recipients
2044
will be seen by each "Bcc:" recipient. Even if a separate message is
2045
sent to each "Bcc:" recipient with only the individual's address,
2046
implementations still need to be careful to process replies to the
2047
message as per section 3.6.3 so as not to accidentally reveal the
2048
blind recipient to other recipients.
2052
[ASCII] American National Standards Institute (ANSI), Coded
2053
Character Set - 7-Bit American National Standard Code for
2054
Information Interchange, ANSI X3.4, 1986.
2056
[ISO2022] International Organization for Standardization (ISO),
2057
Information processing - ISO 7-bit and 8-bit coded
2058
character sets - Code extension techniques, Third edition
2059
- 1986-05-01, ISO 2022, 1986.
2061
[RFC822] Crocker, D., "Standard for the Format of ARPA Internet
2062
Text Messages", RFC 822, August 1982.
2064
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
2065
Extensions (MIME) Part One: Format of Internet Message
2066
Bodies", RFC 2045, November 1996.
2068
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
2069
Extensions (MIME) Part Two: Media Types", RFC 2046,
2074
Resnick Standards Track [Page 37]
2076
RFC 2822 Internet Message Format April 2001
2079
[RFC2047] Moore, K., "Multipurpose Internet Mail Extensions (MIME)
2080
Part Three: Message Header Extensions for Non-ASCII Text",
2081
RFC 2047, November 1996.
2083
[RFC2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose
2084
Internet Mail Extensions (MIME) Part Four: Format of
2085
Internet Message Bodies", RFC 2048, November 1996.
2087
[RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
2088
Extensions (MIME) Part Five: Conformance Criteria and
2089
Examples", RFC 2049, November 1996.
2091
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
2092
Requirement Levels", BCP 14, RFC 2119, March 1997.
2094
[RFC2234] Crocker, D., Editor, and P. Overell, "Augmented BNF for
2095
Syntax Specifications: ABNF", RFC 2234, November 1997.
2097
[RFC2821] Klensin, J., Editor, "Simple Mail Transfer Protocol", RFC
2100
[STD3] Braden, R., "Host Requirements", STD 3, RFC 1122 and RFC
2103
[STD12] Mills, D., "Network Time Protocol", STD 12, RFC 1119,
2106
[STD13] Mockapetris, P., "Domain Name System", STD 13, RFC 1034
2107
and RFC 1035, November 1987.
2109
[STD14] Partridge, C., "Mail Routing and the Domain System", STD
2110
14, RFC 974, January 1986.
2115
QUALCOMM Incorporated
2116
5775 Morehouse Drive
2117
San Diego, CA 92121-1714
2120
Phone: +1 858 651 4478
2121
Fax: +1 858 651 1102
2122
EMail: presnick@qualcomm.com
2130
Resnick Standards Track [Page 38]
2132
RFC 2822 Internet Message Format April 2001
2137
Many people contributed to this document. They included folks who
2138
participated in the Detailed Revision and Update of Messaging
2139
Standards (DRUMS) Working Group of the Internet Engineering Task
2140
Force (IETF), the chair of DRUMS, the Area Directors of the IETF, and
2141
people who simply sent their comments in via e-mail. The editor is
2142
deeply indebted to them all and thanks them sincerely. The below
2143
list includes everyone who sent e-mail concerning this document.
2144
Hopefully, everyone who contributed is named here:
2146
Matti Aarnio Barry Finkel Larry Masinter
2147
Tanaka Akira Erik Forsberg Denis McKeon
2148
Russ Allbery Chuck Foster William P McQuillan
2149
Eric Allman Paul Fox Alexey Melnikov
2150
Harald Tveit Alvestrand Klaus M. Frank Perry E. Metzger
2151
Ran Atkinson Ned Freed Steven Miller
2152
Jos Backus Jochen Friedrich Keith Moore
2153
Bruce Balden Randall C. Gellens John Gardiner Myers
2154
Dave Barr Sukvinder Singh Gill Chris Newman
2155
Alan Barrett Tim Goodwin John W. Noerenberg
2156
John Beck Philip Guenther Eric Norman
2157
J. Robert von Behren Tony Hansen Mike O'Dell
2158
Jos den Bekker John Hawkinson Larry Osterman
2159
D. J. Bernstein Philip Hazel Paul Overell
2160
James Berriman Kai Henningsen Jacob Palme
2161
Norbert Bollow Robert Herriot Michael A. Patton
2162
Raj Bose Paul Hethmon Uzi Paz
2163
Antony Bowesman Jim Hill Michael A. Quinlan
2164
Scott Bradner Paul E. Hoffman Eric S. Raymond
2165
Randy Bush Steve Hole Sam Roberts
2166
Tom Byrer Kari Hurtta Hugh Sasse
2167
Bruce Campbell Marco S. Hyman Bart Schaefer
2168
Larry Campbell Ofer Inbar Tom Scola
2169
W. J. Carpenter Olle Jarnefors Wolfgang Segmuller
2170
Michael Chapman Kevin Johnson Nick Shelness
2171
Richard Clayton Sudish Joseph John Stanley
2172
Maurizio Codogno Maynard Kang Einar Stefferud
2173
Jim Conklin Prabhat Keni Jeff Stephenson
2174
R. Kelley Cook John C. Klensin Bernard Stern
2175
Steve Coya Graham Klyne Peter Sylvester
2176
Mark Crispin Brad Knowles Mark Symons
2177
Dave Crocker Shuhei Kobayashi Eric Thomas
2178
Matt Curtin Peter Koch Lee Thompson
2179
Michael D'Errico Dan Kohn Karel De Vriendt
2180
Cyrus Daboo Christian Kuhtz Matthew Wall
2181
Jutta Degener Anand Kumria Rolf Weber
2182
Mark Delany Steen Larsen Brent B. Welch
2186
Resnick Standards Track [Page 39]
2188
RFC 2822 Internet Message Format April 2001
2191
Steve Dorner Eliot Lear Dan Wing
2192
Harold A. Driscoll Barry Leiba Jack De Winter
2193
Michael Elkins Jay Levitt Gregory J. Woodhouse
2194
Robert Elz Lars-Johan Liman Greg A. Woods
2195
Johnny Eriksson Charles Lindsey Kazu Yamamoto
2196
Erik E. Fair Pete Loshin Alain Zahm
2197
Roger Fajman Simon Lyall Jamie Zawinski
2198
Patrik Faltstrom Bill Manning Timothy S. Zurcher
2199
Claus Andre Farber John Martin
2242
Resnick Standards Track [Page 40]
2244
RFC 2822 Internet Message Format April 2001
2247
Appendix A. Example messages
2249
This section presents a selection of messages. These are intended to
2250
assist in the implementation of this standard, but should not be
2251
taken as normative; that is to say, although the examples in this
2252
section were carefully reviewed, if there happens to be a conflict
2253
between these examples and the syntax described in sections 3 and 4
2254
of this document, the syntax in those sections is to be taken as
2257
Messages are delimited in this section between lines of "----". The
2258
"----" lines are not part of the message itself.
2260
A.1. Addressing examples
2262
The following are examples of messages that might be sent between two
2265
A.1.1. A message from one person to another with simple addressing
2267
This could be called a canonical message. It has a single author,
2268
John Doe, a single recipient, Mary Smith, a subject, the date, a
2269
message identifier, and a textual message in the body.
2272
From: John Doe <jdoe@machine.example>
2273
To: Mary Smith <mary@example.net>
2274
Subject: Saying Hello
2275
Date: Fri, 21 Nov 1997 09:55:06 -0600
2276
Message-ID: <1234@local.machine.example>
2278
This is a message just to say hello.
2298
Resnick Standards Track [Page 41]
2300
RFC 2822 Internet Message Format April 2001
2303
If John's secretary Michael actually sent the message, though John
2304
was the author and replies to this message should go back to him, the
2305
sender field would be used:
2308
From: John Doe <jdoe@machine.example>
2309
Sender: Michael Jones <mjones@machine.example>
2310
To: Mary Smith <mary@example.net>
2311
Subject: Saying Hello
2312
Date: Fri, 21 Nov 1997 09:55:06 -0600
2313
Message-ID: <1234@local.machine.example>
2315
This is a message just to say hello.
2319
A.1.2. Different types of mailboxes
2321
This message includes multiple addresses in the destination fields
2322
and also uses several different forms of addresses.
2325
From: "Joe Q. Public" <john.q.public@example.com>
2326
To: Mary Smith <mary@x.test>, jdoe@example.org, Who? <one@y.test>
2327
Cc: <boss@nil.test>, "Giant; \"Big\" Box" <sysservices@example.net>
2328
Date: Tue, 1 Jul 2003 10:52:37 +0200
2329
Message-ID: <5678.21-Nov-1997@example.com>
2334
Note that the display names for Joe Q. Public and Giant; "Big" Box
2335
needed to be enclosed in double-quotes because the former contains
2336
the period and the latter contains both semicolon and double-quote
2337
characters (the double-quote characters appearing as quoted-pair
2338
construct). Conversely, the display name for Who? could appear
2339
without them because the question mark is legal in an atom. Notice
2340
also that jdoe@example.org and boss@nil.test have no display names
2341
associated with them at all, and jdoe@example.org uses the simpler
2342
address form without the angle brackets.
2354
Resnick Standards Track [Page 42]
2356
RFC 2822 Internet Message Format April 2001
2359
A.1.3. Group addresses
2362
From: Pete <pete@silly.example>
2363
To: A Group:Chris Jones <c@a.test>,joe@where.test,John <jdoe@one.test>;
2364
Cc: Undisclosed recipients:;
2365
Date: Thu, 13 Feb 1969 23:32:54 -0330
2366
Message-ID: <testabcd.1234@silly.example>
2371
In this message, the "To:" field has a single group recipient named A
2372
Group which contains 3 addresses, and a "Cc:" field with an empty
2373
group recipient named Undisclosed recipients.
2377
The following is a series of three messages that make up a
2378
conversation thread between John and Mary. John firsts sends a
2379
message to Mary, Mary then replies to John's message, and then John
2380
replies to Mary's reply message.
2382
Note especially the "Message-ID:", "References:", and "In-Reply-To:"
2383
fields in each message.
2386
From: John Doe <jdoe@machine.example>
2387
To: Mary Smith <mary@example.net>
2388
Subject: Saying Hello
2389
Date: Fri, 21 Nov 1997 09:55:06 -0600
2390
Message-ID: <1234@local.machine.example>
2392
This is a message just to say hello.
2410
Resnick Standards Track [Page 43]
2412
RFC 2822 Internet Message Format April 2001
2415
When sending replies, the Subject field is often retained, though
2416
prepended with "Re: " as described in section 3.6.5.
2419
From: Mary Smith <mary@example.net>
2420
To: John Doe <jdoe@machine.example>
2421
Reply-To: "Mary Smith: Personal Account" <smith@home.example>
2422
Subject: Re: Saying Hello
2423
Date: Fri, 21 Nov 1997 10:01:10 -0600
2424
Message-ID: <3456@example.net>
2425
In-Reply-To: <1234@local.machine.example>
2426
References: <1234@local.machine.example>
2428
This is a reply to your hello.
2431
Note the "Reply-To:" field in the above message. When John replies
2432
to Mary's message above, the reply should go to the address in the
2433
"Reply-To:" field instead of the address in the "From:" field.
2436
To: "Mary Smith: Personal Account" <smith@home.example>
2437
From: John Doe <jdoe@machine.example>
2438
Subject: Re: Saying Hello
2439
Date: Fri, 21 Nov 1997 11:00:00 -0600
2440
Message-ID: <abcd.1234@local.machine.tld>
2441
In-Reply-To: <3456@example.net>
2442
References: <1234@local.machine.example> <3456@example.net>
2444
This is a reply to your reply.
2447
A.3. Resent messages
2449
Start with the message that has been used as an example several
2453
From: John Doe <jdoe@machine.example>
2454
To: Mary Smith <mary@example.net>
2455
Subject: Saying Hello
2456
Date: Fri, 21 Nov 1997 09:55:06 -0600
2457
Message-ID: <1234@local.machine.example>
2459
This is a message just to say hello.
2466
Resnick Standards Track [Page 44]
2468
RFC 2822 Internet Message Format April 2001
2471
Say that Mary, upon receiving this message, wishes to send a copy of
2472
the message to Jane such that (a) the message would appear to have
2473
come straight from John; (b) if Jane replies to the message, the
2474
reply should go back to John; and (c) all of the original
2475
information, like the date the message was originally sent to Mary,
2476
the message identifier, and the original addressee, is preserved. In
2477
this case, resent fields are prepended to the message:
2480
Resent-From: Mary Smith <mary@example.net>
2481
Resent-To: Jane Brown <j-brown@other.example>
2482
Resent-Date: Mon, 24 Nov 1997 14:22:01 -0800
2483
Resent-Message-ID: <78910@example.net>
2484
From: John Doe <jdoe@machine.example>
2485
To: Mary Smith <mary@example.net>
2486
Subject: Saying Hello
2487
Date: Fri, 21 Nov 1997 09:55:06 -0600
2488
Message-ID: <1234@local.machine.example>
2490
This is a message just to say hello.
2494
If Jane, in turn, wished to resend this message to another person,
2495
she would prepend her own set of resent header fields to the above
2522
Resnick Standards Track [Page 45]
2524
RFC 2822 Internet Message Format April 2001
2527
A.4. Messages with trace fields
2529
As messages are sent through the transport system as described in
2530
[RFC2821], trace fields are prepended to the message. The following
2531
is an example of what those trace fields might look like. Note that
2532
there is some folding white space in the first one since these lines
2536
Received: from x.y.test
2541
for <mary@example.net>; 21 Nov 1997 10:05:43 -0600
2542
Received: from machine.example by x.y.test; 21 Nov 1997 10:01:22 -0600
2543
From: John Doe <jdoe@machine.example>
2544
To: Mary Smith <mary@example.net>
2545
Subject: Saying Hello
2546
Date: Fri, 21 Nov 1997 09:55:06 -0600
2547
Message-ID: <1234@local.machine.example>
2549
This is a message just to say hello.
2578
Resnick Standards Track [Page 46]
2580
RFC 2822 Internet Message Format April 2001
2583
A.5. White space, comments, and other oddities
2585
White space, including folding white space, and comments can be
2586
inserted between many of the tokens of fields. Taking the example
2587
from A.1.3, white space and comments can be inserted into all of the
2591
From: Pete(A wonderful \) chap) <pete(his account)@silly.test(his host)>
2592
To:A Group(Some people)
2593
:Chris Jones <c@(Chris's host.)public.example>,
2595
John <jdoe@one.test> (my dear friend); (the end of the group)
2596
Cc:(Empty list)(start)Undisclosed recipients :(nobody(that I know)) ;
2602
-0330 (Newfoundland Time)
2603
Message-ID: <testabcd.1234@silly.test>
2608
The above example is aesthetically displeasing, but perfectly legal.
2609
Note particularly (1) the comments in the "From:" field (including
2610
one that has a ")" character appearing as part of a quoted-pair); (2)
2611
the white space absent after the ":" in the "To:" field as well as
2612
the comment and folding white space after the group name, the special
2613
character (".") in the comment in Chris Jones's address, and the
2614
folding white space before and after "joe@example.org,"; (3) the
2615
multiple and nested comments in the "Cc:" field as well as the
2616
comment immediately following the ":" after "Cc"; (4) the folding
2617
white space (but no comments except at the end) and the missing
2618
seconds in the time of the date field; and (5) the white space before
2619
(but not within) the identifier in the "Message-ID:" field.
2621
A.6. Obsoleted forms
2623
The following are examples of obsolete (that is, the "MUST NOT
2624
generate") syntactic elements described in section 4 of this
2634
Resnick Standards Track [Page 47]
2636
RFC 2822 Internet Message Format April 2001
2639
A.6.1. Obsolete addressing
2641
Note in the below example the lack of quotes around Joe Q. Public,
2642
the route that appears in the address for Mary Smith, the two commas
2643
that appear in the "To:" field, and the spaces that appear around the
2644
"." in the jdoe address.
2647
From: Joe Q. Public <john.q.public@example.com>
2648
To: Mary Smith <@machine.tld:mary@example.net>, , jdoe@test . example
2649
Date: Tue, 1 Jul 2003 10:52:37 +0200
2650
Message-ID: <5678.21-Nov-1997@example.com>
2655
A.6.2. Obsolete dates
2657
The following message uses an obsolete date format, including a non-
2658
numeric time zone and a two digit year. Note that although the
2659
day-of-week is missing, that is not specific to the obsolete syntax;
2660
it is optional in the current syntax as well.
2663
From: John Doe <jdoe@machine.example>
2664
To: Mary Smith <mary@example.net>
2665
Subject: Saying Hello
2666
Date: 21 Nov 97 09:55:06 GMT
2667
Message-ID: <1234@local.machine.example>
2669
This is a message just to say hello.
2673
A.6.3. Obsolete white space and comments
2675
White space and comments can appear between many more elements than
2676
in the current syntax. Also, folding lines that are made up entirely
2677
of white space are legal.
2690
Resnick Standards Track [Page 48]
2692
RFC 2822 Internet Message Format April 2001
2696
From : John Doe <jdoe@machine(comment). example>
2700
Subject : Saying Hello
2701
Date : Fri, 21 Nov 1997 09(comment): 55 : 06 -0600
2702
Message-ID : <1234 @ local(blah) .machine .example>
2704
This is a message just to say hello.
2708
Note especially the second line of the "To:" field. It starts with
2709
two space characters. (Note that "__" represent blank spaces.)
2710
Therefore, it is considered part of the folding as described in
2711
section 4.2. Also, the comments and white space throughout
2712
addresses, dates, and message identifiers are all part of the
2715
Appendix B. Differences from earlier standards
2717
This appendix contains a list of changes that have been made in the
2718
Internet Message Format from earlier standards, specifically [RFC822]
2719
and [STD3]. Items marked with an asterisk (*) below are items which
2720
appear in section 4 of this document and therefore can no longer be
2723
1. Period allowed in obsolete form of phrase.
2724
2. ABNF moved out of document to [RFC2234].
2725
3. Four or more digits allowed for year.
2726
4. Header field ordering (and lack thereof) made explicit.
2727
5. Encrypted header field removed.
2728
6. Received syntax loosened to allow any token/value pair.
2729
7. Specifically allow and give meaning to "-0000" time zone.
2730
8. Folding white space is not allowed between every token.
2731
9. Requirement for destinations removed.
2732
10. Forwarding and resending redefined.
2733
11. Extension header fields no longer specifically called out.
2734
12. ASCII 0 (null) removed.*
2735
13. Folding continuation lines cannot contain only white space.*
2736
14. Free insertion of comments not allowed in date.*
2737
15. Non-numeric time zones not allowed.*
2738
16. Two digit years not allowed.*
2739
17. Three digit years interpreted, but not allowed for generation.
2740
18. Routes in addresses not allowed.*
2741
19. CFWS within local-parts and domains not allowed.*
2742
20. Empty members of address lists not allowed.*
2746
Resnick Standards Track [Page 49]
2748
RFC 2822 Internet Message Format April 2001
2751
21. Folding white space between field name and colon not allowed.*
2752
22. Comments between field name and colon not allowed.
2753
23. Tightened syntax of in-reply-to and references.*
2754
24. CFWS within msg-id not allowed.*
2755
25. Tightened semantics of resent fields as informational only.
2756
26. Resent-Reply-To not allowed.*
2757
27. No multiple occurrences of fields (except resent and received).*
2758
28. Free CR and LF not allowed.*
2759
29. Routes in return path not allowed.*
2760
30. Line length limits specified.
2761
31. Bcc more clearly specified.
2765
Intellectual Property
2767
The IETF takes no position regarding the validity or scope of any
2768
intellectual property or other rights that might be claimed to
2769
pertain to the implementation or use of the technology described in
2770
this document or the extent to which any license under such rights
2771
might or might not be available; neither does it represent that it
2772
has made any effort to identify any such rights. Information on the
2773
IETF's procedures with respect to rights in standards-track and
2774
standards-related documentation can be found in BCP-11. Copies of
2775
claims of rights made available for publication and any assurances of
2776
licenses to be made available, or the result of an attempt made to
2777
obtain a general license or permission for the use of such
2778
proprietary rights by implementors or users of this specification can
2779
be obtained from the IETF Secretariat.
2802
Resnick Standards Track [Page 50]
2804
RFC 2822 Internet Message Format April 2001
2807
Full Copyright Statement
2809
Copyright (C) The Internet Society (2001). All Rights Reserved.
2811
This document and translations of it may be copied and furnished to
2812
others, and derivative works that comment on or otherwise explain it
2813
or assist in its implementation may be prepared, copied, published
2814
and distributed, in whole or in part, without restriction of any
2815
kind, provided that the above copyright notice and this paragraph are
2816
included on all such copies and derivative works. However, this
2817
document itself may not be modified in any way, such as by removing
2818
the copyright notice or references to the Internet Society or other
2819
Internet organizations, except as needed for the purpose of
2820
developing Internet standards in which case the procedures for
2821
copyrights defined in the Internet Standards process must be
2822
followed, or as required to translate it into languages other than
2825
The limited permissions granted above are perpetual and will not be
2826
revoked by the Internet Society or its successors or assigns.
2828
This document and the information contained herein is provided on an
2829
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
2830
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
2831
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
2832
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
2833
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
2837
Funding for the RFC Editor function is currently provided by the
2858
Resnick Standards Track [Page 51]