--On Wednesday, 28 November, 2007 17:39 -0500 Hector Santos
<hsantos(_at_)santronics(_dot_)com> wrote:
RFC 2821 (RFC 2821bis) says for the NOOP:
4.1.1.9 NOOP (NOOP)
This command does not affect any parameters or previously
entered
commands. It specifies no action other than that the
receiver send
an OK reply.
This command has no effect on the reverse-path buffer, the
forward-
path buffer, or the mail data buffer and may be issued at
any time.
If a parameter string is specified, servers SHOULD ignore
it.
Syntax:
"NOOP" [ SP String ] CRLF
I just came across a transaction where a Microsoft ESMTP
server rejected it with a 421 response.
Unless 421 was used in the sense of "service shutting down,
closing connection" (in which case the response and code are
perfectly valid -- see the introductory material to Section
4.3.2), that is what is technically known as a "bug". Less
technically, it might be described as "blatantly
non-conforming".
The two cases can presumably be distinguished by issuing another
command. If the server responds by closing the connection (or
has closed it already), the 421 was valid. If it sends any
positive or negative response other than "503 bad sequence of
commands" or another 421, I think it would indicate a bug.
Note that support for NOOP is required (Section 4.5.1).
The paragraph should include semantics that the NOOP command
itself SHOULD be ignored, not just the string SHOULD be
ignored. Maybe:
This command does not affect any parameters or previously
entered
commands. It specifies no action other than that the
receiver send
an OK reply. Server SHOULD ignore the NOOP command by
issueing a
250 response.
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.
And, of course, if the "Microsoft ESMTP server" issued the 421
because it intended to shut the connection down, then not only
is the response valid but I think we would prefer it to
"ignoring the command" by sending a 250 and suppressing that
information.
john