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: > http://tools.ietf.org/html/draft-atkinson-callerid-00 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
