I had the same problem a few months ago where SMTP messages would get stuck in remote queues for server-to-server messages we’re stuck. We resolved it by disabling fixup on the Cisco Firewall in between our primary and standby (using Exchange SCR) data centers which is detailed article by Panagiotis Malakoudis.
A CISCO firewall feature that is widely used is fixup (aka MailGuard aka Inspection). Fixup is basically a protocol filter and it was designed to intercept the traffic that was going to DNS or SMTP (or some other protocol) and apply some basic policies. On the newer versions of the PIX OS, on CISCO ASA and also the Cisco IOS Firewall in Cisco IOS, fixup is replaced by inspect.
What it does
When fixup is enabled on the SMTP protocol (using the fixup protocol smtp 25 setting) the policy that is applied basically restricts the range of commands that are accepted and forwarded to the destination server. This basically means that it accepts only the basic commands from the original SMTP RFC (RFC821). An example would be using HELO instead of EHLO (since EHLO is an ESMTP verb). What actually happens is that any command that violates the policy (like EHLO) is forwarded to the destination server but is first replaced with asterisks. That means that it is not actually blocked but rather rendered useless since the destination mail server will response with 500 Command unknown.
Another change is that it changes the SMTP banner so when you try to connect to a fixup’ed mail server, instead of the normal banner you see a one that has no information. Here is an example:
220 mail2.nwtraders.msft Microsoft ESMTP Mail Service
Specifically, as of version 5.1 and higher, all original characters are replaced with asterists except character 2 and 0 (thus mail2 it replaced with ****2). Earlier versions convert all characters to asterisks. At the time of writing, the latest Cisco PIX Firewall Software version was 8.0.
Why is this a problem
There are two primary issues here.
a) Message limits. Most servers have the option to have a configurable maximum size limit for incoming messages. Sending mail servers are made aware of this option by looking at 250-SIZE option which is inside an EHLO response. If the sending mail server wants to send a 12MB email but the size option has a 10MB limit, then the sending mail server will not even bother to send the message but will rather send a NDR back to the sender with an explanation. This means that we just saved our incoming internet connection 12MB. If fixup is enabled, EHLO is disabled thus the sending mail server cannot see if there is a limit. This will result in the entire 12MB email traveling to our mail server just to be later on rejected by the next-hop exchange server.
b) Message Tracking. Another interesting side-effect of the use of fixup is that it causes many problems in the Exchange message tracking logs. If the fixup is between two exchange servers, the fact that the SMTP banner is altered causes some parsing issues on the message tracking center and errors appear. Some customers report the following error:
“The object *************” in the message tracking logs can’t be found in the directory. The object may have been deleted. The tracking history may be incorrect.”
What can I do
a) Disable fixup on the Cisco device
b) Update your CISCO software/hardware to a version that supports the inspect feature. The inspect feature can still filter the connection but keep ESMTP enabled. This is due to the fact that the inspect command supports parameter inspection so what actually happens is that it also checks the result from the EHLO command.
Read the complete article @> The Greek Exchange Blog : Cisco FixUp and SMTP