Re: SMTP Extensions - proper peply code for disabled commands

Just to close this loop, the omission of 502 from the valid code 
list for EHLO was intentional.  Specifically, Lyndon is correct: 
2821 requires ("MUST") that EHLO be supported.  If you are not 
going to support it, then you are either operating in 821-land, 
in which EHLO is an unrecognized command, or you need the reply 
code for "my implementation is broken".
As Lyndon says, 2821 doesn't specify the details of ways to 
violate the standard. Consequently, it hence doesn't specify a 
value for the "my implementation is broken" code.  If you need 
one, I'd suggest, e.g., "999", which would cause almost all 
clients to stop talking to your server.  :-(
 regards,
   john

p.s. Your server seems to not like Reverse-paths that contain 
plus signs, or otherwise has problems "verifying addresses" with 
which other systems seem to have no difficulty.    Might be 
worth trying to fix if you expect to participate in IETF 
discussions, since a number of folks around here use addresses 
of that type.
--On Sunday, 11 January, 2004 00:20 -0500 Hector Santos 
<winserver(_dot_)support(_at_)winserver(_dot_)com> wrote:
> Hello all,
>
> I am just throwing this out there for comment.
>
> - Proper response code for a disabled EHLO implementation.
>
> What is the proper response code for a system which supports
> EHLO but for some reason or another the sysop has it turned
> off (disabled)?
>
> In older code (versions back in 2001) we used a general 500
> response for commands that were not recognized or implemented
> but "turned off."
>
> In our current version, for recognized but turned off
> (disabled) commands the response was changed to use a 502
> response.   This was done in accordance to '2821' section
> 4.2.4:
>
> 4.2.4 Reply Code 502
>
>    Questions have been raised as to when reply code 502
> (Command not    implemented) SHOULD be returned in preference
> to other codes.  502    SHOULD be used when the command is
> actually recognized by the SMTP    server, but not
> implemented.  If the command is not recognized, code    500
> SHOULD be returned.  Extended SMTP systems MUST NOT list
> capabilities in response to EHLO for which they will return
> 502 (or    500) replies.
>
> However,  per 2821, it you look at the possible error codes
> for EHLO, it indicates 504, 550 as the possible error response
> codes.
>
> 504 says "command parameters are incorrect"
> 550 ... command rejected for policy reasons
>
> We didn't use 504 is because this seems to suggest the command
> is "possible" with proper parameters.
>
> We didn't use 550 because it sounds more like a "access issue"
> not a disabled notification. Also since section 4.2.4  seems
> to reinforce  502 as the proper response for a "recognized but
> not implemented" command, it may sense to use 502.
>
> What say you here?
>
> First,  in my view,  I think the document should clarify or
> distinguish the difference between  the terms;
>
>     - recognized,
>     - implemented and
>     - disabled.
>
> Second,  to me, it sounds like the specific responses can be
> summarized as:
>
>     500 is used for an unrecognized command
>     502 is used for recognized but disabled commands
>     504 is used for recognized but with incorrect parameters.
>     55x is used as a processed command but rejected for some
> reason
>
> would you agree with this?
>
> Anyway,  it seems obvious to understand that per section
> 4.2.4,  502 is inherently inclusive of all possible error
> responses for all ESMTP extended commands which are recognized
> but not implemented (to me, that means disabled).
>
> However, in section 4.3.2,  502 is explicitly stated as
> possible error codes for the commands such as VRFY, EXPN.
> Therefore, at a minimum,  502 should be added as a possible
> error code for the EHLO command listed in section 4.3.2.
>
> Do you agree?
>
> Thanks