Summary

  • The August 1982 revision defined SMTP as a reliable stream conversation that could relay mail between hosts without requiring both ends to share one transport service.
  • MAIL supplied a reverse path and RCPT one or more forward paths; RFC 822 separately specified the text-message format, so a successful SMTP exchange did not itself prove mailbox use or human receipt.

An email can cross a network boundary without the message itself knowing which network carried it. That was the design problem visible in the August 1982 Simple Mail Transfer Protocol specification published by Jonathan B. Postel. RFC 821 did not require a particular transmission subsystem. It required a reliable, ordered data stream, then described how SMTP processes could exchange commands and replies across the channel.

The specification made relaying part of the model. If the sending and destination hosts shared a transport service, the sender could contact the receiving SMTP process directly. If they did not, one or more intermediate SMTP servers could bridge the transport-service environments. Postel was careful about the unit of connection: a transport service might cover one network, several networks, or only part of one. “Network” and “transport environment” were not interchangeable boxes in the diagram.

The transaction made the relay decision legible. The sending side opened a two-way channel; the receiver answered. MAIL began a transaction with a reverse path identifying where non-delivery information should return. Each RCPT command supplied a forward path for a recipient, and the command could be repeated. DATA then carried the message. The receiver’s numeric replies made acceptance or failure visible command by command. The SMTP envelope therefore carried delivery instructions that were not the same thing as the words and fields in the message.

That distinction matters when reading RFC 821 alongside RFC 822, published in the same month. RFC 822 standardized the format of ARPA Internet text messages; RFC 821 specified the transfer conversation. The two documents touched the same mail event from different sides. A From: header was part of the message representation, while MAIL FROM belonged to the SMTP transfer transaction. Confusing them turns an address written in text into proof of the route or the delivery decision, which the specifications do not support.

RFC 821 was also a revision, not SMTP’s birth certificate. Its header says it replaces RFCs 788, 780 and 772; RFC 788, dated November 1981, had already specified SMTP. RFC 801’s transition plan mentions the SMTP service in the context of network transition, but it supplies no adoption count or measure of successful user delivery. The date of a revised protocol document cannot stand in for when every host implemented it.

Nor was the model TCP-only. RFC 821’s appendices describe different transport services, including NCP, TCP and NITS, and its TCP appendix assigns the SMTP socket number 25. That detail makes the protocol concrete without implying that opening port 25 proves an operational mail service. A host still needed a running receiver, accepted commands, correct paths, a message transaction, and local handling beyond the channel.

The historical contribution was a boundary that could travel. SMTP defined a common conversation for moving mail and allowed a relay to translate reachability between transport environments; message format and local mailbox behavior remained separate questions. Read through Heng Lu’s Note 64, the design illustrates a useful limit on a shared specification: make the exchange precise enough for interoperability, leave transport choice and deployment to the systems that run it. That is an analytical lens, not a claim about the RFC author’s intent.

Sources