Exim retry rules

Edit the /etc/exim.conf

32.8 Retry rule examples

Here are some example retry rules:

alice@wonderland.fict.example quota_5d F,7d,3h
wonderland.fict.example quota_5d
wonderland.fict.example * F,1h,15m; G,2d,1h,2;
lookingglass.fict.example * F,24h,30m;
* refused_A F,2h,20m;
* * F,2h,15m; G,16h,1h,1.5; F,5d,8h

The first rule sets up special handling for mail to alice@wonderland.fict.example when there is an over-quota error and the mailbox has not been read for at least 5 days. Retries continue every three hours for 7 days. The second rule handles over-quota errors for all other local parts at wonderland.fict.example; the absence of a local part has the same effect as supplying “*@”. As no retry algorithms are supplied, messages that fail are bounced immediately if the mailbox has not been read for at least 5 days.

The third rule handles all other errors at wonderland.fict.example; retries happen every 15 minutes for an hour, then with geometrically increasing intervals until two days have passed since a delivery first failed. After the first hour there is a delay of one hour, then two hours, then four hours, and so on (this is a rather extreme example).

The fourth rule controls retries for the domain lookingglass.fict.example. They happen every 30 minutes for 24 hours only. The remaining two rules handle all other domains, with special action for connection refusal from hosts that were not obtained from an MX record.

The final rule in a retry configuration should always have asterisks in the first two fields so as to provide a general catch-all for any addresses that do not have their own special handling. This example tries every 15 minutes for 2 hours, then with intervals starting at one hour and increasing by a factor of 1.5 up to 16 hours, then every 8 hours up to 5 days.
32.9 Timeout of retry data

Exim timestamps the data that it writes to its retry hints database. When it consults the data during a delivery it ignores any that is older than the value set in retry_data_expire (default 7 days). If, for example, a host hasn’t been tried for 7 days, Exim will try to deliver to it immediately a message arrives, and if that fails, it will calculate a retry time as if it were failing for the first time.

This improves the behaviour for messages routed to rarely-used hosts such as MX backups. If such a host was down at one time, and happens to be down again when Exim tries a month later, using the old retry data would imply that it had been down all the time, which is not a justified assumption.

If a host really is permanently dead, this behaviour causes a burst of retries every now and again, but only if messages routed to it are rare. If there is a message at least once every 7 days the retry data never expires.

This was taken from http://www.exim.org/exim-html-current/doc/html/spec_html/ch32.html



Popular posts from this blog

Python: thread.error: can't start new thread

Windows 2003 W2k3 Getting Current MTU Size