Merge branch 'master' of ozlabs.org:ccan

ccan/rfc822/rfc5322.txt

@@ -0,0 +1,3195 @@
+
+
+
+
+
+
+Network Working Group                                    P. Resnick, Ed.
+Request for Comments: 5322                         Qualcomm Incorporated
+Obsoletes: 2822                                             October 2008
+Updates: 4021
+Category: Standards Track
+
+
+                        Internet Message Format
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Abstract
+
+   This document specifies the Internet Message Format (IMF), a syntax
+   for text messages that are sent between computer users, within the
+   framework of "electronic mail" messages.  This specification is a
+   revision of Request For Comments (RFC) 2822, which itself superseded
+   Request For Comments (RFC) 822, "Standard for the Format of ARPA
+   Internet Text Messages", updating it to reflect current practice and
+   incorporating incremental changes that were specified in other RFCs.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Resnick                     Standards Track                     [Page 1]
+
+RFC 5322                Internet Message Format             October 2008
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
+     1.1.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . .  4
+     1.2.  Notational Conventions . . . . . . . . . . . . . . . . . .  5
+       1.2.1.  Requirements Notation  . . . . . . . . . . . . . . . .  5
+       1.2.2.  Syntactic Notation . . . . . . . . . . . . . . . . . .  5
+       1.2.3.  Structure of This Document . . . . . . . . . . . . . .  5
+   2.  Lexical Analysis of Messages . . . . . . . . . . . . . . . . .  6
+     2.1.  General Description  . . . . . . . . . . . . . . . . . . .  6
+       2.1.1.  Line Length Limits . . . . . . . . . . . . . . . . . .  7
+     2.2.  Header Fields  . . . . . . . . . . . . . . . . . . . . . .  8
+       2.2.1.  Unstructured Header Field Bodies . . . . . . . . . . .  8
+       2.2.2.  Structured Header Field Bodies . . . . . . . . . . . .  8
+       2.2.3.  Long Header Fields . . . . . . . . . . . . . . . . . .  8
+     2.3.  Body . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
+   3.  Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
+     3.1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . 10
+     3.2.  Lexical Tokens . . . . . . . . . . . . . . . . . . . . . . 10
+       3.2.1.  Quoted characters  . . . . . . . . . . . . . . . . . . 10
+       3.2.2.  Folding White Space and Comments . . . . . . . . . . . 11
+       3.2.3.  Atom . . . . . . . . . . . . . . . . . . . . . . . . . 12
+       3.2.4.  Quoted Strings . . . . . . . . . . . . . . . . . . . . 13
+       3.2.5.  Miscellaneous Tokens . . . . . . . . . . . . . . . . . 14
+     3.3.  Date and Time Specification  . . . . . . . . . . . . . . . 14
+     3.4.  Address Specification  . . . . . . . . . . . . . . . . . . 16
+       3.4.1.  Addr-Spec Specification  . . . . . . . . . . . . . . . 17
+     3.5.  Overall Message Syntax . . . . . . . . . . . . . . . . . . 18
+     3.6.  Field Definitions  . . . . . . . . . . . . . . . . . . . . 19
+       3.6.1.  The Origination Date Field . . . . . . . . . . . . . . 22
+       3.6.2.  Originator Fields  . . . . . . . . . . . . . . . . . . 22
+       3.6.3.  Destination Address Fields . . . . . . . . . . . . . . 23
+       3.6.4.  Identification Fields  . . . . . . . . . . . . . . . . 25
+       3.6.5.  Informational Fields . . . . . . . . . . . . . . . . . 27
+       3.6.6.  Resent Fields  . . . . . . . . . . . . . . . . . . . . 28
+       3.6.7.  Trace Fields . . . . . . . . . . . . . . . . . . . . . 30
+       3.6.8.  Optional Fields  . . . . . . . . . . . . . . . . . . . 30
+   4.  Obsolete Syntax  . . . . . . . . . . . . . . . . . . . . . . . 31
+     4.1.  Miscellaneous Obsolete Tokens  . . . . . . . . . . . . . . 32
+     4.2.  Obsolete Folding White Space . . . . . . . . . . . . . . . 33
+     4.3.  Obsolete Date and Time . . . . . . . . . . . . . . . . . . 33
+     4.4.  Obsolete Addressing  . . . . . . . . . . . . . . . . . . . 35
+     4.5.  Obsolete Header Fields . . . . . . . . . . . . . . . . . . 35
+       4.5.1.  Obsolete Origination Date Field  . . . . . . . . . . . 36
+       4.5.2.  Obsolete Originator Fields . . . . . . . . . . . . . . 36
+       4.5.3.  Obsolete Destination Address Fields  . . . . . . . . . 37
+       4.5.4.  Obsolete Identification Fields . . . . . . . . . . . . 37
+       4.5.5.  Obsolete Informational Fields  . . . . . . . . . . . . 37
+
+
+
+Resnick                     Standards Track                     [Page 2]
+
+RFC 5322                Internet Message Format             October 2008
+
+
+       4.5.6.  Obsolete Resent Fields . . . . . . . . . . . . . . . . 38
+       4.5.7.  Obsolete Trace Fields  . . . . . . . . . . . . . . . . 38
+       4.5.8.  Obsolete optional fields . . . . . . . . . . . . . . . 38
+   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 38
+   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 39
+   Appendix A.     Example Messages . . . . . . . . . . . . . . . . . 43
+   Appendix A.1.   Addressing Examples  . . . . . . . . . . . . . . . 44
+   Appendix A.1.1. A Message from One Person to Another with
+                   Simple Addressing  . . . . . . . . . . . . . . . . 44
+   Appendix A.1.2. Different Types of Mailboxes . . . . . . . . . . . 45
+   Appendix A.1.3. Group Addresses  . . . . . . . . . . . . . . . . . 45
+   Appendix A.2.   Reply Messages . . . . . . . . . . . . . . . . . . 46
+   Appendix A.3.   Resent Messages  . . . . . . . . . . . . . . . . . 47
+   Appendix A.4.   Messages with Trace Fields . . . . . . . . . . . . 48
+   Appendix A.5.   White Space, Comments, and Other Oddities  . . . . 49
+   Appendix A.6.   Obsoleted Forms  . . . . . . . . . . . . . . . . . 50
+   Appendix A.6.1. Obsolete Addressing  . . . . . . . . . . . . . . . 50
+   Appendix A.6.2. Obsolete Dates . . . . . . . . . . . . . . . . . . 50
+   Appendix A.6.3. Obsolete White Space and Comments  . . . . . . . . 51
+   Appendix B.     Differences from Earlier Specifications  . . . . . 52
+   Appendix C.     Acknowledgements . . . . . . . . . . . . . . . . . 53
+   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 55
+     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 55
+     7.2.  Informative References . . . . . . . . . . . . . . . . . . 55
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Resnick                     Standards Track                     [Page 3]
+
+RFC 5322                Internet Message Format             October 2008
+
+
+1.  Introduction
+
+1.1.  Scope
+
+   This document specifies the Internet Message Format (IMF), a syntax
+   for text messages that are sent between computer users, within the
+   framework of "electronic mail" messages.  This specification is an
+   update to [RFC2822], which itself superseded [RFC0822], updating it
+   to reflect current practice and incorporating incremental changes
+   that were specified in other RFCs such as [RFC1123].
+
+   This document specifies a syntax only for text messages.  In
+   particular, it makes no provision for the transmission of images,
+   audio, or other sorts of structured data in electronic mail messages.
+   There are several extensions published, such as the MIME document
+   series ([RFC2045], [RFC2046], [RFC2049]), which describe mechanisms
+   for the transmission of such data through electronic mail, either by
+   extending the syntax provided here or by structuring such messages to
+   conform to this syntax.  Those mechanisms are outside of the scope of
+   this specification.
+
+   In the context of electronic mail, messages are viewed as having an
+   envelope and contents.  The envelope contains whatever information is
+   needed to accomplish transmission and delivery.  (See [RFC5321] for a
+   discussion of the envelope.)  The contents comprise the object to be
+   delivered to the recipient.  This specification applies only to the
+   format and some of the semantics of message contents.  It contains no
+   specification of the information in the envelope.
+
+   However, some message systems may use information from the contents
+   to create the envelope.  It is intended that this specification
+   facilitate the acquisition of such information by programs.
+
+   This specification is intended as a definition of what message
+   content format is to be passed between systems.  Though some message
+   systems locally store messages in this format (which eliminates the
+   need for translation between formats) and others use formats that
+   differ from the one specified in this specification, local storage is
+   outside of the scope of this specification.
+
+      Note: This specification is not intended to dictate the internal
+      formats used by sites, the specific message system features that
+      they are expected to support, or any of the characteristics of
+      user interface programs that create or read messages.  In
+      addition, this document does not specify an encoding of the
+      characters for either transport or storage; that is, it does not
+      specify the number of bits used or how those bits are specifically
+      transferred over the wire or stored on disk.
+
+
+
+Resnick                     Standards Track                     [Page 4]
+
+RFC 5322                Internet Message Format             October 2008
+
+
+1.2.  Notational Conventions
+
+1.2.1.  Requirements Notation
+
+   This document occasionally uses terms that appear in capital letters.
+   When the terms "MUST", "SHOULD", "RECOMMENDED", "MUST NOT", "SHOULD
+   NOT", and "MAY" appear capitalized, they are being used to indicate
+   particular requirements of this specification.  A discussion of the
+   meanings of these terms appears in [RFC2119].
+
+1.2.2.  Syntactic Notation
+
+   This specification uses the Augmented Backus-Naur Form (ABNF)
+   [RFC5234] notation for the formal definitions of the syntax of
+   messages.  Characters will be specified either by a decimal value
+   (e.g., the value %d65 for uppercase A and %d97 for lowercase A) or by
+   a case-insensitive literal value enclosed in quotation marks (e.g.,
+   "A" for either uppercase or lowercase A).
+
+1.2.3.  Structure of This Document
+
+   This document is divided into several sections.
+
+   This section, section 1, is a short introduction to the document.
+
+   Section 2 lays out the general description of a message and its
+   constituent parts.  This is an overview to help the reader understand
+   some of the general principles used in the later portions of this
+   document.  Any examples in this section MUST NOT be taken as
+   specification of the formal syntax of any part of a message.
+
+   Section 3 specifies formal ABNF rules for the structure of each part
+   of a message (the syntax) and describes the relationship between
+   those parts and their meaning in the context of a message (the
+   semantics).  That is, it lays out the actual rules for the structure
+   of each part of a message (the syntax) as well as a description of
+   the parts and instructions for their interpretation (the semantics).
+   This includes analysis of the syntax and semantics of subparts of
+   messages that have specific structure.  The syntax included in
+   section 3 represents messages as they MUST be created.  There are
+   also notes in section 3 to indicate if any of the options specified
+   in the syntax SHOULD be used over any of the others.
+
+   Both sections 2 and 3 describe messages that are legal to generate
+   for purposes of this specification.
+
+
+
+
+
+
+Resnick                     Standards Track                     [Page 5]
+
+RFC 5322                Internet Message Format             October 2008
+
+
+   Section 4 of this document specifies an "obsolete" syntax.  There are
+   references in section 3 to these obsolete syntactic elements.  The
+   rules of the obsolete syntax are elements that have appeared in
+   earlier versions of this specification or have previously been widely
+   used in Internet messages.  As such, these elements MUST be
+   interpreted by parsers of messages in order to be conformant to this
+   specification.  However, since items in this syntax have been
+   determined to be non-interoperable or to cause significant problems
+   for recipients of messages, they MUST NOT be generated by creators of
+   conformant messages.
+
+   Section 5 details security considerations to take into account when
+   implementing this specification.
+
+   Appendix A lists examples of different sorts of messages.  These
+   examples are not exhaustive of the types of messages that appear on
+   the Internet, but give a broad overview of certain syntactic forms.
+
+   Appendix B lists the differences between this specification and
+   earlier specifications for Internet messages.
+
+   Appendix C contains acknowledgements.
+
+2.  Lexical Analysis of Messages
+
+2.1.  General Description
+
+   At the most basic level, a message is a series of characters.  A
+   message that is conformant with this specification is composed of
+   characters with values in the range of 1 through 127 and interpreted
+   as US-ASCII [ANSI.X3-4.1986] characters.  For brevity, this document
+   sometimes refers to this range of characters as simply "US-ASCII
+   characters".
+
+      Note: This document specifies that messages are made up of
+      characters in the US-ASCII range of 1 through 127.  There are
+      other documents, specifically the MIME document series ([RFC2045],
+      [RFC2046], [RFC2047], [RFC2049], [RFC4288], [RFC4289]), that
+      extend this specification to allow for values outside of that
+      range.  Discussion of those mechanisms is not within the scope of
+      this specification.
+
+   Messages are divided into lines of characters.  A line is a series of
+   characters that is delimited with the two characters carriage-return
+   and line-feed; that is, the carriage return (CR) character (ASCII
+   value 13) followed immediately by the line feed (LF) character (ASCII
+   value 10).  (The carriage return/line feed pair is usually written in
+   this document as "CRLF".)
+
+
+
+Resnick                     Standards Track                     [Page 6]
+
+RFC 5322                Internet Message Format             October 2008
+
+
+   A message consists of header fields (collectively called "the header
+   section of the message") followed, optionally, by a body.  The header
+   section is a sequence of lines of characters with special syntax as
+   defined in this specification.  The body is simply a sequence of
+   characters that follows the header section and is separated from the
+   header section by an empty line (i.e., a line with nothing preceding
+   the CRLF).
+
+      Note: Common parlance and earlier versions of this specification
+      use the term "header" to either refer to the entire header section
+      or to refer to an individual header field.  To avoid ambiguity,
+      this document does not use the terms "header" or "headers" in
+      isolation, but instead always uses "header field" to refer to the
+      individual field and "header section" to refer to the entire
+      collection.
+
+2.1.1.  Line Length Limits
+
+   There are two limits that this specification places on the number of
+   characters in a line.  Each line of characters MUST be no more than
+   998 characters, and SHOULD be no more than 78 characters, excluding
+   the CRLF.
+
+   The 998 character limit is due to limitations in many implementations
+   that send, receive, or store IMF messages which simply cannot handle
+   more than 998 characters on a line.  Receiving implementations would
+   do well to handle an arbitrarily large number of characters in a line
+   for robustness sake.  However, there are so many implementations that
+   (in compliance with the transport requirements of [RFC5321]) do not
+   accept messages containing more than 1000 characters including the CR
+   and LF per line, it is important for implementations not to create
+   such messages.
+
+   The more conservative 78 character recommendation is to accommodate
+   the many implementations of user interfaces that display these
+   messages which may truncate, or disastrously wrap, the display of
+   more than 78 characters per line, in spite of the fact that such
+   implementations are non-conformant to the intent of this
+   specification (and that of [RFC5321] if they actually cause
+   information to be lost).  Again, even though this limitation is put
+   on messages, it is incumbent upon implementations that display
+   messages to handle an arbitrarily large number of characters in a
+   line (certainly at least up to the 998 character limit) for the sake
+   of robustness.
+
+
+
+
+
+
+
+Resnick                     Standards Track                     [Page 7]
+
+RFC 5322                Internet Message Format             October 2008
+
+
+2.2.  Header Fields
+
+   Header fields are lines beginning with a field name, followed by a
+   colon (":"), followed by a field body, and terminated by CRLF.  A
+   field name MUST be composed of printable US-ASCII characters (i.e.,
+   characters that have values between 33 and 126, inclusive), except
+   colon.  A field body may be composed of printable US-ASCII characters
+   as well as the space (SP, ASCII value 32) and horizontal tab (HTAB,
+   ASCII value 9) characters (together known as the white space
+   characters, WSP).  A field body MUST NOT include CR and LF except
+   when used in "folding" and "unfolding", as described in section
+   2.2.3.  All field bodies MUST conform to the syntax described in
+   sections 3 and 4 of this specification.
+
+2.2.1.  Unstructured Header Field Bodies
+
+   Some field bodies in this specification are defined simply as
+   "unstructured" (which is specified in section 3.2.5 as any printable
+   US-ASCII characters plus white space characters) with no further
+   restrictions.  These are referred to as unstructured field bodies.
+   Semantically, unstructured field bodies are simply to be treated as a
+   single line of characters with no further processing (except for
+   "folding" and "unfolding" as described in section 2.2.3).
+
+2.2.2.  Structured Header Field Bodies
+
+   Some field bodies in this specification have a syntax that is more
+   restrictive than the unstructured field bodies described above.
+   These are referred to as "structured" field bodies.  Structured field
+   bodies are sequences of specific lexical tokens as described in
+   sections 3 and 4 of this specification.  Many of these tokens are
+   allowed (according to their syntax) to be introduced or end with
+   comments (as described in section 3.2.2) as well as the white space
+   characters, and those white space characters are subject to "folding"
+   and "unfolding" as described in section 2.2.3.  Semantic analysis of
+   structured field bodies is given along with their syntax.
+
+2.2.3.  Long Header Fields
+
+   Each header field is logically a single line of characters comprising
+   the field name, the colon, and the field body.  For convenience
+   however, and to deal with the 998/78 character limitations per line,
+   the field body portion of a header field can be split into a
+   multiple-line representation; this is called "folding".  The general
+   rule is that wherever this specification allows for folding white
+   space (not simply WSP characters), a CRLF may be inserted before any
+   WSP.
+
+
+
+
+Resnick                     Standards Track                     [Page 8]
+
+RFC 5322                Internet Message Format             October 2008
+
+
+   For example, the header field:
+
+   Subject: This is a test
+
+   can be represented as:
+
+   Subject: This
+    is a test
+
+      Note: Though structured field bodies are defined in such a way
+      that folding can take place between many of the lexical tokens
+      (and even within some of the lexical tokens), folding SHOULD be
+      limited to placing the CRLF at higher-level syntactic breaks.  For
+      instance, if a field body is defined as comma-separated values, it
+      is recommended that folding occur after the comma separating the
+      structured items in preference to other places where the field
+      could be folded, even if it is allowed elsewhere.
+
+   The process of moving from this folded multiple-line representation
+   of a header field to its single line representation is called
+   "unfolding".  Unfolding is accomplished by simply removing any CRLF
+   that is immediately followed by WSP.  Each header field should be
+   treated in its unfolded form for further syntactic and semantic
+   evaluation.  An unfolded header field has no length restriction and
+   therefore may be indeterminately long.
+
+2.3.  Body
+
+   The body of a message is simply lines of US-ASCII characters.  The
+   only two limitations on the body are as follows:
+
+   o  CR and LF MUST only occur together as CRLF; they MUST NOT appear
+      independently in the body.
+   o  Lines of characters in the body MUST be limited to 998 characters,
+      and SHOULD be limited to 78 characters, excluding the CRLF.
+
+      Note: As was stated earlier, there are other documents,
+      specifically the MIME documents ([RFC2045], [RFC2046], [RFC2049],
+      [RFC4288], [RFC4289]), that extend (and limit) this specification
+      to allow for different sorts of message bodies.  Again, these
+      mechanisms are beyond the scope of this document.
+
+
+
+
+
+
+
+
+
+
+Resnick                     Standards Track                     [Page 9]
+
+RFC 5322                Internet Message Format             October 2008
+
+
+3.  Syntax
+
+3.1.  Introduction
+
+   The syntax as given in this section defines the legal syntax of
+   Internet messages.  Messages that are conformant to this
+   specification MUST conform to the syntax in this section.  If there
+   are options in this section where one option SHOULD be generated,
+   that is indicated either in the prose or in a comment next to the
+   syntax.
+
+   For the defined expressions, a short description of the syntax and
+   use is given, followed by the syntax in ABNF, followed by a semantic
+   analysis.  The following primitive tokens that are used but otherwise
+   unspecified are taken from the "Core Rules" of [RFC5234], Appendix
+   B.1: CR, LF, CRLF, HTAB, SP, WSP, DQUOTE, DIGIT, ALPHA, and VCHAR.
+
+   In some of the definitions, there will be non-terminals whose names
+   start with "obs-".  These "obs-" elements refer to tokens defined in
+   the obsolete syntax in section 4.  In all cases, these productions
+   are to be ignored for the purposes of generating legal Internet
+   messages and MUST NOT be used as part of such a message.  However,
+   when interpreting messages, these tokens MUST be honored as part of
+   the legal syntax.  In this sense, section 3 defines a grammar for the
+   generation of messages, with "obs-" elements that are to be ignored,
+   while section 4 adds grammar for the interpretation of messages.
+
+3.2.  Lexical Tokens
+
+   The following rules are used to define an underlying lexical
+   analyzer, which feeds tokens to the higher-level parsers.  This
+   section defines the tokens used in structured header field bodies.
+
+      Note: Readers of this specification need to pay special attention
+      to how these lexical tokens are used in both the lower-level and
+      higher-level syntax later in the document.  Particularly, the
+      white space tokens and the comment tokens defined in section 3.2.2
+      get used in the lower-level tokens defined here, and those lower-
+      level tokens are in turn used as parts of the higher-level tokens
+      defined later.  Therefore, white space and comments may be allowed
+      in the higher-level tokens even though they may not explicitly
+      appear in a particular definition.
+
+3.2.1.  Quoted characters
+
+   Some characters are reserved for special interpretation, such as
+   delimiting lexical tokens.  To permit use of these characters as
+   uninterpreted data, a quoting mechanism is provided.
+
+
+
+Resnick                     Standards Track                    [Page 10]
+
+RFC 5322                Internet Message Format             October 2008
+
+
+   quoted-pair     =   ("\" (VCHAR / WSP)) / obs-qp
+
+   Where any quoted-pair appears, it is to be interpreted as the
+   character alone.  That is to say, the "\" character that appears as
+   part of a quoted-pair is semantically "invisible".
+
+      Note: The "\" character may appear in a message where it is not
+      part of a quoted-pair.  A "\" character that does not appear in a
+      quoted-pair is not semantically invisible.  The only places in
+      this specification where quoted-pair currently appears are
+      ccontent, qcontent, and in obs-dtext in section 4.
+
+3.2.2.  Folding White Space and Comments
+
+   White space characters, including white space used in folding
+   (described in section 2.2.3), may appear between many elements in
+   header field bodies.  Also, strings of characters that are treated as
+   comments may be included in structured field bodies as characters
+   enclosed in parentheses.  The following defines the folding white
+   space (FWS) and comment constructs.
+
+   Strings of characters enclosed in parentheses are considered comments
+   so long as they do not appear within a "quoted-string", as defined in
+   section 3.2.4.  Comments may nest.
+
+   There are several places in this specification where comments and FWS
+   may be freely inserted.  To accommodate that syntax, an additional
+   token for "CFWS" is defined for places where comments and/or FWS can
+   occur.  However, where CFWS occurs in this specification, it MUST NOT
+   be inserted in such a way that any line of a folded header field is
+   made up entirely of WSP characters and nothing else.
+
+   FWS             =   ([*WSP CRLF] 1*WSP) /  obs-FWS
+                                          ; Folding white space
+
+   ctext           =   %d33-39 /          ; Printable US-ASCII
+                       %d42-91 /          ;  characters not including
+                       %d93-126 /         ;  "(", ")", or "\"
+                       obs-ctext
+
+   ccontent        =   ctext / quoted-pair / comment
+
+   comment         =   "(" *([FWS] ccontent) [FWS] ")"
+
+   CFWS            =   (1*([FWS] comment) [FWS]) / FWS
+
+
+
+
+
+
+Resnick                     Standards Track                    [Page 11]
+
+RFC 5322                Internet Message Format             October 2008
+
+
+   Throughout this specification, where FWS (the folding white space
+   token) appears, it indicates a place where folding, as discussed in
+   section 2.2.3, may take place.  Wherever folding appears in a message
+   (that is, a header field body containing a CRLF followed by any WSP),
+   unfolding (removal of the CRLF) is performed before any further
+   semantic analysis is performed on that header field according to this
+   specification.  That is to say, any CRLF that appears in FWS is
+   semantically "invisible".
+
+   A comment is normally used in a structured field body to provide some
+   human-readable informational text.  Since a comment is allowed to
+   contain FWS, folding is permitted within the comment.  Also note that
+   since quoted-pair is allowed in a comment, the parentheses and
+   backslash characters may appear in a comment, so long as they appear
+   as a quoted-pair.  Semantically, the enclosing parentheses are not
+   part of the comment; the comment is what is contained between the two
+   parentheses.  As stated earlier, the "\" in any quoted-pair and the
+   CRLF in any FWS that appears within the comment are semantically
+   "invisible" and therefore not part of the comment either.
+
+   Runs of FWS, comment, or CFWS that occur between lexical tokens in a
+   structured header field are semantically interpreted as a single
+   space character.
+
+3.2.3.  Atom
+
+   Several productions in structured header field bodies are simply
+   strings of certain basic characters.  Such productions are called
+   atoms.
+
+   Some of the structured header field bodies also allow the period
+   character (".", ASCII value 46) within runs of atext.  An additional
+   "dot-atom" token is defined for those purposes.
+
+      Note: The "specials" token does not appear anywhere else in this
+      specification.  It is simply the visible (i.e., non-control, non-
+      white space) characters that do not appear in atext.  It is
+      provided only because it is useful for implementers who use tools
+      that lexically analyze messages.  Each of the characters in
+      specials can be used to indicate a tokenization point in lexical
+      analysis.
+
+
+
+
+
+
+
+
+
+
+Resnick                     Standards Track                    [Page 12]
+
+RFC 5322                Internet Message Format             October 2008
+
+
+   atext           =   ALPHA / DIGIT /    ; Printable US-ASCII
+                       "!" / "#" /        ;  characters not including
+                       "$" / "%" /        ;  specials.  Used for atoms.
+                       "&" / "'" /
+                       "*" / "+" /
+                       "-" / "/" /
+                       "=" / "?" /
+                       "^" / "_" /
+                       "`" / "{" /
+                       "|" / "}" /
+                       "~"
+
+   atom            =   [CFWS] 1*atext [CFWS]
+
+   dot-atom-text   =   1*atext *("." 1*atext)
+
+   dot-atom        =   [CFWS] dot-atom-text [CFWS]
+
+   specials        =   "(" / ")" /        ; Special characters that do
+                       "<" / ">" /        ;  not appear in atext
+                       "[" / "]" /
+                       ":" / ";" /
+                       "@" / "\" /
+                       "," / "." /
+                       DQUOTE
+
+   Both atom and dot-atom are interpreted as a single unit, comprising
+   the string of characters that make it up.  Semantically, the optional
+   comments and FWS surrounding the rest of the characters are not part
+   of the atom; the atom is only the run of atext characters in an atom,
+   or the atext and "." characters in a dot-atom.
+
+3.2.4.  Quoted Strings
+
+   Strings of characters that include characters other than those
+   allowed in atoms can be represented in a quoted string format, where
+   the characters are surrounded by quote (DQUOTE, ASCII value 34)
+   characters.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Resnick                     Standards Track                    [Page 13]
+
+RFC 5322                Internet Message Format             October 2008
+
+
+   qtext           =   %d33 /             ; Printable US-ASCII
+                       %d35-91 /          ;  characters not including
+                       %d93-126 /         ;  "\" or the quote character
+                       obs-qtext
+
+   qcontent        =   qtext / quoted-pair
+
+   quoted-string   =   [CFWS]
+                       DQUOTE *([FWS] qcontent) [FWS] DQUOTE
+                       [CFWS]
+
+   A quoted-string is treated as a unit.  That is, quoted-string is
+   identical to atom, semantically.  Since a quoted-string is allowed to
+   contain FWS, folding is permitted.  Also note that since quoted-pair
+   is allowed in a quoted-string, the quote and backslash characters may
+   appear in a quoted-string so long as they appear as a quoted-pair.
+
+   Semantically, neither the optional CFWS outside of the quote
+   characters nor the quote characters themselves are part of the
+   quoted-string; the quoted-string is what is contained between the two
+   quote characters.  As stated earlier, the "\" in any quoted-pair and
+   the CRLF in any FWS/CFWS that appears within the quoted-string are
+   semantically "invisible" and therefore not part of the quoted-string
+   either.
+
+3.2.5.  Miscellaneous Tokens
+
+   Three additional tokens are defined: word and phrase for combinations
+   of atoms and/or quoted-strings, and unstructured for use in
+   unstructured header fields and in some places within structured
+   header fields.
+
+   word            =   atom / quoted-string
+
+   phrase          =   1*word / obs-phrase
+
+   unstructured    =   (*([FWS] VCHAR) *WSP) / obs-unstruct
+
+3.3.  Date and Time Specification
+
+   Date and time values occur in several header fields.  This section
+   specifies the syntax for a full date and time specification.  Though
+   folding white space is permitted throughout the date-time
+   specification, it is RECOMMENDED that a single space be used in each
+   place that FWS appears (whether it is required or optional); some
+   older implementations will not interpret longer sequences of folding
+   white space correctly.
+
+
+
+
+Resnick                     Standards Track                    [Page 14]
+
+RFC 5322                Internet Message Format             October 2008
+
+
+   date-time       =   [ day-of-week "," ] date time [CFWS]
+
+   day-of-week     =   ([FWS] day-name) / obs-day-of-week
+
+   day-name        =   "Mon" / "Tue" / "Wed" / "Thu" /
+                       "Fri" / "Sat" / "Sun"
+
+   date            =   day month year
+
+   day             =   ([FWS] 1*2DIGIT FWS) / obs-day
+
+   month           =   "Jan" / "Feb" / "Mar" / "Apr" /
+                       "May" / "Jun" / "Jul" / "Aug" /
+                       "Sep" / "Oct" / "Nov" / "Dec"
+
+   year            =   (FWS 4*DIGIT FWS) / obs-year
+
+   time            =   time-of-day zone
+
+   time-of-day     =   hour ":" minute [ ":" second ]
+
+   hour            =   2DIGIT / obs-hour
+
+   minute          =   2DIGIT / obs-minute
+
+   second          =   2DIGIT / obs-second
+
+   zone            =   (FWS ( "+" / "-" ) 4DIGIT) / obs-zone
+
+   The day is the numeric day of the month.  The year is any numeric
+   year 1900 or later.
+
+   The time-of-day specifies the number of hours, minutes, and
+   optionally seconds since midnight of the date indicated.
+
+   The date and time-of-day SHOULD express local time.
+
+   The zone specifies the offset from Coordinated Universal Time (UTC,
+   formerly referred to as "Greenwich Mean Time") that the date and
+   time-of-day represent.  The "+" or "-" indicates whether the time-of-
+   day is ahead of (i.e., east of) or behind (i.e., west of) Universal
+   Time.  The first two digits indicate the number of hours difference
+   from Universal Time, and the last two digits indicate the number of
+   additional minutes difference from Universal Time.  (Hence, +hhmm
+   means +(hh * 60 + mm) minutes, and -hhmm means -(hh * 60 + mm)
+   minutes).  The form "+0000" SHOULD be used to indicate a time zone at
+   Universal Time.  Though "-0000" also indicates Universal Time, it is
+
+
+
+
+Resnick                     Standards Track                    [Page 15]
+
+RFC 5322                Internet Message Format             October 2008
+
+
+   used to indicate that the time was generated on a system that may be
+   in a local time zone other than Universal Time and that the date-time
+   contains no information about the local time zone.
+
+   A date-time specification MUST be semantically valid.  That is, the
+   day-of-week (if included) MUST be the day implied by the date, the
+   numeric day-of-month MUST be between 1 and the number of days allowed
+   for the specified month (in the specified year), the time-of-day MUST
+   be in the range 00:00:00 through 23:59:60 (the number of seconds
+   allowing for a leap second; see [RFC1305]), and the last two digits
+   of the zone MUST be within the range 00 through 59.
+
+3.4.  Address Specification
+
+   Addresses occur in several message header fields to indicate senders
+   and recipients of messages.  An address may either be an individual
+   mailbox, or a group of mailboxes.
+
+   address         =   mailbox / group
+
+   mailbox         =   name-addr / addr-spec
+
+   name-addr       =   [display-name] angle-addr
+
+   angle-addr      =   [CFWS] "<" addr-spec ">" [CFWS] /
+                       obs-angle-addr
+
+   group           =   display-name ":" [group-list] ";" [CFWS]
+
+   display-name    =   phrase
+
+   mailbox-list    =   (mailbox *("," mailbox)) / obs-mbox-list
+
+   address-list    =   (address *("," address)) / obs-addr-list
+
+   group-list      =   mailbox-list / CFWS / obs-group-list
+
+   A mailbox receives mail.  It is a conceptual entity that does not
+   necessarily pertain to file storage.  For example, some sites may
+   choose to print mail on a printer and deliver the output to the
+   addressee's desk.
+
+   Normally, a mailbox is composed of two parts: (1) an optional display
+   name that indicates the name of the recipient (which can be a person
+   or a system) that could be displayed to the user of a mail
+   application, and (2) an addr-spec address enclosed in angle brackets
+
+
+
+
+
+Resnick                     Standards Track                    [Page 16]
+
+RFC 5322                Internet Message Format             October 2008
+
+
+   ("<" and ">").  There is an alternate simple form of a mailbox where
+   the addr-spec address appears alone, without the recipient's name or
+   the angle brackets.  The Internet addr-spec address is described in
+   section 3.4.1.
+
+      Note: Some legacy implementations used the simple form where the
+      addr-spec appears without the angle brackets, but included the
+      name of the recipient in parentheses as a comment following the
+      addr-spec.  Since the meaning of the information in a comment is
+      unspecified, implementations SHOULD use the full name-addr form of
+      the mailbox, instead of the legacy form, to specify the display
+      name associated with a mailbox.  Also, because some legacy
+      implementations interpret the comment, comments generally SHOULD
+      NOT be used in address fields to avoid confusing such
+      implementations.
+
+   When it is desirable to treat several mailboxes as a single unit
+   (i.e., in a distribution list), the group construct can be used.  The
+   group construct allows the sender to indicate a named group of
+   recipients.  This is done by giving a display name for the group,
+   followed by a colon, followed by a comma-separated list of any number
+   of mailboxes (including zero and one), and ending with a semicolon.
+   Because the list of mailboxes can be empty, using the group construct
+   is also a simple way to communicate to recipients that the message
+   was sent to one or more named sets of recipients, without actually
+   providing the individual mailbox address for any of those recipients.
+
+3.4.1.  Addr-Spec Specification
+
+   An addr-spec is a specific Internet identifier that contains a
+   locally interpreted string followed by the at-sign character ("@",
+   ASCII value 64) followed by an Internet domain.  The locally
+   interpreted string is either a quoted-string or a dot-atom.  If the
+   string can be represented as a dot-atom (that is, it contains no
+   characters other than atext characters or "." surrounded by atext
+   characters), then the dot-atom form SHOULD be used and the quoted-
+   string form SHOULD NOT be used.  Comments and folding white space
+   SHOULD NOT be used around the "@" in the addr-spec.
+
+      Note: A liberal syntax for the domain portion of addr-spec is
+      given here.  However, the domain portion contains addressing
+      information specified by and used in other protocols (e.g.,
+      [RFC1034], [RFC1035], [RFC1123], [RFC5321]).  It is therefore
+      incumbent upon implementations to conform to the syntax of
+      addresses for the context in which they are used.
+
+
+
+
+
+
+Resnick                     Standards Track                    [Page 17]
+
+RFC 5322                Internet Message Format             October 2008
+
+
+   addr-spec       =   local-part "@" domain
+
+   local-part      =   dot-atom / quoted-string / obs-local-part
+
+   domain          =   dot-atom / domain-literal / obs-domain
+
+   domain-literal  =   [CFWS] "[" *([FWS] dtext) [FWS] "]" [CFWS]
+
+   dtext           =   %d33-90 /          ; Printable US-ASCII
+                       %d94-126 /         ;  characters not including
+                       obs-dtext          ;  "[", "]", or "\"
+
+   The domain portion identifies the point to which the mail is
+   delivered.  In the dot-atom form, this is interpreted as an Internet
+   domain name (either a host name or a mail exchanger name) as
+   described in [RFC1034], [RFC1035], and [RFC1123].  In the domain-
+   literal form, the domain is interpreted as the literal Internet
+   address of the particular host.  In both cases, how addressing is
+   used and how messages are transported to a particular host is covered
+   in separate documents, such as [RFC5321].  These mechanisms are
+   outside of the scope of this document.
+
+   The local-part portion is a domain-dependent string.  In addresses,
+   it is simply interpreted on the particular host as a name of a
+   particular mailbox.
+
+3.5.  Overall Message Syntax
+
+   A message consists of header fields, optionally followed by a message
+   body.  Lines in a message MUST be a maximum of 998 characters
+   excluding the CRLF, but it is RECOMMENDED that lines be limited to 78
+   characters excluding the CRLF.  (See section 2.1.1 for explanation.)
+   In a message body, though all of the characters listed in the text
+   rule MAY be used, the use of US-ASCII control characters (values 1
+   through 8, 11, 12, and 14 through 31) is discouraged since their
+   interpretation by receivers for display is not guaranteed.
+
+   message         =   (fields / obs-fields)
+                       [CRLF body]
+
+   body            =   (*(*998text CRLF) *998text) / obs-body
+
+   text            =   %d1-9 /            ; Characters excluding CR
+                       %d11 /             ;  and LF
+                       %d12 /
+                       %d14-127
+
+
+
+
+
+Resnick                     Standards Track                    [Page 18]
+
+RFC 5322                Internet Message Format             October 2008
+
+
+   The header fields carry most of the semantic information and are
+   defined in section 3.6.  The body is simply a series of lines of text
+   that are uninterpreted for the purposes of this specification.
+
+3.6.  Field Definitions
+
+   The header fields of a message are defined here.  All header fields
+   have the same general syntactic structure: a field name, followed by
+   a colon, followed by the field body.  The specific syntax for each
+   header field is defined in the subsequent sections.
+
+      Note: In the ABNF syntax for each field in subsequent sections,
+      each field name is followed by the required colon.  However, for
+      brevity, sometimes the colon is not referred to in the textual
+      description of the syntax.  It is, nonetheless, required.
+
+   It is important to note that the header fields are not guaranteed to
+   be in a particular order.  They may appear in any order, and they
+   have been known to be reordered occasionally when transported over
+   the Internet.  However, for the purposes of this specification,
+   header fields SHOULD NOT be reordered when a message is transported
+   or transformed.  More importantly, the trace header fields and resent
+   header fields MUST NOT be reordered, and SHOULD be kept in blocks
+   prepended to the message.  See sections 3.6.6 and 3.6.7 for more
+   information.
+
+   The only required header fields are the origination date field and
+   the originator address field(s).  All other header fields are
+   syntactically optional.  More information is contained in the table
+   following this definition.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Resnick                     Standards Track                    [Page 19]
+
+RFC 5322                Internet Message Format             October 2008
+
+
+   fields          =   *(trace
+                         *optional-field /
+                         *(resent-date /
+                          resent-from /
+                          resent-sender /
+                          resent-to /
+                          resent-cc /
+                          resent-bcc /
+                          resent-msg-id))
+                       *(orig-date /
+                       from /
+                       sender /
+                       reply-to /
+                       to /
+                       cc /
+                       bcc /
+                       message-id /
+                       in-reply-to /
+                       references /
+                       subject /
+                       comments /
+                       keywords /
+                       optional-field)
+
+   The following table indicates limits on the number of times each
+   field may occur in the header section of a message as well as any
+   special limitations on the use of those fields.  An asterisk ("*")
+   next to a value in the minimum or maximum column indicates that a
+   special restriction appears in the Notes column.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Resnick                     Standards Track                    [Page 20]
+
+RFC 5322                Internet Message Format             October 2008
+
+
+   +----------------+--------+------------+----------------------------+
+   | Field          | Min    | Max number | Notes                      |
+   |                | number |            |                            |
+   +----------------+--------+------------+----------------------------+
+   | trace          | 0      | unlimited  | Block prepended - see      |
+   |                |        |            | 3.6.7                      |
+   | resent-date    | 0*     | unlimited* | One per block, required if |
+   |                |        |            | other resent fields are    |
+   |                |        |            | present - see 3.6.6        |
+   | resent-from    | 0      | unlimited* | One per block - see 3.6.6  |
+   | resent-sender  | 0*     | unlimited* | One per block, MUST occur  |
+   |                |        |            | with multi-address         |
+   |                |        |            | resent-from - see 3.6.6    |
+   | resent-to      | 0      | unlimited* | One per block - see 3.6.6  |
+   | resent-cc      | 0      | unlimited* | One per block - see 3.6.6  |
+   | resent-bcc     | 0      | unlimited* | One per block - see 3.6.6  |
+   | resent-msg-id  | 0      | unlimited* | One per block - see 3.6.6  |
+   | orig-date      | 1      | 1          |                            |
+   | from           | 1      | 1          | See sender and 3.6.2       |
+   | sender         | 0*     | 1          | MUST occur with            |
+   |                |        |            | multi-address from - see   |
+   |                |        |            | 3.6.2                      |
+   | reply-to       | 0      | 1          |                            |
+   | to             | 0      | 1          |                            |
+   | cc             | 0      | 1          |                            |
+   | bcc            | 0      | 1          |                            |
+   | message-id     | 0*     | 1          | SHOULD be present - see    |
+   |                |        |            | 3.6.4                      |
+   | in-reply-to    | 0*     | 1          | SHOULD occur in some       |
+   |                |        |            | replies - see 3.6.4        |
+   | references     | 0*     | 1          | SHOULD occur in some       |
+   |                |        |            | replies - see 3.6.4        |
+   | subject        | 0      | 1          |                            |
+   | comments       | 0      | unlimited  |                            |
+   | keywords       | 0      | unlimited  |                            |
+   | optional-field | 0      | unlimited  |                            |
+   +----------------+--------+------------+----------------------------+
+
+   The exact interpretation of each field is described in subsequent
+   sections.
+
+
+
+
+
+
+
+
+
+
+
+Resnick                     Standards Track                    [Page 21]
+
+RFC 5322                Internet Message Format             October 2008
+
+
+3.6.1.  The Origination Date Field
+
+   The origination date field consists of the field name "Date" followed
+   by a date-time specification.
+
+   orig-date       =   "Date:" date-time CRLF
+
+   The origination date specifies the date and time at which the creator
+   of the message indicated that the message was complete and ready to
+   enter the mail delivery system.  For instance, this might be the time
+   that a user pushes the "send" or "submit" button in an application
+   program.  In any case, it is specifically not intended to convey the
+   time that the message is actually transported, but rather the time at
+   which the human or other creator of the message has put the message
+   into its final form, ready for transport.  (For example, a portable
+   computer user who is not connected to a network might queue a message
+   for delivery.  The origination date is intended to contain the date
+   and time that the user queued the message, not the time when the user
+   connected to the network to send the message.)
+
+3.6.2.  Originator Fields
+
+   The originator fields of a message consist of the from field, the
+   sender field (when applicable), and optionally the reply-to field.
+   The from field consists of the field name "From" and a comma-
+   separated list of one or more mailbox specifications.  If the from
+   field contains more than one mailbox specification in the mailbox-
+   list, then the sender field, containing the field name "Sender" and a
+   single mailbox specification, MUST appear in the message.  In either
+   case, an optional reply-to field MAY also be included, which contains
+   the field name "Reply-To" and a comma-separated list of one or more
+   addresses.
+
+   from            =   "From:" mailbox-list CRLF
+
+   sender          =   "Sender:" mailbox CRLF
+
+   reply-to        =   "Reply-To:" address-list CRLF
+
+   The originator fields indicate the mailbox(es) of the source of the
+   message.  The "From:" field specifies the author(s) of the message,
+   that is, the mailbox(es) of the person(s) or system(s) responsible
+   for the writing of the message.  The "Sender:" field specifies the
+   mailbox of the agent responsible for the actual transmission of the
+   message.  For example, if a secretary were to send a message for
+   another person, the mailbox of the secretary would appear in the
+   "Sender:" field and the mailbox of the actual author would appear in
+   the "From:" field.  If the originator of the message can be indicated
+
+
+
+Resnick                     Standards Track                    [Page 22]
+
+RFC 5322                Internet Message Format             October 2008
+
+
+   by a single mailbox and the author and transmitter are identical, the
+   "Sender:" field SHOULD NOT be used.  Otherwise, both fields SHOULD
+   appear.
+
+      Note: The transmitter information is always present.  The absence
+      of the "Sender:" field is sometimes mistakenly taken to mean that
+      the agent responsible for transmission of the message has not been
+      specified.  This absence merely means that the transmitter is
+      identical to the author and is therefore not redundantly placed
+      into the "Sender:" field.
+
+   The originator fields also provide the information required when
+   replying to a message.  When the "Reply-To:" field is present, it
+   indicates the address(es) to which the author of the message suggests
+   that replies be sent.  In the absence of the "Reply-To:" field,
+   replies SHOULD by default be sent to the mailbox(es) specified in the
+   "From:" field unless otherwise specified by the person composing the
+   reply.
+
+   In all cases, the "From:" field SHOULD NOT contain any mailbox that
+   does not belong to the author(s) of the message.  See also section
+   3.6.3 for more information on forming the destination addresses for a
+   reply.
+
+3.6.3.  Destination Address Fields
+
+   The destination fields of a message consist of three possible fields,
+   each of the same form: the field name, which is either "To", "Cc", or
+   "Bcc", followed by a comma-separated list of one or more addresses
+   (either mailbox or group syntax).
+
+   to              =   "To:" address-list CRLF
+
+   cc              =   "Cc:" address-list CRLF
+
+   bcc             =   "Bcc:" [address-list / CFWS] CRLF
+
+   The destination fields specify the recipients of the message.  Each
+   destination field may have one or more addresses, and the addresses
+   indicate the intended recipients of the message.  The only difference
+   between the three fields is how each is used.
+
+   The "To:" field contains the address(es) of the primary recipient(s)
+   of the message.
+
+
+
+
+
+
+
+Resnick                     Standards Track                    [Page 23]
+
+RFC 5322                Internet Message Format             October 2008
+
+
+   The "Cc:" field (where the "Cc" means "Carbon Copy" in the sense of
+   making a copy on a typewriter using carbon paper) contains the
+   addresses of others who are to receive the message, though the
+   content of the message may not be directed at them.
+
+   The "Bcc:" field (where the "Bcc" means "Blind Carbon Copy") contains
+   addresses of recipients of the message whose addresses are not to be
+   revealed to other recipients of the message.  There are three ways in
+   which the "Bcc:" field is used.  In the first case, when a message
+   containing a "Bcc:" field is prepared to be sent, the "Bcc:" line is
+   removed even though all of the recipients (including those specified
+   in the "Bcc:" field) are sent a copy of the message.  In the second
+   case, recipients specified in the "To:" and "Cc:" lines each are sent
+   a copy of the message with the "Bcc:" line removed as above, but the
+   recipients on the "Bcc:" line get a separate copy of the message
+   containing a "Bcc:" line.  (When there are multiple recipient
+   addresses in the "Bcc:" field, some implementations actually send a
+   separate copy of the message to each recipient with a "Bcc:"
+   containing only the address of that particular recipient.)  Finally,
+   since a "Bcc:" field may contain no addresses, a "Bcc:" field can be
+   sent without any addresses indicating to the recipients that blind
+   copies were sent to someone.  Which method to use with "Bcc:" fields
+   is implementation dependent, but refer to the "Security
+   Considerations" section of this document for a discussion of each.
+
+   When a message is a reply to another message, the mailboxes of the
+   authors of the original message (the mailboxes in the "From:" field)
+   or mailboxes specified in the "Reply-To:" field (if it exists) MAY
+   appear in the "To:" field of the reply since these would normally be
+   the primary recipients of the reply.  If a reply is sent to a message
+   that has destination fields, it is often desirable to send a copy of
+   the reply to all of the recipients of the message, in addition to the
+   author.  When such a reply is formed, addresses in the "To:" and
+   "Cc:" fields of the original message MAY appear in the "Cc:" field of
+   the reply, since these are normally secondary recipients of the
+   reply.  If a "Bcc:" field is present in the original message,
+   addresses in that field MAY appear in the "Bcc:" field of the reply,
+   but they SHOULD NOT appear in the "To:" or "Cc:" fields.
+
+      Note: Some mail applications have automatic reply commands that
+      include the destination addresses of the original message in the
+      destination addresses of the reply.  How those reply commands
+      behave is implementation dependent and is beyond the scope of this
+      document.  In particular, whether or not to include the original
+      destination addresses when the original message had a "Reply-To:"
+      field is not addressed here.
+
+
+
+
+
+Resnick                     Standards Track                    [Page 24]
+
+RFC 5322                Internet Message Format             October 2008
+
+
+3.6.4.  Identification Fields
+
+   Though listed as optional in the table in section 3.6, every message
+   SHOULD have a "Message-ID:" field.  Furthermore, reply messages
+   SHOULD have "In-Reply-To:" and "References:" fields as appropriate
+   and as described below.
+
+   The "Message-ID:" field contains a single unique message identifier.
+   The "References:" and "In-Reply-To:" fields each contain one or more
+   unique message identifiers, optionally separated by CFWS.
+
+   The message identifier (msg-id) syntax is a limited version of the
+   addr-spec construct enclosed in the angle bracket characters, "<" and
+   ">".  Unlike addr-spec, this syntax only permits the dot-atom-text
+   form on the left-hand side of the "@" and does not have internal CFWS
+   anywhere in the message identifier.
+
+      Note: As with addr-spec, a liberal syntax is given for the right-
+      hand side of the "@" in a msg-id.  However, later in this section,
+      the use of a domain for the right-hand side of the "@" is
+      RECOMMENDED.  Again, the syntax of domain constructs is specified
+      by and used in other protocols (e.g., [RFC1034], [RFC1035],
+      [RFC1123], [RFC5321]).  It is therefore incumbent upon
+      implementations to conform to the syntax of addresses for the
+      context in which they are used.
+
+   message-id      =   "Message-ID:" msg-id CRLF
+
+   in-reply-to     =   "In-Reply-To:" 1*msg-id CRLF
+
+   references      =   "References:" 1*msg-id CRLF
+
+   msg-id          =   [CFWS] "<" id-left "@" id-right ">" [CFWS]
+
+   id-left         =   dot-atom-text / obs-id-left
+
+   id-right        =   dot-atom-text / no-fold-literal / obs-id-right
+
+   no-fold-literal =   "[" *dtext "]"
+
+   The "Message-ID:" field provides a unique message identifier that
+   refers to a particular version of a particular message.  The
+   uniqueness of the message identifier is guaranteed by the host that
+   generates it (see below).  This message identifier is intended to be
+   machine readable and not necessarily meaningful to humans.  A message
+   identifier pertains to exactly one version of a particular message;
+   subsequent revisions to the message each receive new message
+   identifiers.
+
+
+
+Resnick                     Standards Track                    [Page 25]
+
+RFC 5322                Internet Message Format             October 2008
+
+
+      Note: There are many instances when messages are "changed", but
+      those changes do not constitute a new instantiation of that
+      message, and therefore the message would not get a new message
+      identifier.  For example, when messages are introduced into the
+      transport system, they are often prepended with additional header
+      fields such as trace fields (described in section 3.6.7) and
+      resent fields (described in section 3.6.6).  The addition of such
+      header fields does not change the identity of the message and
+      therefore the original "Message-ID:" field is retained.  In all
+      cases, it is the meaning that the sender of the message wishes to
+      convey (i.e., whether this is the same message or a different
+      message) that determines whether or not the "Message-ID:" field
+      changes, not any particular syntactic difference that appears (or
+      does not appear) in the message.
+
+   The "In-Reply-To:" and "References:" fields are used when creating a
+   reply to a message.  They hold the message identifier of the original
+   message and the message identifiers of other messages (for example,
+   in the case of a reply to a message that was itself a reply).  The
+   "In-Reply-To:" field may be used to identify the message (or
+   messages) to which the new message is a reply, while the
+   "References:" field may be used to identify a "thread" of
+   conversation.
+
+   When creating a reply to a message, the "In-Reply-To:" and
+   "References:" fields of the resultant message are constructed as
+   follows:
+
+   The "In-Reply-To:" field will contain the contents of the
+   "Message-ID:" field of the message to which this one is a reply (the
+   "parent message").  If there is more than one parent message, then
+   the "In-Reply-To:" field will contain the contents of all of the
+   parents' "Message-ID:" fields.  If there is no "Message-ID:" field in
+   any of the parent messages, then the new message will have no "In-
+   Reply-To:" field.
+
+   The "References:" field will contain the contents of the parent's
+   "References:" field (if any) followed by the contents of the parent's
+   "Message-ID:" field (if any).  If the parent message does not contain
+   a "References:" field but does have an "In-Reply-To:" field
+   containing a single message identifier, then the "References:" field
+   will contain the contents of the parent's "In-Reply-To:" field
+   followed by the contents of the parent's "Message-ID:" field (if
+   any).  If the parent has none of the "References:", "In-Reply-To:",
+   or "Message-ID:" fields, then the new message will have no
+   "References:" field.
+
+
+
+
+
+Resnick                     Standards Track                    [Page 26]
+
+RFC 5322                Internet Message Format             October 2008
+
+
+      Note: Some implementations parse the "References:" field to
+      display the "thread of the discussion".  These implementations
+      assume that each new message is a reply to a single parent and
+      hence that they can walk backwards through the "References:" field
+      to find the parent of each message listed there.  Therefore,
+      trying to form a "References:" field for a reply that has multiple
+      parents is discouraged; how to do so is not defined in this
+      document.
+
+   The message identifier (msg-id) itself MUST be a globally unique
+   identifier for a message.  The generator of the message identifier
+   MUST guarantee that the msg-id is unique.  There are several
+   algorithms that can be used to accomplish this.  Since the msg-id has
+   a similar syntax to addr-spec (identical except that quoted strings,
+   comments, and folding white space are not allowed), a good method is
+   to put the domain name (or a domain literal IP address) of the host
+   on which the message identifier was created on the right-hand side of
+   the "@" (since domain names and IP addresses are normally unique),
+   and put a combination of the current absolute date and time along
+   with some other currently unique (perhaps sequential) identifier
+   available on the system (for example, a process id number) on the
+   left-hand side.  Though other algorithms will work, it is RECOMMENDED
+   that the right-hand side contain some domain identifier (either of
+   the host itself or otherwise) such that the generator of the message
+   identifier can guarantee the uniqueness of the left-hand side within
+   the scope of that domain.
+
+   Semantically, the angle bracket characters are not part of the
+   msg-id; the msg-id is what is contained between the two angle bracket
+   characters.
+
+3.6.5.  Informational Fields
+
+   The informational fields are all optional.  The "Subject:" and
+   "Comments:" fields are unstructured fields as defined in section
+   2.2.1, and therefore may contain text or folding white space.  The
+   "Keywords:" field contains a comma-separated list of one or more
+   words or quoted-strings.
+
+   subject         =   "Subject:" unstructured CRLF
+
+   comments        =   "Comments:" unstructured CRLF
+
+   keywords        =   "Keywords:" phrase *("," phrase) CRLF
+
+   These three fields are intended to have only human-readable content
+   with information about the message.  The "Subject:" field is the most
+   common and contains a short string identifying the topic of the
+
+
+
+Resnick                     Standards Track                    [Page 27]
+
+RFC 5322                Internet Message Format             October 2008
+
+
+   message.  When used in a reply, the field body MAY start with the
+   string "Re: " (an abbreviation of the Latin "in re", meaning "in the
+   matter of") followed by the contents of the "Subject:" field body of
+   the original message.  If this is done, only one instance of the
+   literal string "Re: " ought to be used since use of other strings or
+   more than one instance can lead to undesirable consequences.  The
+   "Comments:" field contains any additional comments on the text of the
+   body of the message.  The "Keywords:" field contains a comma-
+   separated list of important words and phrases that might be useful
+   for the recipient.
+
+3.6.6.  Resent Fields
+
+   Resent fields SHOULD be added to any message that is reintroduced by
+   a user into the transport system.  A separate set of resent fields
+   SHOULD be added each time this is done.  All of the resent fields
+   corresponding to a particular resending of the message SHOULD be
+   grouped together.  Each new set of resent fields is prepended to the
+   message; that is, the most recent set of resent fields appears
+   earlier in the message.  No other fields in the message are changed
+   when resent fields are added.
+
+   Each of the resent fields corresponds to a particular field elsewhere
+   in the syntax.  For instance, the "Resent-Date:" field corresponds to
+   the "Date:" field and the "Resent-To:" field corresponds to the "To:"
+   field.  In each case, the syntax for the field body is identical to
+   the syntax given previously for the corresponding field.
+
+   When resent fields are used, the "Resent-From:" and "Resent-Date:"
+   fields MUST be sent.  The "Resent-Message-ID:" field SHOULD be sent.
+   "Resent-Sender:" SHOULD NOT be used if "Resent-Sender:" would be
+   identical to "Resent-From:".
+
+   resent-date     =   "Resent-Date:" date-time CRLF
+
+   resent-from     =   "Resent-From:" mailbox-list CRLF
+
+   resent-sender   =   "Resent-Sender:" mailbox CRLF
+
+   resent-to       =   "Resent-To:" address-list CRLF
+
+   resent-cc       =   "Resent-Cc:" address-list CRLF
+
+   resent-bcc      =   "Resent-Bcc:" [address-list / CFWS] CRLF
+
+   resent-msg-id   =   "Resent-Message-ID:" msg-id CRLF
+
+
+
+
+
+Resnick                     Standards Track                    [Page 28]
+
+RFC 5322                Internet Message Format             October 2008
+
+
+   Resent fields are used to identify a message as having been
+   reintroduced into the transport system by a user.  The purpose of
+   using resent fields is to have the message appear to the final
+   recipient as if it were sent directly by the original sender, with
+   all of the original fields remaining the same.  Each set of resent
+   fields correspond to a particular resending event.  That is, if a
+   message is resent multiple times, each set of resent fields gives
+   identifying information for each individual time.  Resent fields are
+   strictly informational.  They MUST NOT be used in the normal
+   processing of replies or other such automatic actions on messages.
+
+      Note: Reintroducing a message into the transport system and using
+      resent fields is a different operation from "forwarding".
+      "Forwarding" has two meanings: One sense of forwarding is that a
+      mail reading program can be told by a user to forward a copy of a
+      message to another person, making the forwarded message the body
+      of the new message.  A forwarded message in this sense does not
+      appear to have come from the original sender, but is an entirely
+      new message from the forwarder of the message.  Forwarding may
+      also mean that a mail transport program gets a message and
+      forwards it on to a different destination for final delivery.
+      Resent header fields are not intended for use with either type of
+      forwarding.
+
+   The resent originator fields indicate the mailbox of the person(s) or
+   system(s) that resent the message.  As with the regular originator
+   fields, there are two forms: a simple "Resent-From:" form, which
+   contains the mailbox of the individual doing the resending, and the
+   more complex form, when one individual (identified in the "Resent-
+   Sender:" field) resends a message on behalf of one or more others
+   (identified in the "Resent-From:" field).
+
+      Note: When replying to a resent message, replies behave just as
+      they would with any other message, using the original "From:",
+      "Reply-To:", "Message-ID:", and other fields.  The resent fields
+      are only informational and MUST NOT be used in the normal
+      processing of replies.
+
+   The "Resent-Date:" indicates the date and time at which the resent
+   message is dispatched by the resender of the message.  Like the
+   "Date:" field, it is not the date and time that the message was
+   actually transported.
+
+   The "Resent-To:", "Resent-Cc:", and "Resent-Bcc:" fields function
+   identically to the "To:", "Cc:", and "Bcc:" fields, respectively,
+   except that they indicate the recipients of the resent message, not
+   the recipients of the original message.
+
+
+
+
+Resnick                     Standards Track                    [Page 29]
+
+RFC 5322                Internet Message Format             October 2008
+
+
+   The "Resent-Message-ID:" field provides a unique identifier for the
+   resent message.
+
+3.6.7.  Trace Fields
+
+   The trace fields are a group of header fields consisting of an
+   optional "Return-Path:" field, and one or more "Received:" fields.
+   The "Return-Path:" header field contains a pair of angle brackets
+   that enclose an optional addr-spec.  The "Received:" field contains a
+   (possibly empty) list of tokens followed by a semicolon and a date-
+   time specification.  Each token must be a word, angle-addr, addr-
+   spec, or a domain.  Further restrictions are applied to the syntax of
+   the trace fields by specifications that provide for their use, such
+   as [RFC5321].
+
+   trace           =   [return]
+                       1*received
+
+   return          =   "Return-Path:" path CRLF
+
+   path            =   angle-addr / ([CFWS] "<" [CFWS] ">" [CFWS])
+
+   received        =   "Received:" *received-token ";" date-time CRLF
+
+   received-token  =   word / angle-addr / addr-spec / domain
+
+   A full discussion of the Internet mail use of trace fields is
+   contained in [RFC5321].  For the purposes of this specification, the
+   trace fields are strictly informational, and any formal
+   interpretation of them is outside of the scope of this document.
+
+3.6.8.  Optional Fields
+
+   Fields may appear in messages that are otherwise unspecified in this
+   document.  They MUST conform to the syntax of an optional-field.
+   This is a field name, made up of the printable US-ASCII characters
+   except SP and colon, followed by a colon, followed by any text that
+   conforms to the unstructured syntax.
+
+   The field names of any optional field MUST NOT be identical to any
+   field name specified elsewhere in this document.
+
+
+
+
+
+
+
+
+
+
+Resnick                     Standards Track                    [Page 30]
+
+RFC 5322                Internet Message Format             October 2008
+
+
+   optional-field  =   field-name ":" unstructured CRLF
+
+   field-name      =   1*ftext
+
+   ftext           =   %d33-57 /          ; Printable US-ASCII
+                       %d59-126           ;  characters not including
+                                          ;  ":".
+
+   For the purposes of this specification, any optional field is
+   uninterpreted.
+
+4.  Obsolete Syntax
+
+   Earlier versions of this specification allowed for different (usually
+   more liberal) syntax than is allowed in this version.  Also, there
+   have been syntactic elements used in messages on the Internet whose
+   interpretations have never been documented.  Though these syntactic
+   forms MUST NOT be generated according to the grammar in section 3,
+   they MUST be accepted and parsed by a conformant receiver.  This
+   section documents many of these syntactic elements.  Taking the
+   grammar in section 3 and adding the definitions presented in this
+   section will result in the grammar to use for the interpretation of
+   messages.
+
+      Note: This section identifies syntactic forms that any
+      implementation MUST reasonably interpret.  However, there are
+      certainly Internet messages that do not conform to even the
+      additional syntax given in this section.  The fact that a
+      particular form does not appear in any section of this document is
+      not justification for computer programs to crash or for malformed
+      data to be irretrievably lost by any implementation.  It is up to
+      the implementation to deal with messages robustly.
+
+   One important difference between the obsolete (interpreting) and the
+   current (generating) syntax is that in structured header field bodies
+   (i.e., between the colon and the CRLF of any structured header
+   field), white space characters, including folding white space, and
+   comments could be freely inserted between any syntactic tokens.  This
+   allowed many complex forms that have proven difficult for some
+   implementations to parse.
+
+   Another key difference between the obsolete and the current syntax is
+   that the rule in section 3.2.2 regarding lines composed entirely of
+   white space in comments and folding white space does not apply.  See
+   the discussion of folding white space in section 4.2 below.
+
+   Finally, certain characters that were formerly allowed in messages
+   appear in this section.  The NUL character (ASCII value 0) was once
+
+
+
+Resnick                     Standards Track                    [Page 31]
+
+RFC 5322                Internet Message Format             October 2008
+
+
+   allowed, but is no longer for compatibility reasons.  Similarly, US-
+   ASCII control characters other than CR, LF, SP, and HTAB (ASCII
+   values 1 through 8, 11, 12, 14 through 31, and 127) were allowed to
+   appear in header field bodies.  CR and LF were allowed to appear in
+   messages other than as CRLF; this use is also shown here.
+
+   Other differences in syntax and semantics are noted in the following
+   sections.
+
+4.1.  Miscellaneous Obsolete Tokens
+
+   These syntactic elements are used elsewhere in the obsolete syntax or
+   in the main syntax.  Bare CR, bare LF, and NUL are added to obs-qp,
+   obs-body, and obs-unstruct.  US-ASCII control characters are added to
+   obs-qp, obs-unstruct, obs-ctext, and obs-qtext.  The period character
+   is added to obs-phrase.  The obs-phrase-list provides for a
+   (potentially empty) comma-separated list of phrases that may include
+   "null" elements.  That is, there could be two or more commas in such
+   a list with nothing in between them, or commas at the beginning or
+   end of the list.
+
+      Note: The "period" (or "full stop") character (".") in obs-phrase
+      is not a form that was allowed in earlier versions of this or any
+      other specification.  Period (nor any other character from
+      specials) was not allowed in phrase because it introduced a
+      parsing difficulty distinguishing between phrases and portions of
+      an addr-spec (see section 4.4).  It appears here because the
+      period character is currently used in many messages in the
+      display-name portion of addresses, especially for initials in
+      names, and therefore must be interpreted properly.
+
+   obs-NO-WS-CTL   =   %d1-8 /            ; US-ASCII control
+                       %d11 /             ;  characters that do not
+                       %d12 /             ;  include the carriage
+                       %d14-31 /          ;  return, line feed, and
+                       %d127              ;  white space characters
+
+   obs-ctext       =   obs-NO-WS-CTL
+
+   obs-qtext       =   obs-NO-WS-CTL
+
+   obs-utext       =   %d0 / obs-NO-WS-CTL / VCHAR
+
+   obs-qp          =   "\" (%d0 / obs-NO-WS-CTL / LF / CR)
+
+   obs-body        =   *((*LF *CR *((%d0 / text) *LF *CR)) / CRLF)
+
+   obs-unstruct    =   *((*LF *CR *(obs-utext *LF *CR)) / FWS)
+
+
+
+Resnick                     Standards Track                    [Page 32]
+
+RFC 5322                Internet Message Format             October 2008
+
+
+   obs-phrase      =   word *(word / "." / CFWS)
+
+   obs-phrase-list =   [phrase / CFWS] *("," [phrase / CFWS])
+
+   Bare CR and bare LF appear in messages with two different meanings.
+   In many cases, bare CR or bare LF are used improperly instead of CRLF
+   to indicate line separators.  In other cases, bare CR and bare LF are
+   used simply as US-ASCII control characters with their traditional
+   ASCII meanings.
+
+4.2.  Obsolete Folding White Space
+
+   In the obsolete syntax, any amount of folding white space MAY be
+   inserted where the obs-FWS rule is allowed.  This creates the
+   possibility of having two consecutive "folds" in a line, and
+   therefore the possibility that a line which makes up a folded header
+   field could be composed entirely of white space.
+
+   obs-FWS         =   1*WSP *(CRLF 1*WSP)
+
+4.3.  Obsolete Date and Time
+
+   The syntax for the obsolete date format allows a 2 digit year in the
+   date field and allows for a list of alphabetic time zone specifiers
+   that were used in earlier versions of this specification.  It also
+   permits comments and folding white space between many of the tokens.
+
+   obs-day-of-week =   [CFWS] day-name [CFWS]
+
+   obs-day         =   [CFWS] 1*2DIGIT [CFWS]
+
+   obs-year        =   [CFWS] 2*DIGIT [CFWS]
+
+   obs-hour        =   [CFWS] 2DIGIT [CFWS]
+
+   obs-minute      =   [CFWS] 2DIGIT [CFWS]
+
+   obs-second      =   [CFWS] 2DIGIT [CFWS]
+
+   obs-zone        =   "UT" / "GMT" /     ; Universal Time
+                                          ; North American UT
+                                          ; offsets
+                       "EST" / "EDT" /    ; Eastern:  - 5/ - 4
+                       "CST" / "CDT" /    ; Central:  - 6/ - 5
+                       "MST" / "MDT" /    ; Mountain: - 7/ - 6
+                       "PST" / "PDT" /    ; Pacific:  - 8/ - 7
+                                          ;
+
+
+
+
+Resnick                     Standards Track                    [Page 33]
+
+RFC 5322                Internet Message Format             October 2008
+
+
+                       %d65-73 /          ; Military zones - "A"
+                       %d75-90 /          ; through "I" and "K"
+                       %d97-105 /         ; through "Z", both
+                       %d107-122          ; upper and lower case
+
+   Where a two or three digit year occurs in a date, the year is to be
+   interpreted as follows: If a two digit year is encountered whose
+   value is between 00 and 49, the year is interpreted by adding 2000,
+   ending up with a value between 2000 and 2049.  If a two digit year is
+   encountered with a value between 50 and 99, or any three digit year
+   is encountered, the year is interpreted by adding 1900.
+
+   In the obsolete time zone, "UT" and "GMT" are indications of
+   "Universal Time" and "Greenwich Mean Time", respectively, and are
+   both semantically identical to "+0000".
+
+   The remaining three character zones are the US time zones.  The first
+   letter, "E", "C", "M", or "P" stands for "Eastern", "Central",
+   "Mountain", and "Pacific".  The second letter is either "S" for
+   "Standard" time, or "D" for "Daylight Savings" (or summer) time.
+   Their interpretations are as follows:
+
+      EDT is semantically equivalent to -0400
+      EST is semantically equivalent to -0500
+      CDT is semantically equivalent to -0500
+      CST is semantically equivalent to -0600
+      MDT is semantically equivalent to -0600
+      MST is semantically equivalent to -0700
+      PDT is semantically equivalent to -0700
+      PST is semantically equivalent to -0800
+
+   The 1 character military time zones were defined in a non-standard
+   way in [RFC0822] and are therefore unpredictable in their meaning.
+   The original definitions of the military zones "A" through "I" are
+   equivalent to "+0100" through "+0900", respectively; "K", "L", and
+   "M" are equivalent to "+1000", "+1100", and "+1200", respectively;
+   "N" through "Y" are equivalent to "-0100" through "-1200".
+   respectively; and "Z" is equivalent to "+0000".  However, because of
+   the error in [RFC0822], they SHOULD all be considered equivalent to
+   "-0000" unless there is out-of-band information confirming their
+   meaning.
+
+   Other multi-character (usually between 3 and 5) alphabetic time zones
+   have been used in Internet messages.  Any such time zone whose
+   meaning is not known SHOULD be considered equivalent to "-0000"
+   unless there is out-of-band information confirming their meaning.
+
+
+
+
+
+Resnick                     Standards Track                    [Page 34]
+
+RFC 5322                Internet Message Format             October 2008
+
+
+4.4.  Obsolete Addressing
+
+   There are four primary differences in addressing.  First, mailbox
+   addresses were allowed to have a route portion before the addr-spec
+   when enclosed in "<" and ">".  The route is simply a comma-separated
+   list of domain names, each preceded by "@", and the list terminated
+   by a colon.  Second, CFWS were allowed between the period-separated
+   elements of local-part and domain (i.e., dot-atom was not used).  In
+   addition, local-part is allowed to contain quoted-string in addition
+   to just atom.  Third, mailbox-list and address-list were allowed to
+   have "null" members.  That is, there could be two or more commas in
+   such a list with nothing in between them, or commas at the beginning
+   or end of the list.  Finally, US-ASCII control characters and quoted-
+   pairs were allowed in domain literals and are added here.
+
+   obs-angle-addr  =   [CFWS] "<" obs-route addr-spec ">" [CFWS]
+
+   obs-route       =   obs-domain-list ":"
+
+   obs-domain-list =   *(CFWS / ",") "@" domain
+                       *("," [CFWS] ["@" domain])
+
+   obs-mbox-list   =   *([CFWS] ",") mailbox *("," [mailbox / CFWS])
+
+   obs-addr-list   =   *([CFWS] ",") address *("," [address / CFWS])
+
+   obs-group-list  =   1*([CFWS] ",") [CFWS]
+
+   obs-local-part  =   word *("." word)
+
+   obs-domain      =   atom *("." atom)
+
+   obs-dtext       =   obs-NO-WS-CTL / quoted-pair
+
+   When interpreting addresses, the route portion SHOULD be ignored.
+
+4.5.  Obsolete Header Fields
+
+   Syntactically, the primary difference in the obsolete field syntax is
+   that it allows multiple occurrences of any of the fields and they may
+   occur in any order.  Also, any amount of white space is allowed
+   before the ":" at the end of the field name.
+
+
+
+
+
+
+
+
+
+Resnick                     Standards Track                    [Page 35]
+
+RFC 5322                Internet Message Format             October 2008
+
+
+   obs-fields      =   *(obs-return /
+                       obs-received /
+                       obs-orig-date /
+                       obs-from /
+                       obs-sender /
+                       obs-reply-to /
+                       obs-to /
+                       obs-cc /
+                       obs-bcc /
+                       obs-message-id /
+                       obs-in-reply-to /
+                       obs-references /
+                       obs-subject /
+                       obs-comments /
+                       obs-keywords /
+                       obs-resent-date /
+                       obs-resent-from /
+                       obs-resent-send /
+                       obs-resent-rply /
+                       obs-resent-to /
+                       obs-resent-cc /
+                       obs-resent-bcc /
+                       obs-resent-mid /
+                       obs-optional)
+
+   Except for destination address fields (described in section 4.5.3),
+   the interpretation of multiple occurrences of fields is unspecified.
+   Also, the interpretation of trace fields and resent fields that do
+   not occur in blocks prepended to the message is unspecified as well.
+   Unless otherwise noted in the following sections, interpretation of
+   other fields is identical to the interpretation of their non-obsolete
+   counterparts in section 3.
+
+4.5.1.  Obsolete Origination Date Field
+
+   obs-orig-date   =   "Date" *WSP ":" date-time CRLF
+
+4.5.2.  Obsolete Originator Fields
+
+   obs-from        =   "From" *WSP ":" mailbox-list CRLF
+
+   obs-sender      =   "Sender" *WSP ":" mailbox CRLF
+
+   obs-reply-to    =   "Reply-To" *WSP ":" address-list CRLF
+
+
+
+
+
+
+
+Resnick                     Standards Track                    [Page 36]
+
+RFC 5322                Internet Message Format             October 2008
+
+
+4.5.3.  Obsolete Destination Address Fields
+
+   obs-to          =   "To" *WSP ":" address-list CRLF
+
+   obs-cc          =   "Cc" *WSP ":" address-list CRLF
+
+   obs-bcc         =   "Bcc" *WSP ":"
+                       (address-list / (*([CFWS] ",") [CFWS])) CRLF
+
+   When multiple occurrences of destination address fields occur in a
+   message, they SHOULD be treated as if the address list in the first
+   occurrence of the field is combined with the address lists of the
+   subsequent occurrences by adding a comma and concatenating.
+
+4.5.4.  Obsolete Identification Fields
+
+   The obsolete "In-Reply-To:" and "References:" fields differ from the
+   current syntax in that they allow phrase (words or quoted strings) to
+   appear.  The obsolete forms of the left and right sides of msg-id
+   allow interspersed CFWS, making them syntactically identical to
+   local-part and domain, respectively.
+
+   obs-message-id  =   "Message-ID" *WSP ":" msg-id CRLF
+
+   obs-in-reply-to =   "In-Reply-To" *WSP ":" *(phrase / msg-id) CRLF
+
+   obs-references  =   "References" *WSP ":" *(phrase / msg-id) CRLF
+
+   obs-id-left     =   local-part
+
+   obs-id-right    =   domain
+
+   For purposes of interpretation, the phrases in the "In-Reply-To:" and
+   "References:" fields are ignored.
+
+   Semantically, none of the optional CFWS in the local-part and the
+   domain is part of the obs-id-left and obs-id-right, respectively.
+
+4.5.5.  Obsolete Informational Fields
+
+   obs-subject     =   "Subject" *WSP ":" unstructured CRLF
+
+   obs-comments    =   "Comments" *WSP ":" unstructured CRLF
+
+   obs-keywords    =   "Keywords" *WSP ":" obs-phrase-list CRLF
+
+
+
+
+
+
+Resnick                     Standards Track                    [Page 37]
+
+RFC 5322                Internet Message Format             October 2008
+
+
+4.5.6.  Obsolete Resent Fields
+
+   The obsolete syntax adds a "Resent-Reply-To:" field, which consists
+   of the field name, the optional comments and folding white space, the
+   colon, and a comma separated list of addresses.
+
+   obs-resent-from =   "Resent-From" *WSP ":" mailbox-list CRLF
+
+   obs-resent-send =   "Resent-Sender" *WSP ":" mailbox CRLF
+
+   obs-resent-date =   "Resent-Date" *WSP ":" date-time CRLF
+
+   obs-resent-to   =   "Resent-To" *WSP ":" address-list CRLF
+
+   obs-resent-cc   =   "Resent-Cc" *WSP ":" address-list CRLF
+
+   obs-resent-bcc  =   "Resent-Bcc" *WSP ":"
+                       (address-list / (*([CFWS] ",") [CFWS])) CRLF
+
+   obs-resent-mid  =   "Resent-Message-ID" *WSP ":" msg-id CRLF
+
+   obs-resent-rply =   "Resent-Reply-To" *WSP ":" address-list CRLF
+
+   As with other resent fields, the "Resent-Reply-To:" field is to be
+   treated as trace information only.
+
+4.5.7.  Obsolete Trace Fields
+
+   The obs-return and obs-received are again given here as template
+   definitions, just as return and received are in section 3.  Their
+   full syntax is given in [RFC5321].
+
+   obs-return      =   "Return-Path" *WSP ":" path CRLF
+
+   obs-received    =   "Received" *WSP ":" *received-token CRLF
+
+4.5.8.  Obsolete optional fields
+
+   obs-optional    =   field-name *WSP ":" unstructured CRLF
+
+5.  Security Considerations
+
+   Care needs to be taken when displaying messages on a terminal or
+   terminal emulator.  Powerful terminals may act on escape sequences
+   and other combinations of US-ASCII control characters with a variety
+   of consequences.  They can remap the keyboard or permit other
+   modifications to the terminal that could lead to denial of service or
+   even damaged data.  They can trigger (sometimes programmable)
+
+
+
+Resnick                     Standards Track                    [Page 38]
+
+RFC 5322                Internet Message Format             October 2008
+
+
+   answerback messages that can allow a message to cause commands to be
+   issued on the recipient's behalf.  They can also affect the operation
+   of terminal attached devices such as printers.  Message viewers may
+   wish to strip potentially dangerous terminal escape sequences from
+   the message prior to display.  However, other escape sequences appear
+   in messages for useful purposes (cf. [ISO.2022.1994], [RFC2045],
+   [RFC2046], [RFC2047], [RFC2049], [RFC4288], [RFC4289]) and therefore
+   should not be stripped indiscriminately.
+
+   Transmission of non-text objects in messages raises additional
+   security issues.  These issues are discussed in [RFC2045], [RFC2046],
+   [RFC2047], [RFC2049], [RFC4288], and [RFC4289].
+
+   Many implementations use the "Bcc:" (blind carbon copy) field,
+   described in section 3.6.3, to facilitate sending messages to
+   recipients without revealing the addresses of one or more of the
+   addressees to the other recipients.  Mishandling this use of "Bcc:"
+   may disclose confidential information that could eventually lead to
+   security problems through knowledge of even the existence of a
+   particular mail address.  For example, if using the first method
+   described in section 3.6.3, where the "Bcc:" line is removed from the
+   message, blind recipients have no explicit indication that they have
+   been sent a blind copy, except insofar as their address does not
+   appear in the header section of a message.  Because of this, one of
+   the blind addressees could potentially send a reply to all of the
+   shown recipients and accidentally reveal that the message went to the
+   blind recipient.  When the second method from section 3.6.3 is used,
+   the blind recipient's address appears in the "Bcc:" field of a
+   separate copy of the message.  If the "Bcc:" field sent contains all
+   of the blind addressees, all of the "Bcc:" recipients will be seen by
+   each "Bcc:" recipient.  Even if a separate message is sent to each
+   "Bcc:" recipient with only the individual's address, implementations
+   still need to be careful to process replies to the message as per
+   section 3.6.3 so as not to accidentally reveal the blind recipient to
+   other recipients.
+
+6.  IANA Considerations
+
+   This document updates the registrations that appeared in [RFC4021]
+   that referred to the definitions in [RFC2822].  IANA has updated the
+   Permanent Message Header Field Repository with the following header
+   fields, in accordance with the procedures set out in [RFC3864].
+
+   Header field name:  Date
+   Applicable protocol:  Mail
+   Status:  standard
+   Author/Change controller:  IETF
+   Specification document(s):  This document (section 3.6.1)
+
+
+
+Resnick                     Standards Track                    [Page 39]
+
+RFC 5322                Internet Message Format             October 2008
+
+
+   Header field name:  From
+   Applicable protocol:  Mail
+   Status:  standard
+   Author/Change controller:  IETF
+   Specification document(s):  This document (section 3.6.2)
+
+   Header field name:  Sender
+   Applicable protocol:  Mail
+   Status:  standard
+   Author/Change controller:  IETF
+   Specification document(s):  This document (section 3.6.2)
+
+   Header field name:  Reply-To
+   Applicable protocol:  Mail
+   Status:  standard
+   Author/Change controller:  IETF
+   Specification document(s):  This document (section 3.6.2)
+
+   Header field name:  To
+   Applicable protocol:  Mail
+   Status:  standard
+   Author/Change controller:  IETF
+   Specification document(s):  This document (section 3.6.3)
+
+   Header field name:  Cc
+   Applicable protocol:  Mail
+   Status:  standard
+   Author/Change controller:  IETF
+   Specification document(s):  This document (section 3.6.3)
+
+   Header field name:  Bcc
+   Applicable protocol:  Mail
+   Status:  standard
+   Author/Change controller:  IETF
+   Specification document(s):  This document (section 3.6.3)
+
+   Header field name:  Message-ID
+   Applicable protocol:  Mail
+   Status:  standard
+   Author/Change controller:  IETF
+   Specification document(s):  This document (section 3.6.4)
+
+   Header field name:  In-Reply-To
+   Applicable protocol:  Mail
+   Status:  standard
+   Author/Change controller:  IETF
+   Specification document(s):  This document (section 3.6.4)
+
+
+
+
+Resnick                     Standards Track                    [Page 40]
+
+RFC 5322                Internet Message Format             October 2008
+
+
+   Header field name:  References
+   Applicable protocol:  Mail
+   Status:  standard
+   Author/Change controller:  IETF
+   Specification document(s):  This document (section 3.6.4)
+
+   Header field name:  Subject
+   Applicable protocol:  Mail
+   Status:  standard
+   Author/Change controller:  IETF
+   Specification document(s):  This document (section 3.6.5)
+
+   Header field name:  Comments
+   Applicable protocol:  Mail
+   Status:  standard
+   Author/Change controller:  IETF
+   Specification document(s):  This document (section 3.6.5)
+
+   Header field name:  Keywords
+   Applicable protocol:  Mail
+   Status:  standard
+   Author/Change controller:  IETF
+   Specification document(s):  This document (section 3.6.5)
+
+   Header field name:  Resent-Date
+   Applicable protocol:  Mail
+   Status:  standard
+   Author/Change controller:  IETF
+   Specification document(s):  This document (section 3.6.6)
+
+   Header field name:  Resent-From
+   Applicable protocol:  Mail
+   Status:  standard
+   Author/Change controller:  IETF
+   Specification document(s):  This document (section 3.6.6)
+
+   Header field name:  Resent-Sender
+   Applicable protocol:  Mail
+   Status:  standard
+   Author/Change controller:  IETF
+   Specification document(s):  This document (section 3.6.6)
+
+   Header field name:  Resent-To
+   Applicable protocol:  Mail
+   Status:  standard
+   Author/Change controller:  IETF
+   Specification document(s):  This document (section 3.6.6)
+
+
+
+
+Resnick                     Standards Track                    [Page 41]
+
+RFC 5322                Internet Message Format             October 2008
+
+
+   Header field name:  Resent-Cc
+   Applicable protocol:  Mail
+   Status:  standard
+   Author/Change controller:  IETF
+   Specification document(s):  This document (section 3.6.6)
+
+   Header field name:  Resent-Bcc
+   Applicable protocol:  Mail
+   Status:  standard
+   Author/Change controller:  IETF
+   Specification document(s):  This document (section 3.6.6)
+
+   Header field name:  Resent-Reply-To
+   Applicable protocol:  Mail
+   Status:  obsolete
+   Author/Change controller:  IETF
+   Specification document(s):  This document (section 4.5.6)
+
+   Header field name:  Resent-Message-ID
+   Applicable protocol:  Mail
+   Status:  standard
+   Author/Change controller:  IETF
+   Specification document(s):  This document (section 3.6.6)
+
+   Header field name:  Return-Path
+   Applicable protocol:  Mail
+   Status:  standard
+   Author/Change controller:  IETF
+   Specification document(s):  This document (section 3.6.7)
+
+   Header field name:  Received
+   Applicable protocol:  Mail
+   Status:  standard
+   Author/Change controller:  IETF
+   Specification document(s):  This document (section 3.6.7)
+   Related information:  [RFC5321]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Resnick                     Standards Track                    [Page 42]
+
+RFC 5322                Internet Message Format             October 2008
+
+
+Appendix A.  Example Messages
+
+   This section presents a selection of messages.  These are intended to
+   assist in the implementation of this specification, 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.
+
+   In the text version of this document, messages in this section are
+   delimited between lines of "----".  The "----" lines are not part of
+   the message itself.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Resnick                     Standards Track                    [Page 43]
+
+RFC 5322                Internet Message Format             October 2008
+
+
+Appendix A.1.  Addressing Examples
+
+   The following are examples of messages that might be sent between two
+   individuals.
+
+Appendix 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, even 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".
+   ----
+
+
+
+
+
+
+
+
+
+
+
+
+
+Resnick                     Standards Track                    [Page 44]
+
+RFC 5322                Internet Message Format             October 2008
+
+
+Appendix 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
+   constructs).  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.
+
+Appendix A.1.3.  Group Addresses
+
+   ----
+   From: Pete <pete@silly.example>
+   To: A Group:Ed 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.
+
+
+
+
+
+
+
+
+
+
+
+Resnick                     Standards Track                    [Page 45]
+
+RFC 5322                Internet Message Format             October 2008
+
+
+Appendix A.2.  Reply Messages
+
+   The following is a series of three messages that make up a
+   conversation thread between John and Mary.  John first 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.
+
+
+
+
+
+
+
+
+
+
+
+Resnick                     Standards Track                    [Page 46]
+
+RFC 5322                Internet Message Format             October 2008
+
+
+   ----
+   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.test>
+   In-Reply-To: <3456@example.net>
+   References: <1234@local.machine.example> <3456@example.net>
+
+   This is a reply to your reply.
+   ----
+
+Appendix 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:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Resnick                     Standards Track                    [Page 47]
+
+RFC 5322                Internet Message Format             October 2008
+
+
+   ----
+   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.  (Note that for brevity, trace fields are not shown.)
+
+Appendix A.4.  Messages with Trace Fields
+
+   As messages are sent through the transport system as described in
+   [RFC5321], 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 node.example by x.y.test; 21 Nov 1997 10:01:22 -0600
+   From: John Doe <jdoe@node.example>
+   To: Mary Smith <mary@example.net>
+   Subject: Saying Hello
+   Date: Fri, 21 Nov 1997 09:55:06 -0600
+   Message-ID: <1234@local.node.example>
+
+   This is a message just to say hello.
+   So, "Hello".
+   ----
+
+
+
+
+
+
+
+Resnick                     Standards Track                    [Page 48]
+
+RFC 5322                Internet Message Format             October 2008
+
+
+Appendix 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 nice \) 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)Hidden 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Resnick                     Standards Track                    [Page 49]
+
+RFC 5322                Internet Message Format             October 2008
+
+
+Appendix 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.
+
+Appendix A.6.1.  Obsolete Addressing
+
+   Note in the example below 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 <@node.test: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.
+   ----
+
+Appendix 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".
+   ----
+
+
+
+
+
+
+
+
+
+
+
+
+Resnick                     Standards Track                    [Page 50]
+
+RFC 5322                Internet Message Format             October 2008
+
+
+Appendix 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Resnick                     Standards Track                    [Page 51]
+
+RFC 5322                Internet Message Format             October 2008
+
+
+Appendix B.  Differences from Earlier Specifications
+
+   This appendix contains a list of changes that have been made in the
+   Internet Message Format from earlier specifications, specifically
+   [RFC0822], [RFC1123], and [RFC2822].  Items marked with an asterisk
+   (*) below are items which appear in section 4 of this document and
+   therefore can no longer be generated.
+
+   The following are the changes made from [RFC0822] and [RFC1123] to
+   [RFC2822] that remain in this document:
+
+   1.   Period allowed in obsolete form of phrase.
+   2.   ABNF moved out of document, now in [RFC5234].
+   3.   Four or more digits allowed for year.
+   4.   Header field ordering (and lack thereof) made explicit.
+   5.   Encrypted header field removed.
+   6.   Specifically allow and give meaning to "-0000" time zone.
+   7.   Folding white space is not allowed between every token.
+   8.   Requirement for destinations removed.
+   9.   Forwarding and resending redefined.
+   10.  Extension header fields no longer specifically called out.
+   11.  ASCII 0 (null) removed.*
+   12.  Folding continuation lines cannot contain only white space.*
+   13.  Free insertion of comments not allowed in date.*
+   14.  Non-numeric time zones not allowed.*
+   15.  Two digit years not allowed.*
+   16.  Three digit years interpreted, but not allowed for generation.*
+   17.  Routes in addresses not allowed.*
+   18.  CFWS within local-parts and domains not allowed.*
+   19.  Empty members of address lists not allowed.*
+   20.  Folding white space between field name and colon not allowed.*
+   21.  Comments between field name and colon not allowed.
+   22.  Tightened syntax of in-reply-to and references.*
+   23.  CFWS within msg-id not allowed.*
+   24.  Tightened semantics of resent fields as informational only.
+   25.  Resent-Reply-To not allowed.*
+   26.  No multiple occurrences of fields (except resent and received).*
+   27.  Free CR and LF not allowed.*
+   28.  Line length limits specified.
+   29.  Bcc more clearly specified.
+
+
+
+
+
+
+
+
+
+
+
+Resnick                     Standards Track                    [Page 52]
+
+RFC 5322                Internet Message Format             October 2008
+
+
+   The following are changes from [RFC2822].
+   1.   Assorted typographical/grammatical errors fixed and
+        clarifications made.
+   2.   Changed "standard" to "document" or "specification" throughout.
+   3.   Made distinction between "header field" and "header section".
+   4.   Removed NO-WS-CTL from ctext, qtext, dtext, and unstructured.*
+   5.   Moved discussion of specials to the "Atom" section.  Moved text
+        to "Overall message syntax" section.
+   6.   Simplified CFWS syntax.
+   7.   Fixed unstructured syntax.
+   8.   Changed date and time syntax to deal with white space in
+        obsolete date syntax.
+   9.   Removed quoted-pair from domain literals and message
+        identifiers.*
+   10.  Clarified that other specifications limit domain syntax.
+   11.  Simplified "Bcc:" and "Resent-Bcc:" syntax.
+   12.  Allowed optional-field to appear within trace information.
+   13.  Removed no-fold-quote from msg-id.  Clarified syntax
+        limitations.
+   14.  Generalized "Received:" syntax to fix bugs and move definition
+        out of this document.
+   15.  Simplified obs-qp.  Fixed and simplified obs-utext (which now
+        only appears in the obsolete syntax).  Removed obs-text and obs-
+        char, adding obs-body.
+   16.  Fixed obsolete date syntax to allow for more (or less) comments
+        and white space.
+   17.  Fixed all obsolete list syntax (obs-domain-list, obs-mbox-list,
+        obs-addr-list, obs-phrase-list, and the newly added obs-group-
+        list).
+   18.  Fixed obs-reply-to syntax.
+   19.  Fixed obs-bcc and obs-resent-bcc to allow empty lists.
+   20.  Removed obs-path.
+
+Appendix C.  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 email.  The editor is
+   deeply indebted to them all and thanks them sincerely.  The below
+   list includes everyone who sent email concerning both this document
+   and [RFC2822].  Hopefully, everyone who contributed is named here:
+
+   +--------------------+----------------------+---------------------+
+   | Matti Aarnio       | Tanaka Akira         | Russ Allbery        |
+   | Eric Allman        | Harald Alvestrand    | Ran Atkinson        |
+   | Jos Backus         | Bruce Balden         | Dave Barr           |
+
+
+
+Resnick                     Standards Track                    [Page 53]
+
+RFC 5322                Internet Message Format             October 2008
+
+
+   | Alan Barrett       | John Beck            | J Robert von Behren |
+   | Jos den Bekker     | D J Bernstein        | James Berriman      |
+   | Oliver Block       | Norbert Bollow       | Raj Bose            |
+   | Antony Bowesman    | Scott Bradner        | Randy Bush          |
+   | Tom Byrer          | Bruce Campbell       | Larry Campbell      |
+   | W J Carpenter      | Michael Chapman      | Richard Clayton     |
+   | Maurizio Codogno   | Jim Conklin          | R Kelley Cook       |
+   | Nathan Coulter     | Steve Coya           | Mark Crispin        |
+   | Dave Crocker       | Matt Curtin          | Michael D'Errico    |
+   | Cyrus Daboo        | Michael D Dean       | Jutta Degener       |
+   | Mark Delany        | Steve Dorner         | Harold A Driscoll   |
+   | Michael Elkins     | Frank Ellerman       | Robert Elz          |
+   | Johnny Eriksson    | Erik E Fair          | Roger Fajman        |
+   | Patrik Faltstrom   | Claus Andre Faerber  | Barry Finkel        |
+   | Erik Forsberg      | Chuck Foster         | Paul Fox            |
+   | Klaus M Frank      | Ned Freed            | Jochen Friedrich    |
+   | Randall C Gellens  | Sukvinder Singh Gill | Tim Goodwin         |
+   | Philip Guenther    | Arnt Gulbrandsen     | Eric A Hall         |
+   | Tony Hansen        | John Hawkinson       | Philip Hazel        |
+   | Kai Henningsen     | Robert Herriot       | Paul Hethmon        |
+   | Jim Hill           | Alfred Hoenes        | Paul E Hoffman      |
+   | Steve Hole         | Kari Hurtta          | Marco S Hyman       |
+   | Ofer Inbar         | Olle Jarnefors       | Kevin Johnson       |
+   | Sudish Joseph      | Maynard Kang         | Prabhat Keni        |
+   | John C Klensin     | Graham Klyne         | Brad Knowles        |
+   | Shuhei Kobayashi   | Peter Koch           | Dan Kohn            |
+   | Christian Kuhtz    | Anand Kumria         | Steen Larsen        |
+   | Eliot Lear         | Barry Leiba          | Jay Levitt          |
+   | Bruce Lilly        | Lars-Johan Liman     | Charles Lindsey     |
+   | Pete Loshin        | Simon Lyall          | Bill Manning        |
+   | John Martin        | Mark Martinec        | Larry Masinter      |
+   | Denis McKeon       | William P McQuillan  | Alexey Melnikov     |
+   | Perry E Metzger    | Steven Miller        | S Moonesamy         |
+   | Keith Moore        | John Gardiner Myers  | Chris Newman        |
+   | John W Noerenberg  | Eric Norman          | Mike O'Dell         |
+   | Larry Osterman     | Paul Overell         | Jacob Palme         |
+   | Michael A Patton   | Uzi Paz              | Michael A Quinlan   |
+   | Robert Rapplean    | Eric S Raymond       | Sam Roberts         |
+   | Hugh Sasse         | Bart Schaefer        | Tom Scola           |
+   | Wolfgang Segmuller | Nick Shelness        | John Stanley        |
+   | Einar Stefferud    | Jeff Stephenson      | Bernard Stern       |
+   | Peter Sylvester    | Mark Symons          | Eric Thomas         |
+   | Lee Thompson       | Karel De Vriendt     | Matthew Wall        |
+   | Rolf Weber         | Brent B Welch        | Dan Wing            |
+   | Jack De Winter     | Gregory J Woodhouse  | Greg A Woods        |
+   | Kazu Yamamoto      | Alain Zahm           | Jamie Zawinski      |
+   | Timothy S Zurcher  |                      |                     |
+   +--------------------+----------------------+---------------------+
+
+
+
+Resnick                     Standards Track                    [Page 54]
+
+RFC 5322                Internet Message Format             October 2008
+
+
+7.  References
+
+7.1.  Normative References
+
+   [ANSI.X3-4.1986]  American National Standards Institute, "Coded
+                     Character Set - 7-bit American Standard Code for
+                     Information Interchange", ANSI X3.4, 1986.
+
+   [RFC1034]         Mockapetris, P., "Domain names - concepts and
+                     facilities", STD 13, RFC 1034, November 1987.
+
+   [RFC1035]         Mockapetris, P., "Domain names - implementation and
+                     specification", STD 13, RFC 1035, November 1987.
+
+   [RFC1123]         Braden, R., "Requirements for Internet Hosts -
+                     Application and Support", STD 3, RFC 1123,
+                     October 1989.
+
+   [RFC2119]         Bradner, S., "Key words for use in RFCs to Indicate
+                     Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC5234]         Crocker, D. and P. Overell, "Augmented BNF for
+                     Syntax Specifications: ABNF", STD 68, RFC 5234,
+                     January 2008.
+
+7.2.  Informative References
+
+   [RFC0822]         Crocker, D., "Standard for the format of ARPA
+                     Internet text messages", STD 11, RFC 822,
+                     August 1982.
+
+   [RFC1305]         Mills, D., "Network Time Protocol (Version 3)
+                     Specification, Implementation", RFC 1305,
+                     March 1992.
+
+   [ISO.2022.1994]   International Organization for Standardization,
+                     "Information technology - Character code structure
+                     and extension techniques", ISO Standard 2022, 1994.
+
+   [RFC2045]         Freed, N. and N. Borenstein, "Multipurpose Internet
+                     Mail Extensions (MIME) Part One: Format of Internet
+                     Message Bodies", RFC 2045, November 1996.
+
+   [RFC2046]         Freed, N. and N. Borenstein, "Multipurpose Internet
+                     Mail Extensions (MIME) Part Two: Media Types",
+                     RFC 2046, November 1996.
+
+
+
+
+
+Resnick                     Standards Track                    [Page 55]
+
+RFC 5322                Internet Message Format             October 2008
+
+
+   [RFC2047]         Moore, K., "MIME (Multipurpose Internet Mail
+                     Extensions) Part Three: Message Header Extensions
+                     for Non-ASCII Text", RFC 2047, November 1996.
+
+   [RFC2049]         Freed, N. and N. Borenstein, "Multipurpose Internet
+                     Mail Extensions (MIME) Part Five: Conformance
+                     Criteria and Examples", RFC 2049, November 1996.
+
+   [RFC2822]         Resnick, P., "Internet Message Format", RFC 2822,
+                     April 2001.
+
+   [RFC3864]         Klyne, G., Nottingham, M., and J. Mogul,
+                     "Registration Procedures for Message Header
+                     Fields", BCP 90, RFC 3864, September 2004.
+
+   [RFC4021]         Klyne, G. and J. Palme, "Registration of Mail and
+                     MIME Header Fields", RFC 4021, March 2005.
+
+   [RFC4288]         Freed, N. and J. Klensin, "Media Type
+                     Specifications and Registration Procedures",
+                     BCP 13, RFC 4288, December 2005.
+
+   [RFC4289]         Freed, N. and J. Klensin, "Multipurpose Internet
+                     Mail Extensions (MIME) Part Four: Registration
+                     Procedures", BCP 13, RFC 4289, December 2005.
+
+   [RFC5321]         Klensin, J., "Simple Mail Transfer Protocol",
+                     RFC 5321, October 2008.
+
+Author's Address
+
+   Peter W. Resnick (editor)
+   Qualcomm Incorporated
+   5775 Morehouse Drive
+   San Diego, CA  92121-1714
+   US
+
+   Phone: +1 858 651 4478
+   EMail: presnick@qualcomm.com
+   URI:   http://www.qualcomm.com/~presnick/
+
+
+
+
+
+
+
+
+
+
+
+Resnick                     Standards Track                    [Page 56]
+
+RFC 5322                Internet Message Format             October 2008
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2008).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+Resnick                     Standards Track                    [Page 57]
+

