On 24/10/2006 11:21, Philip Hazel wrote:
> The "obvious" solution to this is to include the sender address in the 
> retry key. However, this would of course increase the number of retries 
> in the case of a genuine (non-greylisting) 4xx response when there are
> many messages from different senders for the same recipient. A queue run 
> would then try one message from each sender instead of just one message.

You already handle message errors slightly differently; perhaps you 
could add an option for this situation to be treated as a message error 
not a recipient error? Alternatively, an option not to update the retry 
time if one is already set for the recipient?

> Is the gain worth the pain?

I think that perhaps Something Should Be Done, yes, because currently 
you could end up with the retry time being pushed back and back; this is 
really quite likely to happen when a remote site initially implements 
greylisting and every message gets a 4xx response until their database 
fills up with host,sender,recipient triples for regular traffic, and if 
the extra delay grows past their timeout - 4 hours? - the whole process 
starts all over again. More practically, it's clear from other people's 
comments that this is a real issue for them.

If a queue run always processes messages oldest-first, you can perhaps 
just not update the retry time if one is already set for the recipient, 
because the oldest messages for a recipient are more likely to get 
through, then when you arrive at one that still won't, you perhaps can 
get away with not processing any other more recent ones.

> If so, should it be optional? If so, which 
> should be the default?

You've probably identified my favourite, which is probably the least 
effort to implement, and I'd make it the default; at worst it causes 
retries to happen one retry time too early, and at best it keeps queues 
down and mail flowing to people who use greylisting.

Cheers,

John.

-- 
## 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/

Reply via email to