INDRA Note 1025
     IEN 169
     23rd January 1981

                    A Simple NIFTP-Based Mail System

                             C. J. Bennett

          ABSTRACT: This INDRA  Note  proposes  a  draft  mail
          protocol  for  use  in  a  wide  variety  of network
          situations. This protocol draws heavily on  existing
          facilities and could be brought up very quickly - in
          months rather than years. It could thus be  used  as
          an  interim  solution  until international standards
          emerge.   An  experiment  in  the  ARPA  Catenet  is
          proposed,  and  the  use  of the system in the UK is

                     Department of Computer Science
                       University College London

     1. Introduction

       One of the major uses of computer networks is for electronic
     mail services. Now that networking technology is proliferating
     rapidly, it is highly desirable that such services  should  be
     made  available  with  the new networks.  However, despite the
     recent adoption of Teletex proposals by CCITT, it may be  some
     time  before  one  can  expect  international  standards to be
     finalised and widely available. Hence there is a  strong  need
     for a simple interim scheme, which could cover the basic needs
     for  mail  transfer  across  multiple  networks  and   through
     intermediate mail relays in a flexible fashion.  We at UCL are
     particularly concerned with this, as we see  the  need  for  a
     scheme  which  will operate both with the facilities available
     in the United States, and those rapidly becoming available  in
     Britain and Europe.

       This note contains a proposal for such an interim  protocol,
     discusses  the  requirements  on  mail  relays,  and  also the
     requirements for experimental systems based on it, both in the
     US  and  the  UK. Partly because the proposed system uses ARPA
     facilities,  the  document  has   a   certain   bias   towards
     familiarity  with ARPA systems and terminology. In particular,
     the  note  assumes  familiarity  with  RFC733   mail   formats
     [Crocker77],  the  ARPA standard. However, it is believed that
     the  system  will  also  be  useful  in  other   environments,
     particularly the X25 and Network Independent Transport Service
     [SG3/80] environments which will be available shortly  in  the
     UK.  ARPA-oriented  readers  should  note  that familiarity is
     assumed with the NIFTP [HLPG81], the interim UK file  transfer

       Comments are solicited and welcomed.

     2. Requirements

       The basic requirements for an immediate mail service are  as

      (1)    Maximum use must be made  of  existing  standards.  No
             radical  new mail formats, transfer protocols, etc may
             be  imposed.  Using  these  facilities  it  should  be
             possible  to bring up an initial service within months
             rather than years.

      (2)    The service should be economic.  In  particular,  only
             one  copy  of  a message should be transmitted to each
             destination mail server.

Bennett                                                         [Page 1]

INDRA Note 1025                                         NIFTP-Based Mail

      (3)    The  service  should  be  independent  of   particular

      (4)    Address information must be transmitted in a way which
             is usable by mail relays.

      (5)    Total global knowledge of mail server addresses should
             not be necessary.

      (6)    The service should be as flexible as  possible.  Where
             possible  it  should  be easy to extend it to meet new
             needs as they emerge.

     The last  requirement  is  perhaps  the  least  important.  It
     implies  that the service will be around for sufficiently long
     that experimental technical advances in message processing can
     be   usefully   incorporated.   For   instance,   the  minimum
     requirement  is  that  text  messages  must  be  transferable.
     Requirement (vi) suggests that it should be possible to extend
     the service simply  to  transfer  mixed-media  messages.  When
     assessing  whether  a given proposal meets this criterion, the
     multi-media case will be used as a test.

       No existing system in wide use meets all these  constraints.
     Hence  it  is  necessary  to  combine  elements with the right
     properties from a number of  sources  not  all  of  which  are
     currently used for mail.

       It should be noted that the  service  defined  here  is  not
     intended  to  be perfect. In particular, it does not of itself
     guarantee bidirectionality, endpoint reliability,  or  use  of
     address  lists.   These  will normally be available for direct
     endpoint transfer, and any problems are most likely  to  arise
     if intermediate relays are used. It is possible to support all
     these things using it, and  of  course  they  are  encouraged.
     However,  I  feel that a service adequate for ordinary use can
     be achieved without  defining  a  great  deal  of  complicated
     additional  mechanism  to guarantee these properties. Finally,
     the  problem  of  conversion  between  mail  formats  is   not
     discussed at all.

     3. Basic Elements

     3.1 Mail Format

Bennett                                                         [Page 2]

INDRA Note 1025                                         NIFTP-Based Mail

       The mail format defines the standards for the appearance  of
     a  message;  it covers such things as the definition of header
     fields to  allow  messages  to  be  processed  by  a  standard

       The mail format most readily available is the  ARPANET  mail
     standard  commonly  known  as  RFC733, defined in [Crocker77],
     which is compatible with all except the last of the objectives
     listed above. RFC733 has been widely and successfully used for
     many years. In practice only  a  subset  of  the  standard  is
     actually  used  -  in particular, the standard allows extended
     addressing  by  specifying  destination   networks,   but   no
     implementation  supports  this. It is proposed that the common
     subset of this standard be used. The only change suggested  is
     that  the  text  code  should  be  IA5  rather than the Telnet
     version of ASCII, as IA5  is  an  international  standard.  In
     practice,  the  two codes are virtually identical.  An example
     of an RFC733 message, and a summary of the RFC733  syntax,  is
     given in Appendix I.

       This standard is completely text-oriented, for both  message
     header  (control)  and  message text (data) information.  This
     makes it readily compatible with most of  the  text-processing
     software generally available on most interactive systems, such
     as text editors, pro forma preparation etc.

       Other formats may be agreed to in the near future. These may
     extended  facilities,  such  as facsimile or multi-media mail.
     These can be accommodated provided any mail servers needing to
     process  the  mail body understand the format in use. Hence it
     may be necessary to provide a means for labelling  the  format
     in use. Such a label is not defined at this time.

     3.2 Mail Addresses

       In any mail system it is essential to provide addresses  for
     the  mail  recipient, and usually for the mail sender as well.
     While mail will frequently be transferred directly between the
     sender and the recipient, there will be occasions when it will
     be  routed,  and  possibly  temporarily  stored,  through   an
     intermediate mail relay.

Bennett                                                         [Page 3]

INDRA Note 1025                                         NIFTP-Based Mail

       Mail addresses are constrained to  be  compatible  with  the
     RFC733  format  as generally used, viz. <username>@<hostname>.
     The <hostname> field defines the host used for an initial mail
     transfer, and in standard RFC733 usage, no further structuring
     is defined or required. If this  name  is  understood  by  all
     message  relays  along a route, then no further structuring is
     ever required. If further structuring is required,  it  should
     be  through  the  use of element separators in the <username>.
     The addressing structures encountered when mail relays must be
     used are discussed further in section 5.1.

     3.3 Mail Transfer

       In addition to  the  appearance  of  the  messages  and  the
     identity  of the parties, it is necessary to define a protocol
     for transferring mail between the  two.  At  first  sight,  it
     would seem natural to take over ARPA-developed procedures here
     too, so that  one  could  use  a  complete,  preexisting  mail
     package.   Despite the great success which have attended these
     procedures,  and  their  undoubted  appropriateness  for   the
     environment  for  which they were designed, they do not fulfil
     the needs of the wider message community,  for  reasons  which
     are discussed below.

       The standard  ARPANET  Mail  Transfer  procedure  [Postel76]
     fulfils  only  the  first  of  the  requirements listed in the
     introduction, and is therefore not acceptable. In  particular,
     it has the following failings:

      (1)    It is uneconomic in that it  transmits  one  copy  per
             destination user.

      (2)    It is specific to the ARPANET.

      (3)    It transfers address information in  a  way  which  is
             only usable for direct source/destination transfer.

      (4)    It requires all hosts to be aware of all  host  names,
             and   hence  requires  a  globally  understood  global
             address space.

      (5)    It can only ever handle text data. If binary data in a
             mixed-media message were encoded as text symbols and a
             code conversion was required between NVT-ASCII  and  a
             local text encoding, that data would be corrupted.

Bennett                                                         [Page 4]

INDRA Note 1025                                         NIFTP-Based Mail

       A recent ARPA proposal [Sluizer80] for a new  Mail  Transfer
     Protocol  (MTP)  remedies  in  whole  or in part some of these
     deficiencies.  In  particular,  it  provides  facilities   for
     economic   uses   of   resources,   and  transfers  addressing
     information in a way compatible with objectives (iv) and  (v).
     However  the MTP as it is currently proposed has some problems
     of its own:

      (1)    The MTP allows a single copy of a message to  be  sent
             to  multiple  recipients, and is thus potentially more
             economic than the  standard  ARPA  protocol.  However,
             this  is only an option which need not be implemented.
             Moreover, the mail sender can only  specify  one  path
             for  a  given  message  to  pass  through intermediate
             relays. Thus MTP does not allow a single  copy  to  be
             sent  to  a  relay  which  could then decide to create
             multiple copies  for  different  destinations  at  the
             point of a path division.

      (2)    In MTP, address lists may be transferred either before
             or after the message body. With the 'recipients first'
             option, it is  only  possible  to  check  the  current
             validity  of  the  addresses  - for the actual message
             transfer, only total success and total failure can  be
             indicated.  If  a  given recipient became inaccessible
             for some reason between the  two  stages,  the  entire
             transfer would fail.

      (3)    The MTP  is  defined  to  operate  in  an  environment
             similar to that of the ARPA Catenet. In particular, it
             relies  heavily  on  the   use   of   Telnet   command
             procedures,  which  are  both  little known and little
             used outside the ARPA community  -  especially  within
             Europe.  It does not define the mechanisms by which it
             will operate across more than  one  network  (just  as
             Telnet  does  not), or where Telnet procedures are not
             appropriate.  To  this  extent,  it  is  not  network-

      (4)    The MTP provides no restart procedures to recover from
             errors   signalled   by   either   the   host  or  the
             transmission medium. It is therefore only as  reliable
             as  the  weakest  underlying network.  For example, an
             X25-based version could not recover from Resets.

Bennett                                                         [Page 5]

INDRA Note 1025                                         NIFTP-Based Mail

      (5)    It can only ever handle text data. If binary data in a
             mixed-media message were encoded as text symbols and a
             code conversion was required between NVT-ASCII  and  a
             local text encoding, that data would be corrupted.

       Accordingly, it is felt here that mail transfer outside  the
     ARPA  environment  should  use  an  alternative  base.  It  is
     proposed here that mail transfer  be  achieved  using  defined
     conventions   with   the  Network  Independent  File  Transfer
     Protocol (NIFTP - [HLPG81]). This FTP is, as the name implies,
     network  independent,  has  been  implemented  on  a number of
     different existing networks, including the  ARPANET  and  ARPA
     Catenet,  and  has  been  successfully  used  for  direct file
     transfers across several intermediate  networks.  The  revised
     version  will be adopted as an interim standard in Britain and
     has  evoked  wide  interest  in  Europe.  There  are  numerous
     implementations  of  the  existing version, and it is expected
     that the revised version will be  implemented  fairly  rapidly
     after  the  new  specification  is  released,  which should be
     within the next two months. It  thus  meets  the  criteria  of
     availability,  standardisation  and  network  independence. It
     remains to define a transfer procedure which meets  the  other

     4. Point to Point Mail Transfer

       Using RFC733 mail formats and RFC733-compatible  addressing,
     it  is necessary to define the procedure used to transfer mail
     from a mail donor to  a  mail  server  with  the  NIFTP.  This
     section defines that procedure.

     4.1 Mail Structure

     4.1.1 Proposal

       A letter shall be transferred as a single file from the mail
     donor  to  the  mail  server.   The  file  name  used shall be
     provided by the mail server. The structure of the file  is  as

     <address list><one or more blank lines><mail text>

     The  <address  list>  is  a  list  of  full,  explicit  RFC733

Bennett                                                         [Page 6]

