SpamAssassin Erkennungsrate (deutlich) verbessern

Jeder, der einen eigenen Mailserver betreibt, kennt es: das leidige Thema SPAM. So betreibe auch ich einen Mailserver und habe mich mit dem Thema einige Tage intensiv auseinandergesetzt. Im Folgenden gebe ich einige Tipps, wie die SpamAssassin Erkennungsrate deutlich verbessert werden kann. Zusammen mit einigen Postfix Konfigurationen kommt bei mir so gut wie überhaupt kein SPAM mehr durch.

Einleitung

SpamAssassin ist ein sehr bekanntes und ausgezeichnetes Programm, das anhand von verschiedensten Tests jeder E-Mail einen “Score” zuweist. Je höher diese Punktzahl ist, desto wahrscheinlicher handelt es sich bei der Mail um SPAM.

Ich habe meine Mailserver alle auf Basis der sehr guten Anleitung von Christoph Haas (workaround.org) konfiguriert. Christoph schreibt diese Tutorials schon sehr lange, ich glaube ich habe um 2006 herum meinen ersten Server danach aufgesetzt.

Im Rahmen des Tutorials wird auch SpamAssassin installiert und aktuell direkt, früher mittels Amavis an Postfix angebunden. Ich bevorzuge nach wie vor die Anbindung über Amavis, da ich gerne auch ClamAV als Virenscanner einsetze. Die Erkennungsrate von ClamAV ist erstmal recht gering, auch hier können wir noch einiges rausholen. Dazu werde ich demnächst noch einen Beitrag schreiben.

 

Verwendet einen eigenen DNS Resolver

Zu Beginn gleich der vielleicht wichtigste Tipp, wie die SpamAssassin Erkennungsrate deutlich verbessert werden kann. SpamAssassin benutzt für viele dieser Tests sogenannte DNS Blacklists (DNSBL). Diese werden verwendet, um z.B. die IP-Adressen der SMTP Relays abzugleichen, oder auch um in der Mail enthaltene Links zu prüfen. Falls eine Domain in einem solchen Link in einer DNSBL bekannt ist, erhöht SpamAssassin folglich den Score und die Mail kann besser klassifiziert werden. Im umgedrehten Fall wird bei vertrauenswürdigen Links der Score verringert, somit sinkt auch die Chance auf eine fälschlicherweise als Spam markierte Mail.

Viele dieser DNSBLs arbeiten nach dem Freemium Prinzip, d.h. für kleinere Mailserver ist deren Benutzung kostenfrei, bei größeren Mailserver-Installationen verkaufen die Provider dieser Listen entsprechende Zugänge. Da die Listen DNS-Basiert arbeiten, wird also die Quell-IP des anfragenden DNS-Servers getrackt und limitiert.

Wenn euer Mailserver einen bekannten öffentlichen DNS-Server verwendet (z.B. Google DNS), frägt ja letztlich dieser DNS-Server bei der Liste nach. Da diese DNS-Server von vielen tausenden Benutzern verwendet werden, laufen sie schnell in das Rate-Limit der DNSBL-Provider.

Ersichtlich wird es im E-Mail Header, wenn SpamAssassin dort den Check URIBL_BLOCKED listet. Dieser wird mit 0.001 Punkten gewertet und soll nur ein Hinweis auf genau dieses Problem sein.

Abhilfe schafft die Verwendung eines eigenen (Caching) DNS-Resolvers. Dadurch frägt euer eigener DNS-Server bei den DNSBLs an und die Anfrage geht durch. Ich habe hier beschrieben, wie unter Ubuntu 14.04 bind als Caching DNS-Resolver installiert wird: Caching DNS-Resolver mit bind9

Allein diese Maßnahme hat die SpamAssassin Erkennungsrate bei mir deutlich verbessert.

 

Trainiert die Bayes-Datenbank

Auch mit folgendem Tipp kann die SpamAssassin Erkennungsrate verbessert werden. Das Programm verwendet eine integrierte Bayes-Datenbank, um Textphrasen zu klassifizieren und zu bewerten. Damit das Ganze funktioniert, muss diese Datenbank zunächst trainiert werden. Wichtig ist, dass der richtige Pfad zur Datenbank angegeben wird, sonst landet das ganze im .spamassassin Ordner des jeweiligen Benutzers. Dort schaut SpamAssassin (meines Wissens) allerdings nicht nach, wenn es über Amavis oder den spamd aufgerufen wird.

Spam Mail Quelle

Für das “Training” sind eine Menge Mails notwendig. Um genug Spam Mails zu bekommen, habe ich das aktuellste Monatsarchiv von http://untroubled.org/spam/ verwendet. Dieses habe ich mittels wget heruntergeladen, entpackt und anschließend das Tool sa-learn auf die Mails losgelassen. Falls SpamAssassin nicht über Amavis eingebunden ist, muss der Datenbank-Pfad angepasst werden.

Anschließend verfüttere ich auch noch alle Mails im “Junk” Ordner aller Postfächer an sa-learn

cd /tmp
wget http://untroubled.org/spam/2016-03.7z
7z x 2016-03.7z
sudo sa-learn --dbpath /var/lib/amavis/.spamassassin --progress --spam /tmp/2016/03
sudo sa-learn --dbpath /var/lib/amavis/.spamassassin --progress --spam /var/vmail/*/*/Maildir/.Junk

 

“Gute” Mails

Die Bayes-Datenbank sollte natürlich auch erwünschte Mails zu Gesicht bekommen. Hierzu verwende ich einfach alle gelesene Mails, die in allen vorhandenen Postfächern vorhanden sind.

sa-learn --dbpath /var/lib/amavis/.spamassassin --progress --ham /var/vmail/*/*/Maildir/cur

Dies kann (und sollte) man selbstverständlich via Cron-Job automatisieren.

 

Verwendet zusätzliche Signaturen

Peer Heinlein von Heinlein Support ist der Mann hinter mailbox.org – einem sicherlich nicht ganz unbekannten E-Mail Anbieter. Freundlicherweise stellt er kostenlos die von seinem Team entwickelten und beinahe täglich aktualisierten SpamAssassin Rulesets zur Verfügung. Eine Anleitung zum Einbinden in ein Debian/Ubuntu System findet ihr auf seinem Blog.

Im Wesentlichen werden diese Signaturen mittels dem bereits vorhandenen Cron-Job, der die SpamAssassin-eigenen Rulesets aktualisiert, zusätzlich geladen. Der Vollständigkeit halber anbei die modifizierte Version des Cron Bash-Scripts, unter Ubuntu 14.04 muss sie nach /etc/cron.daily/spamassassin. Die modifizierten Zeilen habe ich markiert. Neben dem eigentlichen Download prüft mein Script noch die Returncodes von beiden sa-update aufrufen. Wenn nur einer von beiden Aufrufen neue Signaturen gebracht hat, wird spamd bzw. Amavis neu gestartet. Ich habe diesen Code-Schnipsel (Zeile 70-76) aus den Kommentaren von o.g. Blog. Ist ziemlich quick’n’dirty, aber funktioniert für meine Ansprüche.

#!/bin/sh

# Duncan Findlay
# duncf@debian.org

# Daily cronjob for SpamAssassin updates. This isn't pretty but it
# should do the job.

CRON=0

test -f /etc/default/spamassassin && . /etc/default/spamassassin

test -x /usr/bin/sa-update || exit 0
test -x /etc/init.d/spamassassin || exit 0

if [ "$CRON" = "0" ] ; then
exit 0
fi

# If there's a problem with the ruleset or configs, print the output
# of spamassassin --lint (which will typically get emailed to root)
# and abort.
die_with_lint() {
su - debian-spamd -c "spamassassin --lint -D 2>&1"
exit 1
}

do_compile() {
# Compile rules if the required tools are available. Prior to version
# 3.3.2-8, there was an additional check to verify that an sa-compile
# run had previously been executed by hand. With sa-learn now
# distributed in a separate, optional, package, this check is no
# longer necessary.
if [ -x /usr/bin/re2c -a -x /usr/bin/sa-compile ]; then
su - debian-spamd -c "sa-compile --quiet"
# Fixup perms -- group and other should be able to
# read and execute, but never write. Works around
# sa-compile's failure to obey umask.
chmod -R go-w,go+rX /var/lib/spamassassin/compiled
fi
}

# Tell a running spamd to reload its configs and rules.
reload() {
# Reload
if which invoke-rc.d >/dev/null 2>&1; then
invoke-rc.d spamassassin reload > /dev/null
else
/etc/init.d/spamassassin reload > /dev/null
fi
if [ -d /etc/spamassassin/sa-update-hooks.d ]; then
run-parts --lsbsysinit /etc/spamassassin/sa-update-hooks.d
fi
}

# Sleep for up to 3600 seconds
RANGE=3600
number=`od -vAn -N2 -tu4 < /dev/urandom`
number=`expr $number "%" $RANGE`
sleep $number

# Update
umask 022
su - debian-spamd -c "sa-update --gpghomedir /var/lib/spamassassin/sa-update-keys"
retcode1=$?
su - debian-spamd -c "sa-update --nogpg --channel spamassassin.heinlein-support.de"
retcode2=$?

if [ $retcode1 -eq 0 ] || [ $retcode2 -eq 0 ]; then
retcode=0
elif [ $retcode1 -eq 2 ] || [ $retcode2 -eq 2 ]; then
retcode=2
else
retcode=$retcode2
fi

case $retcode in
0)
# got updates!
su - debian-spamd -c "spamassassin --lint" || die_with_lint
do_compile
reload
;;
1)
# no updates
exit 0
;;
2)
# lint failed!
die_with_lint
;;
*)
echo "sa-update failed for unknown reasons" 1>&2
;;
esac

Wenn alles funktioniert hat, müssten unter /var/lib/spamassassin/<version>/ einige Dateien mit “heinlein” im Namen liegen. Das sind die eigentlichen Rulesets. Anhand des Zeitstempels kann auch überprüft werden, wann das letzte Update kam.

 

Verwendet Pyzor und Razor

Pyzor und Razor sind Prüfsummenbasierte Netzwerke, um SPAM zu erkennen. Dabei wird eine Prüfsumme vom Body der erhaltenen Mail gebildet und an die Pyzor oder Razor Server gesendet. Falls die Prüfsummen von vielen Benutzern identisch sind (d.h. der Mailtext ist gleich), ist die Wahrscheinlichkeit, dass es sich bei der Mail um SPAM handelt höher.

Pyzor

Achtung: Pyzor verwendet den Port TCP 24441 für ausgehende Verbindungen zum Pyzor Server. Falls eine Firewall ausgehende Verbindungen blockiert, muss dieser Port entsprechend freigeschaltet werden. Folgende Schritte sind notwendig, um Pyzor unter Ubuntu 14.04 einzubinden:

sudo apt-get install pyzor
pyzor --homedir /etc/mail/spamassassin discover

Nun muss das noch SpamAssassin mitgeteilt werden. Dazu muss die Datei /etc/spamassassin/local.cf wie folgt editiert werden:

# die nächste Zeile dürfte schon auf 1 stehen. Falls nicht, dann anpassen.
use_pyzor               1
# die nächste Zeile kommt ans Ende der Datei
pyzor_options --homedir /etc/mail/spamassassin

Danach noch SpamAssassin oder Amavis neu starten, dann war’s das schon. Getestet werden kann es wie folgt:

cat /pfad/zu/ner/mail | spamassassin -D pyzor 2>&1 | less

