Seit etwa 2015 weht frischer Wind im Bereich Open-Source Spamfilter für Linux. Lange Zeit gab es im Prinzip nur SpamAssassin. Eine millionenfach bewährte Software, die zuverlässig ihren Job tut. Auch ich war nach einigen Optimierungen damit sehr zufrieden. Dennoch kann ich mir gut vorstellen, dass Rspamd in den nächsten Jahren hier stark Marktanteile übernehmen wird. Warum?

Rspamd ist super einfach zu implementieren

Es integriert sich sehr einfach in viele verschiedene MTAs. Nach der Installation von Rspamd ist in Postfix genau eine Zeile Konfiguration notwendig:

smtpd_milters = inet:localhost:11332

Und schon ist Postfix um einen Spamfilter erweitert. Jedoch nicht *nur* um einen Spamfilter:

Rspamd ersetzt alles andere

Früher verwendete ich neben SpamAssassin für die reine Spamfilterung noch Postgrey fürs Greylisting, OpenDKIM für das Hinzufügen von DKIM-Signaturen und Amavis für die Anbindung von Virenscannern an Postfix.

All das kann Rspamd von Haus aus. Und noch viel mehr.

Rspamd wird als milter in den MTA integriert, deshalb bekommt Rspamd jeden Status des Mailempfangs mit und kann zu jedem Zeitpunkt manipulativ eingreifen oder dem MTA mitteilen, er möge die Mail temporär (Greylist) oder dauerhaft ablehnen.

Rspamd ist die modernere Software

Der Kern ist in C geschrieben, die Module in Lua. Zusätzlich kann Redis als Key-Value Datenbank im Backend verwendet werden.

Tipp: Redis sollte auch in jedem Fall als Backend Datenbank verwendet werden, sonst bleiben viele Features (z.B. Greylisting, Rate Limiting, Neuronales Netzwerk, u.v.m) deaktiviert. Ich schreibe demnächst hier einen Beitrag, wie eine Rspamd Installation um Redis erweitert werden kann. Dadurch kann die Rspamd Erkennungsrate wesentlich verbessert werden.

Außerdem bringt es ein schickes Webinterface mit vielen nützlichen Statistiken mit.

Die Entwickler arbeiten stark an der Weiterentwicklung von Rspamd. Es wird immer nur die aktuellste Version unterstützt. Außerdem wollen die Entwickler Anpassungen durch die Linux-Distributionen vermeiden. Die Installation erfolgt üblicherweise über ein 3rd-Party-Repository direkt von Rspamd, sodass automatisch immer die aktuellste Version installiert ist.

Rspamd ist schnell

Laut der offiziellen Webseite wurde Rspamd von Anfang an auf Geschwindigkeit hin optimiert und benötigt nur ein Bruchteil der Ressourcen im Vergleich zu SpamAssassin. Das ist für mich persönlich jedoch weniger wichtig, so viele Mails gehen bei meinen Servern nicht durch, als das ich hier ein Unterschied merken würde.

Rspamd filtert überragend

Nach meiner Migration zu Rspamd vor circa einen Monat kam bis heute tatsächlich keine einzige Spam-Mail mehr durch. Auf die Konfiguration gehe ich im nächsten Artikel näher ein.

Rspamd wird immer bekannter

Aktuell ist die Software noch etwas unbekannt. Sie hat z.B. noch keinen Wikipedia-Artikel. Dennoch merke ich einen starken Zulauf, vor allem in den letzten zwei Jahren. Zum Beispiel berichtete kürzlich die Freak Show darüber. Außerdem verwendet Christoph Haas in seinem bekannten und seit vielen Jahren bewährtem Mailserver-Tutorial ISPMail nun ebenfalls Rspamd. Selbiges macht auch Thomas Leister im nicht weniger guten Tutorial von ihm. Deutlich wird der Trend auch auf Google Trends:

Weitere Informationen

Findet ihr neben dem offiziellen Quick-Start-Guide auch in einer sehr guten Präsentation von Heinlein Support.

Der Beitrag Rspamd, das bessere SpamAssassin erschien zuerst auf SYN-FLUT.de.

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.

