aboutsummaryrefslogtreecommitdiffstats
path: root/admin/www/mailman-install.txt
diff options
context:
space:
mode:
Diffstat (limited to '')
-rw-r--r--admin/www/mailman-install.txt1433
1 files changed, 1433 insertions, 0 deletions
diff --git a/admin/www/mailman-install.txt b/admin/www/mailman-install.txt
new file mode 100644
index 00000000..ae27aebe
--- /dev/null
+++ b/admin/www/mailman-install.txt
@@ -0,0 +1,1433 @@
+ #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 13, 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 right^1. 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/mailman^2. 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 set^3. 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 only^4. 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 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.
+
+ 8 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^5.
+
+ 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
+
+ 9 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
+
+ 10 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.
+
+ 11 Customize Mailman
+
+ 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 13 section.
+
+ * The file $prefix/Mailman/Defaults.py contains a number of defaults
+ for your installation. If any of these are incorrect, override
+ them in $prefix/Mailman/mm_cfg.py, not in the Defaults.py file!
+ See the comments in 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
+ bin/withlist and bin/config_list.
+ The install process will never overwrite an existing mm_cfg.py
+ file so you can freely make changes to this file.
+ 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.
+ * Create the site password. Use this command:
+ % $prefix/bin/mmsitepass <your-site-password>
+ 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 -c option to mmsitepass to set
+ this.
+
+ 12 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 11. 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 13
+ section.
+
+ 13 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 list^6; 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
+
+ 14 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.
+
+14.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.
+
+14.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.
+
+14.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 13, 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
+
+ ... right^1
+ You will be able to check and repair your permissions after
+ installation is complete.
+
+ .../usr/local/mailman^2
+ This is the default for Mailman 2.1. Earlier versions of
+ Mailman installed everything under /home/mailman by default.
+
+ ... set^3
+ BSD users should see the 14.2 section for additional
+ information.
+
+ ... only^4
+ 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.
+
+ ... time^5
+ 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.
+
+ ... list^6
+ 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 13, 2004.
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-27 04:47:33 +0000