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

rfc822.txt (106299B)


      1 
      2  
      3 
      4 
      5 
      6 
      7      RFC #  822
      8 
      9      Obsoletes:  RFC #733  (NIC #41952)
     10 
     11 
     12 
     13 
     14 
     15 
     16 
     17 
     18 
     19 
     20 
     21 
     22                         STANDARD FOR THE FORMAT OF
     23 
     24                         ARPA INTERNET TEXT MESSAGES
     25 
     26 
     27 
     28 
     29 
     30 
     31                               August 13, 1982
     32 
     33 
     34 
     35 
     36 
     37 
     38                                 Revised by
     39 
     40                              David H. Crocker
     41 
     42 
     43                       Dept. of Electrical Engineering
     44                  University of Delaware, Newark, DE  19711
     45                       Network:  DCrocker @ UDel-Relay
     46 
     47 
     48 
     49 
     50 
     51 
     52 
     53 
     54 
     55 
     56 
     57 
     58 
     59 
     60  
     61      Standard for ARPA Internet Text Messages
     62 
     63 
     64                              TABLE OF CONTENTS
     65 
     66 
     67      PREFACE ....................................................   ii
     68 
     69      1.  INTRODUCTION ...........................................    1
     70 
     71          1.1.  Scope ............................................    1
     72          1.2.  Communication Framework ..........................    2
     73 
     74      2.  NOTATIONAL CONVENTIONS .................................    3
     75 
     76      3.  LEXICAL ANALYSIS OF MESSAGES ...........................    5
     77 
     78          3.1.  General Description ..............................    5
     79          3.2.  Header Field Definitions .........................    9
     80          3.3.  Lexical Tokens ...................................   10
     81          3.4.  Clarifications ...................................   11
     82 
     83      4.  MESSAGE SPECIFICATION ..................................   17
     84 
     85          4.1.  Syntax ...........................................   17
     86          4.2.  Forwarding .......................................   19
     87          4.3.  Trace Fields .....................................   20
     88          4.4.  Originator Fields ................................   21
     89          4.5.  Receiver Fields ..................................   23
     90          4.6.  Reference Fields .................................   23
     91          4.7.  Other Fields .....................................   24
     92 
     93      5.  DATE AND TIME SPECIFICATION ............................   26
     94 
     95          5.1.  Syntax ...........................................   26
     96          5.2.  Semantics ........................................   26
     97 
     98      6.  ADDRESS SPECIFICATION ..................................   27
     99 
    100          6.1.  Syntax ...........................................   27
    101          6.2.  Semantics ........................................   27
    102          6.3.  Reserved Address .................................   33
    103 
    104      7.  BIBLIOGRAPHY ...........................................   34
    105 
    106 
    107                              APPENDIX
    108 
    109      A.  EXAMPLES ...............................................   36
    110      B.  SIMPLE FIELD PARSING ...................................   40
    111      C.  DIFFERENCES FROM RFC #733 ..............................   41
    112      D.  ALPHABETICAL LISTING OF SYNTAX RULES ...................   44
    113 
    114 
    115      August 13, 1982               - i -                      RFC #822
    116 
    117 
    118 
    119  
    120      Standard for ARPA Internet Text Messages
    121 
    122 
    123                                   PREFACE
    124 
    125 
    126           By 1977, the Arpanet employed several informal standards for
    127      the  text  messages (mail) sent among its host computers.  It was
    128      felt necessary to codify these practices and  provide  for  those
    129      features  that  seemed  imminent.   The result of that effort was
    130      Request for Comments (RFC) #733, "Standard for the Format of ARPA
    131      Network Text Message", by Crocker, Vittal, Pogran, and Henderson.
    132      The specification attempted to avoid major  changes  in  existing
    133      software, while permitting several new features.
    134 
    135           This document revises the specifications  in  RFC  #733,  in
    136      order  to  serve  the  needs  of the larger and more complex ARPA
    137      Internet.  Some of RFC #733's features failed  to  gain  adequate
    138      acceptance.   In  order to simplify the standard and the software
    139      that follows it, these features have been removed.   A  different
    140      addressing  scheme  is  used, to handle the case of inter-network
    141      mail; and the concept of re-transmission has been introduced.
    142 
    143           This specification is intended for use in the ARPA Internet.
    144      However, an attempt has been made to free it of any dependence on
    145      that environment, so that it can be applied to other network text
    146      message systems.
    147 
    148           The specification of RFC #733 took place over the course  of
    149      one  year, using the ARPANET mail environment, itself, to provide
    150      an on-going forum for discussing the capabilities to be included.
    151      More  than  twenty individuals, from across the country, partici-
    152      pated in  the  original  discussion.   The  development  of  this
    153      revised specification has, similarly, utilized network mail-based
    154      group discussion.  Both specification efforts  greatly  benefited
    155      from the comments and ideas of the participants.
    156 
    157           The syntax of the standard,  in  RFC  #733,  was  originally
    158      specified  in  the  Backus-Naur Form (BNF) meta-language.  Ken L.
    159      Harrenstien, of SRI International, was responsible for  re-coding
    160      the  BNF  into  an  augmented  BNF  that makes the representation
    161      smaller and easier to understand.
    162 
    163 
    164 
    165 
    166 
    167 
    168 
    169 
    170 
    171 
    172 
    173 
    174      August 13, 1982              - ii -                      RFC #822
    175 
    176 
    177  
    178      Standard for ARPA Internet Text Messages
    179 
    180 
    181      1.  INTRODUCTION
    182 
    183      1.1.  SCOPE
    184 
    185           This standard specifies a syntax for text messages that  are
    186      sent  among  computer  users, within the framework of "electronic
    187      mail".  The standard supersedes  the  one  specified  in  ARPANET
    188      Request  for Comments #733, "Standard for the Format of ARPA Net-
    189      work Text Messages".
    190 
    191           In this context, messages are viewed as having  an  envelope
    192      and  contents.   The  envelope  contains  whatever information is
    193      needed to accomplish transmission  and  delivery.   The  contents
    194      compose  the object to be delivered to the recipient.  This stan-
    195      dard applies only to the format and some of the semantics of mes-
    196      sage  contents.   It contains no specification of the information
    197      in the envelope.
    198 
    199           However, some message systems may use information  from  the
    200      contents  to create the envelope.  It is intended that this stan-
    201      dard facilitate the acquisition of such information by programs.
    202 
    203           Some message systems may  store  messages  in  formats  that
    204      differ  from the one specified in this standard.  This specifica-
    205      tion is intended strictly as a definition of what message content
    206      format is to be passed BETWEEN hosts.
    207 
    208      Note:  This standard is NOT intended to dictate the internal for-
    209             mats  used  by sites, the specific message system features
    210             that they are expected to support, or any of  the  charac-
    211             teristics  of  user interface programs that create or read
    212             messages.
    213 
    214           A distinction should be made between what the  specification
    215      REQUIRES  and  what  it ALLOWS.  Messages can be made complex and
    216      rich with formally-structured components of information or can be
    217      kept small and simple, with a minimum of such information.  Also,
    218      the standard simplifies the interpretation  of  differing  visual
    219      formats  in  messages;  only  the  visual  aspect of a message is
    220      affected and not the interpretation  of  information  within  it.
    221      Implementors may choose to retain such visual distinctions.
    222 
    223           The formal definition is divided into four levels.  The bot-
    224      tom level describes the meta-notation used in this document.  The
    225      second level describes basic lexical analyzers that  feed  tokens
    226      to  higher-level  parsers.   Next is an overall specification for
    227      messages; it permits distinguishing individual fields.   Finally,
    228      there is definition of the contents of several structured fields.
    229 
    230 
    231 
    232      August 13, 1982               - 1 -                      RFC #822
    233 
    234 
    235  
    236      Standard for ARPA Internet Text Messages
    237 
    238 
    239      1.2.  COMMUNICATION FRAMEWORK
    240 
    241           Messages consist of lines of text.   No  special  provisions
    242      are  made for encoding drawings, facsimile, speech, or structured
    243      text.  No significant consideration has been given  to  questions
    244      of  data  compression  or to transmission and storage efficiency,
    245      and the standard tends to be free with the number  of  bits  con-
    246      sumed.   For  example,  field  names  are specified as free text,
    247      rather than special terse codes.
    248 
    249           A general "memo" framework is used.  That is, a message con-
    250      sists of some information in a rigid format, followed by the main
    251      part of the message, with a format that is not specified in  this
    252      document.   The  syntax of several fields of the rigidly-formated
    253      ("headers") section is defined in  this  specification;  some  of
    254      these fields must be included in all messages.
    255 
    256           The syntax  that  distinguishes  between  header  fields  is
    257      specified  separately  from  the  internal  syntax for particular
    258      fields.  This separation is intended to allow simple  parsers  to
    259      operate on the general structure of messages, without concern for
    260      the detailed structure of individual header fields.   Appendix  B
    261      is provided to facilitate construction of these parsers.
    262 
    263           In addition to the fields specified in this document, it  is
    264      expected  that  other fields will gain common use.  As necessary,
    265      the specifications for these "extension-fields" will be published
    266      through  the same mechanism used to publish this document.  Users
    267      may also  wish  to  extend  the  set  of  fields  that  they  use
    268      privately.  Such "user-defined fields" are permitted.
    269 
    270           The framework severely constrains document tone and  appear-
    271      ance and is primarily useful for most intra-organization communi-
    272      cations and  well-structured   inter-organization  communication.
    273      It  also  can  be used for some types of inter-process communica-
    274      tion, such as simple file transfer and remote job entry.  A  more
    275      robust  framework might allow for multi-font, multi-color, multi-
    276      dimension encoding of information.  A  less  robust  one,  as  is
    277      present  in  most  single-machine  message  systems,  would  more
    278      severely constrain the ability to add fields and the decision  to
    279      include specific fields.  In contrast with paper-based communica-
    280      tion, it is interesting to note that the RECEIVER  of  a  message
    281      can   exercise  an  extraordinary  amount  of  control  over  the
    282      message's appearance.  The amount of actual control available  to
    283      message  receivers  is  contingent upon the capabilities of their
    284      individual message systems.
    285 
    286 
    287 
    288 
    289 
    290      August 13, 1982               - 2 -                      RFC #822
    291 
    292 
    293  
    294      Standard for ARPA Internet Text Messages
    295 
    296 
    297      2.  NOTATIONAL CONVENTIONS
    298 
    299           This specification uses an augmented Backus-Naur Form  (BNF)
    300      notation.  The differences from standard BNF involve naming rules
    301      and indicating repetition and "local" alternatives.
    302 
    303      2.1.  RULE NAMING
    304 
    305           Angle brackets ("<", ">") are not  used,  in  general.   The
    306      name  of  a rule is simply the name itself, rather than "<name>".
    307      Quotation-marks enclose literal text (which may be  upper  and/or
    308      lower  case).   Certain  basic  rules  are  in uppercase, such as
    309      SPACE, TAB, CRLF, DIGIT, ALPHA, etc.  Angle brackets are used  in
    310      rule  definitions,  and  in  the rest of this  document, whenever
    311      their presence will facilitate discerning the use of rule names.
    312 
    313      2.2.  RULE1 / RULE2:  ALTERNATIVES
    314 
    315           Elements separated by slash ("/") are alternatives.   There-
    316      fore "foo / bar" will accept foo or bar.
    317 
    318      2.3.  (RULE1 RULE2):  LOCAL ALTERNATIVES
    319 
    320           Elements enclosed in parentheses are  treated  as  a  single
    321      element.   Thus,  "(elem  (foo  /  bar)  elem)"  allows the token
    322      sequences "elem foo elem" and "elem bar elem".
    323 
    324      2.4.  *RULE:  REPETITION
    325 
    326           The character "*" preceding an element indicates repetition.
    327      The full form is:
    328 
    329                               <l>*<m>element
    330 
    331      indicating at least <l> and at most <m> occurrences  of  element.
    332      Default values are 0 and infinity so that "*(element)" allows any
    333      number, including zero; "1*element" requires at  least  one;  and
    334      "1*2element" allows one or two.
    335 
    336      2.5.  [RULE]:  OPTIONAL
    337 
    338           Square brackets enclose optional elements; "[foo  bar]"   is
    339      equivalent to "*1(foo bar)".
    340 
    341      2.6.  NRULE:  SPECIFIC REPETITION
    342 
    343           "<n>(element)" is equivalent to "<n>*<n>(element)"; that is,
    344      exactly  <n>  occurrences  of (element). Thus 2DIGIT is a 2-digit
    345      number, and 3ALPHA is a string of three alphabetic characters.
    346 
    347 
    348      August 13, 1982               - 3 -                      RFC #822
    349 
    350 
    351  
    352      Standard for ARPA Internet Text Messages
    353 
    354 
    355      2.7.  #RULE:  LISTS
    356 
    357           A construct "#" is defined, similar to "*", as follows:
    358 
    359                               <l>#<m>element
    360 
    361      indicating at least <l> and at most <m> elements, each  separated
    362      by  one  or more commas (","). This makes the usual form of lists
    363      very easy; a rule such as '(element *("," element))' can be shown
    364      as  "1#element".   Wherever this construct is used, null elements
    365      are allowed, but do not  contribute  to  the  count  of  elements
    366      present.   That  is,  "(element),,(element)"  is  permitted,  but
    367      counts as only two elements.  Therefore, where at least one  ele-
    368      ment  is required, at least one non-null element must be present.
    369      Default values are 0 and infinity so that "#(element)" allows any
    370      number,  including  zero;  "1#element" requires at least one; and
    371      "1#2element" allows one or two.
    372 
    373      2.8.  ; COMMENTS
    374 
    375           A semi-colon, set off some distance to  the  right  of  rule
    376      text,  starts  a comment that continues to the end of line.  This
    377      is a simple way of including useful notes in  parallel  with  the
    378      specifications.
    379 
    380 
    381 
    382 
    383 
    384 
    385 
    386 
    387 
    388 
    389 
    390 
    391 
    392 
    393 
    394 
    395 
    396 
    397 
    398 
    399 
    400 
    401 
    402 
    403 
    404 
    405 
    406      August 13, 1982               - 4 -                      RFC #822
    407 
    408 
    409  
    410      Standard for ARPA Internet Text Messages
    411 
    412 
    413      3.  LEXICAL ANALYSIS OF MESSAGES
    414 
    415      3.1.  GENERAL DESCRIPTION
    416 
    417           A message consists of header fields and, optionally, a body.
    418      The  body  is simply a sequence of lines containing ASCII charac-
    419      ters.  It is separated from the headers by a null line  (i.e.,  a
    420      line with nothing preceding the CRLF).
    421 
    422      3.1.1.  LONG HEADER FIELDS
    423 
    424         Each header field can be viewed as a single, logical  line  of
    425         ASCII  characters,  comprising  a field-name and a field-body.
    426         For convenience, the field-body  portion  of  this  conceptual
    427         entity  can be split into a multiple-line representation; this
    428         is called "folding".  The general rule is that wherever  there
    429         may  be  linear-white-space  (NOT  simply  LWSP-chars), a CRLF
    430         immediately followed by AT LEAST one LWSP-char may instead  be
    431         inserted.  Thus, the single line
    432 
    433             To:  "Joe & J. Harvey" <ddd @Org>, JJV @ BBN
    434 
    435         can be represented as:
    436 
    437             To:  "Joe & J. Harvey" <ddd @ Org>,
    438                     JJV@BBN
    439 
    440         and
    441 
    442             To:  "Joe & J. Harvey"
    443                             <ddd@ Org>, JJV
    444              @BBN
    445 
    446         and
    447 
    448             To:  "Joe &
    449              J. Harvey" <ddd @ Org>, JJV @ BBN
    450 
    451              The process of moving  from  this  folded   multiple-line
    452         representation  of a header field to its single line represen-
    453         tation is called "unfolding".  Unfolding  is  accomplished  by
    454         regarding   CRLF   immediately  followed  by  a  LWSP-char  as
    455         equivalent to the LWSP-char.
    456 
    457         Note:  While the standard  permits  folding  wherever  linear-
    458                white-space is permitted, it is recommended that struc-
    459                tured fields, such as those containing addresses, limit
    460                folding  to higher-level syntactic breaks.  For address
    461                fields, it  is  recommended  that  such  folding  occur
    462 
    463 
    464      August 13, 1982               - 5 -                      RFC #822
    465 
    466 
    467  
    468      Standard for ARPA Internet Text Messages
    469 
    470 
    471                between addresses, after the separating comma.
    472 
    473      3.1.2.  STRUCTURE OF HEADER FIELDS
    474 
    475         Once a field has been unfolded, it may be viewed as being com-
    476         posed of a field-name followed by a colon (":"), followed by a
    477         field-body, and  terminated  by  a  carriage-return/line-feed.
    478         The  field-name must be composed of printable ASCII characters
    479         (i.e., characters that  have  values  between  33.  and  126.,
    480         decimal, except colon).  The field-body may be composed of any
    481         ASCII characters, except CR or LF.  (While CR and/or LF may be
    482         present  in the actual text, they are removed by the action of
    483         unfolding the field.)
    484 
    485         Certain field-bodies of headers may be  interpreted  according
    486         to  an  internal  syntax  that some systems may wish to parse.
    487         These  fields  are  called  "structured   fields".    Examples
    488         include  fields containing dates and addresses.  Other fields,
    489         such as "Subject"  and  "Comments",  are  regarded  simply  as
    490         strings of text.
    491 
    492         Note:  Any field which has a field-body  that  is  defined  as
    493                other  than  simply <text> is to be treated as a struc-
    494                tured field.
    495 
    496                Field-names, unstructured field bodies  and  structured
    497                field bodies each are scanned by their own, independent
    498                "lexical" analyzers.
    499 
    500      3.1.3.  UNSTRUCTURED FIELD BODIES
    501 
    502         For some fields, such as "Subject" and "Comments",  no  struc-
    503         turing  is assumed, and they are treated simply as <text>s, as
    504         in the message body.  Rules of folding apply to these  fields,
    505         so  that  such  field  bodies  which occupy several lines must
    506         therefore have the second and successive lines indented by  at
    507         least one LWSP-char.
    508 
    509      3.1.4.  STRUCTURED FIELD BODIES
    510 
    511         To aid in the creation and reading of structured  fields,  the
    512         free  insertion   of linear-white-space (which permits folding
    513         by inclusion of CRLFs)  is  allowed  between  lexical  tokens.
    514         Rather  than  obscuring  the  syntax  specifications for these
    515         structured fields with explicit syntax for this  linear-white-
    516         space, the existence of another "lexical" analyzer is assumed.
    517         This analyzer does not apply  for  unstructured  field  bodies
    518         that  are  simply  strings  of  text, as described above.  The
    519         analyzer provides  an  interpretation  of  the  unfolded  text
    520 
    521 
    522      August 13, 1982               - 6 -                      RFC #822
    523 
    524 
    525  
    526      Standard for ARPA Internet Text Messages
    527 
    528 
    529         composing  the body of the field as a sequence of lexical sym-
    530         bols.
    531 
    532         These symbols are:
    533 
    534                      -  individual special characters
    535                      -  quoted-strings
    536                      -  domain-literals
    537                      -  comments
    538                      -  atoms
    539 
    540         The first four of these symbols  are  self-delimiting.   Atoms
    541         are not; they are delimited by the self-delimiting symbols and
    542         by  linear-white-space.   For  the  purposes  of  regenerating
    543         sequences  of  atoms  and quoted-strings, exactly one SPACE is
    544         assumed to exist, and should be used, between them.  (Also, in
    545         the "Clarifications" section on "White Space", below, note the
    546         rules about treatment of multiple contiguous LWSP-chars.)
    547 
    548         So, for example, the folded body of an address field
    549 
    550             ":sysmail"@  Some-Group. Some-Org,
    551             Muhammed.(I am  the greatest) Ali @(the)Vegas.WBA
    552 
    553 
    554 
    555 
    556 
    557 
    558 
    559 
    560 
    561 
    562 
    563 
    564 
    565 
    566 
    567 
    568 
    569 
    570 
    571 
    572 
    573 
    574 
    575 
    576 
    577 
    578 
    579 
    580      August 13, 1982               - 7 -                      RFC #822
    581 
    582 
    583  
    584      Standard for ARPA Internet Text Messages
    585 
    586 
    587         is analyzed into the following lexical symbols and types:
    588 
    589                     :sysmail              quoted string
    590                     @                     special
    591                     Some-Group            atom
    592                     .                     special
    593                     Some-Org              atom
    594                     ,                     special
    595                     Muhammed              atom
    596                     .                     special
    597                     (I am  the greatest)  comment
    598                     Ali                   atom
    599                     @                     atom
    600                     (the)                 comment
    601                     Vegas                 atom
    602                     .                     special
    603                     WBA                   atom
    604 
    605         The canonical representations for the data in these  addresses
    606         are the following strings:
    607 
    608                         ":sysmail"@Some-Group.Some-Org
    609 
    610         and
    611 
    612                             Muhammed.Ali@Vegas.WBA
    613 
    614         Note:  For purposes of display, and when passing  such  struc-
    615                tured information to other systems, such as mail proto-
    616                col  services,  there  must  be  NO  linear-white-space
    617                between  <word>s  that are separated by period (".") or
    618                at-sign ("@") and exactly one SPACE between  all  other
    619                <word>s.  Also, headers should be in a folded form.
    620 
    621 
    622 
    623 
    624 
    625 
    626 
    627 
    628 
    629 
    630 
    631 
    632 
    633 
    634 
    635 
    636 
    637 
    638      August 13, 1982               - 8 -                      RFC #822
    639 
    640 
    641  
    642      Standard for ARPA Internet Text Messages
    643 
    644 
    645      3.2.  HEADER FIELD DEFINITIONS
    646 
    647           These rules show a field meta-syntax, without regard for the
    648      particular  type  or internal syntax.  Their purpose is to permit
    649      detection of fields; also, they present to  higher-level  parsers
    650      an image of each field as fitting on one line.
    651 
    652      field       =  field-name ":" [ field-body ] CRLF
    653 
    654      field-name  =  1*<any CHAR, excluding CTLs, SPACE, and ":">
    655 
    656      field-body  =  field-body-contents
    657                     [CRLF LWSP-char field-body]
    658 
    659      field-body-contents =
    660                    <the ASCII characters making up the field-body, as
    661                     defined in the following sections, and consisting
    662                     of combinations of atom, quoted-string, and
    663                     specials tokens, or else consisting of texts>
    664 
    665 
    666 
    667 
    668 
    669 
    670 
    671 
    672 
    673 
    674 
    675 
    676 
    677 
    678 
    679 
    680 
    681 
    682 
    683 
    684 
    685 
    686 
    687 
    688 
    689 
    690 
    691 
    692 
    693 
    694 
    695 
    696      August 13, 1982               - 9 -                      RFC #822
    697 
    698 
    699  
    700      Standard for ARPA Internet Text Messages
    701 
    702 
    703      3.3.  LEXICAL TOKENS
    704 
    705           The following rules are used to define an underlying lexical
    706      analyzer,  which  feeds  tokens to higher level parsers.  See the
    707      ANSI references, in the Bibliography.
    708 
    709                                                  ; (  Octal, Decimal.)
    710      CHAR        =  <any ASCII character>        ; (  0-177,  0.-127.)
    711      ALPHA       =  <any ASCII alphabetic character>
    712                                                  ; (101-132, 65.- 90.)
    713                                                  ; (141-172, 97.-122.)
    714      DIGIT       =  <any ASCII decimal digit>    ; ( 60- 71, 48.- 57.)
    715      CTL         =  <any ASCII control           ; (  0- 37,  0.- 31.)
    716                      character and DEL>          ; (    177,     127.)
    717      CR          =  <ASCII CR, carriage return>  ; (     15,      13.)
    718      LF          =  <ASCII LF, linefeed>         ; (     12,      10.)
    719      SPACE       =  <ASCII SP, space>            ; (     40,      32.)
    720      HTAB        =  <ASCII HT, horizontal-tab>   ; (     11,       9.)
    721      <">         =  <ASCII quote mark>           ; (     42,      34.)
    722      CRLF        =  CR LF
    723 
    724      LWSP-char   =  SPACE / HTAB                 ; semantics = SPACE
    725 
    726      linear-white-space =  1*([CRLF] LWSP-char)  ; semantics = SPACE
    727                                                  ; CRLF => folding
    728 
    729      specials    =  "(" / ")" / "<" / ">" / "@"  ; Must be in quoted-
    730                  /  "," / ";" / ":" / "\" / <">  ;  string, to use
    731                  /  "." / "[" / "]"              ;  within a word.
    732 
    733      delimiters  =  specials / linear-white-space / comment
    734 
    735      text        =  <any CHAR, including bare    ; => atoms, specials,
    736                      CR & bare LF, but NOT       ;  comments and
    737                      including CRLF>             ;  quoted-strings are
    738                                                  ;  NOT recognized.
    739 
    740      atom        =  1*<any CHAR except specials, SPACE and CTLs>
    741 
    742      quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or
    743                                                  ;   quoted chars.
    744 
    745      qtext       =  <any CHAR excepting <">,     ; => may be folded
    746                      "\" & CR, and including
    747                      linear-white-space>
    748 
    749      domain-literal =  "[" *(dtext / quoted-pair) "]"
    750 
    751 
    752 
    753 
    754      August 13, 1982              - 10 -                      RFC #822
    755 
    756 
    757  
    758      Standard for ARPA Internet Text Messages
    759 
    760 
    761      dtext       =  <any CHAR excluding "[",     ; => may be folded
    762                      "]", "\" & CR, & including
    763                      linear-white-space>
    764 
    765      comment     =  "(" *(ctext / quoted-pair / comment) ")"
    766 
    767      ctext       =  <any CHAR excluding "(",     ; => may be folded
    768                      ")", "\" & CR, & including
    769                      linear-white-space>
    770 
    771      quoted-pair =  "\" CHAR                     ; may quote any char
    772 
    773      phrase      =  1*word                       ; Sequence of words
    774 
    775      word        =  atom / quoted-string
    776 
    777 
    778      3.4.  CLARIFICATIONS
    779 
    780      3.4.1.  QUOTING
    781 
    782         Some characters are reserved for special interpretation,  such
    783         as  delimiting lexical tokens.  To permit use of these charac-
    784         ters as uninterpreted data, a quoting mechanism  is  provided.
    785         To quote a character, precede it with a backslash ("\").
    786 
    787         This mechanism is not fully general.  Characters may be quoted
    788         only  within  a subset of the lexical constructs.  In particu-
    789         lar, quoting is limited to use within:
    790 
    791                              -  quoted-string
    792                              -  domain-literal
    793                              -  comment
    794 
    795         Within these constructs, quoting is REQUIRED for  CR  and  "\"
    796         and for the character(s) that delimit the token (e.g., "(" and
    797         ")" for a comment).  However, quoting  is  PERMITTED  for  any
    798         character.
    799 
    800         Note:  In particular, quoting is NOT permitted  within  atoms.
    801                For  example  when  the local-part of an addr-spec must
    802                contain a special character, a quoted  string  must  be
    803                used.  Therefore, a specification such as:
    804 
    805                             Full\ Name@Domain
    806 
    807                is not legal and must be specified as:
    808 
    809                             "Full Name"@Domain
    810 
    811 
    812      August 13, 1982              - 11 -                      RFC #822
    813 
    814 
    815  
    816      Standard for ARPA Internet Text Messages
    817 
    818 
    819      3.4.2.  WHITE SPACE
    820 
    821         Note:  In structured field bodies, multiple linear space ASCII
    822                characters  (namely  HTABs  and  SPACEs) are treated as
    823                single spaces and may freely surround any  symbol.   In
    824                all header fields, the only place in which at least one
    825                LWSP-char is REQUIRED is at the beginning of  continua-
    826                tion lines in a folded field.
    827 
    828         When passing text to processes  that  do  not  interpret  text
    829         according to this standard (e.g., mail protocol servers), then
    830         NO linear-white-space characters should occur between a period
    831         (".") or at-sign ("@") and a <word>.  Exactly ONE SPACE should
    832         be used in place of arbitrary linear-white-space  and  comment
    833         sequences.
    834 
    835         Note:  Within systems conforming to this standard, wherever  a
    836                member of the list of delimiters is allowed, LWSP-chars
    837                may also occur before and/or after it.
    838 
    839         Writers of  mail-sending  (i.e.,  header-generating)  programs
    840         should realize that there is no network-wide definition of the
    841         effect of ASCII HT (horizontal-tab) characters on the  appear-
    842         ance  of  text  at another network host; therefore, the use of
    843         tabs in message headers, though permitted, is discouraged.
    844 
    845      3.4.3.  COMMENTS
    846 
    847         A comment is a set of ASCII characters, which is  enclosed  in
    848         matching  parentheses  and which is not within a quoted-string
    849         The comment construct permits message originators to add  text
    850         which  will  be  useful  for  human readers, but which will be
    851         ignored by the formal semantics.  Comments should be  retained
    852         while  the  message  is subject to interpretation according to
    853         this standard.  However, comments  must  NOT  be  included  in
    854         other  cases,  such  as  during  protocol  exchanges with mail
    855         servers.
    856 
    857         Comments nest, so that if an unquoted left parenthesis  occurs
    858         in  a  comment  string,  there  must  also be a matching right
    859         parenthesis.  When a comment acts as the delimiter  between  a
    860         sequence of two lexical symbols, such as two atoms, it is lex-
    861         ically equivalent with a single SPACE,  for  the  purposes  of
    862         regenerating  the  sequence, such as when passing the sequence
    863         onto a mail protocol server.  Comments are  detected  as  such
    864         only within field-bodies of structured fields.
    865 
    866         If a comment is to be "folded" onto multiple lines,  then  the
    867         syntax  for  folding  must  be  adhered to.  (See the "Lexical
    868 
    869 
    870      August 13, 1982              - 12 -                      RFC #822
    871 
    872 
    873  
    874      Standard for ARPA Internet Text Messages
    875 
    876 
    877         Analysis of Messages" section on "Folding Long Header  Fields"
    878         above,  and  the  section on "Case Independence" below.)  Note
    879         that  the  official  semantics  therefore  do  not  "see"  any
    880         unquoted CRLFs that are in comments, although particular pars-
    881         ing programs may wish to note their presence.  For these  pro-
    882         grams,  it would be reasonable to interpret a "CRLF LWSP-char"
    883         as being a CRLF that is part of the comment; i.e., the CRLF is
    884         kept  and  the  LWSP-char is discarded.  Quoted CRLFs (i.e., a
    885         backslash followed by a CR followed by a  LF)  still  must  be
    886         followed by at least one LWSP-char.
    887 
    888      3.4.4.  DELIMITING AND QUOTING CHARACTERS
    889 
    890         The quote character (backslash) and  characters  that  delimit
    891         syntactic  units  are not, generally, to be taken as data that
    892         are part of the delimited or quoted unit(s).   In  particular,
    893         the   quotation-marks   that   define   a  quoted-string,  the
    894         parentheses that define  a  comment  and  the  backslash  that
    895         quotes  a  following  character  are  NOT  part of the quoted-
    896         string, comment or quoted character.  A quotation-mark that is
    897         to  be  part  of  a quoted-string, a parenthesis that is to be
    898         part of a comment and a backslash that is to be part of either
    899         must  each be preceded by the quote-character backslash ("\").
    900         Note that the syntax allows any character to be quoted  within
    901         a  quoted-string  or  comment; however only certain characters
    902         MUST be quoted to be included as data.  These  characters  are
    903         the  ones that are not part of the alternate text group (i.e.,
    904         ctext or qtext).
    905 
    906         The one exception to this rule  is  that  a  single  SPACE  is
    907         assumed  to  exist  between  contiguous words in a phrase, and
    908         this interpretation is independent of  the  actual  number  of
    909         LWSP-chars  that  the  creator  places  between the words.  To
    910         include more than one SPACE, the creator must make  the  LWSP-
    911         chars be part of a quoted-string.
    912 
    913         Quotation marks that delimit a quoted string  and  backslashes
    914         that  quote  the  following character should NOT accompany the
    915         quoted-string when the string is passed to processes  that  do
    916         not interpret data according to this specification (e.g., mail
    917         protocol servers).
    918 
    919      3.4.5.  QUOTED-STRINGS
    920 
    921         Where permitted (i.e., in words in structured fields)  quoted-
    922         strings  are  treated  as a single symbol.  That is, a quoted-
    923         string is equivalent to an atom, syntactically.  If a  quoted-
    924         string  is to be "folded" onto multiple lines, then the syntax
    925         for folding must be adhered to.  (See the "Lexical Analysis of
    926 
    927 
    928      August 13, 1982              - 13 -                      RFC #822
    929 
    930 
    931  
    932      Standard for ARPA Internet Text Messages
    933 
    934 
    935         Messages"  section  on "Folding Long Header Fields" above, and
    936         the section on "Case  Independence"  below.)   Therefore,  the
    937         official  semantics  do  not  "see" any bare CRLFs that are in
    938         quoted-strings; however particular parsing programs  may  wish
    939         to  note  their presence.  For such programs, it would be rea-
    940         sonable to interpret a "CRLF LWSP-char" as being a CRLF  which
    941         is  part  of the quoted-string; i.e., the CRLF is kept and the
    942         LWSP-char is discarded.  Quoted CRLFs (i.e., a backslash  fol-
    943         lowed  by  a CR followed by a LF) are also subject to rules of
    944         folding, but the presence of the quoting character (backslash)
    945         explicitly  indicates  that  the  CRLF  is  data to the quoted
    946         string.  Stripping off the first following LWSP-char  is  also
    947         appropriate when parsing quoted CRLFs.
    948 
    949      3.4.6.  BRACKETING CHARACTERS
    950 
    951         There is one type of bracket which must occur in matched pairs
    952         and may have pairs nested within each other:
    953 
    954             o   Parentheses ("(" and ")") are used  to  indicate  com-
    955                 ments.
    956 
    957         There are three types of brackets which must occur in  matched
    958         pairs, and which may NOT be nested:
    959 
    960             o   Colon/semi-colon (":" and ";") are   used  in  address
    961                 specifications  to  indicate that the included list of
    962                 addresses are to be treated as a group.
    963 
    964             o   Angle brackets ("<" and ">")  are  generally  used  to
    965                 indicate  the  presence of a one machine-usable refer-
    966                 ence (e.g., delimiting mailboxes), possibly  including
    967                 source-routing to the machine.
    968 
    969             o   Square brackets ("[" and "]") are used to indicate the
    970                 presence  of  a  domain-literal, which the appropriate
    971                 name-domain  is  to  use  directly,  bypassing  normal
    972                 name-resolution mechanisms.
    973 
    974      3.4.7.  CASE INDEPENDENCE
    975 
    976         Except as noted, alphabetic strings may be represented in  any
    977         combination of upper and lower case.  The only syntactic units
    978 
    979 
    980 
    981 
    982 
    983 
    984 
    985 
    986      August 13, 1982              - 14 -                      RFC #822
    987 
    988 
    989  
    990      Standard for ARPA Internet Text Messages
    991 
    992 
    993         which requires preservation of case information are:
    994 
    995                     -  text
    996                     -  qtext
    997                     -  dtext
    998                     -  ctext
    999                     -  quoted-pair
   1000                     -  local-part, except "Postmaster"
   1001 
   1002         When matching any other syntactic unit, case is to be ignored.
   1003         For  example, the field-names "From", "FROM", "from", and even
   1004         "FroM" are semantically equal and should all be treated ident-
   1005         ically.
   1006 
   1007         When generating these units, any mix of upper and  lower  case
   1008         alphabetic  characters  may  be  used.  The case shown in this
   1009         specification is suggested for message-creating processes.
   1010 
   1011         Note:  The reserved local-part address unit, "Postmaster",  is
   1012                an  exception.   When  the  value "Postmaster" is being
   1013                interpreted, it must be  accepted  in  any  mixture  of
   1014                case, including "POSTMASTER", and "postmaster".
   1015 
   1016      3.4.8.  FOLDING LONG HEADER FIELDS
   1017 
   1018         Each header field may be represented on exactly one line  con-
   1019         sisting  of the name of the field and its body, and terminated
   1020         by a CRLF; this is what the parser sees.  For readability, the
   1021         field-body  portion of long header fields may be "folded" onto
   1022         multiple lines of the actual field.  "Long" is commonly inter-
   1023         preted  to  mean greater than 65 or 72 characters.  The former
   1024         length serves as a limit, when the message is to be viewed  on
   1025         most  simple terminals which use simple display software; how-
   1026         ever, the limit is not imposed by this standard.
   1027 
   1028         Note:  Some display software often can selectively fold lines,
   1029                to  suit  the display terminal.  In such cases, sender-
   1030                provided  folding  can  interfere  with   the   display
   1031                software.
   1032 
   1033      3.4.9.  BACKSPACE CHARACTERS
   1034 
   1035         ASCII BS characters (Backspace, decimal 8) may be included  in
   1036         texts and quoted-strings to effect overstriking.  However, any
   1037         use of backspaces which effects an overstrike to the  left  of
   1038         the beginning of the text or quoted-string is prohibited.
   1039 
   1040 
   1041 
   1042 
   1043 
   1044      August 13, 1982              - 15 -                      RFC #822
   1045 
   1046 
   1047  
   1048      Standard for ARPA Internet Text Messages
   1049 
   1050 
   1051      3.4.10.  NETWORK-SPECIFIC TRANSFORMATIONS
   1052 
   1053         During transmission through heterogeneous networks, it may  be
   1054         necessary  to  force data to conform to a network's local con-
   1055         ventions.  For example, it may be required that a CR  be  fol-
   1056         lowed  either by LF, making a CRLF, or by <null>, if the CR is
   1057         to stand alone).  Such transformations are reversed, when  the
   1058         message exits that network.
   1059 
   1060         When  crossing  network  boundaries,  the  message  should  be
   1061         treated  as  passing  through  two modules.  It will enter the
   1062         first module containing whatever network-specific  transforma-
   1063         tions  that  were  necessary  to  permit migration through the
   1064         "current" network.  It then passes through the modules:
   1065 
   1066             o   Transformation Reversal
   1067 
   1068                 The "current" network's idiosyncracies are removed and
   1069                 the  message  is returned to the canonical form speci-
   1070                 fied in this standard.
   1071 
   1072             o   Transformation
   1073 
   1074                 The "next" network's local idiosyncracies are  imposed
   1075                 on the message.
   1076 
   1077                                 ------------------
   1078                     From   ==>  | Remove Net-A   |
   1079                     Net-A       | idiosyncracies |
   1080                                 ------------------
   1081                                        ||
   1082                                        \/
   1083                                   Conformance
   1084                                   with standard
   1085                                        ||
   1086                                        \/
   1087                                 ------------------
   1088                                 | Impose Net-B   |  ==>  To
   1089                                 | idiosyncracies |       Net-B
   1090                                 ------------------
   1091 
   1092 
   1093 
   1094 
   1095 
   1096 
   1097 
   1098 
   1099 
   1100 
   1101 
   1102      August 13, 1982              - 16 -                      RFC #822
   1103 
   1104 
   1105  
   1106      Standard for ARPA Internet Text Messages
   1107 
   1108 
   1109      4.  MESSAGE SPECIFICATION
   1110 
   1111      4.1.  SYNTAX
   1112 
   1113      Note:  Due to an artifact of the notational conventions, the syn-
   1114             tax  indicates that, when present, some fields, must be in
   1115             a particular order.  Header fields  are  NOT  required  to
   1116             occur  in  any  particular  order, except that the message
   1117             body must occur AFTER  the  headers.   It  is  recommended
   1118             that,  if  present,  headers be sent in the order "Return-
   1119             Path", "Received", "Date",  "From",  "Subject",  "Sender",
   1120             "To", "cc", etc.
   1121 
   1122             This specification permits multiple  occurrences  of  most
   1123             fields.   Except  as  noted,  their  interpretation is not
   1124             specified here, and their use is discouraged.
   1125 
   1126           The following syntax for the bodies of various fields should
   1127      be  thought  of  as  describing  each field body as a single long
   1128      string (or line).  The "Lexical Analysis of Message"  section  on
   1129      "Long  Header Fields", above, indicates how such long strings can
   1130      be represented on more than one line in  the  actual  transmitted
   1131      message.
   1132 
   1133      message     =  fields *( CRLF *text )       ; Everything after
   1134                                                  ;  first null line
   1135                                                  ;  is message body
   1136 
   1137      fields      =    dates                      ; Creation time,
   1138                       source                     ;  author id & one
   1139                     1*destination                ;  address required
   1140                      *optional-field             ;  others optional
   1141 
   1142      source      = [  trace ]                    ; net traversals
   1143                       originator                 ; original mail
   1144                    [  resent ]                   ; forwarded
   1145 
   1146      trace       =    return                     ; path to sender
   1147                     1*received                   ; receipt tags
   1148 
   1149      return      =  "Return-path" ":" route-addr ; return address
   1150 
   1151      received    =  "Received"    ":"            ; one per relay
   1152                        ["from" domain]           ; sending host
   1153                        ["by"   domain]           ; receiving host
   1154                        ["via"  atom]             ; physical path
   1155                       *("with" atom)             ; link/mail protocol
   1156                        ["id"   msg-id]           ; receiver msg id
   1157                        ["for"  addr-spec]        ; initial form
   1158 
   1159 
   1160      August 13, 1982              - 17 -                      RFC #822
   1161 
   1162 
   1163  
   1164      Standard for ARPA Internet Text Messages
   1165 
   1166 
   1167                         ";"    date-time         ; time received
   1168 
   1169      originator  =   authentic                   ; authenticated addr
   1170                    [ "Reply-To"   ":" 1#address] )
   1171 
   1172      authentic   =   "From"       ":"   mailbox  ; Single author
   1173                  / ( "Sender"     ":"   mailbox  ; Actual submittor
   1174                      "From"       ":" 1#mailbox) ; Multiple authors
   1175                                                  ;  or not sender
   1176 
   1177      resent      =   resent-authentic
   1178                    [ "Resent-Reply-To"  ":" 1#address] )
   1179 
   1180      resent-authentic =
   1181                  =   "Resent-From"      ":"   mailbox
   1182                  / ( "Resent-Sender"    ":"   mailbox
   1183                      "Resent-From"      ":" 1#mailbox  )
   1184 
   1185      dates       =   orig-date                   ; Original
   1186                    [ resent-date ]               ; Forwarded
   1187 
   1188      orig-date   =  "Date"        ":"   date-time
   1189 
   1190      resent-date =  "Resent-Date" ":"   date-time
   1191 
   1192      destination =  "To"          ":" 1#address  ; Primary
   1193                  /  "Resent-To"   ":" 1#address
   1194                  /  "cc"          ":" 1#address  ; Secondary
   1195                  /  "Resent-cc"   ":" 1#address
   1196                  /  "bcc"         ":"  #address  ; Blind carbon
   1197                  /  "Resent-bcc"  ":"  #address
   1198 
   1199      optional-field =
   1200                  /  "Message-ID"        ":"   msg-id
   1201                  /  "Resent-Message-ID" ":"   msg-id
   1202                  /  "In-Reply-To"       ":"  *(phrase / msg-id)
   1203                  /  "References"        ":"  *(phrase / msg-id)
   1204                  /  "Keywords"          ":"  #phrase
   1205                  /  "Subject"           ":"  *text
   1206                  /  "Comments"          ":"  *text
   1207                  /  "Encrypted"         ":" 1#2word
   1208                  /  extension-field              ; To be defined
   1209                  /  user-defined-field           ; May be pre-empted
   1210 
   1211      msg-id      =  "<" addr-spec ">"            ; Unique message id
   1212 
   1213 
   1214 
   1215 
   1216 
   1217 
   1218      August 13, 1982              - 18 -                      RFC #822
   1219 
   1220 
   1221  
   1222      Standard for ARPA Internet Text Messages
   1223 
   1224 
   1225      extension-field =
   1226                    <Any field which is defined in a document
   1227                     published as a formal extension to this
   1228                     specification; none will have names beginning
   1229                     with the string "X-">
   1230 
   1231      user-defined-field =
   1232                    <Any field which has not been defined
   1233                     in this specification or published as an
   1234                     extension to this specification; names for
   1235                     such fields must be unique and may be
   1236                     pre-empted by published extensions>
   1237 
   1238      4.2.  FORWARDING
   1239 
   1240           Some systems permit mail recipients to  forward  a  message,
   1241      retaining  the original headers, by adding some new fields.  This
   1242      standard supports such a service, through the "Resent-" prefix to
   1243      field names.
   1244 
   1245           Whenever the string "Resent-" begins a field name, the field
   1246      has  the  same  semantics as a field whose name does not have the
   1247      prefix.  However, the message is assumed to have  been  forwarded
   1248      by  an original recipient who attached the "Resent-" field.  This
   1249      new field is treated as being more recent  than  the  equivalent,
   1250      original  field.   For  example, the "Resent-From", indicates the
   1251      person that forwarded the message, whereas the "From" field indi-
   1252      cates the original author.
   1253 
   1254           Use of such precedence  information  depends  upon  partici-
   1255      pants'  communication needs.  For example, this standard does not
   1256      dictate when a "Resent-From:" address should receive replies,  in
   1257      lieu of sending them to the "From:" address.
   1258 
   1259      Note:  In general, the "Resent-" fields should be treated as con-
   1260             taining  a  set  of information that is independent of the
   1261             set of original fields.  Information for  one  set  should
   1262             not  automatically be taken from the other.  The interpre-
   1263             tation of multiple "Resent-" fields, of the same type,  is
   1264             undefined.
   1265 
   1266           In the remainder of this specification, occurrence of  legal
   1267      "Resent-"  fields  are treated identically with the occurrence of
   1268 
   1269 
   1270 
   1271 
   1272 
   1273 
   1274 
   1275 
   1276      August 13, 1982              - 19 -                      RFC #822
   1277 
   1278 
   1279  
   1280      Standard for ARPA Internet Text Messages
   1281 
   1282 
   1283      fields whose names do not contain this prefix.
   1284 
   1285      4.3.  TRACE FIELDS
   1286 
   1287           Trace information is used to provide an audit trail of  mes-
   1288      sage  handling.   In  addition,  it indicates a route back to the
   1289      sender of the message.
   1290 
   1291           The list of known "via" and  "with"  values  are  registered
   1292      with  the  Network  Information  Center, SRI International, Menlo
   1293      Park, California.
   1294 
   1295      4.3.1.  RETURN-PATH
   1296 
   1297         This field  is  added  by  the  final  transport  system  that
   1298         delivers  the message to its recipient.  The field is intended
   1299         to contain definitive information about the address and  route
   1300         back to the message's originator.
   1301 
   1302         Note:  The "Reply-To" field is added  by  the  originator  and
   1303                serves  to  direct  replies,  whereas the "Return-Path"
   1304                field is used to identify a path back to  the  origina-
   1305                tor.
   1306 
   1307         While the syntax  indicates  that  a  route  specification  is
   1308         optional,  every attempt should be made to provide that infor-
   1309         mation in this field.
   1310 
   1311      4.3.2.  RECEIVED
   1312 
   1313         A copy of this field is added by each transport  service  that
   1314         relays the message.  The information in the field can be quite
   1315         useful for tracing transport problems.
   1316 
   1317         The names of the sending  and  receiving  hosts  and  time-of-
   1318         receipt may be specified.  The "via" parameter may be used, to
   1319         indicate what physical mechanism the message  was  sent  over,
   1320         such  as  Arpanet or Phonenet, and the "with" parameter may be
   1321         used to indicate the mail-,  or  connection-,  level  protocol
   1322         that  was  used, such as the SMTP mail protocol, or X.25 tran-
   1323         sport protocol.
   1324 
   1325         Note:  Several "with" parameters may  be  included,  to  fully
   1326                specify the set of protocols that were used.
   1327 
   1328         Some transport services queue mail; the internal message iden-
   1329         tifier that is assigned to the message may be noted, using the
   1330         "id" parameter.  When the  sending  host  uses  a  destination
   1331         address specification that the receiving host reinterprets, by
   1332 
   1333 
   1334      August 13, 1982              - 20 -                      RFC #822
   1335 
   1336 
   1337  
   1338      Standard for ARPA Internet Text Messages
   1339 
   1340 
   1341         expansion or transformation, the receiving host  may  wish  to
   1342         record  the original specification, using the "for" parameter.
   1343         For example, when a copy of mail is sent to the  member  of  a
   1344         distribution  list,  this  parameter may be used to record the
   1345         original address that was used to specify the list.
   1346 
   1347      4.4.  ORIGINATOR FIELDS
   1348 
   1349           The standard allows only a subset of the combinations possi-
   1350      ble  with the From, Sender, Reply-To, Resent-From, Resent-Sender,
   1351      and Resent-Reply-To fields.  The limitation is intentional.
   1352 
   1353      4.4.1.  FROM / RESENT-FROM
   1354 
   1355         This field contains the identity of the person(s)  who  wished
   1356         this  message to be sent.  The message-creation process should
   1357         default this field  to  be  a  single,  authenticated  machine
   1358         address,  indicating  the  AGENT  (person,  system or process)
   1359         entering the message.  If this is not done, the "Sender" field
   1360         MUST  be  present.  If the "From" field IS defaulted this way,
   1361         the "Sender" field is  optional  and  is  redundant  with  the
   1362         "From"  field.   In  all  cases, addresses in the "From" field
   1363         must be machine-usable (addr-specs) and may not contain  named
   1364         lists (groups).
   1365 
   1366      4.4.2.  SENDER / RESENT-SENDER
   1367 
   1368         This field contains the authenticated identity  of  the  AGENT
   1369         (person,  system  or  process)  that sends the message.  It is
   1370         intended for use when the sender is not the author of the mes-
   1371         sage,  or  to  indicate  who among a group of authors actually
   1372         sent the message.  If the contents of the "Sender" field would
   1373         be  completely  redundant  with  the  "From"  field,  then the
   1374         "Sender" field need not be present and its use is  discouraged
   1375         (though  still legal).  In particular, the "Sender" field MUST
   1376         be present if it is NOT the same as the "From" Field.
   1377 
   1378         The Sender mailbox  specification  includes  a  word  sequence
   1379         which  must correspond to a specific agent (i.e., a human user
   1380         or a computer program) rather than a standard  address.   This
   1381         indicates  the  expectation  that  the field will identify the
   1382         single AGENT (person,  system,  or  process)  responsible  for
   1383         sending  the mail and not simply include the name of a mailbox
   1384         from which the mail was sent.  For example in the  case  of  a
   1385         shared login name, the name, by itself, would not be adequate.
   1386         The local-part address unit, which refers to  this  agent,  is
   1387         expected to be a computer system term, and not (for example) a
   1388         generalized person reference which can  be  used  outside  the
   1389         network text message context.
   1390 
   1391 
   1392      August 13, 1982              - 21 -                      RFC #822
   1393 
   1394 
   1395  
   1396      Standard for ARPA Internet Text Messages
   1397 
   1398 
   1399         Since the critical function served by the  "Sender"  field  is
   1400         identification  of  the agent responsible for sending mail and
   1401         since computer programs cannot be held accountable  for  their
   1402         behavior, it is strongly recommended that when a computer pro-
   1403         gram generates a message, the HUMAN  who  is  responsible  for
   1404         that program be referenced as part of the "Sender" field mail-
   1405         box specification.
   1406 
   1407      4.4.3.  REPLY-TO / RESENT-REPLY-TO
   1408 
   1409         This field provides a general  mechanism  for  indicating  any
   1410         mailbox(es)  to which responses are to be sent.  Three typical
   1411         uses for this feature can  be  distinguished.   In  the  first
   1412         case,  the  author(s) may not have regular machine-based mail-
   1413         boxes and therefore wish(es) to indicate an alternate  machine
   1414         address.   In  the  second case, an author may wish additional
   1415         persons to be made aware of, or responsible for,  replies.   A
   1416         somewhat  different  use  may be of some help to "text message
   1417         teleconferencing" groups equipped with automatic  distribution
   1418         services:   include the address of that service in the "Reply-
   1419         To" field of all messages  submitted  to  the  teleconference;
   1420         then  participants  can  "reply"  to conference submissions to
   1421         guarantee the correct distribution of any submission of  their
   1422         own.
   1423 
   1424         Note:  The "Return-Path" field is added by the mail  transport
   1425                service,  at the time of final deliver.  It is intended
   1426                to identify a path back to the orginator  of  the  mes-
   1427                sage.   The  "Reply-To"  field  is added by the message
   1428                originator and is intended to direct replies.
   1429 
   1430      4.4.4.  AUTOMATIC USE OF FROM / SENDER / REPLY-TO
   1431 
   1432         For systems which automatically  generate  address  lists  for
   1433         replies to messages, the following recommendations are made:
   1434 
   1435             o   The "Sender" field mailbox should be sent  notices  of
   1436                 any  problems in transport or delivery of the original
   1437                 messages.  If there is no  "Sender"  field,  then  the
   1438                 "From" field mailbox should be used.
   1439 
   1440             o   The  "Sender"  field  mailbox  should  NEVER  be  used
   1441                 automatically, in a recipient's reply message.
   1442 
   1443             o   If the "Reply-To" field exists, then the reply  should
   1444                 go to the addresses indicated in that field and not to
   1445                 the address(es) indicated in the "From" field.
   1446 
   1447 
   1448 
   1449 
   1450      August 13, 1982              - 22 -                      RFC #822
   1451 
   1452 
   1453  
   1454      Standard for ARPA Internet Text Messages
   1455 
   1456 
   1457             o   If there is a "From" field, but no  "Reply-To"  field,
   1458                 the  reply should be sent to the address(es) indicated
   1459                 in the "From" field.
   1460 
   1461         Sometimes, a recipient may actually wish to  communicate  with
   1462         the  person  that  initiated  the  message  transfer.  In such
   1463         cases, it is reasonable to use the "Sender" address.
   1464 
   1465         This recommendation is intended  only  for  automated  use  of
   1466         originator-fields  and is not intended to suggest that replies
   1467         may not also be sent to other recipients of messages.   It  is
   1468         up  to  the  respective  mail-handling programs to decide what
   1469         additional facilities will be provided.
   1470 
   1471         Examples are provided in Appendix A.
   1472 
   1473      4.5.  RECEIVER FIELDS
   1474 
   1475      4.5.1.  TO / RESENT-TO
   1476 
   1477         This field contains the identity of the primary recipients  of
   1478         the message.
   1479 
   1480      4.5.2.  CC / RESENT-CC
   1481 
   1482         This field contains the identity of  the  secondary  (informa-
   1483         tional) recipients of the message.
   1484 
   1485      4.5.3.  BCC / RESENT-BCC
   1486 
   1487         This field contains the identity of additional  recipients  of
   1488         the  message.   The contents of this field are not included in
   1489         copies of the message sent to the primary and secondary  reci-
   1490         pients.   Some  systems  may choose to include the text of the
   1491         "Bcc" field only in the author(s)'s  copy,  while  others  may
   1492         also include it in the text sent to all those indicated in the
   1493         "Bcc" list.
   1494 
   1495      4.6.  REFERENCE FIELDS
   1496 
   1497      4.6.1.  MESSAGE-ID / RESENT-MESSAGE-ID
   1498 
   1499              This field contains a unique identifier  (the  local-part
   1500         address  unit)  which  refers to THIS version of THIS message.
   1501         The uniqueness of the message identifier is guaranteed by  the
   1502         host  which  generates  it.  This identifier is intended to be
   1503         machine readable and not necessarily meaningful to humans.   A
   1504         message  identifier pertains to exactly one instantiation of a
   1505         particular message; subsequent revisions to the message should
   1506 
   1507 
   1508      August 13, 1982              - 23 -                      RFC #822
   1509 
   1510 
   1511  
   1512      Standard for ARPA Internet Text Messages
   1513 
   1514 
   1515         each receive new message identifiers.
   1516 
   1517      4.6.2.  IN-REPLY-TO
   1518 
   1519              The contents of this field identify  previous  correspon-
   1520         dence  which this message answers.  Note that if message iden-
   1521         tifiers are used in this  field,  they  must  use  the  msg-id
   1522         specification format.
   1523 
   1524      4.6.3.  REFERENCES
   1525 
   1526              The contents of this field identify other  correspondence
   1527         which  this message references.  Note that if message identif-
   1528         iers are used, they must use the msg-id specification format.
   1529 
   1530      4.6.4.  KEYWORDS
   1531 
   1532              This field contains keywords  or  phrases,  separated  by
   1533         commas.
   1534 
   1535      4.7.  OTHER FIELDS
   1536 
   1537      4.7.1.  SUBJECT
   1538 
   1539              This is intended to provide a summary,  or  indicate  the
   1540         nature, of the message.
   1541 
   1542      4.7.2.  COMMENTS
   1543 
   1544              Permits adding text comments  onto  the  message  without
   1545         disturbing the contents of the message's body.
   1546 
   1547      4.7.3.  ENCRYPTED
   1548 
   1549              Sometimes,  data  encryption  is  used  to  increase  the
   1550         privacy  of  message  contents.   If the body of a message has
   1551         been encrypted, to keep its contents private, the  "Encrypted"
   1552         field  can be used to note the fact and to indicate the nature
   1553         of the encryption.  The first <word> parameter  indicates  the
   1554         software  used  to  encrypt the body, and the second, optional
   1555         <word> is intended to  aid  the  recipient  in  selecting  the
   1556         proper  decryption  key.   This  code word may be viewed as an
   1557         index to a table of keys held by the recipient.
   1558 
   1559         Note:  Unfortunately, headers must contain envelope,  as  well
   1560                as  contents,  information.  Consequently, it is neces-
   1561                sary that they remain unencrypted, so that  mail  tran-
   1562                sport   services   may   access   them.   Since  names,
   1563                addresses, and "Subject"  field  contents  may  contain
   1564 
   1565 
   1566      August 13, 1982              - 24 -                      RFC #822
   1567 
   1568 
   1569  
   1570      Standard for ARPA Internet Text Messages
   1571 
   1572 
   1573                sensitive  information,  this  requirement limits total
   1574                message privacy.
   1575 
   1576              Names of encryption software are registered with the Net-
   1577         work  Information Center, SRI International, Menlo Park, Cali-
   1578         fornia.
   1579 
   1580      4.7.4.  EXTENSION-FIELD
   1581 
   1582              A limited number of common fields have  been  defined  in
   1583         this  document.   As  network mail requirements dictate, addi-
   1584         tional fields may be standardized.   To  provide  user-defined
   1585         fields  with  a  measure  of  safety,  in name selection, such
   1586         extension-fields will never have names  that  begin  with  the
   1587         string "X-".
   1588 
   1589              Names of Extension-fields are registered with the Network
   1590         Information Center, SRI International, Menlo Park, California.
   1591 
   1592      4.7.5.  USER-DEFINED-FIELD
   1593 
   1594              Individual users of network mail are free to  define  and
   1595         use  additional  header  fields.   Such fields must have names
   1596         which are not already used in the current specification or  in
   1597         any definitions of extension-fields, and the overall syntax of
   1598         these user-defined-fields must conform to this specification's
   1599         rules   for   delimiting  and  folding  fields.   Due  to  the
   1600         extension-field  publishing  process,  the  name  of  a  user-
   1601         defined-field may be pre-empted
   1602 
   1603         Note:  The prefatory string "X-" will never  be  used  in  the
   1604                names  of Extension-fields.  This provides user-defined
   1605                fields with a protected set of names.
   1606 
   1607 
   1608 
   1609 
   1610 
   1611 
   1612 
   1613 
   1614 
   1615 
   1616 
   1617 
   1618 
   1619 
   1620 
   1621 
   1622 
   1623 
   1624      August 13, 1982              - 25 -                      RFC #822
   1625 
   1626 
   1627  
   1628      Standard for ARPA Internet Text Messages
   1629 
   1630 
   1631      5.  DATE AND TIME SPECIFICATION
   1632 
   1633      5.1.  SYNTAX
   1634 
   1635      date-time   =  [ day "," ] date time        ; dd mm yy
   1636                                                  ;  hh:mm:ss zzz
   1637 
   1638      day         =  "Mon"  / "Tue" /  "Wed"  / "Thu"
   1639                  /  "Fri"  / "Sat" /  "Sun"
   1640 
   1641      date        =  1*2DIGIT month 2DIGIT        ; day month year
   1642                                                  ;  e.g. 20 Jun 82
   1643 
   1644      month       =  "Jan"  /  "Feb" /  "Mar"  /  "Apr"
   1645                  /  "May"  /  "Jun" /  "Jul"  /  "Aug"
   1646                  /  "Sep"  /  "Oct" /  "Nov"  /  "Dec"
   1647 
   1648      time        =  hour zone                    ; ANSI and Military
   1649 
   1650      hour        =  2DIGIT ":" 2DIGIT [":" 2DIGIT]
   1651                                                  ; 00:00:00 - 23:59:59
   1652 
   1653      zone        =  "UT"  / "GMT"                ; Universal Time
   1654                                                  ; North American : UT
   1655                  /  "EST" / "EDT"                ;  Eastern:  - 5/ - 4
   1656                  /  "CST" / "CDT"                ;  Central:  - 6/ - 5
   1657                  /  "MST" / "MDT"                ;  Mountain: - 7/ - 6
   1658                  /  "PST" / "PDT"                ;  Pacific:  - 8/ - 7
   1659                  /  1ALPHA                       ; Military: Z = UT;
   1660                                                  ;  A:-1; (J not used)
   1661                                                  ;  M:-12; N:+1; Y:+12
   1662                  / ( ("+" / "-") 4DIGIT )        ; Local differential
   1663                                                  ;  hours+min. (HHMM)
   1664 
   1665      5.2.  SEMANTICS
   1666 
   1667           If included, day-of-week must be the day implied by the date
   1668      specification.
   1669 
   1670           Time zone may be indicated in several ways.  "UT" is Univer-
   1671      sal  Time  (formerly called "Greenwich Mean Time"); "GMT" is per-
   1672      mitted as a reference to Universal Time.  The  military  standard
   1673      uses  a  single  character for each zone.  "Z" is Universal Time.
   1674      "A" indicates one hour earlier, and "M" indicates 12  hours  ear-
   1675      lier;  "N"  is  one  hour  later, and "Y" is 12 hours later.  The
   1676      letter "J" is not used.  The other remaining two forms are  taken
   1677      from ANSI standard X3.51-1975.  One allows explicit indication of
   1678      the amount of offset from UT; the other uses  common  3-character
   1679      strings for indicating time zones in North America.
   1680 
   1681 
   1682      August 13, 1982              - 26 -                      RFC #822
   1683 
   1684 
   1685  
   1686      Standard for ARPA Internet Text Messages
   1687 
   1688 
   1689      6.  ADDRESS SPECIFICATION
   1690 
   1691      6.1.  SYNTAX
   1692 
   1693      address     =  mailbox                      ; one addressee
   1694                  /  group                        ; named list
   1695 
   1696      group       =  phrase ":" [#mailbox] ";"
   1697 
   1698      mailbox     =  addr-spec                    ; simple address
   1699                  /  phrase route-addr            ; name & addr-spec
   1700 
   1701      route-addr  =  "<" [route] addr-spec ">"
   1702 
   1703      route       =  1#("@" domain) ":"           ; path-relative
   1704 
   1705      addr-spec   =  local-part "@" domain        ; global address
   1706 
   1707      local-part  =  word *("." word)             ; uninterpreted
   1708                                                  ; case-preserved
   1709 
   1710      domain      =  sub-domain *("." sub-domain)
   1711 
   1712      sub-domain  =  domain-ref / domain-literal
   1713 
   1714      domain-ref  =  atom                         ; symbolic reference
   1715 
   1716      6.2.  SEMANTICS
   1717 
   1718           A mailbox receives mail.  It is a  conceptual  entity  which
   1719      does  not necessarily pertain to file storage.  For example, some
   1720      sites may choose to print mail on their line printer and  deliver
   1721      the output to the addressee's desk.
   1722 
   1723           A mailbox specification comprises a person, system  or  pro-
   1724      cess name reference, a domain-dependent string, and a name-domain
   1725      reference.  The name reference is optional and is usually used to
   1726      indicate  the  human name of a recipient.  The name-domain refer-
   1727      ence specifies a sequence of sub-domains.   The  domain-dependent
   1728      string is uninterpreted, except by the final sub-domain; the rest
   1729      of the mail service merely transmits it as a literal string.
   1730 
   1731      6.2.1.  DOMAINS
   1732 
   1733         A name-domain is a set of registered (mail)  names.   A  name-
   1734         domain  specification  resolves  to  a subordinate name-domain
   1735         specification  or  to  a  terminal  domain-dependent   string.
   1736         Hence,  domain  specification  is  extensible,  permitting any
   1737         number of registration levels.
   1738 
   1739 
   1740      August 13, 1982              - 27 -                      RFC #822
   1741 
   1742 
   1743  
   1744      Standard for ARPA Internet Text Messages
   1745 
   1746 
   1747         Name-domains model a global, logical, hierarchical  addressing
   1748         scheme.   The  model is logical, in that an address specifica-
   1749         tion is related to name registration and  is  not  necessarily
   1750         tied  to  transmission  path.   The  model's  hierarchy  is  a
   1751         directed graph, called an in-tree, such that there is a single
   1752         path  from  the root of the tree to any node in the hierarchy.
   1753         If more than one path actually exists, they are considered  to
   1754         be different addresses.
   1755 
   1756         The root node is common to all addresses; consequently, it  is
   1757         not  referenced.   Its  children  constitute "top-level" name-
   1758         domains.  Usually, a service has access to its own full domain
   1759         specification and to the names of all top-level name-domains.
   1760 
   1761         The "top" of the domain addressing hierarchy -- a child of the
   1762         root  --  is  indicated  by  the right-most field, in a domain
   1763         specification.  Its child is specified to the left, its  child
   1764         to the left, and so on.
   1765 
   1766         Some groups provide formal registration services;  these  con-
   1767         stitute   name-domains   that  are  independent  logically  of
   1768         specific machines.  In addition, networks and machines  impli-
   1769         citly  compose name-domains, since their membership usually is
   1770         registered in name tables.
   1771 
   1772         In the case of formal registration, an organization implements
   1773         a  (distributed)  data base which provides an address-to-route
   1774         mapping service for addresses of the form:
   1775 
   1776                          person@registry.organization
   1777 
   1778         Note that "organization" is a logical  entity,  separate  from
   1779         any particular communication network.
   1780 
   1781         A mechanism for accessing "organization" is universally avail-
   1782         able.   That mechanism, in turn, seeks an instantiation of the
   1783         registry; its location is not indicated in the address specif-
   1784         ication.   It  is assumed that the system which operates under
   1785         the name "organization" knows how to find a subordinate regis-
   1786         try.  The registry will then use the "person" string to deter-
   1787         mine where to send the mail specification.
   1788 
   1789         The latter,  network-oriented  case  permits  simple,  direct,
   1790         attachment-related address specification, such as:
   1791 
   1792                               user@host.network
   1793 
   1794         Once the network is accessed, it is expected  that  a  message
   1795         will  go  directly  to the host and that the host will resolve
   1796 
   1797 
   1798      August 13, 1982              - 28 -                      RFC #822
   1799 
   1800 
   1801  
   1802      Standard for ARPA Internet Text Messages
   1803 
   1804 
   1805         the user name, placing the message in the user's mailbox.
   1806 
   1807      6.2.2.  ABBREVIATED DOMAIN SPECIFICATION
   1808 
   1809         Since any number of  levels  is  possible  within  the  domain
   1810         hierarchy,  specification  of  a  fully  qualified address can
   1811         become inconvenient.  This standard permits abbreviated domain
   1812         specification, in a special case:
   1813 
   1814             For the address of  the  sender,  call  the  left-most
   1815             sub-domain  Level  N.   In a header address, if all of
   1816             the sub-domains above (i.e., to the right of) Level  N
   1817             are  the same as those of the sender, then they do not
   1818             have to appear in the specification.   Otherwise,  the
   1819             address must be fully qualified.
   1820 
   1821             This feature is subject  to  approval  by  local  sub-
   1822             domains.   Individual  sub-domains  may  require their
   1823             member systems, which originate mail, to provide  full
   1824             domain  specification only.  When permitted, abbrevia-
   1825             tions may be present  only  while  the  message  stays
   1826             within the sub-domain of the sender.
   1827 
   1828             Use of this mechanism requires the sender's sub-domain
   1829             to reserve the names of all top-level domains, so that
   1830             full specifications can be distinguished from abbrevi-
   1831             ated specifications.
   1832 
   1833         For example, if a sender's address is:
   1834 
   1835                  sender@registry-A.registry-1.organization-X
   1836 
   1837         and one recipient's address is:
   1838 
   1839                 recipient@registry-B.registry-1.organization-X
   1840 
   1841         and another's is:
   1842 
   1843                 recipient@registry-C.registry-2.organization-X
   1844 
   1845         then ".registry-1.organization-X" need not be specified in the
   1846         the  message,  but  "registry-C.registry-2"  DOES  have  to be
   1847         specified.  That is, the first two addresses may  be  abbrevi-
   1848         ated, but the third address must be fully specified.
   1849 
   1850         When a message crosses a domain boundary, all  addresses  must
   1851         be  specified  in  the  full format, ending with the top-level
   1852         name-domain in the right-most field.  It is the responsibility
   1853         of  mail  forwarding services to ensure that addresses conform
   1854 
   1855 
   1856      August 13, 1982              - 29 -                      RFC #822
   1857 
   1858 
   1859  
   1860      Standard for ARPA Internet Text Messages
   1861 
   1862 
   1863         with this requirement.  In the case of abbreviated  addresses,
   1864         the  relaying  service must make the necessary expansions.  It
   1865         should be noted that it often is difficult for such a  service
   1866         to locate all occurrences of address abbreviations.  For exam-
   1867         ple, it will not be possible to find such abbreviations within
   1868         the  body  of  the  message.   The "Return-Path" field can aid
   1869         recipients in recovering from these errors.
   1870 
   1871         Note:  When passing any portion of an addr-spec onto a process
   1872                which  does  not interpret data according to this stan-
   1873                dard (e.g., mail protocol servers).  There must  be  NO
   1874                LWSP-chars  preceding  or  following the at-sign or any
   1875                delimiting period ("."), such as  shown  in  the  above
   1876                examples,   and   only  ONE  SPACE  between  contiguous
   1877                <word>s.
   1878 
   1879      6.2.3.  DOMAIN TERMS
   1880 
   1881         A domain-ref must be THE official name of a registry, network,
   1882         or  host.   It  is  a  symbolic  reference, within a name sub-
   1883         domain.  At times, it is necessary to bypass standard  mechan-
   1884         isms  for  resolving  such  references,  using  more primitive
   1885         information, such as a network host address  rather  than  its
   1886         associated host name.
   1887 
   1888         To permit such references, this standard provides the  domain-
   1889         literal  construct.   Its contents must conform with the needs
   1890         of the sub-domain in which it is interpreted.
   1891 
   1892         Domain-literals which refer to domains within the ARPA  Inter-
   1893         net  specify  32-bit  Internet addresses, in four 8-bit fields
   1894         noted in decimal, as described in Request for  Comments  #820,
   1895         "Assigned Numbers."  For example:
   1896 
   1897                                  [10.0.3.19]
   1898 
   1899         Note:  THE USE OF DOMAIN-LITERALS IS STRONGLY DISCOURAGED.  It
   1900                is  permitted  only  as  a means of bypassing temporary
   1901                system limitations, such as name tables which  are  not
   1902                complete.
   1903 
   1904         The names of "top-level" domains, and  the  names  of  domains
   1905         under  in  the  ARPA Internet, are registered with the Network
   1906         Information Center, SRI International, Menlo Park, California.
   1907 
   1908      6.2.4.  DOMAIN-DEPENDENT LOCAL STRING
   1909 
   1910         The local-part of an  addr-spec  in  a  mailbox  specification
   1911         (i.e.,  the  host's  name for the mailbox) is understood to be
   1912 
   1913 
   1914      August 13, 1982              - 30 -                      RFC #822
   1915 
   1916 
   1917  
   1918      Standard for ARPA Internet Text Messages
   1919 
   1920 
   1921         whatever the receiving mail protocol server allows.  For exam-
   1922         ple,  some systems do not understand mailbox references of the
   1923         form "P. D. Q. Bach", but others do.
   1924 
   1925         This specification treats periods (".") as lexical separators.
   1926         Hence,  their  presence  in  local-parts which are not quoted-
   1927         strings, is detected.   However,  such  occurrences  carry  NO
   1928         semantics.  That is, if a local-part has periods within it, an
   1929         address parser will divide the local-part into several tokens,
   1930         but  the  sequence  of  tokens will be treated as one uninter-
   1931         preted unit.  The sequence  will  be  re-assembled,  when  the
   1932         address is passed outside of the system such as to a mail pro-
   1933         tocol service.
   1934 
   1935         For example, the address:
   1936 
   1937                            First.Last@Registry.Org
   1938 
   1939         is legal and does not require the local-part to be  surrounded
   1940         with  quotation-marks.   (However,  "First  Last" DOES require
   1941         quoting.)  The local-part of the address, when passed  outside
   1942         of  the  mail  system,  within  the  Registry.Org  domain,  is
   1943         "First.Last", again without quotation marks.
   1944 
   1945      6.2.5.  BALANCING LOCAL-PART AND DOMAIN
   1946 
   1947         In some cases, the boundary between local-part and domain  can
   1948         be  flexible.  The local-part may be a simple string, which is
   1949         used for the final determination of the  recipient's  mailbox.
   1950         All  other  levels  of  reference  are, therefore, part of the
   1951         domain.
   1952 
   1953         For some systems, in the case of abbreviated reference to  the
   1954         local  and  subordinate  sub-domains,  it  may  be possible to
   1955         specify only one reference within the domain  part  and  place
   1956         the  other,  subordinate  name-domain  references  within  the
   1957         local-part.  This would appear as:
   1958 
   1959                         mailbox.sub1.sub2@this-domain
   1960 
   1961         Such a specification would be acceptable  to  address  parsers
   1962         which  conform  to  RFC  #733,  but  do not support this newer
   1963         Internet standard.  While contrary to the intent of this stan-
   1964         dard, the form is legal.
   1965 
   1966         Also, some sub-domains have a specification syntax which  does
   1967         not conform to this standard.  For example:
   1968 
   1969                       sub-net.mailbox@sub-domain.domain
   1970 
   1971 
   1972      August 13, 1982              - 31 -                      RFC #822
   1973 
   1974 
   1975  
   1976      Standard for ARPA Internet Text Messages
   1977 
   1978 
   1979         uses a different parsing  sequence  for  local-part  than  for
   1980         domain.
   1981 
   1982         Note:  As a rule,  the  domain  specification  should  contain
   1983                fields  which  are  encoded  according to the syntax of
   1984                this standard and which contain  generally-standardized
   1985                information.   The local-part specification should con-
   1986                tain only that portion of the  address  which  deviates
   1987                from the form or intention of the domain field.
   1988 
   1989      6.2.6.  MULTIPLE MAILBOXES
   1990 
   1991         An individual may have several mailboxes and wish  to  receive
   1992         mail  at  whatever  mailbox  is  convenient  for the sender to
   1993         access.  This standard does not provide a means of  specifying
   1994         "any member of" a list of mailboxes.
   1995 
   1996         A set of individuals may wish to receive mail as a single unit
   1997         (i.e.,  a  distribution  list).  The <group> construct permits
   1998         specification of such a list.  Recipient mailboxes are  speci-
   1999         fied  within  the  bracketed  part (":" - ";").  A copy of the
   2000         transmitted message is to be  sent  to  each  mailbox  listed.
   2001         This  standard  does  not  permit  recursive  specification of
   2002         groups within groups.
   2003 
   2004         While a list must be named, it is not required that  the  con-
   2005         tents  of  the  list be included.  In this case, the <address>
   2006         serves only as an indication of group distribution  and  would
   2007         appear in the form:
   2008 
   2009                                     name:;
   2010 
   2011         Some mail  services  may  provide  a  group-list  distribution
   2012         facility,  accepting  a single mailbox reference, expanding it
   2013         to the full distribution list, and relaying the  mail  to  the
   2014         list's  members.   This standard provides no additional syntax
   2015         for indicating such a  service.   Using  the  <group>  address
   2016         alternative,  while listing one mailbox in it, can mean either
   2017         that the mailbox reference will be expanded to a list or  that
   2018         there is a group with one member.
   2019 
   2020      6.2.7.  EXPLICIT PATH SPECIFICATION
   2021 
   2022         At times, a  message  originator  may  wish  to  indicate  the
   2023         transmission  path  that  a  message  should  follow.  This is
   2024         called source routing.  The normal addressing scheme, used  in
   2025         an  addr-spec,  is  carefully separated from such information;
   2026         the <route> portion of a route-addr is provided for such occa-
   2027         sions.  It specifies the sequence of hosts and/or transmission
   2028 
   2029 
   2030      August 13, 1982              - 32 -                      RFC #822
   2031 
   2032 
   2033  
   2034      Standard for ARPA Internet Text Messages
   2035 
   2036 
   2037         services that are  to  be  traversed.   Both  domain-refs  and
   2038         domain-literals may be used.
   2039 
   2040         Note:  The use of source routing is discouraged.   Unless  the
   2041                sender has special need of path restriction, the choice
   2042                of transmission route should be left to the mail  tran-
   2043                sport service.
   2044 
   2045      6.3.  RESERVED ADDRESS
   2046 
   2047           It often is necessary to send mail to a site, without  know-
   2048      ing  any  of its valid addresses.  For example, there may be mail
   2049      system dysfunctions, or a user may wish to find  out  a  person's
   2050      correct address, at that site.
   2051 
   2052           This standard specifies a single, reserved  mailbox  address
   2053      (local-part)  which  is  to  be valid at each site.  Mail sent to
   2054      that address is to be routed to  a  person  responsible  for  the
   2055      site's mail system or to a person with responsibility for general
   2056      site operation.  The name of the reserved local-part address is:
   2057 
   2058                                 Postmaster
   2059 
   2060      so that "Postmaster@domain" is required to be valid.
   2061 
   2062      Note:  This reserved local-part must be  matched  without  sensi-
   2063             tivity to alphabetic case, so that "POSTMASTER", "postmas-
   2064             ter", and even "poStmASteR" is to be accepted.
   2065 
   2066 
   2067 
   2068 
   2069 
   2070 
   2071 
   2072 
   2073 
   2074 
   2075 
   2076 
   2077 
   2078 
   2079 
   2080 
   2081 
   2082 
   2083 
   2084 
   2085 
   2086 
   2087 
   2088      August 13, 1982              - 33 -                      RFC #822
   2089 
   2090 
   2091  
   2092      Standard for ARPA Internet Text Messages
   2093 
   2094 
   2095      7.  BIBLIOGRAPHY
   2096 
   2097 
   2098      ANSI.  "USA Standard Code  for  Information  Interchange,"  X3.4.
   2099         American  National Standards Institute: New York (1968).  Also
   2100         in:  Feinler, E.  and J. Postel, eds., "ARPANET Protocol Hand-
   2101         book", NIC 7104.
   2102 
   2103      ANSI.  "Representations of Universal Time, Local  Time  Differen-
   2104         tials,  and United States Time Zone References for Information
   2105         Interchange," X3.51-1975.  American National Standards  Insti-
   2106         tute:  New York (1975).
   2107 
   2108      Bemer, R.W., "Time and the Computer."  In:  Interface  Age  (Feb.
   2109         1979).
   2110 
   2111      Bennett, C.J.  "JNT Mail Protocol".  Joint Network Team,  Ruther-
   2112         ford and Appleton Laboratory:  Didcot, England.
   2113 
   2114      Bhushan, A.K., Pogran, K.T., Tomlinson,  R.S.,  and  White,  J.E.
   2115         "Standardizing  Network  Mail  Headers,"   ARPANET Request for
   2116         Comments No. 561, Network Information Center  No.  18516;  SRI
   2117         International:  Menlo Park (September 1973).
   2118 
   2119      Birrell, A.D., Levin, R.,  Needham,  R.M.,  and  Schroeder,  M.D.
   2120         "Grapevine:  An Exercise in Distributed Computing," Communica-
   2121         tions of the ACM 25, 4 (April 1982), 260-274.
   2122 
   2123      Crocker,  D.H.,  Vittal,  J.J.,  Pogran,  K.T.,  Henderson,  D.A.
   2124         "Standard  for  the  Format  of  ARPA  Network  Text Message,"
   2125         ARPANET Request for  Comments  No.  733,  Network  Information
   2126         Center  No.  41952.   SRI International:  Menlo Park (November
   2127         1977).
   2128 
   2129      Feinler, E.J. and Postel, J.B.  ARPANET Protocol  Handbook,  Net-
   2130         work  Information  Center  No.  7104   (NTIS AD A003890).  SRI
   2131         International:  Menlo Park (April 1976).
   2132 
   2133      Harary, F.   "Graph  Theory".   Addison-Wesley:   Reading,  Mass.
   2134         (1969).
   2135 
   2136      Levin, R. and Schroeder, M.  "Transport  of  Electronic  Messages
   2137         through  a  Network,"   TeleInformatics  79, pp. 29-33.  North
   2138         Holland (1979).  Also  as  Xerox  Palo  Alto  Research  Center
   2139         Technical Report CSL-79-4.
   2140 
   2141      Myer, T.H. and Henderson, D.A.  "Message Transmission  Protocol,"
   2142         ARPANET  Request  for  Comments,  No. 680, Network Information
   2143         Center No. 32116.  SRI International:  Menlo Park (1975).
   2144 
   2145 
   2146      August 13, 1982              - 34 -                      RFC #822
   2147 
   2148 
   2149  
   2150      Standard for ARPA Internet Text Messages
   2151 
   2152 
   2153      NBS.  "Specification of Message Format for Computer Based Message
   2154         Systems, Recommended Federal Information Processing Standard."
   2155         National  Bureau   of   Standards:    Gaithersburg,   Maryland
   2156         (October 1981).
   2157 
   2158      NIC.  Internet Protocol Transition Workbook.  Network Information
   2159         Center,   SRI-International,  Menlo  Park,  California  (March
   2160         1982).
   2161 
   2162      Oppen, D.C. and Dalal, Y.K.  "The Clearinghouse:  A Decentralized
   2163         Agent  for  Locating  Named  Objects in a Distributed Environ-
   2164         ment," OPD-T8103.  Xerox Office Products Division:  Palo Alto,
   2165         CA. (October 1981).
   2166 
   2167      Postel, J.B.  "Assigned Numbers,"  ARPANET Request for  Comments,
   2168         No. 820.  SRI International:  Menlo Park (August 1982).
   2169 
   2170      Postel, J.B.  "Simple Mail Transfer  Protocol,"  ARPANET  Request
   2171         for Comments, No. 821.  SRI International:  Menlo Park (August
   2172         1982).
   2173 
   2174      Shoch, J.F.  "Internetwork naming, addressing  and  routing,"  in
   2175         Proc. 17th IEEE Computer Society International Conference, pp.
   2176         72-79, Sept. 1978, IEEE Cat. No. 78 CH 1388-8C.
   2177 
   2178      Su, Z. and Postel, J.  "The Domain Naming Convention for Internet
   2179         User  Applications,"  ARPANET  Request  for Comments, No. 819.
   2180         SRI International:  Menlo Park (August 1982).
   2181 
   2182 
   2183 
   2184 
   2185 
   2186 
   2187 
   2188 
   2189 
   2190 
   2191 
   2192 
   2193 
   2194 
   2195 
   2196 
   2197 
   2198 
   2199 
   2200 
   2201 
   2202 
   2203 
   2204      August 13, 1982              - 35 -                      RFC #822
   2205 
   2206 
   2207  
   2208      Standard for ARPA Internet Text Messages
   2209 
   2210 
   2211                                  APPENDIX
   2212 
   2213 
   2214      A.  EXAMPLES
   2215 
   2216      A.1.  ADDRESSES
   2217 
   2218      A.1.1.  Alfred Neuman <Neuman@BBN-TENEXA>
   2219 
   2220      A.1.2.  Neuman@BBN-TENEXA
   2221 
   2222              These two "Alfred Neuman" examples have identical  seman-
   2223         tics, as far as the operation of the local host's mail sending
   2224         (distribution) program (also sometimes  called  its  "mailer")
   2225         and  the remote host's mail protocol server are concerned.  In
   2226         the first example, the  "Alfred  Neuman"  is  ignored  by  the
   2227         mailer,  as "Neuman@BBN-TENEXA" completely specifies the reci-
   2228         pient.  The second example contains  no  superfluous  informa-
   2229         tion,  and,  again,  "Neuman@BBN-TENEXA" is the intended reci-
   2230         pient.
   2231 
   2232         Note:  When the message crosses name-domain  boundaries,  then
   2233                these specifications must be changed, so as to indicate
   2234                the remainder of the hierarchy, starting with  the  top
   2235                level.
   2236 
   2237      A.1.3.  "George, Ted" <Shared@Group.Arpanet>
   2238 
   2239              This form might be used to indicate that a single mailbox
   2240         is  shared  by several users.  The quoted string is ignored by
   2241         the originating host's mailer, because  "Shared@Group.Arpanet"
   2242         completely specifies the destination mailbox.
   2243 
   2244      A.1.4.  Wilt . (the  Stilt) Chamberlain@NBA.US
   2245 
   2246              The "(the  Stilt)" is a comment, which is NOT included in
   2247         the  destination  mailbox  address  handed  to the originating
   2248         system's mailer.  The local-part of the address is the  string
   2249         "Wilt.Chamberlain", with NO space between the first and second
   2250         words.
   2251 
   2252      A.1.5.  Address Lists
   2253 
   2254      Gourmets:  Pompous Person <WhoZiWhatZit@Cordon-Bleu>,
   2255                 Childs@WGBH.Boston, Galloping Gourmet@
   2256                 ANT.Down-Under (Australian National Television),
   2257                 Cheapie@Discount-Liquors;,
   2258        Cruisers:  Port@Portugal, Jones@SEA;,
   2259          Another@Somewhere.SomeOrg
   2260 
   2261 
   2262      August 13, 1982              - 36 -                      RFC #822
   2263 
   2264 
   2265  
   2266      Standard for ARPA Internet Text Messages
   2267 
   2268 
   2269         This group list example points out the use of comments and the
   2270         mixing of addresses and groups.
   2271 
   2272      A.2.  ORIGINATOR ITEMS
   2273 
   2274      A.2.1.  Author-sent
   2275 
   2276              George Jones logs into his host  as  "Jones".   He  sends
   2277         mail himself.
   2278 
   2279             From:  Jones@Group.Org
   2280 
   2281         or
   2282 
   2283             From:  George Jones <Jones@Group.Org>
   2284 
   2285      A.2.2.  Secretary-sent
   2286 
   2287              George Jones logs in as Jones on his  host.   His  secre-
   2288         tary,  who logs in as Secy sends mail for him.  Replies to the
   2289         mail should go to George.
   2290 
   2291             From:    George Jones <Jones@Group>
   2292             Sender:  Secy@Other-Group
   2293 
   2294      A.2.3.  Secretary-sent, for user of shared directory
   2295 
   2296              George Jones' secretary sends mail  for  George.  Replies
   2297         should go to George.
   2298 
   2299             From:     George Jones<Shared@Group.Org>
   2300             Sender:   Secy@Other-Group
   2301 
   2302         Note that there need not be a space between  "Jones"  and  the
   2303         "<",  but  adding a space enhances readability (as is the case
   2304         in other examples.
   2305 
   2306      A.2.4.  Committee activity, with one author
   2307 
   2308              George is a member of a committee.  He wishes to have any
   2309         replies to his message go to all committee members.
   2310 
   2311             From:     George Jones <Jones@Host.Net>
   2312             Sender:   Jones@Host
   2313             Reply-To: The Committee: Jones@Host.Net,
   2314                                      Smith@Other.Org,
   2315                                      Doe@Somewhere-Else;
   2316 
   2317         Note  that  if  George  had  not  included  himself   in   the
   2318 
   2319 
   2320      August 13, 1982              - 37 -                      RFC #822
   2321 
   2322 
   2323  
   2324      Standard for ARPA Internet Text Messages
   2325 
   2326 
   2327         enumeration  of  The  Committee,  he  would not have gotten an
   2328         implicit reply; the presence of the  "Reply-to"  field  SUPER-
   2329         SEDES the sending of a reply to the person named in the "From"
   2330         field.
   2331 
   2332      A.2.5.  Secretary acting as full agent of author
   2333 
   2334              George Jones asks his secretary  (Secy@Host)  to  send  a
   2335         message for him in his capacity as Group.  He wants his secre-
   2336         tary to handle all replies.
   2337 
   2338             From:     George Jones <Group@Host>
   2339             Sender:   Secy@Host
   2340             Reply-To: Secy@Host
   2341 
   2342      A.2.6.  Agent for user without online mailbox
   2343 
   2344              A friend  of  George's,  Sarah,  is  visiting.   George's
   2345         secretary  sends  some  mail to a friend of Sarah in computer-
   2346         land.  Replies should go to George, whose mailbox is Jones  at
   2347         Registry.
   2348 
   2349             From:     Sarah Friendly <Secy@Registry>
   2350             Sender:   Secy-Name <Secy@Registry>
   2351             Reply-To: Jones@Registry.
   2352 
   2353      A.2.7.  Agent for member of a committee
   2354 
   2355              George's secretary sends out a message which was authored
   2356         jointly by all the members of a committee.  Note that the name
   2357         of the committee cannot be specified, since <group> names  are
   2358         not permitted in the From field.
   2359 
   2360             From:   Jones@Host,
   2361                     Smith@Other-Host,
   2362                     Doe@Somewhere-Else
   2363             Sender: Secy@SHost
   2364 
   2365 
   2366 
   2367 
   2368 
   2369 
   2370 
   2371 
   2372 
   2373 
   2374 
   2375 
   2376 
   2377 
   2378      August 13, 1982              - 38 -                      RFC #822
   2379 
   2380 
   2381  
   2382      Standard for ARPA Internet Text Messages
   2383 
   2384 
   2385      A.3.  COMPLETE HEADERS
   2386 
   2387      A.3.1.  Minimum required
   2388 
   2389      Date:     26 Aug 76 1429 EDT        Date:     26 Aug 76 1429 EDT
   2390      From:     Jones@Registry.Org   or   From:     Jones@Registry.Org
   2391      Bcc:                                To:       Smith@Registry.Org
   2392 
   2393         Note that the "Bcc" field may be empty, while the  "To"  field
   2394         is required to have at least one address.
   2395 
   2396      A.3.2.  Using some of the additional fields
   2397 
   2398      Date:     26 Aug 76 1430 EDT
   2399      From:     George Jones<Group@Host>
   2400      Sender:   Secy@SHOST
   2401      To:       "Al Neuman"@Mad-Host,
   2402                Sam.Irving@Other-Host
   2403      Message-ID:  <some.string@SHOST>
   2404 
   2405      A.3.3.  About as complex as you're going to get
   2406 
   2407      Date     :  27 Aug 76 0932 PDT
   2408      From     :  Ken Davis <KDavis@This-Host.This-net>
   2409      Subject  :  Re: The Syntax in the RFC
   2410      Sender   :  KSecy@Other-Host
   2411      Reply-To :  Sam.Irving@Reg.Organization
   2412      To       :  George Jones <Group@Some-Reg.An-Org>,
   2413                  Al.Neuman@MAD.Publisher
   2414      cc       :  Important folk:
   2415                    Tom Softwood <Balsa@Tree.Root>,
   2416                    "Sam Irving"@Other-Host;,
   2417                  Standard Distribution:
   2418                    /main/davis/people/standard@Other-Host,
   2419                    "<Jones>standard.dist.3"@Tops-20-Host>;
   2420      Comment  :  Sam is away on business. He asked me to handle
   2421                  his mail for him.  He'll be able to provide  a
   2422                  more  accurate  explanation  when  he  returns
   2423                  next week.
   2424      In-Reply-To: <some.string@DBM.Group>, George's message
   2425      X-Special-action:  This is a sample of user-defined field-
   2426                  names.  There could also be a field-name
   2427                  "Special-action", but its name might later be
   2428                  preempted
   2429      Message-ID: <4231.629.XYzi-What@Other-Host>
   2430 
   2431 
   2432 
   2433 
   2434 
   2435 
   2436      August 13, 1982              - 39 -                      RFC #822
   2437 
   2438 
   2439  
   2440      Standard for ARPA Internet Text Messages
   2441 
   2442 
   2443      B.  SIMPLE FIELD PARSING
   2444 
   2445           Some mail-reading software systems may wish to perform  only
   2446      minimal  processing,  ignoring  the internal syntax of structured
   2447      field-bodies and treating them the  same  as  unstructured-field-
   2448      bodies.  Such software will need only to distinguish:
   2449 
   2450          o   Header fields from the message body,
   2451 
   2452          o   Beginnings of fields from lines which continue fields,
   2453 
   2454          o   Field-names from field-contents.
   2455 
   2456           The abbreviated set of syntactic rules  which  follows  will
   2457      suffice  for  this  purpose.  It describes a limited view of mes-
   2458      sages and is a subset of the syntactic rules provided in the main
   2459      part of this specification.  One small exception is that the con-
   2460      tents of field-bodies consist only of text:
   2461 
   2462      B.1.  SYNTAX
   2463 
   2464 
   2465      message         =   *field *(CRLF *text)
   2466 
   2467      field           =    field-name ":" [field-body] CRLF
   2468 
   2469      field-name      =  1*<any CHAR, excluding CTLs, SPACE, and ":">
   2470 
   2471      field-body      =   *text [CRLF LWSP-char field-body]
   2472 
   2473 
   2474      B.2.  SEMANTICS
   2475 
   2476           Headers occur before the message body and are terminated  by
   2477      a null line (i.e., two contiguous CRLFs).
   2478 
   2479           A line which continues a header field begins with a SPACE or
   2480      HTAB  character,  while  a  line  beginning a field starts with a
   2481      printable character which is not a colon.
   2482 
   2483           A field-name consists of one or  more  printable  characters
   2484      (excluding  colon,  space, and control-characters).  A field-name
   2485      MUST be contained on one line.  Upper and lower case are not dis-
   2486      tinguished when comparing field-names.
   2487 
   2488 
   2489 
   2490 
   2491 
   2492 
   2493 
   2494      August 13, 1982              - 40 -                      RFC #822
   2495 
   2496 
   2497  
   2498      Standard for ARPA Internet Text Messages
   2499 
   2500 
   2501      C.  DIFFERENCES FROM RFC #733
   2502 
   2503           The following summarizes the differences between this  stan-
   2504      dard  and the one specified in Arpanet Request for Comments #733,
   2505      "Standard for the Format of ARPA  Network  Text  Messages".   The
   2506      differences  are  listed  in the order of their occurrence in the
   2507      current specification.
   2508 
   2509      C.1.  FIELD DEFINITIONS
   2510 
   2511      C.1.1.  FIELD NAMES
   2512 
   2513         These now must be a sequence of  printable  characters.   They
   2514         may not contain any LWSP-chars.
   2515 
   2516      C.2.  LEXICAL TOKENS
   2517 
   2518      C.2.1.  SPECIALS
   2519 
   2520         The characters period ("."), left-square  bracket  ("["),  and
   2521         right-square  bracket ("]") have been added.  For presentation
   2522         purposes, and when passing a specification to  a  system  that
   2523         does  not conform to this standard, periods are to be contigu-
   2524         ous with their surrounding lexical tokens.   No  linear-white-
   2525         space  is  permitted  between them.  The presence of one LWSP-
   2526         char between other tokens is still directed.
   2527 
   2528      C.2.2.  ATOM
   2529 
   2530         Atoms may not contain SPACE.
   2531 
   2532      C.2.3.  SPECIAL TEXT
   2533 
   2534         ctext and qtext have had backslash ("\") added to the list  of
   2535         prohibited characters.
   2536 
   2537      C.2.4.  DOMAINS
   2538 
   2539         The lexical tokens  <domain-literal>  and  <dtext>  have  been
   2540         added.
   2541 
   2542      C.3.  MESSAGE SPECIFICATION
   2543 
   2544      C.3.1.  TRACE
   2545 
   2546         The "Return-path:" and "Received:" fields have been specified.
   2547 
   2548 
   2549 
   2550 
   2551 
   2552      August 13, 1982              - 41 -                      RFC #822
   2553 
   2554 
   2555  
   2556      Standard for ARPA Internet Text Messages
   2557 
   2558 
   2559      C.3.2.  FROM
   2560 
   2561         The "From" field must contain machine-usable addresses  (addr-
   2562         spec).   Multiple  addresses may be specified, but named-lists
   2563         (groups) may not.
   2564 
   2565      C.3.3.  RESENT
   2566 
   2567         The meta-construct of prefacing field names  with  the  string
   2568         "Resent-"  has been added, to indicate that a message has been
   2569         forwarded by an intermediate recipient.
   2570 
   2571      C.3.4.  DESTINATION
   2572 
   2573         A message must contain at least one destination address field.
   2574         "To" and "CC" are required to contain at least one address.
   2575 
   2576      C.3.5.  IN-REPLY-TO
   2577 
   2578         The field-body is no longer a comma-separated list, although a
   2579         sequence is still permitted.
   2580 
   2581      C.3.6.  REFERENCE
   2582 
   2583         The field-body is no longer a comma-separated list, although a
   2584         sequence is still permitted.
   2585 
   2586      C.3.7.  ENCRYPTED
   2587 
   2588         A field has been specified that permits  senders  to  indicate
   2589         that the body of a message has been encrypted.
   2590 
   2591      C.3.8.  EXTENSION-FIELD
   2592 
   2593         Extension fields are prohibited from beginning with the  char-
   2594         acters "X-".
   2595 
   2596      C.4.  DATE AND TIME SPECIFICATION
   2597 
   2598      C.4.1.  SIMPLIFICATION
   2599 
   2600         Fewer optional forms are permitted  and  the  list  of  three-
   2601         letter time zones has been shortened.
   2602 
   2603      C.5.  ADDRESS SPECIFICATION
   2604 
   2605 
   2606 
   2607 
   2608 
   2609 
   2610      August 13, 1982              - 42 -                      RFC #822
   2611 
   2612 
   2613  
   2614      Standard for ARPA Internet Text Messages
   2615 
   2616 
   2617      C.5.1.  ADDRESS
   2618 
   2619         The use of quoted-string, and the ":"-atom-":" construct, have
   2620         been  removed.   An  address  now  is  either a single mailbox
   2621         reference or is a named list of addresses.  The  latter  indi-
   2622         cates a group distribution.
   2623 
   2624      C.5.2.  GROUPS
   2625 
   2626         Group lists are now required to to have a name.   Group  lists
   2627         may not be nested.
   2628 
   2629      C.5.3.  MAILBOX
   2630 
   2631         A mailbox specification  may  indicate  a  person's  name,  as
   2632         before.   Such  a  named  list  no longer may specify multiple
   2633         mailboxes and may not be nested.
   2634 
   2635      C.5.4.  ROUTE ADDRESSING
   2636 
   2637         Addresses now are taken to be absolute, global specifications,
   2638         independent  of transmission paths.  The <route> construct has
   2639         been provided, to permit explicit specification  of  transmis-
   2640         sion  path.   RFC  #733's  use  of multiple at-signs ("@") was
   2641         intended as a general syntax  for  indicating  routing  and/or
   2642         hierarchical addressing.  The current standard separates these
   2643         specifications and only one at-sign is permitted.
   2644 
   2645      C.5.5.  AT-SIGN
   2646 
   2647         The string " at " no longer is used as an  address  delimiter.
   2648         Only at-sign ("@") serves the function.
   2649 
   2650      C.5.6.  DOMAINS
   2651 
   2652         Hierarchical, logical name-domains have been added.
   2653 
   2654      C.6.  RESERVED ADDRESS
   2655 
   2656      The local-part "Postmaster" has been reserved, so that users  can
   2657      be guaranteed at least one valid address at a site.
   2658 
   2659 
   2660 
   2661 
   2662 
   2663 
   2664 
   2665 
   2666 
   2667 
   2668      August 13, 1982              - 43 -                      RFC #822
   2669 
   2670 
   2671  
   2672      Standard for ARPA Internet Text Messages
   2673 
   2674 
   2675      D.  ALPHABETICAL LISTING OF SYNTAX RULES
   2676 
   2677      address     =  mailbox                      ; one addressee
   2678                  /  group                        ; named list
   2679      addr-spec   =  local-part "@" domain        ; global address
   2680      ALPHA       =  <any ASCII alphabetic character>
   2681                                                  ; (101-132, 65.- 90.)
   2682                                                  ; (141-172, 97.-122.)
   2683      atom        =  1*<any CHAR except specials, SPACE and CTLs>
   2684      authentic   =   "From"       ":"   mailbox  ; Single author
   2685                  / ( "Sender"     ":"   mailbox  ; Actual submittor
   2686                      "From"       ":" 1#mailbox) ; Multiple authors
   2687                                                  ;  or not sender
   2688      CHAR        =  <any ASCII character>        ; (  0-177,  0.-127.)
   2689      comment     =  "(" *(ctext / quoted-pair / comment) ")"
   2690      CR          =  <ASCII CR, carriage return>  ; (     15,      13.)
   2691      CRLF        =  CR LF
   2692      ctext       =  <any CHAR excluding "(",     ; => may be folded
   2693                      ")", "\" & CR, & including
   2694                      linear-white-space>
   2695      CTL         =  <any ASCII control           ; (  0- 37,  0.- 31.)
   2696                      character and DEL>          ; (    177,     127.)
   2697      date        =  1*2DIGIT month 2DIGIT        ; day month year
   2698                                                  ;  e.g. 20 Jun 82
   2699      dates       =   orig-date                   ; Original
   2700                    [ resent-date ]               ; Forwarded
   2701      date-time   =  [ day "," ] date time        ; dd mm yy
   2702                                                  ;  hh:mm:ss zzz
   2703      day         =  "Mon"  / "Tue" /  "Wed"  / "Thu"
   2704                  /  "Fri"  / "Sat" /  "Sun"
   2705      delimiters  =  specials / linear-white-space / comment
   2706      destination =  "To"          ":" 1#address  ; Primary
   2707                  /  "Resent-To"   ":" 1#address
   2708                  /  "cc"          ":" 1#address  ; Secondary
   2709                  /  "Resent-cc"   ":" 1#address
   2710                  /  "bcc"         ":"  #address  ; Blind carbon
   2711                  /  "Resent-bcc"  ":"  #address
   2712      DIGIT       =  <any ASCII decimal digit>    ; ( 60- 71, 48.- 57.)
   2713      domain      =  sub-domain *("." sub-domain)
   2714      domain-literal =  "[" *(dtext / quoted-pair) "]"
   2715      domain-ref  =  atom                         ; symbolic reference
   2716      dtext       =  <any CHAR excluding "[",     ; => may be folded
   2717                      "]", "\" & CR, & including
   2718                      linear-white-space>
   2719      extension-field =
   2720                    <Any field which is defined in a document
   2721                     published as a formal extension to this
   2722                     specification; none will have names beginning
   2723                     with the string "X-">
   2724 
   2725 
   2726      August 13, 1982              - 44 -                      RFC #822
   2727 
   2728 
   2729  
   2730      Standard for ARPA Internet Text Messages
   2731 
   2732 
   2733      field       =  field-name ":" [ field-body ] CRLF
   2734      fields      =    dates                      ; Creation time,
   2735                       source                     ;  author id & one
   2736                     1*destination                ;  address required
   2737                      *optional-field             ;  others optional
   2738      field-body  =  field-body-contents
   2739                     [CRLF LWSP-char field-body]
   2740      field-body-contents =
   2741                    <the ASCII characters making up the field-body, as
   2742                     defined in the following sections, and consisting
   2743                     of combinations of atom, quoted-string, and
   2744                     specials tokens, or else consisting of texts>
   2745      field-name  =  1*<any CHAR, excluding CTLs, SPACE, and ":">
   2746      group       =  phrase ":" [#mailbox] ";"
   2747      hour        =  2DIGIT ":" 2DIGIT [":" 2DIGIT]
   2748                                                  ; 00:00:00 - 23:59:59
   2749      HTAB        =  <ASCII HT, horizontal-tab>   ; (     11,       9.)
   2750      LF          =  <ASCII LF, linefeed>         ; (     12,      10.)
   2751      linear-white-space =  1*([CRLF] LWSP-char)  ; semantics = SPACE
   2752                                                  ; CRLF => folding
   2753      local-part  =  word *("." word)             ; uninterpreted
   2754                                                  ; case-preserved
   2755      LWSP-char   =  SPACE / HTAB                 ; semantics = SPACE
   2756      mailbox     =  addr-spec                    ; simple address
   2757                  /  phrase route-addr            ; name & addr-spec
   2758      message     =  fields *( CRLF *text )       ; Everything after
   2759                                                  ;  first null line
   2760                                                  ;  is message body
   2761      month       =  "Jan"  /  "Feb" /  "Mar"  /  "Apr"
   2762                  /  "May"  /  "Jun" /  "Jul"  /  "Aug"
   2763                  /  "Sep"  /  "Oct" /  "Nov"  /  "Dec"
   2764      msg-id      =  "<" addr-spec ">"            ; Unique message id
   2765      optional-field =
   2766                  /  "Message-ID"        ":"   msg-id
   2767                  /  "Resent-Message-ID" ":"   msg-id
   2768                  /  "In-Reply-To"       ":"  *(phrase / msg-id)
   2769                  /  "References"        ":"  *(phrase / msg-id)
   2770                  /  "Keywords"          ":"  #phrase
   2771                  /  "Subject"           ":"  *text
   2772                  /  "Comments"          ":"  *text
   2773                  /  "Encrypted"         ":" 1#2word
   2774                  /  extension-field              ; To be defined
   2775                  /  user-defined-field           ; May be pre-empted
   2776      orig-date   =  "Date"        ":"   date-time
   2777      originator  =   authentic                   ; authenticated addr
   2778                    [ "Reply-To"   ":" 1#address] )
   2779      phrase      =  1*word                       ; Sequence of words
   2780 
   2781 
   2782 
   2783 
   2784      August 13, 1982              - 45 -                      RFC #822
   2785 
   2786 
   2787  
   2788      Standard for ARPA Internet Text Messages
   2789 
   2790 
   2791      qtext       =  <any CHAR excepting <">,     ; => may be folded
   2792                      "\" & CR, and including
   2793                      linear-white-space>
   2794      quoted-pair =  "\" CHAR                     ; may quote any char
   2795      quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or
   2796                                                  ;   quoted chars.
   2797      received    =  "Received"    ":"            ; one per relay
   2798                        ["from" domain]           ; sending host
   2799                        ["by"   domain]           ; receiving host
   2800                        ["via"  atom]             ; physical path
   2801                       *("with" atom)             ; link/mail protocol
   2802                        ["id"   msg-id]           ; receiver msg id
   2803                        ["for"  addr-spec]        ; initial form
   2804                         ";"    date-time         ; time received
   2805 
   2806      resent      =   resent-authentic
   2807                    [ "Resent-Reply-To"  ":" 1#address] )
   2808      resent-authentic =
   2809                  =   "Resent-From"      ":"   mailbox
   2810                  / ( "Resent-Sender"    ":"   mailbox
   2811                      "Resent-From"      ":" 1#mailbox  )
   2812      resent-date =  "Resent-Date" ":"   date-time
   2813      return      =  "Return-path" ":" route-addr ; return address
   2814      route       =  1#("@" domain) ":"           ; path-relative
   2815      route-addr  =  "<" [route] addr-spec ">"
   2816      source      = [  trace ]                    ; net traversals
   2817                       originator                 ; original mail
   2818                    [  resent ]                   ; forwarded
   2819      SPACE       =  <ASCII SP, space>            ; (     40,      32.)
   2820      specials    =  "(" / ")" / "<" / ">" / "@"  ; Must be in quoted-
   2821                  /  "," / ";" / ":" / "\" / <">  ;  string, to use
   2822                  /  "." / "[" / "]"              ;  within a word.
   2823      sub-domain  =  domain-ref / domain-literal
   2824      text        =  <any CHAR, including bare    ; => atoms, specials,
   2825                      CR & bare LF, but NOT       ;  comments and
   2826                      including CRLF>             ;  quoted-strings are
   2827                                                  ;  NOT recognized.
   2828      time        =  hour zone                    ; ANSI and Military
   2829      trace       =    return                     ; path to sender
   2830                     1*received                   ; receipt tags
   2831      user-defined-field =
   2832                    <Any field which has not been defined
   2833                     in this specification or published as an
   2834                     extension to this specification; names for
   2835                     such fields must be unique and may be
   2836                     pre-empted by published extensions>
   2837      word        =  atom / quoted-string
   2838 
   2839 
   2840 
   2841 
   2842      August 13, 1982              - 46 -                      RFC #822
   2843 
   2844 
   2845  
   2846      Standard for ARPA Internet Text Messages
   2847 
   2848 
   2849      zone        =  "UT"  / "GMT"                ; Universal Time
   2850                                                  ; North American : UT
   2851                  /  "EST" / "EDT"                ;  Eastern:  - 5/ - 4
   2852                  /  "CST" / "CDT"                ;  Central:  - 6/ - 5
   2853                  /  "MST" / "MDT"                ;  Mountain: - 7/ - 6
   2854                  /  "PST" / "PDT"                ;  Pacific:  - 8/ - 7
   2855                  /  1ALPHA                       ; Military: Z = UT;
   2856      <">         =  <ASCII quote mark>           ; (     42,      34.)
   2857 
   2858 
   2859 
   2860 
   2861 
   2862 
   2863 
   2864 
   2865 
   2866 
   2867 
   2868 
   2869 
   2870 
   2871 
   2872 
   2873 
   2874 
   2875 
   2876 
   2877 
   2878 
   2879 
   2880 
   2881 
   2882 
   2883 
   2884 
   2885 
   2886 
   2887 
   2888 
   2889 
   2890 
   2891 
   2892 
   2893 
   2894 
   2895 
   2896 
   2897 
   2898 
   2899 
   2900      August 13, 1982              - 47 -                      RFC #822
   2901