PDF(261.2 KB) View with Adobe Reader on a variety of devices
ePub(264.6 KB) View in various apps on iPhone, iPad, Android, Sony Reader, or Windows Phone
Mobi (Kindle)(225.8 KB) View on Kindle device or Kindle app on multiple devices
Updated:August 14, 2020
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 the actions that can be taken for troubleshooting emails that are queued for delivery aka held on an Email Security Appliance (ESA) and pending to be delivered.
CLI access to your ESA
For Cloud Email Security (CES) customers, more info on CLI access can be found here.
GUI access to your ESA
What does it mean?
When troubleshooting issues concerning email delivery, you may see in the Message Tracking or mail logs that the last state of a message shows queued for delivery. This means that the message has been processed by the ESA, but that for some reason the ESA is unable to complete delivery of the message to the next-hop MTA. This could be for a variety of reasons, but commonly because the ESA is unable to reach the destination host and/or the messages are being throttled or rejected by the next-hop MTA.
Review and Troubleshoot
The steps below will go over the process for taking a closer look at messages queued for delivery and troubleshooting SMTP connectivity.
Step 1 - Verify the Number of Messages Pending Delivery
From the CLI, you can utilize the tophosts command sorted by Active Recipients to review items sitting in the delivery queue. Active Recipients will signify the number of messages held waiting to be delivered.
esa.lab.local> tophosts active_rcpts
Status as of: Thu Aug 13 14:29:42 2020 EDT Hosts marked with '*' were down as of the last delivery attempt.
Active Conn. Deliv. Soft Hard # Recipient Host Recip. Out Recip. Bounced Bounced
From the GUI, you can navigate to Monitor > Delivery Status.
Step 2 - Verify the Host Status of a Destination Domain
From the CLI, you can utilize the hoststatus command combined with the domain in question to review the Host up/down state. More information on the output can be found: here.
esa.lab.local> hoststatus gmail.com
Host mail status for: 'gmail.com' Status as of: Thu Aug 13 14:37:17 2020 EDT Host up/down: up
Counters: Queue Soft Bounced Events 0 Completion Completed Recipients 336 Hard Bounced Recipients 0 DNS Hard Bounces 0 5XX Hard Bounces 0 Filter Hard Bounces 0 Expired Hard Bounces 0 Other Hard Bounces 0 Delivered Recipients 336 Deleted Recipients 0
Gauges: Queue Active Recipients 0 Unattempted Recipients 0 Attempted Recipients 0 Connections Current Outbound Connections 0 Pending Outbound Connections 0
From the GUI, this can also be seen under Monitor > Delivery Status.
Some examples of the Host up/down status and what it may mean (not all-inclusive):
up - Reachable and actively accepting messages
down - Positively down (e.g. connection refused or no route to host) or the SMTP conversation is timing out
unknown -Unable to connect (e.g. delivery routed through an incorrect interface or IP address of the interface is not properly NAT/routed through the firewall)
Step 3 - Testing SMTP Connectivity
If the host is unreachable, we can first check for the DNS MX records using dig and then test connectivity using telnet.
esa.lab.local> dig mx gmail.com
;; QUESTION SECTION: ;gmail.com. IN MX
;; ANSWER SECTION: gmail.com. 1784 IN MX 40 alt4.gmail-smtp-in.l.google.com. gmail.com. 1784 IN MX 30 alt3.gmail-smtp-in.l.google.com. gmail.com. 1784 IN MX 10 alt1.gmail-smtp-in.l.google.com. gmail.com. 1784 IN MX 5 gmail-smtp-in.l.google.com. gmail.com. 1784 IN MX 20 alt2.gmail-smtp-in.l.google.com.
Trying 220.127.116.11... Connectedto cb-in-f26.1e100.net. Escape character is '^]'. 220 mx.google.com ESMTP d21si4412123pll.407 - gsmtp
If the telnet returns Connected and a 220 banner then you can retry delivery using the delivernow all command, or from the GUI you can navigate to Monitor > Delivery Status and click Retry All Delivery.
If the connectivity tests return a rejection then additional troubleshooting may be required. You will want to review the mail logs and/or Message Tracking to see if reasons for possible rejections are shown.
Additional Troubleshooting Methods
SMTPPING can be used for sending a test message. For more info, click here.
Packet captures will allow you to review the SMTP conversation, along with confirming if any errors are being seen (e.g. TLS). For more info, click here. CES customers will need to contact Cisco TAC for assistance with running any captures.
Domain Debug Logs will also show the entireity of the SMTP conversation and are extremely useful if needing to see how messages are being delivered from the ESA. For more info, click here.