aboutsummaryrefslogtreecommitdiffstats
path: root/README.POSTFIX
blob: 204fd26ccdc9997019865801c3a9abc7daf174b0 (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
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: