Re: [exim] Exclude recipient from wildcard

Page principale
Supprimer ce message
Répondre à ce message
Auteur: Phil Pennock
Date:  
À: Peter Thomassen
CC: exim-users
Sujet: Re: [exim] Exclude recipient from wildcard
On 2007-09-21 at 09:56 +0200, Peter Thomassen wrote:
> The output of `exim -bt postmaster` shows that Exim recursively tries to
> lookup for an alias (have a look at the "comments" I put in) and finally
> finds *:peter, regardless of the fact that root is a Linux user account and
> not an alias:


Each address generated will, by default, be routed normally through the
same list of routers as the original address. So the order of the
routers matters.

So let's look at the order of your routers:

real_local:
system_aliases:
long_aliases:
userforward:
procmail:
maildrop:
local_user:
mail4root:

So as long as there's a wildcard record in long_aliases, it will be
used; Philip Hazel offered repeat_use, to allow just one lookup. More
generally, the problem here though is your expectation that being a real
user account will protect against aliases is wrong. You'd need to move
"long_aliases" to after the
userforward/procmail/maildrop/local_user/mail4root batch for this to be
true.

The only reason that you can deliver peter@ is not because that's a
local user, but because of loop-detection built into Exim:

> --------> long_aliases router <--------
> long_aliases router skipped: previously routed peter@???


So when you look at the list of routers tried:

> # exim -bt postmaster
> R: system_aliases for postmaster@???
> R: system_aliases for root@???
> R: long_aliases for root@???
> R: system_aliases for peter@???
> R: long_aliases for peter@???
> R: system_aliases for peter@???
> R: userforward for peter@???
> R: procmail for peter@???
> R: maildrop for peter@???
> R: local_user for peter@???


you'll see that long_aliases mapped root to peter; then long_aliases
treated peter@; then system_aliases is looking at it again, because you
looked up peter@ and got peter@ as a result! This next time through,
the second pass at delivering peter@, long_aliases had already been
tried so you see your R: debug lines skip from system_aliases (the
second time it looks at peter@) to userforward without trying
long_aliases.

So if you want local users to override aliases, then long_aliases should
go to the end of the list. For clarity of your config, you should also
look up what the "cannot_route_message" on your local_user router means
and consider moving it. If you don't normally want local users to
override aliases but do want a catchall, then split long_aliases; remove
the wildcard entry from long_aliases and change the lookup from lsearch*
to lsearch (no wildcard), then put in a new catch-all router at the end.
If you don't want to touch the existing configuration files then you
_could_ just change "lsearch*@" to "lsearch@", and then repeat
long_aliases at the end with a new name and with "lsearch*@"; this way,
the "*" key would not be used the first time. However, this would
create more problems for debugging, so instead the new router at the end
should change:
data = ${lookup{$local_part@$domain}lsearch*@{CONFDIR/aliases}}
to:
data = ${lookup{*@$domain}lsearch@{CONFDIR/aliases}}

As an aside, you'll probably still have problems because you can't
deliver mail to root by default. It's a security step. Don't read mail
as root if you can help it. You can override never_users to remove root
from the list, but there's also a compile-time fixed list that can't be
overriden and which blocks root delivery; you'd need to adjust
Local/Makefile and rebuild to get an Exim which allows delivery to root.
The hoops you'd jump through, in an MTA which normally tries to make
configuration as easy as possible, hopefully highlight how bad an idea
this would be.

So you'll want to keep system_aliases before the local users and then
include root in the system aliases.

-Phil