Guest

Cisco Email Security Appliance

How do I troubleshoot why a message was not received by the ESA?

Document ID: 118014

Updated: Jul 18, 2014

Contributed by Jackie Fleming and Enrico Werner, Cisco TAC Engineers.

   Print

Question:

How do I troubleshoot why a message was not received by the ESA?

To troubleshoot message reception, you need to know the IP addresses used for sending mail by the organization sending mail.  Usually, contacting the sender organization's mail administrator is the most accurate way to get this info. In the absence of this option, you can use some other resources:

  • SenderBase- If you enter a domain in the search box at http://www.senderbase.org, you will receive a list of known sending IPs for that domain.
  • Mail Logs - If you have successfully received mail from the domain in the past, you can look in mail logs for one of those successful deliveries. 
  • DNS -  You can look up the MX records for the domain. Most smaller organizations use the same inbound and outbound servers.  For larger or more segmented organizations, this option will not likely reveal the needed information.

Once you know the IP addresses, you will need to search the mail logs. The grep utility is a good tool for this purpose.  If you are running Windows, you can use Find in Word Pad or Notepad or download a grep utility from the Internet.  Unix and Mac OSX have grep built in and can be accessed from a shell. The grep command line would look like this (where '10.2.3.4' is the IP address you are searching for):

host> grep '10.2.3.4' file.log

If the sender's server is successfully connecting to your server, you will see a line similar to the following when you search for their IP(s):

Wed Feb  2 23:43:11 2008 Info: New SMTP ICID 6 interface Management (10.0.0.1) address 10.2.3.4 reverse dns host test.ironport.com verified no

You can then search for all the lines involving the ICID (Incoming Connection ID).  The lines you find will tell you if they sent From information, if they sent To information, and the message IDs (MID) linked with the connection.  Searching on the MID(s) will show you if the message was accepted by the system, the scan results, and whether delivery was attempted.

Another tool available for troubleshooting this is the Injection Debug Logs.  You will need the IP address of the sending server(s) first.  Once you have these, use the logconfig  commands and select this log type.  Once the log is configured and committed, you can have the user send a test message and (assuming their server connects to your ESA) the ESA will log the entire SMTP conversation.  This will allow you to see the point of breakdown in communication.

If there are still no connections and thus no messages received, the next step is to have the sending servers administrator check their logs and/or use telnet to manually test sending a message from the mail server.  This will mimic the server attempting to deliver to your ESA  and your ESA will react the same as if the sending servers application sent it.

If the test goes through, but the server application fails when it tries to send mail, this indicates delivery issues on the remote server. The remote server administrator will need to review the logs to diagnose the errors. 

One common cause of delayed or failed receiving is that the sending servers IP does not have reverse DNS configured properly causing a long delay (30+ seconds) for the ESA to provide a SMTP banner.  Some server applications will reach their configured timeout and close the session before sending mail because of the delayed banner.  The solution in this case is to extend the timeout or implement reverse DNS.  The recommended action is to implement reverse DNS for all mail servers that deliver to other Internet mail servers.  It is considered proper Internet etiquette and allows mail servers to confirm the identity of the server at a very basic level.

Updated: Jul 18, 2014
Document ID: 118014