Queued for Delivery - 2 hour delay - Why?

[macklinmc]

Occasionally we see emails going out to various domains that sit in the delivery queue for hours. The mail_logs show only "queued for delivery", smtp_debug shows no attempt to deliver and the system log doesn't show any DNS errors. 

Where else should I be looking to find out why an email sat in a queue for several hours?

[Enrico Werner]

Hi Macklin,

what you can do is to check the status of the destination host, which most likely will be unreachable in these cases. On the command line try the following commands:

tophosts (Sort by active recipients, Hosts marked with '*' were down as of the last delivery attempt)

hoststatus

If you want to test connectivity to any destination host try the SMTPPING tool on the command line.

CLI: diagnostic - network - smtpping

Here is more details about it:

http://tinyurl.com/yl45po4

If you want to schedule messages for delivery run the folllowing on the command line:

delivernow

That should help.

Best regards,

Enrico

[macklinmc]

Thanks for the reply. Those commands will help a lot during a problem. We tend to be questioned after the fact. A user trouble report shows an email delayed for 2 hours and there is no current problem to be found. No log evidence to show why the Ironport decided not to deliver the email. There seems to be a dark spot in Ironport logging around DNS name resolution and connection events.

[Enrico Werner]

If DNS does not work it will be reflected in the text mail logs. The appliance is very much depended on a proper DNS configuration. Without DNS no mail flows. Connection events can be also found in the text mail log file. Simply grep for the DCID (Delivery Connection ID). Most handy is to download the text mail log file to a local PC if you need to run complex grep syntaxes. Otherwise simply run:

grep DCID mail_logs

[macklinmc]

Thanks for the suggestion. Log analysis of mail logs shows no DCID for the given MID until delivery is done. The last log entry on the MID is "queued for delivery". 1 hour later, according to local policy, a delivery notification is sent back to sender, for which a new MID and DCID are created. After about 2 hours, the DCID for actual delivery is created. There are no log entries related to the MID or a new DCID to indicatate why there was no attempt to deliver for the 2 hours. No DNS errors, no connection issues, nothing in the logs. System logs, mail logs, smtp debug, error_logs, etc. searched them all, found nothing. Log level is information. Anyone using log level debug? Trace comes with a warning about log size and wouldn't be suitable for long term use. This is an intermittent issue for us. Messages get "queued for delivery" and just sit. The system may have been busy at that point but there were no memory, cpu or disk alerts. Anyone understand the Status Log variables. DSTINMEM looks normal compared to other times, WorkQ is zero, ActvRcp is 102 which is normal. System is Model C670, os 7.1.2-020.  I'm stumped.

[Enrico Werner]

There has to be an initial DCID for the first delivery attempt. If there is none, then the destination server is not reachable. This indeed would not be shown in the mail logs unfortunately. There is an existing feature request to log connection attempts if a host is unreachable. Basis is the bounce profile for unreachable hosts, which can be configured on the command line only. These are the two standard values:

Please enter the initial number of seconds to wait before retrying a host that is unreachable.

[60]>

Please enter the maximum number of seconds to wait before retrying a host that is unreachable.

[3600]>

Again, if a host is unreachable right from the beginning it would not be logged in the mail logs when the appliance attempts to connect. So the question is what hoststatus showed? I would assume the destination host was marked as down.

[frank24]

Hello macklinmc,
did you find a solution for this issue?
Or did you switch to a different mail gateway manufacturer?

Greetings
Frank
*frustrated*