Re: [exim] Retry problems.

Pàgina inicial
Delete this message
Reply to this message
Autor: Philip Hazel
Data:  
A: David Woodhouse
CC: exim-users
Assumpte: Re: [exim] Retry problems.
On Thu, 8 Jun 2006, David Woodhouse wrote:

> On Thu, 2006-06-08 at 09:27 +0100, Philip Hazel wrote:
> > My mind is currently focussed on non-Exim things (new PCRE release) but
> > I've taken a very quick look at your debug output. *My* guess is that
> > once the "expired" bit has got set, it can't get unset, so changing the
> > retry rules such that it should no longer be expired won't work. Maybe
> > "expired" shouldn't be a remembered bit, but should be re-calculated
> > each time. I've made a note to think about this, but it won't be for
> > some time.
>
> Maybe -- although I believe I did change the retry rules _before_ the
> original expiry time was reached, because we _knew_ the primary MX was
> going to be absent for a few more days. So the 'expired' bit shouldn't
> have been set, should it? But then we lost all the mail anyway :)
>
> There exists a strong possibility that I screwed up the format of the
> retry rules though, so maybe your above hypothesis is correct. I think I
> put the rule for this domain _after_ the '*' rule, as follows:
>
> *@*infradead.org       *           F,2h,15m; F,24h,1h; F,30d,4h
> *                      *           F,2h,15m; G,16h,1h,1.5; F,4d,8h
> cardolan.com           *           F,2h,15m; F,24h,1h; F,30d,4h


For the record and archives, just to add some further comments on this.
I have now studied the code, and I believe that your "strong
possibility" must be what in fact happened, leading to the expired bit
being set. What happens is as follows:

1. When a delivery fails, Exim calculates a retry time, and if the cutoff
time has passed, it sets the 'expired' bit in the retry record. If
the cutoff time has not passed, it clears the 'expired' bit. So I was
wrong in my assertion above.

2. When next a message is being considered for delivery, the 'expired'
bit is consulted, and may lead to bouncing etc.

So, once the expired bit has been set in the retry record, it can be
cleared if you change the retry rules, but only after a delivery has
been attempted and deferred. As far as actually running the next
delivery is concerned, the address is still 'expired', and this may
cause a bounce without a delivery attempt.

If you had put the retry rule in the right place, I think all would have
been well if you'd done it before expiry. If after, some mail would have
bounced but once a delivery had happened, it would have recovered.

To change of any of this is a major project which I don't think is
urgent enough to warrant looking at at this time. OK?

Philip

--
Philip Hazel, University of Cambridge Computing Service.