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