On Mon, Sep 19, 2005 at 10:05:11AM +0100, Philip Hazel wrote:
> > Aside: the idea that it would be nice to be able invoke the exim *filter
> > language* during ACLs has occurred to me more than once. Perhaps a "filter =
> > <filename>" or "filter = <string>" condition would do this. Applications:
>
> Permissions issues would make this fail frequently, and therefore cause
> administrative hassles.
Yep; I'd pull the filter string out of a database rather than the
filesystem.
> > - invoking a user's filter during DATA would allow messages to be rejected
> > rather than accepted and subsequently blackholed (yes, I know there's a
> > problem for messages with multiple recipients)
>
> The problem is kind of show-stopping...
Perhaps. I was thinking of using control=fakereject: e.g.
550 Your message was rejected by 2 out of 3 recipients
or
550-Your message was rejected by some of its recipients.
550-fred@???: spamassassin score too high
550 wilma@???: matched DNS list at spamhaus.org
> > - invoking another user-written filter at RCPT stage would allow users to
> > customise policy for message rejection. For example, Exim could previously
> > set $acl_m0 to the number of RBL lists which a message has triggered,
>
> I suspect very few users would be knowledgeable enough to do this kind
> of thing.
This may well be true (although perhaps few users are knowledgeable enough
to write filter files in the first place :-) You could have a web frontend
for creating filters though.
I guess it's possible to allow users (or the web frontend) to write their
filters directly in ACL language:
acl = ${lookup {$local_part@$domain} .... }
That scares me too much. 39.20 doesn't explicitly say what happens for
syntactically invalid ACLs (I guess they defer), but allowing users to write
them is bound to have security impacts, at the very least being able to run
code as the 'exim' user and thus read other people's mail, since there are
no lockdown features like the Exim filter language has.
Oh well, it was just a thought :-)
Regards,
Brian.
