Summary
- Intermail crossed mail-system boundaries without changing users’ native programs, but senders still had to place destination instructions at the beginning of a message body.
- A 1990 operational report shows that the relay was not one uniform gateway: MCI Mail still used TOPS-20 Intermail while the newer UNIX Commercial Mail Relay did not yet support it.
The first boundary was at the application layer
The Internet and commercial email services were separate systems with separate address conventions. In its 1990 report, USC/Information Sciences Institute (ISI) said that Internet mail, Sprint Telemail, MCI Mail and Dialcom had been designed to operate autonomously, with no convenient way for a user on one to reach a user on another. ISI began an experiment in 1981 to bridge that gap. Its first Intermail version carried VLSI chip specifications for the MOSIS project between ARPANET and Telemail. This was a working service for a defined exchange, not a general-purpose promise that every network or mailbox could be reached.
The early solution moved complexity to the message. The first format, called Source Route Forwarding, was intended for cases in which a message could pass through multiple systems. In 1983, Annette DeSchon expanded Intermail into a general-purpose forwarder linking Internet mail with Telemail, MCI Mail and Dialcom. As users gained experience, ISI found that the full source-route machinery was more general than needed and introduced “Simple Forwarding.” Its instruction appeared at the start of the message text. A sender could include destination addresses and familiar fields such as To, Cc and Subject, then end the forwarding header with a blank line before the message body.
The design was nearly transparent only in a limited sense. People could keep their usual mail programs; no modification to each local mail client was required. But the sender still had to know that a relay existed, choose a gateway, and supply the other system’s address in the format its service understood. RFC 1168 gives different examples for Telemail and Dialcom. Some Telemail addresses included a user, organization, host and country; Dialcom used a host identifier and user identifier. A message that looked ordinary to one mail service therefore needed an explicit instruction for the intermediary to interpret.
The relay still needed people and records
The labor did not end when the syntax was written down. Intermail generated error messages only partly automatically: a human postmaster approved or corrected them. The newer UNIX Commercial Mail Relay (CMR) used a spool and a daemon to parse incoming messages and find the embedded Simple Forwarding Header. It also had a small accounting mechanism: scripts counted markers in logs and totaled the number of messages sent and received for each commercial service at month end. The report documents these controls, but it does not give a delivery-success rate, complete staffing cost or full volume series.
Most importantly, “the gateway” did not describe one implementation. In July 1990, the CMR supported Telemail and Dialcom. Its MCI connection was still being developed; the report says MCI Mail continued to be served by the TOPS-20 Intermail system and was not yet implemented in the CMR. The distinction matters because a newer relay could not simply be assumed to have replaced the older service. ISI was maintaining two generations of forwarding, with different software and service coverage.
A mail gateway did not provide general IP access
That operating boundary also had a policy side. RFC 1168 says the ISI relays were supported for DARPA work or other approved government business, and that the relay could not be used merely to bridge two commercial systems. At least one end of a message had to meet the applicable Federal Research Internet Coordinating Committee policy. This restriction did not turn email into general Internet access; it constrained which messages could use particular federally supported facilities. Later accounts of the separate CNRI–MCI Mail Internet experiment describe an approval request in 1988 and a completed connection in 1989.
They do not reproduce the original decision instrument, and that experiment should not be conflated with Intermail’s earlier relay history.
Intermail’s importance lies in the work hidden by the word “interoperability.” Users could avoid replacing local software, but operators had to translate address conventions, preserve the route instruction, keep a relay host running, inspect failures and account for traffic. Each additional mail system widened the set of people who could exchange messages while adding another format and service state to maintain. The evidence supports a bounded conclusion: commercial mail and Internet mail became reachable through staffed gateways before their systems shared a common user-facing address model.
It does not show that the services merged, that every user could exchange mail, or that email access conferred ordinary packet-level Internet access.
Sources
- RFC 1168, “Intermail and Commercial Mail Relay Services” (July 1990) — the contemporary service history and implementation snapshot.
- RFC 821, “Simple Mail Transfer Protocol” (August 1982) and RFC 822, “Standard for the Format of ARPA Internet Text Messages” (August 1982) — Internet mail context.
- CNRI, “What Is the Internet?” — retrospective account of the MCI Mail experiment.
- IEEE Spectrum, “Meet Mr. Internet: Vint Cerf” — Cerf’s later recollection of the MCI interconnection.
- RFC 2235, “Hobbes’ Internet Timeline” (November 1997) — later chronology of commercial mail relays.
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