INDRA Note 1025                                         NIFTP-Based Mail

     addresses to whom the mail shall be distributed  by  the  mail

     The <mail text> shall conform with RFC733 formats.

     4.1.2 Discussion Address Lists

       This structure is designed to fulfil  the  requirement  that
     the  service  be  economic.  The passing of the <address list>
     minimises the number of copies of the message  which  must  be
     made  by  the donor, but allows decisions to create additional
     copies to be made simply by intermediate relays.

       The <address list> must contain explicit  addresses  as  the
     mail  server  is not necessarily able to access address lists,
     and in any case requires additional mechanism to  do  so.  The
     addresses  should be full (i.e. contain an explicit <hostname>
     component) as the server may be a relay using address  mapping
     mechanisms (see below). Possible Extensions

       There are two simple extensions which may be desirable:

      (1)    To distinguish between message formats. This  requires
             simply  the  addition  of  an  extra field in the mail
             file, and the definition of  text  encodings.  Such  a
             field  should  be  inserted between the <address list>
             and the <message text>. The use of other formats  will
             particularly affect the design of mail relays.

      (2)    Mailbagging. The file  may  contain  several  messages
             separated  by  defined  message  delimiters. (A simple
             one, which is widely used in  message  files  on  UNIX
             systems   in   the   ARPANET,  is  ^A^A<cr>.   Another
             alternative,  preferred   here,   is   to   insert   a
             delimitered  character  count,  encoded  in IA5, as in
             TENEX.) Mailbagging also has other implications.   For
             instance,  if  the  mail  donor  wishes  to initiate a
             mailbagged transfer  and  it  knows  the  name  of  an
             existing   mailbag  at  the  server  from  a  previous
             transfer, it may  append  the  file  to  the  existing

Bennett                                                         [Page 7]

INDRA Note 1025                                         NIFTP-Based Mail

             mailbag.  The advantages of a mailbagging  system  are
             for further study. Alternative Structures

       Two alternative structures were considered,  both  involving
     the  explicit  separation  of  the  address list from the mail

       The first was to require the donor to specify the file name,
     which  would  be  the  address  list.  This  has  a  number of

      (1)    The NIFTP  allows  a  maximum  string  length  of  255
             characters  for  string-valued  attributes. This would
             allow at most about 12-20 addresses.

      (2)    It would be difficult  to  trace  the  progress  of  a
             message  through  a series of relays. With an explicit
             and known filename, it would be possible  to  initiate
             manual or automatic tracing procedures.

      (3)    It is unlikely that most mail servers or relays  would
             be  able to use such a filename directly. The internal
             filename would be created using  local  mappings.  The
             potential costs of these mappings could be very high.

       The  second  alternative  considered  was  to  transfer  the
     address  list  and  mail text as two separate files. This also
     has disadvantages:

      (1)    The two files must be linked, e.g. by  requiring  that
             an  Action  Message  be  passed  on  STOP  or  STOPACK
             containing the  filename  to  be  used  for  the  text
             portion of the transfer.

      (2)    An additional level of error handling  procedure  must
             be  defined,  to  cover  cases  such  as the loss of a
             portion of the message text, or  the  arrival  of  two
             address lists with no intermediate message text.

Bennett                                                         [Page 8]

INDRA Note 1025                                         NIFTP-Based Mail

       These problems are avoided by  the  mechanism  proposed.  By
     sending  the  address  list  and  the  body  as a single file,
     address lists of arbitrary length can be sent; their  link  to
     the  text  is  assured;  maximum  use can be made of the NIFTP
     reliability mechanisms; and the donor can be assured that  the
     mail has at least reached the server host.

       The new MTP proposal from the ARPA community  has  a  fairly
     similar  proposal,  but  allows  as  an  additional option the
     possibility of transmitting the  text  before  the  addressing
     data,  arguing  that  in some cases this is more efficient for
     the destination host. Although it is conceivable that this may
     be  true  for  MTP  given the details of the MTP mechanisms, I
     think it is most unlikely that any advantage would  be  gained
     in  the  current  context;  moreover,  in  order to achieve it
     additional mechanism is required to specify  which  option  is
     being used. Hence it has not been proposed.

     4.2 Mail Server Identification

     4.2.1 Proposal

       The mail server will be identified by its transport  service
     subaddress.  This  subaddress  will  be  network-specific  and
     possibly host-specific; for instance, on the ARPANET  it  will
     be  an  NCP  server socket, on the ARPA Catenet a TCP port, on
     public data networks an X25 or Transport Service subaddress as

       If the mail donor and server are not on the  same  transport
     service,  it is the responsibility of the intermediate virtual
     call gateways to perform any address transformations required,
     e.g. mapping the NCP mail socket to the TCP mail port.

     4.2.2 Discussion

       This proposal is in line  with  the  recommendation  in  the
     NIFTP  specification  for  distinguishing  different  services
     utilising NIFTP. An alternative, which is not  favoured  here,
     is  to  reserve  a  value  for the Username attribute, such as

Bennett                                                         [Page 9]

INDRA Note 1025                                         NIFTP-Based Mail

     4.3 Mail Server Communication

     4.3.1 Proposal

       Synchronisation shall be achieved via the  establishment  of
     an  virtual  connection  between  the  mail donor and the mail
     server. This connection may be  used  for  one  or  more  mail
     transfers. The connection may have one or more segments, where
     each segment may use a different transport protocol.

     4.3.2 Discussion

       This is normal NIFTP usage, and is essentially a restatement
     of the network-independence criterion.

       Normally, the donor and server will use the  same  transport
     protocol,   and   no   additional  procedures  need  be  used.
     Exceptionally, the mail donor and server may  not  be  on  the
     same  transport  service.  In  this  case  direct  NIFTP  file
     transfer is  still  possible,  but  an  additional  degree  of
     support  is  needed,  through  the  provision  of  one or more
     virtual call gateways. At the least,  the  following  services
     are necessary:

      (1)    One-to-one connection mapping.

      (2)    Addressing procedures. This could  be  any  acceptable
             procedure,   e.g.   source   routing,  creation  of  a
             hierarchical address space, or  mapping  of  transport
             service subaddress to destination host.

      (3)    Call request facility. This carries all the addressing
             information  necessary  for establishing an end-to-end

      (4)    Call accept facility. This  is  necessary  to  confirm
             that an end-to-end path has been established.

      (5)    Data transfer. This should commence only after a  call
             accept has been received.

      (6)    Push preservation. Data should  be  forwarded  if  any
             push  indication  (e.g.  TCP EOL, X25 No More Data) is
             received. The gateway may decide to  forward  data  in
             other circumstances.

Bennett                                                        [Page 10]

INDRA Note 1025                                         NIFTP-Based Mail

      (7)    Closure  propagation.  If  a  connection  closure   is
             received  from  one  side, it shall be mapped into the
             appropriate closure procedure on the other.

      (8)    Reset propagation. If  any  network  in  the  path  is
             capable  of generating resets, these must be forwarded
             in some fashion by the gateway. For instance,  an  X25
             RESET  may be mapped into TCP URGENT. If resets cannot
             be generated this may be ignored by the gateway.

     It should be noted that the address transformations  mentioned
     above need not be visible to the mail donor and server, and do
     not in any circumstances require  address  processing  of  the
     mail  text  at the virtual call gateway. For bidirectionality,
     however, it  is  necessary  that  the  donor  and  server  can
     recognise  their  respective hostnames as embedded in the mail

     4.4 Mail Transfer

     4.4.1 Proposal

       The transfer may be initiated by either the  mail  donor  or
     the mail server.

       The file will be transferred by the  NIFTP  using  IA5  text
     codes. If the file only contains a text message, then the Data
     Type attribute will indicate text only.

       If the transfer is initiated by the  mail  donor,  then  the
     Mode of Access used will be 'Replace or Make' and the Filename
     attribute on the SFT will indicate 'no value  available';  the
     server  should  supply  a  value  on  the  RPOS  for reporting

       If the transfer is initiated by the mail  server,  then  the
     Mode  of  Access  used  will  be  'Read  Only'. The donor will
     nevertheless often wish to delete the file after it  has  been
     successfully  transferred.  The  Filename attribute on the SFT
     will supply a value.

       No other  constraints  are  imposed  on  the  use  of  NIFTP

Bennett                                                        [Page 11]

INDRA Note 1025                                         NIFTP-Based Mail

     4.4.2 Discussion

       This section defines the actual mail transfer procedure, and
     places minimal restrictions on NIFTP use.

       Alternative  structures  lead  to  greater  restrictions  or
     special interpretation of NIFTP attributes, or both.

       If a message format other than RFC733 is used,  then  mixed-
     media  transfers  may  be possible.  The NIFTP procedure would
     then have to be modified. If the file contains  a  mixed-media
     message,  then  the  Data  Type attribute will indicate either
     mixed file or mixed records as  appropriate,  and  the  binary
     formats for the non-text portions will be negotiated.

       Mailbagging may also require extension. In  this  case,  the
     mode  of  access  used by a mail donor initiating the transfer
     could be 'Append or Make', though this is not recommended.

       Other facilities which may be useful are: data  compression,
     text  formatting,  record  structuring, restart and resumption
     recovery facilities, account name, various passwords etc.

     4.5 Reliability

       The NIFTP has several grades of recovery action,  which  can
     be  exploited  to ensure that a message will be delivered to a
     server  despite  the  occurence  of  system  or  communication
     errors.   However,  the  successful delivery of a message to a
     server does not guarantee it will be successfully delivered to
     the recipient.  If it cannot be delivered, notification should
     be sent to the sender by the  server  forced  to  discard  it,
     where  this  is  possible. This notice will take the form of a
     message, and the sender's  address  will  be  determined  from
     inspection  of  the  appropriate  fields (i.e. "Reply-to:" and
     "From:") in the message. A  non-delivery  notice  should  make
     maximum use of the NIFTP reliability procedures to ensure that
     it itself is delivered.

     5. Mail Relays

       For a number of reasons it may not be possible to transfer a
     message  direct  between  the  sender  and  the  receiver.  In
     particular, they may not use the same mail transfer procedure.

Bennett                                                        [Page 12]

INDRA Note 1025                                         NIFTP-Based Mail

     In such cases, mail must be  staged  through  an  intermediate
     mail server, which acts as a mail relay.

       The function of the relay is to redistribute  received  mail
     to  the  destinations or to other mail relays. I do not intend
     to specify a  mail  manipulation  protocol  here,  but  it  is
     necessary to discuss the functions which must be provided, and
     the options which are available, in order to determine to what
     extent  it is possible to allow variation and still provide an
     acceptable service. Since the actions of other mailing systems
     cannot  be  specified here, these functions will be discussed,
     where  necessary,  in  relation  to  the  NIFTP-based   system
     described above.

       It is important to distinguish these relays from the virtual
     call  gateways  discussed  above.  Either  may  be used at the
     interface between two transport services, but the virtual call
     gateway gives the minimum facilities which must be provided at
     this point, and is invisible to the  endpoint  mail  transfer.
     Mail   relays  must  be  used  when  different  mail  transfer
     protocols are used by mail donor and recipient,  and  will  be
     visible  to  both  the  sender  and  recipient; in this case a
     virtual call gateway will be totally inadequate.

     5.1 Address Processing

       It is not possible to prescribe an addressing format for use
     by  relays,  except that it be RFC733-compatible.  The actions
     to be taken by the relay on processing addresses are dependent
     on  local  conventions  and private agreements. It is expected
     that there are three major types of address  processing  which
     may occur:

      (1)    The address of the next stage  may  be  defined  by  a
             received  <hostname> component, which is understood by
             the relay to map to the name of some other  host.  For
             example,  the  name 'Linington@Cambridge', if received
             at UCL from  the  US,  might  cause  the  mail  to  be
             transferred  to  Cambridge,  or  to  some intermediate

      (2)    If no <hostname> is received (which  can  only  happen
             from  a  non-NIFTP mailing system), the address of the
             next stage may be defined  by  a  received  <username>
             component,  which is understood by the relay to map to

Bennett                                                        [Page 13]

INDRA Note 1025                                         NIFTP-Based Mail

             the  name  of  some  other  relay  host,  or  to   the
             <username>  and  <hostname>  of  the  final  user. For
             example, the name 'DCPU', if received at UCL from  the
             US,     might     be     understood    to    map    to
             'Linington@Cambridge', and be forwarded. This form  is
             not  encouraged  as user names must then become widely

      (3)    If  the  <hostname>  is  the  relay  itself,  and  the
             destination is not at the relay, then either case (ii)
             applies, or the username is structured in some fashion
             understood  by  the  relay.   A  recommended  form  is
             through the use of % as a separator, which leads to  a
             source-routed form, e.g:


             On reception  at  UCL  from  the  US,  the  <hostname>
             component  will  be discarded, the last % converted to
             an   @,   and    the    structured    name    becomes:
             Linington%Cambridge@PSS.  The  relay  then injects the
             message into the appropriate mailing system over  PSS,
             subject to the constraints of that system.

     Any or all of these  approaches  may  coexist.  As  a  general
     approach,   I   prefer   the   third.   All  suffer  from  the
     disadvantages that they  are  not  global,  and  that  address
     transformation  may be required. The user who uses relays must
     use an address format he is sure will be understood along  the
     route. In practice, however, it is unlikely that more than one
     or two relays  will  be  involved  in  the  transfer  of  most

       The address processing at mail relays, which may affect  the
     text  of the message received, must be carefully distinguished
     from the address processing which may be required  at  virtual
     call  gateways  between  the donor and server, which does not.
     Two different levels of addressing are  involved  here  -  the
     former  is  visible  only  in  mail,  the latter only within a
     particular file transfer.

     5.2 Return Paths

       The system provides no  guarantee  that  a  message  can  be
     replied  to,  although  this will normally be possible. Relays

