Home > Debian, Linux, Netz, Software, Software, Solaris, Spam > Spamassassin optimieren

Spamassassin optimieren

14. August 2007

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

  1. 14. August 2007, 22:16 | #1

    Hui, das schaut gut aus.

    Ein paar Sachen werd ich gut gebrauchen können in den nächsten Tagen.

  2. 14. August 2007, 22:30 | #2

    Hi Jörn, für mich privat hab ich SpamAssassin aufgegeben. Ich vertraue da allein auf einen reinen Bayes (der in SpamAssasin ist meines Erachtens nicht sehr sauber implementiert). Ich hab das Programm welches ich verwende seit nunmehr 3 Jahren laufen und hab eine Genauigkeit von 97,98 % wobei die fehlenden Prozente False-Positive und Positive-False sind und jetzt kommt der Witz, ich lass mir da auch den Spam kategorisieren in Nigerian Fraud, Pharma Spam, Rolex-Müll usw. und auch wenn da was falsch kategorisiert wurde, zählt das ja :-) Ich rede ja schon vom Kategorisieren, ja ich lasse mir meine Mails vorsortieren ;-) Probiers halt mal aus, das Ganze nennt sich Popfile rennt als kleiner Proxy, für grössere Unternehmen halte ich es allerdings für ungeeignet.

  3. 15. August 2007, 10:43 | #3

    Sehr schöne Tipps zu SA! Vielen Dank!
    Besonders die Anleitung zu sa-update finde ich gut. Habe gleich mal mein altes RulesDuJour Script verbannt ;)
    Wieviel bringen die netzwerbasierten Tests wie DCC, Pyzor usw. denn wirklich? Ich habe Sie bei mir deaktiviert, da ich sie nicht als allzu nützlich empfinde und die Tools doch einiges an Last/Overhead erzeugen.

  4. 16. August 2007, 00:15 | #4

    Hi, Jörn – klasse Artikel, vor allem vor dem Hintergrund, dass ich gerade dabei bin meinen Mailserver komplett neu aufzusetzen.

    Und Glückwunsch! Hast es auf die Startseite bei yigg.de geschafft – welch Ehre ;-)

  5. 16. August 2007, 00:29 | #5

    Danke fuer den Beitrag ;-).

  6. 16. August 2007, 19:43 | #6

    @gnokii: Ich hatte früher mal bogofilter laufen, aber seit ich SpamAssassin im Einsatz habe möchte ich eigentlich nichts anderes mehr machen.

    @matthias: Bei der oben verlinkten Auswertung sind von 25 Top Fired Rules 8 Netzwerkbasierende.

    @Andreas: Den Traffic den Yigg erzeugt kann man vergnachlässigen. Wenn man auf soetwas (Traffic) aus ist, kann man besser Golem Trackbacked.

  7. 17. August 2007, 16:06 | #7

    Schaut gut aus, Danke für die umfangreiche info, die ich bestimmt gut gebrauchen kann.
    Jo

  8. Hannes
    19. August 2007, 19:19 | #8

    Vielen Dank für die Tipps.

    grüße aus bremen
    H

Kommentare sind geschlossen