Wie die meisten Leser wissen dürften, mache ich ja recht viel mit Mailservern, genauer gesagt mit Postfix als MTA und mit Dovecot als IMAP-Server sowie mit amavisd-new als Framework für die Einbindung von Filtern, welche die Mails dann z.B. auf Spam oder Viren untersuchen. Diesen drei Programmen ist gemein, daß sie einen Teil ihrer Konfiguration aus einer Datenbank lesen können. Das ist ganz praktisch, wenn man gerade keinen eigenen Verzeichnisdienst wie z.B. LDAP am Start hat, weil man auf die Art und Weise sehr einfach eine Weboberfläche zusammenbauen kann, mit der man dann z.B. neue eMail-Adressen anlegen oder die Einstellungen des Spam-Filters verändern kann.

Nachdem ich derzeit zum Spielen - und zum ersten Mal seit Jahren - wieder eine neue Programmiersprache lerne, nämlich Ruby on Rails dachte ich mir, ich versuche mich jetzt mal selber an der Entwicklung einer solchen Management-Applikation (es gibt da fertige Lösungen wie z.B. Postfix Admin, aber wenn ich fertigen Kram nehme, lerne ich ja nichts dabei). Also habe ich mich zuerst einmal hingesetzt und meine Datenbankstruktur (in PostgreSQL) ausgearbeitet. Nachdem das erstellen der Struktur für zu verwaltende Domains, Mailboxen und Aliase keine halbe Stunde gedauert hat, hat mich Christian Boltz auf der Mailingliste zum Postfix-Buch von Peer Heinlein auf eine interessante Idee gebracht. Er meinte nämlich, daß es evt. keine schlechte Idee sei, von der eigentlich wünschenswerten dritten Normalenform wegzugehen und statt dessen einige Daten doppelt vorzuhalten - diese jedoch im Klartext und so, daß die Integration der Applikationen, welche auf die DB zugreifen sollten, möglichst einfach ist. Das Zauberwort dazu lautet PL/pgSQL und ist eine Programmiersprache in der Datenbank selbst, mit der sich das automatische Aktualisieren dieser Zusatzfelder über sog. "Trigger" nach jeder Operation, die Daten verändert, erledigen lässt - und glaubt mir, wenn man eben gerade nicht mehr in der dritten Normalenform unterwegs ist, gibt es da einiges an Daten, was man sozusagen "nachträglich" aktualisieren muß. Und auch die virtuellen Aliase von Postfix machen die Struktur nicht gerade einfacher. Das Positive an der Sache ist jedoch, daß die ganzen Trigger nur laufen, wenn Daten verändert werden, was ja deutlich seltener vorkommt als die reine Abfrage (meine Mailserver kriegen am Tag Millionen von Verbindungen ab, neue Postfächer dagegen richte ich pro Jahr vielleicht 60 oder 70 ein).

Also habe ich mich gestern nochmal zwei Stunden hingesetzt und heraus kam schließlich das hier (das .gz-File ist die Ausgabe von "pg_dump -c -d ...). Das Schema hat folgende Eigenschaften:

1. Die Tabellen für die Abfrage der Mailboxen und Aliase enthalten zwei Felder namens "auto_lhs" und "auto_rhs", welche die Daten direkt in dem Format bereitstellen, welches von Postfix oder Dovecot benötigt wird und von Triggern stets aktuell gehalten werden. Die Abfrage für die Definition von virtuellen Mailboxen ist denn auch trivial:
   CODE:
   query = SELECT auto_rhs FROM mailboxes WHERE auto_lhs='%s';
2. Man kann Domains, Mailboxen und Aliase deaktivieren, woraufhin ein Trigger dann auch alle davon abhängigen Einträge deaktiviert (und ja, da kommt es zu einer Kaskade von Triggern, aber das kann man denke ich in Kauf nehmen) Das gleiche gilt natürlich auch für das Löschen solcher Einträge.
3. Der Ort im Dateisystem, wo die Mails abgelegt werden, wir nur einmal, nämlich beim Erzeugen der Mailbox, festgelegt. Das heißt, daß man im Nachhinein einen anderen Benutzernamen, eine andere Domain oder einen anderen Localpart (den Teil vor dem "@") vergeben kann, ohne daß man danach per Hand Dateien umkopieren muß. Gleichzeitig wird die Ablage auf mehrer Verzeichnisebenen verteilt, so daß man auch mit einer großen Anzahl an Mailboxen keine Probleme bekommen sollte.
4. Die Alias-Daten sind logisch konsistent. Das hat den "Nachteil", daß man keine Aliase zur Weiterleitung benutzen kann (was ich sowieso für eine schlechte Idee halte, SPF sei Dank), aber dadurch, daß man keine Aliase auf nicht-existierende Ziele anlegen kann, kann man sich auch nicht in den Fuß schießen.
5. Aliase "erben" die Spam-Einstellungen der Adresse, auf die sie zeigen, können aber im Nachhinein auch andere Prioritäten erhalten, So kann man z.B. für die Roleaccounts die Spam-Filterung abschalten, obwohl die Mails in die selbe Mailbox gelangen wie private Mails, die dann schon gefiltert werden sollen. Außerdem macht das ganze die Integration von amavisd-new trivial (und ja, die "spam_policy"-Felder sollten Fremdschlüssel sein, ich weiß).

Mein Problem ist jetzt, daß ich gestern zum ersten mal seit sechs Jahren einen Trigger geschrieben habe und dementsprechend sehen die noch recht krude aus. Wer also mal Zeit hat und mir etwas Feedback geben könnte - nicht nur zu den Triggern, sondern auch zur Struktur - dem wäre ich dankbar.

So, ich glaube, jetzt ist es dann erstmal Zeit für einen Spaziergang. Das Wetter ist ja auch toll!