Mailman - The GNU Mailing List Management System Copyright (C) 2001-2003 by the Free Software Foundation, Inc. 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA GENERAL SETUP INFORMATION Mailman should work pretty much out of the box with a standard Postfix installation. As of this writing I've tested it with Postfix 19991231 up to pl13, 200010228 up to pl08, and up to Postfix 2.0.15. By default, Postfix treats -owner and -request addresses specially. Since we want Postfix to deliver such messages to Mailman, you should turn off this option by adding this to your main.cf file: owner_request_special = no In order to support Mailman's optional VERP delivery, you will want to disable luser_relay (the default) and you will want to set recipient_delimiter for extended address semantics. You should comment out any luser_relay value in your main.cf and just go with the defaults. Also, add this to your main.cf file: recipient_delimiter = + Using + as the delimiter works well with the default values for VERP_FORMAT and VERP_REGEXP in Defaults.py. When attempting to deliver a message to a non-existent local address, Postfix may return a 450 error code. Since this is a non-transient error code, Mailman will continue to attempt to delivery the message for DELIVERY_RETRY_PERIOD (5 days by default). You might want to set Postfix up so that it returns permanent error codes for non-existent local users by adding the following to your main.cf file: unknown_local_recipient_reject_code = 550 Finally, if you are using Postfix-style virtual domains, read the section on virtual domain support below. INTEGRATING POSTFIX AND MAILMAN You can integrate Postfix and Mailman such that when new lists are created, or lists are removed, Postfix's alias database will be automatically updated. The following are the steps you need to take to make this work. In the description below, we assume that you've installed Mailman in the default location, i.e. /usr/local/mailman. If that's not the case, adjust the instructions according to your use of configure's --prefix and --with-var-prefix options. - If you are using virtual domains and you want Mailman to honor your virtual domains, read the section below first! - Add this to the bottom of the $prefix/Mailman/mm_cfg.py file: MTA = 'Postfix' The MTA variable names a module in Mailman/MTA which contains the MTA-specific functions to be executed when a list is created or removed. - Look at the Defaults.py file for the variables POSTFIX_ALIAS_CMD and POSTFIX_MAP_CMD command. Make sure these point to your postalias and postmap programs respectively. Remember that if you need to make changes, do it in mm_cfg.py. - Run the genaliases script to initialize your aliases file. % cd /usr/local/mailman % bin/genaliases Make sure that the owner of the data/aliases and data/aliases.db file is `mailman' and that the group owner for those files is `mailman'. E.g.: % su % chown mailman:mailman data/aliases* - Hack your Postfix's main.cf file to include the following path in your alias_maps variable: /usr/local/mailman/data/aliases (no trailing .db). Do not include this in your alias_database variable. This is because you do not want Postfix's newaliases command to modify Mailman's aliases.db file, but you do want Postfix to consult aliases.db when looking for local addresses. You probably want to use a hash: style database for this entry. Here's an example: alias_maps = hash:/etc/postfix/aliases, hash:/usr/local/mailman/data/aliases - When you configure Mailman, use the --with-mail-gid=mailman switch (actually, this will be the default if you configured Mailman after adding the `mailman' owner). Because the owner of the aliases.db file is `mailman', Postfix will execute Mailman's wrapper program as uid and gid mailman. That's it! One caveat: when you add or remove a list, the aliases.db file will updated, but it will not automatically run "postfix reload". This is because you need to be root to run this and suid-root scripts are not secure. The only effect of this is that it will take about a minute for Postfix to notice the change to the aliases.db file and update its tables. I consider this a minor inconvenience. VIRTUAL 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; Mailman will not include this line in virtual-mailman. I highly encourage you 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 = , 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. 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: Let's say I've set up Postfix to handle the virtual domains dom1.ain, dom2.ain, and dom3.ain. Let's say further that in main.cf 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 Let's say further that in virtual-dom1, 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 mylist@dom1.ain mylist mylist-request@dom1.ain 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 As above 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 the `mailman' user/group. So to get things started, set up your virtual domains, run bin/genaliases, and check the ownerships of the files. From here on out, you should be good to go. AN ALTERNATIVE APPROACH Fil has an alternative approach based on virtual maps and regular expressions, as described at: (French) http://listes.rezo.net/comment.php (English) http://listes.rezo.net/how.php This is a good (and simpler) alternative if you don't mind exposing an additional hostname in the domain part of the addresses people will use to contact your list. I.e. if people should use mylist@lists.dom.ain instead of mylist@dom.ain. I have not extensively tested this approach however. Local Variables: mode: text indent-tabs-mode: nil End: