On 2011-07-23 at 15:47 +0100, Tim Watts wrote:
> system_aliases:
[...]
> data = ${lookup{$local_part}lsearch{/etc/exim4/domains/$domain/aliases}}
> 3a) However (and it is logical) a "+" form on an alias cannot be blocked
> with the user level blacklist.
Depends. You can *preserve* the +suffix by changing the data line on
the original redirect, to include $local_part_suffix at the end, then
repeat the local_part_suffix rule on system_aliases and include
local_part_suffix_optional.
That would only allow you to redirect based on the +extension with no
concept of which address is being looked at.
Depending upon your needs, you could then incorporate
$original_local_part and $original_domain into the lookup in the
blacklist (perhaps adjusting the file used, or perhaps using namespaced
keys inside the one file). Beware that you'll need to manually do affix
removal from those, since affices are inherently per-Router and those
variables are just for what was the actual address originally being
handled for this recipient.
Or if you want to explicitly handle just the form which reached the
system_aliases, rather than the original address, then you can look into
using the address_data option and $address_data; the option is a generic
Router option and that variable is then available in subsequent Routers
and in the final Transport. So you can put whatever data you want in
it. I suspect, though, that you'll be happy either with a single
namespace for all +extensions or with using
$original_local_part@$original_domain carefully.
-Phil
