Recently a user at a customers site was having trouble sending email. I ran a script that connected to each mail server and specified the sender and recipient to see if any would get errors. One refused to accept the email because the reverse DNS lookup on the source IP failed. So the lesson to learn here is this. If something does not work, try to figure out where it is broken and try to see exactly what is going on in that part that is broken. But wait - that's not the end of the story because the user was sending email to 27 recipients and none of the messages were being delivered.
Mr. Peabody, set the WABAC machine to February 2004. Microsoft has just published a paper "The Coordinated Spam Reduction Initiative". [more]
http://old.openspf.org/caller-id/csri.pdf
Section 11 is about Computational Puzzles For Spam Deterrence. The idea is to have the computer sending email solve a puzzle that require a lot of resources, usually CPU time, but verifying that solution is fast. The idea was to make it expensive for spammers to send out spam. I know this sounds silly now with botnets having 1000s of machines sending spam. But did you know Microsoft actually implemented this in Outlook 2003? And did you know it is still in Outlook 2007? And did you know it is still in Outlook 2010? It's called postmarking now, but it is still the same computational puzzle. This is only used when it thinks your email might look like spam.
Ok, so the way this works is that Outlook or your Exchange server generates the puzzle solution and adds it to the email headers. It uses the header "x-cr-hashedpuzzle". RFC 2821 (Simple Mail Transfer Protocol) states "The maximum total length of a text line including the <CRLF> is 1000 characters". This x-cr-hashedpuzzle is quite long, so it is broken up into several lines. The first line is 1000 characters, but the continuation lines have a <tab> inserted at the front, causing them to be 1001 characters long. If this happens to be going through an ASA with ESMTP inspection enabled, it will send out resets to close the connection because it violates the RFC.
This is why the user I was working with could not send email to a list of 27 recipients. I removed the SMTP inspection on our ASA (which I have been wanting to do anyway) to work around this.