How Exim determines the retry time for local deliveries

October 1, 2007

The Exim documentation is a little silent on how Exim determines the retry time for local deliveries. Since I spent today looking into this, I might as well write up what I've learned.

Exim's retry rules are based on matching patterns against 'the failing host or address' (as the documentation puts it); call this the retry key. For local deliveries, it turns out that the retry key is the full address (including any local part prefixes or suffixes) that is handed to the transport by a router.

For routers that directly invokes an appendfile-based transport (such as a typical local delivery router and transport), this is just the email address involved, and can be matched with all of the usual retry rule patterns. This does mean that it can get confused with regular SMTP host retry patterns, unless you first rewrite addresses to a unique form and then do local delivery based on that unique form. Fortunately we are already doing this for other reasons.

For redirect-based routers that directly generate general file or pipe destinations (such as one that processes .forwards), the address that the transport sees has a domain of '|....' or '/...' and no particular local part; I believe that the only way to match these is with regular expression patterns. To save people the effort, the patterns I have tested are:

^\N\@\|.$\N for pipe destinations
^\N\@/.$\N for file destinations

(You don't need to worry about pipe destination retries unless you set timeout_defer on the relevant transport. We do set it because we've seen pipe-based deliveries get hung up due to things like full disks and we don't want to bounce email in this situation, plus it means we can lower the pipe delivery timeout from an hour.)

Written on 01 October 2007.
« Understanding Exim's weird way of doing retries
A gotcha with 'bidirectional' pipes to commands »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Mon Oct 1 21:39:07 2007
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.