Im Folgenden beschreibe ich, wie bereits mit Postfix Antispam Maßnahmen eingeführt werden können. Dazu habe ich die relevanten Ausschnitte der Postfix Konfigurationsdatei /etc/postfix/main.cf beigefügt. Wichtig ist mir hierbei, dass die unten aufgeführten Einstellungen keineswegs einfach per Copy&Paste übernommen werden sollten. Die Konfiguration funktioniert bei mir sehr gut, trotzdem solltet ihr genau wissen, was ihr tut.

Die Konfiguration wurde unter Ubuntu 14.04 (Postfix 2.11) erstellt und getestet. Seit Postfix 2.10 wird für das (authentifizierte) Relayen von Mails die Konfiguration unter smtpd_relay_restrictions verwendet. In früheren Versionen wurden die Einstellungen unter smtpd_recipient_restrictions verwendet, was manchmal zu komischem Verhalten führte. Weitere Informationen dazu gibt es auf der Postfix Homepage.

Die Konfiguration

smtpd_sender_restrictions =
  permit_mynetworks,
  permit_sasl_authenticated,
  reject_unknown_sender_domain,
  reject_non_fqdn_sender
smtpd_recipient_restrictions =
  permit_mynetworks,
  permit_sasl_authenticated,
  reject_unauth_destination,
  reject_unauth_pipelining,
  check_client_access hash:/etc/postfix/client_checks,
  check_sender_access hash:/etc/postfix/sender_checks,
  reject_unknown_helo_hostname,
  reject_invalid_hostname,
  reject_non_fqdn_hostname,
  reject_non_fqdn_recipient,
  permit_dnswl_client list.dnswl.org,
  reject_rbl_client ix.dnsbl.manitu.net,
  reject_rbl_client zen.spamhaus.org,
  reject_rbl_client b.barracudacentral.org,
  reject_rbl_client bl.spamcop.net,
  reject_rbl_client psbl.surriel.com,
  reject_rbl_client noptr.spamrats.com,
  reject_rbl_client dyna.spamrats.com,
  reject_rbl_client dnsbl.sorbs.net

Die Einstellungen im Detail

smtpd_sender_restrictions

Hier wird Postfix mitgeteilt, welche Checks während des “MAIL FROM” Kommandos auszuführen sind. Alle weiteren Checks werden top-down, also von oben nach unten durchgeführt. Sobald ein Check anschlägt, sei es permit oder reject, wird diese Kette verlassen und keine weiteren Checks werden durchgeführt.

Mittels permit_mynetworks und permit_sasl_authenticated werden Mails von vertrauenswürdigen Netzen und authentifizierten Benutzern in jedem Fall durchgelassen.

Durch die Befehle reject_unknown_sender_domain sowie reject_non_fqdn_sender wird erstmal geprüft, ob der sendende MTA zumindest die RFC Basics eingehalten hat. Also ob hinter der Domain ein DNS A-Record steckt und ob es einen FQDN gibt.

smtpd_recipient_restrictions

Hier passiert die eigentliche “Magie”. Seit Postfix 2.10 und der Einführung der smtpd_relay_restrictions bin auch ich dazu übergegangen, eigentlich alle Checks hier aufzuführen. Genauere Informationen darüber gibt es auf der Postfix Website.

Die Einstellungen permit_mynetworks und permit_sasl_authenticated bewirken das Gleiche wie oben. Danach wird es interessanter. Der Punkt reject_unauth_destination ist vermutlich der wichtigste Befehl. Er legt fest, dass unauthentifizierte Benutzer nur Mails an die eigenen Domains senden dürfen und somit kein Open Relay entsteht.

RFC-Konforme Checks

Mittels check_client_access und check_sender_access könnten Whitelists erstellt werden. Dies kann hin und wieder nützlich sein, z.B. wenn fremde, legitime Mailserver falsch konfiguriert sind.

Die Punkte reject_unknown_helo_hostname und reject_invalid_hostname prüft, ob der Host im HELO einen (gültigen) DNS A oder MX Record hat. Falls nicht, wird die Mail abgelehnt.

Zu guter Letzt wird mittels reject_non_fqdn_hostname und reject_non_fqdn_recipient noch geprüft, ob die Empfängerdomain im FQDN-Format vorliegt. Also wieder ziemliche “Basics”. Trotzdem helfen diese Regeln, schon mal recht viele Mails von schlecht konfigurierten SPAM Mailservern abzulehnen.

Whitelist

Vor den ganzen DNSBLs habe ich einen Check zur bekannten Whitelist dnswl.org eingebaut. Falls eine sendende IP dort gelistet ist, durchläuft sie nicht die weiteren Checks der ganzen Blacklists. Dadurch kann ich etwas restriktivere Blacklists verwenden, ohne gleich Gefahr zu laufen, dass zu viele false-positives auftreten könnten. Hin und wieder sind beispielsweise einzelne IPs von United Internet (GMX und Co.) auf der Sorbs Blacklist gelistet. Da GMX aber in der Whitelist gelistet ist, brauche ich mir darüber keine Gedanken zu machen. Ich kann auch jedem Mailserver-Administrator empfehlen, sich dort auf dieser Whitelist einzutragen.

Postfix kann die DNS Whitelist ab Version 2.8 direkt mit dem Kommando permit_dnswl_client list.dnswl.org abfragen.

Blacklist

Der Befehl reject_rbl_client frägt die jeweilige DNS Blacklist ab und lehnt die Mail ab, wenn eine der Blacklists einen gelisteten Eintrag zurückgibt. Ich habe mich für die oben genannten acht Stück entschieden. Sie existieren allesamt relativ lange und waren bisher sehr zuverlässig. Hier sollte trotzdem regelmäßig ein Review stattfinden, denn manche DNSBLs geben, wenn sie eines Tages out-of-service gehen, immer “listed” zurück. Folglich würden dann alle Mails abgelehnt werden.

Der Beitrag Mit Postfix SPAM blockieren erschien zuerst auf SYN-FLUT.de.

Zusätzliche Signaturen

Die offiziellen Signaturen von ClamAV sind meiner Meinung nach nicht die besten. Auch Wochen nach bekanntwerden von Locky, erkannte ClamAV in meinem Test diesen Virus nicht. Fast wollte ich ClamAV wieder deinstallieren, dann jedoch habe ich nach zusätzlichen Signaturen gesucht. Das Ergebnis kann sich absolut sehen lassen. In meinem Test wurden alle Viren, die vorher durchflutschten, zuverlässig erkannt. Bisher gabs kein False-Positive, aber auch kein False-Negative.

Der große Nachteil an der Sache ist, dass ClamAV mit zusätzlichen Signaturen ein echter Speicherfresser ist. Bei mir verbraucht ClamAV knapp 800MB RAM.

Am einfachsten gelingt die Installation zusätzlicher Signaturen mit dem ClamAV Unofficial Signatures Updater, der auf Github von “extremeshok” weiter entwickelt wird. Die Installation ist dort super beschrieben und in wenigen Minuten erledigt. In der Konfiguration kann man verschiedene Quellen angeben, von welchen die Signaturen bezogen werden. Einige davon funktionieren nur mit vorheriger Registrierung. Ich habe mich mal bei allen angemeldet.

Wenn ich die Installation allerdings nochmal machen würde, würde ich auf diesen Schritt verzichten und nur die Signaturen von SaneSecurity beziehen, welche ohne Anmeldung geladen werden können. Bisher wurden alle gefundene Viren anhand Signaturen von SaneSecurity erkannt. Dadurch kann man sicherlich auch eine Menge RAM sparen.

Von folgenden Quellen ladet das Tool automatisiert die Signaturen runter und hält sie aktuell:

• SaneSecurity (ohne vorherige Anmeldung)
• SecuriteInfo
• Linux Malware Detect
• Malware Patrol

Wie gesagt, die Installation ist auf der Github Page von extremeshok super beschrieben, deswegen verzichte ich an dieser Stelle auf ein HowTo.

PS: ich seh grad, extremeshok hat auch ein SpamAssassin Plugin geschrieben. Vielleicht teste ich das demnächst mal.

Der Beitrag ClamAV Erkennungsrate verbessern erschien zuerst auf SYN-FLUT.de.

Einleitung

SpamAssassin ist ein sehr bekanntes und ausgezeichnetes Programm, das anhand von verschiedensten Tests jeder E-Mail einen “Score” zuweist. Je höher diese Punktzahl ist, desto wahrscheinlicher handelt es sich bei der Mail um SPAM.

Ich habe meine Mailserver alle auf Basis der sehr guten Anleitung von Christoph Haas (workaround.org) konfiguriert. Christoph schreibt diese Tutorials schon sehr lange, ich glaube ich habe um 2006 herum meinen ersten Server danach aufgesetzt.

Im Rahmen des Tutorials wird auch SpamAssassin installiert und aktuell direkt, früher mittels Amavis an Postfix angebunden. Ich bevorzuge nach wie vor die Anbindung über Amavis, da ich gerne auch ClamAV als Virenscanner einsetze. Die Erkennungsrate von ClamAV ist erstmal recht gering, auch hier können wir noch einiges rausholen. Dazu werde ich demnächst noch einen Beitrag schreiben.

Verwendet einen eigenen DNS Resolver

Zu Beginn gleich der vielleicht wichtigste Tipp, wie die SpamAssassin Erkennungsrate deutlich verbessert werden kann. SpamAssassin benutzt für viele dieser Tests sogenannte DNS Blacklists (DNSBL). Diese werden verwendet, um z.B. die IP-Adressen der SMTP Relays abzugleichen, oder auch um in der Mail enthaltene Links zu prüfen. Falls eine Domain in einem solchen Link in einer DNSBL bekannt ist, erhöht SpamAssassin folglich den Score und die Mail kann besser klassifiziert werden. Im umgedrehten Fall wird bei vertrauenswürdigen Links der Score verringert, somit sinkt auch die Chance auf eine fälschlicherweise als Spam markierte Mail.

Viele dieser DNSBLs arbeiten nach dem Freemium Prinzip, d.h. für kleinere Mailserver ist deren Benutzung kostenfrei, bei größeren Mailserver-Installationen verkaufen die Provider dieser Listen entsprechende Zugänge. Da die Listen DNS-Basiert arbeiten, wird also die Quell-IP des anfragenden DNS-Servers getrackt und limitiert.

Wenn euer Mailserver einen bekannten öffentlichen DNS-Server verwendet (z.B. Google DNS), frägt ja letztlich dieser DNS-Server bei der Liste nach. Da diese DNS-Server von vielen tausenden Benutzern verwendet werden, laufen sie schnell in das Rate-Limit der DNSBL-Provider.

Ersichtlich wird es im E-Mail Header, wenn SpamAssassin dort den Check URIBL_BLOCKED listet. Dieser wird mit 0.001 Punkten gewertet und soll nur ein Hinweis auf genau dieses Problem sein.

Abhilfe schafft die Verwendung eines eigenen (Caching) DNS-Resolvers. Dadurch frägt euer eigener DNS-Server bei den DNSBLs an und die Anfrage geht durch. Ich habe hier beschrieben, wie unter Ubuntu 14.04 bind als Caching DNS-Resolver installiert wird: Caching DNS-Resolver mit bind9

Allein diese Maßnahme hat die SpamAssassin Erkennungsrate bei mir deutlich verbessert.

Trainiert die Bayes-Datenbank

Auch mit folgendem Tipp kann die SpamAssassin Erkennungsrate verbessert werden. Das Programm verwendet eine integrierte Bayes-Datenbank, um Textphrasen zu klassifizieren und zu bewerten. Damit das Ganze funktioniert, muss diese Datenbank zunächst trainiert werden. Wichtig ist, dass der richtige Pfad zur Datenbank angegeben wird, sonst landet das ganze im .spamassassin Ordner des jeweiligen Benutzers. Dort schaut SpamAssassin (meines Wissens) allerdings nicht nach, wenn es über Amavis oder den spamd aufgerufen wird.

Spam Mail Quelle

Für das “Training” sind eine Menge Mails notwendig. Um genug Spam Mails zu bekommen, habe ich das aktuellste Monatsarchiv von http://untroubled.org/spam/ verwendet. Dieses habe ich mittels wget heruntergeladen, entpackt und anschließend das Tool sa-learn auf die Mails losgelassen. Falls SpamAssassin nicht über Amavis eingebunden ist, muss der Datenbank-Pfad angepasst werden.

Anschließend verfüttere ich auch noch alle Mails im “Junk” Ordner aller Postfächer an sa-learn

cd /tmp
wget http://untroubled.org/spam/2016-03.7z
7z x 2016-03.7z
sudo sa-learn --dbpath /var/lib/amavis/.spamassassin --progress --spam /tmp/2016/03
sudo sa-learn --dbpath /var/lib/amavis/.spamassassin --progress --spam /var/vmail/*/*/Maildir/.Junk

“Gute” Mails

Die Bayes-Datenbank sollte natürlich auch erwünschte Mails zu Gesicht bekommen. Hierzu verwende ich einfach alle gelesene Mails, die in allen vorhandenen Postfächern vorhanden sind.

sa-learn --dbpath /var/lib/amavis/.spamassassin --progress --ham /var/vmail/*/*/Maildir/cur

Dies kann (und sollte) man selbstverständlich via Cron-Job automatisieren.

Verwendet zusätzliche Signaturen

Peer Heinlein von Heinlein Support ist der Mann hinter mailbox.org – einem sicherlich nicht ganz unbekannten E-Mail Anbieter. Freundlicherweise stellt er kostenlos die von seinem Team entwickelten und beinahe täglich aktualisierten SpamAssassin Rulesets zur Verfügung. Eine Anleitung zum Einbinden in ein Debian/Ubuntu System findet ihr auf seinem Blog.

Im Wesentlichen werden diese Signaturen mittels dem bereits vorhandenen Cron-Job, der die SpamAssassin-eigenen Rulesets aktualisiert, zusätzlich geladen. Der Vollständigkeit halber anbei die modifizierte Version des Cron Bash-Scripts, unter Ubuntu 14.04 muss sie nach /etc/cron.daily/spamassassin. Die modifizierten Zeilen habe ich markiert. Neben dem eigentlichen Download prüft mein Script noch die Returncodes von beiden sa-update aufrufen. Wenn nur einer von beiden Aufrufen neue Signaturen gebracht hat, wird spamd bzw. Amavis neu gestartet. Ich habe diesen Code-Schnipsel (Zeile 70-76) aus den Kommentaren von o.g. Blog. Ist ziemlich quick’n’dirty, aber funktioniert für meine Ansprüche.

#!/bin/sh

# Duncan Findlay
# duncf@debian.org

# Daily cronjob for SpamAssassin updates. This isn't pretty but it
# should do the job.

CRON=0

test -f /etc/default/spamassassin && . /etc/default/spamassassin

test -x /usr/bin/sa-update || exit 0
test -x /etc/init.d/spamassassin || exit 0

if [ "$CRON" = "0" ] ; then
exit 0
fi

# If there's a problem with the ruleset or configs, print the output
# of spamassassin --lint (which will typically get emailed to root)
# and abort.
die_with_lint() {
su - debian-spamd -c "spamassassin --lint -D 2>&1"
exit 1
}

do_compile() {
# Compile rules if the required tools are available. Prior to version
# 3.3.2-8, there was an additional check to verify that an sa-compile
# run had previously been executed by hand. With sa-learn now
# distributed in a separate, optional, package, this check is no
# longer necessary.
if [ -x /usr/bin/re2c -a -x /usr/bin/sa-compile ]; then
su - debian-spamd -c "sa-compile --quiet"
# Fixup perms -- group and other should be able to
# read and execute, but never write. Works around
# sa-compile's failure to obey umask.
chmod -R go-w,go+rX /var/lib/spamassassin/compiled
fi
}

# Tell a running spamd to reload its configs and rules.
reload() {
# Reload
if which invoke-rc.d >/dev/null 2>&1; then
invoke-rc.d spamassassin reload > /dev/null
else
/etc/init.d/spamassassin reload > /dev/null
fi
if [ -d /etc/spamassassin/sa-update-hooks.d ]; then
run-parts --lsbsysinit /etc/spamassassin/sa-update-hooks.d
fi
}

# Sleep for up to 3600 seconds
RANGE=3600
number=`od -vAn -N2 -tu4 < /dev/urandom`
number=`expr $number "%" $RANGE`
sleep $number

# Update
umask 022
su - debian-spamd -c "sa-update --gpghomedir /var/lib/spamassassin/sa-update-keys"
retcode1=$?
su - debian-spamd -c "sa-update --nogpg --channel spamassassin.heinlein-support.de"
retcode2=$?

if [ $retcode1 -eq 0 ] || [ $retcode2 -eq 0 ]; then
retcode=0
elif [ $retcode1 -eq 2 ] || [ $retcode2 -eq 2 ]; then
retcode=2
else
retcode=$retcode2
fi

case $retcode in
0)
# got updates!
su - debian-spamd -c "spamassassin --lint" || die_with_lint
do_compile
reload
;;
1)
# no updates
exit 0
;;
2)
# lint failed!
die_with_lint
;;
*)
echo "sa-update failed for unknown reasons" 1>&2
;;
esac

Wenn alles funktioniert hat, müssten unter /var/lib/spamassassin/<version>/ einige Dateien mit “heinlein” im Namen liegen. Das sind die eigentlichen Rulesets. Anhand des Zeitstempels kann auch überprüft werden, wann das letzte Update kam.

Verwendet Pyzor und Razor

Pyzor und Razor sind Prüfsummenbasierte Netzwerke, um SPAM zu erkennen. Dabei wird eine Prüfsumme vom Body der erhaltenen Mail gebildet und an die Pyzor oder Razor Server gesendet. Falls die Prüfsummen von vielen Benutzern identisch sind (d.h. der Mailtext ist gleich), ist die Wahrscheinlichkeit, dass es sich bei der Mail um SPAM handelt höher.

Pyzor

Achtung: Pyzor verwendet den Port TCP 24441 für ausgehende Verbindungen zum Pyzor Server. Falls eine Firewall ausgehende Verbindungen blockiert, muss dieser Port entsprechend freigeschaltet werden. Folgende Schritte sind notwendig, um Pyzor unter Ubuntu 14.04 einzubinden:

sudo apt-get install pyzor
pyzor --homedir /etc/mail/spamassassin discover

Nun muss das noch SpamAssassin mitgeteilt werden. Dazu muss die Datei /etc/spamassassin/local.cf wie folgt editiert werden:

# die nächste Zeile dürfte schon auf 1 stehen. Falls nicht, dann anpassen.
use_pyzor               1
# die nächste Zeile kommt ans Ende der Datei
pyzor_options --homedir /etc/mail/spamassassin

Danach noch SpamAssassin oder Amavis neu starten, dann war’s das schon. Getestet werden kann es wie folgt:

cat /pfad/zu/ner/mail | spamassassin -D pyzor 2>&1 | less

Der Output sollte wie folgt aussehen:

Apr 1 14:40:43.038 [17306] dbg: pyzor: network tests on, attempting Pyzor
Apr 1 14:40:46.625 [17306] dbg: pyzor: pyzor is available: /usr/bin/pyzor
Apr 1 14:40:46.626 [17306] dbg: pyzor: opening pipe: /usr/bin/pyzor check < /tmp/.spamassassin17306kiOe9Ytmp
Apr 1 14:40:47.528 [17306] dbg: pyzor: [17308] finished: exit 1
Apr 1 14:40:47.528 [17306] dbg: pyzor: got response: public.pyzor.org:24441 (200, 'OK') 0 0

Razor

So wird Razor unter Ubuntu 14.04 installiert und konfiguriert:

sudo apt-get install 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

entsprechend muss analog zu Pyzor wieder die Datei /etc/spamassassin/local.cf angepasst werden:

# die nächste Zeile dürfte schon auf 1 stehen. Falls nicht, dann anpassen.
use_razor               1
# die nächste Zeile kommt ans Ende der Datei
razor_config /etc/mail/spamassassin/.razor/razor-agent.conf

Hier wüsste ich leider keinen Weg, wie man die Funktion von Razor direkt testen kann. Jedenfalls müsste ab jetzt der SpamAssassin Test RAZOR2_CHECK in Mails auftauchen. Überprüft werden kann das (nach ein paar Tagen) wie folgt:

grep -R RAZOR /pfad/zu/den/mails

Filtert nach Ländern

SpamAssassin bringt ein Plugin namens RelayCountry mit, mit welchem es möglich wird, die Länder der einzelnen SMTP Relays anhand der GeoIP Information zu bestimmen. Dies dient zum einen der Bayes-Datenbank. Sie bekommt also zusätzliche Informationen und wird künftig selbständig lernen, aus welchen Ländern viel Spam kommt. Ich habe bei mir noch “händische” Regeln hinzugefügt: Wenn eine Mail z.B. durch einen SMTP-Server in Vietnam relayed wurde, bekommt sie in meinem Fall zwei Punkte. Dieser Schritt hat auch nochmal gut geholfen, die SpamAssassin Erkennungsrate zu verbessern.

Folgende Schritte sind unter Ubuntu 14.04 als Vorbereitung notwendig:

apt-get install libgeo-ip-perl
mkdir /usr/share/GeoIP
wget http://geolite.maxmind.com/download/geoip/database/GeoLiteCountry/GeoIP.dat.gz
wget http://geolite.maxmind.com/download/geoip/database/GeoIPv6.dat.gz
gunzip GeoIP.dat.gz
gunzip GeoIPv6.dat.gz
mv GeoIP.dat /usr/share/GeoIP/
mv GeoIPv6.dat /usr/share/GeoIP/

Damit wurde das notwendige Perl-Modul installiert, sowie mit der aktuellen GeoIP-Lite Datenbank von MaxMind ausgestattet. Das Plugin wird in der Datei /etc/spamassassin/init.pre aktiviert, dazu wird das Kommentarzeichen vor folgender Zeile entfernt:

loadplugin Mail::SpamAssassin::Plugin::RelayCountry

Jetzt können noch eigene Regeln geschrieben werden, um Mails aus bestimmten Ländern abzuwerten. Dazu muss ans Ende von /etc/spamassassin/local.cf folgendes:

ifplugin Mail::SpamAssassin::Plugin::RelayCountry
add_header all Relay-Country _RELAYCOUNTRY_
header RELAYCOUNTRY_BAD X-Relay-Countries =~ /(CN|RU|UA|RO|VN)/
describe RELAYCOUNTRY_BAD Relayed through spammy country at some point
score RELAYCOUNTRY_BAD 2.0

header RELAYCOUNTRY_GOOD X-Relay-Countries =~ /^(DE|AT|CH)/
describe RELAYCOUNTRY_GOOD First untrusted GW is DE, AT or CH
score RELAYCOUNTRY_GOOD -0.5
endif # Mail::SpamAssassin::Plugin::RelayCountry

Damit bekommt jede Mail, die durch ein SMTP-Relay in China, Russland, Ukraine, Rumänien oder Vietnam geroutet wurde, automatisch zwei Punkte. Im Gegenzug ziehe ich 0,5 Punkte ab, wenn das letzte Relay in Deutschland, Österreich oder der Schweiz stand.

Damit lässt sich das Ganze auch gut testen. Nach einem Neustart von SpamAssassin oder Amavis sollte bei jeder Mail, die aus Deutschland eintrudelt, folgender Check im Header stehen:

Im Gegenzug bei Mails aus den o.g. Ländern:

Verwendet zusätzliche Plugins

Ich habe kürzlich ein gutes SpamAssassin Plugin von eXtremeSHOK gefunden, welches die “From” und “Reply-To” Header vergleicht. Gibt es dort Unterschiede, bekommt die Mail direkt ein paar Punkte. Je nachdem, ob sich auch die Domain unterscheidet, sind es zwei bzw. direkt fünf Punkte. Bei meinem Test ist mir oft aufgefallen, dass bei Spam-Mails hier unterschiedliche Domains verwendet werden. Diesen Tipp habe ich persönlich erst zum Schluss entdeckt und eingebaut. Seitdem kam überhaupt kein SPAM mehr durch.

Die Installation ist unter Ubuntu 14.04 sehr einfach:

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

Das war’s schon, anschließend muss noch Amavis oder der spamd neu gestartet werden. Getestet werden kann das Plugin, indem man sich selbst eine Mail schickt. Anschließend sollte der Check FROM_IS_TO im Mailheader auftauchen.

Modifiziert die Punktevergabe

Noch ein Kurztipp am Ende. Dieser Tipp ist relativ “advanced”, da man genau wissen sollte, was man verändert.

Mittels der Datei /etc/spamassassin/local.cf können die Standardwerte der Punktevergabe für Checks verändert werden. Ich habe bei mir die vergebenen Punkte erhöht, wenn eine Domain oder ein Link in einer DNSBL auftaucht:

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

Der Beitrag SpamAssassin Erkennungsrate (deutlich) verbessern erschien zuerst auf SYN-FLUT.de.