Der Output sollte wie folgt aussehen:

Apr 1 14:40:43.038 [17306] dbg: pyzor: network tests on, attempting Pyzor
Apr 1 14:40:46.625 [17306] dbg: pyzor: pyzor is available: /usr/bin/pyzor
Apr 1 14:40:46.626 [17306] dbg: pyzor: opening pipe: /usr/bin/pyzor check < /tmp/.spamassassin17306kiOe9Ytmp
Apr 1 14:40:47.528 [17306] dbg: pyzor: [17308] finished: exit 1
Apr 1 14:40:47.528 [17306] dbg: pyzor: got response: public.pyzor.org:24441 (200, 'OK') 0 0

Razor

So wird Razor unter Ubuntu 14.04 installiert und konfiguriert:

sudo apt-get install razor
sudo razor-admin -home=/etc/spamassassin/.razor -register
sudo razor-admin -home=/etc/spamassassin/.razor -create
sudo razor-admin -home=/etc/spamassassin/.razor -discover

entsprechend muss analog zu Pyzor wieder die Datei /etc/spamassassin/local.cf angepasst werden:

# die nächste Zeile dürfte schon auf 1 stehen. Falls nicht, dann anpassen.
use_razor               1
# die nächste Zeile kommt ans Ende der Datei
razor_config /etc/mail/spamassassin/.razor/razor-agent.conf

Hier wüsste ich leider keinen Weg, wie man die Funktion von Razor direkt testen kann. Jedenfalls müsste ab jetzt der SpamAssassin Test RAZOR2_CHECK in Mails auftauchen. Überprüft werden kann das (nach ein paar Tagen) wie folgt:

grep -R RAZOR /pfad/zu/den/mails

 

Filtert nach Ländern

SpamAssassin bringt ein Plugin namens RelayCountry mit, mit welchem es möglich wird, die Länder der einzelnen SMTP Relays anhand der GeoIP Information zu bestimmen. Dies dient zum einen der Bayes-Datenbank. Sie bekommt also zusätzliche Informationen und wird künftig selbständig lernen, aus welchen Ländern viel Spam kommt. Ich habe bei mir noch “händische” Regeln hinzugefügt: Wenn eine Mail z.B. durch einen SMTP-Server in Vietnam relayed wurde, bekommt sie in meinem Fall zwei Punkte. Dieser Schritt hat auch nochmal gut geholfen, die SpamAssassin Erkennungsrate zu verbessern.

Folgende Schritte sind unter Ubuntu 14.04 als Vorbereitung notwendig:

apt-get install libgeo-ip-perl
mkdir /usr/share/GeoIP
wget http://geolite.maxmind.com/download/geoip/database/GeoLiteCountry/GeoIP.dat.gz
wget http://geolite.maxmind.com/download/geoip/database/GeoIPv6.dat.gz
gunzip GeoIP.dat.gz
gunzip GeoIPv6.dat.gz
mv GeoIP.dat /usr/share/GeoIP/
mv GeoIPv6.dat /usr/share/GeoIP/

Damit wurde das notwendige Perl-Modul installiert, sowie mit der aktuellen GeoIP-Lite Datenbank von MaxMind ausgestattet. Das Plugin wird in der Datei /etc/spamassassin/init.pre aktiviert, dazu wird das Kommentarzeichen vor folgender Zeile entfernt:

loadplugin Mail::SpamAssassin::Plugin::RelayCountry

Jetzt können noch eigene Regeln geschrieben werden, um Mails aus bestimmten Ländern abzuwerten. Dazu muss ans Ende von /etc/spamassassin/local.cf folgendes:

ifplugin Mail::SpamAssassin::Plugin::RelayCountry
add_header all Relay-Country _RELAYCOUNTRY_
header RELAYCOUNTRY_BAD X-Relay-Countries =~ /(CN|RU|UA|RO|VN)/
describe RELAYCOUNTRY_BAD Relayed through spammy country at some point
score RELAYCOUNTRY_BAD 2.0

