Summary

  • RFC 733 standardized what an ARPANET text message looked like between hosts; it did not standardize a complete mail service or its user interface.
  • That common grammar arrived while delivery still relied on FTP commands, after earlier proposals and local parsers had produced competing expectations.

Analysis

The quick fix began inside FTP

In 1973, network mail already moved through two File Transfer Protocol commands: MAIL and MLFL. That arrangement could place a message in a recipient’s local mail system, but it did not make the message’s header fields consistent. A system might send an author, title or date in one form while another host could not reliably recognize it. The whole message, header included, was data to FTP.

RFC 524 proposed a richer mail protocol inside FTP’s command space. Its author also acknowledged why that design leaned on FTP: FTP was widely implemented, while the proposed unified user-level protocol was not. RFC 561 chose a faster interim route. Rather than waiting for new delivery commands, four authors proposed a text convention for messages already being sent with MAIL or MLFL. It gave From, Date and Subject recognizable forms, then left room for other keyword fields. Its authors explicitly described the approach as quicker to implement than changing the mail protocol.

That was a narrow intervention. RFC 561 did not replace the transport. It tried to make the data carried through that transport more intelligible to both people and software. Its flexibility also left a gap: “miscellaneous” fields could be added, but recipients and other fields still lacked a shared syntax.

A title could outrun a protocol

RFC 680, published in 1975 as “Message Transmission Protocol,” extended the message fields. Its pages define headers and their intended meanings; they do not define the process that transfers a message between hosts. The title later caused confusion about its status and scope. RFC 724, a proposed revision, says RFC 680 received limited distribution and was not formally adopted as an official ARPANET standard. It records that some implementers nevertheless treated it as one.

RFC 724 also describes a more consequential source of authority: deployed mail software. Its authors reported that TENEX systems originated more network messages than other host types, and that their To and Cc syntax became a de facto convention. TENEX readers began expecting that form. Multics systems experimented with different forms and, according to the report, users then complained that their messages could not be parsed by TENEX mail systems. This is a contemporary committee’s account, not a measured census of every host. But it shows why an official document title alone could not settle the format: the messages and parsers already in use shaped expectations.

RFC 733 standardized the seam

RFC 733, published in November 1977, superseded RFCs 561, 680 and the proposed RFC 724. It organized the syntax of ARPANET text messages, including recipient forms and references to stored address lists. Its preface says the work drew on a year of discussion through the mail environment itself, with more than twenty participants. That is evidence of a working process, not proof that every system adopted the result.

The document’s boundary is unusually explicit. It defines the content format passed between hosts. It does not dictate what features a local mail system must support or what its composing and reading programs should look like. The syntax could carry structured fields, but a host could decide which fields to process automatically. The standard’s authors expected the shared format to cover immediate needs and give developers room to produce a separate mail transmission protocol “properly.”

The compromise was practical: make the message boundary common first, while keeping local service design open. A sender could compose mail in one system and a recipient could read it in another without requiring the same interface. Yet this did not make all implementations compatible by decree. Parsers still had to be written, and adoption still depended on the hosts that ran them.

The later standards kept the distinction visible

In 1982, RFC 821 specified the Simple Mail Transfer Protocol as a host-to-host transfer mechanism over a reliable ordered stream. RFC 822 separately specified the format of ARPA Internet text messages and explicitly obsoleted RFC 733. Read together, they make the two questions easier to see: how a message is moved, and how its contents are structured.

The record therefore supports a bounded history, not a claim that RFC 733 invented email or immediately unified every mail system. RFC 724 reports a widely used but informal header convention; RFC 733 supplies a formal syntax and a stated scope; RFCs 821 and 822 later document separate transfer and content standards. None of these documents, by itself, measures how many hosts implemented each rule or when a particular system changed.

Sources and evidence limits

The primary record is RFC 524, RFC 561, RFC 680, RFC 724, RFC 733, RFC 821 and RFC 822. RFC 724’s account of TENEX and Multics is attributed to that contemporary document, not generalized into a network-wide adoption statistic. The later ideas in Heng Lu’s Note 64—minimum initial specification, local future decisions and voluntary adoption—are used only as an analytical lens. They are not evidence of what the 1970s authors intended.

Sources