Re: [Exim] Long time down MTAs

Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: Philip Hazel
Fecha:  
A: Dr. Rich Artym
Cc: exim-users, rich
Asunto: Re: [Exim] Long time down MTAs
On Sat, 14 Aug 1999, Dr. Rich Artym wrote:

> And I'd probably agree with you, but policy at any specific site may
> be different, possibly for good reason, which is why flexibility in
> configuration is important. I think Exim does a pretty good job in
> that area, although I am sure it can be improved.


I agree with the flexibility point, as I think is pretty obvious from
the way Exim works, but there is always room for improvement.

> Yes, there are quite a few options in Exim, but we love them. :-) It
> occurs to me that the "state space" here consists of destination-based
> retry timing versus per-item retry timing, and that in the former, one
> could use incoming items as triggers to reset the algorithm or merely
> to fire off another ad hoc attempt, and in the per-item retry system
> then one could parametrize the algorithm with a modifier based on the
> long-term delivery behaviour for the domain in question. In other words,
> it's not just one or the other -- there is an interesting parameter space
> there in between the two extremes to explore. [I'm reasonably certain
> that I'm being serious. :-)]


Oooh. This is starting to sound ever-so mathematical... once upon a time
I did a maths degre... Yes, I think I see what you are getting at.

> Strict per-item retry algorithms are of course somewhat wasteful and
> (one might say) unnecessarily "dumb", but a little further in from the
> edge of strictness they have some useful properties in promoting
> responsiveness in an environment where, for one reason or another,
> destinations that are "up" do not always respond on every connection.


Indeed. That is the sort of area in which I have promised to think.
However, not just yet, as my brain cells are fully committed to other
things just now.

> And it's *always* better to err on the side of too many attempts
> rather than to perform too few and end up returning an item to sender.


Problem is in defining "too many" and "too few".

-- 
Philip Hazel            University of Cambridge Computing Service,
ph10@???      Cambridge, England. Phone: +44 1223 334714.