Schlagwort-Archive: razor2

Der eigene Mailserver – Teil 3

6 Antworten

Es ist Zeit für Teil 3 dieser kleinen Artikelreihe. In diesem Teil wird der Server einsatzbereit gemacht. Dazu sind im Wesentlichen die folgenden sechs Aufgaben zu erledigen.

Es gibt wieder viel zu tun. Also legen wir los.

Haben wir nicht was vergessen?

Wie ist es denn um den Update-Status des eigenen Servers bestellt? Evtl. ist jetzt eine gute Gelegenheit das System auf Updates zu prüfen und diese einzuspielen. Doch muss dies nicht manuell passieren.

In „Automatische Installation von Sicherheitsupdates“ erkläre ich, wie man die Update-Installation unter Ubuntu automatisieren kann. Exkurs Ende.

OpenDKIM

OpenDKIM soll Mailservern dabei helfen die Authentizität und die Integrität von eingehenden E-Mails zu überprüfen.

Versendet ein Mailserver eine E-Mail mit OpenDKIM, so bildet der Server einen Hashwert über den Inhalt der E-Mail. Dieser Hashwert wird mit einem privaten Schlüssel verschlüsselt und im Header der E-Mail gespeichert. Der empfangende Mailserver fragt über DNS einen speziellen TXT-Record ab, welcher das öffentliche Gegenstück zum privaten Schlüssel enthält, mit welchem der Hash verschlüsselt wurde. Der empfangende Mailserver nutzt diesen öffentlichen Schlüssel, um den Hashwert der Nachricht zu entschlüsseln. Abschließend bildet der Mailserver selbst den Hashwert der empfangenen E-Mail und vergleicht ihn mit dem soeben entschlüsselten Hashwert aus dem Mailheader. Stimmen beide Hashwerte überein, kann man mit hinreichender Sicherheit davon ausgehen, dass die E-Mail von einem autorisierten Absender stammt und unterwegs nicht verändert wurde.

Für die einzelnen Schritte in diesem Teil werden wieder root-Rechte benötigt. Entweder man öffnet eine root-Shell oder stellt den folgenden Befehlen ein sudo voran.

Als erstes wird das Paket OpenDKIM installiert.

:~$ sudo apt-get install opendkim opendkim-tools

Das OpenDKIM Paket richtet bei der Installation automatisch die benötigten Benutzerkonten und Upstart Jobs ein. Es muss nur noch ein Verzeichnis erstellt werden, in dem die Konfigurationsdateien und der private Schlüssel gespeichert werden. Der Zugriff auf dieses Verzeichnis wird auf den Benutzer und die Gruppe von opendkim beschränkt.

mkdir /etc/opendkim
chown opendkim:opendkim /etc/opendkim

Im nächsten Schritt wird im soeben erstellen Verzeichnis ein DKIM Schlüsselpaar erstellt.

cd /etc/opendkim
opendkim-genkey -r -h sha256 -d domainname.tld -s mail

Mit dem Parameter -r schränkt man das erstellte Schlüsselpaar in der Art ein, dass es nur zur Signatur von E-Mails verwendet werden kann. Die Angabe des Hash-Algorithmus sollte selbsterklärend sein. Der Parameter -d spezifiziert die Domain und -s gibt den Selektor an.[9. opendkim-genkey Manual] Das Kommando gibt die beiden Dateien mail.private und mail.txt aus. Letztere enthält den öffentlichen Schlüssel in Form eines DNS TXT Records. Dies macht es einfach, den benötigten DNS Eintrag auf dem DNS Server hinzuzufügen. Ich komme in Kürze darauf zurück.

Die Datei mail.private wird in mail umbenannt. Anschließend wird festgelegt, welche Dienste den Schlüssel zur Signatur von Mails nutzen dürfen. Aber ein Schritt nach dem Anderen.

Zuerst wird die Datei umbenannt:

mv mail.private mail

