> ${if match{$header_X-Mailer:}{.*Bobs Message Poster.*}{1}{0}}
>
> You get the idea. This must be either in MIME or DATA ACLs (every ACL before
> does not have the headers yet). You can also use "regex" but that will be
> slower.
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:
- 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)
- 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, and
then the user could write
if $acl_m0 is not below 3 then fail endif
to bounce messages matching 3 or more RBLs. Right now, if you want to give
this sort of control to users you have to write complex ACLs which perform
external lookups for these parameters.
- if there were string expansions or 'if' conditions for RBL lookups and
suchlike, users could directly set their RCPT TO policies without help from
the ACL.
<sky colour="blue">
I wonder what Exim 5 would look like if the ACL language and the filter
language were merged?
</sky>
acl_check_rcpt:
if $sender_host_address is ""
finish
endif
if $domain match_domain_list +local_domains and
local_parts match_list "^[.] : ^.*[@%!/|]"
fail "Restricted characters in address"
endif
if $local_part is "postmaster" and $domain match_domain_list +local_domains
finish
endif
unless verify sender
fail
end
if $sender_host_address match_dnslist "black.list.example"
fail "rejected because $sender_host_address is in a black list at $dnslist_domain\n$dnslist_text"
endif
if $domain match_domain_list "+local_domains"
unless verify recipient
fail
end
finish
endif
# allow users to apply their own filter rules
include $home/.filter
... etc
As an even bluer sky: imagine if the filter language were able to return
values from expressions. Then we could replace ${..{..}..} expansion syntax
with filter language too. Not that I'm a great fan of the current filter
language, especially where quoting is concerned, but I still find it awkward
writing complex nested ${...} expressions.
Oh well, just an idea :-)
Regards,
Brian.
