ietf-smtp
[Top] [All Lists]

Re: New Issue: NOOP clarification

2007-12-09 08:03:17

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/

<Prev in Thread] Current Thread [Next in Thread>