Re: [exim] Exim 4.61 retrying too often?

Pàgina inicial
Delete this message
Reply to this message
Autor: Philip Hazel
Data:  
A: Dean Brooks
CC: exim-users
Assumpte: Re: [exim] Exim 4.61 retrying too often?
On Thu, 27 Apr 2006, Dean Brooks wrote:

> We use the -qq option on Exim to do queue runs. Is it possible that
> the -qq option checks retry times at beginning of execution so that
> multiple queue runners end up processing the same message over and
> over since maybe retry times are checked at startup of a -qq queue run?


A -qq run just goes through the queue twice. The first time it pretends
it had a temporary delivery error, and adds the message to the list of
messages waiting for certain hosts. Unless I'm mis-remembering, it
shouldn't look at delivery retry data (it would look at *routing* retry
data). I don't think it would mis-behave in the way you suspect, since
the retry data will be updated dynamically for each message in turn.

> I hate to follow up to my own message, but it appears that other
> messages that go through to AOL successfully (to 205.188.159.217 in
> this example) and end up causing the retry data for the deferred message
> to be reset.


This has always been a problematic case. There was a change in the code
for 4.61 which I have partly backed off in 4.62 (to be released next
week, with luck). Ironically, the change was specifically to avoid
retrying too often.

> However, the manual in chapter 44.2 says this about temporary errors
> that occur after end of DATA:
>
>     A temporary error response (4xx), or one of the timeouts, causes all
>     addresses to be deferred. Retry data is not created for the host, but
>     instead, a retry record for the combination of host plus message id is
>     created. The message is not added to the list of those waiting for this
>     host. This ensures that the failing message will not be sent to this host
>     again until the retry time arrives.

>
> This would indicate to me that successful deliveries to 205.188.159.217
> would not cause a redelivery attempt for the message that was deferred
> for a 421 error, but it appears to be doing exactly that.
>
> Am I missing something?


Probably not. I suspect that I've screwed up something else in this
rather over-complicated area. However, the only way to figure out what
is happening is to try a delivery with debugging turned on, to see
exactly what Exim thinks it is doing. You need to do a delivery with -Mc
rather than -M, so that it looks at the retry data. I suspect this will
be frustrating, because when you try that, it is likely to say "retry
time not reached" at first... and then the delivery might succeed after
all...

-- 
Philip Hazel            University of Cambridge Computing Service
Get the Exim 4 book:    http://www.uit.co.uk/exim-book