Bennett                                                        [Page 14]

INDRA Note 1025                                         NIFTP-Based Mail

     can provide assistance in the following ways,  both  of  which
     involve the processing of the header content of the message:

      (1)    Each relay can insert a "Via: " field in the message.

      (2)    Each relay can add its name to a  "Reply-to: "  field,
             thus building up a return source route. The name added
             must be the name known  to  the  message  system  into
             which it is forwarding the mail.

       The general problem is  to  allow  replies  to  be  sent  to
     recipients  other than the sender. One possibility is to allow
     replies to be redistributed by the original sending  host,  if
     that  host  is  willing  to do so. Alternatively, intermediate
     relays could process the names of "To: " and "Cc: " fields  in
     the message to provide a shorter path. This problem is exactly
     analogous to the "third-party addressing" problem  of  the  UK
     Transport  Service  [SG3/80],  and the techniques discussed in
     that document could be used here.

       Although this  procedure  requires  relays  to  process  the
     message  text,  programs  to  do such processing already exist
     which could be used for this purpose. If  such  processing  is
     not  done,  it is necessary to insist that replies can only be
     sent if the recipient knows the location of the sender,  which
     for  full  answerability amounts to a requirement for a global
     address space. This contravenes one of the stated  limitations
     on the system.

     5.3 Economy

       Where the mail system  protocols  allow,  the  relay  should
     minimise  the  number of copies of a message injected into the
     system. Thus a relay may receive a single copy  of  a  message
     destined  for  several  different  hosts, some of which may be
     only accessible through another relay. For each host which can
     be  reached  directly the relay will send a single copy of the
     message; for the remaining hosts, a single copy will  be  sent
     to the next relay which will redistribute it in turn.

       This minimisation may require considerable  intelligence  to
     do  properly, and may not always be practicable.  If the relay
     is receiving mail from a system which  creates  one  copy  per
     user,  and  injecting  it  into a system similar to the NIFTP-

Bennett                                                        [Page 15]

INDRA Note 1025                                         NIFTP-Based Mail

     based system described here, there  is  no  easy  option.  One
     possibility  is  to  parse  the  header to identify, so far as
     possible, how many copies of the  message  it  may  expect  to
     receive,  detect  the duplicates, and discard them. Another is
     for a relay to create a mail list and instruct a recipient  to
     "Reply-to: <mail list name>@<relay>".   It   must   then  have
     criteria for deciding how long to keep such lists  around.  No
     doubt other equally inspiring schemes can be devised.

     5.4 Reliability

       Relays should make use of the mail system to  give  delivery
     failure  notifications, as described above. There is, however,
     no guarantee that the return path can be constructed.

     6. The ARPA Mail Transition Plan: A Case Study

       In this section a proposal is made for using the NIFTP-based
     protocol to allow mail transfer between ARPANET users who have
     only NCP-based mail transfer available to them, and those  who
     have only TCP-based network access.

     6.1 Current Proposals

       The current proposals for ARPANET mail transition centre  on
     the  implementation  of  the  MTP  discussed  above,  and  the
     definition  of  relay  procedures  between  NCP-based  mailing
     systems  and TCP-based mailing systems [Postel80]. In general,
     these relays fit into the context discussed  in  the  previous
     section,  and  most of the comments of the current proposal on
     the complexity of maintaining relays, mapping tables  etc  are
     fully endorsed here.

       Aside from the features of the MTP, there are a two specific
     points that need discussion:

      (1)    As noted in the October  1980  Internet  meeting,  the
             transition  plan  requires  that  user names be unique
             throughout the  ARPA  Catenet  (and  hence  a  growing
             portion  of  the ARPANET), in order to allow ARPA mail
             from a standard ARPANET NCP-based mail  server  to  be
             sent  to  a  relay for forwarding to the ARPA Catenet.
             This is clearly unacceptable, and can most  simply  be

Bennett                                                        [Page 16]

INDRA Note 1025                                         NIFTP-Based Mail

             avoided by  allowing  the  relays  to  parse,  and  if
             necessary  modify  the  header  fields  in the message
             text. Such solutions are preferable.

      (2)    The solution is inextensible.   The  transition  plans
             assumes  that transfer of mail between two MTP servers
             on hosts using only  NCP  and  TCP  must  be  achieved
             through  an MTP-based mail relay at a site with access
             to both. This is rather  wasteful,  since  essentially
             the same protocol is involved in both cases. A similar
             relay is required  if  other  transport  services,  or
             network services such as X25, require mail service.

     6.2 NIFTP and the Transition Plan

       The major  fault  of  the  current  transition  arrangements
     relevant here is that a complex message relay is required even
     for hosts which both talk MTP. This is not the  case  for  the
     NIFTP-based  scheme  outlined here. All that is necessary is a
     relatively  simple  virtual  call  gateway   at   an   NCP/TCP
     transition  point,  along  the  lines  discussed above. Such a
     gateway  has  been  built  and  its  feasability  demonstrated
     [Bennett80]. Moreover, it has been demonstrated that the NIFTP
     can be readily extended to non-Catenet networks, whereas it is
     far  from  clear  that  this is true for the MTP-based scheme,
     because of its reliance on Telnet.

       The advantage of an explicitly network-independent  approach
     is  that  mail  transition  can  now be entirely divorced from
     NCP/TCP transition. The development of future  mail  protocols
     can carry on without requiring an immediate, new, solution for
     the Catenet. Any host with NIFTP can do direct mail  transfers
     using existing formats.

       Of course, very few ARPANET  hosts  have  access  to  NIFTP,
     although this is easy to change.  However, it is not necessary
     that they should. There is indeed  a  staging  problem  to  be
     solved - the staging between NIFTP-based mail and current ARPA
     mail. This must take place along the  lines  discussed  above,
     but once solved, it is solved, in theory, not just for NCP and
     TCP but for any transport protocol.

Bennett                                                        [Page 17]

INDRA Note 1025                                         NIFTP-Based Mail

     6.3 A Proposal

       It is believed that an NIFTP scheme  of  this  sort  can  be
     built  and proliferated very quickly. The following components
     already exist:

      (1)    NIFTP implementations written to a  transport  service
             interface for TOPS20 DEC20s, UNIX PDP-11s (Version 6),
             and MOS LSI-11s. These need to be upgraded to  conform
             to the new specification of the protocol. The first is
             available above TCP and NCP; the second  will  shortly
             be  accessible  above  TCP  and  X25; and the third is
             available above TCP.

      (2)    A simple  NCP/TCP  virtual  call  gateway,  for  NIFTP
             support, on a TOPS20. This was built for demonstration
             purposes, and needs some modification for general use.

      (3)    Message relays for heterogenous mail systems,  in  the
             form of the MMDF system developed by the University of
             Delaware [Crocker79], for UNIX. Such  relays  must  be
             built in any case for the MTP scheme.

     The following components are needed:

      (1)    Specification  and  agreement  to  the  virtual   call
             extensions needed for direct NCP/TCP file transfer. If
             these are done using a subset of the protocol proposed
             for  implementing  the  UK Transport Service above TCP
             [Bennett80a] (and a similar protocol  for  NCP),  then
             direct  mail  transfers from NCP sites to sites on the
             UK public network PSS could also be done.

      (2)    Allocation of NIFTP-mail  server  sockets  and  ports.
             Again,   for  extension  to  the  UK  public  network,
             Transport Service and/or X25 subaddresses must also be

      (3)    Agreement on an addressing scheme  to  allow  transfer
             from  ARPA  mail  to NIFTP-based sites. It is proposed
             that a structured user name of the form outlined above
             be used.

      (4)    Implementation of an NIFTP  mail  channel  in  a  form
             suitable for incorporation under MMDF by UCL.

Bennett                                                        [Page 18]

INDRA Note 1025                                         NIFTP-Based Mail

      (5)    At least one system in the US  supporting  MMDF  which
             can  act  as a relay between ARPA mail and NIFTP mail,
             using the NIFTP channel supplied by UCL.

      (6)    Code interfacing the transport  service  interface  of
             the UNIX NIFTP directly to UNIX TCP (and possibly NCP)
             implementations, supplied by the US MMDF site.

       This allows us to define the minimum configuration necessary
     to  provide  NIFTP-based mail transfer between UCL systems and
     systems in the CONUS ARPANET using either the current  ARPANET
     mail  transfer  protocol  or the new MTP. The path would be as

      (1)    UCL donor passes mail to UCL UNIX NIFTP in core.

      (2)    NIFTP initiates a  connection  to  the  remote  NIFTP,
             which  is which is driven as a mail channel by an MMDF
             system (e.g. SRI-UNIX or UDEL-EE). This path will  be:
             through the UCL UIPP protocol to the Front End; thence
             via TCP through UCLNET, SATNET and the CONUS  ARPANET,
             either  directly to the remote system, or to a TCP/NCP
             virtual call gateway resident at ISIE (which  in  turn
             forwards  the  NIFTP traffic to the remote MMDF server
             through NCP).

      (3)    The remote MMDF  injects  the  mail  into  either  the
             standard  ARPANET  mail  channel or an MTP channel; at
             the remote end of which it is delivered to the  user's

       In addition, it would be highly desirable  to  construct  an
     MMDF-like system which could act as a multi-channel mail relay
     on TOPS20 systems in the ARPANET. All relevant  mail  channels
     could  be  driven  through  it  in a precisely similar manner.
     However, rather more work is required  to  make  this  service

       The above discussion ignores MTP-based mail altogether. This
     has been done for illustrative purposes only - I have no doubt
     that the current transition plans will be implemented,  though
     possibly not quite in their current form. In practice, the two
     systems could  coexist  quite  happily.  The  main  impact  of
     allowing  the  two  systems to proceed in parallel would be in

Bennett                                                        [Page 19]

INDRA Note 1025                                         NIFTP-Based Mail

     the design of mail relays.  The  more  mail  transfer  systems
     exist,  the  more important it is that relays be designed in a
     'mail-independent'  fashion.  The  advantages  of  this   have
     already   been  demonstrated  for  the  UNIX  MMDF.  The  same
     principles should be followed in  the  design  of  relays  for
     other computer systems.

     7. NIFTP-Based Mail in the UK.

       Within Britain, the problems of building a mail system along
     these  lines  are  rather  different,  but  on  the whole less
     complex. The basic  communications  facilities  are  only  now
     coming into widespread use, and the investment in higher level
     protocols is much lower. However, the higher  level  protocols
     which  are  coming into use are much friendlier to the system,
     for the following reasons:

      (1)    NIFTP is already available on most widely used machine
             types  in  Britain.  Implementing  the  mail  transfer
             procedure is a trivial additional exercise.

      (2)    The UK transport service proposals assume the need for
             network  interconnection  to  provide  a  semantically
             equivalent service rather than a  superimposed  common
             protocol.  Hence  the  need  for extensibility through
             virtual call gateways is widely accepted.

      (3)    Because  there  is  no  heavy  investment   in   first
             generation protocols, there is no absolute requirement
             for mail relays at this stage.

       The major need is for  message  processing  and  preparation
     programs, as such programs are not widely available in the UK,
     except for UNIX systems. In particular, these should be  based
     on  RFC733  procedures.  For  many  system  types these may be
     available from similar systems in the US; others would have to
     be developed from scratch.

     8. References

     [Bennett80] - Bennett, C. J.: The Design and Implementation of

Bennett                                                        [Page 20]

INDRA Note 1025                                         NIFTP-Based Mail

          Transnetwork  Systems.  UCL   TR   65.   Available   from
          Univeristy College London.

     [Bennett80a] - Bennett, C. J.: Realisation of the Yellow  Book
          Above  TCP.  INDRA  Note  965.  Available from University
          College London.

     [Crocker77] - Crocker, D. H., Vittal, J. J.,  Pogran,  K.  T.,
          Henderson  Jr,  D.  A.:  Standard  for the Format of ARPA
          Network   Messages.   RFC733.    Available    from    SRI
          International,  Menlo Park, California. Obsoletes earlier

     [Crocker79] - Crocker, D. H., Szurkowski, E.  S.,  Farber,  D.
          J.:  An Internetwork Memo Distribution Capability - MMDF.
          Proc. 6th Data Comm. Symp.

     [HLPG81] - HLPG/FTPIG: A  Network  Independent  File  Transfer
          Protocol.   Available   from   DCPU,   National  Physical
          Laboratory, Teddington, UK. Obsoletes earlier versions.

     [Postel76]  -  Postel,  J.  B.:  Mail  Protocol.  NIC   29588.
          Available from SRI International, Menlo Park, California.

     [Postel80] - Postel, J. B., Cerf, V. G.: Mail Transition Plan.
          RFC773.  Available  from  SRI  International, Menlo Park,

     [SG3/80] - PSS/SG3: A Network Independent  Transport  Service.
          Available  from  the  DCPU, National Physical Laboratory,
          Teddington, UK.

     [Sluizer80] - Sluizer, S., Postel,  J.  B.:  A  Mail  Transfer
          Protocol. RFC772. Available from SRI International, Menlo
          Park, California.

Bennett                                                        [Page 21]

INDRA Note 1025                                         NIFTP-Based Mail

                                 APPENDIX I

                               RFC733 Formats

            Below is an example of an RFC733 message taken from the

                 Date: 26 August 1976 1430-EDT
                 From:George Jones<Group at Host>
                 Sender:Secy at SHOST
                 To:Al Neuman at Mad-Host,
                          Sam Irving at Other-Host
                 Message-ID:  <some string at SHOST>

                 This is an example of an RFC733 message. Both
                 simpler and more complex headers are possible.

            The entire RFC733 syntax specification is summarised in
          the   following  listing,  extracted  from  the  original

          address     =  host-phrase / quoted-string
                      / (*phrase "<"  address ">" )
                      / (*phrase ":"  address ";" )
                      / (":" ("Include" / "Postal" / atom) ":" address)
          ALPHA       =  <any TELNET ASCII alphabetic character>
          atom        =  1*<any CHAR except specials and CTLs>

          CHAR        =  <any TELNET ASCII character>
          comment     =  "(" *(ctext / comment / quoted-pair) ")"
          CR          =  <TELNET ASCII carriage return>
          CRLF        =  CR LF
          ctext       =  <any CHAR excluding "(", ")", CR, LF and
                         including linear-white-space>
          CTL         =  <any TELNET ASCII control character and DEL>

          date        =  1*2DIGIT ["-"] month ["-"] (2DIGIT /4DIGIT)
          date-field  =  "Date"       ":" date-time
          date-time   =  [ day-of-week "," ] date time
          day-of-week =  "Monday"    / "Mon"  / "Tuesday"   / "Tue"
                      /  "Wednesday" / "Wed"  / "Thursday"  / "Thu"
                      /  "Friday"    / "Fri"  / "Saturday"  / "Sat"
                      /  "Sunday"    / "Sun"
          delimiters  =  specials / comment / linear-white-space

Bennett                                                        [Page 22]