ccan/rfc822/rfc822.c

@@ -150,29 +150,33 @@ static struct rfc822_header *next_header_parse(struct rfc822_msg *msg)
 	if (msg->body && (msg->remainder >= msg->body))
 		return NULL;
 
-	eh = h = msg->remainder;
-	do {
-		eh = next_line(eh, msg->end);
-	} while ((eh < msg->end) && rfc822_iswsp(*eh));
-
-	if (eh >= msg->end)
-		msg->remainder = NULL;
-	else
-		msg->remainder = eh;
+	h = msg->remainder;
+	eh = next_line(h, msg->end);
 
 	ev = eh;
 	if ((ev > h) && (ev[-1] == '\n'))
 		ev--;
 	if ((ev > h) && (ev[-1] == '\r'))
 		ev--;
-
 	if (ev == h) {
 		/* Found the end of the headers */
+
+		assert(!msg->body || (msg->body == eh));
+
 		if (eh < msg->end)
 			msg->body = eh;
 		return NULL;
 	}
 
+	while ((eh < msg->end) && rfc822_iswsp(*eh))
+		eh = next_line(eh, msg->end);
+
+	if (eh >= msg->end)
+		msg->remainder = NULL;
+	else
+		msg->remainder = eh;
+
+
 	hi = talloc_zero(msg, struct rfc822_header);
 	ALLOC_CHECK(hi, NULL);
 

