Delivery Failure Notice and Retry Frequency

For any email system, the administrators are most concern about the safe delivery of emails. Otherwise, their job will not be safe. 

In Sun Java System Messaging Server, there are 2 channel keywords to pay attention to: "notices" and "backoff".

Notices refers to the Delivery Failure Notice:

Undeliverable messages are held in a given channel queue for specified amount of time before being returned to sender. In addition, a series of status/warning messages can be returned to the sender while Messaging Server attempts delivery. The amount of time and intervals between messages can be specified with the notices, nonurgentnotices, normalnotices, or urgentnotices keywords.

Backoff refers to retry frequency for undeliverable messages:

By default, the frequency of delivery retries for messages that have had delivery failures depends on the message’s priority. 

2 more things to note:

1. The notices unit is in days; while the backoff unit is in minutes

2. An email can be further classified as non-urgent, normal, urgent. Thus, you'll have nonurgentnotices, normalnotices, urgentnotices and nonurgentbackoff, normalbackoff, urgentbackoff.

Let's see an example:

defaults logging notices 1 2 4 7 copywarnpost copysendpost postheadonly noswitch channel immnonurgent maxjobs 7 defaulthost openmail.sg openmail.sg

• The above configuration for notices is declared in the defaults channel, which means this is the default system-wide setting. 
• Non-delivery notification will be sent to the originator every 1 day, 2 days, and 4 days. At the 7th day, the message will be returned to the originator and removed from the queue.
  

ims-ms defragment subdirs 20 notices 1 7 14 21 28 backoff "pt5m" "pt10m" "pt30m" "pt1h" "pt2h" "pt4h" maxjobs 2 pool IMS_POOL fileinto $U+$S@$D destinationspamfilter1optin spam

• The above configuration for backoff is declared in the ims-ms channel, which means this will affect the in-coming emails to our users' mailboxes. 
  
• Retry interval is set at 5 mins, then 10 mins, then 30 mins, then 1 hour, then 2 hours. At the 4th hour, the message will be returned to the originator with a delivery failure notification. 

The most common query I have from customers is: 

What happens when the limit is reached? 

That is what their bosses want to know, so they need to know so as to preempt. The answer is simple: the original message will be bounced back to the originator/sender. There is no such thing as silence removal of messages, so no worries. Life is good!

By the way, the configuration for the above is to be modified in imta.cnf.