RFC 1869 – SMTP Service Extensions (ESMTP)

Internet Standard Core SMTP & Message Format Published November 1995 Obsoleted by RFC 5321

ELI5: Original SMTP was like two people who could only speak basic English. ESMTP is like starting a conversation by saying “I also speak French, German, and Japanese — do you?” The EHLO command replaced HELO and lets both sides discover what extra features they share before they start exchanging mail. Every modern SMTP feature — authentication, encryption, size limits — relies on this negotiation mechanism.

Why This RFC Exists

The original SMTP protocol (RFC 821, 1982) had no mechanism for adding new features. There was no way for a client to discover what a server supports, and no way for a server to advertise capabilities. Every extension required a new, incompatible protocol version.

RFC 1869, published in 1995, solved this by defining a generic framework for SMTP extensions. It introduced the EHLO command (Extended HELLO) as a replacement for HELO. When a client sends EHLO, the server responds with a list of extensions it supports. The client can then use any extensions both sides understand.

This framework is so fundamental that it was later folded directly into the base SMTP specification in RFC 5321. Virtually every SMTP session today uses ESMTP — plain HELO is effectively obsolete.

How It Works

The client connects and receives the server's greeting banner.
The client sends EHLO client.example.com (instead of the old HELO).
The server responds with 250 followed by its hostname, then one extension keyword per line. Each line uses 250- (continuation) except the last, which uses 250 (final).
The client inspects the extension list and uses only the features the server advertised.
If the server doesn't understand EHLO (extremely rare today), it returns a 500 error, and the client falls back to HELO.

SMTP Example

A typical ESMTP capability negotiation:

S: 220 mx.example.com ESMTP ready C: EHLO sender.example.net S: 250-mx.example.com Hello sender.example.net S: 250-SIZE 52428800 S: 250-8BITMIME S: 250-STARTTLS S: 250-ENHANCEDSTATUSCODES S: 250-PIPELINING S: 250-CHUNKING S: 250-SMTPUTF8 S: 250 AUTH PLAIN LOGIN # The client now knows exactly what this server supports: # SIZE — max message size is 50 MB # 8BITMIME — 8-bit content transfer encoding allowed # STARTTLS — TLS encryption available # ENHANCEDSTATUSCODES — RFC 3463 status codes # PIPELINING — can batch commands (RFC 2920) # CHUNKING — BDAT command available (RFC 3030) # SMTPUTF8 — internationalized addresses (RFC 6531) # AUTH — authentication with PLAIN or LOGIN

Key Technical Details

The Extension Registry

ESMTP extensions are registered with IANA. Each extension defines a keyword (e.g., STARTTLS, AUTH, PIPELINING) and optionally parameters. The most important extensions for email:

Keyword	RFC	Purpose
`SIZE`	RFC 1870	Declare maximum message size
`8BITMIME`	RFC 6152	Allow 8-bit content in message body
`STARTTLS`	RFC 3207	Upgrade connection to TLS encryption
`AUTH`	RFC 4954	SMTP authentication
`PIPELINING`	RFC 2920	Batch multiple commands without waiting
`CHUNKING`	RFC 3030	Binary data transfer with BDAT
`SMTPUTF8`	RFC 6531	Internationalized email addresses
`DSN`	RFC 3461	Delivery status notification requests
`ENHANCEDSTATUSCODES`	RFC 3463	Detailed status codes in responses
`REQUIRETLS`	RFC 8689	Require TLS for this message

EHLO vs. HELO

HELO is the original SMTP greeting from 1982. It provides no capability discovery. EHLO is a strict superset: it performs the same greeting function but also triggers the capability list. Servers must support both, but clients should always use EHLO first and only fall back to HELO if EHLO is rejected.

Re-EHLO After State Changes

The capability list can change during a session. After a STARTTLS handshake, the client must send a new EHLO because the server may advertise different extensions over the encrypted connection (e.g., AUTH is often only available after TLS). After RSET, the capability list remains valid.

Extension Parameters

Some extensions include parameters on the EHLO response line. For example, SIZE 52428800 declares a 50 MB limit, and AUTH PLAIN LOGIN lists the available authentication mechanisms. Extensions can also add parameters to MAIL FROM and RCPT TO commands, like MAIL FROM:<user@example.com> SIZE=1048576.

Common Mistakes

Using HELO instead of EHLO. Some legacy applications still send HELO. This disables all SMTP extensions, including authentication and encryption. Always use EHLO.
Not checking the EHLO response. Clients that blindly use extensions without verifying the server advertised them will get errors. Always parse the capability list before using any extension.
Caching capabilities across sessions. The extensions a server supports can change between connections. Always perform a fresh EHLO for each new connection.
Forgetting to re-EHLO after STARTTLS. After upgrading to TLS, the pre-TLS capability list is invalid. A new EHLO is mandatory to get the updated capabilities.
Sending an invalid EHLO hostname. The argument to EHLO should be your server's FQDN or, if no hostname is available, an address literal like [192.0.2.1]. Sending an empty or bogus hostname can cause rejection.
Ignoring the EHLO domain for security. Receiving servers should not trust the EHLO hostname for authentication — it's self-reported and trivially forged. Use SPF, DKIM, and DMARC instead.

Deliverability Impact

ESMTP is required for modern email. Without EHLO, you cannot use STARTTLS, AUTH, PIPELINING, or any other extension. A client that only speaks HELO is treated as suspicious by most mail servers.
Extension support signals legitimacy. Servers that advertise and correctly implement standard extensions (ENHANCEDSTATUSCODES, PIPELINING, SIZE) are seen as well-configured. Missing or broken extension support can trigger negative scoring in spam filters.
EHLO hostname matters for reputation. While the EHLO hostname isn't authenticated, many spam filters check that it resolves in DNS and matches the connecting IP's reverse DNS. Mismatches contribute to spam scoring.
SIZE declaration prevents wasted bandwidth. When the server advertises its size limit, clients can avoid sending oversized messages that would be rejected after the full data transfer. This improves delivery efficiency.