ACHTUNG - Neu ab 10.01.2008: Die in SpamAssassin 3.x automatisch aktivierte Blacklist SURBL ist für große Volumen von Spam (mehr als 1.000 Postfächer oder mehr als 250.000 e-Mails pro Tag) nun kostenpflichtig. Man muss sich bei einem speziellen Service registrieren.
SpamAssassin ist ein sehr leistungsfähiger Spam-Filter für (Linux-) Mail-Server. Ich hatte die Aufgabe, einen Spam-Schutz auf einem solchen Linux-System zu installieren.
Auf dem Server lief ein RedHat 7.2 sowie Sendmail, Procmail und ein Perl 5.6.0.
Grundsätzlich sollte aber das Folgende auch auf neuere Redhat-Systeme anwendbar sein, wie ich es selbst mit Redhat 9 und Perl 5.8.0 geschafft habe.
Als Erstes war es nötig, die Software auf den neuesten Stand zu bringen, also Sendmail, Procmail und Perl.
Vor allem das Update auf Perl 5.6.1 machte einige Probleme. Am besten ist es, sich alle benötigten Perl-RPMs downzuloaden, in ein Verzeichnis zu legen und dann mit "rpm -Uvh *.rpm" zu installieren.
Die benötigten Pakete sind:
Die Versionen hängen vom Redhat-System ab. Sollten noch andere Perl-Module fehlen, lassen die sich mit CPAN nachinstallieren. Das CPAN-Modul ist in Version 5.6.1 standardmäßig dabei. Man startet mit "perl -MCPAN -e shell" und installiert z.B. durch Eingabe von "install HTML::Parser". Welche Module mit welchem Name es gibt, zeigt die CPAN Search Site.
Nach erfolgreicher Aktualisierung der Grund-Software kann SpamAssassin installiert werden. Man benötigt als rpms:
Am allereinfachsten geht die Installation jedoch mit perl und CPAN selbst. Hier installiert man nacheinander benötigte Module und den SpamAssassin, ohne sich um andere Dinge kümmern zu müssen. Voraussetzung ist allerdings ein perfekt installiertes Perl, mindestens Version 5.6.1, empfehle ich.
Bei Redhat 9 sollte man zum Vermeiden von Schwierigkeiten beim Installieren von CPAN-Modulen die Datei "/etc/sysconfig/i18n" editieren und die Variable "LANG" von "en_US.UTF-8" in "en_US" ändern.
Man startet also Perl im Shell Modus:
perl -MCPAN -e shell
Um das CPAN-Modul selbst auf den neuesten Stand zu bringen, installiert man es neu, verlässt die Shell und startet sie nochmal:
install Bundle::CPAN
An der CPAN-Eingabeaufforderung installiert man nun die benötigten Pakete und Spamassassin. Wird man nach der Installation benötigter, abhängiger Module gefragt, sollte man mit Ja antworten:
o conf prerequisites_policy ask
install Bundle::LWP
install ExtUtils::MakeMaker
install File::Spec
install File::Copy
install Pod::Usage
install HTML::Parser
install HTML::Tagset
install Sys::Syslog
install DB_File
install Net::DNS
install Net::Ping
install Time::HiRes
install Test::More
install Digest::SHA1
install Digest::Nilsimsa
install Digest::MD5
install Digest::HMAC
install URI
install Getopt::Long
und schließlich
install Mail::SpamAssassin quitNach der Installation sind nur noch wenige Dinge zu konfigurieren. Eine sehr ausführliche Anleitung findet man bei www.stearns.org, wo auch andere nützliche Dinge zu SpamAssassin und anderen Themen zu finden sind.
Die wichtigsten Punkte sind hier zusammengefasst:
/etc/init.d/service spamassassin start
netstat -anp | grep spamd
Das Ergebnis ist eine Ausgabe ähnlich wie:
tcp 0 0 127.0.0.1:783 0.0.0.0:* LISTEN 4753/spamd -d -c -a
was soviel bedeutet, das der SpamAssassin-Daemon an Port 783 nach Verbindungen vom localhost lauscht.
Es gibt zwei Test-e-Mails, die mit SpamAssassin mitgeliefert werden. Die schickt man an den Dienst:
spamc -R < /usr/share/doc/spamassassin-*/sample-spam.txt
Hier sollte irgendwo in der Ausgabe eine Spamscore weit unter 5.0 stehen.
spamc -R < /usr/share/doc/spamassassin-*/sample-nonspam.txt
Diese Spam-e-Mail sollte eine Spam-Score über 5.0 haben und wird dadurch als Spam erkannt.
Die Konfigurations-Datei heißt "/etc/mail/spamassassin/local.conf". Hier ergänzt man Folgendes:
required_hits 8
rewrite_subject 1
use_terse_report 1
report_safe 0
use_bayes 1
auto_learn 1
Eine Dokumentation aller dieser Parameter bringt leider keine direkte man-Page, sondern: "perldoc Mail::SpamAssassin::Conf", was man jedoch nur als non-root Nutzer ausführen sollte.
Procmail bearbeitet eingehende Mail auf dem Server. Dieser Software muss mitgeteilt werden, dass die eingehende Mail an SpamAssassin geschickt werden soll.
Procmail hat die Konfigurations-Datei "procmailrc" unter "/etc" oder für jeden Nutzer in den Homeverzeichnissen "procmailrc" oder auch ".procmailrc".
In Datei "/etc/procmailrc" als globale Einstellung für den gesamten Server schreibt man:
DROPPRIVS=yes :0fw
"-u mail" ist eine Angabe, unter welchem non-root Nutzer der Dienst ausgeführt werden soll und wird benötigt.
Um die Konfiguration neu zu lesen, muss der SpamAssassin-Dienst neu gestartet werden:
service spamassassin restart
Um für alle Nutzer gemeinsame Konfigurationen zu haben und die Selbstlernfähigkeiten von SpamAssassin gemeinsam nutzen zu können, werden drei Nutzer (sharedspam, spamtrap und hamtrap) angelegt.
sharedspam besitzt die gemeinsame Konfiguration für die Whitelist und die Bayes-DB.
spamtrap ist eine e-Mail-Adresse, an welche nicht erkannte Spam-e-Mails ge-"bounced" werden, wodurch SpamAssassin dies dazulernt.
hamtrap ist der Gegensatz zu spamtrap: Falsch erkannte Spam, welche kein Spam sind, werden in eine Whitelist eingetragen beim "bouncen" solch einer e-Mail.
"Bouncen" ist dabei kein "Forwarding", sondern ein erneutes Senden der e-mail mit eigentlich "falschem" Absender. Dies funktioniert in fast allen e-Mail-Clients, in Outlook 2000 öffnet man eine solche Mail mit Doppelklick und wählt "Aktionen/Erneut senden..."
adduser sharedspam
mkdir /home/sharedspam/.spamassassin/
chmod 755 /home/sharedspam
chmod 777 /home/sharedspam/.spamassassin/
touch /home/sharedspam/.spamassassin/user_prefs
chmod 644 /home/sharedspam/.spamassassin/user_prefs
touch /home/sharedspam/.spamassassin/auto-whitelist
chmod 666 /home/sharedspam/.spamassassin/auto-whitelist
chown sharedspam:sharedspam /home/sharedspam/.spamassassin
chown mail:mail /home/sharedspam/.spamassassin/* (mail=User aus procmailrc)
In der Datei "/etc/mail/spamassassin/local.cf" ergänzt man:
bayes_path /home/sharedspam/.spamassassin/bayes
adduser spamtrap
cd /home/spamtrap
ln -sf ../sharedspam/.spamassassin .spamassassin
mkdir mail .procmail
chown spamtrap.spamtrap mail .procmail
In die Datei "/home/spamtrap/.procmailrc" kommt:
SHELL=/bin/sh
adduser hamtrap
cd /home/hamtrap
ln -sf ../sharedspam/.spamassassin .spamassassin
mkdir mail .procmail
chown hamtrap.hamtrap mail .procmail
In die Datei "/home/hamtrap/.procmailrc" kommt:
SHELL=/bin/sh
Um die Konfiguration neu zu lesen, muss der SpamAssassin-Dienst neu gestartet werden:
service spamassassin restart
Alle eingehenden e-Mails werden nun mit umfangreichen Checks geprüft und gegebenenfalls als Spam markiert. Dazu schreibt SpamAssassin in den Betreff standardmäßig "*****SPAM*****" (zur guten Ausfilterung mit Filterregeln im e-Mail-Client) und ergänzt den Header um einen kurzen Report.
Der Inhalt der e-Mail kann mit dem Parameter "report_safe" auch in ein Attachment (HTML oder Text) umgewandelt und angehängt werden.
Es gibt für SpamAssassin zusätzliche Scan-Module, die auf Basis von Datenbanken noch mehr Spam erkennen können. Es werden dazu externe Server abgefragt und ggf. auch aktualisiert.
Hier beschreibe ich die Integration von Razor2, DCC und Pyzor.
Razor2 basiert wie SpamAssassin auf Perl und benötigt zusätzliche Perl-Module, die über den CPAN-Service sehr einfach zu installieren sind. Man startet Perl im Shell-Modus:
perl -MCPAN -e shell
Danach gibt man nacheinander folgende Kommandos ein, um die Module zu installieren. Nach jedem Kommando läuft die jeweilige Installation ab, evtl. Fragen nach bei der Installation benötigter, abhängiger Module bestätigt man mit "yes":
install Net::Ping
Verlassen kann man die Shell mit "quit".
Nun downloadet man die neueste Version von Razor und entpackt wie gewohnt mit "tar xvfz"... Danach wechselt man in das Razor-Verzeichnis und compiliert man mit:
perl Makefile.PL
Die Installation wird durch mehrere Kommandos abgeschlossen:
razor-client
Der User sollte dem User entsprechen, unter dem SpamAssassin ausgeführt wird (siehe oben).
In die Konfigurations-Datei von SpamAssassin "/etc/mail/spamassassin/local.cf" kommen noch folgende Zeilen (Pfad ggf. anpassen):
razor_config /etc/razor/razor-agent.conf
DCC steht für "Distributed Checksum Clearinghouse" und funktioniert ähnlich wie Razor.
Erst die neueste Version von DCC downloaden und wieder entpacken. Installiert wird mit:
./configure --disable-server --disable-dccm
Die Installation erstellte eine Datei "map.txt", in der die aktuellen DCC-Server stehen. Diese Server müssen in eine Datei "map" übertragen werden. Falls diese Datei noch nicht existiert, muss sie vorher erstellt werden. Diese Dinge erledigen wir mit "cdcc", dem Kommando-Interface von DCC:
cdcc "new map"
Ob die Installation erfolgreich war und die externen Server ansprechbar sind, geschieht mit:
cdcc "info"Das Ergebnis sollte eine Server-Liste mit Parametern sein.
In die Konfigurations-Datei von SpamAssassin "/etc/mail/spamassassin/local.cf" kommen noch folgende Zeilen (Pfad ggf. anpassen):
dcc_path /usr/local/bin/dccproc
Pyzor basiert auf Python (mind. Python 2.2.1) und war ursprünglich lediglich eine Python-Version von Razor. Mittlerweile ist es aber völlig unabhängig davon und erkennt teilweise mehr als Razor.
Nach dem Entpacken (mit "bunzip2" und "tar xvf") und dem Wechsel in das Pyzor-Verzeichnis installiert man mit:
python setup.py build
Evtl. werden dabei die Rechte nicht richtig gesetzt. Korrigiert wird mit (Python-Version beachten!):
chmod -R a+rX /usr/local/share/doc/pyzor /usr/local/lib/python2.2/site-packages/pyzor /usr/local/bin/pyzor /usr/local/bin/pyzord
In die Konfigurations-Datei von SpamAssassin "/etc/mail/spamassassin/local.cf" kommen noch folgende Zeilen (Pfad ggf. anpassen):
pyzor_path /usr/bin/pyzor
Dann wird SpamAssassin neu gestartet:
service spamassassin restart
Nützlich ist es, sich von allen Modulen die zugehörigen Dokumentationen und Readme-Dateien durchzulesen, um evtl. manuelle Anpassungen vornehmen zu können.
Außerdem sollte man in regelmäßigen Abständen prüfen, ob der "public server", auf den Pyzor zugreift, noch korrekt ist bzw. vorsichtshalber nach einer neuen Server-IP suchen lassen mittels
pyzor discover
Beispielsweise änderte sich der "public server" im Januar und im April 2009. Und seit Mai 2009 gibt es die neue Version 0.5!
Die Erkennungsraten von SpamAssassin kann man noch steigern, indem man zusätzliche Blacklists und zusätzliche Regelsätze verwendet, die im Internet in rauhen Mengen existieren:
Blacklists ergänzt man in der "local.cf". Hier zwei Beispiele:
header RCVD_IN_BNBL eval:check_rbl('bl','bl.blueshore.net.')
Weitere Blacklists findet man leicht bei Google mit dem Stichwort "check_rbl".
Zusätzliche Regeln (Rulesets) findet man im Internet z.B. im Rulesemporium (wird momentan nicht aktualisiert) oder auch im SpamAssassin-Wiki.
Ich habe mir einen Cron-Job geschrieben, der (bei Redhat) als ausführbare Datei in /etc/cron.weekly liegt:
rm -f /etc/mail/spamassassin/bigevil.cf
Wie man sieht, muss man die Rulesets nur in das Verzeichnis /etc/mail/spamassassin neben die "local.cf" legen und spamassassin neu starten. Tut man dies manuell bzw. zum ersten Mal, empfiehlt sich vorher, mit "spamassassin --lint" zu prüfen, ob alle Regeln o.k. sind.
Auf sehr ähnliche Weise installiert man das Plugin "SpamCopURI".
Erst downloaden, entpacken, dann installieren:
Kommt es beim "make test" zu Fehlermeldungen, fehlen evtl. andere Perl-Module. Die installiert man mit der CPAN-Shell (siehe oben). Bei einem meiner Installationen auf Redhat 7.2 und Perl 5.6.1 fehlte z.B. das Modul "Storable", was ich in der CPAN-Shell einfach mit "install Storable" installierte.
Danach erstmal ein "make clean" im Installationsverzeichnis des "SpamCopURI" zum Aufräumen und alles nochmal von vorn.
Am Ende die eine .cf-Datei aus dem Verzeichnis "rules" neben die "local.cf" des SpamAssassin legen/kopieren, SpamAssassin neu starten, fertig.
Der Vorteil dieser Blacklist ist, dass keine Absender in dieser Blacklist erfasst werden, sondern ganze e-Mails. Unabhängig vom Absender werden solche e-Mails also dann als Spam erkannt.
Ein SpamAssassin-Update ist wirklich sehr leicht. Ich hätte es selbst kaum geglaubt. :-)
Zuerst beendet man den laufenden SpamAssassin-Dienst:
service spamassassin stop
Jetzt macht man noch eine Aufräumaktion, damit die Daten von der neuen Version (sie hat auch ein neues Datenbank-Format der Bayes-Daten) gut erkannt werden und konvertiert werden können. Die Konvertierung geschieht beim ersten Start.
sa-learn --rebuild
Danach startet man die Perl CPAN-Shell und installiert das SpamAssassin-Paket. Vorsichtshalber sollten zusätzlich einige Pakete aktualisiert werden.
perl -MCPAN -e shell o conf prerequisites_policy ask
Jetzt nochmal Daten vorbereiten und dann den Dienst neu starten:
sa-learn --rebuild
Es sollte jetzt alles wie bisher laufen.
Vorteilhaft ist es, wenn man sich von der SpamAssassin-Website das Source-Archiv der neuen Version downloadet und entpackt. Dort ist neben einiges an Dokumentation auch ein Patch für Razor2 enthalten.
Dafür sucht man das Razor2-Home-Verzeichnis (bei mir ist das /usr/lib/perl5/site_perl/5.6.1/i386-linux/Razor2). Hier sollte auch ein Unterverzeichnis "Client" sein. Daneben hin kopiert man die Datei "Razor2.patch" aus den SpamAssassin-Quellen und startet den Patch mit:
patch -p0 < Razor2.patch
Einige Meldungen erscheinen und alles sollte o.k. sein.
Wie schon bei einem Update auf 2.6x geht es los:
SpamAssassin stoppen:
service spamassassin stop
Dann die Bayes-Datenbank vorbereiten und aufräumen:
sa-learn --rebuild
Jetzt ins CPAN:
perl -MCPAN -e shell
Jetzt einfach SpamAssassin installieren:
install Mail::SpamAssassin
(Vorsichtshalber hier die benötigten Perl-Module:
Digest::SHA1
HTML::Parser (besser als 3.24)
Storable
DB_File
Net::DNS (wichtig! neueste Version)
Net::SMTP
Mail::SPF::Query
(IP::Country::Fast)
Mail::Audit::Razor
(Net::Ident)
(IO::Socket::SSL)
Time::HiRes
DBI
DBD::mysql (für MySQL-Datenbank für die Bayes-Daten)
Fragen, ob benötigte andere Module installiert werden sollen, sollten immer mit JA beantwortet werden.)
Anschließend muss man noch einige Dinge vor dem nächsten Start vorbereiten.
Datenbank konvertieren:
sa-learn --sync (ersetzt auch die Option --rebuild)
Die Startoptionen "--auto-whitelist", "--whitelist" und "-a" zur Aktivierung der Auto-Whitelist-Funktion gibt es nicht mehr. Stattdessen steht in der "local.cf":
use_auto_whitelist 1
"rewrite_subject" und "subject_tag" gibt es auch nicht mehr. Stattdessen in die "local.cf":
Version 3.0.0:
rewrite_subject 1
subject_tag ****SPAM****
ab Version 3.0.1:
rewrite_header subject *****SPAM*****
Jetzt checkt man noch die Gesamtkonfiguration und merzt letzte Fehler in der "local.cf" aus:
spamassassin --lint
Jetzt kann man mal risikieren, SpamAssassin neu zu starten:
service spamassassin start
Außerdem sollten vorhandene Regelsätze daraufhin überprüft werden, ob denn diese Funktion nicht schon sowieso in Version 3.0.x enthalten ist. Z.B. braucht man die "antidrug.cf" aus dem Rulesemporium nicht mehr. Eine gute Idee ist es, die alten Sätze zu löschen und nur die wirklich nötigen Teile neu zu downloaden. Manchmal haben die im Namen ein "post3.0.x" oder andere Kennzeichen bzgl. der Versionen von SpamAssassin.
In Version 3.0.x ist es möglich, die Bayes-Datenbank in einer MySQL-Datenbank oder ähnlichem zu speichern.
Dazu benötigt man das Quellcode-Paket von SpamAssassin, worin dann eine Beschreibung, der SQL-Code zum Anlegen der Datenstruktur und auch eine nette Beschreibung drin ist (im Verzeichnis "/sql").
In Kürze dieser Vorgang:
- Bayes-Daten exportieren
- Datenbank und Tabellen anlegen
- Bayes-Daten in die Datenbank importieren (dauert ziemlich lange!)
- "local.cf" um die Zugriffsdaten für die MySQL-Datenquelle ergänzen
Bei der Installation ändert sich nicht viel, siehe oben die Beschreibung zu SpamAssassin 3.0x
Beim Update ist zu beachten, dass einige bisherige Bestandteile des Hauptprogrammes nun externe PlugIns sind, andere PlugIns (DCC, Razor2) sind standardmäßig (wegen Lizenzproblemen) deaktiviert.
Eine gute Beschreibung zum Update ist das offizielle UPGRADE file.
Hier noch die offizielle Installationsanleitung.
Bei der Installation ändert sich nicht viel, siehe oben die Beschreibung zu SpamAssassin 3.0.x
Beim Update ist zu beachten, dass nun der localhost 127.0.0.1 stets Mitglied des "trusted_networks" ist, was auch Sinn macht. Außerdem gibt es im Bereich Mail Submission Agents ("msa_networks") Neuigkeiten, worüber die man-Pages von Mail::SpamAssassin::Conf detailliert Auskunft geben.
Eine gute Beschreibung zum Update ist das offizielle UPGRADE file.
Hier noch die offizielle Installationsanleitung.
Bei der Installation ändert sich nicht viel, siehe oben die Beschreibung zu SpamAssassin 3.0.x
Beim Update ist zu beachten, dass die Regeln (Rules) nicht mehr von Anfang an Bestandteil von SpamAssassin 3.3.x sind. Man muss am Anfang einmal "sa-update" starten oder die ergänzenden Regeln als .tgz Package ("rules tarball") downloaden und dann starten "sa-update --install" zum Installieren der Regelsätze.
Die SQL-Unterstützung ist ab jetzt nicht mehr im Beta-Stadium.
Außerdem ist das DKIM Plugin (für DomainKey Lookups) standardmäßig aktiviert, wenn das Perl-Modul Mail::DKIM installiert wurde. Da aber die Konfigurationsdateien .pre (falls existent, z.B. local.pre) nict automatisch aktualisiert werden, muss man dort ggf. auskommentieren oder ergänzen und damit aktivieren:
Eine gute Beschreibung zum Update ist das offizielle UPGRADE file.
Hier noch die offizielle Installationsanleitung.
Bei der Installation ändert sich nicht viel, siehe oben die Beschreibung zu SpamAssassin 3.0.x
In der Bayes-Datenbank wurde ein Fehler behoben der bewirkt, dass neue e-Mail nicht mehr mit zuvor gelernten alten Daten in Relation gebracht werden kann. Es wird empfohlen, die Bayes-Datenbank zu leeren und neu anzufangen. Kein sehr netter Tipp...
Neues optionales Modul Net::Patricia um Zugriffe auf internal_networks, trusted_networks oder msa_networks zu beschleunigen.
Die benötigte Minimalversion von NetAddr::IP wurde zu Version 4.010 geändert.
Ergänzend kann eine Bayes-Datenbank auf einem Redis-Server lokal oder in einem Netzwerk gehostet werden. Mehrere SpamAssassin-Installationen können gleichzeitig auf so eine Datenbank zugreifen, ähnlich wie bei SQL.
Eine gute Beschreibung zum Update ist das offizielle UPGRADE file.
Hier noch die offizielle Installationsanleitung.
Eine gute Beschreibung zum Update ist das offizielle UPGRADE file.
Hier noch die offizielle FAQ.