Message Queueing
November 29th, 2018Generally emails are directly delivered to the destination server. However, if the delivery attempt to the destination server is returning a temporary failure, all email sent to known valid recipients are queued locally on the filtering servers for delivery retry. Emails which have been permanently rejected by the destination server with a 5xx error code, will NOT be queued and are rejected by the systems. If the destination mailserver acts as catch-all for the domain, no recipients will be cached and therefore email will only be queued if the valid recipients have been explicitly set as Local Recipient in the nettigritty’s Antispam Cloud control panel. In case a recipient is not cached as valid, the message will be temporarily rejected and queued at the sender instead of on the filtering server (unless Local Recipients is enabled).
Queue Access
You can access the email queue from the webinterface, from which you can also manually retry delivery of a queued message.
Automatic Retry Schedule
Messages queued for known valid recipients because of temporary problems with the destination route (for example network problems) are automatically retried for delivery at the following approximate intervals:
When a message is frozen, (when a message can neither be delivered to its recipients nor returned to its sender) no more automatic delivery attempts are made. A super administrator can “thaw” ( force retry) such messages when the problem has been corrected.
nettigritty’s Antispam Cloud caches valid recipients up to 4 days. When such entry has expired, nettigritty’s Antispam Cloud will not queue email for such recipients and instead temporarily reject the message so it’s queued on the sending server. The sending server in such case will automaticallty retry delivery. When using the “Local Recipients” feature, no caching is involved and nettigritty’s Antispam Cloud continues to accept and queue the emails for all specified recipients.
Messages Queued
The SMTP RFC 5321 specifies a sending server must queue messages which cannot be directly delivered because of a temporary failure at the receiving end. Therefore in case of temporary issues with the email infrastructure, emails will not be bounced immediately but are instead queued on the sending server(s) and automatically retried for delivery. In case of downtime of the destination mailserver, messages are only accepted for delivery by the filtercluster if the recipient is known to be valid. Valid destination recipients are cached up to 96 hours.
When a destination server cannot be reached for 4 days, all messages will be bounced after 4 days and no new email will be accepted/queued until the destination server is back online. This 4 day period is conform the SMTP RFC. The reason it’s not longer than 4 days, is because it’s important for the sender to be aware that delivery of their message has been failing for 4 days so they can try and contact the recipient in another way.
