Wer seinen Spamassassin nicht nur in der Standardkonfiguration betreiben möchte, sondern darüber hinaus noch weitaus mehr Tests zum Erkennen von Spam nutzen. Hierfür hatte man früher über die Seite exit0.us ein Bash Script zur Verfügung gestellt bekommen, welches die Sare Checks herunterläd. Durch die Neuerungen in Spamassassin ist dieses Script überflüssig geworden, da man nun sa-update als nützliches Werkzeug an die Hand bekommt. Nur ich vermute, dass die wenigsten wissen werden wie man dies korrekt konfiguriert.

Und genau deswegen heute dieses HowTo. Man nehme einen handelsüblichen Server auf dem ein Spamassassin bereits vorinstalliert ist und auch funktioniert. Alles weitere wird nun beschrieben.

Inhalt

1. Vorbereiten der Verzeichnisse
2. Import der notwendigen GnuPG Keys
3. Erzeugen der Konfigurationsdateien
4. sa-update das erste Mal ausführen
5. Optional: Cronjob einrichten

Und schon geht’s los…

1.) Vorbereiten der Verzeichnisse

Damit sa-update arbeiten kann benötigt es ein Verzeichnis in dem die GnuPG Keys und andere Daten abgelegt werden: sa-update-keys. Das Verzeichnis muss, sofern es nicht vorhanden ist erstellt werden. Ich traue nun mal jedem zu, dass er weiß wie ein Verzeichnis angelegt wird. Um später keinen Rechtefehler beim sa-update zu erhalten, geben wir dem Verzeichnis die Rechte 0600 für die User:Gruppe root:root. Im Endergebnis schaut dann alles so aus:


drwx------ 2 root root 4096 2009-03-30 06:46 sa-update-keys


Das war ja nun noch leicht Daher ziehen wir ohne Warten direkt zum nächsten Punkt weiter

2.) Import der notwendigen GPG Keys

Um sicherzustellen, dass die heruntergeladenen Regeldateien auch vom Entwickler stammen und nicht von bösen Buben, ist es notwendig dass wir die GnuPG Keys herunterladen und diese unserem lokalen Keyring hinzufügen. Nun laden wir erst einmal herunter:


wget http://spamassassin.apache.org/updates/GPG.KEY -O GPG-sa.KEY
wget http://daryl.dostech.ca/sa-update/sare/GPG.KEY -O GPG-dostech.KEY


Und schon haben wir die Keyfiles der beiden Channels. Da beide Dateien gleich lauten habe ich eine Output Anweisung bei wget angegeben, die uns 2 verschiedene Dateien anlegt. Nun müssen diese Keys in den Keyring importiert werden:


gpg --import GPG-sa.KEY
gpg --import GPG-dostech.KEY


Spamassassin bzw. sa-update hat aber noch einmal einen eigenen Keycache dem wir ebenfalls die Dateien zuführen müssen:


sa-update --import GPG-sa.KEY
sa-update --import GPG-dostech.KEY


Das wäre geschafft. Damit sind wir nun gerüstet die Channel und GPGKey Dateien anzulegen.

3.) Erzeugen der Konfigrationsdateien

sa-update bietet die Möglichkeit mehrere Regelsätze direkt herunterzuladen. Dazu legt man einfach eine Datei an in welcher die verschiedenen Regeln eingetragen werden. Bei einem Update übergibt man diese einfach zusammen mit der GnuPG Datei und schon werden die Regel automatisch heruntergeladen. Die notwendigen Inhalte folgen nun:


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.sare.sa-update.dostech.net
70_sare_evilnum0.cf.sare.sa-update.dostech.net
70_sare_highrisk.cf.sare.sa-update.dostech.net
70_sare_header0.cf.sare.sa-update.dostech.net
70_sare_html0.cf.sare.sa-update.dostech.net
70_sare_obfu0.cf.sare.sa-update.dostech.net
70_sare_stocks.cf.sare.sa-update.dostech.net
70_sare_unsub.cf.sare.sa-update.dostech.net
70_sare_uri0.cf.sare.sa-update.dostech.net
70_sare_uri1.cf.sare.sa-update.dostech.net
70_sare_uri3.cf.sare.sa-update.dostech.net
70_sc_top200.cf.sare.sa-update.dostech.net
72_sare_bml_post25x.cf.sare.sa-update.dostech.net
99_sare_fraud_post25x.cf.sare.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


Übrigens genau genommen sind dies nicht die direkten Regeln sondern sog. Channels in welchen die Regeln verwaltet werden (nur falls ein Schlaumeier wieder meint man müsse gleich mit Wissen prahlen). Die oben stehenden Zeilen dann einfach in eine Datei kopieren und wie folgt benennen: sare-sa-update-channels.chan

Als nächstes legen wir eine Datei für die beiden GnuPG Keys an. Man könnte diese auch direkt über die Option –gpgkey übergeben, da man sich aber die Zahlen-/Buchstabenkombinationen eher schlecht merken kann, nutzen wir dazu ebenfalls eine Datei:


856AA88A
5244EC45


Diese Zeilen kopieren wir nun ebenfalls in eine Datei und benennen diese: sare-sa-update-keys.chan. Fertig sind unsere beiden Konfigurationsdateien die wir nun im nächsten Schritt an sa-update übergeben.

4.) sa-update das erste Mal ausführen

Nachdem wir nun alle notwendigen Maßnahmen ergriffen haben, können wir das Update nun das erste Mal durchführen und die Regeldateien herunterladen. Ich empfehle beim beim ersten Update die Debug Option “-D” mit zu aktivieren, damit man auf Fehler aufmerksam wird.


sa-update --channelfile sare-sa-update-channels.chan --gpgkeyfile sare-sa-update-keys.chan -D


Es huschen nun eine ganze Menge Zeilen und Ausgaben über die Shell. Wie gesagt, solange keine Fehlermeldung erscheint ist alles normal. Spamassassin selbst kennt die Regeln nach dem Update aber noch nicht und muss daher mit der Option “–lint” aufgerufen werden. Auch hier kann man die Debug Option “-D” nutzen um weitere Fehler zu lokalisieren:


spamassassin --lint -D


Fertig Und nun darf der Spam gerne kommen.

5.) Optional: Cronjob zum automatischen Update anlegen

Sobald man Spamassassin installiert hat, wird auch (zumindest bei Debian) ein Cronjob angelegt der tägliche Updates des Spamfilters durchführt. Daher würde ich als erstes im Verzeichnis “/etc/cron.daily” nachsehen ob dort eine Datei namens “spamassassin” liegt. Wenn ja, dann diese mit einem Editor deiner Wahl öffnen und folgendes ersetzen:


# Update
umask 022
sa-update --channelfile /etc/mail/spamassassin/sare-sa-update-channels.chan --gpgkeyfile /etc/mail/spamassassin/sare-sa-update-keys.chan || exit 0


Bitte vorher nachsehen ob eine ähnliche Zeile bereits im Script vorhanden ist und diese dann durch die og. ersetzen. Nun kann der Crond jeden Tag die Updates herunter holen und in den Spamassassin laden. Mehr ist nicht zu tun

Vor kurzem (ich weiss leider das genaue Datum nicht) ist eine neue PLESK Version erschienen. Verwunderlich war, dass die Version 9.1 scheinbar komplett ausgelassen wurde. Neben einigen Bugfixes wurden scheinbar auch einige Postfix Probleme behoben.

Die komplette Liste findet man hier: http://download1.parallels.com/Plesk/PPP9/plesk-9.2.1-for-deb-based-os.html

Ich habe auf meinen Servern das Update bereits durchgeführt und beim Updateprozess keine größeren Probleme festgestellt. In der neuen Version ist nun ein Greylisting Daemon enthalten. Dieser wird aber nicht über postgrey bereitgestellt, sondern direkt von Plesk. Einigen Stimmen zu folge soll es damit aber bereits Probleme geben, in dem sehr viele Prozesse gestartet werden, während das Greylisting abläuft. Ich für meinen Teil nutze das so oder so nicht, sondern konfiguriere Postfix dahingehend, dass er postgrey und policyd-weight nutzt. Damit habe ich mehr Kontrolle was das Whitelisting von Clients, Emailadressen und Hosts angeht.

Ich stelle später noch eine Konfigurationsanleitung zur Verfügung in der man nachlesen kann wie man sowas einstellt

Neu an Board ist nun auch der Migration Manager wieder, welcher seit der Veröffentlichung der Version 9 von PLESK immer gefehlt hat. Mal sehen wie stabil die neue Version läuft.

Mozilla hat eine weitere Beta Version des neuen Firefox 3.5 (vormals 3.1) veröffentlicht. In der neuen Version wurde nun wie angekündigt die Versionsnummer auf 3.5 geändert und dazu noch einige Bugfixes sowie Verbesserungen eingepflegt.

Als wesentliche Neuerungen sind dabei der Private Browsing Modus, die nun scheinbar vollständige Implementierung der Java Engine TraceMonkey, WebWorkers für Hintergrundaktionen von JavaScripten sowie die native Unterstützung von JSON.

Leider hat es allerdings für die vollständige Implementierung von HTML und CSS nicht gereicht, so dass der Acid 3 test erneut fehlschlägt, wenn auch erst bei 93/100 Punkten.

Unter mozilla.com steht die neue Version zum Download bereit. Es wird natürlich daraufhin gewiesen, dass es sich um eine Beta Version handelt, die nicht auf produktiven System zum Einsatz kommen sollte. Im Übrigen erwarten uns FireFox Nutzer noch einige RC Versionen, so Mozilla

Ein Tasmanischer Teufel mit aufgesetztem gelben Schnabel der auf den Namen Tuz hört soll während des dreimonatigen Urlaubs des Linux Maskottchens Tux sein Ersatz sein.

Die Entwickler wollen damit darauf Aufmerksam machen, dass der Beutelteufel vom Aussterben durch die Devil Facial Tumour Disease bedroht ist.

Da ich heute selbst das Problem hatte, dachte ich mir ich poste das Ganze hier, vielleicht gibt es ja noch andere Geschädigte Unter PLESK 9.x kann es sein, dass der Backup Manager zum Laden extrem lange braucht. Dies sieht man auch an der Server Load, da ein Prozess namens “pmm-ras” stundenlang vor sich hin nudelt.

Das Problem dürfte dabei im Verzeichnis”/var/lib/psa/dumps/tmp/” zu finden sein. Dort lagen bei mir extrem viele Ordner (rnd 15 000 Stück) in denen scheinbar PLESK Backups abgelegt wurden. Diese werden bei jedem Aufruf des Backupmanagers durchsucht um das Server Repository aufzubauen. Nachdem ich die alten Verzeichnisse dort gelöscht habe, funktioniert alles wieder tadellos