~ubuntu-branches/ubuntu/hoary/mailman/hoary-security

« back to all changes in this revision

Viewing changes to FAQ

  • Committer: Bazaar Package Importer
  • Author(s): Matthias Klose
  • Date: 2004-10-11 02:02:43 UTC
  • Revision ID: james.westby@ubuntu.com-20041011020243-ukiishnhlkmsoh21
Tags: upstream-2.1.5
ImportĀ upstreamĀ versionĀ 2.1.5

Show diffs side-by-side

added added

removed removed

Lines of Context:
 
1
Mailman - The GNU Mailing List Management System
 
2
Copyright (C) 1998,1999,2000,2001,2002 by the Free Software Foundation, Inc.
 
3
59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
 
4
 
 
5
Note: We're migrating the FAQ to an on-line interactive system called
 
6
      "FAQ Wizard".  To see the Mailman FAQ Wizard in action, go to
 
7
      http://www.python.org/cgi-bin/faqw-mm.py
 
8
 
 
9
FREQUENTLY ASKED QUESTIONS
 
10
 
 
11
Q. How do you spell this program?
 
12
 
 
13
A. You spell it "Mailman", with a leading capital "M" and a lowercase
 
14
   second "m".  It is incorrect to spell it "MailMan" (i.e. you should
 
15
   not use StudlyCaps).
 
16
 
 
17
Q. I'm getting really terrible performance for outgoing messages.  It
 
18
   seems that if the MTA has trouble resolving DNS for any recipients,
 
19
   qrunner just gets really slow clearing the queue.  Any ideas?
 
20
 
 
21
A. What's likely happening is that your MTA is doing DNS resolution on
 
22
   recipients for messages delivered locally (i.e. from Mailman to
 
23
   your MTA via SMTPDirect.py).  This is a Bad Thing.  You need to
 
24
   turn off synchronous DNS resolution for messages originating from
 
25
   the local host.
 
26
 
 
27
   In Exim, the value to edit is receiver_verify_hosts.  See
 
28
   README.EXIM for details.  Other MTAs have (of course) different
 
29
   parameters and defaults that control this.  First check the README
 
30
   file for your MTA and then consult your MTA's own documentation.
 
31
 
 
32
Q. My list members are complaining about Mailman's List-* headers!
 
33
   What can I do about this?
 
34
 
 
35
A. These headers are described in RFC 2369 and are added by Mailman
 
36
   for the long-term benefit of end-users.  While discouraged, the
 
37
   list admin can disable these via the General Options page.  See
 
38
   also README.USERAGENT for more information.
 
39
 
 
40
Q. Can I put the user's address in the footer that Mailman adds to
 
41
   each message?
 
42
 
 
43
A. Yes, in Mailman 2.1.  The site admin needs to enable
 
44
   personalization by setting the following variables in the mm_cfg.py
 
45
   file:
 
46
 
 
47
    VERP_PASSWORD_REMINDERS = 1
 
48
    VERP_PERSONALIZED_DELIVERIES = 1
 
49
    VERP_DELIVERY_INTERVAL = 1
 
50
    VERP_CONFIRMATIONS = 1
 
51
 
 
52
   Once this is done, list admins can enable personalization for
 
53
   regular delivery members (digest deliveries can't be
 
54
   personalized currently).  A personalized list can include the
 
55
   user's address in the footer.
 
56
 
 
57
Q. My users hate HTML in their email and for security reasons, I want
 
58
   to strip out all MIME attachments.  How can I do this?
 
59
 
 
60
A. Mailman 2.1 has this feature built-in.  See the Content Filtering
 
61
   Options page in the admin interface.
 
62
 
 
63
Q. What if I get "document contains no data" from the web server, or
 
64
   mail isn't getting delivered, or I see "Premature end of script
 
65
   headers" or "Mailman CGI error!!!"
 
66
 
 
67
A. The most likely cause of this is that the GID that is compiled into
 
68
   the C wrappers does not match the GID that your Web server invokes
 
69
   CGI scripts with.  Note that a similar error could occur if your
 
70
   mail system invokes filter programs under a GID that does not match
 
71
   the one compiled into the C mail wrapper.
 
72
 
 
73
   To fix this you will need to re-configure Mailman using the
 
74
   --with-cgi-gid and --with-mail-gid options.  See the INSTALL file
 
75
   for details.
 
76
 
 
77
   These errors are logged to syslog and they do not show up in the
 
78
   Mailman log files.  Problems with the CGI wrapper do get reported
 
79
   in the web browser though (unless STEALTH_MODE is enabled), and
 
80
   include the expected GID, so that should help a lot.
 
81
 
 
82
   You may want to have syslog running and configured to log the
 
83
   mail.error log class somewhere; on Solaris systems, the line
 
84
 
 
85
       mail.debug                /var/log/syslog
 
86
 
 
87
   causes the messages to go to them in /var/log/syslog, for example.
 
88
   (The distributed syslog.conf forwards the message to the loghost,
 
89
   when present.  See the syslog man page for more details.)
 
90
 
 
91
   If your system is set like this, and you get a failure trying to
 
92
   visit the mailman/listinfo web page, and it's due to a UID or GID
 
93
   mismatch, then you should get an entry at the end of
 
94
   /var/log/syslog identifying the expected and received values.
 
95
 
 
96
   If you are not getting any log messages in syslog, or in Mailman's
 
97
   own log files, but messages are still not being delivered, then it
 
98
   is likely that qrunner is not running (qrunner is the process that
 
99
   handles all mail in the system).  In Mailman 2.0, qrunner was
 
100
   invoked from cron so make sure your crontab entries for the
 
101
   `mailman' user have been installed.  In Mailman 2.1, qrunner is
 
102
   started with the bin/mailmanctl script, which can be invoked
 
103
   manually, or merged with your OS's init scripts.
 
104
 
 
105
Q. What should I check periodically?
 
106
 
 
107
A. Many of the scripts have their standard error logged to
 
108
   $prefix/logs/error, and some of the modules write caught errors
 
109
   there, as well, so you should check there at least occasionally to
 
110
   look for bugs in the code and problems in your setup.
 
111
 
 
112
   You may want to periodically check the other log files in the logs/
 
113
   directory, perhaps occasionally rotating them with something like
 
114
   the Linux logrotate script.
 
115
 
 
116
Q. I can't access the public archives.  Why?
 
117
 
 
118
A. If you are using Apache, you must make sure that FollowSymLinks is
 
119
   enabled for the path to the public archives.  Note that the actual
 
120
   archives always reside in the private tree, and only when archives
 
121
   are public, is the symlink followed. See this archive message for
 
122
   more details:
 
123
 
 
124
   http://mail.python.org/pipermail/mailman-users/1998-November/000150.html
 
125
 
 
126
Q. Still having problems?  Running QMail?
 
127
 
 
128
A. Make sure that you are using "preline" before calling the "mailman"
 
129
   wrapper:
 
130
 
 
131
       |preline /home/mailman/mail/mailman post listname
 
132
 
 
133
   "preline" adds a Unix-style "From " header which the archiver requires.
 
134
   You can fix the archive mbox files by adding:
 
135
 
 
136
       From somebody Mon Oct  9 12:27:34 MDT 2000
 
137
 
 
138
   before every message and re-running the archive command
 
139
   "bin/arch listname".  The archives should now exist.  See README.QMAIL
 
140
   for more information.
 
141
 
 
142
Q. Still having problems?  Running on GNU/Linux?
 
143
 
 
144
A. See the README.LINUX file.
 
145
 
 
146
Q. I want to get rid of some messages in my archive.  How do I do
 
147
   this?
 
148
 
 
149
A. David Rocher posts the following recipe:
 
150
 
 
151
   * remove $prefix/archives/private/<listname>
 
152
   * edit $prefix/archives/private/<listname>.mbox/<listname>.mbox [optional]
 
153
   * run $prefix/bin/arch <listname>
 
154
 
 
155
Q. How secure are the authentication mechanisms used in Mailman's web
 
156
   interface?
 
157
 
 
158
A. If your Mailman installation run on an SSL-enabled web server
 
159
   (i.e. you access the Mailman web pages with "https://..." URLs),
 
160
   you should be as safe as SSL itself is.
 
161
 
 
162
   However, most Mailman installation run under standard,
 
163
   encryption-unaware servers.  There's nothing wrong with that for
 
164
   most applications, but a sufficiently determined cracker *could*
 
165
   get unauthorized access by:
 
166
 
 
167
   * Packet sniffing: The password used to do the initial
 
168
     authentication for any non-public Mailman page is sent as clear
 
169
     text over the net.  If you consider this to be a big problem, you
 
170
     really should use an SSL-enabled server.
 
171
 
 
172
   * Stealing a valid cookie: After successful password
 
173
     authentication, Mailman sends a "cookie" back to the user's
 
174
     browser.  This cookie will be used for "automatic" authentication
 
175
     when browsing further within the list's protected pages.  Mailman
 
176
     employs "session cookies" which are set until you quit your
 
177
     browser or explicitly log out.
 
178
 
 
179
     Gaining access to the user's cookie (e.g. by being able to read
 
180
     the user's browser cookie database, or by means of packet
 
181
     sniffing, or maybe even by some broken browser offering all it's
 
182
     cookies to any and all sites the user accesses), and at the same
 
183
     time being able to fulfill the other criteria for using the
 
184
     cookie could result in unauthorized access.
 
185
 
 
186
     Note that this problem is more easily exploited when users browse
 
187
     the web via proxies -- in that case, the cookie would be valid
 
188
     for any connections made through that proxy, and not just for
 
189
     connections made from the particular machine the user happens to
 
190
     be accessing the proxy from.
 
191
 
 
192
   * Getting access to the user's terminal: This is really just
 
193
     another kind of cookie stealing.  The short cookie expiration
 
194
     time is supposed to help defeat this problem.  It can be
 
195
     considered the price to pay for the convenience of not having to
 
196
     type the password in every time.
 
197
 
 
198
Q. I want to backup my lists.  What do I need to save?
 
199
 
 
200
A. See this FAQ wizard entry:
 
201
   http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq04.006.htp
 
202
 
 
203
Q. How do I rename a list?
 
204
 
 
205
A. Renaming a list is currently a bit of a pain to do completely
 
206
   correctly, especially if you want to make sure that the old list
 
207
   contacts are automatically forwarded to the new list.  This ought
 
208
   to be easier. :(
 
209
 
 
210
   The biggest problem you have is how to stop mail and web traffic to
 
211
   your list during the transition, and what to do about any mail
 
212
   undelivered to the old list after the move.  I don't think there
 
213
   are any foolproof steps, but here's how you can reduce the risk:
 
214
 
 
215
   - Temporarily disable qrunner.  To do this, you need to edit the
 
216
     user `mailman's crontab entry.  Execute the following command,
 
217
     commenting out the qrunner line when you're dropped into your
 
218
     editor.  Then save the file and quit the editor.
 
219
 
 
220
     % crontab -u mailman -e
 
221
 
 
222
   - Turn off your mail server.  This is mostly harmless since remote
 
223
     MTAs will just keep retrying until you turn it back on, and it's
 
224
     not going to be off for very long.
 
225
 
 
226
   - Next turn off your web server if possible.  This of course means
 
227
     your entire site will be off-line while you make the switch and
 
228
     this may not be acceptable to you.  The next best suggestion is
 
229
     to set up your permanent redirects now for the list you're
 
230
     moving.  This means that anybody looking for the list under its
 
231
     old name will be redirected to the new name, but they'll get
 
232
     errors until you've completed the move.
 
233
 
 
234
     Let's say the old name is "oldname" and the new name is
 
235
     "newname".  Here are some Apache directives that will do the
 
236
     trick, though YMMV:
 
237
 
 
238
     RedirectMatch permanent /mailman/(.*)/oldname(.*) http://www.dom.ain/mailman/$1/newname$2
 
239
     RedirectMatch permanent /pipermail/oldname(.*)    http://www.dom.ain/pipermail/newname$1
 
240
 
 
241
     Add these to your httpd.conf file and restart Apache.
 
242
 
 
243
   - Now cd to the directory where you've installed Mailman.  Let's
 
244
     say it's /usr/local/mailman:
 
245
 
 
246
     % cd /usr/local/mailman
 
247
 
 
248
     and cd to the `lists' subdirectory:
 
249
 
 
250
     % cd lists
 
251
 
 
252
     You should now see the directory `oldname'.  Move this to
 
253
     `newname':
 
254
 
 
255
     % mv oldname newname
 
256
 
 
257
   - Now cd to the private archives directory:
 
258
 
 
259
     % cd ../archives/private
 
260
 
 
261
     You will need to move the oldname's .mbox directory, and the
 
262
     .mbox file within that directory.  Don't worry about the public
 
263
     archives; the next few steps will take care of them without
 
264
     requiring you to fiddle around in the file system:
 
265
 
 
266
     % mv oldname.mbox newname.mbox
 
267
     % mv newname.mbox/oldname.mbox newname.mbox/newname.mbox
 
268
 
 
269
   - You now need to run the `bin/move_list' script to update some of
 
270
     the internal archiver paths.  IMPORTANT: Skip this step if you
 
271
     are using Mailman 2.1!
 
272
 
 
273
     % cd ../..
 
274
     % bin/move_list newname
 
275
 
 
276
   - You should now regenerate the public archives:
 
277
 
 
278
     % bin/arch newname
 
279
 
 
280
   - You'll likely need to change some of your list's configuration
 
281
     options, especially if you want to accept postings addressed to
 
