rfc2822 April 2001
[TOC]
8. Acknowledgements
Many people contributed to this document. They included folks who
participated in the Detailed Revision and Update of Messaging
Standards (DRUMS) Working Group of the Internet Engineering Task
Force (IETF), the chair of DRUMS, the Area Directors of the IETF, and
people who simply sent their comments in via e-mail. The editor is
deeply indebted to them all and thanks them sincerely. The below
list includes everyone who sent e-mail concerning this document.
Hopefully, everyone who contributed is named here:
Matti Aarnio Barry Finkel Larry Masinter
Tanaka Akira Erik Forsberg Denis McKeon
Russ Allbery Chuck Foster William P McQuillan
Eric Allman Paul Fox Alexey Melnikov
Harald Tveit Alvestrand Klaus M. Frank Perry E. Metzger
Ran Atkinson Ned Freed Steven Miller
Jos Backus Jochen Friedrich Keith Moore
Bruce Balden Randall C. Gellens John Gardiner Myers
Dave Barr Sukvinder Singh Gill Chris Newman
Alan Barrett Tim Goodwin John W. Noerenberg
John Beck Philip Guenther Eric Norman
J. Robert von Behren Tony Hansen Mike O'Dell
Jos den Bekker John Hawkinson Larry Osterman
D. J. Bernstein Philip Hazel Paul Overell
James Berriman Kai Henningsen Jacob Palme
Norbert Bollow Robert Herriot Michael A. Patton
Raj Bose Paul Hethmon Uzi Paz
Antony Bowesman Jim Hill Michael A. Quinlan
Scott Bradner Paul E. Hoffman Eric S. Raymond
Randy Bush Steve Hole Sam Roberts
Tom Byrer Kari Hurtta Hugh Sasse
Bruce Campbell Marco S. Hyman Bart Schaefer
Larry Campbell Ofer Inbar Tom Scola
W. J. Carpenter Olle Jarnefors Wolfgang Segmuller
Michael Chapman Kevin Johnson Nick Shelness
Richard Clayton Sudish Joseph John Stanley
Maurizio Codogno Maynard Kang Einar Stefferud
Jim Conklin Prabhat Keni Jeff Stephenson
R. Kelley Cook John C. Klensin Bernard Stern
Steve Coya Graham Klyne Peter Sylvester
Mark Crispin Brad Knowles Mark Symons
Dave Crocker Shuhei Kobayashi Eric Thomas
Matt Curtin Peter Koch Lee Thompson
Michael D'Errico Dan Kohn Karel De Vriendt
Cyrus Daboo Christian Kuhtz Matthew Wall
Jutta Degener Anand Kumria Rolf Weber
Mark Delany Steen Larsen Brent B. Welch
Steve Dorner Eliot Lear Dan Wing
Harold A. Driscoll Barry Leiba Jack De Winter
Michael Elkins Jay Levitt Gregory J. Woodhouse
Robert Elz Lars-Johan Liman Greg A. Woods
Johnny Eriksson Charles Lindsey Kazu Yamamoto
Erik E. Fair Pete Loshin Alain Zahm
Roger Fajman Simon Lyall Jamie Zawinski
Patrik Faltstrom Bill Manning Timothy S. Zurcher
Claus Andre Farber John Martin
Appendix A. Example messages
This section presents a selection of messages. These are intended to
assist in the implementation of this standard, but should not be
taken as normative; that is to say, although the examples in this
section were carefully reviewed, if there happens to be a conflict
between these examples and the syntax described in sections 3 and 4
of this document, the syntax in those sections is to be taken as
correct.
Messages are delimited in this section between lines of "----". The
"----" lines are not part of the message itself.
A.1. Addressing examples
The following are examples of messages that might be sent between two
individuals.
A.1.1. A message from one person to another with simple addressing
This could be called a canonical message. It has a single author,
John Doe, a single recipient, Mary Smith, a subject, the date, a
message identifier, and a textual message in the body.
----
From: John Doe <jdoe@machine.example>
To: Mary Smith <mary@example.net>
Subject: Saying Hello
Date: Fri, 21 Nov 1997 09:55:06 -0600
Message-ID: <1234@local.machine.example>
This is a message just to say hello.
So, "Hello".
----
If John's secretary Michael actually sent the message, though John
was the author and replies to this message should go back to him, the
sender field would be used:
----
From: John Doe <jdoe@machine.example>
Sender: Michael Jones <mjones@machine.example>
To: Mary Smith <mary@example.net>
Subject: Saying Hello
Date: Fri, 21 Nov 1997 09:55:06 -0600
Message-ID: <1234@local.machine.example>
This is a message just to say hello.
So, "Hello".
----
A.1.2. Different types of mailboxes
This message includes multiple addresses in the destination fields
and also uses several different forms of addresses.
----
From: "Joe Q. Public" <john.q.public@example.com>
To: Mary Smith <mary@x.test>, jdoe@example.org, Who? <one@y.test>
Cc: <boss@nil.test>, "Giant; \"Big\" Box" <sysservices@example.net>
Date: Tue, 1 Jul 2003 10:52:37 +0200
Message-ID: <5678.21-Nov-1997@example.com>
Hi everyone.
----
Note that the display names for Joe Q. Public and Giant; "Big" Box
needed to be enclosed in double-quotes because the former contains
the period and the latter contains both semicolon and double-quote
characters (the double-quote characters appearing as quoted-pair
construct). Conversely, the display name for Who? could appear
without them because the question mark is legal in an atom. Notice
also that jdoe@example.org and boss@nil.test have no display names
associated with them at all, and jdoe@example.org uses the simpler
address form without the angle brackets.
A.1.3. Group addresses
----
From: Pete <pete@silly.example>
To: A Group:Chris Jones <c@a.test>,joe@where.test,John <jdoe@one.test>;
Cc: Undisclosed recipients:;
Date: Thu, 13 Feb 1969 23:32:54 -0330
Message-ID: <testabcd.1234@silly.example>
Testing.
----
In this message, the "To:" field has a single group recipient named A
Group which contains 3 addresses, and a "Cc:" field with an empty
group recipient named Undisclosed recipients.
A.2. Reply messages
The following is a series of three messages that make up a
conversation thread between John and Mary. John firsts sends a
message to Mary, Mary then replies to John's message, and then John
replies to Mary's reply message.
Note especially the "Message-ID:", "References:", and "In-Reply-To:"
fields in each message.
----
From: John Doe <jdoe@machine.example>
To: Mary Smith <mary@example.net>
Subject: Saying Hello
Date: Fri, 21 Nov 1997 09:55:06 -0600
Message-ID: <1234@local.machine.example>
This is a message just to say hello.
So, "Hello".
----
When sending replies, the Subject field is often retained, though
prepended with "Re: " as described in section 3.6.5.
----
From: Mary Smith <mary@example.net>
To: John Doe <jdoe@machine.example>
Reply-To: "Mary Smith: Personal Account" <smith@home.example>
Subject: Re: Saying Hello
Date: Fri, 21 Nov 1997 10:01:10 -0600
Message-ID: <3456@example.net>
In-Reply-To: <1234@local.machine.example>
References: <1234@local.machine.example>
This is a reply to your hello.
----
Note the "Reply-To:" field in the above message. When John replies
to Mary's message above, the reply should go to the address in the
"Reply-To:" field instead of the address in the "From:" field.
----
To: "Mary Smith: Personal Account" <smith@home.example>
From: John Doe <jdoe@machine.example>
Subject: Re: Saying Hello
Date: Fri, 21 Nov 1997 11:00:00 -0600
Message-ID: <abcd.1234@local.machine.tld>
In-Reply-To: <3456@example.net>
References: <1234@local.machine.example> <3456@example.net>
This is a reply to your reply.
----
A.3. Resent messages
Start with the message that has been used as an example several
times:
----
From: John Doe <jdoe@machine.example>
To: Mary Smith <mary@example.net>
Subject: Saying Hello
Date: Fri, 21 Nov 1997 09:55:06 -0600
Message-ID: <1234@local.machine.example>
This is a message just to say hello.
So, "Hello".
----
Say that Mary, upon receiving this message, wishes to send a copy of
the message to Jane such that (a) the message would appear to have
come straight from John; (b) if Jane replies to the message, the
reply should go back to John; and (c) all of the original
information, like the date the message was originally sent to Mary,
the message identifier, and the original addressee, is preserved. In
this case, resent fields are prepended to the message:
----
Resent-From: Mary Smith <mary@example.net>
Resent-To: Jane Brown <j-brown@other.example>
Resent-Date: Mon, 24 Nov 1997 14:22:01 -0800
Resent-Message-ID: <78910@example.net>
From: John Doe <jdoe@machine.example>
To: Mary Smith <mary@example.net>
Subject: Saying Hello
Date: Fri, 21 Nov 1997 09:55:06 -0600
Message-ID: <1234@local.machine.example>
This is a message just to say hello.
So, "Hello".
----
If Jane, in turn, wished to resend this message to another person,
she would prepend her own set of resent header fields to the above
and send that.
A.4. Messages with trace fields
As messages are sent through the transport system as described in
[RFC2821], trace fields are prepended to the message. The following
is an example of what those trace fields might look like. Note that
there is some folding white space in the first one since these lines
can be long.
----
Received: from x.y.test
by example.net
via TCP
with ESMTP
id ABC12345
for <mary@example.net>; 21 Nov 1997 10:05:43 -0600
Received: from machine.example by x.y.test; 21 Nov 1997 10:01:22 -0600
From: John Doe <jdoe@machine.example>
To: Mary Smith <mary@example.net>
Subject: Saying Hello
Date: Fri, 21 Nov 1997 09:55:06 -0600
Message-ID: <1234@local.machine.example>
This is a message just to say hello.
So, "Hello".
----
A.5. White space, comments, and other oddities
White space, including folding white space, and comments can be
inserted between many of the tokens of fields. Taking the example
from A.1.3, white space and comments can be inserted into all of the
fields.
----
From: Pete(A wonderful \) chap) <pete(his account)@silly.test(his host)>
To:A Group(Some people)
:Chris Jones <c@(Chris's host.)public.example>,
joe@example.org,
John <jdoe@one.test> (my dear friend); (the end of the group)
Cc:(Empty list)(start)Undisclosed recipients :(nobody(that I know)) ;
Date: Thu,
13
Feb
1969
23:32
-0330 (Newfoundland Time)
Message-ID: <testabcd.1234@silly.test>
Testing.
----
The above example is aesthetically displeasing, but perfectly legal.
Note particularly (1) the comments in the "From:" field (including
one that has a ")" character appearing as part of a quoted-pair); (2)
the white space absent after the ":" in the "To:" field as well as
the comment and folding white space after the group name, the special
character (".") in the comment in Chris Jones's address, and the
folding white space before and after "joe@example.org,"; (3) the
multiple and nested comments in the "Cc:" field as well as the
comment immediately following the ":" after "Cc"; (4) the folding
white space (but no comments except at the end) and the missing
seconds in the time of the date field; and (5) the white space before
(but not within) the identifier in the "Message-ID:" field.
A.6. Obsoleted forms
The following are examples of obsolete (that is, the "MUST NOT
generate") syntactic elements described in section 4 of this
document.
A.6.1. Obsolete addressing
Note in the below example the lack of quotes around Joe Q. Public,
the route that appears in the address for Mary Smith, the two commas
that appear in the "To:" field, and the spaces that appear around the
"." in the jdoe address.
----
From: Joe Q. Public <john.q.public@example.com>
To: Mary Smith <@machine.tld:mary@example.net>, , jdoe@test . example
Date: Tue, 1 Jul 2003 10:52:37 +0200
Message-ID: <5678.21-Nov-1997@example.com>
Hi everyone.
----
A.6.2. Obsolete dates
The following message uses an obsolete date format, including a non-
numeric time zone and a two digit year. Note that although the
day-of-week is missing, that is not specific to the obsolete syntax;
it is optional in the current syntax as well.
----
From: John Doe <jdoe@machine.example>
To: Mary Smith <mary@example.net>
Subject: Saying Hello
Date: 21 Nov 97 09:55:06 GMT
Message-ID: <1234@local.machine.example>
This is a message just to say hello.
So, "Hello".
----
A.6.3. Obsolete white space and comments
White space and comments can appear between many more elements than
in the current syntax. Also, folding lines that are made up entirely
of white space are legal.
----
From : John Doe <jdoe@machine(comment). example>
To : Mary Smith
__
<mary@example.net>
Subject : Saying Hello
Date : Fri, 21 Nov 1997 09(comment): 55 : 06 -0600
Message-ID : <1234 @ local(blah) .machine .example>
This is a message just to say hello.
So, "Hello".
----
Note especially the second line of the "To:" field. It starts with
two space characters. (Note that "__" represent blank spaces.)
Therefore, it is considered part of the folding as described in
section 4.2. Also, the comments and white space throughout
addresses, dates, and message identifiers are all part of the
obsolete syntax.
Appendix B. Differences from earlier standards
This appendix contains a list of changes that have been made in the
Internet Message Format from earlier standards, specifically [RFC822]
and [STD3]. Items marked with an asterisk (*) below are items which
appear in section 4 of this document and therefore can no longer be
generated.
1. Period allowed in obsolete form of phrase.
2. ABNF moved out of document to [RFC2234].
3. Four or more digits allowed for year.
4. Header field ordering (and lack thereof) made explicit.
5. Encrypted header field removed.
6. Received syntax loosened to allow any token/value pair.
7. Specifically allow and give meaning to "-0000" time zone.
8. Folding white space is not allowed between every token.
9. Requirement for destinations removed.
10. Forwarding and resending redefined.
11. Extension header fields no longer specifically called out.
12. ASCII 0 (null) removed.*
13. Folding continuation lines cannot contain only white space.*
14. Free insertion of comments not allowed in date.*
15. Non-numeric time zones not allowed.*
16. Two digit years not allowed.*
17. Three digit years interpreted, but not allowed for generation.
18. Routes in addresses not allowed.*
19. CFWS within local-parts and domains not allowed.*
20. Empty members of address lists not allowed.*
21. Folding white space between field name and colon not allowed.*
22. Comments between field name and colon not allowed.
23. Tightened syntax of in-reply-to and references.*
24. CFWS within msg-id not allowed.*
25. Tightened semantics of resent fields as informational only.
26. Resent-Reply-To not allowed.*
27. No multiple occurrences of fields (except resent and received).*
28. Free CR and LF not allowed.*
29. Routes in return path not allowed.*
30. Line length limits specified.
31. Bcc more clearly specified.
Appendix C. Notices
Intellectual Property
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
[TOC]
#Diff to first older