There are instances where a mail host may go down and there fore the appliance registers host as down and message tracking will show 'queued for delivery' but no actual delivery attempts done and a customer may think the ESA is unable to deliver anymore and reboots the system to restore it and it works and has a concern on health of the system
When an email has a temporary delivery failure cause the mail server host was reported as ‘down’ on the appliance, it will treat this as a soft bounce event and not a hard bounce – therefore you will not see a bounce notification reply.
Soft bounce emails means the appliance attempts a delivery, it fails to reach the mail server so the appliance marks the recipient host as ‘down’ and does not re-attempt for an hour, if it’s still down, all emails to that host will be re-attempted for 2 hours after and so on until it eventually hard bounces or the recipient host status shows as ‘up’ again on the appliance.
If the host is showing as down due to mail server unresponsive and the appliance already puts the status as down and delays all deliveries, the appliance will still not attempt any deliveries for old and new emails to that host until the next counter reset happens for the appliance to attempt a connection again
The way to see the status of recipient host is to review ‘tophosts’ in your appliance CLI (Command Line Interface), any hosts with a * marked next to it means that the appliance attempted delivery and there is no reply in the connection attempt so it is marked as down until the counter resets, after which the appliance attempts another connection, if successful it will tag the host as ‘up’ and resume all deliveries, if not it will hit another counter and will not attempt any connections until the counter resets, for new and old emails to that recipient host.
You would need to attempt a port 25 telnet test from the appliance’s delivery interface to the affected mail servers, if the connection had failed then it would be the reason why no emails are delivering to this mail server.
If successful and no delivery is made as yet, that would be due to the counter has not reset, so I would suggest in this circumstance to force deliveries use the ‘delivernow’ command on the CLI.
To initiate a telnet test for delivery, first locate the delivery interface.
C370.lab> deliveryconfig
Default interface to deliver mail: Auto
"Possible Delivery": Enabled
Default system wide maximum outbound message delivery concurrency: 10000
Default system wide TLS maximum outbound message delivery concurrency: 100
Choose the operation you want to perform:
- SETUP - Configure mail delivery.
[]>
This will show the interface that is used. When you see 'auto' this suggests that the system will choose the interface closest to the default gateway.
To initiate a telnet test
telnet <IP/hostname> 25
This will use the 'auto' interface as well.
