Re: New Issue: NOOP clarification

[Hector Santos <[e-mail]>]

Peter J. Holzer wrote:
> This is an incompatible change in the protocol, as a client conforming
> to RFC 2821 is of course perfectly correct in sending the optional
> parameter while the server conforming to RFC 821 is equally correct in
> rejecting it. 

Ok, this is just practice. :-) I am just winging it. Not proposing it 
should be added. Just food for thought.

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.

    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.

Of course, as John pointed out, it would of been better if the MS server 
had use 500 instead of 421.

But at least implementators who are aware of this do have a work around. 
  Our CBV issues the NOOP before the EHLO, so we can possibly use this 
unique response to continue the section:

   S: 220 example.com Microsoft ESMTP MAIL Service ....
   C: NOOP WCSAP v2.09 Wildcat! Sender Authentication Protocol ..
   S: 421 5.5.2 Syntax error (command line too long)
   C: EHLO mail.winserver.com

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.

> There is a way for the client to handle this problem: Send the optional
> parameter only if the server recognized EHLO (since then it claims to
> conform to 2821) and omit it otherwise. But 2821 contains no hint that
> the parameter is new and incompatible with 821, so this issue is only
> apparent if you compare the two RFCs. 

Right. For the scenario like above where the NOOP is issued before the 
EHLO, then I don't see no choice but detect this unique response and 
continue with an EHLO.   I am guessing, but if it was truly a strict 821 
system, it might issue the 500 "invalid syntax"" response.

Of course, we could also change our code to issue the NOOP after EHLO or 
HELO is determined.  If it fall backs to HELO, then we know for sure not 
to issue the NOOP string, in that case, we probably won't even issue 
NOOP at all since the main purpose for here was to allow the server to 
log it.  That is how it currently used today by CBV systems.

> RFC 2821 also introduced the
> extension mechanism, which allows adding additional parameters to
> existing commands. For some reason, this was not used for NOOP, but an
> incompatible change was made in the core protocol (which I admit I don't
> understand: What is the purpose of this parameter? Why was it added at
> all? To reflect actual usage or just because somebody thought it might
> be useful?)

I can only guess "logging" were on people's mind. Thats how we are using 
it.  However, for one CBV system I am aware off, based on their "How it 
works" documentation, they are adding a 32 bit unique hex hash number (8 
characters) for tracing and also to help detect loops (show how).

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

Caller ID for E-mail was MS's original entry into the mix of LMAP 
(domain::ip association) protocols which eventually merged with SPF to 
create SENDER-ID:

   5.2 SMTP Security Considerations

   ...

   Specifically, prior to sending any SMTP MAIL commands, an SMTP
   client SHOULD send to its server an SMTP NOOP command (see section

     The 40 case-insensitive characters of the hexadecimal encoding
     of the SHA1 hash of the entire data provided previously by the
     server in its EHLO response (that is, the entire sequence of
     characters matching the ehlo-ok-rsp production found in section
     4.1.1.1 of [rfc2821]).

   By including a pseudorandom string as part of its EHLO response, an
   SMTP server can have reasonable confidence that, upon the receipt
   of such a NOOP command, the SMTP client is in fact receiving its
   responses, and one-side TCPIP hijacking is not occurring. Note that,
   as a security consideration, the SMTP server provides no indication
   in response to the NOOP as to whether a correct hash value was
   provided.

And I would swear I seen other drafts that attempt to use NOOP for some 
"authentication" purpose as well.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com