Anschließend wird die Datei /etc/opendkim/KeyTable angelegt und mit Inhalt nach folgendem Muster befüllt:

domainname.tld domainname.tld:mail:/etc/opendkim/mail

Hier wird domainname.tld mit dem privaten Schlüssel für diese Domain verknüpft. Hat man mehrere Domains und Schlüssel, werden diese nach dem gleichen Muster hier eingetragen.

Als nächstes wird die Datei /etc/opendkim/SigningTable erstellt und mit folgendem Inhalt gefüllt:

*@domainname.tld domainname.tld

Dieser Eintrag weist OpenDKIM an, alle E-Mails von allen Adressen, die auf @domainname.tld enden, mit der Signatur von mail.domainname.tld zu versehen. Auch hier lassen sich ganz einfach weitere Domains hinzufügen.

Als letzte Datei wird die Datei /etc/opendkim/TrustedHosts erstellt, welche lediglich eine lokale IP-Adresse enthält:

127.0.0.1
::1

Diese Datei gibt an, welche Server Mails signieren dürfen und welche Server signierte Mails versenden dürfen, ohne Benutzeranmeldedaten zu übermitteln.

Damit nur OpenDKIM auf die Dateien unterhalb von /etc/opendkim zugreifen kann, wird der Zugriff noch entsprechend eingeschränkt:

chown -R opendkim:opendkim /etc/opendkim

Jetzt kann es der Konfigurationsdatei /etc/opendkim.conf an den Kragen gehen. An das Ende der Datei wird der folgende Inhalt angehängt:

## Benutzerspezifische OpenDKIM Konfiguration
Canonicalization        relaxed/relaxed
ExternalIgnoreList      refile:/etc/opendkim/TrustedHosts
InternalHosts           refile:/etc/opendkim/TrustedHosts
KeyTable                refile:/etc/opendkim/KeyTable
SigningTable            refile:/etc/opendkim/SigningTable
LogWhy                  Yes
PidFile                 /var/run/opendkim/opendkim.pid
Socket                  local:/var/spool/postfix/opendkim/opendkim.sock
SyslogSuccess           Yes
TemporaryDirectory      /var/tmp
UserID                  opendkim:opendkim

Da das Verzeichnis für den Socket noch nicht existiert, wird es jetzt angelegt und mit den entsprechenden Berechtigungen versehen.

mkdir /var/spool/postfix/opendkim
chown opendkim:root /var/spool/postfix/opendkim

Damit die Konfiguration wirksam wird, muss der Dienst einmal neugestartet werden:

service opendkim restart

Damit Postfix über den Socket mit OpenDKIM kommunizieren kann, fügt man den Benutzer Postfix der OpenDKIM Gruppe hinzu.

usermod -G opendkim postfix

Damit ist die erste Aufgabe für diesen Teil erledigt. Bevor wir OpenDKIM endgültig mit Postfix verbinden, wenden wir uns einem anderen Schlachtfeld zu.

Der ewige Kampf gegen den Spam…

…beginnt an dieser Stelle mit der Installation des milters und der Pakete, die benötigt werden, damit Spamassassin mit den DKIM Headers zusammenarbeitet.

sudo apt-get install spamass-milter pyzor razor libmail-dkim-perl

Es gibt mehrere Wege, SpamAssassin zu konfigurieren und zu nutzen. Der einfachste wäre alle Dienstfunktionalitäten zu ignorieren und Postfix die Mails einfach an SpamAssassin weiterleiten zu lassen, bevor diese an Dovecot geleitet werden. Doch dieser Weg führt zur dunklen Seite der Macht.

Ich möchte, dass Postfix die E-Mails über einen Unix-Socket an spamd zur Überprüfung gibt. spamd läuft im Hintergrund und wartet auf die Mails von Postfix. Dies ist schneller und ressourcenschonender. Denn es muss nicht für jede eintreffende E-Mail ein SpamAssassin Prozess gestartet werden.