header RELAYCOUNTRY_GOOD X-Relay-Countries =~ /^(DE|AT|CH)/
describe RELAYCOUNTRY_GOOD First untrusted GW is DE, AT or CH
score RELAYCOUNTRY_GOOD -0.5
endif # Mail::SpamAssassin::Plugin::RelayCountry

Damit bekommt jede Mail, die durch ein SMTP-Relay in China, Russland, Ukraine, Rumänien oder Vietnam geroutet wurde, automatisch zwei Punkte. Im Gegenzug ziehe ich 0,5 Punkte ab, wenn das letzte Relay in Deutschland, Österreich oder der Schweiz stand.

Damit lässt sich das Ganze auch gut testen. Nach einem Neustart von SpamAssassin oder Amavis sollte bei jeder Mail, die aus Deutschland eintrudelt, folgender Check im Header stehen:

Im Gegenzug bei Mails aus den o.g. Ländern:

 

Verwendet zusätzliche Plugins

Ich habe kürzlich ein gutes SpamAssassin Plugin von eXtremeSHOK gefunden, welches die “From” und “Reply-To” Header vergleicht. Gibt es dort Unterschiede, bekommt die Mail direkt ein paar Punkte. Je nachdem, ob sich auch die Domain unterscheidet, sind es zwei bzw. direkt fünf Punkte. Bei meinem Test ist mir oft aufgefallen, dass bei Spam-Mails hier unterschiedliche Domains verwendet werden. Diesen Tipp habe ich persönlich erst zum Schluss entdeckt und eingebaut. Seitdem kam überhaupt kein SPAM mehr durch.

Die Installation ist unter Ubuntu 14.04 sehr einfach:

cd /tmp
wget https://github.com/extremeshok/spamassassin-extremeshok_fromreplyto/archive/1.3.1.tar.gz
tar -zxvf 1.3.1.tar.gz
mkdir /etc/mail/spamassassin/plugins/
cp plugins/* /etc/mail/spamassassin/plugins/
cp 01_extremeshok_fromreplyto.cf /etc/mail/spamassassin

Das war’s schon, anschließend muss noch Amavis oder der spamd neu gestartet werden. Getestet werden kann das Plugin, indem man sich selbst eine Mail schickt. Anschließend sollte der Check FROM_IS_TO im Mailheader auftauchen.

 

Modifiziert die Punktevergabe

Noch ein Kurztipp am Ende. Dieser Tipp ist relativ “advanced”, da man genau wissen sollte, was man verändert.

Mittels der Datei /etc/spamassassin/local.cf können die Standardwerte der Punktevergabe für Checks verändert werden. Ich habe bei mir die vergebenen Punkte erhöht, wenn eine Domain oder ein Link in einer DNSBL auftaucht:

score RCVD_IN_BL_SPAMCOP_NET 0 5.246 0 5.347
score RCVD_IN_BRBL_LASTEXT 0 5.246 0 5.347
score URIBL_BLACK 0 5.7 0 5.7
score URIBL_WS_SURBL 0 2.659 0 2.608
score URIBL_MW_SURBL 0 2.263 0 2.263
score URIBL_CR_SURBL 0 2.263 0 2.263
score URIBL_GREY 0 2.084 0 1.424
score URIBL_DBL_SPAM    0 4.5 0 4.5
score URIBL_DBL_PHISH   0 4.5 0 4.5
score URIBL_DBL_MALWARE 0 4.5 0 4.5
score URIBL_DBL_BOTNETCC 0 4.5 0 4.5
score URIBL_DBL_ABUSE_SPAM 0 4.0 0 4.0
score URIBL_DBL_ABUSE_PHISH 0 4.5 0 4.5
score URIBL_DBL_ABUSE_MALW  0 4.5 0 4.5
score URIBL_DBL_ABUSE_BOTCC 0 4.5 0 4.5