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: [EMAIL PROTECTED] Phone: +44 20 88008915 Mobile: +44 7986 053399 http://sabahattin-gucukoglu.com/
