Re: [cobalt-users] raq3 catch-all alias problems (& solution)

[Chris Adams <cmadams@xxxxxxxxxx>]

Once upon a time, Duncan Laurie <duncan@xxxxxxxxxx> said:
> The unpredictible nature of the problem has to do with the order of aliases
> in /etc/virtusertable.  When looking for the user assigned to a particular
> alias sendmail will parse this file from top to bottom (well not this file
> exactly, but the binary representation of it), stopping on the first match
> that it finds.  This means that if the catch-all alias (i.e. @www.x.com)
> appears above any user aliases (i.e. doug@xxxxxxxxx) the match will stop
> there and send the mail to the catch-all address, and NOT to the user...

That is not quite how it works.  If order makes a difference, then
something else is happening (and order did NOT make any difference when
I was trying to figure this out).

First, the text file /etc/virtusertable is converted into a Berkeley DB
hash file, which doesn't have any notion of order.  If you try to step
through a hash file, the order you get will be based on an internal
representation, not the order the lines were in the original text file
(or even alphabetical order).

Second, sendmail's search rules go like this (in order):

1) If you have user@xxxxxxxxxx and domain.com is in the list of virtual
domains, then lookup user@xxxxxxxxxxx  If you get a match, you are done.
2) If you have user+extra@xxxxxxxxxx, lookup user+*@domain.com.  If you
get a match, you are done.
3) If you have user+extra@xxxxxxxxxx, lookup user@xxxxxxxxxxx  If you
get a match, you are done.
4) If you have user@xxxxxxxxxx, lookup @domain.com, possibly replacing a
"%1" in the result with the original user.  If you get a match, you are
done.

This set of rules is run repeatedly until none of the rules match.
Rules 2 and 3 let you have "extra" stuff on the user part of an address
and just strip it off to look up the virtual user entry.  After that, if
user exists as a local user on the RaQ (even if they are not part of
domain.com), the email would be delivered to them.

The way Cobalt sets things up, virtual users are always setup only for
@host.domain.com, not plain @domain.com.  If you check the "Accept email
for domain" box, then a special entry like:

@domain.com %1@xxxxxxxxxxxxxxx

is setup (this is the kind of entry that matches rule 4 above).  So, the
rules get run twice: the first time turns user@xxxxxxxxxx to
user@xxxxxxxxxxxxxxx, and then user@xxxxxxxxxxxxxxx gets checked.

Now, on the RaQ1 and RaQ2, each user on a site had an entry in the
virtual users file, even if the username was the same as the preferred
email alias.  So you had entries like:

user@xxxxxxxxxxxxxxx user

So, for each user, rule 1 above would match, and then (since there was
no longer a @domain.com part on the address) the rules wouldn't match
any more.  So rule 4 was only reached for users that didn't exist.

On a RaQ3, this is no longer true.  Users _don't_ get the alias anymore,
so if somebody sends to user@xxxxxxxxxx, rules 1, 2, and 3, don't match,
and then rule 4 matches the catch-all.

That's why explicitly specifying an alias for each user that is the same
as their username works, because then you put the

user@xxxxxxxxxxxxxxx user

line back in.

Now, one other thing (and this is true for all RaQ products): since
there is not an explicit

@host.domain.com error:nouser User unknown

line for each domain, users on a RaQ can (depending on what aliases are
setup for a domain) receive email at any domain hosted on that RaQ,
unless the domain has a catch-all.  For example, if you have dom_a.com
and dom_b.com setup, and dom_a.com has a user "joe" and dom_b.com has a
user "bob", AND dom_b.com doesn't have any user with an alias "joe",
then dom_a.com's user "joe" will also receive email addressed to
"joe@xxxxxxxxx".

-- 
Chris Adams <cmadams@xxxxxxxxxx>
Systems and Network Administrator - HiWAAY Information Services
I don't speak for anybody but myself - that's enough trouble.