Running Exchange 2003 SP2, outbound e-mails go straight out to the Internet
(no smarthost, etc), but the traffic is inspected by a Cisco ASA on the way
out (inspect esmtp). A number of outgoing messages are being flagged as
having message headers with lines longer than 998 characters (per RFC 2183
spec), causing the ASA to drop the connection. The obvious answer is to
disable ESMTP inspection on the ASA and just allow the non-compliant messages
to go out. However, I like having the inspection to prevent any sort of
buffer-overflow from getting to/from Exchange.
Microsoft swears that Exchange is RFC compliant, but a Wireshark packet
capture reveals otherwise. The header causing the problem is the
x-cr-hashedpuzzle, which appears to be some sort of spam protection that
Outlook 2007 adds by default (you can disable this of course). Outlook
passes this lengthy header to Exchange, which then Exchange should parse the
long hash into multiple lines of 998 characters each. THe first line is 998
character, but then the subsequent lines at 999 characters because there is a
tab character preceeding each subsequent line. I believe this is a bug in
Exchange, because whoever wrote the function to break long headers into
multiple lines of 998 forgot that there was a tab (ASCII hex 09) added at the
beginning.
Has anyone else seen this issue or am I going crazy? I can attach the
wireshark dumps and the full hex values of any MS people are curious.