alias maps, virtual domains, and LDAP

[Greg Woods]

I'm having a small problem with a virtual domain. We have
mydomain=ucar.edu, but we serve a virtual domain called nlr.net. It had
to be a virtual domain because when we took nlr.net over, there were
existing aliases that conflicted with some from ucar.edu (i.e.
***@ucar.edu reaches our USENET admin, but ***@nlr.net is a Mailman
list). Everything works fine on the central server, but we also have a
Mailman server that wants to serve lists in both virtual domains. This
works OK as far as the Mailman server is concerned. Users can send mail
to the Mailman aliases and that all works. Addresses within ucar.edu
work. What doesn't work is non-Mailman aliases within nlr.net, when mail
is originated on the Mailman server. We discovered this when one of the
nlr.net list admins tried to use "***@nlr.net" as the list admin
address, and stopped receiving subscribe notifications. Attached is the
entire postconf -n output, but here are some of the more relevant config
file lines:

virtual_alias_maps = hash:/etc/mailman/virtual-mailman
alias_maps = hash:/etc/aliases, ldap:/etc/postfix/ldap_alias.cf

This doesn't quite work. The only nlr.net aliases that get correctly
delivered are those that are in the virtual-mailman map. Aliases within
the virtual domain that are in the LDAP server don't get recognized, but
they are there:

# postmap -q ***@nlr.net ldap:/etc/postfix/ldap_alias.cf
***@aldea.com

But "sendmail.postfix -bv ***@nlr.net" gets this response:

<***@nlr.net>: delivery via none: User unknown in virtual alias table


OK, so let's try putting the ldap:/etc/postfix/ldap_alias.cf into
virtual_alias_maps too. As soon as I do that, the aliases that overlap
between the domain and the virtual domain don't work correctly:

<***@mailman.ucar.edu> (expanded from <***@nlr.net>): delivery via
local: delivers to command: /usr/bin/procmail

That's because ***@nlr.net expands to ***@mailman.ucar.edu, and the
mailman.ucar.edu gets stripped out because it is the name of the local
host, and then "news" from the LDAP query gets expanded to
***@mailman.ucar.edu and that's a local address, so now nobody can
post to the Mailman list ***@nlr.net.

Is there some way to set this up to do what I want? I think I've tried
just about every order of the maps, but it always works out so that
either the nlr.net aliases that overlap with ucar.edu get interpreted as
the ucar.edu alias, or the nlr.net aliases that are not in the
virtual-mailman map will bounce.

# postmap -q ***@nlr.net hash:/etc/mailman/virtual-mailman
news
# postmap -q ***@nlr.net hash:/etc/aliases
# postmap -q ***@nlr.net ldap:/etc/postfix/ldap_alias.cf
***@mailman
# postmap -q news hash:/etc/mailman/virtual-mailman
# postmap -q news hash:/etc/aliases
"|/usr/lib/mailman/mail/mailman post news"
# postmap -q news ldap:/etc/postfix/ldap_alias.cf
woods
# postmap -q ***@nlr.net hash:/etc/mailman/virtual-mailman
# postmap -q ***@nlr.net hash:/etc/aliases
# postmap -q ***@nlr.net ldap:/etc/postfix/ldap_alias.cf
***@aldea.com

There is no "editor" in any of the maps.

What I want, of course, is something that doesn't require me to maintain
all of the virtual aliases on the Mailman system too, I want to get them
from LDAP.

--Greg

[Noel Jones]

Post by Greg Woods
mydomain=ucar.edu, but we serve a virtual domain called
nlr.net. It had
to be a virtual domain because when we took nlr.net over,
there were
existing aliases that conflicted with some from ucar.edu (i.e.
is a Mailman
...
virtual_alias_maps = hash:/etc/mailman/virtual-mailman
alias_maps = hash:/etc/aliases, ldap:/etc/postfix/ldap_alias.cf
This doesn't quite work. The only nlr.net aliases that get
correctly
delivered are those that are in the virtual-mailman map.
Aliases within
the virtual domain that are in the LDAP server don't get
recognized, but

Aliases for virtual_alias_domains must be defined in
virtual_alias_maps. Entries in alias_maps are expanded
when local mail (listed in $mydestination) is delivered by
local(8).
Your ***@nlr.net address must be added to your
virtual-mailman hash, and removed from ldap_alias.cf.

[Greg Woods]

Post by Noel Jones
virtual-mailman hash, and removed from ldap_alias.cf.

If that is the case, then there really is no fix for my problem. I
really don't want to have to maintain all the nlr.net aliases in
multiple places. There are quite a lot of them, and there is no way of
knowing when someone might decide to use one of them as a list
administrator address, sign it up for a Mailman list, etc., so anything
I come up with must allow any of the @nlr.net aliases to be sent to. And
to be a real solution, it can't require all of the aliases to be
hand-maintained on the Mailman system, I have to find a way to get them
from the LDAP server.

Here's one other thing I tried. In the virtual-mailman map, instead of
an alias like:

***@nlr.net testnlr

I tried putting the testnlr expansion directly in here:

***@nlr.net "|/usr/lib/mailman/mail/mailman post testnlr"

The /etc/aliases map already had:

testnlr "|/usr/lib/mailman/mail/mailman post testnlr"

When I do this, I get:


<"|/usr/lib/mailman/mail/mailman post testnlr"@mailman.ucar.edu>
(expanded from
<***@nlr.net>): delivery via local: unknown user:
"|/usr/lib/mailman/mail/mailman post testnlr"

Why doesn't this work? You can expand an alias_maps entry to a pipe, but
not a virtual_alias_maps entry?

--Greg

[Magnus Bäck]

On Friday, June 30, 2006 at 20:59 CEST,
Greg Woods <***@ucar.edu> wrote:

[...]

Post by Greg Woods
Why doesn't this work? You can expand an alias_maps entry to a pipe,
but not a virtual_alias_maps entry?

Correct. The result of a virtual rewriting is always another address.
virtual(5) has the details.

[Wietse Venema]

Post by Greg Woods

Post by Noel Jones
virtual-mailman hash, and removed from ldap_alias.cf.

If that is the case, then there really is no fix for my problem. I
really don't want to have to maintain all the nlr.net aliases in
multiple places. There are quite a lot of them, and there is no way of
knowing when someone might decide to use one of them as a list
administrator address, sign it up for a Mailman list, etc., so anything
to be a real solution, it can't require all of the aliases to be
hand-maintained on the Mailman system, I have to find a way to get them
from the LDAP server.
Here's one other thing I tried. In the virtual-mailman map, instead of
testnlr "|/usr/lib/mailman/mail/mailman post testnlr"
(expanded from
"|/usr/lib/mailman/mail/mailman post testnlr"
Why doesn't this work? You can expand an alias_maps entry to a pipe, but
not a virtual_alias_maps entry?

I suggest that you read the documentation, in this case, VIRTUAL_README.

Wietse

[Noel Jones]

Post by Greg Woods
hand-maintained on the Mailman system, I have to find a
way to get them
from the LDAP server.

So set up another ldap query to use in virtual_alias_maps.

Post by Greg Woods
<"|/usr/lib/mailman/mail/mailman post
(expanded from
"|/usr/lib/mailman/mail/mailman post testnlr"
Why doesn't this work? You can expand an alias_maps entry
to a pipe, but
not a virtual_alias_maps entry?

Correct. Virtual_alias_maps will not expand to a pipe,
file, or command - only to another mail address.
(but the result can be something listed in alias_maps and
expand to a list there).

Others have suggested VIRTUAL_README for further insight.
http://www.postfix.org/VIRTUAL_README.html

[Greg Woods]

Post by Noel Jones
Others have suggested VIRTUAL_README for further insight.
http://www.postfix.org/VIRTUAL_README.html

That was enough to convince me that I didn't want to use a virtual
domain here. The virtual domain on the central server is what I want in
that case. The central server does no local delivery, it relays
everything to internal servers specified for each user in the LDAP
server, including mailman lists which expand "***@ucar.edu" or
"***@nlr.net" to "***@mailman.ucar.edu". With a virtual
domain, it can also expand "***@nlr.net" to something completely
different, which is what was needed.

The reason I started doing it this way on the Mailman server is because
I was following the Mailman documentation (reading the documentation is
NOT always a magic bullet!) Obviously the authors of that document were
assuming that you were running the Mailman server on the same machine as
the central Postfix server, which is not true in my case.

What actually worked was much simpler than what I was trying to do. Get
rid of the virtual domain on the Mailman server, and maintain only
aliases for the Mailman software. I don't need to have all the @nlr.net
aliases available at all, because if it's not a Mailman list, the MX
record will send it to the central server for delivery anyway. If it is
a Mailman list, all I need is a local expand-to-pipe alias like:

testnlr "|/pipe/to/mailman testnlr"

If I send to "***@nlr.net" from anywhere, including from the Mailman
server, it goes to our central server, gets expanded to
"***@mailman.ucar.edu", gets sent back to the Mailman server after
expansion, and everything works.

So I was just trying to get too cute. In the end, the only aliases I
have to maintain are those directly related to the Mailman system, and
I've always had to do that anyway. I also have to make sure that there
are not two Mailman lists in the two domains with the same name, but a
list name can conflict with an LDAP alias in the other domain, or two
LDAP aliases can conflict, and everything works as expected. Problem
solved.

--Greg

[mouss]

[snip]
So I was just trying to get too cute. In the end, the only aliases I
have to maintain are those directly related to the Mailman system, and
I've always had to do that anyway. I also have to make sure that there
are not two Mailman lists in the two domains with the same name, but a
list name can conflict with an LDAP alias in the other domain, or two
LDAP aliases can conflict, and everything works as expected. Problem
solved.

The conflict can be solved with virtual_alias_maps. for instance,
***@ucar.edu => news+***@listserver.example.org
***@nlr.net => news+***@listserver.example.org

then use news+ucar and news+nlr in your alias_maps. you can choose othe
forms, but '+' is nice if you also have it as an extension delimiter (so
that if no match is found, "news" will be tried).

A more general form would be
***@listdomain.example =>
locallistname+listname=***@listserver.example.org
but don't use wildcards as they break recipient validation.