Position: Home > Computer Know-How / Gewusst Wie > SpamAssassin

SpamAssassin

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:

  • perl-5.6.1
  • perl-Net-DNS
  • perl-HTML-Parser
  • perl-HTML-Tagset

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:

  • perl-Mail-SpamAssassin
  • spamassassin
  • spamassassin-tools (optional, z.B. für Konfigurationen mit MySQL-DB)

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
quit
perl -MCPAN -e shell

 

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 quit

 

Nach 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.

Tuning für SpamAssassin

Update auf Version 3.4.x von SpamAssassin

Update auf Version 3.3.x von SpamAssassin

Update auf Version 3.2.x von SpamAssassin

Update auf Version 3.1.x von SpamAssassin

Update auf Version 3.0.x von SpamAssassin

Update auf Version 2.6x von SpamAssassin

 

Die wichtigsten Punkte sind hier zusammengefasst:

Start von SpamAssassin

/etc/init.d/service spamassassin start

Netzwerk-Test von SpamAssassin

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
unix 2 [ ] DGRAM 5988777 4753/spamd -d -c -a

 

was soviel bedeutet, das der SpamAssassin-Daemon an Port 783 nach Verbindungen vom localhost lauscht.

Funktions-Test von SpamAssassin

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.

Konfiguration von SpamAssassin

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-Setup

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
| /usr/bin/spamc -u mail

 

"-u mail" ist eine Angabe, unter welchem non-root Nutzer der Dienst ausgeführt werden soll und wird benötigt.

Neustart von SpamAssassin

Um die Konfiguration neu zu lesen, muss der SpamAssassin-Dienst neu gestartet werden:

service spamassassin restart

Gemeinsame Whitelist, Bayes-DB und Auto-Reporting-Adressen

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..."

Nutzer sharedspam

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
auto_whitelist_path /home/sharedspam/.spamassassin/auto-whitelist
bayes_file_mode 777
auto_whitelist_file_mode 777
use_bayes 1
auto_learn 1
bayes_ignore_header ReSent-Date
bayes_ignore_header ReSent-From
bayes_ignore_header ReSent-Message-ID
bayes_ignore_header ReSent-Subject
bayes_ignore_header ReSent-To
bayes_ignore_header Resent-Date
bayes_ignore_header Resent-From
bayes_ignore_header Resent-Message-ID
bayes_ignore_header Resent-Subject
bayes_ignore_header Resent-To

Nutzer spamtrap

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
PATH=/bin:/usr/bin
PMDIR=$HOME/.procmail
LOGABSTRACT=all
MAILDIR=$HOME/mail #you'd better make sure it exists
LOGFILE=$PMDIR/proclog #recommended
VERBOSE=off
#Spamassassin start :0
* > 256000
toobigtoreport
:0c: spamassassin.lock
| /usr/bin/spamassassin -r -d -a
:0c: spamassassin.lock
| /usr/bin/sa-learn --spam
:0:
learned-spam
#Spamassassin end

Nutzer hamtrap

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
PATH=/bin:/usr/bin
PMDIR=$HOME/.procmail
LOGABSTRACT=all
MAILDIR=$HOME/mail #you'd better make sure it exists
LOGFILE=$PMDIR/proclog #recommended
VERBOSE=off
#Spamassassin start :0
* > 256000
toobigtoreport
:0c: spamassassin.lock
| /usr/bin/sa-learn --ham --single --local
#:0:
#learned-ham
#Spamassassin end

Neustart von SpamAssassin

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.

Installieren von zusätzlichen Modulen

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
install Net::DNS
install Time::HiRes
install Test::More
install Digest::SHA1
install Digest::Nilsimsa
install Digest::MD5
install Digest::HMAC
install URI
install Getopt::Long
install File::Copy

 

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
make
make test
make install

 

Die Installation wird durch mehrere Kommandos abgeschlossen:

razor-client
razor-admin -create
razor-admin -register -user=mail -pass=deinpasswort

 

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
use_razor2 1

 

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
make
make install

 

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"
cdcc "add servername1"
cdcc "add servername2"

 

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
add_header all DCC _DCCB_: _DCCR_
use_dcc 1

 

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
python setup.py install

 

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
add_header all Pyzor _PYZOR_
use_pyzor 1

 

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!

Tuning für SpamAssassin

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.')
describe RCVD_IN_BNBL Listed by BNBL
tflags RCVD_IN_BNBL net
score RCVD_IN_BNBL 4.00
header RCVD_IN_XBL.SPAMHAUS.ORG rbleval:check_rbl('relay','xbl.spamhaus.org.')
describe RCVD_IN_XBL.SPAMHAUS.ORG Received via a relay in xbl.spamhaus.org
tflags RCVD_IN_XBL.SPAMHAUS.ORG net
score RCVD_IN_XBL.SPAMHAUS.ORG 4.00

 

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
rm -f /etc/mail/spamassassin/evilnumbers.cf
rm -f /etc/mail/spamassassin/98_text_de_evilnumbers.cf
rm -f /etc/mail/spamassassin/bogus-virus-warnings.cf
wget -P /etc/mail/spamassassin http://www.rulesemporium.com/rules/bigevil.cf
wget -P /etc/mail/spamassassin http://www.yackley.org/sa-rules/evilnumbers.cf
wget -P /etc/mail/spamassassin http://www.yackley.org/sa-rules/98_text_de_evilnumbers.cf
wget -P /etc/mail/spamassassin http://www.timj.co.uk/linux/bogus-virus-warnings.cf
service spamassassin restart

 

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:

perl Makefile.PL
make
make test
make install

 

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.

Update auf Version 2.6x

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
install DB_File
install HTML::Parser
install HTML::Tagset
install ExtUtils::MM
install Net::DNS
install Mail::SpamAssassin
quit

 

Jetzt nochmal Daten vorbereiten und dann den Dienst neu starten:

sa-learn --rebuild
service spamassassin start

 

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.

Update auf Version 3.0.x

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

Update auf Version 3.1.x

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.

Update auf Version 3.2.x

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.

Update auf Version 3.3.x

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:

loadplugin Mail::SpamAssassin::Plugin::DKIM

 

Eine gute Beschreibung zum Update ist das offizielle UPGRADE file.

Hier noch die offizielle Installationsanleitung.

Update auf Version 3.4.x

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.

SpamAssassin Logo (Little Rubber Ninja)
Ingenieure ohne Grenzen
NachDenkSeiten - Die kritische Website
www.charitywater.org