Nein, die Überschrift hat keinen Tippfehler; zumindest, wenn es um die Leere in den Postfächern auf dem Server geht. Ungefähr seit etwa 3 Monaten wollten nämlich sporadisch einige Mails nicht mehr ankommen. Dies war insbesondere auffällig bei Mails, die von GoogleMail aus gesendet wurden: Diese wollten nämlich einfach nicht ankommen.
Nun lässt sich ein Mailserver typischerweise so effizient debuggen wie Sand zum Schlittschuhfahren geeignet ist (es geht, aber man hat diverse Reibungsverluste, während man das tut), so dass eine Logmeldung jede Stunde schon fast der einzige Ausgangspunkt für die Fehlersuche war:
Mar 25 23:00:42 server dkim-filter[1337]: FEDCBA987654: dkim_eoh(): internal error from libdkim: ar_addquery() for `20120113._domainkey.gmail.com' failed
Wer dies für zu viel Ausgangsinformation für die Fehlersuche hält, darf sich als nächstes auf die Suche nach dem richtigen Source-Paket begeben, denn eine Bibliothek für DKIM gibt es in mindestens 3 verschiedenen Paketen in Debian, die alle samt irgendwie dkim heißen: libmail-dkim-perl, libsmdkim2 und dkim-filter. Wer sich jetzt wundert, eigentlich gibt’s ja noch eine; aber zu der komme ich gleich noch; keine Sorge! Nunja: Alle 3 haben ihre Berechtigung und basierend auf der Fehlermeldung KANN es eigentlich jedes dieser Pakete sein. Also hilft nur ein kurzes Trial-and-Error, was die DKIM-Implementation von AMaViS, die sich hinter libmail-dkim-perl versteckt recht schnell ausschließt: Die hat nämlich die in der Logmeldung enthaltene Funktion nicht. Okay, weiter zu libsmdkim2: Die sieht zwar auch stark verdächtig aus, stellt sich nach kurzer Durchsicht des Sources auch als unproblematisch heraus. Womit wir den dkim-milter als Übeltäter hätten.
Also auch hier kurz einen Blick in den Soruce geworfen und recht schnell gefunden, dass die drei erwähnten Code-Fragmente „dkim_eoh“, „libar“ und „libdkim“ zum dkim-milter gehören; bzw. dessen Libraries. Nun ist das Einarbeiten in komplexere Projekte mit Multithreading-Architektur oftmals etwas schwierig, weshalb ich mich für die Fehlersuche für den Frontalangriff mittels Debugger entschieden hab: Nur leider ohne Debug-Symbole wollte mir der gdb meinen Breakpoint nicht setzen.
Also nach etwas Frickeln an den Build-Scripts die Debug-Symbole bis ins Installer-Paket bekommen und den GDB erneut auf den Dienst losglassen, was diesmal mit mehr Erfolg gekrönt war; leider wegen Optimierung aber sehr interessant zu debuggen ist; insbesondere, wenn man nur eine Kommandozeile für die Bedienung des Debuggerfrontends zur Verfügung hat. Und so brauchte es durchaus ein paar mehr hereinkommende Mails, bevor der Workflow soweit saß, dass innerhalb des Request Timeouts der Postfix seine Antwort bekam, wenn ich einen Request nicht zu debuggen brauchte. Oder anders ausgedrückt: Der Debugger hing im Live-System und für das Debuggen einer Funktion hatte man exakt bis zum Timeout des Mailservers Zeit, was üblicherweise unter einer halben Minute beträgt. Für große Analysen bleibt da also nicht viel Zeit. Nja, außer halt bei den Mails, wo man weiß, dass der Bug auftritt und man sich deshalb auch über das Timeout hinweg Zeit nehmen konnte.
Nach etwa 20 Requests, die ich auf diese Weise manuell im Debugger bestätigt hatte, konnte ich im Code die Fehlerquelle dann noch etwas genauer eingrenzen und indirekt bestätigen, dass der Fehler nicht wirklich an der im Syslog genannten Stelle lag; sondern im Resolver-Code – auf den ich nun wiederum nicht so wirklichscharf war.
Da man in einem solchen Falle, in der Regel bereits bevor man den Debugger anschmeißt, einen Blick in die große, allwissende Müllhalde wirft, fällt einem dann auch manchmal etwas Brauchbares in die Hand. In meinem Fall handelte es sich um einen etwa 2 Jahre alten Diskussionsbeitrag, der ziemlich genau auf mein Problem passte.
Da ich nun nicht so viel Zeit hatte, noch groß auf dem Server weiter zu debuggen und auch sonst die Maintainer solche Probleme üblicherweise besser einordnen können, ging dann auch prompt eine Mail an die DKIM-Milter-Leute raus, da für ander Nutzer das Problm durchaus auch von Interesse sein dürfte. Nach kurzer Bedenkzeit kam dann auch gleich mailwendend die Antwort: Probier mal OpenDKIM.
Also dann: Wechseln wir mal eben die Software im Live-System; wir haben ja sonst keinen Spaß sonst.
aptitude remove dkim-milter
aptitude install opendkim
Funktionierte sofort, wie man es von der Paket-Verwaltung gewohnt ist, aber Mails angekommen wären so erstmal gar keine; das wäre nämlich ZU einfach gewesen. Schuld daran sind im Wesentlichen 2 Aspekte:
- DKIM-Milter lief über TCP-Socket auf Port 8891
- DKIM-Milter und OpenDKIM nutzen unterschiedliche Konfig-Dateien
Aber dies sollte sich recht schnell korrigieren lassen, denn die Start-Scripte von dkim-milter und opendkim sind praktisch identisch: Also Settings umkopieren und fertig.
Ein wenig schwieriger sah es bei der dkim-milter.conf aus; aber auch hier zeigte ein kurzer Diff recht schnell, dass mit einem kurzen Umkopieren der Settings alles laufen sollte. Gesagt, getan. Kurz ein paar Dienste neustarten und die ersten Mails wurden erfolgreich angenommen. Bliebe da nur noch ein anderes Problem, was ein andermal zu lösen ist …
Ach ja, was das mit veralteter Software zu tun hat? Das in Debian enthaltene Paket dkim-milter wird seit 2 Jahren nicht mehr weiterentwickelt und ist seit Ende letzten Jahres auch laut SourceForge.net-Projektseite offiziell begraben. Dennoch gibt es nirgends bei Debian einen entsprechenden Hinweis, dass man auf das neue Paket von OpenDKIM wechseln sollte. Naja, der Bugreport dazu geht (auch auf Bitte des Maintainers) die Tage raus. Und wer jetzt gegen Testing meckern möchte: Das Problematische Paket ist auch in Stable drinnen.
