Home 
ORDIX News 2/2004
ORDIX News 2/2004
ORDIX News 2/2004
Das IT-Magazin der ORDIX AG mit Fachbeiträgen zu Datenbanken, Unix und Java/XML.
Einen 100%igen Schutz vor SPAM oder UCE (Unsolicited Commercial E-Mail) wird es nicht geben, solange es sich für "SPAMer" noch lohnt, irgendwelche Filter zu knacken, um die Werbung an den Empfänger zu bringen.
Es gibt aber mehrere Hard- und Software Lösungen auf dem Markt, die sich diesem Problem widmen. Wir haben uns für den Einsatz des Open Source Produktes "SpamAssassin" entschieden, weil dieses Programm eine verblüffende Effizienz aufweist. Davon hat uns die Software bei umfangreichen Tests überzeugt. Die Trefferquote lag nahezu sofort zwischen 90 % und 95 %, was schon Grund genug ist, diese Software einmal einzusetzen.
Ein weiterer, für uns wichtiger Punkt: Die Software verändert die E-Mail beim Scannen nicht. Ihr wird nur ein Stempel im Header "verpasst". Damit ist schon eine Vorarbeit für das Sortieren geleistet. Der Mitarbeiter entscheidet dann letztendlich selbst, wie er mit solchen E-Mails umgeht.
Zu Beginn eines solchen Projektes muss man sich zunächst einmal überlegen, an welcher Stelle der gesamten internen E-Mail-Route das Filtern erfolgen soll. Eine Richtlinie, an die wir uns unbedingt halten wollten, war, dass alle E-Mails von extern erst einmal angenommen werden. Erst auf dem POP3/IMAP Server sollte dann das Scannen erfolgen.
Drei Software Pakete in Kombination machen es möglich: Sendmail, Spamass-Milter und SpamAssassin. Das Zusammenspiel der drei Pakete zeigt Abbildung 1.
Abb. 1: Durchlauf einer E-Mail im Unternehmen über POP3/IMAP Server mit Sendmail, Spamass-Milter und SpamAssassin.Sobald eine E-Mail den Sendmail auf dem Server erreicht, wird sie erst durch Spamass-Milter weiterverarbeitet. Dieser ruft den SpamAssassin auf und analysiert die Mail unter Verwendung von spamd und spamc (Dämon und Client).
Anhand von Suchmustern und Regeln bekommt jede Mail einen Zahlenwert zugeordnet. Je höher der Wert, desto größer ist die Wahrscheinlichkeit, dass sie eine SPAM-Mail ist.
Dieser Wert wird in den Mail-Header "X-Spam-Status" eingefügt. Ab einem konfigurierbaren Schwellwert wird zusätzlich das Subject mit dem Wort SPAM "verziert". Danach geht die Mail den üblichen Weg durch Sendmail und wird dann z. B. auf dem IMAP Server abgelegt.
Um es kurz darzustellen: Anstatt den üblichen Weg zu gehen, wird die E-Mail beim Sendmail durch einen Bypass geschickt, wo das Filtern erfolgt.
Folgende Software-Versionen sind auf dem E-Mail-Server im Einsatz:
[1] Sendmail - 8.12.8
Compiled with:
DNSMAP LOG MATCHGECOS MILTER MIME7TO8 MIME8TO7
NAMED_BIND NETINET NETUNIX
NEWDB PIPELINING SCANF USERDB XDEBUG
...
[2] Spamass-milter 0.2.0
[3] SpamAssassin version 2.60
Zunächst die Source auf dem System auspacken: # rpm -i sendmail-8.12.8-5.90.src.rpm
Eine Datei site.config.m4 unter /usr/src/redhat/SOURCE/sendmail-8.12.8/Site mit folgendem Inhalt erstellen:
APPENDDEF(‘conf_sendmail_ENVDEF’, ‘-DMILTER’) define(‘confENVDEF’, ‘-DSM_CONF_SHM=0’)
Mittels rpm Befehl ein Sendmail Paket erstellen:
# cd usr/src/redhat/SPECS # rpm –bb sendmail.spac # pwd # /usr/src/redhat/SPECS # ls -al ../RPMS/i?86/sendmail-8.12.8-4.i?86.rpm -rw-r—r— 1 root root 540096 Nov 6 10:11 ../RPMS/i?86/sendmail-8.12.8-4.i?86.rpm
und auf dem System installieren: # rpm –i sendmail-8.12.8-4.i?86.rpm
Die Konfiguration von Sendmail ist etwas umfangreicher und unter gut beschrieben.
Paket Mail-SpamAssassin-2.60.tar.gz unter z. B. /tmp auspacken, dann mit make kompilieren und (spätestens hier als root) mit make install installieren:
# cd /tmp/Mail-SpamAssassin-2.60 # perl Makefile.PL # make # make install
Beim Spamass-Milter gibt es eine ähnliche Vorgehensweise, allerdings wird hier mit einem configure Skript gearbeitet:
# cd /tmp; tar xvfz spamass-milter-0.2.0.tar.gz # cd spamass-milter-0.2.0 # ./configure # make # make install
Zu der Konfiguration von SpamAssassin und Spamass-Milter ist folgendes zu erwähnen:
ist es sehr wichtig, darauf zu achten, welche Optionen man dem spamc Client mitgibt. Der Grund dafür ist, dass SpamAssassin z. B. nicht unerhebliche Ressourcen des Hauptspeichers benötigt.
Mit der Option –s (maximum message size) beim spamc kann man z. B. Mails mit großem Inhalt von dem Scanprozess ausschließen.
Um das Geschehen in der /var/log/maillog zu verfolgen, stellt man am Anfang den Debug-Modus beim spamd ein. Die restlichen Parameter kann man zunächst beim Default (z. B. Stempel ***SPAM*** wird bei Default-Werten nur nach drei Sternen vergeben) belassen und in der Datei user_prefs nach und nach anpassen.
Bei sauberem Starten von sendmail, spamass-milter und spamd sind folgende Dämonprozesse zu finden:
# ps -e | grep sendmail | grep -v grep 27667 ? 00:04:58 sendmail # ps -e | grep spam | grep -v grep 13773 ? 00:00:53 spamass-milter 27772 ? 00:00:31 spamd
Start/Stop Skripte sind in den Sourcen mitgeliefert, müssen aber je nach Betriebssystem angepasst werden. Wichtig zu erwähnen: die Optionen für den spamc (Client) sind in dem Start/Stop Skript für spamass-milter definiert.
Um das Geschehen und die Effizienz etwas überschaubarer zu gestalten, haben wir ein Skript entwickelt, das relevante Zahlen über den Tagesablauf liefert. Hier wird sehr schnell deutlich, dass SPAM-Mails durchaus einen großen Anteil an der Gesamtmenge an E-Mails haben. An Wochenenden, wo der "normale" Mailverkehr etwas ruht, wird der SPAM Anteil prozentual deutlich sichtbar (siehe Skriptausgabe in Abbildung 2).
Abb. 2: Ausgabe eines Scripts zur Veranschaulichung des Anteils von Spam Mails an Mails insgesamt.Der höhere Bedarf an Rechenleistung und Hauptspeicher beim Scannen einer E-Mail ist zwar ein Nachteil, aber immer noch kostengünstiger als menschliche Arbeitszeit, die investiert wird, um sich von unerwünschten Informationen zu befreien.
Alexander Hochhalter (info@ordix.de).