Mailserver auf Debian mit IMAP, Smarthost und Filter
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.
