]>
Commit | Line | Data |
---|---|---|
ef416fc2 | 1 | |
2 | ||
3 | ||
4 | ||
5 | ||
6 | ||
7 | Network Working Group P. Resnick, Editor | |
8 | Request for Comments: 2822 QUALCOMM Incorporated | |
9 | Obsoletes: 822 April 2001 | |
10 | Category: Standards Track | |
11 | ||
12 | ||
13 | Internet Message Format | |
14 | ||
15 | Status of this Memo | |
16 | ||
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. | |
22 | ||
23 | Copyright Notice | |
24 | ||
25 | Copyright (C) The Internet Society (2001). All Rights Reserved. | |
26 | ||
27 | Abstract | |
28 | ||
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. | |
35 | ||
36 | Table of Contents | |
37 | ||
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 | |
55 | ||
56 | ||
57 | ||
58 | Resnick Standards Track [Page 1] | |
59 | \f | |
60 | RFC 2822 Internet Message Format April 2001 | |
61 | ||
62 | ||
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 | |
111 | ||
112 | ||
113 | ||
114 | Resnick Standards Track [Page 2] | |
115 | \f | |
116 | RFC 2822 Internet Message Format April 2001 | |
117 | ||
118 | ||
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 | |
125 | ||
126 | 1. Introduction | |
127 | ||
128 | 1.1. Scope | |
129 | ||
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 | |
136 | [STD3]. | |
137 | ||
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 | |
146 | this standard. | |
147 | ||
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. | |
155 | ||
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. | |
159 | ||
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. | |
166 | ||
167 | ||
168 | ||
169 | ||
170 | Resnick Standards Track [Page 3] | |
171 | \f | |
172 | RFC 2822 Internet Message Format April 2001 | |
173 | ||
174 | ||
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 | |
182 | on disk. | |
183 | ||
184 | 1.2. Notational conventions | |
185 | ||
186 | 1.2.1. Requirements notation | |
187 | ||
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]. | |
193 | ||
194 | 1.2.2. Syntactic notation | |
195 | ||
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. | |
203 | ||
204 | 1.3. Structure of this document | |
205 | ||
206 | This document is divided into several sections. | |
207 | ||
208 | This section, section 1, is a short introduction to the document. | |
209 | ||
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. | |
215 | ||
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 | |
223 | ||
224 | ||
225 | ||
226 | Resnick Standards Track [Page 4] | |
227 | \f | |
228 | RFC 2822 Internet Message Format April 2001 | |
229 | ||
230 | ||
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. | |
235 | ||
236 | Both sections 2 and 3 describe messages that are legal to generate | |
237 | for purposes of this standard. | |
238 | ||
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 | |
248 | conformant messages. | |
249 | ||
250 | Section 5 details security considerations to take into account when | |
251 | implementing this standard. | |
252 | ||
253 | Section 6 is a bibliography of references in this document. | |
254 | ||
255 | Section 7 contains the editor's address. | |
256 | ||
257 | Section 8 contains acknowledgements. | |
258 | ||
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. | |
262 | ||
263 | Appendix B lists the differences between this standard and earlier | |
264 | standards for Internet messages. | |
265 | ||
266 | Appendix C has copyright and intellectual property notices. | |
267 | ||
268 | 2. Lexical Analysis of Messages | |
269 | ||
270 | 2.1. General Description | |
271 | ||
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". | |
277 | ||
278 | ||
279 | ||
280 | ||
281 | ||
282 | Resnick Standards Track [Page 5] | |
283 | \f | |
284 | RFC 2822 Internet Message Format April 2001 | |
285 | ||
286 | ||
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. | |
293 | ||
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".) | |
300 | ||
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). | |
307 | ||
308 | 2.1.1. Line Length Limits | |
309 | ||
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 | |
313 | the CRLF. | |
314 | ||
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. | |
324 | ||
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 | |
333 | ||
334 | ||
335 | ||
336 | ||
337 | ||
338 | Resnick Standards Track [Page 6] | |
339 | \f | |
340 | RFC 2822 Internet Message Format April 2001 | |
341 | ||
342 | ||
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 | |
345 | robustness. | |
346 | ||
347 | 2.2. Header Fields | |
348 | ||
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. | |
358 | ||
359 | 2.2.1. Unstructured Header Field Bodies | |
360 | ||
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). | |
368 | ||
369 | 2.2.2. Structured Header Field Bodies | |
370 | ||
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. | |
383 | ||
384 | 2.2.3. Long Header Fields | |
385 | ||
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 | |
391 | ||
392 | ||
393 | ||
394 | Resnick Standards Track [Page 7] | |
395 | \f | |
396 | RFC 2822 Internet Message Format April 2001 | |
397 | ||
398 | ||
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: | |
402 | ||
403 | Subject: This is a test | |
404 | ||
405 | can be represented as: | |
406 | ||
407 | Subject: This | |
408 | is a test | |
409 | ||
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. | |
418 | ||
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 | |
424 | evaluation. | |
425 | ||
426 | 2.3. Body | |
427 | ||
428 | The body of a message is simply lines of US-ASCII characters. The | |
429 | only two limitations on the body are as follows: | |
430 | ||
431 | - CR and LF MUST only occur together as CRLF; they MUST NOT appear | |
432 | independently in the body. | |
433 | ||
434 | - Lines of characters in the body MUST be limited to 998 characters, | |
435 | and SHOULD be limited to 78 characters, excluding the CRLF. | |
436 | ||
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 | |
441 | document. | |
442 | ||
443 | ||
444 | ||
445 | ||
446 | ||
447 | ||
448 | ||
449 | ||
450 | Resnick Standards Track [Page 8] | |
451 | \f | |
452 | RFC 2822 Internet Message Format April 2001 | |
453 | ||
454 | ||
455 | 3. Syntax | |
456 | ||
457 | 3.1. Introduction | |
458 | ||
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. | |
464 | ||
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 | |
468 | come from [RFC2234]. | |
469 | ||
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. | |
479 | ||
480 | 3.2. Lexical Tokens | |
481 | ||
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. | |
485 | ||
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. | |
495 | ||
496 | 3.2.1. Primitive Tokens | |
497 | ||
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. | |
502 | ||
503 | ||
504 | ||
505 | ||
506 | Resnick Standards Track [Page 9] | |
507 | \f | |
508 | RFC 2822 Internet Message Format April 2001 | |
509 | ||
510 | ||
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. | |
516 | ||
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 | |
521 | %d127 | |
522 | ||
523 | text = %d1-9 / ; Characters excluding CR and LF | |
524 | %d11 / | |
525 | %d12 / | |
526 | %d14-127 / | |
527 | obs-text | |
528 | ||
529 | specials = "(" / ")" / ; Special characters used in | |
530 | "<" / ">" / ; other parts of the syntax | |
531 | "[" / "]" / | |
532 | ":" / ";" / | |
533 | "@" / "\" / | |
534 | "," / "." / | |
535 | DQUOTE | |
536 | ||
537 | No special semantics are attached to these tokens. They are simply | |
538 | single characters. | |
539 | ||
540 | 3.2.2. Quoted characters | |
541 | ||
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. | |
545 | ||
546 | quoted-pair = ("\" text) / obs-qp | |
547 | ||
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". | |
551 | ||
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. | |
557 | ||
558 | ||
559 | ||
560 | ||
561 | ||
562 | Resnick Standards Track [Page 10] | |
563 | \f | |
564 | RFC 2822 Internet Message Format April 2001 | |
565 | ||
566 | ||
567 | 3.2.3. Folding white space and comments | |
568 | ||
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. | |
575 | ||
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. | |
579 | ||
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. | |
586 | ||
587 | FWS = ([*WSP CRLF] 1*WSP) / ; Folding white space | |
588 | obs-FWS | |
589 | ||
590 | ctext = NO-WS-CTL / ; Non white space controls | |
591 | ||
592 | %d33-39 / ; The rest of the US-ASCII | |
593 | %d42-91 / ; characters not including "(", | |
594 | %d93-126 ; ")", or "\" | |
595 | ||
596 | ccontent = ctext / quoted-pair / comment | |
597 | ||
598 | comment = "(" *([FWS] ccontent) [FWS] ")" | |
599 | ||
600 | CFWS = *([FWS] comment) (([FWS] comment) / FWS) | |
601 | ||
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." | |
610 | ||
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 | |
615 | ||
616 | ||
617 | ||
618 | Resnick Standards Track [Page 11] | |
619 | \f | |
620 | RFC 2822 Internet Message Format April 2001 | |
621 | ||
622 | ||
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. | |
629 | ||
630 | Runs of FWS, comment or CFWS that occur between lexical tokens in a | |
631 | structured field header are semantically interpreted as a single | |
632 | space character. | |
633 | ||
634 | 3.2.4. Atom | |
635 | ||
636 | Several productions in structured header field bodies are simply | |
637 | strings of certain basic characters. Such productions are called | |
638 | atoms. | |
639 | ||
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. | |
643 | ||
644 | atext = ALPHA / DIGIT / ; Any character except controls, | |
645 | "!" / "#" / ; SP, and specials. | |
646 | "$" / "%" / ; Used for atoms | |
647 | "&" / "'" / | |
648 | "*" / "+" / | |
649 | "-" / "/" / | |
650 | "=" / "?" / | |
651 | "^" / "_" / | |
652 | "`" / "{" / | |
653 | "|" / "}" / | |
654 | "~" | |
655 | ||
656 | atom = [CFWS] 1*atext [CFWS] | |
657 | ||
658 | dot-atom = [CFWS] dot-atom-text [CFWS] | |
659 | ||
660 | dot-atom-text = 1*atext *("." 1*atext) | |
661 | ||
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. | |
667 | ||
668 | ||
669 | ||
670 | ||
671 | ||
672 | ||
673 | ||
674 | Resnick Standards Track [Page 12] | |
675 | \f | |
676 | RFC 2822 Internet Message Format April 2001 | |
677 | ||
678 | ||
679 | 3.2.5. Quoted strings | |
680 | ||
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) | |
684 | characters. | |
685 | ||
686 | qtext = NO-WS-CTL / ; Non white space controls | |
687 | ||
688 | %d33 / ; The rest of the US-ASCII | |
689 | %d35-91 / ; characters not including "\" | |
690 | %d93-126 ; or the quote character | |
691 | ||
692 | qcontent = qtext / quoted-pair | |
693 | ||
694 | quoted-string = [CFWS] | |
695 | DQUOTE *([FWS] qcontent) [FWS] DQUOTE | |
696 | [CFWS] | |
697 | ||
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. | |
703 | ||
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 | |
710 | either. | |
711 | ||
712 | 3.2.6. Miscellaneous tokens | |
713 | ||
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 | |
717 | header fields. | |
718 | ||
719 | word = atom / quoted-string | |
720 | ||
721 | phrase = 1*word / obs-phrase | |
722 | ||
723 | ||
724 | ||
725 | ||
726 | ||
727 | ||
728 | ||
729 | ||
730 | Resnick Standards Track [Page 13] | |
731 | \f | |
732 | RFC 2822 Internet Message Format April 2001 | |
733 | ||
734 | ||
735 | utext = NO-WS-CTL / ; Non white space controls | |
736 | %d33-126 / ; The rest of US-ASCII | |
737 | obs-utext | |
738 | ||
739 | unstructured = *([FWS] utext) [FWS] | |
740 | ||
741 | 3.3. Date and Time Specification | |
742 | ||
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 | |
749 | space correctly. | |
750 | ||
751 | date-time = [ day-of-week "," ] date FWS time [CFWS] | |
752 | ||
753 | day-of-week = ([FWS] day-name) / obs-day-of-week | |
754 | ||
755 | day-name = "Mon" / "Tue" / "Wed" / "Thu" / | |
756 | "Fri" / "Sat" / "Sun" | |
757 | ||
758 | date = day month year | |
759 | ||
760 | year = 4*DIGIT / obs-year | |
761 | ||
762 | month = (FWS month-name FWS) / obs-month | |
763 | ||
764 | month-name = "Jan" / "Feb" / "Mar" / "Apr" / | |
765 | "May" / "Jun" / "Jul" / "Aug" / | |
766 | "Sep" / "Oct" / "Nov" / "Dec" | |
767 | ||
768 | day = ([FWS] 1*2DIGIT) / obs-day | |
769 | ||
770 | time = time-of-day FWS zone | |
771 | ||
772 | time-of-day = hour ":" minute [ ":" second ] | |
773 | ||
774 | hour = 2DIGIT / obs-hour | |
775 | ||
776 | minute = 2DIGIT / obs-minute | |
777 | ||
778 | second = 2DIGIT / obs-second | |
779 | ||
780 | zone = (( "+" / "-" ) 4DIGIT) / obs-zone | |
781 | ||
782 | ||
783 | ||
784 | ||
785 | ||
786 | Resnick Standards Track [Page 14] | |
787 | \f | |
788 | RFC 2822 Internet Message Format April 2001 | |
789 | ||
790 | ||
791 | The day is the numeric day of the month. The year is any numeric | |
792 | year 1900 or later. | |
793 | ||
794 | The time-of-day specifies the number of hours, minutes, and | |
795 | optionally seconds since midnight of the date indicated. | |
796 | ||
797 | The date and time-of-day SHOULD express local time. | |
798 | ||
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 | |
812 | time zone. | |
813 | ||
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. | |
821 | ||
822 | 3.4. Address Specification | |
823 | ||
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. | |
827 | ||
828 | address = mailbox / group | |
829 | ||
830 | mailbox = name-addr / addr-spec | |
831 | ||
832 | name-addr = [display-name] angle-addr | |
833 | ||
834 | angle-addr = [CFWS] "<" addr-spec ">" [CFWS] / obs-angle-addr | |
835 | ||
836 | group = display-name ":" [mailbox-list / CFWS] ";" | |
837 | [CFWS] | |
838 | ||
839 | ||
840 | ||
841 | ||
842 | Resnick Standards Track [Page 15] | |
843 | \f | |
844 | RFC 2822 Internet Message Format April 2001 | |
845 | ||
846 | ||
847 | display-name = phrase | |
848 | ||
849 | mailbox-list = (mailbox *("," mailbox)) / obs-mbox-list | |
850 | ||
851 | address-list = (address *("," address)) / obs-addr-list | |
852 | ||
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. | |
864 | ||
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. | |
874 | ||
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 | |
885 | recipients. | |
886 | ||
887 | 3.4.1. Addr-spec specification | |
888 | ||
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 | |
895 | ||
896 | ||
897 | ||
898 | Resnick Standards Track [Page 16] | |
899 | \f | |
900 | RFC 2822 Internet Message Format April 2001 | |
901 | ||
902 | ||
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. | |
906 | ||
907 | addr-spec = local-part "@" domain | |
908 | ||
909 | local-part = dot-atom / quoted-string / obs-local-part | |
910 | ||
911 | domain = dot-atom / domain-literal / obs-domain | |
912 | ||
913 | domain-literal = [CFWS] "[" *([FWS] dcontent) [FWS] "]" [CFWS] | |
914 | ||
915 | dcontent = dtext / quoted-pair | |
916 | ||
917 | dtext = NO-WS-CTL / ; Non white space controls | |
918 | ||
919 | %d33-90 / ; The rest of the US-ASCII | |
920 | %d94-126 ; characters not including "[", | |
921 | ; "]", or "\" | |
922 | ||
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. | |
932 | ||
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 | |
935 | particular mailbox. | |
936 | ||
937 | 3.5 Overall message syntax | |
938 | ||
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. | |
947 | ||
948 | ||
949 | ||
950 | ||
951 | ||
952 | ||
953 | ||
954 | Resnick Standards Track [Page 17] | |
955 | \f | |
956 | RFC 2822 Internet Message Format April 2001 | |
957 | ||
958 | ||
959 | message = (fields / obs-fields) | |
960 | [CRLF body] | |
961 | ||
962 | body = *(*998text CRLF) *998text | |
963 | ||
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. | |
967 | ||
968 | 3.6. Field definitions | |
969 | ||
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. | |
974 | ||
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. | |
979 | ||
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 | |
988 | information. | |
989 | ||
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. | |
994 | ||
995 | fields = *(trace | |
996 | *(resent-date / | |
997 | resent-from / | |
998 | resent-sender / | |
999 | resent-to / | |
1000 | resent-cc / | |
1001 | resent-bcc / | |
1002 | resent-msg-id)) | |
1003 | *(orig-date / | |
1004 | from / | |
1005 | sender / | |
1006 | reply-to / | |
1007 | ||
1008 | ||
1009 | ||
1010 | Resnick Standards Track [Page 18] | |
1011 | \f | |
1012 | RFC 2822 Internet Message Format April 2001 | |
1013 | ||
1014 | ||
1015 | to / | |
1016 | cc / | |
1017 | bcc / | |
1018 | message-id / | |
1019 | in-reply-to / | |
1020 | references / | |
1021 | subject / | |
1022 | comments / | |
1023 | keywords / | |
1024 | optional-field) | |
1025 | ||
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. | |
1031 | ||
1032 | Field Min number Max number Notes | |
1033 | ||
1034 | trace 0 unlimited Block prepended - see | |
1035 | 3.6.7 | |
1036 | ||
1037 | resent-date 0* unlimited* One per block, required | |
1038 | if other resent fields | |
1039 | present - see 3.6.6 | |
1040 | ||
1041 | resent-from 0 unlimited* One per block - see | |
1042 | 3.6.6 | |
1043 | ||
1044 | resent-sender 0* unlimited* One per block, MUST | |
1045 | occur with multi-address | |
1046 | resent-from - see 3.6.6 | |
1047 | ||
1048 | resent-to 0 unlimited* One per block - see | |
1049 | 3.6.6 | |
1050 | ||
1051 | resent-cc 0 unlimited* One per block - see | |
1052 | 3.6.6 | |
1053 | ||
1054 | resent-bcc 0 unlimited* One per block - see | |
1055 | 3.6.6 | |
1056 | ||
1057 | resent-msg-id 0 unlimited* One per block - see | |
1058 | 3.6.6 | |
1059 | ||
1060 | orig-date 1 1 | |
1061 | ||
1062 | from 1 1 See sender and 3.6.2 | |
1063 | ||
1064 | ||
1065 | ||
1066 | Resnick Standards Track [Page 19] | |
1067 | \f | |
1068 | RFC 2822 Internet Message Format April 2001 | |
1069 | ||
1070 | ||
1071 | sender 0* 1 MUST occur with multi- | |
1072 | address from - see 3.6.2 | |
1073 | ||
1074 | reply-to 0 1 | |
1075 | ||
1076 | to 0 1 | |
1077 | ||
1078 | cc 0 1 | |
1079 | ||
1080 | bcc 0 1 | |
1081 | ||
1082 | message-id 0* 1 SHOULD be present - see | |
1083 | 3.6.4 | |
1084 | ||
1085 | in-reply-to 0* 1 SHOULD occur in some | |
1086 | replies - see 3.6.4 | |
1087 | ||
1088 | references 0* 1 SHOULD occur in some | |
1089 | replies - see 3.6.4 | |
1090 | ||
1091 | subject 0 1 | |
1092 | ||
1093 | comments 0 unlimited | |
1094 | ||
1095 | keywords 0 unlimited | |
1096 | ||
1097 | optional-field 0 unlimited | |
1098 | ||
1099 | The exact interpretation of each field is described in subsequent | |
1100 | sections. | |
1101 | ||
1102 | 3.6.1. The origination date field | |
1103 | ||
1104 | The origination date field consists of the field name "Date" followed | |
1105 | by a date-time specification. | |
1106 | ||
1107 | orig-date = "Date:" date-time CRLF | |
1108 | ||
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 | |
1118 | ||
1119 | ||
1120 | ||
1121 | ||
1122 | Resnick Standards Track [Page 20] | |
1123 | \f | |
1124 | RFC 2822 Internet Message Format April 2001 | |
1125 | ||
1126 | ||
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.) | |
1130 | ||
1131 | 3.6.2. Originator fields | |
1132 | ||
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. | |
1143 | ||
1144 | from = "From:" mailbox-list CRLF | |
1145 | ||
1146 | sender = "Sender:" mailbox CRLF | |
1147 | ||
1148 | reply-to = "Reply-To:" address-list CRLF | |
1149 | ||
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 | |
1161 | appear. | |
1162 | ||
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 | |
1169 | reply. | |
1170 | ||
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 | |
1174 | reply. | |
1175 | ||
1176 | ||
1177 | ||
1178 | Resnick Standards Track [Page 21] | |
1179 | \f | |
1180 | RFC 2822 Internet Message Format April 2001 | |
1181 | ||
1182 | ||
1183 | 3.6.3. Destination address fields | |
1184 | ||
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). | |
1189 | ||
1190 | to = "To:" address-list CRLF | |
1191 | ||
1192 | cc = "Cc:" address-list CRLF | |
1193 | ||
1194 | bcc = "Bcc:" (address-list / [CFWS]) CRLF | |
1195 | ||
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. | |
1200 | ||
1201 | The "To:" field contains the address(es) of the primary recipient(s) | |
1202 | of the message. | |
1203 | ||
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. | |
1208 | ||
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. | |
1228 | ||
1229 | ||
1230 | ||
1231 | ||
1232 | ||
1233 | ||
1234 | Resnick Standards Track [Page 22] | |
1235 | \f | |
1236 | RFC 2822 Internet Message Format April 2001 | |
1237 | ||
1238 | ||
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. | |
1252 | ||
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 | |
1259 | addressed here. | |
1260 | ||
1261 | 3.6.4. Identification fields | |
1262 | ||
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. | |
1266 | ||
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. | |
1270 | ||
1271 | The message identifier (msg-id) is similar in syntax to an angle-addr | |
1272 | construct without the internal CFWS. | |
1273 | ||
1274 | message-id = "Message-ID:" msg-id CRLF | |
1275 | ||
1276 | in-reply-to = "In-Reply-To:" 1*msg-id CRLF | |
1277 | ||
1278 | references = "References:" 1*msg-id CRLF | |
1279 | ||
1280 | msg-id = [CFWS] "<" id-left "@" id-right ">" [CFWS] | |
1281 | ||
1282 | id-left = dot-atom-text / no-fold-quote / obs-id-left | |
1283 | ||
1284 | id-right = dot-atom-text / no-fold-literal / obs-id-right | |
1285 | ||
1286 | no-fold-quote = DQUOTE *(qtext / quoted-pair) DQUOTE | |
1287 | ||
1288 | ||
1289 | ||
1290 | Resnick Standards Track [Page 23] | |
1291 | \f | |
1292 | RFC 2822 Internet Message Format April 2001 | |
1293 | ||
1294 | ||
1295 | no-fold-literal = "[" *(dtext / quoted-pair) "]" | |
1296 | ||
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 | |
1304 | identifiers. | |
1305 | ||
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. | |
1319 | ||
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 | |
1327 | conversation. | |
1328 | ||
1329 | When creating a reply to a message, the "In-Reply-To:" and | |
1330 | "References:" fields of the resultant message are constructed as | |
1331 | follows: | |
1332 | ||
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:" | |
1339 | field. | |
1340 | ||
1341 | ||
1342 | ||
1343 | ||
1344 | ||
1345 | ||
1346 | Resnick Standards Track [Page 24] | |
1347 | \f | |
1348 | RFC 2822 Internet Message Format April 2001 | |
1349 | ||
1350 | ||
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. | |
1361 | ||
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. | |
1369 | ||
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. | |
1389 | ||
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 | |
1392 | characters. | |
1393 | ||
1394 | ||
1395 | ||
1396 | ||
1397 | ||
1398 | ||
1399 | ||
1400 | ||
1401 | ||
1402 | Resnick Standards Track [Page 25] | |
1403 | \f | |
1404 | RFC 2822 Internet Message Format April 2001 | |
1405 | ||
1406 | ||
1407 | 3.6.5. Informational fields | |
1408 | ||
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. | |
1414 | ||
1415 | subject = "Subject:" unstructured CRLF | |
1416 | ||
1417 | comments = "Comments:" unstructured CRLF | |
1418 | ||
1419 | keywords = "Keywords:" phrase *("," phrase) CRLF | |
1420 | ||
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. | |
1433 | ||
1434 | 3.6.6. Resent fields | |
1435 | ||
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 | |
1443 | fields are added. | |
1444 | ||
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. | |
1450 | ||
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:". | |
1455 | ||
1456 | ||
1457 | ||
1458 | Resnick Standards Track [Page 26] | |
1459 | \f | |
1460 | RFC 2822 Internet Message Format April 2001 | |
1461 | ||
1462 | ||
1463 | resent-date = "Resent-Date:" date-time CRLF | |
1464 | ||
1465 | resent-from = "Resent-From:" mailbox-list CRLF | |
1466 | ||
1467 | resent-sender = "Resent-Sender:" mailbox CRLF | |
1468 | ||
1469 | resent-to = "Resent-To:" address-list CRLF | |
1470 | ||
1471 | resent-cc = "Resent-Cc:" address-list CRLF | |
1472 | ||
1473 | resent-bcc = "Resent-Bcc:" (address-list / [CFWS]) CRLF | |
1474 | ||
1475 | resent-msg-id = "Resent-Message-ID:" msg-id CRLF | |
1476 | ||
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. | |
1487 | ||
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 | |
1499 | forwarding. | |
1500 | ||
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). | |
1508 | ||
1509 | Note: When replying to a resent message, replies behave just as they | |
1510 | would with any other message, using the original "From:", | |
1511 | ||
1512 | ||
1513 | ||
1514 | Resnick Standards Track [Page 27] | |
1515 | \f | |
1516 | RFC 2822 Internet Message Format April 2001 | |
1517 | ||
1518 | ||
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 | |
1521 | replies. | |
1522 | ||
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. | |
1527 | ||
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. | |
1532 | ||
1533 | The "Resent-Message-ID:" field provides a unique identifier for the | |
1534 | resent message. | |
1535 | ||
1536 | 3.6.7. Trace fields | |
1537 | ||
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]. | |
1548 | ||
1549 | trace = [return] | |
1550 | 1*received | |
1551 | ||
1552 | return = "Return-Path:" path CRLF | |
1553 | ||
1554 | path = ([CFWS] "<" ([CFWS] / addr-spec) ">" [CFWS]) / | |
1555 | obs-path | |
1556 | ||
1557 | received = "Received:" name-val-list ";" date-time CRLF | |
1558 | ||
1559 | name-val-list = [CFWS] [name-val-pair *(CFWS name-val-pair)] | |
1560 | ||
1561 | name-val-pair = item-name CFWS item-value | |
1562 | ||
1563 | item-name = ALPHA *(["-"] (ALPHA / DIGIT)) | |
1564 | ||
1565 | item-value = 1*angle-addr / addr-spec / | |
1566 | atom / domain / msg-id | |
1567 | ||
1568 | ||
1569 | ||
1570 | Resnick Standards Track [Page 28] | |
1571 | \f | |
1572 | RFC 2822 Internet Message Format April 2001 | |
1573 | ||
1574 | ||
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. | |
1579 | ||
1580 | 3.6.8. Optional fields | |
1581 | ||
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. | |
1587 | ||
1588 | The field names of any optional-field MUST NOT be identical to any | |
1589 | field name specified elsewhere in this standard. | |
1590 | ||
1591 | optional-field = field-name ":" unstructured CRLF | |
1592 | ||
1593 | field-name = 1*ftext | |
1594 | ||
1595 | ftext = %d33-57 / ; Any character except | |
1596 | %d59-126 ; controls, SP, and | |
1597 | ; ":". | |
1598 | ||
1599 | For the purposes of this standard, any optional field is | |
1600 | uninterpreted. | |
1601 | ||
1602 | 4. Obsolete Syntax | |
1603 | ||
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 | |
1613 | messages. | |
1614 | ||
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 | |
1623 | ||
1624 | ||
1625 | ||
1626 | Resnick Standards Track [Page 29] | |
1627 | \f | |
1628 | RFC 2822 Internet Message Format April 2001 | |
1629 | ||
1630 | ||
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. | |
1634 | ||
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. | |
1642 | ||
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. | |
1647 | ||
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 | |
1652 | shown here. | |
1653 | ||
1654 | Other differences in syntax and semantics are noted in the following | |
1655 | sections. | |
1656 | ||
1657 | 4.1. Miscellaneous obsolete tokens | |
1658 | ||
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. | |
1664 | ||
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. | |
1675 | ||
1676 | obs-qp = "\" (%d0-127) | |
1677 | ||
1678 | obs-text = *LF *CR *(obs-char *LF *CR) | |
1679 | ||
1680 | ||
1681 | ||
1682 | Resnick Standards Track [Page 30] | |
1683 | \f | |
1684 | RFC 2822 Internet Message Format April 2001 | |
1685 | ||
1686 | ||
1687 | obs-char = %d0-9 / %d11 / ; %d0-127 except CR and | |
1688 | %d12 / %d14-127 ; LF | |
1689 | ||
1690 | obs-utext = obs-text | |
1691 | ||
1692 | obs-phrase = word *(word / "." / CFWS) | |
1693 | ||
1694 | obs-phrase-list = phrase / 1*([phrase] [CFWS] "," [CFWS]) [phrase] | |
1695 | ||
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 | |
1700 | meanings. | |
1701 | ||
1702 | 4.2. Obsolete folding white space | |
1703 | ||
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. | |
1709 | ||
1710 | obs-FWS = 1*WSP *(CRLF 1*WSP) | |
1711 | ||
1712 | 4.3. Obsolete Date and Time | |
1713 | ||
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 | |
1718 | tokens. | |
1719 | ||
1720 | obs-day-of-week = [CFWS] day-name [CFWS] | |
1721 | ||
1722 | obs-year = [CFWS] 2*DIGIT [CFWS] | |
1723 | ||
1724 | obs-month = CFWS month-name CFWS | |
1725 | ||
1726 | obs-day = [CFWS] 1*2DIGIT [CFWS] | |
1727 | ||
1728 | obs-hour = [CFWS] 2DIGIT [CFWS] | |
1729 | ||
1730 | obs-minute = [CFWS] 2DIGIT [CFWS] | |
1731 | ||
1732 | obs-second = [CFWS] 2DIGIT [CFWS] | |
1733 | ||
1734 | obs-zone = "UT" / "GMT" / ; Universal Time | |
1735 | ||
1736 | ||
1737 | ||
1738 | Resnick Standards Track [Page 31] | |
1739 | \f | |
1740 | RFC 2822 Internet Message Format April 2001 | |
1741 | ||
1742 | ||
1743 | ; North American UT | |
1744 | ; offsets | |
1745 | "EST" / "EDT" / ; Eastern: - 5/ - 4 | |
1746 | "CST" / "CDT" / ; Central: - 6/ - 5 | |
1747 | "MST" / "MDT" / ; Mountain: - 7/ - 6 | |
1748 | "PST" / "PDT" / ; Pacific: - 8/ - 7 | |
1749 | ||
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 | |
1754 | ||
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. | |
1761 | ||
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". | |
1765 | ||
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: | |
1771 | ||
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 | |
1780 | ||
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. | |
1790 | ||
1791 | ||
1792 | ||
1793 | ||
1794 | Resnick Standards Track [Page 32] | |
1795 | \f | |
1796 | RFC 2822 Internet Message Format April 2001 | |
1797 | ||
1798 | ||
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. | |
1803 | ||
1804 | 4.4. Obsolete Addressing | |
1805 | ||
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. | |
1816 | ||
1817 | obs-angle-addr = [CFWS] "<" [obs-route] addr-spec ">" [CFWS] | |
1818 | ||
1819 | obs-route = [CFWS] obs-domain-list ":" [CFWS] | |
1820 | ||
1821 | obs-domain-list = "@" domain *(*(CFWS / "," ) [CFWS] "@" domain) | |
1822 | ||
1823 | obs-local-part = word *("." word) | |
1824 | ||
1825 | obs-domain = atom *("." atom) | |
1826 | ||
1827 | obs-mbox-list = 1*([mailbox] [CFWS] "," [CFWS]) [mailbox] | |
1828 | ||
1829 | obs-addr-list = 1*([address] [CFWS] "," [CFWS]) [address] | |
1830 | ||
1831 | When interpreting addresses, the route portion SHOULD be ignored. | |
1832 | ||
1833 | 4.5. Obsolete header fields | |
1834 | ||
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. | |
1839 | ||
1840 | obs-fields = *(obs-return / | |
1841 | obs-received / | |
1842 | obs-orig-date / | |
1843 | obs-from / | |
1844 | obs-sender / | |
1845 | obs-reply-to / | |
1846 | obs-to / | |
1847 | ||
1848 | ||
1849 | ||
1850 | Resnick Standards Track [Page 33] | |
1851 | \f | |
1852 | RFC 2822 Internet Message Format April 2001 | |
1853 | ||
1854 | ||
1855 | obs-cc / | |
1856 | obs-bcc / | |
1857 | obs-message-id / | |
1858 | obs-in-reply-to / | |
1859 | obs-references / | |
1860 | obs-subject / | |
1861 | obs-comments / | |
1862 | obs-keywords / | |
1863 | obs-resent-date / | |
1864 | obs-resent-from / | |
1865 | obs-resent-send / | |
1866 | obs-resent-rply / | |
1867 | obs-resent-to / | |
1868 | obs-resent-cc / | |
1869 | obs-resent-bcc / | |
1870 | obs-resent-mid / | |
1871 | obs-optional) | |
1872 | ||
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. | |
1880 | ||
1881 | 4.5.1. Obsolete origination date field | |
1882 | ||
1883 | obs-orig-date = "Date" *WSP ":" date-time CRLF | |
1884 | ||
1885 | 4.5.2. Obsolete originator fields | |
1886 | ||
1887 | obs-from = "From" *WSP ":" mailbox-list CRLF | |
1888 | ||
1889 | obs-sender = "Sender" *WSP ":" mailbox CRLF | |
1890 | ||
1891 | obs-reply-to = "Reply-To" *WSP ":" mailbox-list CRLF | |
1892 | ||
1893 | 4.5.3. Obsolete destination address fields | |
1894 | ||
1895 | obs-to = "To" *WSP ":" address-list CRLF | |
1896 | ||
1897 | obs-cc = "Cc" *WSP ":" address-list CRLF | |
1898 | ||
1899 | obs-bcc = "Bcc" *WSP ":" (address-list / [CFWS]) CRLF | |
1900 | ||
1901 | ||
1902 | ||
1903 | ||
1904 | ||
1905 | ||
1906 | Resnick Standards Track [Page 34] | |
1907 | \f | |
1908 | RFC 2822 Internet Message Format April 2001 | |
1909 | ||
1910 | ||
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. | |
1915 | ||
1916 | 4.5.4. Obsolete identification fields | |
1917 | ||
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. | |
1923 | ||
1924 | obs-message-id = "Message-ID" *WSP ":" msg-id CRLF | |
1925 | ||
1926 | obs-in-reply-to = "In-Reply-To" *WSP ":" *(phrase / msg-id) CRLF | |
1927 | ||
1928 | obs-references = "References" *WSP ":" *(phrase / msg-id) CRLF | |
1929 | ||
1930 | obs-id-left = local-part | |
1931 | ||
1932 | obs-id-right = domain | |
1933 | ||
1934 | For purposes of interpretation, the phrases in the "In-Reply-To:" and | |
1935 | "References:" fields are ignored. | |
1936 | ||
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 | |
1939 | respectively. | |
1940 | ||
1941 | 4.5.5. Obsolete informational fields | |
1942 | ||
1943 | obs-subject = "Subject" *WSP ":" unstructured CRLF | |
1944 | ||
1945 | obs-comments = "Comments" *WSP ":" unstructured CRLF | |
1946 | ||
1947 | obs-keywords = "Keywords" *WSP ":" obs-phrase-list CRLF | |
1948 | ||
1949 | 4.5.6. Obsolete resent fields | |
1950 | ||
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. | |
1954 | ||
1955 | obs-resent-from = "Resent-From" *WSP ":" mailbox-list CRLF | |
1956 | ||
1957 | obs-resent-send = "Resent-Sender" *WSP ":" mailbox CRLF | |
1958 | ||
1959 | ||
1960 | ||
1961 | ||
1962 | Resnick Standards Track [Page 35] | |
1963 | \f | |
1964 | RFC 2822 Internet Message Format April 2001 | |
1965 | ||
1966 | ||
1967 | obs-resent-date = "Resent-Date" *WSP ":" date-time CRLF | |
1968 | ||
1969 | obs-resent-to = "Resent-To" *WSP ":" address-list CRLF | |
1970 | ||
1971 | obs-resent-cc = "Resent-Cc" *WSP ":" address-list CRLF | |
1972 | ||
1973 | obs-resent-bcc = "Resent-Bcc" *WSP ":" | |
1974 | (address-list / [CFWS]) CRLF | |
1975 | ||
1976 | obs-resent-mid = "Resent-Message-ID" *WSP ":" msg-id CRLF | |
1977 | ||
1978 | obs-resent-rply = "Resent-Reply-To" *WSP ":" address-list CRLF | |
1979 | ||
1980 | As with other resent fields, the "Resent-Reply-To:" field is to be | |
1981 | treated as trace information only. | |
1982 | ||
1983 | 4.5.7. Obsolete trace fields | |
1984 | ||
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]. | |
1988 | ||
1989 | obs-return = "Return-Path" *WSP ":" path CRLF | |
1990 | ||
1991 | obs-received = "Received" *WSP ":" name-val-list CRLF | |
1992 | ||
1993 | obs-path = obs-angle-addr | |
1994 | ||
1995 | 4.5.8. Obsolete optional fields | |
1996 | ||
1997 | obs-optional = field-name *WSP ":" unstructured CRLF | |
1998 | ||
1999 | 5. Security Considerations | |
2000 | ||
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 | |
2014 | indiscriminately. | |
2015 | ||
2016 | ||
2017 | ||
2018 | Resnick Standards Track [Page 36] | |
2019 | \f | |
2020 | RFC 2822 Internet Message Format April 2001 | |
2021 | ||
2022 | ||
2023 | Transmission of non-text objects in messages raises additional | |
2024 | security issues. These issues are discussed in [RFC2045, RFC2046, | |
2025 | RFC2047, RFC2048, RFC2049]. | |
2026 | ||
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. | |
2049 | ||
2050 | 6. Bibliography | |
2051 | ||
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. | |
2055 | ||
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. | |
2060 | ||
2061 | [RFC822] Crocker, D., "Standard for the Format of ARPA Internet | |
2062 | Text Messages", RFC 822, August 1982. | |
2063 | ||
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. | |
2067 | ||
2068 | [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail | |
2069 | Extensions (MIME) Part Two: Media Types", RFC 2046, | |
2070 | November 1996. | |
2071 | ||
2072 | ||
2073 | ||
2074 | Resnick Standards Track [Page 37] | |
2075 | \f | |
2076 | RFC 2822 Internet Message Format April 2001 | |
2077 | ||
2078 | ||
2079 | [RFC2047] Moore, K., "Multipurpose Internet Mail Extensions (MIME) | |
2080 | Part Three: Message Header Extensions for Non-ASCII Text", | |
2081 | RFC 2047, November 1996. | |
2082 | ||
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. | |
2086 | ||
2087 | [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail | |
2088 | Extensions (MIME) Part Five: Conformance Criteria and | |
2089 | Examples", RFC 2049, November 1996. | |
2090 | ||
2091 | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |
2092 | Requirement Levels", BCP 14, RFC 2119, March 1997. | |
2093 | ||
2094 | [RFC2234] Crocker, D., Editor, and P. Overell, "Augmented BNF for | |
2095 | Syntax Specifications: ABNF", RFC 2234, November 1997. | |
2096 | ||
2097 | [RFC2821] Klensin, J., Editor, "Simple Mail Transfer Protocol", RFC | |
2098 | 2821, March 2001. | |
2099 | ||
2100 | [STD3] Braden, R., "Host Requirements", STD 3, RFC 1122 and RFC | |
2101 | 1123, October 1989. | |
2102 | ||
2103 | [STD12] Mills, D., "Network Time Protocol", STD 12, RFC 1119, | |
2104 | September 1989. | |
2105 | ||
2106 | [STD13] Mockapetris, P., "Domain Name System", STD 13, RFC 1034 | |
2107 | and RFC 1035, November 1987. | |
2108 | ||
2109 | [STD14] Partridge, C., "Mail Routing and the Domain System", STD | |
2110 | 14, RFC 974, January 1986. | |
2111 | ||
2112 | 7. Editor's Address | |
2113 | ||
2114 | Peter W. Resnick | |
2115 | QUALCOMM Incorporated | |
2116 | 5775 Morehouse Drive | |
2117 | San Diego, CA 92121-1714 | |
2118 | USA | |
2119 | ||
2120 | Phone: +1 858 651 4478 | |
2121 | Fax: +1 858 651 1102 | |
2122 | EMail: presnick@qualcomm.com | |
2123 | ||
2124 | ||
2125 | ||
2126 | ||
2127 | ||
2128 | ||
2129 | ||
2130 | Resnick Standards Track [Page 38] | |
2131 | \f | |
2132 | RFC 2822 Internet Message Format April 2001 | |
2133 | ||
2134 | ||
2135 | 8. Acknowledgements | |
2136 | ||
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: | |
2145 | ||
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 | |
2183 | ||
2184 | ||
2185 | ||
2186 | Resnick Standards Track [Page 39] | |
2187 | \f | |
2188 | RFC 2822 Internet Message Format April 2001 | |
2189 | ||
2190 | ||
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 | |
2200 | ||
2201 | ||
2202 | ||
2203 | ||
2204 | ||
2205 | ||
2206 | ||
2207 | ||
2208 | ||
2209 | ||
2210 | ||
2211 | ||
2212 | ||
2213 | ||
2214 | ||
2215 | ||
2216 | ||
2217 | ||
2218 | ||
2219 | ||
2220 | ||
2221 | ||
2222 | ||
2223 | ||
2224 | ||
2225 | ||
2226 | ||
2227 | ||
2228 | ||
2229 | ||
2230 | ||
2231 | ||
2232 | ||
2233 | ||
2234 | ||
2235 | ||
2236 | ||
2237 | ||
2238 | ||
2239 | ||
2240 | ||
2241 | ||
2242 | Resnick Standards Track [Page 40] | |
2243 | \f | |
2244 | RFC 2822 Internet Message Format April 2001 | |
2245 | ||
2246 | ||
2247 | Appendix A. Example messages | |
2248 | ||
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 | |
2255 | correct. | |
2256 | ||
2257 | Messages are delimited in this section between lines of "----". The | |
2258 | "----" lines are not part of the message itself. | |
2259 | ||
2260 | A.1. Addressing examples | |
2261 | ||
2262 | The following are examples of messages that might be sent between two | |
2263 | individuals. | |
2264 | ||
2265 | A.1.1. A message from one person to another with simple addressing | |
2266 | ||
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. | |
2270 | ||
2271 | ---- | |
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> | |
2277 | ||
2278 | This is a message just to say hello. | |
2279 | So, "Hello". | |
2280 | ---- | |
2281 | ||
2282 | ||
2283 | ||
2284 | ||
2285 | ||
2286 | ||
2287 | ||
2288 | ||
2289 | ||
2290 | ||
2291 | ||
2292 | ||
2293 | ||
2294 | ||
2295 | ||
2296 | ||
2297 | ||
2298 | Resnick Standards Track [Page 41] | |
2299 | \f | |
2300 | RFC 2822 Internet Message Format April 2001 | |
2301 | ||
2302 | ||
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: | |
2306 | ||
2307 | ---- | |
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> | |
2314 | ||
2315 | This is a message just to say hello. | |
2316 | So, "Hello". | |
2317 | ---- | |
2318 | ||
2319 | A.1.2. Different types of mailboxes | |
2320 | ||
2321 | This message includes multiple addresses in the destination fields | |
2322 | and also uses several different forms of addresses. | |
2323 | ||
2324 | ---- | |
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> | |
2330 | ||
2331 | Hi everyone. | |
2332 | ---- | |
2333 | ||
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. | |
2343 | ||
2344 | ||
2345 | ||
2346 | ||
2347 | ||
2348 | ||
2349 | ||
2350 | ||
2351 | ||
2352 | ||
2353 | ||
2354 | Resnick Standards Track [Page 42] | |
2355 | \f | |
2356 | RFC 2822 Internet Message Format April 2001 | |
2357 | ||
2358 | ||
2359 | A.1.3. Group addresses | |
2360 | ||
2361 | ---- | |
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> | |
2367 | ||
2368 | Testing. | |
2369 | ---- | |
2370 | ||
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. | |
2374 | ||
2375 | A.2. Reply messages | |
2376 | ||
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. | |
2381 | ||
2382 | Note especially the "Message-ID:", "References:", and "In-Reply-To:" | |
2383 | fields in each message. | |
2384 | ||
2385 | ---- | |
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> | |
2391 | ||
2392 | This is a message just to say hello. | |
2393 | So, "Hello". | |
2394 | ---- | |
2395 | ||
2396 | ||
2397 | ||
2398 | ||
2399 | ||
2400 | ||
2401 | ||
2402 | ||
2403 | ||
2404 | ||
2405 | ||
2406 | ||
2407 | ||
2408 | ||
2409 | ||
2410 | Resnick Standards Track [Page 43] | |
2411 | \f | |
2412 | RFC 2822 Internet Message Format April 2001 | |
2413 | ||
2414 | ||
2415 | When sending replies, the Subject field is often retained, though | |
2416 | prepended with "Re: " as described in section 3.6.5. | |
2417 | ||
2418 | ---- | |
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> | |
2427 | ||
2428 | This is a reply to your hello. | |
2429 | ---- | |
2430 | ||
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. | |
2434 | ||
2435 | ---- | |
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> | |
2443 | ||
2444 | This is a reply to your reply. | |
2445 | ---- | |
2446 | ||
2447 | A.3. Resent messages | |
2448 | ||
2449 | Start with the message that has been used as an example several | |
2450 | times: | |
2451 | ||
2452 | ---- | |
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> | |
2458 | ||
2459 | This is a message just to say hello. | |
2460 | So, "Hello". | |
2461 | ---- | |
2462 | ||
2463 | ||
2464 | ||
2465 | ||
2466 | Resnick Standards Track [Page 44] | |
2467 | \f | |
2468 | RFC 2822 Internet Message Format April 2001 | |
2469 | ||
2470 | ||
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: | |
2478 | ||
2479 | ---- | |
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> | |
2489 | ||
2490 | This is a message just to say hello. | |
2491 | So, "Hello". | |
2492 | ---- | |
2493 | ||
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 | |
2496 | and send that. | |
2497 | ||
2498 | ||
2499 | ||
2500 | ||
2501 | ||
2502 | ||
2503 | ||
2504 | ||
2505 | ||
2506 | ||
2507 | ||
2508 | ||
2509 | ||
2510 | ||
2511 | ||
2512 | ||
2513 | ||
2514 | ||
2515 | ||
2516 | ||
2517 | ||
2518 | ||
2519 | ||
2520 | ||
2521 | ||
2522 | Resnick Standards Track [Page 45] | |
2523 | \f | |
2524 | RFC 2822 Internet Message Format April 2001 | |
2525 | ||
2526 | ||
2527 | A.4. Messages with trace fields | |
2528 | ||
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 | |
2533 | can be long. | |
2534 | ||
2535 | ---- | |
2536 | Received: from x.y.test | |
2537 | by example.net | |
2538 | via TCP | |
2539 | with ESMTP | |
2540 | id ABC12345 | |
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> | |
2548 | ||
2549 | This is a message just to say hello. | |
2550 | So, "Hello". | |
2551 | ---- | |
2552 | ||
2553 | ||
2554 | ||
2555 | ||
2556 | ||
2557 | ||
2558 | ||
2559 | ||
2560 | ||
2561 | ||
2562 | ||
2563 | ||
2564 | ||
2565 | ||
2566 | ||
2567 | ||
2568 | ||
2569 | ||
2570 | ||
2571 | ||
2572 | ||
2573 | ||
2574 | ||
2575 | ||
2576 | ||
2577 | ||
2578 | Resnick Standards Track [Page 46] | |
2579 | \f | |
2580 | RFC 2822 Internet Message Format April 2001 | |
2581 | ||
2582 | ||
2583 | A.5. White space, comments, and other oddities | |
2584 | ||
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 | |
2588 | fields. | |
2589 | ||
2590 | ---- | |
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>, | |
2594 | joe@example.org, | |
2595 | John <jdoe@one.test> (my dear friend); (the end of the group) | |
2596 | Cc:(Empty list)(start)Undisclosed recipients :(nobody(that I know)) ; | |
2597 | Date: Thu, | |
2598 | 13 | |
2599 | Feb | |
2600 | 1969 | |
2601 | 23:32 | |
2602 | -0330 (Newfoundland Time) | |
2603 | Message-ID: <testabcd.1234@silly.test> | |
2604 | ||
2605 | Testing. | |
2606 | ---- | |
2607 | ||
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. | |
2620 | ||
2621 | A.6. Obsoleted forms | |
2622 | ||
2623 | The following are examples of obsolete (that is, the "MUST NOT | |
2624 | generate") syntactic elements described in section 4 of this | |
2625 | document. | |
2626 | ||
2627 | ||
2628 | ||
2629 | ||
2630 | ||
2631 | ||
2632 | ||
2633 | ||
2634 | Resnick Standards Track [Page 47] | |
2635 | \f | |
2636 | RFC 2822 Internet Message Format April 2001 | |
2637 | ||
2638 | ||
2639 | A.6.1. Obsolete addressing | |
2640 | ||
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. | |
2645 | ||
2646 | ---- | |
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> | |
2651 | ||
2652 | Hi everyone. | |
2653 | ---- | |
2654 | ||
2655 | A.6.2. Obsolete dates | |
2656 | ||
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. | |
2661 | ||
2662 | ---- | |
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> | |
2668 | ||
2669 | This is a message just to say hello. | |
2670 | So, "Hello". | |
2671 | ---- | |
2672 | ||
2673 | A.6.3. Obsolete white space and comments | |
2674 | ||
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. | |
2678 | ||
2679 | ||
2680 | ||
2681 | ||
2682 | ||
2683 | ||
2684 | ||
2685 | ||
2686 | ||
2687 | ||
2688 | ||
2689 | ||
2690 | Resnick Standards Track [Page 48] | |
2691 | \f | |
2692 | RFC 2822 Internet Message Format April 2001 | |
2693 | ||
2694 | ||
2695 | ---- | |
2696 | From : John Doe <jdoe@machine(comment). example> | |
2697 | To : Mary Smith | |
2698 | __ | |
2699 | <mary@example.net> | |
2700 | Subject : Saying Hello | |
2701 | Date : Fri, 21 Nov 1997 09(comment): 55 : 06 -0600 | |
2702 | Message-ID : <1234 @ local(blah) .machine .example> | |
2703 | ||
2704 | This is a message just to say hello. | |
2705 | So, "Hello". | |
2706 | ---- | |
2707 | ||
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 | |
2713 | obsolete syntax. | |
2714 | ||
2715 | Appendix B. Differences from earlier standards | |
2716 | ||
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 | |
2721 | generated. | |
2722 | ||
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.* | |
2743 | ||
2744 | ||
2745 | ||
2746 | Resnick Standards Track [Page 49] | |
2747 | \f | |
2748 | RFC 2822 Internet Message Format April 2001 | |
2749 | ||
2750 | ||
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. | |
2762 | ||
2763 | Appendix C. Notices | |
2764 | ||
2765 | Intellectual Property | |
2766 | ||
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. | |
2780 | ||
2781 | ||
2782 | ||
2783 | ||
2784 | ||
2785 | ||
2786 | ||
2787 | ||
2788 | ||
2789 | ||
2790 | ||
2791 | ||
2792 | ||
2793 | ||
2794 | ||
2795 | ||
2796 | ||
2797 | ||
2798 | ||
2799 | ||
2800 | ||
2801 | ||
2802 | Resnick Standards Track [Page 50] | |
2803 | \f | |
2804 | RFC 2822 Internet Message Format April 2001 | |
2805 | ||
2806 | ||
2807 | Full Copyright Statement | |
2808 | ||
2809 | Copyright (C) The Internet Society (2001). All Rights Reserved. | |
2810 | ||
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 | |
2823 | English. | |
2824 | ||
2825 | The limited permissions granted above are perpetual and will not be | |
2826 | revoked by the Internet Society or its successors or assigns. | |
2827 | ||
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. | |
2834 | ||
2835 | Acknowledgement | |
2836 | ||
2837 | Funding for the RFC Editor function is currently provided by the | |
2838 | Internet Society. | |
2839 | ||
2840 | ||
2841 | ||
2842 | ||
2843 | ||
2844 | ||
2845 | ||
2846 | ||
2847 | ||
2848 | ||
2849 | ||
2850 | ||
2851 | ||
2852 | ||
2853 | ||
2854 | ||
2855 | ||
2856 | ||
2857 | ||
2858 | Resnick Standards Track [Page 51] | |
2859 | \f |