SPAM-Abwehr: Ein einfaches Rezept
In Zeiten lawinenartig zunehmenden SPAM’s im Internet stellt sich für
jeden Email-Nutzer die Frage, wie er sich demgegenüber verhalten soll.
Da ist zum einen die Strategie, die eigene Mailadresse möglichst geheim zu
halten um zu vermeiden, das Ziel von SPAMMERN zu werden, sowie der Ausweg,
von Zeit zu Zeit den Provider bzw. die Mailadresse zu wechseln.
Beide Rezepte haben den Nachteil, dass sie zum einen auch die gewünschte Kommunikation
mit Freunden/Bekannten erschweren bzw. unmöglich machen und zudem ist deren
Wirksamkeit auch immer nur eine Frage der Zeit - ausser dann, wenn man grundsätzlich
niemandem die eigene Mailadresse gibt, nirgendwo was reinschreibt und immer dafür sorgt,
dass niemand, der die Adresse (doch) kennt, dies tut.
In diesem Fall braucht man aber erst garkein Email - Problem gelöst
Obwohl in letzter Zeit auch bei Gesetzgebern und Regierungen die Einsicht wächst, dass
SPAM ein gravierendes Problem für eine freie Informationsgesellschaft ist,
das gelöst werden sollte, ist die Hoffnung auf dahingehende Lösungen
gering - das kann noch Jahre dauern bis sich da soviel bewegt, dass den meisten SPAMMERN
das Handwerk gelegt wird.
Also bleibt nur die Möglichkeit, selbst etwas zu tun - und zwar AKTIV und nicht durch
‘Flucht’ wie oben beschrieben.
Im Weiteren sollen hier einige praktikable Möglichkeiten der SPAM-Abwehr beschrieben werden,
ohne Anspruch auf Vollständigkeit.
Ideale Voraussetzungen haben diejenigen, die selber einen permanenten Mailserver
im Internet betreiben (‘Rootserver’) - hier kann man durch entsprechende Filterprogramme
dafür sorgen, dass der meiste SPAM erst garnicht die Mailbox der Enduser erreicht,
sondern schon vorher gelöscht wird.
Doch wer hat diesen Luxus schon - ich nicht …
Nächste Stufe ist ein ISP, der schon eingebaute SPAM-Abwehrfunktionen hat,
die ggf. auch individuell z.B. über ein Webinterface konfigurierbar sind,
wie dies z.B. bei gmx.de bzw. web.de der Fall ist.
Leider ist die Effektivität dieser Filter meist begrenzt, einmal bedingt durch Rechenzeit,
zum Anderen dadurch, dass ein grosser Provider es sich nicht leisten kann,
zu strenge Filter anzuwenden, da dann evtl. versehentlich ’echte’ Mails
gelöscht werden.
Daher ist ein eigenes SPAM-Abwehr System in jedem Fall anzuraten, sofern
man nicht kommerzielle Angebote (wie z.B. von T-Offline oder Spamcop),
auf die ich hier nicht näher eingehen will, nutzen möchte.
Beim Aufbau eines eigenen Systems gibt es verschiedene Möglichkeiten, deren Vor-und Nachteile
ich hier kurz ansprechen möchte.
Die praktische Umsetzung erfolgt hier auf einem Linux-Mailserver, der sich auch sehr
gut für ein heterogenes Netzwerk eignet.
Besonders wichtig für User mit geringer Bandbreite (Modem,ISDN) sind Filter,
die VOR dem Download der Mails auf den Server des Providers zugreifen, die also zu untersuchende Mails
nicht erst ‘runterladen’ müssen, sondern offensichtlichen SPAM gleich dort
erledigen - das spart echte Downloadzeit !
Nachteil ist hier dass diese Programme, da sie nicht direkt auf dem Server laufen,
lediglich Zugriff auf den sog. ‘Header’ einer Email haben
(zumindest bei sog. ‘POP’-Postfächern, und das sind die meisten), anhand derer aber doch
schon eine effektive Vorsortierung gemacht werden kann, Beispiele hierfür sind
Mailfilter
oder Swendeleter.
Effektiver sind nat. Filter, die zur Analyse auch auf den Inhalt der Mails Zugriff haben,
dazu müssen diese halt erstmal heruntergeladen werden.
Ist das erledigt, kann man nun mit ‘schwerem Geschütz’ auffahren.
Als solches kann man z.B. Spamassassin
oder Bogofilter einsetzen.
Nachdem ich bisher mit recht gutem Erfolg Spamassassin eingesetzt habe, bin ich
neuerdings zu Bogofilter gewechselt - der ist im Vergleich zu Spamassassin rasend schnell
(ist halt C statt Perl
), und ausserdem ist dessen ‘Selbstlernfunktion’ superb:
einmal mit ca. 100 SPAMMAILS gefüttert, lässt er kaum noch Schrott durch,
ohne einen einzigen Fehlgriff !
Damit das Ganze auch ordentlich funktioniert, ist es am besten, eine Kombination
der genannten Verfahren einzusetzten, womit die Effektivität erheblich gesteigert wird,
und ebenso der Komfort - der Anwender will sich schliesslich möglichst wenig mit dem
leidigen Thema beschäftigen.
Um das alles zu erreichen, habe ich meine Infrastruktur folgendermassen konfiguriert:
- Vorab mit swendeleter beim ISP die z.Zt. 'dicksten Brocken', die in meine Mailbox wollen, löschen
- Abholen des 'Restes' mit Fetchmail
- Weiterverarbeiten mit Procmail
- Bereitstellen mit Imap - mehr Infos hierzu siehe auch Anhang C
Statt einer umfangreichen Linksammlung zum Thema verweise ich lieber auf:
- Google - frei nach dem Motto: STFW
Anhang A - Konfigurationsfiles:
fm.sh - Ablaufscript:
#!/bin/bash
PATH=\$PATH:/usr/local/bin
export host=mein.mailserver.de
ping -c 1 \$host # erstmal 1 ping, ggf. router 'aufwecken'
# und hier lernt bogofilter neuen SPAM und vernichtet ihn gleich...
find /mnt/pub/werner/imap/.SPAM/cur -type f | bogofilter -s -b
find /mnt/pub/werner/imap/.SPAM/new -type f | bogofilter -s -b
find /mnt/pub/werner/imap/.SPAM/ -type f -exec rm -f {} \;
# ab und zu sollte man hier 'gute' mails reinkopieren, damit bogofilter nicht verlernt wie die aussehen
find /mnt/pub/werner/imap/.HAM/cur -type f | bogofilter -n -b
find /mnt/pub/werner/imap/.HAM/new -type f | bogofilter -n -b
find /mnt/pub/werner/imap/.HAM/ -type f -exec rm -f {} \;
if (ping -c 1 \$host)
then
/usr/bin/perl /usr/bin/swendeleter.pl -s \$host -l werner -p xxxx -n
fetchmail -s -a
fi
crontab - steuerdatei f. cron zum automatischen Aufruf des o.g. scripts:
5,20,35,50 * * * * /home/werner/bin/fm.sh 1>/dev/null # This file was written by KCron. Copyright (c) 1999, Gary Meyer # Although KCron supports most crontab formats, use care when editing. # Note: Lines beginning with "#" indicates a disabled task.
~.fetchmailrc (Steuerdatei f. fetchmail):
# server + protokoll server mein.mailserver.de proto pop3 #user + passwort user werner pass xxxx # alles an procmail uebergeben mda /usr/bin/procmail
~.procmailrc (Steuerdatei f. procmail):
PATH=/bin:/usr/bin:/usr/local/bin:\$HOME/bin:/usr/sbin:/sbin: MAILDIR=/mnt/pub/werner/imap DEFAULT=\$MAILDIR/ # von bogofilter aussortierten mist erstmal in Trash - spaeter gleich nach /dev/null :0HB: * ? bogofilter -l .Trash/ # /dev/null # sobald bogofilter gut genug trainiert ist, gleich ab ins nirwana # gentoo-user-de in mailinglisten-Verzeichnis einsortieren :0HB: * ^List-Id:.*gentoo-user-de.gentoo.org .mailinglisten.gentoo/ # ebenso die f. lug-ketsch, hier ist List-Id nicht vorhanden :0HB: * ^To:.*ml\@lug-ketsch.de .mailinglisten.lug-ketsch/
Und last not least meine praktischen Erfahrungen mit der beschriebenen Konfiguration: Da ich relativ viel in kde/linux Mailinglisten unterwegs bin und dort auch schreibe, bekomme ich mittlerweile ungefähr 50 SPAM’s pro Tag, von der Viagra-Werbung bis zu Investments in Uganda… Seit mein bogofilter mit ca. 100 sample-SPAMS trainiert ist, kommt so ein- bis zweimal pro Woche noch einer durch, der irgendwie vom Schema bzw. ‘Wortschatz’ der schon ‘gelernten’ abweicht. Der kommt dann gleich in die SPAM-LERN-BOX, und das wars… Und das Beste daran: bogofilter ist rasend schnell - wo vorher der Spamassassin minutenlang rumgerödelt hat, braucht der gerademal 10 sec.
Anhang B - kmail zur Verwendung von bogofilter einstellen: Für alle, die sich nicht mit fetchmail/procmail/imap... beschäftigen wollen, und die kmail als mail-client verwenden, hier ist eine kurze Beschreibung, wie man kmail so einrichtet, dass es direkt bogofilter verwendet. Wer mehr wissen will: eine ausführliche deutsche Anleitung findet sich auf Pro-Linux, weitere Tips gibts hier: Kmail Tips site Kmail und bogofilter.
Screenshots zur Einstellung der Filter:
Zur Beachtung: das Ganze funktioniert nur, wenn bogofilter 'trainiert' wird, wie das geht, ist am obengenannten script 'fm.sh' zu sehen, dieses kann sowohl als cron-job automatisch als auch 'von Hand' ausgeführt werden. Wichtig ist auch, dass kmail zum Speichern im maildir-format eingestellt wird, in der Einstellung 'mailbox-format' wird das 'bogofilter-training' nicht funktionieren ! Als Zusatz zu den Screenshots füge ich hier auch noch den entsprechenden Abschnitt der Datei ~/.kde/share/config/kmailrc an:
[Filter #0] ConfigureShortcut=false Icon=gear StopProcessingHere=false action-args-0=bogofilter -ep action-name-0=filter app actions=1 apply-on=check-mail,manual-filtering contentsA=1 fieldA=funcA=greater-or-equal name=bogofilter operator=and rules=1 [Filter #1] ConfigureShortcut=false Icon=gear StopProcessingHere=true action-args-0=trash action-args-1=R action-args-2=O action-name-0=transfer action-name-1=set status action-name-2=set status actions=3 apply-on=check-mail,manual-filtering contentsA=Yes fieldA=X-Bogosity funcA=contains name=bogofilter_ist_spam operator=and rules=1
Anhang C - Einrichten des Courier-Imap Mailservers:
Die Dokumentation für Courier Imap ist generell sehr gut, also sollte jede(r) diese erstmal lesen. Die Installation selbst wird hier nicht behandelt, da dies sehr stark von der verwendeten Distri abhängt, für debian z.B.genügt ein einfaches ‘apt-get install courier-imap’ an der Kommandozeile, für Gentoo: ’emerge courier-imap’. Andere haben ihre eigenen Paket/Softwareinstallationsroutinen, worauf hiermit verwiesen sei. Nichtsdestotrotz gibt es derart viele Konfigurationsmöglichkeiten, dass manche(r) leicht durcheinander kommt und nicht sicher ist, welche er nehmen soll. Deswegen will ich hier kurz erklären welche ich verwendet habe und warum. Evtl. hilft das ja anderen, die Sache zum Laufen zu bekommen. Und so gehts:
Da jeder User in meinem Heimnetzwerk einen regulären Account auf dem Server, der auch f. Imap zuständig ist, hat, beschloss ich das ‘USERDB authentification’ Modul zu verwenden, wobei im Prinzip die schon im system vorhandenen Informationen für den ’normalen’ Login in /etc/passwd und /etc/shadow als Vorlage benutzt werden, um daraus die Imap-Login Daten zu erstellen. Zu diesem Zweck gibt es hilfreiche Skripte (makeuserdb, userdb, pw2userdb), die zusammen mit Courier-Imap installiert werden, und sie sind gut dokumentiert, deshalb möchte ich sie hier nicht weiter erklären. Der nächste Schritt ist, die notwendigen Verzeichnisse zu erstellen, in denen die Mails auf dem Server gespeichert werden sollen. Diese Verzeichnisse müssen eine ‘maildir’ genannte Struktur haben, um dies sicherzustellen, gibt es das Programm ‘maildirmake’, das die nötige Arbeit macht. Maildirmake muss f. jeden User-Account der Zugriff auf den Imap-Server haben soll, angewendet werden. Sobald das erledigt ist, muss die Datei /etc/userdb angepasst werden um die bisher gemachten Änderungen abzubilden. Danach wird /etc/userdb in ein binäres Format übersetzt, dazu wird das Programm’makeuserdb’ verwendet. Wenn alles klappt, stehen danach die beiden Dateien userdb.dat und userdbshadow.dat im /etc Verzeichnis z.V. - diese werden dann vom Imap-Server zur Authentifizierung der User verwendet. Bevor nun der Imap-authdaemon gestartet wird, muss noch die Datei /etc/courier/authdaemonrc angepasst werden damit der Daemon die richtige (USERDB) Methode anwendet:
#NAME: authmodulelist:0 # # The authentication modules that are linked into authdaemond. The # default list is installed. You may selectively disable modules simply # by removing them from the following list. The available modules you # can use are: authcustom authcram authuserdb authldap authmysql authpam authmodulelist="authuserdb"
Nun können wir den authdaemond server starten:
/etc/init.d/courier-imap start /etc/init.d/courier-authdaemon start
(diese init-scripts werden normalerweise durch die courier-imap installation erstellt).
Wenn das erledigt ist, müssen noch die mail-clients konfiguriert werden,
hier am Beispiel von Kmail erläutert:
Gehe zu ‘Einstellungen-Einrichten-Netzwerk einrichten-Empfang’.
Wähle ‘Hinzufügen-(disconnected) Imap’ und Ausfüllen des Formulars..
Für den ‘Server’ sollte ’localhost’ verwendet werden, sofern der Imap-server auf dem gleichen
Rechner läuft wie der Client (Kmail).
Der Rest ist dann einfach, Ordner können nach Belieben von Kmail aus erstellt werden.
Natürlich müssen die Mails selbst z.B. vom (pop3-) Server des Providers
abgeholt und in die entsprechenden Imap-Ordner einsortiert werden,
dies kann z.B. mit fetchmail/procmail wie weiter oben beschrieben erfolgen,
am besten durch einen regelmässigen cron-job.
Sollte irgendetwas schiefgehen, lohnt es sich, zuerst in der Datei /var/log/syslog
des Servers nachzusehen, erfolgreiche Logins sehen darin so aus:
Dec 28 10:02:10 dsrv imaplogin: authdaemon: starting client module Dec 28 10:02:10 dsrv imaplogin: authdaemon: ACCEPT, username josswern Dec 28 10:02:10 dsrv imaplogin: LOGIN, user=josswern, ip=[::ffff:192.168.0.20], protocol=IMAP
Ein guter Tip im Falle von Problemen mit dem Imap Login ist auch, erstmal via telnet zum Imap-Server Verbindung aufzunehmen:
telnet 127.0.0.1 143
dann z.B.
a001 USER username a002 PASS password a003 SELECT INBOX
Weitere Informationen über den Imap4 Befehlssatz kann ich hier leider nicht geben, da ich mich hiermit noch zuwenig beschäftigt habe, aber eine google-Suche nach ‘Imap telnet 143’ hilft hier sicher weiter…
Bitte zu beachten, dass diese Beschreibung lediglich erklärt, wie ich die Sache hier zum Laufen bekommen habe, wie erwähnt gibt es unzählige andere Möglichkeiten. Wie immer, sind Anmerkungen/Kritik/Korrekturen willkommen - viel Spass