In der Standardkonfiguration legt spamass-milter für jedes Postfach eine eigene AntiSpam-Datenbank an. Ob man dies möchte, hängt vom Einsatzzweck des jeweiligen Servers ab. Ich persönlich plane den Server für meine eigenen Domains und meine eigenen Postfächer zu nutzen. Daher werde ich es mit einer globalen Konfiguration versuchen, die für alle Postfächer gilt.

Benutzerkonten und Konfigurationsdateien

Bevor die Betriebsbereitschaft hergestellt werden kann, muss noch ein System-Benutzer für den Dienst spamd erzeugt und der Benutzer spamass-milter der spamd Benutzergruppe hinzugefügt werden.

addgroup --system spamd
adduser --system --home /var/lib/spamassassin --ingroup spamd spamd
usermod -a -G spamd spamass-milter

Fertig, nun werden erstmal ein paar Konfigurationsdateien gehackt.

Zu Beginn ist /etc/default/spamassassin dran. Nach der Bearbeitung sollte die Datei wie folgt aussehen:

SAHOME="/var/lib/spamassassin"
SAGLOBALCFGPATH="/etc/spamassassin"
 
# Change to one to enable spamd
ENABLED=1
 
# Options
# See man spamd for possible options. The -d option is automatically added.
OPTIONS="-x --max-children 5 --helper-home-dir ${SAHOME} -u spamd -g spamd --siteconfigpath ${SAGLOBALCFGPATH} --socketpath=/var/spool/postfix/spamassassin/spamd.sock --socketowner=spamd --socketgroup=spamd --socketmode=0660"
 
# Pid file
# Where should spamd write its PID to file? If you use the -u or
# --username option above, this needs to be writable by that user.
# Otherwise, the init script will not be able to shut spamd down.
PIDFILE="/var/run/spamd.pid"
 
# Cronjob
# Set to anything but 0 to enable the cron job to automatically update
# spamassassin's rules on a nightly basis
CRON=1

Die ersten beiden Zeilen enthalten Variablen, die das SpamAssassin Home-Verzeichnis und das Verzeichnis mit der globalen Konfiguration beinhalten. Als nächstes wird der spamd Daemon aktiviert. OPTIONS enthält einen ganzen Blumenstrauß an Parametern. Hier wird festgelegt, dass nur eine Konfigurationsdatei für alle Benutzer verwendet wird. Die UID und GID, unter denen SpamAssassin ausgeführt werden soll, werden festgelegt. Der Pfad zur globalen Konfigurationsdatei wird angegeben, usw. usf. Am Ende wird noch das automatische Policyupdate aktiviert. Für weitere Erläuterungen dieser Datei verweise ich auf die Projektseite[2. Projektseite Apache SpamAssassin], welche unter den Quellen verlinkt ist.

Das Verzeichnis für den Socket wird manuell erstellt und die entsprechenden Benutzerrechte vergeben:

mkdir /var/spool/postfix/spamassassin
chown spamd:root /var/spool/postfix/spamassassin/

Speichern und schließen! Jetzt geht es mit /etc/default/spamass-milter weiter. Diese Datei enthält nur eine einzige Zeile, die nach der Bearbeitung wie folgt aussehen sollte.

OPTIONS="-u spamass-milter -i 127.0.0.1 -m -I -- --socket=/var/spool/postfix/spamassassin/spamd.sock"

Die Option „-u“ definiert, unter welchem Benutzerkontext der Milter ausgeführt wird. „-i“ gibt die Quell-IPs der Systeme an, deren Mails der Milter ignorieren soll. „-I“ ignoriert E-Mails von authentifizierten SMTP-Sendern. „-m“ hält SpamAssassin davon ab, sich zu sehr mit den Mail-Headern zu beschäftigen. Der Rest der Zeile gibt an, wohin der Milter die Mails zum Scannen leiten soll. Hier wird der Socket angegeben, der im letzten Schritt erstellt wurde.

Speichern, schließen, nächster!

An die Datei /etc/spamassassin/init.pre werden die beiden folgenden Zeilen angefügt:

