SpamAssassin auf Plesk-Servern ideal einstellen

Vor Kurzem durfte ich mich mal wieder mit Servern beschäftigen, die mittels Plesk gemanaged werden. Plesk verwendet zur Spamfilterung ebenfalls SpamAssassin. Die Standardkonfiguration kann hier durchaus Optimiert werden, denn die Erkennungsrate von Spam ist bei Plesk Servern erst mal recht gering. Doch der Reihe nach:

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.

2 Comments on “SpamAssassin auf Plesk-Servern ideal einstellen

  1. Nachdem ich einige Beiträge von Alexander gelesen habe, war meine Entscheidung klar. Diesen Mann wollte ich kennenlernen und ich schickte ihm kurzerhand eine E-Mail mit der Anfrage, ob er sich einmal unsere Server “zur Brust” nehmen und evt. optimieren könne.

    Wir haben insgesamt 11 VPS Cloud Server (10 WEB und 1 BACKUP-Server alle Ubuntu 16.04 LTS ) und 2 DNS-Server bei Alfahosting und nach einigen Abklärungen fing Alexander an zu “wirken”. Heute sind alle Server optimiert und das Resultat ist schlicht sensationell. Die meisten unserer Kunden haben im Normalfall pro Tag eine SPAM-Nachricht, einige alle 2 Tage eine. Auch andere Problemfälle mit den Mails haben sich ohne Ausnahme erledigt.

    Unser Fazit: Alexander ist wirklich gut, sehr gut sogar. Er weiss, von was er spricht und setzt die Lösungen/Anpassungen auch in unheimlich schneller Zeit um. Wir hoffen, dass er auch in Zukunft ein Auge auf unsere Konfigurationen hat. Herzlichen Dank Alexander für Deine Mithilfe.

    Peter Wäger

  2. Ergänzung zu meinem Kommentar vom 1. Juni 2019 – Unsere Erfahrungen nach 4 Wochen.

    Vorerst einmal: Die Auswirkungen der Konfiguration von Alexander sind ohne Einschränkungen super und sehr empfehlenswert..

    Allerdings haben wir eine Erfahrung gemacht, die eigentlich logisch war, von uns aber gar nicht in Betracht gezogen worden war. Schon nach kurzer Zeit erhielten wir Anrufe von Kunden, (bis heute rund 15), dass einige Ihrer Kunden/Geschäftspartner angerufen hätten, dass Ihre Mailbox nicht erreichbar sei. 🙁 Beispiel: Ein grosser Lieferant für Arbeitskleider aus Deutschland konnte unserem Kunden keine Mails mehr senden. Wir haben uns die Fehlermeldungen zustellen lassen und festgestellt, dass alle Fehlermeldungen identisch waren:
    SMTP error from remote server for RCPT TO command, host:
    ( )reason: 554 5.7.1 Service unavailable; Client host [212.227.15.19] blocked using dnsbl.sorbs.net
    currently Sending Spam See:
    Nur die DNSBLACKLIST war logischerweise nicht immer gleich. Es betraf unter anderem Mails von Servern GMX Schweiz, Bluewin Schweiz, hotmail.com und yahoo.com.

    Wir haben den Kunden folgendes vorgeschlagen
    – Whitelist (nur ungern und in absoluten Einzelfällen)
    – Eine zweite E-Mail-Adresse bei wem auch immer
    – Warten, bis der Server wieder frei wird.

    Die Ueberraschung für uns war, das bis auf einen Kunden, der Pläne nicht mehr erhielt, alle am System nichts ändern wollten. Sie waren durchwegs der Meinung, dass das ein Problem des E-Mail-Sernders sei und nicht ihres. Die Freude über den guten SPAM-Schutz war zu gross!!!

    Wir sind uns bewusst, dass für uns das Problem einfacher zu lösen war als bei einem grossen Provider. Wir haben ausschliesslich Geschäftskunden auf unseren Servern und 90% unserer Kunden beziehen von uns auch noch andere Dienstleistungen wie eigene VPS-Cloud Server, Individual-Software usw.

    Team Udon IT / W-Soft IT

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.