rohrpost

A commandline mail client to change the world as we see it.
git clone git://r-36.net/rohrpost
Log | Files | Refs | README | LICENSE

rfc5322.txt (122322B)


      1 
      2 
      3 
      4 
      5 
      6 
      7 Network Working Group                                    P. Resnick, Ed.
      8 Request for Comments: 5322                         Qualcomm Incorporated
      9 Obsoletes: 2822                                             October 2008
     10 Updates: 4021
     11 Category: Standards Track
     12 
     13 
     14                         Internet Message Format
     15 
     16 Status of This Memo
     17 
     18    This document specifies an Internet standards track protocol for the
     19    Internet community, and requests discussion and suggestions for
     20    improvements.  Please refer to the current edition of the "Internet
     21    Official Protocol Standards" (STD 1) for the standardization state
     22    and status of this protocol.  Distribution of this memo is unlimited.
     23 
     24 Abstract
     25 
     26    This document specifies the Internet Message Format (IMF), a syntax
     27    for text messages that are sent between computer users, within the
     28    framework of "electronic mail" messages.  This specification is a
     29    revision of Request For Comments (RFC) 2822, which itself superseded
     30    Request For Comments (RFC) 822, "Standard for the Format of ARPA
     31    Internet Text Messages", updating it to reflect current practice and
     32    incorporating incremental changes that were specified in other RFCs.
     33 
     34 
     35 
     36 
     37 
     38 
     39 
     40 
     41 
     42 
     43 
     44 
     45 
     46 
     47 
     48 
     49 
     50 
     51 
     52 
     53 
     54 
     55 
     56 
     57 
     58 Resnick                     Standards Track                     [Page 1]
     59 
     60 RFC 5322                Internet Message Format             October 2008
     61 
     62 
     63 Table of Contents
     64 
     65    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     66      1.1.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     67      1.2.  Notational Conventions . . . . . . . . . . . . . . . . . .  5
     68        1.2.1.  Requirements Notation  . . . . . . . . . . . . . . . .  5
     69        1.2.2.  Syntactic Notation . . . . . . . . . . . . . . . . . .  5
     70        1.2.3.  Structure of This Document . . . . . . . . . . . . . .  5
     71    2.  Lexical Analysis of Messages . . . . . . . . . . . . . . . . .  6
     72      2.1.  General Description  . . . . . . . . . . . . . . . . . . .  6
     73        2.1.1.  Line Length Limits . . . . . . . . . . . . . . . . . .  7
     74      2.2.  Header Fields  . . . . . . . . . . . . . . . . . . . . . .  8
     75        2.2.1.  Unstructured Header Field Bodies . . . . . . . . . . .  8
     76        2.2.2.  Structured Header Field Bodies . . . . . . . . . . . .  8
     77        2.2.3.  Long Header Fields . . . . . . . . . . . . . . . . . .  8
     78      2.3.  Body . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     79    3.  Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     80      3.1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . 10
     81      3.2.  Lexical Tokens . . . . . . . . . . . . . . . . . . . . . . 10
     82        3.2.1.  Quoted characters  . . . . . . . . . . . . . . . . . . 10
     83        3.2.2.  Folding White Space and Comments . . . . . . . . . . . 11
     84        3.2.3.  Atom . . . . . . . . . . . . . . . . . . . . . . . . . 12
     85        3.2.4.  Quoted Strings . . . . . . . . . . . . . . . . . . . . 13
     86        3.2.5.  Miscellaneous Tokens . . . . . . . . . . . . . . . . . 14
     87      3.3.  Date and Time Specification  . . . . . . . . . . . . . . . 14
     88      3.4.  Address Specification  . . . . . . . . . . . . . . . . . . 16
     89        3.4.1.  Addr-Spec Specification  . . . . . . . . . . . . . . . 17
     90      3.5.  Overall Message Syntax . . . . . . . . . . . . . . . . . . 18
     91      3.6.  Field Definitions  . . . . . . . . . . . . . . . . . . . . 19
     92        3.6.1.  The Origination Date Field . . . . . . . . . . . . . . 22
     93        3.6.2.  Originator Fields  . . . . . . . . . . . . . . . . . . 22
     94        3.6.3.  Destination Address Fields . . . . . . . . . . . . . . 23
     95        3.6.4.  Identification Fields  . . . . . . . . . . . . . . . . 25
     96        3.6.5.  Informational Fields . . . . . . . . . . . . . . . . . 27
     97        3.6.6.  Resent Fields  . . . . . . . . . . . . . . . . . . . . 28
     98        3.6.7.  Trace Fields . . . . . . . . . . . . . . . . . . . . . 30
     99        3.6.8.  Optional Fields  . . . . . . . . . . . . . . . . . . . 30
    100    4.  Obsolete Syntax  . . . . . . . . . . . . . . . . . . . . . . . 31
    101      4.1.  Miscellaneous Obsolete Tokens  . . . . . . . . . . . . . . 32
    102      4.2.  Obsolete Folding White Space . . . . . . . . . . . . . . . 33
    103      4.3.  Obsolete Date and Time . . . . . . . . . . . . . . . . . . 33
    104      4.4.  Obsolete Addressing  . . . . . . . . . . . . . . . . . . . 35
    105      4.5.  Obsolete Header Fields . . . . . . . . . . . . . . . . . . 35
    106        4.5.1.  Obsolete Origination Date Field  . . . . . . . . . . . 36
    107        4.5.2.  Obsolete Originator Fields . . . . . . . . . . . . . . 36
    108        4.5.3.  Obsolete Destination Address Fields  . . . . . . . . . 37
    109        4.5.4.  Obsolete Identification Fields . . . . . . . . . . . . 37
    110        4.5.5.  Obsolete Informational Fields  . . . . . . . . . . . . 37
    111 
    112 
    113 
    114 Resnick                     Standards Track                     [Page 2]
    115 
    116 RFC 5322                Internet Message Format             October 2008
    117 
    118 
    119        4.5.6.  Obsolete Resent Fields . . . . . . . . . . . . . . . . 38
    120        4.5.7.  Obsolete Trace Fields  . . . . . . . . . . . . . . . . 38
    121        4.5.8.  Obsolete optional fields . . . . . . . . . . . . . . . 38
    122    5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 38
    123    6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 39
    124    Appendix A.     Example Messages . . . . . . . . . . . . . . . . . 43
    125    Appendix A.1.   Addressing Examples  . . . . . . . . . . . . . . . 44
    126    Appendix A.1.1. A Message from One Person to Another with
    127                    Simple Addressing  . . . . . . . . . . . . . . . . 44
    128    Appendix A.1.2. Different Types of Mailboxes . . . . . . . . . . . 45
    129    Appendix A.1.3. Group Addresses  . . . . . . . . . . . . . . . . . 45
    130    Appendix A.2.   Reply Messages . . . . . . . . . . . . . . . . . . 46
    131    Appendix A.3.   Resent Messages  . . . . . . . . . . . . . . . . . 47
    132    Appendix A.4.   Messages with Trace Fields . . . . . . . . . . . . 48
    133    Appendix A.5.   White Space, Comments, and Other Oddities  . . . . 49
    134    Appendix A.6.   Obsoleted Forms  . . . . . . . . . . . . . . . . . 50
    135    Appendix A.6.1. Obsolete Addressing  . . . . . . . . . . . . . . . 50
    136    Appendix A.6.2. Obsolete Dates . . . . . . . . . . . . . . . . . . 50
    137    Appendix A.6.3. Obsolete White Space and Comments  . . . . . . . . 51
    138    Appendix B.     Differences from Earlier Specifications  . . . . . 52
    139    Appendix C.     Acknowledgements . . . . . . . . . . . . . . . . . 53
    140    7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 55
    141      7.1.  Normative References . . . . . . . . . . . . . . . . . . . 55
    142      7.2.  Informative References . . . . . . . . . . . . . . . . . . 55
    143 
    144 
    145 
    146 
    147 
    148 
    149 
    150 
    151 
    152 
    153 
    154 
    155 
    156 
    157 
    158 
    159 
    160 
    161 
    162 
    163 
    164 
    165 
    166 
    167 
    168 
    169 
    170 Resnick                     Standards Track                     [Page 3]
    171 
    172 RFC 5322                Internet Message Format             October 2008
    173 
    174 
    175 1.  Introduction
    176 
    177 1.1.  Scope
    178 
    179    This document specifies the Internet Message Format (IMF), a syntax
    180    for text messages that are sent between computer users, within the
    181    framework of "electronic mail" messages.  This specification is an
    182    update to [RFC2822], which itself superseded [RFC0822], updating it
    183    to reflect current practice and incorporating incremental changes
    184    that were specified in other RFCs such as [RFC1123].
    185 
    186    This document specifies a syntax only for text messages.  In
    187    particular, it makes no provision for the transmission of images,
    188    audio, or other sorts of structured data in electronic mail messages.
    189    There are several extensions published, such as the MIME document
    190    series ([RFC2045], [RFC2046], [RFC2049]), which describe mechanisms
    191    for the transmission of such data through electronic mail, either by
    192    extending the syntax provided here or by structuring such messages to
    193    conform to this syntax.  Those mechanisms are outside of the scope of
    194    this specification.
    195 
    196    In the context of electronic mail, messages are viewed as having an
    197    envelope and contents.  The envelope contains whatever information is
    198    needed to accomplish transmission and delivery.  (See [RFC5321] for a
    199    discussion of the envelope.)  The contents comprise the object to be
    200    delivered to the recipient.  This specification applies only to the
    201    format and some of the semantics of message contents.  It contains no
    202    specification of the information in the envelope.
    203 
    204    However, some message systems may use information from the contents
    205    to create the envelope.  It is intended that this specification
    206    facilitate the acquisition of such information by programs.
    207 
    208    This specification is intended as a definition of what message
    209    content format is to be passed between systems.  Though some message
    210    systems locally store messages in this format (which eliminates the
    211    need for translation between formats) and others use formats that
    212    differ from the one specified in this specification, local storage is
    213    outside of the scope of this specification.
    214 
    215       Note: This specification is not intended to dictate the internal
    216       formats used by sites, the specific message system features that
    217       they are expected to support, or any of the characteristics of
    218       user interface programs that create or read messages.  In
    219       addition, this document does not specify an encoding of the
    220       characters for either transport or storage; that is, it does not
    221       specify the number of bits used or how those bits are specifically
    222       transferred over the wire or stored on disk.
    223 
    224 
    225 
    226 Resnick                     Standards Track                     [Page 4]
    227 
    228 RFC 5322                Internet Message Format             October 2008
    229 
    230 
    231 1.2.  Notational Conventions
    232 
    233 1.2.1.  Requirements Notation
    234 
    235    This document occasionally uses terms that appear in capital letters.
    236    When the terms "MUST", "SHOULD", "RECOMMENDED", "MUST NOT", "SHOULD
    237    NOT", and "MAY" appear capitalized, they are being used to indicate
    238    particular requirements of this specification.  A discussion of the
    239    meanings of these terms appears in [RFC2119].
    240 
    241 1.2.2.  Syntactic Notation
    242 
    243    This specification uses the Augmented Backus-Naur Form (ABNF)
    244    [RFC5234] notation for the formal definitions of the syntax of
    245    messages.  Characters will be specified either by a decimal value
    246    (e.g., the value %d65 for uppercase A and %d97 for lowercase A) or by
    247    a case-insensitive literal value enclosed in quotation marks (e.g.,
    248    "A" for either uppercase or lowercase A).
    249 
    250 1.2.3.  Structure of This Document
    251 
    252    This document is divided into several sections.
    253 
    254    This section, section 1, is a short introduction to the document.
    255 
    256    Section 2 lays out the general description of a message and its
    257    constituent parts.  This is an overview to help the reader understand
    258    some of the general principles used in the later portions of this
    259    document.  Any examples in this section MUST NOT be taken as
    260    specification of the formal syntax of any part of a message.
    261 
    262    Section 3 specifies formal ABNF rules for the structure of each part
    263    of a message (the syntax) and describes the relationship between
    264    those parts and their meaning in the context of a message (the
    265    semantics).  That is, it lays out the actual rules for the structure
    266    of each part of a message (the syntax) as well as a description of
    267    the parts and instructions for their interpretation (the semantics).
    268    This includes analysis of the syntax and semantics of subparts of
    269    messages that have specific structure.  The syntax included in
    270    section 3 represents messages as they MUST be created.  There are
    271    also notes in section 3 to indicate if any of the options specified
    272    in the syntax SHOULD be used over any of the others.
    273 
    274    Both sections 2 and 3 describe messages that are legal to generate
    275    for purposes of this specification.
    276 
    277 
    278 
    279 
    280 
    281 
    282 Resnick                     Standards Track                     [Page 5]
    283 
    284 RFC 5322                Internet Message Format             October 2008
    285 
    286 
    287    Section 4 of this document specifies an "obsolete" syntax.  There are
    288    references in section 3 to these obsolete syntactic elements.  The
    289    rules of the obsolete syntax are elements that have appeared in
    290    earlier versions of this specification or have previously been widely
    291    used in Internet messages.  As such, these elements MUST be
    292    interpreted by parsers of messages in order to be conformant to this
    293    specification.  However, since items in this syntax have been
    294    determined to be non-interoperable or to cause significant problems
    295    for recipients of messages, they MUST NOT be generated by creators of
    296    conformant messages.
    297 
    298    Section 5 details security considerations to take into account when
    299    implementing this specification.
    300 
    301    Appendix A lists examples of different sorts of messages.  These
    302    examples are not exhaustive of the types of messages that appear on
    303    the Internet, but give a broad overview of certain syntactic forms.
    304 
    305    Appendix B lists the differences between this specification and
    306    earlier specifications for Internet messages.
    307 
    308    Appendix C contains acknowledgements.
    309 
    310 2.  Lexical Analysis of Messages
    311 
    312 2.1.  General Description
    313 
    314    At the most basic level, a message is a series of characters.  A
    315    message that is conformant with this specification is composed of
    316    characters with values in the range of 1 through 127 and interpreted
    317    as US-ASCII [ANSI.X3-4.1986] characters.  For brevity, this document
    318    sometimes refers to this range of characters as simply "US-ASCII
    319    characters".
    320 
    321       Note: This document specifies that messages are made up of
    322       characters in the US-ASCII range of 1 through 127.  There are
    323       other documents, specifically the MIME document series ([RFC2045],
    324       [RFC2046], [RFC2047], [RFC2049], [RFC4288], [RFC4289]), that
    325       extend this specification to allow for values outside of that
    326       range.  Discussion of those mechanisms is not within the scope of
    327       this specification.
    328 
    329    Messages are divided into lines of characters.  A line is a series of
    330    characters that is delimited with the two characters carriage-return
    331    and line-feed; that is, the carriage return (CR) character (ASCII
    332    value 13) followed immediately by the line feed (LF) character (ASCII
    333    value 10).  (The carriage return/line feed pair is usually written in
    334    this document as "CRLF".)
    335 
    336 
    337 
    338 Resnick                     Standards Track                     [Page 6]
    339 
    340 RFC 5322                Internet Message Format             October 2008
    341 
    342 
    343    A message consists of header fields (collectively called "the header
    344    section of the message") followed, optionally, by a body.  The header
    345    section is a sequence of lines of characters with special syntax as
    346    defined in this specification.  The body is simply a sequence of
    347    characters that follows the header section and is separated from the
    348    header section by an empty line (i.e., a line with nothing preceding
    349    the CRLF).
    350 
    351       Note: Common parlance and earlier versions of this specification
    352       use the term "header" to either refer to the entire header section
    353       or to refer to an individual header field.  To avoid ambiguity,
    354       this document does not use the terms "header" or "headers" in
    355       isolation, but instead always uses "header field" to refer to the
    356       individual field and "header section" to refer to the entire
    357       collection.
    358 
    359 2.1.1.  Line Length Limits
    360 
    361    There are two limits that this specification places on the number of
    362    characters in a line.  Each line of characters MUST be no more than
    363    998 characters, and SHOULD be no more than 78 characters, excluding
    364    the CRLF.
    365 
    366    The 998 character limit is due to limitations in many implementations
    367    that send, receive, or store IMF messages which simply cannot handle
    368    more than 998 characters on a line.  Receiving implementations would
    369    do well to handle an arbitrarily large number of characters in a line
    370    for robustness sake.  However, there are so many implementations that
    371    (in compliance with the transport requirements of [RFC5321]) do not
    372    accept messages containing more than 1000 characters including the CR
    373    and LF per line, it is important for implementations not to create
    374    such messages.
    375 
    376    The more conservative 78 character recommendation is to accommodate
    377    the many implementations of user interfaces that display these
    378    messages which may truncate, or disastrously wrap, the display of
    379    more than 78 characters per line, in spite of the fact that such
    380    implementations are non-conformant to the intent of this
    381    specification (and that of [RFC5321] if they actually cause
    382    information to be lost).  Again, even though this limitation is put
    383    on messages, it is incumbent upon implementations that display
    384    messages to handle an arbitrarily large number of characters in a
    385    line (certainly at least up to the 998 character limit) for the sake
    386    of robustness.
    387 
    388 
    389 
    390 
    391 
    392 
    393 
    394 Resnick                     Standards Track                     [Page 7]
    395 
    396 RFC 5322                Internet Message Format             October 2008
    397 
    398 
    399 2.2.  Header Fields
    400 
    401    Header fields are lines beginning with a field name, followed by a
    402    colon (":"), followed by a field body, and terminated by CRLF.  A
    403    field name MUST be composed of printable US-ASCII characters (i.e.,
    404    characters that have values between 33 and 126, inclusive), except
    405    colon.  A field body may be composed of printable US-ASCII characters
    406    as well as the space (SP, ASCII value 32) and horizontal tab (HTAB,
    407    ASCII value 9) characters (together known as the white space
    408    characters, WSP).  A field body MUST NOT include CR and LF except
    409    when used in "folding" and "unfolding", as described in section
    410    2.2.3.  All field bodies MUST conform to the syntax described in
    411    sections 3 and 4 of this specification.
    412 
    413 2.2.1.  Unstructured Header Field Bodies
    414 
    415    Some field bodies in this specification are defined simply as
    416    "unstructured" (which is specified in section 3.2.5 as any printable
    417    US-ASCII characters plus white space characters) with no further
    418    restrictions.  These are referred to as unstructured field bodies.
    419    Semantically, unstructured field bodies are simply to be treated as a
    420    single line of characters with no further processing (except for
    421    "folding" and "unfolding" as described in section 2.2.3).
    422 
    423 2.2.2.  Structured Header Field Bodies
    424 
    425    Some field bodies in this specification have a syntax that is more
    426    restrictive than the unstructured field bodies described above.
    427    These are referred to as "structured" field bodies.  Structured field
    428    bodies are sequences of specific lexical tokens as described in
    429    sections 3 and 4 of this specification.  Many of these tokens are
    430    allowed (according to their syntax) to be introduced or end with
    431    comments (as described in section 3.2.2) as well as the white space
    432    characters, and those white space characters are subject to "folding"
    433    and "unfolding" as described in section 2.2.3.  Semantic analysis of
    434    structured field bodies is given along with their syntax.
    435 
    436 2.2.3.  Long Header Fields
    437 
    438    Each header field is logically a single line of characters comprising
    439    the field name, the colon, and the field body.  For convenience
    440    however, and to deal with the 998/78 character limitations per line,
    441    the field body portion of a header field can be split into a
    442    multiple-line representation; this is called "folding".  The general
    443    rule is that wherever this specification allows for folding white
    444    space (not simply WSP characters), a CRLF may be inserted before any
    445    WSP.
    446 
    447 
    448 
    449 
    450 Resnick                     Standards Track                     [Page 8]
    451 
    452 RFC 5322                Internet Message Format             October 2008
    453 
    454 
    455    For example, the header field:
    456 
    457    Subject: This is a test
    458 
    459    can be represented as:
    460 
    461    Subject: This
    462     is a test
    463 
    464       Note: Though structured field bodies are defined in such a way
    465       that folding can take place between many of the lexical tokens
    466       (and even within some of the lexical tokens), folding SHOULD be
    467       limited to placing the CRLF at higher-level syntactic breaks.  For
    468       instance, if a field body is defined as comma-separated values, it
    469       is recommended that folding occur after the comma separating the
    470       structured items in preference to other places where the field
    471       could be folded, even if it is allowed elsewhere.
    472 
    473    The process of moving from this folded multiple-line representation
    474    of a header field to its single line representation is called
    475    "unfolding".  Unfolding is accomplished by simply removing any CRLF
    476    that is immediately followed by WSP.  Each header field should be
    477    treated in its unfolded form for further syntactic and semantic
    478    evaluation.  An unfolded header field has no length restriction and
    479    therefore may be indeterminately long.
    480 
    481 2.3.  Body
    482 
    483    The body of a message is simply lines of US-ASCII characters.  The
    484    only two limitations on the body are as follows:
    485 
    486    o  CR and LF MUST only occur together as CRLF; they MUST NOT appear
    487       independently in the body.
    488    o  Lines of characters in the body MUST be limited to 998 characters,
    489       and SHOULD be limited to 78 characters, excluding the CRLF.
    490 
    491       Note: As was stated earlier, there are other documents,
    492       specifically the MIME documents ([RFC2045], [RFC2046], [RFC2049],
    493       [RFC4288], [RFC4289]), that extend (and limit) this specification
    494       to allow for different sorts of message bodies.  Again, these
    495       mechanisms are beyond the scope of this document.
    496 
    497 
    498 
    499 
    500 
    501 
    502 
    503 
    504 
    505 
    506 Resnick                     Standards Track                     [Page 9]
    507 
    508 RFC 5322                Internet Message Format             October 2008
    509 
    510 
    511 3.  Syntax
    512 
    513 3.1.  Introduction
    514 
    515    The syntax as given in this section defines the legal syntax of
    516    Internet messages.  Messages that are conformant to this
    517    specification MUST conform to the syntax in this section.  If there
    518    are options in this section where one option SHOULD be generated,
    519    that is indicated either in the prose or in a comment next to the
    520    syntax.
    521 
    522    For the defined expressions, a short description of the syntax and
    523    use is given, followed by the syntax in ABNF, followed by a semantic
    524    analysis.  The following primitive tokens that are used but otherwise
    525    unspecified are taken from the "Core Rules" of [RFC5234], Appendix
    526    B.1: CR, LF, CRLF, HTAB, SP, WSP, DQUOTE, DIGIT, ALPHA, and VCHAR.
    527 
    528    In some of the definitions, there will be non-terminals whose names
    529    start with "obs-".  These "obs-" elements refer to tokens defined in
    530    the obsolete syntax in section 4.  In all cases, these productions
    531    are to be ignored for the purposes of generating legal Internet
    532    messages and MUST NOT be used as part of such a message.  However,
    533    when interpreting messages, these tokens MUST be honored as part of
    534    the legal syntax.  In this sense, section 3 defines a grammar for the
    535    generation of messages, with "obs-" elements that are to be ignored,
    536    while section 4 adds grammar for the interpretation of messages.
    537 
    538 3.2.  Lexical Tokens
    539 
    540    The following rules are used to define an underlying lexical
    541    analyzer, which feeds tokens to the higher-level parsers.  This
    542    section defines the tokens used in structured header field bodies.
    543 
    544       Note: Readers of this specification need to pay special attention
    545       to how these lexical tokens are used in both the lower-level and
    546       higher-level syntax later in the document.  Particularly, the
    547       white space tokens and the comment tokens defined in section 3.2.2
    548       get used in the lower-level tokens defined here, and those lower-
    549       level tokens are in turn used as parts of the higher-level tokens
    550       defined later.  Therefore, white space and comments may be allowed
    551       in the higher-level tokens even though they may not explicitly
    552       appear in a particular definition.
    553 
    554 3.2.1.  Quoted characters
    555 
    556    Some characters are reserved for special interpretation, such as
    557    delimiting lexical tokens.  To permit use of these characters as
    558    uninterpreted data, a quoting mechanism is provided.
    559 
    560 
    561 
    562 Resnick                     Standards Track                    [Page 10]
    563 
    564 RFC 5322                Internet Message Format             October 2008
    565 
    566 
    567    quoted-pair     =   ("\" (VCHAR / WSP)) / obs-qp
    568 
    569    Where any quoted-pair appears, it is to be interpreted as the
    570    character alone.  That is to say, the "\" character that appears as
    571    part of a quoted-pair is semantically "invisible".
    572 
    573       Note: The "\" character may appear in a message where it is not
    574       part of a quoted-pair.  A "\" character that does not appear in a
    575       quoted-pair is not semantically invisible.  The only places in
    576       this specification where quoted-pair currently appears are
    577       ccontent, qcontent, and in obs-dtext in section 4.
    578 
    579 3.2.2.  Folding White Space and Comments
    580 
    581    White space characters, including white space used in folding
    582    (described in section 2.2.3), may appear between many elements in
    583    header field bodies.  Also, strings of characters that are treated as
    584    comments may be included in structured field bodies as characters
    585    enclosed in parentheses.  The following defines the folding white
    586    space (FWS) and comment constructs.
    587 
    588    Strings of characters enclosed in parentheses are considered comments
    589    so long as they do not appear within a "quoted-string", as defined in
    590    section 3.2.4.  Comments may nest.
    591 
    592    There are several places in this specification where comments and FWS
    593    may be freely inserted.  To accommodate that syntax, an additional
    594    token for "CFWS" is defined for places where comments and/or FWS can
    595    occur.  However, where CFWS occurs in this specification, it MUST NOT
    596    be inserted in such a way that any line of a folded header field is
    597    made up entirely of WSP characters and nothing else.
    598 
    599    FWS             =   ([*WSP CRLF] 1*WSP) /  obs-FWS
    600                                           ; Folding white space
    601 
    602    ctext           =   %d33-39 /          ; Printable US-ASCII
    603                        %d42-91 /          ;  characters not including
    604                        %d93-126 /         ;  "(", ")", or "\"
    605                        obs-ctext
    606 
    607    ccontent        =   ctext / quoted-pair / comment
    608 
    609    comment         =   "(" *([FWS] ccontent) [FWS] ")"
    610 
    611    CFWS            =   (1*([FWS] comment) [FWS]) / FWS
    612 
    613 
    614 
    615 
    616 
    617 
    618 Resnick                     Standards Track                    [Page 11]
    619 
    620 RFC 5322                Internet Message Format             October 2008
    621 
    622 
    623    Throughout this specification, where FWS (the folding white space
    624    token) appears, it indicates a place where folding, as discussed in
    625    section 2.2.3, may take place.  Wherever folding appears in a message
    626    (that is, a header field body containing a CRLF followed by any WSP),
    627    unfolding (removal of the CRLF) is performed before any further
    628    semantic analysis is performed on that header field according to this
    629    specification.  That is to say, any CRLF that appears in FWS is
    630    semantically "invisible".
    631 
    632    A comment is normally used in a structured field body to provide some
    633    human-readable informational text.  Since a comment is allowed to
    634    contain FWS, folding is permitted within the comment.  Also note that
    635    since quoted-pair is allowed in a comment, the parentheses and
    636    backslash characters may appear in a comment, so long as they appear
    637    as a quoted-pair.  Semantically, the enclosing parentheses are not
    638    part of the comment; the comment is what is contained between the two
    639    parentheses.  As stated earlier, the "\" in any quoted-pair and the
    640    CRLF in any FWS that appears within the comment are semantically
    641    "invisible" and therefore not part of the comment either.
    642 
    643    Runs of FWS, comment, or CFWS that occur between lexical tokens in a
    644    structured header field are semantically interpreted as a single
    645    space character.
    646 
    647 3.2.3.  Atom
    648 
    649    Several productions in structured header field bodies are simply
    650    strings of certain basic characters.  Such productions are called
    651    atoms.
    652 
    653    Some of the structured header field bodies also allow the period
    654    character (".", ASCII value 46) within runs of atext.  An additional
    655    "dot-atom" token is defined for those purposes.
    656 
    657       Note: The "specials" token does not appear anywhere else in this
    658       specification.  It is simply the visible (i.e., non-control, non-
    659       white space) characters that do not appear in atext.  It is
    660       provided only because it is useful for implementers who use tools
    661       that lexically analyze messages.  Each of the characters in
    662       specials can be used to indicate a tokenization point in lexical
    663       analysis.
    664 
    665 
    666 
    667 
    668 
    669 
    670 
    671 
    672 
    673 
    674 Resnick                     Standards Track                    [Page 12]
    675 
    676 RFC 5322                Internet Message Format             October 2008
    677 
    678 
    679    atext           =   ALPHA / DIGIT /    ; Printable US-ASCII
    680                        "!" / "#" /        ;  characters not including
    681                        "$" / "%" /        ;  specials.  Used for atoms.
    682                        "&" / "'" /
    683                        "*" / "+" /
    684                        "-" / "/" /
    685                        "=" / "?" /
    686                        "^" / "_" /
    687                        "`" / "{" /
    688                        "|" / "}" /
    689                        "~"
    690 
    691    atom            =   [CFWS] 1*atext [CFWS]
    692 
    693    dot-atom-text   =   1*atext *("." 1*atext)
    694 
    695    dot-atom        =   [CFWS] dot-atom-text [CFWS]
    696 
    697    specials        =   "(" / ")" /        ; Special characters that do
    698                        "<" / ">" /        ;  not appear in atext
    699                        "[" / "]" /
    700                        ":" / ";" /
    701                        "@" / "\" /
    702                        "," / "." /
    703                        DQUOTE
    704 
    705    Both atom and dot-atom are interpreted as a single unit, comprising
    706    the string of characters that make it up.  Semantically, the optional
    707    comments and FWS surrounding the rest of the characters are not part
    708    of the atom; the atom is only the run of atext characters in an atom,
    709    or the atext and "." characters in a dot-atom.
    710 
    711 3.2.4.  Quoted Strings
    712 
    713    Strings of characters that include characters other than those
    714    allowed in atoms can be represented in a quoted string format, where
    715    the characters are surrounded by quote (DQUOTE, ASCII value 34)
    716    characters.
    717 
    718 
    719 
    720 
    721 
    722 
    723 
    724 
    725 
    726 
    727 
    728 
    729 
    730 Resnick                     Standards Track                    [Page 13]
    731 
    732 RFC 5322                Internet Message Format             October 2008
    733 
    734 
    735    qtext           =   %d33 /             ; Printable US-ASCII
    736                        %d35-91 /          ;  characters not including
    737                        %d93-126 /         ;  "\" or the quote character
    738                        obs-qtext
    739 
    740    qcontent        =   qtext / quoted-pair
    741 
    742    quoted-string   =   [CFWS]
    743                        DQUOTE *([FWS] qcontent) [FWS] DQUOTE
    744                        [CFWS]
    745 
    746    A quoted-string is treated as a unit.  That is, quoted-string is
    747    identical to atom, semantically.  Since a quoted-string is allowed to
    748    contain FWS, folding is permitted.  Also note that since quoted-pair
    749    is allowed in a quoted-string, the quote and backslash characters may
    750    appear in a quoted-string so long as they appear as a quoted-pair.
    751 
    752    Semantically, neither the optional CFWS outside of the quote
    753    characters nor the quote characters themselves are part of the
    754    quoted-string; the quoted-string is what is contained between the two
    755    quote characters.  As stated earlier, the "\" in any quoted-pair and
    756    the CRLF in any FWS/CFWS that appears within the quoted-string are
    757    semantically "invisible" and therefore not part of the quoted-string
    758    either.
    759 
    760 3.2.5.  Miscellaneous Tokens
    761 
    762    Three additional tokens are defined: word and phrase for combinations
    763    of atoms and/or quoted-strings, and unstructured for use in
    764    unstructured header fields and in some places within structured
    765    header fields.
    766 
    767    word            =   atom / quoted-string
    768 
    769    phrase          =   1*word / obs-phrase
    770 
    771    unstructured    =   (*([FWS] VCHAR) *WSP) / obs-unstruct
    772 
    773 3.3.  Date and Time Specification
    774 
    775    Date and time values occur in several header fields.  This section
    776    specifies the syntax for a full date and time specification.  Though
    777    folding white space is permitted throughout the date-time
    778    specification, it is RECOMMENDED that a single space be used in each
    779    place that FWS appears (whether it is required or optional); some
    780    older implementations will not interpret longer sequences of folding
    781    white space correctly.
    782 
    783 
    784 
    785 
    786 Resnick                     Standards Track                    [Page 14]
    787 
    788 RFC 5322                Internet Message Format             October 2008
    789 
    790 
    791    date-time       =   [ day-of-week "," ] date time [CFWS]
    792 
    793    day-of-week     =   ([FWS] day-name) / obs-day-of-week
    794 
    795    day-name        =   "Mon" / "Tue" / "Wed" / "Thu" /
    796                        "Fri" / "Sat" / "Sun"
    797 
    798    date            =   day month year
    799 
    800    day             =   ([FWS] 1*2DIGIT FWS) / obs-day
    801 
    802    month           =   "Jan" / "Feb" / "Mar" / "Apr" /
    803                        "May" / "Jun" / "Jul" / "Aug" /
    804                        "Sep" / "Oct" / "Nov" / "Dec"
    805 
    806    year            =   (FWS 4*DIGIT FWS) / obs-year
    807 
    808    time            =   time-of-day zone
    809 
    810    time-of-day     =   hour ":" minute [ ":" second ]
    811 
    812    hour            =   2DIGIT / obs-hour
    813 
    814    minute          =   2DIGIT / obs-minute
    815 
    816    second          =   2DIGIT / obs-second
    817 
    818    zone            =   (FWS ( "+" / "-" ) 4DIGIT) / obs-zone
    819 
    820    The day is the numeric day of the month.  The year is any numeric
    821    year 1900 or later.
    822 
    823    The time-of-day specifies the number of hours, minutes, and
    824    optionally seconds since midnight of the date indicated.
    825 
    826    The date and time-of-day SHOULD express local time.
    827 
    828    The zone specifies the offset from Coordinated Universal Time (UTC,
    829    formerly referred to as "Greenwich Mean Time") that the date and
    830    time-of-day represent.  The "+" or "-" indicates whether the time-of-
    831    day is ahead of (i.e., east of) or behind (i.e., west of) Universal
    832    Time.  The first two digits indicate the number of hours difference
    833    from Universal Time, and the last two digits indicate the number of
    834    additional minutes difference from Universal Time.  (Hence, +hhmm
    835    means +(hh * 60 + mm) minutes, and -hhmm means -(hh * 60 + mm)
    836    minutes).  The form "+0000" SHOULD be used to indicate a time zone at
    837    Universal Time.  Though "-0000" also indicates Universal Time, it is
    838 
    839 
    840 
    841 
    842 Resnick                     Standards Track                    [Page 15]
    843 
    844 RFC 5322                Internet Message Format             October 2008
    845 
    846 
    847    used to indicate that the time was generated on a system that may be
    848    in a local time zone other than Universal Time and that the date-time
    849    contains no information about the local time zone.
    850 
    851    A date-time specification MUST be semantically valid.  That is, the
    852    day-of-week (if included) MUST be the day implied by the date, the
    853    numeric day-of-month MUST be between 1 and the number of days allowed
    854    for the specified month (in the specified year), the time-of-day MUST
    855    be in the range 00:00:00 through 23:59:60 (the number of seconds
    856    allowing for a leap second; see [RFC1305]), and the last two digits
    857    of the zone MUST be within the range 00 through 59.
    858 
    859 3.4.  Address Specification
    860 
    861    Addresses occur in several message header fields to indicate senders
    862    and recipients of messages.  An address may either be an individual
    863    mailbox, or a group of mailboxes.
    864 
    865    address         =   mailbox / group
    866 
    867    mailbox         =   name-addr / addr-spec
    868 
    869    name-addr       =   [display-name] angle-addr
    870 
    871    angle-addr      =   [CFWS] "<" addr-spec ">" [CFWS] /
    872                        obs-angle-addr
    873 
    874    group           =   display-name ":" [group-list] ";" [CFWS]
    875 
    876    display-name    =   phrase
    877 
    878    mailbox-list    =   (mailbox *("," mailbox)) / obs-mbox-list
    879 
    880    address-list    =   (address *("," address)) / obs-addr-list
    881 
    882    group-list      =   mailbox-list / CFWS / obs-group-list
    883 
    884    A mailbox receives mail.  It is a conceptual entity that does not
    885    necessarily pertain to file storage.  For example, some sites may
    886    choose to print mail on a printer and deliver the output to the
    887    addressee's desk.
    888 
    889    Normally, a mailbox is composed of two parts: (1) an optional display
    890    name that indicates the name of the recipient (which can be a person
    891    or a system) that could be displayed to the user of a mail
    892    application, and (2) an addr-spec address enclosed in angle brackets
    893 
    894 
    895 
    896 
    897 
    898 Resnick                     Standards Track                    [Page 16]
    899 
    900 RFC 5322                Internet Message Format             October 2008
    901 
    902 
    903    ("<" and ">").  There is an alternate simple form of a mailbox where
    904    the addr-spec address appears alone, without the recipient's name or
    905    the angle brackets.  The Internet addr-spec address is described in
    906    section 3.4.1.
    907 
    908       Note: Some legacy implementations used the simple form where the
    909       addr-spec appears without the angle brackets, but included the
    910       name of the recipient in parentheses as a comment following the
    911       addr-spec.  Since the meaning of the information in a comment is
    912       unspecified, implementations SHOULD use the full name-addr form of
    913       the mailbox, instead of the legacy form, to specify the display
    914       name associated with a mailbox.  Also, because some legacy
    915       implementations interpret the comment, comments generally SHOULD
    916       NOT be used in address fields to avoid confusing such
    917       implementations.
    918 
    919    When it is desirable to treat several mailboxes as a single unit
    920    (i.e., in a distribution list), the group construct can be used.  The
    921    group construct allows the sender to indicate a named group of
    922    recipients.  This is done by giving a display name for the group,
    923    followed by a colon, followed by a comma-separated list of any number
    924    of mailboxes (including zero and one), and ending with a semicolon.
    925    Because the list of mailboxes can be empty, using the group construct
    926    is also a simple way to communicate to recipients that the message
    927    was sent to one or more named sets of recipients, without actually
    928    providing the individual mailbox address for any of those recipients.
    929 
    930 3.4.1.  Addr-Spec Specification
    931 
    932    An addr-spec is a specific Internet identifier that contains a
    933    locally interpreted string followed by the at-sign character ("@",
    934    ASCII value 64) followed by an Internet domain.  The locally
    935    interpreted string is either a quoted-string or a dot-atom.  If the
    936    string can be represented as a dot-atom (that is, it contains no
    937    characters other than atext characters or "." surrounded by atext
    938    characters), then the dot-atom form SHOULD be used and the quoted-
    939    string form SHOULD NOT be used.  Comments and folding white space
    940    SHOULD NOT be used around the "@" in the addr-spec.
    941 
    942       Note: A liberal syntax for the domain portion of addr-spec is
    943       given here.  However, the domain portion contains addressing
    944       information specified by and used in other protocols (e.g.,
    945       [RFC1034], [RFC1035], [RFC1123], [RFC5321]).  It is therefore
    946       incumbent upon implementations to conform to the syntax of
    947       addresses for the context in which they are used.
    948 
    949 
    950 
    951 
    952 
    953 
    954 Resnick                     Standards Track                    [Page 17]
    955 
    956 RFC 5322                Internet Message Format             October 2008
    957 
    958 
    959    addr-spec       =   local-part "@" domain
    960 
    961    local-part      =   dot-atom / quoted-string / obs-local-part
    962 
    963    domain          =   dot-atom / domain-literal / obs-domain
    964 
    965    domain-literal  =   [CFWS] "[" *([FWS] dtext) [FWS] "]" [CFWS]
    966 
    967    dtext           =   %d33-90 /          ; Printable US-ASCII
    968                        %d94-126 /         ;  characters not including
    969                        obs-dtext          ;  "[", "]", or "\"
    970 
    971    The domain portion identifies the point to which the mail is
    972    delivered.  In the dot-atom form, this is interpreted as an Internet
    973    domain name (either a host name or a mail exchanger name) as
    974    described in [RFC1034], [RFC1035], and [RFC1123].  In the domain-
    975    literal form, the domain is interpreted as the literal Internet
    976    address of the particular host.  In both cases, how addressing is
    977    used and how messages are transported to a particular host is covered
    978    in separate documents, such as [RFC5321].  These mechanisms are
    979    outside of the scope of this document.
    980 
    981    The local-part portion is a domain-dependent string.  In addresses,
    982    it is simply interpreted on the particular host as a name of a
    983    particular mailbox.
    984 
    985 3.5.  Overall Message Syntax
    986 
    987    A message consists of header fields, optionally followed by a message
    988    body.  Lines in a message MUST be a maximum of 998 characters
    989    excluding the CRLF, but it is RECOMMENDED that lines be limited to 78
    990    characters excluding the CRLF.  (See section 2.1.1 for explanation.)
    991    In a message body, though all of the characters listed in the text
    992    rule MAY be used, the use of US-ASCII control characters (values 1
    993    through 8, 11, 12, and 14 through 31) is discouraged since their
    994    interpretation by receivers for display is not guaranteed.
    995 
    996    message         =   (fields / obs-fields)
    997                        [CRLF body]
    998 
    999    body            =   (*(*998text CRLF) *998text) / obs-body
   1000 
   1001    text            =   %d1-9 /            ; Characters excluding CR
   1002                        %d11 /             ;  and LF
   1003                        %d12 /
   1004                        %d14-127
   1005 
   1006 
   1007 
   1008 
   1009 
   1010 Resnick                     Standards Track                    [Page 18]
   1011 
   1012 RFC 5322                Internet Message Format             October 2008
   1013 
   1014 
   1015    The header fields carry most of the semantic information and are
   1016    defined in section 3.6.  The body is simply a series of lines of text
   1017    that are uninterpreted for the purposes of this specification.
   1018 
   1019 3.6.  Field Definitions
   1020 
   1021    The header fields of a message are defined here.  All header fields
   1022    have the same general syntactic structure: a field name, followed by
   1023    a colon, followed by the field body.  The specific syntax for each
   1024    header field is defined in the subsequent sections.
   1025 
   1026       Note: In the ABNF syntax for each field in subsequent sections,
   1027       each field name is followed by the required colon.  However, for
   1028       brevity, sometimes the colon is not referred to in the textual
   1029       description of the syntax.  It is, nonetheless, required.
   1030 
   1031    It is important to note that the header fields are not guaranteed to
   1032    be in a particular order.  They may appear in any order, and they
   1033    have been known to be reordered occasionally when transported over
   1034    the Internet.  However, for the purposes of this specification,
   1035    header fields SHOULD NOT be reordered when a message is transported
   1036    or transformed.  More importantly, the trace header fields and resent
   1037    header fields MUST NOT be reordered, and SHOULD be kept in blocks
   1038    prepended to the message.  See sections 3.6.6 and 3.6.7 for more
   1039    information.
   1040 
   1041    The only required header fields are the origination date field and
   1042    the originator address field(s).  All other header fields are
   1043    syntactically optional.  More information is contained in the table
   1044    following this definition.
   1045 
   1046 
   1047 
   1048 
   1049 
   1050 
   1051 
   1052 
   1053 
   1054 
   1055 
   1056 
   1057 
   1058 
   1059 
   1060 
   1061 
   1062 
   1063 
   1064 
   1065 
   1066 Resnick                     Standards Track                    [Page 19]
   1067 
   1068 RFC 5322                Internet Message Format             October 2008
   1069 
   1070 
   1071    fields          =   *(trace
   1072                          *optional-field /
   1073                          *(resent-date /
   1074                           resent-from /
   1075                           resent-sender /
   1076                           resent-to /
   1077                           resent-cc /
   1078                           resent-bcc /
   1079                           resent-msg-id))
   1080                        *(orig-date /
   1081                        from /
   1082                        sender /
   1083                        reply-to /
   1084                        to /
   1085                        cc /
   1086                        bcc /
   1087                        message-id /
   1088                        in-reply-to /
   1089                        references /
   1090                        subject /
   1091                        comments /
   1092                        keywords /
   1093                        optional-field)
   1094 
   1095    The following table indicates limits on the number of times each
   1096    field may occur in the header section of a message as well as any
   1097    special limitations on the use of those fields.  An asterisk ("*")
   1098    next to a value in the minimum or maximum column indicates that a
   1099    special restriction appears in the Notes column.
   1100 
   1101 
   1102 
   1103 
   1104 
   1105 
   1106 
   1107 
   1108 
   1109 
   1110 
   1111 
   1112 
   1113 
   1114 
   1115 
   1116 
   1117 
   1118 
   1119 
   1120 
   1121 
   1122 Resnick                     Standards Track                    [Page 20]
   1123 
   1124 RFC 5322                Internet Message Format             October 2008
   1125 
   1126 
   1127    +----------------+--------+------------+----------------------------+
   1128    | Field          | Min    | Max number | Notes                      |
   1129    |                | number |            |                            |
   1130    +----------------+--------+------------+----------------------------+
   1131    | trace          | 0      | unlimited  | Block prepended - see      |
   1132    |                |        |            | 3.6.7                      |
   1133    | resent-date    | 0*     | unlimited* | One per block, required if |
   1134    |                |        |            | other resent fields are    |
   1135    |                |        |            | present - see 3.6.6        |
   1136    | resent-from    | 0      | unlimited* | One per block - see 3.6.6  |
   1137    | resent-sender  | 0*     | unlimited* | One per block, MUST occur  |
   1138    |                |        |            | with multi-address         |
   1139    |                |        |            | resent-from - see 3.6.6    |
   1140    | resent-to      | 0      | unlimited* | One per block - see 3.6.6  |
   1141    | resent-cc      | 0      | unlimited* | One per block - see 3.6.6  |
   1142    | resent-bcc     | 0      | unlimited* | One per block - see 3.6.6  |
   1143    | resent-msg-id  | 0      | unlimited* | One per block - see 3.6.6  |
   1144    | orig-date      | 1      | 1          |                            |
   1145    | from           | 1      | 1          | See sender and 3.6.2       |
   1146    | sender         | 0*     | 1          | MUST occur with            |
   1147    |                |        |            | multi-address from - see   |
   1148    |                |        |            | 3.6.2                      |
   1149    | reply-to       | 0      | 1          |                            |
   1150    | to             | 0      | 1          |                            |
   1151    | cc             | 0      | 1          |                            |
   1152    | bcc            | 0      | 1          |                            |
   1153    | message-id     | 0*     | 1          | SHOULD be present - see    |
   1154    |                |        |            | 3.6.4                      |
   1155    | in-reply-to    | 0*     | 1          | SHOULD occur in some       |
   1156    |                |        |            | replies - see 3.6.4        |
   1157    | references     | 0*     | 1          | SHOULD occur in some       |
   1158    |                |        |            | replies - see 3.6.4        |
   1159    | subject        | 0      | 1          |                            |
   1160    | comments       | 0      | unlimited  |                            |
   1161    | keywords       | 0      | unlimited  |                            |
   1162    | optional-field | 0      | unlimited  |                            |
   1163    +----------------+--------+------------+----------------------------+
   1164 
   1165    The exact interpretation of each field is described in subsequent
   1166    sections.
   1167 
   1168 
   1169 
   1170 
   1171 
   1172 
   1173 
   1174 
   1175 
   1176 
   1177 
   1178 Resnick                     Standards Track                    [Page 21]
   1179 
   1180 RFC 5322                Internet Message Format             October 2008
   1181 
   1182 
   1183 3.6.1.  The Origination Date Field
   1184 
   1185    The origination date field consists of the field name "Date" followed
   1186    by a date-time specification.
   1187 
   1188    orig-date       =   "Date:" date-time CRLF
   1189 
   1190    The origination date specifies the date and time at which the creator
   1191    of the message indicated that the message was complete and ready to
   1192    enter the mail delivery system.  For instance, this might be the time
   1193    that a user pushes the "send" or "submit" button in an application
   1194    program.  In any case, it is specifically not intended to convey the
   1195    time that the message is actually transported, but rather the time at
   1196    which the human or other creator of the message has put the message
   1197    into its final form, ready for transport.  (For example, a portable
   1198    computer user who is not connected to a network might queue a message
   1199    for delivery.  The origination date is intended to contain the date
   1200    and time that the user queued the message, not the time when the user
   1201    connected to the network to send the message.)
   1202 
   1203 3.6.2.  Originator Fields
   1204 
   1205    The originator fields of a message consist of the from field, the
   1206    sender field (when applicable), and optionally the reply-to field.
   1207    The from field consists of the field name "From" and a comma-
   1208    separated list of one or more mailbox specifications.  If the from
   1209    field contains more than one mailbox specification in the mailbox-
   1210    list, then the sender field, containing the field name "Sender" and a
   1211    single mailbox specification, MUST appear in the message.  In either
   1212    case, an optional reply-to field MAY also be included, which contains
   1213    the field name "Reply-To" and a comma-separated list of one or more
   1214    addresses.
   1215 
   1216    from            =   "From:" mailbox-list CRLF
   1217 
   1218    sender          =   "Sender:" mailbox CRLF
   1219 
   1220    reply-to        =   "Reply-To:" address-list CRLF
   1221 
   1222    The originator fields indicate the mailbox(es) of the source of the
   1223    message.  The "From:" field specifies the author(s) of the message,
   1224    that is, the mailbox(es) of the person(s) or system(s) responsible
   1225    for the writing of the message.  The "Sender:" field specifies the
   1226    mailbox of the agent responsible for the actual transmission of the
   1227    message.  For example, if a secretary were to send a message for
   1228    another person, the mailbox of the secretary would appear in the
   1229    "Sender:" field and the mailbox of the actual author would appear in
   1230    the "From:" field.  If the originator of the message can be indicated
   1231 
   1232 
   1233 
   1234 Resnick                     Standards Track                    [Page 22]
   1235 
   1236 RFC 5322                Internet Message Format             October 2008
   1237 
   1238 
   1239    by a single mailbox and the author and transmitter are identical, the
   1240    "Sender:" field SHOULD NOT be used.  Otherwise, both fields SHOULD
   1241    appear.
   1242 
   1243       Note: The transmitter information is always present.  The absence
   1244       of the "Sender:" field is sometimes mistakenly taken to mean that
   1245       the agent responsible for transmission of the message has not been
   1246       specified.  This absence merely means that the transmitter is
   1247       identical to the author and is therefore not redundantly placed
   1248       into the "Sender:" field.
   1249 
   1250    The originator fields also provide the information required when
   1251    replying to a message.  When the "Reply-To:" field is present, it
   1252    indicates the address(es) to which the author of the message suggests
   1253    that replies be sent.  In the absence of the "Reply-To:" field,
   1254    replies SHOULD by default be sent to the mailbox(es) specified in the
   1255    "From:" field unless otherwise specified by the person composing the
   1256    reply.
   1257 
   1258    In all cases, the "From:" field SHOULD NOT contain any mailbox that
   1259    does not belong to the author(s) of the message.  See also section
   1260    3.6.3 for more information on forming the destination addresses for a
   1261    reply.
   1262 
   1263 3.6.3.  Destination Address Fields
   1264 
   1265    The destination fields of a message consist of three possible fields,
   1266    each of the same form: the field name, which is either "To", "Cc", or
   1267    "Bcc", followed by a comma-separated list of one or more addresses
   1268    (either mailbox or group syntax).
   1269 
   1270    to              =   "To:" address-list CRLF
   1271 
   1272    cc              =   "Cc:" address-list CRLF
   1273 
   1274    bcc             =   "Bcc:" [address-list / CFWS] CRLF
   1275 
   1276    The destination fields specify the recipients of the message.  Each
   1277    destination field may have one or more addresses, and the addresses
   1278    indicate the intended recipients of the message.  The only difference
   1279    between the three fields is how each is used.
   1280 
   1281    The "To:" field contains the address(es) of the primary recipient(s)
   1282    of the message.
   1283 
   1284 
   1285 
   1286 
   1287 
   1288 
   1289 
   1290 Resnick                     Standards Track                    [Page 23]
   1291 
   1292 RFC 5322                Internet Message Format             October 2008
   1293 
   1294 
   1295    The "Cc:" field (where the "Cc" means "Carbon Copy" in the sense of
   1296    making a copy on a typewriter using carbon paper) contains the
   1297    addresses of others who are to receive the message, though the
   1298    content of the message may not be directed at them.
   1299 
   1300    The "Bcc:" field (where the "Bcc" means "Blind Carbon Copy") contains
   1301    addresses of recipients of the message whose addresses are not to be
   1302    revealed to other recipients of the message.  There are three ways in
   1303    which the "Bcc:" field is used.  In the first case, when a message
   1304    containing a "Bcc:" field is prepared to be sent, the "Bcc:" line is
   1305    removed even though all of the recipients (including those specified
   1306    in the "Bcc:" field) are sent a copy of the message.  In the second
   1307    case, recipients specified in the "To:" and "Cc:" lines each are sent
   1308    a copy of the message with the "Bcc:" line removed as above, but the
   1309    recipients on the "Bcc:" line get a separate copy of the message
   1310    containing a "Bcc:" line.  (When there are multiple recipient
   1311    addresses in the "Bcc:" field, some implementations actually send a
   1312    separate copy of the message to each recipient with a "Bcc:"
   1313    containing only the address of that particular recipient.)  Finally,
   1314    since a "Bcc:" field may contain no addresses, a "Bcc:" field can be
   1315    sent without any addresses indicating to the recipients that blind
   1316    copies were sent to someone.  Which method to use with "Bcc:" fields
   1317    is implementation dependent, but refer to the "Security
   1318    Considerations" section of this document for a discussion of each.
   1319 
   1320    When a message is a reply to another message, the mailboxes of the
   1321    authors of the original message (the mailboxes in the "From:" field)
   1322    or mailboxes specified in the "Reply-To:" field (if it exists) MAY
   1323    appear in the "To:" field of the reply since these would normally be
   1324    the primary recipients of the reply.  If a reply is sent to a message
   1325    that has destination fields, it is often desirable to send a copy of
   1326    the reply to all of the recipients of the message, in addition to the
   1327    author.  When such a reply is formed, addresses in the "To:" and
   1328    "Cc:" fields of the original message MAY appear in the "Cc:" field of
   1329    the reply, since these are normally secondary recipients of the
   1330    reply.  If a "Bcc:" field is present in the original message,
   1331    addresses in that field MAY appear in the "Bcc:" field of the reply,
   1332    but they SHOULD NOT appear in the "To:" or "Cc:" fields.
   1333 
   1334       Note: Some mail applications have automatic reply commands that
   1335       include the destination addresses of the original message in the
   1336       destination addresses of the reply.  How those reply commands
   1337       behave is implementation dependent and is beyond the scope of this
   1338       document.  In particular, whether or not to include the original
   1339       destination addresses when the original message had a "Reply-To:"
   1340       field is not addressed here.
   1341 
   1342 
   1343 
   1344 
   1345 
   1346 Resnick                     Standards Track                    [Page 24]
   1347 
   1348 RFC 5322                Internet Message Format             October 2008
   1349 
   1350 
   1351 3.6.4.  Identification Fields
   1352 
   1353    Though listed as optional in the table in section 3.6, every message
   1354    SHOULD have a "Message-ID:" field.  Furthermore, reply messages
   1355    SHOULD have "In-Reply-To:" and "References:" fields as appropriate
   1356    and as described below.
   1357 
   1358    The "Message-ID:" field contains a single unique message identifier.
   1359    The "References:" and "In-Reply-To:" fields each contain one or more
   1360    unique message identifiers, optionally separated by CFWS.
   1361 
   1362    The message identifier (msg-id) syntax is a limited version of the
   1363    addr-spec construct enclosed in the angle bracket characters, "<" and
   1364    ">".  Unlike addr-spec, this syntax only permits the dot-atom-text
   1365    form on the left-hand side of the "@" and does not have internal CFWS
   1366    anywhere in the message identifier.
   1367 
   1368       Note: As with addr-spec, a liberal syntax is given for the right-
   1369       hand side of the "@" in a msg-id.  However, later in this section,
   1370       the use of a domain for the right-hand side of the "@" is
   1371       RECOMMENDED.  Again, the syntax of domain constructs is specified
   1372       by and used in other protocols (e.g., [RFC1034], [RFC1035],
   1373       [RFC1123], [RFC5321]).  It is therefore incumbent upon
   1374       implementations to conform to the syntax of addresses for the
   1375       context in which they are used.
   1376 
   1377    message-id      =   "Message-ID:" msg-id CRLF
   1378 
   1379    in-reply-to     =   "In-Reply-To:" 1*msg-id CRLF
   1380 
   1381    references      =   "References:" 1*msg-id CRLF
   1382 
   1383    msg-id          =   [CFWS] "<" id-left "@" id-right ">" [CFWS]
   1384 
   1385    id-left         =   dot-atom-text / obs-id-left
   1386 
   1387    id-right        =   dot-atom-text / no-fold-literal / obs-id-right
   1388 
   1389    no-fold-literal =   "[" *dtext "]"
   1390 
   1391    The "Message-ID:" field provides a unique message identifier that
   1392    refers to a particular version of a particular message.  The
   1393    uniqueness of the message identifier is guaranteed by the host that
   1394    generates it (see below).  This message identifier is intended to be
   1395    machine readable and not necessarily meaningful to humans.  A message
   1396    identifier pertains to exactly one version of a particular message;
   1397    subsequent revisions to the message each receive new message
   1398    identifiers.
   1399 
   1400 
   1401 
   1402 Resnick                     Standards Track                    [Page 25]
   1403 
   1404 RFC 5322                Internet Message Format             October 2008
   1405 
   1406 
   1407       Note: There are many instances when messages are "changed", but
   1408       those changes do not constitute a new instantiation of that
   1409       message, and therefore the message would not get a new message
   1410       identifier.  For example, when messages are introduced into the
   1411       transport system, they are often prepended with additional header
   1412       fields such as trace fields (described in section 3.6.7) and
   1413       resent fields (described in section 3.6.6).  The addition of such
   1414       header fields does not change the identity of the message and
   1415       therefore the original "Message-ID:" field is retained.  In all
   1416       cases, it is the meaning that the sender of the message wishes to
   1417       convey (i.e., whether this is the same message or a different
   1418       message) that determines whether or not the "Message-ID:" field
   1419       changes, not any particular syntactic difference that appears (or
   1420       does not appear) in the message.
   1421 
   1422    The "In-Reply-To:" and "References:" fields are used when creating a
   1423    reply to a message.  They hold the message identifier of the original
   1424    message and the message identifiers of other messages (for example,
   1425    in the case of a reply to a message that was itself a reply).  The
   1426    "In-Reply-To:" field may be used to identify the message (or
   1427    messages) to which the new message is a reply, while the
   1428    "References:" field may be used to identify a "thread" of
   1429    conversation.
   1430 
   1431    When creating a reply to a message, the "In-Reply-To:" and
   1432    "References:" fields of the resultant message are constructed as
   1433    follows:
   1434 
   1435    The "In-Reply-To:" field will contain the contents of the
   1436    "Message-ID:" field of the message to which this one is a reply (the
   1437    "parent message").  If there is more than one parent message, then
   1438    the "In-Reply-To:" field will contain the contents of all of the
   1439    parents' "Message-ID:" fields.  If there is no "Message-ID:" field in
   1440    any of the parent messages, then the new message will have no "In-
   1441    Reply-To:" field.
   1442 
   1443    The "References:" field will contain the contents of the parent's
   1444    "References:" field (if any) followed by the contents of the parent's
   1445    "Message-ID:" field (if any).  If the parent message does not contain
   1446    a "References:" field but does have an "In-Reply-To:" field
   1447    containing a single message identifier, then the "References:" field
   1448    will contain the contents of the parent's "In-Reply-To:" field
   1449    followed by the contents of the parent's "Message-ID:" field (if
   1450    any).  If the parent has none of the "References:", "In-Reply-To:",
   1451    or "Message-ID:" fields, then the new message will have no
   1452    "References:" field.
   1453 
   1454 
   1455 
   1456 
   1457 
   1458 Resnick                     Standards Track                    [Page 26]
   1459 
   1460 RFC 5322                Internet Message Format             October 2008
   1461 
   1462 
   1463       Note: Some implementations parse the "References:" field to
   1464       display the "thread of the discussion".  These implementations
   1465       assume that each new message is a reply to a single parent and
   1466       hence that they can walk backwards through the "References:" field
   1467       to find the parent of each message listed there.  Therefore,
   1468       trying to form a "References:" field for a reply that has multiple
   1469       parents is discouraged; how to do so is not defined in this
   1470       document.
   1471 
   1472    The message identifier (msg-id) itself MUST be a globally unique
   1473    identifier for a message.  The generator of the message identifier
   1474    MUST guarantee that the msg-id is unique.  There are several
   1475    algorithms that can be used to accomplish this.  Since the msg-id has
   1476    a similar syntax to addr-spec (identical except that quoted strings,
   1477    comments, and folding white space are not allowed), a good method is
   1478    to put the domain name (or a domain literal IP address) of the host
   1479    on which the message identifier was created on the right-hand side of
   1480    the "@" (since domain names and IP addresses are normally unique),
   1481    and put a combination of the current absolute date and time along
   1482    with some other currently unique (perhaps sequential) identifier
   1483    available on the system (for example, a process id number) on the
   1484    left-hand side.  Though other algorithms will work, it is RECOMMENDED
   1485    that the right-hand side contain some domain identifier (either of
   1486    the host itself or otherwise) such that the generator of the message
   1487    identifier can guarantee the uniqueness of the left-hand side within
   1488    the scope of that domain.
   1489 
   1490    Semantically, the angle bracket characters are not part of the
   1491    msg-id; the msg-id is what is contained between the two angle bracket
   1492    characters.
   1493 
   1494 3.6.5.  Informational Fields
   1495 
   1496    The informational fields are all optional.  The "Subject:" and
   1497    "Comments:" fields are unstructured fields as defined in section
   1498    2.2.1, and therefore may contain text or folding white space.  The
   1499    "Keywords:" field contains a comma-separated list of one or more
   1500    words or quoted-strings.
   1501 
   1502    subject         =   "Subject:" unstructured CRLF
   1503 
   1504    comments        =   "Comments:" unstructured CRLF
   1505 
   1506    keywords        =   "Keywords:" phrase *("," phrase) CRLF
   1507 
   1508    These three fields are intended to have only human-readable content
   1509    with information about the message.  The "Subject:" field is the most
   1510    common and contains a short string identifying the topic of the
   1511 
   1512 
   1513 
   1514 Resnick                     Standards Track                    [Page 27]
   1515 
   1516 RFC 5322                Internet Message Format             October 2008
   1517 
   1518 
   1519    message.  When used in a reply, the field body MAY start with the
   1520    string "Re: " (an abbreviation of the Latin "in re", meaning "in the
   1521    matter of") followed by the contents of the "Subject:" field body of
   1522    the original message.  If this is done, only one instance of the
   1523    literal string "Re: " ought to be used since use of other strings or
   1524    more than one instance can lead to undesirable consequences.  The
   1525    "Comments:" field contains any additional comments on the text of the
   1526    body of the message.  The "Keywords:" field contains a comma-
   1527    separated list of important words and phrases that might be useful
   1528    for the recipient.
   1529 
   1530 3.6.6.  Resent Fields
   1531 
   1532    Resent fields SHOULD be added to any message that is reintroduced by
   1533    a user into the transport system.  A separate set of resent fields
   1534    SHOULD be added each time this is done.  All of the resent fields
   1535    corresponding to a particular resending of the message SHOULD be
   1536    grouped together.  Each new set of resent fields is prepended to the
   1537    message; that is, the most recent set of resent fields appears
   1538    earlier in the message.  No other fields in the message are changed
   1539    when resent fields are added.
   1540 
   1541    Each of the resent fields corresponds to a particular field elsewhere
   1542    in the syntax.  For instance, the "Resent-Date:" field corresponds to
   1543    the "Date:" field and the "Resent-To:" field corresponds to the "To:"
   1544    field.  In each case, the syntax for the field body is identical to
   1545    the syntax given previously for the corresponding field.
   1546 
   1547    When resent fields are used, the "Resent-From:" and "Resent-Date:"
   1548    fields MUST be sent.  The "Resent-Message-ID:" field SHOULD be sent.
   1549    "Resent-Sender:" SHOULD NOT be used if "Resent-Sender:" would be
   1550    identical to "Resent-From:".
   1551 
   1552    resent-date     =   "Resent-Date:" date-time CRLF
   1553 
   1554    resent-from     =   "Resent-From:" mailbox-list CRLF
   1555 
   1556    resent-sender   =   "Resent-Sender:" mailbox CRLF
   1557 
   1558    resent-to       =   "Resent-To:" address-list CRLF
   1559 
   1560    resent-cc       =   "Resent-Cc:" address-list CRLF
   1561 
   1562    resent-bcc      =   "Resent-Bcc:" [address-list / CFWS] CRLF
   1563 
   1564    resent-msg-id   =   "Resent-Message-ID:" msg-id CRLF
   1565 
   1566 
   1567 
   1568 
   1569 
   1570 Resnick                     Standards Track                    [Page 28]
   1571 
   1572 RFC 5322                Internet Message Format             October 2008
   1573 
   1574 
   1575    Resent fields are used to identify a message as having been
   1576    reintroduced into the transport system by a user.  The purpose of
   1577    using resent fields is to have the message appear to the final
   1578    recipient as if it were sent directly by the original sender, with
   1579    all of the original fields remaining the same.  Each set of resent
   1580    fields correspond to a particular resending event.  That is, if a
   1581    message is resent multiple times, each set of resent fields gives
   1582    identifying information for each individual time.  Resent fields are
   1583    strictly informational.  They MUST NOT be used in the normal
   1584    processing of replies or other such automatic actions on messages.
   1585 
   1586       Note: Reintroducing a message into the transport system and using
   1587       resent fields is a different operation from "forwarding".
   1588       "Forwarding" has two meanings: One sense of forwarding is that a
   1589       mail reading program can be told by a user to forward a copy of a
   1590       message to another person, making the forwarded message the body
   1591       of the new message.  A forwarded message in this sense does not
   1592       appear to have come from the original sender, but is an entirely
   1593       new message from the forwarder of the message.  Forwarding may
   1594       also mean that a mail transport program gets a message and
   1595       forwards it on to a different destination for final delivery.
   1596       Resent header fields are not intended for use with either type of
   1597       forwarding.
   1598 
   1599    The resent originator fields indicate the mailbox of the person(s) or
   1600    system(s) that resent the message.  As with the regular originator
   1601    fields, there are two forms: a simple "Resent-From:" form, which
   1602    contains the mailbox of the individual doing the resending, and the
   1603    more complex form, when one individual (identified in the "Resent-
   1604    Sender:" field) resends a message on behalf of one or more others
   1605    (identified in the "Resent-From:" field).
   1606 
   1607       Note: When replying to a resent message, replies behave just as
   1608       they would with any other message, using the original "From:",
   1609       "Reply-To:", "Message-ID:", and other fields.  The resent fields
   1610       are only informational and MUST NOT be used in the normal
   1611       processing of replies.
   1612 
   1613    The "Resent-Date:" indicates the date and time at which the resent
   1614    message is dispatched by the resender of the message.  Like the
   1615    "Date:" field, it is not the date and time that the message was
   1616    actually transported.
   1617 
   1618    The "Resent-To:", "Resent-Cc:", and "Resent-Bcc:" fields function
   1619    identically to the "To:", "Cc:", and "Bcc:" fields, respectively,
   1620    except that they indicate the recipients of the resent message, not
   1621    the recipients of the original message.
   1622 
   1623 
   1624 
   1625 
   1626 Resnick                     Standards Track                    [Page 29]
   1627 
   1628 RFC 5322                Internet Message Format             October 2008
   1629 
   1630 
   1631    The "Resent-Message-ID:" field provides a unique identifier for the
   1632    resent message.
   1633 
   1634 3.6.7.  Trace Fields
   1635 
   1636    The trace fields are a group of header fields consisting of an
   1637    optional "Return-Path:" field, and one or more "Received:" fields.
   1638    The "Return-Path:" header field contains a pair of angle brackets
   1639    that enclose an optional addr-spec.  The "Received:" field contains a
   1640    (possibly empty) list of tokens followed by a semicolon and a date-
   1641    time specification.  Each token must be a word, angle-addr, addr-
   1642    spec, or a domain.  Further restrictions are applied to the syntax of
   1643    the trace fields by specifications that provide for their use, such
   1644    as [RFC5321].
   1645 
   1646    trace           =   [return]
   1647                        1*received
   1648 
   1649    return          =   "Return-Path:" path CRLF
   1650 
   1651    path            =   angle-addr / ([CFWS] "<" [CFWS] ">" [CFWS])
   1652 
   1653    received        =   "Received:" *received-token ";" date-time CRLF
   1654 
   1655    received-token  =   word / angle-addr / addr-spec / domain
   1656 
   1657    A full discussion of the Internet mail use of trace fields is
   1658    contained in [RFC5321].  For the purposes of this specification, the
   1659    trace fields are strictly informational, and any formal
   1660    interpretation of them is outside of the scope of this document.
   1661 
   1662 3.6.8.  Optional Fields
   1663 
   1664    Fields may appear in messages that are otherwise unspecified in this
   1665    document.  They MUST conform to the syntax of an optional-field.
   1666    This is a field name, made up of the printable US-ASCII characters
   1667    except SP and colon, followed by a colon, followed by any text that
   1668    conforms to the unstructured syntax.
   1669 
   1670    The field names of any optional field MUST NOT be identical to any
   1671    field name specified elsewhere in this document.
   1672 
   1673 
   1674 
   1675 
   1676 
   1677 
   1678 
   1679 
   1680 
   1681 
   1682 Resnick                     Standards Track                    [Page 30]
   1683 
   1684 RFC 5322                Internet Message Format             October 2008
   1685 
   1686 
   1687    optional-field  =   field-name ":" unstructured CRLF
   1688 
   1689    field-name      =   1*ftext
   1690 
   1691    ftext           =   %d33-57 /          ; Printable US-ASCII
   1692                        %d59-126           ;  characters not including
   1693                                           ;  ":".
   1694 
   1695    For the purposes of this specification, any optional field is
   1696    uninterpreted.
   1697 
   1698 4.  Obsolete Syntax
   1699 
   1700    Earlier versions of this specification allowed for different (usually
   1701    more liberal) syntax than is allowed in this version.  Also, there
   1702    have been syntactic elements used in messages on the Internet whose
   1703    interpretations have never been documented.  Though these syntactic
   1704    forms MUST NOT be generated according to the grammar in section 3,
   1705    they MUST be accepted and parsed by a conformant receiver.  This
   1706    section documents many of these syntactic elements.  Taking the
   1707    grammar in section 3 and adding the definitions presented in this
   1708    section will result in the grammar to use for the interpretation of
   1709    messages.
   1710 
   1711       Note: This section identifies syntactic forms that any
   1712       implementation MUST reasonably interpret.  However, there are
   1713       certainly Internet messages that do not conform to even the
   1714       additional syntax given in this section.  The fact that a
   1715       particular form does not appear in any section of this document is
   1716       not justification for computer programs to crash or for malformed
   1717       data to be irretrievably lost by any implementation.  It is up to
   1718       the implementation to deal with messages robustly.
   1719 
   1720    One important difference between the obsolete (interpreting) and the
   1721    current (generating) syntax is that in structured header field bodies
   1722    (i.e., between the colon and the CRLF of any structured header
   1723    field), white space characters, including folding white space, and
   1724    comments could be freely inserted between any syntactic tokens.  This
   1725    allowed many complex forms that have proven difficult for some
   1726    implementations to parse.
   1727 
   1728    Another key difference between the obsolete and the current syntax is
   1729    that the rule in section 3.2.2 regarding lines composed entirely of
   1730    white space in comments and folding white space does not apply.  See
   1731    the discussion of folding white space in section 4.2 below.
   1732 
   1733    Finally, certain characters that were formerly allowed in messages
   1734    appear in this section.  The NUL character (ASCII value 0) was once
   1735 
   1736 
   1737 
   1738 Resnick                     Standards Track                    [Page 31]
   1739 
   1740 RFC 5322                Internet Message Format             October 2008
   1741 
   1742 
   1743    allowed, but is no longer for compatibility reasons.  Similarly, US-
   1744    ASCII control characters other than CR, LF, SP, and HTAB (ASCII
   1745    values 1 through 8, 11, 12, 14 through 31, and 127) were allowed to
   1746    appear in header field bodies.  CR and LF were allowed to appear in
   1747    messages other than as CRLF; this use is also shown here.
   1748 
   1749    Other differences in syntax and semantics are noted in the following
   1750    sections.
   1751 
   1752 4.1.  Miscellaneous Obsolete Tokens
   1753 
   1754    These syntactic elements are used elsewhere in the obsolete syntax or
   1755    in the main syntax.  Bare CR, bare LF, and NUL are added to obs-qp,
   1756    obs-body, and obs-unstruct.  US-ASCII control characters are added to
   1757    obs-qp, obs-unstruct, obs-ctext, and obs-qtext.  The period character
   1758    is added to obs-phrase.  The obs-phrase-list provides for a
   1759    (potentially empty) comma-separated list of phrases that may include
   1760    "null" elements.  That is, there could be two or more commas in such
   1761    a list with nothing in between them, or commas at the beginning or
   1762    end of the list.
   1763 
   1764       Note: The "period" (or "full stop") character (".") in obs-phrase
   1765       is not a form that was allowed in earlier versions of this or any
   1766       other specification.  Period (nor any other character from
   1767       specials) was not allowed in phrase because it introduced a
   1768       parsing difficulty distinguishing between phrases and portions of
   1769       an addr-spec (see section 4.4).  It appears here because the
   1770       period character is currently used in many messages in the
   1771       display-name portion of addresses, especially for initials in
   1772       names, and therefore must be interpreted properly.
   1773 
   1774    obs-NO-WS-CTL   =   %d1-8 /            ; US-ASCII control
   1775                        %d11 /             ;  characters that do not
   1776                        %d12 /             ;  include the carriage
   1777                        %d14-31 /          ;  return, line feed, and
   1778                        %d127              ;  white space characters
   1779 
   1780    obs-ctext       =   obs-NO-WS-CTL
   1781 
   1782    obs-qtext       =   obs-NO-WS-CTL
   1783 
   1784    obs-utext       =   %d0 / obs-NO-WS-CTL / VCHAR
   1785 
   1786    obs-qp          =   "\" (%d0 / obs-NO-WS-CTL / LF / CR)
   1787 
   1788    obs-body        =   *((*LF *CR *((%d0 / text) *LF *CR)) / CRLF)
   1789 
   1790    obs-unstruct    =   *((*LF *CR *(obs-utext *LF *CR)) / FWS)
   1791 
   1792 
   1793 
   1794 Resnick                     Standards Track                    [Page 32]
   1795 
   1796 RFC 5322                Internet Message Format             October 2008
   1797 
   1798 
   1799    obs-phrase      =   word *(word / "." / CFWS)
   1800 
   1801    obs-phrase-list =   [phrase / CFWS] *("," [phrase / CFWS])
   1802 
   1803    Bare CR and bare LF appear in messages with two different meanings.
   1804    In many cases, bare CR or bare LF are used improperly instead of CRLF
   1805    to indicate line separators.  In other cases, bare CR and bare LF are
   1806    used simply as US-ASCII control characters with their traditional
   1807    ASCII meanings.
   1808 
   1809 4.2.  Obsolete Folding White Space
   1810 
   1811    In the obsolete syntax, any amount of folding white space MAY be
   1812    inserted where the obs-FWS rule is allowed.  This creates the
   1813    possibility of having two consecutive "folds" in a line, and
   1814    therefore the possibility that a line which makes up a folded header
   1815    field could be composed entirely of white space.
   1816 
   1817    obs-FWS         =   1*WSP *(CRLF 1*WSP)
   1818 
   1819 4.3.  Obsolete Date and Time
   1820 
   1821    The syntax for the obsolete date format allows a 2 digit year in the
   1822    date field and allows for a list of alphabetic time zone specifiers
   1823    that were used in earlier versions of this specification.  It also
   1824    permits comments and folding white space between many of the tokens.
   1825 
   1826    obs-day-of-week =   [CFWS] day-name [CFWS]
   1827 
   1828    obs-day         =   [CFWS] 1*2DIGIT [CFWS]
   1829 
   1830    obs-year        =   [CFWS] 2*DIGIT [CFWS]
   1831 
   1832    obs-hour        =   [CFWS] 2DIGIT [CFWS]
   1833 
   1834    obs-minute      =   [CFWS] 2DIGIT [CFWS]
   1835 
   1836    obs-second      =   [CFWS] 2DIGIT [CFWS]
   1837 
   1838    obs-zone        =   "UT" / "GMT" /     ; Universal Time
   1839                                           ; North American UT
   1840                                           ; offsets
   1841                        "EST" / "EDT" /    ; Eastern:  - 5/ - 4
   1842                        "CST" / "CDT" /    ; Central:  - 6/ - 5
   1843                        "MST" / "MDT" /    ; Mountain: - 7/ - 6
   1844                        "PST" / "PDT" /    ; Pacific:  - 8/ - 7
   1845                                           ;
   1846 
   1847 
   1848 
   1849 
   1850 Resnick                     Standards Track                    [Page 33]
   1851 
   1852 RFC 5322                Internet Message Format             October 2008
   1853 
   1854 
   1855                        %d65-73 /          ; Military zones - "A"
   1856                        %d75-90 /          ; through "I" and "K"
   1857                        %d97-105 /         ; through "Z", both
   1858                        %d107-122          ; upper and lower case
   1859 
   1860    Where a two or three digit year occurs in a date, the year is to be
   1861    interpreted as follows: If a two digit year is encountered whose
   1862    value is between 00 and 49, the year is interpreted by adding 2000,
   1863    ending up with a value between 2000 and 2049.  If a two digit year is
   1864    encountered with a value between 50 and 99, or any three digit year
   1865    is encountered, the year is interpreted by adding 1900.
   1866 
   1867    In the obsolete time zone, "UT" and "GMT" are indications of
   1868    "Universal Time" and "Greenwich Mean Time", respectively, and are
   1869    both semantically identical to "+0000".
   1870 
   1871    The remaining three character zones are the US time zones.  The first
   1872    letter, "E", "C", "M", or "P" stands for "Eastern", "Central",
   1873    "Mountain", and "Pacific".  The second letter is either "S" for
   1874    "Standard" time, or "D" for "Daylight Savings" (or summer) time.
   1875    Their interpretations are as follows:
   1876 
   1877       EDT is semantically equivalent to -0400
   1878       EST is semantically equivalent to -0500
   1879       CDT is semantically equivalent to -0500
   1880       CST is semantically equivalent to -0600
   1881       MDT is semantically equivalent to -0600
   1882       MST is semantically equivalent to -0700
   1883       PDT is semantically equivalent to -0700
   1884       PST is semantically equivalent to -0800
   1885 
   1886    The 1 character military time zones were defined in a non-standard
   1887    way in [RFC0822] and are therefore unpredictable in their meaning.
   1888    The original definitions of the military zones "A" through "I" are
   1889    equivalent to "+0100" through "+0900", respectively; "K", "L", and
   1890    "M" are equivalent to "+1000", "+1100", and "+1200", respectively;
   1891    "N" through "Y" are equivalent to "-0100" through "-1200".
   1892    respectively; and "Z" is equivalent to "+0000".  However, because of
   1893    the error in [RFC0822], they SHOULD all be considered equivalent to
   1894    "-0000" unless there is out-of-band information confirming their
   1895    meaning.
   1896 
   1897    Other multi-character (usually between 3 and 5) alphabetic time zones
   1898    have been used in Internet messages.  Any such time zone whose
   1899    meaning is not known SHOULD be considered equivalent to "-0000"
   1900    unless there is out-of-band information confirming their meaning.
   1901 
   1902 
   1903 
   1904 
   1905 
   1906 Resnick                     Standards Track                    [Page 34]
   1907 
   1908 RFC 5322                Internet Message Format             October 2008
   1909 
   1910 
   1911 4.4.  Obsolete Addressing
   1912 
   1913    There are four primary differences in addressing.  First, mailbox
   1914    addresses were allowed to have a route portion before the addr-spec
   1915    when enclosed in "<" and ">".  The route is simply a comma-separated
   1916    list of domain names, each preceded by "@", and the list terminated
   1917    by a colon.  Second, CFWS were allowed between the period-separated
   1918    elements of local-part and domain (i.e., dot-atom was not used).  In
   1919    addition, local-part is allowed to contain quoted-string in addition
   1920    to just atom.  Third, mailbox-list and address-list were allowed to
   1921    have "null" members.  That is, there could be two or more commas in
   1922    such a list with nothing in between them, or commas at the beginning
   1923    or end of the list.  Finally, US-ASCII control characters and quoted-
   1924    pairs were allowed in domain literals and are added here.
   1925 
   1926    obs-angle-addr  =   [CFWS] "<" obs-route addr-spec ">" [CFWS]
   1927 
   1928    obs-route       =   obs-domain-list ":"
   1929 
   1930    obs-domain-list =   *(CFWS / ",") "@" domain
   1931                        *("," [CFWS] ["@" domain])
   1932 
   1933    obs-mbox-list   =   *([CFWS] ",") mailbox *("," [mailbox / CFWS])
   1934 
   1935    obs-addr-list   =   *([CFWS] ",") address *("," [address / CFWS])
   1936 
   1937    obs-group-list  =   1*([CFWS] ",") [CFWS]
   1938 
   1939    obs-local-part  =   word *("." word)
   1940 
   1941    obs-domain      =   atom *("." atom)
   1942 
   1943    obs-dtext       =   obs-NO-WS-CTL / quoted-pair
   1944 
   1945    When interpreting addresses, the route portion SHOULD be ignored.
   1946 
   1947 4.5.  Obsolete Header Fields
   1948 
   1949    Syntactically, the primary difference in the obsolete field syntax is
   1950    that it allows multiple occurrences of any of the fields and they may
   1951    occur in any order.  Also, any amount of white space is allowed
   1952    before the ":" at the end of the field name.
   1953 
   1954 
   1955 
   1956 
   1957 
   1958 
   1959 
   1960 
   1961 
   1962 Resnick                     Standards Track                    [Page 35]
   1963 
   1964 RFC 5322                Internet Message Format             October 2008
   1965 
   1966 
   1967    obs-fields      =   *(obs-return /
   1968                        obs-received /
   1969                        obs-orig-date /
   1970                        obs-from /
   1971                        obs-sender /
   1972                        obs-reply-to /
   1973                        obs-to /
   1974                        obs-cc /
   1975                        obs-bcc /
   1976                        obs-message-id /
   1977                        obs-in-reply-to /
   1978                        obs-references /
   1979                        obs-subject /
   1980                        obs-comments /
   1981                        obs-keywords /
   1982                        obs-resent-date /
   1983                        obs-resent-from /
   1984                        obs-resent-send /
   1985                        obs-resent-rply /
   1986                        obs-resent-to /
   1987                        obs-resent-cc /
   1988                        obs-resent-bcc /
   1989                        obs-resent-mid /
   1990                        obs-optional)
   1991 
   1992    Except for destination address fields (described in section 4.5.3),
   1993    the interpretation of multiple occurrences of fields is unspecified.
   1994    Also, the interpretation of trace fields and resent fields that do
   1995    not occur in blocks prepended to the message is unspecified as well.
   1996    Unless otherwise noted in the following sections, interpretation of
   1997    other fields is identical to the interpretation of their non-obsolete
   1998    counterparts in section 3.
   1999 
   2000 4.5.1.  Obsolete Origination Date Field
   2001 
   2002    obs-orig-date   =   "Date" *WSP ":" date-time CRLF
   2003 
   2004 4.5.2.  Obsolete Originator Fields
   2005 
   2006    obs-from        =   "From" *WSP ":" mailbox-list CRLF
   2007 
   2008    obs-sender      =   "Sender" *WSP ":" mailbox CRLF
   2009 
   2010    obs-reply-to    =   "Reply-To" *WSP ":" address-list CRLF
   2011 
   2012 
   2013 
   2014 
   2015 
   2016 
   2017 
   2018 Resnick                     Standards Track                    [Page 36]
   2019 
   2020 RFC 5322                Internet Message Format             October 2008
   2021 
   2022 
   2023 4.5.3.  Obsolete Destination Address Fields
   2024 
   2025    obs-to          =   "To" *WSP ":" address-list CRLF
   2026 
   2027    obs-cc          =   "Cc" *WSP ":" address-list CRLF
   2028 
   2029    obs-bcc         =   "Bcc" *WSP ":"
   2030                        (address-list / (*([CFWS] ",") [CFWS])) CRLF
   2031 
   2032    When multiple occurrences of destination address fields occur in a
   2033    message, they SHOULD be treated as if the address list in the first
   2034    occurrence of the field is combined with the address lists of the
   2035    subsequent occurrences by adding a comma and concatenating.
   2036 
   2037 4.5.4.  Obsolete Identification Fields
   2038 
   2039    The obsolete "In-Reply-To:" and "References:" fields differ from the
   2040    current syntax in that they allow phrase (words or quoted strings) to
   2041    appear.  The obsolete forms of the left and right sides of msg-id
   2042    allow interspersed CFWS, making them syntactically identical to
   2043    local-part and domain, respectively.
   2044 
   2045    obs-message-id  =   "Message-ID" *WSP ":" msg-id CRLF
   2046 
   2047    obs-in-reply-to =   "In-Reply-To" *WSP ":" *(phrase / msg-id) CRLF
   2048 
   2049    obs-references  =   "References" *WSP ":" *(phrase / msg-id) CRLF
   2050 
   2051    obs-id-left     =   local-part
   2052 
   2053    obs-id-right    =   domain
   2054 
   2055    For purposes of interpretation, the phrases in the "In-Reply-To:" and
   2056    "References:" fields are ignored.
   2057 
   2058    Semantically, none of the optional CFWS in the local-part and the
   2059    domain is part of the obs-id-left and obs-id-right, respectively.
   2060 
   2061 4.5.5.  Obsolete Informational Fields
   2062 
   2063    obs-subject     =   "Subject" *WSP ":" unstructured CRLF
   2064 
   2065    obs-comments    =   "Comments" *WSP ":" unstructured CRLF
   2066 
   2067    obs-keywords    =   "Keywords" *WSP ":" obs-phrase-list CRLF
   2068 
   2069 
   2070 
   2071 
   2072 
   2073 
   2074 Resnick                     Standards Track                    [Page 37]
   2075 
   2076 RFC 5322                Internet Message Format             October 2008
   2077 
   2078 
   2079 4.5.6.  Obsolete Resent Fields
   2080 
   2081    The obsolete syntax adds a "Resent-Reply-To:" field, which consists
   2082    of the field name, the optional comments and folding white space, the
   2083    colon, and a comma separated list of addresses.
   2084 
   2085    obs-resent-from =   "Resent-From" *WSP ":" mailbox-list CRLF
   2086 
   2087    obs-resent-send =   "Resent-Sender" *WSP ":" mailbox CRLF
   2088 
   2089    obs-resent-date =   "Resent-Date" *WSP ":" date-time CRLF
   2090 
   2091    obs-resent-to   =   "Resent-To" *WSP ":" address-list CRLF
   2092 
   2093    obs-resent-cc   =   "Resent-Cc" *WSP ":" address-list CRLF
   2094 
   2095    obs-resent-bcc  =   "Resent-Bcc" *WSP ":"
   2096                        (address-list / (*([CFWS] ",") [CFWS])) CRLF
   2097 
   2098    obs-resent-mid  =   "Resent-Message-ID" *WSP ":" msg-id CRLF
   2099 
   2100    obs-resent-rply =   "Resent-Reply-To" *WSP ":" address-list CRLF
   2101 
   2102    As with other resent fields, the "Resent-Reply-To:" field is to be
   2103    treated as trace information only.
   2104 
   2105 4.5.7.  Obsolete Trace Fields
   2106 
   2107    The obs-return and obs-received are again given here as template
   2108    definitions, just as return and received are in section 3.  Their
   2109    full syntax is given in [RFC5321].
   2110 
   2111    obs-return      =   "Return-Path" *WSP ":" path CRLF
   2112 
   2113    obs-received    =   "Received" *WSP ":" *received-token CRLF
   2114 
   2115 4.5.8.  Obsolete optional fields
   2116 
   2117    obs-optional    =   field-name *WSP ":" unstructured CRLF
   2118 
   2119 5.  Security Considerations
   2120 
   2121    Care needs to be taken when displaying messages on a terminal or
   2122    terminal emulator.  Powerful terminals may act on escape sequences
   2123    and other combinations of US-ASCII control characters with a variety
   2124    of consequences.  They can remap the keyboard or permit other
   2125    modifications to the terminal that could lead to denial of service or
   2126    even damaged data.  They can trigger (sometimes programmable)
   2127 
   2128 
   2129 
   2130 Resnick                     Standards Track                    [Page 38]
   2131 
   2132 RFC 5322                Internet Message Format             October 2008
   2133 
   2134 
   2135    answerback messages that can allow a message to cause commands to be
   2136    issued on the recipient's behalf.  They can also affect the operation
   2137    of terminal attached devices such as printers.  Message viewers may
   2138    wish to strip potentially dangerous terminal escape sequences from
   2139    the message prior to display.  However, other escape sequences appear
   2140    in messages for useful purposes (cf. [ISO.2022.1994], [RFC2045],
   2141    [RFC2046], [RFC2047], [RFC2049], [RFC4288], [RFC4289]) and therefore
   2142    should not be stripped indiscriminately.
   2143 
   2144    Transmission of non-text objects in messages raises additional
   2145    security issues.  These issues are discussed in [RFC2045], [RFC2046],
   2146    [RFC2047], [RFC2049], [RFC4288], and [RFC4289].
   2147 
   2148    Many implementations use the "Bcc:" (blind carbon copy) field,
   2149    described in section 3.6.3, to facilitate sending messages to
   2150    recipients without revealing the addresses of one or more of the
   2151    addressees to the other recipients.  Mishandling this use of "Bcc:"
   2152    may disclose confidential information that could eventually lead to
   2153    security problems through knowledge of even the existence of a
   2154    particular mail address.  For example, if using the first method
   2155    described in section 3.6.3, where the "Bcc:" line is removed from the
   2156    message, blind recipients have no explicit indication that they have
   2157    been sent a blind copy, except insofar as their address does not
   2158    appear in the header section of a message.  Because of this, one of
   2159    the blind addressees could potentially send a reply to all of the
   2160    shown recipients and accidentally reveal that the message went to the
   2161    blind recipient.  When the second method from section 3.6.3 is used,
   2162    the blind recipient's address appears in the "Bcc:" field of a
   2163    separate copy of the message.  If the "Bcc:" field sent contains all
   2164    of the blind addressees, all of the "Bcc:" recipients will be seen by
   2165    each "Bcc:" recipient.  Even if a separate message is sent to each
   2166    "Bcc:" recipient with only the individual's address, implementations
   2167    still need to be careful to process replies to the message as per
   2168    section 3.6.3 so as not to accidentally reveal the blind recipient to
   2169    other recipients.
   2170 
   2171 6.  IANA Considerations
   2172 
   2173    This document updates the registrations that appeared in [RFC4021]
   2174    that referred to the definitions in [RFC2822].  IANA has updated the
   2175    Permanent Message Header Field Repository with the following header
   2176    fields, in accordance with the procedures set out in [RFC3864].
   2177 
   2178    Header field name:  Date
   2179    Applicable protocol:  Mail
   2180    Status:  standard
   2181    Author/Change controller:  IETF
   2182    Specification document(s):  This document (section 3.6.1)
   2183 
   2184 
   2185 
   2186 Resnick                     Standards Track                    [Page 39]
   2187 
   2188 RFC 5322                Internet Message Format             October 2008
   2189 
   2190 
   2191    Header field name:  From
   2192    Applicable protocol:  Mail
   2193    Status:  standard
   2194    Author/Change controller:  IETF
   2195    Specification document(s):  This document (section 3.6.2)
   2196 
   2197    Header field name:  Sender
   2198    Applicable protocol:  Mail
   2199    Status:  standard
   2200    Author/Change controller:  IETF
   2201    Specification document(s):  This document (section 3.6.2)
   2202 
   2203    Header field name:  Reply-To
   2204    Applicable protocol:  Mail
   2205    Status:  standard
   2206    Author/Change controller:  IETF
   2207    Specification document(s):  This document (section 3.6.2)
   2208 
   2209    Header field name:  To
   2210    Applicable protocol:  Mail
   2211    Status:  standard
   2212    Author/Change controller:  IETF
   2213    Specification document(s):  This document (section 3.6.3)
   2214 
   2215    Header field name:  Cc
   2216    Applicable protocol:  Mail
   2217    Status:  standard
   2218    Author/Change controller:  IETF
   2219    Specification document(s):  This document (section 3.6.3)
   2220 
   2221    Header field name:  Bcc
   2222    Applicable protocol:  Mail
   2223    Status:  standard
   2224    Author/Change controller:  IETF
   2225    Specification document(s):  This document (section 3.6.3)
   2226 
   2227    Header field name:  Message-ID
   2228    Applicable protocol:  Mail
   2229    Status:  standard
   2230    Author/Change controller:  IETF
   2231    Specification document(s):  This document (section 3.6.4)
   2232 
   2233    Header field name:  In-Reply-To
   2234    Applicable protocol:  Mail
   2235    Status:  standard
   2236    Author/Change controller:  IETF
   2237    Specification document(s):  This document (section 3.6.4)
   2238 
   2239 
   2240 
   2241 
   2242 Resnick                     Standards Track                    [Page 40]
   2243 
   2244 RFC 5322                Internet Message Format             October 2008
   2245 
   2246 
   2247    Header field name:  References
   2248    Applicable protocol:  Mail
   2249    Status:  standard
   2250    Author/Change controller:  IETF
   2251    Specification document(s):  This document (section 3.6.4)
   2252 
   2253    Header field name:  Subject
   2254    Applicable protocol:  Mail
   2255    Status:  standard
   2256    Author/Change controller:  IETF
   2257    Specification document(s):  This document (section 3.6.5)
   2258 
   2259    Header field name:  Comments
   2260    Applicable protocol:  Mail
   2261    Status:  standard
   2262    Author/Change controller:  IETF
   2263    Specification document(s):  This document (section 3.6.5)
   2264 
   2265    Header field name:  Keywords
   2266    Applicable protocol:  Mail
   2267    Status:  standard
   2268    Author/Change controller:  IETF
   2269    Specification document(s):  This document (section 3.6.5)
   2270 
   2271    Header field name:  Resent-Date
   2272    Applicable protocol:  Mail
   2273    Status:  standard
   2274    Author/Change controller:  IETF
   2275    Specification document(s):  This document (section 3.6.6)
   2276 
   2277    Header field name:  Resent-From
   2278    Applicable protocol:  Mail
   2279    Status:  standard
   2280    Author/Change controller:  IETF
   2281    Specification document(s):  This document (section 3.6.6)
   2282 
   2283    Header field name:  Resent-Sender
   2284    Applicable protocol:  Mail
   2285    Status:  standard
   2286    Author/Change controller:  IETF
   2287    Specification document(s):  This document (section 3.6.6)
   2288 
   2289    Header field name:  Resent-To
   2290    Applicable protocol:  Mail
   2291    Status:  standard
   2292    Author/Change controller:  IETF
   2293    Specification document(s):  This document (section 3.6.6)
   2294 
   2295 
   2296 
   2297 
   2298 Resnick                     Standards Track                    [Page 41]
   2299 
   2300 RFC 5322                Internet Message Format             October 2008
   2301 
   2302 
   2303    Header field name:  Resent-Cc
   2304    Applicable protocol:  Mail
   2305    Status:  standard
   2306    Author/Change controller:  IETF
   2307    Specification document(s):  This document (section 3.6.6)
   2308 
   2309    Header field name:  Resent-Bcc
   2310    Applicable protocol:  Mail
   2311    Status:  standard
   2312    Author/Change controller:  IETF
   2313    Specification document(s):  This document (section 3.6.6)
   2314 
   2315    Header field name:  Resent-Reply-To
   2316    Applicable protocol:  Mail
   2317    Status:  obsolete
   2318    Author/Change controller:  IETF
   2319    Specification document(s):  This document (section 4.5.6)
   2320 
   2321    Header field name:  Resent-Message-ID
   2322    Applicable protocol:  Mail
   2323    Status:  standard
   2324    Author/Change controller:  IETF
   2325    Specification document(s):  This document (section 3.6.6)
   2326 
   2327    Header field name:  Return-Path
   2328    Applicable protocol:  Mail
   2329    Status:  standard
   2330    Author/Change controller:  IETF
   2331    Specification document(s):  This document (section 3.6.7)
   2332 
   2333    Header field name:  Received
   2334    Applicable protocol:  Mail
   2335    Status:  standard
   2336    Author/Change controller:  IETF
   2337    Specification document(s):  This document (section 3.6.7)
   2338    Related information:  [RFC5321]
   2339 
   2340 
   2341 
   2342 
   2343 
   2344 
   2345 
   2346 
   2347 
   2348 
   2349 
   2350 
   2351 
   2352 
   2353 
   2354 Resnick                     Standards Track                    [Page 42]
   2355 
   2356 RFC 5322                Internet Message Format             October 2008
   2357 
   2358 
   2359 Appendix A.  Example Messages
   2360 
   2361    This section presents a selection of messages.  These are intended to
   2362    assist in the implementation of this specification, but should not be
   2363    taken as normative; that is to say, although the examples in this
   2364    section were carefully reviewed, if there happens to be a conflict
   2365    between these examples and the syntax described in sections 3 and 4
   2366    of this document, the syntax in those sections is to be taken as
   2367    correct.
   2368 
   2369    In the text version of this document, messages in this section are
   2370    delimited between lines of "----".  The "----" lines are not part of
   2371    the message itself.
   2372 
   2373 
   2374 
   2375 
   2376 
   2377 
   2378 
   2379 
   2380 
   2381 
   2382 
   2383 
   2384 
   2385 
   2386 
   2387 
   2388 
   2389 
   2390 
   2391 
   2392 
   2393 
   2394 
   2395 
   2396 
   2397 
   2398 
   2399 
   2400 
   2401 
   2402 
   2403 
   2404 
   2405 
   2406 
   2407 
   2408 
   2409 
   2410 Resnick                     Standards Track                    [Page 43]
   2411 
   2412 RFC 5322                Internet Message Format             October 2008
   2413 
   2414 
   2415 Appendix A.1.  Addressing Examples
   2416 
   2417    The following are examples of messages that might be sent between two
   2418    individuals.
   2419 
   2420 Appendix A.1.1.  A Message from One Person to Another with Simple
   2421                  Addressing
   2422 
   2423    This could be called a canonical message.  It has a single author,
   2424    John Doe, a single recipient, Mary Smith, a subject, the date, a
   2425    message identifier, and a textual message in the body.
   2426 
   2427    ----
   2428    From: John Doe <jdoe@machine.example>
   2429    To: Mary Smith <mary@example.net>
   2430    Subject: Saying Hello
   2431    Date: Fri, 21 Nov 1997 09:55:06 -0600
   2432    Message-ID: <1234@local.machine.example>
   2433 
   2434    This is a message just to say hello.
   2435    So, "Hello".
   2436    ----
   2437 
   2438    If John's secretary Michael actually sent the message, even though
   2439    John was the author and replies to this message should go back to
   2440    him, the sender field would be used:
   2441 
   2442    ----
   2443    From: John Doe <jdoe@machine.example>
   2444    Sender: Michael Jones <mjones@machine.example>
   2445    To: Mary Smith <mary@example.net>
   2446    Subject: Saying Hello
   2447    Date: Fri, 21 Nov 1997 09:55:06 -0600
   2448    Message-ID: <1234@local.machine.example>
   2449 
   2450    This is a message just to say hello.
   2451    So, "Hello".
   2452    ----
   2453 
   2454 
   2455 
   2456 
   2457 
   2458 
   2459 
   2460 
   2461 
   2462 
   2463 
   2464 
   2465 
   2466 Resnick                     Standards Track                    [Page 44]
   2467 
   2468 RFC 5322                Internet Message Format             October 2008
   2469 
   2470 
   2471 Appendix A.1.2.  Different Types of Mailboxes
   2472 
   2473    This message includes multiple addresses in the destination fields
   2474    and also uses several different forms of addresses.
   2475 
   2476    ----
   2477    From: "Joe Q. Public" <john.q.public@example.com>
   2478    To: Mary Smith <mary@x.test>, jdoe@example.org, Who? <one@y.test>
   2479    Cc: <boss@nil.test>, "Giant; \"Big\" Box" <sysservices@example.net>
   2480    Date: Tue, 1 Jul 2003 10:52:37 +0200
   2481    Message-ID: <5678.21-Nov-1997@example.com>
   2482 
   2483    Hi everyone.
   2484    ----
   2485 
   2486    Note that the display names for Joe Q. Public and Giant; "Big" Box
   2487    needed to be enclosed in double-quotes because the former contains
   2488    the period and the latter contains both semicolon and double-quote
   2489    characters (the double-quote characters appearing as quoted-pair
   2490    constructs).  Conversely, the display name for Who? could appear
   2491    without them because the question mark is legal in an atom.  Notice
   2492    also that jdoe@example.org and boss@nil.test have no display names
   2493    associated with them at all, and jdoe@example.org uses the simpler
   2494    address form without the angle brackets.
   2495 
   2496 Appendix A.1.3.  Group Addresses
   2497 
   2498    ----
   2499    From: Pete <pete@silly.example>
   2500    To: A Group:Ed Jones <c@a.test>,joe@where.test,John <jdoe@one.test>;
   2501    Cc: Undisclosed recipients:;
   2502    Date: Thu, 13 Feb 1969 23:32:54 -0330
   2503    Message-ID: <testabcd.1234@silly.example>
   2504 
   2505    Testing.
   2506    ----
   2507 
   2508    In this message, the "To:" field has a single group recipient named
   2509    "A Group", which contains 3 addresses, and a "Cc:" field with an
   2510    empty group recipient named Undisclosed recipients.
   2511 
   2512 
   2513 
   2514 
   2515 
   2516 
   2517 
   2518 
   2519 
   2520 
   2521 
   2522 Resnick                     Standards Track                    [Page 45]
   2523 
   2524 RFC 5322                Internet Message Format             October 2008
   2525 
   2526 
   2527 Appendix A.2.  Reply Messages
   2528 
   2529    The following is a series of three messages that make up a
   2530    conversation thread between John and Mary.  John first sends a
   2531    message to Mary, Mary then replies to John's message, and then John
   2532    replies to Mary's reply message.
   2533 
   2534    Note especially the "Message-ID:", "References:", and "In-Reply-To:"
   2535    fields in each message.
   2536 
   2537    ----
   2538    From: John Doe <jdoe@machine.example>
   2539    To: Mary Smith <mary@example.net>
   2540    Subject: Saying Hello
   2541    Date: Fri, 21 Nov 1997 09:55:06 -0600
   2542    Message-ID: <1234@local.machine.example>
   2543 
   2544    This is a message just to say hello.
   2545    So, "Hello".
   2546    ----
   2547 
   2548    When sending replies, the Subject field is often retained, though
   2549    prepended with "Re: " as described in section 3.6.5.
   2550 
   2551    ----
   2552    From: Mary Smith <mary@example.net>
   2553    To: John Doe <jdoe@machine.example>
   2554    Reply-To: "Mary Smith: Personal Account" <smith@home.example>
   2555    Subject: Re: Saying Hello
   2556    Date: Fri, 21 Nov 1997 10:01:10 -0600
   2557    Message-ID: <3456@example.net>
   2558    In-Reply-To: <1234@local.machine.example>
   2559    References: <1234@local.machine.example>
   2560 
   2561    This is a reply to your hello.
   2562    ----
   2563 
   2564    Note the "Reply-To:" field in the above message.  When John replies
   2565    to Mary's message above, the reply should go to the address in the
   2566    "Reply-To:" field instead of the address in the "From:" field.
   2567 
   2568 
   2569 
   2570 
   2571 
   2572 
   2573 
   2574 
   2575 
   2576 
   2577 
   2578 Resnick                     Standards Track                    [Page 46]
   2579 
   2580 RFC 5322                Internet Message Format             October 2008
   2581 
   2582 
   2583    ----
   2584    To: "Mary Smith: Personal Account" <smith@home.example>
   2585    From: John Doe <jdoe@machine.example>
   2586    Subject: Re: Saying Hello
   2587    Date: Fri, 21 Nov 1997 11:00:00 -0600
   2588    Message-ID: <abcd.1234@local.machine.test>
   2589    In-Reply-To: <3456@example.net>
   2590    References: <1234@local.machine.example> <3456@example.net>
   2591 
   2592    This is a reply to your reply.
   2593    ----
   2594 
   2595 Appendix A.3.  Resent Messages
   2596 
   2597    Start with the message that has been used as an example several
   2598    times:
   2599 
   2600    ----
   2601    From: John Doe <jdoe@machine.example>
   2602    To: Mary Smith <mary@example.net>
   2603    Subject: Saying Hello
   2604    Date: Fri, 21 Nov 1997 09:55:06 -0600
   2605    Message-ID: <1234@local.machine.example>
   2606 
   2607    This is a message just to say hello.
   2608    So, "Hello".
   2609    ----
   2610 
   2611    Say that Mary, upon receiving this message, wishes to send a copy of
   2612    the message to Jane such that (a) the message would appear to have
   2613    come straight from John; (b) if Jane replies to the message, the
   2614    reply should go back to John; and (c) all of the original
   2615    information, like the date the message was originally sent to Mary,
   2616    the message identifier, and the original addressee, is preserved.  In
   2617    this case, resent fields are prepended to the message:
   2618 
   2619 
   2620 
   2621 
   2622 
   2623 
   2624 
   2625 
   2626 
   2627 
   2628 
   2629 
   2630 
   2631 
   2632 
   2633 
   2634 Resnick                     Standards Track                    [Page 47]
   2635 
   2636 RFC 5322                Internet Message Format             October 2008
   2637 
   2638 
   2639    ----
   2640    Resent-From: Mary Smith <mary@example.net>
   2641    Resent-To: Jane Brown <j-brown@other.example>
   2642    Resent-Date: Mon, 24 Nov 1997 14:22:01 -0800
   2643    Resent-Message-ID: <78910@example.net>
   2644    From: John Doe <jdoe@machine.example>
   2645    To: Mary Smith <mary@example.net>
   2646    Subject: Saying Hello
   2647    Date: Fri, 21 Nov 1997 09:55:06 -0600
   2648    Message-ID: <1234@local.machine.example>
   2649 
   2650    This is a message just to say hello.
   2651    So, "Hello".
   2652    ----
   2653 
   2654    If Jane, in turn, wished to resend this message to another person,
   2655    she would prepend her own set of resent header fields to the above
   2656    and send that.  (Note that for brevity, trace fields are not shown.)
   2657 
   2658 Appendix A.4.  Messages with Trace Fields
   2659 
   2660    As messages are sent through the transport system as described in
   2661    [RFC5321], trace fields are prepended to the message.  The following
   2662    is an example of what those trace fields might look like.  Note that
   2663    there is some folding white space in the first one since these lines
   2664    can be long.
   2665 
   2666    ----
   2667    Received: from x.y.test
   2668       by example.net
   2669       via TCP
   2670       with ESMTP
   2671       id ABC12345
   2672       for <mary@example.net>;  21 Nov 1997 10:05:43 -0600
   2673    Received: from node.example by x.y.test; 21 Nov 1997 10:01:22 -0600
   2674    From: John Doe <jdoe@node.example>
   2675    To: Mary Smith <mary@example.net>
   2676    Subject: Saying Hello
   2677    Date: Fri, 21 Nov 1997 09:55:06 -0600
   2678    Message-ID: <1234@local.node.example>
   2679 
   2680    This is a message just to say hello.
   2681    So, "Hello".
   2682    ----
   2683 
   2684 
   2685 
   2686 
   2687 
   2688 
   2689 
   2690 Resnick                     Standards Track                    [Page 48]
   2691 
   2692 RFC 5322                Internet Message Format             October 2008
   2693 
   2694 
   2695 Appendix A.5.  White Space, Comments, and Other Oddities
   2696 
   2697    White space, including folding white space, and comments can be
   2698    inserted between many of the tokens of fields.  Taking the example
   2699    from A.1.3, white space and comments can be inserted into all of the
   2700    fields.
   2701 
   2702    ----
   2703    From: Pete(A nice \) chap) <pete(his account)@silly.test(his host)>
   2704    To:A Group(Some people)
   2705         :Chris Jones <c@(Chris's host.)public.example>,
   2706             joe@example.org,
   2707      John <jdoe@one.test> (my dear friend); (the end of the group)
   2708    Cc:(Empty list)(start)Hidden recipients  :(nobody(that I know))  ;
   2709    Date: Thu,
   2710          13
   2711            Feb
   2712              1969
   2713          23:32
   2714                   -0330 (Newfoundland Time)
   2715    Message-ID:              <testabcd.1234@silly.test>
   2716 
   2717    Testing.
   2718    ----
   2719 
   2720    The above example is aesthetically displeasing, but perfectly legal.
   2721    Note particularly (1) the comments in the "From:" field (including
   2722    one that has a ")" character appearing as part of a quoted-pair); (2)
   2723    the white space absent after the ":" in the "To:" field as well as
   2724    the comment and folding white space after the group name, the special
   2725    character (".") in the comment in Chris Jones's address, and the
   2726    folding white space before and after "joe@example.org,"; (3) the
   2727    multiple and nested comments in the "Cc:" field as well as the
   2728    comment immediately following the ":" after "Cc"; (4) the folding
   2729    white space (but no comments except at the end) and the missing
   2730    seconds in the time of the date field; and (5) the white space before
   2731    (but not within) the identifier in the "Message-ID:" field.
   2732 
   2733 
   2734 
   2735 
   2736 
   2737 
   2738 
   2739 
   2740 
   2741 
   2742 
   2743 
   2744 
   2745 
   2746 Resnick                     Standards Track                    [Page 49]
   2747 
   2748 RFC 5322                Internet Message Format             October 2008
   2749 
   2750 
   2751 Appendix A.6.  Obsoleted Forms
   2752 
   2753    The following are examples of obsolete (that is, the "MUST NOT
   2754    generate") syntactic elements described in section 4 of this
   2755    document.
   2756 
   2757 Appendix A.6.1.  Obsolete Addressing
   2758 
   2759    Note in the example below the lack of quotes around Joe Q. Public,
   2760    the route that appears in the address for Mary Smith, the two commas
   2761    that appear in the "To:" field, and the spaces that appear around the
   2762    "." in the jdoe address.
   2763 
   2764    ----
   2765    From: Joe Q. Public <john.q.public@example.com>
   2766    To: Mary Smith <@node.test:mary@example.net>, , jdoe@test  . example
   2767    Date: Tue, 1 Jul 2003 10:52:37 +0200
   2768    Message-ID: <5678.21-Nov-1997@example.com>
   2769 
   2770    Hi everyone.
   2771    ----
   2772 
   2773 Appendix A.6.2.  Obsolete Dates
   2774 
   2775    The following message uses an obsolete date format, including a non-
   2776    numeric time zone and a two digit year.  Note that although the day-
   2777    of-week is missing, that is not specific to the obsolete syntax; it
   2778    is optional in the current syntax as well.
   2779 
   2780    ----
   2781    From: John Doe <jdoe@machine.example>
   2782    To: Mary Smith <mary@example.net>
   2783    Subject: Saying Hello
   2784    Date: 21 Nov 97 09:55:06 GMT
   2785    Message-ID: <1234@local.machine.example>
   2786 
   2787    This is a message just to say hello.
   2788    So, "Hello".
   2789    ----
   2790 
   2791 
   2792 
   2793 
   2794 
   2795 
   2796 
   2797 
   2798 
   2799 
   2800 
   2801 
   2802 Resnick                     Standards Track                    [Page 50]
   2803 
   2804 RFC 5322                Internet Message Format             October 2008
   2805 
   2806 
   2807 Appendix A.6.3.  Obsolete White Space and Comments
   2808 
   2809    White space and comments can appear between many more elements than
   2810    in the current syntax.  Also, folding lines that are made up entirely
   2811    of white space are legal.
   2812 
   2813    ----
   2814    From  : John Doe <jdoe@machine(comment).  example>
   2815    To    : Mary Smith
   2816    __
   2817              <mary@example.net>
   2818    Subject     : Saying Hello
   2819    Date  : Fri, 21 Nov 1997 09(comment):   55  :  06 -0600
   2820    Message-ID  : <1234   @   local(blah)  .machine .example>
   2821 
   2822    This is a message just to say hello.
   2823    So, "Hello".
   2824    ----
   2825 
   2826    Note especially the second line of the "To:" field.  It starts with
   2827    two space characters.  (Note that "__" represent blank spaces.)
   2828    Therefore, it is considered part of the folding, as described in
   2829    section 4.2.  Also, the comments and white space throughout
   2830    addresses, dates, and message identifiers are all part of the
   2831    obsolete syntax.
   2832 
   2833 
   2834 
   2835 
   2836 
   2837 
   2838 
   2839 
   2840 
   2841 
   2842 
   2843 
   2844 
   2845 
   2846 
   2847 
   2848 
   2849 
   2850 
   2851 
   2852 
   2853 
   2854 
   2855 
   2856 
   2857 
   2858 Resnick                     Standards Track                    [Page 51]
   2859 
   2860 RFC 5322                Internet Message Format             October 2008
   2861 
   2862 
   2863 Appendix B.  Differences from Earlier Specifications
   2864 
   2865    This appendix contains a list of changes that have been made in the
   2866    Internet Message Format from earlier specifications, specifically
   2867    [RFC0822], [RFC1123], and [RFC2822].  Items marked with an asterisk
   2868    (*) below are items which appear in section 4 of this document and
   2869    therefore can no longer be generated.
   2870 
   2871    The following are the changes made from [RFC0822] and [RFC1123] to
   2872    [RFC2822] that remain in this document:
   2873 
   2874    1.   Period allowed in obsolete form of phrase.
   2875    2.   ABNF moved out of document, now in [RFC5234].
   2876    3.   Four or more digits allowed for year.
   2877    4.   Header field ordering (and lack thereof) made explicit.
   2878    5.   Encrypted header field removed.
   2879    6.   Specifically allow and give meaning to "-0000" time zone.
   2880    7.   Folding white space is not allowed between every token.
   2881    8.   Requirement for destinations removed.
   2882    9.   Forwarding and resending redefined.
   2883    10.  Extension header fields no longer specifically called out.
   2884    11.  ASCII 0 (null) removed.*
   2885    12.  Folding continuation lines cannot contain only white space.*
   2886    13.  Free insertion of comments not allowed in date.*
   2887    14.  Non-numeric time zones not allowed.*
   2888    15.  Two digit years not allowed.*
   2889    16.  Three digit years interpreted, but not allowed for generation.*
   2890    17.  Routes in addresses not allowed.*
   2891    18.  CFWS within local-parts and domains not allowed.*
   2892    19.  Empty members of address lists not allowed.*
   2893    20.  Folding white space between field name and colon not allowed.*
   2894    21.  Comments between field name and colon not allowed.
   2895    22.  Tightened syntax of in-reply-to and references.*
   2896    23.  CFWS within msg-id not allowed.*
   2897    24.  Tightened semantics of resent fields as informational only.
   2898    25.  Resent-Reply-To not allowed.*
   2899    26.  No multiple occurrences of fields (except resent and received).*
   2900    27.  Free CR and LF not allowed.*
   2901    28.  Line length limits specified.
   2902    29.  Bcc more clearly specified.
   2903 
   2904 
   2905 
   2906 
   2907 
   2908 
   2909 
   2910 
   2911 
   2912 
   2913 
   2914 Resnick                     Standards Track                    [Page 52]
   2915 
   2916 RFC 5322                Internet Message Format             October 2008
   2917 
   2918 
   2919    The following are changes from [RFC2822].
   2920    1.   Assorted typographical/grammatical errors fixed and
   2921         clarifications made.
   2922    2.   Changed "standard" to "document" or "specification" throughout.
   2923    3.   Made distinction between "header field" and "header section".
   2924    4.   Removed NO-WS-CTL from ctext, qtext, dtext, and unstructured.*
   2925    5.   Moved discussion of specials to the "Atom" section.  Moved text
   2926         to "Overall message syntax" section.
   2927    6.   Simplified CFWS syntax.
   2928    7.   Fixed unstructured syntax.
   2929    8.   Changed date and time syntax to deal with white space in
   2930         obsolete date syntax.
   2931    9.   Removed quoted-pair from domain literals and message
   2932         identifiers.*
   2933    10.  Clarified that other specifications limit domain syntax.
   2934    11.  Simplified "Bcc:" and "Resent-Bcc:" syntax.
   2935    12.  Allowed optional-field to appear within trace information.
   2936    13.  Removed no-fold-quote from msg-id.  Clarified syntax
   2937         limitations.
   2938    14.  Generalized "Received:" syntax to fix bugs and move definition
   2939         out of this document.
   2940    15.  Simplified obs-qp.  Fixed and simplified obs-utext (which now
   2941         only appears in the obsolete syntax).  Removed obs-text and obs-
   2942         char, adding obs-body.
   2943    16.  Fixed obsolete date syntax to allow for more (or less) comments
   2944         and white space.
   2945    17.  Fixed all obsolete list syntax (obs-domain-list, obs-mbox-list,
   2946         obs-addr-list, obs-phrase-list, and the newly added obs-group-
   2947         list).
   2948    18.  Fixed obs-reply-to syntax.
   2949    19.  Fixed obs-bcc and obs-resent-bcc to allow empty lists.
   2950    20.  Removed obs-path.
   2951 
   2952 Appendix C.  Acknowledgements
   2953 
   2954    Many people contributed to this document.  They included folks who
   2955    participated in the Detailed Revision and Update of Messaging
   2956    Standards (DRUMS) Working Group of the Internet Engineering Task
   2957    Force (IETF), the chair of DRUMS, the Area Directors of the IETF, and
   2958    people who simply sent their comments in via email.  The editor is
   2959    deeply indebted to them all and thanks them sincerely.  The below
   2960    list includes everyone who sent email concerning both this document
   2961    and [RFC2822].  Hopefully, everyone who contributed is named here:
   2962 
   2963    +--------------------+----------------------+---------------------+
   2964    | Matti Aarnio       | Tanaka Akira         | Russ Allbery        |
   2965    | Eric Allman        | Harald Alvestrand    | Ran Atkinson        |
   2966    | Jos Backus         | Bruce Balden         | Dave Barr           |
   2967 
   2968 
   2969 
   2970 Resnick                     Standards Track                    [Page 53]
   2971 
   2972 RFC 5322                Internet Message Format             October 2008
   2973 
   2974 
   2975    | Alan Barrett       | John Beck            | J Robert von Behren |
   2976    | Jos den Bekker     | D J Bernstein        | James Berriman      |
   2977    | Oliver Block       | Norbert Bollow       | Raj Bose            |
   2978    | Antony Bowesman    | Scott Bradner        | Randy Bush          |
   2979    | Tom Byrer          | Bruce Campbell       | Larry Campbell      |
   2980    | W J Carpenter      | Michael Chapman      | Richard Clayton     |
   2981    | Maurizio Codogno   | Jim Conklin          | R Kelley Cook       |
   2982    | Nathan Coulter     | Steve Coya           | Mark Crispin        |
   2983    | Dave Crocker       | Matt Curtin          | Michael D'Errico    |
   2984    | Cyrus Daboo        | Michael D Dean       | Jutta Degener       |
   2985    | Mark Delany        | Steve Dorner         | Harold A Driscoll   |
   2986    | Michael Elkins     | Frank Ellerman       | Robert Elz          |
   2987    | Johnny Eriksson    | Erik E Fair          | Roger Fajman        |
   2988    | Patrik Faltstrom   | Claus Andre Faerber  | Barry Finkel        |
   2989    | Erik Forsberg      | Chuck Foster         | Paul Fox            |
   2990    | Klaus M Frank      | Ned Freed            | Jochen Friedrich    |
   2991    | Randall C Gellens  | Sukvinder Singh Gill | Tim Goodwin         |
   2992    | Philip Guenther    | Arnt Gulbrandsen     | Eric A Hall         |
   2993    | Tony Hansen        | John Hawkinson       | Philip Hazel        |
   2994    | Kai Henningsen     | Robert Herriot       | Paul Hethmon        |
   2995    | Jim Hill           | Alfred Hoenes        | Paul E Hoffman      |
   2996    | Steve Hole         | Kari Hurtta          | Marco S Hyman       |
   2997    | Ofer Inbar         | Olle Jarnefors       | Kevin Johnson       |
   2998    | Sudish Joseph      | Maynard Kang         | Prabhat Keni        |
   2999    | John C Klensin     | Graham Klyne         | Brad Knowles        |
   3000    | Shuhei Kobayashi   | Peter Koch           | Dan Kohn            |
   3001    | Christian Kuhtz    | Anand Kumria         | Steen Larsen        |
   3002    | Eliot Lear         | Barry Leiba          | Jay Levitt          |
   3003    | Bruce Lilly        | Lars-Johan Liman     | Charles Lindsey     |
   3004    | Pete Loshin        | Simon Lyall          | Bill Manning        |
   3005    | John Martin        | Mark Martinec        | Larry Masinter      |
   3006    | Denis McKeon       | William P McQuillan  | Alexey Melnikov     |
   3007    | Perry E Metzger    | Steven Miller        | S Moonesamy         |
   3008    | Keith Moore        | John Gardiner Myers  | Chris Newman        |
   3009    | John W Noerenberg  | Eric Norman          | Mike O'Dell         |
   3010    | Larry Osterman     | Paul Overell         | Jacob Palme         |
   3011    | Michael A Patton   | Uzi Paz              | Michael A Quinlan   |
   3012    | Robert Rapplean    | Eric S Raymond       | Sam Roberts         |
   3013    | Hugh Sasse         | Bart Schaefer        | Tom Scola           |
   3014    | Wolfgang Segmuller | Nick Shelness        | John Stanley        |
   3015    | Einar Stefferud    | Jeff Stephenson      | Bernard Stern       |
   3016    | Peter Sylvester    | Mark Symons          | Eric Thomas         |
   3017    | Lee Thompson       | Karel De Vriendt     | Matthew Wall        |
   3018    | Rolf Weber         | Brent B Welch        | Dan Wing            |
   3019    | Jack De Winter     | Gregory J Woodhouse  | Greg A Woods        |
   3020    | Kazu Yamamoto      | Alain Zahm           | Jamie Zawinski      |
   3021    | Timothy S Zurcher  |                      |                     |
   3022    +--------------------+----------------------+---------------------+
   3023 
   3024 
   3025 
   3026 Resnick                     Standards Track                    [Page 54]
   3027 
   3028 RFC 5322                Internet Message Format             October 2008
   3029 
   3030 
   3031 7.  References
   3032 
   3033 7.1.  Normative References
   3034 
   3035    [ANSI.X3-4.1986]  American National Standards Institute, "Coded
   3036                      Character Set - 7-bit American Standard Code for
   3037                      Information Interchange", ANSI X3.4, 1986.
   3038 
   3039    [RFC1034]         Mockapetris, P., "Domain names - concepts and
   3040                      facilities", STD 13, RFC 1034, November 1987.
   3041 
   3042    [RFC1035]         Mockapetris, P., "Domain names - implementation and
   3043                      specification", STD 13, RFC 1035, November 1987.
   3044 
   3045    [RFC1123]         Braden, R., "Requirements for Internet Hosts -
   3046                      Application and Support", STD 3, RFC 1123,
   3047                      October 1989.
   3048 
   3049    [RFC2119]         Bradner, S., "Key words for use in RFCs to Indicate
   3050                      Requirement Levels", BCP 14, RFC 2119, March 1997.
   3051 
   3052    [RFC5234]         Crocker, D. and P. Overell, "Augmented BNF for
   3053                      Syntax Specifications: ABNF", STD 68, RFC 5234,
   3054                      January 2008.
   3055 
   3056 7.2.  Informative References
   3057 
   3058    [RFC0822]         Crocker, D., "Standard for the format of ARPA
   3059                      Internet text messages", STD 11, RFC 822,
   3060                      August 1982.
   3061 
   3062    [RFC1305]         Mills, D., "Network Time Protocol (Version 3)
   3063                      Specification, Implementation", RFC 1305,
   3064                      March 1992.
   3065 
   3066    [ISO.2022.1994]   International Organization for Standardization,
   3067                      "Information technology - Character code structure
   3068                      and extension techniques", ISO Standard 2022, 1994.
   3069 
   3070    [RFC2045]         Freed, N. and N. Borenstein, "Multipurpose Internet
   3071                      Mail Extensions (MIME) Part One: Format of Internet
   3072                      Message Bodies", RFC 2045, November 1996.
   3073 
   3074    [RFC2046]         Freed, N. and N. Borenstein, "Multipurpose Internet
   3075                      Mail Extensions (MIME) Part Two: Media Types",
   3076                      RFC 2046, November 1996.
   3077 
   3078 
   3079 
   3080 
   3081 
   3082 Resnick                     Standards Track                    [Page 55]
   3083 
   3084 RFC 5322                Internet Message Format             October 2008
   3085 
   3086 
   3087    [RFC2047]         Moore, K., "MIME (Multipurpose Internet Mail
   3088                      Extensions) Part Three: Message Header Extensions
   3089                      for Non-ASCII Text", RFC 2047, November 1996.
   3090 
   3091    [RFC2049]         Freed, N. and N. Borenstein, "Multipurpose Internet
   3092                      Mail Extensions (MIME) Part Five: Conformance
   3093                      Criteria and Examples", RFC 2049, November 1996.
   3094 
   3095    [RFC2822]         Resnick, P., "Internet Message Format", RFC 2822,
   3096                      April 2001.
   3097 
   3098    [RFC3864]         Klyne, G., Nottingham, M., and J. Mogul,
   3099                      "Registration Procedures for Message Header
   3100                      Fields", BCP 90, RFC 3864, September 2004.
   3101 
   3102    [RFC4021]         Klyne, G. and J. Palme, "Registration of Mail and
   3103                      MIME Header Fields", RFC 4021, March 2005.
   3104 
   3105    [RFC4288]         Freed, N. and J. Klensin, "Media Type
   3106                      Specifications and Registration Procedures",
   3107                      BCP 13, RFC 4288, December 2005.
   3108 
   3109    [RFC4289]         Freed, N. and J. Klensin, "Multipurpose Internet
   3110                      Mail Extensions (MIME) Part Four: Registration
   3111                      Procedures", BCP 13, RFC 4289, December 2005.
   3112 
   3113    [RFC5321]         Klensin, J., "Simple Mail Transfer Protocol",
   3114                      RFC 5321, October 2008.
   3115 
   3116 Author's Address
   3117 
   3118    Peter W. Resnick (editor)
   3119    Qualcomm Incorporated
   3120    5775 Morehouse Drive
   3121    San Diego, CA  92121-1714
   3122    US
   3123 
   3124    Phone: +1 858 651 4478
   3125    EMail: presnick@qualcomm.com
   3126    URI:   http://www.qualcomm.com/~presnick/
   3127 
   3128 
   3129 
   3130 
   3131 
   3132 
   3133 
   3134 
   3135 
   3136 
   3137 
   3138 Resnick                     Standards Track                    [Page 56]
   3139 
   3140 RFC 5322                Internet Message Format             October 2008
   3141 
   3142 
   3143 Full Copyright Statement
   3144 
   3145    Copyright (C) The IETF Trust (2008).
   3146 
   3147    This document is subject to the rights, licenses and restrictions
   3148    contained in BCP 78, and except as set forth therein, the authors
   3149    retain all their rights.
   3150 
   3151    This document and the information contained herein are provided on an
   3152    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   3153    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   3154    THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   3155    OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   3156    THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   3157    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
   3158 
   3159 Intellectual Property
   3160 
   3161    The IETF takes no position regarding the validity or scope of any
   3162    Intellectual Property Rights or other rights that might be claimed to
   3163    pertain to the implementation or use of the technology described in
   3164    this document or the extent to which any license under such rights
   3165    might or might not be available; nor does it represent that it has
   3166    made any independent effort to identify any such rights.  Information
   3167    on the procedures with respect to rights in RFC documents can be
   3168    found in BCP 78 and BCP 79.
   3169 
   3170    Copies of IPR disclosures made to the IETF Secretariat and any
   3171    assurances of licenses to be made available, or the result of an
   3172    attempt made to obtain a general license or permission for the use of
   3173    such proprietary rights by implementers or users of this
   3174    specification can be obtained from the IETF on-line IPR repository at
   3175    http://www.ietf.org/ipr.
   3176 
   3177    The IETF invites any interested party to bring to its attention any
   3178    copyrights, patents or patent applications, or other proprietary
   3179    rights that may cover technology that may be required to implement
   3180    this standard.  Please address the information to the IETF at
   3181    ietf-ipr@ietf.org.
   3182 
   3183 
   3184 
   3185 
   3186 
   3187 
   3188 
   3189 
   3190 
   3191 
   3192 
   3193 
   3194 Resnick                     Standards Track                    [Page 57]
   3195