Summary

  • RFC 1425 introduced EHLO as a common discovery point for SMTP service extensions. A successful reply described capabilities for one session, and clients were explicitly forbidden to cache that information for the next session.
  • The specification offered a clean compatibility path: an old server could reject EHLO, preserve the connection state and allow HELO. RFC 1651 later documented deployed servers that instead disconnected or refused HELO after the rejection.
  • The historical record separates a registered extension, a session advertisement, a usable fallback, an accepted command, a completed mail transaction and delivery. None can stand as evidence for the next.

In February 1993, Internet mail needed a way to change without requiring every mail server to change at once.

SMTP had survived for more than a decade partly because its conversation was small and predictable. A client connected, received a greeting, introduced itself with HELO, supplied an envelope and then sent content. New needs were accumulating, but adding each one through an unrelated command or private convention risked turning that shared conversation into a collection of dialects.

RFC 1425 proposed a thin common layer. It did not define all future extensions. It defined how an extended client could discover what one server said it supported: begin the session with EHLO, receive a reply containing registered keywords and optional parameters, and use the separate specification behind a keyword if both sides chose that path.

This was a registry, a grammar and a moment of disclosure. It was not a universal upgrade.

One reply described one session

The time boundary was unusually explicit. If a client needed information about extended facilities, it had to issue EHLO at the start of each SMTP session. It must not cache the information returned by a prior successful EHLO.

That rule prevented yesterday's observation from becoming today's authority. The same host name could lead to a different process, configuration, route, maintenance state or server. Even when nothing changed, the protocol still required a fresh statement inside the current transmission channel.

A successful EHLO used a 250 reply. It also established a particular state: client and server were at the beginning, no mail transaction was in progress, and their state tables and buffers were clear. The multiline response could then enumerate keywords. Keyword recognition was case-insensitive. Registered, non-X keywords were tied to extension specifications; locally agreed keywords used the X convention of that era.

The list was not a report of completed work. It answered a narrower question: what extended behavior does this server announce here and now? A client still had to select an extension, construct the command or parameter defined by its own RFC and receive the relevant reply.

RFC 1426 made the separation concrete. Seeing 8BITMIME in an EHLO response came before sending MAIL FROM with BODY=8BITMIME. Acceptance of that extended command came before DATA. Responsibility for the message came before any next-hop decision. The bit-preserving rules belong to RFC 1426, not RFC 1425. The evidence sequence belongs to both.

The clean fallback assumed preserved state

Extension discovery had to coexist with servers that knew only RFC 821. RFC 1425 described the expected encounter. An old server would not recognize EHLO; it would return an error and stay available. The client could reset or send HELO and continue under the older SMTP rules.

On paper, this was a careful compatibility design. A new client tested for a new vocabulary. Failure did not force the old peer to implement it, and refusal did not label the peer defective. The parties simply selected the common compatibility set.

But the transition depended on more than the reply code. It depended on the server leaving the transmission channel open. It depended on the server's command state remaining valid after the unknown word. It depended on the following RSET or HELO being interpreted in the state the standard expected.

Those dependencies were executable facts, not properties of the syntax diagram.

The next RFC recorded the missing reality

In July 1994, RFC 1651 obsoleted RFC 1425. Much of the extension framework remained familiar. A new section, however, dealt with “improperly implemented servers.” Its existence is the revealing part of the revision.

Some known servers closed the SMTP transmission channel when they received EHLO. The close could occur immediately or after a response. RFC 821 said the channel should normally remain open until QUIT, so this was not a newly authorized variation. Yet interoperability could not be restored by repeating what a conforming server ought to do.

The client now had to observe the channel itself. If the connection closed, it had to decide whether the operation could succeed without extensions. If so, it could open a new connection and use HELO. The retry was not the continuation originally imagined. It was a second session with a new greeting, new state and a separate outcome.

Other servers kept the connection but would not accept HELO after they had rejected EHLO. For some, sending RSET before HELO could work. Even there, the repair accumulated another anomaly: implementations might answer that RSET with 503 Bad sequence of commands, which the RFC said could be ignored in this narrow workaround.

RFC 1869, which replaced RFC 1651 in November 1995, retained the operational warning. The live incompatibility had become part of the standard's historical memory.

The lesson is not that specifications are useless. The revision did precisely what a healthy specification should do: absorb evidence from deployment without pretending the first design had already caused compliant behavior. Running code disciplined the text.

A fallback is a chain, not a label

It is tempting to record this exchange as “ESMTP unsupported, SMTP fallback succeeded.” That sentence can conceal several different events.

The TCP connection may have opened. A 220 greeting may have arrived. The client may have sent EHLO. The server may have returned a reply, closed before replying or closed afterward. If the channel survived, RSET may have been accepted, rejected or ignored. HELO may then have succeeded. A mail envelope may have been accepted. The content may have been received. A relay may have assumed responsibility. The destination may or may not have delivered the message.

Each record has its own identity and time. A second connection must not silently overwrite the first. A successful HELO retry does not make the earlier channel continuous. An advertised keyword does not prove its command will be accepted. A 250 after DATA does not prove that a person read the message.

This is the deeper value of RFC 1425's no-cache rule. Capability was never meant to become a durable property attached to a host in an inventory. It was an assertion inside a session. Once a channel closed, its advertisement expired with the context that gave it meaning.

Thin extension points moved risk instead of erasing it

RFC 1425 warned that protocols with few options tend toward ubiquity while those with many options tend toward obscurity. It asked that every extension be weighed against implementation, deployment and interoperability cost. The extension framework managed that cost by keeping a small common discovery surface and assigning specific behavior to separate RFCs.

That design protected old servers from a mandatory fleet-wide upgrade. It also moved compatibility work toward clients. A client seeking broad reach had to parse multiline replies, distinguish error paths, discard stale capability state and survive peers that reacted incorrectly to discovery itself.

The arrangement was decentralized in a practical sense. Registration gave a keyword common meaning; it did not cause deployment. A server locally chose which extensions to run. A client locally chose which advertised path it could use. Old and new peers could continue on the smaller shared language when the transition machinery actually held.

The word “actually” carries the history. A published fallback can describe the intended state machine. Only an observed sequence can show that both participants inhabited it.