We send mail with unicode asian characters to our mail server on the other side of our WAN... immediately after upgrading from a FWSM running 2.3(2) to an ASA5550 running 8.2(5), we saw failures on mail jobs that contained unicode and other text encoded as Base64.

The symptoms are pretty clear... using the ASA's packet capture utility, we snagged the traffic before and after it left the ASA...

access-list PCAP line 1 extended permit tcp any host eq 25
capture pcap_inside type raw-data access-list PCAP buffer 1500000 packet-length 9216 interface inside
capture pcap_outside type raw-data access-list PCAP buffer 1500000 packet-length 9216 interface WAN

I downloaded the pcaps from the ASA by going to https://<fw_addr>/pcap_inside/pcap and https://<fw_addr>/pcap_outside/pcap... when I looked at them with Wireshark > Follow TCP Stream, the inside traffic going into the ASA looks like this

EHLO metabike




But the same mail leaving the ASA on the outside interface looks like this...

EHLO metabike




The XXXX characters are concerning... I fixed the issue by disabling ESMTP inspection:

wan-fw1(config)# policy-map global_policy

wan-fw1(config-pmap)# class inspection_default

wan-fw1(config-pmap-c)# no inspect esmtp

wan-fw1(config-pmap-c)# end

The $5 question... our old FWSM used SMTP fixup without issues... mail went down at the exact moment that we brought the new ASAs online... what specifically is different about the ASA that it is now breaking this mail?

Note: usernames / passwords / app names were changed... don't bother trying to Base64-decode this text.


Are there UTF-8 characters in the 'real' version of that username (after decoding)? If the inspection has triggered on it, I'm guessing there's a reason that it's picked that specific line.

But maybe not; the inspection feature is more akin to the chaos monkey than an IPS. Personally, the only things the inspection features have really provided for me have been headaches (through overly aggressive sanitizing of perfectly valid traffic) and security vulnerabilities. From a quick search:

  • CVE-2011-0394 (reboot of the ASA from inspect skinny)
  • CVE-2012-2472 (CPU DoS from inspect sip)
  • CVE-2012-4660/4661/4662 (more reboots, you get the idea)

My recommendation is to not lose much sleep over needing to turn off aspects of the ASA's protocol inspection; the endpoint server applications (or a targeted security platform like a web application firewall) tend to do a much better job of enforcing protocol compliance anyway.

  • I will need to investigate whether the UTF-8 was valid... I loose sleep more from irrational conclusions (rollback to the FWSM) drawn by political operators in the company than needing to disable inspection for a technical reason... Nov 9 '12 at 10:53
  • I'm with Mike on this one. "protocol fixup" generally ignores all sorts of corner-cases in the RFCs, since (I strongly suspect) they never get people versed in each protocol to write the reqs for the fixup code. MTAs, on the other hand, are well-versed in the arcane art of SMTP, and are much better-placed to detect weirdness in the connection. Get a decent, strong MTA, keep it well-patched, turn off the fixup, and sleep soundly. Incidentally, a front-end MTA relay can often do a much better job of protecting the main mailstore behind it, if you're really worried.
    – MadHatter
    Nov 9 '12 at 10:58
  • 2
    The characters encoded in Base64 were valid, the ASA's ESMTP inspection is just flawed... permanently disabled for us... and note to self for the future. Nov 10 '12 at 16:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.