282
     the old list on the new list.  Visit the admin interface for your
 
283
     new list:
 
284
 
 
285
     o Go to the General options
 
286
 
 
287
     o Change the "real_name" option to reflect the new list's name,
 
288
       e.g. "Newname"
 
289
 
 
290
     o Change the subject prefix to reflect the new list's name,
 
291
       e.g. "[Newname] " (yes, that's a trailing space character).
 
292
 
 
293
     o Optionally, update other configuration fields like info,
 
294
       description, or welcome_msg.  YMMV.
 
295
 
 
296
     o Save your changes
 
297
 
 
298
     o Go to the Privacy options
 
299
 
 
300
     o Add the old list's address to acceptable_aliases.
 
301
       E.g. "oldname@dom.ain".  This way, (after the /etc/aliases
 
302
       changes described below) messages posted to the old list will
 
303
       not be held by the new list for "implicit destination"
 
304
       approval.
 
305
 
 
306
     o Save your changes
 
307
 
 
308
   - Now you want to update your /etc/aliases file to include the
 
309
     aliases for the new list, and forwards for the old list to the
 
310
     new list.  Note that these instructions are for Sendmail style
 
311
     alias files, adjust to the specifics of how your MTA is set up.
 
312
 
 
313
     o Find the lines defining the aliases for your old list's name
 
314
 
 
315
     o Copy and paste them just below the originals.
 
316
 
 
317
     o Change all the references of "oldname" to "newname" in the
 
318
       pasted stanza.
 
319
 
 
320
     o Now change the targets of the original aliases to forward to
 
321
       the new aliases.  When you're done, you will end up with
 
322
       /etc/aliases entries like the following (YMMV):
 
323
 
 
324
       XXX This needs updating for MM2.1!
 
325
 
 
326
       # Forward the oldname list to the newname list
 
327
       oldname:         newname@dom.ain
 
328
       oldname-request: newname-request@dom.ain
 
329
       oldname-admin:   newname-admin@dom.ain
 
330
       oldname-owner:   newname-owner@dom.ain
 
331
 
 
332
       newname:         "|/usr/local/mailman/mail/mailman post newname"
 
333
       newname-admin:   "|/usr/local/mailman/mail/mailman mailowner newname"
 
334
       newname-request: "|/usr/local/mailman/mail/mailman mailcmd newname"
 
335
       newname-owner:   newname-admin
 
336
 
 
337
     o Run newaliases
 
338
 
 
339
   - Before you restart everything, you want to make one last check.
 
340
     You're looking for files in the qfiles/ directory that may have
 
341
     been addressed to the old list but weren't delivered before you
 
342
     renamed the list.  Do something like the following:
 
343
 
 
344
     % cd /usr/local/mailman/qfiles
 
345
     % grep oldname *.msg
 
346
 
 
347
     If you get no hits, skip to the next step, you've got nothing to
 
348
     worry about.
 
349
 
 
350
     If you did get hits, then things get complicated.  I warn you
 
351
     that the rest of this step is untested. :(
 
352
 
 
353
     For each of the .msg files that were destined for the old list,
 
354
     you need to change the corresponding .db file.  Unfortunately
 
355
     there's no easy way to do this.  Anyway...
 
356
 
 
357
     Save the following Python code in a file called 'hackdb.py':
 
358
 
 
359
     -------------------------hackdb.py
 
360
     import sys
 
361
     import marshal
 
362
     fp = open(sys.argv[1])
 
363
     d = marshal.load(fp)
 
364
     fp.close()
 
365
     d['listname'] = sys.argv[2]
 
366
     fp = open(sys.argv[1], 'w')
 
367
     marshal.dump(d, fp)
 
368
     fp.close()
 
369
     -------------------------
 
370
 
 
371
     And then for each file that matched your grep above, do the
 
372
     following:
 
373
 
 
374
     % python hackdb.py reallylonghexfilenamematch1.db newname
 
375
 
 
376
   - It's now safe to turn your MTA back on.
 
377
 
 
378
   - Turn your qrunner back on by running
 
379
 
 
380
     % crontab -u mailman -e
 
381
 
 
382
     again and this time uncommenting the qrunner line.  Save the file
 
383
     and quit your editor.
 
384
 
 
385
   - Rejoice, you're done.  Send $100,000 in shiny new pennies to the
 
386
     Mailman cabal as your downpayment toward making this easier for
 
387
     the next list you have to rename. :)
 
388
 
 
389
 
 
390
 
 
391
Local Variables:
 
392
mode: text
 
393
indent-tabs-mode: nil
 
394
End: