SpamAssassin to blacklist and unblacklist

SpamAssassin has a feature to blacklist and unblacklist certain e-mailaddressen. But recently I noticed something interesting that may need some more investigation. I have all addresses for domain example.org blacklisted, but also unblacklisted certain functional addresses as is shown in the example below.

blacklist_from          *@example.org
unblacklist_from        abuse@*
unblacklist_from        hostmaster@*
unblacklist_from        postmaster@*
unblacklist_from        security@*
unblacklist_from        webmaster@*

Now I expected that webmaster@example.org was going to be unblacklisted, meaning the mail would have both a spamscore of both +100 and -100 making it effective 0 again. This modification resulted in a spamscore of +100 and makes me worry that unblacklisting will demand that the domain part needs to be specified instead of having a wildcard. This will require some more testing in the near future, but for now it may affect other installations.

A smoother transition in Debian

About a month ago a transition in Debian took a wrong turn for systemd users. This ended in systemd users who where unable to shutdown there system, but recently a newer version was uploaded to unstable solving this issue. So time to unlock the block packages and upgrading systemd to version 37-1.1 and blocked packages.

$ echo "bootlogd install" | sudo dpkg --set-selections
$ echo "initscripts install" | sudo dpkg --set-selections
$ echo "sysvinit install" | sudo dpkg --set-selections
$ echo "sysvinit-utils install" | sudo dpkg --set-selections
$ echo "sysv-rc install" | sudo dpkg --set-selections
$ sudo apt-get install -t unstable systemd libpam-systemd libsystemd-daemon0 libsystemd-login0 bootlogd initscripts sysv-rc sysvinit sysvinit-utils

Only remark after upgrade as for the last time a normal reboot isn’t possible since the system already looks at the new location, but a `halt -f` solves that.

No smooth transition in Debian

Bugreport 638019 appears to be very straight forward, until the code finally hit Debian Testing last weekend. A simple relocation of a FIFO-buffer from /dev to /run caused direct trouble for machines with systemd and a normal shutdown wasn’t possible anymore. Both bugs 657979 and 657990 are a results of the modification. Seeing the overview of effected files and made me go back to the previous working release of source package sysvinit with the following commands

$ cd `xdg-user-dir DOWNLOAD`
$ wget http://snapshot.debian.org/archive/debian/20111223T034013Z/pool/main/s/sysvinit/bootlogd_2.88dsf-18_amd64.deb
$ wget http://snapshot.debian.org/archive/debian/20111223T034013Z/pool/main/s/sysvinit/initscripts_2.88dsf-18_amd64.deb
$ wget http://snapshot.debian.org/archive/debian/20111223T034013Z/pool/main/s/sysvinit/sysv-rc_2.88dsf-18_all.deb
$ wget http://snapshot.debian.org/archive/debian/20111223T034013Z/pool/main/s/sysvinit/sysvinit-utils_2.88dsf-18_amd64.deb
$ wget http://snapshot.debian.org/archive/debian/20111223T034013Z/pool/main/s/sysvinit/sysvinit_2.88dsf-18_amd64.deb
$ dpkg -i bootlogd_2.88dsf-18_amd64.deb initscripts_2.88dsf-18_amd64.deb sysvinit_2.88dsf-18_amd64.deb sysvinit-utils_2.88dsf-18_amd64.deb sysv-rc_2.88dsf-18_all.deb

And as there is no solution for now except a dependency change for systemd the package are being placed on hold like the last time they broke systemd.

$ echo "bootlogd hold" | sudo dpkg --set-selections
$ echo "initscripts hold" | sudo dpkg --set-selections
$ echo "sysvinit hold" | sudo dpkg --set-selections
$ echo "sysvinit-utils hold" | sudo dpkg --set-selections
$ echo "sysv-rc hold" | sudo dpkg --set-selections

It sounds strange for Linux-people, but I really wished I had an alternative boot environment like Solaris has. Maybe this is the reason for me to invest more time in read-write within BtrFS.

DNSSEC, de dag erna

Gisteravond werd DNSSEC ingevoerd voor de root-zone, maar vlak voor de invoering kwam nog een foutje in BIND 9.7.1 naar boven. Dit mocht helaas de pret niet drukken en wat sommige voorspelden met het einde van de wereld is ook niet uitgekomen en zijn de eerste ccTLD en non-ccTLD opgenomen met een DS resource record.

De tijd is dus gekomen om te kijken om van DLV af te gaan stappen en kijken of de resolving correct blijft werken. De tijd is dus ook gekomen dat SIDN binnenkort DNSSEC gaat ondersteunen, want de belofte was om dit een maand na de root-zone te gaan ondersteunen.

Helaas werken sommige oplossingen niet correct zoals de resolver in de Fritz!Box. Bij het opvragen van de nameservers van de root-zone met het verzoek om DNSSEC te gebruiken besluit de firmware om op slot te gaan voor een paar minuten. Er is een bugreport naar AVM gegaan en hopelijk komt er binnenkort een update.

De vraag die ook al bij IPv6 kwam is hoe lang het nog gaat duren voordat het mainstream gebruikt kan worden. Want veel verouderde oplossingen worden nog steeds verkocht en zolang is het nog niet geleden dat oa SpeedTouch-modems alleen maar A en CNAME records konden verwerken.

SpamAssassin op automatische piloot

In de afgelopen periode is SpamAssassin al meerdere malen aanbod gekomen en vooral in de context met Bayesian-filtering, maar er is nog veel meer. Zeker nu recentelijk release 3.3 het daglicht heeft gezien wordt het tijd om eens wat dieper in SpamAssassin te duiken.

Een van de grootste probleempunten met SpamAssassin was altijd de ruleset en de strijd met de spammers om die rules net te omzeilen. Bayesian-filtering lost een deel van dit probleem op, maar het andere probleem is de ruleset zelf. Voorheen werden rules met SpamAssassin meegeleverd en werden ze pas bijgewerkt als je een nieuwe versie van SpamAssassin installeerde. Het mag duidelijk zijn dat dit een onbegonnen strijd is, maar ook een gevaarlijke strijd. Zeker voor installaties die afhankelijk waren van DNS blacklists cq whitelists en waarbij de beheerder van de lijst besloot om zijn lijst op te heffen bijvoorbeeld.

De SARE-regels zijn een hele tijd populair geweest en zijn dat helaas nog steeds. Dit terwijl ze stelselmatig worden opgenomen in de ruleset van SpamAssassin zelf. Gelukkig heeft oa SARE er wel voor gezorgd dat er een update methode kwam die met de 3.3 release verplicht is geworden. Hiermee volgt SpamAssassin eigenlijk ClamAV in de voetsporen en is het verspreiden van een vaste ruleset overbodig geworden.

De eerste stap is eigenlijk heel simpel met het draaien van het commando sa-update als de gebruiker root op Debian. Als we nu in /var/lib/spamassassin/ kijken dan zien we het volgende:

$ ls -l /var/lib/spamassassin/ /var/lib/spamassassin/*/
/var/lib/spamassassin/:
total 8
drwxr-xr-x 3 root root 4096 2010-01-02 14:46 3.002005

/var/lib/spamassassin/3.002005/:
total 8
drwxr-xr-x 2 root root 4096 2010-01-02 14:46 updates_spamassassin_org
-rw-r--r-- 1 root root 2431 2010-01-02 14:46 updates_spamassassin_org.cf

We zien netjes de betreffende versie van SpamAssassin en in die directory de ruleset zoals die nu voor versie 3.2.5 wordt aanbevolen door SpamAssassin. Deze regels worden automatisch meegenomen als SpamAssassin de volgende keer start. Nu kan je zelf een paar regels in de crontab van de gebruiker root zetten, maar in Debian zijn al voorzieningen getroffen. Door het onderstaande aan te passen in het bestand /etc/dedault/spamassassin zal automatisch de sa-update worden gedaan en wanneer nodig SpamAssassin worden geherstart.

CRON=1

Helaas stopt hier het verhaal niet, want op dit moment worden services zoals Amavisd-new, die ook de SpamAssassin ruleset kan gebruiken, niet herstart. Op moment van schrijven staan bugs 315961 en 567205 hier nog over open. Totdat die zijn opgelost kan de volgende extra code geen kwaad aan het einde van /etc/cron.daily/spamassassin

test -f /var/run/amavis/amavisd.pid && /etc/init.d/amavis force-reload

Dit laatste is natuurlijk op eigen risico, maar het lost de bug voor mij al een redelijke tijd op.