Re: [Exim] ACL to verify recipient

Page principale
Supprimer ce message
Répondre à ce message
Auteur: Alan J. Flavell
Date:  
À: Matt Bernstein
CC: Exim users list
Sujet: Re: [Exim] ACL to verify recipient
On Sun, 1 Sep 2002, Matt Bernstein wrote:

> On Aug 31 Alan J. Flavell wrote:
>
> >Take care that you don't simply hand the spammers an address-checking
> >facility for laundering their dirty lists.
>
> Here's a silly thing to do if you care[1] that much:


An ingenious scheme, indeed...

> [1] your caring involves doing DNS lookups you might not otherwise have
> done, just to provide a possibly misleading (though possibly not false)
> reason for your rejection!


I think the issue here is the sequence in which the ACLs are actioned.

We defined two groups of blacklists: those on which we reject
outright, and those on which we cut warnings which feature later
in spam-rating etc.

Let's concentrate on the outright-rejection blacklists.

Here's the simple scenarios, without your nice refinement...

What we're going to do, in one sequence or the other, is:

- check if the recipient is valid locally

- check whether the offering IP is blacklisted in the dns.

If the mail gets past the first check, then we're going to do the
second check anyway. So, successful mails are going to involve both
of these tests, and for those it doesn't matter which order they're
done in.

So, any differences in processing relate only to the subset of mails
which fail at the first check.

By checking the DNS first, we have the cost of a DNS lookup; but
if there's a bunch of spam from the same source, then we'll use the
cached lookups after the first.

By checking valid recipients first: if the recipient is invalid then
we save the DNS lookup. But we hand out information about the
validity of users.[1]

Bottom line is that this difference between the two ACL sequences only
makes a processing difference in a subset of the total incoming mails.
(Roughly: those for which the recipient is invalid _and_ the IP
blacklist lookup isn't in the dns cache.)

(If you're going to also consider relay recipients who are validated
by callout, then the balance swings even further towards doing the
blacklist check first.)

That's how I see it, anyway. But I think I've (more than?) exhausted
this topic now. Apologies.

all the best

[1] Whether there's _really_ any benefit in denying the spammers this
bit of additional information isn't something I'd want to argue over:
folks are welcome to conclude it's not worth worrying about, and
that's fair enough: I'm not exactly _worried_, but I'm still
sufficiently crabby that I prefer not to hand spammers information
which might help them to do their work more effectively.