[Top] [All Lists]

Re: New Issue: NOOP clarification

2007-12-02 11:03:05

Hector Santos wrote:

Does this make since? After the ABNF statement, add a note:
       "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 <>.  

This blatant case of [censored] is now Internet history, RFC 4405
has no "enhanced NOOP" (also has no "embraced" or "extended" NOOP).


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