Re: [exim] Exim has a bad queue handling?

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.