Die Kunst beim Optimieren von Spamassassin heisst gute Planung, beobachten können und sich in Zurückhaltung üben. Man sollte zuallerst nie die Relationen aus den Augen verlieren. Wenn bei 100 Spams eine durchkommt liegt die Erkennungsrate immer noch bei 99 Prozent. Aktuell bekomme ich ca. 250 Spams am Tag. Selten wird davon eine nicht erkannt, womit ich schon im Nachkommta-Bereich bin. Auch Nutzer die aufgeregt anrufen, das eine Spam-Mail durchgekommen ist oder entsprechende Mails weiterleiten sollte man getrost ignorieren. Die Welt geht auch nicht unter, wenn eine Mail vom Bayes-System[1] vermeintlich falsch gelernt wurde. Dabei wird vergessen das es sich um eine statistische Wahrscheinlichkeit handelt und dafür braucht man die entsprechenden Wörter sowohl in der Spam, als auch in der Ham Datenbank. Ein Beispiel:
Kommt das Wort Viagra in 3000 Spam-Mails 500 mal vor und in 5 von 600, liegt die Wahrscheinlichkeit bei:
(300/5000) / (5/600 + 300/5000) = 0,98
Ausserdem macht die Bayes-Bewertung nur einen Teil des Gesamt-Score aus. Lange Rede, kurzer Sinn: Ruhe bewahren ist wichtig. Meiner Erfahrung nach bringt es ausser schlechten Erkennungsraten und False Positives nicht viel an den vorgegeben Scores herumzudrehen. Je mehr man daran rumdreht, umso mehr Arbeit macht man sich an anderer Stelle. Im Folgenden also ein paar Dinge, die man beim Betrieb von Spamassassin auf Servern beachten, tun und sein lassen sollte.
Ist das System schon in Betrieb und leidet unter schlechten Ergebnissen, sollte man zuerst feststellen welche Regeln für die Einteilung in Spam und Ham überhaupt greifen. Gute Dienste leistet hier sa-stats, welches allerdings ein Logfile des Spamd benötigt um aussagekräftige Statistiken zu erzeugen. Bei Debian wird hierzu /etc/default/spamassassin angepasst und das OPTIONS-Feld um -s /var/log/maillog erweitert. Anschließend einmal
touch /var/log/maillog
und den Spamd durchtreten nicht vergessen. Je nach Mail-Durchsatz muss man nun ein wenig warten, also Zeit logrotate einzurichten. Für die meisten sollte es reichen wöchentlich das Spamd-Logfile zu rotieren und somit einen guten Kompromiss zwischen Grösse des Logfiles und Aussagekraft der Statistik zu erreichen. So hat /etc/logrotate.d/spamassassin auszusehen:
/var/log/maillog {
weekly
missingok
rotate 12
compress
delaycompress
notifempty
create 640 root root
sharedscripts
postrotate
/etc/init.d/spamassassin reload >/dev/null
endscript
}
Sind genug Daten gesammelt heisst es sa-stats auszuführen. Dem Ergebniss sieht man sofort ein paar wichtige Informationen an wie z.B. das Verhältnis von Spam und Ham oder der generelle Durchsatz an Mail. Am intressantesten sind natürlich die Top Fired Rules für Spam und Ham, die man unter den Gesichtspunkt durchschauen sollte, das Regeln welche für die Spamerkennung da sind, wie z.B. BAYES_99 für Spam oder AWL für Ham (AWL), auf den richtigen Seiten stehen. Tun sie es nicht sollte man mit diesen Datenbanken von vorne beginnen.
Das Bayes-System
Ich persönlich arbeite mit einer generellen Bayes- und AWL-DB für alle. Eigene Datenbanken für Benutzer sind ein stetiger Quell von False-Positives, da entweder komplett falsch gelernt wird oder garnicht. Es ist einfach zu aufwendig und ineffektiv an dieser Stelle hinterherzuräumen, daher lohnt es sich nicht. Solch generelles Setup erreicht man entweder durch ein Site-Wide Setup oder weil Spamassassin von z.B. Amavis getriggert wird und sich somit im Home-Verzeichnis vom Amavis-User die Datenbanken aufbauen.
Bevor es los geht noch ein paar Worte zu den Bayes- und AWL-DBs. Zu einem ist es gut, wenn man die Funktion der AWL versteht:
The AWL is actually a very simple system. In short, the AWL is a score averaging system. It keeps track of the historical average of a sender, and pushes any subsequent mail towards that average. So if someone that never sent you mail before sends you a mail that scores 20, and then sends you a second mail that would score 2.0 without the AWL, the AWL will push the score up to 11 on the second mail. This is auto blacklisting, based on their past history of spam.
Zum anderen sollte man sich abgewöhnen an der Bayes-DB rumzudrehen. Das Autolearning funktioniert bei vernünftigen Regelsätzen besser als jeder Mensch, also Finger weg. Bei solch einen Setup lohnt es sich auch nicht alle erkannten Spams und Hams nachträglich nocheinmal manuell nachzulernen, denn sie wurden bereits durch das Auto-Learning hinzugefügt.
Arbeitet das Bayes-System garnicht liegt es mit hoher Wahrscheinlichkeit an zu wenig gelernten Spam und Ham.
amavis@rte:$ sa-learn --dump magic
0.000 0 3 0 non-token data: bayes db version
0.000 0 21852 0 non-token data: nspam
0.000 0 7754 0 non-token data: nham
0.000 0 150913 0 non-token data: ntokens
0.000 0 1184319834 0 non-token data: oldest atime
0.000 0 1187116894 0 non-token data: newest atime
0.000 0 0 0 non-token data: last journal sync atime
0.000 0 1187084641 0 non-token data: last expiry atime
0.000 0 2764800 0 non-token data: last expire atime delta
0.000 0 1991 0 non-token data: last expire reduction count
Die Werte nham und nspam stehen für die Anzahl bereits gelernter Mails. Liegen sie unter 200 ist das Bayes-System deaktiviert. Möchte man es trotzdem starten kann man dies mit bayes_min_ham_num und bayes_min_spam_num in der Spamassassin-Konfiguration beeinflussen. Auch empfiehlt es sich vor der Inbetriebnahme Gedanken über wichtige Email-Partner zu machen und diese in die Whitelist zu nehmen. Man kann sie später wieder entfernen, da die Whitlist-Scores in die AWL eingegangen ist.
Netzwerkbasierte Tests
Spamassassin basiert im Grunde aus drei Teilen: Festen Regelsätzen, die in der Mail nach bestimmten Pattern suchen, dem Bayes-System und den Netzwerk-basierten Tests wie Razor, Pyzor und (Su)RBLs. Bei Debian geht die Installation recht einfach:
apt-get install libnet-dns-perl razor pyzor dcc-client dcc-common
Man sollte darauf achten einen schnellen DNS-Server in Reichweite zu haben oder lokal einen Caching-DNS betreiben um die Antwortzeiten und damit die Durchlaufzeit einer Mail zu minimieren. Steht der Server hinter einer Firewall sind entsprechende Regeln einzupflegen, näheres hier.
Externe Regelwerke
Die mitgelieferten Regelsätze von Spamassassin sind schon recht gut, man kann sie aber noch verbessern. Aber auch hier sollte man Vorsicht walten lassen. Viele Regeln helfen nicht viel, im schlimmsten Fall machen sie Spamassassin zu einen Ram fressenden Monster. Meine Daumenregel ist dabei, das ich sie wieder lösche wenn sie nach einer Woche nicht in den Top 20 Regeln auftauchen.
Ein guter Anfang sind die Regeln vom RulesEmporium. Die kann man einfach ins Konfigurations-Verzeichnis werfen und Spamassassin durchstarten. Da sie sich aber hin und wieder ändern ist ein automatisches Update wünschenswert. Anfangs gab es RulesDuJour das aber seit dem erscheinen von sa-update nicht mehr weiterentwickelt wird.
sa-update arbeite mit sogenannten Channels, die quasi jeder zur Verfügung stellen kann. Ich nutze zum einen den Update-Channel von Spamassassin und einen von Daryl O’Shea. Zuerst muss man die GPG-Keys installieren:
wget wget http://daryl.dostech.ca/sa-update/sare/GPG.KEY
gpg --import GPG.KEY
sa-update --import GPG.KEY
rm GPG.KEY
wget http://spamassassin.apache.org/updates/GPG.KEY
gpg --import GPG.KEY
sa-update --import GPG.KEY
Anschließend legt man ein File an, indem die Channels hinterlegt werden:
touch /etc/spamassassin/sare-sa-update-channels.txt
Und packt folgende Daten rein, welche die externen Regelwerke repräsentieren die geladen werden sollen:
updates.spamassassin.org
70_sare_stocks.cf.sare.sa-update.dostech.net
70_sare_adult.cf.sare.sa-update.dostech.net
70_sare_spoof.cf.sare.sa-update.dostech.net
70_sare_bayes_poison_nxm.cf.sare.sa-update.dostech.net
70_sare_genlsubj_x30.cf.sare.sa-update.dostech.net
70_sare_oem.cf.sare.sa-update.dostech.net
70_sare_random.cf.sare.sa-update.dostech.net
70_sare_specific.cf.sare.sa-update.dostech.net
70_zmi_german.cf.zmi.sa-update.dostech.net
88_FVGT_Bayes_Poison.cf.sare.sa-update.dostech.net
88_FVGT_Tripwire.cf.sare.sa-update.dostech.net
88_FVGT_rawbody.cf.sare.sa-update.dostech.net
88_FVGT_subject.cf.sare.sa-update.dostech.net
chickenpox.cf.sare.sa-update.dostech.net
Um beide Channels gleichzeitig updaten zu können braucht es nun noch ein Key-File
touch /etc/spamassassin/keys
indem die Keys stehen:
856AA88A
5244EC45
Nun kann man mit
sa-update -D --channelfile /etc/spamassassin/sare-sa-update-channels.txt --gpgkeyfile /etc/spamassassin/keys
die Regelsätze herunterladen und im späteren mit dem selben Befehl auf Stand halten. Vor dem Neustart von Spamassasin ist dringenden ein
spammassassin -D --lint
angesagt um Fehler im Regelwerk rechtzeitig zu erkennen.
Ausblick
Im zweiten Teil geht es um allerlei Plugins mit denen man unter Spamassassin arbeiten kann.
[1] - Kampf dem Spam
Posted: August 14th, 2007 under Debian, Linux, Netz, Software, Software, Solaris, Spam.
Comments: 9
