From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc771.txt | 531 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 531 insertions(+) create mode 100644 doc/rfc/rfc771.txt (limited to 'doc/rfc/rfc771.txt') 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 + -- cgit v1.2.3