Summary

  • RFC 784 described an ISI TOPS20 mail dispatcher that could choose a route for each recipient using a host-capability table: MTP over TCP, MTP over NCP, older FTP over NCP, or a special route.
  • RFC 785 defined a two-file interface: a control file held the sender, recipient paths and a pointer to the message; the message file held the text. The dispatcher could change recipient work state as channels succeeded or stalled while keeping one copy of the text.

An email sent to four people should require one letter and four addresses. Early mail systems could turn it into four copies of the letter, each carrying its own delivery job. Suzanne Sluizer and Jon Postel described a tidier arrangement in July 1981. Their RFC 784 on an ISI TOPS20 MTP implementation separated the letter from the instructions for getting it to its readers. One file held the mail; another held a list of people still waiting for it. The paper trail was literal.

The environment made that separation useful. Their planned Mail Transfer Protocol implementation for TOPS20, written in BLISS-10, would send and receive over both TCP and the older NCP transport and connect to other mail mechanisms. A background dispatcher gathered mail files produced by composition programs or network receivers and chose outgoing channels. A user-side dispatcher could attempt an immediate send when a suitable channel was available. The host-capability table recorded whether a destination could take MTP over TCP, MTP over NCP or the older FTP-over-NCP method.

A special table covered other cases, including mail to hosts in England through a system made by UCL. The same message could therefore need several roads.

The key was to let each road have its own progress without multiplying the message itself. The control file carried delivery information and a pointer to the second file, which contained the mail data, including its RFC 733 header. Once the dispatcher had served one recipient, it could mark or remove that person from the control file. If a different channel was unavailable, that recipient stayed on the pending list. The text file remained the same material for every trip, although it would eventually be renamed or deleted as the local process finished.

The control sheet changed because work changed; the letter did not need a fresh typescript every time a road closed.

RFC 785, the companion file-definition document, put names and lines on the idea. The control file began with FILE: pointing to the full message-file name, followed by FROM: and a TO: line for each destination path. The message file contained the header and body. The authors contrasted this pair with older creation systems that made N text copies for N addresses. Their interface needed two files however long the recipient list grew. In the example, visible To, Cc and Bcc names in the message led to separate destination paths on the dispatch sheet. The envelope had a different job from the words inside it.

Another companion, RFC 786, showed how a neighboring mail system, NIMAIL, could hand files to MTP and receive files back. It included examples of turning a percent-style address into an MTP route and the reverse. That small translation is a reminder that “mail” was already crossing boundaries between systems that wrote addresses differently. The dispatcher needed to know both which path a host could accept and how a neighboring system expected the address to look.

The authors wrote, “We are creating an implementation.” They listed pieces under construction, parts they hoped other mail programs would adapt, and tables still to be built. The RFC 784 pages document a concrete implementation plan with a file interface detailed in RFC 785; they do not provide a ledger of completed deliveries. That distinction belongs in the story because the proposal's practical insight is already clear. When four addressees live on different network paths, the sender's prose can stay put while the dispatch work takes four different turns.

It is a surprisingly recognizable mailroom: one letter on the desk, a changing card beside it, and a clerk who knows which door each recipient's building uses. In 1981 the doors had names like TCP, NCP and FTP over NCP. The design gave failure a place to wait. A stalled route kept its recipient on the card while the others could proceed. One message, several journeys, and no need to keep rewriting the letter.