-
Notifications
You must be signed in to change notification settings - Fork 0
/
FAQ
383 lines (275 loc) · 14.7 KB
/
FAQ
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
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
Mailman - The GNU Mailing List Management System
Copyright (C) 1998-2018 by the Free Software Foundation, Inc.
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA
Note: We've migrated the FAQ to the wiki at http://wiki.list.org/
To see the Mailman FAQ go to http://wiki.list.org/x/AgA3
FREQUENTLY ASKED QUESTIONS
Q. How do you spell this program?
A. You spell it "Mailman", with a leading capital "M" and a lowercase
second "m". It is incorrect to spell it "MailMan" (i.e. you should
not use StudlyCaps).
Q. I'm getting really terrible performance for outgoing messages. It
seems that if the MTA has trouble resolving DNS for any recipients,
qrunner just gets really slow clearing the queue. Any ideas?
A. What's likely happening is that your MTA is doing DNS resolution on
recipients for messages delivered locally (i.e. from Mailman to
your MTA via SMTPDirect.py). This is a Bad Thing. You need to
turn off synchronous DNS resolution for messages originating from
the local host.
In Exim, the value to edit is receiver_verify_hosts. Consult the
Mailman Installation Manual for details. Other MTAs have (of
course) different parameters and defaults that control this. First
check the README file for your MTA and then consult your MTA's own
documentation.
Q. My list members are complaining about Mailman's List-* headers!
What can I do about this?
A. These headers are described in RFC 2369 and are added by Mailman
for the long-term benefit of end-users. While discouraged, the
list admin can disable these via the General Options page. See
also README.USERAGENT for more information.
Q. Can I put the user's address in the footer that Mailman adds to
each message?
A. Yes, in Mailman 2.1. The site admin needs to enable personalization by
setting the following variable in the mm_cfg.py file:
OWNERS_CAN_ENABLE_PERSONALIZATION = Yes
Once this is done, list admins can enable personalization for regular
delivery members (digest deliveries can't be personalized currently). A
personalized list can include the user's address in the footer.
Q. My users hate HTML in their email and for security reasons, I want
to strip out all MIME attachments. How can I do this?
A. Mailman 2.1 has this feature built-in. See the Content Filtering
Options page in the admin interface.
Q. What if I get "document contains no data" from the web server, or
mail isn't getting delivered, or I see "Premature end of script
headers" or "Mailman CGI error!!!"
A. The most likely cause of this is that the GID that is compiled into
the C wrappers does not match the GID that your Web server invokes
CGI scripts with. Note that a similar error could occur if your
mail system invokes filter programs under a GID that does not match
the one compiled into the C mail wrapper.
To fix this you will need to re-configure Mailman using the
--with-cgi-gid and --with-mail-gid options. See the INSTALL file
for details.
These errors are logged to syslog and they do not show up in the
Mailman log files. Problems with the CGI wrapper do get reported
in the web browser though (unless STEALTH_MODE is enabled), and
include the expected GID, so that should help a lot.
You may want to have syslog running and configured to log the
mail.error log class somewhere; on Solaris systems, the line
mail.debug /var/log/syslog
causes the messages to go to them in /var/log/syslog, for example.
(The distributed syslog.conf forwards the message to the loghost,
when present. See the syslog man page for more details.)
If your system is set up like this, and you get a failure trying to
visit the mailman/listinfo web page, and it's due to a UID or GID
mismatch, then you should get an entry at the end of
/var/log/syslog identifying the expected and received values.
If you are not getting any log messages in syslog, or in Mailman's
own log files, but messages are still not being delivered, then it
is likely that qrunner is not running (qrunner is the process that
handles all mail in the system). In Mailman 2.0, qrunner was
invoked from cron so make sure your crontab entries for the
`mailman' user have been installed. In Mailman 2.1, qrunner is
started with the bin/mailmanctl script, which can be invoked
manually, or merged with your OS's init scripts.
Q. What should I check periodically?
A. Many of the scripts have their standard error logged to
$prefix/logs/error, and some of the modules write caught errors
there, as well, so you should check there at least occasionally to
look for bugs in the code and problems in your setup.
You may want to periodically check the other log files in the logs/
directory, perhaps occasionally rotating them with something like
the Linux logrotate script.
Q. I can't access the public archives. Why?
A. If you are using Apache, you must make sure that FollowSymLinks is
enabled for the path to the public archives. Note that the actual
archives always reside in the private tree, and only when archives
are public, is the symlink followed. See this archive message for
more details:
http://mail.python.org/pipermail/mailman-users/1998-November/000150.html
Q. Still having problems? Running QMail?
A. Make sure that you are using "preline" before calling the "mailman"
wrapper:
|preline /home/mailman/mail/mailman post listname
"preline" adds a Unix-style "From " header which the archiver requires.
You can fix the archive mbox files by adding:
From somebody Mon Oct 9 12:27:34 MDT 2000
before every message and re-running the archive command
"bin/arch listname". The archives should now exist.
Q. I want to get rid of some messages in my archive. How do I do
this?
A. David Rocher posts the following recipe:
* remove $prefix/archives/private/<listname>
* edit $prefix/archives/private/<listname>.mbox/<listname>.mbox [optional]
* run $prefix/bin/arch <listname>
Q. How secure are the authentication mechanisms used in Mailman's web
interface?
A. If your Mailman installation run on an SSL-enabled web server
(i.e. you access the Mailman web pages with "https://..." URLs),
you should be as safe as SSL itself is.
However, most Mailman installation run under standard,
encryption-unaware servers. There's nothing wrong with that for
most applications, but a sufficiently determined cracker *could*
get unauthorized access by:
* Packet sniffing: The password used to do the initial
authentication for any non-public Mailman page is sent as clear
text over the net. If you consider this to be a big problem, you
really should use an SSL-enabled server.
* Stealing a valid cookie: After successful password
authentication, Mailman sends a "cookie" back to the user's
browser. This cookie will be used for "automatic" authentication
when browsing further within the list's protected pages. Mailman
employs "session cookies" which are set until you quit your
browser or explicitly log out.
Gaining access to the user's cookie (e.g. by being able to read
the user's browser cookie database, or by means of packet
sniffing, or maybe even by some broken browser offering all it's
cookies to any and all sites the user accesses), and at the same
time being able to fulfill the other criteria for using the
cookie could result in unauthorized access.
Note that this problem is more easily exploited when users browse
the web via proxies -- in that case, the cookie would be valid
for any connections made through that proxy, and not just for
connections made from the particular machine the user happens to
be accessing the proxy from.
* Getting access to the user's terminal: This is really just
another kind of cookie stealing. The short cookie expiration
time is supposed to help defeat this problem. It can be
considered the price to pay for the convenience of not having to
type the password in every time.
Q. I want to backup my lists. What do I need to save?
A. See this FAQ entry: http://wiki.list.org/x/5oA9
Q. How do I rename a list?
A. Renaming a list is currently a bit of a pain to do completely
correctly, especially if you want to make sure that the old list
contacts are automatically forwarded to the new list. This ought
to be easier. :(
The biggest problem you have is how to stop mail and web traffic to
your list during the transition, and what to do about any mail
undelivered to the old list after the move. I don't think there
are any foolproof steps, but here's how you can reduce the risk:
- Temporarily disable qrunner. To do this, you need to edit the
user `mailman's crontab entry. Execute the following command,
commenting out the qrunner line when you're dropped into your
editor. Then save the file and quit the editor.
% crontab -u mailman -e
- Turn off your mail server. This is mostly harmless since remote
MTAs will just keep retrying until you turn it back on, and it's
not going to be off for very long.
- Next turn off your web server if possible. This of course means
your entire site will be off-line while you make the switch and
this may not be acceptable to you. The next best suggestion is
to set up your permanent redirects now for the list you're
moving. This means that anybody looking for the list under its
old name will be redirected to the new name, but they'll get
errors until you've completed the move.
Let's say the old name is "oldname" and the new name is
"newname". Here are some Apache directives that will do the
trick, though YMMV:
RedirectMatch permanent /mailman/(.*)/oldname(.*) http://www.dom.ain/mailman/$1/newname$2
RedirectMatch permanent /pipermail/oldname(.*) http://www.dom.ain/pipermail/newname$1
Add these to your httpd.conf file and restart Apache.
- Now cd to the directory where you've installed Mailman. Let's
say it's /usr/local/mailman:
% cd /usr/local/mailman
and cd to the `lists' subdirectory:
% cd lists
You should now see the directory `oldname'. Move this to
`newname':
% mv oldname newname
- Now cd to the private archives directory:
% cd ../archives/private
You will need to move the oldname's .mbox directory, and the
.mbox file within that directory. Don't worry about the public
archives; the next few steps will take care of them without
requiring you to fiddle around in the file system:
% mv oldname.mbox newname.mbox
% mv newname.mbox/oldname.mbox newname.mbox/newname.mbox
- You now need to run the `bin/move_list' script to update some of
the internal archiver paths. IMPORTANT: Skip this step if you
are using Mailman 2.1!
% cd ../..
% bin/move_list newname
- You should now regenerate the public archives:
% bin/arch newname
- You'll likely need to change some of your list's configuration
options, especially if you want to accept postings addressed to
the old list on the new list. Visit the admin interface for your
new list:
o Go to the General options
o Change the "real_name" option to reflect the new list's name,
e.g. "Newname"
o Change the subject prefix to reflect the new list's name,
e.g. "[Newname] " (yes, that's a trailing space character).
o Optionally, update other configuration fields like info,
description, or welcome_msg. YMMV.
o Save your changes
o Go to the Privacy options
o Add the old list's address to acceptable_aliases.
E.g. "[email protected]". This way, (after the /etc/aliases
changes described below) messages posted to the old list will
not be held by the new list for "implicit destination"
approval.
o Save your changes
- Now you want to update your /etc/aliases file to include the
aliases for the new list, and forwards for the old list to the
new list. Note that these instructions are for Sendmail style
alias files, adjust to the specifics of how your MTA is set up.
o Find the lines defining the aliases for your old list's name
o Copy and paste them just below the originals.
o Change all the references of "oldname" to "newname" in the
pasted stanza.
o Now change the targets of the original aliases to forward to
the new aliases. When you're done, you will end up with
/etc/aliases entries like the following (YMMV):
XXX This needs updating for MM2.1!
# Forward the oldname list to the newname list
oldname: [email protected]
oldname-request: [email protected]
oldname-admin: [email protected]
oldname-owner: [email protected]
newname: "|/usr/local/mailman/mail/mailman post newname"
newname-admin: "|/usr/local/mailman/mail/mailman mailowner newname"
newname-request: "|/usr/local/mailman/mail/mailman mailcmd newname"
newname-owner: newname-admin
o Run newaliases
- Before you restart everything, you want to make one last check.
You're looking for files in the qfiles/ directory that may have
been addressed to the old list but weren't delivered before you
renamed the list. Do something like the following:
% cd /usr/local/mailman/qfiles
% grep oldname *.msg
If you get no hits, skip to the next step, you've got nothing to
worry about.
If you did get hits, then things get complicated. I warn you
that the rest of this step is untested. :(
For each of the .msg files that were destined for the old list,
you need to change the corresponding .db file. Unfortunately
there's no easy way to do this. Anyway...
Save the following Python code in a file called 'hackdb.py':
-------------------------hackdb.py
import sys
import marshal
fp = open(sys.argv[1])
d = marshal.load(fp)
fp.close()
d['listname'] = sys.argv[2]
fp = open(sys.argv[1], 'w')
marshal.dump(d, fp)
fp.close()
-------------------------
And then for each file that matched your grep above, do the
following:
% python hackdb.py reallylonghexfilenamematch1.db newname
- It's now safe to turn your MTA back on.
- Turn your qrunner back on by running
% crontab -u mailman -e
again and this time uncommenting the qrunner line. Save the file
and quit your editor.
- Rejoice, you're done. Send $100,000 in shiny new pennies to the
Mailman cabal as your downpayment toward making this easier for
the next list you have to rename. :)
Local Variables:
mode: text
indent-tabs-mode: nil
End: