GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:ien:ien169
                                            INDRA
                                           Working
                                            Paper
   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
        discussed.
                   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
   standard.
     Comments are solicited and welcomed.
   2. Requirements
     The basic requirements for an immediate mail service are  as
   follows:
    (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
           networks.
    (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
   program.
     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-
           independent.
    (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
   criteria.
   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
   follows:
   <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
   server.
   The <mail text> shall conform with RFC733 formats.
   4.1.2 Discussion
   4.1.2.1 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).
   4.1.2.2 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.
   4.1.2.3 Alternative Structures
     Two alternative structures were considered,  both  involving
   the  explicit  separation  of  the  address list from the mail
   text.
     The first was to require the donor to specify the file name,
   which  would  be  the  address  list.  This  has  a  number of
   disadvantages:
    (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
   appropriate.
     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
   MAIL.

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
           path.
    (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
   file.
   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
   purposes.
     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
   attributes.

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
           relay.
    (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
           known.
    (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:
                  Linington%Cambridge%PSS@UCL.
           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
   messages.
     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
           defined.
    (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
   follows:
    (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
           mailbox.
     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
   available.
     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
        versions.
   [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,
        California.
   [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
        specification.
               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
        specification:
        A.  ALPHABETICAL LISTING OF SYNTAX RULES
        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
                       specification>
        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
                       texts>
        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
                       linear-white-space>
        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
                       extensions>
        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.
           or
           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
                           above.
                    (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
           beyond):

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
                   X25.
            (2)    The use of the UCL MMDF server  as  an  actual
                   mail  relay, if Catenet sites are using an MTP
                   channel.
            (3)    A TCP/X25 virtual call convertor if  they  are
                   not.
    (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
         4.1.2.1 Address Lists...................................7
         4.1.2.2 Possible Extensions.............................7
         4.1.2.3 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]

/data/webs/external/dokuwiki/data/pages/rfc/ien/ien169.txt · Last modified: 2001/06/25 20:34 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki