aboutsummaryrefslogtreecommitdiffstats
path: root/README.POSTFIX
diff options
context:
space:
mode:
Diffstat (limited to '')
-rw-r--r--README.POSTFIX222
1 files changed, 0 insertions, 222 deletions
diff --git a/README.POSTFIX b/README.POSTFIX
deleted file mode 100644
index d5da5d57..00000000
--- a/README.POSTFIX
+++ /dev/null
@@ -1,222 +0,0 @@
-Mailman - The GNU Mailing List Management System
-Copyright (C) 2001-2004 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 transient error
- code, Mailman will continue to attempt to deliver 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 = <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.
-
- 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 <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: