Re: [Exim] Long time down MTAs

Página Principal
Apagar esta mensagem
Responder a esta mensagem
Autor: Philip Hazel
Data:  
Para: Dr.Rich Artym
CC: exim-users
Assunto: Re: [Exim] Long time down MTAs
On Fri, 13 Aug 1999, Dr.Rich Artym wrote:

> 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. Even then, it will do a retry if the
host's retry time has past.

> Exim currently operates with
> an implicit (non-existing) parameter of
>
>     reject_incoming_on_longterm_delivery_failure = true

>
> while Martin Stewart's secondary MX problem really requires
> running the MTA with
>
>     reject_incoming_on_longterm_delivery_failure = false


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

> because I have this odd feeling that
> each mail item should compete for delivery on its own merits and
> not be affected by precedent,


There I beg to differ.

(1) If a delivery failed 5 minutes ago, I see no point in trying a new
message that has just arrived for the same host. They might as well all
wait till the next retry time (and maybe they'll go down the same SMTP
connection).

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

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

Philip

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