Re: [Exim] Retrying after a long period of failure: opinions…

Top Page
Delete this message
Reply to this message
Author: Tim Jackson
Date:  
To: exim-users
Subject: Re: [Exim] Retrying after a long period of failure: opinions sought
Hi Philip, on Thu, 19 Dec 2002 11:12:47 +0000 (GMT) you wrote:

<snip retry issues>

> VIEWS?


I can't claim extensive experience in this area; as the recent thread
about me trying to understand exactly what's happening retry-wise will
show, I've only just been getting my head round it (and indeed
experiencing significant queues for hosts that have been down for extended
periods).

Nevertheless, based on my experience so far, I'd say keep the current
behaviour. I agree (and have proved by my questions) that it's a bit
complicated to understand, and the spec could perhaps be slightly clearer
(that's not to underestimate the difficulty of expressing it; however,
including a few examples may help to explain), but now that the fog is
clearing, I do actually think that the current system is good. At the end
of the day, these are (potentially) complex situations, and there's no
particularly easy way of handling or explaining it.

In particular, people's needs/desires for delay_after_cutoff will vary
between hosts to such an extent that I think keeping the option is a good
thing. If you've got a quiet machine handling backup for one domain, the
primary MX(es) for which are up almost constantly,
delay_after_cutoff=false probably makes sense. But as someone else pointed
out, if you're handling a lot of mail, the overhead of repeatedly trying
long-failing hosts may be significant and undesirable.

So, FWIW, I'd say retain the current behaviour.

(Furthermore, on a practical level, quite apart from what I've discussed
above, there are probably quite a few low (or not so low)-hanging Wishlist
items that might well merit attention more than the retry system that is
fundamentally OK.)


Tim