home *** CD-ROM | disk | FTP | other *** search
/ kermit.columbia.edu / kermit.columbia.edu.tar / kermit.columbia.edu / public_html / rfc822.txt < prev    next >
Text File  |  1988-04-10  |  106KB  |  2,902 lines
  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.  
  2902.