## Add TextCat to assist enable language-based filtering
loadplugin Mail::SpamAssassin::Plugin::TextCat

Die beiden Zeilen bewirken, dass das TextCat-Plugin geladen wird, welches wir in der folgenden Konfigurationsdatei verwenden.

In der Datei /etc/spamassassin/local.cf wird direkt unterhalb des ersten Kommentars der folgende Code eingefügt:

## Force global Bayesian databases instead of per-user
bayes_path /var/lib/spamassassin/.spamassassin/bayes
bayes_file_mode 0777
 
## Ensure non-English and non-German e-mails are treated as spam
ok_languages en de
ok_locales en
 
## Set Pyzor and Razor config file paths
razor_config /etc/razor/razor-agent.conf
pyzor_options --homedir /var/lib/spamassassin/.pyzor

Zu Beginn wird festgelegt, wo die Datenbank für den Bayesian-Filter liegt.

Die nächsten beiden Optionen geben an, in welcher Sprache und welchem Zeichensatz eine E-Mail entsprechen muss, um nicht als Spam aussortiert zu werden. Die aktuelle Einstellung erlaubt E-Mails in englischer so wie deutscher Sprache und westlichem Zeichensatz. Eine vollständige Liste der untestützten Sprachen gibt es in der TextCat Dokumentation[4. Dokumentation TextCat Plugin], die verfügbaren Zeichensätze sind in der SpamAssassin Dokumentation für Konfigurationsdateien[5. SpamAssassin Language Options] zu finden.

Auf die letzten beiden Zeilen werde ich in Kürze noch eingehen.

Wann immer man an den Konfigurationsdateien von SpamAssassin herumgemacht hat, ist es eine gute Idee, die Konfiguration mit folgendem Befehl auf Fehler zu überprüfen.

spamassassin --lint

Liefert das Kommando keine Ausgabe zurück, ist alles in Ordnung.

Zum Start werden einmal die aktuellen SpamAssassin-Regeln mit dem Kommando sa-update abgerufen. In Zukunft passiert dies automatisch.

sa-update
chown -R spamd:spamd /var/lib/spamassassin

Nun werden noch das Verzeichnis für den Socket angelegt, die Benutzerrechte korrigiert und die beiden Dienste neugestartet. Anschließend kann es schon zum nächsten Schritt weitergehen.

chown spamd:spamd /var/lib/spamassassin/.spamassassin
service spamassassin restart
service spamass-milter restart

Razor2 und Pyzor

Razor2 und Pyzor sind zwei Add-Ons für SpamAssassin. Sie erweitern die Fähigkeit Spam auszusortieren, indem auf zwei AntiSpam-Datenbanken zurückgegriffen wird, die ständig erweitert werden. Einmal eingerichtet, muss man sich nicht weiter um die beiden kümmern.

Zuerst werden die benötigten Verzeichnisse angelegt:

mkdir /var/lib/spamassassin/.razor
mkdir /var/lib/spamassassin/.pyzor

Laut der Dokumentation[7. Using Pyzor] braucht es nur ein Kommando, um Pyzor in Gefechtsbereitschaft zu versetzen.

pyzor --homedir /var/lib/spamassassin/.pyzor discover

Um Razor in Gefechtsbereitschaft zu versetzen, bedarf es nur weniger Kommandos mehr:

razor-admin -home=/var/lib/spamassassin/.razor -register
razor-admin -home=/var/lib/spamassassin/.razor -create
razor-admin -home=/var/lib/spamassassin/.razor -discover

Der Datei /var/lib/spamassassin/.razor/razor-agent.conf ist folgende Zeile hinzuzufügen:

razorhome = /var/lib/spamassassin/.razor

Das wars…fast…noch zwei Kommandos und SpamAssassin ist klar zum Gefecht.

chown -R spamd:spamd /var/lib/spamassassin
service spamassassin restart
service spamass-milter restart

