© Suprijono Suharjoto, Fotolia

Mailinglisten-Software muss viel mehr leisten als nur das schnöde Verteilen von Mail. Die Spreu trennt sich vom Weizen, wenn es um komfortable Verwaltungsfunktionen für Admins und Anwender geht. Das Linux-Magazin untersucht fünf Programme und deckt ihre Unterschiede auf.

Wenn es darum geht, eine eingehende E-Mail an mehrere Empfänger zu verteilen, ist die erste Idee vermutlich, einen Alias-Eintrag im verwendeten Mailsystem (MTA) einzurichten (siehe den Artikel zur LPI-Zertifizierung in dieser Ausgabe des Linux-Magazins). Schnell wünschen sich allerdings Benutzer und Administratoren auch Funktionen über das schlichte Verteilen hinaus. Eine Software für das Verwalten von Mailinglisten bietet mehr Komfort.

Der Mailserver nimmt dabei nach wie vor die eingehenden E-Mails an und stellt sie auch an die Empfänger zu. Die Mailinglisten-Software koordiniert jedoch das Verteilen und verwaltet die Nachrichten der Listenmitglieder (Subskribenten). Sie kümmert sich in der Regel um mehrere unabhängige Mailinglisten und verwaltet manchmal sogar mehrere Mail-Domains.

Um die Verwaltungssoftware zu steuern, haben sich drei Ansätze herausgebildet: Teilnehmer auf Listen haben – erstens – praktisch immer die Möglichkeit, Aufträge über besondere E-Mails zu steuern. Die fünf vorgestellten Programme unterschieden sich durchaus in der Intelligenz, mit der sie Anweisungen der Nutzer interpretieren, die diese an eine spezielle E-Mail-Adresse schicken.

Als zweite Möglichkeit bringen neuere Programme ein Webfrontend mit. Admins und Systemintegratoren freuen sich als dritte Variante über eine einfach zu bedienende Kommando-Schnittstelle. Letzteres kommt für die Teilnehmer auf den Mailinglisten nur in Ausnahmefällen in Betracht, da nicht alle den erforderlichen Shellzugriff auf das Verwaltungssystem haben.

Abonnentenservice

Abonnenten verwalten ihre Mitgliedschaften am liebsten über ein Webfrontend. Dort sehen sie auf einen Blick, in welchen Listen sie eingeschrieben sind, können sich an- und abmelden oder persönliche Einstellungen verändern. Einige Systeme bieten eine mehrsprachige Menüführung an und erlauben es sogar, über Templates die Darstellung anzupassen. Häufig ist auch eine Archiv-Funktion integriert, die das Blättern durch frühere Nachrichten sowie das Suchen über Mailinglisten-Inhalte unterstützt.

Umfangreiche Funktionen

Als zentrale Funktion wachen Mailinglisten darüber, wer versenden und wer lesen darf. Üblich ist, dass nur auf der Liste angemeldete Mailadressen für den Versand freigeschaltet sind oder ein Moderator eine Meldung freigibt, bevor sie das System verteilt. Es stellt die Nachrichten entweder direkt oder in einer beispielsweise täglichen Zusammenfassung (Digest) an die Abonnenten zu.

Möchte ein Absender von wechselnden E-Mail-Adressen aus Nachrichten versenden, muss er bei geschlossenen Listen jede Adresse registrieren. Um E-Mails dann nicht auch mehrfach zu erhalten, erlauben es Mailinglisten-Tools, Adressen als »non-delivery subscriber« zu markieren. Damit stellt das System an diese Adressen keine Nachrichten zu.

Fast alle Mailinglisten-Programme verschicken technisch gesehen eine neue E-Mail und leiten die ursprüngliche Nachricht nicht nur weiter. Dass diese eine Reply-to-Adresse haben, ist ein Zeichen dafür. Die Programme tun dies, damit Antworten auf solche Nachrichten automatisch auch wieder alle Empfänger erreichen.

Um die Zugehörigkeit von E-Mails zu einer bestimmten Liste auf den ersten Blick leicht zu erkennen, ist es außerdem üblich, den Betreff automatisch mit einem Präfix zu versehen. Footer oder spezielle Headerzeilen im Kopf der Nachricht nennen das Thema der Liste oder geben dem Empfänger Hinweise, wie er sich wieder von der Liste austrägt.

Achtung, Kettenreaktion!

Es gilt als mühsam, Rückläufer bei großen Mailinglisten manuell zu pflegen. Einige Programme nehmen dem Admin die Verwaltung der Bounces ab. Dies unterscheidet sie beispielsweise von reinen Alias-Listen, denn diese würden im schlimmsten Fall eine erneute Nachricht an alle Teilnehmer auslösen. Eine Kettenreaktion wäre das Resultat.

Die Aufgabe einer Mailinglisten-Software ist es, solche Rückmeldungen zu filtern und auszuwerten. So ist es beispielsweise möglich, Empfängeradressen mit permanenten Fehlern kurzzeitig oder dauerhaft von der weiteren Mailverteilung auszuschließen. Um Rückläufer eindeutig einem bestimmten Empfänger zuzuordnen, unterstützen viele Systeme individuelle Antwortadressen im Umschlag der E-Mail (VERP, Variable Envelope Return Path). Große Mailinglisten lassen die VERP-Adressen direkt vom MTA erledigen [1].

Einige Programme bieten zusätzlich an, eine Nachricht gleich an eine Vielzahl von Empfängern gemeinsam im Envelope zu adressieren. Das empfiehlt sich, um bei großen Empfängerlisten nicht Tausende von Nachrichten einzeln einzuliefern und Platz in der Mailqueue zu belegen. Stattdessen kümmert sich der MTA darum, die Nachrichten an alle Empfänger zu verteilen. Mailinglisten-Experten schlagen jedoch vor, die Anzahl solcher Empfänger auf etwa 5000 zu begrenzen, um dem MTA eine Parallelisierung der Auslieferung zu ermöglichen [2]. Mailman konfiguriert dieses Verhalten über den Parameter »SMTP_MAX_RCPTS« in »mm_cfg.py«.

Gut eingebunden

Eingehende Nachrichten erhält die Software vom MTA über dessen Alias-Mechanismus. In der Datei »/etc/aliases« legt der Mail-Admin fest, für welche Mailadressen der MTA die Mailinglisten-Software aufruft. Das Beispiel in Listing 1 ruft das Tool Mailman per Pipe auf und übergibt ihm als Parameter unter anderem den Namen der Mailingliste. Es wechselt per SUID-Bit zum Mailinglisten-User und empfängt die eigentliche Nachricht per »stdin«.

Ausgehende Nachrichten sendet die Mailingliste über ein Sendmail-kompatibles Programm wie »/usr/sbin/sendmail« an den MTA, einige Programme beherrschen zusätzlich auch direkt SMTP, beispielsweise an »localhost:25«. Sinnvoll ist hierbei, Nachrichten einer Mailingliste über einen separaten lokalen SMTP-Port (zum Beispiel 10025) ohne vorgeschaltete Spam- und Virenprüfung einzuliefern. Dies verbessert bei einer großen Anzahl von Abonnenten den Durchsatz erheblich.

Die Inhalte sollte der verantwortliche Admin besser vor dem Eingang in die Mailingliste auf Spam und Viren prüfen lassen. Wer separate Alias-Dateien verwendet (im Fall von Mailman etwa »/var/lib/mailman/data/aliases«), hat Vorteile, weil die Mailinglisten-Software jene Datei dann selbstständig pflegt, wenn Anwender neue Listen anlegen. Bei Postfix reicht hierfür ein entsprechender Eintrag in »main.cf«:

alias_maps = hash:/etc/aliases,hash:/var/lib/mailman/data/aliases

Manche Mailinglisten-Software verwendet separate Aliase für Nachrichten an die Liste und Steuernachrichten. Bei anderen kommen sogar noch mehr separate Aliase beispielsweise für den Admin oder zum Subscriben und Unsubscriben hinzu (siehe Listing 1).

Abbildung 1: Majorcool ist ein Webfrontend für den Ahnvater der Listenverwaltungen: Majordomo. Der ist zwar ein Klassiker, wird aber nicht mehr gepflegt.

01 # Auszug aus /var/lib/mailman/data/aliases
02 liste:             "|/var/lib/mailman/mail/mailman post liste"
03 liste-admin:       "|/var/lib/mailman/mail/mailman admin liste"
04 liste-bounces:     "|/var/lib/mailman/mail/mailman bounces liste"
05 liste-confirm:     "|/var/lib/mailman/mail/mailman confirm liste"
06 liste-join:        "|/var/lib/mailman/mail/mailman join liste"
07 liste-leave:       "|/var/lib/mailman/mail/mailman leave liste"
08 liste-owner:       "|/var/lib/mailman/mail/mailman owner liste"
09 liste-request:     "|/var/lib/mailman/mail/mailman request liste"
10 liste-subscribe:   "|/var/lib/mailman/mail/mailman subscribe liste"
11 liste-unsubscribe: "|/var/lib/mailman/mail/mailman unsubscribe liste"

Majordomo: Der Klassiker

Als Klassiker darf sich Majordomo [3] bezeichnen. Das Programm war einst der Quasistandard für Mailinglisten-Software. Entwickelt und betreut hat es Great Circle Associates. Majordomo steht jedoch unter einer eingeschränkten Open-Source-Lizenz, die es Dritten erschwert, das Programm weiterzuentwickeln und zu verbreiten. Seit 1997 hat niemand die Software aktualisiert, außer einer Fix-Release im Jahr 2000. Sie weist mittlerweile einige nicht geschlossene Sicherheitslücken auf.

Die überwiegend in Perl geschriebene Software unterstützte bereits damals eine Vielzahl von Features wie moderierte Listen oder den Versand von Nachrichten-Digests. Ein Webinterface gehört nicht zum Umfang, ließe sich jedoch beispielsweise in Form von Majorcool [4] separat nachrüsten (Abbildung 1). Viele Nutzer von Majordomo haben mittlerweile zu Mailman gewechselt, das seine Entwickler regelmäßiger pflegen und das einige zusätzliche Eigenschaften aufweist, aber sonst dem Klassiker hinsichtlich des Bedienkonzepts nahekommt.

Mailman: Leistungsstark

Dass GNU Mailman [5] in Python implementiert ist, wundert wenig, schließlich gehört Autor Barry Warsaw zu den Python-Core-Entwicklern. In Bezug auf Stabilität, Leistung und Features hat sich das System auch in sehr großen Installationen bewährt. Es enthält eine Weboberfläche für nahezu alle Aufgaben wie das Konfigurieren von Listen, das Moderieren oder die Benutzerverwaltung. Selbst HTML-Templates für das Webinterface kann der Admin dort pflegen.

Auch Benutzer ändern bequem per Webbrowser ihre Einstellungen (siehe Abbildung 2) oder greifen auf das eingebaute Archivsystem Pipermail zu. Wer statt des eingebauten Archivsystems lieber eine externe Lösung wie beispielsweise den Mail-zu-Web-Konverter Mhonarc [6] einsetzen möchte (siehe Abbildung 3), findet die Möglichkeit auch über entsprechende Hooks. Features wie integriertes Filtern von Spam und ein Gateway ins Usenet runden den positiven Gesamteindruck ab.

Abbildung 2: Mailman gilt aktuell als heimlicher Marktführer der Verwalter von Mailinglisten. Sein Frontend ist schicht, aber effektiv.

Abbildung 3: Der Konverter Mhonarc bereitet E-Mails zum bequemen Browsen im Web auf. Das Werkzeug lässt sich leicht in Mailman integrieren.

Der Betrieb einer einzelnen Mailman-Instanz für mehrere Domains mit einer individuellen Übersicht ihrer Listen ist über die integrierte Funktion für virtuelle Domains ebenfalls möglich. Allerdings dürfen Listen unter zwei verschiedenen Domains in der aktuellen Version 2.1.9 leider nicht den gleichen Namen tragen, zum Beispiel nicht jeweils »kontakt« heißen. Die schon seit Langem erwartete Version 3.0 soll dieses Problem beheben und das Programm rundum erneuern, weil die Entwickler es in Teilen komplett neu entwickeln. Bislang ist allerdings noch kein Termin für die erste neue Major-Release absehbar.

Ebenfalls erst für Version 3.0 ist ein echtes Datenbank-Backend geplant, das umfangreichere Verwaltungsaufgaben vereinfachen würde. Derzeit setzt Mailman das Python-Modul »pickle« ein, das aber nur Daten in einer serialisierten Form speichert. Komplexe Aufgaben löst der Admin daher über den Umweg eines Python-Skripts. Mailman stellt hierzu neben den regulären Konfigurationswerkzeugen auch das Tool »withlist« vor, das ein Python-Objekt für die als Parameter übergebene Mailingliste instanziiert. Eine Shell erlaubt damit interaktiven Python-Zugriff auf das Objekt (siehe Kasten “Mailman automatisiert”). Wenn Tausende Nachrichten unmoderiert in der Queue hängen und das Webinterface blockieren, ist dies ein willkommener Ausweg für den Admin.

m.Lock()
from Mailman import mm_cfg
h = m.GetHeldMessageIds()
for i in h:
    m.HandleRequest(i, mm_cfg.DISCARD)

m.Lock()
m.web_page_url='http://example.org/mm/'
m.Save()
m.Unlock()

Mailman integriert zwar nicht direkt Verzeichnisdienste wie LDAP, um aus ihnen automatisch Listen zu bilden, aber über separate Tools lässt sich diese Funktion nachrüsten [7].

Sympa: Flexibel ange-bunden

Zwar ist das Mailinglisten-System Sympa [8] jünger als die beiden bereits vorgestellten Pakete, hat aber ähnliche Eigenschaften und Leistungsdaten – und übertrifft sie in einigen Punkten sogar. Eine, zugegebenermaßen nicht immer ganz unproblematische, Internationalisierung sowie die Anpassung über Templates zeichnen die aus Frankreich stammende Software aus. Das mit der Distribution ausgelieferte Layout der Weboberfläche lässt sich zwar anpassen, erinnert aber eher an den Bedienkomfort des Web 0.9 (siehe Abbildung 4).

Abbildung 4: Sympa punktet zwar mit umfangreichen Features und lässt sich an LDAP und Datenbanken anbinden, das Webinterface hätte jedoch dringend einen Usability-Experten sowie einen neuen Anstrich verdient.

Sympa punktet, weil es eine ganze Reihe von RDBMS verwenden kann, darunter MySQL, PostgreSQL, Oracle und Sybase. Die Software unterstützt verschiedene Mechanismen für die Authentisierung der Benutzer, darunter Single-Sign-on-Systeme oder LDAP. Über Letzteres lassen sich auch Gruppenmitgliedschaften und deren zentrale Pflege realisieren. RSS-Feeds erlauben es, die Nachrichten auf der Liste in Websites einzubinden. Wer Sympa in andere Anwendungen integrieren möchte, tut dies über das SOAP-Interface – Beispiel-Clients für Perl und PHP liefern die Entwickler mit.

Ezmlm: Der Qmail-Weg

Wer sich beim MTA für Daniel J. Bernsteins Qmail entschieden hat, für den ist Ezmlm [9] die passende Mailinglisten-Erweiterung aus demselben Haus. Der Name steht offenbar für “Easy mailinglist manager” (einfache Verwaltung für Mailinglisten). Zwar lassen sich die anderen hier vorgestellten Systeme prinzipiell auch mit Qmail verwenden, umgekehrt gilt dies aber nicht.

Ezmlm setzt auf Qmail auf und bietet Basisfunktionen für Mailinglisten. Es verwaltet Empfänger und Versandarten und behandelt Bounces. Weitere Funktionen fügt der Admin in Form von Addons hinzu. Mit Ezmlm-Idx beispielsweise führt er ein Archiv und kann Listen konfigurieren, moderieren und pflegen sowie internationalisieren. Die Erweiterung Ezmlm-Web integriert ein Webinterface (siehe Abbildung 5).

Abbildung 5: Die Lizenzpolitik von Qmail und der daran angelehnten Listenverwaltung Ezmlm war lange umstritten. Anhänger der beiden Systeme rühmen jedoch das schlanke Design und betonen vor allem den Sicherheitsaspekt der Software.

Auf Grund der bis Ende 2007 strikten Lizenz war Qmail nur mühsam zu nutzen, da keine aktive Entwicklung stattfand und statt modifizierter Pakete lediglich Patches verteilt werden durften. Mit der Öffnung bleibt für alle Qmail-Anhänger nun zu hoffen, dass sich hier noch etwas entwickelt. Aktuell arbeitet niemand aktiv an Ezmlm – vielleicht hat die Öffnung von Qmail ja einen positiven Einfluss.

Mlmmj: Brillant offen

Mit Mlmmj [10] entstand in den letzten Jahren eine bisher weitgehend unbekannte Mailinglisten-Software, deren Feature-Umfang dem Vorbild Ezmlm nicht nachsteht. Ziel ihres Autors ist es, eine Software nach Vorbild des “brillanten Ezmlm” zu schaffen, die aber anders als einst das Vorbild unter einer freien MIT-Lizenz steht. Das Programm ist neben Qmail auch zu anderen Mailsystemen kompatibel. Die Nutzergemeinde ist noch überschaubar – ein Eindruck, den auch die Website sowie das Mailinglisten-Archiv bestätigen. Dennoch lohnt es sich, das System zu beobachten.

Grundsolide – junge Wilde

Ihre Grundfunktionen erledigen alle fünf Programme klaglos. Die Spreu trennt sich vom Weizen, wenn es um Bequemlichkeit geht. Musterknaben sind die Tools hinsichtlich der Bedienung alle nicht, ein leichter Schuss Web 2.0 täte den Webfrontends durchaus gut.

Wer keine bestehende Installation pflegt, wird vermutlich vom Einsatz von Majordomo absehen. Wer bereits mit Qmail gearbeitet hat, kennt sich vielleicht bereits auch mit Ezmlm aus. Die Weiterentwicklung Mlmmj ist dann durchaus eine Überlegung wert.

Admins, die auf etablierte Systeme setzen möchten, entscheiden sich zwischen Mailman und Sympa. Zwar ist bei Mailman die Entwicklung der Version 3.0 bereits im Gange, sehr bald jedoch sind kaum Neuerungen zu erwarten. Wer mit den Features zufrieden ist und auf ein System setzt, das bereits seit einigen Jahren stabil und auch unter Last zuverlässig seinen Dienst verrichtet, trifft mit Mailman eine solide Entscheidung. Jenen Nutzern, die Wert auf Features wie Datenbank-Backends, LDAP-Anbindung, RSS und eine SOAP-Schnittstelle legen, sei Sympa ans Herz gelegt. (mg)