RE: [Exim] Idea for a per-recipient DATA ACL stage

--- Original Message ---
From: Eli <eli-list@???>
Sent: Tue, 6 Apr 2004 17:39:46 -0400
To: kelley@???, exim-users@???
Subject: RE: [Exim] Idea for a per-recipient DATA ACL stage

> Kelley Reynolds wrote:
> > It's easy enough to have per-address and per-domain DATA settings
> > simply by using acl-type conditions in the routers. This accomplishes
> > everything that you want, except for having the rejection done during
> > the DATA phase, which can still be done for single recipients.
>
> How exactly do you accomplish that during the DATA phase when you can't base
> anything off of $local_part or $domain? That's the whole issue many people
> have is that a message, once it's at the DATA phase, can have any number of
> recipients specified on it so you can't start filtering the message during
> ACL time based off of any user or domain level specific rules because then
> you're making decisions for other recipients who may not want the same
> filters applied.
>
> I understand that filtering messages can be done *after* the ACL stages, but
> the whole reason for having them done in the ACL stages is that you can
> prevent a message from being accepted in the first place, and its also a bit
> nicer in other ways too by reducing the # of messages you have in queue,
> etc... As well, I use exiscan which allows me to do av and spam filtering
> at ACL time, and many people would like to have individual per recipient
> specific settings for those types of filters and without something like a
> per recipient DATA phase, it's only possible by restricting the number of
> recipients per message to 1 which is a nasty hack in my opinion.

First of all, recall that I said that per-address and per-domain DATA settings can be used in the routers, I never said that you could perform rejections for multiple recipients at DATA time (unless they are all rejected, of course).

We'll use the SA example since that's a popular one.

First, determine if you have multiple recipients. If you do, run a warn acl that writes the score to an acl_m variable of your choice (or not, I think the spam_score is available in the routers). Optionally you can also write the SA report or whatever else you want. Then, accept the message (or don't reject it for this reason at least). At the routers, you can use any of local_parts, domains, senders, or condition to perform any acl-like conditions that you require. And example condition would compare $local_part@$domain's SA threshold with the acl_variable (or not) that you previously got. If it is higher, reject the message with a bounce (which is what I previously said you'd have to do), or the router gets skipped and moves on to another which accepts the message.

For single recipients, you can deny them at DATA time. For multiple recipients, you can still have per-address exiscan-type settings when there are multiple recipients in a single envelope, you just can't deny them at DATA time, as I stated in the first post. This is a very clean way of getting the DATA reject efficiency the vast majority of the time, and cleanly using the router facility for reject/bounces the rest of the time.

As far as opinions go, attempting to have per-recipient rejects in multiple recipient envelopes at DATA time is the hack since that behavior can be extremely unpredictable.

Kelley Reynolds