On 27 May 2010, at 18:08, Brent Jones wrote: > On Tue, May 25, 2010 at 6:37 PM, Simon Johnstone > <[email protected]> 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 -- ## List details at http://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
