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 -- ## List details at http://www.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://www.exim.org/eximwiki/
