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. :-(
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
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
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 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
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;
- implemented and
Second, to me, it sounds like the specific responses can be
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
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?