diplomarbeit - Hochschule Furtwangen

ANGEN
WIRTSCHAFT
NCES
Fachhochschule Furtwangen
Fachbereich Informatik
Studiengang Computer Networking
DIPLOMARBEIT
OPEN SOURCE ANTISPAM UND
ANTIVIRUS LÖSUNG FÜR KLEINE UND
MITTELSTÄNDISCHE UNTERNEHMEN
vorgelegt im
Wintersemester 2004/2005
von
Adrian Woizik
Erstprüfer:
Zweitprüfer:
Prof. Dr. Christoph Reich
Fachhochschule Furtwangen
Dipl.-Inform. Med. Tobias Häcker
Thinking Objects Software GmbH
Anmeldedatum: 01. September 2004
Abgabedatum: 31. März 2005

Eidesstattliche Erklärung
Ich erkläre hiermit an Eides statt, dass ich die vorliegende Diplomarbeit selbstständig
und ohne unzulässige fremde Hilfe angefertigt habe. Die verwendeten
Quellen und Hilfsmittel sind vollständig zitiert.
Furtwangen, den 31. März 2005
Adrian Woizik

Kurzfassung
E-Mail hat für Unternehmen in der heutigen Zeit an Bedeutung gewonnen.
Heutzutage gilt die E-Mail-Infrastruktur eines Unternehmens als geschäftskritisch
und wird dementsprechend hochverfügbar realisiert. Neben den Vorteilen
der E-Mail Kommunikation lässt der damit verbundene Spamanteil die
Kosten ansteigen.
Der zunehmende Anteil an Spam und Viren in E-Mails zwingt Unternehmen,
sich mit dieser Problematik zu befassen. Besonders bei der Spamabwehr
versuchen viele Hersteller kostenpflichtige Lösungen anzubieten, die oft auf
schon vorhandenen Konzepten aus dem Open-Source-Bereich basieren. Vor
allem kleinere und mittelständische Unternehmen scheuen die hohen Kosten,
die mit dem Kauf und dem Betrieb solch kommerzieller Lösungen anfallen.
Als Alternative bietet sich hier eine auf Open-Source basierende Implementation
an. Die Installation und Konfiguration ist jedoch für die Administratoren
eines Unternehmens eine anspruchsvolle und zeitintensive Aufgabe. Gerade
die Komplexität beim Zusammenspiel der einzelnen Abwehrmethoden birgt
die Gefahr, dass das System unter hoher Last den Anforderungen einer erfolgreichen
E-Mail Kommunikation nicht mehr gerecht wird.
Die vorliegende Diplomarbeit beschreibt die grundlegenden Werkzeuge, um
eine zentrale Spam- und Virenfilterung einzurichten. Sie identifiziert die dabei
entstehenden rechtlichen Probleme und zeigt Lösungsmöglichkeiten auf. Außerdem
werden die Methoden der Spambekämpfung erläutert. Die gewählte
Lösung wird von der Auswahl der Komponenten, über das E-Mail Konzept
bis zur Implementierung genau beschrieben. Um am Ende ein kostenloses
Testsystem als Basis anbieten zu können, wurden ausschließlich Open-Source-
Produkte verwendet. Die implementierte Lösung vereinfacht den Betrieb und
die Konfiguration einer zentralen Spam- und Virenfilterung erheblich und
lässt sich mit geringem Aufwand in eine bestehende E-Mail-Infrastruktur einbinden.

Inhaltsverzeichnis
Kurzfassung
i
1 Einleitung 1
1.1 Hintergrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Aufbau der Diplomarbeit . . . . . . . . . . . . . . . . . . . . . . 2
1.4 Betreuer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.5 Danksagung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Grundlagen 5
2.1 Übersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Rechtliche Voraussetzung . . . . . . . . . . . . . . . . . . . . . . 5
2.3 SMTP-Protokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4 Mail / MIME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.5 Begriffsbestimmung Spamarten . . . . . . . . . . . . . . . . . . . 15
3 Methoden der Spam- und Virenerkennung 21
3.1 Methoden der Spammer . . . . . . . . . . . . . . . . . . . . . . . 21
3.2 RBL – Echtzeit Ausschlussliste . . . . . . . . . . . . . . . . . . . 23
3.3 Greylisting – Graue Listen . . . . . . . . . . . . . . . . . . . . . . 23
3.4 Fehlerhafte SMTP-Implementierung . . . . . . . . . . . . . . . . 24
3.5 Verteilte Prüfsummen-Verfahren . . . . . . . . . . . . . . . . . . 25
3.6 Regular Expression - Regulärer Ausdruck . . . . . . . . . . . . . 26
3.7 Bayes – Statistische Analyse . . . . . . . . . . . . . . . . . . . . . 26
3.8 Weitere Methoden . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.9 Virenfilter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4 Implementierung 31
4.1 Konzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.2 Mail Transfer Agent . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.3 Antivirus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.4 Antispam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5 Erweiterungen 45
5.1 Statistische Auswertung . . . . . . . . . . . . . . . . . . . . . . . 45
5.2 Quarantäne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

iv
Inhaltsverzeichnis
5.3 Spam / Ham Training . . . . . . . . . . . . . . . . . . . . . . . . 48
5.4 Regel Aktualisierung . . . . . . . . . . . . . . . . . . . . . . . . . 48
6 Tests 51
6.1 Lasttest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.2 Langzeittest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.3 Profiling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.4 Spam / Ham Erkennung . . . . . . . . . . . . . . . . . . . . . . . 55
7 Resümee 57
Quellenverzeichniss 61
Abkürzungen 65
Glossar 67
A Konfiguration 69
A.1 exim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
A.2 Spam/Ham training . . . . . . . . . . . . . . . . . . . . . . . . . 80

