This is my last note on this issue unless you can present a
succinct and focused argument as to why this is sufficiently
important that we should reopen the document, risking having the
IESG suspend the Last Call, etc. However, since this note is
(finally) the sort of focused discussion about the issue that I
(and I think others) have been looking for (and for which I
thank you), I want to respond directly to it.
--On Thursday, 29 November, 2007 18:12 -0500 Hector Santos
John C Klensin wrote:
This is just my personal opinion, but if we add specific text
to deal with every clear violation of the existing standard
text, we will make 2821bis twice as long and add
approximately zero new information. I don't particularly
object to this change but wonder where things end if we start
down that path.
John, I looked into this more, and I think I found how what is
First the summary of all this:
Maybe simply this change to the last sentence of the NOOP
command section is appropriate:
If a parameter string is specified, servers MUST ignore
string as a reason for a 421 response. It MAY be used for
logging purposes only.
This is helpful in that it is a specific proposal, with a
specific justification... and one that avoids distractions with
the many sub-issues.
However, my reading and understanding of the specification in
2821bis is that there is one and only one valid "reason for a
421 response" and that is imminent shutdown or disconnect.
Because one implementation has violated the specification by
issuing a 421 when that reason does not apply does not, for me,
justify reopening the document or inserting this text. After
all, one could as easily say (at the risk of using a pair of
If it is Thursday, servers MUST ignore the string as a
reason for a 421 response.
If the mailbox name in the backward-pointing address
contains an even number of characters, servers MUST
ignore the string as a reason for a 421 response.
In other words, _any_ 421 response that isn't justified by the
only valid reason for a 421 response is an error. We don't make
the specification better by listing all of the variations of
that error we can think of, or even find in the wild.
Now, for the record (because I don't think this is a significant
enough issue to justify reopening the document, but YMMD and you
can try to convince others), I'd be fine with
If a parameter string is specified, servers MUST ignore
that string. It MAY be used for logging purposes only.
I'd be fine with applying that same statement to RSET and QUIT
if their syntax permits strings at all. Note that it doesn't
say a think about 421, which I think is a distraction as well as
a clear violation of the spec. I don't think it is necessary
because I think that principle is clear from existing text. But
I don't think it is harmful either and, if it didn't require
opening a document that had already gone into IETF Last Call,
I'd be inclined to add such text if any two or three of the
people on the list thought it was useful (Tony might, of course,
have other opinions).
What's going on that these specific ESMTP (Extended Server)
are still following RFC 821 where there is ABNF or expecting
for a NOOP string:
Very possible. And I, at least, find the additional
understanding helpful. But 2821 (and several of its
predecessors) were quite clear that, if one advertises EHLO, the
conformance expectations were higher than, and slightly
different from, the conformance expectations for 821. So
conforming halfway to 821 and halfway to 2821 is non-conforming
behavior ... arguably not bad enough to earn some of the scorn
for the implementers that Valdis and I have expressed, but
broken enough to not require further comment nonetheless.
Please note that in RFC821, the 421 is specifically stated for
ALL commands. This is important when it comes to RFC 2821
because it is now removed and implied across all commands, and
it adds ABNF for NOOP.
Yes, but there was a specific reason for doing that, it was
discussed in DRUMS, and it wasn't just editorial. Separating
the codes out makes it more clear that the "these can be used
anywhere" rule applies even to commands that are not explicitly
part of the spec.
With RFC 2821 (same text in 2821bis):
18.104.22.168 NOOP (NOOP)
This command does not affect any parameters or
commands. It specifies no action other than that the
receiver send an OK reply.
And that is still, IMO, perfectly clear, regardless of what is
in the argument string.
If someone were returning "5yz syntax error in parameters", we
could be having a much more interesting discussion here. But
returning 421 for a perceived syntax error is a clear violation
of both 2821 and 821, IMO... so clear that it doesn't deserve
any additional specific discussion.
4.3.2 Command-Reply Sequences
So 421 is implied for real server critical shut down reasons
in 2821 compliant servers across the board.
For 821 compliant servers, the 421 is appropiate for an
unexpected NOOP string. No bug.
I believe that is a misreading and that this is a bug even under
821. 421 has a specific meaning in the "theory of reply codes".
The first digit indicates that it is a transient error, which an
unexpected string certainly is not (something that someone else
pointed out much earlier in this discussion). Using 421, or
4yz for any value of yz, in some other way violates the intent
of 821. Nothing in 821 says that, because a code can be
returned from a particular command, one can use that code to
report any condition one likes. That would be madness.
This will make it backward compatible and helpful to legacy
programmers of 821 base logic that might want to revisit their
code, and it will also make it very clear to future
It is useful to "legacy programmers of 821 base logic" only if
those programmers had somehow reached the conclusion that the
inclusion of 421 as an explicit possible reply code to NOOP
justified using it to report a syntax error rather than a
pending shutdown. I think that reading would be bizarre, so
bizarre that I would consider metaphors that question the
programmer's basic competence or state of mind to be entirely
Just my opinion, of course.