Pünktlich zum Jahresstart brachte uns der Spamassassin mit einem Jahr 2010-Bug Freude. Problem war die Regel »FH_DATE_PAST_20XX«, welche seit dem 1.1.2010 3,188 Extrapunkte pro Mail auf den Spamstatus aufgerechnet hat. Durch diese Extrapunkte wurden viele Mails als sogenannte »false positives« gekennzeichnet und sind, je nach Konfiguration des Mailservers, im Spamordner gelandet.

Per »sa-update« wurde (ich glaube noch am 1.1.2010 selbst) ein entsprechendes Update veröffentlicht, welches die falsche RegEx ersetzt:

Alt:

Neu:

Wer einmal genau guckt sieht, dass wir uns nach diesem tollen »Patch« am 1.1.2020 wieder sprechen, sollten wir zu diesem Zeitpunkt noch die gleiche Technologie nutzen. Im Bugreport aber war zu lesen, dass nun ja 1 Jahrzehnt Zeit ist, das Problem endgültig zu fixen, wir sind gespannt.

Heise ist am 1.1.2010 noch von einem GMX-Problem ausgegangen, hatte dies in einem späteren Update aber korrigiert. Im Forum wurde mit Recht darauf hingewiesen, dass das im Nachhinein schlecht gewählte Topic viele Spamassassin-Nutzer nur durch Zufall auf den Artikel hat aufmerksam werden lassen.

Weiteres Problem unter Ubuntu- und Debian-Systemen

Ich persönlich hatte auf 2 Ubuntu Hardy-Systemen noch das Problem, dass die mit »sa-update« aktualisieren Regeln nicht aktiviert wurden. Grund hierfür scheint gewesen zu sein, dass Ubuntu (und dies betrifft natürlich genauso auch Debian-Systeme) unter /usr/share/spamassassin noch die Regeln vom Auslieferungszustand liegen hat. Diese können gefahrlos entfernt werden, vorher natürlich ein Backup anlegen. »sa-update« legt seine neuen Dateien unter /var/lib/spamassassin/3.002004 ab. In der Datei
/var/lib/spamassassin/3.002004/updates_spamassassin_org/72_active.cf
kann auch kontrolliert werden, ob die oben genannte RegEx erfolgreich aktualisiert wurde.

Wer „sa-update“ bis jetzt noch gar nicht konfiguriert hatte findet unter http://saupdates.openprotect.com/ ein gutes Howto.

Wer Ubuntu Hardy (8.04) nativ auf einem IBM Blade vom Typ HS21 XM (7995) einsetzt, sollte einmal überpüfen, ob das System bei Volllast nicht unerwartet in einen Freeze läuft. Bei uns ist dies nun zum 2. Mal aufgetreten (siehe Bild), beim ersten Mal hatte der Blank-Screen den Absturzgrund erfolgreich verstecken können, Logeinträge bleiben hier natürlich ebenfalls aus. Da es sich um keinen Hardwarefehler handelt, hüllt sich ebenfalls auch das Eventlog vom Bladecenter in Schweigen.

Der »Konsolen-Bildschirmschoner« lässt sich über folgenden Eintrag in der »/etc/rc.local« abschalten (hinterher muss natürlich entweder neu gestartet oder »/etc/rc.local« einmalig manuell über tty1 ausgeführt werden):

Kurze Zeit später ist der Fehler erneut aufgetreten, das hängende »htop« hat noch 3 CPU-Kerne auf 100% angezeigt, in der Console war folgender Fehler zu erkennen (siehe auch Bild):

Um den Fehler nun zu umgehen, wird der Kernelaufruf um die Parameter »nmi_watchdog=0 nohpet« ergänzt. Die Kernelparameter werden dafür in der Datei »/boot/grub/menu.lst« folgendermassen editiert:

Im Anschluss wird die menu.lst über »update-grub« aktualisiert, das System kann neu gestartet werden und sollte nun auch unter Volllast stabil laufen. Bei mir tut es dies nun seit 3 Tagen.