Argh! Stop this madness!
RFC 2821 introduced an incompatibility with NOOP. I'd've gone right ahead
and implemented the optional argument without a second thought, with no
intention for my client to ever use NOOP (or, indeed, RSET - even when
caching connections, there simply isn't a need because you just have to
try the next transaction to find out if link is dead). I didn't notice
the optional argument when reading both 821 and 2821, though, and nor did
anyone else using liberal and/or modern implementations of SMTP which
rigorously follow spec. Even if the server falls over, it's a rare case
indeed that it should result in session termination, and there's still a
chance your logging intentions are satisfied even when you get non-250
responses to NOOP when using arguments (not that I think they're actually
*justified*, nor that, indeed, there are many real uses for NOOP in
"Normal" operation). But this has been as good as law for the past - hang
on a sec - six years, so that it's kind of hard to justify changing things
again. Lastly, there are still uses for HELO even when a client is an
otherwise fully-capable ESMTP implementation - it mightn't want any
extensions, so it naturally won't bother to ask for them (I know, it's
unlikely but it's possible and the spec provides for it). Given that the
whole HELO fallback thing is a hack that relies on servers actually
working as intended by RFC 821 when the first command is EHLO and when
EHLO isn't supported (they don't and to this day sendmail is still using
the ESMTP keyword in the banner as indicator by default), I don't think we
should condition any aspect of the protocol on whether or not we were an
old or new client introducing ourselves - we merely do whatever is asked
of us with extended commands.
So, in summary: if we do want to add any kind of note, it should do
nothing more than state the change. Like this:
Note that [RFC821] does not provide for arguments to the NOOP command. If
a client implementation sends arguments with NOOP commands when in a
session to a server that conforms to [RFC821], it MUST expect responses
with codes other than 250, but is otherwise free to conclude that the
command has completed unless the session is terminated with the "421
<domain> Service not available, closing transmission channel" response as
described in section x.x.
(x.x being the number of a section somewhere - not got the draft to hand
just now - that describes this global response.)
Cheers,
Sabahattin
--
Sabahattin Gucukoglu <mail<at>sabahattin<dash>gucukoglu<dot>com>
Address harvesters, snag this: feedme(_at_)yamta(_dot_)org
Phone: +44 20 88008915
Mobile: +44 7986 053399
http://sabahattin-gucukoglu.com/