SMTP Service Extensions
Extracted elements (25)
Keywords beginning with "X" are designated for local, bilateral (non-standardized) service extensions, keeping the standardized keyword namespace clean while allowing experimentation without IANA registration.
No extended MAIL FROM or RCPT TO parameters are defined in RFC 1651 itself; the document only establishes the syntactic framework (esmtp-parameters) to support future extensions in separate RFCs.
The document explicitly cautions that each extension must be scrutinized for implementation, deployment, and interoperability costs, observing that "protocols with few options tend towards ubiquity, whilst protocols with many options tend towards obscurity."
The extension framework is designed so that existing RFC 821 SMTP clients and servers require no modification unless they wish to use or provide specific extensions. Compatibility is maintained by falling back to HELO when EHLO is not understood.
RFC 821-conformant servers that do not support ESMTP will return code 500 to EHLO and remain in the same state. The client may then issue HELO or QUIT to proceed with a non-extended session.
Some broken servers will not accept HELO after EHLO has been rejected. A workaround is to send RSET after the EHLO failure before issuing HELO; clients should ignore a 503 response to the RSET in this context.
Some improperly-implemented servers disconnect the SMTP channel upon receiving EHLO, violating RFC 821 section 4.1.1. Extended clients are suggested to check for connection closure after sending EHLO and, if closed, reconnect and fall back to HELO if extensions are not required.
A client SMTP MUST NOT cache any information returned by a successful EHLO response; it must reissue EHLO at the start of each session if information about extended facilities is needed.
A client SMTP supporting service extensions SHOULD start an SMTP session by issuing EHLO instead of HELO.
A conforming server MUST NOT offer non-"X"-prefixed EHLO keyword values that are not described in a registered and standardized SMTP service extension. Keywords beginning with "X" are reserved for local, bilateral extensions.
All esmtp-keyword values used in MAIL FROM or RCPT TO parameters must be registered through the IANA registration process. No extended parameters are defined by RFC 1651 itself.
EHLO keywords MUST always be recognized and processed in a case-insensitive manner, regardless of whether they are presented in upper, lower, or mixed case.
If EHLO succeeds, a subsequent HELO or EHLO command will result in the server returning code 503 (bad sequence of commands).
If the server cannot recognize or implement one or more MAIL FROM or RCPT TO parameters, it MUST return code 555. If it is temporarily unable to accommodate parameters it SHOULD return code 455.
If the server SMTP is unable to list its supported service extensions, it MUST return code 554. In that case, the client should issue either HELO or QUIT.
SMTP servers are required to add a Received: field to all messages they relay; a "with ESMTP" clause SHOULD be added to this field when any SMTP service extensions are used.
The EHLO command is introduced as the new session-opening command for ESMTP clients, replacing HELO. It allows the server to advertise supported service extensions to the client. It may be issued at any time a HELO command would be appropriate.
"ESMTP" is added to the IANA list of standard protocol names, to be used in the "with ESMTP" clause of Received: header fields.
Initial IANA SMTP service extension registry entries are SEND, SOML, SAML, EXPN, HELP, and TURN — corresponding to the optional commands from RFC 821. Each has no additional parameters and uses the same verb as the keyword.
The IANA maintains a registry of standard SMTP service extensions. Each entry must be defined by a standards-track RFC and includes: extension name, EHLO keyword, parameter syntax, any additional verbs, any MAIL FROM/RCPT TO parameters, and behavioral description.
RFC 1651 does not introduce new security issues beyond those already present in RFC 821. The EHLO response announces server capabilities, but all such information could also be obtained by selectively probing individual SMTP verbs. Security implications of specific extensions are deferred to the RFCs defining those extensions.
A successful EHLO response (250) indicates that both server and client are in the initial state: no transaction is in progress and all state tables and buffers are cleared. This mirrors the reset semantics of HELO.
A successful EHLO response is a multiline 250 reply. Each line carries an ehlo-keyword optionally followed by space-separated ehlo-params. Keywords consist of ALPHA/DIGIT and hyphens; params exclude SP and control characters (US-ASCII 0-31).
EHLO command syntax is: "EHLO" SP domain CR LF. On success the server returns 250; on failure 550; on error one of 500, 501, 502, 504, or 421.
Extended MAIL FROM and RCPT TO commands accept esmtp-parameters of the form esmtp-keyword ["=" esmtp-value], space-separated after the standard path argument. esmtp-value excludes "=", SP, and all control characters.