INDRA Note 1025                                         NIFTP-Based Mail

          DIGIT       =  <any TELNET ASCII digit>

          extension-field = <Any field which is defined in a document
                         published as a formal extension to this

          field       =  field-name ":" [ field-body ] CRLF

          fields      =  date-field  originator-fields  *optional-field
          field-body  =  field-body-contents
                         [CRLF LWSP-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, and specials tokens, or else consisting of
          field-name  =  fnatom *(LWSP-char [fnatom])
          fnatom      =  1*<any CHAR, excluding CTLs, SPACE, and ":">

          host-indicator =  1*( ("at" / "@") node )
          host-phrase =  phrase  host-indicator
          hour        =  2DIGIT [":"] 2DIGIT [ [":"] 2DIGIT ]
          HTAB        =  <TELNET ASCII horizontal-tab>

          LF          =  <TELNET ASCII linefeed>
          linear-white-space =  1*([CRLF] LWSP-char)
          LWSP-char   = SPACE / HTAB

          mach-id     =  "<" host-phrase ">"
          mailbox     =  host-phrase /  (phrase mach-id)
          message     =  fields *(CRLF *text)
          month       =  "January"   / "Jan"  / "February"  / "Feb"
                      /  "March"     / "Mar"  / "April"     / "Apr"
                      /  "May"                / "June"      / "Jun"
                      /  "July"      / "Jul"  / "August"    / "Aug"
                      /  "September" / "Sep"  / "October"   / "Oct"
                      /  "November"  / "Nov"  / "December"  / "Dec"

          node        =  word / 1*DIGIT

          optional-field  =
                         "To"         ":"  address
                      /  "cc"         ":"  address
                      /  "bcc"        ":"  address
                      /  "Subject"    ":" *text
                      /  "Comments"   ":" *text

Bennett                                                        [Page 23]

INDRA Note 1025                                         NIFTP-Based Mail

                      /  "Message-ID:" mach-id
                      /  "In-Reply-To"":"  (phrase / mach-id)
                      /  "References:"  (phrase / mach-id)
                      /  "Keywords"   ":"  phrase
                      /  extension-field
                      /  user-defined-field
          originator-fields =
                         (  "From"     ":" mailbox
                           ["Reply-To:"  address] )
                      /  (  "From"     ":" 1 address
                            "Sender"   ":" mailbox
                           ["Reply-To:"  address] )

          phrase      =  1*word

          quoted-pair =  "
          quoted-string =  <">  *(qtext / quoted-pair)  <">
          qtext       =  <any CHAR except <">, CR, or LF and including
          SPACE       =  <TELNET ASCII space>
          specials    =  "(" / ")" / "<" / ">" / "@"/ "," / ";" / ":"
                      /  "

          text        =  <any CHAR, including bare CR and/or bare LF, but
                         NOT including CRLF>
          time        =  hour zone

          user-defined-field = <Any field which has not been defined in
                         this specification or published as an extension to
                         this specification; names for such fields must be
                         unique and may be preempted by published

          word        =  atom / quoted-string

          zone        = ( ("+" / "-") 4DIGIT )
                      / ( ["-"] (1ALPHA
                        / "GMT" / "NST"  / "AST" / "ADT" / "EST" / "EDT"
                        / "CST" / "CDT"  / "MST" / "MDT" / "PST" / "PDT"
                        / "YST" / "YDT"  / "HST" / "HDT" / "BST" / "BDT" ))

          <">         =  <TELNET ASCII quote mark>

Bennett                                                        [Page 24]

INDRA Note 1025                                         NIFTP-Based Mail

                                 APPENDIX II

                       UCL Mail System Plans for 1981

            The following is an extract from the UCL annual  report
          for  the  Ministry  of  Defence,  summarising our planned
          activities in 1981.

            Plans for the message systems work  in  1981  have  not
          been  finalised,  as  some  areas depend on decisions and
          choices which have not yet been made.  However,  a  rough
          scheme is as follows:

      (1)    Complete  installation  of  MMDF  in   local   systems
             (January).    Supportive   tasks   will   be  required
             throughout  the   year,   eg   bugfixing   as   found,
             transferring  and  reconfiguring  MMDF for new systems
             (eg the 11/44) as they become available.

      (2)    Issue  specification  of  proposed  NIFTP-based   mail
             channel (January)

      (3)    Either

             implement NIFTP-based  mail  channel  over  TCP  under
             MMDF;  if  possible, after upgrading UNIX NIFTP to the
             1980 specification.  Optionally (but  preferably)  the
             UNIX NIFTP should also use Yellow Book TCP commands.


             implement or obtain MTP mail channel  over  TCP  under
             MMDF.  If  one  is  obtained from an outside source it
             must be modified to access TCP through the  UIPP,  and
             very  probably  modified so that it can be driven as a
             channel through MMDF.  (1st - 3rd quarter)

      (4)    Depending  on  the  choice  made  above,   appropriate
             supportive  action  must be taken. (2nd to 4th quarter
             and beyond)

              (1)    NIFTP-based channel

Bennett                                                        [Page 25]

INDRA Note 1025                                         NIFTP-Based Mail

                      (1)    This should be  released  to  an  MMDF
                             site  in  the  US  (either  SRI or the
                             University of  Delaware)  which  could
                             act as a relay.

                      (2)    Help and  assistance  as  required  to
                             interface NIFTP directly to TCP or NCP
                             in the remote system.

                      (3)    TCP/X25 virtual call gateway to  allow
                             access  through  IPSS  and  PSS.  This
                             should be in existance in any case.

              (2)    MTP channel

                      (1)    TCP/X25  virtual  call   gateway,   as

                      (2)    Possibly    TCP/NCP    virtual    call
                             gateways. This depends on the progress
                             of MTP/ARPA  mail  relays  at  TCP/NCP
                             boundaries  as  required  by  the ARPA
                             Mail Transition Plan.

      (5)    Replace MSG message processing system by MH, to  allow
             remote  access  to UCL mail handling. (3rd/4th quarter
             and beyond).

             While the above lists the primary  path  to  providing
             mail  services,  there  are  a number of subsidiary or
             optional pathways which will also  be  undertaken,  if
             necessary or desirable. These include the following:

      (6)    Continue  efforts  to  provide  ARPANET  mail   access
             through a terminal channel. (January/February).

      (7)    Undertake   necessary    activity    to    incorporate
             TOPS20/TENEX  systems  into  either  the  NIFTP or MTP
             based scheme above. The latter case should  presumably
             involve  very  little  UCL  activity.  The former case
             requires the following from us (1st to 4th quarter and

Bennett                                                        [Page 26]

INDRA Note 1025                                         NIFTP-Based Mail

              (1)    Optionally (but preferably) the  upgrading  of
                     the TOPS20 NIFTP to the 1980 specification.

              (2)    Optionally (but preferably) the interfacing of
                     the NIFTP to a Yellow Book TCP Service.

              (3)    The design and development  of  a  mail  relay
                     system  analogous  to MMDF for TOPS20. Even if
                     it is decided that UCL will go the NIFTP path,
                     such  a  relay  may  well be developed by a US
                     ARPA contractor for MTP support. In this case,
                     our  task is to interface the NIFTP channel on
                     TOPS20 to this relay.

      (8)    There may arise interest  in  providing  mail  servers
             within  the  UK  community,  eg on SRCNet or PSS. Such
             services are more likely to be NIFTP-based  than  MTP-
             based  (though  in  the  longer term Teletex is a more
             favoured candidate than  either).  In  this  case  the
             following  UCL  activities  would be required (2nd/3rd
             quarter to 4th quarter and beyond):

              (1)    NIFTP-based mail channel over Yellow Book over

              (2)    The use of the UCL MMDF server  as  an  actual
                     mail  relay, if Catenet sites are using an MTP

              (3)    A TCP/X25 virtual call convertor if  they  are

      (9)    Additionally, UCL will  continue  to  take  an  active
             interest in message standardisation activity, in areas
             such as Teletex, IFIP WG6.5, etc.

Bennett                                                        [Page 27]

INDRA Note 1025                                         NIFTP-Based Mail

                           Table of Contents

  1. Introduction..................................................1

  2. Requirements..................................................1

  3. Basic Elements................................................2

     3.1 Mail Format...............................................2
     3.2 Mail Addresses............................................3
     3.3 Mail Transfer.............................................4

  4. Point to Point Mail Transfer..................................6

     4.1 Mail Structure............................................6
        4.1.1 Proposal.............................................6
        4.1.2 Discussion...........................................7
  Address Lists...................................7
  Possible Extensions.............................7
  Alternative Structures..........................8
     4.2 Mail Server Identification................................9
        4.2.1 Proposal.............................................9
        4.2.2 Discussion...........................................9
     4.3 Mail Server Communication.................................9
        4.3.1 Proposal.............................................9
        4.3.2 Discussion...........................................10
     4.4 Mail Transfer.............................................11
        4.4.1 Proposal.............................................11
        4.4.2 Discussion...........................................11
     4.5 Reliability...............................................12

  5. Mail Relays...................................................12

     5.1 Address Processing........................................13
     5.2 Return Paths..............................................14
     5.3 Economy...................................................15
     5.4 Reliability...............................................16

  6. The ARPA Mail Transition Plan: A Case Study...................16

     6.1 Current Proposals.........................................16

Bennett                                                        [Page 28]

INDRA Note 1025                                         NIFTP-Based Mail

     6.2 NIFTP and the Transition Plan.............................17
     6.3 A Proposal................................................17

  7. NIFTP-Based Mail in the UK....................................20

  8. References....................................................20

Bennett                                                        [Page 29]