Brent Jones wrote:
> On Tue, May 25, 2010 at 6:37 PM, Simon Johnstone
> <simon@???> wrote:
>> Hi all,
>>
>> Encountered a strange issue I was hoping someone might be able to explain. Exim 4.69/Debian (although a 4.71 source build seems to do the same).
>>
>> An email was sent on the 19th to a domain with two MXes:
>>
>> * first MX responded to 'RCPT TO' with a 4xx code (greylisting, AFAICT)
>> * second MX accepted the message
>>
>> However, a retry entry was still created:
>>
>> R:john@???:<simon@???> -44 13133 SMTP error from remote mail server after RCPT TO:<john@???>: host mx2.SOMEDOMAIN.co.uk [xx.xx.xx.xxx]: 451 Deferred: Temporary error, please
>> 19-May-2010 00:27:48 25-May-2010 22:58:40 26-May-2010 04:58:40 *
>>
>> Fast-forward to today - the retry time (4 days) has expired, which seems to be causing subsequent messages sent with the same retry key (recipient:<sender>) to bounce *immediately* if both MXes return a 4xx code (which they do, again due to the other end's greylisting).
>>
>> 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).
>>
>> Thanks,
>>
>> Simon.
>> --
>> ## 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/
>>
>
> 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.
> 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.
> But I'm still struggling to find a proper way to handle these cases.
>
>
CAVEAT: (right up front - 'coz this is NOT a panacea)
But 'works for me..' applies. Bigtime.
- set Exim's retry to NOT beat on a potential greylister with too many early
retries, but rather to make its second and subsequent attempts after not less
than five minutes.
- set retry to fail - not at 3 or 4 days, but rather at one day or less. Even 15
minutes may be appreciated by some business clients.
Seriously.
Why so?
Given the *general* speed and reliability of smtp these days, many, if not most,
folks would rather know 'Real Soon Now' that their message did not reach the
destination in a timely fashion than to wait and hope that it might do so 3 or 4
days delayed. More especially if they are unaware of the retry process and delay
entirely.
The poor souls sitting behind dodgy or over-zealous greylisters, otherwise
unreliable servers- noen of which you can 'fix' from your end - self-Identify to
their correspondents, (and no others). Those now-alerted correspondents may then
seek some other way to reach them if the situation warrants that.
...and there are not likely to be many retry hints at large, duplicated or
otherwise.
JM2CW
Bill