Training für SpamAssassin

Die Filter von SpamAssassin lernen selbstständig. Doch kann man den Lernprozess durch aktives Training unterstützen. Dazu lässt man eine gewisse Menge an E-Mails durch das Hilfsprogramm sa-learn analysieren.

Hat man z.B. nur solche E-Mails im Posteingang, bei denen es sich ganz sicher nicht um Spam handelt, kann man SpamAssassin wie folgt darauf trainieren, dass es sich dabei nicht um Spam handelt:

sa-learn --ham /path/to/your/inbox/on/the/server --progress

Genau so gut funktioniert das andersherum. Hat man einen Ordner, der ausschließlich Spam-Mails enthält, kann man den Filter wie folgt trainieren:

sa-learn --spam /path/to/directory/of/spam --progress

Der Trainingsprozess ist am effektivsten, wenn man ca. je 1.000 Nachrichten Spam und echte E-Mail hat. Der Filter wird sogar erst dann aktiv genutzt, wenn sich mindestens 200 Spam-Mails in der Datenbank befinden. Das Training kann man beschleunigen, indem man Mails aus seinem Google-Postfach mit Hilfe von Google exportiert, in ein Verzeichnis auf dem Server entpackt und das Trainingsprogramm auf dieses Verzeichnis anwendet.[8. Download a copy of your Gmail and Google Calendar data] Führt man das Lernprogramm als root aus, muss man anschließend sicherstellen, dass alle Dateien in /var/lib/spamassassin/.spamassassin dem Benutzer spamd gehören.

Falls man SpamAssassin versehentlich mal falsch angelernt hat, kann man dies auch wieder rückgängig machen, in dem man das oben genannte Kommando mit der Option –forget auf die betroffene Menge Nachrichten anwendet.

ClamAV

Mit ClamAV wird ein Virenscanner in Stellung gebracht, der E-Mails und Anhänge auf Schädlingsbefall hin untersucht. Damit ClamAV die die E-Mail-Anhänge auch auf Virusbefall untersuchen kann, werden neben dem Milter auch noch eine ganze Reihe an Dekomprimierungsprogrammen installiert.

apt-get install clamav-milter arj bzip2 cabextract cpio file gzip lha lzop nomarch p7zip pax rar rpm unrar unzip zip zoo

Nach der Installation sind Änderungen an der Konfigurationsdatei /etc/clamav/clamav-milter.conf vorzunehmen. Die folgenden Zeilen sind auszukommentieren und durch die Zeilen im zweiten Codeblock zu ersetzen.

MilterSocket /var/run/clamav/clamav-milter.ctl
...
OnInfected Quarantine 
...
LogFacility LOG_LOCAL6

MilterSocket /var/spool/postfix/clamav/clamav-milter.ctl
...
OnInfected Accept 
...
LogFacility LOG_MAIL

Die erste Option gibt an, wo der Socket erstellt wird, der auf E-Mails von Postfix wartet. Da wie bei allen anderen Miltern auch der Socket innerhalb des Postfix chroot jail liegen muss, legt man das Verzeichnis für den Socket wie folgt an und setzt die Benutzerrechte entsprechend.

mkdir /var/spool/postfix/clamav
chown clamav:root /var/spool/postfix/clamav/

Die nächste Option erlaubt es, Nachrichten mit infiziertem Inhalt weiterzuleiten, statt sie in Postfix Warteschlange zu belassen. Denn um diese soll sich später Sieve kümmern. Zum Schluss wird ClamAV angewiesen, das Log von Postfix zu verwenden, um bei Problemen nur an einer Stelle suchen zu müssen.

Nun wird noch die Zeile

SOCKET_RWGROUP=postfix

in der Datei /etc/default/clamav-milter einkommentiert. Jetzt ist es Zeit für einen Neustart.

service clamav-daemon restart
service clamav-milter restart

