On 2005-07-01 at 14:11 +0100, Tony Finch wrote:
> It's a misfeature of the list construction syntax. You can probably work
> around it by using a regex match for the local part instead of simple
> string matching, e.g. ^barking $ : ^ wacky$
I've gone with the rules below, which seem to work adequately.
Unfortunately, a caret is an atext character so an email address of
<^foo@???> is valid. As is </foo/bar@???>. Ah, the
things we protect ourselves against with RCPT ACLs where we get to
define local restrictions ... and so take for granted.
So in fact, the stored data needs to escape starting '+', '/', '^' ...
I need to find the least intrusive way of dealing with that, but will do
so at config build time. Even if we didn't want to let customers use
such things, I wouldn't want to _rely_ on a web-interface filtering it.
Am I missing any other special-cases in Exim's parsing logic?
whitelist_filter:
driver = redirect
verify_only
no_expn
local_part_suffix = +*
local_part_suffix_optional
domains = cdb;DISTCONF/whitelist-exim.cdb
condition = ${if match_local_part{${quote_local_part:$local_part}}{$domain_data} {no}{yes}}
allow_fail
data = :fail: Blacklisted LHS for mail-domain $domain
blacklist_filter:
driver = redirect
verify_only
no_expn
local_part_suffix = +*
local_part_suffix_optional
domains = cdb;DISTCONF/blacklist-exim.cdb
condition = ${if match_local_part{${quote_local_part:$local_part}}{$domain_data} {yes}{no}}
allow_fail
data = :fail: Blacklisted LHS for mail-domain $domain
--
Phil Pennock, Senior Systems Administrator, Demon Netherlands
NL Sales: +31 20 422 20 00 Thus Plc NL Support: 0800 33 6666 8
