Updated on Mai 8, 2019
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:
Inhaltsverzeichnis
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.
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
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
funktioniert prima. Danke!
Leider wird die /etc/resolv.conf immer wieder überschrieben, so dass unbound immer deaktiviert wird.
Ich nutze Plesk und finde keine Möglichkeit, das Überschreiben zu verhindern.
Hi Konrad, wie oben beschrieben: chattr +i /etc/resolv.conf
Hi, gute Anleitung. Ergänzend die Anmerkung:
Plesk kommt immer mit bind installiert. In vielen Rechenzentren ist ein Nameserver über systemd-resolve eingestellt und das kann an sich auch so bleiben, auch wenn der ein rate-limit für DNSBL hat. Am einfachsten ist es, man legt eine Datei an, unter
/etc/spamassassin/65_dns.cf
mit dem Eintrag
dns_server 127.0.0.1
Dann gehts immer … VG
Super Tipp, Danke!
Bist du Klaus Umland aus Eimsbüttel, mein alter Lehrkollege?
Hallo Alex,
Super Blog, ich scheine etwas zu spät zu kommen … pyzor … -discover gibt es bei mir nicht mehr als befehl.
GeoIp Lite gibt es leider auch nicht mehr, schade aber es wird auch ohne gehen.
Danke für die Tolle Anleitung
“… 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: …”
ExecuteSpamtrain wird tatsächlich mit dem täglichen Plesk Cronjob
/etc/cron.daily/50plesk-daily
aufgerufen (“/opt/psa/admin/plib/DailyMaintainance/script.php”).
Dieses arbeitet die Scripts im Ordner
/opt/psa/admin/plib/DailyMaintainance/Task/
ab, worunter sich wiederum das Skript “ExecuteSpamtrain.php” befindet.
Vielen dank für die Hinweise. Ich bin gespannt was die bringen werden.
Das Script /opt/psa/admin/sbin/spamtrain hat exakt die gleiche Beschränkung, es werden max. 256kb an Mails fürs Training verwendet. Doof ist auch, dass im Gegensatz zu der Anpassung in der /etc/psa/psa.conf das Script bei jedem Update überschrieben wird. Einzige Lösung wäre, den Spamtrain in Plesk zu deaktivieren, eine Kopie vom Script zu machen und einen eigenen Cron dafür zu erstellen.
Hallo,
erstmal vielen Dank für die tolle Anleitung. Ich glaube sie braucht eine Überarbeitung. Bei Pyzor gibt es discover nicht mehr und das extremeshock plugin ist wohl seit SA 3.4.2 implementiert. Es wäre toll wenn du das nochmal umsetzen könntest.
LG
Pingback: SpamAssassin optimieren – wiki.schoppe.it