Kürzlich war eine größere Aktualisierung der Serverumgebung nötig, auf der ich auch einen Mailserver betreibe. Ich habe das zum Anlass genommen, rspamd als Alternative zur Kombination aus SpamAssassin und amavisd-new anzusehen und kann das uneingeschränkt empfehlen.
Wesentliche Eigenschaften von rspamd:
- Web-Oberfläche für Status-Informationen und einfache Anpassung der Konfiguration.
- Bis zu 10× schneller als SpamAssassin (siehe auch die Erläuterungen dazu bei rspamd).
- Direkte Einbindung als milter in Postfix, wodurch E-Mails bereits während der Zustellung geprüft und auch ggf. aktiv abgelehnt oder durch Greylisting verzögert werden können.
- Optional Erzeugung von DKIM-Signaturen für ausgehende E-Mails.
Integration in ISPConfig
Da die Nutzer/innen des Servers ihre E-Mail-Adressen auf einfache Weise selber verwalten können sollen, nutze ich ISPConfig. ISPConfig unterstützt auch rspamd statt SpamAssassin. Der Wechsel ist nicht besonders schwer. Eine Anleitung für Debian und Ubuntu findet man bei HowtoForge.
Sieve-Regeln für Spam-Ordner aktualisieren
Je nach dem, wie lange man ISPConfig schon nutzt, kann es nötig sein, die Option zum Verschieben von Spam in den Spam-Ordner bei allen Postfächern einmal aus- und wieder einzuschalten (jeweils danach speichern), damit die Sieve-Regeln für Dovecot aktualisiert werden und als Spam gekennzeichnete E-Mails zuverlässig im Spam-Ordner landen. Aktuelle Versionen von ISPConfg erzeugen dann Regeln, die sowohl bei SpamAssassin wie auch rspamd funktionieren.
Grundsätzlich kann man rspamd auch so konfiguriereren, dass es für Spam-Kennzeichnungen den selben Header setzt, wie SpamAssassin – ich bevorzuge es allerdings, so wenig wie möglich gegenüber der Standardkonfiguration anzupassen.
DKIM
ISPConfig unterstützt auch die Nutzung von DKIM für ausgehende E-Mails in den Einstellungen der jeweiligen Mail-Domain. Damit das auch mit rspamd zuverlässig funktioniert, waren bei mir aber noch ein paar manuelle Anpassungen nötig.
Der Pfad für die DKIM-Schlüssel muss in der Server-Konfiguration (System → Server Config → Mail) auf /var/lib/rspamd/dkim
gesetzt werden. Man sollte auch die Schlüsselstärke von 1024 auf 2048 Bit erhöhen.
Zusätzlich legt man die Datei /etc/rspamd/local.d/dkim_signing.conf
mit folgendem Inhalt an:
try_fallback = false; path_map = "/etc/rspamd/local.d/dkim_domains.map"; selector_map "/etc/rspamd/local.d/dkim_selectors.map";
Damit diese Änderungen wirksam ist, muss man rspamd einmal neu starten:
systemctl restart rspamd
Damit wird sichergestellt, dass rspamd die DKIM-Schlüssel laden kann, die korrekten Selektoren nutzt und nur für E-Mails Signaturen erzeugt, für deren Absender-Domains DKIM in ISPConfig aktiviert wurde.
Danach kann man für jede Mail-Domain, für die man DKIM nutzen will, ein Schlüsselpaar erzeugen und die Einstellung speichern – zunächst ohne aktiviertes „enable DKIM“!
Der angezeigte TXT-Record mit dem öffentlichen Schlüssel muss im zuständigen Nameserver eingetragen werden. Bevor man DKIM aktiviert, sollte man zunächst sicherstellen, dass der öffentliche DKIM-Schlüssel auch abrufbar ist, z.B. mit https://mxtoolbox.com/dkim.aspx. Das kann abhängig von der eingestellten TTL einige Stunden bis hin zu einem Tag dauern. Vorher sollte man DKIM für den E-Mail-Versand nicht aktivieren!
Wenn der öffentliche DKIM-Schlüssel funktioniert, kann man schließlich DKIM in ISPConfig aktivieren, indem man die Option „enable DKIM“ in der Mail-Domain einschaltet und die Einstellungen speichert. ISPConfig schreibt dann den die Schlüssel der Domain in das Verzeichnis /var/lib/rspamd/dkim
und aktualisiert die Domain- und Selector-Map in /etc/rspamd/local.d/dkim_domains.map
und /etc/rspamd/local.d/dkim_selectors.map
entsprechend.
Ein Test auf korrekte Funktion kann auf einer der folgenden Websites durchgeführt werden:
https://www.appmaildev.com/de/dkim
Für Thunderbird gibt es das AddOn „DKIM Verifier“, das man ebenfalls nutzen kann, wenn man sich zur Überprüfung selbst eine E-Mail schicken will.
Zusätzliche Mail-Header mit Prüfergebnissen einfügen
Es ist hilfreich, wenn man bei E-Mails sehen kann, warum eine E-Mail als Spam eingestuft wurde (X-Spam: Yes
im Header) oder auch nicht. Um die Ausgabe der zusätzlichen Header mit detaillierten Prüfergebnissen zu aktivieren, legt man die Datei /etc/rspamd/local.d/milter_headers.conf
mit folgendem Inhalt an:
extended_spam_headers = true skip_local = false skip_authenticated = true
Im Mail-Header X-Rspamd-Server:
fügt rspamd den automatisch ermittelten Namen des Servers ein. Wenn gewünscht, kann man den Namen aber auch manuell vorgeben, indem man noch folgenden Abschnitt in die Konfigurationsdatei einträgt:
routines { x-rspamd-server { hostname = my.host.example } }
Statt my.host.example
trägt man hier natürlich den Namen des eigenen Servers ein.
Danach ist auch wieder ein Neustart von rspamd wie oben beschrieben nötig.
Weitere Informationen zur Konfiguration findet man in der Dokumentation von rspamd.
Praktische Erfahrungen nach 6 Monaten
rspamd hat sich als sehr zuverlässige Lösung herausgestellt. Besonders angenehm ist die Tatsache, dass Spam bereits bei der Zustellung aktiv abgelehnt werden kann, was die regelmäßige Kontrolle eines Spamordners erspart.
Falls erwünschte Absender irrtümlich abgelehnt wurden, kann man diese auch in der Whitelist von ISPConfig eintragen. Anpassungen an den Einstellungen und Filterregeln von rspamd sind in der Weboberfläche im laufenden Betrieb möglich, was gegenüber SpamAssassin auch eine Vereinfachung ist.