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
