GNU Mailman 3 Deployment with Docker

This repository hosts code for two docker images maxking/mailman-core and maxking/mailman-web both of which are meant to deploy GNU Mailman 3 in a production environment.

Docker is a container ecosystem which can run containers on several platforms. It consists of a tool called docker-compose which can be used to run multi-container applications. This repository consists of a docker-compose.yaml file which is a set of configurations that can be used to deploy the Mailman 3 Suite.

Please see NEWS for the latest changes and releases.


The tags for the images are assumed to be release versions for images. This is going to be somewhat common philosophy of distributing Container images where the images with same tags are usually updated with the new functionality.

Releases will follow the following rules:


All the releases are signed and can be verified using Docker Content Trust. To make sure that your docker client actually verifies these signatures, you can enable Docker’s content trust by setting an environment variable DOCKER_CONTENT_TRUST. In bash/zsh you can try this:


Or, alternatively, you can do this on a per-command basis without setting the environment variable above. For example, when pulling an image:

$ docker pull --disable-content-trust=false maxking/mailman-core:release

The above command will fail if the release tag doesn’t exist or is not signed.


To run this you first need to download docker for whichever operating system you are using. You can find documentation about how to install. It is recomended to use these instead of the one from your package managers. After you have downloaded and installed docker, install docker-compose from here.


Most of the common configuration is handled through environment variables in the docker-compose.yaml. However, there is need for some extra configuration that interacts directly with the application. There are two configuration files on the host that interact directly with Mailman’s settings. These files exist on the host running the containers and are imported at runtime in the containers.

Also, note that if you need any other files to be accessible from the host to inside the container, you can place them at certain directories which are mounted inside the containers.


These are the settings that you MUST change before deploying:

For more details on how to configure this image, please look at Mailman-web’s Readme


These are the variables that you MUST change before deploying:

For more details on how to configure this image, please look Mailman-core’s Readme

While the above configuration will allow you to run the images and possible view the Web Frontend, it won’t be functional until it is fully configured to to send emails.

To configure the mailman-web container to send emails, see these configuration settings.

To configure the mailman-core container to send emails, see the Setting you MTA section below.


To run the containers, simply run:

$ mkdir -p /opt/mailman/core
$ mkdir -p /opt/mailman/web
$ git clone
$ cd docker-mailman
# Change some configuration variables as mentioned above.
$ docker-compose up -d

Note that the web frontend in the mailman-web container is, by default, only configured to serve dynamic content. Anything static like stylesheets etc is expected to be served directly by the web server. The static content exists at /opt/mailman/web/static and should be aliased to /static/ in the web server configuration.

See the nginx configuration as an example.

This command will do several things, most importantly:

Some more details about what the above system achieves is mentioned below. If you are only going to deploy a simple configuration, you don’t need to read this. However, these are very easy to understand if you know how docker works.

Setting up your MTA

The provided docker containers do not have an MTA in-built. You can either run your own MTA inside a container and have them relay emails to the mailman-core container or just install an MTA on the host and have them relay emails.

To use Exim4, it should be setup to relay emails from and The mailman specific configuration is provided in the repository at core/assets/exim. There are three files

Also, the default configuration inside the mailman-core image has the MTA set to Exim, but just for reference, it looks like this:

# mailman.cfg
incoming: mailman.mta.exim4.LMTP
outgoing: mailman.mta.deliver.deliver
lmtp_host: $MM_HOSTNAME
lmtp_port: 8024
smtp_host: $SMTP_HOST
smtp_port: $SMTP_PORT
configuration: python:mailman.config.exim4

To use Postfix, it should be set up to relay emails from and The mailman specific configuration is mentioned below which you should add to you configuration file, which is typically at /etc/postfix/ on Debian based operating systems:


# Support the default VERP delimiter.
recipient_delimiter = +
unknown_local_recipient_reject_code = 550
owner_request_special = no

transport_maps =
local_recipient_maps =
relay_domains =

To configure Mailman to use Postfix, add the following to mailman-extra.cfg at /opt/mailman/core/mailman-extra.cfg.

# mailman-extra.cfg

incoming: mailman.mta.postfix.LMTP
outgoing: mailman.mta.deliver.deliver
lmtp_port: 8024
smtp_port: 25
configuration: /etc/postfix-mailman.cfg

The configuration file /etc/postfix-mailman.cfg is generated automatically.

Setting up your web server

It is advisable to run your Django (interfaced through WSGI server) through an actual webserver in production for better performance.

If you are using v0.1.0, the uwsgi server is configured to listen to requests at using HTTP protocol. Make sure that you preserve the HOST header when you proxy the requests from your Web Server. In Nginx, you can do that by adding the following to your configuration:

       # Nginx configuration.

        location / {
		 # First attempt to serve request as file, then

		  include uwsgi_params;
		  uwsgi_read_timeout 300;
		  proxy_set_header Host $host;
		  proxy_set_header X-Forwarded-For $remote_addr;

Make sure you are using proxy_pass for HTTP protocol.

Starting from v0.1.1, the uwsgi server is configured to listen to requests at with the http protocol and for the uwsgi protocol.

It is advised to use the uwsgi protocol as it has better performance. Both Apache and Nginx have native support for uwsgi protocol through plugins which are generally included in the distro packages.

To move to uwsgi protocol in the above nginx configuration use this

       # Nginx configuration.

        location / {
		 # First attempt to serve request as file, then

		  include uwsgi_params;
		  uwsgi_read_timeout 300;

Please make sure that you are using v0.1.1 if you use this configuration.

Serving static files

UWSGI by default doesn’t serve static files by default, so when running mailman-web using the provided docker-compose.yaml file you won’t see any CSS or JS files being served.

You will have to add an alias rule in your web server to serve the static files. See here for instructions on how to configure you web server. The STATIC_ROOT for you would be /opt/mailman/web/static. This method is highly recommended for better performance reasons.

SSL certificates

SSL Certificates from Lets Encrypt need to be renewed every 90 days. You can setup a cron job to do the job. I have this small shell script( that you can put up in /etc/cron.monthly to get the job done.

#! /bin/bash

cd /opt/letsencrypt/
./certbot-auto --config /etc/letsencrypt/renewal/MY_DOMAIN_NAME.conf certonly

if [ $? -ne 0 ]
        ERRORLOG=`tail /var/log/letsencrypt/letsencrypt.log`
        echo -e "The Let's Encrypt cert has not been renewed! \n \n" \
        nginx -s reload

exit 0

Please do not forget to make the script executable (chmod +x


This repository is licensed under MIT License. Please see the LICENSE file for more details.