Re: [exim] Per-User Whitelisting

On Tue, 5 Apr 2005, Miles Wilton wrote yard-long lines when, when
reflowed, said:

> I have just recently implemented per-user whitelisting and
> blacklisting (and also per-domain) on our mail server. Blacklisting
> is simple enough, but whitelisting was somewhat more problematic.
>
> I was wondering if either I missed something, or whether there are
> plans to develop some functionality to assist this.

No offence meant, but what have you done about messages with multiple
recipients who have different acceptance profiles?

I don't really grasp why you say that blacklisting was simple but
whitelisting was problematic. Seems to me that, if one is applying
the principles right, then they're of roughly equal problematicity...

> Basically what I've done is
>
> 1. Check white list in acl_smtp_rcpt, if the recipient has
> whitelisted the sender, then I add the recipient's address to
> $acl_m9

You mean if *one* recipient has whitelisted the sender, all of the
recipients get the mail?

> 2. After SPAM filtering in acl_smtp_data, before rejecting the
> message due to a high score, I check $acl_m9 is blank, if it isn't I
> accept the message.

There's a decision to be taken here (maybe you already took it). Spam
filtering (e.g spamassassin) is far and away the most expensive
operation involved in delivering a mail on our system: ACL checks, no
matter how baroque, and antivirus tests, pale into insignificance
compared to the cost of a spamassassin run. So anything which can
eliminate a run of spamassassin (whether by rejecting at an earlier
stage, or by accepting without running spamassassin) is a benefit, in
terms of server load. The flip side is that then the recipient gets
no spamassassin score - on which they might want to be diverting mail
to a spam inbox, or whatever.

> 3. I added a router which has the condition that the message is
> spam, $acl_m9 is not blank and that the original recpient is not
> found in the list $acl_m9. The router is a redirect with data set to
> :fail: (and various flags etc set to make sure it works properly
> with verify...)

I suppose it's a feasible approach (?) but we've always found it quite
simple to reject at the appropriate ACL stage.

> BLURB: It would be nice (!) if an extra option or two was added so
> that in the acl_smtp_rcpt you can construct a whitelist without
> resorting to custom vars and then when you deny a message,

Perhaps you need to take a look at the way exim expands strings.

You can include some amazingly elaborate expansions, including looking
things up in files and databases to get the final result.

h t h