On 2007-11-30 00:09:57 -0500, Hector Santos wrote:
Ok, I searched: SMTP proxy "421 5.5.2"
Very interesting! This seems this is an issue with the Microsoft
Internet Security and Acceleration (ISA) server. MS has this KB
description and resolution for it:
http://support.microsoft.com/kb/312213
It was definitely following RFC 821!! From the article:
I think there is a lesson to learn here. In RFC 821 the syntax of the
NOOP command was:
NOOP <CRLF>
No optional parameter or even trailing spaces allowed. A server
conforming to RFC 821 is completely correct in rejecting a NOOP command
with a parameter (a 421 return code is of course quite bizarre here.
IMHO a 501 code would be most appropriate).
In RFC 2821 an optional parameter was added:
Syntax:
"NOOP" [ SP String ] CRLF
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.
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. 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?)
hp
--
_ | Peter J. Holzer | It took a genius to create [TeX],
|_|_) | Sysadmin WSR | and it takes a genius to maintain it.
| | | hjp(_at_)hjp(_dot_)at | That's not engineering, that's art.
__/ | http://www.hjp.at/ | -- David Kastrup in comp.text.tex
signature.asc
Description: Digital signature