Die meisten Tipps meines Artikels “SpamAssassin Erkennungsrate (deutlich) verbessern” sind auch für Plesk-Server interessant. Bei einigen Details muss man jedoch aufpassen, da Plesk gerne Konfigurationsdateien überschreibt und auch “Eigenkonsktrukte” einbaut. So ist z.B. der LDA (Local Delivery Agent) meines Wissens nach eine Eigenentwicklung von Plesk. Mit folgenden Maßnahmen habe ich gute Ergebnisse erzielt:

Verwendet einen lokalen Resolver

Wie ich bereits im Hauptartikel “SpamAssassin Erkennungsrate (deutlich) verbessern” näher erklärt habe, ist der wichtigste Schritt, einen lokalen DNS-Resolver zu verwenden. Die voreingestellten DNS-Server sind häufig bei vielen DNSBLs auf der Blacklist. Deshalb klappen viele Checks von SpamAssassin nicht und die Erkennungsrate von Spam lässt deshalb zu Wünschen übrig. Bei Ubuntu 16.04 reicht es aus, unbound zu installieren und diesen anschließend in der resolv.conf einzutragen.

apt update 
apt install unbound
nano /etc/resolv.conf
  # vorhandene DNS-Server auskommentieren
  # nameserver x.x.x.x
  # nameserver y.y.y.y

  # eigenen DNS-Resolver eintragen
  nameserver 127.0.0.1

Mehr sollte nicht nötig sein. Ich halte übrigens nichts davon, die zuvor eingestellten Nameserver weiterhin als “Backup” eingetragen zu lassen. Soweit mir bekannt schickt Linux DNS-Requests immer an alle DNS-Server gleichzeitig und verwendet dann die Antwort, die am schnellsten eingetroffen ist. Damit schießt man sich mitunter ins eigene Knie, wenn die externen Server Einträge bereits im Cache haben, die der lokale Unbound erst noch auflösen muss.

Zusatztipp: Bei OpenVZ-Basierten Servern wird die Datei /etc/resolv.conf bei jedem Boot mit der vom Provider gesetzten Standardkonfiguration überschrieben. Der Fehler passiert schnell und bleibt häufig unbemerkt. Bis auf den Umstand, dass noch immer viel Spam durchkommt. Im Zweifel Server durchbooten und prüfen, ob die Datei durch den Boot modifiziert wurde.

Abhilfe schafft hier das Sperren der Datei, sodass noch nicht mal mehr Root Schreibzugriff hat:

chattr +i /etc/resolv.conf

Falls man die Datei irgendwann wieder bearbeiten möchte, muss man sie zuvor mit dem Flag -i wieder entsperren.

Ich habe die Erfahrung gemacht, dass Plesk-basierte Server manchmal von Haus aus einen Bind9 DNS Server installiert haben, der bereits korrekt konfiguriert ist. Auch, wenn in den Service-Einstellungen von Plesk der “DNS-Service” deaktiviert ist. In einem Fall war der Service jedoch nach einem Neustart nicht mehr verfügbar. Deshalb habe ich mich lieber nicht drauf verlassen und Bind9 kurzerhand deaktiviert:

netstat -tulpen | grep :53 #check, ob ein Daemon auf Port 53 lauscht. Falls es named (Bind9) ist:
systemctl stop bind9.service
systemctl disable bind9

Verwendet Pyzor und Razor

Auch hier ist die Konfiguration nahezu identisch mit meiner Vorgehensweise aus dem Hauptartikel. Deswegen liste ich hier nur kurz die Kommandos für Ubuntu 16.04 auf:

# Zunächst installieren:
apt install pyzor razor

# Pyzor und Razor initialisieren:
pyzor --homedir /etc/mail/spamassassin discover
mkdir /etc/spamassassin/.razor
sudo razor-admin -home=/etc/spamassassin/.razor -register
sudo razor-admin -home=/etc/spamassassin/.razor -create
sudo razor-admin -home=/etc/spamassassin/.razor -discover

# Anpassungen in einer neuen Datei vornehmen.
# Wichtig: nicht in /etc/spamassassin/local.cf eintragen (wie in meinem Hauptbeitrag gezeigt)
# da diese Datei bei Plesk-Updates überschrieben werden könnte.

nano /etc/spamassassin/99_pyzor_razor.cf
	use_pyzor 1
	pyzor_options --homedir /etc/mail/spamassassin
	pyzor_path /usr/bin/pyzor
	use_razor2 1
	razor_config /etc/mail/spamassassin/.razor/razor-agent.conf

    # Anpassung der Scores, wie ich ebenfalls im Hauptartikel erläutere
	score RCVD_IN_BL_SPAMCOP_NET 0 5.246 0 5.347
	score RCVD_IN_BRBL_LASTEXT 0 5.246 0 5.347
	score URIBL_BLACK 0 5.7 0 5.7
	score URIBL_WS_SURBL 0 2.659 0 2.608
	score URIBL_MW_SURBL 0 2.263 0 2.263
	score URIBL_CR_SURBL 0 2.263 0 2.263
	score URIBL_GREY 0 2.084 0 1.424
	score URIBL_DBL_SPAM    0 4.5 0 4.5
	score URIBL_DBL_PHISH   0 4.5 0 4.5
	score URIBL_DBL_MALWARE 0 4.5 0 4.5
	score URIBL_DBL_BOTNETCC 0 4.5 0 4.5
	score URIBL_DBL_ABUSE_SPAM 0 4.0 0 4.0
	score URIBL_DBL_ABUSE_PHISH 0 4.5 0 4.5
	score URIBL_DBL_ABUSE_MALW  0 4.5 0 4.5
	score URIBL_DBL_ABUSE_BOTCC 0 4.5 0 4.5

