summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc771.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc771.txt')
-rw-r--r--doc/rfc/rfc771.txt531
1 files changed, 531 insertions, 0 deletions
diff --git a/doc/rfc/rfc771.txt b/doc/rfc/rfc771.txt
new file mode 100644
index 0000000..9cf77d4
--- /dev/null
+++ b/doc/rfc/rfc771.txt
@@ -0,0 +1,531 @@
+
+
+Network Working Group V. Cerf (ARPA)
+Request for Comments: 771 J. Postel (ISI)
+ September 1980
+
+ MAIL TRANSITION PLAN
+
+
+PREFACE
+
+ This is a draft memo and comments are requested.
+
+INTRODUCTION
+
+ 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
+ protocols.
+
+ 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
+ transition.
+
+
+
+
+
+
+
+
+ 1
+
+
+
+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
+ (receiving).
+
+ 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
+ transmission.
+
+ 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
+ such as:
+
+ USC-ISIA
+ ARPANET-ISIA
+ SATNET-NDRE
+ PPSN-RSRE
+ HOST1.SRINET
+ LSCNET/MAILROOM
+
+
+
+
+ 2
+
+
+
+RFC 771 September 1980
+ Mail Transition Plan
+
+
+
+ or even the name of an organization:
+
+ BBN
+ ARPA
+ MIT
+ SRI
+
+ 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.
+ This name-to-address conversion is typically done by looking the name
+ up in a table and finding the physical address in another field of
+ that table entry. This means that all the compound and organization
+ names (and any other alternate names or synonyms) must also be in the
+ host table.
+
+HIDDEN HOSTS
+
+ Sometimes the mailbox part of the destination address is a compound
+ name and is used to mark a set of mailboxes which are not really on
+ the host at all, but rather on another host which is connected to
+ this host in a non-standard way.
+
+ It is important to users of computer mail that replies to messages
+ may be easily composed with automatic assistance from the mail
+ processing programs. To preserve this capability it is important
+ that a host understand the mailbox part of every address in every
+ message it sends if the host part of the address is itself.
+
+ That is, for every message, in every header field, in every address
+ "m@h", host h must understand all values of m. Thus when a host
+ prepares a message it should check all the addresses that appear in
+ the header and for any address whose host part is this host the
+ mailbox part should be verified.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 3
+
+
+
+September 1980 RFC 771
+Mail Transition Plan
+
+
+
+THE TRANSITION PLAN
+
+ The basic ground rules for the transition are:
+
+ 1. ARPANET mailbox names must continue to work correctly.
+
+ 2. No changes should be required to mail editor software which
+ parses message headers to compose replies and the like.
+ Specifically, non-ARPANET mailbox designators must be
+ accommodated without change to the parsing and checking mechanisms
+ of mail processing programs.
+
+ 3. Automatic forwarding of messages between NCP and TCP
+ environments without user (or operator) intervention.
+
+ For the communication of messages between NCP and TCP hosts a mail
+ relay service will be provided on a few hosts that implement both TCP
+ and NCP. These will be "well known" in the same sense that sockets
+ or ports for contacting Telnet or FTP servers are well known.
+
+ To make use of these relay servers changes will be made to the mailer
+ programs. The mailer program will be responsible for determining if
+ the destination address of the message is directly reachable via the
+ interprocess communication system it has available (TCP or NCP or
+ both), or if the mail must be relayed. If the mail must be relayed,
+ the mailer must choose a relay server and transmit the message to it.
+
+ The basis for the decision the mailer must make is an expanded host
+ name table. There will be a table which translates host names to
+ physical addresses. The physical addresses in this table will be the
+ 32-bit Internet addresses. (This makes sense for even NCP-only hosts,
+ since after 1 January 1981 even they must use 96-bit leader format
+ which requires 24-bit ARPANET physical addresses). Each entry in
+ this table will also have some flag bits.
+
+ The flag bits will include information to indicate if the host in
+ this entry is (1) a NCP host with "old tables", (2) a NCP host with
+ "new tables", (3) a TCP host, or (4) some other kind of host. All
+ TCP hosts are assumed to have "new tables". "Old tables" are those
+ without these flag bits, while "new tables" do have these flags.
+
+ A separate table may be useful to list the addresses of the hosts
+ with relay servers.
+
+
+
+
+
+
+
+ 4
+
+
+
+RFC 771 September 1980
+ Mail Transition Plan
+
+
+
+ When a message is sent to a relay server, the control information (in
+ the argument of the mail transfer command) must be augmented to
+ include the destination host identifier.
+
+ The relay server may accept messages to be relayed without knowing
+ that destination mailbox is actually reachable. This means that it
+ may later discover that the destination mailbox does not exist (or
+ some other condition prevents mail delivery). To be able to report
+ the error to the originating user, the mailbox (mailbox@host) of the
+ originating user must be included in the argument of the mail
+ transfer command. If the argument does not contain the address of
+ the originating user no error response is attempted. The error
+ report, which is itself a message, does not carry an originator
+ address in the command argument to avoid the possibility of a endless
+ chain of error reports (however, an originator address does appear
+ the header).
+
+ Since the originating host will act as if the mail was successfully
+ delivered when it is accepted by the relay server, it deletes any
+ back up copies of the message it was keeping in case of errors. For
+ this reason, the relay server must include the complete message in
+ any error report it sends to the originator. The relay server should
+ parse the addresses in the argument before accepting a message. If
+ it does not understand how deliver locally, or both relay and reply
+ (if the originating address is present) to the message, it should not
+ accept it.
+
+ There are enough differences in the transmission procedure that the
+ relay server will use a distinct mail transfer protocol, separate
+ from the file transfer protocol.
+
+MAIL TRANSFER PROTOCOL
+
+ The mail trasfer protocol to be used by the relay server and all TCP
+ hosts is documented in reference [9].
+
+CONNECTIVITY
+
+ There are nine cases of mail exchange, the three by three matrix of
+ (1) old-table NCP hosts, (2) new-table NCP hosts, (3) TCP hosts.
+ There are also two transfer mechanisms: file transfer and mail
+ transfer. The diagonal is easy, each type of host can exchange mail
+ with other hosts of its type. The other cases are more subtle.
+
+
+
+
+
+
+
+ 5
+
+
+
+September 1980 RFC 771
+Mail Transition Plan
+
+
+
+ An old-table NCP host is assumed to have a table with 32-bit physical
+ addresses, but no flag bits. It has NCP and file transfer. It does
+ not have the separate mail transfer protocol.
+
+ An new-table NCP host is assumed to have a table with 32-bit physical
+ addresses, and the flag bits. It has NCP and file transfer. It also
+ has the new separate mail transfer.
+
+ An TCP host is assumed to have a table with 32-bit physical
+ addresses, and the flag bits. It has the new separate mail transfer.
+ It probably has a file transfer, but does not use it for mail.
+
+ 1. Old-table NCP to Old-table NCP
+
+ This transfer is direct and uses the old mechanisms -- NCP and
+ file transfer.
+
+ 2. New-table NCP to Old-table NCP
+
+ This transfer is direct and uses the old mechanisms -- NCP and
+ file transfer.
+
+ 3. TCP to Old-table NCP
+
+ This transfer must use a relay server. The first transfer (from
+ the TCP host to the relay server) is via TCP and the mail transfer
+ protocol. The second transfer (from the relay server to the
+ old-table NCP) is via NCP and file transfer protocol.
+
+ 4. Old-table NCP to New-table NCP
+
+ This transfer is direct and uses the old mechanisms -- NCP and
+ file transfer.
+
+ 5. New-table NCP to New-table NCP
+
+ This transfer is done with the NCP and the mail transfer protocol,
+ that is, using the old interprocess communication system and the
+ new mail transmission scheme.
+
+ 6. TCP to New-table NCP
+
+ This transfer must use a relay server. The first transfer (from
+ the TCP host to the relay server) is via TCP and the mail transfer
+ protocol. The second transfer (from the relay server to the
+ new-table NCP) is via NCP and mail transfer protocol.
+
+
+
+
+ 6
+
+
+
+RFC 771 September 1980
+ Mail Transition Plan
+
+
+
+ 7. Old-table NCP to TCP
+
+ This transfer must use a special relay server. The first transfer
+ (from the old-table NCP to the relay server) is via NCP and the
+ file transfer protocol. The second transfer (from the relay
+ server to the TCP host) is via TCP and mail transfer protocol.
+ This relay server must be special because the messages coming from
+ the old-table NCP host will not have the destination host
+ information in the command argument. This relay server must have
+ a list of registered TCP user mailboxes and their associated TCP
+ host identifiers. Since such a registry could be potentially
+ large and frequently changing (and will grow as more TCP hosts
+ come into existence) it will be necessary to limit the mailboxes
+ on the registry.
+
+ 8. New-table NCP to TCP
+
+ This transfer must use a relay server. The first transfer (from
+ the new-table NCP to the relay server) is via NCP and the mail
+ transfer protocol. The second transfer (from the relay server to
+ the TCP host) is via TCP and mail transfer protocol.
+
+ 9. TCP to TCP
+
+ This transfer is direct and uses the new mechanisms -- TCP and the
+ mail transfer protocol.
+
+ In general, whenever possible the new procedures are to be used.
+
+MULTIPLE RECIPIENTS
+
+ A substantial portion of the mail sent is addressed to multiple
+ recipients. It would substantially cut the transmission and
+ processing costs if such multiple recipient mail were transfered
+ using the multiple recipient technique available for use in both the
+ old file transfer protocol [12] and new mail transfer protocol [9].
+
+ The relay servers will attempt to use a multiple recipient commands
+ whenever applicable on transmitting messages, and will accept such
+ commands when revceiving messages.
+
+
+
+
+
+
+
+
+
+
+ 7
+
+
+
+September 1980 RFC 771
+Mail Transition Plan
+
+
+
+COMPOSITION AND READING PROGRAMS
+
+ The impact on the mail composition and reading programs is minimal.
+ If these programs use a table to recognize, complete, or verify host
+ identifiers, then they must be modified to use the new table.
+
+ To assist the user in replying to messages it will be important that
+ all addresses in the header fields (TO:, CC:, etc.) be complete with
+ both the mailbox and host parts. In some cases this has not
+ previously been necessary since the addresses without host parts
+ could be assumed to be local to the originating host, and the sending
+ host was recorded by the receiving host. When the messages were sent
+ directly the originating host was the sending host, but when messages
+ are relayed the originating host will not be the host sending the
+ mail to the destination host.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 8
+
+
+
+RFC 771 September 1980
+ Mail Transition Plan
+
+
+
+REFERENCES
+
+ [1] Cerf, V., "The Catenet Model for Internetworking," IEN 48,
+ DARPA/IPTO, July 1978.
+
+ [2] Postel, J., "Internet Protocol," RFC 760, USC/Information
+ Sciences Institute, NTIS ADA079730, January 1980.
+
+ [3] Postel, J., "Transmission Control Protocol," RFC 761,
+ USC/Information Sciences Institute, NTIS ADA082609,
+ January 1980.
+
+ [4] Postel, J., "Telnet Protocol Specification," RFC 764,
+ USC/Information Sciences Institute, June 1980.
+
+ [4] Postel, J., "File Transfer Protocol," RFC 765,
+ USC/Information Sciences Institute, June 1980.
+
+ [5] Postel, J., "Assigned Numbers," USC/Information Sciences
+ Institute, RFC 762, January 1980.
+
+ [6] Postel, J., "Internet Protocol Handbook," USC/Information
+ Sciences Institute, RFC 766, July 1980.
+
+ [7] Feinler, E. and, J. Postel, "ARPANET Protocol Handbook,"
+ NIC 7104, Network Information Center, SRI International,
+ January 1978.
+
+ [8] Crocker, D., J. Vittal, K. Pogran, and, D. Henderson,
+ "Standards for the Format of ARPA Network Text Messages,"
+ RFC 733 7104, Network Information Center, SRI International,
+ November 1977.
+
+ [9] Sluizer, S. and, J. Postel, "Mail Transfer Protocol,"
+ USC/Information Sciences Institute, RFC rrr, September 1980.
+
+ [10] Postel, J., "Internet Message Protocol," USC/Information
+ Sciences Institute, RFC 759, August 1980.
+
+ [11] Postel, J., "A Structured Format for Transmission of
+ Multi-Media Documents," USC/Information Sciences Institute,
+ RFC 767, August 1980.
+
+ [12] Harrenstien, K., "FTP Extension: XRSQ/XRCP,"
+ SRI International, RFC 743, December 1977.
+
+
+
+
+
+ 9
+