diff options
Diffstat (limited to 'admin/www/faq.ht')
| -rw-r--r-- | admin/www/faq.ht | 296 |
1 files changed, 0 insertions, 296 deletions
diff --git a/admin/www/faq.ht b/admin/www/faq.ht deleted file mode 100644 index 91f98dfa..00000000 --- a/admin/www/faq.ht +++ /dev/null @@ -1,296 +0,0 @@ -Title: Mailman Frequently Asked Questions - -See also the <a href="http://www.python.org/cgi-bin/faqw-mm.py">Mailman -FAQ Wizard</a> for more information. - - <h3>Mailman Frequently Asked Questions</h3> - -<b> Q. How do you spell this program? - -</b><br> 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). -<p> <b> 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? - -</b><br> 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. -<p> In Exim, the value to edit is receiver_verify_hosts. See - README.EXIM 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. -<p> <b> Q. My list members are complaining about Mailman's List-* headers! - What can I do about this? - -</b><br> 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. -<p> <b> Q. Can I put the user's address in the footer that Mailman adds to - each message? - -</b><br> A. Yes, in Mailman 2.1. The site admin needs to enable personalization by - setting the following variable in the mm_cfg.py file: -<p> OWNERS_CAN_ENABLE_PERSONALIZATION = Yes -<p> 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. -<p> <b> 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? - -</b><br> A. Mailman 2.1 has this feature built-in. See the Content Filtering - Options page in the admin interface. -<p> <b> 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!!!" - -</b><br> 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. -<p> 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. -<p> 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. -<p> You may want to have syslog running and configured to log the - mail.error log class somewhere; on Solaris systems, the line -<p> mail.debug /var/log/syslog -<p> 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.) -<p> If your system is set 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. -<p> 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. -<p> <b> Q. What should I check periodically? - -</b><br> 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. -<p> 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. -<p> <b> Q. I can't access the public archives. Why? - -</b><br> 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: -<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> -<p> <b> Q. Still having problems? Running QMail? - -</b><br> A. Make sure that you are using "preline" before calling the "mailman" - wrapper: -<p> |preline /home/mailman/mail/mailman post listname -<p> "preline" adds a Unix-style "From " header which the archiver requires. - You can fix the archive mbox files by adding: -<p> From somebody Mon Oct 9 12:27:34 MDT 2000 -<p> before every message and re-running the archive command - "bin/arch listname". The archives should now exist. See README.QMAIL - for more information. -<p> <b> Q. Still having problems? Running on GNU/Linux? - -</b><br> A. See the README.LINUX file. -<p> <b> Q. I want to get rid of some messages in my archive. How do I do - this? - -</b><br> A. David Rocher posts the following recipe: -<p> <li> - remove $prefix/archives/private/<em>listname</em> -<li> - edit $prefix/archives/private/<em>listname</em>.mbox/<em>listname</em>.mbox [optional] -<li> - run $prefix/bin/arch <em>listname</em> -<p> <b> Q. How secure are the authentication mechanisms used in Mailman's web - interface? - -</b><br> 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. -<p> 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: -<p> <li> - 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. -<p> <li> - 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. -<p> 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. -<p> 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. -<p> <li> - 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. -<p> <b> Q. I want to backup my lists. What do I need to save? - -</b><br> A. See this FAQ wizard entry: - <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> -<p> <b> Q. How do I rename a list? - -</b><br> 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. :( -<p> 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: -<p> - 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. -<p> % crontab -u mailman -e -<p> - 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. -<p> - 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. -<p> 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: -<p> RedirectMatch permanent /mailman/(.*)/oldname(.*) <a href="http://www.dom.ain/mailman/$1/newname$2">http://www.dom.ain/mailman/$1/newname$2</a> - RedirectMatch permanent /pipermail/oldname(.*) <a href="http://www.dom.ain/pipermail/newname$1">http://www.dom.ain/pipermail/newname$1</a> -<p> Add these to your httpd.conf file and restart Apache. -<p> - Now cd to the directory where you've installed Mailman. Let's - say it's /usr/local/mailman: -<p> % cd /usr/local/mailman -<p> and cd to the `lists' subdirectory: -<p> % cd lists -<p> You should now see the directory `oldname'. Move this to - `newname': -<p> % mv oldname newname -<p> - Now cd to the private archives directory: -<p> % cd ../archives/private -<p> 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: -<p> % mv oldname.mbox newname.mbox - % mv newname.mbox/oldname.mbox newname.mbox/newname.mbox -<p> - 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! -<p> % cd ../.. - % bin/move_list newname -<p> - You should now regenerate the public archives: -<p> % bin/arch newname -<p> - 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: -<p> o Go to the General options -<p> o Change the "real_name" option to reflect the new list's name, - e.g. "Newname" -<p> o Change the subject prefix to reflect the new list's name, - e.g. "[Newname] " (yes, that's a trailing space character). -<p> o Optionally, update other configuration fields like info, - description, or welcome_msg. YMMV. -<p> o Save your changes -<p> o Go to the Privacy options -<p> o Add the old list's address to acceptable_aliases. - E.g. "oldname@dom.ain". 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. -<p> o Save your changes -<p> - 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. -<p> o Find the lines defining the aliases for your old list's name -<p> o Copy and paste them just below the originals. -<p> o Change all the references of "oldname" to "newname" in the - pasted stanza. -<p> 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): -<p> XXX This needs updating for MM2.1! -<p> # Forward the oldname list to the newname list - oldname: newname@dom.ain - oldname-request: newname-request@dom.ain - oldname-admin: newname-admin@dom.ain - oldname-owner: newname-owner@dom.ain -<p> 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 -<p> o Run newaliases -<p> - 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: -<p> % cd /usr/local/mailman/qfiles - % grep oldname *.msg -<p> If you get no hits, skip to the next step, you've got nothing to - worry about. -<p> If you did get hits, then things get complicated. I warn you - that the rest of this step is untested. :( -<p> 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... -<p> Save the following Python code in a file called 'hackdb.py': -<p> -------------------------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() - ------------------------- -<p> And then for each file that matched your grep above, do the - following: -<p> % python hackdb.py reallylonghexfilenamematch1.db newname -<p> - It's now safe to turn your MTA back on. -<p> - Turn your qrunner back on by running -<p> % crontab -u mailman -e -<p> again and this time uncommenting the qrunner line. Save the file - and quit your editor. -<p> - 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. :) -<p> <p>
\ No newline at end of file |