Ich habe gerade den nächsten Snapshot von Postfix 2.8 in mein Repository geworfen. An Neuerungen gibt es zum einen die access(5)-Direktive „reject_rhsbl_reverse_client”, bei der man auf den unverifizierten Hostnamen losgehen kann, sowie die Möglichkeit, Postfix zu sagen, ob es bei MX-Einträgen mit gleicher Priorität (oder bei einem MX-Eintrag, hinter dem mehrere IP-Adressen liegen) zuerst IPv6 oder IPv4 probieren soll („smtp_address_preference”).
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 Kufhladen 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:
