SMTP Service Extensions
obsoleted by
- rfc-1651 — SMTP Service Extensions
Extracted elements (19)
The authors emphasize that extensions to SMTP should not be considered lightly: 'protocols with few options tend towards ubiquity, whilst protocols with many options tend towards obscurity.' Each extension must be scrutinized for implementation, deployment, and interoperability costs.
The extension framework was deliberately designed so that existing SMTP clients and servers require no modification unless they actually use extension features. This preserves backward compatibility and avoids forcing upgrades on the deployed base.
The 'X'-prefix convention for local extensions enables bilateral experimentation without polluting the standardized namespace, while the IANA registration requirement for non-'X' keywords ensures that advertised capabilities have interoperable, documented semantics.
An RFC 821-conformant server that does not support SMTP service extensions will not recognize the EHLO command and will return code 500. The client should then send RSET and proceed with HELO as specified in RFC 821.
A client SMTP MUST NOT cache any information returned if the EHLO command succeeds. It must issue the EHLO command at the start of each SMTP session if information about extended facilities is needed.
A conforming server MUST NOT offer non-'X'-prefixed EHLO keyword values that are not described in a registered IANA extension. Any keyword not beginning with 'X' must correspond to a registered SMTP service extension.
All esmtp-keyword values used in MAIL FROM and RCPT TO parameters MUST be registered as part of the IANA registration process. RFC 1425 defines only the framework; no extended MAIL FROM or RCPT TO parameters are defined here.
EHLO keywords MUST always be recognized and processed in a case-insensitive manner, regardless of whether they are specified in upper, lower, or mixed case.
If the server does not recognize or cannot implement one or more MAIL FROM or RCPT TO parameters, it MUST return code 555. If temporarily unable to accommodate parameters, it SHOULD return code 455.
SMTP servers are required to add an appropriate Received: header field to all messages they receive. A 'with ESMTP' clause SHOULD be added when any SMTP service extensions are used. 'ESMTP' is added to the list of standard protocol names registered with IANA.
EHLO keyword values beginning with an upper or lower case 'X' denote local SMTP service extensions used through bilateral rather than standardized agreement. Keywords beginning with 'X' may not be used in a registered service extension.
On EHLO failure (server unable to list extensions), the server returns code 554. On unacceptable argument, code 501. On recognized-but-unimplemented EHLO, code 502. On service unavailable, code 421. The client should issue HELO or QUIT after any error or failure response.
The EHLO command is a new SMTP command issued by a client at the start of a session instead of HELO to signal support for SMTP service extensions. The server responds with code 250 and a multiline list of supported extension keywords, or with an error code.
The IANA maintains a registry of standard SMTP service extensions. Each registered extension must be defined by a standards-track RFC specifying: the extension name, EHLO keyword, keyword parameters, any additional SMTP verbs, any new MAIL FROM/RCPT TO parameters, and behavioral impact. Initial entries include SEND, SOML, SAML, EXPN, HELP, and TURN (all from RFC 821 optional commands).
RFC 1425 does not introduce new security issues beyond those already present in RFC 821 and conforming email implementations. The EHLO verb does announce server capabilities, but all information from the initial extension set can be deduced by probing standard SMTP verbs. Security implications of specific extensions are deferred to their defining RFCs.
After a successful EHLO (or HELO) response is returned, a subsequent HELO or EHLO command will result in the server replying with code 503 (bad sequence). EHLO may be issued at any time a HELO would be appropriate.
EHLO command syntax: 'EHLO' SP domain CR LF. The domain field identifies the client. This follows the ABNF notation of RFC 822.
Extended MAIL FROM and RCPT TO commands accept esmtp-parameters of the form 'esmtp-keyword [= esmtp-value]' appended after a SP. The esmtp-keyword is (ALPHA/DIGIT)(ALPHA/DIGIT/'-')*; the esmtp-value excludes '=', SP, and control characters (US ASCII 0-31).
Successful EHLO response (code 250) is a multiline reply where each line contains an ehlo-keyword optionally followed by space-separated ehlo-params. The final line uses '250 SP ehlo-line' while continuation lines use '250-'. Keywords are (ALPHA/DIGIT) sequences; params exclude SP and control characters (US ASCII 0-31).