doc: Add RFC documents

1 files changed, 1869 insertions, 0 deletions

diff --git a/doc/rfc/rfc724.txt b/doc/rfc/rfc724.txt
new file mode 100644
index 0000000..ff6b123
--- /dev/null
+++ b/doc/rfc/rfc724.txt
@@ -0,0 +1,1869 @@
+
+
+
+
+     RFC #  724
+     NIC #37435                                            12 May 1977
+
+
+
+
+
+
+
+
+
+
+
+
+                    Proposed Official Standard for the
+                      Format of ARPA Network Messages
+
+
+
+
+
+
+
+
+
+
+                                    by
+
+
+              Ken Pogran, MIT-LCS/CSR    (Pogran at MIT-Multics)
+              John Vittal, BBN            (Vittal at BBN-TENEXA)
+              Dave Crocker, RAND-ISD     (DCrocker at Rand-Unix)
+              Austin Henderson, BBN    (Henderson at BBN-TENEXD)
+
+
+
+     Proposed Standard for Message Format                         / ii
+
+
+
+
+
+                                  PREFACE
+
+
+
+          ARPA's  Committee  on  Computer-Aided  Human   Communication
+     (CAHCOM) wishes to promulgate an official standard for the format
+     of ARPA Network mail headers which will adequately meet the needs
+     of  the  various message service subsystems on the Network today.
+     The authors  of  this  RFC  constitute  the  CAHCOM  subcommittee
+     charged  with  the  task  of  developing  this new standard; this
+     document presents our  current  thoughts  on  the  matter  and  a
+     specific proposal.
+
+          This document is organized as follows: First, we  present  a
+     history,  of the development of what has become known as the ARPA
+     Network "mail" or "message" service, and the issues which we feel
+     are  most  pressing  --  problems for which solutions are lacking
+     today, inhibiting the further development of message  subsystems.
+     We  then  present  the  specification  for  the  new ARPA Network
+     Message Header  standard.   This  is  followed  by  a  References
+     section.
+
+          Essentially, we propose a revision to Request  for  Comments
+     (RFC)  561,  "Standardizing  Network  Mail Headers", and RFC 680,
+     "Message  Transmission  Protocol".   This  revision  removes  and
+     compacts  portions  of  the  previous  syntax  and  adds  several
+     features to network address  specification.   In  particular,  we
+     focus  on  people  and  not  mailboxes  as  recipients  and allow
+     reference to stored address lists.   We  expect  this  syntax  to
+     provide  sufficient  capabilities  to  meet most users' immediate
+     needs and, therefore, give developers enough  breathing  room  to
+     produce  a new mail transmission protocol "properly".  We believe
+     that there is enough of a consensus in the Network  community  in
+     favor  of such a standard syntax to make possible its adoption at
+     this time.
+
+          We would like to make clear  the  status  of  this  proposed
+     standard:  The CAHCOM Steering Committee has replaced the Message
+     Service Committee as the ARPANET  standards-setting  organization
+     in  the  area  of  message  services.   It  is  expected that the
+     proposal of this CAHCOM subcommittee, when  in  its  final  form,
+     will  be  adopted  as  an  ARPANET  standard  by  CAHCOM.  In the
+     interests of making this standard the best possible one,  we  are
+     distributing  this  proposal as an RFC.
+
+          Please send any  comments  and  criticisms  to  any  of  the
+     authors  of  this  RFC  by  15 June 1977.  It is planned that the
+     standard will be officially adopted by  1  September  1977,  with
+     hosts expected to accept its syntax by 1 January 1978.
+
+
+
+     Proposed Standard for Message Format                        / iii
+
+
+
+
+
+
+
+
+
+
+
+                             CONTENTS
+
+
+
+                  I.  PROBLEMS WITH ARPANET
+                      MESSAGE STANDARDS
+
+                      A.  Background and History
+                      B.  Issues and Conclusions
+                      C.  Message Parts
+                      D.  Adoption of the Standard
+
+
+
+                 II.  STANDARD FOR THE FORMAT
+                      OF ARPA NETWORK MESSAGES
+
+                      A.  Framework
+                      B.  Syntax
+                      C.  Semantics
+                      D.  Examples
+
+
+
+                III.  REFERENCES
+
+
+
+
+                              APPENDIX
+
+                  A.  Alphabetical Listing of Syntax Rules
+
+
+
+     I. Problems with ARPANET Message Standards                    / 1
+     A. Background and History
+
+
+
+
+
+              I.  PROBLEMS WITH ARPANET MESSAGE STANDARDS
+
+
+
+     A.  BACKGROUND AND HISTORY
+
+
+          Today's ARPA Network "mail" or "message" service  uses,  for
+     its delivery mechanism, two special commands of the File Transfer
+     Protocol.  Viewed from within the structure of  FTP,  the  entire
+     message,  both header and text, is data for the FTP MAIL and MLFL
+     commands.  This facility was added to the File Transfer  Protocol
+     as  an  afterthought;  it was an interim solution to be used only
+     until  a  separate  mail  transmission  protocol  was  specified.
+     Several  versions of such a protocol have been proposed, but none
+     has yet received general acceptance.   Meanwhile,  attempts  have
+     been made to improve upon the original interim facility.
+
+          As  message  service  subsystems  on  various  host  systems
+     (especially  TENEX)  developed  to  the  point  where rudimentary
+     parsing of incoming messages was being done, it became clear that
+     it  would  be  desirable to standardize the format and content of
+     the headers of messages transmitted between hosts using these FTP
+     commands.   To this end, an ad hoc committee wrote RFC 561, which
+     suggested a standard message header format.   The  committee  was
+     unofficial,  so  it could not legislate a standard, it could only
+     recommend.  However, the standard it suggested adequately met  an
+     urgent need, and was generally adopted.
+
+          Several  salient  points should be noted:
+
+          1. RFC 561 defined the concept  of  a  message  header,  and
+             specified  the  syntax which delimited it from the actual
+             text of a message;
+
+          2. It proposed a standard format for the  most  obvious  and
+             most  urgently-needed header items: "From:", "Date:", and
+             "Subject:";
+
+          3. It proposed that a general standard syntax  be  used  for
+             all other header items;
+
+          4. RFC 561 is still, today, an unofficial standard,  adhered
+             to by most because of its utility;
+
+          5. Its syntax was designed to allow humans to read the  text
+             easily,  without  the  aid  of special message processing
+             systems.
+
+
+
+     I. Problems with ARPANET Message Standards                    / 2
+     A. Background and History
+
+
+
+          As message services grew in  sophistication,  the  need  for
+     specific header items in RFC 561's "miscellaneous" category grew:
+     "To:" and "cc:", especially, were  generated  and  recognized  by
+     several  different  message  services.   However,  there  was  no
+     specific standard for the syntax of the contents of these  items.
+     The  message  service  subsystems on TENEX developed a particular
+     format for these items; since more messages originated  from  the
+     TENEX  hosts  on  the  Network  than  from any other type of host
+     system, the TENEX format for these fields soon became a de  facto
+     standard.   Message  service  subsystems  on TENEX began to parse
+     these fields, expecting them to be in the TENEX-generated format.
+     Message service subsystems on other hosts -- Multics, for example
+     -- began to dabble with other formats  for  these  fields,  since
+     there  was  no standard for them, only to receive complaints from
+     users of  TENEX  message  service  subsystems  that  their  "non-
+     standard"  message  headers  could not be parsed according to the
+     (de facto) "standard" syntax.
+
+          Recognizing that the time had come to  make  an  attempt  to
+     standardize  the  additional header fields that had come into use
+     since RFC 561 was published,  ARPA's  Message  Service  Committee
+     chartered  a  small group in 1975 to develop a revised version of
+     RFC 561 which would define the syntax of these additional message
+     header  fields.   Several things should be noted about this small
+     group of  people:  first,  they  were  TENEX-oriented;  when  the
+     functionality  of  the  message  header  items  they  desired was
+     matched by  the  functionality  of  an  already-existing  message
+     header  item  of  the  TENEX message subsystems, they adopted the
+     syntax used by the TENEX message subsystems.  Second, they  based
+     additional  header  items  not  already  found  on  TENEX message
+     subsystems on the deliberations of the Message Service Committee.
+     Third,  they were not familiar with the procedure for publication
+     of a document as a Network RFC.
+
+          The document which this group produced,  labelled  RFC  680,
+     "Message    Transmission   Protocol",   received   only   limited
+     distribution.  Matters were further confused  because  its  title
+     was  misleading, since it was not a protocol for the transmission
+     of messages between ARPA Network hosts, but rather a standard for
+     the format of messages transmitted via the standard File Transfer
+     Protocol.    Some,   including  the  Message  Service  Committee,
+     believed that RFC 680 became a Network Standard.   This  was  not
+     strictly true, because it never received proper distribution, and
+     it had never been "officially blessed" by anyone, to turn it from
+     a  request  for  comments  into an accepted official ARPA Network
+     standard document.  Reflecting this confusion over the status  of
+     the  document  are  the  facts  that  the document DOES currently
+     reside in the "official"  ARPANET  Protocol  Handbook,  and  most
+     users and message system implementors remain unaware that this is
+     so.
+
+
+
+     I. Problems with ARPANET Message Standards                    / 3
+     A. Background and History
+
+
+
+          For all its shortcomings, RFC 680  has  performed  a  needed
+     service,  just  as  did RFC 561 before it.  It defined additional
+     message header items at a time  when  this  needed  to  be  done.
+     Unfortunately,  since  the  group  had not sought ideas and input
+     from others, the specification did not adequately  respond  to  a
+     sufficient  set  of  community needs.  In addition, the manner in
+     which the document was promulgated -- or not promulgated --  left
+     a great deal to be desired.  Implementators of message-processing
+     subsystems who had not received RFC 680 proceeded to go their own
+     ways, feeling justified in doing so, while those who accepted RFC
+     680 as a standard felt justified in complaining to --  and  about
+     --  those  whom  they  considered  to be maverick implementors of
+     idiosyncratic message service subsystems.
+
+          Perhaps because of the ad-hoc nature  of  the  interim  mail
+     facility,  users  have not, until recently, attempted to push the
+     system to the limits of their imagination.   Presently,  however,
+     several different sites are using the "interim" mail facility for
+     more than it was designed and in ways which are incompatible both
+     with  each  other  and  with the original intent of the facility.
+     Mail subsystem  implementors  are  increasingly  being  asked  to
+     provide for the handling of mail from idiosyncratic hosts.  Also,
+     it has become clear that there are a few very  specific features,
+     too useful to ignore, which cannot reasonably be specified within
+     the syntax of RFC 680.
+
+
+
+     B.  ISSUES AND CONCLUSIONS
+
+
+          At first glance, it would seem that a resolution of  today's
+     somewhat  chaotic situation could best be obtained by immediately
+     junking the existing "interim" mail facility, and adopting a true
+     mail  transmission protocol.  We strongly believe that this would
+     be ill-advised at this time, for we feel that there is no general
+     understanding  within  the  Network  community  today  of  how to
+     specify and implement  a  full  and  adequate  mail  transmission
+     protocol.   However,  we  are convinced that there is, finally, a
+     strong commitment within the Network  community  to  attack  this
+     problem  (which  there  was  not  at  the time the "interim" mail
+     transmission facility was specified and developed).
+
+          The frontal attacks on the mail protocol  problem  have,  so
+     far, resulted in at least two suggestions for a mail transmission
+     protocol.  Why should not  one  of  these  protocols  be  adopted
+     immediately? We feel that, in general, there has been a  tendency
+     for  experimental  Network  software to be prematurely treated as
+     though  it  were  adequately  designed  and  fully   operational.
+     Typically, the system or protocol proposed is so much better than
+     what was previously available that  its  experimental  nature  is
+     disregarded,  and  it is pressed into service before it has had a
+
+
+     I. Problems with ARPANET Message Standards                    / 4
+     B. Issues and Conclusions
+
+
+
+     chance to properly develop and mature.   We  are  very  concerned
+     that this phenomenon not afflict the Network mail system any more
+     than it already has.
+
+          While it is true that there are several sites  in  the  ARPA
+     Community  which  have  mail  systems  that understand the syntax
+     specified in RFC's 561 and 680, in addition to some of the  "non-
+     standard"  syntax  provided  by  the  mail generating programs at
+     several other sites, most mail systems do not parse much  of  the
+     contents  of  received  messages.   A consideration of the syntax
+     specified here is that messages which are sent to  people  should
+     be  easily  read  by  people.   Parsers  which  can turn an ugly,
+     syntactically expedient form into something which is easy to read
+     are  the  exception,  rather  than  the  rule, in today's message
+     systems.  Also, the modifications to the existing  "non-standard"
+     syntax  should  be  kept  to a minimum, enhancing the probability
+     that the requirement of small perturbations to existing  software
+     will be accepted.
+
+          With this syntax, we introduce mechanisms so that:
+
+          1. Users of mail systems can have multiple mailboxes, either
+             on  one  machine  or  multiple machines, all of which are
+             treated identically; the default mailbox for  a  user  is
+             not  necessarily  associated  (directly)  with  his login
+             name.
+
+          2. Mail for a person can be sent to  other  than  a  single,
+             default mailbox.
+
+          3. Named   groups  may  consist  of  both  individuals   and
+             (possibly)  other  named  groups  (i.e.,  nesting  within
+             groups is permitted).
+
+          4. Address lists may contain references  to  other,  stored,
+             lists.  The complete path with which one can retrieve the
+             stored list may be specified in  order  to  allow  either
+             manual or automatic retrieval of the stored list.
+
+          5. Address lists may contain references to  addresses  which
+             are  not  accessible through the standard ARPANET message
+             system.  For example, U.S.  Postal system  addresses  can
+             be specified.  Such addresses are, of course, expected to
+             be ignored by the  ARPANET  system,  although  individual
+             sites  may  provide  services  for  using the information
+             (e.g., automatically sending a copy of the  message to  a
+             line printer, in preparation for transmission through the
+             Postal system).
+
+          6. Parenthetical remarks, or comments, can be  included  and
+             syntactically  recognized  as  such  within  some  header
+             items.
+
+
+     I. Problems with ARPANET Message Standards                    / 5
+     B. Issues and Conclusions
+
+
+
+          7. Received messages are capable of  being  read  by  humans
+             without  a  program having to parse the message (or parts
+             of it) before presenting the message to the user; however
+             there  is  sufficient  formal  syntax to enable a parsing
+             program to modify the appearance and content of  material
+             presented  to  users.   Although message-display software
+             may   exercise   considerable   control   over    message
+             appearance, the degree to which a message's actual format
+             is  PLEASANT  for  humans  to  read   is   entirely   the
+             responsibility of the message creation program.
+
+     No mechanism for authentication is provided,  since  the  Network
+     provides  no  mechanisms for enforcing mail security.  The syntax
+     does provide for one aspect of "correctness":  a  distinction  is
+     made  between  an  address which is claimed to be a valid network
+     address and one which is  simply  free  text,  included  for  the
+     convenience of the human participants.
+
+
+
+
+     C. MESSAGE PARTS
+
+          Some  confusion  has  existed  over  the  roles  played   by
+     different message parts.  Einar Stefferud has suggested using the
+     perspective of envelope, letter head, and  letter  content.   The
+     presence of structured portions in messages additionally requires
+     reference to "headers".
+
+          In  computer-based  message  systems,  human  users  do  not
+     generally  encounter  "envelopes",  which  are  often constructed
+     automatically, to be  used  by  the  participating  system(s)  to
+     deliver  the  message.  For example on TENEX, the envelope is the
+     name of the file containing a message awaiting transmission.  For
+     FTP  servers,  it is the data portion of the MAIL or MLFL command
+     line.  Some systems attach  "envelope-like"  information  to  the
+     message header, such as time-stamp and originating host name.
+
+          In paper-based communications,  headers  occur  both  before
+     (e.g., "To:" and "From:" and after (e.g., "cc:" and "enclosure:")
+     the body of the message.  Within this standard, all headers occur
+     before  the  body  of the message, although local message display
+     programs may choose to alter that ordering.
+
+          Wayne Hathaway has pointed out that ARPANET  message  format
+     does not support specification of letterheads, since these are  a
+     type   of   organizational   public   relations   symbol.    Some
+     idiosyncrasies are supported, however, by way of choosing special
+     field names.
+
+          In general, it is  important  to  realize  that  the  header
+     portion  of  a  message  plays several roles during the life of a
+
+
+     I. Problems with ARPANET Message Standards                    / 6
+     C. Message Parts
+
+
+
+     message, variously participating in each of the  three  functions
+     suggested by Stefferud.
+
+
+
+     D. ADOPTION OF THE STANDARD
+
+
+         During the early phases of specifying this standard, a  great
+     deal  of  concern  was  expressed  over the problems which may be
+     experienced during the transition from the  current  standard  to
+     this  new  one.   We  feel  that  the true problem is the lack of
+     realization that THERE IS NO CURRENT OFFICIAL  STANDARD.   Enough
+     systems  have  enough  overlapping behaviors to allow the current
+     mail environment to function, but this in no  way  constitutes  a
+     standard.
+
+          In fact, we  strongly  believe  that  the  new  requirements
+     imposed by the proposed standard involve less complexity than the
+     ambiguities resulting  from  the  current  variations  in  system
+     behaviors.
+
+
+
+     II. Standard for the Format of Messages                       / 7
+
+
+
+
+
+
+
+                     II. STANDARD FOR THE FORMAT
+                         OF ARPA NETWORK MESSAGES
+
+
+
+          This standard supercedes the informal standards specified in
+     ARPANET  Request for Comments numbers 561, "Standardizing Network
+     Mail Headers", and 680, "Message Transmission Protocol".  In this
+     document, a general framework is described.  The formal syntax is
+     then specified,  followed  by  a  discussion  of  the  semantics.
+     Finally, a number of examples are given.
+
+          This specification is intended strictly as a  definition  of
+     what is to be passed  between hosts  on the  ARPANET.   It is NOT
+     intended to dictate either features which systems on the  Network
+     are  expected  to support, or user interfaces to message creating
+     or reading programs.
+
+          A distinction should be made between what the  specification
+     requires  and  what it allows.  Certain equivalences are defined,
+     such as between a space  character  <space>  and  an  end-of-line
+     character  <crlf>, which both facilitate the formal specification
+     and indicate  what  the  OFFICIAL  semantics  are  for  messages.
+     Particular   implementations   may   wish   to  preserve  further
+     distinctions which the specification does not require.
+
+
+
+     A. FRAMEWORK
+
+
+          Since there are many message systems which exist outside the
+     ARPANET environment, as well as those within it, it may be useful
+     to consider the general framework, and resulting capabilities and
+     limitations, of this standard.
+
+          Messages are expected to  consist  of  lines  of  text.   No
+     special provisions are made, at this time, for encoding drawings,
+     facimile, speech, or structured text.
+
+          No significant consideration has been given to questions  of
+     data   compression   or   transmission/storage  efficiency.   The
+     standard, in fact, tends to be very free with the number of  bits
+     consumed.   For  example, field names are specified as free text,
+     rather than special terse codes.
+
+          A general "memo" framework is  used.   That  is,  a  message
+     consists  of some information, in a rigid format, followed by the
+     main part of the message, which is text  and whose format is  not
+
+
+     II. Standard for the Format of Messages                       / 8
+      A. Framework
+
+
+
+     specified  in this document.  The syntax of several fields of the
+     rigidly-formated  ("header")   section   is   defined   in   this
+     specification;  some of the header fields must be included in all
+     messages.  In addition to the fields specified in this  document,
+     it  is  expected  that  other fields will gain common use.  User-
+     defined header fields allow systems to extend their functionality
+     while  maintaining  a uniform framework.  Our approach is similar
+     to that of the TELNET protocol, in that we are defining  a  basic
+     standard which includes a mechanism  for  (optionally)  extending
+     itself.    The   authors  of  this  document  will  regulate  the
+     publishing of specifications for these extensions.
+
+          Such a framework severely  constrains  document  "tone"  and
+     appearance  and  is  primarily useful for most intra-organization
+     communications  and  relatively   structured   inter-organization
+     communication.   A more robust environment might allow for multi-
+     font, multi-color, multi-dimension encoding  of  information.   A
+     less  robust  environment,  as  is present in most single-machine
+     message systems, would more severely constrain the ability to add
+     fields  and the decision to include specific fields.  Relative to
+     paper-based communication, it is interesting  to  note  that  the
+     RECEIVER  of  a  message  can exercise an extraordinary amount of
+     control over the message's  appearance.   The  amount  of  actual
+     control  available  to  message  receivers is contingent upon the
+     capabilties of their individual message systems.
+
+
+
+     II. Standard for the Format of Messages                       / 9
+      B. Syntax
+
+
+
+
+
+     B.  SYNTAX
+
+
+          This  syntax  is  given  in  four  parts.   The  first  part
+     describes  a  base-level lexical analyzer which feeds the higher-
+     level parser described in the succeeding  sections.   The  second
+     part  gives  a  general  syntax  for messages and standard header
+     fields.  The third part specifies the  syntax  of  addresses.   A
+     final  section  specifies  some general syntax which supports the
+     other sections.
+
+
+
+     1.  LEXICAL ANALYSIS OF MESSAGES
+
+
+     a.  General Description
+
+         A message consists of headers and, optionally, a  body  (i.e.
+         the  <message-text>).   The  <message-text>  part  is  just a
+         sequence of  ASCII  characters;  it  is  separated  from  the
+         headers  by  a null line (i.e., a line with nothing preceding
+         the <crlf>).
+
+         1) Folding and unfolding of headers
+
+            Each header item can be viewed as a single, logical,  long
+            line   of   ASCII   characters.    For  convenience,  this
+            conceptual  entity  can  be  split  into  a  multiple-line
+            representation (i.e., "folded").  The general rule is that
+            wherever there can be <linear-white-space> characters, you
+            can  instead  insert  a  <crlf> immediately followed by AT
+            LEAST  one  <linear-white-space>  character.   Thus,   the
+            single line
+
+               To:  "Joe Dokes & J. Harvey" <ddd at Host>, JJV at BBN
+
+            can be represented as
+
+               To:  "Joe Dokes & J. Harvey" <ddd at Host>,
+                    JJV at BBN
+
+            and
+
+               To:  "Joe Dokes & J. Harvey"
+                                <ddd at Host>,
+                JJV at BBN
+
+
+
+     II. Standard for the Format of Messages                      / 10
+      B. Syntax
+      1. Lexical Analysis
+
+
+
+            and
+
+               To:  "Joe Dokes
+                & J. Harvey" <ddd at Host>, JJV at BBN
+
+            The process  of  moving  from  this  folded  multiple-line
+            representation  of  a  header  field  to  its  single line
+            representation will be called "unfolding".   Unfolding  is
+            accomplished by regarding <crlf> immediately followed by a
+            <linear-white-space-char> as equivalent  to  the  <linear-
+            white-space-char>.
+
+
+         2) Structure of header fields
+
+            Once header fields have been unfolded, they may be  viewed
+            as  being  composed  of  a  <field-name> followed by a ":"
+            (colon), followed by  a  <field-body>.   The  <field-name>
+            must  be  composed  of  printable  ASCII characters (i.e.,
+            characters which have decimal values between 33  and  126)
+            and <linear-white-space> characters.  The <field-body> may
+            composed of any ASCII  characters  (other  than  <cr>  and
+            <lf>, which have been removed by unfolding).
+
+            Certain header fields may be interpreted according  to  an
+            internal  syntax  which  some  systems  may wish to parse.
+            These fields will be referred  to  as  structured  fields.
+            Examples  include  fields  containing dates and addresses.
+            Other fields, such as  the  subject  field,  are  regarded
+            simply as a single line of text.
+
+         3) Field names
+
+            To aid in the creation and reading of  <field-name>s,  the
+            free   insertion  of  <linear-white-space>  characters  is
+            allowed in reasonable places.  Rather than  obscuring  the
+            syntax  specification  for  <field-name> with the explicit
+            syntax  for  these  <linear-white-space>  characters,  the
+            existence  of a simple "lexical" analyzer is assumed.  The
+            analyzer reinterprets the unfolded  text  which  comprises
+            the  <field-name>  as  a  sequence of <atoms> separated by
+            <linear-white-space> characters.  The field  name  may  be
+            conveniently  represented  by the sequence of these atoms,
+            separated by a single ASCII space character.
+
+
+
+     II. Standard for the Format of Messages                      / 11
+      B. Syntax
+      1. Lexical Analysis
+
+
+
+         4) Field bodies
+
+            To aid in the creation and reading  of  structured fields,
+            the  free  insertion of <linear-white-space> characters is
+            allowed in reasonable places.  Rather than  obscuring  the
+            syntax specifications for  these  structured  fields  with
+            explicit syntax for these <linear-white-space> characters,
+            the existence of  another  simple  "lexical"  analyzer  is
+            assumed.   It  provides  an interpretation of the unfolded
+            text comprising the body of the field  as  a  sequence  of
+            lexical symbols.  These include
+
+                    -  individual special characters
+                    -  quoted strings
+                    -  comments
+                    -  atoms
+
+            The first three symbols are  self-delimiting.   Atoms  are
+            not;  they  therefore are delimited by the self-delimiting
+            symbols and by <linear-white-space>.
+
+            So, for example, the folded body of an address field
+
+                    ":sysmail"@ Some-Host,
+                    Muhammed(I am the greatest)Ali at WBA
+
+            is analyzed into the following lexical symbols and types:
+
+                    ":sysmail"              quoted string
+                    @                       special
+                    Some-Host               atom
+                    ,                       special
+                    Muhammed                atom
+                    (I am the greatest)     comment
+                    Ali                     atom
+                    at                      atom
+                    WBA                     atom
+
+
+     b.  Formal Definition
+
+         <field>           ::=   <field-name> ":" <field-body>
+         <field-name>      ::=   <atom>
+                               | <atom> <field-name>
+
+         <field-body>      ::=   <field-body-contents>
+                               | <field-body-contents> <crlf>
+                                    <linear-white-space-char>
+                                    <field-body>
+
+
+
+     II. Standard for the Format of Messages                      / 12
+      B. Syntax
+      1. Lexical Analysis
+
+
+
+         <field-body-contents> ::= <the TELNET ASCII characters making
+                                    up the <field-body>, as defined in
+                                    the following sections, and
+                                    consisting of combinations of
+                                    <atom>, <quoted-string>, <text-line>,
+                                    and <specials> tokens>
+
+         <atom>            ::=   <a sequence of one or more TELNET
+                                    ASCII alpha-numeric or graphics
+                                    characters, excluding all control
+                                    characters (those characters with
+                                    a decimal value less than 33 or
+                                    equal to 127) and <delimeters> >
+
+         <quoted-string>   ::=   <double quote mark ("), decimal 34>
+                                    <a sequence of one or more TELNET
+                                    ASCII characters, where two
+                                    adjacent quotes are treated as a
+                                    single quote and part of the
+                                    string> <">
+
+         <text-line>        ::=   <a sequence of one or more TELNET
+                                    ASCII characters excluding <cr>
+                                    and <lf> >
+
+         <message-text>     ::=   <a sequence of zero of more TELNET
+                                    ASCII characters>
+
+         <delimeters>      ::=   <specials> | <comment>
+                               | <linear-white-space> | <crlf>
+
+         <specials>        ::=   "(" | ")" | "<" | ">"
+                               | "@" | "," | ";" | ":" | <">
+
+         <comment>         ::=   "(" <TELNET ASCII characters, except
+                                    <crlf> > ")"
+
+         <linear-white-space>::= <linear-white-space-char>
+                               | <linear-white-space-char>
+                                    <linear-white-space>
+         <linear-white-space-char>::=  <space> | <horizontal-tab>
+
+         <space>           ::=   <TELNET ASCII space (decimal 32)>
+         <tab>             ::=   <TELNET ASCII tab   (decimal  9)>
+         <cr>              ::=   <TELNET ASCII carriage return
+                                    (decimal 13)>
+         <lf>              ::=   <TELNET ASCII line feed (decimal 10)>
+         <crlf>            ::=   <TELNET ASCII carriage return/line
+                                  feed (decimal 13, followed by
+                                  decimal 10)>
+
+
+
+     II. Standard for the Format of Messages                      / 13
+      B. Syntax
+      1. Lexical Analysis
+
+
+
+     c.  Clarifications
+
+         1) Comments
+
+            Comments  may  appear   only   within   <field-body>s   of
+            structured fields.   A  comment is any set of TELNET ASCII
+            characters, which is not within a quoted string, and which
+            is  enclosed in matching parentheses; parentheses nest, so
+            that if a left paren occurs in  a  comment  string,  there
+            must also be a matching right paren.
+
+            Comments are NOT passed to the FTP server, as  part  of  a
+            MAIL  or  MLFL command, since comments are not part of the
+            "formal" address.
+
+
+         2) "White space"
+
+            Remember that in structured fields, MULTIPLE LINEAR  WHITE
+            SPACE TELNET ASCII CHARACTERS (namely <tab>s and <space>s)
+            ARE TREATED AS SINGLE SPACES AND MAY FREELY  SURROUND  ANY
+            SYMBOL.   In  all  header  fields, at least one <space> is
+            REQUIRED only at the beginning of folded lines.
+
+            Writers of mail-sending (i.e.  header generating) programs
+            should realize that there is no Network-wide definition of
+            the  effect  of  <tab>  TELNET  ASCII  characters  on  the
+            appearance of text at another Network host; therefore, the
+            use of <tab>s in message  headers,  though  permitted,  is
+            discouraged.
+
+            Note that the contents of messages are required to conform
+            with  TELNET  NVT conventions (e.g.  <cr> must be followed
+            by either <lf>, making a <crlf>, or <null>, if the <cr> is
+            to stand alone).
+
+         3) Quoted strings
+
+            Where  permitted  (i.e.,  in  structured  fields)   quoted
+            strings  are  treated as a single symbol (i.e.  equivalent
+            to an <atom> syntactically).  However, if  quoted  strings
+            are  to  be  "folded" onto multiple lines, then the syntax
+            for folding must be  adhered  to  (See  items  II.B.1.a.1,
+            above,  and  II.B.1.c.6,  below.)  Note  that the official
+            semantics do not  encounter  <crlf>s  in  quoted  strings,
+            although  particular  parsing  programs  may  wish to note
+            their presence.
+
+
+
+     II. Standard for the Format of Messages                      / 14
+      B. Syntax
+      1. Lexical Analysis
+
+
+
+         4) Bracketing characters
+
+            There are two types of brackets which must be well nested:
+
+                - Parentheses are used to indicate comments.
+
+                - Angle brackets  ("<"  and  ">")  are  used
+                  where  there is a question of the presence
+                  of machine-usable code (e.g.  deliminating
+                  mailboxes).
+
+         5) Case independence of certain specials <atom>s
+
+            It should be assumed by all  mail  reading  programs  that
+            certain  <atom>s  can be represented in any combination of
+            upper and lower case.  These are:
+
+                - <field-name>s,
+                - "File", in a <path>,
+                - "at", in an <at-indicator>,
+                - <host-name>s,
+                - <day-of-week>s,
+                - <string-month>s, and
+                - <time-zone>s
+
+            For example, the <field-name>s "From", "FROM", "from", and
+            even "FroM" should all be treated identically.  Note that,
+            at the level of this specification, case  IS  relevant  to
+            other   <word>s   and   <text-line>s.   Also  see  Section
+            II.C.1.a.4, below.
+
+         6) Folding long lines
+
+            Each header item (field of the message) may be represented
+            on  exactly  one  line consisting of the name of the field
+            and its body, and this  is  what  the  parser  sees.   For
+            readability,  it  is  recommended  that  the  <field-body>
+            portion of long header items  be  "folded"  onto  multiple
+            lines of the actual header.
+
+
+         7) Backspace characters
+
+            Backspace TELNET ASCII characters (ASCII  BS,  decimal  8)
+            may  be  included  in  <text-line>  and <quoted-string> to
+            effect overstriking; however, any use of backspaces  which
+            effects  an overstrike to the left of the beginning of the
+            <text-line> or <quoted-string> is prohibited.
+
+
+
+
+     II. Standard for the Format of Messages                      / 15
+      B. Syntax
+      2. Messages
+
+
+
+     2.  GENERAL SYNTAX OF MESSAGES:
+
+         NOTE: The syntax indicates that items  in  <required-headers>
+         must  be  in  a  specific  order and precede all other header
+         items.  Header fields, in fact, are NOT required to occur  in
+         any  particular  order.  Required header items must be unique
+         (occur exactly once).  This  specification  permits  multiple
+         occurrences   of   most   optional   fields.    However,  the
+         interpretation of such multiple occurrences is not  specified
+         here.
+
+         <message>         ::=   <headers>
+                               | <headers> <crlf> <message-text>
+
+         <headers>         ::=   <required-headers>
+                               | <required-headers> <optional-headers>
+         <required-headers> ::=  <date-field> <originator>
+         <originator>      ::=   <mach-from-field>
+                               | <mach-from-list> <sender-field>
+                               | <mach-from-field> <reply-to-field>
+                               | <any-from-field> <sender-field>
+                                    <reply-to-field>
+
+         <date-field>      ::=   "Date"        ":" <date-time>
+         <mach-from-field> ::=   "From"        ":" <mach-addr-item>
+         <mach-from-list>  ::=   "From"        ":" <mach-addr-list>
+         <any-from-field>  ::=   "From"        ":" <address-list>
+         <sender-field>    ::=   "Sender"      ":" <host-phrase>
+         <reply-to-field>  ::=   "Reply-To"    ":" <mach-addr-list>
+
+         <optional-headers>::=   <optional-header-field>
+                               | <optional-headers>
+                                    <optional-header-field>
+
+         <optional-header-field> ::= <addressee-field>
+                               | <extension-field>
+
+         <addressee-field> ::=   "To"          ":" <address-list>
+                               | "cc"          ":" <address-list>
+                               | "bcc"         ":" <address-list>
+                               | "Fcc"         ":" <path-list>
+
+         <extension-field> ::=   "In-Reply-To" ":" <reference-list>
+                               | "Keywords"    ":" <phrase-list>
+                               | "Message-Id"  ":" <mach-host-phrase>
+                               | "References"  ":" <reference-list>
+                               | "Subject"     ":" <text-line>
+                               | "Comments"    ":" <text-line>
+                               | <user-defined-field>
+
+
+
+     II. Standard for the Format of Messages                      / 16
+      B. Syntax
+      2. Messages
+
+
+
+         <user-defined-field> ::= <A <field> which has a <field-name>
+                                    not defined in this specification>
+
+
+
+     The following syntax for the bodies of various fields  should  be
+     thought  of as describing each field body as a single long string
+     (or line).  The section  on  Lexical  Analysis  (section  II.B.1)
+     indicated  how  such long strings can be represented on more than
+     one line in the actual transmitted message.
+
+
+     3.  SYNTAX OF GENERAL ADDRESSEE ITEMS
+
+         <mach-addr-list>  ::=   <mach-addr-item>
+                               | <mach-addr-item> "," <address-list>
+
+         <address-list>    ::=   <null>
+                               | <address-item>
+                               | <address-item> "," <address-list>
+         <address-item>    ::=   <mach-addr-item>
+                               | <group-name> ":" <address-list> ";"
+                               | <any-name>
+                               | <path>
+
+         <mach-addr-item>  ::=   <mailbox>
+                               | <phrase> "<" <mailbox-list> ">"
+
+         <group-name>      ::=   <phrase>
+         <any-name>        ::=   <quoted-string>
+
+         <mailbox-list>    ::=   <mailbox>
+                               | <mailbox> "," <mailbox-list>
+         <mailbox>         ::=   <host-phrase>
+
+         <path>            ::=   ":" "File" ":" <path-name>
+         <path-name>       ::=   <path-item>
+                               | "<" <path-list> ">"
+         <path-list>       ::=   <path-item>
+                               | <path-item> "," <path-list>
+         <path-item>       ::=   <host-phrase>
+
+
+
+
+     II. Standard for the Format of Messages                      / 17
+      B. Syntax
+      4. Supporting Constructs
+
+
+
+     4.  SUPPORTING SYNTAX
+
+         <reference-list>  ::=   <null>
+                               | <reference-item>
+                               | <reference-item> "," <reference-list>
+         <reference-item>  ::=   <phrase>
+                               | <mach-host-phrase>
+
+         <mach-host-phrase>::=   "<" <host-phrase> ">"
+         <host-phrase>     ::=   <phrase> <host-indicator>
+         <host-indicator>  ::=   <at-indicator> <host-name>
+         <at-indicator>    ::=   "at" | "@"
+         <host-name>       ::=   <atom>
+                               | <decimal host address>
+
+         <date-time>       ::=   <day> <date> <time>
+         <day>             ::=   <null>
+                               | <day-of-week> ","
+         <day-of-week>     ::=   "Monday"    | "Mon"
+                               | "Tuesday"   | "Tue"
+                               | "Wednesday" | "Wed"
+                               | "Thursday"  | "Thu"
+                               | "Friday"    | "Fri"
+                               | "Saturday"  | "Sat"
+                               | "Sunday"    | "Sun"
+         <date>            ::=   <string-date>
+                               | <slash-date>
+         <string-date>     ::=   <day-of-month> <string-month>
+                                                <4-digit-year>
+         <slash-date>      ::=   <numeric-month> "/" <date-of-month>
+                                                 "/" <2-digit-year>
+         <numeric-month>   ::=   <one or two decimal digits>
+         <day-of-month>    ::=   <one or two decimal digits>
+         <string-month>    ::=   "January" | "Jan"
+                               | "February" | "Feb"
+                               | "March"    | "Mar"
+                               | "April"    | "Apr"
+                               | "May"
+                               | "June"     | "Jun"
+                               | "July"     | "Jul"
+                               | "August"   | "Aug"
+                               | "September"| "Sep"
+                               | "October"  | "Oct"
+                               | "November" | "Nov"
+                               | "December" | "Dec"
+         <4-digit-year>    ::=   <four decimal digits>
+         <2-digit-year>    ::=   <two decimal digits>
+         <time>            ::=   <24-hour-time> "-" <time-zone>
+         <24-hour-time>    ::=   <hour> <minute>
+         <hour>            ::=   <two decimal digits>
+         <minute>          ::=   <two decimal digits>
+
+
+     II. Standard for the Format of Messages                      / 18
+      B. Syntax
+      4. Supporting Constructs
+
+
+
+         <time-zone>       ::=   "GMT" | "Z"   | "GDT"
+                               | "AST" | "ADT"
+                               | "EST" | "EDT" | "CST" | "CDT"
+                               | "MST" | "MDT" | "PST" | "PDT"
+                               | "YST" | "YDT" | "HST" | "HDT"
+
+         <phrase>          ::=   <word>
+                               | <word> <phrase>
+         <phrase-list>     ::=   <null>
+                               | <phrase>
+                               | <phrase> "," <phrase-list>
+
+         <word>            ::=   <atom>
+                               | <quoted-string>
+
+
+
+     II. Standard for the Format of Messages                      / 19
+      C. Semantics
+      1. Address Fields
+
+
+
+
+
+     C. SEMANTICS
+
+
+     1. ADDRESS FIELDS
+
+     a. General
+
+        1) <path>s are used to refer to a location,  on  the  ARPANET,
+           containing  a  stored  address  list.   The <phrase> should
+           contain text which the referenced host  can  resolve  to  a
+           file.   This  standard  is  not  a protocol and so does not
+           prescribe HOW data  is  to  be  retrieved  from  the  file.
+           However, the following requirements are made:
+
+           - the   file  must  be  accessible  through  the   local
+             operating  system  interface  (if  it  exists),  given
+             adequate user access rights; and
+
+           - if a host has an FTP server and  a  user  is  able  to
+             retrieve  any  files  from the host using that server,
+             then the file must be accessible  through  FTP,  using
+             DEFAULT  transfer settings, given adequate user access
+             rights.
+
+           It is intended that this mechanism will allow  programs  to
+           retrieve such lists automatically.
+
+           The interpretation  of  a  <path>  follows.   This  is  not
+           intended to imply any particular implementation scheme, but
+           is included to aid in understanding the notion of <path>s:
+
+           - The contents of the file indicated by a <path-name> is
+             treated  as  an  <address-list>  and is inserted as an
+             <address-item> in the position of the <path-name> item
+             in  the  syntax.   That is, the TELNET ASCII character
+             string of the <path-name> or, if present,  the  <path-
+             list>  containing  it,  is replaced by the contents of
+             the file to which the <path-name>  refers.  Therefore,
+             the  contents  of  the file indicated by a <path-name>
+             must be syntactically self-contained and  must  adhere
+             to  the  full  syntax  prescribed herein for <address-
+             list>.
+
+           - <Path-item>s of a <path-list> are alternates  and  the
+             contents  of ONLY ONE of them is to be included in the
+             resultant address list.
+
+        2) The <phrase> part  of  a  <mailbox>  is  understood  to  be
+           whatever  the  receiving  FTP  Server  allows (for example,
+
+
+     II. Standard for the Format of Messages                      / 20
+      C. Semantics
+      1. Address Fields
+
+
+
+           TENEX systems do not now understand addresses of  the  form
+           "P.  D.  Q.  Bach", but another system might).
+
+           Note that a <mailbox> is a conceptual entity which does not
+           necessarily  pertain  to  file  storage.  For example, some
+           sites may choose to print mail on their  line  printer  and
+           deliver the output to the addressee's desk.
+
+           A user may have several mailboxes. The use  of  the  second
+           alternative  of  <mach-addr-item>  (<phrase>  "<" <mailbox-
+           list> ">") indicates that a copy of the message  is  to  be
+           sent to EACH mailbox named.
+
+        3) <any-name>  may  contain  any  sequence  of  "words".  This
+           sequence  of  words,  used as an <address-item>, is used to
+           facilitate reference  to  non-standard  (e.g.  non-Network)
+           addresses.    Such   an  address  might  be  one  which  is
+           acceptable to the U.S.  Postal Service.
+
+        4) The <host-name> in a <host-phrase>  must  be  THE  official
+           name of a Network host, or else a decimal number indicating
+           the Network address for that host.  The USE OF  NUMBERS  IS
+           STRONGLY  DISCOURAGED  and  is  permitted  only  due to the
+           occasional necessity of bypassing local host-name tables.
+
+           The  <phrase>  in  a  <host-phrase>  is  intended   to   be
+           meaningful only to the indicated host.  To all other hosts,
+           the <phrase> is treated  as  a  literal  string.   No  case
+           transformations  should be (automatically) performed on the
+           <phrase>.  The <phrase> is passed to the local host's  mail
+           sending   program;   it   is   the  responsibility  of  the
+           destination host's mail receiving (distribution) program to
+           perform  case  mapping  on  this  <phrase>, if required, to
+           deliver the mail.
+
+     b. Originator Fields
+
+           WARNING: The standard allows only a subset of  the
+                    combinations   possible  with  the  From,
+                    Sender,   and   Reply-to   fields.    The
+                    limitation  is intentional; the permitted
+                    alternatives have been  carefully  chosen
+                    and are adequate for the purposes of this
+                    standard.
+
+
+
+     II. Standard for the Format of Messages                      / 21
+      C. Semantics
+      1. Address Fields
+
+
+
+        1) From:
+
+           This field contains  the  identity  of  the  person(s)  who
+           wished  this  message  to  be  sent.   The message-creation
+           process should default this field to be  a  single  machine
+           address,  indicating  the user entering the message; if and
+           only if this is done,  the  "Sender:"  field  need  not  be
+           present.
+
+        2) Sender:
+
+           This field contains the identity of the  person  who  sends
+           the  message.   It need not be present in the header of the
+           message if it is the SAME as the "From:" field.
+
+           The <sender-field-body>  includes  a  <phrase>  which  must
+           correspond  to  a  user,  rather  than a standard <address-
+           item>, to indicate the  expectation  that  the  field  will
+           refer  to  the  PERSON responsible for sending the mail and
+           not simply include the name of a mailbox,  from  which  the
+           mail  was  sent.  For example in the case of a shared login
+           name, the name, by itself,  would  not  be  adequate.   The
+           <phrase>  (user)  is  a  system  entity,  not a generalized
+           person reference.
+
+        3) Reply-to:
+
+           This field provides a general mechanism for indicating  any
+           mailbox(es)  to  which  responses  are  to  be sent.  Three
+           different uses for this feature can be  distinguished.   In
+           the  first  case,  the  author(s)  may  not  have   regular
+           machine-based  mailboxes  and therefore wish to indicate an
+           alternate machine address.  In the second case,  an  author
+           may  wish  additional  persons  to  be  made  aware  of, or
+           responsible for, responses; responders  should  send  their
+           replies  to  the "Reply-to:" mailbox(es).  More interesting
+           is a case such as text-message teleconferencing in which an
+           automatic distribution facility  is  provided  and  a  user
+           submitting  an  "entry" for distribution only needs to send
+           their message to the mailbox(es) indicated in  the  "Reply-
+           to:" field.
+
+           If there is no <reply-to-field>, then the <from-field> MUST
+           contain  AT  LEAST  ONE machine address.  In all cases when
+           used and even if a <sender> field is present, the  Reply-to
+           field must contain at least one machine address.
+
+        NOTE: For systems which automatically generate  address  lists
+        for replies to messages, the following requirements are made:
+
+
+
+     II. Standard for the Format of Messages                      / 22
+      C. Semantics
+      1. Address Fields
+
+
+
+           - The receiver, when replying to a message,  must  NEVER
+             automatically  include  the <sender-field-body> in the
+             reply's address list
+
+           - If the <reply-to-field> exists, then the reply  should
+             go ONLY to the <reply-to-field-body> addressees.
+
+        (Extensive  examples  are  provided  in  Section  II.D.)  This
+        recommendation is intended only for <originator-field>s and in
+        no way is intended to reflect that replies should not be sent,
+        also,  to  the  other recipients of this message.  It is up to
+        the respective mail handling programs as  to  what  additional
+        facilities will be provided.
+
+     c. Receiver Fields
+
+        1) To:
+
+           This field contains the identity of the primary  recipients
+           of the message.
+
+        2) cc:
+
+           This  field  contains  the  identity   of   the   secondary
+           recipients of the message.
+
+        3) Bcc:
+
+           This field contains the identity of  additional  recipients
+           of  the  message  who are to remain hidden from the primary
+           and secondary  recipients.   Some  systems  may  choose  to
+           include   the   text  of  the  "Bcc:"  field  only  in  the
+           author(s)'s copy, while others may include it in  the  text
+           sent to all those indicated in the "Bcc:" list.
+
+        4) Fcc:
+
+           This field contains the identity of any  message  files  in
+           which  copies  of  this  message  are  being  placed by the
+           originator.  Note that the presence of this field does  NOT
+           guarantee  long-term  availability of the message in any of
+           the indicated files.
+
+
+
+
+     II. Standard for the Format of Messages                      / 23
+      C. Semantics
+      2. Reference Specification Fields
+
+
+
+     2. REFERENCE SPECIFICATION FIELDS
+
+     a. Message-Id:
+
+        This field contains a  unique  identifier  (the  <phrase>)  to
+        refer  to this version of this message.  The uniqueness of the
+        message  identifier  is  guaranteed  by   each   host.    This
+        identifier  is  intended  to  be  machine  readable,  and  not
+        necessarily meaningful to humans.  A  message-id  pertains  to
+        exactly  one instantiation of a particular message; subsequent
+        revisions to the message should receive new message-id's.
+
+     b. In-Reply-To:
+
+        The contents of this field  identify  previous  correspondence
+        which  this  message answers.  If message identifiers are used
+        in this field, they should be enclosed in angle brackets (<>).
+
+     c. References:
+
+        The contents of this field identify other correspondence which
+        this  message  references.   If  message identifiers are used,
+        they should be enclosed in angle brackets (<>).
+
+     d. Keywords:
+
+        This field contains keywords or phrases, separated by commas.
+
+
+     3. OTHER FIELDS AND SYNTACTIC ITEMS
+
+     a. Subject:
+
+        The  "subject:"  field  is  intended  to   provide   as   much
+        information  as  necessary to adequately summarize or indicate
+        the nature of the message.
+
+     b. Comments:
+
+        Permits  adding  text  comments  onto  the   message   without
+        disturbing the contents of the message's body.
+
+
+
+
+     II. Standard for the Format of Messages                      / 24
+      C. Semantics
+      4. Dates
+
+
+
+     4. DATES
+
+        It is recommended that,  because  of  differing  international
+        interpretations,  the  <string-day>  option be used instead of
+        the <slash-day> option in the specification of a <day>.
+
+        If included, <day-of-week> must be  the  day  implied  by  the
+        <date> specification.
+
+        <Time-zones> allow reference to Greenwich and to each  of  the
+        zones  in  the  United  States.  The zone references beginning
+        with "A" are for Atlantic time which are one hour faster  than
+        the  corresponding Eastern times.  "Y" indicates Yukon time in
+        Alaska, which  is  one  hour  slower  than  the  corresponding
+        Pacific times, and "H" indicates Hawaiian times, which are two
+        hours slower.
+
+
+
+     II. Standard for the Format of Messages                      / 25
+      D. Examples
+
+
+
+
+
+
+     D. EXAMPLES
+
+
+     1. ADDRESSES
+
+     a. Alfred E. Newman <Newman at BBN-TENEXA>
+        Newman@BBN-TENEXA
+
+        These  two  "Alfred  E.   Newman"  examples   have   identical
+        semantics,  as far as the operation of the local host's mailer
+        and the remote host's FTP server are concerned.  In the  first
+        example,  the "Alfred E.  Newman" is ignored by the mailer, as
+        "Newman at BBN-TENEXA"  completely  specifies  the  recipient.
+        The  second  example contains no superfluous information, and,
+        again, "Newman@BBN-TENEXA" is the intended recipient.
+
+     b. Al Newman at BBN-TENEXA
+
+        This is identical with "Al Newman<Al Newman  at  BBN-TENEXA>."
+        That is, the full <phrase>, "Al Newman", is passed to the  FTP
+        server.   Note  that  not  all  FTP  servers accept multi-word
+        identifiers; and some that do accept them will treat each word
+        as  a  different addressee (in this case, attempting to send a
+        copy of the message to "Al" and a copy to "Newman").
+
+     c. "George Lovell, Ted Hackle" <Shared-Mailbox at Office-1>
+
+        This form might be used to indicate that a single  mailbox  is
+        shared  by several users.  The quoted string is ignored by the
+        originating host's mailer,  as  "Shared-Mailbox  at  Office-1"
+        completely specifies the destination mailbox.
+
+     d. Wilt (the Stilt) Chamberlain at NBA
+
+        The "(the Stilt)" is a comment, which is NOT included  in  the
+        destination mailbox address handed to the originating system's
+        mailer.  The address is the string  "Wilt  Chamberlain",  with
+        exactly  one  space  between the first and second words.  (The
+        quotation marks are not included.)
+
+
+
+
+     II. Standard for the Format of Messages                      / 26
+      D. Examples
+
+
+
+
+     2. ADDRESS LISTS
+
+            Gourmets:  Pompous Person <WhoZiWhatZit at Cordon-Bleu>,
+                       Cooks:  Childs at WGBH, Galloping Gourmet at
+                               ANT (Australian National Television);
+                       Wine Lovers:  Drunk at Discount-Liquors,
+                                     Port at Portugal;;,
+            Jones at SEA
+
+        This group list example points out the use  of  comments,  the
+        nesting  of  groups,  and  the mixing of addresses and groups.
+        Note that the two consecutive semi-colons  preceding "Jones at
+        SEA" mean that Jones is NOT a member of the Gourmets group.
+
+
+     3. ORIGINATOR ITEMS
+
+     a. George Jones logs into his Host as  "Jones".   He  sends  mail
+        himself.
+
+            From:  Jones at Host
+        or
+            From:  George Jones <Jones at Host>
+
+     b. George Jones logs in as Jones on his Host.  His secretary, who
+        logs  in  as  Secy  on  her  Host  (SHost) sends mail for him.
+        Replies to the mail should go to George, of course.
+
+            From:    George Jones <Jones at Host>
+            Sender:  Secy at SHost
+
+     c. George Jones logs in as Group at Host.  He sends mail himself;
+        replies should go to the Group mailbox.
+
+            From:  George Jones <Group at Host>
+
+     d. George Jones' secretary sends mail for George in his  capacity
+        as a member of Group while logged in as Secy at Host.  Replies
+        should go to Group.
+
+            From:   George Jones<Group at Host>
+            Sender: Secy at Host
+
+        Note that there need not be a space between  "Jones"  and  the
+        "<",  but  adding a space enhances readability (as is the case
+        in other examples).
+
+     e. George Jones asks his secretary  (Secy  at  Host)  to  send  a
+        message  for  him  in  his  capacity  as  Group.  He wants his
+        secretary to handle all replies.
+
+
+
+     II. Standard for the Format of Messages                      / 27
+      D. Examples
+
+
+
+
+            From:     George Jones <Group at Host>
+            Sender:   Secy at Host
+            Reply-to: Secy at Host
+
+     f. A non-ARPANET user friend  of  George's,  Sarah,  is  visting.
+        George's  secretary  sends  some  mail to a friend of Sarah in
+        computer-land.  Replies should go to George, whose mailbox  is
+        Jones at Host.
+
+            From:     Sarah Friendly
+            Sender:   Secy at Host
+            Reply-to: Jones at Host
+
+     g. George is a member of a committee.   He  wishes  to  have  any
+        replies to his message go to all committee members.
+
+            From:     George Jones
+            Sender:   Jones at Host
+            Reply-To: Big-committee: Jones at Host,
+                                     Smith at Other-Host,
+                                     Doe at Somewhere-Else;
+
+        Note  that  if  George  had  not  included  himself   in   the
+        enumeration  of  Big-committee,  he  would  not  have gotten a
+        reply; the presence of the "Reply-to:"  field  SUPERSEDES  the
+        sending of a reply to the person named in the "From:" field.
+
+     h. (Example of INCORRECT USE)
+
+        George desires a reply to go to his secretary;  therefore  his
+        secretary  leaves  his  mailbox address off the "From:" field,
+        leaving only  his  name,  which  is  not,  itself,  a  mailbox
+        address.
+
+                 From:   George Jones
+                 Sender: Secy at SHost
+
+        THIS IS NOT PERMITTED.  Replies are NEVER implicitly  sent  to
+        the   "Sender:";  George's  secretary  should  have  used  the
+        "Reply-to:" field, or the mail creating program she was  using
+        should have forced her to.
+
+     i. George's secretary sends out  a  message  which  was  authored
+        jointly by all the members of the "Big-committee".
+
+            From:   Big-committee: Jones at Host,
+                                   Smith at Other-Host,
+                                   Doe at Somewhere-Else;
+            Sender: Secy at SHost
+
+
+
+     II. Standard for the Format of Messages                      / 28
+      D. Examples
+
+
+
+
+     4. COMPLETE HEADERS
+
+     a. Minimum required:
+
+            Date:  26 August 1976 1429-EDT
+            From:  Jones at Host
+
+     b. Using some of the additional fields:
+
+            Date  26 August 1976 1430-EDT
+            From:  George Jones<Group at Host>
+            Sender: Secy at SHOST
+            To:    Al Newman at Mad-Host,
+                   Sam Irving at Other-Host
+            Message-id:  some string at SHOST
+
+     c. About as complex as you're going to get:
+
+            Date:       27 Aug 1976 0932-PDT
+            From:       Ken Davis <KDavis at Other-Host>
+            Sender:     KSecy at Other-Host
+            Reply-to:   Sam Irving at Other-Host
+            Subject:    Re: The Syntax in the RFC
+            To:         George Jones <Group at Host>,
+                        Al Newman at Mad-Host
+            cc:         Tom Softwood <Balsa at Another-Host>,
+                        Sam Irving at Other-Host,
+                        Standard Distribution:
+                         :File:
+                           </main/davis/people/standard at Other Host,
+                           "<Jones>standard.dist.3" at Tops-20-Host>
+            In-Reply-to: <some string at SHOST>
+            Message-ID: 4231.629.XYzi-What at Other-Host
+            Comment:    Sam is away on business. He asked me to handle
+                        his  mail  for  him  today.   He'll be able to
+                        provide a more accurate  explanation  tomorrow
+                        when he returns.
+
+
+
+     III. References
+
+
+
+
+
+
+
+                            III.  REFERENCES
+
+
+     --- TELNET Protocol Specification.   Network  Information  Center
+        No.  18639;  Augmentation  Research  Center, Stanford Research
+        Institute: Menlo Park, August 1973.
+
+     Bhushan, A.K.  The File Transfer Protocol.  ARPANET  Request  for
+        Comments,  No.   354,  Network  Information Center No.  10596;
+        Augmentation Research  Center,  Stanford  Research  Institute:
+        Menlo Park, July 1972.
+
+     Bhushan, A.K.  Comments on the File Transfer  Protocol.   ARPANET
+        Request for Comments, No.  385, Network Information Center No.
+        11357;  Augmentation  Research   Center,   Stanford   Research
+        Institute: Menlo Park, August 1972.
+
+     Bhushan, A.K., Pogran, K.T., Tomlinson,  R.S.,  and  White,  J.E.
+        Standardizing  Network  Mail  Headers.   ARPANET  Request  for
+        Comments, No.  561,  Network  Information  Center  No.  18516;
+        Augmentation  Research  Center,  Stanford  Research Institute:
+        Menlo Park, September 1973.
+
+     Feinler,  E.J.  and  Postel,  J.B.   ARPANET  Protocol  Handbook.
+        Network  Information  Center  No.  7104; Augmentation Research
+        Center, Stanford Research Institute: Menlo Park,  April  1976.
+        (NTIS AD A003890).
+
+     McKenzie,  A.   File  Transfer  Protocol.   ARPANET  Request  for
+        Comments,  No.  454,  Network  Information  Center  No. 14333;
+        Augmentation Research  Center,  Stanford  Research  Institute:
+        Menlo Park, February 1973.
+
+     Myer, T.H. and Henderson, D.A.   Message  Transmission  Protocol.
+        ARPANET  Request  for  Comments,  No. 680, Network Information
+        Center  No.  32116;  Augmentation  Research  Center,  Stanford
+        Research Institute: Menlo Park, 1975.
+
+     Neigus,  N.   File  Transfer  Protocol.   ARPANET   Request   for
+        Comments,  No.  542,  Network  Information  Center  No. 17759;
+        Augmentation Research  Center,  Stanford  Research  Institute:
+        Menlo Park, July 1973.
+
+     Postel, J.B.  Revised  FTP  Reply  Codes.   ARPANET  Request  for
+        Comments,  No.  640,  Network  Information  Center  No. 30843;
+        Augmentation Research  Center,  Stanford  Research  Institute:
+        Menlo Park, June 1974.
+
+
+
+     Appendix                                                     / 30
+     Alphabetical Listing of Syntax Rules
+
+
+
+
+
+
+                             APPENDIX
+
+
+     A.  ALPHABETICAL LISTING OF SYNTAX RULES
+
+     <2-digit-year>    ::=   <two decimal digits>
+     <4-digit-year>    ::=   <four decimal digits>
+     <24-hour-time>    ::=   <hour> <minute>
+
+     <addressee-field> ::=   "To"          ":" <address-list>
+                           | "cc"          ":" <address-list>
+                           | "bcc"         ":" <address-list>
+                           | "Fcc"         ":" <path-list>
+     <address-item>    ::=   <mach-addr-item>
+                           | <group-name> ":" <address-list> ";"
+                           | <any-name>
+                           | <path>
+     <address-list>    ::=   <null> | <address-item>
+                           | <address-item> "," <address-list>
+
+     <any-from-field>  ::=   "From"        ":" <address-list>
+
+     <any-name>        ::=   <quoted-string>
+
+     <at-indicator>    ::=   "at" | "@"
+
+     <atom>            ::=   <a sequence of one or more TELNET ASCII
+                                alpha-numeric or graphics characters,
+                                excluding all control characters
+                                (those characters with a decimal value
+                                less than 33 or equal to 127) and
+                                <delimeters> >
+
+     <comment>         ::=   "(" <TELNET ASCII characters, except
+                                <crlf> > ")"
+
+     <cr>              ::=   <TELNET ASCII carriage return (decimal 13)>
+     <crlf>            ::=   <TELNET ASCII carriage return/line feed
+                                (decimal 13, followed by decimal 10)>
+
+     <date>            ::=   <string-date> | <slash-date>
+     <date-field>      ::=   "Date"        ":" <date-time>
+     <date-time>       ::=   <day> <date> <time>
+     <day>             ::=   <null> | <day-of-week> ","
+     <day-of-month>    ::=   <one or two decimal digits>
+     <day-of-week>     ::=   "Monday"    | "Mon"
+                           | "Tuesday"   | "Tue"
+                           | "Wednesday" | "Wed"
+                           | "Thursday"  | "Thu"
+
+
+     Appendix                                                     / 31
+     Alphabetical Listing of Syntax Rules
+
+
+
+
+                           | "Friday"    | "Fri"
+                           | "Saturday"  | "Sat"
+                           | "Sunday"    | "Sun"
+
+     <delimeter>       ::=   <specials> | <comment>
+                           | <linear-white-space> | <crlf>
+
+     <field>           ::=   <field-name> ":" <field-body>
+     <field-body>      ::=   <field-body-contents>
+                           | <field-body-contents> <crlf>
+                                <linear-white-space-CHAR> <field-body>
+     <field-body-contents> ::= <the TELNET ASCII characters making up
+                                the field body, as defined in the
+                                following sections and consisting of
+                                combinations of <atom>, <quoted-
+                                string>, <text-line>, and <specials>
+                                tokens>
+
+     <field-name>      ::=   <atom> | <atom> <field-name>
+
+     <group-name>      ::=   <phrase>
+
+     <headers>         ::=   <required-headers>
+                           | <required-headers> <optional-headers>
+
+     <host-indicator>  ::=   <at-indicator> <host-name>
+     <host-name>       ::=   <atom>  | <decimal host address>
+     <host-phrase>     ::=   <phrase> <host-indicator>
+
+     <hour>            ::=   <two decimal digits>
+
+     <lf>              ::=   <TELNET ASCII line feed (decimal 10)>
+     <linear-white-space>::= <linear-white-space-char>
+                           | <linear-white-space-char>
+                                <linear-white-space>
+     <linear-white-space-char>::=  <space> | <horizontal-tab>
+
+     <mach-addr-item>  ::=   <mailbox> | <phrase> "<" <mailbox-list> ">"
+     <mach-addr-list>  ::=   <mach-addr-item>
+                           | <mach-addr-item> "," <address-list>
+
+     <mach-from-field> ::=   "From"        ":" <mach-addr-item>
+     <mach-from-list>  ::=   "From"        ":" <mach-addr-list>
+
+     <mach-host-phrase>::=   "<" <host-phrase> ">"
+
+     <mailbox>         ::=   <host-phrase>
+     <mailbox-list>    ::=   <mailbox> | <mailbox> "," <mailbox-list>
+
+     <message>         ::=   <headers>
+                           | <headers> <crlf> <message-text>
+
+
+     Appendix                                                     / 32
+     Alphabetical Listing of Syntax Rules
+
+
+
+
+     <message-text>    ::=   <a sequence of zero of more TELNET ASCII
+                                characters>
+
+     <minute>          ::=   <two decimal digits>
+
+     <numeric-month>   ::=   <one or two decimal digits>
+
+     <optional-headers>::=   <optional-header-field>
+                           | <optional-headers> <optional-header-field>
+     <optional-header-field> ::= <addressee-field> | <extension-field>
+
+     <originator>      ::=   <mach-from-field>
+                           | <mach-from-list> <sender-field>
+                           | <mach-from-field> <reply-to-field>
+                           | <any-from-field> <sender-field>
+                                <reply-to-field>
+
+     <path>            ::=   ":" "File" ":" <path-name>
+     <path-item>       ::=   <host-phrase>
+     <path-list>       ::=   <path-item> | <path-item> "," <path-list>
+     <path-name>       ::=   <path-item> | "<" <path-list> ">"
+
+     <phrase>          ::=   <word> | <word> <phrase>
+     <phrase-list>     ::=   <null> | <phrase>
+                           | <phrase> "," <phrase-list>
+
+     <reference-item>  ::=   <phrase> | <mach-host-phrase>
+     <reference-list>  ::=   <null> | <reference-item>
+                           | <reference-item> "," <reference-list>
+
+     <quoted-string>   ::=   <double quote mark ("), decimal 34>
+                                <a sequence of one or more TELNET
+                                ASCII characters, where two adjacent
+                                quotes are treated as a single quote
+                                and part of the string> <">
+
+     <reply-to-field>  ::=   "Reply-To"    ":" <mach-addr-list>
+
+     <required-headers> ::=  <date-field> <originator>
+
+     <sender-field>    ::=   "Sender"      ":" <host-phrase>
+
+     <slash-date>      ::=   <numeric-month> "/" <date-of-month>
+                                             "/" <2-digit-year>
+     <space>           ::=   <TELNET ASCII space (decimal 32)>
+
+     <specials>        ::=   "(" | ")" | "<" | ">"
+                           | "@" | "," | ";" | ":" | <">
+
+     <string-date>     ::=   <day-of-month> <string-month>
+     <string-month>    ::=   "January"  | "Jan" | "February" | "Feb"
+
+
+     Appendix                                                     / 33
+     Alphabetical Listing of Syntax Rules
+
+
+
+
+                           | "March"    | "Mar" | "April"    | "Apr"
+                           | "May"              | "June"     | "Jun"
+                           | "July"     | "Jul" | "August"   | "Aug"
+                           | "September"| "Sep" | "October"  | "Oct"
+                           | "November" | "Nov" | "December" | "Dec"
+
+     <tab>             ::=   <TELNET ASCII tab   (decimal  9)>
+
+     <text-line>        ::=   <a sequence of one or more TELNET ASCII
+                                characters excluding <cr> and <lf> >
+
+     <time>            ::=   <24-hour-time> "-" <time-zone>
+     <time-zone>       ::=   "GMT" | "Z"   | "GDT" | "AST" | "ADT
+                           | "EST" | "EDT" | "CST" | "CDT"
+                           | "MST" | "MDT" | "PST" | "PDT"
+                           | "YST" | "YDT" | "HST" | "HDT"
+
+     <user-defined-field> ::= <A <field> which has a <field-name> not
+                                defined in this specification>
+
+     <word>            ::=   <atom> | <quoted-string>
+
+
+
+