On 2006-03-04 at 00:48 -0800, Christian Gregoire wrote: > Thanks a lot for the hints. I'll give it a try.
The Exim author's hint, lower the retry time, is even better for almost all circumstances. I should've thought back to why we do things as we do. For us, our front-end hosts can also redirect off-site and I needed a quick fix which wouldn't result in retrying third-party servers every minute; by nuking or ignoring the hints, the rate of retry of existing mails is held the same but new mails coming in will still try the backend server and the queued mail will deliver fine from a queue-runner once there's either no hint or the hint says that the host is up again. With proper design of lookups, lowered retry times on a per-recipient-address basis using multiple retry rules is good, so using lowered retry times wins. For us, we already had several CDBs providing different types of redirect, some on a per-domain basis and some on a per-recipient basis. It was less intrusive and easier to just nuke the hints (plus I was really busy with something else and could easily tell someone how to deploy this, which is probably why I didn't notice that there's a directive to consider old retry data stale). Nuking hints on a live platform is easier to safely deploy in an emergency, and an emergency is when you discover "oops, those backends falling over is having a bad knock-on effect there" needs dealing with. It works with no bad side-effects, so we've kept it for the sake of simplicity. Running with retry hints nuked every minute on the front-end servers for over a year now, I think. -- I am keeping international relations on a peaceable footing. You are biding your time before acting. He is coddling tyrants. -- Roger BW on topic of verb conjugation -- ## List details at http://www.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://www.exim.org/eximwiki/
