Message Transmission Protocol

Network Working Group                                            T. Myer
Request for Comment: 680                                    D. Henderson
NIC: 32116                                                     BBN-TENEX
                                                          April 30, 1975

                     Message Transmission Protocol

                            Theodore H. Myer

                          D. Austin Henderson

                               BBN-TENEX

   This document defines a number of message fields beyond those
   discussed in RFC 561.  The overall message format is compatible with
   RFC 561; it makes extensive use of the miscellaneous fileds defined
   within RFC 561.  The purpose of this document is to establish ARPANET
   standards with regard to the syntax and semantics for these
   additional fields.  It is fully expected that all fields discussed
   herein will not be automatically processed by all Message Servers;
   however, the standard is necessary so that sites which wish to make
   use of these fields have a standard to work with.

   This document attempts to tread the narrow line between features for
   human processing and features for machine processing.  The general
   feeling is that the fields listed are useful to people even if
   automatic processing is not supplied.  In most cases, machine-
   readable notations have been enclosed in angle brackets (<>) to allow
   easy non-ambiguous ways for automatic processes to know whether and
   where to look in any field.  The entire specifications has been made
   excessively general to allow for experimentation. Future documents
   based on experience will try to be more specific.  This is simply the
   next step following <RFC 561>.

   This document is contained in two sections.  Section I contains the
   relevant parts of RFC 561 which define the basic message syntax.
   Section II lists the new (and existing) header fields together with
   their proposed uses.

RFC 680


SECTION I: BASIC MESSAGE SYNTAX


   <message>            ::=     <header><crlf><body>
   <header>             ::=     <required header><optional header>
   <required header>    ::=     <date item><sender item>
   <date item>          ::=     DATE:<sp><date><sp>AT<sp>
                                <time>-<zone><crlf>
   <date>               ::=     <vdate>  !  <tdate>
   <vdate>              ::=     <dayofmonth><SP><vmonth><SP><vyear>
   <tdate>              ::=     <tmonth>/<dayofmonth>/<tyear>
   <dayofmonth>         ::=     one or two decimal digits
   <vmonth>             ::=     JAN ! FEB ! MAR ! APR ! MAY ! JUN !
                                JUL ! AUG ! SEP ! OCT ! NOV !  DEC
   <tmonth>             ::=     one or two decimal digits
   <vyear>              ::=     four decimal digits
   <tyear>              ::=     two decimal digits
   <zone>               ::=     EST ! EDT ! CST ! CDT ! MST ! MDT !
                                PST ! PDT ! GMT ! GDT
   <time>               ::=     four decimal digits
   <sender item         :=      SENDER: <sp><user><sp>AT<sp><host>
                                <crlf>
   <optional header>    ::=     <subjects><optional items>
   <subjects>           ::=     !<subject item> !
                                <subject item><subjects>
   <subject item>       ::=     SUBJECT:<sp><line><crlf>
   <optional items>     ::=     <optional item> ! <optional item>
                                <optional items>
   <optional item>      ::=     <messid> ! <addressee item> !
                                <other item>
   <addressee item>     ::=     <addressee keyword>:<sp><addressee
                                list><crlf>
   <addressee keywork>  ::=     TO:! CC:! BCC:!
   <messid>             ::=     Message-ID:<sp>[<Net
                                Address>}]<line>
                                <crlf>
   <other item>         ::=     <other keyword>:<sp><line><crlf>
   <other keyword>      ::=     FROM ! IN-REPLY-TO! REFERENCES!
                                KEYWORD ! PRECEDENCE !
                                MESSAGE-CLASS!
                                SPECIAL-HANDLING! AUTHENTICATION!
                                ACCESSION-KEY
   <address list>       ::=     <addressee> ! <addressee><addressee
                                list>
   <addressee>          ::=     <mailbox> ! <mailbox group>
   <mailbox>            ::=     <user><host spec><attention spec>
   <host spec>          ::=     !@<host>
   <attention spec>     ::=     (ATTN:<sp><user list>)

