[Top] [All Lists]

Re: New Issue: NOOP clarification

2007-12-01 22:14:26

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:

      "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 Microsoft ESMTP MAIL Service ....
  C: NOOP WCSAP v2.09 Wildcat! Sender Authentication Protocol ..
  S: 421 5.5.2 Syntax error (command line too long)

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:

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 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

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


Hector Santos, CTO

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