Mail transition plan
RFC 771

Document Type RFC - Unknown (September 1980; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text html pdf htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 771 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                    V. Cerf  (ARPA)
Request for Comments: 771                                J. Postel (ISI)
                                                          September 1980

                          MAIL TRANSITION PLAN


   This is a draft memo and comments are requested.


   The principal aim of the mail service transition plan is to provide
   orderly support for computer mail service during the period of
   transition from the old ARPANET protocols to the new Internet

   This plan covers only the transition from the current text computer
   mail in the ARPANET environment to text computer mail in an Internet
   environment.  This plan does not address a second transition from
   text only mail to multimedia mail [10,11].

   The goal is to provide equivalent or better service in the new
   Internet environment as was available in the ARPANET environment.
   During the interim period, when both protocol environments are in
   use, the goal is to minimize the impact on users and existing
   software, yet to permit the maximum mail exchange connectivity.

   It is assumed that the user is familiar with both the ARPANET and
   Internet protocol environments [1-8].  The Internet protocols are
   designed to be used in a diverse collection of networks including the
   ARPANET, Packet Radio nets, Satellite nets, and local nets (e.g.,
   Ethernets, Ring nets); while the ARPANET protocol are, of course,
   limited to the ARPANET.

   The Internet protocol environment specifies TCP as the host-to-host
   transport protocol.  The ARPANET protocol environment specifies NCP
   as the host-to-host transport protocol.  Both TCP and NCP provide
   connection type process-to-process communication.  The problem in the
   transition is to bridge these two different interprocess
   communication systems.

   The objective of this plan is to specify the means by which the
   ARPANET computer mail services may be extended into the Internet
   system without disruptive changes for the users during the


September 1980                                                   RFC 771
Mail Transition Plan                                                    


   The model of the computer mail system taken here separates the mail
   composition and reading functions from the mail transport functions.
   In the following, the discussion will be hoplessly TOPS20-oriented.
   We appologize to users of other systems, but  we feel it is better to
   discuss examples we know than to attempt to be abstract.

   In the ARPANET mail service, composition and reading is done with
   user programs such as HERMES, MSG, MM, etc., while mail transmission
   is done by system programs such as MAILER (sending) and FTPSRV

   One element of the ARPANET mail service is the assumption that every
   source of mail can have a direct interprocess communication
   connection (via the NCPs) to every destination for mail.  (There are
   some cases where special handling and forwarding of mail violates
   this assumption.)

   Mailbox names are of the form "MAILBOX@HOST", and it is assumed that
   MAILBOX is a destination mailbox on that host.

   The messages are actually transmitted according to the provisions of
   the File Transfer Protocol.  Mail may be transimitted via either the
   control connection (MAIL command), or via a data connection (MLFL
   command).  In either case, the argument specifies only the mailbox
   since the destination host is assumed to be the host receiving the

      For example:  messages sent from Postel at USC-ISIF to Cerf at
      USC-ISIA would arrive at ISIA with the argument "Cerf" but no
      indication of the host.


   Mailboxes are of the form "mailbox@host" where mailbox is usually a
   name like "Postel" and host is a host identifier like "USC-ISIF".  In
   some cases it will be useful to allow the host to be a compound name
   such as:



RFC 771                                                   September 1980
                                                    Mail Transition Plan

   or even the name of an organization:


   The only restriction is that "@" not appear in either the "mailbox"
   or the "host" strings in the destination address.

   To actually send the message the mailer program must convert the host
   string into the physical address to which to transmit the message.
Show full document text