Recently there has been a flurry of ill-considered schemes for extending
SMTP in a manner which is not compatible with the large deployed base of
products which implement ESMTP and which are used in mission-critical
applications. Evidently the authors of such schemes are unfamiliar with
the existing mechanisms which provide for backward-compatible extensions.
Details are in RFC 1869; what follows here is a brief introductory
tutorial.
1. Vanilla SMTP
Here is how an error-free SMTP session for sending a single message
proceeds:
Client opens connection to server
Server sends greeting
Client sends HELO command
Server responds
Client sends MAIL FROM command
Server responds
Client sends RCPT TO command
Server responds
Client sends DATA command
Server responds
Client sends byte-stuffed message, ends with CRLF.CRLF
Server responds
Client sends QUIT command
Server responds and closes connection
All commands in that sequence are part of the base SMTP command set,
guaranteed to be supported by all servers.
2. Capability Negotiation and Fallback
In order to handle extended functionality in a backwards-compatible
manner, it is necessary for the client and server to negotiate
capabilities. It is unacceptable for a client to issue random commands
which are not known to be supported by the server. If some extension is
not announced by the server in negotiation, the client must avoid that
extension, falling back to the set of announced extensions plus the base
SMTP commands. A session with a server that does not support extensions
and a client attempting ESMTP begins:
Client opens connection to server
Server sends greeting
Client sends EHLO command
Server sends error response code
Client sends HELO command; remainder of session is as above for basic SMTP
3. Negotiation Mechanisms
The established negotiation mechanism uses the following components:
o One extension command, EHLO, similar to HELO, which informs the
server that the client wishes to be informed of extensions supported by
the server. If the server responds with an error code to the EHLO
command, the client must fall back to using HELO (and exclusively
other base SMTP commands) or QUIT.
o extension keywords, which identify extended capability features and
which are listed in the server response to EHLO to indicate supported
extensions. Keywords are registered by IANA.
o optional extension commands, associated with a feature named by an
extension keyword
o optional command parameters, associated with a feature named by an
extension keyword.
4. Extended SMTP (ESMTP) Operation
An ESMTP session proceeds as follows:
Client opens connection to server
Server sends greeting
Client sends EHLO command
Server responds, listing supported extension keywords
Client may send commands and parameters associated with supported
extensions announced by the server, and base SMTP commands
5. Ground rules
Clients must not send extended commands other than EHLO unless an
associated keyword is announced by the server in response to EHLO.
Clients may not use extended parameters with base commands unless
an associated keyword is announced by the server. Servers must
support base SMTP commands. Servers announcing extensions must be
prepared to accept any legal combination of commands and parameters
associated with those extensions (e.g. by having sufficient command
line length resources).
6. Choice
A client that wishes to use some extension may try a different server
if that extension is not announced by some particular server. A client
may choose to abort delivery and return an error to the return path if
no suitable server can be found which supports an extension which the
client must use for delivery. A server may choose to offer, or not
offer certain extensions based on the IP address of the connecting
client, the port (e.g. 25 or 587), use of initial TLS, and/or the
domain name or literal specified by the client in the EHLO command
parameter, local policy, availability of resources, etc.; however, the
server must support the base SMTP commands.
7. Recipes for Failure
Any of the following will doom a proposal:
o requirement to simultaneously "upgrade" a significant fraction of
SMTP servers (i.e. lack of negotiation and/or fallback)
o requirement to simultaneously "upgrade" a significant fraction of
SMTP clients (same as above)
o specification of some extension without using the negotiation
mechanism outlined above
In addition, any Internet-Draft proposal that lacks appropriate IANA
Considerations and Security Considerations sections is not likely to
be taken seriously.
Before making extension proposals, authors should carefully review these
considerations, RFC 1869, RFC 822 (base SMTP), and other available
resources (RFCs 2223, 2119, 2277, 2360, 2434, 3365, 3552, and 3426, also
ID-Checklist and 1id-guidelines).