\documentclass{howto}

\title{GNU Mailman - Installation Manual}
\author{Barry Warsaw}
\authoraddress{\email{barry(at)python.org}}

\date{\today}
\release{2.1}                   % software release, not documentation
\setreleaseinfo{}               % empty for final release
\setshortversion{2.1}           % major.minor only for software

\begin{document}

\maketitle

% This makes the Abstract go on a separate page in the HTML version;
% if a copyright notice is used, it should go immediately after this.
%
\ifhtml
\chapter*{Front Matter\label{front}}
\fi

\begin{abstract}
\noindent
This document describes how to install GNU Mailman on a POSIX-based system
such as \UNIX{}, MacOSX, or GNU/Linux.  It will cover basic installation
instructions, as well as guidelines for integrating Mailman with your web and
mail servers.

\noindent
The GNU Mailman website is at \url{http://www.list.org}
\end{abstract}

% The ugly "%begin{latexonly}" pseudo-environment supresses the table
% of contents for HTML generation.
%
%begin{latexonly}
\tableofcontents
%end{latexonly}


\section{Installation Requirements}

GNU Mailman works on most POSIX-based systems such as \UNIX{}, MacOSX, or
GNU/Linux.  It does not currently work on Windows.  You must have a mail
server that you can send messages to, and a web server that supports the
CGI/1.1 API.  \ulink{Apache}{http://httpd.apache.org} makes a fine choice for
web server, and mail servers such as
\ulink{Postfix}{http://www.postfix.org},
\ulink{Exim}{http://www.exim.org},
\ulink{Sendmail}{http://www.sendmail.org}, and
\ulink{qmail}{http://cr.yp.to/qmail.html} should
work just fine.

To install Mailman from source, you will need an ANSI C compiler to build
Mailman's security wrappers.  The
\ulink{GNU C compiler gcc}{http://gcc.gnu.org} 2.8.1 or later is known
to work well.

You must have the \ulink{Python}{http://www.python.org} interpreter installed
somewhere on your system.  Mailman 2.1 requires Python 2.1 or newer, although
Python 2.3 or newer is recommended.

\section{Set up your system}

Before installing Mailman, you need to prepare your system by adding certain
users and groups.  You will need to have root privileges to perform the steps
in this section.

\subsection{Add the group and user}

Mailman requires a unique user and group name which will own its files, and
under which its processes will run.  Mailman's basic security is based on
group ownership permissions, so it's important to get this step
right\footnote{You will be able to check and repair your permissions after
installation is complete.}.  Typically, you will add a new user and a new
group, both called \code{mailman}.  The \code{mailman} user must be a member
of the \code{mailman} group.  Mailman will be installed under the
\code{mailman} user and group, with the set-group-id (setgid) bit enabled.

If these names are already in use, you can choose different user and group
names, as long as you remember these when you run \program{configure}.  If you
choose a different unique user name, you will have to specify this with
\program{configure}'s \longprogramopt{with-username} option, and if you choose
a different group name, you will have to specify this with
\program{configure}'s \longprogramopt{with-groupname} option.

On Linux systems, you can use the following commands to create these
accounts.  Check your system's manual pages for details:

\begin{verbatim}
    % groupadd mailman
    % useradd -c''GNU Mailman'' -s /no/shell -d /no/home -g mailman mailman
\end{verbatim}

\subsection{Create the installation directory\label{create-install-dir}}
Typically, Mailman is installed into a single directory, which includes both
the Mailman source code and the run-time list and archive data.  It is
possible to split the static program files from the variable data files and
install them in separate directories.  This section will describe the
available options.

The default is to install all of Mailman to
\file{/usr/local/mailman}\footnote{This is the default for Mailman 2.1.
Earlier versions of Mailman installed everything under \file{/home/mailman} by
default.}.  You can change this base installation directory (referred to here
as \var{\$prefix}) by specifying the directory with the
\longprogramopt{prefix} \program{configure} option.  If you're upgrading from
a previous version of Mailman, you may want to use the \longprogramopt{prefix}
option unless you move your mailing lists.

\begin{notice}[warning]
You cannot install Mailman on a filesystem that is mounted with the
\code{nosuid} option.  This will break Mailman, which relies on setgid
programs for its security.  If this describes your environment, simply install
Mailman in a location that allows setgid programs.
\end{notice}

Make sure the installation directory is set to group \code{mailman} (or
whatever you're going to specify with \longprogramopt{with-groupname}) and has
the setgid bit set\footnote{BSD users should see the \ref{bsd-issues} section
for additional information.}.  You probably also want to guarantee that this
directory is readable and executable by everyone.  For example, these shell
commands will accomplish this:

\begin{verbatim}
    % cd $prefix
    % chgrp mailman .
    % chmod a+rx,g+ws .
\end{verbatim}

You are now ready to configure and install the Mailman software.

\section{Build and install Mailman\label{building}}

\subsection{Run \program{configure}}

Before you can install Mailman, you must run \program{configure} to set
various installation options your system might need.

\begin{notice}[note]
Take special note of the \longprogramopt{with-mail-gid} and
\longprogramopt{with-cgi-gid} options below.  You will probably need to use
these.
\end{notice}

You should \strong{not} be root while performing the steps in this section.
Do them under your own login, or whatever account you typically use to install
software.  You do not need to do these steps as user \code{mailman}, but you
could.  However, make sure that the login used is a member of the
\code{mailman} group as that that group has write permissions to the
\var{\$prefix} directory made in the previous step.  You must also have
permission to create a setgid file in the file system where it resides (NFS
and other mounts can be configured to inhibit setgid settings).

If you've installed other GNU software, you should be familiar with the
\program{configure} script.  Usually you can just \program{cd} to the
directory you unpacked the Mailman source tarball into, and run
\program{configure} with no arguments:

\begin{verbatim}
  % cd mailman-<version>
  % ./configure
  % make install
\end{verbatim}

The following options allow you to customize your Mailman
installation.

\begin{description}
\item[\longprogramopt{prefix}=\var{dir}]
    Standard GNU configure option which changes the base directory that
    Mailman is installed into.  By default \var{\$prefix} is
    \file{/usr/local/mailman}.  This directory must already exist, and be set
    up as described in \ref{create-install-dir}.

\item[\longprogramopt{exec-prefix}=\var{dir}]
    Standard GNU configure option which lets you specify a different
    installation directory for architecture dependent binaries.

\item[\longprogramopt{with-var-prefix}=\var{dir}]
    Store mutable data under \var{dir} instead of under the \var{\$prefix} or
    \var{\$exec_prefix}.  Examples of such data include the list archives and
    list settings database.

\item[\longprogramopt{with-python}=\file{/path/to/python}]
    Specify an alternative Python interpreter to use for the wrapper programs.
    The default is to use the interpreter found first on your shell's
    \var{\$PATH}.

\item[\longprogramopt{with-username}=\var{username-or-uid}]
    Specify a different username than \code{mailman}.  The value of this
    option can be an integer user id or a user name.  Be sure your
    \var{\$prefix} directory is owned by this user.

\item[\longprogramopt{with-groupname}=\var{groupname-or-gid}]
    Specify a different groupname than \code{mailman}.  The value of this
    option can be an integer group id or a group name.  Be sure your
    \var{\$prefix} directory is group-owned by this group.

\item[\longprogramopt{with-mail-gid}=\var{group-or-groups}]
    Specify an alternative group for running scripts via the mail wrapper.
    \var{group-or-groups} can be a list of one or more integer group ids or
    symbolic group names.  The first value in the list that resolves to an
    existing group is used.  By default, the value is the list \code{mailman},
    \code{other}, \code{mail}, and \code{daemon}.

    \begin{notice}[note]
    This is highly system dependent and you must get this right, because the
    group id is compiled into the mail wrapper program for added security.  On
    systems using \program{sendmail}, the \file{sendmail.cf} configuration
    file designates the group id of \program{sendmail} processes using the
    \var{DefaultUser} option.  (If commented out, it still may be indicating
    the default...)
    \end{notice}

    Check your mail server's documentation and configuration files to find the
    right value for this switch.

\item[\longprogramopt{with-cgi-gid}=\var{group-or-groups}]
    Specify an alternative group for running scripts via the CGI wrapper.
    \var{group-or-groups} can be a list of one or more integer group ids or
    symbolic group names.  The first value in the list that resolves to an
    existing group is used.  By default, the value is the the list
    \code{www}, \code{www-data}, and \code{nobody}.

    \begin{notice}[note]
    The proper value for this is dependent on your web server configuration.
    You must get this right, because the group id is compiled into the CGI
    wrapper program for added security, and no Mailman CGI scripts will run if
    this is incorrect.
    \end{notice}

    If you're using Apache, check the values for the \var{Group} option in
    your \file{httpd.conf} file.

\item[\longprogramopt{with-cgi-ext}=\var{extension}]
    Specify an extension for cgi-bin programs.  The CGI wrappers placed in
    \file{\var{\$prefix}/cgi-bin} will have this extension (some web servers
    require an extension).  \var{extension} must include the leading dot.

\item[\longprogramopt{with-mailhost}=\var{hostname}]
    Specify the fully qualified host name part for outgoing email.  After the
    installation is complete, this value can be overriden in
    \file{\var{\$prefix}/Mailman/mm_cfg.py}.

\item[\longprogramopt{with-urlhost}=\var{hostname}]
    Specify the fully qualified host name part of urls.  After the
    installation is complete, this value can be overriden in
    \file{\var{\$prefix}/Mailman/mm_cfg.py}.

\item[\longprogramopt{with-gcc}=no]
    Don't use gcc, even if it is found.  In this case, \program{cc} must be
    found on your \var{\$PATH}.

\end{description}

\subsection{Make and install}

Once you've run \program{configure}, you can simply run \program{make}, then
\program{make install} to build and install Mailman.

\section{Check your installation}

After you've run \program{make install}, you should check that your
installation has all the correct permissions and group ownerships by running
the \program{check_perms} script.  First change to the installation
(i.e. \var{\$prefix}) directory, then run the \program{bin/check_perms}
program.  Don't try to run bin/check_perms from the source directory; it will
only run from the installation directory.

If this reports no problems, then it's very likely <wink> that your
installation is set up correctly.  If it reports problems, then you can either
fix them manually, re-run the installation, or use \program{bin/check_perms}
to fix the problems (probably the easiest solution):

\begin{itemize}
\item You need to become the user that did the installation, and that owns all
      the files in \var{\$prefix}, or root.

\item Run \program{bin/check_perms -f}

\item Repeat previous step until no more errors are reported!
\end{itemize}

\section{Set up your web server}

Congratulations!  You've installed the Mailman software.  To get everything
running you need to hook Mailman up to both your web server and your mail
system.

If you plan on running your mail and web servers on different machines,
sharing Mailman installations via NFS, be sure that the clocks on those two
machines are synchronized closely.  You might take a look at the file
\file{Mailman/LockFile.py}; the constant \var{CLOCK_SLOP} helps the locking
mechanism compensate for clock skew in this type of environment.

This section describes some of the things you need to do to connect Mailman's
web interface to your web server.  The instructions here are somewhat geared
toward the Apache web server, so you should consult your web server
documentation for details.

You must configure your web server to enable CGI script permission in the
\file{\var{\$prefix}/cgi-bin} to run CGI scripts.  The line you should add
might look something like the following, with the real absolute directory
substituted for \var{\$prefix}, of course:

\begin{verbatim}
    Exec        /mailman/*      $prefix/cgi-bin/*
\end{verbatim}
% $ - emacs turd

  or:

\begin{verbatim}
    ScriptAlias /mailman/       $prefix/cgi-bin/
\end{verbatim}
% $ - emacs turd

\begin{notice}[warning]
You want to be very sure that the user id under which your CGI scripts run is
\strong{not} in the \code{mailman} group you created above, otherwise private
archives will be accessible to anyone.
\end{notice}

Copy the Mailman, Python, and GNU logos to a location accessible to your web
server.  E.g. with Apache, you've usually got an \file{icons} directory that
you can drop the images into.  For example:

\begin{verbatim}
    % cp $prefix/icons/*.{jpg,png} /path/to/apache/icons
\end{verbatim}

You then want to add a line to your \file{\var{\$prefix}/Mailman/mm_cfg.py}
file which sets the base URL for the logos.  For example:

\begin{verbatim}
  IMAGE_LOGOS = '/images/'
\end{verbatim}

The default value for \var{IMAGE_LOGOS} is \file{/icons/}.  Read the comment
in \file{Defaults.py.in} for details.

Configure your web server to point to the Pipermail public mailing list
archives.  For example, in Apache:

\begin{verbatim}
    Alias   /pipermail/     $varprefix/archives/public/
\end{verbatim}
% $ - emacs turd

where \var{\$varprefix} is usually \var{\$prefix} unless you've used the
\longprogramopt{with-var-prefix} option to \program{configure}.  Also be
sure to configure your web server to follow symbolic links in this directory,
otherwise public Pipermail archives won't be accessible.  For Apache users,
consult the \var{FollowSymLinks} option.

If you're going to be supporting internationalized public archives, you will
probably want to turn off any default charset directive for the Pipermail
directory, otherwise your multilingual archive pages won't show up correctly.
Here's an example for Apache, based on the standard installation directories:

\begin{verbatim}
    <Directory "/usr/local/mailman/archives/public/">
        AddDefaultCharset Off
    </Directory>
\end{verbatim}

Now restart your web server.

\section{Set up your mail server\label{mail-server}}

This section describes some of the things you need to do to connect Mailman's
email interface to your mail server.  The instructions here are different for
each mail server; if your mail server is not described in the following
subsections, try to generalize from the existing documentation, and consider
contributing documentation updates to the Mailman developers.

\subsection{Using the Postfix mail server}

Mailman should work pretty much out of the box with a standard Postfix
installation.  It has been tested with various Postfix versions up to and
including Postfix 2.1.5.

By default, Postfix treats \code{-owner} and \code{-request} addresses
specially.  Since you want Postfix to deliver such messages to Mailman, you
should turn off this option by adding this to your \file{main.cf} file:

\begin{verbatim}
    owner_request_special = no
\end{verbatim}

In order to support Mailman's optional VERP delivery, you will want to disable
\code{luser_relay} (the default) and you will want to set
\code{recipient_delimiter} for extended address semantics.  You should comment
out any \code{luser_relay} value in your \file{main.cf} and just go with the
defaults.  Also, add this to your \file{main.cf} file:

\begin{verbatim}
    recipient_delimiter = +
\end{verbatim}

Using \samp{+} as the delimiter works well with the default values for
\var{VERP_FORMAT} and \var{VERP_REGEXP} in \file{Defaults.py}.

When attempting to deliver a message to a non-existent local address, Postfix
may return a 450 error code.  Since this is a transient error code, Mailman
will continue to attempt to deliver the message for
\var{DELIVERY_RETRY_PERIOD} -- 5 days by default.  You might want to set
Postfix up so that it returns permanent error codes for non-existent local
users by adding the following to your \file{main.cf} file:

\begin{verbatim}
    unknown_local_recipient_reject_code = 550
\end{verbatim}

Finally, if you are using Postfix-style virtual domains, read the section on
virtual domain support below.

\subsubsection{Integrating Postfix and Mailman}

You can integrate Postfix and Mailman such that when new lists are created, or
lists are removed, Postfix's alias database will be automatically updated.
The following are the steps you need to take to make this work.

In the description below, we assume that you've installed Mailman in the
default location, i.e. \file{/usr/local/mailman}.  If that's not the case,
adjust the instructions according to your use of \program{configure}'s
\longprogramopt{prefix} and \longprogramopt{with-var-prefix} options.

\begin{notice}[note]
If you are using virtual domains and you want Mailman to honor your virtual
domains, read the \ref{postfix-virtual} section below first!
\end{notice}

\begin{itemize}
\item Add this to the bottom of the \file{\var{\$prefix}/Mailman/mm_cfg.py}
      file:

      \begin{verbatim}
        MTA = 'Postfix'
      \end{verbatim}

      The MTA variable names a module in the \file{Mailman/MTA} directory
      which contains the mail server-specific functions to be executed when a
      list is created or removed.

\item Look at the \file{Defaults.py} file for the variables
      \var{POSTFIX_ALIAS_CMD} and \var{POSTFIX_MAP_CMD} command.  Make sure
      these point to your \program{postalias} and \program{postmap} programs
      respectively.  Remember that if you need to make changes, do it in
      \file{mm_cfg.py}.

\item Run the \program{bin/genaliases} script to initialize your
      \file{aliases} file.

      \begin{verbatim}
        % cd /usr/local/mailman
        % bin/genaliases
      \end{verbatim}

      Make sure that the owner of the \file{data/aliases} and
      \file{data/aliases.db} file is \code{mailman} and that the group owner
      for those files is \code{mailman}, or whatever user and group you used
      in the configure command:

      \begin{verbatim}
        % su
        % chown mailman:mailman data/aliases*
      \end{verbatim}

\item Hack your Postfix's \file{main.cf} file to include the following path in
      your \var{alias_maps} variable:

      \begin{verbatim}
          /usr/local/mailman/data/aliases
      \end{verbatim}

      Note that there should be no trailing \code{.db}.  Do not include this
      in your \var{alias_database} variable.  This is because you do not want
      Postfix's \program{newaliases} command to modify Mailman's
      \file{aliases.db} file, but you do want Postfix to consult
      \file{aliases.db} when looking for local addresses.

      You probably want to use a \code{hash:} style database for this entry.
      Here's an example:

      \begin{verbatim}
        alias_maps = hash:/etc/postfix/aliases,
            hash:/usr/local/mailman/data/aliases
      \end{verbatim}

\item When you configure Mailman, use the
      \longprogramopt{with-mail-gid=mailman} switch; this will be the default
      if you configured Mailman after adding the \code{mailman} owner.
      Because the owner of the \file{aliases.db} file is \code{mailman},
      Postfix will execute Mailman's wrapper program as uid and gid
      \code{mailman}.

\end{itemize}

That's it!  One caveat: when you add or remove a list, the \file{aliases.db}
file will updated, but it will not automatically run \program{postfix reload}.
This is because you need to be root to run this and suid-root scripts are not
secure.  The only effect of this is that it will take about a minute for
Postfix to notice the change to the \file{aliases.db} file and update its
tables.

\subsubsection{Virtual domains\label{postfix-virtual}}

Postfix 2.0 supports ``virtual alias domains'', essentially what used to be
called ``Postfix-style virtual domains'' in earlier Postfix versions.  To make
virtual alias domains work with Mailman, you need to do some setup in both
Postfix and Mailman.  Mailman will write all virtual alias mappings to a file
called, by default, \file{/usr/local/mailman/data/virtual-mailman}.  It will
also use \program{postmap} to create the \program{virtual-mailman.db} file
that Postfix will actually use.

First, you need to set up the Postfix virtual alias domains as described in
the Postfix documentation (see Postfix's \code{virtual(5)} manpage).  Note
that it's your responsibility to include the \code{virtual-alias.domain
anything} line as described manpage; Mailman will not include this line in
\file{virtual-mailman}.  You are highly encouraged to make sure your virtual
alias domains are working properly before integrating with Mailman.

Next, add a path to Postfix's \var{virtual_alias_maps} variable, pointing to
the virtual-mailman file, e.g.:

\begin{verbatim}
    virtual_alias_maps = <your normal virtual alias files>,
        hash:/usr/local/mailman/data/virtual-mailman
\end{verbatim}

assuming you've installed Mailman in the default location.  If you're using an
older version of Postfix which doesn't have the \var{virtual_alias_maps}
variable, use the \var{virtual_maps} variable instead.

Next, in your \file{mm_cfg.py} file, you will want to set the variable
\var{POSTFIX_STYLE_VIRTUAL_DOMAINS} to the list of virtual domains that Mailman
should update.  This may not be all of the virtual alias domains that your
Postfix installation supports!  The values in this list will be matched
against the \var{host_name} attribute of mailing lists objects, and must be an
exact match.

Here's an example.  Say that Postfix is configured to handle the virtual
domains \code{dom1.ain}, \code{dom2.ain}, and \code{dom3.ain}, and further
that in your \file{main.cf} file you've got the following settings:

\begin{verbatim}
    myhostname = mail.dom1.ain
    mydomain = dom1.ain
    mydestination = $myhostname, localhost.$mydomain
    virtual_alias_maps =
        hash:/some/path/to/virtual-dom1,
        hash:/some/path/to/virtual-dom2,
        hash:/some/path/to/virtual-dom2
\end{verbatim}

If in your \file{virtual-dom1} file, you've got the following lines:

\begin{verbatim}
    dom1.ain  IGNORE
    @dom1.ain @mail.dom1.ain
\end{verbatim}

this tells Postfix to deliver anything addressed to \code{dom1.ain} to the
same mailbox at \code{mail.dom1.com}, its default destination.

In this case you would not include \code{dom1.ain} in
\var{POSTFIX_STYLE_VIRTUAL_DOMAINS} because otherwise Mailman will write
entries for mailing lists in the dom1.ain domain as

\begin{verbatim}
    mylist@dom1.ain         mylist
    mylist-request@dom1.ain mylist-request
    # and so on...
\end{verbatim}

The more specific entries trump your more general entries, thus breaking the
delivery of any \code{dom1.ain} mailing list.

However, you would include \code{dom2.ain} and \code{dom3.ain} in
\file{mm_cfg.py}:

\begin{verbatim}
    POSTFIX_STYLE_VIRTUAL_DOMAINS = ['dom2.ain', 'dom3.ain']
\end{verbatim}

Now, any list that Mailman creates in either of those two domains, will have
the correct entries written to \file{/usr/local/mailman/data/virtual-mailman}.

As above with the \file{data/aliases*} files, you want to make sure that both
\file{data/virtual-mailman} and \file{data/virtual-mailman.db} are user and
group owned by \code{mailman}.

\subsubsection{An alternative approach}

Fil \email{fil@rezo.net} has an alternative approach based on virtual maps and
regular expressions, as described at:

\begin{itemize}
\item (French)  \url{http://listes.rezo.net/comment.php}
\item (English) \url{http://listes.rezo.net/how.php}
\end{itemize}

This is a good (and simpler) alternative if you don't mind exposing an
additional hostname in the domain part of the addresses people will use to
contact your list.  I.e. if people should use \code{mylist@lists.dom.ain}
instead of \code{mylist@dom.ain}.

\subsection{Using the Exim mail server}

\begin{notice}[note]
This section is derived from Nigel Metheringham's ``HOWTO - Using Exim and
Mailman together'', which covers Mailman 2.0.x and Exim 3.  It has been
updated to cover Mailman 2.1 and Exim 4.  The original document is here:
\url{http://www.exim.org/howto/mailman.html}.
\end{notice}

There is no Mailman configuration needed other than the standard options
detailed in the Mailman install documentation.  The Exim configuration is
transparent to Mailman.  The user and group settings for Mailman must match
those in the config fragments given below.

\subsubsection{Exim configuration}

The Exim configuration is built so that a list created within Mailman
automatically appears to Exim without the need for defining any additional
aliases.

The drawback of this configuration is that it will work poorly on systems
supporting lists in several different mail domains.  While Mailman handles
virtual domains, it does not yet support having two distinct lists with the
same name in different virtual domains, using the same Mailman installation.
This will eventually change.  (But see below for a variation on this scheme
that should accommodate virtual domains better.)

The configuration file excerpts below are for use in an already functional
Exim configuration, which accepts mail for the domain in which the list
resides.  If this domain is separate from the others handled by your Exim
configuration, then you'll need to:

\begin{itemize}
\item add the list domain, ``my.list.domain'' to \var{local_domains}

\item add a ``domains=my.list.domain'' option to the director (router) for the
      list

\item (optional) exclude that domain from your other directors (routers)
\end{itemize}

\begin{notice}[note]
The instructions in this document should work with either Exim 3 or Exim 4.
In Exim 3, you must have a \var{local_domains} configuration setting; in Exim
4, you most likely have a \var{local_domains} domainlist.  If you don't, you
probably know what you're doing and can adjust accordingly.  Similarly, in
Exim 4 the concept of ``directors'' has disappeared -- there are only routers
now.  So if you're using Exim 4, whenever this document says ``director'',
read ``router''.
\end{notice}

Whether you are using Exim 3 or Exim 4, you will need to add some macros to
the main section of your Exim config file.  You will also need to define one
new transport.  With Exim 3, you'll need to add a new director; with Exim 4, a
new router plays the same role.

Finally, the configuration supplied here should allow co-habiting Mailman 2.0
and 2.1 installations, with the proviso that you'll probably want to use
\code{mm21} in place of \code{mailman} -- e.g., \var{MM21_HOME},
\var{mm21_transport}, etc.

\subsubsection{Main configuration settings}

First, you need to add some macros to the top of your Exim config file.  These
just make the director (router) and transport below a bit cleaner.  Obviously,
you'll need to edit these based on how you configured and installed Mailman.

\begin{verbatim}
    # Home dir for your Mailman installation -- aka Mailman's prefix
    # directory.
    MAILMAN_HOME=/usr/local/mailman
    MAILMAN_WRAP=MAILMAN_HOME/mail/mailman

    # User and group for Mailman, should match your --with-mail-gid
    # switch to Mailman's configure script.
    MAILMAN_USER=mailman
    MAILMAN_GROUP=mailman
\end{verbatim}

\subsubsection{Transport for Exim 3\label{exim3-transport}}

Add this to the transports section of your Exim config file,
i.e. somewhere between the first and second ``end'' line:

\begin{verbatim}
  mailman_transport:
    driver = pipe
    command = MAILMAN_WRAP \
              '${if def:local_part_suffix \
                    {${sg{$local_part_suffix}{-(\\w+)(\\+.*)?}{\$1}}} \
                    {post}}' \
              $local_part
    current_directory = MAILMAN_HOME
    home_directory = MAILMAN_HOME
    user = MAILMAN_USER
    group = MAILMAN_GROUP
\end{verbatim}

\subsubsection{Director for Exim 3}

If you're using Exim 3, you'll need to add the following director to your
config file (directors go between the second and third ``end'' lines).  Also,
don't forget that order matters -- e.g. you can make Mailman lists take
precedence over system aliases by putting this director in front of your
aliasfile director, or vice-versa.

\begin{verbatim}
  # Handle all addresses related to a list 'foo': the posting address.
  # Automatically detects list existence by looking
  # for lists/$local_part/config.pck under MAILMAN_HOME.
  mailman_director:
    driver = smartuser
    require_files = MAILMAN_HOME/lists/$local_part/config.pck
    suffix_optional
    suffix = -bounces : -bounces+* : \
             -confirm+* : -join : -leave : \
             -owner : -request : -admin
    transport = mailman_transport
\end{verbatim}

\subsubsection{Router for Exim 4}

In Exim 4, there's no such thing as directors -- you need to add a new router
instead.  Also, the canonical order of the configuration file was changed so
routers come before transports, so the router for Exim 4 comes first here.
Put this router somewhere after the ``begin routers'' line of your config
file, and remember that order matters.

\begin{verbatim}
  mailman_router:
    driver = accept
    require_files = MAILMAN_HOME/lists/$local_part/config.pck
    local_part_suffix_optional
    local_part_suffix = -bounces : -bounces+* : \
                        -confirm+* : -join : -leave : \
                        -owner : -request : -admin
    transport = mailman_transport
\end{verbatim}
% $ - emacs turds

\subsubsection{Transports for Exim 4}

The transport for Exim 4 is the same as for Exim 3 (see \ref{exim3-transport};
just copy the transport given above to somewhere under the ``begin
transports'' line of your Exim config file.

\subsubsection{Additional notes}

Exim should be configured to allow reasonable volume -- e.g. don't set
\var{max_recipients} down to a silly value -- and with normal degrees of
security -- specifically, be sure to allow relaying from 127.0.0.1, but pretty
much nothing else.  Parallel deliveries and other tweaks can also be used if
you like; experiment with your setup to see what works.  Delay warning
messages should be switched off or configured to only happen for non-list
mail, unless you like receiving tons of mail when some random host is down.

\subsubsection{Problems}

\begin{itemize}

\item Mailman will send as many \code{MAIL FROM}/\code{RCPT TO} as it needs.
      It may result in more than 10 or 100 messages sent in one connection,
      which will exceed the default value of Exim's
      \var{smtp_accept_queue_per_connection} value.  This is bad because it
      will cause Exim to switch into queue mode and severely delay delivery of
      your list messages.  The way to fix this is to set Mailman's
      \var{SMTP_MAX_SESSIONS_PER_CONNECTION} (in
      \file{\var{\$prefix}/Mailman/mm_cfg.py}) to a smaller value than Exim's
      \var{smtp_accept_queue_per_connection}.

\item Mailman should ignore Exim delay warning messages, even though Exim
      should never send this to list messages.  Mailman 2.1's general bounce
      detection and VERP support should greatly improve the bounce detector's
      hit rates.

\item List existence is determined by the existence of a \file{config.pck}
      file for a list.  If you delete lists by foul means, be aware of this.

\item If you are getting Exim or Mailman complaining about user ids when you
      send mail to a list, check that the \var{MAILMAN_USER} and
      \var{MAILMAN_GROUP} match those of Mailman itself (i.e. what were used
      in the \program{configure} script).  Also make sure you do not have
      aliases in the main alias file for the list.
\end{itemize}

\subsubsection{Receiver Verification}

Exim's receiver verification feature is very useful -- it lets Exim reject
unrouteable addresses at SMTP time.  However, this is most useful for
externally-originating mail that is addressed to mail in one of your local
domains.  For Mailman list traffic, mail originates on your server, and is
addressed to random external domains that are not under your control.
Furthermore, each message is addressed to many recipients
-- up to 500 if you use Mailman's default configuration and don't tweak
\var{SMTP_MAX_RCPTS}.

Doing receiver verification on Mailman list traffic is a recipe for trouble.
In particular, Exim will attempt to route every recipient addresses in
outgoing Mailman list posts.  Even though this requires nothing more than a
few DNS lookups for each address, it can still introduce significant delays.
Therefore, you should disable recipient verification for Mailman traffic.

Under Exim 3, put this in your main configuration section:

\begin{verbatim}
    receiver_verify_hosts = !127.0.0.1
\end{verbatim}

Under Exim 4, this is probably already taken care of for you by the default
recipient verification ACL statement (in the \code{RCPT TO} ACL):

\begin{verbatim}
  accept  domains       = +local_domains
          endpass
          message       = unknown user
          verify        = recipient
\end{verbatim}

which only does recipient verification on addresses in your domain.  (That's
not exactly the same as doing recipient verification only on messages coming
from non-127.0.0.1 hosts, but it should do the trick for Mailman.)

\subsubsection{SMTP Callback}

Exim's SMTP callback feature is an even more powerful way to detect bogus
sender addresses than normal sender verification.  Unfortunately, lots of
servers send bounce messages with a bogus address in the header, and there are
plenty that send bounces with bogus envelope senders (even though they're
supposed to just use an empty envelope sender for bounces).

In order to ensure that Mailman can disable/remove bouncing addresses, you
generally want to receive bounces for Mailman lists, even if those bounces are
themselves not bounceable.  Thus, you might want to disable SMTP callback on
bounce messages.

With Exim 4, you can accomplish this using something like the following in
your \code{RCPT TO} ACL:

\begin{verbatim}
  # Accept bounces to lists even if callbacks or other checks would fail
  warn     message      = X-WhitelistedRCPT-nohdrfromcallback: Yes
           condition    = \
           ${if and {{match{$local_part}{(.*)-bounces\+.*}} \
                     {exists {MAILMAN_HOME/lists/$1/config.pck}}} \
                {yes}{no}}
                {yes}{no}}

  accept   condition    = \
           ${if and {{match{$local_part}{(.*)-bounces\+.*}} \
                     {exists {MAILMAN_HOME/lists/$1/config.pck}}} \
                {yes}{no}}
                {yes}{no}}

  # Now, check sender address with SMTP callback.
  deny   !verify = sender/callout=90s
\end{verbatim}

If you also do SMTP callbacks on header addresses, you'll want something like
this in your \code{DATA} ACL:

\begin{verbatim}
  deny   !condition = $header_X-WhitelistedRCPT-nohdrfromcallback:
         !verify = header_sender/callout=90s
\end{verbatim}
% $ - emacs turd

\subsubsection{Doing VERP with Exim and Mailman}

VERP will send one email, with a separate envelope sender (return path), for
each of your subscribers -- read the information in
\file{\var{\$prefix}/Mailman/Default.py} for the options that start with VERP.
In a nutshell, all you need to do to enable VERP with Exim is to add these lines to \file{\var{\$prefix}/Mailman/mm_cfg.py}:

\begin{verbatim}
    VERP_PASSWORD_REMINDERS = Yes
    VERP_PERSONALIZED_DELIVERIES = Yes
    VERP_DELIVERY_INTERVAL = Yes
    VERP_CONFIRMATIONS = Yes
\end{verbatim}

(The director (router) above is smart enough to deal with VERP bounces.)

\subsubsection{Virtual Domains}

One approach to handling virtual domains is to use a separate Mailman
installation for each virtual domain.  Currently, this is the only way to have
lists with the same name in different virtual domains handled by the same
machine.

In this case, the \var{MAILMAN_HOME} and \var{MAILMAN_WRAP} macros are useless
-- you can remove them.  Change your director (router) to something like this:

\begin{verbatim}
  require_files = /virtual/${domain}/mailman/lists/${lc:$local_part}/config.pck
\end{verbatim}
% $ - emacs turd

and change your transport like this:

\begin{verbatim}
  command = /virtual/${domain}/mailman/mail/mailman \
            ${if def:local_part_suffix \
                 {${sg{$local_part_suffix}{-(\\w+)(\\+.*)?}{\$1}}}
                 {post}} \
              $local_part
  current_directory = /virtual/${domain}/mailman
  home_directory = /virtual/${domain}/mailman
\end{verbatim}
% $ - emacs turd

\subsubsection{List Verification}

This is how a set of address tests for the Exim lists look on a working
system.  The list in question is \email{quixote-users@mems-exchange.org}, and
these commands were run on the \code{mems-exchange.org} mail server ("% "
indicates the Unix shell prompt):

\begin{verbatim}
  % exim -bt quixote-users
  quixote-users@mems-exchange.org
    router = mailman_main_router, transport = mailman_transport

  % exim -bt quixote-users-request
  quixote-users-request@mems-exchange.org
    router = mailman_router, transport = mailman_transport

  % exim -bt quixote-users-bounces
  quixote-users-bounces@mems-exchange.org
    router = mailman_router, transport = mailman_transport

  % exim -bt quixote-users-bounces+luser=example.com
  quixote-users-bounces+luser=example.com@mems-exchange.org
    router = mailman_router, transport = mailman_transport
\end{verbatim}

If your \program{exim -bt} output looks something like this, that's a start:
at least it means Exim will pass the right messages to the right Mailman
commands.  It by no means guarantees that your Exim/Mailman installation is
functioning perfectly, though!

\subsubsection{Document History}

Originally written by Nigel Metheringham \email{postmaster@exim.org}.  Updated
by Marc Merlin \email{marc_soft@merlins.org} for Mailman 2.1, Exim 4.
Overhauled/reformatted/clarified/simplified by Greg Ward
\email{gward@python.net}.

\subsection{Using the Sendmail mail server}

\begin{notice}[warning]
You may be tempted to set the \var{DELIVERY_MODULE} configuration variable in
\file{mm_cfg.py} to \code{'Sendmail'} when using the Sendmail mail server.
\strong{Don't}.  The \file{Sendmail.py} module is misnamed -- it's really a
command line based message handoff scheme as opposed to the SMTP scheme used
in \file{SMTPDirect.py} (the default).  \file{Sendmail.py} has known security
holes and is provided as a proof-of-concept only\footnote{In fact, in later
versions of Mailman, this module is explicitly sabotaged.  You have to know
what you're doing in order to re-enable it.}.  If you are having problems
using \file{SMTPDirect.py} fix those instead of using \file{Sendmail.py}, or
you may open your system up to security exploits.
\end{notice}

\subsubsection{Sendmail ``smrsh'' compatibility}

Many newer versions of Sendmail come with a restricted execution utility
called ``smrsh'', which limits the executables that Sendmail will allow to be
used as mail programs.  You need to explicitly allow Mailman's wrapper program
to be used with smrsh or Mailman will not work.  If mail is not getting
delivered to Mailman's wrapper program and you're getting an ``operating
system error'' in your mail syslog, this could be your problem.

One good way of enabling this is:

\begin{itemize}
    \item Find out where your Sendmail executes its smrsh wrapper

          \begin{verbatim}
            % grep smrsh /etc/mail/sendmail.cf
          \end{verbatim}

    \item Figure out where smrsh expects symlinks for allowable mail
          programs.  At the very beginning of the following output you will
          see a full path to some directory, e.g. \file{/var/adm/sm.bin} or
          similar:

          \begin{verbatim}
            % strings $path_to_smrsh | less
          \end{verbatim}

    \item cd into \file{/var/adm/sm.bin}, or where ever it happens to reside
          on your system -- alternatives include \file{/etc/smrsh},
          \file{/var/smrsh} and \file{/usr/local/smrsh}.

          \begin{verbatim}
            % cd /var/adm/sm.bin
          \end{verbatim}

    \item Create a symbolic link to Mailman's wrapper program:

          \begin{verbatim}
            % ln -s /usr/local/mailman/mail/mailman mailman
          \end{verbatim}
\end{itemize}

\subsubsection{Integrating Sendmail and Mailman}

David Champion has contributed a recipe for more closely integrating Sendmail
and Mailman, such that Sendmail will automatically recognize and deliver to
new mailing lists as they are created, without having to manually edit alias
tables.

In the \file{contrib} directory of Mailman's source distribution, you will
find four files:

\begin{itemize}
\item \file{mm-handler.readme} - an explanation of how to set everything up
\item \file{mm-handler}        - the mail delivery agent (MDA)
\item \file{mailman.mc}        - a toy configuration file sample
\item \file{virtusertable}     - a sample for RFC 2142 address exceptions
\end{itemize}

\subsubsection{Performance notes}

One of the surest performance killers for Sendmail users is when Sendmail is
configured to synchronously verify the recipient's host via DNS.  If it does
this for messages posted to it from Mailman, you will get horrible
performance.  Since Mailman usually connects via \code{localhost}
(i.e. 127.0.0.1) to the SMTP port of Sendmail, you should be sure to configure
Sendmail to \strong{not} do DNS verification synchronously for localhost
connections.

\subsection{Using the Qmail mail server\label{qmail-issues}}

There are some issues that users of the qmail mail transport agent have
encountered.  None of the core maintainers use qmail, so all of this
information has been contributed by the Mailman user community, especially
Martin Preishuber and Christian Tismer, with notes by Balazs Nagy (BN) and
Norbert Bollow (NB).

\begin{itemize}
\item You might need to set the mail-gid user to either \code{qmail},
      \code{mailman}, or \code{nofiles} by using the
      \longprogramopt{with-mail-gid} \program{configure} option.

      \emph{BN:} it highly depends on your mail storing policy.  For example
      if you use the simple \file{~alias/.qmail-*} files, you can use
      \program{`id -g alias`}.  But if you use \file{/var/qmail/users}, the
      specified mail gid can be used.

      If you are going to be directing virtual domains directly to the
      \code{mailman} user (using ``virtualdomains'' on a list-only domain, for
      example), you will have to use \longprogramopt{with-mail-gid}=\var{gid
      of mailman user's group}.  This is incompatible with having list aliases
      in \file{~alias}, unless that alias simply forwards to
      \code{mailman-listname*}.

\item If there is a user \code{mailman} on your system, the alias
      \code{mailman-owner} will work only in \file{~mailman}.  You have to do
      a \program{touch .qmail-owner} in \file{~mailman} directory to create
      this alias.

      \emph{NB:} An alternative, IMHO better solution is to \program{chown
      root ~mailman}, that will stop qmail from considering \code{mailman} to
      be a user to whom mail can be delivered.  (See ``man 8 qmail-getpw''.)

\item In a related issue, if you have any users with the same name as one of
      your mailing lists, you will have problems if list names contain
      \samp{-} in them.  Putting \file{.qmail} redirections into the user's
      home directory doesn't work because the Mailman wrappers will not get
      spawned with the proper GID.  The solution is to put the following lines
      in the \file{/var/qmail/users/assign} file:

\begin{verbatim}
  +zope-:alias:112:11:/var/qmail/alias:-:zope-:
  .
\end{verbatim}

      where in this case the listname is e.g. \code{zope-users}.

      \emph{NB:} Alternatively, you could host the lists on a virtual domain,
      and use the \file{/var/qmail/control/virtualdomains} file to put the
      \code{mailman} user in charge of this virtual domain.

\item \emph{BN:}If inbound messages are delivered by another user than
      \code{mailman}, it's necessary to allow it to access \file{~mailman}.
      Be sure that \file{~mailman} has group writing access and setgid bit is
      set.  Then put the delivering user to \code{mailman} group, and you can
      deny access to \file{~mailman} to others.  Be sure that you can do the
      same with the WWW service.

      By the way the best thing is to make a virtual mail server to handle all
      of the mail.  \emph{NB:} E.g. make an additional "A" DNS record for the
      virtual mailserver pointing to your IP address, add the line
      \code{lists.kva.hu:mailman} to \file{/var/qmail/control/virtualdomains}
      and a \code{lists.kva.hu} line to \file{/var/qmail/control/rcpthosts}
      file.  Don't forget to HUP the qmail-send after modifying
      ``virtualdomains''.  Then every mail to lists.kva.hu will arrive to
      mail.kva.hu's mailman user.

      Then make your aliases:

\begin{verbatim}
          .qmail              => mailman@...'s letters
          .qmail-owner        => mailman-owner's letters
\end{verbatim}

      For list aliases, you can either create them manually:

\begin{verbatim}
          .qmail-list         => posts to the 'list' list
          .qmail-list-admin   => posts to the 'list's owner
          .qmail-list-request => requests to 'list'
          etc
\end{verbatim}

      or for automatic list alias handling (when using the lists.kva.hu
      virtual as above), see \file{contrib/qmail-to-mailman.py} in the Mailman
      source distribution.  Modify the \file{~mailman/.qmail-default} to
      include:

\begin{verbatim}
          |/path/to/python /path/to/qmail-to-mailman.py
\end{verbatim}

      and new lists will automatically be picked up.

\item You have to make sure that the localhost can relay.  If you start qmail
      via inetd and tcpenv, you need some line the following in your
      \file{/etc/hosts.allow} file:

\begin{verbatim}
      tcp-env: 127. 10.205.200 : setenv RELAYCLIENT
\end{verbatim}

      where 10.205.200. is your IP address block.  If you use tcpserver, then
      you need something like the following in your \file{/etc/tcp.smtp} file:

\begin{verbatim}
      10.205.200.:allow,RELAYCLIENT=""
      127.:allow,RELAYCLIENT=""
\end{verbatim}

\item \emph{BN:} Bigger \file{/var/qmail/control/concurrencyremote} values
      work better sending outbound messages, within reason.  Unless you know
      your system can handle it (many if not most cannot) this should not be
      set to a value greater than 120.

\item More information about setting up qmail and relaying can be found in the
      qmail documentation.
\end{itemize}

\emph{BN:} Last but not least, here's a little script to generate aliases to
your lists (if for some reason you can/will not have them automatically picked
up using \file{contrib/qmail-to-mailman.py}):

This script is for the Mailman 2.0 series:

\begin{verbatim}
#!/bin/sh
if [ $# = 1 ]; then
    i=$1
    echo Making links to $i in the current directory...
    echo "|preline /home/mailman/mail/mailman post $i" > .qmail-$i
    echo "|preline /home/mailman/mail/mailman mailowner $i" > .qmail-$i-admin
    echo "|preline /home/mailman/mail/mailman mailowner $i" > .qmail-$i-owner
    echo "|preline /home/mailman/mail/mailman mailowner $i" > .qmail-owner-$i
    echo "|preline /home/mailman/mail/mailman mailcmd $i" > .qmail-$i-request
fi
\end{verbatim}
% $ - emacs turd

\begin{notice}[note]
This is for a new Mailman 2.1 installation.  Users upgrading from
Mailman 2.0 would most likely change \file{/usr/local/mailman} to
\file{/home/mailman}.  If in doubt, refer to the \longprogramopt{prefix}
option passed to \program{configure} during compile time.
\end{notice}

\begin{verbatim}
#!/bin/sh
if [ $# = 1 ]; then
    i=$1
    echo Making links to $i in the current directory...
    echo "|preline /usr/local/mailman/mail/mailman post $i" > .qmail-$i
    echo "|preline /usr/local/mailman/mail/mailman admin $i" > .qmail-$i-admin
    echo "|preline /usr/local/mailman/mail/mailman bounces $i" > .qmail-$i-bounces
    # The following line is for VERP
    # echo "|preline /usr/local/mailman/mail/mailman bounces $i" > .qmail-$i-bounces-default
    echo "|preline /usr/local/mailman/mail/mailman confirm $i" > .qmail-$i-confirm
    echo "|preline /usr/local/mailman/mail/mailman join $i" > .qmail-$i-join
    echo "|preline /usr/local/mailman/mail/mailman leave $i" > .qmail-$i-leave
    echo "|preline /usr/local/mailman/mail/mailman owner $i" > .qmail-$i-owner
    echo "|preline /usr/local/mailman/mail/mailman request $i" > .qmail-$i-request
    echo "|preline /usr/local/mailman/mail/mailman subscribe $i" > .qmail-$i-subscribe
    echo "|preline /usr/local/mailman/mail/mailman unsubscribe $i" > .qmail-$i-unsubscribe
fi
\end{verbatim}
% $ - emacs turd

\subsubsection{Information on VERP}

You will note in the alias generating script for 2.1 above, there is a line
for VERP that has been commented out.  If you are interested in VERP there are
two options.  The first option is to allow Mailman to do the VERP formatting.
To activate this, uncomment that line and add the following lines to your
\file{mm_cfg.py} file:

\begin{verbatim}
    VERP_FORMAT = '%(bounces)s-+%(mailbox)s=%(host)s'
    VERP_REGEXP = r'^(?P<bounces>.*?)-\+(?P<mailbox>[^=]+)=(?P<host>[^@]+)@.*$'
\end{verbatim}
% $ - emacs turd

The second option is a patch on SourceForge located at:

\url{http://sourceforge.net/tracker/?func=detail\&atid=300103\&aid=645513\&group_id=103}

This patch currently needs more testing and might best be suitable for
developers or people well familiar with qmail.  Having said that, this patch
is the more qmail-friendly approach resulting in large performance gains.

\subsubsection{Virtual mail server}

As mentioned in the \ref{qmail-issues} section for a virtual mail server, a
patch under testing is located at:

\url{http://sf.net/tracker/index.php?func=detail\&aid=621257\&group_id=103\&atid=300103}

Again, this patch is for people familiar with their qmail installation.

\subsubsection{More information}

You might be interested in some information on modifying footers that Norbert
Bollow has written about Mailman and qmail, available here:

    \url{http://mailman.cis.to/qmail-verh/}

\section{Create a site-wide mailing list}

After you have completed the integration of Mailman and your mail server, you
need to create a ``site-wide'' mailing list.  This is the one that password
reminders will appear to come from, and it is required for proper Mailman
operation.  Usually this should be a list called \code{mailman}, but if you
need to change this, be sure to change the \var{MAILMAN_SITE_LIST} variable in
\file{mm_cfg.py}.  You can create the site list with this command, following
the prompts:

\begin{verbatim}
    % bin/newlist mailman
\end{verbatim}

Now configure your site list.  There is a convenient template for a generic
site list in the installation directory, under \file{data/sitelist.cfg} which
can help you with this.  You should review the configuration options in the
template, but note that any options not named in the \file{sitelist.cfg} file
won't be changed.

The template can be applied to your site list by
running:

\begin{verbatim}
    % bin/config_list -i data/sitelist.cfg mailman
\end{verbatim}

After applying the \file{sitelist.cfg} options, be sure you review the
site list's configuration via the admin pages.

You should also subscribe yourself to the site list.

\section{Set up cron}

Several Mailman features occur on a regular schedule, so you must set up
\program{cron} to run the right programs at the right time\footnote{Note that
if you're upgrading from a previous version of Mailman, you'll want to install
the new crontab, but be careful if you're running multiple Mailman
installations on your site!  Changing the crontab could mess with other
parallel Mailman installations.}.

If your version of crontab supports the \programopt{-u} option, you must be
root to do this next step.  Add \file{\var{\$prefix}/cron/crontab.in} as a
crontab entry by executing these commands:

\begin{verbatim}
    % cd $prefix/cron
    % crontab -u mailman crontab.in
\end{verbatim}

If you used the \longprogramopt{with-username} option, use that user name
instead of \code{mailman} for the \programopt{-u} argument value.  If your
crontab does not support the \programopt{-u} option, try these commands:

\begin{verbatim}
    % cd $prefix/cron
    % su - mailman
    % crontab crontab.in
\end{verbatim}

\section{Start the Mailman qrunner}

Mailman depends on a process called the ``qrunner'' to delivery all
email messages it sees.  You must start the qrunner by executing the following
command from the \var{\$prefix} directory:

\begin{verbatim}
    % bin/mailmanctl start
\end{verbatim}

You probably want to start Mailman every time you reboot your system.  Exactly
how to do this depends on your operating system.  If your OS supports the
\program{chkconfig} command (e.g. RedHat and Mandrake Linuxes) you can
do the following (as root, from the Mailman install directory):

\begin{verbatim}
    % cp scripts/mailman /etc/init.d/mailman
    % chkconfig --add mailman
\end{verbatim}

Note that \file{/etc/init.d} may be \file{/etc/rc.d/init.d} on some systems.

On Gentoo Linux, you can do the following:

\begin{verbatim}
    % cp scripts/mailman /etc/init.d/mailman
    % rc-update add mailman default
\end{verbatim}

On Debian, you probably want to use:

\begin{verbatim}
    % update-rc.d mailman defaults
\end{verbatim}

For \UNIX{}es that don't support \program{chkconfig}, you might try the
following set of commands:

\begin{verbatim}
    % cp scripts/mailman /etc/init.d/mailman
    % cp misc/mailman /etc/init.d
    % cd /etc/rc.d/rc0.d
    % ln -s ../init.d/mailman K12mailman
    % cd ../rc1.d
    % ln -s ../init.d/mailman K12mailman
    % cd ../rc2.d
    % ln -s ../init.d/mailman S98mailman
    % cd ../rc3.d
    % ln -s ../init.d/mailman S98mailman
    % cd ../rc4.d
    % ln -s ../init.d/mailman S98mailman
    % cd ../rc5.d
    % ln -s ../init.d/mailman S98mailman
    % cd ../rc6.d
    % ln -s ../init.d/mailman K12mailman
\end{verbatim}

\section{Check the hostname settings}

You should check the values for \var{DEFAULT_EMAIL_HOST} and
\var{DEFAULT_URL_HOST} in \file{Defaults.py}.  Make any necessary changes in
the \file{mm_cfg.py} file, \strong{not} in the \file{mm_cfg.py} file.  If you
change either of these two values, you'll want to add the following afterwards
in the \file{mm_cfg.py} file:

\begin{verbatim}
    add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)
\end{verbatim}

You will want to run the \program{bin/fix_url.py} to change the domain of any
existing lists.

\section{Customize Mailman\label{customizing}}

Now that Mailman is all set up, there are a few site-wide configurations you
can make before you start creating mailing lists.  You should do these steps
using the account you installed Mailman under in the \ref{building} section.

\begin{itemize}
\item The file \file{\var{\$prefix/Mailman/Defaults.py}} contains a number of
      defaults for your installation.  If any of these are incorrect, override
      them in \file{\var{\$prefix}/Mailman/mm_cfg.py}, \strong{not} in the
      \file{Defaults.py} file!  See the comments in \file{Defaults.py} for
      details.  Once a list is created, editing many of these variables will
      have no effect.  At that point, you'll need to configure your lists
      through the web administration interface or through the command line
      scripts \program{bin/withlist} and \program{bin/config_list}.

      The install process will never overwrite an existing \file{mm_cfg.py}
      file so you can freely make changes to this file.

      \begin{notice}[note]
      Do \strong{not} change the \var{HOME_DIR} or \var{MAILMAN_DIR}
      variables.  These are set automatically by the \program{configure}
      script, and you will break your Mailman installation by if you change
      these.
      \end{notice}
\item Create the site password.  Use this command:

\begin{verbatim}
    % $prefix/bin/mmsitepass <your-site-password>
\end{verbatim}

    This password can be used anywhere that individual user or mailing list
    administrator passwords are required, giving the mailman site
    administrator the ability to adjust these things when necessary.

    You may also want to create a password for the site-wide ``list creator''
    role.  The list creator is someone other than the site administrator who
    has privileges to create and remove lists through the web interface.  Use
    the \programopt{-c} option to \program{mmsitepass} to set this.

\end{itemize}

\section{Create your first mailing list}

For more detailed information about using Mailman, including creating and
configuring mailing lists, see the Mailman List Adminstration Manual.  These
instructions provide a quick guide to creating your first mailing list via the
web interface:

\begin{itemize}
\item Start by visiting the url \code{http://my.dom.ain/mailman/create}.

\item Fill out the form as described in the on-screen instructions, and in the
      ``List creator's password'' field, type the password you entered in
      section \ref{customizing}.  Type your own email address for the
      ``Initial list owner address'', and select ``Yes'' to notify the list
      administrator.

\item Click on the ``Create List'' button.

\item Check your email for a message from Mailman informing you that your new
      mailing list was created.

\item Now visit the list's administration page, either by following the link
      on the confirmation web page or clicking on the link from the email
      Mailman just sent you.  Typically the url will be something like
      \code{http://my.dom.ain/mailman/admin/mylist}.

\item Type in the list's password and click on ``Let me in...''

\item Click on ``Membership Management'' and then on ``Mass Subscription''.

\item Enter your email address in the big text field, and click on ``Submit
      Your Changes''.

\item Now go to your email and send a message to \code{mylist@my.dom.ain}.
      Within a minute or two you should see your message reflected back to you
      via Mailman.
\end{itemize}

Congratulations!  You've just set up and tested your first Mailman mailing
list.  If you had any problems along the way, please see the
\ref{troubleshooting} section.

\section{Troubleshooting\label{troubleshooting}}

If you encounter problems with running Mailman, first check the question and
answer section below.  If your problem is not covered there, check the
\ulink{online help}{http://www.list.org/help.html}, including the
\ulink{FAQ}{http://www.list.org/faq.html} and the
\ulink{interactive FAQ wizard}{http://www.python.org/cgi-bin/faqw-mm.py}.

Also check for errors in your syslog files, your mail and web server log files
and in Mailman's \file{\var{\$prefix}/logs/error} file.  If you're still
having problems, you should send a message to the
\email{mailman-users@python.org} mailing list\footnote{You must subscribe to
this mailing list in order to post to it, but the mailing list's archives are
publicly visible.}; see
\url{http://mail.python.org/mailman/listinfo/mailman-users} for more
information.

Be sure to including information on your operating system, which version of
Python you're using, and which version of Mailman you're installing.

Here is a list of some common questions and answers:

\begin{itemize}

\item \strong{Problem:} All Mailman web pages give a 404 File not found
      error.

      \strong{Solution:} Your web server has not been set up properly for
      handling Mailman's CGI programs.  Make sure you have:

      \begin{enumerate}
      \item configured the web server to give permissions to
            \file{\var{\$prefix}/cgi-bin}

      \item restarted the web server properly.
      \end{enumerate}

      Consult your web server's documentation for instructions on how to do
      check these issues.

\item \strong{Problem:} All Mailman web pages give an "Internal Server
      Error".

      \strong{Solution:} The likely problem is that you are using the wrong
      user or group for the CGI scripts.  Check your web server's log files.
      If you see a line like

      \begin{verbatim}
            Attempt to exec script with invalid gid 51, expected 99
      \end{verbatim}

      you will need to reinstall Mailman, specifying the proper CGI group id,
      as described in the \label{building} section.

\item \strong{Problem:} I send mail to the list, and get back mail saying the
       list is not found!

      \strong{Solution:} You probably didn't add the necessary aliases to the
      system alias database, or you didn't properly integration Mailman with
      your mail server.  Perhaps you didn't update the alias database, or your
      system requires you to run \program{newaliases} explicitly.  Refer to
      your server specific instructions in the \ref{mail-server} section.

\item \strong{Problem:} I send mail to the list, and get back mail saying,
      ``unknown mailer error''.

      \strong{Solution:} The likely problem is that you are using the wrong
      user or group id for the mail wrappers.  Check your mail server's log
      files; if you see a line like

      \begin{verbatim}
            Attempt to exec script with invalid gid 51, expected 99
      \end{verbatim}

      you will need to reinstall Mailman, specifying the proper mail group id
      as described in the \label{building} section.

\item \strong{Problem:} I use Postfix as my mail server and the mail wrapper
      programs are logging complaints about the wrong GID.

      \strong{Solution:} Make sure the \file{\var{\$prefix}/data/aliases.db}
      file is user owned by \code{mailman} (or whatever user name you used
      in the \program{configure} command).  If this file is not user owned by
      \code{mailman}, Postfix will not run the mail programs as the correct
      user.

\item \strong{Problem:} I use Sendmail as my mail server, and when I send mail
      to the list, I get back mail saying, ``sh: mailman not available for
      sendmail programs''.

      \strong{Solution:} Your system uses the Sendmail restricted shell
      (smrsh). You need to configure smrsh by creating a symbolic link from
      the mail wrapper (\file{\var{\$prefix}/mail/mailman}) to the directory
      identifying executables allowed to run under smrsh.

      Some common names for this directory are \file{/var/admin/sm.bin},
      \file{/usr/admin/sm.bin} or \file{/etc/smrsh}.

      Note that on Debian Linux, the system makes \file{/usr/lib/sm.bin},
      which is wrong, you will need to create the directory
      \file{/usr/admin/sm.bin} and add the link there.  Note further any
      aliases \program{newaliases} spits out will need to be adjusted to point
      to the secure link to the wrapper.

\item \strong{Problem:}  I messed up when I called \program{configure}.  How
      do I clean things up and re-install?

      \strong{Solution:}

      \begin{verbatim}
        % make clean
        % ./configure --with-the-right-options
        % make install
      \end{verbatim}

\end{itemize}

\section{Platform and operating system notes}

Generally, Mailman runs on any POSIX-based system, such as Solaris, the
various BSD variants, Linux systems, MacOSX, and other generic \UNIX{}
systems.  It doesn't run on Windows.  For the most part, the generic
instructions given in this document should be sufficient to get Mailman
working on any supported platform.  Some operating systems have additional
recommended installation or configuration instructions.

\subsection{GNU/Linux issues}

Linux seems to be the most popular platform for running Mailman.  Here are
some hints on getting Mailman to run on Linux:

\begin{itemize}
\item If you are getting errors with hard link creations and/or you are using
      a special secure kernel (securelinux/openwall/grsecurity), see the file
      \file{contrib/README.check_perms_grsecurity} in the Mailman source
      distribution.

      Note that if you are using Linux Mandrake in secure mode, you are
      probably concerned by this.

\item Apparently Mandrake 9.0 changed the permissions on gcc, so if you build
      as the \code{mailman} user, you need to be sure \code{mailman} is in the
      \code{cctools} group.

\item If you installed Python from your Linux distribution's package manager
      (e.g. .rpms for Redhat-derived systems or .deb for Debian), you must
      install the ``development'' package of Python, or you may not get
      everything you need.

      For example, using Python 2.2 on Debian, you will need to install the
      \code{python2.2-dev} package.  On Redhat, you probably need the
      \code{python2-devel} package.

      If you install Python from source, you should be fine.

      One symptom of this problem, although for unknown reasons, is that you
      might get an error such as this during your install:

      \begin{verbatim}
          Traceback (most recent call last):
            File "bin/update", line 44, in ?
              import paths
          ImportError: No module named paths
          make: *** [update] Error 1
      \end{verbatim}

      If this happens, install the Python development package and try
      \program{configure} and \program{make install} again.  Or install the
      latest version of Python from source, available from
      \url{http://www.python.org}.

      This problem can manifest itself in other Linux distributions in
      different ways, although usually it appears as \code{ImportErrors}.
\end{itemize}

\subsection{BSD issues\label{bsd-issues}}

Vivek Khera writes that some BSDs do nightly security scans for setuid file
changes.  setgid directories also come up on the scan when they change.  Also,
the setgid bit is not necessary on BSD systems because group ownership is
automatically inherited on files created in directories.  On other \UNIX{}es,
this only happens when the directory has the setgid bit turned on.

To install without turning on the setgid bit on directories, simply pass in
the \var{DIRSETGID} variable to \program{make}, after you've run
\program{configure}:

\begin{verbatim}
    % make DIRSETGID=: install
\end{verbatim}

This disables the \program{chmod g+s} command on installed directories.

\subsection{MacOSX issues}

Many people run Mailman on MacOSX.  Here are some pointers that have been
collected on getting Mailman to run on MacOSX.

\begin{itemize}
\item Jaguar (MacOSX 10.2) comes with Python 2.2.  While this isn't the very
      latest stable version of Python, it ought to be sufficient to run
      Mailman 2.1.

\item David B. O'Donnell has a web page describing his configuration of
      Mailman 2.0.13 and Postfix on MacOSX Server.

      \url{http://www.afp548.com/Articles/mail/python-mailman.html}

\item Kathleen Webb posted her experiences in getting Mailman running on
      Jaguar using Sendmail.

      \url{http://mail.python.org/pipermail/mailman-users/2002-October/022944.html}

\item Panther server (MacOSX 10.3) comes with Mailman; Apple has a tech
      document about a problem you might encounter running Mailman on Mac OS X
      Server 10.3:

      \url{http://docs.info.apple.com/article.html?artnum=107889}
\end{itemize}

\end{document}