RFC 680


   <user list>          ::=     <user> ! <user><user list>
   <mailbox group>      ::=     <group name>:(<group numbers>)
   <group numbers>      ::=     ! (<mailbox list>)
   <mailbox list>       ::=     <mailbox> ! <mailbox>,<mailboxlist>
   <body>               ::=     <line><CRLF> ! <line><CRLF><body>
   <user>               ::=     <word>
   <host>               ::=     a standard host name
   <group name>         ::=     ! <word>
   <line>               ::=     a string containing any of the 128
                                ASCII
                                characters except CR and LF
   <word>               ::=     a string containing any of the 128
                                ASCII
                                characters except CR, LF, and SP
   <CRLF>               ::=     CR LF
   <SP>                 ::=     space

   Notes:

   1. A message may have at most one MESSAGE-ID item.

   2. All items with the same keyword must be grasped together.

   Please note the following:

      (1) The case (upper or lower) of keywords -- specifically, 'FROM',
      'DATE', 'SUBJECT', 'AT', <host>, <zone>, <vmonth> and <keyword> --
      is insignificant.  Although 'FROM', for example, appears in
      upper-case in the formal syntax above, in the header of an actual
      message it may appear as 'FROM', 'from', or 'From', etc.

      (2) No attempt has been made to legislate the format of <user>
      except to exclude spaces from it.

      (3) The time has no internal punctuation.

RFC 680


SECTION II: MESSAGE HEADER FIELDS


A. ORIGINATOR SPECIFICATION FIELDS

   FROM

   This field contains the identity of the person who wished this
   message to be sent.  This is expected to be the originator field
   which is specified by the user in the case that the message is being
   entered by one person for another.  The message-creation process
   should default this field to be the user entering the message. [The
   usage for FROM and SENDER differs from that of RFC 561.]

   SENDER

   This field contains the identity of the person who sends the message.
   This field is expected to be set by the message-creation process
   automatically.  It is possible that some sites will not include this
   field in external communications.


   AUTHENTICATION

   This field contains a description of which originator fields have
   been authenticated, and by which operating systems.  This field
   should be created by message transmission and/or reception processes
   (FTP/Operating System level).

   It is expected that current system will be able to authenticate only
   the SENDER field; however, later systems might have mechanisms to
   verify that the FROM actually authorized the SENDER to act on his/her
   behalf.  It is expected that, when the FROM is authenticated, the
   SENDER will no longer be necessary for external distribution.

B. REFERENCE SPECIFICATION FIELDS

   MESSAGE-ID

   This field contains a unique identifier to refer to this message.
   The format for a message identifier is:


   [Net Address]Text String CRLF
   Examples:
              [ISIB]7-DEC-74.14:23:45
              [ARC]QLOURNAL 39274a3

RFC 680


   The uniqueness of the message identifier is guaranteed by each net-
   address message processor making the text which follows unique for
   that net-address.  This, specifically says net-address and not site
   name.  This would allow BBN (for instance) to allocate unique
   identifiers over all four machines, which may be addressed as BBN
   within the message system, thus producing a more integrated service
   for their users.

   The text following the net-address is not defined here, as the
   problems associated with this specification are too great at this
   time.  However, the net-address should allow automatic processes to
   determine if they can deal intelligently with the following text.
   Several types of automatic processing by the local message reader are
   thus possible:  1) if the site uses a filing mechanism known to the
   reader, the reader can retrieve the message 2) if the site supports
   remote message access (protocol not currently defined), the message
   id can be passed to the remote site and the message has been filed in
   the Datacomputer (using the entire message id [including net-address]
   as the handle), the reader can retrieve it from the Datacomputer.

   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 (<>).

   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 (<>).

   KEYWORDS

   This field contains keywords or phrases from the message, separated
   by commas.

RFC 680


C. RECEIVER SPECIFICATION FIELDS

   TO

   This field contains the identity of the primary receivers of the
   message.

   CC

   This field contains the identity of the secondary receivers of the
   message.

   BCC

   This field contains the identity of the tertiary receivers of the
   message.  This field should not be made available to the primary and
   secondary receivers, but it may be recorded to provide information
   for access control.

D. MESSAGE-TYPE SPECIFICATION FIELDS

   PRECEDENCE

   This field describes the importance and urgency of the message.
   Machine-readable notations will be enclosed in angle brackets (<>).
   <PRIORITY> means that the message should be delivered as soons as
   possible. <ROUTINE> means that Priority processing is not necessary.
   Plain text may also be included in this field.

   MESSAGE-CLASS

   This field describes the "legal" status of the message. Examples:
   Official, Unofficial, Record, Off the Record, Junk Mail.  No
   automatic processing of this field is immediately expected.  Certain
   message creation processes might, for example, always insert:

      MESSAGE CLASS: Unofficial ARPANET Message

   SPECIAL-HANDLING

   This field contains any special instructions with regard to the
   handling of the message at the receiver's end.  Machine-readable
   notations will be enclosed in angle brackets (<>). <PRIVATE> means
   that the message reception process should not aid the user in
   circulating copies to others.  Plain text may also be included in
   this field.