ClamAV beinhaltet freshclam, um automatisch die Virusdefinitionen zu aktualisieren. Zum Abschluss sollte man sich vergewissern, dass der Updatemechanismus korrekt funktioniert. In der Logdatei /var/log/clamav/freshclam.log sollte in etwa folgende Ausgabe zu finden sein:

--------------------------------------
freshclam daemon 0.97.8 (OS: linux-gnu, ARCH: x86_64, CPU: x86_64)
ClamAV update process started at Sun Mar 16 18:32:49 2014
WARNING: Your ClamAV installation is OUTDATED!
WARNING: Local version: 0.97.8 Recommended version: 0.98.1
DON'T PANIC! Read http://www.clamav.net/support/faq
Downloading main.cvd [100%]
main.cvd updated (version: 55, sigs: 2424225, f-level: 60, builder: neo)
Downloading daily.cvd [100%]
daily.cvd updated (version: 18609, sigs: 824724, f-level: 63, builder: neo)
Downloading bytecode.cvd [100%]
bytecode.cvd updated (version: 236, sigs: 43, f-level: 63, builder: dgoddard)
Database updated (3248992 signatures) from db.local.clamav.net (IP: 207.57.106.31)
--------------------------------------

Nach der Konfiguration der ganzen Milter ist es jetzt noch nötig, diese in Postfix zu aktivieren. Dazu sind folgende Zeilen in der Datei /etc/postfix/main.cf einzukommentieren und die Konfiguration neu zu laden.

milter_default_action = accept
milter_connect_macros = j {daemon_name} v {if_name} _
non_smtpd_milters = $smtpd_milters
smtpd_milters = unix:/spamass/spamass.sock unix:/clamav/clamav-milter.ctl unix:/opendkim/opendkim.sock

service postfix reload

DNS Konfiguration

Ohne DNS funktioniert kein E-Mailsystem. Damit der Mailserver erreichbar ist, muss im DNS-Manager des eigenen Domainproviders ein MX-Record angelegt werden, welcher auf die öffentliche IP-Adresse oder einen A-Record des eigenen Mailservers zeigt.

Wie genau man einen DNS-Eintrag für die eigene Domain erstellt, ist von Anbieter zu Anbieter unterschiedlich. Zieht dazu am besten die Anleitung bzw. Hilfe eures Anbieters zu Rate. Ich werde am Ende dieses Abschnitts beispielhaft noch ein Bild meines DNS-Providers einfügen.

Als Nächstes wird noch ein TXT-Eintrag benötigt, welcher den öffentlichen DKIM Schlüssel beinhaltet. Dazu kann der Inhalt der Datei /etc/opendkim/mail.txt verwendet werden. Bitte zieht im Zweifel auch hierbei die Hilfe eures DNS-Anbieters zu Rate. Dort sollte beschrieben werden, wie ihr diesen Eintrag am besten erstellt.

Es folgt noch der Eintrag für die Funktionalität des SPF.

dns configuration

Beispielhafte DNS-Konfiguration im Interface von Goneo.

Im obigen Bild sind insgesamt 5 DNS Einträge zu sehen. Bei den ersten beiden Einträgen handelt es sich um einen A-Record für IPv4 und einen AAAA-Record für IPv6. Mit diesen Einträgen wird den IP-Adressen ein Name zugeordnet. Diese beiden Einträge sind nicht zwingend notwendig, man kann sich einen Namen jedoch leichter merken als eine IP-Adresse. In der dritten Zeile sieht man den MX-Record. Dieser gibt Auskunft darüber, welcher Server für die E-Mails einer Domain zuständig ist. Existiert für die Domain kein A-Record, muss hier eine IP-Adresse angegeben werden. Andernfalls kann man, wie in diesem Beispiel, auch einen Namen verwenden.

In Zeile 4 steht der TXT-Eintrag für das Sender Policy Framework (SPF)[10. Sender Policy Framework (SPF) bei Wikipedia] Hier wird festgelegt, welche Server E-Mails für die genannte Domain versenden dürfen.

