I've been playing around with support for virtual domains in Mailman,
trying to make them play nice with Postfix. For the record, I'm using
Postfix 20010228-pl08 on a RH6.1-ish Linux box. I'm using the latest
Mailman 2.1 alpha cvs snapshots. I'm not sure I understand how
Postfix expands addresses in virtual tables, so let me explain how
things are currently set up.

Let's say I have two domains that I want my Postfix to answer to
dom1.ain and dom2.ain. I am going to have mailing lists and plain
users in both domains. In my main.cf file I have

myhostname = mail.dom1.ain
mydomain = dom1.ain
myorigin = $myhostname

alias_maps = ..., hash:/usr/local/mailman/data/aliases
virtual_maps = ...,
    hash:/usr/local/etc/postfix/virtual-dom1,
    hash:/usr/local/etc/postfix/virtual-dom2,
    hash:/usr/local/mailman/data/virtual-mailman

In virtual-dom1 I have

dom1.ain IGNORE
dom1.ain mail.dom1.ain

and in virtual-dom2 I have

dom2.ain IGNORE
# lots of addresses which are only visible in dom2.ain...

Note that the two files /usr/local/mailman/data/* are written by
Mailman when a mailing list is created or deleted, and they must be
set up a priori with the proper permissions (i.e. must be owned by
`mailman') so that the mail programs they refer to will get executed
with the proper uid.

In /usr/local/mailman/data/aliases{,.db} I'll have entries such as:

list1: "|/usr/local/mailman/mail/mailman post list1"
list1-admin: "|/usr/local/mailman/mail/mailman bounces list1
list1-bounces: "|/usr/local/mailman/mail/mailman bounces list1"
list1-join: "|/usr/local/mailman/mail/mailman join list1"
list1-leave: "|/usr/local/mailman/mail/mailman leave list1"
list1-owner: "|/usr/local/mailman/mail/mailman owner list1"
list1-request: "|/usr/local/mailman/mail/mailman request list1"

list2: "|/usr/local/mailman/mail/mailman post list2"
list2-admin: "|/usr/local/mailman/mail/mailman bounces list2
list2-bounces: "|/usr/local/mailman/mail/mailman bounces list2"
list2-join: "|/usr/local/mailman/mail/mailman join list2"
list2-leave: "|/usr/local/mailman/mail/mailman leave list2"
list2-owner: "|/usr/local/mailman/mail/mailman owner list2"
list2-request: "|/usr/local/mailman/mail/mailman request list2"

and in /usr/local/mailman/data/virtual-mailman{,.db} I'll have entries
such as

list1dom1.ain list1
list1-admindom1.ain list1-admin
list1-bouncesdom1.ain list1-bounces
list1-joindom1.ain list1-join
list1-leavedom1.ain list1-leave
list1-ownerdom1.ain list1-owner
list1-requestdom1.ain list1-request

list2dom2.ain list2
list2-admindom2.ain list2-admin
list2-bouncesdom2.ain list2-bounces
list2-joindom2.ain list2-join
list2-leavedom2.ain list2-leave
list2-ownerdom2.ain list2-owner
list2-requestdom2.ain list2-request

That is, list1 should only be visible in dom1.ain and list2 should
only be visible in dom2.ain. Note that these are all Postfix-style
virtual domains.

With the current setup, I must set myorigin to mail.dom1.ain and not
dom1.ain, otherwise mail to list1dom1.ain will bounce with an
"unknown user". I believe the reason for this is because unqualified
bare names on the right-hand side of a virtual map entry will get
$myorigin appended to them. Further, I believe that Postfix's
recursive expansion rules state that if the right hand side is the
same as the left hand side, expansion stops.

So, when a message is received for list1dom1.ain, this gets expanded
to list1+$myorigin, and if $myorigin is dom1.ain, then Postfix stops
and tries to deliver to list1dom1.ain. Postfix ignores the
dom1.ain -> mail.dom1.ain mapping in the virtual-dom1 file because
(I believe) this is a more general mapping and the more specific
mapping trumps. So Postfix doesn't know where to deliver
list1dom1.ain and so it bounces it.

However, if $myorigin is mail.dom1.ain, then list1dom1.ain expands to
list1mail.dom1.ain, and because this is the default $mydestination,
Postfix stops, consults its local aliases table, and successfully
delivers the message to the intended program.

Delivery to list2 works for by $myorigin = dom1.ain and $myorigin =
mail.dom1.ain, and breaks down like so. When $myorigin = dom1.ain,
mail comes in addressed to list2dom2.ain, which expands to
list2dom1.ain. Postfix continues expansion of this address, sees the
mapping from dom1.ain -> mail.dom1.ain in virtual-dom1, and expands
this to list2mail.dom1.ain. Then it sees the default $mydestination
after the y, looks this up in the alias table, and delivers it to the
intended program. When $myorigin = mail.dom1.ain, it also works,
simply shortcircuiting one level of expansion. I.e. list2dom2.ain ->
list2mail.dom1.ain directly.

To sum up, here are my questions:

1. When a "bare" address appears on the right hand side of a virtual
   table entry, is it true that $myorigin gets appended during the
   address expansion phase?

2. If not, how does Postfix actually deal with a bare address on the
   right hand side of a virtual table entry?

3. Is it correct that if list1dom1.ain expands to list1+$myorigin in
   a virtual map, and $myorigin = dom1.ain, expansion will stop here
   without seeing the mapping of dom1.ain -> mail.dom1.ain in the
   virtual-dom1 map? And thus delivery will fail?

Apologies for such a long ramble, but I really want Mailman and
Postfix to play nicely w.r.t. virtual domains. It would be more
difficult to hack Mailman to include the fully qualified expansion on
the right hand side of its virtual table, e.g.

list2dom2.ain list2mail.dom1.ain

but I may have to do this. I'd like to better understand exactly what
Postfix is doing though before I propose a solution for Mailman, so
part of the purpose of this email is as a sanity check.

Aside: all this is further complicated by the fact that to use hash:
tables, the version of BerkeleyDB that Postfix is linked against must
match the version that Python is linked against, otherwise Mailman may
write hash tables that Postfix can't read. It doesn't help that I
think BerkeleyDB support in Python 2.2 is broken. :( All this is
starting to feel too complicated and error prone so I might have to
punt and try a different approach.

Thanks,
-Barry
-
To unsubscribe, send mail to majordomopostfix.org with content
(not subject): unsubscribe postfix-users

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]