Automatische Updates könnten so toll sein...

Anmerkung: Eigentlich müsste der Titel dieses Eintrags folgendermaßen lauten: SpamAssassin - warum automatische Updates toll sind, und wie man sich trotzdem in den Fuß schießen kann.

Jedes Open Source-Projekt muß einmal einen kapitalen Bock schießen. Bei Debian z.B. hatten wir 2008 das OpenSSL-Desaster. Damals habe ich auch vier Zertifikate neu anfordern dürfen - von externen CAs, natürlich. Davon, daß es meine private CA ebenso erwischt hat und ich in einem großen Rundumschlag auch gleich alle SSH-Keys (Host- und User!) ausgetauscht habe, davon wollen wir hier gar nicht anfangen. Eine ganz andere Mongose hat sich die SpamAssassin-Truppe geleistet. Für diejenigen, die SpamAssassin nicht kennen: Das dürfte der mit Abstand am weitesten verbreitete Spam-Scanner im Open Source-Bereich sein. Die in Perl geschriebene Applikation führt diverse Tests mit jeder Mail durch, die man ihm vorwirft, und berechnet daraus eine Punktzahl. In den Default-Einstellungen werden Mails ab einer Punktzahl von 6.31 als Spam markiert (kann sein, daß die 6.31 jetzt von amavisd-new kommt, ich habe SA schon seit Ewigkeiten nicht mehr “solo” eingesetzt).

Nun gibt es im Regelwerk eine Regel mit dem schönen Namen FH_DATE_PAST_20XX. Deren ursprünglicher Sinn war es eigentlich zu schauen, ob der Date-Header einer Mail zu weit in der Zukunft liegt (Spammer machen das ganz gerne, weil die Mail dann bei vielen MUAs an prominenter Stelle im Posteingang landet). Ist das der Fall, werden 3.41 Punkte extra vergeben - das ist also schon “mehr als die halbe Miete”. Anfang 2008 ist dann jemandem aufgefallen, daß diese Regel (und eine ähnliche) uns im Jahr 2010 Probleme bereiten werden. Die Regel wurde also korrigiert und in die Versionskontroll-Software eingepflegt, und damit war das Thema eigentlich auch schon wieder abgeschlossen. Denn SpamAssassin, so muß man wissen, verfügt über ein kleines Tool mit Namen sa-update, mit welchem sich die Regeln auch zwischen verschiedenen Releases des kompletten Programms aktuell halten lassen - ähnlich wie bei einem Virenscanner. Die Regeln, die das Projekt über seine Update-Kanäle bereit stellt, kommen vereinfacht gesagt aus der vorhin erwähnten Software zur Versionskontrolle. Regeln, die dort von den Entwicklern z.B. als passend für das Release 3.2 markiert werden, stehen kurze Zeit später auch für Updates bereit.

Dummerweise hat man nun genau diese Markierung (dieses Tag) vergessen, und so flog pünktlich zum Jahreswechel eine größere Zahl von Kuhfladen in den Ventilator. Das Problem haben die Entwickler relativ schnell in den Griff bekommen, und jede Installation, die seit damals auch nur einmal sa-update aufgerufen hat, ist frei von diesem Fehler.

Das alles ist Geschichte, und ihr fragt Euch zurecht, warum ich solche alten Kamellen (oder solche alten Mannheimer Tüten?) hier erwähne. Das ganze hat zwei einfache Gründe: Man muß - NATÜRLICH! - erstmal sa-update aufrufen, um überhaupt in den Genuß der Regelupdates zu kommen. Eigentlich sollte das so klar wie Kloßbrühe sein, aber die traurige Wahrheit ist, daß da draußen eine ganze Menge Leute Mailserver betreiben, denen man eigentlich gar keine Server vermieten (oder anderweitig zur Verfügung stellen) dürfte. Und solche Vollhonks sind dann natürlich wahnsinnig heiße Kandidaten für Probleme wie das oben geschilderte. Was tut man also, als halbwegs verantwortungsvoller Distributor (egal, ob man jetzt eine Linux-Distribution oder einen *BSD-Port bereitstellt)? Genau, man führt einen Automatismus ein, der das dem Luser abnimmt. Unter Debian z.B. macht das einmal am Tag das Skript /etc/cron.daily/spamassassin, zumindest, wenn man in der Datei /etc/default/spamassassin; den Wert der Variable CRON von 0 auf irgendwas anderes geändert hat (letztere Datei ist übrigens auch ein geeigneter Ort für eine Anweisung à la export http_proxy=http://proxy:3128/ o.Ä.). Ich weiß auch nicht, ob das im derzeitigen Paket noch drin ist, aber bei der Erstinstallation habe ich irgendwann sogar mal so eine schöne Dialogbox bekommen, in der ich das automatische Update aktivieren konnte. Damit hätten wir den ersten Punkt auf der Liste abgehakt.

Wie ich gerade von einem Bekannten im IRC erfahren durfte, gibt es aber anscheinend noch eine zweite Hürde beim automatischen Update der SA-Regeln: Man muß es richtig machen! In dem mir zugetragenen Fall hatte jemand tagaus, tagein brav sa-update aufgerufen. Die Person ist sogar so weit gegangen und hat verifiziert, daß die Regeln - die bei ihr unter /var/lib/spamassassin lagen - sich auch wirklich immer aktualisieren und daß ihr Spamfilter - sie hat die Spamassassin-Module via amavisd-new benutzt - auch wirklich diesen Regelsatz benutzt (liebe Kinder, das ist schon ungefähr das dreifache von dem, was die üblichen Verdächtigen so unternehmen). Jetzt könnt ihr Euch bestimmt ihre Überraschung vorstellen, als sie - vor zwei Wochen, soviel dann zu Gründlichkeit und Lesen von Logfiles - bemerkt hat, daß ankommende Mails nach wie vor nicht nur 3.4 Extrapunkte von der Datums-Regel bekamen, sondern auch noch ganz anderen Fallout (mit 2.4 Punkten) erlitten.

Mein Kumpel hat sich dann mal den Server angesehen und dabei festgestellt, daß das erwähnte Update-Skript von Debian nach einem Regel-Update den Dienst spamassassin (präziser: den spamd-Dämon) neu initialisiert - das jedoch juckt amavisd-new überhaupt nicht. Soviel dann zu “man muß es richtig machen”. Und darum gilt nach wie vor: Wer vorhat, Server zu betreiben und dort bestimmte Applikationen einzusetzen, dem bleibt es auch im Jahr 2010 nicht erspart, sich genauestens mit der Applikation selbst, aber auch mit dem von seiner Distribution bereitgestellten Rahmenwerk auseinander zu setzen.

Zur Entspannung: Die White Stripes mit Seven Nation Army - enjoy: