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?
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.
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:
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.
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.
Please enter the maximum number of seconds to wait before retrying a host that is unreachable.
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.
Login to the FXOS chassis manager.
Direct your browser to https://hostname/, and log-in using the user-name and password.
Go to Help > About and check the current version:
Check the current version availa...
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...