Mailman - The GNU Mailing List Management System
Copyright (C) 1998 by the Free Software Foundation, Inc.
59 Temple Place - Suite 330, Boston, MA 02111-1307, USA

FREQUENTLY ASKED QUESTIONS

1. If from the web you get "document contains no data"
   If mail isn't getting delivered
   If you see "Premature end of script headers"
   If you see "Mailman CGI error!!!"

      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 INSTALL 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, 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 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.

2. If the web pages hang:

      CERN Web servers might leave Python processes running, and in
      some cases might hang the CGI completely.  In that case, switch
      to Apache.

3. Check ~mailman/logs/error periodically:

      Many of the scripts have their stderr logged to
      ~mailman/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.

      One thing that is *not* caught by stderr hook is syntax errors,
      but any of these should have been caught in the installation
      phase, which byte-compiles all .py files in the distribution.
      There may be syntax errors lurking if you hacked the code, or in 
      the scripts that are not modules.

      You can always use the Python module `compile' or `compileall'
      to force byte compilation of a file, or just fire up the Python
      interpreter and try importing the module!
    
4. Other debugging aids

      If you get exceptions in the log and/or Web pages, and these are
      complaining that files could not be opened, you might like to
      see which files Mailman is trying to open!

      In Python 1.5.2, this will be a standard part of the exception
      message.  In Python 1.5.1 the best you can do is to comment out
      the code in $prefix/scripts/driver where it is redefining the
      built-in open function.  This simulates what Python 1.5.2 will
      do when it raises an IOError exception, however this only works
      for open().  While this is the most common case, Python 1.5.2
      will handle many other cases where files are unsuccessfully
      referenced.

5. Why doesn't the archive link work?

      Have any messages been posted to the list?  This is a known
      buglet; the archive link doesn't work until at least one message 
      has been posted.

6. Okay, the archive link works, but I can't access the public
   archives.

      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://www.python.org/pipermail/mailman-users/1998-November/000173.html

7. Still having problems?  Running on Linux?

    See the README.LINUX file.

8. I want to get rid of some messages in my archive.  How do I do
   this?

   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> 
	   $prefix/archives/private/<listname>.mbox/<listname>.mbox

9. I set member_posting_only to yes because I want to limit posts to
   members only, however it seems like all messages coming from
   members are held for approval.

   There appears to be a problem on some systems where the envelope
   sender (e.g. the Unix "From " line) is set incorrectly.  This will
   cause a negative match when checking to see if the sender is a
   member of the list.  Until 1.0b12, Mailman defaulted to using the
   envelope sender before the sender (i.e. "From:" header) because the
   former is set by the SMTP agent while the latter is easily
   spoofable by the end user.

   [ The possible causes for envelope sender munging taking place are
     many, but the "owner-alias" sendmail feature probably deserves
     special mention:

     If mail arrives for list "foo", and there is an alias entry for
     "owner-foo" as well, the envelope sender of the message will be
     changed to the single-level expansion of the "owner-foo" alias.

     Code has been included in post-1.0rc2 Mailman releases to try
     working around the problem this (unconfigurable) sendmail feature
     constitutes.  Prior to this, some people worked around the
     problem by not including the suggested "owner-LISTNAME" alias
     entries for Mailman lists in their alias files. ]

   However, if you are having this problem, you may opt to favor the
   From: header over the envelope sender.  Do this by adding the
   following line to your mm_cfg.py file:

   USE_ENVELOPE_SENDER=0

   if you want (arguably) more security, add this to your mm_cfg.py
   file:

   USE_ENVELOPE_SENDER=1

   However, read the comments about this variable in the Defaults.py
   file for a full discussion of the issues.

10. How secure are the authentication mechanisms used in Mailman's web
    interface?

   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.  The cookie will only work for a limited
        time, and only on connections made from the same IP number as
        the password-authenticating connection.

        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 easier exploitable 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 expiry 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.



Local Variables:
mode: text
indent-tabs-mode: nil
End:
