Wenn's um den Mailversand an viele Empfänger geht, ist Mailman die passende Software. Doch bis alles läuft, müssen Sie das komplexe System erst mal konfigurieren. Auch der Umgang mit Listenmoderation, Spammern, Querulanten jeder Art und neugierigen Suchmaschinen-Spidern will gelernt sein.

Für Open-Source-Projekte sind sie unverzichtbar: Fast jedes verfügt heute über mindestens eine, wenn nicht eine ganze Herde Mailinglisten, auf denen sich Anwender austauschen oder Entwickler über technische Fragen diskutieren. Das Tool der Wahl ist dabei häufig der Listenmanager Mailman[1], der sich in jeder gut sortierten Linux-Distribution findet. Zwar hat er durchaus noch einige Konkurrenten wie die Klassiker Majordomo[2] und Ezmlm[3] neben sich. Doch Mailman überzeugt durch gute Performance auch bei sehr großen Verteilern und vor allem durch sein komfortables Webinterface.

Per Browser verwalten Benutzer ihre Abonnements, das integrierte Tool Pipermail erzeugt HTML-Archive der Listen und auch die Administration lässt sich komplett übers Web erledigen, wenn Sie nicht auf den Satz mitgelieferter Kommandozeilentools zurückgreifen wollen. Dass Mailman in Python geschrieben ist, sollte niemanden wundern: Autor Barry Warsaw gehört zu den Python-Core-Entwicklern.

Wer Mailman partout selbst übersetzen will, findet im Kasten “Mailman kompilieren” Hinweise dazu. Einfacher ist es jedoch, das fertige Paket einer aktuellen Distribution zu nutzen. Auch hier schadet ein Blick in das zugehörige Readme nicht, zumindest müssen Sie bei den nachfolgenden Einstellungen prüfen, ob Ihre Distribution sie ordnungsgemäß vorgenommen hat. Ohne manuelle Arbeit läuft Mailman in der Regel nicht.

Apache anpassen

Als Erstes nehmen Sie das zugehörige Webinterface in Betrieb. Mailman stellt dafür einige CGI-Programme bereit, die im Regelfall unter »/usr/lib/mailman/cgi« installiert sind. Statt diese in das »cgi-bin« des Webservers zu kopieren, verwenden Sie besser im Apache die Parameter »ScriptAlias« und »Alias«. In der »httpd.conf« ergänzen Sie an passender Stelle in den Host-Einstellungen folgende Zeilen – prüfen Sie aber zuerst noch, ob Ihre Distribution das nicht bereits erledigt hat:

ScriptAlias /mailman/ 
/usr/lib/mailman/cgi-bin/
Alias       /mailmanicons/ 
/usr/lib/mailman/icons/
Alias       /pipermail/ 
/var/lib/mailman/archives/public/

Nach einem Neustart des Webservers sehen Sie unter der URL »http:// Servername/mailman/listinfo« eine leere Listenübersicht. Erhalten Sie stattdessen Warnungen über falsche User- oder CGI-IDs, beachten Sie bitte den Kasten “Mailman kompilieren”.

Mailman konfigurieren

Die Datei »/usr/lib/mailman/Mailman/ Defaults.py« enthält ausführlich kommentiert alle möglichen Parameter für Mailman. Da schon das nächste Update diese Datei möglicherweise überschreibt, ändern Sie sie nicht direkt, sondern kopieren die Parameter, die Sie anpassen wollen, aus »Defaults.py« an das Ende der Konfigurationsdatei »mm_cfg.py«. Listing 1 zeigt ein Beispiel für die Grundeinstellungen.

Mailman versendet seine Nachrichten per SMTP an »localhost«, Port 25 (Zeilen 1 bis 3). »SMTP_MAX_RCPTS« in Zeile 4 legt fest, dass er bei Listen mit sehr vielen Abonnenten mehrere E-Mails mit jeweils 5000 Empfängern generiert. Die explizite Angabe des benutzten Mailservers in Zeile 5 ist für den Versand irrelevant, hilft Mailman aber später dabei, Konfigurationsdateien wie die »aliases.db« für den MTA automatisch bereitzustellen. Die Angabe von Hostnamen und URL (Zeile 7 bis 9) sorgt dafür, dass die von Mailman erzeugten E-Mails korrekte Absender tragen und das Webinterface die richtigen Links erzeugt.

Der Mail Transfer Agent (MTA) muss wissen, was er an Mailman weiterreichen soll. Der Listenmanager arbeitet mit beliebigen Mailservern zusammen, etwa Postfix, Sendmail, QMail oder Exim. Dieser Artikel erklärt die Konfiguration anhand von Postfix. Wer einen anderen Mailserver einsetzt, findet unter den Readme-Dateien im Mailman-Paket für die gebräuchlichsten MTAs jeweils eigene Anleitungen. Der Mailserver muss auf die passende Maildomain der künftigen Mailinglisten hören, zum Beispiel »listen.postfixbuch.de«.

Eine eigene Subdomain für die Mailinglisten anzulegen ist ratsam. Sollten irgendwann Postfächer und Mailinglisten auf unterschiedlichen Servern lagern, richten Sie anhand der Domains leicht das passende Routing ein.

./configure --prefix=/usr/lib/mailman 
--sysconfdir=/etc --localstatedir=
/var/run --libexecdir=/usr/lib/mailman 
--mandir=/usr/share/man --with-groupname=
mailman --with-username=mailman 
--with-var-prefix=/var/lib/mailman 
--with-cgi-gid=nogroup 
--with-mail-gid=mailman

Kooperation mit dem MTA

Mailman selbst besitzt keine SMTP-Schnittstelle für die Annahme der E-Mails. Genau wie beim früher sehr verbreiteten Mailinglisten-Manager Majordomo gelangen die Mails über Einträge in der »aliases«-Tabelle des Servers ins System. Mailman kann die systemweite »/etc/aliases« benutzen, sicherer und stabiler ist es aber, wenn Mailman eine eigene »aliases«-Tabelle unter »/var/lib/ mailman/data/aliases« bekommt und der MTA stattdessen beide Dateien parallel auswertet. So kommt der Admin Mailman nicht in die Quere, wenn er eigene »aliases«-Einträge pflegt. Postfix sollte darum in der »main.cf« folgenden Eintrag haben:

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

Für alle Listen enthält die Tabelle mehrere Einträge, die die ankommenden E-Mails an Mailman pipen. Aufrufparameter bestimmen, an welches Mailman-Modul der MTA die Nachricht per Standard-In übergibt. Die Module, ausgestattet mit dem Namen der Liste (in Listing 2 »debatten«), verarbeiten die Anfrage weiter, verteilen die Mail zum Beispiel an die Liste (»post«), tragen den Absender in die Liste ein (»subscribe«) oder registrieren eine Bestätigung (»confirm«).

Abbildung 1: Eine neue Liste legt der Admin über das – ausführlich kommentierte – Webinterface an. Dort trägt er den Listeneigentümer ein, der die Liste später konfigurieren und verwalten soll.

Per Pipe und Alias ans richtige Modul

Diese Einträge erzeugt Mailman automatisch, wenn Sie eine neue Liste über das Webinterface oder das Konsolenprogramm »newlist« anlegen. Ist in der Konfiguration der richtige MTA eingestellt, kümmert sich Mailman gleichzeitig um den Aufruf von »newaliases« oder »postalias«, um die Datei ordentlich in die »aliases.db« zu konvertieren.

Jede Mailingliste ist durch ein Kennwort geschützt, das im Idealfall nur der Listenverwalter kennt. Der Administrator hat über ein Master-Passwort im Webinterface Zugriff auf alle Mailinglisten. Dieses Passwort setzen Sie auf Shell-Ebene mit dem Befehl »/usr/lib/mailman/bin/mmsitepass«.

01 DELIVERY_MODULE = 'SMTPDirect'
02 SMTPHOST = 'localhost'
03 SMTPPORT = 25
04 SMTP_MAX_RCPTS = 5000
05 MTA = 'Postfix'
06 
07 DEFAULT_EMAIL_HOST = 'listen.postfixbuch.de'
08 DEFAULT_URL_HOST = 'www.postfixbuch.de'
09 DEFAULT_URL_PATTERN = 'http://%s/mailman/'
10 
11 DEFAULT_SERVER_LANGUAGE = 'de'
12 IMAGE_LOGOS = '/mailmanicons/'

Über das Webinterface legen Sie neue Mailinglisten an. Auch dafür gibt es ein eigenes Kennwort, das Sie mit »mmsitepass -c« erzeugen. Verteilen Sie es nicht zu frei – jeder, der es kennt, kann nach Belieben Listen generieren.

Eine neue Liste ist mit der Einrichtung sofort funktionsfähig, eine erste sollten Sie auch gleich anlegen: Die spezielle Liste mit dem Namen »mailman« muss existieren, das Programm braucht sie für die interne Verwaltung.

Zum Anlegen nutzen Sie das Webinterface unter »http:// Servername/mailman /create« (Abbildung 1). Tragen Sie »mailman« als Listennamen ein, Ihr eigenes Postfach als Admin-Mailadresse und markieren Sie den Button »Passwort automatisch erzeugen«, Sie brauchen es später nie wieder. Ins letzte Feld gehört das eben eingerichtete Kennwort, um neue Listen zu erzeugen.

Alle Tage wieder

Auch wenn er gerade keine E-Mails verteilt, hat Mailman viel zu tun: Nachts packt er Online-Archive, einmal im Monat schickt er Passworterinnerungen an alle Listenmitglieder, täglich erstellt er für Listen-Owner auf Wunsch einen Statusreport über zu moderierende Nachrichten und überprüft, ob wegen Unzustellbarkeit vorübergehend deaktivierte Listenmitglieder wieder Mails empfangen können.

In »/usr/lib/mailman/cron/crontab.in« bringt Mailman eine vorbereitete »cron«-Tabelle mit, die die meisten Distributionen bereits installiert haben. Einige Systeme kopieren dazu diese Datei nach »/etc/cron.d/mailman«, andere haben sie direkt für den User Mailman hinterlegt, sodass sie darin über »crontab -e -u mailman« die Uhrzeit der Aktionen anpassen können. Suse-Benutzer sollten darauf achten, welche Datei sie bearbeiten: Das Startskript kopiert nämlich bei jedem Neustart die Datei »/usr/lib/mailman/cron/crontab« nach »/etc/cron.d/ mailman«.

01 debatten:             "|/usr/lib/mailman/mail/mailman post debatten"
02 debatten-admin:       "|/usr/lib/mailman/mail/mailman admin debatten"
03 debatten-bounces:     "|/usr/lib/mailman/mail/mailman bounces debatten"
04 debatten-confirm:     "|/usr/lib/mailman/mail/mailman confirm debatten"
05 debatten-join:        "|/usr/lib/mailman/mail/mailman join debatten"
06 debatten-leave:       "|/usr/lib/mailman/mail/mailman leave debatten"
07 debatten-owner:       "|/usr/lib/mailman/mail/mailman owner debatten"
08 debatten-request:     "|/usr/lib/mailman/mail/mailman request debatten"
09 debatten-subscribe:   "|/usr/lib/mailman/mail/mailman subscribe debatten"
10 debatten-unsubscribe: "|/usr/lib/mailman/mail/mailman unsubscribe debatten"

Startklar

Wer Mailman als Distributionspaket installiert hat, findet in der Regel bereits ein passendes Startskript unter »/etc/init.d/mailman«. Andernfalls nutzen Sie das mitgebrachte Kontrollprogramm und starten Mailman über »/usr/lib/mailman/bin/mailmanctl start«. Funktioniert alles problemlos, dann sind in der Prozessliste acht »qrunner«-Prozesse zu finden, die die Warteschlangen (Queues) eigenständig abarbeiten.

Die erste richtige Mailingliste legen Sie wie oben dargestellt an und loggen sich anschließend über »http:// Servername/mailman/admin« als Admin ein. Das Admin-Interface wirkt anfänglich etwas unübersichtlich, dahinter verbirgt sich jedoch eine durchaus logische Struktur (Abbildung 2). Verschaffen Sie sich zuerst einen Überblick über die einzelnen Menüpunkte und Einstellmöglichkeiten.

Entweder als Administrator über den Bereich »Mitgliederverwaltung« oder als normaler Nutzer über das öffentliche Interface auf »http:// Servername/mailman/listinfo« tragen Sie die ersten Testempfänger ein. Wenn Sie eine Mail an »mailman-owner@ Servername« senden, sollte Mailman diese nach wenigen Sekunden an die vorhin hinterlegte Admin-Adresse weiterleiten. Auch eine erste Mail an die eben angelegte Testliste, sollte er nach kurzer Zeit verteilen.

Abbildung 2: Das Admin-Interface bietet Zugriff auf alle Einstellungen einer Liste. Dort tragen Sie Eigentümer und Moderatoren ein und gestalten den Text, den Mailman auf der Listenübersicht-Seite anzeigt.

Auf dem Weg durchs System

Ein Blick in die Logfiles des Systems macht den Weg der E-Mail durch das System klar (Abbildung 3): Der MTA empfängt die Mail, prüft, ob er für die Maildomain zuständig ist, und wertet die »aliases«-Tabellen aus. Daraufhin startet er das Programm »mailman« mit den passenden Aufrufparametern und und übergibt die E-Mail – das lässt sich in »/var/log/mail« nachvollziehen.

Mailman puffert die E-Mail zuerst in »/var/lib/mailman/qfiles/in«. Kurz darauf liest ein Qrunner-Prozess sie dort aus und legt sie mit der Empfängerliste der angeschriebenen Mailingliste in »out« ab. Ein weiterer Qrunner-Prozess übergibt die dort lagernden Mails per SMTP an »localhost:25«. Auch darüber gibt es Aufzeichnungen in den Logfiles, Mailman protokolliert per Default nach »/var/lib/mailman/logs/smtp«.

Zurück beim MTA angelangt, ist die Testmail nun an andere Empfänger adressiert. Der Mailserver macht sich ans Werk und stellt sie zu, wie ein Blick in »/var/log/mail« zeigt. Mailman ist jetzt einsatzfähig.

Abbildung 3: Ablaufschema: Über die »aliases«-Datei des MTA oder das CGI-Interface gelangen E-Mails in die In-Queue von Mailman, der sie in »/var/spool/mailman/qfiles/in« speichert. Die Mailman-Module Incoming, Outgoing und Arch Runner verarbeiten sie weiter: Der Outgoing Runner stellt sie über den MTA an die Listenabonnenten zu, Arch Runner generiert ein Webarchiv.

Performance-Tuning

Für den erfolgreichen Betrieb eines Mailinglisten-Servers sind Stabilität und Zuverlässigkeit wichtig – nicht zu unterschätzen sind die Probleme, die auftauchen, wenn es um E-Mail-Zahlen im zweistelligen Millionenbereich geht. Mit den folgenden Tipps zur Performance Ihres Mailman-Servers gehen Sie häufigen Fehlern aus dem Weg.

Wer auf dem Mailinglisten-Server nur eingehende, aber keine ausgehenden E-Mails auf Viren oder Spam filtert, erspart sich unnötige Doppelarbeit und sorgt für schnellen Versand. Der »amavisd-new« leitet auf Viren geprüfte Mails in der Regel über »localhost:10025« zurück an den Mailserver, der so konfiguriert ist, dass Mails dieses Ports nicht (nochmals) gefiltert werden. Mailman können Sie guten Gewissens ebenfalls auf »localhost:10025« statt auf »localhost:25« einliefern lassen – ändern Sie dazu die Portangabe in »mm_cfg.py«.

Setzen Sie mehrere Maschinen oder Spam- und Virenfilter in externen Appliances ein, versuchen Sie, diese für die Mailinglisten-Mails zu überspringen: Liefern Sie die Listenmails gleich beim äußersten Mail-Relay ein, das die Nachrichten zustellen soll.

Mailman kann auch – mit Einschränkungen – E-Mails personalisieren. Dabei setzt er den User- oder Realname des Empfängers für eine individuelle Ansprache ein. Aus gutem Grund ist diese Fähigkeit per Default mit »OWNERS_CAN_ENABLE_PERSONALIZATION = No« deaktiviert. Denn während Mailman normalerweise eine Mail mit einer großen Anzahl von Envelope-Empfängern generiert, muss er individualisierte E-Mails einzeln erzeugen. Das sorgt bei großen Verteilern für erheblichen Aufwand, sowohl bei Mailman als auch beim zugehörigen MTA.

Die Fähigkeit, eine Mail mit 10000 Empfängern im Envelope zu generieren, ist zwar eine großartige Entlastung für Mailman, doch setzen Sie in »mm_cfg.py« besser – wie in Listing 1 gezeigt – den Wert auf 5000. So sorgen Sie dafür, dass Mailman statt eines riesigen mehrere große Envelopes erzeugt. Viele Mailserver können deren Versand nämlich parallelisieren. Außerdem begrenzen einige MTAs die Anzahl der Empfänger pro Envelope, Postfix zum Beispiel auf 20000 – höher darf der Wert für »SMTP_MAX_RCPTS« nicht liegen, wenn man nicht auch Postfix anpasst.

Auswahl des MTA

Entscheidend für den zügigen Versand ist ein guter MTA. Postfix ist bekannt für seine guten Queuing-Algorithmen. Auch bei einer sehr großen Anzahl unzustellbarer Nachrichten kommt er nicht aus dem Tritt und liefert die Neuzugänge in der Mail-Warteschlange trotzdem flott am Stau vorbei aus.

Im Speicherverbrauch bei kleinen Servern mit weniger als 250 Listen zeigt sich Mailman recht genügsam, 128 MByte RAM sollten gut ausreichen. Sobald Sie jedoch deutlich mehr Listen anlegen, braucht der Listenmanager sehr lange, um die Übersichten auf den Webseiten zu generieren. Der Mailman-Algorithmus skaliert hier nicht besonders gut. Festplatten-Cache ist da ein wichtiges Hilfsmittel – bei 1000 Listen schaden 512 oder besser 1024 MByte RAM nicht und auch der Prozessor sollte ein Pentium 4 mit mindestens 2 GHz sein.

Neben technischer Kompetenz ist bei großen Mailinglisten auch Geschick im Management gefragt. Die einzelnen Listen-Owner, die nicht mit dem Administrator des Servers identisch sein müssen, können über ihr Admin-Interface eine Menge weitreichender Entscheidungen für den Betrieb ihrer Mailingliste treffen.

Moderation als Notbremse

Listen mit hohem Mailaufkommen oder vielen Mitgliedern werden oft moderiert, das heißt, Mailman verteilt die eintreffenden E-Mails nicht automatisch, sondern hält sie zurück und legt sie dem zuständigen Administrator zur Prüfung vor. Dieser gibt sie über das Admin-Interface frei, verwirft sie oder weist sie zurück (Abbildung 4).

Im Gegensatz zu anderen Mailinglisten- Managern kann Mailman nicht eine ganze Liste grundsätzlich auf Moderiert schalten. Stattdessen lässt sich die Moderation im Bereich »Mitgliederverwaltung« für jeden Nutzer über ein Flag individuell einstellen. Sind alle Nutzer moderiert, steht die ganze Liste unter Kontrolle. So ist es kein Problem, nur einzelne Querulanten zu blocken oder einige Personen von der Moderation auszunehmen.

Vorsicht: Im Bereich »Abo-Regeln und Adreßfilter -> Absender-Filter« stellen Sie ein, ob neue Nutzer automatisch das Moderationsflag bekommen sollen. Auf bereits eingetragene User wirkt sich das jedoch nicht aus.

Etwas anders funktioniert die Notmoderation, die der Listen-Owner auf der ersten Admin-Seite einschalten kann. Ist dieser Modus aktiv, hält Mailman alle E-Mails zurück – egal ob sie von einem moderierten oder unmoderierten Account stammen. Bricht auf einer Liste einmal ein Flamewar aus oder baut jemand dank Fetchmail-Multidrop eine Endlosschleife[4], lässt sich jede Mailinglistenaktivität einfrieren, bis sich die Lage beruhigt hat. Die Notmoderation verändert keine Einstellungen, sie überlagert sie nur.

Abbildung 4: Mailman hält eintreffende E-Mails nach bestimmten Kriterien zurück und legt sie dem Listen- Owner zur Genehmigung vor, im Bild die Mail eines Nichtmitglieds einer geschlossenen Liste. Der Eigentümer kann die Mail nun verschieben, annehmen, ablehnen oder wegwerfen.

Wider die Spamflut

Egal ob Knochenmarksspende, Handyviren oder einfältige Schneeballsysteme: Kettenmails sterben nicht aus, solange naive Nutzer jeden mittelmäßig gefakten Unsinn für bare Münze nehmen und in ihr Adressbuch weiterleiten[5]. Typischerweise nennen diese Hoax-Mails zahlreiche Empfänger im Mailheader-»To«. Beschränken Sie die zulässige Empfängerzahl, dann hält Mailman solche Rundmails unabhängig vom Absender zurück und legt sie dem Listenbesitzer zur Moderation vor. Die Einstellung findet sich in »Abo-Regeln und Adreßfilter -> Empfänger-Filter«.

Steht die Adresse der Mailingliste nicht im Mailheader-»To«, handelt es sich häufig um Kettenmails oder Viren. Ebenfalls unter »Empfänger-Filter« weisen Sie Mailman an, dies zu prüfen und die Nachricht zurückzuhalten.

Listenarchive bei Google & Co.

Weithin unbekannt ist, dass Google und andere Suchmaschinen auch die zugänglichen HTML-Archive von Mailinglisten indizieren. Irgendwann werden Listenmitglieder ihre Postings bei Google wiederfinden und damit nicht einverstanden sein – schon ist der Ärger da.

Eine »robots.txt« im obersten Verzeichnis des Webservers schafft Abhilfe. Das folgende Beispiel weist die Suchmaschinen-Spider an, die Admin-Seiten und vor allem das von Pipermail generierte Webarchiv nicht zu indizieren:

User-agent: *
Disallow: /mailman/create
Disallow: /mailman/admin
Disallow: /mailman/roster
Disallow: /mailman/options
Disallow: /pipermail

Der Parameter »DEFAULT_ARCHIVE = Off« in »mm_cfg.py« sorgt dafür, dass neu angelegte Listen kein Webarchiv erhalten, wenn es der Administrator im Admin-Interface nicht ausdrücklich aktiviert.

Auch die Information, wer welche Mailingliste abonniert hat, ist nichts für die Öffentlichkeit. Mailman bietet an, diese Daten nur an Listenmitglieder zu geben. Andererseits kann es auch gute Gründe geben, diese Details ganz zurückzuhalten – das muss der Administrator im Einzelfall entscheiden. Wie auch immer: Ein ganz ungeschützter öffentlicher Abruf der Mitgliederliste ist eigentlich nie vertretbar.

Weniger Stress

Selbst wenn vergleichsweise wenige Beschwerden und Support-Anfragen kommen: Bei Servern mit weit über 100000 Listenmitgliedern bringen ein paar Prozent Beschwerdefälle auch eine Menge Arbeit. Eine FAQ hilft hier weiter. Schreiben Sie entsprechende Erklärungen und verlinken Sie an passender Stelle darauf.

Die Fähigkeiten von Mailman sind damit noch längst nicht ausgereizt. Die Tabelle 1 listet die wichtigsten Einstiegspunkte, um weitere Funktionen zu erkunden. Auf der deutschen Mailman-Liste[6] gibt es Auskunft und Rat zu Mailman. (eba)