Thanks for the information Ralf. You've confirmed that $myorigin gets
appended to bare names on the RHS of virtual table entries. I'm still
a little confused, so let me set up a simpler example:

-------------------- snip snip --------------------
main.cf:
    myorigin = dom1.ain
    virtual_maps = hash:.../virtual-dom1, hash:.../virtual-mailman

.../virtual-dom1:
    dom1.ain IGNORE
    dom1.ain mail.dom1.ain

.../virtual-mailman:
    addrdom1.ain addr

.../aliases
    addr: /dev/null
-------------------- snip snip --------------------

Mail is sent to addrdom1.ain:

addrdom1.ain -> addr$myorigin (virtual-mailman)
addr$myorigin == addrdom1.ain (main.cf)

--> addrdom1.ain bounces (user unknown)

So I think that Postfix gives up once it sees an address on the RHS
that equals the address on the LHS, or that it sees the address it
started with. And because the domain part of the address isn't in
$mydestination, it doesn't apply the aliases rule, and thus it
bounces. When Postfix has "addrdom1.ain" and it sees a rewrite loop,
it does not try to apply the more general dom.ain -> mail.dom1.ain
rule. If it did, we'd expect this address to succeed, via:

addrdom1.ain -> addrmail.dom1.ain (virtual-dom1, line 2)
addrmail.dom1.ain == addr$mydestination (main.cf)
addr$mydestination -> addr -> /dev/null (aliases)

Now, change myorigin to mail.dom1.ain and everything works:

addrdom1.ain -> addr$myorigin (virtual-mailman)
addr$myorigin == addrmail.dom.ain (main.cf)
addrmail.dom.ain -> addr$mydestination (main.cf)
addr$mydestination -> addr -> /dev/null (aliases)

So it appears that $myorigin cannot be a virtual domain. That's
certainly a valid rule, but this isn't documented. Note that
$mydestination is clearly documented as not allowed to be a virtual
domain.

    RH> Why don't you use FQDN's on the RHS or localhost on the RHS,
    RH> with localhost and localhost.$mydomain in $mydestination?

That might be what I'll end up doing. Using `localhost' avoids having
to add yet another Postfix-specific configuration variable to Mailman,
or trying to guess the value out of Postfix.

> 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.

    RH> Hmm, why can't you write a plain text file and then execute
    RH> "postmap" with mailman privileges?

Because currently I don't have any set-uid programs in Mailman (all of
Mailman's security is gid based). Perhaps this is a stupid prejudice
on my part, but I wanted to see how far I could get w/o requiring a
set-uid program. I've actually gotten quite far, and in fact I'd
probably win if the state of BerkeleyDB wasn't so chaotic.

Again, thanks.

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

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