Re: [Exim] Long time down MTAs

Philip writes:

> > This coupling of outgoing failure to incoming acceptance should be
> > under the control of the administrator.
>
> Not quite sure what you are getting at there, Rich. Exim doesn't reject
> messages based on any outgoing failures. It's only when it comes to try
> to deliver a message (to a specific recipient) that it notices a host
> has been down for a long time.

Oh dear, I am guilty of taking the first post of the thread on face
value, and assuming that there was now a new-fangled semantic that
rejected new incoming items on the basis of delivery failure for old
items to the same destination. This made me unhappy. :-) I'm glad
to hear that this was a figment of my imagination.

> I can't really find a way of turning that round into how Exim actually
> works! Sorry. Maybe it's too late on a Friday afternoon...

Good point. I must remember not to post on a Friday afternoon myself. :-)

> (2) If a host has been dead for a week, I see no point in trying to
> deliver a new message for another four days. I can see a problem related
> to when you last tested the host if the current attempt fails, and I'm
> going to think about that, but if you've kept on trying regularly and it
> keeps on failing, I think you should give up.

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 have felt for a while now that we have needed a
> > little more parametrization on the operation of delivery deferral,
>
> I can't disagree with that, having implemented an MTA with half a
> zillion options... :-) There is, for example, the delay_after_cutoff
> option in the smtp transport, which relates to this.

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. :-)]

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.
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.


Rich Artym
rich@???