© Andriy Popov, 123RF

Mit Mailman 3.0 ist 12 Jahre nach der Ausgabe 2.0 eine neue Hauptversion erschienen. Das Linux-Magazin hat den Neuen in Betrieb genommen und erläutert die Neuerungen und die Installation.

Der in Python geschriebene Mailman des GNU-Projekts zählt zweifellos zur professionellen Software in Sachen Mailing. Die Fan-Gemeinde weiß die solide Arbeitsweise zu schätzen. Version 1.0 erschien Mitte 1999 [1], gefolgt von 2.0 im Jahr 2000. Der letzte stabile Zweig wurde mit 2.1 vor rund zwölf Jahren eröffnet. In den vergangenen Jahren fand im stabilen Versionszweig eher Pflege als Entwicklung statt. Die erste Alphaversion des 3.0er Zweiges hat inzwischen auch sieben Jahre auf dem Buckel. Mailman 3.0 legt als nahezu komplett runderneuerte Hauptversion nun alle Alpha- und Beta-Namenszusätze ab.

Neuer Aufbau

Technologisch hat sich eine Menge getan. Nach den Erläuterungen von Hauptentwickler Barry Warsaw [2] ist der Schritt zu Version 3.0 notwendig geworden, um problematische Design-Entscheidungen der vorangegangenen Hauptversionen auszubügeln. Seit den Anfängen läuft die Software unter Python und hat in manchen Bereichen zur Entwicklung von Python beigetragen. So hat Warsaw Code zum Unicode-Handling für Python 3 beigesteuert [3]. Der Kern von Mailman, der die eigentliche Verarbeitung von Nachrichten übernimmt, setzt nun Python 3 voraus.

Das in Version 2.x noch eher rudimentäre Webinterface wurde durch eine zeitgemäße Komponente abgelöst. Und auch für die Mailinglisten-Archivierung haben die Entwickler eine ansprechende Lösung mit vielen nützlichen Funktionen geschaffen. Genauer betrachtet besteht die Mailman-3-Suite aus folgenden Komponenten [4]:

• Mailman Core: Die Kernkomponente zur Nachrichtenverarbeitung mit einheitlichem Benutzermodell, Moderation und Bearbeitung von E-Mail-Nachrichten sowie Schnittstellen für Systeme zur Mailinglisten-Archivierung und einer REST-Schnittstelle zur Anbindung weiterer Komponenten.
• Postorius: Ein auf Django fußendes Webinterface für Benutzer und Listen-Administratoren.
• Hyperkitty: Eine ebenfalls auf Django basierende Archivierungs-Komponente für Mailinglisten mit umfangreichen Möglichkeiten zur Verwaltung historischer Nachrichten und Threadansichten sowie mit einer eingebauten Archiv-Suche, Tag- und Voting-Funktionen und einer integrierten Antwort-Möglichkeit per Webinterface.
• Mailman Bundler: Eine Skriptsammlung zum einfachen Aufsetzen der kompletten Suite in virtuellen Python-Umgebungen.

Sowohl das Webinterface zur Administration als auch die Archiv-Komponente sind optional. Über die REST-Schnittstelle lässt sich Mailman Core auch direkt in andere Applikationen integrieren oder mit einem eigenen Webinterface versehen. Für die Archiv-Komponente steht ein Python-Interface bereit.

Mitgeliefert werden neben Hyperkitty (Abbildung 1) Anbindungen zu Mhonarc, zum öffentlich nutzbaren Mail-Archive.com sowie ein einfaches Prototyp-Plugin zum Anbinden eigener Systeme. Auch ist die Nutzung mehrerer Archive gleichzeitig möglich, diese Funktion lässt sich pro Mailingliste individuell aktivieren.

Abbildung 1: Startseite von Mailman im Hyperkitty-Interface.

Relationale Datenbank

In früheren Versionen verwendete Mailman zur Datenspeicherung Pickles [5]. Dabei handelt es sich um serialisierte Python-Objekte, was die Arbeit mit den enthaltenen Daten erschwerte und den Zugriff aus Nicht-Python-Anwendungen nahezu unmöglich machte. Hier kommt die große Neuerung bei Mailman 3 sowie den zugehörigen Komponenten der Suite ins Spiel: Die Speicherung erfolgt in relationalen Datenbanken wie SQlite 3 (als einfache Embedded-Variante) sowie PostgreSQL und MySQL. Bei MySQL hat Mailman Core derzeit allerdings noch Einschränkungen.

Mit Mailman 3 ist nun der Betrieb von Mailinglisten unter mehreren Domains problemlos möglich. Im Konzept von Version 2 waren keine Domainnamen berücksichtigt, sodass der Admin Aliasse benutzen oder je Domain separate Mailman-Installationen betreiben musste. Auch Benutzeraccounts können nun Mitgliedschaften in mehreren Mailinglisten zusammenfassen.

Es mag ironisch klingen, dass Barry Warsaw in seiner Ankündigung für Mailman 3.0 als Feature hervorhebt, dass es keine monatlichen Benachrichtigungen mit Passwörtern im Klartext mehr verschickt. Ein Versand im Klartext wäre mittlerweile auch gar nicht mehr möglich, da Mailman Core nun lediglich Passworthashes speichert.

Mailman Core unterstützt derzeit offiziell Postfix und Exim als Mailserver. Beispielkonfigurationen sind momentan nur für Postfix im Lieferumfang, auch Mailman Bundler erwartet eine Postfix-Installation. Die Testinstallation mittels Mailman Bundler ist auch ohne Postfix oder theoretisch ganz ohne Mailer möglich. Beim Anlegen einer Mailingliste ruft sie dann standardmäßig das Tool »postmap« auf, da andernfalls unschöne Fehlermeldungen erscheinen.

Python gemischt

Auf vielen Serverumgebungen kommt noch immer Python 2 zum Einsatz. Bei einem aktuellen RHEL oder Centos 7 steht ein Python 3 nur über zusätzlich installierbare Software-Collections oder seit Kurzem über das EPEL-Testing-Repository [6] zur Verfügung. Auf einem Debian 8 beispielsweise gibt es auch regulär parallel installierbare Pakete. Für manche Administratoren dürfte dies das erste Softwarepaket sein, welches Python 3 (genauer Python 3.4) erfordert. Dies macht allerdings lediglich Mailman Core zur Bedingung, Postorius und Hyperkitty hingegen müssen gegenwärtig noch explizit mit einer Python-Version 2.7 ausgeführt werden.

Um diese gemischte Umgebung zu betreiben, wählt Mailman Bundler den Ansatz, virtuelle Umgebungen für jeden Versionszweig anzulegen, um benötigte Bibliotheken auf einfache Weise parallel betreiben und flexibel wählen zu können. Selbst bei Distributionen, die alle notwendigen Bibliotheken bereits als reguläre Pakete anbieten, könnte die parallele Nutzung sonst Probleme bereiten.

Die virtuellen Umgebungen realisiert Virtualenv. Das sind dann keine virtuellen Maschinen, sondern lediglich Verzeichnisbäume, die ein paar Skripte und Binaries enthalten. Sie setzen Environment-Variablen beim Aktivieren einer solchen Umgebung voraus. Das bringt für die Installation einer Entwicklungsumgebung praktische Vorteile und ermöglicht eine Installation auf einem breiten Spektrum von Distributionen. Allerdings sind die auf diese Weise installierten Pakete dann nicht über die gewohnte Paketverwaltung der Distribution installiert und benötigen für Updates gesonderte Aufmerksamkeit.

Installation mit Bundler

Bei der Verwendung von Mailman Bundler installiert dieser die meisten benötigten Komponenten. Zum Starten sind erforderlich:

• Pakete für Python 2.7 (Paketname meist »python« ) und Python 3.4 (meist »python3« oder »python34« ).
• Virtualenv (Paketname etwa »python-virtualenv« ).
• Pip als Installer (»python-pip« ).
• GCC als Compiler für einige Pakete.
• Der Node.js-Less-Generator (etwa »node-less« ) für CSS-Stylesheets.
• Der Postfix-Mailserver.

Zwar existiert für Mailman Bundler ein offizielles Paket 3.0.0 [7]. Bei den Testinstallationen zu diesem Artikel trat jedoch ein Fehler auf, der im Repository des Projekts bereits behoben ist [8]. Daher empfiehlt es sich, mittels der Versionsverwaltung Bazaar einen aktuellen Entwicklungsstand einzuspielen. Hierfür bedarf es an der Kommandozeile noch des Tool »bzr« .

Die Installation der Testumgebung kann einfach in einem Unterverzeichnis erfolgen. Außerdem lässt sich zum Betrieb von Mailman ein separater Benutzer auf dem System anlegen. Die Mailman-Umgebung kann der Admin dann testweise einfach in dessen Heimatverzeichnis aufsetzen.

Zuerst lädt der Admin die aktuelle Version von Mailman Bundler aus dem Repository, wechselt in jenes Verzeichnis, erzeugt eine virtuelle Python-Umgebung (für Python 2.7) und aktiviert sie:

bzr branch lp:mailman-bundler
cd mailman-bundler
virtualenv venv
source venv/bin/activate

Dann nutzt er den Pip-Installer, um das Tool Buildout nachzuinstallieren. Der Installer führt anhand der Vorgaben in »buildout.cfg« die Installation der Komponenten durch:

pip install zc.buildout
buildout

Sollte die Installation zwischendurch abbrechen, etwa wegen einer fehlenden Bibliothek, lässt sie sich durch erneuten Start von »buildout« fortsetzen, bis sie komplett ist. In den Tests konnte Buildout etwa die Komponente »python-social-auth« nicht installieren. Auch hierzu existiert bereits eine Lösung [9], die aber noch nicht in die Bibliothek eingeflossen ist. Der Admin installiert das Paket einfach manuell und führt anschließend die Installation fort:

pip install python-social-auth

Bei Bedarf lässt sich die manuelle Installation für andere Komponenten wiederholen.

Während des Installationsverlaufs legt Buildout eine virtuelle Umgebung für Python 3.4 an. Diese aktiviert der Admin bei Bedarf mittels:

source venv-3.4/bin/activate

Die Startskripte der Komponenten tragen selbst dafür Sorge, die jeweilige Umgebung zu verwenden.

Die Datenbank für die Django-basierten Webkomponenten initialisiert der Admin mittels:

./bin/mailman-post-update

Außerdem sollte er einen Superbenutzer anlegen:

./bin/mailman-web-django-admin createsuperuser

Hierbei ist darauf zu achten, für den Supernutzer eine Mailadresse zu konfigurieren, anderenfalls kommt es – zumindest beim getesteten Versionsstand – zu mysteriösen Fehlermeldungen bei der Verwendung des Webinterface.

Zum Betrieb der Dienste in der Testumgebung startet

./bin/mailman start
./bin/mailman-web-django-admin runserver &

Mailman Core sowie die Django-basierten Webdienste: Es laufen nun auf drei TCP-Ports neue Dienste, die nur über die IP-Adresse 127.0.0.1 von der lokalen Maschine erreichbar sind. Dabei erschienen die Ports 8001 und 8024 in einer Netstat-Auflistung im Zusammenhang mit einem Python-3.4-Prozess. Es handelt sich hierbei um Mailman Core, der auf Port 8001 das REST-API anbindet und auf Port 8024 die LMTP-Verbindung für eingehende Mails des Mailservers.

Das Django-Webinterface ist auf Port 8000 erreichbar und stellt die Schnittstelle zum Benutzer dar. Der Admin kann diesen Port durch eine Firewall- oder Proxy-Regel extern bereitstellen oder bei der lediglich für Tests gedachten Umgebung erst einmal lokal nutzen.

E-Mail-Anbindung an Postfix

Als Hilfe für den Anschluss an Postfix steht eine Beispielkonfiguration zur Verfügung. Die dort enthaltenen Pfade passt Mailman Bundler an die lokale Umgebung an. In der Haupt-Konfigurationsdatei von Postfix ist es leider nicht möglich, weitere Einstellungen per Include nachzuladen, weshalb sie der Admin zur bestehenden Konfiguration hinzufügen muss, üblicherweise unter »/etc/postfix/main.cf« . Enthalten sind dort drei Zeilen mit Verweisen auf Dateien, die Mailman Core verwaltet. Beim Anlegen einer neuen Mailingliste werden diese automatisch gepflegt. Da die Dateien nicht im Klartext, sondern gehasht vorliegen, ruft Mailman nach der Aktualisierung automatisch das Postmap-Kommando auf.

Erste Schritte

Das Anmelden am Frontend erfolgt per Webbrowser. Die beiden eigenständigen Webapplikationen Postorius und Hyperkitty sind in einem einheitlichen Look gehalten und bei der Installation per Mailman Bundler rudimentär querverlinkt. Grundsätzlich lassen sich beide Systeme aber auch separat sowie unabhängig von Mailman Core betreiben. Über die Verwaltungsoberfläche Postorius (Abbildung 2) darf der Admin dem System eine Domain hinzufügen und in einem weiteren Schritt Listen zur Domain hinzufügen. Sollten hier nach dem Anlegen einer Liste Fehlermeldungen erscheinen, sind oft ein fehlendes »postmap« oder beschränkte Dateirechte der Grund.

Abbildung 2: Blick auf die Einstellungsmenüs von Postorius.

Listenkonfiguration

Die Listenkonfiguration bietet dem Nutzer umfangreiche Einstellungsmöglichkeiten. Hier zeigt sich sehr wohltuend die langjährige Erfahrung von Mailman im Umgang mit Mailinglisten. Ziel der Entwickler war es, möglichst alle Features der Version 2 auch in Mailman 3 abzubilden. Für viele der Kernfunktionen trifft dies bereits jetzt zu.

Für eine Mailingliste lässt sich so festlegen, ob Mailman Nachrichten von (Nicht-)Abonnenten akzeptiert, abweist oder moderiert. Es lässt sich auch einstellen, ob er den Betreff der Nachrichten auf der Liste um ein Präfix ergänzt, ein Reply-To setzt oder den Originalabsender der Nachricht verstecken soll. Die Struktur der Nachrichten lässt sich aufräumen (nur den ersten Teil von »multipart/alternative« übernehmen) oder zu einer Nur-Text-Variante umwandeln.

Für die Archivierung legt der Admin aus mehreren vorkonfigurierten Archiver-Plugins pro Liste individuell mehrere fest, die neue Nachrichten über die Liste erhalten sollen. Er aktiviert hier den Hyperkitty-Archiver und fügt ein paar Abonnenten zur Mailingliste (Abbildung 3) hinzu – schon ist die Grundkonfiguration fertig, um eine erste Nachricht an die Liste zu schicken.

Abbildung 3: Bildschirm für die Mailinglisten in Hyperkitty, wo sich Abonnenten hinzufügen lassen.

Hyperkitty

Sollte alles funktionieren, nimmt Postfix die Nachricht entgegen, findet über die automatisch konfigurierten Transports den Weg zu Mailman und leitet diesem die Nachricht per LMTP auf Port 8024 zu. Diese wird dann, falls entsprechend konfiguriert, an die Abonnenten verteilt sowie auch an Hyperkitty weitergeleitet. Auf der Startseite des Webinterface ist nun die konfigurierte Mailingliste erschienen. Ein Klick hierauf führt zur Übersichtsseite, die einen ersten Eindruck der verfügbaren Funktionen vermittelt. Wer mit dem Archiv von Mailman 2 gearbeitet hat, wird an dieser Stelle große Augen machen: Hyperkitty ist optisch wie funktional ein klares Highlight der Mailman-3-Suite.

In der Übersicht zu sehen sind die neuesten Diskussionen (Abbildung 4), Statistiken über Nachrichten-Häufigkeit sowie Diskussionsteilnehmer, Beliebtheitswerte zu Diskussionen sowie persönliche Listen von als Favoriten markierten Diskussionen oder Diskussionen, an denen der Nutzer teilgenommen hat.

Abbildung 4: Ansicht einer Diskussion in Hyperkitty.

Die Diskussion selbst zeigt den Inhalt von Nachrichten, der Nutzer kann direkt auf dem Webinterface antworten, Nachrichten mit Daumen-hoch oder Daumen-runter markieren, eine Favoriten-Markierung setzen sowie Tags zur Diskussion hinzufügen. Neben Suchmöglichkeiten anhand dieser Tags findet sich auch eine integrierte Volltextsuche.

Umgebung wählen

Die mittels Mailman Bundler installierte Umgebung startet standardmäßig in einem eher für Entwicklungs- und Testzwecke gedachten Modus. In der Datei »buildout.cfg« ist mit der »deployment« -Eigenschaft der Wechsel in den Production-Modus möglich. Das führt zu einem Schwenk der Mailman-Webkomponenten (Postorius und Hyperkitty) von der Einstellungsdatei »mailman_web/development.py« zu »mailman_web/production.py« . In letztgenannter Datei gilt es notwendigerweise, die Einstellung »SECRET _KEY» auf einen selbst gewählten Wert zu setzen. Dieser Schlüssel dient zur Kommunikation der Komponenten der Mailman-Suite. Die geänderten Einstellungen lassen sich durch erneuten Aufruf von »buildout« ausrollen.

Durch den Wechsel in der Konfigurationsdatei schlägt die Standardkonfiguration dann einen Wechsel von SQlite 3 auf PostgreSQL vor. Für die Django-basierten Webkomponenten ist alternativ auch MySQL nutzbar. Bei Mailman Core funktioniert das offiziell noch nicht – und Tests zeigten, dass tatsächlich noch Anpassungen notwendig sind.

Für den Betrieb mit PostgreSQL sind noch die Header der Postgre-Libraries sowie ein Python-Modul erforderlich. Die Installation der PostgreSQL-Libraries sowie des Servers wird der Admin üblicherweise direkt mit Paketen der jeweiligen Distribution ausführen. Für das Python-Paket kommt dann wieder der Pip-Installer der virtuellen Umgebung zum Einsatz:

sudo dnf install -y postgresql-devel
pip install psycopg2

Für die Webkomponenten kann über Django eine Initialisierung oder Aktualisierung der Datenbank mittels »syncdb« erfolgen. In der Testinstallation lässt sich so auch von der SQlite-3-Datenbank auf eine MySQL-Datenbank wechseln:

bin/django-admin dumpdata >dump.json
Oder DB-Einstellungen in der Konfiguration anpassen und Datenbank anlegen:
bin/django-admin syncdb
bin/django-admin loaddata dump.json

Für eine kleine Installation sollte SQlite 3 eigentlich eine einfache Möglichkeit darstellen. Die Mailman-Entwickler würden gerne weitere Rückmeldungen über jene Konfiguration in der Praxis erhalten. Vereinzelt habe man aber Locking-Probleme beobachtet, die bei einer großen Datenbank-Engine in dieser Form nicht auftreten sollten. Entsprechend lautet die offizielle Empfehlung für den produktiven Betrieb, PostgreSQL als Datenbank zu verwenden.

Der in der Testumgebung bisher verwendete integrierte Webserver ist ebenfalls nicht für den Produktiveinsatz gedacht. Hier werden für die Praxis ein Webserver wie Apache oder Nginx mit Anbindung an die Python-Komponenten per WSGI-Schnittstelle oder der Betrieb des Stand-alone-Webservers Gunicorn mit Anbindung per Proxy-Funktionalität an die Außenwelt angeraten. Apache mit WSGI benötigt das Modul »mod_wsgi« , Nginx das Modul »uwsgi« .

Kein Paketservice

Obwohl Mailman 3 nun bereits seit Mai 2015 veröffentlicht ist, existieren für die gängigen Distributionen noch keine einfach installierbaren Pakete. An dieser Stelle sei alternativ auf die Testpakete im persönlichen Repository [10] des Fedora-Maintainers Aurelien Bompard hingewiesen. Es enthält Pakete, die sich auf Fedora 20 und 21 sowie RHEL 7 installieren lassen.

Die besondere Verbindung zwischen dem Mailman-Projekt und Fedora liegt darin, dass es sich bei Hyperkitty um eine Entwicklung der Fedora-Community handelt. Das Repository bietet auch Mailman Core sowie Postorius und zusätzlich benötigten Python-Pakete feil. Erklärtes Ziel ist es, jene Pakete kurzfristig auch als offizielle Pakete in die Fedora-Distribution aufzunehmen. Eine Testinstallation unter Centos 7 verlief beim Linux-Magazin erstaunlich sauber.

Nach Aktivierung des Repository sind folgende Pakete zu installieren:

• »mailman3« ,
• »mailman3-hyperkitty« (ein Adapter zwischen Mailman 3 und Hyperkitty),
• »hyperkitty« ,
• »postorius«

sowie alle zugehörigen Abhängigkeiten. Außerdem sind noch manuell die Pakete »python-whoosh« und »python-BeautifulSoup« zu installieren, die eigentlich als Abhängigkeit hätten automatisch installiert werden sollen. Als Webserver kommt Apache (Paket »httpd« ) und zur Anpassung an Python das Modul »mod_wsgi« zum Einsatz.

Die Pakete installieren sauber etwa die Startskripte für die Services, Konfigurationen für Logrotate sowie jene für Postorius und Hyperkitty unter »/etc/httpd/conf.d/« . Dort finden sie bereits die Konfiguration der WSGI-Anbindung:

WSGIScriptAlias /hyperkitty /etc/hyperkitty/sites/default/wsgi.py
WSGIDaemonProcess hyperkitty threads=25 python-path=/etc/hyperkitty/sites/default

Bei der Arbeit mit den vorgefertigten Paketen gilt es dann lediglich, noch ein paar kleinere Fehler in »postorius.conf« und »hyperkitty.conf« zu korrigieren. Da bei Centos 7 der Apache-Httpd in Version 2.4.x zum Einsatz kommt, benötigt der Admin statt der enthaltenen Angaben für Apache 2.2

Order deny,allow
Allow from all

dieses 2.4-Pendant:

Require all granted

Bei paralleler Installation von Postorius und Hyperkitty auf demselben Server überlappen sich außerdem die Aliasse für »/static« (sowie für die »favicon.ico« ) in der Konfiguration. Hier verwendet der Admin einfach einzelne Aliasse für die benötigten Verzeichnisse unterhalb von »/static« , wie in Listing 1 zu sehen. Die weiteren Verzeichnisse »admin« und »browserid« aus dem Postorius-Paket werden automatisch über die gleichnamigen Verzeichnisse des Hyperkitty-Pakets mitgenutzt.

01 # für hyperkitty
02 Alias /static/admin      /var/lib/hyperkitty/sites/default/static/admin
03 Alias /static/browserid        /var/lib/hyperkitty/sites/default/static/browserid
04 Alias /static/CACHE      /var/lib/hyperkitty/sites/default/static/CACHE
05 Alias /static/django_extensions     /var/lib/hyperkitty/sites/default/static/django_extensions
06 Alias /static/hyperkitty       /var/lib/hyperkitty/sites/default/static/hyperkitty
07 Alias /static/paintstore       /var/lib/hyperkitty/sites/default/static/paintstore
08 Alias /static/rest_framework   /var/lib/hyperkitty/sites/default/static/rest_framework
09 # für postorius
10 Alias /static/postorius        /var/lib/postorius/sites/default/static/postorius

Beim Einsatz der aktuellen Pakete trat bei späteren Tests noch ein Problem mit Hyperkitty auf, das beim Start weder seine Einstellung einlesen, noch die Datenbank oder Cachedateien anlegen konnte. Leider gab es im schlimmsten Fall sogar einen nichtssagenden “Internal Server Error”, da Mailman 3 Fehler noch nicht überall sauber abfängt. Grund hierfür sind fehlende Rechte des Apache-Benutzers auf die entsprechenden Verzeichnisse aus den Paketen. Ein einfacher Workaround ist es, jene Verzeichnisse dem Apache-User zuzuschlagen:

chown -R apache:apache /var/lib/hyperkitty/sites/default
chown -R apache:apache /var/lib/postorius/sites/default

Anschließend erledigt der Admin noch Standardaufgaben wie die Installation von Postfix, die Ergänzung der Postfix-Konfiguration (»main.cf« ), die Installation von PostgreSQL (falls gewünscht), den Start der Dienste und die Freigabe von Ports in der Firewall.

Fazit

Die aktuell noch bestehenden Hürden bei der Installation von Mailman 3 trüben die Freude über die neue Version. Dass noch (fast) keine Pakete für gängige Distributionen existieren, erschwert die ersten Schritte zusätzlich. Man wird das ungute Gefühl so schnell nicht los, hier trotz des Zusatzes “stabil” noch mit sehr frischer Software zu arbeiten.

Ist die Installation gemeistert, die Grundkonfiguration vorgenommen, die erste Nachricht erfolgreich über die Listen versandt, entschädigt der Blick in das Hyperkitty-Webinterface für manche Strapazen. Tatsächlich haben sich die Mailman-Entwickler eine Menge Fehlerkorrekturen oder dringend notwendige Funktionen bereits für die Version 3.1 auf die Liste geschrieben.

Auch sollte man trotz eines schicken Webinterface nicht übersehen, dass alle Meldungen in Englisch erfolgen. Lokalisierungen existieren bisher nicht. Für Endanwender kann dies eine Hürde darstellen. Wer möchte, kann allerdings selbst Hand anlegen, denn grundsätzlich ist Internationalisierung an vielen Stellen bereits berücksichtigt. Weiterführende Features wie eine Anbindung von Mailman Core per NNTP, die Mailman 2 beherrschte, stehen fest auf der Wunschliste, sind aber bisher noch nicht auf die neue Architektur portiert.

Wer Erfahrung mit Mailman 2 vorweisen kann, wird schnell feststellen, dass Mailman 3 eine von Grund auf neu konzipierte Suite ist. Betrachtet man die aktuelle Version als technische Vorschau auf eine neue Mailman-Ära, zeigen sich deutliche Stärken und eine Menge Potenzial des Programms. Die siebenjährige Arbeit hat sich gelohnt. Mailman 3 ergibt vom Konzept der einzelnen Teilkomponenten sowie ihrer Schnittstellen und der klaren Aufgabentrennung durchaus Sinn. Die Modularität ermöglicht in Zukunft auch individuelle Integrationen.