Installing and running Mailman 3¶
Copyright (C) 2008-2018 by the Free Software Foundation, Inc.
For the Core, Python 3.5 or newer is required. It can either be the default
‘python3’ on your
$PATH or it can be accessible via the
python3.6 binary. If your operating system does not include Python 3, see
https://www.python.org for information about downloading installers (where
available) and installing it from source (when necessary or preferred).
Python 2 is not supported by the Core.
You may need some additional dependencies, which are either available from your OS vendor, or can be downloaded automatically from the Python Cheeseshop.
The documentation for Mailman 3 is distributed throughout the sources. The
core documentation (such as this file) is found in the
directory, but much of the documentation is in module-specific places. Online
version of the Mailman 3 Core documentation is available.
Also helpful might be Mark Sapiro’s documentation on building out the mailman3.org server.
Get the sources¶
The Mailman 3 source code is version controlled using Git. You can get a local copy by running this command:
$ git clone https://gitlab.com/mailman/mailman.git
or if you have a GitLab account and prefer ssh:
$ git clone firstname.lastname@example.org:mailman/mailman.git
Running Mailman 3¶
The Mailman command line interface requires a properly configured UTF-8
locale. This is because the Core is implemented in Python 3 and uses the
click command line argument parsing library. Generally this will not be
an issue since your shell is probably set up correctly. However, in
certain environments such as init scripts and cron scripts, your locale may
not be UTF-8 compatible. This can cause Mailman to mysteriously fail to
run (since often, proper logging may also not be set up). If you’re seeing
weird behavior in these types of environments, be sure they are UTF-8
compatible, e.g. by setting
You will need to set up a configuration file to override the defaults and set
things up for your environment. Mailman is configured using an “ini”-style
configuration system. Usually this means creating a
mailman.cfg file and
putting it in a standard search location. See the configuration documentation for details.
By default, all runtime files are put under a
var directory in the current
mailman info command to see which configuration file Mailman is
using, and where it will put its database file. The first time you run this,
Mailman will also create any necessary run-time directories and log files.
mailman --help for more details. You can use the commands
mailman start to start the runner subprocess daemons, and of course
mailman stop to stop them.
Note that you can also run Mailman from one of the virtual environments created by tox, e.g.:
$ tox -e py35-nocov --notest -r $ .tox/py35-nocov/bin/mailman info
This documentation has examples which use the Mailman shell to interact with
Mailman. To start the shell type
mailman shell in your terminal.
There are some testings functions which need to be imported first before you
use them. They can be imported from the modules available in
mailman.testing. For example, to use
dump_list you first need to
import it from the
The shell automatically initializes the Mailman system, loads all the available interfaces, and configures the Zope Component Architecture (ZCA) which is used to access all the software components in Mailman. So for example, if you wanted to get access to the list manager component, you could do:
$ mailman shell Welcome to the GNU Mailman shell >>> list_manager = getUtility(IListManager)