Installiert das extremeshok-Plugin nach

Auch hier zeige ich nur die Kommandos und verweise auf den Hauptartikel.

cd /tmp
wget https://github.com/extremeshok/spamassassin-extremeshok_fromreplyto/archive/1.3.1.tar.gz
tar -zxvf 1.3.1.tar.gz
cd spamassassin-extremeshok_fromreplyto-1.3.1/
mkdir /etc/mail/spamassassin/plugins/
cp plugins/* /etc/mail/spamassassin/plugins/
cp 01_extremeshok_fromreplyto.cf /etc/mail/spamassassin
systemctl restart spamassassin.service

Verwendet zusätzliche Regeln

Um die Regeln von Heinlein Support nachzuinstallieren, habe ich auf Basis des original Cron-Scripts eine Variante dafür gebastelt. Dieses Script kann auch zur initialen Installation verwendet werden. Wenn es unter /etc/cron.daily liegt und ausführbar ist, führt es Ubuntu ab sofort selbständig aus.

nano /etc/cron.daily/61sa-update-heinlein

	#!/bin/bash

	sa_update()
	{
	        /usr/bin/sa-update --nogpg --channel spamassassin.heinlein-support.de
	        local rc="$?"
	        case $rc in
	                # Only restart spamd if sa-update returns 0, meaning it updated the rules
	                0) env PATH=/opt/psa/admin/sbin:/usr/local/psa/admin/sbin:$PATH spammng --condrestart ;;
	                # If sa-update returns 1 then there are no updates
	                1) exit 0 ;;
	        esac
	        return $rc
	}

	sa_update >> /var/log/sa-update.log 2>&1
	exit 0

# Datei ausführbar machen
chmod +x /etc/cron.daily/61sa-update-heinlein

# Einmal händisch ausführen, sodass die Regeln heruntergeladen werden
/etc/cron.daily/61sa-update-heinlein

# Und zum Schluss SpamAssassin durchstarten.
systemctl restart spamassassin.service

Lasst Plesk SpamAssassin trainieren

Plesk liefert praktischerweise eine eigene Funktion mit, die den SpamAssassin Bayes-Filter anhand der sich bereits in den Mailboxen befindlichen Mails trainiert. Dabei werden alle gelesenen Mails im Posteingang als “Ham” gelernt, alle Mails im Spam-Ordner hingegen als “Spam”. Die Besonderheit der Funktion ist, dass jede Mailbox seine eigene Bayes-Datenbank benutzt. Das lässt sich meines Wissens auch nicht (ohne großen Aufwand) ändern.

Ein Userbasiertes Training ist auf der einen Seite super, da es sehr genau ist und keine Probleme durch anderer User Mails entstehen können. Auf der anderen Seite werden für das Training eine Menge Mails benötigt. Diese Mails muss jeder Benutzer selbst im Postfach haben, sonst bleibt der Bayes-Filter für dasjenige Postfach einfach deaktiviert. Ich glaube erst nach 200 gelernten Ham-Mails und zusätzlich 200 gelernten Spam-Mails aktiviert sich das Bayes-Modul.

Laut der (etwas widersprüchlichen) Online-Hilfe von Plesk wird das Modul wohl nicht selbständig gestartet, deshalb habe ich vorsichtshalber ein Script unter /etc/cron.daily platziert:

nano /etc/cron.daily/80-spamtrain
	#!/bin/bash
	echo "spamtrain started at $(date)" >> /var/log/spamtrain.log
	plesk daily ExecuteSpamtrain >> /var/log/spamtrain.log 2>&1
	exit 0

# Datei ausführbar machen
chmod +x /etc/cron.daily/80-spamtrain

# Und einmal händisch laufen lassen
/etc/cron.daily/80-spamtrain

Setzt die max. Mailgröße hoch

Plesk ist im Standard so eingestellt, dass nur Mails bis zu einer Größe von 256kb überhaupt durch SpamAssassin überprüft werden. Größere Mails werden überhaupt nicht geprüft und landen direkt im Posteingang. Ein gefundenes Fressen für Spam-Mails mit größeren Bildern.

Entlarven kann man solche Mails an den fehlenden SpamAssassin-Zeilen im Mail-Header. Ich habe daher die maximale Dateigröße auf 15MB hochgesetzt, da jede Mail durch SpamAssassin geprüft werden soll, auch wenn das mehr Ressourcen kostet:

nano /etc/psa/psa.conf
	# folgenden Wert suchen und anpassen, sollte ganz unten in der Datei sein
	SA_MAX_MAIL_SIZE 15728640

Das waren meine Tipps, um die Spam-Erkennungsrate von SpamAssassin auf Plesk-Servern wesentlich zu steigern. Falls Ihr noch weitere Tipps auf Lager habt, lasst sie mich gerne in den Kommentaren wissen.

Der Beitrag SpamAssassin auf Plesk-Servern ideal einstellen erschien zuerst auf SYN-FLUT.de.