diff options
| -rw-r--r-- | README.POSTFIX | 140 |
1 files changed, 133 insertions, 7 deletions
diff --git a/README.POSTFIX b/README.POSTFIX index 68d9fe1ea..ae60917d8 100644 --- a/README.POSTFIX +++ b/README.POSTFIX @@ -3,11 +3,38 @@ Copyright (C) 2001 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 (25-Nov-2001) 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 - automatically be updated. The following are the steps you need to + 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 @@ -15,6 +42,19 @@ INTEGRATING POSTFIX AND MAILMAN the case, adjust the instructions according to your use of configure's --prefix and --with-var-prefix options. + A WORD OF CAUTION: The version of BerkeleyDB that Postfix was + linked against MUST match the version that Python's bsddb module + was linked against. If they don't, you will get an exception from + genaliases (see below) that says "Invalid argument". You can use + ldd to see which version each was linked against, and if they + don't match, you'll have to recompile either Python or Postfix so + that they do match. You'll probably find the most luck with + libdb.so.3 and Python 2.1.1. + + - If you are using Postfix-style virtual domains and you want + Mailman to honor your virtual domains, read the section below + first! + - Run the genaliases script to initialize your aliases file. % cd /usr/local/mailman @@ -27,11 +67,15 @@ INTEGRATING POSTFIX AND MAILMAN % su % chown mailman.mailman data/aliases* - - Hack your Postfix's main.cf file to include $mailman/data/aliases - (no trailing .db) in the alias_map variable but not alias_database. - This is because you do not want Postfix's newalias command to modify - Mailman's aliases.db file, but you do want Postfix to consult - aliases.db when looking for local addresses. + - Hack your Postfix's main.cf file to include the following path + in your alias_map 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 want to be sure that that you're using the hash: style database for this entry. Here's an example: @@ -62,6 +106,81 @@ INTEGRATING POSTFIX AND MAILMAN 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 + 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 @@ -70,6 +189,13 @@ AN ALTERNATIVE APPROACH (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: |