diff options
Diffstat (limited to '')
| -rw-r--r-- | README.POSTFIX | 198 |
1 files changed, 198 insertions, 0 deletions
diff --git a/README.POSTFIX b/README.POSTFIX new file mode 100644 index 00000000..204fd26c --- /dev/null +++ b/README.POSTFIX @@ -0,0 +1,198 @@ +Mailman - The GNU Mailing List Management System +Copyright (C) 2001,2002 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, and with 200010228 up to pl08. + + It is recommended that you set "owner_request_special = no" in + your main.cf config file so that Postfix won't treat -owner and + -request addresses specially (we want Postfix to simply deliver + such messages to the Mailman wrapper). The default is "yes" I + believe. + + 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. Here, my + recommendations are to comment out any luser_relay value in your + main.cf and just go with the defaults. Also, set + "recipient_delimiter = +" so that the symbol used to separate an + address from its extended semantics is a + sign. This will work + well with the default values for VERP_FORMAT and VERP_REGEXP in + Defaults.py. + + 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 Postfix-style 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. + + - 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 supports two styles of virtual domains, called + "Postfix-style" and "Sendmail-style". With the latter, all + aliases are visible in all domains, and nothing special need be + done with Mailman. + + With Postfix-style virtual domains, things are a little trickier, + although Mailman should work well with it. First, you'll need to + add a path to Postfix's virtual_maps variable: + + virtual_maps = <your normal virtual files>, + hash:/usr/local/mailman/data/virtual-mailman + + assuming you've installed Mailman in the default location. Note + that you must follow Postfix's instructions for setting up the + virtual domains; get your virtual domains working in Postfix + first before integrating Mailman. + + 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 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_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, it's 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 and 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 <fil@rezo.net> 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: |