PDF(7.8 KB) View with Adobe Reader on a variety of devices
Updated:October 10, 2014
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This document describes why you see "XXXXXXXA" in mailserver communication and TLS failures associated with the Cisco Email Security Appliance (ESA).
Why do you see XXXXXXXA after EHLO and "500 #5.5.1 command not recognized" after STARTTLS?
TLS fails for inbound or outbound messages.
After the EHLO command, the ESA responds to an external mailserver with:
250-8BITMIME\ 250-SIZE 14680064 250 XXXXXXXA
After command "STARTTLS" in the SMTP conversation, the ESA responds to an external mailserver with:
500 #5.5.1 command not recognized
Internal tests for STARTTLS are successful. That means when bypassing the firewall, STARTTLS works fine, such as STARTTLS connections with the local mail servers or telnet injection tests.
The problem is typically seen when you use a Cisco Pix or Cisco ASA firewall when SMTP Packet Inspection (SMTP and ESMTP Inspection, SMTP Fixup Protocol) and the STARTTLS command is not allowed in the firewall.
Cisco PIX firewall versions earlier than 7.2(3) that use the various ESMTP security protocols incorrectly terminate connections because of a bug in interpreting duplicate headers. The ESMTP security protocols include "fixup," "ESMTP inspect," and others.
Turn off all ESMTP security features in PIX, or upgrade PIX to 7.2(3) or later, or both. Since this problem occurs with remote email destinations that run PIX, it might not be practical to turn this off or recommend turning it off. If you have the opportunity to make a recommendation, a firewall upgrade should solve this issue.
Some, not all, of the issues are due to the inclusion of message headers within other headers, notably the signature headers for Domain Keys and Domain Keys Identified Mail. While there are still other circumstances under which PIX incorrectly terminates an SMTP session and causes delivery failures, DK and DKIM signing is one known cause. Temporarily disabling DK or DKIM might solve this issue for the time being, but the best solution is for all PIX users to upgrade or disable these security features.
Cisco recommends that all customers continue to sign messages with DKIM and to consider using this feature if not already doing so.
For SMTP and ESMTP Inspection (PIX/ASA 7.x and above) please see: