SPAM

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
Procmail arbeitet mit sog. 'Recipes (Rezepten)', in die z.B. Bogofilter direkt integriert ist, wodurch SPAM aus- und alles andere auch gleich richtig einsortiert wird. Beispiele zur Konfiguration der o.g. Programme finden sich im Anhang A. Idealerweise laufen alle o.g. Programme auf einem Server, der z.B. via IMAP die gefilterten und sortierten Mails allen Clients im (Heim-) Netz transparent z.V. stellt, dabei ist es unerheblich, welches OS auf den Clients läuft !. Der Anwender braucht sich weder mit der Konfiguration noch sonstwas herumschlagen, er sollte lediglich SPAM's die trotz Filter ab und zu noch durchkommen, in den Ordner 'SPAM' auf dem IMAP-Server verschieben, bogofilter 'lernt' dann daraus (und löscht sie anschliessend gleich). Wer nur einen Arbeitsplatzrechner hat, kann procmail nat. gleich in die lokale Mailbox einsortieren lassen (Voraussetzung: maildir-Format kompatibler Mail-Client, also kein OE ) - imap wäre an dieser Stelle wohl etwas 'Overkill'... So gerüstet, kann man dann wieder sorglos mailen, (fast) so wie früher, als die SPAM-Flut noch nicht rollte... In diesem Sinne: Happy Mailing ! Wer jetzt Interesse bekommen hat - einfach melden - ich bin gerne bereit, beim Aufbau eines Mailservers/SPAMBLOCKERS zu helfen (allerdings beschränkt sich das auf Linux-Technologie, M$ wird von mir bekanntlich nicht supportet...).

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