RFC 771

RFC 771: MAIL TRANSITION PLAN 🦋

Authors: V. Cerf (ARPA) and J. Postel (ISI). Published by the Network Working Group in September 1980 as Request for Comments 771. The title block doesn't list a category, and it doesn't say that this document obsoletes or updates anything.

PREFACE ✨

This is a draft memo, and the authors are asking for comments. 💌

INTRODUCTION 🌸

okay so the main goal of this mail service transition plan is to give computer mail orderly support while we move from the old ARPANET protocols to the new Internet protocols. 📬

This plan only covers moving from the current text-only computer mail in the ARPANET environment to text-only computer mail in an Internet environment. It does not cover a second transition, from text-only mail to multimedia mail [10,11]. one thing at a time, bestie 💅

The goal is to give equivalent or better service in the new Internet environment than what ARPANET already had. During the interim period, when both protocol environments are in use, the goal is to minimize the impact on users and existing software, while still allowing the maximum mail exchange connectivity. It's giving "everyone can still talk to everyone" 🫶

It's assumed that the user is familiar with both the ARPANET and Internet protocol environments [1-8]. The Internet protocols are designed to work across a diverse collection of networks, including the ARPANET, Packet Radio nets, Satellite nets, and local nets (e.g., Ethernets, Ring nets). The ARPANET protocols 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. So the problem in the transition is bridging these two different interprocess communication systems. it's a whole vibe 🧚

The objective of this plan is to specify how ARPANET computer mail services can be extended into the Internet system without disruptive changes for users during the transition. ✨

---

MODEL OF MAIL SERVICE 💖

The model of the computer mail system used here separates the mail composition and reading functions from the mail transport functions. Fair warning, the discussion will be hopelessly TOPS20-oriented 🙈 Sorry to users of other systems, but we feel it's better to talk about examples we actually know than to try being 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: 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 breaks this assumption, so bear that in mind 👀)

Mailbox names look like "MAILBOX@HOST", and it's 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 can be sent either over the control connection (MAIL command) or over a data connection (MLFL command). Either way, the argument only specifies the mailbox, since the destination host is assumed to be the host receiving the transmission. Iconic behaviour, honestly 💅

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 look like "mailbox@host", where mailbox is usually a name like "Postel" and host is a host identifier like "USC-ISIF". Sometimes it's useful to let the host be a compound name, such as:

USC-ISIA
ARPANET-ISIA
SATNET-NDRE
PPSN-RSRE
HOST1.SRINET
LSCNET/MAILROOM

or even the name of an organization:

BBN
ARPA
MIT
SRI

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

To actually send the message, the mailer program has to convert the host string into the physical address it transmits to. This name-to-address conversion is usually done by looking the name up in a table, then finding the physical address in another field of that table entry. That means all the compound and organization names (and any other alternate names or synonyms) must also be in the host table. Main character energy for the host table 👑

HIDDEN HOSTS 🙈

Sometimes the mailbox part of the destination address is a compound name that marks a set of mailboxes which aren't really on the host at all. They're actually on another host that's connected to this one in a non-standard way. Plot twist 🌸

It matters a lot to computer mail users that replies to messages can be composed easily, with automatic help from the mail processing programs. To keep that working, it's important that a host understands the mailbox part of every address in every message it sends, whenever the host part of that address is itself. 🫶

So, for every message, in every header field, in every address "m@h", host h must understand all values of m. That means 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. ✅

---

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 that parses message headers to compose replies and the like. Specifically, non-ARPANET mailbox designators must be accommodated without any 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 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 use these relay servers, changes will be made to the mailer programs. The mailer program is responsible for determining whether the destination address of the message is directly reachable via the interprocess communication system it has available (TCP or NCP or both), or whether 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 that decision is an expanded host name table. This table translates host names to physical addresses. The physical addresses in this table will be the 32-bit Internet addresses. (This makes sense even for 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 indicate whether the host in this entry is (1) an NCP host with "old tables", (2) an 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 the ones without these flag bits, while "new tables" do have these flags. 🎀

A separate table may be useful for listing the addresses of hosts with relay servers. 🧚

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 the destination mailbox is actually reachable. So it may later discover that the destination mailbox doesn't exist (or that some other condition prevents delivery). To be able to report that 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 doesn't contain the address of the originating user, no error response is attempted. 😬

The error report is itself a message, and it does not carry an originator address in the command argument, to avoid the possibility of an endless chain of error reports. (However, an originator address does appear in the header.) 🔁

Since the originating host acts as if the mail was successfully delivered once the relay server accepts it, the originating host deletes any backup 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 doesn't understand how to deliver locally, or both relay and reply (if the originating address is present) for 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 transfer protocol to be used by the relay server and all TCP hosts is documented in reference [9].

CONNECTIVITY 🦋

okay so picture a 3x3 grid 💅 with three kinds of hosts on each side: (1) old-table NCP hosts, (2) new-table NCP hosts, and (3) TCP hosts. There are also two transfer mechanisms: file transfer and mail transfer. The diagonal is the easy part, because every host type can trade mail with its own type. The other cases are where it gets spicy 🌶️

An old-table NCP host has a table with 32-bit physical addresses but no flag bits. It has NCP and file transfer, but no separate mail transfer protocol 🙈

A new-table NCP host has a table with 32-bit physical addresses and the flag bits. It has NCP and file transfer, and it also has the new separate mail transfer 🌸

A TCP host has 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 it doesn't use it for mail ✨

1. Old-table NCP to Old-table NCP

This one is direct and uses the old mechanisms, NCP and file transfer. Easy mode 🍓

2. New-table NCP to Old-table NCP

Also direct, using the old mechanisms, NCP and file transfer. No drama 💜

3. TCP to Old-table NCP

This one must use a relay server 🧚 The first hop, from the TCP host to the relay server, goes over TCP and the mail transfer protocol. The second hop, from the relay server to the old-table NCP, goes over NCP and the file transfer protocol.

4. Old-table NCP to New-table NCP

Direct again, with the old mechanisms, NCP and file transfer. Honestly so smooth 🫶

5. New-table NCP to New-table NCP

This one uses NCP and the mail transfer protocol. In other words, it runs on the old interprocess communication system but with the new mail transmission scheme 🔥

6. TCP to New-table NCP

This one must use a relay server too 💅 The first hop, from the TCP host to the relay server, is via TCP and the mail transfer protocol. The second hop, from the relay server to the new-table NCP, is via NCP and the mail transfer protocol.

7. Old-table NCP to TCP

Okay, this is the main character of the nine cases 😭 It must use a special relay server. The first hop, from the old-table NCP to the relay server, is via NCP and the file transfer protocol. The second hop, from the relay server to the TCP host, is via TCP and the mail transfer protocol. The relay has to be special because messages coming from the old-table NCP host won't have the destination host information in the command argument. So the relay must keep a list of registered TCP user mailboxes and their associated TCP host identifiers. That registry could get really big and keep changing, and it'll keep growing as more TCP hosts show up, so it'll be necessary to limit the mailboxes on the registry 🌈

8. New-table NCP to TCP

This one must use a relay server 🎀 The first hop, from the new-table NCP to the relay server, is via NCP and the mail transfer protocol. The second hop, from the relay server to the TCP host, is via TCP and the mail transfer protocol.

9. TCP to TCP

Direct, using the new mechanisms, TCP and the mail transfer protocol. Chef's kiss 👑

In general, whenever possible the new procedures are to be used. Use the new stuff when you can, bestie 💖

---

MULTIPLE RECIPIENTS 🍓

A big chunk of the mail that gets sent is addressed to multiple recipients 📬 Sending it that way would cut down on both transmission and processing costs, if it's transferred using the multiple recipient technique that's available in both the old file transfer protocol [12] and the new mail transfer protocol [9].

The relay servers will try to use multiple recipient commands whenever they apply when transmitting messages, and they will accept those commands when receiving messages 🫶

---

COMPOSITION AND READING PROGRAMS 💜

The impact on mail composition and reading programs is minimal, so don't panic 🙈 If these programs use a table to recognize, complete, or verify host identifiers, then they must be modified to use the new table.

To help the user reply to messages, it's going to matter that every address in the header fields (TO:, CC:, etc.) is complete, with both the mailbox and host parts 💅 In some cases this hasn't been necessary before, because addresses without host parts could be assumed to be local to the originating host, and the receiving host recorded the sending host. When messages were sent directly, the originating host was the sending host. But when messages get relayed, the originating host won't be the host sending the mail to the destination host, so the full address really matters ✨

---

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.