Mail transition plan
RFC - Unknown
(September 1980; No errata)
||RFC Editor Note
RFC 771 (Unknown)
||Send notices to
Network Working Group V. Cerf (ARPA)
Request for Comments: 771 J. Postel (ISI)
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
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
MODEL OF MAIL SERVICE
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
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.
COMPOUND AND ALTERNATE NAMES
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
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