Re: New Issue: NOOP clarification2007-12-02 11:03:05
Hector Santos wrote:
Does this make since? After the ABNF statement, add a note: Syntax: "NOOP" [ SP String ] CRLF Note: If the SMTP client is required to fall back to a HELO because it has connected to a legacy SMTP server following RFC 821 (STD 10) specifications, then all follow up commands MUST conform to RFC 821 command syntax. e.g., the client MUST not send a string with the NOOP command.
No general discussion necessary at this point, you can trim the note: | Note: If the SMTP client used the HELO command as explained | in section 3.1, then it MUST NOT send a string with NOOP. We could also twist it: "If and only if" ... "then the server MAY reject a NOOP command with a string as RFC 821 syntax error". The consequence "better do not try this after HELO" is obvious, but a MAY still allows for whatever caused the introduction of this oddity in 2821.
If the client issued a "NOOP string" command before the EHLO, it is possible to received a negative response 421 or 500 from a legacy SMTP server. In this case, the client MAY use this negative response to proceed with a HELO fall back command.
In the twisted KISS style that could be: | A server supporting only RFC 821 syntax MAY treat a NOOP | command with a string as syntax error (500). We can't use a "legacy" qualifier, it's not defined in the draft. As John explained 421 is unrelated to the problem at hand, it is always allowed when a server wants to get rid of a(ll) client(s).
Of course, as John pointed out, it would of been better if the MS server had use 500 instead of 421.
Yes, better don't mention 421 here, 2821bis is the spec., it's not some kind of Exchange or Sendmail manual.
Of course, I don't think this is material for the specs. But at least we have a unofficial work around available to avoid mail delivery issues.
Don't send spam with NOOP, nobody is going to read it, and MS even rejects it, well done... <gd&r>
I can only guess "logging" were on people's mind. Thats how we are using it.
NOOP as User-Agent emulation ? Apparently that doesn't fly, maybe that's a good thing, servers behaving differently depending on the "client identification" are a nuisance in other protocols.
Now that I think about it, I seem to recall Microsoft's Caller-ID proposal taking NOOP to another level:
Omigod, "enhanced NOOP", that certainly fits with "XML over DNS".
Caller ID for E-mail was MS's original entry into the mix of LMAP
It was anything but not an "L" in LMAP, compare the original LMAP draft as explained in <http://en.wikipedia.org/wiki/MARID>. This blatant case of [censored] is now Internet history, RFC 4405 has no "enhanced NOOP" (also has no "embraced" or "extended" NOOP). Frank