#GNU Mailman - Installation Manual About this document... About this
document...
Previous Page Up One Level Next Page GNU Mailman - Installation Manual
_________________________________________________________________
GNU Mailman - Installation Manual
Barry Warsaw
barry(at)python.org
Release 2.1
December 22, 2004
Front Matter
Abstract:
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.
The GNU Mailman website is at http://www.list.org
1 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. Apache makes a fine choice for web server, and mail
servers such as Postfix, Exim, Sendmail, and qmail should work just
fine.
To install Mailman from source, you will need an ANSI C compiler to
build Mailman's security wrappers. The GNU C compiler gcc 2.8.1 or
later is known to work well.
You must have the Python interpreter installed somewhere on your
system. Mailman 2.1 requires Python 2.1 or newer, although Python 2.3
or newer is recommended.
2 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.
2.1 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 right1. Typically, you will add a new user and a new
group, both called mailman. The mailman user must be a member of the
mailman group. Mailman will be installed under the 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 configure. If
you choose a different unique user name, you will have to specify this
with configure's --with-username option, and if you choose a different
group name, you will have to specify this with configure's
--with-groupname option.
On Linux systems, you can use the following commands to create these
accounts. Check your system's manual pages for details:
% groupadd mailman
% useradd -c''GNU Mailman'' -s /no/shell -d /no/home -g mailman mailman
2.2 Create the installation directory
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 /usr/local/mailman2. You
can change this base installation directory (referred to here as
$prefix) by specifying the directory with the --prefix configure
option. If you're upgrading from a previous version of Mailman, you
may want to use the --prefix option unless you move your mailing
lists.
Warning: You cannot install Mailman on a filesystem that is mounted
with the 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.
Make sure the installation directory is set to group mailman (or
whatever you're going to specify with --with-groupname) and has the
setgid bit set3. You probably also want to guarantee that this
directory is readable and executable by everyone. For example, these
shell commands will accomplish this:
% cd $prefix
% chgrp mailman .
% chmod a+rx,g+ws .
You are now ready to configure and install the Mailman software.
3 Build and install Mailman
3.1 Run configure
Before you can install Mailman, you must run configure to set various
installation options your system might need.
Note: Take special note of the --with-mail-gid and --with-cgi-gid
options below. You will probably need to use these.
You should 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 mailman,
but you could. However, make sure that the login used is a member of
the mailman group as that that group has write permissions to the
$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 configure script. Usually you can just cd to the directory you
unpacked the Mailman source tarball into, and run configure with no
arguments:
% cd mailman-<version>
% ./configure
% make install
The following options allow you to customize your Mailman
installation.
--prefix=dir
Standard GNU configure option which changes the base directory
that Mailman is installed into. By default $prefix is
/usr/local/mailman. This directory must already exist, and be
set up as described in 2.2.
--exec-prefix=dir
Standard GNU configure option which lets you specify a
different installation directory for architecture dependent
binaries.
--with-var-prefix=dir
Store mutable data under dir instead of under the $prefix or
$exec_prefix. Examples of such data include the list archives
and list settings database.
--with-python=/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 $PATH.
--with-username=username-or-uid
Specify a different username than mailman. The value of this
option can be an integer user id or a user name. Be sure your
$prefix directory is owned by this user.
--with-groupname=groupname-or-gid
Specify a different groupname than mailman. The value of this
option can be an integer group id or a group name. Be sure your
$prefix directory is group-owned by this group.
--with-mail-gid=group-or-groups
Specify an alternative group for running scripts via the mail
wrapper. 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 mailman, other, mail, and daemon.
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 sendmail, the
sendmail.cf configuration file designates the group id of
sendmail processes using the DefaultUser option. (If commented
out, it still may be indicating the default...)
Check your mail server's documentation and configuration files
to find the right value for this switch.
--with-cgi-gid=group-or-groups
Specify an alternative group for running scripts via the CGI
wrapper. 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 www, www-data, and nobody.
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.
If you're using Apache, check the values for the Group option
in your httpd.conf file.
--with-cgi-ext=extension
Specify an extension for cgi-bin programs. The CGI wrappers
placed in $prefix/cgi-bin will have this extension (some web
servers require an extension). extension must include the
leading dot.
--with-mailhost=hostname
Specify the fully qualified host name part for outgoing email.
After the installation is complete, this value can be overriden
in $prefix/Mailman/mm_cfg.py.
--with-urlhost=hostname
Specify the fully qualified host name part of urls. After the
installation is complete, this value can be overriden in
$prefix/Mailman/mm_cfg.py.
--with-gcc=no
Don't use gcc, even if it is found. In this case, cc must be
found on your $PATH.
3.2 Make and install
Once you've run configure, you can simply run make, then make install
to build and install Mailman.
4 Check your installation
After you've run make install, you should check that your installation
has all the correct permissions and group ownerships by running the
check_perms script. First change to the installation (i.e. $prefix)
directory, then run the 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
bin/check_perms to fix the problems (probably the easiest solution):
* You need to become the user that did the installation, and that
owns all the files in $prefix, or root.
* Run bin/check_perms -f
* Repeat previous step until no more errors are reported!
5 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 Mailman/LockFile.py; the constant 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 $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 $prefix, of course:
Exec /mailman/* $prefix/cgi-bin/*
or:
ScriptAlias /mailman/ $prefix/cgi-bin/
Warning: You want to be very sure that the user id under which your
CGI scripts run is not in the mailman group you created above,
otherwise private archives will be accessible to anyone.
Copy the Mailman, Python, and GNU logos to a location accessible to
your web server. E.g. with Apache, you've usually got an icons
directory that you can drop the images into. For example:
% cp $prefix/icons/*.{jpg,png} /path/to/apache/icons
You then want to add a line to your $prefix/Mailman/mm_cfg.py file
which sets the base URL for the logos. For example:
IMAGE_LOGOS = '/images/'
The default value for IMAGE_LOGOS is /icons/. Read the comment in
Defaults.py.in for details.
Configure your web server to point to the Pipermail public mailing
list archives. For example, in Apache:
Alias /pipermail/ $varprefix/archives/public/
where $varprefix is usually $prefix unless you've used the
--with-var-prefix option to 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 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:
<Directory "/usr/local/mailman/archives/public/">
AddDefaultCharset Off
</Directory>
Now restart your web server.
6 Set up your 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.
6.1 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 -owner and -request addresses specially.
Since you want Postfix to deliver such messages to Mailman, you should
turn off this option by adding this to your main.cf file:
owner_request_special = no
In order to support Mailman's optional VERP delivery, you will want to
disable luser_relay (the default) and you will want to set
recipient_delimiter for extended address semantics. You should comment
out any luser_relay value in your main.cf and just go with the
defaults. Also, add this to your main.cf file:
recipient_delimiter = +
Using "+" as the delimiter works well with the default values for
VERP_FORMAT and VERP_REGEXP in 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
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 main.cf file:
unknown_local_recipient_reject_code = 550
Finally, if you are using Postfix-style virtual domains, read the
section on virtual domain support below.
6.1.1 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. /usr/local/mailman. If that's not the case,
adjust the instructions according to your use of configure's --prefix
and --with-var-prefix options.
Note: If you are using virtual domains and you want Mailman to honor
your virtual domains, read the 6.1 section below first!
* Add this to the bottom of the $prefix/Mailman/mm_cfg.py file:
MTA = 'Postfix'
The MTA variable names a module in the Mailman/MTA directory which
contains the mail server-specific functions to be executed when a
list is created or removed.
* Look at the Defaults.py file for the variables POSTFIX_ALIAS_CMD
and POSTFIX_MAP_CMD command. Make sure these point to your
postalias and postmap programs respectively. Remember that if you
need to make changes, do it in mm_cfg.py.
* Run the bin/genaliases script to initialize your aliases file.
% cd /usr/local/mailman
% bin/genaliases
Make sure that the owner of the data/aliases and data/aliases.db
file is mailman and that the group owner for those files is
mailman, or whatever user and group you used in the configure
command:
% su
% chown mailman:mailman data/aliases*
* Hack your Postfix's main.cf file to include the following path in
your alias_maps variable:
/usr/local/mailman/data/aliases
Note that there should be no trailing .db. Do not include this in
your alias_database variable. This is because you do not want
Postfix's newaliases command to modify Mailman's aliases.db file,
but you do want Postfix to consult aliases.db when looking for
local addresses.
You probably want to use a hash: style database for this entry.
Here's an example:
alias_maps = hash:/etc/postfix/aliases,
hash:/usr/local/mailman/data/aliases
* When you configure Mailman, use the --with-mail-gid=mailman
switch; this will be the default if you configured Mailman after
adding the mailman owner. Because the owner of the aliases.db file
is mailman, Postfix will execute Mailman's wrapper program as uid
and gid mailman.
That's it! One caveat: when you add or remove a list, the aliases.db
file will updated, but it will not automatically run 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 aliases.db file and
update its tables.
6.1.2 Virtual domains
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,
/usr/local/mailman/data/virtual-mailman. It will also use postmap to
create the 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 virtual(5)
manpage). Note that it's your responsibility to include the
virtual-alias.domain anything line as described manpage; Mailman will
not include this line in 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 virtual_alias_maps variable, pointing to
the virtual-mailman file, e.g.:
virtual_alias_maps = <your normal virtual alias files>,
hash:/usr/local/mailman/data/virtual-mailman
assuming you've installed Mailman in the default location. If you're
using an older version of Postfix which doesn't have the
virtual_alias_maps variable, use the virtual_maps variable instead.
Next, in your mm_cfg.py file, you will want to set the variable
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 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 dom1.ain, dom2.ain, and dom3.ain, and further that in
your main.cf file you've got the following settings:
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
If in your virtual-dom1 file, you've got the following lines:
dom1.ain IGNORE
@dom1.ain @mail.dom1.ain
this tells Postfix to deliver anything addressed to dom1.ain to the
same mailbox at mail.dom1.com, its default destination.
In this case you would not include dom1.ain in
POSTFIX_STYLE_VIRTUAL_DOMAINS because otherwise Mailman will write
entries for mailing lists in the dom1.ain domain as
mylist@dom1.ain mylist
mylist-request@dom1.ain mylist-request
# and so on...
The more specific entries trump your more general entries, thus
breaking the delivery of any dom1.ain mailing list.
However, you would include dom2.ain and dom3.ain in mm_cfg.py:
POSTFIX_STYLE_VIRTUAL_DOMAINS = ['dom2.ain', 'dom3.ain']
Now, any list that Mailman creates in either of those two domains,
will have the correct entries written to
/usr/local/mailman/data/virtual-mailman.
As above with the data/aliases* files, you want to make sure that both
data/virtual-mailman and data/virtual-mailman.db are user and group
owned by mailman.
6.1.3 An alternative approach
Fil fil@rezo.net has an alternative approach based on virtual maps and
regular expressions, as described at:
* (French) http://listes.rezo.net/comment.php
* (English) http://listes.rezo.net/how.php
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
mylist@lists.dom.ain instead of mylist@dom.ain.
6.2 Using the Exim mail server
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: http://www.exim.org/howto/mailman.html.
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.
6.2.1 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:
* add the list domain, ``my.list.domain'' to local_domains
* add a ``domains=my.list.domain'' option to the director (router)
for the list
* (optional) exclude that domain from your other directors (routers)
Note: The instructions in this document should work with either Exim 3
or Exim 4. In Exim 3, you must have a local_domains configuration
setting; in Exim 4, you most likely have a 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''.
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 mm21 in place of mailman - e.g., MM21_HOME,
mm21_transport, etc.
6.2.2 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.
# 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
6.2.3 Transport for Exim 3
Add this to the transports section of your Exim config file, i.e.
somewhere between the first and second ``end'' line:
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
6.2.4 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.
# 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
6.2.5 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.
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
6.2.6 Transports for Exim 4
The transport for Exim 4 is the same as for Exim 3 (see 6.2; just copy
the transport given above to somewhere under the ``begin transports''
line of your Exim config file.
6.2.7 Additional notes
Exim should be configured to allow reasonable volume - e.g. don't set
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.
6.2.8 Problems
* Mailman will send as many MAIL FROM/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
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 SMTP_MAX_SESSIONS_PER_CONNECTION (in
$prefix/Mailman/mm_cfg.py) to a smaller value than Exim's
smtp_accept_queue_per_connection.
* 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.
* List existence is determined by the existence of a config.pck file
for a list. If you delete lists by foul means, be aware of this.
* If you are getting Exim or Mailman complaining about user ids when
you send mail to a list, check that the MAILMAN_USER and
MAILMAN_GROUP match those of Mailman itself (i.e. what were used
in the configure script). Also make sure you do not have aliases
in the main alias file for the list.
6.2.9 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 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:
receiver_verify_hosts = !127.0.0.1
Under Exim 4, this is probably already taken care of for you by the
default recipient verification ACL statement (in the RCPT TO ACL):
accept domains = +local_domains
endpass
message = unknown user
verify = recipient
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.)
6.2.10 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 RCPT TO ACL:
# 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
If you also do SMTP callbacks on header addresses, you'll want
something like this in your DATA ACL:
deny !condition = $header_X-WhitelistedRCPT-nohdrfromcallback:
!verify = header_sender/callout=90s
6.2.11 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
$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 $prefix/Mailman/mm_cfg.py:
VERP_PASSWORD_REMINDERS = Yes
VERP_PERSONALIZED_DELIVERIES = Yes
VERP_DELIVERY_INTERVAL = Yes
VERP_CONFIRMATIONS = Yes
(The director (router) above is smart enough to deal with VERP
bounces.)
6.2.12 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 MAILMAN_HOME and MAILMAN_WRAP macros are useless -
you can remove them. Change your director (router) to something like
this:
require_files = /virtual/${domain}/mailman/lists/${lc:$local_part}/config.pck
and change your transport like this:
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
6.2.13 List Verification
This is how a set of address tests for the Exim lists look on a
working system. The list in question is
quixote-users@mems-exchange.org, and these commands were run on the
mems-exchange.org mail server ("indicates the Unix shell prompt):
% 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
If your 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!
6.2.14 Document History
Originally written by Nigel Metheringham postmaster@exim.org. Updated
by Marc Merlin marc_soft@merlins.org for Mailman 2.1, Exim 4.
Overhauled/reformatted/clarified/simplified by Greg Ward
gward@python.net.
6.3 Using the Sendmail mail server
Warning: You may be tempted to set the DELIVERY_MODULE configuration
variable in mm_cfg.py to 'Sendmail' when using the Sendmail mail
server. Don't. The Sendmail.py module is misnamed - it's really a
command line based message handoff scheme as opposed to the SMTP
scheme used in SMTPDirect.py (the default). Sendmail.py has known
security holes and is provided as a proof-of-concept only4. If you are
having problems using SMTPDirect.py fix those instead of using
Sendmail.py, or you may open your system up to security exploits.
6.3.1 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:
* Find out where your Sendmail executes its smrsh wrapper
% grep smrsh /etc/mail/sendmail.cf
* 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. /var/adm/sm.bin or
similar:
% strings $path_to_smrsh | less
* cd into /var/adm/sm.bin, or where ever it happens to reside on
your system - alternatives include /etc/smrsh, /var/smrsh and
/usr/local/smrsh.
% cd /var/adm/sm.bin
* Create a symbolic link to Mailman's wrapper program:
% ln -s /usr/local/mailman/mail/mailman mailman
6.3.2 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 contrib directory of Mailman's source distribution, you will
find four files:
* mm-handler.readme - an explanation of how to set everything up
* mm-handler - the mail delivery agent (MDA)
* mailman.mc - a toy configuration file sample
* virtusertable - a sample for RFC 2142 address exceptions
6.3.3 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
localhost (i.e. 127.0.0.1) to the SMTP port of Sendmail, you should be
sure to configure Sendmail to not do DNS verification synchronously
for localhost connections.
6.4 Using the Qmail mail server
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).
* You might need to set the mail-gid user to either qmail, mailman,
or nofiles by using the --with-mail-gid configure option.
BN: it highly depends on your mail storing policy. For example if
you use the simple alias/.qmail-* files, you can use `id -g
alias`. But if you use /var/qmail/users, the specified mail gid
can be used.
If you are going to be directing virtual domains directly to the
mailman user (using ``virtualdomains'' on a list-only domain, for
example), you will have to use --with-mail-gid=gid of mailman
user's group. This is incompatible with having list aliases in
alias, unless that alias simply forwards to mailman-listname*.
* If there is a user mailman on your system, the alias mailman-owner
will work only in mailman. You have to do a touch .qmail-owner in
mailman directory to create this alias.
NB: An alternative, IMHO better solution is to chown root mailman,
that will stop qmail from considering mailman to be a user to whom
mail can be delivered. (See ``man 8 qmail-getpw''.)
* 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 "-" in them. Putting .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 /var/qmail/users/assign file:
+zope-:alias:112:11:/var/qmail/alias:-:zope-:
.
where in this case the listname is e.g. zope-users.
NB: Alternatively, you could host the lists on a virtual domain,
and use the /var/qmail/control/virtualdomains file to put the
mailman user in charge of this virtual domain.
* BN:If inbound messages are delivered by another user than mailman,
it's necessary to allow it to access mailman. Be sure that
mailman has group writing access and setgid bit is set. Then put
the delivering user to mailman group, and you can deny access to
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. NB: E.g. make an additional "A" DNS record
for the virtual mailserver pointing to your IP address, add the
line lists.kva.hu:mailman to /var/qmail/control/virtualdomains and
a lists.kva.hu line to /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:
.qmail => mailman@...'s letters
.qmail-owner => mailman-owner's letters
For list aliases, you can either create them manually:
.qmail-list => posts to the 'list' list
.qmail-list-admin => posts to the 'list's owner
.qmail-list-request => requests to 'list'
etc
or for automatic list alias handling (when using the lists.kva.hu
virtual as above), see contrib/qmail-to-mailman.py in the Mailman
source distribution. Modify the mailman/.qmail-default to
include:
|/path/to/python /path/to/qmail-to-mailman.py
and new lists will automatically be picked up.
* 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 /etc/hosts.allow file:
tcp-env: 127. 10.205.200 : setenv RELAYCLIENT
where 10.205.200. is your IP address block. If you use tcpserver,
then you need something like the following in your /etc/tcp.smtp
file:
10.205.200.:allow,RELAYCLIENT=""
127.:allow,RELAYCLIENT=""
* BN: Bigger /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.
* More information about setting up qmail and relaying can be found
in the qmail documentation.
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 contrib/qmail-to-mailman.py):
This script is for the Mailman 2.0 series:
#!/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
Note: This is for a new Mailman 2.1 installation. Users upgrading from
Mailman 2.0 would most likely change /usr/local/mailman to
/home/mailman. If in doubt, refer to the --prefix option passed to
configure during compile time.
#!/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-boun
ces
# The following line is for VERP
# echo "|preline /usr/local/mailman/mail/mailman bounces $i" > .qmail-$i-bo
unces-default
echo "|preline /usr/local/mailman/mail/mailman confirm $i" > .qmail-$i-conf
irm
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-requ
est
echo "|preline /usr/local/mailman/mail/mailman subscribe $i" > .qmail-$i-su
bscribe
echo "|preline /usr/local/mailman/mail/mailman unsubscribe $i" > .qmail-$i-
unsubscribe
fi
6.4.1 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 mm_cfg.py file:
VERP_FORMAT = '%(bounces)s-+%(mailbox)s=%(host)s'
VERP_REGEXP = r'^(?P<bounces>.*?)-\+(?P<mailbox>[^=]+)=(?P<host>[^@]+)@.*$'
The second option is a patch on SourceForge located at:
http://sourceforge.net/tracker/?func=detail&atid=300103&aid=645513&gro
up_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.
6.4.2 Virtual mail server
As mentioned in the 6.4 section for a virtual mail server, a patch
under testing is located at:
http://sf.net/tracker/index.php?func=detail&aid=621257&group_id=103&at
id=300103
Again, this patch is for people familiar with their qmail
installation.
6.4.3 More information
You might be interested in some information on modifying footers that
Norbert Bollow has written about Mailman and qmail, available here:
http://mailman.cis.to/qmail-verh/
7 Review your site defaults
Mailman has a large number of site-wide configuration options which
you should now review and change according to your needs. Some of the
options control how Mailman interacts with your environment, and other
options select defaults for newly created lists5. There are system
tuning parameters and integration options.
The full set of site-wide defaults lives in the
$prefix/Mailman/Defaults.py file, however you should never modify this
file! Instead, change the mm_cfg.py file in that same directory. You
only need to add values to mm_cfg.py that are different than the
defaults in Defaults.py, and future Mailman upgrades are guaranteed
never to touch your mm_cfg.py file.
The Defaults.py file is documented extensively, so the options are not
described here. The Defaults.py and mm_cfg.py are both Python files so
valid Python syntax must be maintained or your Mailman installation
will break.
Note: Do not change the HOME_DIR or MAILMAN_DIR variables. These are
set automatically by the configure script, and you will break your
Mailman installation by if you change these.
You should make any changes to mm_cfg.py using the account you
installed Mailman under in the 14 section.
8 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 mailman, but if you need to change this, be sure to change the
MAILMAN_SITE_LIST variable in mm_cfg.py. You can create the site list
with this command, following the prompts:
% bin/newlist mailman
Now configure your site list. There is a convenient template for a
generic site list in the installation directory, under
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 sitelist.cfg file won't be changed.
The template can be applied to your site list by running:
% bin/config_list -i data/sitelist.cfg mailman
After applying the 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.
9 Set up cron
Several Mailman features occur on a regular schedule, so you must set
up cron to run the right programs at the right time^6.
If your version of crontab supports the -u option, you must be root to
do this next step. Add $prefix/cron/crontab.in as a crontab entry by
executing these commands:
% cd $prefix/cron
% crontab -u mailman crontab.in
If you used the --with-username option, use that user name instead of
mailman for the -u argument value. If your crontab does not support
the -u option, try these commands:
% cd $prefix/cron
% su - mailman
% crontab crontab.in
10 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 $prefix directory:
% bin/mailmanctl start
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 chkconfig command (e.g. RedHat and Mandrake Linuxes) you
can do the following (as root, from the Mailman install directory):
% cp scripts/mailman /etc/init.d/mailman
% chkconfig --add mailman
Note that /etc/init.d may be /etc/rc.d/init.d on some systems.
On Gentoo Linux, you can do the following:
% cp scripts/mailman /etc/init.d/mailman
% rc-update add mailman default
On Debian, you probably want to use:
% update-rc.d mailman defaults
For Unixes that don't support chkconfig, you might try the following
set of commands:
% 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
11 Check the hostname settings
You should check the values for DEFAULT_EMAIL_HOST and
DEFAULT_URL_HOST in Defaults.py. Make any necessary changes in the
mm_cfg.py file, not in the mm_cfg.py file. If you change either of
these two values, you'll want to add the following afterwards in the
mm_cfg.py file:
add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)
You will want to run the bin/fix_url.py to change the domain of any
existing lists.
12 Create the site password
There are two site-wide passwords that you can create from the command
line, using the bin/mmsitepass script. The first is the ``site
password'' which can be used anywhere a password is required in the
system. The site password will get you into the administration page
for any list, and it can be used to log in as any user. Think root for
a Unix system, so pick this password wisely!
The second password is a site-wide ``list creator'' password. You can
use this to delegate the ability to create new mailing lists without
providing all the privileges of the site password. Of course, the
owner of the site password can also create new mailing lists, but the
list creator password is limited to just that special role.
To set the site password, use this command:
% $prefix/bin/mmsitepass <your-site-password>
To set the list creator password, use this command:
% $prefix/bin/mmsitepass -c <list-creator-password>
It is okay not to set a list creator password, but you probably do
want a site password.
13 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:
* Start by visiting the url http://my.dom.ain/mailman/create.
* 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 7. Type your own email address for the
``Initial list owner address'', and select ``Yes'' to notify the
list administrator.
* Click on the ``Create List'' button.
* Check your email for a message from Mailman informing you that
your new mailing list was created.
* 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 http://my.dom.ain/mailman/admin/mylist.
* Type in the list's password and click on ``Let me in...''
* Click on ``Membership Management'' and then on ``Mass
Subscription''.
* Enter your email address in the big text field, and click on
``Submit Your Changes''.
* Now go to your email and send a message to mylist@my.dom.ain.
Within a minute or two you should see your message reflected back
to you via Mailman.
Congratulations! You've just set up and tested your first Mailman
mailing list. If you had any problems along the way, please see the 14
section.
14 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 online help, including the FAQ and the interactive
FAQ wizard.
Also check for errors in your syslog files, your mail and web server
log files and in Mailman's $prefix/logs/error file. If you're still
having problems, you should send a message to the
mailman-users@python.org mailing list7; see
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:
* Problem: All Mailman web pages give a 404 File not found error.
Solution: Your web server has not been set up properly for
handling Mailman's CGI programs. Make sure you have:
1. configured the web server to give permissions to
$prefix/cgi-bin
2. restarted the web server properly.
Consult your web server's documentation for instructions on how to
do check these issues.
* Problem: All Mailman web pages give an "Internal Server Error".
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
Attempt to exec script with invalid gid 51, expected 99
you will need to reinstall Mailman, specifying the proper CGI
group id, as described in the section.
* Problem: I send mail to the list, and get back mail saying the
list is not found!
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 newaliases
explicitly. Refer to your server specific instructions in the 6
section.
* Problem: I send mail to the list, and get back mail saying,
``unknown mailer error''.
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
Attempt to exec script with invalid gid 51, expected 99
you will need to reinstall Mailman, specifying the proper mail
group id as described in the section.
* Problem: I use Postfix as my mail server and the mail wrapper
programs are logging complaints about the wrong GID.
Solution: Make sure the $prefix/data/aliases.db file is user owned
by mailman (or whatever user name you used in the configure
command). If this file is not user owned by mailman, Postfix will
not run the mail programs as the correct user.
* 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''.
Solution: Your system uses the Sendmail restricted shell (smrsh).
You need to configure smrsh by creating a symbolic link from the
mail wrapper ($prefix/mail/mailman) to the directory identifying
executables allowed to run under smrsh.
Some common names for this directory are /var/admin/sm.bin,
/usr/admin/sm.bin or /etc/smrsh.
Note that on Debian Linux, the system makes /usr/lib/sm.bin, which
is wrong, you will need to create the directory /usr/admin/sm.bin
and add the link there. Note further any aliases newaliases spits
out will need to be adjusted to point to the secure link to the
wrapper.
* Problem: I messed up when I called configure. How do I clean
things up and re-install?
Solution:
% make clean
% ./configure --with-the-right-options
% make install
15 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.
15.1 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:
* If you are getting errors with hard link creations and/or you are
using a special secure kernel (securelinux/openwall/grsecurity),
see the 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.
* Apparently Mandrake 9.0 changed the permissions on gcc, so if you
build as the mailman user, you need to be sure mailman is in the
cctools group.
* 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 python2.2-dev package. On Redhat, you probably need the
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:
Traceback (most recent call last):
File "bin/update", line 44, in ?
import paths
ImportError: No module named paths
make: *** [update] Error 1
If this happens, install the Python development package and try
configure and make install again. Or install the latest version of
Python from source, available from http://www.python.org.
This problem can manifest itself in other Linux distributions in
different ways, although usually it appears as ImportErrors.
15.2 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 Unixes, 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 DIRSETGID variable to make, after you've run configure:
% make DIRSETGID=: install
This disables the chmod g+s command on installed directories.
15.3 MacOSX issues
Many people run Mailman on MacOSX. Here are some pointers that have
been collected on getting Mailman to run on MacOSX.
* 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.
* David B. O'Donnell has a web page describing his configuration of
Mailman 2.0.13 and Postfix on MacOSX Server.
http://www.afp548.com/Articles/mail/python-mailman.html
* Kathleen Webb posted her experiences in getting Mailman running on
Jaguar using Sendmail.
http://mail.python.org/pipermail/mailman-users/2002-October/022944
.html
* 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:
http://docs.info.apple.com/article.html?artnum=107889
About this document ...
GNU Mailman - Installation Manual, December 22, 2004, Release 2.1
This document was generated using the LaTeX2HTML translator.
LaTeX2HTML is Copyright � 1993, 1994, 1995, 1996, 1997, Nikos Drakos,
Computer Based Learning Unit, University of Leeds, and Copyright �
1997, 1998, Ross Moore, Mathematics Department, Macquarie University,
Sydney.
The application of LaTeX2HTML to the Python documentation has been
heavily tailored by Fred L. Drake, Jr. Original navigation icons were
contributed by Christopher Petrilli.
_________________________________________________________________
Footnotes
... right1
You will be able to check and repair your permissions after
installation is complete.
.../usr/local/mailman2
This is the default for Mailman 2.1. Earlier versions of
Mailman installed everything under /home/mailman by default.
... set3
BSD users should see the 15.2 section for additional
information.
... only4
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.
... lists5
In general, changing the list defaults described in this
section will not affect any already created lists. To make
changes after a list has been created, use the web interface or
the command line scripts, such as bin/withlist and
bin/config_list.
... time^6
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.
... list7
You must subscribe to this mailing list in order to post to it,
but the mailing list's archives are publicly visible.
_________________________________________________________________
Previous Page Up One Level Next Page GNU Mailman - Installation Manual
_________________________________________________________________
Release 2.1, documentation updated on December 22, 2004.
