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:
Update 06.02.2022: Das Video existiert nicht mehr.