Re: [exim] Per-User Whitelisting

Top Page
Delete this message
Reply to this message
Author: Alan J. Flavell
Date:  
To: Alun
CC: Exim users list
Subject: Re: [exim] Per-User Whitelisting
On Wed, 6 Apr 2005, Alun wrote:

> I think Alan might have missed the point here slightly


I concede that I might have got some of the detail confused, but I
reckon I still have a grasp of the key underlying issue...

> > As for why whitelisting is harder than blacklisting, well... we'll
> > just have to disagree.
>
> Your blacklist is independent of spam filtering, yes? So when a
> blacklisted sender submits a message you can reject at rcpt time for
> the recipients who don't want to receive from that sender.


That's fine, no arguments there.

> With the whitelist, you have to accept at rcpt time to get a chance
> of doing the SpamAssassin scan. At which point, you can't
> selectively accept for the whitelisted cases.


That was indeed the point I was trying to make.[1]

You have a wide range of /delivery/ options, e.g you can deliver to
one recipient's normal inbox, another recipient's spam bucket, and yet
another recipient's /dev/null if you (or they) want. But you've lost
the option to selectively reject the item, meaning that false-positive
items can simply disappear, without recipient or sender getting to
know about it. This is undesirable - *but* if one attempted to deal
with that shorcoming by composing non-delivery reports to the apparent
(envelope) sender, then collateral spam is inevitable.

> Temporary deferral sounds a bit complicated for the whitelist case.


I think that's a decision which one has to take on the grounds of
/policy/. Discussing the minute /technical detail/ of how to
implement it, is tending to obscure the key issue of what the end
result is going to be, and how it accords with your site's policy.
If you see what I mean.

all the best

[1] and this is where selective defer can help; although if you allow
every user to define a different rejection profile, you presumably
could only accept one recipient per transaction. Quite how you then
avoid running spamassassin n times for the n recipients is an
interesting question. Compute a checksum of the item and cache the
spamassassin score against it? - just a random thought.