Und in der letzten Tabellenzeile steht der Eintrag, welcher den öffentlichen DKIM-Schlüssel enthält. Der Name des Eintrags wird dabei nach dem Muster <selector>._domainkey.<domainname.tld> gebildet. Als Wert wird der öffentliche Schlüssel verwendet. Damit kann ein fremder Mailserver die Signatur der E-Mails überprüfen, die von dem eigenen Mailserver versendet werden.

Ein sehr wichtiger Schritt in der DNS Konfiguration fehlt jedoch noch. Es sollte unbedingt noch ein passender PTR-Record konfiguriert werden, welcher ein Reverse-Lookup der IP-Adresse des Servers erlaubt. Fast alle E-Mail-Server versuchen, mit einem Reverse-Lookup die IP-Adresse eines Servers in einen DNS Namen aufzulösen. Entspricht der aufgelöste Name nicht dem Namen aus dem Forward-Lookup, werden die meisten Mailserver die eingehende E-Mail abweisen. Dies ist eine übliche Vorgehensweise, um den Versand von Spam einzudämmen. Denn Spam wird oft von gekaperten Maschinen versendet, oder von Servern, wo sich der Spammer nicht die Mühe macht, den PTR korrekt zu konfigurieren.

dns-reverse

PTR-Einträge für IPv4 und IPv6

Der Screenshot zeigt einen Ausschnitt aus dem DNS-Konfigurationstool von Strato. Es zeigt zwei PTR-Einträge. Jeweils einen für IPv4 und einen für IPv6.

Konsultiert die Hilfe oder den Support eures Anbieters, wenn sich das Menü mit den entsprechenden Konfigurationsmöglichkeiten nicht auf Anhieb finden lässt.

Angeblich gibt es auch noch Hosting-Provider, die ihren Kunden das Recht vorenthalten, einen PTR-Eintrag zu setzen. In diesem Fall kann man sich entweder damit abfinden, dass es mit dem eigenen E-Mailserver nichts mehr wird, oder man wechselt den Hosting-Provider.

Mit E-Mail Filtern gegen Spam

Wir sind nun im letzten Abschnitt von Teil 3 dieser Artikelreihe angelangt. Zum Abschluss kommt die Konfiguration von Sieve, welcher zwei Dinge erledigen soll:

  1. E-Mails filtern, die von SpamAssassin als Spam markiert wurden.
  2. E-Mails filtern, die von ClamAV als virusinfiziert markiert wurden.

Sieve Filter finden sich an mehreren Stellen. Jeder virtuelle Benutzer kann eigene Filter im virtuellen E-Mail Home-Verzeichnis haben (das ist /var/mail/vmail/domainname/Benutzername/sieve). Global definierte Filter befinden sich in /var/mail/vmail/sieve-before und /var/mail/vmail/sive-after. Die Filterregeln in sieve-before werden vor den benutzerdefinierten Filtern angewendet, die in sieve-after nach diesen.

Ich erstelle einen ersten Filter im Verzeichnis /var/mail/vmail/sieve-before, indem ich die Datei masterfilter.sieve erstelle und mit folgendem Inhalt fülle:

# cat masterfilter.sieve 
require ["envelope", "fileinto", "imap4flags", "regex"];
 
# I don't even want to see spam higher than level 10
if header :contains "X-Spam-Level" "**********" {
    discard;
    stop;
}
 
# Twitter? Die in a fire.
if anyof (envelope "From" "bounce@tweet.twitter.com",
          envelope :contains "From" "@bounce.twitter.com") {
    discard;
    stop;
}
 
# Trash messages with improperly formed message IDs
if not header :regex "message-id" ".*@.*\\." {
    discard;
    stop;
}
 
# File low-level spam in spam bucket, and viruses in Infected folder
if anyof (header :contains "X-Spam-Level" "*****",
          header :contains "X-Virus-Status" "Infected") {
    if header :contains "X-Spam-Level" "*****" {
        fileinto "Junk";
        setflag "\\Seen";
    }
    else {
        fileinto "Infected";
    }
}

