Summary

  • D. L. Mills proposed Internet name domains in September 1981 because the combined ARPANET–DCNET tables already held more than 400 names and nicknames; every host could not keep every future host in one flat local book.
  • His harder mail problem appeared when one forwarder served several domains. Mills@HOST could identify different mailboxes under COMSAT and INTELPOST, while one machine address could not tell a reply which domain to use. Complete mailbox names and preserved route context carried the distinction.

Imagine a mailroom with one desk, two offices and a correspondent called Mills@HOST in each office. A letter addressed to that local name reaches the shared desk. Which Mills gets it? The question comes straight from D. L. Mills's September 1981 RFC 799, though the mailroom is a metaphor. Mills was tackling an Internet still able to fit many names into host tables, yet already uncomfortable doing so: the combined ARPANET–DCNET lists held more than four hundred names and nicknames. A hierarchy sounded easy on a diagram. Making mail and replies survive it was the real work.

Mills proposed name domains associated with institutions such as ARPA, UCL and COMSAT. These domains could overlap and need not cover every address. The memo examined a single level even though its standard mailbox spelling, <user>.<host>@<domain>, read like a three-part hierarchy from right to left. Inside COMSAT, Mills@COMSAT-DLM might be sufficient. Across the Internet, Mills.COMSAT-DLM@COMSAT carried the domain as well. Local nicknames could repeat in different domains. The suffix was therefore useful information, not decorative stationery.

Every domain in the proposal had one or more mail-forwarder processes. A forwarder knew all host names in its own domain and at least one forwarder in every other domain. Ordinary hosts needed the forwarders' names, with any other convenient local entries. Forwarders might be replicated for resilience, but Mills left the resulting routing complications for another discussion. One host could itself support forwarders for several domains and have multiple Internet addresses. The model allowed local naming choices; the forwarding process had to remember which choice was in force.

The presence of forwarders did not turn every message into a relay race. Mills expected most mail to travel directly between originating and recipient hosts. Intermediate relays mattered when the two hosts were not online at the same time, when the originator could not do all the name translation, when a direct path faced regulatory, economic or security constraints, or when the endpoints spoke different transport protocols such as TCP and NCP. A relay could store and send a message without knowing every domain's name table. A forwarder needed the richer knowledge.

That division kept the expensive cross-domain address book at selected desks.

The sharpest example has two recipient routes: MRCP to:<@COMSAT,Mills@HOST> and MRCP to:<@INTELPOST,Mills@HOST>. In Mills's example they can refer to different mailboxes, even if one computer runs forwarders for both domains. If the forwarder computer is called FORWARDER in both places, a route reduced to MRCP to:<@FORWARDER,Mills@HOST> has lost the instruction that made the destination unique. The computer's Internet address does not rescue it: one address can stand behind more than one domain role. A reply reconstructed from that address alone would inherit the same ambiguity.

Mills therefore wanted complete Internet mailbox spelling when relays could cross domain boundaries. His examination of RFC 780's recipient and sender routes exposed a related flaw: the receiver was supposed to infer a sender-route name from the address of the host that handed it the message. On a multi-domain forwarder, that address named the machine but left the domain unresolved. The sending host had to update the sender route as well as the recipient route, copying the first recipient-route entry it received into the sender route. The return path needed to remember which counter the letter had crossed.

Older mail systems complicated the tidy spelling. Mills advised against repeatedly editing RFC 733 message headers because that required invasive analysis. New systems could use standard mailbox names throughout. For existing ARPANET mail, he placed necessary rewriting at the first step into the Internet mail system: a local <anything>@<host> became <anything>.<host>@ARPA; a recognized <anything>@<domain> stayed as written. That boundary made later replies easier because subsequent forwarders no longer had to guess whether a short name was local or global.

RFC 799 was a proposal, ending with an invitation to discussion. Its memorable insight was operationally precise: a unique 32-bit machine address does not uniquely identify the role a multi-domain mail process is performing. Mills's scheme kept the missing context in names and routes, while leaving most mail free to go directly. Four hundred names were enough to make the flat book creak; one shared desk was enough to show why merely splitting the book would not fix replies.