The Postman Cometh

List Configuration

The developers' aim was to have as many features of version 2 in Mailman 3 as possible, including many of the core functions. Their years of experience in dealing with mailing lists has been beneficial: The user has extensive list configuration options.Mailman can accept, reject, or modify messages from mailing list (non-)subscribers.

Other list options include whether to add a prefix to the Subject line, whether to set a Reply To, or whether to hide the original sender of the message. The structure of the messages can be cleaned up (only accept the first part of multipart/alternative) or converted to a text-only version. For archiving, the admin individually defines several archiver plugins per list from multiple preconfigured plugins, which should receive the new messages via the list.

After enabling the HyperKitty archiver and adding a few subscribers to the mailing list (Figure 3), the basic configuration is ready to send a first message to the list.

Figure 3: Screen for the mailing lists in HyperKitty, where subscribers can be added.

HyperKitty

If everything works, Postfix accepts the message, finds the path to Mailman via the autoconfigured transports, and forwards the message via LMTP on port 8024. If configured accordingly, the message is distributed to subscribers and also forwarded to HyperKitty.

The configured mailing list has now been published on the web interface start screen. Clicking here leads to the Summary page, which provides a first impression of the available features. Anyone who has worked with the Mailman 2 archive will be in for a surprise at this point: HyperKitty is visually and functionally a highlight in the Mailman 3 suite.

The latest discussions (Figure 4), statistics on message frequency and participants, popularity ratings for discussions, and personal lists of discussions marked as favorites or discussions in which the user has participated are shown in the overview.

Figure 4: View of a discussion in HyperKitty.

The discussion itself shows the message contents; the user can respond directly on the web interface, mark messages with thumbs up or thumbs down, place a favorite tag, and add tags to the discussion. In addition to search capabilities on tags, you also get an integrated full-text search.

Selecting an Environment

The environment installed using Mailman Bundler starts in a mode intended for development and testing purposes by default. It is possible to switch to production mode in the file buildout.cfg using deployment. This causes a switch in the Mailman web components (Postorius and HyperKitty) from the settings file mailman_web/development.py to mailman_web/production.py. In the production file, you must set the SECRET _KEY setting to a value of your choice. This key is used for communication between the components of the Mailman suite. Any changes you make can be implemented by accessing buildout again.

By changing the configuration file, the default configuration then suggests switching from SQLite 3 to PostgreSQL. MySQL is also available for Django-based web components. In Mailman Core, this does not officially work, and tests showed that adjustments are indeed still needed.The PostgreSQL libraries' headers and a Python module are still required to operate using PostgreSQL. Administrators typically install the PostgreSQL libraries and the server with packages directly from the respective distribution. The Pip installer for the virtual environment is used again for the Python package:

sudo dnf install -y postgresql-devel
pip install psycopg2

The database can be initialized or updated via Django for the web components using syncdb. You can also switch from the SQLite 3 database to a MySQL database in the test installation

bin/django-admin dumpdata >dump.json

or adjust DB settings in the configuration and create the database:

bin/django-admin syncdb
bin/django-admin loaddata dump.json

SQLite 3 should be an easy option for a small installation. The Mailman developers would like to get more feedback about the configuration in practice. They say that locking problems, which should not occur with a huge database engine, have been observed. Accordingly, the official recommendation for production operation is to use PostgreSQL as a database.

The integrated web server previously used in the test environment is also not intended for production use. A web server such as Apache or Nginx linked to the Python components via the web server gateway interface (WSGI) or operating the standalone web server Gunicorn linked to the outside world via proxy functionality is recommended in practice. Apache with WSGI requires the mod_wsgi module and Nginx the uwsgi module.