ccan/rfc822/test/run-hdr-and-body.c

@@ -45,7 +45,7 @@ static void check_header(struct rfc822_msg *msg,
 	allocation_failure_check();
 
 	ok(hname.ptr && bytestring_eq(hname, bytestring_from_string(name)),
-	   "Header name \"%.*s\"", hname.len, hname.ptr);
+	   "Header name \"%.*s\"", (int)hname.len, hname.ptr);
 
 	hvalue = rfc822_header_raw_value(msg, h);
 	allocation_failure_check();

ccan/rfc822/test/run-unfold.c

@@ -89,7 +89,7 @@ static void check_folded_header(const char *buf, size_t len)
 	hunfold = rfc822_header_unfolded_value(msg, hdr);
 	allocation_failure_check();
 
-	ok(hunfold.len == strlen(UNFOLDED), "Unfolded length %d, should be %d",
+	ok(hunfold.len == strlen(UNFOLDED), "Unfolded length %zd, should be %zd",
 	   hunfold.len, strlen(UNFOLDED));
 	ok1(memcmp(hunfold.ptr, UNFOLDED, hunfold.len) == 0);
 

ccan/rfc822/test/testdata.h

@@ -53,11 +53,15 @@ AEXAMPLE(test_msg_nlnl_crlf);
 const char test_msg_nlnl_mixed_body[] = "Message containing both \n\n and \r\n\r\n inside body\n\r\n";
 AEXAMPLE(test_msg_nlnl_mixed);
 
+#define test_msg_space_body_hdrs test_msg_1_hdrs
+const char test_msg_space_body_body[] = " Message with LWS at start of body\n";
+AEXAMPLE(test_msg_space_body);
 
 #define for_each_aexample(_e)				     \
 	foreach_ptr((_e), &test_msg_1, &test_msg_empty_body, \
 		    &test_msg_nlnl_lf, &test_msg_nlnl_crlf, \
-		    &test_msg_nlnl_mixed)
+		    &test_msg_nlnl_mixed, \
+		    &test_msg_space_body)
 
 #define for_each_aexample_buf(_e, _buf, _len)	\
 	for_each_aexample((_e)) 		\