Sieve wendet die Filter sequentiell von oben nach unten an. Es spielt daher eine große Rolle, an welcher Stelle eine Filterregel erstellt wird.

Der erste Filter wertet das Spam-Scoring aus, welches von SpamAssassin durchgeführt und in den Header der E-Mails eingefügt wird. Dazu prüft der Filter das Feld „X-Spam-Level“ im Header einer E-Mail. Finden sich hier wenigstens zehn „*“, lässt Sieve die E-Mail verschwinden. Die Aktion wird in /var/log/mail.log protokolliert, doch nirgendwo sonst wird man etwas von dieser E-Mail zu Gesicht bekommen. Die Option stop sorgt dafür, dass die übrigen Mailfilter nicht mehr ausgewertet werden.

Der nächste Filter sortiert Twitter-Werbung aus. E-Mails zum Zurücksetzen des Passworts werden von diesem Filter nicht erfasst, da sie von einer anderen Absenderadresse kommen.

Darunter werden E-Mails abgefangen, die über keine gültige Message-ID verfügen. Dieser Filter nutzt reguläre Ausdrücke. In Sieve können reguläre Ausdrücke verwendet werden, die dem RFC 5228 entsprechen.[11. IETF RFC 5228]

Der letzte Filter funktioniert wie folgt. Er prüft, ob ein E-Mail Header entweder ein X-Spam-Level von 5 oder die Markierung „Infected“ enthält und verschiebt sie in den „Junk“-Ordner. E-Mails, die sowohl als Spam klassifiziert sind, als auch einen Virus enthalten, werden in den „Junk“-Ordner verschoben. Nur Mails, die nur einen Virus enthalten, aber nicht als Spam markiert sind, landen im Ordner „Infected“.

Sieve Filter sind extrem komplex. Es würde den Umfang dieser Artikelreihe sprengen, wenn ich versuche, sie allumfassend zu behandeln. Zum tieferen Verständnis empfehle ich die Quellen 12[12. Pigeonhole Sieve examples], 13[13. Sieve example rules von Tiger technologies] und 14[14. Sieve.info].

Die Datei masterfile.sieve wandeln wir in eine Binärdatei um. Dabei wird auch gleich eine Syntaxüberprüfung durchgeführt.

sievec masterfilter.sieve

Wird dieses Kommando als root ausgeführt, müssen die Besitzrechte wieder korrigiert werden.

chown vmail:vmail *.svbin

In Teil 4 dieser Artikelreihe werde ich noch darauf eingehen, wie man Sieve-Filter über das Webinterface von Roundcube erstellen kann, ohne sich in die Tiefen der RegEx-Syntax einarbeiten zu müssen.

Einrichtung eines E-Mail Clients (MUA)

Mit dem Ende dieses Artikels ist der Webserver bereits voll einsatzbereit und kann mit einem Mail User Agent genutzt werden. Dies ist ein guter Zeitpunkt, um ein Konto z.B. in Mozilla Thunderbird[15. Ubuntuusers Wiki: Thunderbird Einrichtung] einzurichten, um die Konfiguration zu testen. Die folgenden Screenshots zeigen exemplarisch, wie ein Konto in Thunderbird hinzugefügt wird.

Wer an dieser Stelle bereits die Nase voll hat von den doch recht langen Artikeln, kann sich bereits entspannt zurücklehnen. Denn er betreibt einen für das Internet gewappneten MTA, MDA und MUA mit Anti-Spam und Anti-Virus Modulen.

Ich werde in Teil 4 noch weitergehen und Webmail einrichten, um die konfigurierten Postfächer auch über einen Webbrowser nutzen zu können. Teil 4 wird sich außerdem mit der Möglichkeit beschäftigen, eine zertifikatsbasierte Anmeldung zu konfigurieren.

Wenn ihr ebenfalls noch weitermachen möchtet, sehen wir uns in einer Woche. ;-)