Cisco Support Community
Step-by-Step Configuration and Troubleshooting Best Practices for the NGFW, NGIPS and AMP Technologies A Visual Guide to the Cisco Firepower Threat Defense (FTD)

ASA 8.4x ESMTP Inspection bug CSCtr92976?

We have several customers running ASA 8.4x code and all seem to be plagued with the ESMTP inspection bug CSCtr92976.

I have tested this in the lab with an ASA 5505 running 8.4(1), 8.4(2) and 8.4(4)1 & 8.4(4)3 and the behaviour is always the same.  I have an Exchange 2007 server and I can see in the logs the following messages:

2012-08-10T13:04:37.331Z,EXCHANGE\Default EXCHANGE,08CF3610468A42D7,3,,,<,XXXX XXXXXXXXXXXXXXX,

2012-08-10T13:04:42.345Z,EXCHANGE\Default EXCHANGE,08CF3610468A42D7,4,,,>,500 5.3.3 Unrecognized command,

2012-08-10T13:05:20.506Z,EXCHANGE\Default EXCHANGE,08CF3610468A42D7,5,,,<,XXX,

This is with the default ESMTP inspection enabled.  I have also created a custom ESMTP inspection policy that does nothing but log and the behaviour is still the same.  Sometimes traffic will pass but most of the time it won't.  The workaround is to just disable the ESMTP inspection but I don't like the idea of this.

Any idea when this will be fixed or if there is some other magic workaround?


Everyone's tags (5)
VIP Purple

ASA 8.4x ESMTP Inspection bug CSCtr92976?

Will it ever be? The ESMTP-inspection is somehow the successor of the "Mailguard". And that was the worst function for nearly every mail-administrator in the past with PIX firewalls on the network ...

It got better with the ESMTP-inspection, but I assume the troble will never end. I typically disable it. The mailserver is protected by the mail-relay in the DMZ and the mail-relay has to protect himself.

Don't stop after you've improved your network! Improve the world by lending money to the working poor:

ASA 8.4x ESMTP Inspection bug CSCtr92976?

It quite blatantly just doesn't work.  I am reluctant to downgrade to 8.2 or earlier because of the NAT issues I will inevitably hit.  I'll try 8.3 on the lab 5505 and see how this behaves - I suspect it will be the same.

How can Cisco get away with not fixing this if its been around since PIX days?


CreatePlease to create content