On 27 May 2010, at 18:08, Brent Jones wrote:
> On Tue, May 25, 2010 at 6:37 PM, Simon Johnstone
> <simon@???> wrote:
>> <snipped>
>> Is this expected behaviour and/or am I missing something obvious? I imagined a successful delivery would *always* remove the retry hint (in this case, perhaps not even bothering to create one in the first place, since I suspect the delivery process adding the entry was the same to deliver the message moments later, when it tried the second MX).
>
> I see that behavior as well, especially with Postini's greylisting
> (they will accept one recipient, but 400 defer another recipient to
> the same domain). Exim will abort the entire message, enter an entry
> into the retry database, and not retry any recipient to that domain
> until the entry expires.
I don't think this is the same behaviour - my problem seems to be that successful delivery to a non-primary MX does not clear the retry hint for that address.
What you're describing sounds peculiar for two reasons:
* a 4xx response for a single RCPT doesn't normally abort delivery if other recipients were accepted
* according to docs[1] when a recipient is deferred, retry lookups are keyed on the entire failing address, not just the domain
Do you have some non-standard config that may be causing this?
> Sometimes, I wish you could disable Exim's retry database and run it
> as a dumb server almost, but the benefits outweigh disabling it in
> most cases still.
There's a lot of power in the heuristics developed in Exim over the years to cope with all kinds of brokenness in an admirable fashion - my only gripe is that it's sometimes hard to understand *why* a particular behaviour exists, and the impact of changing it.
Simon.
[1] -
http://www.exim.org/exim-html-current/doc/html/spec_html/ch32.html#SECID159
