Ubuntu 20.04 - SpamAssassin in Postfix einrichten
Vorwort
Diese Dokumentation beschreibt den Installationsvorgang von SpamAssassin zur Verwendung mit Postfix.
Bitte vergewissern Sie sich, dass Ihr System über die nötigen Voraussetzungen verfügt, wie in der Infobox beschrieben. Weiterhin sind Grundkenntnisse im Umgang mit Linux erforderlich, da die Vorgehensweise, wie sie hier beschrieben ist, in manchen Teilen abweichen kann. Kein System ist wie das Andere. Die Dokumentation wurde sorgfältig von mir geprüft. Dennoch kann ich keinerlei Haftung für Schäden an Ihrem System oder eine Gewährleistung übernehmen. Bitte verwenden Sie diese Dokumentation auf eigene Gefahr.
Verwendete Software:
Voraussetzungen:
- Ubuntu 20.04 LTS
- Postfix (fertig eingerichtet), z.B.:
Weitere, empfohlene Dokumentationen:
- Lokalen DNS-Resolver (cashing-only) mit Bind installieren
- SPF, DKIM und DMARC in Postfix einrichten
- Postfix als Mailserver mit Dovecot und PostfixAdmin
- Postfix als Relayhost (Smarthost)
Was soll erreicht werden?
Ziel dieser Dokumentation soll sein, Postfix um SpamAssassin zu erweitern.
Server vorbereiten
Root-Rechte einräumen
Während der gesamten Dokumentation werden Root-Rechte benötigt. Um auf das Voranstellen von sudo zu verzichten, verschaffen Sie sich für die gesamte Sitzung erhöhte Rechte mit:
# sudo -i
Update durchführen
Bringen Sie den Server auf den aktuellen Patchstand:
# apt update && apt upgrade
Software herunterladen und installieren
Laden Sie SpamAssassin aus dem offiziellen Ubuntu-Repository herunter:
# apt-get install spamassassin libmail-dkim-perl
SpamAssassin einrichten
SpamAssassin konfigurieren
Editieren Sie zunächst die Datei /etc/default/spamassassin und ändernd Sie folgende Parameter:
# nano /etc/default/spamassassin
[...]
OPTIONS="--create-prefs --max-children 5 --username debian-spamd --helper-home-dir /var/log/spamassassin/ -s /var/log/spamassassin/spamd.log"
[...]
CRON=1
Anti-Spam-Rules einrichten
Anti-Spam-Rules werden bei SpamAssassin in der Datei /etc/spamassassin/local.cf konfiguriert. Sämtliche Parameter sind in dieser Datei ausführlich dokumentiert. Die Ansprüche an einen Spam-Schutz sind sehr individuell. Betrachten Sie daher die, in dieser Dokumentation verwendete Konfiguration, lediglich als Vorschlag und passen Sie diese entsprechend Ihrer eigenen Bedürfnisse an.
In unserem Setup werden alle Default-Tests durchgeführt (inkl. DKIM) und Spamassassin fügt dem Header einer E-Mail das X-Spam-Flag hinzu, welches von nachgeschalteten Instanzen ausgewerten werden kann (z.B. für Mailregeln). Weder wird eine E-Mails abgewiesen noch wird die Betreff-Zeile verändert.
Die Parameter clear_headers und add_header [...] verhindern, dass die verwendete Version von Spamassassin im X-Spam-Status angezeigt wird.
Alle weiteren Konfigurations-Parameter finden Sie auf der offiziellen Seite von SpamAssassin.
Benennen Sie zunächst die /etc/spamassassin/local.cf um, damit Sie eine Sicherheitskopie der Original-Datei haben:
# mv /etc/spamassassin/local.cf /etc/spamassassin/local.cf.bak
Erstellen Sie eine neue Datei /etc/spamassassin/local.cf mit folgendem Inhalt:
# nano /etc/spamassassin/local.cf
envelope_sender_header X-Envelope-From report_safe 0 required_score 3.5 use_bayes 1 use_bayes_rules 1 bayes_auto_learn 1 skip_rbl_checks 0 use_razor2 0 use_pyzor 0 score DKIM_VERIFIED -0.1 score DKIM_POLICY_TESTING 0 clear_headers add_header all Flag _YESNO_ add_header all Status _YESNO_, score=_SCORE_ required=_REQD_ tests=_TESTS_ autolearn=_AUTOLEARN_ add_header all Report _REPORT_
Logging einrichten
Erstellen Sie einen neuen Ordner /var/log/spamassassin und vergeben Sie die Zugriffsrechte:
# mkdir /var/log/spamassassin # chown -R debian-spamd. /var/log/spamassassin
Erstellen Sie eine neue Datei /etc/logrotate.d/spamassassin mit folgendem Inhalt:
# nano /etc/logrotate.d/spamassassin
/var/log/spamassassin/*.log {
rotate 7
weekly
compress
missingok
}
SpamAssassin bei Systemstart automatisch starten
Führen Sie folgendes Kommando aus, damit SpamAssassin nach einem Neustart automatisch startet:
# systemctl enable spamassassin.service
Synchronizing state of spamassassin.service with SysV init with /lib/systemd/systemd-sysv-install...
Executing /lib/systemd/systemd-sysv-install enable spamassassin
SpamAssassin in Postfix implementieren
Zur Bewertung einer E-Mail durch SpamAssassin muss Postfix diese zunächst an SpamAssassin übergeben. Sobald SpamAssassin die Bewertung abgeschlossen und die Ergebnisse dem Header der E-Mail hinzugefügt hat, muss sie zur Weiterverarbeitung wieder zurück zu Postfix.
Spamassassin kann auf verschieden Arten in Postfix implementiert werden. Beide Methoden haben ihre Vor- und Nachteile.
Implementierung über Milter:
Bei dieser Methode wird Spamassassin über das sogenannte Milter-Programm Spamass-Milter implementiert. Das Kofferwort Milter setzt sich aus den Worten Mail und Filter zusammen. Milter-Programme erhalten von Postfix Voll-Zugriff auf eine E-Mail und dürfen diese auswerten und sogar inhaltlich verändern.
Eine E-Mail wird hierfür zuerst an das entsprechende Milter-Programm übergeben, bevor sie in die Warteschlange eingereiht wird (Pre-Queue-Filtering).
Vorteil:
Der Vorteil dieser Methode besteht darin, dass bereits während der SMTP-Transaktion über Annahme oder Ablehnung einer E-Mail entschieden werden kann, also noch bevor sie von Postfix der Warteschlange übergeben wurde.
Diese Funktion kann direkt in Spamass-Milter konfiguriert werden.
Nachteil:
Ein möglicher Nachteil ist, dass das Scannen einer E-Mail Zeit beansprucht. Der sendende Mailserver wartet aber nur eine gewisse Zeitspanne (Timeout), bis der empfangende Mailserver ihm mitteilt, ob die E-Mail angenommen oder abgelehnt wird. Bleibt diese Mitteilung innerhalb dieser Zeitspanne aus, wird der sendende Mailserver den Zustellversuch abbrechen und normalerweise später erneut versuchen, die E-Mail zuzustellen. Beim erneuten Zustellversuch steht er wieder vor dem gleichen Problem.
Dieser Nachteil besteht zwar grundsätzlich, allerdings benötigt die Analyse durch Spamassassin nur wenig Zeit. Unter normalen Umständen wird diese Methode keine Probleme verursachen.
Implementierung über Content-Filter:
Durch die Verwendung dieses Filter-Typs wird eine E-Mail, unabhängig ihrer inhaltlichen Eigenschaften, zunächst von Postfix angenommen und erst nach der Annahme an den, im content-filter angegebenen Dienst, übergeben (Post-Queue-Filtering).
Vorteil:
Der Vorteil dieser Methode besteht darin, dass das Scannen der E-Mail nicht zeitkritisch ist, da die SMTP-Transaktion zu diesem Zeitpunkt bereits abgeschlossen ist. Die Gefahr eines Timeouts besteht nicht.
Nachteil:
Der Nachteil besteht ganz klar darin, dass eine unerwünschte E-Mail nicht mehr in Echtzeit abgelehnt werden kann. Das nachträgliche Ablehnen würde in den meisten Fällen zum Double-Bounce-Effekt führen, da die Absender-Adressen unerwünschter E-Mails in den meisten Fällen gefälscht sind. Im schlimmsten Fall würde Ihr System durch nachträgliches Ablehnen sogar unbeabsichtigt zum Spam-Host werden.
Entscheiden Sie sich also nur dann für diese Methode, wenn Sie bewusst auf das Ablehnen von unerwünschten E-Mails verzichten möchten. Ein Ablehnen ist mit dieser Methode ohnehin nicht ohne Weiteres möglich.
Milter-Methode einrichten (Empfohlen)
Da Spamass-Milter eine eingehenden E-Mail auswertet, muss in Postfix ein entsprechender smtpd-milter definiert werden.
Die Kommunikation zwischen Postfix und Spamass-Milter findet über Spamass-Milter-Socket statt.
Spamass-Milter kann nicht zwischen Ein- und Ausgehenden Emails unterscheiden. Um das Scannen ausgehender Emails zu verhindern, muss ein entsprechender Parameter gesetzt sein.
Installieren Sie den Spamassassin-Milter:
# apt install spamass-milter
Mit Spamass-Milter können unerwünschte E-Mails ab einem definierten Spamassassin-Score (z.B. 10) während der SMTP-Transaktion abgelehnt werden.
Editieren Sie dazu die Datei /etc/default/spamass-milter und ändern Sie folgenden Paramater:
# nano /etc/default/spamass-milter
[...]
OPTIONS="${OPTIONS} -r 10"
[...]
Überschreitet eine E-Mail den Spamassassin-Score von 10, wird die E-Mail mit dem Reject-Code 550 und folgendem Text abgelehnt:
5.7.1 Blocked by SpamAssassin
Es ist nicht sinnvoll Informationen über die verwendete Software mitzuteilen. Passen Sie den Text der Meldung daher entsprechend an.
Editieren Sie dazu die Datei /etc/default/spamass-milter und fügen Sie folgenden Paramater hinzu:
[...]
OPTIONS="${OPTIONS} -R Looks_like_Spam!"
[...]
Definieren Sie IP-Adressen oder Subnetze, die von spamass-milter ignoriert werden sollen. Werden alle internen Netze angegeben, wird keine ausgehende Email gescannt.
Editieren Sie dazu die Datei /etc/default/spamass-milter und fügen Sie folgenden Paramater nach folgendem Syntax hinzu:
[...]
OPTIONS="${OPTIONS} -i <IP-Adresse/Subnetz>"
[...]
Alternativ kann auch eine Ausnahme für alle Absender, die sich mit SMTP AUTH authentifiziert haben, eingerichtet werden.
Editieren Sie dazu die Datei /etc/default/spamass-milter und fügen Sie folgenden Paramater hinzu:
[...]
OPTIONS="${OPTIONS} -I"
[...]
Spammassassin fügt dem Header der E-Mail verschiedene Informationen hinzu. Die verwendete Version von Spamassassin soll allerdings nicht übertragen werden.
Da über Milter eingefügte Header-Informationen nicht über den Postfix-Parameter header_checks bearbeitet werden können, erstellen wir eine neue Datei und verwenden den Postfix-Parameter milter_header_checks.
Erstellen Sie eine neue Datei /etc/postfix/milter_header_checks mit folgendem Inhalt:
# nano /etc/postfix/milter_header_checks
## Anonymisierung
# SPAM-Agent
/^X-Spam-Checker-Version:/ IGNORE
Fügen Sie der Datei /etc/postfix/main.cf folgendes hinzu:
[...]
milter_default_action = accept
milter_protocol = 6
milter_header_checks = pcre:${config_directory}/milter_header_checks
smtpd_milters =
local:spamass/spamass.sock
non_smtpd_milters =
${smtpd_milters}
[...]
Starten Sie die Dienste neu, damit die Konfiguration angewendet wird:
# service spamass-milter restart # service spamassassin restart # service postfix restart
Content-Filter-Methode einrichten (Alternativ)
Als content-filter-Dienst wird der Dienst spammassassin eingerichtet.
Da SpamAssassin ein externes Programm ist, muss es mit dem pipe-daemon aufgerufen werden.
Der pipe-daemon ruft das Programm spamc mit entsprechender Parametrisierung auf und übergibt die E-Mail anschliessend über den Aufruf sendmail wieder an Postfix.
Fügen Sie der Datei /etc/postfix/master.cf unter smtp inet n - n - -den Parameter -o content_filter=spamassassin hinzu:
[...]
smtp inet n - n - - smtpd
[...]
-o content_filter=spamassassin
[...]
[...]
und fügen Sie folgendes hinzu:
[...]
spamassassin unix - n n - - pipe
user=debian-spamd argv=/usr/bin/spamc -f -e
/usr/sbin/sendmail -oi -f ${sender} ${recipient}
[...]
Starten Sie die Dienste neu, damit die Konfiguration angewendet wird:
# service spamassassin restart # service postfix restart
DNS-Resolver einrichten (URIBL_BLOCKED Problem)
Mit SpamAssassin können sogenannte DNS-basierte Blacklists zur Spam-Klassifikation verwendet werden. Die Blacklist von URIBL.com ist standardmässig aktiviert.
Diese Blacklists werden von SpamAssassin in Echtzeit abgefragt und die meisten Blacklist-Anbieter räumen ein kostenloses Kontingent von Abfragen ein (auch URIBL.com). Nur Nutzer mit sehr vielen Anfragen müssen entsprechende Gebühren zahlen.
Technisch gesehen ist die Abfrage einer Blacklist eine DNS-Abfrage und das führt zu folgendem Problem:
Wenn öffentliche oder vom ISP automatisch zugewiesene DNS-Server zur Abfrage verwendet werden, wird die Anfrage höchstwahrscheinlich geblockt, da diese DNS-Server von sehr vielen Nutzern verwendet werden. Abfragen unterschiedlicher Mailserver erfolgen somit über die gleiche IP-Adresse. Dadurch wird das kostenlose Kontingent an Anfragen für diese IP-Adresse überschritten.
Der SpamAssassin-Tag sieht in diesem Fall wie folgt aus:
URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information.
Abhilfe schafft hier ein sogenannter lokaler DNS-Resolver. Über diesen DNS-Resolver können Abfragen einer Blacklist direkt und ohne Umweg über einen öffentlichen DNS-Server durchgeführt werden. Da für die Abfrage logischerweise auch die eigene IP-Adresse und nicht die des öffentlichen DNS-Servers verwendet wird, kann das kostenlose Kontingent genutzt werden.
Ein lokaler DNS-Resolver ist schnell eingerichtet und nahezu wartungsfrei. Wie ein lokaler DNS-Resolver eingerichtet wird, erfahren Sie hier:
Lokalen DNS-Resolver (cashing-only) mit Bind installieren