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

« back to all changes in this revision

Viewing changes to admin/www/faq.ht

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