[Mailman-Developers] Getting Mailman and Postfix to play nice in virtual domains

[Barry A. Warsaw]

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

list1@dom1.ain          	list1
list1-admin@dom1.ain    	list1-admin
list1-bounces@dom1.ain  	list1-bounces
list1-join@dom1.ain     	list1-join
list1-leave@dom1.ain    	list1-leave
list1-owner@dom1.ain    	list1-owner
list1-request@dom1.ain  	list1-request

list2@dom2.ain          	list2
list2-admin@dom2.ain    	list2-admin
list2-bounces@dom2.ain  	list2-bounces
list2-join@dom2.ain     	list2-join
list2-leave@dom2.ain    	list2-leave
list2-owner@dom2.ain    	list2-owner
list2-request@dom2.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 list1@dom1.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 list1@dom1.ain, this gets expanded
to list1+$myorigin, and if $myorigin is dom1.ain, then Postfix stops
and tries to deliver to list1@dom1.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
list1@dom1.ain and so it bounces it.

However, if $myorigin is mail.dom1.ain, then list1@dom1.ain expands to
list1@mail.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 list2@dom2.ain, which expands to
list2@dom1.ain.  Postfix continues expansion of this address, sees the
mapping from dom1.ain -> mail.dom1.ain in virtual-dom1, and expands
this to list2@mail.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. list2@dom2.ain ->
list2@mail.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 list1@dom1.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.

list2@dom2.ain	list2@mail.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