On Thu, 2007-01-04 at 09:39 +0000, Philip Hazel wrote:
> On Thu, 4 Jan 2007, Kjetil Torgrim Homme wrote:
>
> > here's the scenario:
> >
> > * server sends message to A (highest MX priority), and is defered
> > due to greylisting.
> > * server now tries to send message to B (lowest MX priority) which
> > always defers.
> > * server notes that B defers in retry database
> > * some time later, it retries A, and it is successful.
> >
> > repeat this for some time. eventually you get this:
> >
> > * server sends message to A, and is deferred due to greylisting.
> > * server tries B, which defers. it looks in retry database, sees
> > that B hasn't worked for a long time, and BOUNCES THE MESSAGE
> > IMMEDIATELY.
>
> That isn't right.
>
> It is *recipients* that are deferred by greylisting, not messages. When
> a recipient is deferred, Exim notes that the recipient, not the host,
> has had a temporary error. (In the latest releases it is the
> sender+recipient combination, not just the recipient.) So, the above
> scenario will happen only if A defers *the same recipient* due to
> greylisting on the second occasion, and as I understand it, this
> shouldn't happen because the recipient was previously accepted.
the retry entry for B will be for the host if it sends 4xx in the
banner, right?
some greylisting implementations don't whitelist at all or whitelist
(sender-IP, sender-addr, rcpt-addr) tuples, and as I pointed out, even
if it does whitelist, a periodic list cleaning can cause mail to bounce.
--
Kjetil T.
