ietf-smtp
[Top] [All Lists]

Backward compatible SMTP extensions

2005-05-15 20:16:43

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).


<Prev in Thread] Current Thread [Next in Thread>