From RFC 821 to RFC 5321: The Evolution of SMTP
Trace SMTP's standards history from the 1982 base protocol through ESMTP extensions and the later separation of message submission.
Simple Mail Transfer Protocol has survived by evolving around a stable transfer model. RFC 821, published in August 1982, defined a way for cooperating hosts to transfer mail over a reliable ordered stream. It did not define every aspect of modern email, and SMTP should not be confused with the message format carried inside the transaction.
The durable design separated mail transfer from the details of a particular network. Later standards clarified routing, extensions, message submission, and interoperability. Understanding that history helps explain why modern mail uses different services and rules for server-to-server relay and for a user’s mail client submitting a message.
RFC 821: a transfer protocol, not a complete mail system
RFC 821 specified the SMTP dialogue between a client and server, including commands for identifying the peer, naming envelope recipients, transmitting message data, and closing a transaction. The SMTP envelope is distinct from the message headers and body: the envelope directs delivery, while headers such as From and To are part of the message content. The protocol was designed to work over a reliable ordered byte stream and could relay mail across different transport environments.
That scope matters historically. SMTP is one component in an email system that also includes message syntax, naming, DNS routing, mailbox storage, user agents, and later security mechanisms. Saying SMTP “invented email” collapses several technical layers and obscures the earlier research and protocols from which Internet mail developed.
Extension mechanisms made the protocol adaptable
The basic command vocabulary was not enough for every later requirement. RFC 1869 introduced an extension model in which a client can use EHLO and a server can advertise capabilities. RFC 5321 describes the modern baseline: clients should prefer EHLO, while HELO remains a compatibility path. Extensions can be negotiated without replacing the underlying transaction model, allowing new capabilities to be deployed where both sides support them.
RFC 5321, published in October 2008, consolidated and clarified the SMTP transport specification. It obsoleted RFC 821, RFC 974, RFC 1869, and RFC 2821, while retaining compatibility requirements for older implementations. It also documents obsolete or problematic legacy features rather than pretending they never existed. That is why reading an old RFC requires checking its status and successors, not treating a historical document as current operational guidance.
Submission and relay acquired separate roles
SMTP was initially a message-transfer protocol, but user agents also began using it to submit new messages into the mail-routing system. Authentication and local policy create different needs at that boundary than at server-to-server relay. RFC 6409 formalized the separation: message relay continues to use SMTP on port 25, while message submission normally uses port 587 under the submission service’s rules.
This separation is a security and operations boundary, not merely a port-number convention. A submission service can authenticate users, enforce sender policy, and apply account-specific controls. A relay service has a different role and generally routes accepted mail onward. TLS, authentication, and modern anti-abuse practices are specified in separate documents and extensions; they should not be attributed wholesale to RFC 821.
Keep message format and transport distinct
RFC 5322 specifies Internet Message Format, including header fields and body structure. SMTP transports that message using its own command and reply sequence. The layers interact, but they answer different questions: SMTP handles the mail transaction and routing envelope; the message-format specification defines the transmitted content. This separation is one reason modern mail can preserve a message through different agents while the transfer path changes.
When documenting or debugging mail, record the role of each service, the SMTP response at each hop, negotiated EHLO extensions, TLS state, envelope sender and recipients, and the relevant message headers. Never infer that a message was accepted for final delivery merely because a submission server accepted the transaction; relays and destination systems can still reject or defer it later.
Related:
Sources: