Gut angebunden

Der Listenserver benötigt eine SQL-Datenbank. Obwohl Anwender Sympa auch produktiv mit Oracle oder PostgreSQL einsetzen, ist die Anpassung an MySQL die beste. Bei anderen Backends muss der Admin einige Tabellen von Hand anlegen, bei MySQL kümmert sich Sympa selbst um die Datenbankstruktur. Da Sympa  6 ausgehende Mails in der Datenbank zwischenspeichert, stellt der Systemverwalter deren Puffergröße so groß ein, dass Nachrichten mit der maximal erlaubten Größe noch hineinpassen.

Die Weboberfläche läuft als »fcgi« -Skript auf einem Apache-Webserver und nutzt dazu Perls Template Toolkit (TT2, [3] ). Schablonendateien dienen als Grundlage, das eigentliche Layout haben die Entwickler in ein CSS-Stylesheet ausgelagert. Zumindest theoretisch ist es möglich, Sympa jedes erdenkliche Kleid anzuziehen. In der Praxis bedeutet allerdings jede Änderung, die über kleine Eingriffe in das Stylesheet hinausgeht, ziemlich viel Arbeit.

Statt die Präsentation umzustricken, lässt sich Sympa auch als Webservice von eigenen Anwendungen aus aufrufen: Der mitgelieferte SOAP-Server ist recht einfach zu bedienen und anzusprechen. Französische Bildungsinstitute, Sympas Heimatdomäne, benutzen die Software mittlerweile sogar als Backend zur Gruppenverwaltung oder als Authentifizierungsdienst für Webportale. Manchem Anwender scheinen dies aber Fälle zu sein, bei denen ein Hammer jedes Problem wie einen Nagel aussehen lässt.

Eine Szene machen

Sympa ist eine ereignisgetriebene Software: Nahezu alles, was der Server macht, tut er als Reaktion auf bestimmte Aktionen in der Weboberfläche oder bestimmte eingehende Mails. Sympa kennt derzeit 17 verschiedene Ereignisse: Die wichtigsten sind das Hinzufügen und Löschen von Listenabonnenten, das Abonnieren und Abbestellen einer Liste und natürlich das Senden von Mails über eine Liste. Wie genau Sympa auf ein Ereignis reagiert, entscheidet sich durch Auswerten einer kleinen Konfigurationsdatei des Szenarios. Szenarien werden pro Liste durch die Eigentümer oder den Listmaster konfiguriert (siehe Abbildung  4), einige, für das Ereignis »Beantragen einer neuen Liste« beispielsweise, auch global durch den Listmaster.

Abbildung 4: Der Listeneigentümer darf auswählen, wie Sympa bestimmte Ereignisse verarbeitet, etwa das Abonnieren einer Liste oder das Senden einer Mail. Szenarien legen dabei fest, was genau passiert.

Ein Szenario hat eine etwas ungewöhnliche Syntax: Jede Zeile besteht aus einer Bedingung, einem Pfeil und einer Aktion (siehe Listings 1 und 2 ). Sympa arbeitet die Datei von oben nach unten ab, bis eine Bedingung zutrifft. Dann führt es die zugeordnete Aktion aus und beendet die Auswertung.

Jedes Ereignis wird einem Benutzer (also einer E-Mail-Adresse) zugeordnet, sei es, weil diese Adresse im From-Header der das Ereignis auslösenden Mail steht oder weil der Benutzer beim Auslösen einer Aktion über das Web unter dieser Adresse eingeloggt ist. Eine Bedingung kann beispielsweise diese Benutzeradresse mit einem regulären Ausdruck abgleichen oder prüfen, ob sie einer Rechtegruppe (Abonnent, Moderator etc.) angehört. Es gibt noch eine ganze Reihe weiterer Bedingungen – wer möchte, schreibt neue Bedingungen als Perl-Plugin.

Die wichtigsten Aktionen hinter dem Pfeil sind »do_it« und »reject« , jeweils ergänzt um ein Argument. Die Aktion »do_it« lässt jenes Ereignis geschehen, bei dem die Software das Szenario aufgerufen hat – also etwa einen Abonnenten hinzufügen oder die Mail verschicken. Die Aktion »reject« verweigert die Ausführung und liefert eine im Parameter genannte Schablonendatei als Fehlermeldung. Je nachdem, ob Benutzer das Ereignis per Mail oder per Web angestoßen haben, erhalten sie diese Meldung per E-Mail oder als Popup-Fenster zugestellt. Um in jedem Fall etwas zu tun, notiert der Admin als letzte Bedingung »true()« . Sympa führt dann die dort zugeordnete Aktion aus, typischerweise erzeugt dies eine Ablehnungsmail.

Das Szenario aus Listing 1 kümmert sich zum Beispiel darum, eine Nachricht an die Liste zu verteilen, wenn der Absender entweder Abonnent, Moderator oder Eigentümer der betreffenden Liste ist. In jedem anderen Fall führt die letzte »true()« -Bedingung dazu, dass eine Ablehnungsmeldung ergeht.

Etwas verwickelt geraten Szenarien, wenn die Liste der Legitimierungsmodi vor dem Pfeil ins Spiel kommt. Hier sind drei Schlüsselwörter, »smtp« , »md5« und »smime« erlaubt. »smtp« steht für eine Legitimierung der Benutzeradresse lediglich durch den From-Header der Mail, »md5« bezeichnet aus historischen Gründen die Legitimierung durch Login in der Weboberfläche, »smime« steht schließlich für die Legitimierung durch eine X.509-Signatur per Browserzertifikat.

Listing  2 verdeutlicht dies: Die ersten beiden Bedingungszeilen greifen, wenn Eigentümer oder Listmaster per unsignierter Mail ( »smtp« ) das Löschen einer Adresse aus einer Liste anfordern. Sie führen zur Aktion »request_auth« , sodass Sympa den Eintrag erst dann löscht, wenn der Besitzer es per One-Time-Ticket bestätigt. Die Zeilen 3 und 4 formulieren die gleiche Bedingung, aber den Legitimierungsmodus »md5,smime« und die Aktion »do_it« : Löschanträge per signierter Mail oder aus der Weboberfläche heraus führt Sympa damit ohne Bestätigung durch. Die »true()« -Bedingung übernimmt es wieder, alle anderen Anforderungen abzuweisen.

Mit dem Szenarienkonzept lassen sich Berechtigungen flexibel zuschneiden. Die Universität Marburg stellt damit beispielsweise sicher, dass nur Universitätsangehörige neue Listen beantragen dürfen, dass Skripte, die Newsletter-Listen beschicken, sich legitimieren müssen, oder dass Anwender innerhalb bestimmter Gruppen von Listen beliebig quer posten dürfen. Im Zusammenwirken verschiedener Szenarien lassen sich Listen sogar als Webforum betreiben oder vertrauliche Listen anlegen, auf denen alle Aktionen digitale Signaturen erfordern.

Da Sympa einen Suchpfad für Szenarien kennt, steht es dem Admin frei, mitgelieferte Szenarien zu überschreiben, zu ignorieren oder eigene hinzufügen, ohne in das Default-Konfigurationsverzeichnis einzugreifen. Welche Rechtegruppen welche Optionen verändern dürfen, lässt sich ebenso zentral konfigurieren wie die Vorlagen, nach denen berechtigte User neue Listen einrichten dürfen.