- Mailman 3 Hosting
- Noteworthy changes from Mailman 2
- Known problems and limitations
Mailman 3 Hosting
We’re providing mailing-lists hosting using Mailman 3, with migration from Mailman 2 if needed.
The mailing-list instance may be hosted in the Community Cage or any host at the tenant’s convenience.
This document records our offering but also our experience around it. We develop packages and Ansible roles to drive these deployments and it may be useful to others.
Noteworthy changes from Mailman 2
Previously subscriptions came with a password, one per list, and aside from a hack to help change settings globaly it was not very practical to manage settings. The password was also sent (on most lists) insecurely in a regular reminder notification.
In Mailman 3 there are real user accounts. Once authenticated using a local or social (Google, GitHub…) account the use can see and change its subscriptions, profile information, list preferences…
It is not compulsory to create an account though, one can be subscribed without never login in, but there is no way to customize settings.
This account is also practical for moderators and list admins, to filter subscriptions and posts as well as define lists settings.
Previously you could use a moderator or list admin password using the
Approved: pseudo-header, but this was utterly unsafe and this is no longer possible, please use the web UI for these tasks.
Prevously the post URLs were generated in a non-unique manner, meaning that the URL was not stable and could change if you rescanned the archives or exported and reimported. This affects the migration because there is no way to map old URLs to the new ones.
As the archives path in the URL is different in Mailman 3 we decided to keep the old generated pages available to avoid breaking the links returned by search engines. The posts are of course also available in the new UI with all the new features, this is just a static view. Aside from taking extra storage on the server there is no downside.
If a migration from Mailman 2 is needed, then access to the Mailman 2 files is necessary. The original mailboxes (mbox files) are used to import the posts for each list. The settings files (pck files) are used to get the subscribers and list settings. The old archives’ web pages are used to keep all the links on the Internet working (see previous chapter).
Information about the number of lists, expected volume, and domains involved are necessary to size the new instance. In case of migration from Mailman 2 we can find most of this out by looking at the current archives. It is possible to have multiple domains managed on the same instance, but if both domains are planned to be separated (separate projects) it would be better to setup separate instances from the start; exporting and reimporting is a delicate matter.
Aside from local accounts, authentication with social accounts is possible, so we need to get tokens from each provider to setup the instance. We highly recommand to setup a team account on each provider instead of using one from a team member: users will see the name of the person instead of the project name when registering, and things are going to be complicated when the person leaves the project. Have a look at the procedure to create tokens.
Posts footer, subscription messages and various notifications messages can be customized. Messages can be global or per list and using various languages. Mailman’s default messages can be used as examples to draft messages adapted to the community (upstream technical documentation). Then we can easily deploy these customization using Ansible.
Lists short and long descriptions can be setup in the administrative UI but it is very limited. To customize further certain parts of the UI can be overriden.
Currently we only have experience customizing the top bar to add project branding (logo) as well as favicon. It is also possible to easily add content at the very top and bottom of the page. We’re looking into more useful places to customize the theme (extra headers to load a custom CSS for eg).
Known problems and limitations
Hyperkitty is not at the latest version
Previously the packaging was kindly done my Aurelien Bompard, but he now lacks time to maintain it. We decided to take over and try to help push the various bits to be one day available in Fedora and later RHEL 9.
We are working on preparing the lastest Mailman 3 packages with EL7 backport (later EL8 when CentOS 8 is read). Python 3.4 was replaced in EL 7 by 3.6, so Mailman 3 daemon package needed to be adapted. We now have the lastest Mailman 3 daemon ready but the UI needs more work to get all the dependencies available for the new upstream version as well as Python 3 (previously 2.7 only). This is WIP.
A few list and site-wide settings are not yet available in the web UI (global bans, maybe others).
We have scripts to fix these problems. In the Message-Id case threads cannot be reconstituted due to lack of information though.
Cannot delete list archive
Deleting a list removes the configuration in the routing daemon, thus it is not possible anymore to post, and the archives are kept (read-only). This is usually what most people want but sometimes you made a mistake or wish to get rid of some tests but unfortunately it is not possible to remove archives in the web UI.
With shell access it is possible though, with this procedure:
cd /var/www/mailman/config/ export DJANGO_SETTINGS_MODULE=settings python import django django.setup() from hyperkitty.models import MailingList ml = MailingList.objects.get(name="<list-email>") ml.delete()
- RPM packaging sources
- current production-ready RPM repository with latest Mailman 3.2 core daemon but slightly older UI (targeted at EL7)
- development RPM repository to work on latest Mailman suite (targeted on EL7 and Fedora)