Abbildungsverzeichnis
2.1 Spam Aufkommen der Jahre 2003/2004 - Quelle: Messagelabs
Ltd. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2 Spam Kategorien - Quelle: Brightmail Logistics and Operational
Center (BLOC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1 Konzept der Architektur . . . . . . . . . . . . . . . . . . . . . . . 33
4.2 acl_rcpt_check Konzept. . . . . . . . . . . . . . . . . . . . . . . . 37
4.3 acl_content_check Konzept. . . . . . . . . . . . . . . . . . . . . . 40
5.1 RRD Grafik Exim Statistk . . . . . . . . . . . . . . . . . . . . . . 46
5.2 Userinterface Quarantäne . . . . . . . . . . . . . . . . . . . . . . 47
6.1 Mail Durchsatz durch Mail submitting. . . . . . . . . . . . . . . 52
6.2 Statistik des Langzeittests. . . . . . . . . . . . . . . . . . . . . . . 54

Kapitel 1
Einleitung
1.1 Hintergrund
Kein anderes Medium bietet heutzutage eine einfachere Möglichkeit, zeitnahe
und effizient geschäftskritische Informationen mit Kunden und Partnern
auszutauschen. Für viele Firmen hängt der Erfolg von einer funktionierenden
E-Mail-Infrastruktur ab. Gleichzeitig werden die Mail-Adressen jedoch mit einer
stetig steigenden Anzahl von Spam- und Virenmails überhäuft. Bei der
Sortierung seiner Mailbox verliert der Mitarbeiter kostbare Arbeitszeit. Nachdem
mittlerweile der Anteil an Spam-Mails auf 81,4% [ML05] angestiegen ist
und die Viren eine Zunahme von über 50% [SO04] aufweisen, kommen Unternehmen
nicht umher, eine zentrale Spam- und Virenfilterung zu verwenden.
Zur Umsetzung einer zentralen Spam- und Virenfilterung bieten sich verschiedene
Lösungmöglichkeiten an. Diese reichen von einer einfachen schwarzen
Liste mit gesperrten IP-Addressen von Mailsendern bis hin zur umständlichen
statistischen Analyse des Mailinhalts. Viele kommerzielle Produkte versuchen
die einzelnen Methoden zu kombinieren, um eine bessere Trefferquote zu erreichen.
Dieses perfekte Zusammenspiel der einzelnen Methoden wird meist
nur in Form von Enterprise-Lösungen angeboten, die für die kleinen und mittelständischen
Unternehmen eine vergleichsweise hohe Investitionsbelastung
bedeuten.

2 Kapitel 1. Einleitung
1.2 Zielsetzung
Ziel dieser Diplomarbeit ist die Konzeption und Bewertung eines Antispam/Antivirus
Mailgateways, welches den notwendigen Installations- und
Verwaltungsaufwand verringert und dabei für das Unternehmen ohne laufenden
Lizenzkosten zu betreiben ist. Neben dem konzeptionellen Teil soll eine
Implementierung in Form einer Testinstallation entstehen, die im weiteren
Verlauf als kostenlose Installationsbasis dienen soll.
1.3 Aufbau der Diplomarbeit
Die vorliegende Diplomarbeit ist in folgende Kapitel gegliedert:
Kapitel 1 beschreibt die Hintergründe und Zielsetzung der vorliegenden Diplomarbeit.
Kapitel 2 schildert die zum Verständnis der Arbeit nötigen Protokollgrundlagen.
Neben dem SMTP-Protokoll wird auf rechtliche Aspekte und Begriffe
im Zusammenhang mit unerwünschten Massenmails eingegangen.
Kapitel 3 baut auf den gesetzten Grundlagen auf und veranschaulicht die einzelnen
Methoden zur Spamabwehr. Dabei werden die einzelnen Methoden
bewertet und ein Erfahrungsbericht mit kommerziellen Produkten
angefügt.
Kapitel 4 verdeutlicht die im Rahmen der Diplomarbeit entstandene Implementierung.
Dabei wird auf die Konzeptionierung und das Zusammenspiel
der gewählten Komponenten eingegangen.
Kapitel 5 beschreibt die Erweiterungen der Implementierung und zeigt, mit
welchen Methoden ein System für ein Unternehmen einsatzfähig wird.
Kapitel 6 stellt die während der Testphase der Software gewonnenen Ergebnisse
vor. Im Besonderen enthält dieses Kapitel eine kritische Betrachtung
der Performance unter hoher Last.
Kapitel 7 fasst das Ergebnis zusammen und beschreibt den Verlauf der Diplomarbeit.

1.4. Betreuer 3
1.4 Betreuer
Erstbetreuer:
Prof. Dr. Christoph Reich
Fachhochschule Furtwangen
Hochschule für Technik und Wirtschaft
Gerwigstraße 11
78120 Furtwangen
Zweitbetreuer:
Dipl.-Inform. Med. Tobias Häcker
Thinking Objects Software GmbH
Lilienthalstraße 2/1
70825 Stuttgart-Korntal
1.5 Danksagung
Ich möchte mich an dieser Stelle bei Herr Prof. Dr. Christoph Reich und Herr
Dipl.-Inform. Med. Tobias Häcker für die Betreuung meiner Diplomarbeit bedanken.
Außerdem bedanke ich mich bei den Mitarbeitern der Thinking Objects
GmbH und der Topalis AG, insbesondere bei Andreas Schlenk, die mir
viele neue Denkanstöße zur Optimierung dieser Arbeit gegeben haben. Desweiterem
möchte ich all jenen danken, die durch ihre fachliche und persönliche
Unterstützung zum Gelingen dieser Diplomarbeit beigetragen haben.

Kapitel 2
Grundlagen
2.1 Übersicht
Im folgendem Kapitel wird auf die rechtlichen Rahmenbedingungen einer Antispam
und Antivirus Lösung in Unternehmen eingegangen. Hierfür werden
rechtliche Abhandlungen zusammgefasst und erläutert. Desweiteren wird das
SMTP-Protokoll in Grundzügen vorgestellt und es folgt eine Übersicht über
die häufigsten Spam Begriffe und deren Herkunft. Im weiterem Verlauf wird
der Begriff Mail als Synonym für E-Mail verwendet.
2.2 Rechtliche Voraussetzung
Der Einsatz einer zentralen Spam- und Virenfilterung muss sich an die rechtlichen
Vorgaben halten. Hierbei müssen verschiedene Voraussetzungen in einem
Unternehmen beachtet werden. Wie in [JK04] dargestellt, besteht das
Hauptproblem für ein Unternehmen in einer erlaubten Privatnutzung der E-
Mail-Infrastruktur des Unternehmens.
Bei einer erlaubten Privatnutzung findet das Telekommunikationsgesetze
(TKG) anwendung, insbesondere muss das Telekommunikationsgeheimniss
gewahrt werden. Ebenso muss der Schutz der Datenintegrität nach § 303a
Strafgesetzbuch (StGB) beachtet werden. Dies bedeutet, dass die E-Mail nicht
in ihrem Inhalt verändert werden darf. Das Unternehmen gilt durch die Privatnutzung
als Telekommunikationsanbieter und darf ohne Einwilligung des
Empfängers keine Maßnahmen zur Filterung ergreifen.
Bei einer Virenfilterung ist dies allerdings nicht der Fall. Die Datenschutzgesetze
von Bund und Ländern (§9 BDSG) verpflichten datenverarbeitende Stellen
(in diesem Fall die Unternehmen) zur Gewährleistung von Datenschutz und
-sicherung. Aus diesem Grund sind Unternehmen sogar verpflichtet, für einen
funktionierenden Virenfilter zu sorgen (BDSG §9 Rn. 19.).

6 Kapitel 2. Grundlagen
2.2.1 Telekommunikationsgesetz
Nach §85 TKG sind Anbieter, die einen Telekommunikationsdienst erbringen,
zur Wahrung des Telekommunikationsgeheimnises verpflichtet. Dies bedeutet
im Falle einer erlaubten Privatnutzung im Unternehmen, dass sich die Firma
nach §206 Abs. 2 Nr. 2 StGB strafbar macht, wenn sie eine E-Mail an zentraler
Stelle löscht oder unterdrückt.
Diese Problematik kann ein Unternehmen zwar durch den Ausschluss der Privatnutzung
umgehen, allerdings mit dem Nachteil, dass die private E-Mail-
Kommunikation zu externen Webmailern verlagern wird. An dieser Stelle
kann ein Unternehmen keinen Einfluss mehr auf die Aktualität der Virenfilter
nehmen. Die Viren somit damit durch einen verschlüsselten HTTPS-Tunnel in
das Unternehmensnetzwerk gelangen.
Eine zentrale Erkennung beziehungsweise Filterung von Spam und Viren ermöglicht
folgende Szenarien:
• Löschung Mails, die Spam oder Viren enthalten, werden am zentralen
Gateway gelöscht. Sofern dies für den Benutzer nicht transparent oder
sogar ohne seine Einwilligung geschieht, macht sich das Unternehmen
strafbar. Eine Ausnahme stellt die bereits angesprochene Virenfilterung
dar, da hier die Datenschutzgesetze beachtet werden müssen.
• Blockierung Bei der Blockierung wird meist der Empfänger periodisch
über zurückgehaltene Mails informiert. Die Mails werden dabei in einer
Quarantäne aufbewahrt, bis sich der Benutzer dazu entscheidet, die
Mails zu bearbeiten oder zu löschen. Hierbei dürfen die Mails nicht automatisch,
nach einer gewissen Vorhaltezeit, aus der Quarantäne entfernt
werden, dies würde der Löschung, mit all ihren Problemen entsprechen.
Die Quarantäne muss dabei vom Benutzer zugänglich sein und darf
nicht durch einen Administrator verwaltet werden. Eine sogenannte
“catch-all” 1 Quarantäne, darf daher nicht verwendet werden.
• Kennzeichnung Bei der Kennzeichnung wird ein für den Benutzer nicht
sichtbarer Header eingefügt, der über die Klassifizierung informiert.
Diese Methode hat sich als am rechtlich unbedenklichsten erwiesen, da
sie dem Benutzer die Wahl lässt, eine Filterung an seinem Mail-Client
vorzunehmen. Der Benutzer kann dabei auch den Grad der Filterung
definieren.
Eine weitere Form der Kennzeichnung ist das “Tagging” 2 , hierbei
wird der Subject-Header der Mail um eine Zeichenkette, zum Beispiel
“[SPAM]” erweitert. Dies ermöglicht den Empfänger eine einheitliche
Kontrolle, ist rechtlich aber als Verstoß gegen die Datenintegrität zu werten,
da eine Änderung des Inhalts vorgenommen wird.
1 alle Mails werden hierbei in das selbe Postfach zugestellt
2 aus dem Englischen: “to tag” - etwas markieren

2.2. Rechtliche Voraussetzung 7
• Ablehnung Hierbei werden positive erkannte Mails noch während der
SMTP-Transaktion abgelehnt. Ein legitimer Sender wird dadurch über
den Fehler informiert und kann mittels eines anderem Mediums Kontakt
mit dem Empfänger aufnehmen. Dies kann ebenfalls als rechtlich
unbedenklich angesehen werden, da der Absender über den Misserfolg
unterrichtet wird und weitere Schritte einleiten kann, um den Kontakt
herzustellen. Im Gegensatz zu den Non-Delivery-Reports, die erst nach
der eigentlichen SMTP-Prozedur stattfinden, wird hierbei auch gewährleistet,
dass keine gefälschten Absenderinformationen zum Spammen
genutzt werden.
2.2.1.1 TKÜV – Telekommunikations-Überwachungsverordnung
Die erlaubte Privatnutzung in einem Unternehmen kann zu einem weiteren
negativen Aspekt führen. Am 1.1.2005 ist die Telekommunikationsrichtlinie
zur Überwachung von Telekommunikationsdiensten (insbesondere E-Mail) in
Kraft getreten. Diese zwingt jeden Telekommunikationsdienstleister zur Vorhaltung
technischer Maßnahmen zur Überwachung des E-Mail-Verkehrs.
Da sich die Diplomarbeit aber mit einer Lösung für kleine und mittelständische
Unternehmen befasst, ist nicht zu erwarten, dass die von der TKÜV geforderten
1.000 Teilnehmer erreicht werden. Sollte dies eines Tages der Fall sein,
empfiehlt es sich, die Privatnutzung der E-Mail-Infrastruktur zu untersagen.
2.2.1.2 Bestrebungen der Regierung
Die Bundesregierung verfasste am 18. Februar 2005 einen Gesetzesentwurf
[SG05], der als Antispam-Gesetz vorgestellt wurde. Hierbei droht dem Absender
eine Geldbuße von bis zu 50.000 e, wenn der Versuch unternommen
wird, die Identität zu verschleiern. Zudem sieht das Gesetz vor, dass bei Massenmails
der Charakter einer E-Mail durch die Betreffzeile erkennbar gemacht
werden muss.
Ziel dieses Entwurfes scheint die Legalisierung von Spam zu sein. Er unterteilt
den Spam in vorschriftsmäßig versendeten und illegal manipulierten Spam,
sieht aber keine Möglichkeit für das Unterdrücken der Spam-Mails, durch
den Telekommunikationsanbieter vor. Die Verabschiedung würde dazu führen,
dass Spammern das Recht zugesprochen wird, ihre legal gekennzeichneten,
unerwünschten Massenmails zustellen zu dürfen.
Dieses Problem ist auch für den Verband der deutschen Internetwirtschaft e.V.
(http://www.eco.de (02.2005)) relevant. Der Verband vereinbarte eine Positivliste
für deutsche Direktvertriebler, die dazu dienen soll, legalen Spam
unbehelligt durch die Vielzahl an Spamfiltern zu transportieren.
Derzeit stellt sich dieses Antispam-Gesetz der Regierung als zahnloser Tiger
dar, der das Spamaufkommen der Providern nicht vermindert und somit die

8 Kapitel 2. Grundlagen
Mailinfrastruktur nicht entlasten wird. Auch wird dem Bürger keine Möglichkeit
gegeben, sich gegen Spammer gerichtlich zur Wehr zu setzen. Es bleibt zu
hoffen, dass dieser Entwurf in seiner jetzigen Form, nicht verabschiedet wird.
2.3 SMTP-Protokoll
Simple Mail Transfer Protocol (SMTP) wurde erstmals 1982 im RFC821 [JP82]
definiert, 2001 wurde dieser RFC durch RFC2821 [JK01] ersetzt. RFC2821 veränderte
keine Funktionen und dient hauptsächlich zur Klärung, der in die
Jahre gekommenen RFC821 und der bis dahin eingeführten Erweiterungen.
In beiden RFCs wird lediglich der Transport einer E-Mail definiert. Auf die
Struktur und den Aufbau einer E-Mail wird zu einem späterem Zeitpunkt in
diesem Kapitel eingegangen.
SMTP soll sicher stellen, dass Mails zuverlässig und effizient den Empfänger
erreichen. Sender und Empfänger müssen sich dabei nicht im gleichen Netzwerk
befinden. Gegebenenfalls wird die Mail über ein Relay oder Gateway in
ein anderes Netzwerk übermittelt.
2.3.1 Das SMTP Konzept
2.3.1.1 Grundkonzept
Soll eine Nachricht versendet werden, ist der Client dafür verantwortlich, die
Nachricht an einen (oder mehrere) SMTP-Server zu senden oder eine Fehlermeldung
zurück zu liefern.
Mit Hilfe des Namens der Zieldomain identifiziert der SMTP-Client die Adresse
der zu dieser Domain gehörigen SMTP-Server. Dieser SMTP-Server lässt
sich unter anderem über den MX-Record der Ziel-Domain abfragen. Sollte
kein MX-Record vorhanden sein, wird der A-Record ausgewertet. Der identifizierte
Host kann bereits das Ziel der E-Mail sein, oder aber erst ein zwischengeschalteter
MX-Host, der die Mail weiter zustellt. Bei letzterem unterscheidet
man zwischen:
• Relay (d.h. nach dem Empfang der Nachricht übernimmt der Server die
Rolle des SMTP-Clients, um die Nachricht weiterzuleiten) und
• Gateway (d.h. nach dem Empfang wird die Nachricht mit einem anderen
Protokoll weiterversendet - auch hier wird das Gateway für den darauf
folgenden Zielrechner zum Client)
Ein Relay- oder Gateway-Server, der die Nachricht entgegen nimmt, übernimmt
die oben beschriebene Verantwortung des Clients, die Nachricht an
einen oder mehrere SMTP-Server zu senden oder eine Fehlermeldung für Sender
zu generieren.

2.3. SMTP-Protokoll 9
Zu dem SMTP-Server auf dem identifizierten Host baut der SMTP-Client
einen 2-Wege-Übertragungskanal auf: der Client schickt SMTP-Kommandos
an den Server, die dieser beantwortet. Abgesehen von speziellen Erweiterungen
und dem DATA-Kommando muss der Server nach jedem Kommando erst
antworten, bevor der Client einen neuen Befehl absetzen kann. Sollte der Server
PIPELINING unterstützen, kann der Client MAIL FROM: und RCPT TO:
in einem Block senden. Der Client muss danach auf die Antwort der einzelnen
gesendeten Kommandos warten.
Nach dem Verbindungsaufbau und dem Handshake sendet der Client meistens
eine E-Mail. Geht die Nachricht an mehrere Empfänger, so kann über das
Protokoll sichergestellt werden, dass lediglich eine Kopie an einen Ziel- oder
Zwischenhost versendet wird. Der Server liefert eine Antwort, ob das Kommando
erfolgreich war, weitere Kommandos erwartet werden, oder ob temporäre
beziehungsweise permanente Fehler auftraten. Nach dem Versand einer
Mail kann der Client einen Verbindungsabbau initiieren oder weitere Mails,
über die bestehende Verbindung senden.
Weiterhin kann der Client – statt eine Mail zu verschicken – verschiedene
Hilfsdienste des Servers (verifizieren von E-Mail-Adressen, ermitteln von
Empfängern einer Mailingliste) nutzen, sofern diese implementiert und freigeschalten
sind.
2.3.1.2 Das Erweiterungskonzept
1993 wurde SMTP, durch RFC1425 [JK93], um ein “Service Extension”-
Konzept erweitert. Dieses erlaubt die dynamische Erweiterung von SMTP um
zusätzliche Funktionalität. Client und Server können sich darauf einigen, diese
zu verwenden sofern sie von Beiden unterstützt werden. Aktuelle SMTP-
Implementierungen müssen den grundlegenden Extension-Mechanismus unterstützen,
auch wenn sie keine Erweiterungen anbieten.
Mit Hilfe des “Service Extension”-Modell wurden beispielsweise folgende Erweiterungen
Implementiert:
• STARTTLS – Um eine verschlüsselte und authentifizierte Verbindung
zu initiieren.
• SMTP AUTH – Zur Authentifizierung des Clients.
• PIPELINING – Um mehrere Befehle in einem Block senden zu können.
2.3.2 Die SMTP-Prozeduren
Nachfolgend werden relevante Prozeduren der SMTP Kommunikation beschrieben.
Vertiefende Informationen sind der RFC zu entnehmen.

10 Kapitel 2. Grundlagen
2.3.2.1 Sitzungsaufbau
Eine SMTP-Sitzung wird initiiert, sobald der Client eine Verbindung zum Server
aufbaut und letzterer mit einer positiven Nachricht antwortet. Der Server
muss seine Bereitschaft mit einer 220 Nachricht signalisieren, bevor der Client
sein erstes Kommando senden kann. Diese Nachricht wird im Allgemeinen
auch “Banner” genannt. Hierbei enthält die Bannernachricht bereits Informationen,
ob der Server in der Lage ist mit Protokoll Erweiterungen (ESMTP)
umzugehen.
2.3.2.2 Client Initiierung
Nachdem der Client auf das Banner gewartet hat, muss sich dieser beim
Server mit dem EHLO- oder mit dem veralteten HELO-Kommando vorstellen.
Durch das EHLO gibt der Client dem Server gleichzeitig an, das dieser
mit SMTP-Erweiterungen arbeiten kann. Sollte der Server nicht mit SMTP-
Erweiterungen umgehen können, greift der Client auf das HELO-Kommando
zurück. Hierbei übergibt der Client seinen Hostnamen als Parameter.
Syntax:
EHLO [hostname]
HELO [hostname]
2.3.2.3 Mail-Transaktion
Zum Versenden einer Mail werden vom Client die folgenden Befehle in dieser
Reihenfolge genutzt:
• EHLO/HELO gibt das sendende System an.
• MAIL FROM: gibt den Sender an, der bei einem späteren Fehler benachrichtigt
wird.
• RCPT TO:um den Empfänger anzugeben. Dieser Befehl kann mehrmals
bei einer Mail vorkommen.
• Mittels DATAgibt der Client bekannt, dass er die Mail senden möchte.
Bei einer positiven Server-Antwort gelten alle darauf folgenden Zeilen
als Mail-Daten. Die Dateneingabe kann mit einem einzelnem “.” in einer
Zeile beendet werden. Sollte eine Zeile innerhalb der Mail mit einem
Punkt beginnen, wird dieser mit einem weiteren Punkt maskiert. Die beendete
Dateneingabe wird vom Server beantwortet. Im Fall einer positiven
Antwort wird der Server für die weitere Zustellung verantwortlich.
Der Server fügt eine Received-Header an den Beginn der Mail-
Nachricht ein, der wenigstens den Client, den Server sowie den Zeitpunkt
des Empfangs enthält. Hierdurch wird eine spätere Zurückverfolgung
und Fehlersuche vereinfacht.

2.3. SMTP-Protokoll 11
Syntax:
EHLO
MAIL FROM:
RCPT TO:
RCPT TO:
RCPT TO:
DATA
[Mail-Header]
[Body]
.
2.3.2.4 Kommandos zum Testen von Adressen
Der Client kann sowohl User-Namen verifizieren (VRFY), als auch die Mitglieder
einer Mailingliste in Erfahrung bringen (EXPN). Wenn der Client
einen User verifizieren möchte, bekommt er im Erfolgsfall vom Server die
Mailbox/E-Mail-Adresse des Users zurückgeliefert. Gibt es mehrere zutreffende
Mailboxen (wenn zum Beispiel mehrere User mit dem gesuchten Nachnamen
existieren), gibt der Server die Mehrdeutigkeit zurück und eventuell
in weiteren Zeilen auch die in Frage kommenden Mailboxen (jede Zeile eine
mögliche Adresse).
Syntax:
VRFY [string]
Wird eine Mailingliste abgefragt, liefert der Server im Erfolgsfall eine mehrzeilige
Antwort, die pro Zeile eine Mailbox (und wahlweise noch den Usernamen)
enthält.
Syntax:
EXPN [string]
Beide Befehle können an beliebiger Stelle, innerhalb des SMTP-Dialogs benutzt
werden und haben keinen Einfluss auf die aktuelle Transaktion.
2.3.2.5 Relaying
Ein Relay-Server ist üblicherweise durch den DNS MX-Record das Ziel einer
E-Mail-Domain. Der Relay-Server kann eine Mail akzeptieren oder ablehnen.
Wenn er eine Mail akzeptiert, agiert der Relay-Server als Client gegenüber
dem wahren Ziel-System. Bei einer fehlgeschlagenen Zustellung muss der
Relay-Server den Absender über den Misserfolg durch einen “Non-Delivery-
Report” informieren. Ein Relay-Server wird üblicherweise als Fallback im

12 Kapitel 2. Grundlagen
DNS propagiert, so dass im Falle eines Ausfalls am Ziel-System die E-Mail
weiterhin zugestellt werden kann.
2.3.2.6 Mail Gateway
Soll eine Mail über ein anderes Transport Protokoll als SMTP weitergeleitet
werden, bezeichnet man den dafür zuständigen Server als Gateway-Server.
Da die meisten proprietären Protokolle nicht öffentlich dokumentiert sind, gestaltet
sich dies als äußerst komplex, sofern kein Gateway vom Hersteller angeboten
wird.
2.3.3 SMTP-Server Antworten
Die Antworten des SMTP-Servers beginnen mit einer dreistelligen Zahl und
einem beschreibenden Text. Die erste Ziffer gibt dabei an, ob das Kommando
erfolgreich, erfolglos oder unvollständig war. Bereits durch die erste Ziffer
kann ein Client über den darauf folgenden Schritt entschieden. Die zweite Ziffer
dient zu einer spezifischeren Antwort, während die dritte Ziffer die kleinste
Unterscheidung definiert.
Die 5 Werte für die erste Ziffer sind:
1xz - erfolgreiche vorläufige Antwort.
Der Befehl wurde akzeptiert aber noch nicht ausgeführt. Anhand des
genaueren Fehlercodes kann der Client entscheiden ob er den Befehl bestätigt
oder einen Abbruch initiiert.
2yz - erfolgreiche Antwort.
Der Befehl wurde akzeptiert und erfolgreich ausgeführt. Ein neuer Befehl
kann folgen.
3yz - positive Zwischenantwort.
Der Befehl wurde akzeptiert aber benötigt vor der endgültigen Ausführung
noch weitere Informationen.
4yz - temporärer Fehler.
Der Befehl wurde akzeptiert aber wurde aufgrund eines temprären Fehlers
nicht erfolgreich ausgeführt. Zu einem späteren Zeitpunkt könnte
der Befehl erfolgrauch Ausgeführt werden.
5yz - permanenter Fehler.
Der Befehl wurde nicht akzeptiert.
Nur drei dieser fünf Werte sind für diese Diplomarbeit relevant. Diese sind der
2yz, 4yz und der 5yz Antwort Code.
Die zweite Ziffer gibt eine genauere Beschreibung.

2.4. Mail / MIME 13
x0z - signalisiert Syntax Fehler oder nicht implementierte Befehle.
x1z - bezieht sich auf die Anforderung nach Information wie Status oder
Hilfe.
x2z - bezieht sich auf Übertragungskanäle
x3z und x4z - nicht spezifiziert
x5z - bezieht sich auf das Mail-System.
Beispiel:
S: 220 hq.netclue.de ESMTP Exim 4.43
C: HELO
S: 250 netclue.de Hello netclue.de [213.95.27.138]
C: MAIL FROM:
S: 250 OK
C: RCPT TO:
S: 550 unrouteable address
C: QUIT
S: 221 netclue.de closing connection
2.4 Mail / MIME
Das Format von E-Mails wurde 1982 durch die RFC822 [DC82] definiert. Das
Message-Format ist dabei durch zwei Bestandteile gekennzeichnet. Als ersten
Teil kommen die Mail-Header, deren Funktion weitestgehend bis heute gleich
geblieben sind.
Die wichtigsten Header sind hierbei:
To:
Cc: 3
From:
Date:
Subject:
Received:
Empfänger einer E-Mail.
weitere Empfänger einer E-Mail.
Sender einer E-Mail.
Zeitpunkt wann die E-Mail verfasst wurde.
Betreff einer E-Mail.
Statuszeile in der jeder sendende und empfangende Mailer,
inklusive Zeitstempel, angegeben werden muss.
Der Body, der den eigentlichen Inhalt darstellt, wird über eine Leerzeile vom
Header getrennt.
Die Header-Daten sind vom SMTP-Protokoll unabhängig. Daher sollte den
Headern auch kein grosses Vertrauen entgegen gebracht werden.

14 Kapitel 2. Grundlagen
2.4.1 MIME
Diese Struktur der “ARPA Nachrichten” hat sich bis heute so gehalten und
wurde 2001 durch die RFC2822 [RE01] erweitert. Hierbei wurden keine Funktionen
verändert, sondern die Header an die aktuelle Nutzung angepasst.
Eine der wichtigsten Neuerungen dabei war die Einführung von MIME (Multipurpose
Internet Mail Extensions) durch die RFC2045 [PR01]. MIME bildet
eine Struktur, um verschiedene Inhalte übertragen zu können. MIME ist
hierbei ein Format, um nicht-ASCII-Zeichen, wie Videos, Bilder oder ähnliches
über ein Textprotokoll, wie zum Beispiel E-Mail, zu übertragen. Hierfür
wird der Mail-Body in mehrere Inhalte (contents) unterteilt und anhand des
Content-Type-Headers entsprechend auf dem Client verarbeitet.
Zur Übertragung über ein 7-Bit ASCII-Medium 4 werden hierfür die Daten mittels
base64 [SJ03] kodiert.
Bei der base64-Kodierung werden jeweils drei Bytes des Bytestroms (=24
Bit) in vier 6-Bit-Blöcke aufgeteilt. Jeder dieser 6-Bit-Blöcke bildet zwischen 0
und 63 einen Wert. Diese Zahlen werden anhand einer Umsetzungstabelle in
“druckbare ASCII-Zeichen” umgewandelt und ausgegeben. Nach jeweils 64
ausgegebenen Zeichen wird ein Zeilenumbruch eingefügt, welcher ansonsten
für die Kodierung nicht von Belang ist.
Falls die Gesamtanzahl der Eingabebytes nicht durch drei teilbar ist, wird
zur Kodierung mit Nullbytes aufgefüllt. Um dem Dekodierer mitzuteilen,
wie viele Füllbytes angefügt wurden, werden die 6-Bit-Blöcke, die vollständig
aus Füllbytes entstanden sind, mit ’=’ kodiert. Somit können am Ende einer
Base64-kodierten Datei 0, 1 oder 2 ’=’-Zeichen auftreten.
4 der kleinste gemeinsame Nenner bei SMTP

2.5. Begriffsbestimmung Spamarten 15
2.5 Begriffsbestimmung Spamarten
Vor einiger Zeit hätte an dieser Stelle noch die Erklärung von Spam-Mails
erscheinen müssen. Doch angesichts des derzeitigen Spamaufkommens von
81,4% [ML05] ist heute jedem Internetbenutzer Spam ein Begriff.
Über die Entstehung des Begriffes streitet man sich in der Gemeinde. Als gesichert
gilt, dass der Begriff durch einen Monty Python Sketch geprägt wurde.
SPAM ist hierbei der Produktname fuer den “Spiced Ham” der Firma Hormel.
Im besagten Sketch wird dabei für SPAM durch ein Lied so exzessiv geworben,
dass man nur noch den Produktnamen versteht. Aus dieser Herkunft erklärt
sich auch der Begriff “Ham”, der für legitime Mail steht und quasi das Gegenstück
einer Spam-Mail darstellt.
Den ersten Beleg [FH04] für die Beziehung des Begriffs mit unerwünschten
Werbenachrichten stammt aus dem Usenet 5 . Am 13. April 1994 nutzte das Anwaltsbüro
Canter & Siegel die einfache Verbreitungsmöglichkeit des Usenet
um für ihr “Green Card Lottery” Geschäft zu werben. Da zu diesem Zeitpunkt
der Begriff Spam schon durch MUD-Spieler 6 , für das “flooden” mit unnützen
Informationen genutzt wurde, übernahm man den Begriff erst im Usenet und
in der Folge auch für E-Mails mit vergleichbarem Charakter.
Schon vor Canter & Siegel wurden E-Mails zu Werbezwecken genutzt. Damals
wurde dafür der Begriff Spam noch nicht genutzt. Ein Beispiel ist in [FH04]
geschildert, indem DEC 1978 die Möglichkeit des ARPA-Net nutze um für für
ihre ARPA-Net Ünterstützung in ihren Produkten zu werben.
2.5.1 Umfang des Spamaufkommens
Seit dem Vorfall mit Canter & Siegel haben Spam-Mails rapide zugenommen.
Die Zunahme wurde meist nur kurzfristig durch neue Gesetze verzögert. Wie
in der Abbildung 2.1 zu sehen ist, wurde der Anstieg fast nur durch gesetzliche
Verfahren in den Vereinigten Staaten von Amerika kurzfristig unterbrochen,
konnte dabei aber nicht eine Verdoppelung des Spamaufkommens innerhalb
des letzten Jahres auf 81,4% Anteil am gesamten E-Mail-Verkehr verhindern.
2.5.2 UCE – Unsolicited Commercial E-Mail
Als UCE werden E-Mails bezeichnet, die vom Empfänger unerwünschte
Werbebotschaften enthalten. Diese E-Mails dienen in der Regel dazu kommerzielle
Dienste oder Produkte anzubieten.
An erster Stelle bei den kommerziellen E-Mails stehen Werbe-Mails für Produkte.
Dazu zählen Online-Apotheken, die ihre potenzsteigernde Produkte
5 ein weltweites elektronisches Netzwerk an Diskussionsforen
6 Multi User Dungeons

16 Kapitel 2. Grundlagen
Abbildung 2.1: Spam Aufkommen der Jahre 2003/2004 - Quelle: Messagelabs
Ltd.
an den Mann bringen wollen. Das erklärt vermutlich warum die Kategorie
“Health” in Abbildung 2.2 nur an fünfter Stelle residiert. An zweiter Stelle stehen
die “Financial” Werbe-Mails mit Kredit- und Investmentangeboten. Erst
an dritter Stelle steht die Werbung für pornografische Inhalte.
Trotz minimaler Durchdringungsquote 7 ist allen UCE gemeinsam, dass die
Gewinnmargen so lukrativ sind, dass sich diese Massenmails lohnen. Die
Durchdringungsquotebewegt sich dabei häufig im Promille-Bereich. Wie viele
der Empfänger tatsächlich darauf reagiert ist allerdings unklar.
2.5.2.1 Newsletter
Im Gegensatz zu den UCE besteht bei Newslettern die Möglichkeit, dass sie
vom Empfänger erwünscht sind. Daher müssen diese klar von Spam-Mails
abgegrenzt werden.
Zur Bestandpflege eines Newsletters bedienen sich die Anbieter folgender Methoden:
• Opt-In – Der Interessent trägt seine E-Mail-Adresse über ein Webformular
ein, um den Erhalt des Newsletters zu beantragen. Üblicherweise
wird daraufhin eine Bestätigung über die Eintragung versandt. Diese
Methode hat den Nachteil, dass Dritte sie mittels Adressfälschung missbrauchen
können.
7 tatsächlich zugestellte Mails

2.5. Begriffsbestimmung Spamarten 17
Spam Kategorien (März 2004)
1%
2%
5%
6%
7%
7%
7%
5%
25%
20%
Products
Financial
Adult
Internet
Health
Scams
Leisure
Fraud
Political
Spiritual
others
15%
Abbildung 2.2: Spam Kategorien - Quelle: Brightmail Logistics and Operational
Center (BLOC)
• Opt-Out – Deswegen wird zusätzlich zum Opt-In noch ein Opt-Out angeboten,
in dem der Empfänger sich selbständig austragen kann. Häufig
findet man falsche “remove me”-Links in Spam-Mails zur Adressenverifikation.
• Confirmed Opt-In – Im Gegensatz zum Opt-In wird hier eine
Bestätigungs-Mail mit einem eindeutigen Token versandt. Wenn der Interessent
mit diesem Token sein Vorhaben bestätigt, wird er in die Datenbank
aufgenommen. Diese Methode hat den Vorteil, dass sowohl das
Interesse des Kunden überprüft wird, als auch die Zugehörigkeit zu der
E-Mail-Adresse. Diese Methode nennt sich auch “Double Opt-In”, wobei
dieser Begriff den falschen Eindruck erweckt, dass der Aufwand doppelt
so hoch ist und daher das einfache Opt-In die bessere Methode wäre.
Anbieter, die sich an das als sicher geltende Confirmed Opt-In halten, kämpfen
derzeitig um eine Abgrenzung. So wurde eine Allianz der Direktmarketing-
Unternehmen gegründet, die versucht, ihre Mitglieds-Unternehmen mit Hilfe
einer Positivliste aus dem Wirkungsfeld der Filtermaßnahmen zu entfernen.
Newsletter werden auch oft in Zusammenhang mit Gewinnspielen genutzt.
Bei einer Beteiligung wird automatisch die Weitergabe der Daten an Dritte

18 Kapitel 2. Grundlagen
akzeptiert. Laut einem Posting im Heise Forum [DL05] beträgt die Klickrate
bei diesen Mails 3 - 7%.
2.5.2.2 Scam – Betrug
Der bekannteste Scam stammt von der sogenannten “Nigerian Connection”.
Die Betrüger wurden durch den Erfolg der E-Mail, auf diese kostengünstige
Form der Kontaktaufnahme aufmerksam. Der Betrug läuft dabei nach dem
folgenden Schema ab:
Der Empfänger erhält eine Mail, in der von einem größeren Geldbetrag geredet
wird, der außer Landes geschafft werden muss. Da dieses Geld aber an den
Behörden vorbei geschmuggelt werden soll, benötige man einen Mittelsmann
im Ausland, der das Geld auf seinem Bankkonto zwischenlagert. An dieser
Stelle wird dann der Empfänger aufgefordert mitzuhelfen und in Kontakt mit
dem Absender zu treten. Natürlich müsse der Empfänger eine Vorauszahlung
leisten, um die Gebühren und fiktiven Bestechungen zu bezahlen.
Sollte der Empfänger darauf eingehen, wird dieser mit Verzögerungstaktiken
und weiteren Vorauszahlungen hingehalten, bis dieser entweder kein Geld
mehr zur Verfügung hat oder aufgibt (oder im schlimmsten Fall beides). Die
”Nigerian Connection“ gilt als die bestorganisierte Betrüger-Organisation derzeit.
Sie sitzt in Nigeria und arbeitet mit Landsleuten in den Zielländern zusammen,
um ihren Betrug auszuführen. Selten wird seitens der nigerianischen
Regierung oder Banken der Versuch unternommen, diese Organisation zu zerschlagen.
Die Organisation verlässt sich auch darauf das die meisten Opfer
sich nicht bei den Behörden melden, da sie nicht zugeben wollen, dass sie auf
ein illegales Geschäft eingegangen sind.
Diese Betrugsmethode wird nach dem relevanten Paragraphen im nigerianischen
Strafgesetz buch außerhalb Europas auch “419 Scam” oder kurz “419”
genannt.
Die E-Mails variieren dabei sehr stark, was die Gründe für das Umschichten
von Geldern angeht und werden stark an aktuelle Themen angepasst. So
dauerte es keine 6 Tage, bis die “Nigerian Connection” ihren Inhalt auf die
Tsunami-Katastrophe im Dezember 2004 angepasst hatten. In dem Fall wurde
aber nicht mit einem illegalen Geschäft gelockt, sondern nur an die Spendenwilligkeit
appelliert.
2.5.3 UBE – Unsolicited Bulk E-Mail
UBE (Unerwünschte Massenmails) bezeichnen Mails, die keinem direkten
kommerziellen Erfolg dienen. Diese werden zum Verbreiten von Hoax-
Meldungen 8 , zum manipulieren einer Meinung und zur Gewinnung von persönlichen
Daten verwendet.
8 falschen Informationen

2.5. Begriffsbestimmung Spamarten 19
2.5.3.1 Politisch motivierter Spam
Drei Tage vor den Europawahlen 2004 startete ein neues Ausmaß an politisch
motivierten Spam. Der Wurmautor des Sober Wurms nutzte die infizierten
Rechner, um seine rechtsradikalen Botschaften zu verteilen. Der Inhalt der
Mails war dabei sehr kurz gehalten und versuchte scheinbar wahre Begebenheiten
aufzuzeigen, in denen Ausländer als kriminell und gefährlich dargestellt
wurden. Diese Spam-Welle hatte ein derartiges Ausmaß, dass dadurch
die großen E-Mail Provider in Deutschland ihre Mail-Server anpassen mussten,
um diese Mails vor einer Virus-Überprüfung abzulehnen. [HE04]
2.5.3.2 JoeJobs
Gegen den Empfang von Spam-Mails gibt es mehrere Abwehrmöglichkeiten,
auf die bereits genauer eingegangen wurde. Unangenehmer ist dabei die
umgekehrte Version. Dabei wird die eigene Mail-Adresse (oder die Firmen-
Domain) als Absender von Spam-Mails genutzt und somit der (scheinbare)
Absender diskreditiert. Das Fälschen von MAIL FROM: oder dem From:-
Header ist dabei trivial. Der erste bekannte Fall dieser Diskreditierung betraf
“joes.com” [JD97]. Damals sind Spam-Mails aufgetaucht, die den Anschein
hatten, als ob sie für “joes.com” werben. Der Betreiber musste daraufhin seinen
Provider und diverse Blacklisten überzeugen, dass er mit dieser Spam-
Welle nichts zu schaffen hatte und das Opfer einer Verleumdungs-Kampagne
war.
Gegen solche JoeJobs gibt es derzeit kein standardisiertes Mittel. Die MARID
(MTA authorization in DNS) Workinggroup des IETF versuchte im Jahre 2004
mit mehreren Vorschlägen das Problem anzugehen. Aufgrund von Lizenzstreitigkeiten
unter den Teilnehmern, löste sich die Gruppe Ende des Jahres
2004 [TH04] ohne einen verabschiedeten Standard auf.
2.5.3.3 Phishing
Messagelabs bezeichnet in [ML05] das abgelaufene Jahr 2004 als das Jahr
des “Phishings”. Phishing bezeichnet Mails, in denen versucht wird, Konto-
, Login- oder Kreditkartendaten vom Empfänger zu erhalten. Hierzu wird
der Empfänger mit einer E-Mail getäuscht, die vorgibt von der zuständigen
Organisation 9 zu sein. Der Begriff Phishing leitet sich aus den drei Worten
“password harvesting fishing“ ab.
Am Anfang genügte es, das HTML-Layout der E-Mails an das Layout der jeweiligen
Organisationen anzupassen und mit einem Formular für die Daten
zu versehen, dessen Inhalt dann aber an den Betrüger übermittelt wurde. Um
noch effektiver zu werden passten sich die “Phisher” an und nutzten URL-
Spoofing in den E-Mails. Durch eine Browserschwäche glaubte der Benutzer,
9 Bank, eBay, PayPal etc.

20 Kapitel 2. Grundlagen
dass er sich auf den Seiten der Organisation befand und gab bereitwillig alle
nötigen Daten im Formular an.
In der aktuellste Angriffsmethode [EJ05] wird die IDN-Domain-Verarbeitung 10
in Mozilla Produkten ausgenützt. Hierbei werden übliche Zeichen als Sonderzeichen
kodiert. Dadurch ist es möglich, dem Benutzer einen scheinbar korrekten
Domainnamen anzuzeigen. Als www.paypal.com kann mittels IDN auch
www.xn–pypal-4ve.com angegeben werden, welches ein ähnlich aussehendes
“a” verwendet.
2.5.3.4 Address Verification
Mittels präparierten HTML-Image-Tags innerhalb einer E-Mail wird versucht,
eine Mailadresse zu verifizieren. Ebenfalls sehen es diese sogenannten “Address
Harvester” als ausreichend verifiziert an, wenn eine E-Mail ohne Mailinhalt
zugestellt wird und keine Fehlernachricht produziert wird. Hierbei
werden auch die schon beschriebenen “remove-me”-Links verwendet. Solche
überprüften Mailadressen lassen sich im Direktmarketing Geschäft teuer verkaufen,
da hier die Durchdringungsquote um einiges höher liegt als bei einem
via Webrobots von Webseiten gesammelten Mailadressen Bestand.
10 Umlaut Domains

Kapitel 3
Methoden der Spam- und
Virenerkennung
Je nach Betroffenheitsgrad der Empfänger gibt es unterschiedliche Arten der
Reaktion auf Spam-Mails: Empörung, Ärger, Resignation, störrisches Wegklicken
. . .
In diesem Kapitel wird beschrieben mit welchen Methoden Spammer arbeiten
und welche technischen Möglichkeiten zur Spamvermeidung sich daraus ergeben.
Neben einer Schulung der Mitarbeiter zur Vermeidung unerwünschter
Mails müssen technische Filtermaßnahmen eingesetzt werden.
3.1 Methoden der Spammer
Bevor es möglich ist, Methoden der Spamerkennung zu finden, muss man sich
der Methoden der Spammer bewusst werden.
3.1.1 Open Relay
Als Open Relay werden Mailserver bezeichnet die ohne gesonderte Autorisierung
E-Mails an beliebige Empfänger-Domains annehmen und weiterleiten.
Um die eigenen Ressourcen zu schonen, bedient man sich bei solchen MTAs.
Dank mehrerer RCPT TO: kann ein Spammer bereits mit einer DSL-Leitung
Millionen von Empfängern erreichen wenn ein Open Relay für ihn die Mail
in mehrere einzelne Mails aufteilt. Obwohl Mailadministratoren als erstes ihre
Mailserver entsprechend konfigurieren sollten, damit diese nicht als Open
Relay missbraucht werden können, gibt es immernoch Installationen im Netz
mit falsch konfigurierter Software. Dies passiert zum einen durch Standard-
Installationen, die nicht weiter angepasst werden und zum anderen aufgrund
von Konfigurationsfehlern. So glauben einige Mail-Administratoren noch heute,
dass es als Authentifizierung genüge wenn der MAIL FROM: aus dem eigenen
Domain-Bereich stammt.

22 Kapitel 3. Methoden der Spam- und Virenerkennung
3.1.2 Open Proxy
Unter Open Proxy versteht man Systeme, die Dienste zum weiterleiten von
Verbindungen ohne eine Berechtigungsüberprüfung anbieten. Durch der Verbreitung
von DSL und Heimnetzwerken hat die Anzahl dieser Systeme stark
zugenommen. Somit bietet sich für Spammer eine neue Möglichkeit Mails
über möglichst viele Systeme zuzustellen und damit ihre Herkunft zu verschleiern.
Heimanwender PCs mit Proxy-Software sind häufig nicht vor Missbrauch
aus dem Internet geschützt. Hierbei genügt es bereits, wenn der Proxy
Dienst einen TCP Port weiterleitet, wie es zum Beispiel bei einem HTTP-
Proxy 1 üblich ist. Mit einem Port-Scanner, der gleichzeitig die Konfiguration
des Proxy-Servers überprüft, gelingt es den Spammern in kurzer Zeit eine Vielzahl
von Open-Proxy-Systemen zu finden.
Ein weiterer beliebter Proxy Dienst stellt der Socks-Proxy dar. Eine ehemals
beliebte Anwendung bei Windows-Gateways war die “Wingate” Software, die
standardmäßig mit einem offenem Socks Proxy installiert wurde.
3.1.3 Trojaner / Viren / Kompromittierte Maschinen
Durch die starke Nutzung des Internets ist auch die Anzahl der durch Trojaner,
Viren oder Exploits 2 kompromittierten Maschinen angestiegen. Wie durch
den Heise Verlag in [JK04] nachgewiesen wurde, verkaufen Virenautoren die
Ressourcen ihrer infizierten Maschinen an Spamversender. Im vorliegendem
Fall handelte es sich um den Trojaner Randex, der mittels IRC steuerbar war.
Hierbei gab es die Möglichkeit, einen Socks-Proxy-Server zu installieren. Die
IP-Adressen der infizierten Rechner werden von den Virenautoren an Spammer
verkauft. Somit kann der Spammer seine Herkunft verschleiern.
Da E-Mail-Würmer durch ihre SMTP Verbreitungsroutine schon die nötigen
Werkzeuge mit sich bringen, liegt auch die Vermutung nahe, dass Virenautoren
den Spammern nicht nur mit Socks-Proxies helfen, sondern auch direkt
entsprechende Spam Läufe starten. Wie im Abschnitt 2.5.3.1 beschrieben, nutzte
bereits der Autor des Sober Wurms die infizierten Rechner um seine politisch
motivierten Botschaften zu verbreiten.
Bei dieser Methode stellt der kompromittierte Rechner eine direkte Verbindung
zum MX-Host der Empfänger-Domain her. Wie in [IH05] dargestellt, gibt
es bereits einen Trojaner der in den Einstellungen des Benutzers nach einem
SMTP-Server sucht, den er zum versenden seiner E-Mails missbrauchen kann.
Es bleibt abzuwarten, ob durch das Blockieren von dynamischen IPs sich diese
Methode bei den Würmern durchsetzen wird.
1 mittels POST- oder CONNECT-Befehl
2 aus dem Englischem: “to exploit” - ausnutzen, in diesem Fall das Ausnutzen von Software
Fehlern.

3.2. RBL – Echtzeit Ausschlussliste 23
3.2 RBL – Echtzeit Ausschlussliste
Realtime Blacklists (RBL) dienen zur Blockade von als Spamquellen bekannten
IP-Adressen. Zur Abfrage nutzt man das DNS-Protokoll. Bei einem Verbindungsaufbau
kann der Server anhand der Client-IP-Adresse überprüfen, ob
diese bereits als Spammer identifiziert wurde. Verschiedene Organisationen
haben sich auf die Pflege der Datenbestände solcher RBLs spezialisiert. Dabei
werden nicht nur bekannte Spamquellen aufgenommen sondern, je nach Anbieter
und Anliegen, auch andere Kategorien. Der Mail-Server-Administrator
muss sich hierbei für eine Liste entscheiden, deren Datenbestand er vertraut.
Es darf dabei nicht außer acht gelassen werden, dass bei Nutzung einer RBL
ein Teil der E-Mail-Policy an eine externe Organisation übergeben wird.
Die verfügbaren RBLs und die Beschreibung ihres Datenbestands sind unter
http://www.openrbl.org/zones.htm aufgelistet.
RBLs gibt es aber nicht nur für Client-IP-Adressen. So wurde im April 2004
eine weitere Form der RBL berühmt:
Die Spam URI Realtime BlockList (SURBL) dient nicht zum Abfragen des sendenden
Mailservers, sondern testet die in der E-Mail enthaltenen URIs gegen
die SURBL. Diese Strategie nutzt die Beobachtung aus, dass Spammer von
überall aus Mails verschicken, aber selten ihren Webserver wechseln.
RBLs haben sich als wirksame Möglichkeit erwiesen, um spammerfreundliche
Provider zu einem Umdenken zu bewegen. Sollte der komplette
Adressbereich eines Providers gelistet werden, muss dieser mit erheblichen
Einbußen rechnen durch einen möglichen Verlust seiner Kunden.
Eine Möglichkeit für Spammer dies zu Umgehen, birgt das IP-Hijacking
[SR04]. Hierzu announcen Provider einen ungenutzten IP-Block, damit Spammer
“frische” IP-Adressen für ihren relativ kurzen Spam lauf erhalten. Nach
dem Spamlauf wird der IP-Space wieder freigegeben.
3.3 Greylisting – Graue Listen
Im Gegensatz zu den RBLs versucht Greylisting das Problem anhand der
SMTP RFC anzugehen. Das Prinzip des Greylisting [EH03] baut auf den
Queue-Mechanismus der Mailserver. Sollte der Ziel-Mailserver einen temporären
Fehler ausgeben, ist der Client dazu verpflichtet, die Mail zu einem späterem
Zeitpunkt noch einmal zu senden. Um dies zu erreichen, liefert der Ziel-
Mailserver nach dem RCPT TO: einen temporären Fehler, und speichert ein
Triplet, bestehend aus MAIL FROM: , RCPT TO: und der Client-IP-Adresse.
Bei einem erneuten Zustellungsversuch innerhalb eines definerten Zeitrahmens,
bei dem das Triplet unverändert bleibt, wird dieses dann “Whitelisted”
und für zukünftige Transaktionen zugelassen.
Spammer sind daran interessiert, ihre Nachrichten möglichst schnell und mit
geringem Ressourcenverbrauch zu versenden. Da derzeitig bei der Zustellung

24 Kapitel 3. Methoden der Spam- und Virenerkennung
über Open Proxy oder Trojaner-Systeme kein Queueing Verfahren zum Einsatz
kommt, wirken temporäre Fehler wie eine permanente Ablehnung. Laut
Genua [GE04] können damit 99% der Spam-Mails unterdrückt werden.
Ein Problem dieser Methode stellen große Mail-Systeme wie gmail.com oder
btinternet.com dar, die bei einem erneuten Versenden nicht zwangsweise von
der gleichen IP-Adresse, oder im schlimmsten Fall einem anderen Netzblock,
kommen. Ebenfalls muss beachtet werden das nicht alle fehlerhaften Implementierungen
auf einen Spammer schließen lassen.
Auch wenn SMTP nicht für Echtzeit Kommunikation ausgelegt ist, bringt dieses
Verfahren eine unnötige Verzögerung in den gesamten Mail-Verkehr, der je
nach Client-MTA-System bis zu 8h dauern kann. Ein weiterer Nachteil ist der
erhöhte Verbrauch der Ressourcen (durch anwachsende lokale Queue) beim
Client-System, aufgrund des Greylistings auf Empfängerseite.
Eine Anpassung an Greylisting ist sowohl für Würmer, als auch für Spammer
kein großer Aufwand. Wie in Abschnitt 3.1.3 auf Seite 22 erwähnt, wird im
ersten Schritt die vorhandene Provider Struktur durch die Virenautoren und
Spam-Versender genutzt. Die SMTP-Server der missbrauchten Clients sind
dann in der Lage, die Mails für einen zweiten Zustellungsversuch in ihrer
Queue zu halten. Sollten die Provider sich anpassen und ihre SMTP-Server
mit aktuellen Viren- und Spamfiltern versehen, müsste die Software am infizierten
Rechner eine lokale Queue halten. Auch diese Methode bedarf keinen
größeren Aufwand, wenn man bedenkt, dass kleinere Mail-Software, wie zum
Beispiel SSMTP, bereits mit 1800 Zeilen C-Code auskommt.
3.4 Fehlerhafte SMTP-Implementierung
Die Spammer haben in der Vergangenheit gezeigt, dass die von ihnen benutzte
Software bestimmte Merkmale aufweist. In der Regel achten sie bei der Entwicklung
ihrer Software vordergründig auf ein schnelles Versenden von Mails
und nicht auf RFC-Konformität. Die Verstöße gegen RFC-Standards können
als Antispammethode genutzt werden.
• SMTP-Banner – Nach einem erfolgreichen TCP-Connect muss sich der
Server zuerst mit einem SMTP-Banner “vorstellen”. Ein Client muss erst
auf dieses Banner warten, bevor er sein EHLO/HELO-Kommando schickt.
Fügt der Server vor dem senden des Banners eine künstliche Wartezeit
von fünf Sekunden ein und weist Clients, die schon vorher ein Kommando
senden, mit einem 5xx Fehler ab, werden bereits schlechte SMTP-
Implementationen identifiziert. Leider trifft dies auch auf einen Dienst
wie Gmail zu, die aufgrund ihrer großen Mail-Infrastruktur ebenfalls die
Mail so schnell wie möglich aus ihrem System haben wollen. Doch glücklicherweise
startet Gmail einen zweiten Versuch gleich im Anschluss, bei
dem sie auf das SMTP-Banner warten.

3.5. Verteilte Prüfsummen-Verfahren 25
• EHLO/HELO – Laut RFC2821 darf im EHLO/HELO nur ein Hostname
als Parameter enthalten sein. Eine Ausnahme zum Hostname besteht,
falls der Client keinen Reverse-Eintrag besitzt, kann dieser auch seine IP,
in der Form [], als Parameter verwenden. Die Nutzung verschiedener
Sonderzeichen ist damit ausgeschlossen. Laut RFC ist es sogar
Pflicht, bei ungültigen Sonderzeichen im EHLO/HELO die Verbindung
mit einem 501 Fehler zu beenden.
Zitat RFC 2821 Section 4.1.2:
[...] In particular, the underscore character is not permitted.
SMTP servers that receive a command in which invalid character
codes have been employed, and for which there are no
other reasons for rejection, MUST reject that command with a
501 response.
Eine Situation, die laut RFC nicht vorkommen kann, ist das senden des
Zielsystem-Hostnamen als Parameter. Dies würde den Sender nicht eindeutig
Identifizieren und kann daher ebenfalls mit einer Fehlernachricht
quittiert werden.
• MAIL FROM – Laut RFC muss der im MAIL FROM: angegebene Absender
in der Lage sein, Non-Delivery-Reports zu empfangen. Dadurch ist
er in der Lage, gegebenenfalls über ein anderes Kommunikationsmedium
den Empfänger zu benachrichtigen. Sollte dieser nicht dazu in der
Lage sein, kann der SMTP-Server die Transaktion mit einer Fehlermeldung
quittieren. Es gibt einige Mail-Server die einen sog. “sender verify
callout” beherrschen, um die Validität einer Mail-Adresse zu überprüfen.
• RCPT TO – Als Empfänger einer Mail darf nur eine Adresse angegeben
werden, für die sich das Zielsystem zuständig fühlt. Bei sogennanten
Smarthost Relay Servern gilt noch die Bedingung, dass der Client sich
authentifiziert hat (via IP oder SMTP AUTH-Mechanismen).
Bei mehreren fehlgeschlagenen RCPT TO: kann davon ausgangen werden,
dass eine Brute-Force-Attacke 3 läuft. In diesem Fall kann der Spam-
Versand durch das künstliche Verzögern der Kommandos oder das beenden
der Verbindung behindert werden. Damit werden Ressourcen auf
Seiten des Spam-Versenders gebunden, die nicht für weitere Adressverifikation
zur Verfügung stehen.
3.5 Verteilte Prüfsummen-Verfahren
Beim verteilten Prüfsummen-Verfahren (zum Beispiel DCC – Distributed
Checksum Clearinghouse) wird für jede empfangene E-Mail eine Prüfsumme
3 im amerkanischen auch “rumpelstilzchen-attack” gennant

26 Kapitel 3. Methoden der Spam- und Virenerkennung
gebildet, welche an ein verteiltes Rechnernetzwerk weitergeleitet wird. Aus
der resultierenden Antwort kann darauf geschlossen werden, wie oft diese
E-Mail von anderen Rechnern empfangenen wurde. Jede Abfrage nach einer
Prüfsumme erhöht dabei gleichzeitig den Zähler. Ab einem definierten
Schwellwert gilt die Mail als Spam. Dieses Verfahren erkennt dabei nicht notwendigerweise
nur Spam, sondern auch erwünschte identische Massenmails
(zum Beispiel Newsletter).
Da in Spam-Mails oftmals versucht wird, einen persönlichen Bezug zum Empfänger
zu suggerieren, ändert sich die Anrede in den Mails. Ebenso versuchen
Spammer durch zufällige Zeichenfolgen innerhalb einer Mail, dieses
Checksum-Verfahren zu umgehen. Daher werden sogenannte Fuzzy-
Checksum-Verfahren verwendet, deren Prüfsummen sich durch kleine Veränderung
nicht beeinflussen lassen. Um die Fuzzy-Checksum-Verfahren zu umgehen
muss ein Spammer nur den zufälligen Textbaustein größer gestalten als
den eigentlichen Mail-Inhalt.
3.6 Regular Expression - Regulärer Ausdruck
Reguläre Ausdrücke sind genau definierte Textsuchmuster, mit denen es möglich
ist, Zeichenketten zu beschreiben.
Beispiel:
/v.{0,2}i.{0,2}a.{0,2}g.{0,2}r.{0,2}a/i
Die Mächtigkeit von regulären Ausdrücken besteht in den vielen Variationen
eines Suchmusters. So passt dieses Beispiel auf mehrere Schreibweisen des
Wortes “Viagra”. Dies kann bereits an vielen Mail-Servern beim Empfang einer
E-Mail, eingebunden werden, um zum Beispiel anhand von Textmustern
im Subject-Header die Mail abzulehnen.
Den Mail-Inhalt mittels regulären Ausdrücken zu untersuchen, hat sich als
Standard zur Spamerkennung etabliert. Hierbei muss aber darauf geachtet
werden, dass nicht bei einer einzelnen gefundenen Zeichenfolge eine Klassifizierung
als Spam vorgenommen wird. Dadurch wird verhindert, dass einzelne
Treffer in einer Ham-Mail den Text als Spam einordnen. Erst die Summe
aller Treffer entscheidet über den Charakter einer E-Mail. Deswegen nutzen
Antispam-Produkte das Ergebnis mehrerer regulärer Ausdrücke als Basis zur
Textklassifizerung.
3.7 Bayes – Statistische Analyse
Paul Graham beschrieb in [PG02] zum ersten Mal den Einsatz einer statistischen
Wahrscheinlichkeitsrechnung zur Erkennung von Spam. Paul Graham
war selber jahrelang Mitentwickler diverser Antispam-Methoden und

3.7. Bayes – Statistische Analyse 27
bemerkte, dass die derzeitigen Filtermethoden nur reaktiver Natur waren. So
wurden Textbausteine von Spam-Mails analysiert und entsprechende reguläre
Ausdrücke an die neuen Bausteine angepasst. Spammer hingegen optimierten
ihren Spam mittels der aktuellen Spam-Filter und konnten somit sicher sein
dass ihre Mails nicht gefiltert wurden. Diesem Katz-und-Maus-Spiel wollte
Graham durch eine statistische Analyse der Spam-Mails entgehen.
In der ersten Lernphase eines Bayesian Filter kategorisiert der Benutzer selbst
seine Mails nach Spam und Ham Kriterien. Diese Sammlung wird dem Filter
übergeben, der anhand der vorgenommenen Kategorisierung eine Einordnung
einzelner Tokens als signifikant für Spam oder Ham durchführt.
Neu eintreffende Mails werden dann ebenfalls in Tokens aufgeschlüsselt und
deren Wahrscheinlichkeit der Tabelle für das Auftreten in Spam beziehungsweise
Ham der Tabelle entnommen. Mittels des Satz von Bayes lässt sich aus
den Token-Warscheinlichkeiten die Wahrscheinlichkeit ermitteln, dass die eintreffende
Mail eine Spam-Mail ist oder nicht.
Das Prinzip funktioniert aber nur, wenn die Datenbank mit entsprechend vielen
Mails trainiert wurde. Hierbei geht zum Beispiel SpamAssassin von einer
Mindestanzahl von jeweils 200 Ham und Spam-Mails aus. Die Methode hat
sich auch als äußerst resistent gegenüber Falsch-Positiven bewiesen. Wenige
Spam-Mail Merkmale in einer Ham-Mail führen also nicht zu einer Einordnung
als Spam.
Beispiel:
Gegeben sind drei Tokens mit der Spam-Wahrscheinlichkeit von
p 1 = 10%, p 2 = 89% und p 3 = 14%. Dann gilt:
p total =
(0.10)(0.89)(0.14)
(0.10)(0.89)(0.14)+(1−0.10)(1−0.89)(1−0.14)
Dies ergibt eine Wahrscheinlichkeit von p total = 12, 7% dass diese Mail Spam
sein könnte.
Dieses vereinfachte Beispiel verdeutlicht, dass selbst bei einem Token mit hoher
Spam-Wahrscheinlichkeit sich der Gesamt Charakter der E-Mail nicht ändern
wird. In der Realität werden auch E-Mailr-Header und komplette Textbausteine
verwendet, so dass 3-4 Tokens mit hoher Wahrscheinlichkeit einer
Vielzahl von Tokens mit niedriger Wahrscheinlichkeit gegenüberstehen.
Das Bayes Theorem [TB63] erfordert einen hohen Rechenaufwand, weswegen
man zur Spamfilterung eine vereinfachte Version namens “Naiv Bayes”
verwendet. Dabei wird davon ausgegangen, dass die Token-Merkmale keinen
Bezug zueinander haben. Was im Falle des Wortes “Grüßen“ (wie der Name
schon sagt) recht naiv ist, da meist noch “freundlichen” vorangestellt wird.
Trotz dieser Einschränkung funktioniert das Naiv Bayes aber immer noch erfolgreich
bei der Erkennung von Spam Mails. Sofern die Bayes-Datenbank mit
genügend Beispielen zu jeder Kategorie befüllt wurde.

28 Kapitel 3. Methoden der Spam- und Virenerkennung
3.8 Weitere Methoden
Es gibt noch eine Vielzahl weiterer Methoden, um Spam zu bekämpfen. Da
diese aber für den Einsatz in einer Unternehmenslösung unsinnig erscheinen,
werden diese kurz beschrieben und anschliessend begründet, weswegen sie
nicht für die weitere Verwendung in der Diplomarbeit relevant sind.
3.8.1 Tarpitting
Beim Tarpitting wird eine künstliche Verzögerung benutzt, sobald der Client
eine bestimmte Anzahl von RCPT TO: pro Mail verwendet. Dabei erhofft man
sich, dass ein Spammer, der tausende von RCPT TO:angibt mehrere Stunden
mit der Auslieferung einer Mail beschäftigt ist. Wenn sich der Versand lange
genug hinauszögert, könnte der Spammer bereits seinen Spamlauf beenden.
Nachteil dieser Methode ist der Verbrauch von eigenen System Ressourcen.
Ebenso wird dies leicht umgangen, indem Spammer die Anzahl der Empfänger
pro SMTP-Verbindung reduzieren.
3.8.2 Teergrubing
Teergrubing basiert auf dem gleichen Verzögerungsprinzip wie Tarpitting.
Doch im Gegensatz zum Tarpitting verzögert eine “Teer-Grube” bereits ab
dem ersten Kommando. Hierfür gibt es mehrere unterschiedliche Ansätze. So
wird zum Beispiel bei OpenBSD ein Daemon verwendet, der Zeichen für Zeichen
sendet und dazwischen eine konfigurierbare Pause einlegt. Clients, die
mit SMTP Erweiterungen (ELHO) umgehen können, werden mit sogenannten
’continuation lines’ hingehalten. Um nicht auch legitimen Sender auszubremsen,
kann auf den Datenbestand von RBL Quellen zurückgegriffen werden.
Sollte es doch zu einem “Falsch-Positiv” kommen, würde sich die Mail um
Stunden verzögern. Die Hoffnung der Netzgemeinde besteht darin, dass
Spammer nicht die Ressourcen aufbringen wollen, um ihre versendenden Maschinen
mit blockierten Sockets zu belasten.
Doch in Anbetracht der Vielzahl an Spammer-freundlichen Providern und der
Nutzung von kompromittierten Maschinen wirkt diese Methode nur bedingt
gegen Spam.
3.8.3 TMDA - Tagged Message Delivery Agent
Das TMDA Verfahren friert beim ersten Zustellungsversuch eine Mail ein und
informiert den Versender über diesen Vorgang. Dabei erhält der Sender meist
einen Link, mit dem er die Zustellung seiner Mail bestätigen kann. Sollte der
Sender nach einer bestimmten Zeit die Mail nicht bestätigt haben, wird diese

3.9. Virenfilter 29
gelöscht. Diese Methode basiert auf der Beobachtung, dass Spammer Fehlernachrichten
nicht auswerten. Praktisch einsetzbar ist dies jedoch nicht, da sie
dem Sender zuzätzliche Arbeit macht, und diese sich schnell von den automatischen
Nachrichten gestört fühlen.
Wenn beide Seiten (Sender und Empfänger) das TMDA Verfahren einsetzen,
ohne dabei die Confirmation Mails der Gegenstelle gesondert zu behandeln,
besteht die Gefahr, dass sich beide Systeme gegenseitig aufschaukeln, indem
sie jede weitere Confirmation Mail mit einer neuen Nachricht bestätigt haben
wollen. Dieser MTA-Ping-Pong kann zu einem Denial-of-Service führen.
3.8.4 MARID - MTA authorization in DNS
Die IETF stellte eine Arbeitsgruppe zusammen, die sich mit der Autorisierung
im DNS System befassen sollte. Hierbei wollte man die gefälschten MAIL
FROM: eindämmen. Einer der vorgeschlagenen Standards beruht auf dem bereits
implementierten SPF (Sender Policy Framework), welches via DNS ein
TXT-Feld vom Namerservers der Absenderdomain abfragt und auswertet, ob
der sendenden MTA bere chtigt ist, für diese Domain Mails zu verschicken.
Dabei zerstörte SPF ein Mail-Forwarding an weitere Domains. Letztendlich
löste sich die MARID Workinggroup Ende 2004 ergebnislos auf. Die vorgeschlagenen
Standards wurden von den meisten Mail-Server-Administratoren
nicht angenommen, da sie nur die Kundenbindung weniger großer Mail-
Anbieter unterstützen, aber nicht verhinderten, dass Spammer sich schnell eigene
Domains zulegten um dieses Verfahren zu umgehen.
Vereinzelt wird SPF noch zum Schutze von JoeJobs und Phishing Mails
angeboten. So verwenden zum Beispiel die großen E-Mail Provider wie
GMX/AOL/GMAIL solche SPF Einträge im DNS. Auch größere IT Unternehmen
wie SAP oder Microsoft veröffentlichen SPF Einträge auf ihren Nameservern.
3.9 Virenfilter
Da Viren glücklicherweise nicht so stark in ihrer Software Komponente variieren,
nutzen die Antiviren Scanner Signatur-Datenbanken mit den jeweils
aktuellen Viren. Diese Signaturen müssen stündlich aktualisiert werden um
gegen neue Würmer reagieren zu können.
Bei der Verbreitung über E-Mail unterscheidet man zwischen Würmern und
Trojanern. Würme r sind Viren, deren Hauptaufgabe darin besteht, eine möglichst
schnelle Verbreitung über E-Mail zu realisieren. Dafür untersucht der
Mail-Wurm den infizierten Rechner nach möglichen Empfängern, um sich anschliessend
selber zu replizieren und an diese zu senden. Damit der Wurm
sich erfolgreich verbreiten kann, nutzt er Fehler in der Mail-Client-Software

30 Kapitel 3. Methoden der Spam- und Virenerkennung
aus oder versucht dem Benutzer davon zu überzeugen, den Mail-Anhang zu
öffnen.
Der gängige Fachbegriff für diese Art von schadhafter Software ist “malware”.
Er entstand durch die Kombination von “malicious” = boshaft und Software
und beschreibt damit den böswilligen Charakter der Software.

Kapitel 4
Implementierung
In diesem Kapitel wird die gewählte Implementierung vorgestellt. Hierzu
wird das Konzept beschreiben und die Auswahl der einzelnen Komponenten
begründet.
4.1 Konzept
Wie schon in Kapitel 3 erwähnt, ist das Zusammenspiel der Abwehrmethoden
entscheidend für den Erfolg des Systems. Hierbei geht es nicht nur um eine
möglichst präzise Texterkennung, sondern gleichzeitig auch um die optimale
Ausnutzung der Performance eines Systems. In Tabelle 4.1 auf der nächsten
Seite werden die Abwehrmethoden nochmal zusammengefasst und ihre Performanceanforderungen
anhand der beschriebenen funktionsweise bewertet.
Diese Methoden sind aufgrund ihrer unterschiedlichen Performanceanforderung
entsprechend einzusetzen. Ziel soll es sein, dass Methoden
die weniger Ressourcen verbrauchen, vor den aufwendigeren Methoden
zum Einsatz kommen, so dass eine Filterung während des
SMTP DATA möglich wird. Dadurch wird es möglich die Annahme
der Mail noch während der SMTP-Session zu verweigern und

32 Kapitel 4. Implementierung
damit einen legitimen Sender über den Fehlschlag zu informieren.
Methode Wirkung Implementierung Performanceanforderung
IP-RBL Blockade auf IP Ebene.
SURBL Blockade von Spammer
Webservern
Greylist Temporäre Blockade
von SMTP gelieferten
Daten
SMTP Blockade von nicht
Syntax RFC Konformen
Mailern
Checksum Erkennung von Massenmails
Regular Erkennung von bekannten
Expression
Text- und
Headerbausteinen im
Mail Body
Am MTA während des
Verbindungsaufbaus
Textanalyse der Mail.
Im MTA während der
SMTP Prozedur
Im MTA während der
SMTP Prozedur
Textanalyse der Mail.
Textanalyse der Mail.
sehr gering
sehr gering
gering
gering
mittel
hoch
Naiv Statistische Analyse Textanalyse der Mail. sehr hoch
Bayes des Text- und Headertokens
im Mail
Body
Viren Filter
Patternanalyse der Patternanalyse einzel-
hoch
MIME Attachements ner Mail Anhänge.
Tabelle 4.1: Performance-Anforderung der einzelnen Methoden
Die einzelnen Komponenten des Systems können ausgelagert werden und bieten
so die Grundlage für eine hochverfügbare Clusterlösung. Die in Abbildung
4.1 auf der nächsten Seite dargestellten Komponenten werden im späteren
Verlauf beschrieben. Die abgebildete Architektur zeigt die Implementation.
Hierbei sind die Komponenten, welche sich mit der SMTP-Prozedur befassen
zu einer Einheit zusammengefasst. Sowohl die SQL, als auch die Quarantänen
Komponente können gemeinsam mit den SMTP Komponenten auf
einem System betrieben werden. Im Fall eines Ressourcenmangels des Systems,
können die Komponenten zu mehreren Systemen erweitert werden. Dabei
ist es denkbar, dass zum Beispiel nur die Antispam Komponente ausgelagert
wird oder aber die kompletten SMTP-Komponenten nachgebildet werden,
während diese auf eine gemeinsame Datenbank und Quarantäne zugreifen.

4.2. Mail Transfer Agent 33
Abbildung 4.1: Konzept der Architektur
4.2 Mail Transfer Agent
Es musste gewährleistet werden, dass jede einzelne Methode User- bzw Domainspezifisch
an- bzw. abschaltbar ist. Dies konnte nur mit einem komplexem
Regelwerk geschehen. Hier liegt auch die Stärke von exim. Die Konfiguration
ist in ACL (Access Control Language) gehalten und erscheint eher als
eine Skript Sprache als eine Konfigurationssprache. Aufgrund der genannten
Vorteilen wurde zur Implementierung der exim Mail Transfer Agent (MTA)
[EXIM/SW] ausgewählt.
Ebenso bietet exim (Ab Version 4.5) dank dem Exiscan Patch von Tom Kistner
die Möglichkeit, den Mail-Body schon während der SMTP Prozedur an einen
Virenscanner und an SpamAssassin zu übergeben. Dadurch können Viren bzw
Spam-Mails direkt abgelehnt werden.
Um einen eventuellen Cluster Betrieb zu gewährleisten, besitzt exim die Option,
mehrere SpamAssassin oder ClamAV in einem Round-Robin-Verfahren
anzusprechen. Sollte eine redundante Komponente ausfallen, wird diese für
einen definierbaren Zeitraum nicht weiter verwendet.
Zur Installation des exim genügte es unter Debian den aktuellen Backport von
“exim4-daemon-heavy“ zu installieren. Dieser kommt bereits mit dem exiscan
patch und bietet auch für die Zukunft die Möglichkeit, die Konfiguration
der einzelnen User Adressen und Domains in einer zentralen SQL-Datenbank
abzulegen.

34 Kapitel 4. Implementierung
4.2.1 exim Überblick
Die exim Konfiguration lässt sich in drei für diese Arbeit relevante Bereiche
aufteilen.
• ACL Access Control Language, die beim Empfang einer E-Mail entscheidet,
wie eine Mail nach definierbaren Kriterien verarbeitet wird.
• router definiert wie Adressen behandelt werden und über welchen
transport die Mail verarbeitet wird.
• transport gibt an welche möglichen Transportmechanismen (SMTP,
mbox) den Routern zur Verfügung stehen.
4.2.2 exim Konzept
Die Konfiguration des exim Daemons ist so aufgebaut, dass Änderungen am
Verhalten über cdb 1 oder SQL-Abfragen geschehen können. Auf diese Weise
muss sich der Administrator eines Mail-Systems nicht mit der auf den ersten
Blick ungewöhnlichen Konfiguration des Mailservers auseinander setzen.
Um eine User/Domain spezifische Konfiguration des Verhaltens zu ermöglichen,
wurden Makros definiert, die in der Datenbank nach der entsprechenden
Mailadresse suchen. Diese Abfragen werden vom exim Daemon im Cache gehalten
und stellen daher keine allzu große Belastung dar.
In der Standard-Installation, bei dem nur ein Mail-Gateway die Mails entgegen
nimmt, ist es unnötig eine SQL Datenbank für die exim Konfiguration
aufzusetzen. Hierfür hat sich das cdb Format bewährt, welches durch seine
konstante Datenbank eine Abfrage mit maximal zwei Dateizugriffen ermöglicht.
Dabei werden die Parameter in der exim Konfiguration aus der cdb-Datei
ausgelesen. Sollte eine redundante Installation mit mindestens zwei Gateways
ausgewählt werden, muss die Konfigurationsdatei nur an einer Stelle angepasst
werden, um auf einen zentralen SQL-Server zuzugreifen.
4.2.2.1 Das ACL Prinzip
Um das Konzept besser nachvollziehen zu können, muss man das ACL System
für diese Arbeit betrachten.
Die ACLs werden der Reihe nach abgearbeitet und sind in der Form
=
aufgebaut. Als Aktion kann dabei warn, accept, defer, require oder deny
ausgewählt werden.
1 constant database format

4.2. Mail Transfer Agent 35
• warn dient dabei zum Hinzufügen von Header Zeilen oder zum Generieren
von zusätzlichen Einträgen in die Logdatei.
• defer meldet dem Client einen temporären Fehler.
• require wird verwendet um eine weitere Bedingungen erfüllen zu
müssen.
# g r e y l i s t i f mail comes from b l a c k l i s t e d or unresolveable hosts .
defer message = $sender_host_address i s not yet authorized to d e l i v e r mail \
from to . \
reason f o r g r e y l i s t i n g : \
$acl_m8 \
Please t r y l a t e r .
log_message = g r e y l i s t e d ( $acl_m8 ) .
! senders = :
a c l
= dnsbl_or_unresolved
s e t acl_m9 = $ { mask : $sender_host_address /24} $sender_address\
$local_part@$domain
s e t acl_m9 = $ { readsocket {/ var/run/ g r e y l i s t d /socket } { $acl_m9 } { 5 s } { } { } }
condition = $ { i f eq {USERBLGREY } { 1 } { 1 } { 0 } }
condition = $ { i f eq { $acl_m9 } { grey } { true } { f a l s e } }
Listing 4.1: exim ACL Beispiel
Im Listing 4.1 wird eine Aktion der acl\_check\_rcpt dargestellt, die das
Greylisting basierend auf RBL Daten und fehlerhaften DNS Einträgen (durch
eine sub-acl) implementiert. Wenn jede einzelne Bedingung zutrifft, wird als
Aktion das defer ausgeführt mit der in message angegebenen Fehlernachricht.
Gleichzeitig wird ein Log Eintrag generiert, der über den Grund für das
Greylisting informiert.
$acl_m8 wird durch die ACL dnsbl_or_unresolved gesetzt. Die Aktion
wird nur ausgeführt, wenn der Sender über TCP/IP eine Mail versucht auszuliefern.
Das USERGREY ist ein Makro, welches in einer Datenbank überprüft
ob für den Empfänger ein Greylisting erwünscht ist.
Prinzipiell werden bei der Einlieferung einer Mail zwei ACLs aufgerufen.
• acl_check_rcpt wird bei jedem RCPT TO: abgearbeitet. Hier werden Bedingungen
definiert, die mit dem Envelope und dem Sender einer E-Mail
zusammenhängen.
• acl_check_content Wird nach dem Empfang des Mail-Bodys abgearbeitet.
Hierbei kann auf die Werte der einzelnen Inhaltsfilter eingegangen
werden und dementsprechende Aktionen ausgeführt werden.
4.2.2.2 Einbindung externer Scanner
Dank des exiscan Patches von Tom Kistner ist die Integration externer
Content-Scanner in exim deutlich vereinfacht worden. Im Gegensatz zu einer
häufig implementierten Sandwich Konfiguration (in der ein Mailer die Mails

36 Kapitel 4. Implementierung
intern an einen Virenscanner und Spamfilter durchreicht), kann man die Aktion
bei exim dort konfigurieren wo sie relevant ist: im MTA der die Mail an
vorderster Stelle entgegen nimmmt. Es sollte nicht Aufgabe eines externen
Programms sein, über die Verarbeitung des Mailers zu entscheiden, vielmehr
sollte der Mailer mit Hilfe von externen Informationen die Entscheidung treffen.
Dies vereinfacht unter anderem das Lokalisieren von Fehlerquellen beim
Mailempfang. Anstatt in vielen unterschiedlichen Protokolldateien nach der
Information zu einem Fehler zu suchen, genügt es, eine Datei des MTA zu
analysieren.
Mit dem exiscan Patch kann eine Vielzahl von externen Scanner eingebunden
werden.
Diese sind unter anderem:
• sophos
ein Antiviren-Scanner von Sophos (http://www.sophos.com)
• aveserver
der Kaspersky Antiviren-Daemon
• clamd
bindet das unten beschriebene Clam AV Toolkit ein
• fsecure
der von F-Secure (http://www.f-secure.com) entwickelte Antiviren
Scanner
• drweb
eine Schnittstelle zum DrWeb (http://www.sald.com/) Antiviren-
Daemon
• cmdline
ein über Kommandozeile aufgerufener Virenscanner.
• spamd
eine Schnittstelle zum SpamAssassin Daemon
• brightmail
Einbindung der Brightmail Antispam Schnittstelle (http://www.
brightmail.com)
4.2.3 implementierte ACLs
Wie schon beschrieben werden Datenbankabfragen genutzt, um Informationen
über die user- oder domainspezifischen Konfigurationen zu erhalten. Diese
sind durch Makros in den einzelnen ACLs eingebettet. Eine Veränderung
im Konfigurationsschema kann dadurch an einer zentralen Stelle in der Konfiguration
vorgenommen werden.

4.2. Mail Transfer Agent 37
4.2.3.1 acl_check_rcpt ACL
Abbildung 4.2: acl_rcpt_check Konzept.
Um das Konzept hinter den einzelnen ACLs besser zu vermitteln, wird auf
einige einige Besonderheiten eingegangen. Selbstverständliche Operationen,
wie zum Beispiel das Ablehnen von Mails für die der Server nicht zuständig
ist, werden dabei nicht erläutert, was aber nicht bedeutet, dass diese Mechanismen
nicht vorhanden sind.

38 Kapitel 4. Implementierung
Die acl_rcpt_check ACL ist dementsprechend ausgelegt, dass “merkwürdig”
erscheinende Sender im ersten Anlauf nicht zu der aufwendigen Inhaltsanalyse
vordringen können.
Ebenso wird an dieser Stelle die userspezifische Konfiguration aus der Datenbank
abgefragt. Sollte es für den User keine Konfiguration geben, wird versucht,
eine domainspezifische Konfiguration abzufragen. Sollte dies wieder
zu keiner erfolgreichen Abfrage führen, wird eine Standardkonfiguration verwendet.
Jede der beschriebenen Aktionen ist daher an beziehungsweise abschaltbar.
Sollte eine Mail an mehr als einen Empfänger adressiert sein, werden die Empfänger
verglichen. Bei gleicher Domain wird die Abfrage von userspezifisch
auf domainspezifisch geändert. Sollte die Domain sich unterscheiden, wird ein
temporärer Fehler für den Empfänger ausgegeben, damit dieser beim nächsten
Zustellungsversuch verwendet wird.
RBL
Als erstes wird der sendende Host einer Überprüfung gegenüber als konservativ
geltenden RBLs überprüft. Dies verlangt nur einen geringen Aufwand
und trifft bereits die meisten als Spam-Versender verifizierten IPs.
Greylisting
Da der Erfolg von Greylisting in dieser Arbeit nicht außer Acht gelassen werden
konnte, wurde diese in einer weniger aggressiven Methode eingesetzt. Die
Idee entstand durch die Überprüfung diverser RBL Organisationen und den
Auswirkungen, wenn deren Antworten zum Ablehnen von Mails verwendet
wird. Die “Falsch-Positiv” Rate ist bei diesen RBLs unbrauchbar hoch. Greylisting
dagegen behandelt jeden Absender auf die gleiche Weise, und verzögert
den Empfang einer (legitimen) E-Mail auf bis zu acht Stunden. Desweiteren
wird Greylisting nur solange erfolgreich sein, bis die Trojanerentwickler
und Open-Proxy-Missbraucher ihre Mails über den Smarthost des Providers
ausliefern. Die Kombination aus diesen aggressiven RBL-Organisationen und
dem Greylisting löst damit gleich zwei Probleme: Fälschlicherweise gelistete
Mailserver werden beim zweiten Versuch zugelassen, und Trojaner/Würmer
bzw Open-Proxy-Misbraucher werden an vorderster Front abgelehnt.
Die Implementation in exim wird dadurch realisiert, dass durch eine weitere
ACL überprüft wird, ob für diesen Sender ein Greylisting angewandt wird.
Sollte der Sender einen zweiten Versuch starten, wird dieser dann auch akzeptiert.
Diese Sub-ACL entscheidet aus dem Datenbestand von vier RBLs und
überprüft ob der sendende Host einen passenden rückwärts auflösbaren DNS-
Namen besitzt. Sollte dieser DNS-Name noch einem Pattern entsprechen, dass
auf dynamische Host zugeschnitten ist, wird ebenfalls ein Greylisting angewandt.
Sollte es wider Erwarten doch zu Zustellungsproblemen bei einem legitimen
Sender kommen, kann dieser durch die Fehlermeldung erkennen, ob
er auf einer RBL gelistet wurde oder durch seinen DNS Eintrag abgewiesen
wurde.

4.2. Mail Transfer Agent 39
Recipient Verify Callout
Um unnötige unzustellbare Fehlermeldungen zu vermeiden, wird der Empfänger
durch einen sogenannter “SMTP callout” überprüft. Hierbei wird der
interne Mailer befragt, ob der Empfänger existiert, bzw. ob Mails für diesen
Empfänger angenommen werden. Damit dieses System erfolgreich greift, darf
der interne Mailserver keine “catch all” Adresse besitzen, bei der jede Mail
Adresse akzeptiert wird. Ebenso hinderlich sind Vorgehensweisen, bei denen
erst nach dem DATA der Client darüber informiert wird, dass der Empfänger
unzustellbar ist. Bei solchen Methoden glaubt das System das die Adresse gültig
ist.
Sender Verify Callout
Damit keine imaginären Absenderadressen angegeben werden können, sollte
auch überprüft werden, ob der Absender in der Lage ist Mails anzunehmen.
Spammer nutzen gerne Webmailer Domains mit einem zufällig gewählten
“localpart”. Ähnlich wie beim “Recipient Verify Callout” wird hier ein
SMTP callout gestartet, der dem für die Absender-Domain zuständigen Mailserver
durch Ablaufen der SMTP Prozedur (EHLO , MAIL FROM:, RCPT TO:)
einen Zustellungsversuch vorspielt.
Diese Callouts sind, durch den Verbrauch von Netzwerkresourcen, aufwendiger
als die davor beschriebenen. Aus diesem Grund ist dies auch als letzte
Hürde in der ACL definiert, so dass nicht für jede Mail, die abgelehnt wird,
ein Verify Callout gestartet werden muss. Exim sieht hierbei von Haus aus
einen Cache vor, um nicht bei einer erneuten Zustellung die gesamte Callout
Prozedur erneut durchlaufen zu müssen.
4.2.3.2 acl_check_content ACL
Die acl_content_check ACL wird nach dem vom Client gesendeten .
während des DATA ausgeführt.

40 Kapitel 4. Implementierung
Abbildung 4.3: acl_content_check Konzept.
Die in der ACL acl_rcpt_check enthaltenen Datenbankabfragen dienen
hier wieder als Basis welche der Funktionen der Nutzer in Anspruch nimmt.
Um in einem Cluster-Umfeld ein doppeltes Scannen zu vermeiden, wird zuerst
überprüft ob ein kryptographischer Header mit einer Signatur vorhanden
ist. Ein positiver Check zwingt die ACL die Mail ohne weitere Scans anzunehmen.
Defekte MIME-Container schließen auf einen unbrauchbaren Mail-Inhalt und
werden daher abgewiesen.
Da der Virenscanner weniger Resourcen verbraucht als eine Spamerkennung
mittels Textanalyse wird diese mittels der malware-Bedingung vor der Viruserkennung
ausgeführt. Hierfür kann mittels der av_scanner-Anweisung
die schon erwähnten Third-Party-Scanner genutzt werden. Der Virenscanner
kann auf Wunsch auch an einem remote Host installiert werden, um die Performance
des Mailsystems nicht zu beeinflussen. Bei einem gefundenem Virus/Wurm/Trojaner
wird die Mail abgelehnt. Hierbei ist es auch nicht notwendig,
die Datensicherheit des Unternehmens durch eine Quarantänefunktion
zu gefährden.

4.3. Antivirus 41
Als letzte Aktion wird die Mail, über das spamd Interface von SpamAssassin
2 kategorisiert. Danach stehen im exim vier Variablen zur weiteren Klassifizierung
und Bearbeitung zur Verfügung. Anhand dieser Variablen und den
userspezifischen Konfigurationen wird über eine Ablehnung oder eine Quarantäne
bei Spam-Mails entschieden.
Falls die Filterung zum späteren Zeitpunkt am internen Mailserver oder
am Mailclient geschehen soll, wird das Scoring-System von SpamAssassin
als X-Spam-Score-Header eingefügt. Damit können unter anderem auch
Outlook-Nutzer eine Filterregel anhand des Spam-Scoring vornehmen.
Da in der acl_rcpt_check schon ein großer Anteil der nicht legitimen Zustellungsversuche
abgehandelt wird, besteht nun die Möglichkeit, die Analysen
während der Mailtransaktion anzusetzen. In [JS04] wird die accept rate gegen
die delivery rate gegenüber gestellt. Dabei werden die üblichen Sandwichkonfigurationen
genauer durchleuchtet. Der Nachteil einer Sandwichkonfiguration
besteht darin, dass sie mehr Mails, empfängt als der dahinter geschaltene
Virenscanner / Spamfilter verarbeiten kann. Dies ermöglichst einen Denial-
Of-Service durch Füllen der lokalen Queue.
Bei einer Inhaltsanalyse während des DATA wird dagegen nur die Anzahl an
Mails angenommen, die bereits Kategorisiert wurden. Dafür nimmt man in
Kauf, dass in Spitzenzeiten das System stark belastet wird. Da aber der größte
Anteil schon vor der Inhaltsanalyse abgearbeitet wird, muss sich das System
einem bis zu 70% geringerem Mailaufkommen stellen.
4.3 Antivirus
Als Open-Source-Virenscanner hat sich nur das Clam AntiVirus Toolkit
[CLAMAV/SW] ergeben. Dieses wird als einziger in der Open-Source-
Gemeinde aktiv gewartet und weiterentwickelt. Ähnlich wie bei den kommerziellen
Anbietern steht hinter dem Projekt ein mehrköpfiges Team dahinter,
das versucht die Virenpattern aktuell zu halten.
Zur Installation auf einem Debian-System genügen die Installationen der Pakete
“clamav-daemon” und “clamav-freshclam”. Letzteres dient zur Aktualisierung
der Virenpatterndatenbank.
Die Auswahl von ClamAV bringt einen Vorteil mit sich: Da, im Sinne der “defense
in depth” Strategie, die Client-Systeme mit Virenscannern anderer Hersteller
ausgestattet sind, bietet ClamAV durch seine unabhängige Patterndatenbank
eine weitere Absicherung vor sich schnell verbreitenden Viren.
2 SpamAssasssin - Spam Attentäter

42 Kapitel 4. Implementierung
4.4 Antispam
Im Antispam-Bereich haben sich einige Open-Source-Projekte bereits einen
Namen gemacht. Zum einen das dspam Projekt, dass sich auf die statistische
Analyse von Spam-Mails spezialisiert hat und zum anderen das schon
erwähnte SpamAssassin (Spam Attentäter) Projekt, welches die verschiedensten
Methoden der Spambekämpfung zusammenführt.
4.4.1 DSpam
DSpam [DSPAM/SW] (wie in De-Spam) wurde hauptsächlich zum zentralen
Einsatz entwickelt. Seine Entwicklung erfolgte dabei vollständig in C und behauptet
dadurch auch einen geringeren Overhead als die in Perl implementierten
Konkurrenten zu haben. Eine nicht nur für das DSpam Projekt interessante
Entwicklung wird der dieses Jahr erscheinende Hardware-Beschleuniger
für die von DSpam verwendeten statistischen Algorithmen sein. Sensory Networks
hat sich zu einer Partnerschaft in [SD04] bereit erklärt, um die CPUintensiven
Softwarealgorithmen in ihrer Hardware abzubilden.
Trotz eines reichen Funktionsumfanges von DSPAM (wie zum Beispiel eine
vollständige User-Quarantäne, statistische Erfassung, Report-Generierung)
wurde DSpam nicht für die Umsetzung dieser Arbeit verwendet. DSPAM
nutzt ausschließlich statistische Methoden zur Erkennung von Spam und lässt
daher keinen Spielraum, das System an eine schwache Hardware anzupassen.
Wie der Schritt von Sensory Networks zeigt, scheinen diese Algorithmen bereits
zu einem Maximum in Software optimiert zu sein.
Es bleibt abzuwarten, ob die Hardwarebeschleuniger auch von weiteren
Open-Source-Produkten genutzt werden kann. In Anbetracht der Bayes Performanceanforderung
wäre dies wünschenswert.
4.4.2 SpamAssassin
SpamAssassin [SPAMASSASSIN/SW] ist mittlerweile in der Version 3.0.2 erschienen
und ist neuerdings unter der Schirmherrschaft der Apache Software
Foundation.
Historisch betrachtet stammt SpamAssassin aus der Regular-Expression-
Methode. Es fing mit einem Perl-Script an, welches die einzelnen Teile einer
Mail aufschlüsselte und entsprechende Regexp-Bedingungen für jeden Teil anwendete.
Mittlerweile ist SpamAssassin eine Sammlung verschiedenster Methoden
der Textanalyse geworden, was es vermutlich auch der “einfachen”
Perl-Implementierung zu verdanken hat.
Zur Kategorisierung von Mail bedient sich SpamAssassin einem Scoringsystem,
welches bei jedem Release neu abgestimmt wird. Diese heuristische Suche
wird durch einen Naiv Bayes Filter und verschiedene Netzwerktests unterstützt.

4.4. Antispam 43
Die einzelnen Funktionsmerkmale sind nach http://wiki.
apache.org/spamassassin/SpamAssassin (02.2005) sind:
• Header Tests
• Mailinhalt Phrasen Tests
• Bayes Filter
• Automatisches White/Blacklisting von Adressen
• Manuelles White/Blacklisting von Adressen.
• Verteilte Prüfsummen Datenbanken (DCC, Pyzor, Razor2)
• RBL (Realtime Blackhole Lists)
• DNS Blocklists (SURBL)
• Zeichensatz und “locale” Tests
Jeder dieser Tests kann dabei schnell eine Falsch-Positiv auslösen. Die Kombination
dieser Testmethoden senkt dagegen sowohl die Falsch-Positiv als auch
die Falsch-Negativ kategorisierten Mails.
Das Bewertungssystem von SpamAssassin kann hierbei userspezifisch angepasst
werden. Entgegen manch selbstgestrickten procmail Varianten
[SPAMBLOCK/SW] besitzt SpamAssassin auch Tests, die eine negative
Punktzahl besitzen. Diese Tests dienen der Erkennung von Ham, trotz diverser
Spam ähnlicher Merkmale. Aus diesem Grund kann eine Punktzahl ins
Negative gehen, die Mail gilt dann als sicherer Ham.
Das automatische Training des SpamAssassin setzt bei diesen niedrig bewerteten
Mails an, um die Bayes-Datenbank mit Ham-Mails zu trainieren. Bei einer
hohen SpamAssassin Punktzahl werden die Mails als Spam trainiert. Die
Schwellwerte sind hierbei konfigurierbar.
4.4.2.1 Integration
Die Anbindung des SpamAssassin geschieht mittels des in Abschnitt 4.2.2 beschriebenen
Interfaces von exiscan. Hierfür wird der SpamAssassin als Daemon
gestartet. Dabei nutzt SpamAssassin das preforking, um bereits durch
den Perl-Interpreter übersetzt zu werden. Da es bereits im Speicher residiert,
wird der Overhead eines erneuten interpretierens bei einkommenden
Mails vermieden. Seit der Version 3.0 besitzt SpamAssassin die Fähigkeit die
Konfiguration, White/Blacklist und Bayes-Daten über eine SQL-Datenbank
abzufragen. Beim Profiling ergab sich aber, dass die Bayes-Daten über die
SQL-Schnittstelle den Maildurchfluss um 30% reduzierten. Im Falle eines
Mailserver-Clustering sollte daher darauf geachtet werden, dass der zentrale
SQL-Server nicht mit Ressourcenmangel kämpfen muss. Zu weiteren Ergebnissen
des Profiling wird in Kapitel 6 genauer eingegangen.

44 Kapitel 4. Implementierung
Sobald SpamAssassin über den Unix-Socket 3 eine Mail erhält, arbeitet dieser
alle aktivierten Tests ab. Hierbei erhält der SpamAssassin vom exim MTA Daemon
noch die Information, für welchen User die Mail zu überprüfen ist. Durch
eine Abspeicherung der Konfiguration in MySQL kann der SpamAssassin eine
userspezifische Konfiguration laden. Wenn keine userspezifische Konfiguration
vorhanden ist, wird die Standard-Konfiguration verwendet.
4.4.2.2 Konfiguration
SpamAssassin bietet eine Fülle von Anpassungsmöglichkeiten. Seit der Version
3.0 besteht die Möglichkeit, als Datenspeicher für die einzelnen Datenbanken
(Bayes/Whitelist) und für die Konfiguration auch auf eine SQL-
Datenbank zuzugreifen. Dies bietet Mail-Administratoren die Möglichkeit,
mit einer zentralen Datenhaltung mehrere SpamAssassin im Cluster-Betrieb
einzusetzen. Wie sich beim Profiling in Kapitel ?? ergeben hat, empfiehlt es
sich bei vielen parallel eintreffenden Mails an einem SpamAssassin die Bayes-
Datenbank in SQL zu halten. Das File-Locking einer Berkley-DB4 kann zu weiteren
Verzögerungen führen, die bei einer SQL-Datenbank nicht auftreten.
Damit die Bayes-Algorithmen im SpamAssassin genutzt werden können,
muss dieser mit einer entsprechend hohen Anzahl an Mails trainiert werden.
Das derzeitige Minimum an Mails beträgt dabei jeweils 200 Mails für Spam
und Ham. Erst ab dieser Anzahl werden die Bayes-Tests im SpamAssassin
aktiviert. Um dies zu beschleunigen, ist es ratsam, die Datenbank mit bereits
empfangenem Spam/Ham Mails zu trainieren. Dieses kann mit dem in Kapitel
5.3 beschriebenem Verfahren bewerkstelligt werden.
3 Defaultmäßig TCP-Socket, doch der Unix Socket hat für eine bessere Leistung gesorgt

Kapitel 5
Erweiterungen
In diesem Kapitel wird auf die Erweiterungen eingegangen, die nicht zu einer
üblichen SpamAssassin Installation gehören. Diese Erweiterungen sollen die
Installation als Endprodukt vervollständigen.
5.1 Statistische Auswertung
Als Basis der statistischen Auswertung dient das RRD-Tool von Tobi Oetiker.
Hierfür wird im exim zu jeder Mail ein Logeintrag generiert, den ein Perl
Script für die Round-Robin Datenbank zusammenfasst. Der Vorteil dieser Datenhaltung
besteht in der Konstanz der Datenmenge.
Die flexible Möglichkeit der Datenrepräsentation lässt somit eine kundenorientierte
Grafikgenerierung zu.
Derzeitig werden folgende Daten statistisch erfasst:
• Mails Incoming – Anzahl der akzeptierten Mails.
• Greylisted Reciptient – Anzahl der greylisted Empfänger.
• Spam Mails – Anzahl der erkannten Spam Mails.
• Virus Mails – Anzahl der erkannten Viren / Trojaner.
• RBL denied – Anzahl der durch RBL blockierten Mails.
• SpamAssassin Scores – Durchschnittswert der Spam/Ham/Gesamt
Mails
• SpamAssassin time per mail – Zeit pro gescannte Mail
• Load Average – Anzahl der in der Run Queue befindlichen Prozesse.
• Speicherverbrauch – Prozentuale Auslastung des Hauptspeichers.

46 Kapitel 5. Erweiterungen
• Disk usage – Prozentuale Auslastung des Festplattenverbrauchs.
Abbildung 5.1: RRD Grafik Exim Statistk
Die exim-abhängigen Daten werden, wie in Abbildung 5.1 zur Visualisierung
des Erfolgs zu einer Grafik zusammengefasst. Damit kann der Benutzer den
prozentualen Anteil an Spam-Mails erkennen. Die Daten werden im 5 Minuten
Intervall erfasst und zur Round-Robin Datenbank hinzugefügt.
5.2 Quarantäne
Die Quarantäne wurde durch eine Kombination des Open-Source-Webmailers
SquirrelMail [SQUIRRELMAIL/SW] und einer Maildir-Mailbox gelöst.
Zur Speicherung der Mails werden die Maildir-Verzeichnisse in einer
User/Domain-Verzeichnis-Struktur aufbewahrt. Dadurch können mit den Unix
üblichen Tools (wie find, grep, awk, sed) die Statistik- und Digest-Reports
generiert werden.
Innerhalb der exim-Konfiguration liefert ein spezieller Transport Mails, die
für die Quarantäne bestimmt sind, in ein Maildir-Verzeichnis aus. Dabei wird
für jeden user@domain ein Verzeichnis angelegt, worauf der IMAP-Server zugreifen
kann. Durch dieses Maildir Verfahren können Mails anhand ihres File-
Datums aussortiert (bzw. auf Userwunsch gelöscht) werden.
Als User-Interface für die Quarantäne wurde der PHP Webmailer SquirrelMail
entsprechend verändert. Hierfür musste die User-Authentifizierung angepasst
werden und SquirrelMail um eine ’Release’-Funktion erweitert werden.
SquirrelMail benötigt einen IMAP Server zur Datenhaltung und Authentifizierung.
Das Webinterface wurde auf die nötigen Funktionen minimiert, damit

5.2. Quarantäne 47
dieses nicht als voll funktionstüchtiger Webmailer genutzt wird. Alle Funktionen
die mit dem Adressbuch oder dem Versenden von Mails zusammen
hängen, wurden aus dem Source Code entfernt, damit der Benutzer dieses
Webinterface nur für die Quarantäne benutzt. Es soll nicht der Eindruck entstehen,
dass das System als Webmailer zu gebrauchen ist.
5.2.1 User-Authentifizierung
Zur User-Authentifizierung dient die Mail-Adresse des Benutzers. Um Zugriff
auf die Quarantäne zu erhalten, muss der Benutzer seine Mailadresse angeben,
woraufhin er eine Mail zugeschickt bekommt. Diese enthält eine URL mit
einem zufälligen String der nach 30 Minuten verfällt. Diese URL wird dann
verwertet und ein entsprechender Eintrag in eine SQL-Tabelle gesetzt, der die
Mail-Adresse und den Pfad zur Quarantäne-Mailbox enthält. Dank Courier-
IMAP und dessen Möglichkeit, die User-Authentifizierung über SQL zu gestalten,
kann der Benutzer so an die Mails in seiner Quarantäne zugreifen,
ohne dass ein Benutzer Account angelegt werden muss.
5.2.2 Mail-Anzeige
Damit der Benutzer Ham-Mails in der Quarantäne leichter erkennen kann,
wurde SquirrelMail noch um die Auswertung des X-Spam-Score-Headers
erweitert. Hierbei kann der Benutzer nun auch Mails anhand des Scorings in
der Index-Ansicht sortieren und entsprechend aus der Quarantäne entlassen.
Die Mail kann aus der Quarantäne gelöscht werden und wird vorher SpamAssassin
zum trainieren der Bayes-Datenbank übergeben.
Abbildung 5.2: Userinterface Quarantäne
Innerhalb des SquirrelMail-Userinterfaces kann, dank der Plugin-Technologie,
noch eine Erweiterung zur SpamAssassin User-Konfiguration eingebunden
werden. Diese Möglichkeit wurde auch rudimentär auf der Beispielimplementation
verwirklicht.

48 Kapitel 5. Erweiterungen
5.3 Spam / Ham Training
Damit am Client Rechner keine Plugins installiert werden müssen, geschieht
das Trainieren der Bayes Datenbank komplett via Mail. Hierfür muss der Benutzer
Mails, die fälschlicherweise erkannt wurden, als Anhang an eine vorher
definierte Mail-Adresse weiterleiten.
Auf der Serverseite nimmt sich ein Perl Script der Mails an und verarbeitet alle
als MIME “Content-Type=message/rfc822” angegebenen Anhänge. Damit
können auch mehrere Mails zum Bayes Training angehängt werden. Hierbei
wird noch der ’nice’ Level angepasst, um die Priorisierung der Ressourcen für
eingehende Mails zu berücksichtigen.
Damit es zu keinem von extern manipulierbaren Training kommt, wird im
exim definiert welche Mail-Server Mails für das Training senden dürfen.
Zusätzlich wird jede Spam-Mail, die aus der Quarantäne freigegeben wird,
als Ham trainiert. Damit sollte es möglich sein, die Bayes Datenbank entsprechend
aktuell zu halten. Das verwendete Perl Script zum trainieren ist im
Anhang A.2 zu finden. Es wurde für das Konzept angepasst damit nur Mail-
Adressen, für die das System zuständig ist, akzeptiert werden.
5.4 Regel Aktualisierung
Da sich die Spammer den Regeln des SpamAssassins schnell anpassen, muss
man dafür sorgen, dass man die Regeln entsprechend häufig aktualisiert. Da
der Versionszyklus von SpamAssassin zu lange dauert, haben sich benutzerspezifische
Regeln etabliert. Hierfür besteht die Möglichkeit mit dem “Rules
de jour” (Regeln des Tages) Perl Scripts täglich eine vordefinierte Basis an
Regeln zu aktualisieren. Die meisten Regeln kommen aus dem “SpamAssassin
Rules Emporium” (SARE) [SARE/SW]. SARE wird aktiv durch freiwillige
Helfer geführt, die sich zur Aufgabe gemacht haben, den sich schnell anpassenden
Spam zu bekämpfen.
Das “RulesDuJour” Bash Script wird täglich per cron aufgerufen. Nach einer
erfolgreichen Aktualisierung wird der SpamAssassin Daemon neu gestartet.
Um eventuelle Fehler in den Regelsätzen zu erkennen, wird zuerst ein Probedurchlauf
mittels spammassassin --lint angestoßen.
Derzeitig werden folgende Regeln aktualisiert:
• ANTIDRUG erkennt Pillen/Medizin Spam.
• BOGUSVIRUS erkennt gefälschte Bounce / Non-delivery Report Virus
Mails. Entlastet ebenfalls durch das Erkennen von Antivirus-Warnungen
diverser Mail-Gateways.
• EVILNUMBERS erkennt bekannte Spammeranschriften und Telefonnummern

5.4. Regel Aktualisierung 49
• RANDOMVAL erkennt Fehler der Spam-Software. So vergessen einige
Spammer, die Platzhalter durch Daten zu ersetzen.
• SARE_ADULT erkennt nicht jugendfreien Mailinhalt.
• SARE_FRAUD dient zur Erkennung von SCAM und ähnlichen Betrugs-
Mails.
• SARE_BML BML steht für business, marketing and educational.
• SARE_SPOOF erkennt leichtsinnige Fälschungen in Spam Mails. Zum
Beispiel wenn die Message-ID einer Mail vorgibt, von einem Provider
zu sein, obwohl die Mail den Provider nie durchlaufen hat.
• SARE_BAYES_POISON_NXM erkennt den Versuch mittels zufälligen
Buchstaben Kombinationen den Bayes Algorithmus zu täuschen.
• SARE_OEM erkennt OEM-Software Anbieter.
• SARE_RANDOM dient ebenfalls wie RANDOMVAL zur Erkennung von
ungenutzten Platzhaltern.
• SARE_SPECIFIC erkennt Spam von sehr bekannten Spammer-
Organisationen.
Wie bei den RBL gilt, dass der Administrator darauf achten sollte, ob diese
Regeln weiterhin aktiv gepflegt werden. Es gibt hier noch keine Möglichkeit,
dafür zu sorgen, dass keine extrem abweichenden Scores eingebunden werden.
Ein mögliches Szenario wäre, dass ein Entwickler eine Regel einfügt. die
jegliche Mail mit 10000 Punkten bewertet und somit gefiltert wird. Um diese
mögliche Attacke abzuwehren müßte im RulesDuJour Script eine Überprüfung
hinzugefügt werden, die nur einen definierbaren Wertebereich zulässt.

Kapitel 6
Tests
Das Konzept wurde auf einem Testsystem realisiert. Als Server diente ein 2HE
Server im Rechenzentrum der noris network AG in Nürnberg. Als Hardwareausstattung
wurde absichtlich ein relativ gering dimensioniertes System zusammengestellt.
Damit sollte gewährleistet werden, dass die Testinstallation
auch für kleinere Unternehmen nutzbar ist.
Die Hardware Komponenten sind dabei im einzelnen:
CPU:
RAM:
DISK:
AMD Athlon 1333 MHz
2 * 512MB SDRAM
2 * WDC WD800JB-00FMA0/13.03G13 (80GB UDMA100 RAID1)
Das System wurde während der Tests nicht ausschließlich als Mail-Server genutzt.
Dadurch sind die Ergebnisse der einzelnen Tests nicht als Maximalwerte
anzusehen. Damit nachgewiesen wird, dass dieses System in der Lage ist, ein
größeres Mailaufkommen eines Unternehmens zu verarbeiten, wurden zwei
Lasttests durchgeführt.
6.1 Lasttest
Bei den Lasttest hat sich ergeben, dass die vorhandenen 1GB Hauptspeicher
nicht ausreichten. Das resultierende Swaping führte zu einem Flaschenhals
bei der Verarbeitung der Mails im SpamAssassin.
6.1.1 postal
Postal behauptet von sich, eine Software zum Performancetest von SMTP Servern
zu sein. Hierfür sendet es so schnell wie möglich zufällige Zeichenfolgen
als Mails zum Zielsystem und protokolliert dabei die Anzahl der akzeptierten
Mails pro Minute.
Dabei hat sich ergeben, dass der Durchsatz abhängig von den im SpamAssassin
aktivierten Methoden ist.

52 Kapitel 6. Tests
Spracherkennung / Bayes pro Min pro Tag pro Woche
An / An 59 84.960 594.720
Aus / An 66,5 95.760 670.320
Aus / Aus 100,6 144.960 1.014.720
Tabelle 6.1: Maildurchsatz gemessen mit postal
Die Daten aus der Tabelle 6.1 wurden anhand einer 30 minütigen Laufzeit
hochgerechnet. Sie zeigen, dass das Testsystem zwischen einer halben Million
und einer Million Mails pro Woche verarbeiten kann. Dies betrifft nur
Mails die über die RBL-, Greylist- und SMTP-Syntax-Hürde gekommen sind.
Bei den Langzeitmessungen hat sich gezeigt, dass diese Hürden bereits im
Durchschnitt 85% der Zustellversuche blockieren.
6.1.2 Mail submitting
Die zufällige Zeichenfolge bei postal eignet sich nur bedingt zum testen einer
Spamerkennung. Um einen praxisnahen Durchsatzwert zu erhalten, sollten
die einzelnen Mails aus einem vorher sortierten Datenbestand stammen. Die
einzelnen zufälligen Zeichenfolgen von postal sorgen sowohl beim Bayes als
auch bei der Erkennung der verwendeten Sprache für Verwirrung und haben
damit eine unnötige Verzögerung zur Folge, die bei regulären Mails nicht auftritt.
Als Testfälle wurden 3000 Mails aus jeweils einer Ham- und Spam-Sammlung
verwendet. Diese Testfälle wurden über zwei unterschiedlichen Providern, mit
jeweils zehn simultanen Verbindungen auf dem Testsystem ausgeliefert.
Abbildung 6.1: Mail Durchsatz durch Mail submitting.

6.2. Langzeittest 53
Die in Abbildung 6.1 gemessenen Werte zeigen, dass das System in der Lage
ist, bis zu 492 Mails in einem 5-Minuten-Intervall zu verarbeiten. Dies würde
einem Maildurchsatz von circa 142.000 Mails pro Tag beziehungsweise 992.000
Mails pro Woche entsprechen.
Selbst bei einer Betrachtung des Durchschnittswerts ist das System in der Lage,
276 Mails in fünf Minuten zu verarbeiten bzw eine halbe Million Mails
pro Woche zu empfangen. Wie beim Lasttest mit postal gemessen, hat es sich
gezeigt, dass das System für ein kleines bis mittelständisches Unternehmen
vollkommen ausreichend ausgestattet ist..
Bewertung:
Die Höhe des möglichen Durchsatzes hängt stark von der Art und der Größe
der Mail ab. Die Komplexität der einzelnen SpamAssassin Regeln lassen viele
mögliche Szenarien zu, die jeweils unterschiedliche Ergebnisse liefern. Bei
eingeschaltetem DNS- und RBL-basiertem Greylisting ist nicht zu erwarten,
dass die Zielgruppe eine Million Mails pro Woche verarbeiten muss. Bei der
Ausstattung sollte der Speicher nicht vernachlässigt werden. So war das Testsystem
zwar großzügig für anschliessenden Langzeittest dimensioniert, doch
könnte der Durchsatz bei einem Stresstest durch einen größeren Speicher erhöht
werden, wenn der Hauptspeicher über 1GB hinaus ausgebaut würde. Die
Gründe hierfür ist der immense Speicherverbrauch des SpamAssassins.
6.2 Langzeittest
Dank der Unterstützung von Christian Küster, war es möglich das implementierte
Konzept über einen längeren Zeitraum zu testen. Hierfür wurde eine
ehemalige Provider-Domain, die seit 1993 in Benutzung war und 1150 Domains
eines früheren Webspace Providers verwendet. Dafür zeigte der MX-
Eintrag der Domains auf das Testsystem. Da diese Domains schon seit geraumer
Zeit nicht mehr in Benutzung sind, konnten alle empfangenden Mails am
Testsystem verworfen werden. Mit der Zeit haben sich diese Domains in den
Adressbeständen der Spammer eingebrannt. Dies ist mit ein Grund dafür weswegen
auf den Domains keine Falsch-Positive zu erwarten ist.
Zum Nachweis, dass das System in der Lage ist, größere Mailaufkommen zu
verarbeiten, war das Speichern der empfangenen Mails auch nicht notwendig.
Es sollte nur der Erfolg beziehungsweise Misserfolg protokolliert werden, wie
viele Mails mit welchem Spamanteil empfangen wurden. In der Abbildung 6.2
ist in der Kalenderwoche 7 eine starke Veränderung der durch RBL Blockierten
Empfänger zu sehen. Zu diesem Zeitpunkt wurde das Testsystem umgestellt
um den Großteil der RBL-Provider zum Greylisting zu verwenden.
Durch die längere Nichtbenutzung der Domains konnte davon ausgegangen
werden, dass keine legitime Mail mehr am System ankommen wird.

54 Kapitel 6. Tests
Abbildung 6.2: Statistik des Langzeittests.
Das System hat während der drei monatigen Testphase im Durchschnitt 4656
Zustellungsversuche pro Tag verarbeitet. Die Hauptlast (insgesamt 85%) der
Zustellungsversuche wurde durch RBL und DNS/RBL-basiertes Greylisting
abgehalten.
6.3 Profiling
Um den Performanceverbrauch der einzelnen SpamAssassin-Tests besser analysieren
zu können, wurde der SpamAssassin einem sogenannten Profiling
unterzogen. Dabei wurde darauf geachtet, welche Funktionen im SpamAssassin
den größten CPU-Verbrauch haben und ob einzelne Konfigurationsmöglichkeiten
sich positiv auf die Gesamtperformance auswirken.
6.3.1 DProf
DProf ist ein Perl-Code-Profiler welcher die Ausführungszeit und die Anzahl
der Aufrufe einer Perl-Funktion misst. Um dies auszuführen, genügt es das
Perl-Script mit der Option -d:DProf aufzurufen. Nach der Ausführung legt
DProf die Datei tmon.out an. Mittels des dprofpp-Befehls wird die Datei verarbeitet.
Dabei hat sich SQL als Datenhaltung für die Bayes-Tokens als nicht sinnvoll in
der vorliegenden Konfiguration erwiesen. Im Vergleich zur Berkley DB4r- Datenhaltung
haben die zusätzlichen SQL-Aufrufe die gesamte Ausführungszeit
um 30% erhöht. Es hatte sich ebenfalls gezeigt, dass durch die Erkennung der
verwendete Sprache sehr viel CPU-Zeit beim Verarbeiten einer Mail verwendet
wird. Aufgrund der Komplexität der Sprachenerkennung besteht hier nur
die Option, diese komplett in der Konfiguration abzuschalten.

6.4. Spam / Ham Erkennung 55
Sollte ein Mailer an seine Perfomancegrenze stoßen, empfiehlt es sich daher
die Sprachenerkennung mittels ok_locales all in der Konfiguration abzuschalten.
Ebenso kann man kurzfristig auf Bayes verzichten, muss dann aber
in beiden Fällen mit einer verringerten Spam/Ham Erkennung rechnen.
6.4 Spam / Ham Erkennung
Bei dem Erfolg der Spam / Ham Erkennung sind viele Variablen zu betrachten.
So hilft eine von Hand trainierte Bayes Datenbank bei der Entscheidung
ob es sich bei der betrachteten Mail um Spam oder Ham handelt. Ebenso wird
durch das Erraten der verwendeten Sprache viele Regeln an der Kategorisierung
mit entschieden.
Wie erfolgreich das System Spam bekämpft, hängt von der Anzahl und der
Qualität der gelernten Mails und dem zu erwartendem Ham-Inhalt ab. Nicht
ohne Grund versuchen die Direktmarketing Vertreiber mittels ihrer Positivliste,
ihre als Spam erkannten Newsletter durch die Spamfilter zu schleusen.
Als Basis für diesen Test gilt eine Spam- und Ham- Mailbox die sich im Laufe
der Jahre angesammelt hat. Aus jeder Mailox wurden jeweils 2000 Mails
verwendet und über einen weiteren Rechner via SMTP eingeliefert.
Art Gesamt Falsch erkannt % Richtig erkannt %
Spam 2000 48 2.35% 1953 97.65%
Ham 2000 2 0.1% 1998 99.9%
Tabelle 6.2: Spam/Ham Erkennung
Da es keine standardisierten Testläufe zur Spam-Erkennung gibt, empfiehlt es
sich, solchen Statistiken nicht allzu viel Gewicht bei der Entscheidung zu geben.
Je nach verwendeten Mails können die Werte in beide Richtungen stark
abweichen. So wäre es kein Problem gewesen, für diesen Test eine Spam-
Mailbox zu verwenden, die nur Mails mit einem SpamAssassin Score von
mehr als 40 Punkten enthält. Diese Mails würden zu 100% als Spam erkannt
werden.
Trotzdem hat sich im Verlauf der Arbeit gezeigt, dass das Testsystem zuverlässig
Spam-Mails richtig klassifiziert und Falsch-Positive nur durch Mailinglisten,
die sich mit der Spam Thematik auseinander setzen oder durch abonnierte
Newsletter entstehen. In beiden Fällen kann SpamAssassin mittels des manuellen
Whitelistens von Adressen dazu veranlasst werden, diese Mails nicht
mehr als Spam zu kategorisieren.

Kapitel 7
Resümee
In dieser Diplomarbeit wurde ein Konzept eines Antispam/Antivirus Mailgateways
erstellt und in Form einer Testinstallation implementiert. Im konzeptionellen
Teil dieser Arbeit wurden notwendige Komponenten eines solchen
Gateways identifiziert. Diese umfassen RBL, Mail-Transfer-Agents, Antiviren-
Scanner und die Textklassifizierer. Weiterhin wurden bereits vorhandene Anwendungen
evaluiert, welche die Funktionalitäten der Komponenten abbilden.
Als ideale Kombination wurde exim als Mail Transfer Agent, SpamAssasin
als Antispam- und ClamAV als Antivirenkomponente ermittelt. Im
Zusammenspiel können diese Anwendungen nun als Antispam/Antivirus-
Mailgateway eingesetzt werden. Eine durchdachte Kombination der Komponenten
und Erkennungsmethoden stellt sicher, dass das Gateway performant
funktioniert. Durch die konsequente Verwendung von Open-Source-Software
fallen außerdem keine Lizenzkosten an.
Im Konzept wurden ebenfalls rechtliche Rahmenbedingungen berücksichtigt,
die beim Einsatz eines Antispam/Antivirus-Mailgateways zu beachten sind.
Durch den Einsatz einer userabhängige Quarantäne ist beispielsweise die Einhaltung
des Telekommunikationsgeheimnis gewahrt. Zudem kann der Benutzer
Filtermethoden für seine E-Mail Adresse aktivieren oder deaktivieren
und daher selber über den Einsatz einer Antispam-Filterung entscheiden. Die
Bayes Analyse ist durch den Einsatz von SpamAssasin ebenfalls benutzerspezifisch
realisiert, so dass jeder Benutzer seine eigene Datenbank zum Trainieren
nutzen kann.
Im praktischen Teil dieser Diplomarbeit wurde das erarbeitete Konzept in
Form einer Testinstallation implementiert. Dabei hat sich gezeigt, dass die Installation
und Konfiguration im Vergleich zu vielfältigen Individuallösungen
erheblich vereinfacht wurde. Somit kann die entwickelte Implementierung ohne
großen Aufwand in eine bestehende Infrastruktur eingebunden werden.
Die in der Konzeptphase entwickelten Performanceoptimierungen bestätigten
sich in Langzeit- und Lasttests, selbst bei der Verwendung verhältnismäßig
schwacher Hardware. Das gewählte Konzept ist auch für den hochverfügbaren
Einsatz ausgelegt und kann ebenfalls mit geringem Aufwand daran

58 Kapitel 7. Resümee
angepasst werden. Durch die Verwendung von exim kann jede einzelne Komponente
der Implementierung elegant ausgelagert oder als Cluster betrieben
werden.
Die Beispielimplementation soll zukünftig in das Produktportfolio der Thinking
Objects GmbH als “Managed Service”aufgenommen werden, um Unternehmen
ohne eigene IT-Abteilung anbieten zu können. Dabei wird die Implementierung
als Basis genutzt und kundenorientiert angepasst.
Am 31. Januar 2005 [FI05] entschied sich Firetrust ihr kommerzielles
Antispam-Projekt MailWasher unter einer Open-Source Lizenz zu stellen. Dies
könnte zur Folge haben das ihr verwendetes Webinterface als eigenständiges
Projekt in das erarbeitete Konzept integriert werden kann. Die Entwicklung
des Hardware Beschleunigers für den Bayes-Algorithmus von Sensory Networks
[SD04] sollte aus den gleichem Grund weiter verfolgt werden.

Literaturverzeichnis
[CL04] CORMACK, G.; LYNAM, T.: A Study of Supervised Spam Detection applied
to Eight Months of Personal E-Mail
http://plg.uwaterloo.ca/~gvcormac/spamcormack.html (03.2005) Cormack,
Lynam 2004
[DC82] CROCKER, D.H.: RFC822 - Standard for ARPA Internet Text Messages
The Internet Society, 1982
[EH04] HOFFMANN, E.: Power networking with Qmail&Co
http://www.fehcom.de/qmail/qmailbook.html (03.2005) fehcomm, 2004
[EH03] HARRIS, E.: The Next Step in the Spam Control War: Greylisting
http://projects.puremagic.com/greylisting/whitepaper.html (03.2005)
Evan Harris, 2003
[EJ05] JOHANSON, E.: The state of homograph attacks
http://www.shmoo.com/idn/homograph.txt (03.2005) Eric Johanson, 2005
[FH03] HERRMANN, F.: Ein Internetdienst zur Vermeidung von unerwünschter
Reklamepost
Diplomarbeit aus dem Fachbereich Informatik TU-Dresden, 2003
[GL04] LAGA, G.: E-Mail-Werbung 2004
Manz Verlag, 2004
[GE04] GENUA PRESSEINFORMATION SYSTEMS 2004: Premiere: GeNUA bietet
Firewall mit Greylisting
http://www.genua.de/news/presseinfo/presse/pi_greylisting.pdf
(03.2005) Gesellschaft für Netzwerk- und UNIX-Administration mbH, 2004
[HE04] Rassistischer Spam und der Mail-Wurm Sober.G
http://www.heise.de/newsticker/meldung/48135 (03.2005) Heise Verlag, 2004
[JK04] Ferngesteuerte Spam-Armeen, Nachgewiesen: Virenschreiber liefern Spam-
Infrastruktur
c’t 5/04, S. 18 – Heise Verlag, 2004
[IH05] ILETT, D.;HU, J.: Zombie trick expected to send spam sky-high
http://news.com.com/Zombie+trick+expected+to+send+spam+sky-high/
2100-7349_3-5560664.html (03.2005) CNET News.com, 2005

62 Literaturverzeichnis
[FH04] FESTA, P.; HANSEN, E.: Happy spamiversary
http://news.com.com/Happy+spamiversary/2100-1024_3-5189340.html
(03.2005) CNET News.com, 2004
[JK93] KLENSIN, J.: RFC1425 - SMTP Service Extensions
The Internet Society, 2001
[JK01] KLENSIN, J.: RFC2821 - Simple Mail Transfer Protocol
The Internet Society, 2001
[JK04] KOECHER, J.: Zentrale Spam- und Virenfilterung
DuD – Datenschutz und Datensicherheit Ausgabe 28, 2004
[JP82] POSTEL, J.B.: RFC821 - Simple Mail Transfer Protocol
The Internet Society, 1982
[JS04] SNYDER, J.: Review: Analyzing the spam test results
http://www.nwfusion.com/reviews/2004/122004spamcharts.html (03.2005)
Network World, Dezember 2004
[JD97] DOLL, J.: Spam Attack! - The Story of a Mail Forgery
http://www.joes.com/spammed.html (03.2005) Joy Doll, 1997
[FI05] FIRETRUST PRESS RELEASE: Firetrust Limited Launches Open Source Antispam
Project
http://firetrust.com/media/?press_id=18 (03.2005)
Firetrust, 2005
[ML05] MESSAGELABS INTELLIGENCE: Jahresbericht E-Mail-Sicherheit 2004
http://www.messagelabs.com/binaries/annual%20report%2004_german.
pdf (03.2005)
MessageLabs, 2005
[NJ04] NIERDMEIER, R.; JUNKER, M.: Rechtliche Pflichten im Bereich der IT-
Sicherheit
SurfControl, 2004
[PG02] GRAHAM, P.: A Plan for Spam
http://www.paulgraham.com/spam.html (03.2005) Paul Graham, 2002
[PR01] RESNICK, P.: RFC2045 - Multipurpose Internet Mail Extensions (MIME)
Part One
The Internet Society, 2001
[RE01] RESNICK, P.: RFC2822 - Internet Message Format
The Internet Society, 2001
[RH04] RIGOUTSOS I.; HUYNH T.: Chung-Kwei: a Pattern-discovery-based
System for the Automatic Identification of Unsolicited E-mail Messages (SPAM)
http://www.research.ibm.com/spam/papers/chung-kwei.pdf (03.2005) IBM
Research, 2004

Literaturverzeichnis 63
[DL05] LAU, D.: Forumsbeitrag zu SPAMMER RATEN VON GMX AB
http://www.heise.de/newsticker/foren/go.shtml?read=1\&msg_id=
7460955\&forum_id=74207 (03.2005) Dieter Lau, SW-Netmarketing, 2005
[RV04] VÖLKER, R.: Mit Greylisting gegen Spam vorgehen. Momen bitte
iX Ausgabe 12/2004. Heise Verlag, 2004
[SD04] DSpam project and Sensory Networks team up to deliver hardware accelerated
Antispam solution.
http://www.sensorynetworks.com/pressreleases/DSPAM_Sensory_
Networks.pdf (03.2005) iX Ausgabe 12/2004. Heise Verlag, 2004
[SG05] REGIERUNGSFRANKTION: Drucksache 15/4835 - Gesetzentwurf
der Fraktionen SPD und BÜNDNIS 90/DIE GRÜNEN
Entwurf eines Zweiten Gesetzes zur Änderung des Teledienstegesetzes (Anti-
Spam-Gesetz)
Deutscher Bundestag
[SJ03] JOSEFSSON, S.: RFC3548 - The Base16, Base32, and Base64 Data Encodings
The Internet Society, 2003
[SO04] SOPHOS PRESS RELEASE: Netsky-P führt die Jahrescharts der schlimmsten
Virenausbrüche an
http://www.sophos.de/pressoffice/pressrel/20041208yeartopten.html
(03.2005)
Sophos, 2004
[SR04] SORBS FAQ: Zombie Netblock
http://www.dnsbl.nl.sorbs.net/faq/zombie.shtml (03.2005)
Sorbs Publishing, 2004
[TB63] BAYES, T.: An Essay towards solving a Problem in the Doctrine of Chances.
Thomas Bayes, 1763
[TF05] FINCH, T.: Exim configuration at the University of Cambridge
University of Cambridge, 2005
[TH04] HARDIE, T.: MARID to close
http://article.gmane.org/gmane.ietf.mxcomp/5232 (03.2005)
Ted Hardie, 2004
[TN04] NIDECKI, T.: Wie Spam verschickt wird
Hakin9 – Ausgabe 2/2004
[TN04] TALECKI, M.; NIDECKI, T.: Serverseitige Spamabwehr
Hakin9 – Ausgabe 2/2004
[TU04] NUNNINGER, T.: E-Mail-Versand und Spamerkennung
Nunninger, 2004

64 Literaturverzeichnis
[PH04] HAZEL, P.: Specification of the exim mail transfer agent
University of Cambridge, 2004
[WS02] WEBER-STEINHAUS, U.: Eine Entwurmungskur und ihre rechtlichen Folgen:
http://www.uni-muenster.de/ZIV/inforum/2002-3/a13.html (03.2005)
[CLAMAV/SW] CLAMAV: Clam AntiVirus Toolkit
http://www.clamav.net/ (03.2005)
[DSPAM/SW] DSPAM: Nuclear Elephant: DSPAM
http://www.nuclearelephant.com/projects/dspam/ (03.2005)
[EXIM/SW] EXIM: exim Internet Mail
http://exim.org/ (03.2005)
[EXISCAN/SW] exiscan - An email content scanner patch for the exim MTA
http://duncanthrax.net/exiscan-acl/ (03.2005)
[MAILWASHER/SW] MailWasher Server Open Source Site
http://oss.firetrust.com/home/ (03.2005)
[PERL/SW] PERL: The Source for Perl
http://www.perl.com/ (02.2005)
[PHP/SW] PHP: Hypertext Preprocessor
http://www.php.net/ (02.2005)
[RRDTOOL/SW] RRD-TOOL
http://people.ee.ethz.ch/~oetiker/webtools/rrdtool/ (02.2005)
[RULESDUJOUR/SW] RULESDUJOUR
http://www.exit0.us/index.php?pagename=RulesDuJour (02.2005)
[SARE/SW] SARE: SpamAssassin Rules Emporiom
http://www.rulesemporium.com/ (02.2005)
[SPAMASSASSIN/SW] THE APACHE SPAMASSASSIN PROJECT
http://spamassassin.apache.org/ (03.2005)
[SPAMBLOCK/SW] BELWUE: SPAM-FILTER FÜR UNIX USER
http://www.belwue.de/projekte/spamblock.html (03.2005)
[SQUIRRELMAIL/SW] SQUIRRELMAIL - WEBMAIL FOR NUTS!
http://www.squirrelmail.org/ (02.2005)
[POSTAL/SW] POSTAL - SMTP AND POP BENCHMARK PROGRAM.
http://www.coker.com.au/postal/ (02.2005)

Abkürzungen
ANSI American National Standards Institute
ASCII American Standard Code for Information Interchange
ARPA Advanced Research Projects Agency
DB Database
DNS Domain Name System
DoS Denial of Service (DDoS = Distributed DoS)
DDoS Distributed Denial of Service (DDoS = Distributed DoS)
HE Höhen Einheit
HTML Hypertext Markup Language
HTTP Hypertext Transfer Protocol
IEEE Institute of Electrical and Electronics Engineers, Inc.
IETF Internet Engineering Task Force
IDN International Domain Name
IMAP Internet Messaging Access Protocol
IP Internet Protocol (v4 = Version 4, v6 = Version 6)
IRC Internet Relay Chat
IT Information Technology
MTA Mail Transfer Agent
MX Mail eXchanger
NNTP Network News Transfer Protocol
OS Operating System
RBL Realtime Block (Black) List
RFC Request For Comment
RAID Redundant Array of Independent Disks
RRD Round Robbin Database
SMTP Simple Mail Transfer Protocol
SQL Structured Query Language
SURBL Spam URI RBL
TCP Transmission Control Protocol
TXT Text
UCE Unsolicited Commercial E-Mail
UBE Unsolicited Bulk E-Mail
URL Uniform Resource Locator
URI Uniform Resource Indicator

Glossar
A
ACL
Eine Liste von Anweisungen, die über Bedingungen bestimmt, ob
Zugriffe auf eine Ressource gestattet oder verweigert wird
F
Falsch-Negativ
Fälschlicherweise als Ham erkannte Spam-Mails.
Falsch-Positiv
Fälschlicherweise als Spam erkannte Mails. Gegenstück hierzu:
Falsch-Negative
H
Ham
Gegenteil von Spam.
L
locale
definiert Parameter um eine Gebietsschemaabhängige Verarbeitung
in Computerprogrammen zu ermöglichen.
M
malware
Zusammengesetzt aus “malicious” (boshaft) und Software. Beschreibt
den böswilligen Charakter der Software

68 Glossar
P
procmail
ein autonomes Mailverarbeitungs-Programm, welches auf Unix
Systemen zur Sortierung von einkommenden Mails in verschiedene
Mailboxdateien dient.
S
Spam
Unerwünschte Massenmail
spam lauf
Zeit die ein Spammer benötigt um seine Spam Mails loszuwerden
U
URI
Uniform Resource Indicator - Standardisierte Angabe einer Ressource
wie zum Beispiel einer Website.

Anhang A
Konfiguration
A.1 exim
1 ######################################################################
2 # Runtime configuration file for Exim #
3 ######################################################################
4
5
6 ######################################################################
7 # MACRO DEFINTIONS #
8 ######################################################################
9
10 USERENTRY = ${lookup {$acl_m1} cdb*@ {/usr/local/etc/exim/pusers/pusers.cdb}}
11 #USERENTRY = ${lookup {$local_part@$domain} cdb*@ {/usr/local/etc/exim/pusers.cdb}}
12 USERCALLOUT = ${extract {callout} {USERENTRY}}
13 USERSENDERVERIFY = ${extract {senderverify} {USERENTRY}}
14 USERVIRUS = ${extract {virus} {USERENTRY}}
15 USERRBL = ${extract {rbl} {USERENTRY}}
16 USERSPAM = ${extract {spam} {USERENTRY}}
17 USERREJECT = ${extract {spamreject} {USERENTRY}}
18 USERSCORE = ${extract {spamrejectscore} {USERENTRY}}
19 USERTRAP = ${extract {trap} {USERENTRY}}
20 USERSA = ${expand:${extract {sauser} {USERENTRY}}}
21 USERBLGREY = ${extract {dialupgreylist} {USERENTRY}}
22
23
24
25 ######################################################################
26 # MAIN CONFIGURATION SETTINGS #
27 ######################################################################
28
29 # Specify your host’s canonical name here. This should normally be the fully
30 # qualified "official" name of your host. If this option is not set, the
31 # uname() function is called to obtain the name. In many cases this does
32 # the right thing and you need not set anything explicitly.
33
34 primary_hostname = netclue.de
35
36
37 # The next three settings create two lists of domains and one list of hosts.
38 # These lists are referred to later in this configuration using the syntax
39 # +local_domains, +relay_to_domains, and +relay_from_hosts, respectively. They
40 # are all colon-separated lists:
41
42 domainlist local_domains = dsearch;/usr/local/etc/exim/domains/ : @

70 Anhang A. Konfiguration
43 domainlist relay_to_domains = dsearch;/usr/local/etc/exim/relays/
44 hostlist relay_from_hosts = localhost : 213.95.27.136/29 : @
45 addresslist traps = wildlsearch;/usr/local/etc/exim/spamtraps.wild
46
47 # Most straightforward access control requirements can be obtained by
48 # appropriate settings of the above options. In more complicated situations, you
49 # may need to modify the Access Control List (ACL) which appears later in this
50 # file.
51
52 queue_list_requires_admin = false
53
54 tls_certificate = /usr/local/etc/exim/mta.cert
55 tls_privatekey = /usr/local/etc/exim/mta.key
56 tls_dhparam = /usr/local/etc/exim/dsa_param.pem
57 tls_verify_certificates = /usr/local/etc/exim/cert
58 tls_advertise_hosts = *
59 tls_try_verify_hosts = *
60
61 # The first setting specifies your local domains, for example:
62 #
63 # domainlist local_domains = my.first.domain : my.second.domain
64 #
65 # You can use "@" to mean "the name of the local host", as in the default
66 # setting above. This is the name that is specified by primary_hostname,
67 # as specified above (or defaulted). If you do not want to do any local
68 # deliveries, remove the "@" from the setting above. If you want to accept mail
69 # addressed to your host’s literal IP address, for example, mail addressed to
70 # "user@[192.168.23.44]", you can add "@[]" as an item in the local domains
71 # list. You also need to uncomment "allow_domain_literals" below. This is not
72 # recommended for today’s Internet.
73
74 # The second setting specifies domains for which your host is an incoming relay.
75 # If you are not doing any relaying, you should leave the list empty. However,
76 # if your host is an MX backup or gateway of some kind for some domains, you
77 # must set relay_to_domains to match those domains. For example:
78 #
79 # domainlist relay_to_domains = *.myco.com : my.friend.org
80 #
81 # This will allow any host to relay through your host to those domains.
82 # See the section of the manual entitled "Control of relaying" for more
83 # information.
84
85 # The third setting specifies hosts that can use your host as an outgoing relay
86 # to any other host on the Internet. Such a setting commonly refers to a
87 # complete local network as well as the localhost. For example:
88 #
89 # hostlist relay_from_hosts = 127.0.0.1 : 192.168.0.0/16
90 #
91 # The "/16" is a bit mask (CIDR notation), not a number of hosts. Note that you
92 # have to include 127.0.0.1 if you want to allow processes on your host to send
93 # SMTP mail by using the loopback address. A number of MUAs use this method of
94 # sending mail.
95
96
97 # All three of these lists may contain many different kinds of item, including
98 # wildcarded names, regular expressions, and file lookups. See the reference
99 # manual for details. The lists above are used in the access control list for
100 # incoming messages. The name of this ACL is defined here:
101
102 acl_smtp_rcpt = acl_check_rcpt
103
104 # You should not change that setting until you understand how ACLs work.
105
106 # The following ACL entry is used if you want to do content scanning with the
107 # exiscan-acl patch. When you uncomment this line, you must also review the

A.1. exim 71
108 # acl_check_content entry in the ACL section further below.
109
110 acl_smtp_data = acl_check_content
111
112 # This configuration variable defines the virus scanner that is used with
113 # the ’malware’ ACL condition of the exiscan acl-patch. If you do not use
114 # virus scanning, leave it commented. Please read doc/exiscan-acl-readme.txt
115 # for a list of supported scanners.
116
117 # av_scanner = sophie:/var/run/sophie
118 av_scanner = clamd:/var/run/clamav/clamd
119
120 # The following setting is only needed if you use the ’spam’ ACL condition
121 # of the exiscan-acl patch. It specifies on which host and port the SpamAssassin
122 # "spamd" daemon is listening. If you do not use this condition, or you use
123 # the default of "127.0.0.1 783", you can omit this option.
124
125 spamd_address = /var/run/spamd.socket
126
127
128 # Specify the domain you want to be added to all unqualified addresses
129 # here. An unqualified address is one that does not contain an "@" character
130 # followed by a domain. For example, "caesar@rome.example" is a fully qualified
131 # address, but the string "caesar" (i.e. just a login name) is an unqualified
132 # email address. Unqualified addresses are accepted only from local callers by
133 # default. See the recipient_unqualified_hosts option if you want to permit
134 # unqualified addresses from remote sources. If this option is not set, the
135 # primary_hostname value is used for qualification.
136
137 qualify_domain = netclue.de
138
139
140 # If you want unqualified recipient addresses to be qualified with a different
141 # domain to unqualified sender addresses, specify the recipient domain here.
142 # If this option is not set, the qualify_domain value is used.
143
144 # qualify_recipient =
145
146
147 # The following line must be uncommented if you want Exim to recognize
148 # addresses of the form "user@[10.11.12.13]" that is, with a "domain literal"
149 # (an IP address) instead of a named domain. The RFCs still require this form,
150 # but it makes little sense to permit mail to be sent to specific hosts by
151 # their IP address in the modern Internet. This ancient format has been used
152 # by those seeking to abuse hosts by using them for unwanted relaying. If you
153 # really do want to support domain literals, uncomment the following line, and
154 # see also the "domain_literal" router below.
155
156 # allow_domain_literals
157
158
159 # No deliveries will ever be run under the uids of these users (a colon-
160 # separated list). An attempt to do so causes a panic error to be logged, and
161 # the delivery to be deferred. This is a paranoic safety catch. Note that the
162 # default setting means you cannot deliver mail addressed to root as if it
163 # were a normal user. This isn’t usually a problem, as most sites have an alias
164 # for root that redirects such mail to a human administrator.
165
166 exim_user = mailnull
167 exim_group = mail
168 never_users = root
169 trusted_users = morrow:mailnull
170
171 # The setting below causes Exim to do a reverse DNS lookup on all incoming
172 # IP calls, in order to get the true host name. If you feel this is too

72 Anhang A. Konfiguration
173 # expensive, you can specify the networks for which a lookup is done, or
174 # remove the setting entirely.
175
176 host_lookup = *
177
178
179 # The settings below, which are actually the same as the defaults in the
180 # code, cause Exim to make RFC 1413 (ident) callbacks for all incoming SMTP
181 # calls. You can limit the hosts to which these calls are made, and/or change
182 # the timeout that is used. If you set the timeout to zero, all RFC 1413 calls
183 # are disabled. RFC 1413 calls are cheap and can provide useful information
184 # for tracing problem messages, but some hosts and firewalls have problems
185 # with them. This can result in a timeout instead of an immediate refused
186 # connection, leading to delays on starting up an SMTP session.
187
188 rfc1413_hosts = localhost
189 rfc1413_query_timeout = 5s
190 #rfc1413_query_timeout = 0
191
192
193 # By default, Exim expects all envelope addresses to be fully qualified, that
194 # is, they must contain both a local part and a domain. If you want to accept
195 # unqualified addresses (just a local part) from certain hosts, you can specify
196 # these hosts by setting one or both of
197 #
198 # sender_unqualified_hosts =
199 # recipient_unqualified_hosts =
200 #
201 # to control sender and recipient addresses, respectively. When this is done,
202 # unqualified addresses are qualified using the settings of qualify_domain
203 # and/or qualify_recipient (see above).
204
205 #
206 # logselector
207 log_selector = +incoming_interface
208
209
210 # If you want Exim to support the "percent hack" for certain domains,
211 # uncomment the following line and provide a list of domains. The "percent
212 # hack" is the feature by which mail addressed to x%y@z (where z is one of
213 # the domains listed) is locally rerouted to x@y and sent on. If z is not one
214 # of the "percent hack" domains, x%y is treated as an ordinary local part. This
215 # hack is rarely needed nowadays; you should not enable it unless you are sure
216 # that you really need it.
217 #
218 # percent_hack_domains =
219 #
220 # As well as setting this option you will also need to remove the test
221 # for local parts containing % in the ACL definition below.
222
223
224 # When Exim can neither deliver a message nor return it to sender, it "freezes"
225 # the delivery error message (aka "bounce message"). There are also other
226 # circumstances in which messages get frozen. They will stay on the queue for
227 # ever unless one of the following options is set.
228
229 # This option unfreezes frozen bounce messages after two days, tries
230 # once more to deliver them, and ignores any delivery failures.
231
232 ignore_bounce_errors_after = 2d
233
234 # This option cancels (removes) frozen messages that are older than a week.
235
236 timeout_frozen_after = 7d
237

A.1. exim 73
238 smtp_accept_max = 512
239
240 return_size_limit = 10K
241
242 message_size_limit = 50M
243 #queue_only_load = 10.0
244 smtp_load_reserve = 15.0
245 accept_8bitmime
246 split_spool_directory
247
248 ######################################################################
249 # ACL CONFIGURATION #
250 # Specifies access control lists for incoming SMTP mail #
251 ######################################################################
252
253 begin acl
254
255 # This access control list is used for every RCPT command in an incoming
256 # SMTP message. The tests are run in order until the address is either
257 # accepted or denied.
258
259 acl_check_rcpt:
260 # invoked via commandline
261 accept hosts = :
262 # Rejects mails with strange local_parts
263 deny local_parts = ^.*[@%!/|] : ^\\.
264 # Accept mail to postmaster in any domain we handle, regardless of the source,
265 # and without verifying the sender.
266 accept local_parts = postmaster
267 domains = +local_domains : +relay_to_domains : +blackholed
268
269 # Accept if the message arrived over an authenticated connection, from
270 # any host. Again, these messages are usually from MUAs, so recipient
271 # verification is omitted.
272
273 accept authenticated = *
274
275 # defer if our load goes googoo
276 defer message = try again later ...
277 condition = ${if > {$load_average} {20000}{1}{0}}
278
279 # deny well known spamtraps
280 deny recipients = +traps
281 delay = 2m
282
283 # SPF Check ASAP
284 warn message = $spf_received
285 spf = pass : fail : softfail : none : neutral : err_perm : err_temp
286 omains = +local_domains : +relay_to_domains
287
288 # Defer message if not for the same domain. (site may be broke then)
289
290
291 warn condition = ${if def:acl_m0 {1}{0} }
292 set acl_m1 = *@$domain
293 log_message = multiple RCPT TO for @$domain switching to domain\
294 based profiles
295
296 warn condition = ${if !def:acl_m0 {1}{0} }
297 domains = +local_domains : +relay_to_domains
298 set acl_m0 = $domain
299 set acl_m1 = $local_part@$domain
300
301 defer message = try this address in the next batch
302 condition = ${if and{ {def:acl_m0} {!eq {${acl_m0}}{${domain}}} } {1}{0}}

74 Anhang A. Konfiguration
303
304 # RBL Check
305
306 deny message = rejected because $sender_host_address is in a\
307 black list at $dnslist_domain\n$dnslist_text
308 condition = ${if !eq {USERRBL}{0}{1}{0}}
309 log_message = found in $dnslist_domain: $dnslist_text
310 dnslists = relays.bl.kundenserver.de:list.dsbl.org
311
312 # Deny unless the sender address can be verified.
313
314 deny message = unroutable address
315 condition = ${if !eq {USERCALLOUT}{0}{1}{0}}
316 !verify = sender/callout=90s/no_details
317
318 deny condition = ${if and{ {eq{USERCALLOUT}{0}} {eq{USERSENDERVERIFY}{1}}} {1}{0}}
319 !verify = sender
320
321 # defer if mail comes from blacklisted or unresolveable hosts.
322
323 defer message = $sender_host_address is not yet authorized to deliver mail \
324 from to . \
325 reason for greylisting: $acl_m8 \
326 Please try later.
327 log_message = greylisted ($acl_m8).
328 !senders = :
329 acl = dnsbl_or_unresolved
330 set acl_m9 = ${mask:$sender_host_address/24} $sender_address $local_part@$domain
331 set acl_m9 = ${readsocket{/var/run/greylistd/socket}{$acl_m9}{5s}{}{}}
332 condition = ${if eq {USERBLGREY}{1}{1}{0}}
333 condition = ${if eq {$acl_m9}{grey}{true}{false}}
334
335 # Accept if the address is in a local domain, but only if the recipient can
336 # be verified. Otherwise deny. The "endpass" line is the border between
337 # passing on to the next ACL statement (if tests above it fail) or denying
338 # access (if tests below it fail).
339
340 accept domains = +local_domains
341 endpass
342 message = unrouteable address
343 verify = recipient
344
345 # Accept if the address is in a domain for which we are relaying, but again,
346 # only if the recipient can be verified.
347
348 accept domains = +relay_to_domains
349 endpass
350 message = unrouteable address
351 verify = recipient/callout=90s/no_details
352
353 # If control reaches this point, the domain is neither in +local_domains
354 # nor in +relay_to_domains.
355
356 # Accept if the message comes from one of the hosts for which we are an
357 # outgoing relay. Recipient verification is omitted here, because in many
358 # cases the clients are dumb MUAs that don’t cope well with SMTP error
359 # responses. If you are actually relaying out from MTAs, you should probably
360 # add recipient verification here.
361
362 accept hosts = +relay_from_hosts
363
364 # Reaching the end of the ACL causes a "deny", but we might as well give
365 # an explicit message.
366
367 deny message = relay not permitted (check http://netclue.de/freerelay)

A.1. exim 75
368
369 # This access control list is used for content scanning with the exiscan-acl
370 # patch. You must also uncomment the entry for acl_smtp_data (scroll up),
371 # otherwise the ACL will not be used. IMPORTANT: the default entries here
372 # should be treated as EXAMPLES. You MUST read the file doc/exiscan-acl-spec.txt
373 # to fully understand what you are doing ...
374
375 acl_check_content:
376
377 # we probably checked this mail allready...
378 accept condition = ${if eq {${hmac{md5}{password}{$body_linecount}}}\
379 {$h_X-Scan-Signature:} {1}{0} }
380
381 # First unpack MIME containers and reject serious errors.
382 deny message = This message contains a MIME error ($demime_reason)
383 demime = *
384 condition = ${if >{$demime_errorlevel}{2}{1}{0}}
385
386 # Reject virus infested messages.
387 deny message = This message contains malware ($malware_name)
388 condition = ${if !eq {USERVIRUS}{0}{1}{0} }
389 demime = *
390 malware = *
391
392 # Always add X-Spam-Score and X-Spam-Report headers, using SA system-wide settings
393 # (user "nobody"), no matter if over threshold or not.
394 warn message = X-Spam-Score: $spam_score ($spam_bar)
395 condition = ${if >{$message_size}{256k}{0}{1}}
396 condition = ${if eq{USERSPAM}{0}{0}{1}}
397 spam = USERSA:true
398
399 warn message = X-Spam-Report: $spam_report
400 condition = ${if >{$message_size}{256k}{0}{1}}
401 condition = ${if eq{USERSPAM}{0}{0}{1}}
402 spam = USERSA
403
404 # Add X-Spam-Flag if spam is over system-wide threshold
405 warn message = X-Spam-Flag: YES
406 condition = ${if >{$message_size}{256k}{0}{1}}
407 condition = ${if eq{USERSPAM}{0}{0}{1}}
408 spam = USERSA
409
410
411 # add crypto sig
412 warn message = X-Scan-Signature: ${hmac{md5}{password}{$body_linecount}}
413 condition = ${if >{$message_size}{256k}{0}{1}}
414 condition = ${if or{ {!eq{USERSPAM}{0}} {!eq{USERVIRUS}{0}}}{1}{0}}
415 logwrite = :main: SA $return_path H=$sender_address S=$message_size\
416 to=$acl_m1 SPAM=$spam_score
417
418 warn message = X-Warning: This Email has not been fully scanned.
419 condition = ${if >{$message_size}{256k}{1}{0}}
420 condition = ${if or{ {eq{USERSPAM}{0}} {eq{USERVIRUS}{0}}}{1}{0}}
421
422 # Reject spam messages with score over USERSA, using an extra condition.
423 deny message = sender declines this kind of mail
424 condition = ${if >{$message_size}{256k}{1}{0}}
425 condition = ${if and{ {eq{USERSPAM}{1}} {and{ {eq{USERREJECT}{1}}\
426 {>{$spam_score_int}{USERSCORE}}}}}{1}{0}}
427 spam = USERSA
428 logwrite = :main: SA $return_path H=$sender_address S=$message_size
429 to=$acl_m1 SPAM=$spam_score
430
431
432 # finally accept all the rest

76 Anhang A. Konfiguration
433 accept
434
435 dnsbl_or_unresolved:
436 accept condition = $host_lookup_failed
437 set acl_m8 = reverse/forward lookup failure
438 accept hosts = *ppp*.*.* : *adsl*.*.* : *dyn*.*.* : *dial-in*.*.*
439 set acl_m7 = $host is probably dialup.
440 accept dnslists = dnsbl.sorbs.net
441 set acl_m8 = $dnslist_text
442 accept dnslists = combined.njabl.org
443 set acl_m8 = $dnslist_text
444 accept dnslists = blackholes.five-ten-sg.com
445 set acl_m8 = $dnslist_text
446 deny
447
448 ######################################################################
449 # ROUTERS CONFIGURATION #
450 # Specifies how addresses are handled #
451 ######################################################################
452 # THE ORDER IN WHICH THE ROUTERS ARE DEFINED IS IMPORTANT! #
453 # An address is passed to each router in turn until it is accepted. #
454 ######################################################################
455
456 begin routers
457
458 spam_trap:
459 driver = redirect
460 condition = ${if and{ {>{$spam_score_int}{100}} {!eq{USERTRAP}{0}} }{1}{0}}
461 router_home_directory = /var/mail/Trapped
462 directory_transport = address_directory
463 user = mailnull
464 data = /var/mail/Trapped/$domain/$local_part/
465
466
467 # This router routes to remote hosts over SMTP by explicit IP address,
468
469 # domain_literal:
470 # driver = ipliteral
471 # domains = ! +local_domains
472 # transport = remote_smtp
473
474 # the actual mail-relay information is in
475 # /usr/local/etc/exim/relays/. This file should look like:
476 # : [,,]
477
478 mailrelay:
479 driver=manualroute
480 domains = +relay_to_domains
481 route_data=${lookup{$domain}lsearch{/usr/local/etc/exim/relays/$domain}}
482 transport = remote_smtp
483
484
485
486 # This router routes addresses that are not in local domains by doing a DNS
487 # lookup on the domain name. Any domain that resolves to 0.0.0.0 or to a
488 # loopback interface address (127.0.0.0/8) is treated as if it had no DNS
489 # entry. Note that 0.0.0.0 is the same as 0.0.0.0/32, which is commonly treated
490 # as the local host inside the network stack. It is not 0.0.0.0/0, the default
491 # route. If the DNS lookup fails, no further routers are tried because of
492 # the no_more setting, and consequently the address is unrouteable.
493
494 dnslookup:
495 driver = dnslookup
496 domains = ! +local_domains
497 transport = remote_smtp

A.1. exim 77
498 ignore_target_hosts = 0.0.0.0 : 127.0.0.0/8
499 no_more
500
501
502 # The remaining routers handle addresses in the local domain(s).
503
504
505 # This router handles aliasing using a linearly searched alias file with the
506 # name /etc/aliases. When this configuration is installed automatically,
507 # the name gets inserted into this file from whatever is set in Exim’s
508 # build-time configuration. The default path is the traditional /etc/aliases.
509 # If you install this configuration by hand, you need to specify the correct
510 # path in the "data" setting below.
511 #
512
513 system_aliases:
514 driver = redirect
515 allow_fail
516 allow_defer
517 data = ${lookup{$local_part}lsearch{/etc/aliases}}
518 user = mailnull
519 group = mail
520 file_transport = address_file
521 pipe_transport = address_pipe
522
523 virtual_aliases:
524 driver = redirect
525 data = ${lookup {$local_part} lsearch \
526 {/usr/local/etc/exim/domains/$domain}}
527 file_transport = address_file
528 pipe_transport = address_pipe
529
530
531 # This router handles forwarding using traditional .forward files in users’
532 # home directories. If you want it also to allow mail filtering when a forward
533 # file starts with the string "# Exim filter", uncomment the "allow_filter"
534 # option.
535
536 # The no_verify setting means that this router is skipped when Exim is
537 # verifying addresses. Similarly, no_expn means that this router is skipped if
538 # Exim is processing an EXPN command.
539
540 # The check_ancestor option means that if the forward file generates an
541 # address that is an ancestor of the current one, the current one gets
542 # passed on instead. This covers the case where A is aliased to B and B
543 # has a .forward file pointing to A.
544
545 # The three transports specified at the end are those that are used when
546 # forwarding generates a direct delivery to a file, or to a pipe, or sets
547 # up an auto-reply, respectively.
548
549 userforward:
550 driver = redirect
551 check_local_user
552 file = $home/.forward
553 no_verify
554 no_expn
555 check_ancestor
556 allow_filter
557 file_transport = address_file
558 directory_transport = address_directory
559 pipe_transport = address_pipe
560 reply_transport = address_reply
561 condition = ${if exists{$home/.forward} {yes} {no} }
562

78 Anhang A. Konfiguration
563
564 # This router matches local user mailboxes.
565
566 localuser:
567 driver = accept
568 check_local_user
569 transport = local_delivery
570
571 virtual_aliases_wildcard:
572 driver = redirect
573 data = ${lookup {$local_part} lsearch* \
574 {/usr/local/etc/exim/domains/$domain}}
575
576
577 ######################################################################
578 # TRANSPORTS CONFIGURATION #
579 ######################################################################
580 # ORDER DOES NOT MATTER #
581 # Only one appropriate transport is called for each delivery. #
582 ######################################################################
583
584 # A transport is used only when referenced from a router that successfully
585 # handles an address.
586
587 begin transports
588
589 remote_smtp:
590 driver = smtp
591 connect_timeout = 5s
592 interface =
593
594
595
596 # This transport is used for local delivery to user mailboxes in traditional
597 # BSD mailbox format. By default it will be run under the uid and gid of the
598 # local user, and requires the sticky bit to be set on the /var/mail directory.
599 # Some systems use the alternative approach of running mail deliveries under a
600 # particular group instead of using the sticky bit. The commented options below
601 # show how this can be done.
602
603 local_delivery:
604 driver = appendfile
605 file = /var/mail/$local_part
606 delivery_date_add
607 envelope_to_add
608 return_path_add
609 group = mail
610 mode = 0660
611
612
613 # This transport is used for handling pipe deliveries generated by alias or
614 # .forward files. If the pipe generates any standard output, it is returned
615 # to the sender of the message as a delivery error. Set return_fail_output
616 # instead of return_output if you want this to happen only when the pipe fails
617 # to complete normally. You can set different transports for aliases and
618 # forwards if you want to - see the references to address_pipe in the routers
619 # section above.
620
621 address_pipe:
622 driver = pipe
623 return_output
624
625
626 # This transport is used for handling deliveries directly to files that are
627 # generated by aliasing or forwarding.

A.1. exim 79
628
629 address_file:
630 driver = appendfile
631 delivery_date_add
632 envelope_to_add
633 return_path_add
634
635 address_directory:
636 driver = appendfile
637 delivery_date_add
638 envelope_to_add
639 return_path_add
640 maildir_format
641 headers_add = "Lines: ${body_linecount}"
642 maildir_tag = ,S=$message_size
643
644
645 # This transport is used for handling autoreplies generated by the filtering
646 # option of the userforward router.
647
648 address_reply:
649 driver = autoreply
650
651 ######################################################################
652 # RETRY CONFIGURATION #
653 ######################################################################
654
655 begin retry
656
657 # This single retry rule applies to all domains and all errors. It specifies
658 # retries every 15 minutes for 2 hours, then increasing retry intervals,
659 # starting at 1 hour and increasing each time by a factor of 1.5, up to 16
660 # hours, then retries every 6 hours until 4 days have passed since the first
661 # failed delivery.
662
663 # Domain Error Retries
664 # ------ ----- -------
665
666 * * F,2h,15m; G,16h,1h,1.5; F,4d,6h
667
668
669
670 ######################################################################
671 # REWRITE CONFIGURATION #
672 ######################################################################
673
674 # There are no rewriting specifications in this default configuration file.
675
676 begin rewrite
677
678
679
680 ######################################################################
681 # AUTHENTICATION CONFIGURATION #
682 ######################################################################
683
684 # There are no authenticator specifications in this default configuration file.
685
686 begin authenticators
687
688
689 # End of Exim configuration file

80 Anhang A. Konfiguration
A.2 Spam/Ham training
1 #!/usr/bin/perl -w
2 # Time-stamp:
3 #
4 # sa-wrapper.pl
5 #
6 # SpamAssassin sa-learn wrapper
7 # (c) Alexandre Jousset, 2004
8 # Adrian Woizik, 2005
9 #
10 # This script is GPL’d
11 # added some file-search for domain scanning and spamassassin user..
12 #
13 # Thanks to: Chung-Kie Tung for the removal of the dir
14 # Adam Gent for bug report
15 #
16 # v1.2
17 #
18 # v1.2-ne1
19 # Removes text/plain from multipart/alternative messages
20
21 use strict;
22 use MIME::Tools;
23 use MIME::Parser;
24 use File::Find;
25
26 use constant DEBUG => 0;
27 my $UNPACK_DIR = ’/tmp/’;
28 my $SA_LEARN = ’/usr/local/bin/sa-learn’;
29 my $SPAMASSASSIN = ’/usr/local/bin/spamassassin’;
30 my @DOMAINS;
31 my @DOMAINDIRS = qw(/usr/local/etc/exim/domains /usr/local/etc/exim/relays);
32
33 find(\&domains, @DOMAINDIRS);
34 sub domains {
35 push @DOMAINS,$_ unless (/^\./);
36 }
37
38
39 my ($spamham, $sender, $SAUSER) = @ARGV;
40 my $parser = new MIME::Parser;
41 $parser->extract_nested_messages(1);
42 $parser->output_under($UNPACK_DIR);
43
44 sub recurs
45 {
46 my $ent = shift;
47
48 if ($ent->head->mime_type eq ’message/rfc822’) {
49 # Report an Razor & Co
50 if (DEBUG) {
51 unlink "/tmp/spam.log.$$" if -e "/tmp/spam.log.$$";
52 open(OUT, "|$SPAMASSASSIN -D ".($spamham eq ’spam’ ? ’-r’ : ’-k’).\
53 ">>/tmp/spam.log.$$ 2>&1") or die "Cannot pipe $SPAMASSASSIN: $!";
54 } else {
55 open(OUT, "|$SPAMASSASSIN ".($spamham eq ’spam’ ? ’-r’ : ’-k’)) or\
56 die "Cannot pipe $SPAMASSASSIN: $!";
57 };
58 $ent->print_body(\*OUT);
59 close(OUT);
60
61 # Bayes füttern
62 # Decoding embedded message
63 $ent = $ent->parts(0);

A.2. Spam/Ham training 81
64 return unless $ent; # Not a valid message/rfc822
65
66 if ($ent->head->mime_type eq ’multipart/alternative’) {
67 # Lösche text/plain
68 $ent->parts([ grep { $_->head->mime_type ne ’text/plain’ } $ent->parts ]);
69 };
70 if (DEBUG) {
71 open(OUT, "|$SA_LEARN -D --$spamham --single --no-sync -u $SAUSER \
72 >>/tmp/spam.log.$$ 2>&1") or die "Cannot pipe $SA_LEARN: $!";
73 } else {
74 open(OUT, "|$SA_LEARN --$spamham --single --no-sync -u $SAUSER") \
75 or die "Cannot pipe $SA_LEARN: $!";
76 };
77 $ent->print(\*OUT);
78 close(OUT);
79 return;
80 }
81
82 my @parts = $ent->parts;
83
84 if (@parts) {
85 map { recurs($_) } @parts;
86 }
87 }
88
89 my ($domain) = $sender =~ /\@(.*)$/;
90 unless (grep { $_ eq $domain } @DOMAINS) {
91 die "I don’t recognize your domain !";
92 }
93
94 if (DEBUG) {
95 MIME::Tools->debugging(1);
96 open(STDERR, ">/tmp/spam_err.log");
97 }
98
99 my $entity;
100 eval {
101 $entity = $parser->parse(\*STDIN);
102 };
103
104 if ($@) {
105 die $@;
106 } else {
107 recurs($entity);
108 }
109
110 $parser->filer->purge;
111 rmdir $parser->output_dir;