6.1.2 Virtual domains

Note: This section describes how to integrate Mailman with Postfix for automatic generation of Postfix virtual_alias_maps for Mailman list addresses. Mailman's support of virtual domains is limited in that list names must be globally unique within a single Mailman instance, i.e., two lists may not have the same name even if they are in different domains.

Postfix 2.0 supports ``virtual alias domains'', essentially what used to be called ``Postfix-style virtual domains'' in earlier Postfix versions. To make virtual alias domains work with Mailman, you need to do some setup in both Postfix and Mailman. Mailman will write all virtual alias mappings to a file called, by default, /usr/local/mailman/data/virtual-mailman. It will also use postmap to create the virtual-mailman.db file that Postfix will actually use.

First, you need to set up the Postfix virtual alias domains as described in the Postfix documentation (see Postfix's virtual(5) manpage). Note that it's your responsibility to include the virtual-alias.domain anything line as described manpage (in recent Postfix this is not required if the domain is included in virtual_alias_domains in main.cf); Mailman will not include this line in virtual-mailman. You are highly encouraged to make sure your virtual alias domains are working properly before integrating with Mailman.

Next, add a path to Postfix's virtual_alias_maps variable, pointing to the virtual-mailman file, e.g.:

    virtual_alias_maps = <your normal virtual alias files>,
        hash:/usr/local/mailman/data/virtual-mailman

assuming you've installed Mailman in the default location. If you're using an older version of Postfix which doesn't have the virtual_alias_maps variable, use the virtual_maps variable instead.

The default mappings in virtual-mailman map list addresses in virtual domains to unqualified local names as in:

    [email protected]         mylist
    [email protected] mylist-request
    # and so on...

In some Postfix configurations it may be necessary to qualify those local names as for example:

    [email protected]         mylist@localhost
    [email protected] mylist-request@localhost
    # and so on...

If this is the case, you can include

    VIRTUAL_MAILMAN_LOCAL_DOMAIN = 'localhost'

or whatever qualification is needed in mm_cfg.py.

Next, in your mm_cfg.py file, you will want to set the variable POSTFIX_STYLE_VIRTUAL_DOMAINS to the list of virtual domains that Mailman should update. This may not be all of the virtual alias domains that your Postfix installation supports! The values in this list will be matched against the host_name attribute of mailing lists objects, and must be an exact match.

Here's an example. Note that this example describes an unusual configuration. A more usual configuration is described next. Say that Postfix is configured to handle the virtual domains dom1.ain, dom2.ain, and dom3.ain, and further that in your main.cf file you've got the following settings:

    myhostname = mail.dom1.ain
    mydomain = dom1.ain
    mydestination = $myhostname, localhost.$mydomain
    virtual_alias_maps =
        hash:/some/path/to/virtual-dom1,
        hash:/some/path/to/virtual-dom2,
        hash:/some/path/to/virtual-dom2

If in your virtual-dom1 file, you've got the following lines:

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

this tells Postfix to deliver anything addressed to dom1.ain to the same mailbox at mail.dom1.com, its default destination.

In this case you would not include dom1.ain in POSTFIX_STYLE_VIRTUAL_DOMAINS because otherwise Mailman will write entries for mailing lists in the dom1.ain domain as

    [email protected]         mylist
    [email protected] mylist-request
    # and so on...

The more specific entries trump your more general entries, thus breaking the delivery of any dom1.ain mailing list.

However, you would include dom2.ain and dom3.ain in mm_cfg.py:

    POSTFIX_STYLE_VIRTUAL_DOMAINS = ['dom2.ain', 'dom3.ain']

Now, any list that Mailman creates in either of those two domains, will have the correct entries written to /usr/local/mailman/data/virtual-mailman.

In a more usual configuration, dom1.ain would not be a virtual domain at all as in the following:

    myhostname = mail.dom1.ain
    mydomain = dom1.ain
    mydestination = $myhostname, $mydomain localhost.$mydomain
    virtual_alias_maps =
        hash:/some/path/to/virtual-dom2,
        hash:/some/path/to/virtual-dom2

In this case too, you would include dom2.ain and dom3.ain in mm_cfg.py:

    POSTFIX_STYLE_VIRTUAL_DOMAINS = ['dom2.ain', 'dom3.ain']

As in the previous section with the data/aliases* files, you want to make sure that both data/virtual-mailman and data/virtual-mailman.db are user and group owned by mailman.