SMTP Service Extensions
obsoleted by
- rfc-2821 — Simple Mail Transfer Protocol
obsoletes
- rfc-1651 — SMTP Service Extensions
also
- std-10
Extracted elements (20)
Keywords beginning with 'X' (upper or lower case) designate local SMTP service extensions negotiated bilaterally rather than through standardization, providing an escape valve for experimentation without polluting the registered namespace.
The extension framework is deliberately minimal: protocols with few options tend toward ubiquity, while protocols with many options tend toward obscurity. Each extension must be carefully scrutinized because the cost of extending SMTP will often outweigh the benefit.
An RFC 821 server that does not support SMTP extensions will return code 500 to EHLO. The client may then issue HELO or QUIT and proceed per RFC 821. The server should remain in the same state after this response.
Some improperly-implemented servers disconnect upon receipt of EHLO or refuse HELO after a rejected EHLO. Extended SMTP clients should check for connection closure after EHLO, and may work around the HELO refusal by sending RSET first (ignoring a 503 failure code from RSET).
A client SMTP must not cache any information returned if the EHLO command succeeds; it must issue EHLO at the start of each SMTP session if information about extended facilities is needed.
A client SMTP supporting SMTP service extensions should start an SMTP session by issuing the EHLO command instead of the HELO command.
A conforming server must not offer non-'X'-prefixed EHLO keyword values that are not described in a registered extension. Keywords beginning with 'X' refer to local bilateral extensions and may not be used in a registered service extension.
EHLO keywords must always be recognized and processed in a case-insensitive manner, regardless of the case in which they are presented.
Every SMTP service extension must be registered with IANA and defined in a standards-track or IESG-approved experimental RFC. The registration must include the keyword, parameter syntax, any new verbs, any MAIL FROM/RCPT TO parameters, behavioral description, and maximum command-length increment.
If the server is unable to accommodate one or more MAIL FROM or RCPT TO parameters, it must return code 555 (unrecognized/unimplemented parameter) or 455 (temporarily unable to accommodate), depending on the nature of the failure.
RFC 821's requirement that the first command in an SMTP session must be HELO is amended to allow a session to start with either EHLO or HELO.
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.
The 512-character limit on SMTP command line length is amended to apply only to command lines without parameters. Implementations supporting extensions must support 512 plus the sum of all maximum parameter lengths for all supported extensions.
EHLO success returns code 250 (possibly multiline). Failure to list extensions returns 554. Unacceptable argument returns 501. Unimplemented EHLO returns 502. Service unavailable returns 421. An RFC 821 server that does not recognize EHLO returns 500.
The EHLO command is introduced as a replacement for HELO to initiate an SMTP session with extension negotiation. The server responds with a multiline 250 reply listing supported extension keywords and optional parameters.
'ESMTP' is added to the list of standard protocol names registered with IANA, for use in the 'with ESMTP' clause of Received: header fields.
IANA maintains a registry of SMTP service extensions, each identified by an EHLO keyword. The initial registry entries are SEND, SOML, SAML, EXPN, HELP, and TURN, corresponding to optional RFC 821 commands.
RFC 1869 does not introduce new security issues beyond those already endemic in electronic mail and RFC 821. The EHLO response does announce server capabilities, but all such information can be deduced by selectively probing mandatory SMTP verbs. Security implications of individual extensions should be addressed in their defining RFCs.
Extended MAIL FROM and RCPT TO commands accept esmtp-parameters of the form 'esmtp-keyword ["=" esmtp-value]', where esmtp-keyword is alphanumeric-plus-hyphen and esmtp-value excludes '=', SP, and control characters.
The EHLO command takes the form 'EHLO SP domain CR LF'. The successful multiline 250 response carries the server domain on the first line, followed by zero or more lines each containing an ehlo-keyword and optional ehlo-param values separated by spaces.