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

On Mon, 23 Oct 2006, John Robinson wrote:

> On 23/10/2006 17:53, Patrick von der Hagen wrote:
> [...]
> > Imagine you forward messages to a server that applies greylisting. Quite
> > a normal setup here. You get a message from A at 0:00 and have to
> > forward it to recipient Z on the server applying greylisting. A
> > temporary error is received and the greylisting-daemon saves
> > (A,Z,YOUR-IP) to its database.
> > Exim sets a retry-time, e.g. 15 minutes for recipient Z.
> >
> > At 0:14 a new mail from a new sender arrives, which is to be forwarded
> > to Z. You try it immediately, the greylisting-daemon saves (B,Z,YOUR-IP)
> > and your exim updates its retry-database, to have a new retry at 0:29
>
> Ah. Yes, that would be problematical.

Having thought some more about this, I've come to the conclusion that
after a 4xx response to RCPT, it normally does make sense to use the
combination of sender+recipient as the "key" for the delay. In other
words, delay attempts to deliver from the same sender to the recipient
until the retry time arrives, but do not delay deliveries from other
senders to the same recipient.

OK, this is particulary relevant to greylisting, but in principle there
may be other situations where a 4xx response depends on the sender as
well as the recipient.

I have committed code in which this is the default, so it will be in
tonight's snapshot. I made it the default, because I think that is the
safer option (avoids messages getting "stuck", as was reported earlier
in this thread). However, in case anybody has a problem with this, I
have added an option called address_retry_include_sender to the smtp
transport. Setting this false reverts to the old behaviour, in which
retries for 4xx errors do not depend on the sender.

Philip

--
Philip Hazel, University of Cambridge Computing Service.