Re: New Issue: NOOP clarification

["Frank Ellermann" <[e-mail]>]

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