Mail Assure Help

Message Queueing

Generally emails are delivered directly to the destination server. However, if the delivery attempt to the destination server returns a temporary failure, all email messages sent to known, valid recipients are queued locally on the filtering servers for delivery retry - see View Incoming Delivery Queue.

Emails which have been permanently rejected by the destination server with a 5xx error code, will NOT be queued and are rejected by the system - you can see these messages in the Spam Quarantine.

Automatic Retry Schedule

Messages queued for known valid recipients because of temporary problems with the destination route (e.g network problems) are automatically retried for delivery at the following approximate intervals:

  • During the first 2 hours, delivery is retried at a fixed interval of 15 minutes.
  • During the next 14 hours, delivery is retried at a variable interval, starting at 15 minutes and multiplying by 1.5 with each attempt (e.g. after 15 minutes, then 22.5 minutes, then 34 minutes, and so on).
  • From 16 hours since the initial failure, until 14 days have passed, delivery is retried at a fixed interval of every 6 hours.
  • After 14 days we generate a bounce to the sender. If the bounce cannot be delivered immediately (i.e. if the 'message could not be delivered' message (Non-Delivery Report) fails to send), it will be frozen automatically. After this time, delivery of the message will have permanently failed.

When a message is frozen (it cannot be delivered to the recipient or returned to the sender), no more automatic delivery attempts are made. An Admin user can “thaw” ( force retry) such messages when the problem has been corrected.

Mail Assure caches valid recipients up to 14 days. After this time, Mail Assure will not queue email for those recipients and instead temporarily rejects the message so it is queued on the sending server. The sending server in this case will automatically retry delivery. When using the 'Local Recipients' feature (described above), no caching is involved and Mail Assure 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 the 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 (when “Accept mail for any mailbox confirmed as valid by the destination mail server” is enabled”) up to 96 hours, per filtering server.

To make use of message continuity in Mail Assure, the recipient callouts must be disabled. To do this, ensure that in the Mailboxes Overview pages, the Mailboxes and Aliases lists are complete (do this manually, by CSV import or LDAP sync), and select Accept mail only for mailboxes listed in the "Mailboxes" tab in the Configuration tab of the Mailboxes Overview page. This will accept mail for all recipients listed in the filter, and queue this for up to 14 days, until the message can be successfully delivered to the recipient, or when a destination server cannot be reached for 14 days,all messages will be bounced after 14 days and no new email will be accepted/queued until the destination server is back online. The reason that it is not longer than 14 days, is because it is important for the sender to be aware that delivery of their message has been failing for 14 days so they can try and contact the recipient in another way.

Your own Fallback Server(s)

Please note that when you specify multiple destination routes, Mail Assure assumes you run your own fallback system. If the specified fallback server is not responding to recipient callouts, there will be no database built up of valid recipients internally. We recommend not to specify any fallback server(s) unless you've specifically designed your infrastructure to handle outages of the main destination server.

See also: