Mailserver auf Debian mit IMAP, Smarthost und Filter

Spam tilgen mit Spamassassin

Jetzt widmen wir uns der schlimmsten Mailplage im Netz, dem Spam. Auch hier gibt es einige Möglichkeiten, gegen Spam anzutreten. Unter Linux hat sich als Filter das Programm Spamassassin etabliert. Wir wollen nun unseren Mailserver so konfigurieren, dass er eingehende Mails auf Spam untersucht, und sollte er der Meinung sein, dass es sich um Spam handelt, die Mails als Spam markiert und in einen eigenen Ordner Junk verschiebt. Der Benutzer hat dann die Möglichkeit, den Ordner weiterhin auf »Falsche Treffer« zu untersuchen, und löscht einfach den Rest heraus. Hier sind zumindest die Mails vorsortiert, und man geht dabei nicht das Risiko ein, dass vielleicht irgendwo noch erwünschte Mails einem generellen Löschvorgang zum Opfer fallen.

Zuerst installieren wir Spamassassin:

apt-get install spamassassin

Dies liefert uns noch weitere zahlreiche Pakete hauptsächlich aus dem Bereich Perl. Wenn die Pakete installiert sind, dann bauen wir erst einmal eine einfache Grundkonfiguration auf, die natürlich noch durch viele weitere ausgeklügelte Filtermaßnahmen erweitert werden kann. Wir editieren zuerst die Datei /etc/spamassassin/local.cf. Bei folgenden Zeilen entfernen wir das #, um sie zu aktivieren:

rewrite_header Subject *****SPAM*****
required_score 5.0
use_bayes 1
bayes_auto_learn 1
bayes_ignore_header X-Bogosity
bayes_ignore_header X-Spam-Flag
bayes_ignore_header X-Spam-Status

Unter die drei bayes_ignore-Zeilen schreiben wir noch folgende Zeile:

bayes_ignore_header X-getmail-filter-classifier

Das verhindert, dass Header-Erweiterungen von Getmail irgendwann als Spam ausgewertet und gekennzeichnet werden.

Jetzt editieren wir die Datei /etc/deafault/spamassassin. Dort ist der Eintrag ENABLED=0 auf ENABLED=1 zu ändern. Dies stellt sicher, dass der Filter beim Booten des Servers automatisch gestartet wird. Da dieser nach der Installation nicht angefahren wird, können wir den Spamfilter auch manuell scharf machen, ohne erst dafür unseren Server neu zu starten:

/etc/init.d/spamassassin start

Damit das alles über Getmail läuft, fügen wir der Getmail-Konfiguration unter .getmail folgende Filterregel hinzu:

[filter]
type = Filter_external
path = /usr/bin/spamc

Über Procmail lassen wir nun noch nach der Headererweiterung *****SPAM***** suchen. Dazu fügen wir folgende Regel (am besten als erste Regel unterhalb der Virenregeln) in der Datei ~/.procmailrc ein:

:0
* ^Subject:.******SPAM*****
.Junk/

Das sollte nun alle vom Spamassassin mit SPAM gekennzeichnete Mails in den Junk-Ordner schieben.

Hinweis: Da Procmail als Platzhalter ein Sternchen * verwendet, ist es auch ratsam, die Subject-Markierung auf ein anderes Symbol zu setzen, beispielsweise +++++SPAM+++++ . Man ändert dies in der Datei /etc/spamassassin/local.cf und in .procmailrc. Danach natürlich den Spamassassin neu starten:

/etc/init.d/spamassassin restart

Woran sieht man nun, ob der Spamfilter läuft? Hierzu schickt man sich einfach eine Testmail. Als Betreff nimmt man die entsprechende Änderung, die Spamassassin einfügen würde, wenn Spam erkannt würde (also beispielsweise +++++SPAM+++++). Das zeigt uns, ob Procmail wie gewünscht filtert und die Mail in den Junk-Ordner verschiebt. Wenn die Mail dann im Junk-Ordner liegt, sehen Sie sich den Quelltext an. Im Header der Mail sollte etwa Folgendes stehen:

X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on myserver
X-Spam-Level: *
X-Spam-Status: No, score=1.5 required=5.0 tests=AWL,SPF_FAIL autolearn=no
 version=3.2.5

Hier sieht man, dass Spamassassin aktiv war und seinen Score (1.5) eingetragen hat. Daneben steht der benötigte Score, damit die Mail als Spam markiert wird. Man kann jetzt abwarten, ob diese Konfiguration auf Dauer genügt, oder ob man noch ein paar Goodies einbauen will.

Skript-Erweiterungen

An dieser Stelle will ich noch ein paar Konfigurationserweiterungen für Spamassassin, procmail und getmail bringen.

Openprotects Spamassassin Updates einbauen

Um immer auf dem Laufenden zu bleiben, empfiehlt es sich, nun auch die aktuellen Filterregeln parat zu haben. Diese lassen sich recht einfach einbauen. Stellen Sie zunächst sicher, dass die TCP-Ports 8090 und 11371 für ausgehende Pakete offen sind. Dann folgende Befehle ausführen (bitte vorher hier prüfen, ob die öffentlichen Schlüssel noch aktuell sind):

gpg --keyserver pgp.mit.edu --recv-keys BDE9DC10
gpg --armor -o pub.gpg --export BDE9DC10
sa-update --import pub.gpg

Um nun regelmäßig das Update durchzuführen, kann man ein Skript anlegen. Dieses schickt dann auch jeweils eine E-Mail, wenn alles geklappt hat.

Einfach unter /usr/local/bin das Skript spamupdater mit folgendem Inhalt anlegen:

#!/bin/sh
# alte Logdatei loeschen
rm /var/log/spamupdate.log
# Updates herunterladen.
sa-update --allowplugins --gpgkey D1C035168C1EBC08464946DA258CDB3ABDE9DC10 \
--channel saupdates.openprotect.com --channel updates.spamassassin.org
# Spamassasin-Dienst neu starten
/etc/init.d/spamassassin restart >> /var/log/spamupdate.log
# Uhrzeit eintragen
echo "" >> /var/log/spamupdate.log
date >> /var/log/spamupdate.log
# Statusmail versenden
mail -a "Content-Type: text/plain; charset=UTF-8" -s "[System] \
Spamupdate" name@adresse < /var/log/spamupdate.log

Das Skript muss ausführbar gemacht werden:

chmod +x /usr/local/bin/spamupdater

Das Skript soll von Cron aufgerufen werden, dazu ändern wir die Crontab von root:

crontab -e

Wir fügen folgende Zeile hinzu:

1 5 * * * /usr/local/bin/spamupdater > /dev/null

Das Update wird dann jeden Tag um 5.01 Uhr ausgeführt. Wer nur im Fehlerfall eine Mail erhalten will, lässt den Aufruf von mail in der letzten Zeile des Skripts weg.

Mails mit speziellen Anhängen filtern

Manche Anhänge einer Mail sind potentielle Risiken. Hier kann man, um die Aufmerksamkeit ein wenig zu heben, solche Mails gleich von Haus aus in einen speziellen Ordner (z.B. dangerous) verschieben. Der Benutzer sieht dann gleich, dass man hier besondere Vorsicht walten lassen sollte im Umgang mit einer derartigen Mail. Der Code für .procmailrc würde so aussehen:

:0 B:
*
name=.*\.(vbs\"|wsf\"|exe\"|vbe\"|src\"|rar\"|dll\*)
.dangerous/

Dies lässt sich natürlich noch erweitern. Die Regel sollte recht weit nach oben unter der Spamregel stehen.

Gargis Schlusswort

Das soll uns nun für einen Mailserver genügen, der sowohl von außen als auch vom internen Netz zu erreichen ist. Dass man hier noch einiges an Finetuning betreiben kann, ist klar. Aber ein Gerüst für einen funktionierenden Mailverteiler ist das allemal und sollte im Homebereich und für kleine Büros sicher genügen. Einen echten SMTP aufzubauen, wäre der nächste Schritt. Nur wird man sich nach wie vor schwer tun, einen Server ohne vollständigen Domänen-Namen im Netz ernsthaft als Mailserver zu betreiben, da die Mails schneller auf den Spamlisten landen, als Sie Spam aussprechen können. Aber das ist auch nicht nötig, denn für den Hausgebrauch reicht das dicke!

Referenzen

Dieses Tutorial ist auf Gargi.org erschienen. Aktualisierungen erscheinen zuerst dort. Veröffentlichung mit freundlicher Genehmigung des Autors.