我们使用unicode亚洲字符将邮件发送到广域网另一端的邮件服务器…从运行2.3（2）的FWSM升级到运行8.2（5）的ASA5550后，立即看到包含unicode和其他文本编码为Base64。
症状非常明显…使用ASA的数据包捕获实用程序，我们在离开ASA之前和之后拦截了stream量…
access-list PCAP line 1 extended permit tcp any host 192.0.2.25 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 我从ASA下载了pcap，转到https://<fw_addr>/pcap_inside/pcap和https://<fw_addr>/pcap_outside/pcap …当我用Wireshark查看它们时>按照TCP Stream，进入ASA的stream量看起来像这样
EHLO metabike AUTH LOGIN YzFwbUlciXNlck== cZUplCVyXzRw
但是在外部接口上离开ASA的邮件看起来像这样…
EHLO metabike AUTH LOGIN YzFwbUlciXNlck== XXXXXXXXXXXX
XXXX字符是关于…我通过禁用ESMTP检查解决了问题：
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
5美元的问题…我们的旧FWSM使用SMTP修正没有问题…邮件在我们把新的ASA在线的时刻…在什么特别的不同是关于现在打破这封邮件的ASA？
注意：用户名/密码/应用程序名称已更改…不要打扰Base64解码这个文本。
该用户名的“真实”版本中是否存在UTF-8字符（解码后）？ 如果检查已经触发，我猜测有一个原因，它是挑选的具体行。
但也许不是; 检查function更像是一个混乱的猴子比IPS。 就个人而言，检查function所提供的唯一的东西是令人头疼的（通过对完全有效的stream量进行过度积极的清理）以及安全漏洞。 从快速search：
inspect skinny骨干网重新启动ASA） inspect sip CPU拒绝服务） 我的build议是不要因为需要closuresASA协议检查的方面而失去很多的睡眠; 端点服务器应用程序（或像Web应用程序防火墙这样的目标安全平台）无论如何都倾向于更好地执行协议遵从性。