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
199
200
201
202
203
204
205
206
207
208
209
210
211
|
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, and with 200010228 up to pl08.
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 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. 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 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:
|
