[Top] [All Lists]

Re: SMTP Extensions - proper peply code for disabled commands

2004-01-12 22:50:19

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 <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 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;

    - 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

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?