Mailserver 5 von 10: Spamprüfung mit SpamAssassin

Jahrelang habe ich mich davor gedrückt, doch endlich ist es geschafft - die Einrichtung eines eigenen Mailservers. In einer kleinen Artikelserie möchte ich einmal meine Erfahrungen und Konfigurationsschritte festhalten. Diese Serie basiert auf zahllosen Tutorials, Best Practices, Gesprächen mit Mailserver-Betreibern, aus endlosem Dokumentationen lesen und dem Wissen der Bücher "Postfix" von Kyle D. Dent und "Postfix - Einrichtung, Betrieb und Wartung" von Ralf Hildebrandt und Patrick Ben Koetter. Vielleicht werden sie ja nützlich für andere Leute sein, die das gleiche erreichen wollen.

Doch eines vorab: Die Einrichtung und der Betrieb eines Mailservers ist eine komplexe Sache. Klar, die Software lässt sich schnell installieren, doch fertig ist man danach noch lange nicht, wenn man ernsthaft damit arbeiten möchte.

Der Fahrplan der Artikelserie:

  1. Einleitung
  2. Mailempfang und Mailversand mit Dovecot und Postfix
  3. Virenprüfung mit ClamAV
  4. Mailsignatur mit OpenDKIM
  5. Spamprüfung mit SpamAssassin
  6. Mailabruf mit Dovecot
  7. Mailboxen konfigurieren mit mailconf.phs
  8. Mails synchronisieren mit mailsync.phs
  9. Mailqueue überwachen mit mailqueue.phs
  10. SpamAssassin anlernen mit maillearn.phs

Nachdem wir im letzten Artikel unseren DKIM-Milter eingebunden haben, werden wir uns heute um den letzten Milter kümmern - den SpamAssassin Milter zum Filtern von Spamnachrichten.

Wieder werden wir als erstes das nötige Paket installieren und anschließend alles stoppen, bis die Konfiguration fertig ist. Damit können wir sicherstellen, dass wirklich alle Änderungen übernommen werden. Zudem müssen wir ein Home-Verzeichnis anlegen, da dies vom Package nicht automatisch gemacht wird:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
sudo apt-get update

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

sudo /etc/init.d/spamassassin stop
sudo /etc/init.d/spamass-milter stop

sudo /etc/init.d/dovecot stop
sudo /etc/init.d/postfix stop

sudo mkdir /var/lib/spamass-milter/
sudo chown spamass-milter /var/lib/spamass-milter/

sudo mkdir /var/lib/spamass-milter/.spamassassin/
sudo chmod 700 /var/lib/spamass-milter/.spamassassin/
sudo chown spamass-milter /var/lib/spamass-milter/.spamassassin/

Leider scheint sich der Paketverantwortliche auch nicht sonderlich um ordentliche Ablageorte für die Konfigurationsdateien zu kümmern. Diese liegen verstreut im Ordner "/etc/spamassassin/", sowie in den beiden Dateien "/etc/default/spamassassin" und "/etc/default/spamass-milter". Sehr gruselig das ganze.

Sehen wir uns als erstes einmal die Datei "/etc/spamassassin/local.cf" an. Dort werden grundlegende - vom Nutzer angepasste - Spamassassin-Konfigurationen abgelegt. Diese Datei ist bei mir ziemlich kurz geraten:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
report_contact  postmaster@example.com
report_hostname send.example.com

bayes_auto_learn 0

loadplugin Mail::SpamAssassin::Plugin::DKIM
loadplugin Mail::SpamAssassin::Plugin::Shortcircuit
loadplugin Mail::SpamAssassin::Plugin::SPF

ifplugin Mail::SpamAssassin::Plugin::SPF
ignore_received_spf_header 1
endif # Mail::SpamAssassin::Plugin::SPF

ifplugin Mail::SpamAssassin::Plugin::Shortcircuit
shortcircuit BAYES_99 spam
shortcircuit BAYES_95 spam
shortcircuit BAYES_80 spam

shortcircuit BAYES_00 ham
shortcircuit BAYES_05 ham
shortcircuit BAYES_20 ham
endif # Mail::SpamAssassin::Plugin::Shortcircuit

Die einzelnen Felder sind schnell erklärt:

  • report_contact: Der Spamassassin Milter erstellt - je nach Konfiguration - einen Spamreport. Dieser Report enthält einen Ansprechpartner, dessen E-Mail-Adresse wir mit dieser Option setzen.
  • report_hostname: Der Spamreport enthält auch den Hostnamen des Servers, der den Scan durchgeführt hat. Zudem setzt der SpamAssassin Milter bei Spamverdacht einen E-Mail-Header, der ebenfalls den Hostnamen enthält.
  • bayes_auto_learn: SpamAssassin enthält eine Spamerkennung auf Basis von Bayesian Networks - ein Standardkonstrukt im Maschinenlernen. Dieses Netzwerk lernt man typischerweise mit Echtdaten an und das Netzwerk versucht daraufhin, eigene Entscheidungen zu treffen. Spamassassin bietet die Möglichkeiten, dass getroffene Entscheidungen als neue Fakten ins Netzwerk aufgenommen werden. Das kann jedoch zu schlecht angelernten Netzwerken führen. In Artikel 10 werden wir uns tiefer mit diesem Anlernen beschäftigen. (P.S.: In meinem Studium habe ich selbst mal solch ein Bayesian Network implementieren dürfen.)
  • loadplugin: Wir stellen sicher, dass das DKIM-, Shortcircuit und SPF-Plugin geladen wird.
  • ignore_received_spf_header: Wir wollen empfangene Received-SPF Header ignorieren. Wir stellen damit sicher, dass der SPF-Check nicht durch absichtlich mitgeschickte Header manipuliert wird.
  • shortcircuit: Wir werden den Bayes-Filter später ordentlich anlernen. Wenn dieser dann normal arbeitet und eine E-Mail relativ eindeutig als Spam (80% bis 99%) oder relativ eindeutig als Ham (0% bis 20%) erkennt, soll diese Einordnung auf der Grundlage unserer eigenen Erkenntnisse natürlich ein entsprechendes Gewicht bei der Spamerkennung haben. Damit stellen wir sicher, dass unsere eigene Ham-/Spam-Einschätzung die Regeln von SpamAssassin überstimmt.

Wie auch schon beim ClamAV Milter ist der SpamAssassin Milter zweigeteilt. Es gibt zum einen einen Dienst (spamd), dem Nachrichten zum Spamscanning übergeben werden können und einen weiteren Dienst (spamass-milter), der die Milter-Schnittstelle implementiert und die Anfragen an den eigentlichen Scanner weiterreicht.

Als erstes konfigurieren wir den spamd Dienst, der für das eigentliche Scannen zuständig ist. Die zugehörige Konfiguration befindet sich in der Datei "/etc/default/spamassassin". Auch diese fällt relativ kurz aus:

1
2
3
4
5
6
7
8
9
ENABLED=1

SAHOME="/var/lib/spamassassin"

OPTIONS="-x -H ${SAHOME} -m 5 -i 127.0.0.1 -p 10011 -A 127.0.0.1 -u debian-spamd -g debian-spamd"

PIDFILE="/var/run/spamd.pid"

CRON=1

Schuld daran, dass diese Konfiguration so unleserlich ist, ist der Package-Verantwortliche, der die hier gesetzten Variablen einfach im Init-Script "/etc/init.d/spamassassin" heranzieht. Typischerweise würde man das hübscher gestalten. Naja, kann man leider nichts machen. Hier jedenfalls die grobe Erklärung:

  • ENABLED: Es muss explizit gesetzt werden, dass der spamd Dienst starten darf - warum auch immer. Das ganze ist so schlecht implementiert, dass - sollte man den Dienst starten und diesen Wert auf "0" setzen - man den Dienst nicht mehr stoppen kann.
  • OPTIONS: Hier wird im Grunde die gesamte Konfiguration abgebildet, mit der der spamd Dienst gestartet wird. Wichtig ist, dass hier definiert wird, dass der spamd Dienst auf der Adresse "127.0.0.1:10011" erreichbar ist (Parameter "-i" und "-p"), dass Zugriffe von der Adresse "127.0.0.1" aus erlaubt sind (Parameter "-A") und dass der Dienst als Nutzer "debian-spamd" gestartet wird (Parameter "-u" und "-g")
  • CRON: Sollten sich die Filterregeln von Spamassassin ändern, so werden diese jede Nacht neu eingelesen.

Nun muss noch der eigentliche Milter konfiguriert werden. Das wiederum geschieht in der Datei "/etc/default/spamass-milter", die leider das gleiche unschöne Format wie die vorherige Konfigurationsdatei hat. Glücklicherweise ist auch diese Datei recht kurz:

1
2
3
4
5
OPTIONS="-u spamass-milter -m -- -d 127.0.0.1 -p 10011"

SOCKET="inet:10010@127.0.0.1"
SOCKETOWNER=""
SOCKETMODE=""

Hier die kurze Erklärung:

  • OPTIONS: Auch hier wird direkt die Konfiguration an den Milter-Dienst übergeben. Wir sagen im Grunde, dass nur E-Mail-Header gesetzt werden dürfen (Parameter "-m"). Der Milter nutzt den Client spamc, um mit dem spamd Dienst zu sprechen. Alle Parameter hinter dem "--" werden an diesen spamc Client weitergereicht. Das ist in diesem Fall nur die Information, dass der spamd Dienst auf der Adresse "127.0.0.1:10011" erreichbar ist (Parameter "-d" und "-p").
  • SOCKET: Hier geben wir an, dass der Milter auf der Adresse "127.0.0.1:10010" erreichbar sein soll.
  • SOCKETOWNER und SOCKETMODE: Das Init-Script des Paket-Verwalters ist SO dermaßen schlecht, dass es standardmäßig davon ausgeht, dass der Milter nicht per TCP/IP, sondern per Unix-Socket erreichbar ist. Aus diesem Grund müssen diese zwei Parameter explizit als leer angegeben werden - ansonsten hagelt es Fehlermeldungen beim Starten.

Damit sind wir glücklicherweise auch schon fertig mit der Konfiguration. Jetzt muss nur noch Postfix mitgeteilt werden, dass er den Milter aufrufen soll. Dazu öffnen wir die Datei "/etc/postfix/main.cf" und ändern folgende Konfiguration ab:

1
2
3
4
5
6
smtpd_milters     = inet:127.0.0.1:10010
                    inet:127.0.0.1:10020
                    inet:127.0.0.1:10030
non_smtpd_milters = inet:127.0.0.1:10010
                    inet:127.0.0.1:10020
                    inet:127.0.0.1:10030

Jetzt noch den Milter und den Mailserver wieder starten:

1
2
3
4
5
sudo /etc/init.d/spamassassin start
sudo /etc/init.d/spamass-milter start

sudo /etc/init.d/dovecot start
sudo /etc/init.d/postfix start

Um zu testen, ob ihr alles richtig konfiguriert habt, könnt ihr euch im ersten Schritt einmal eine Mail zusenden. Diese sollte dann folgende Zeilen enthalten:

1
2
3
X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY
    autolearn=disabled version=3.3.2
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on send.example.com

Ähnlich wie beim Virenscanner gibt es auch bei Spamscannern eine Möglichkeit, die Funktionsfähigkeit zu testen. Dieser Test nennt sich GTUBE. Sendet euch eine Test-E-Mail mit dem GTUBE-String zu. Die Header sollten sich wie folgt ändern:

1
2
3
4
5
X-Spam-Flag: YES
X-Spam-Status: Yes, score=1000.0 required=5.0 tests=GTUBE,TVD_SPACE_RATIO,
    UNPARSEABLE_RELAY autolearn=disabled version=3.3.2
X-Spam-Level: **************************************************
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on send.example.com

Ist das der Fall? Dann herzlichen Glückwunsch! Du hast so eben deinen Mailserver mit einem Spamscanner ausgerüstet. 🙂

Damit haben wir vorerst alles wichtige bezüglich des Mailemfangs und des Mailversands installiert, konfiguriert und getestet. Im nächsten Artikel wird es deshalb darum gehen, wie man denn nun die empfangenen E-Mails mit Hilfe von Dovecot abrufen kann.

Update:
Der Bayes-Filter hat nun einen wesentlich stärkeren Einfluss auf die Bewertung von Spam- und Ham-Mails.

Update:
SpamAssassin führt nun auch selbst DKIM- und SPF-Checks durch.

Spamfreie Grüße, Kenny

Schreibe einen Kommentar

Um Ihnen beim weiteren Kommentieren auf dieser Webseite die erneute Eingabe Ihrer Daten zu ersparen, wird beim Absenden Ihres Kommentars ein Cookie an Ihren Browser gesendet und von diesem gespeichert. Mit dem Absenden eines Kommentars auf dieser Webseite stimmen Sie der Speicherung und Übertragung dieses Cookies explizit zu.

Pflichtfelder sind mit * markiert.