Spamassassin mit Exim4 und Dovecot (Debian)
Beschreibung, wie SpamAssassin in einem Debian-Basierten Mailserver mit Exim4, Dovecot und Sieve genutzt werden kann.
Dabei wird als Exim4 nur als MTA genutzt. Als LDA kommt Dovecot zum Einsatz, welches mit Plugins um die Nutzung von Sieve-Skripten erweitert wird.
Quellen:
https://wiki.debian.org/Exim#Spam_scanning
http://www.exim.org/exim-html-current/doc/html/spec_html/ch44.html
https://linux.die.net/man/1/spamassassin
Installation
Metapaket exim4-daemon-light deinstallieren.
Metapaket exim4-daemon-heavy installieren
apt-get install exim4-daemon-heavy
SpamAssassin installieren:
apt-get install spamassassin (spamc?)
SpamAssassin aktivieren und starten
systemctl enable spamassassin.service systemctl status spamassassin.service
Konfiguration
Configfile anpassen:
Splitkonfiguration: /etc/exim4/conf.d/acl/40_exim4-config_check_data
Ohne Split: /etc/exim4/exim4.conf.template --> Sollte hier nicht eher exim3.conf.localmacros verwendet werden?
Folgende Zeilen dekommentieren, um die Ergebnisse von Spamassassin in den Mailheader reinzuschreiben:
warn
condition = ${if <{$message_size}{120k}{1}{0}}
# ":true" to add headers/acl variables even if not spam
spam = nobody:true
add_header = X-Spam_score: $spam_score
add_header = X-Spam_bar: $spam_bar
# # Do not enable this unless you have shorted SpamAssassin's report
# add_header = X-Spam_report: $spam_report
Wenn Fetchmail genutzt wird, muss es so konfiguriert werden, dass Fetchmails E-Mails an den SMTP-Server weitergibt, statt diese direkt in die Mailbox zu legen.
Dazu in der .fetchmailrc-Datei folgende Zeile hinzufügen:
smtp <smtp-server-name>
Dovecot zu lokalem LDA einrichten
Quelle: http://wiki.dovecot.org/LDA/Exim
Damit Sieve für Dovecot genutzt wird, muss Dovecot als LDA genutzt werden.
Findet die Abholung der Mails per Fetchmail statt, kann Fetchmail die Mails direkt an den Dovecot-LDA "deliver" weitergeben.
Dies kann ggf. mit Zwischenschritt über Spamasssassin bzw. spamc, welches dann die Daten per Standardausgabe an Dovecot-LDA weiter gibt, passieren.
Alternativ muss Exim angepasst werden, damit es nicht selbst als LDA fungiert, sondern die Mails an den Dovecot-LDA weiter gibt.
In dem Zuge muss die Nutzung von Procmail ggf. unterbunden werden. Procmail wird als LDA in Exim genutzt, wenn es eine Datei /etc/procmailrc gibt. Diese muss dann ggf. entfernt werden.
Am einfachsten ist es, die verteilte Konfiguration von Exim zu verwenden.
In diesem Falle wird eine neuer Transport für den Dovecot-LDA erstellt:
/etc/exim4/conf.d/transport/30_exim4-config_dovecot_pipe
Inhalt:
dovecot_pipe: debug_print = "T: maildrop_pipe for $local_part@$domain" driver = pipe # Use /usr/lib/dovecot/dovecot-lda if using Debian's package. # You may or may not want to add -d $local_part@$domain depending on if you need a userdb lookup done. # command = /usr/local/libexec/dovecot/dovecot-lda -f $sender_address command = /usr/lib/dovecot/dovecot-lda -f $sender_address message_prefix = message_suffix = log_output delivery_date_add envelope_to_add return_path_add #group = mail #mode = 0660 temp_errors = 64 : 69 : 70: 71 : 72 : 73 : 74 : 75 : 78
Anschließend wird der Dovecot-LDA für den lokalen Transport hinterlegt. Anpassung von: router/900_exim4-config_local_user
# transport = LOCAL_DELIVERY transport = dovecot_pipe
Abschließend Exim neu starten:
service exim4 restart
Dovecot-Sieve sowie Managesieve
Installation von Sieve:
# apt-get install dovecot-sieve dovecot-managesieved (dovecot-antispam?)
Die nachfolgenden Anpassungen in den Config-Files zeigen auf die Teildateien in /etc/dovecot/conf.d/
Idealerweise bleiben diese Config-Files jedoch unangetastet. Die Konfiguration sollte stattdessen in einer Sammeldatei, die nicht zum Lieferumfang der Distribution gehört, gesammelt werden, z.B.: 99-my-customzation.conf
Sieve greift in Dovecot an mehreren Stellen ein. Diese werden konfiguriert in: 90-sieve.conf bzw. entsprechend in 99-my-customzation.conf
plugin {
sieve = file:~/sieve;active=~/.dovecot.sieve
# The default Sieve script when the user has none. This is the location of a
# global sieve script file, which gets executed ONLY if user's personal Sieve
# script doesn't exist. Be sure to pre-compile this script manually using the
# sievec command line tool if the binary is not stored in a global location.
# --> See sieve_before for executing scripts before the user's personal
# script.
sieve_default = /var/lib/dovecot/sieve/default.sieve
# Directory for :personal include scripts for the include extension. This
# is also where the ManageSieve service stores the user's scripts.
sieve_dir = ~/sieve
# Location Sieve of scripts that need to be executed before the user's
# personal script.
#sieve_before = /var/lib/dovecot/sieve.d/
# Identical to sieve_before, only the specified scripts are executed after the
# user's script (only when keep is still in effect!). Multiple script
# locations can be specified by appending an increasing number.
sieve_after = /etc/dovecot/sieve-after
}
Es sind zwei Lösungsansätze denkbar:
1. Verzeichnis für Sieve-Regeln erstellen
Dies ist sinnvoll, wenn man zusätzlich Skripte durch User erstellen lassen möchte, z. B. mit Managesieve und der Roundcube-Erweiterung.
# mkdir /etc/dovecot/sieve-after
Neue Sieve-Regeldatei erstellen darin erstellen, z. B. movespam.sieve
Inhalt der Datei siehe zweiter Lösungsansatz.
2. Globale Default-Sieve-Datei (Getesteter Weg)
Diese Default-Sieve-Datei wird verwendet, wenn keine persönliche Sieve-Datei für den User vorhanden ist. Dies ist z. B. dann der Fall, wenn Managesieve nicht genutzt werden soll.
Alternativ ist dies sinnvoll, wenn der User ohne persönliche Sieve-Datei ein Standardverhalten erhalten soll, dieses aber vollständig vom User übersteuert können werden soll.
# mkdir /var/lib/dovecot/sieve
Datei anlegen: /var/lib/dovecot/sieve/default.sieve
Inhalt für Sortierung der Mails anhand des X-Spam-Flag:
# The “require” lines include functionality to move emails
# into certain folders (fileinto) and to create folders if
# they don’t exist yet (mailbox). Then if SpamAssassin marked
# a header as spam it is moved into the Junk folder
# which just appears as “Junk” to the user underneath their inbox.
require ["fileinto","mailbox"];
if header :contains "X-Spam-Flag" "Yes" {
fileinto :create "Junk";
}
Inhalt für Sortierung der Mails anhand der X-Spam_bar:
require "fileinto";
if header :contains "X-Spam_bar" "+++++"
{
fileinto "Junk";
}
In beiden Fällen sollte die Sieve-Regel-Datei zu einer binären Datei kompiliert werden:
sievec /etc/dovecot/sieve/spam-to-junk.sieve
bzw.
sievec /var/lib/dovecot/sieve/default.sieve
Sieve-Configdatei 20-managesieve.conf bearbeiten und folgende Zeile einfügen, um Sieve zu aktivieren:
protocols = $protocols sieve
LDA-Plugins aktivieren in 15-lda.conf durch erweitern der folgenden Zeilen um Sieve:
protocol lda {
# Space separated list of plugins to load (default is global mail_plugins).
mail_plugins = $mail_plugins sieve
}
Evtl. auch "protocol lmtp" erweitern? (Findet sich in einer anderen Conf-Datei)
Dovecot neu starten
service dovecot restart
Verfügbarkeit Sieve testen, Port 4190 sollte von Dovecot geöffnet sein
netstat -tulpen | grep -i dovecot
Bei Problemen: http://wiki2.dovecot.org/Pigeonhole/Sieve/Troubleshooting
Dovecot Managesieve / Roundcube
Siehe Roundcube als Webmail-Client (Debian)#Managesieve
Bayes in SpamAssassin
Kleine Einleitung zum Bayesschen Filter in SpamAssassin: https://wiki.apache.org/spamassassin/BayesInSpamAssassin
FAQ: https://wiki.apache.org/spamassassin/BayesFaq
SpamAssassin-Learn einrichten:
sa-learn --spam <spamfolder> sa-learn --ham <hamfolder>
Alternativ
sa-learn --folders=foldersfile
Wobei foldersfile folgenden Aufbau haben muss:
ham:dir:/path/to/hamfolder1 ham:dir:/path/to/hamfolder2 ham:dir:/path/to/hamfolder3 spam:dir:/path/to/spamfolder1 spam:dir:/path/to/spamfolder2 spam:dir:/path/to/spamfolder3
Statt dir kann man auch mbox verwenden. Vgl. Dokumentation https://spamassassin.apache.org/full/3.4.x/doc/sa-learn.txt
Status SA-Learn überprüfen:
sa-learn --dump magic sa-learn --dbpath /path/to/bayesdb --dump magic
Netzwerktests / HashSharingSysteme Razor und Pyzor
Was sind Netzwerktests? https://wiki.apache.org/spamassassin/UsingNetworkTests
Bei Razor und Pyzor handelt es sich um Hash-Sharing-Systeme. Was sind Hash-Sharing-Systeme? https://wiki.apache.org/spamassassin/HashSharingSystem
Wie funktioniert Razor? https://wiki.apache.org/spamassassin/UsingRazor
Wie funktioniert Pyzor? https://wiki.apache.org/spamassassin/UsingPyzor
Ein Server kann seine Spam-Informationen auch an Hash-Sharing-Systeme zurückmelden: https://wiki.apache.org/spamassassin/ReportingSpam
Installation:
# apt-get install razor pyzor
Bei Razor registrieren und Serverliste downloaden:
# razor-admin -create # razor-admin -register
Serverliste aktualisieren:
# pyzor discover
Pyzor testen:
# pyzor ping
Das Ergebnis sollte etwa so lauten:
public.pyzor.org:24441 (200, 'OK')
Als letztes wird noch die SpamAssassin-Konfiguration /etc/spamassassin/local.cf erweitert. Unter dem Bayes-Bereich folgende Zeilen einfügen:
use_pyzor 1 pyzor_path /usr/bin/pyzor use_razor2 1 razor_config /etc/razor/razor-agent.conf
Normalerweise sind in Debian die zugehörigen SpamAssassin-Plugins bereits aktiviert. Diese kan man in /etc/spamassassin/v310.pre nochmal überprüfen:
# Pyzor - perform Pyzor message checks. # loadplugin Mail::SpamAssassin::Plugin::Pyzor # Razor2 - perform Razor2 message checks. # loadplugin Mail::SpamAssassin::Plugin::Razor2
Spamassassin neu starten:
/etc/init.d/spamassassin restart
Zum Testen der Funktionsweise von Razor und Pyzor vgl. Abschnitt Testen.
Troubleshooting
Erweitertes Logging kann aktiviert werden in /etc/dovecot/conf.d/10-logging.conf
# Enable mail process debugging. This can help you figure out why Dovecot # isn't finding your mails. mail_debug = yes
Die Logs werden nach /var/log/syslog geschrieben.
Alternativ lohnt es sich auch noch folgende Dateien zu prüfen:
- /var/log/syslog
- /var/log/mail.info
- /var/log/mail.err
- /var/log/exim/maillog
Testen
Testmail senden um gesamten SMTP-Stack zu testen:
Vgl. Exim als SMTP-Server (Debian)#Versenden von Testmails
Testdaten befinden sich in Debian unter /usr/share/doc/spamassassin/examples/
Testdurchführung Spamassassin
spamassassin -t < /usr/share/doc/spamassassin/examples/sample-nonspam.txt > ~/nonspam.out spamassassin -t < /usr/share/doc/spamassassin/examples/sample-spam.txt > ~/spam.out spamc < /usr/share/doc/spamassassin/examples/sample-nonspam.txt > ~/nonspam.out spamc -t < /usr/share/doc/spamassassin/examples/sample-spam.txt > ~/spam.out
Testdurchführung Razor / Pyzor
spamassassin -D -t < /usr/share/doc/spamassassin/examples/sample-spam.txt 2>&1 | tee ~/sa.out
In der erstellten Datei sa.out sollte nach folgenden dbg: pyzor Ausschau gehalten werden:
cat sa.out | grep "dbg: pyzor"
Ergebnis könnte so aussehen:
Mär 30 22:02:27.032 [4039] dbg: pyzor: network tests on, attempting Pyzor Mär 30 22:02:29.999 [4039] dbg: pyzor: pyzor is available: /usr/bin/pyzor Mär 30 22:02:30.000 [4039] dbg: pyzor: opening pipe: /usr/bin/pyzor check < /tmp/.spamassassin4039JL3Abptmp Mär 30 22:02:30.316 [4039] dbg: pyzor: [4041] finished: exit 1 Mär 30 22:02:30.316 [4039] dbg: pyzor: got response: public.pyzor.org:24441 (200, 'OK') 0 3
Außerdem sollte folgende Zeile enthalten sein, die auf die Nutzung von Razor und Pyzor hinweist:
check_dkim_adsp: 4 (0.2%), check_spf: 23 (1.1%), check_razor2: 218 (10.5%), check_pyzor: 92 (4.4%), tests_pri_500: 73 (3.5%)
