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