Re: [exim] Host-based retrying problem

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