ietf-smtp
[Top] [All Lists]

Re: RFC2821 and EHLO-specified extensions.

2004-11-17 16:44:09

On Wed November 17 2004 17:40, Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu wrote:
Regarding a client's use of an extension not actually advertised in the EHLO -
I was under the impression that was a no-no
[...]
But nowhere did I find a general "Thou shalt not send anything outside the
spec unless negotiated via EHLO or similar"....  Am I blind, or does it not
have that anyplace?

It takes two to tango...

Probably the client is doing something wrong; the whole point of
negotiation of extensions is to avoid a client sending an unsupported
command (or command parameter).  RFC 2821 section 2.2 and its
subsections discuss the negotiation of extensions.

The server, when presented with aberrant client behavior, is free
to return an appropriate error response, such as (sect. 4.2.2):
      500 Syntax error, command unrecognized 
         (This may include errors such as command line too long) 
      501 Syntax error in parameters or arguments 
      502 Command not implemented  (see section 4.2.4) 
      503 Bad sequence of commands 
      504 Command parameter not implemented 
or it could process the command (if supported).

Note also that some commands which were optional in RFCs 821
and 788 are now treated as extensions; however older clients
might not support extension negotiation (EHLO) and therefore
might send any of those commands (VRFY, EXPN, SEND, SAML,
SOML) w/o negotiating.  In order to interoperate with old clients,
SMTP servers should accept any of those commands which they
support even if a client initiates a session with HELO rather than
EHLO.