What this RFC defines
RFC 1869 defines ESMTP (Extended Simple Mail Transfer Protocol) and the EHLO command. It introduces the extension framework that allows SMTP servers to advertise optional capabilities to connecting clients: AUTH, STARTTLS, SIZE, 8BITMIME, and others. Before ESMTP, SMTP had no mechanism to negotiate optional features.
Where you see it in practice
When your MTA connects to a receiving server and sends EHLO yourdomain.com, the list of 250- capability lines in the response (250-STARTTLS, 250-AUTH PLAIN LOGIN, 250-SIZE 52428800) is the ESMTP extension advertisement defined by RFC 1869. Every modern SMTP transaction begins with this EHLO exchange. Servers that only support the older HELO command cannot use any of the extensions built on RFC 1869.
How it connects to other RFCs
RFC 1869 obsoletes RFC 1651 and is the foundation for all SMTP extension RFCs. RFC 3207 (STARTTLS), RFC 4954 (AUTH), RFC 1870 (SIZE), RFC 6152 (8BITMIME), and RFC 6409 (submission) all advertise their capabilities via the EHLO mechanism RFC 1869 defines. RFC 5321 incorporates and updates the EHLO concept.
Current status
RFC 1869 is a current standard, published November 1995. The ESMTP extension framework it defines is the basis of all modern SMTP capability negotiation and is universally supported by every mail server on the internet.
The extension mechanism itself
RFC 1869 introduced the ESMTP framework in November 1995. Rather than modifying the base SMTP protocol from RFC 821, the authors created a negotiation mechanism: a client greets the server with EHLO instead of HELO, and the server responds with a list of extensions it supports, one per line. Each extension has a keyword (SIZE, STARTTLS, AUTH, 8BITMIME, PIPELINING) and optional parameters. This design allowed SMTP to evolve without breaking legacy servers, since any server that does not recognize EHLO can be reprobed with HELO for baseline behavior.
Extensions that grew from this framework
Every major SMTP capability added since 1995 is a separate RFC that plugs into the RFC 1869 framework. RFC 1870 defined the SIZE keyword for message size declaration. RFC 3207 defined STARTTLS for opportunistic encryption. RFC 4954 defined AUTH for authenticated submission. RFC 6152 defined 8BITMIME for eight-bit-clean transport. RFC 2920 defined PIPELINING for command batching. RFC 6531 defined SMTPUTF8 for internationalized addresses. Without the RFC 1869 extension mechanism, each of these would have required a fork of the base protocol.
Current status and integration
RFC 1869 was folded into the RFC 5321 base standard in 2008; you rarely see it cited by itself in new work. However, it remains the conceptual foundation for how SMTP evolves. Understanding the EHLO negotiation is essential for debugging: if an EHLO response is missing an expected extension, either the server does not support it, or a firewall or middlebox is stripping the capability line. Both scenarios cause real deliverability issues that trace back to RFC 1869 negotiation.
RFC 1869 (November 1995) defined SMTP Service Extensions and the EHLO command: the mechanism that lets SMTP clients discover which extensions a server supports. Introduced multi-line 250 responses listing capabilities. Every modern SMTP extension (STARTTLS, AUTH, 8BITMIME, SMTPUTF8, SIZE, PIPELINING, CHUNKING, DSN) depends on this mechanism. Obsoleted by RFC 2821 (2001), which was folded into RFC 5321 (2008). Reference for current EHLO behavior: RFC 5321.
RFC 1869 at a glance
| Aspect | Detail |
|---|---|
| Purpose | Introduce extensibility to SMTP via EHLO capability discovery |
| Key command | EHLO replaces HELO for extensibility-aware sessions |
| Response format | Multi-line 250 with capability keywords |
| Fallback | Client can retry with HELO if server doesn’t support EHLO |
| Enabled extensions | SIZE, PIPELINING, STARTTLS, AUTH, 8BITMIME, SMTPUTF8, DSN, CHUNKING |
| Published | November 1995 |
| Superseded by | RFC 2821 (2001), then RFC 5321 (2008) |
EHLO vs HELO
| Aspect | HELO (original RFC 821) | EHLO (RFC 1869) |
|---|---|---|
| Response | Single line 250 | Multi-line 250 with capabilities |
| Extension support | None advertised | Each supported extension listed |
| Modern usage | Fallback only (legacy servers) | Default for all modern clients |
| Command parameters | Client identity only | Client identity plus optional parameters |
EHLO dialogue example
Common EHLO/extension mistakes
Related standards and further reading
- RFC 821: Original SMTP (obsoleted by RFC 2821, then RFC 5321)
- RFC 2821: Second-generation SMTP (obsoleted by RFC 5321)
- RFC 5321: Current SMTP (includes RFC 1869 EHLO mechanism)
- RFC 5321 Guide: current SMTP with all extensions
- Email Protocols and Ports: SMTP alongside IMAP and POP3
Frequently asked questions
Should I reference RFC 1869 or RFC 5321 for current SMTP behavior?
RFC 5321. It absorbed RFC 1869 and RFC 2821, and is the current specification. Reference RFC 1869 for historical context (when the extension mechanism was introduced) or when discussing the specific evolution of SMTP extensibility. Modern implementers should target RFC 5321 for compliant behavior.
What happens if a server does not advertise an extension I want to use?
Depends on the extension. STARTTLS, AUTH, 8BITMIME are essential and unsupported servers are legacy. SMTPUTF8, CHUNKING, BINARYMIME are optional and clients should fall back to non-extended behavior. Send code should always check EHLO response for capabilities before attempting to use them; assuming universal support of any extension breaks against real-world legacy servers.
How do I add a new SMTP extension?
Draft an RFC through the IETF Standards Track process. The extension defines: an EHLO keyword (all uppercase, hyphenated), any new commands or parameters, wire format, and error handling. Register the keyword with IANA. Extensions must be backward compatible: clients not requesting the extension continue to work; servers not advertising it fall back to base SMTP. This is by design; the whole point of RFC 1869’s mechanism was extensibility without breaking legacy peers.
Why do some servers respond to EHLO with 500 or 502?
Legacy MTAs from before RFC 1869 (pre-1995) supported only HELO. Their response to unknown commands like EHLO is 500 or 502. Modern RFC-compliant clients try EHLO first; if it fails with 500, 502, or connection reset, retry with HELO. Server rejection with 500 to EHLO is a strong signal that the peer is legacy and may not support any extensions.
Can EHLO be issued more than once in a session?
Yes, and it must be re-issued after STARTTLS per RFC 3207 (post-TLS server capabilities may differ). Multiple EHLO commands are legal; each resets the session state to the point just after EHLO. This is occasionally useful for clients that want to renegotiate parameters mid-session, though rarely done in practice.
About the Author
Alaa · LinkedIn
Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. I’ve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.
About SMTPedia
SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.
We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.
