Hi.
In the process of trying to sort through the correspondence
about NOOP, I've gone back and carefully read 4.3.2. I believe
that Hector correctly spotted a real issue that could use some
clarification even though, in looking at one particular piece of
misbehavior (the use of 421), we all missed what I now think is
the key point.
Section 4.3.2 specifies three codes that can be used in response
to any command. They are 421 (which we have been discussing),
500, and 501. The 500 text reads:
# 500 For the "command line too long" case or if the command
# name was not recognized. Note that producing a "command
# not recognized" error in response to the required subset
# of these commands is a violation of this specification.
Now, suppose that, instead of the 421 that Hector observed and
reported on, the server had responded to
NOOP aa
with
500 5.5.2 Syntax error (command line too long)
Now, that would have avoided violating the several constraints
that we have been discussing with 421 as well as the disconnect
between the first digits of the primary and extended codes
(while I agree with Tony that a bogus string is valid, if the
server advertises ENHANCEDSTATUSCODES, I believe that a bogus
enhanced code is not, even though it is not a 2821bis problem).
However, I contend it would still be a bug relative to the
2821[bis] spec and that the comments in the Microsoft Knowledge
Base article that Hector kindly identified reinforce that view.
That article talks about a "default filter value" for a "NOOP
SMTP command" being set at six characters (presumably
NOOP<crlf>), acknowledges that it is a problem and provides a
fix (the vendor already knows that they have a bug, although
they apparently haven't figured out the 421 problem).
(Incidentally, I can see nothing in that article or
Hectors client-server exchange that leads me to believe
that they are trying to conform to 821 and not 2821.
They cite both specs, but respond to EHLO with a long
list of extensions, quote extensively from 2821 and not,
where they are different, from 821, etc. The only
justification for this behavior is the "defend
themselves" provision, which they do not cite, and
even that would be a stretch.)
Now, my reading of Section 4.5.3.1.4 (the "command line"
material in the "Size limits and minimums" section) is that one
doesn't get to use "command line too long" in an error reply
without violating the spec, i.e., that the notion that one can
figure out a maximum length, in the absence of extensions, on a
per-command basis and then apply it as a "filter" that results
in length-based rejection messages is incorrect and broken.
But, unlike the applicability of 421, I don't think that is
completely clear.
So, if others agree with my interpretation, I propose to modify
the description of 500 quoted above by adding to the end...
Similarly, producing a "command line too long" message
for a command line shorter than 1000 characters would
violate the provisions of Section 4.5.3.1.4.
Hector's concerns about NOOP also raise another, more general,
issue, which is whether we are being clear enough about the
expected normal replies to commands. I think that, if it isn't
obvious, one reads the command description, understands the
theory of reply codes (there is a cross-reference from the
introduction to Section 4.1, which lists the commands and syntax
to Section 4.2, which describes replies), and then looks in
Section 4.3.2 for a 2yz code associated with the particular
command. That is the way it has been since 821 and, if one
believes it, then the answer to the question "what is the normal
reply to NOOP" is clearly already answered as "250". The
commands that can return more than one 2yz codes should have the
differences between those codes described in the command
descriptions; I believe all of them do, but I'd welcome someone
else checking on that.
But one of the implied goals for 2821bis has been making the
spec easier to read and understand without a comprehensive
understanding of how it is organized. So, with the
understanding that this is a question and not a recommendation
(since I do not have an opinion), would it be useful to insert
text in the command descriptions for the commands that have only
a single positive reply (EHLO/HELO, DATA, RSET, NOOP, and QUIT)
that explicitly identifies the code that is expected for a
normal/successful reply? Or would that be just clutter that
makes the document longer to no good end?
john