Werbeemail beziehungsweise so genannte Spam E-Mail stellen ein immer größer werdendes Problem in unserer Kommunikationskultur dar. Diese Arbeit beschreibt softwaretechnische Verfahren und deren Funktion zur Vermeidung von Spam E-Mails. Diese Verfahren werden auf Stärken und Schwächen hin analysiert und ihre Funktionsweise anhand unterschiedlicher Kriterien, wie zum Beispiel Erkennungsrate, Funktionsprinzip und Userinteraktion, bewertet. Nach dieser Analyse werden die besten ausgewählten aufgelistet und kombiniert. Die Kombination u. a. von Greylisting, Sender Policy Framework, Bayesscher Filter und einige mehr ergeben ein neues, leistungsfähigeres System zur Filterung von unerwünschten E-Mails. Zur Demonstration der Leistungsfähigkeit wurde das System mit dem objektorientierten Regelsystem und einem Webinterface zur Konfiguration in einem Mailgateway implementiert. Das Mailgateway kann einfach installiert, leicht in die vorhandene IT Infrastruktur integriert und konfiguriert werden. Das Ergebnis ist eine auf unterschiedlichen Verfahren basierende Lösung gegen Spam E-Mail.
Inhaltsverzeichnis
1. Einleitung
1.1 Motivation
1.2 Maurer IT Systemlösungen KEG
1.3 Zieldefinition
2. Theoretische Grundlagen
2.1 elektronische Mail
2.1.1 E-Mail Komponenten
2.1.2 Simple Mail Transport Protocol (SMTP)
2.1.3 E-Mail Routing
2.1.4 Multipurpose Internet Mail Extenstions
2.2 Spam E-Mail
2.3 Rechtliche Rahmenbedingungen
2.3.1 Die österreichische Gesetzeslage
2.3.2 Die europäische Gesetzeslage
2.3.3 Die amerikanische Gesetzeslage
2.3.4 Auswirkungen der Gesetze auf Spammer
2.4 Spam Techniken
2.4.1 E-Mail Adressen
2.4.2 Spam Versand
2.5 Passive Techniken gegen SPAM
2.5.1 Auto-Whitelist
2.5.2 Bayesscher Filter
2.5.3 Blacklist
2.5.4 Channels
2.5.5 Challenge/Response (CR) Methode
2.5.6 Distributed Checksum Clearinghouse (DCC)
2.5.7 Greylisting (Greenlist)
2.5.8 Greylisting nach Rhyolite
2.5.9 Hashcash
2.5.10 Header Test
2.5.11 Inhaltsfilter
2.5.12 Pyzor
2.5.13 Razor
2.5.14 Regelbasierende Filter
2.5.15 Sender Policy Framework (SPF)
2.5.16 Spamtraps
2.5.17 URL Erkennung
2.5.18 Wegwerf-Adressen
2.5.19 Whitelist
2.6 Aktive techniken gegen SPAM
2.6.1 Denial of Service (DoS)
2.6.2 Teergrube
3. Praktische Ausführung
3.1 SPAM in der PRAXIS
3.1.1 Kosten von Spam
3.1.2 Folgen von Spam
3.1.3 Spamkategorien
3.2 Ziel
3.2.1 Anforderungen / Zieldefinition
3.2.2 Vorgehensmodell
3.3 Kategorisieren der Filtertechniken
3.3.1 Authentifizierende Methoden
3.3.2 Analytische Methoden
3.3.3 Lokale und Online Methoden
3.3.4 Verteilung der Methoden über die Kategorien
3.4 Analyse der verschiedenen Filtertechniken
3.4.1 Stärken/Schwächen Analyse
3.4.2 Bewertungskriterien
3.4.3 Bewertung
3.4.4 Analyse der Kombinationsmöglichkeiten
3.5 Spamfiltereinsatz in der IT Infrastruktur
3.5.1 Client
3.5.2 Server
3.5.3 Zentraler Mailgateway (Proxy)
3.5.4 Variantenvergleich
3.5.5 Kombination von Varianten
3.6 Software Design & IMplementierung
3.6.1 Mailgateway Architektur
3.6.2 Filterstruktur
3.6.3 Regelsystem
3.6.4 Installer
3.6.5 Webinterface
3.6.6 Implementierung
3.6.7 Mailgateway Prototyp
4. Wirtschaftliche Betrachtung
4.1 Kosten für Spammer
4.2 Kosten für Unternehmen
5. Diskussion
5.1 Reflexion der gewonnenen Erkenntnisse
5.2 Entwicklungen gegen SPAM
5.2.1 E-Mail Netzwerkanalyse
5.2.2 Der Mensch als Filter
5.3 Verbesserungen des Mailgateways
5.3.1 Greylisting
5.3.2 Mail Tracking Center
6. Literatur
7. Abbildungsverzeichnis
8. Tabellenverzeichnis
1. Einleitung
Das Internet hat in den letzten Jahren die weltweite Kommunikation in einer drastischen Art und Weise verändert. Die Veränderung hat auch vor unserer Gesellschaft nicht halt gemacht und ist dabei soweit gegangen sich als Informationsgesellschaft zu bezeichnen.
Die elektronische Post (E-Mail) ist dabei eine der erfolgreichsten Internet Anwendungen und für viele Menschen ein tägliches Kommunikationsmittel. Im Jahr 2005 wird die Anzahl der versendeten E-Mails auf ca. 36 Milliarden pro Tag steigen. [CNN, 2004]
Im April 1994 hat der amerikanischer Rechtsanwalt Laurence Canter erstmals automatisiert tausende E-Mails verschickt, um seine Kanzlei zu bewerben. Dies brachte dem Rechtsanwalt einen kolportierten Mehrumsatz von 200.000 USD und einige wütende Protestmails der User. [Laga et al., 2004, S. 6]
Die ersten SPAM Mails wurden verschickt. Spam bezeichnet, kurz gesagt, unerbetene E-Mails, häufig in Form von Massenpost. Meist wird Spam für Zwecke der Direktwerbung verwendet. Die Tragweite von Spam ist enorm und zeigt eine beunruhigende Wachstumsrate. Im Jahr 2001 wurde das Spam Aufkommen auf 7% des gesamten E-Mail-Verkehrs, 2002 auf 29%, 2003 auf 51% und 2004 auf rund 70% geschätzt. [Kommission d. europ. Gem., 2004]
1.1 Motivation
Die unzähligen Spam E-Mails in meinem Posteingang haben mich zu einer intensiven Auseinandersetzung mit der Materie bewegt. Zusätzlich wurde ein Entwicklungsprojekt innerhalb der Maurer IT gestartet. Das persönliche Interesse am Thema Spam E-Mails und die Entwicklungstätigkeit an einem zentralen Mailgateway motivierten zu dieser Diplomarbeit.
1.2 Maurer IT Systemlösungen KEG
Die Maurer IT Systemlösungen KEG ist ein 1999 von Martin Maurer und DI Dietmar Maurer gegründetes Wiener Unternehmen. Die Ziele des IT Unternehmens liegen in der Schaffung zuverlässiger Lösungen für IT Netzwerke und Entwicklung innovativer Software. Die Maurer IT setzt sowohl auf Microsoft als auch auf OpenSource Software (z.B.: Linux) und bietet Maßlösungen für heterogene Netzwerke an.
Das aktuelle Entwicklungsprojekt der Maurer IT Systemlösungen KEG ist ein Mailgateway mit integriertem Spamfilter, basierend auf vielen unterschiedlichen Filtertechnologien, einen Virenscanner und einer einfachen Integration in die vorhandene IT Infrastruktur. Die vorliegende Diplomarbeit ist eng mit diesem Projekt zur gegenseitigen Unterstützung verbunden.
1.3 Zieldefinition
Das Ziel dieser Diplomarbeit ist es die Vor- und Nachteile der unterschiedlichen Filtertechniken zur Bekämpfung von Spam zu beschreiben und einen Weg zu zeigen, wie diese intelligent in eine Mailgateway integriert werden können. Eine kritische Analyse der Schwächen und Stärken der Lösung soll als Basis für eine zukünftige Weiterentwicklung dienen.
2. Theoretische Grundlagen
2.1 elektronische Mail
Die elektronische Mail (E-Mail) oder auch Internet-E-Mail basiert auf verschiedenen Standards und Protokollen, die definieren, woraus Nachrichten bestehen und wie sie vom Sender zum Empfänger gelangen. An diesem Prozess sind mehrere Softwarekomponenten beteiligt, von denen jeder einen bestimmten Aufgabenteil des gesamten Prozesses übernimmt. Die meisten E-Mail Nutzer sind lediglich mit ihrer Software zum Empfangen und Lesen von Nachrichten vertraut. Diese Software wie z.B. Microsoft Outlook oder Mozilla Thunderbird ist auch als Mail User Agent (MUA) bekannt. MUAs sind für das Lesen und Schreiben von E-Mail geeignet, nicht jedoch für die Auslieferung dieser. [Dent, 2004, S.3]
2.1.1 E-Mail Komponenten
Wenn der MUA nun angewiesen wird eine Nachricht zu senden, dann übergibt er die Nachricht einfach an einen Server, der einen Mail Transfer Agent (MTA) ausführt.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2.1: Einfacher Nachrichtenfluss im Internet
Abbildung 2.1 zeigt die für eine einfache Nachrichtenübertragung notwenigen Komponenten zwischen Sender und Empfänger. MTAs (wie zum Beispiel Postfix) übernehmen die Arbeit welche notwenig ist eine Nachricht von einem System an ein anderes auszuliefern. Erhält der MTA einen Request, d.h. eine E-Mail soll empfangen werden, dann prüft er zuerst ob er die Nachricht annehmen soll oder nicht. Ein MTA akzeptiert im Allgemeinen nur Nachrichten, welche für
-
- die eigenen lokalen Benutzer sind.
- andere Systeme, wenn er weiß wie die Nachricht weiterzuleiten ist.
- andere Benutzern, Systemen oder Netzwerke, wenn deren Weitervermittlung (Relaying) an andere Ziele erlaubt ist.
Sobald ein MTA eine Nachricht akzeptiert, muss dieser entscheiden, was als nächstes geschehen soll. Er kann die Nachricht an einen Benutzer seines Systems ausliefern oder an einen weiteren MTA übergeben. Nachrichten für andere Netzwerke können in der Praxis viele verschiedene MTAs durchlaufen. Tritt der Fall ein dass ein MTA die Nachricht nicht ausliefern oder weiterleiten kann, sendet er diese an den ursprüngliche Absender zurück und benachrichtigt einen lokalen Systemadministrator über den Fehler. MTA Server werden für einzelne Personen in der Regel von Internet Service Providern (ISP) betrieben, wobei ein MTA Server für mehrere Benutzer verantwortlich ist.
Nach einer Kette von MTAs erreicht die Nachricht den MTA, der das eigentliche Ziel ist. In Abbildung 2.1 wurden zwecks der Vereinfachung nur zwei MTAs dargestellt. Der Ziel MTA übergibt die Nachricht an einen Message Delivery Agent (MDA). Der MDA speichert die Nachricht persistent im Nachrichtenspeicher. Dies kann durch Speicherung in eine Datei oder in eine spezialisierte Datenbank erfolgen.
Die Nachricht wird so lange im Nachrichtenspeicher abgelegt bis sie der Empfänger abholt. Dafür steht dem Empfänger der MUA zur Verfügung. Der MUA kontaktiert den Server, welcher Zugriff auf den Nachrichtenspeicher ermöglicht.
Weil die Internet-E-Mail Standards offen sind, stehen viele unterschiedliche Softwarepakete und Protokolle zu Verfügung. Die Kommunikation zwischen MTAs und MUA zu MTA findet in der Praxis meistens über das Simple Mail Transfer Protocoll (SMTP) statt. Es können jedoch auch andere Protokolle wie zum Beispiel Extended Simple Mail Transfer Protocoll (ESMTP) zum Einsatz kommen. Protokolle für die Kommunikation zwischen MUA und einem Server, welcher Zugriff auf den Nachrichtenspeicher besitz, sind zum Beispiel Post Office Protocol (POP) oder Internet Message Access Protocol (IMAP). [Dent, 2004, S. 3-4]
2.1.2 Simple Mail Transport Protocol (SMTP)
Das SMTP wurde im Request for Comments (RFC) 2821 und im Mil-Standard (MIL-STD-1781) definiert. Der wesentliche Unterschied zwischen diesen beiden Standards liegt mehr in der Art und Weise der Dokumentation, als in deren Inhalten. SMTP setzt direkt auf TCP auf und die meisten SMTP Implementierung benutzen den Well-known-Port 25.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2.2: SMTP im TCP/IP - Protokollstack
Nachrichten die mit SMTP verschickt werden, werden im Allgemeinen nach RFC 822 definiert. SMTP beachtet den Inhalt der Nachrichten nicht, wobei die Nachricht nur aus 7-Bit ASCII Zeichen bestehen darf. Ein zweite Eigenheit von SMTP besteht darin, dass der Weg, welcher eine Nachricht nimmt nicht protokolliert werden muss. Der MTA kann eine Protokollierung mittels hinzufügen von Headerinformationen durchführen. Diese zwei Besonderheiten sind wichtig für kommende Überlegungen bezüglich Spam E-Mails.
2.1.2.1 Versenden einer Nachricht mittels SMTP – Kommandos
Die Telnet Applikation kann dazu verwendet werden sich mit einem Mailserver zu verbinden. Mailserver verwenden in der Regel Port 25.
Abbildung in dieser Leseprobe nicht enthalten
Nach jeder Kommando Eingabe meldet sich der Mailserver mit einem Reply und einem dazugehörigem Reply-Code. (Reply-Codes die mit 2 beginnen zeigen eine Positive-Abschluss-Bestätigung an.)
Abbildung in dieser Leseprobe nicht enthalten
Tabelle 2.1: SMTP Reply Kodierung
Bevor eine Nachricht gesendet werden kann, muss sich der Client zuerst beim Mailserver mit dem Befehl HELO anmelden. Weiters übergibt man den Absender (MAIL FROM) und die Empfänger (RCPT TO). Nach Eingabe von DATA kann nun die eigentliche Nachricht erstellt werden. Mit einem Zeilenumbruch gefolgt von einem Punkt (.) und einem weiteren Zeilenumbruch wird die Dateneingabe beendet. Die Verbindung kann danach mit QUIT beendet werden. [Hein, 2004]
2.1.2.2 Das SMTP-822-Format
Das 822-Format ist strukturell einfach gestaltet und besteht aus einigen Zeilen Header Informationen und dem eigentlichen Text. Dieser Text wird auch als Message Body bezeichnet. Eine Leerzeile trennt die Header Informationen und den Message Body. Eine Zeile im Header besteht allgemein aus einem Schlüsselwort gefolgt von einem Doppelpunkt und einem Wert. Das Protokoll definiert keine bestimmte Reihenfolge der Schlüsselwörter, empfiehlt für folgende Schlüsselwörter jedoch diese: From, To, Subject, Date. Diese Header Informationen definieren den Absender und den Empfänger, die Überschrift und das Erstellungsdatum der Nachricht. Der Message Body besteht aus reinem Text (in 7-Bit-ASCII) und kann beliebig lang sein. [Hein, 2004]
Beispiel einer E-Mail im RFC 822 Format:
Abbildung in dieser Leseprobe nicht enthalten
2.1.3 E-Mail Routing
Eine erfolgreiche Zustellung oder Weiterleitung einer E-Mail erfordert es, dass MTAs mittels Domain Name Server (DNS) die Zieladresse in eine IP - Adresse wandeln können.
2.1.3.1 DNS
Der DNS – Dienst wurde 1983 in RFC 882 definiert. Die Benennung der Hosts erfolgt hierarchisch damit Konflikte vermieden werden. Jedes Netzwerk oder Rechnergruppe erhält mindestens einen Domainnamen, und alle dazugehörigen Hosts werden so benannt, dass deren Name vor den Domainnamen gestellt wird. Zum Beispiel: host1.example.com, host2.example.com, www.example.com, usw. Jede Domain besitzt mindestens zwei Domain Nameserver, die für diese Domain als authorative betrachtet werden. Diese authoritativen Nameserver müssen Zugriff auf die Datenbank haben, die alle Informationen über diese Domain speichert. [Dent, 2004, S.73f]
Die Daten bestehen aus unterschiedlichen Arten von Datensätzen, die als Ressource Records bekannt sind. Folgende wichtige Ressource Records werden gespeichert: [Dent, 2004, S.74]
Abbildung in dieser Leseprobe nicht enthalten
Tabelle 2.2: DNS - Ressource Records
2.1.4 Multipurpose Internet Mail Extenstions
Die Multipurpose Internet Mail Extension (MIME) ist eine Erweiterung von RFC-822. Diese Erweiterung wird benötigt, um auch binäre Daten, wie zum Beispiel Bilder, Audio und Video versenden zu können. Ein MIME kompatibler MUA kann binären Inhalt an die E-Mail Nachricht anhängen und an einen MIME kompatiblen MTA für die Zustellung weitergeben. Ein empfangender MUA kann die E-Mail dekodieren und die angehängten Dateien entweder anzeigen oder lokal speichern. Die eingefügten Dateien werden im englischen Attachments genannt. Dieser Begriff ist auch im deutschen Sprachraum in Verwendung.
MIME Nachrichten bestehen aus einer normalen Internet Text Mail Nachricht mit einigen spezialen Headers (RFC-822) und formatierten Message Body. Der Message Body wird in Sektionen eingeteilt, wobei jede ASCII kodierte Daten enthalten kann. Jede Sektion wird mit einleitenden Informationen über die folgenden Daten begonnen. [WOOD, 1999, S38ff]
2.1.4.1 MIME Headers
Es gibt zwei unterschiedliche MIME Headers:
- MIME Message Header – Teil des RFC-822 Headers
- MIME Part Header – Einleitende Information vor jeder Sektion
Die Message Header sind:
- MIME-Version
- Content-Type
- Content-Transfer-Encoding
- Content-ID
- Content-Description
Der MIME Part Header kann bis auf MIME-Version beliebige MIME Message Header Felder beinhalten. Alle MIME Part Header müssen mit „Content“ beginnen.
Damit kein Konflikt zwischen Benutzerdefinierten Header und MIME Header entsteht müssen alle MIME Header mit „Content“ und alle Benutzerdefinierten Header mit „X“ beginnen.
MIME Beispiel:
Abbildung in dieser Leseprobe nicht enthalten
Der Content-Type Header definiert, um welchen Inhalt es sich bei dieser E-Mail handelt (z.B.: multipart/mixed) und setzt die MIME Boundary Markierung.
2.1.4.2 MIME Boundary
Eine E-Mail mit mehreren Daten verwendet die MIME Boundary als Grenzline, um die Daten (Bodyparts) trennen zu können. Die MIME Boundary wird im Content-Type Header definiert und kann einen beliebigen 7-Bit-ASCII Text beinhalten. Dieser Text sollte jedoch eindeutig sein.
2.1.4.3 Multipart Message
Beispiel für eine einfache Multipart-Message (mit einem verkürzten boundary):
Abbildung in dieser Leseprobe nicht enthalten
Der empfangende MTA zeigt den Text aus dem ersten Bodypart an und bietet dem User, abhängig von der verwendeten Software, den Download des mitgelieferten Bildes an.
2.2 Spam E-Mail
SPAM ist in vielen Teilen der Welt, aber vor allem in den USA, als Marke für Dosenfleisch bekannt. Das Produkt wird von der Firma Hormel Foods Inc. seit 1937 produziert und vertrieben.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2 . 3 : Eine Dose SPAM [WIKIPEDIA; Spam]
Ausgelöst durch einen Sketch der englischen Comedyserie Monty Python's Flying Circus wird die Bezeichnung Spam für unerwünschte Massenpostings im Usenet verwendet. Im modernen Sprachgebrauch wird Spam auch für Unsolicited Commercial Email (unverlangte Werbe-E-Mail) verwendet. Der Begriff Spam hat sich mittlerweile bereits für alle unverlangten E-Mails etabliert. SPAM in Großbuchstaben geschrieben, ist ein Markenname der Firma Hormel Foods Inc. Aufgrund der Spam E-Mail Problematik wird der Begriff Spam im Allgemeinen zuerst mit E-Mails in Verbindung gebracht.
2.3 Rechtliche Rahmenbedingungen
Spam E-Mails verursachen erhebliche Kosten für Unternehmen, wie auch für die Gesellschaft. Die Gesetzgebung hat auf unterschiedliche Art und Weise auf diese Bedrohung reagiert.
2.3.1 Die österreichische Gesetzeslage
E-Mail, sowie Spam E-Mail entspricht der Definition für elektronische Post, welche in §92 Abs 3 Z 10 des Telekommunikationsgesetztes (TKG) definiert:
„Eine elektronische Post“ ist jede über ein öffentliches Kommunikationsnetz verschickte Text- Sprach-, Ton- oder Bildnachricht, die im Netz oder im Endgerät des Empfängers gespeichert werden kann, bis sie von diesem abgerufen wird.“ – TKG §92 Abs 3 Z 10
Den eigentlichen Umgang mit E-Mail Werbung regelt § 107 TKG, der sich mit unerbetenen Nachrichten beschäftigt.
„§107. (1) Anrufe – einschließlich das Senden von Fernkopien – zu Werbezwecken ohne vorherige Einwilligung des Teilnehmers sind unzulässig. Der Einwilligung des Teilnehmers steht die Einwilligung einer Person die vom Teilnehmer zur Benützung seines Anschlusses ermächtigt wurde gleich. Die erteilte Einwilligung kann jederzeit widerrufen werden; der Widerruf der Einwilligung hat auf ein Vertragsverhältnis mit dem Adressaten der Einwilligung keinen Einfluss.
(2) Die Zusendung einer elektronischen Post – einschließlich SMS – an Verbraucher im Sinne des §1 Abs. 1 Z 2 Konsumentenschutzgesetz ohne vorherige Einwilligung des Empfängers ist unzulässig wenn 1. die Zusendung zu Zwecken der Direktwerbung erfolgt oder 2. an mehr als 50 Empfänger gerichtet ist.
(3) Eine vorherige Zustimmung für elektronische Post gemäß Abs. 2 ist dann nicht notwenig, wenn 1. der Absender die Kontaktinformation für die Nachricht im Zusammenhang mit dem Verkauf oder einer Dienstleistung an seine Kunden erhalten hat und 2. diese Nachricht zur Direktwerbung für eigene ähnliche Produkte oder Dienstleistungen erfolgt und 3. der Kunde klar und deutlich die Möglichkeit erhalten hat, eine solche Nutzung der elektronische Kontaktinformation von vornherein bei deren Erhebung und zusätzlich bei jeder Übertragung kostenfrei und problemlos abzulehnen.
(4) Die Zusendung einer elektronischen Post – einschließlich SMS – an andere als die in Abs. 2 genannten Empfänger ist ohne vorherige Einwilligung des Empfängers unzulässig, wenn der Versender dem Empfänger in der elektronischen Post oder in der SMS ausdrücklich die Möglichkeit einräumt, den Empfang weiterer Nachrichten abzulehnen.
(5) Die Zusendung elektronsicher Nachrichten zu Zwecken der Direktwerbung ist auch bei Vorliegen der Voraussetzungen der Abs. 2, 3 und 4 unzulässig, wenn die Identität des Absenders, in dessen Auftrag die Nachricht übermittelt wird, verschleiert oder verheimlicht wird oder bei der keine authentische Adresse vorhanden ist, an die der Empfänger eine Aufforderung zur Einstellung solcher Nachrichten richten kann.
(6) Wurden Verwaltungsübertretungen nach Abs. 1 nicht im Inland begangen, gelten sie als an jenem Ort begangen, an dem der Anruf den Anschluss des Teilnehmers erreicht. „ - TKG - §107 Abs. 1-6
Wesentlich für die Spam E-Mails ist Absatz 2, der es grundsätzlich verbietet Direktwerbung an Verbraucher zu senden ohne dass diese vorher zugestimmt hätten. Dieses Verbot gilt aber nur für Spam E-Mails an Verbraucher. Werbe E-Mails an Personen eines Unternehmens müssen auf eine Opt-Out Möglichkeit hinweisen (Absatz 3).
Für jede Werbe-E-Mail gilt, dass sie die Identität des Absenders enthalten muss, in dessen Auftrag die Nachricht übermittelt wird.
2.3.1.1 E-Commerce Gesetz (Robinsonliste)
Würden sich alle Versender von E-Mail-Werbung an die Gesetze halten wäre die Opt-Out Möglichkeit sinnvoll. Gibt man dem Versender von E-Mail Werbung aber bekannt, dass man an diese E-Mail Adresse keine Werbung geschickt bekommen möchte, so weiß der Absender, dass diese E-Mail Adresse sicher genutzt wird und kann diese Information ausnützen, wie z.B. die Daten an andere Spammer weiterverkaufen (Siehe auch Kapitel „Wie arbeiten Spammer“ für mehr Informationen).
Aus diesem Grund wurde von der EU-Kommision im Jahr 2004 auf europäischer Ebene in der E-Commerce-Richtlinie (2000/31/EG) vorgeschlagen, nationale aber zentrale elektronische Opt-Out Listen einzuführen, in die sich jene Personen eintragen können, die generell keine E-Mail Werbung erhalten möchten. Dies wird in §7 des E-Commerce Gesetzes beschrieben:
„§7. (1) Ein Dienstanbieter, der eine kommerzielle Kommunikation zulässigerweise ohne vorherige Zustimmung des Empfängers mittels elektronischer Post versendet, hat dafür zu sorgen, dass die kommerzielle Kommunikation bei ihrem Eingang beim Nutzer klar und eindeutig als solche erkennbar ist.
(2) Die Rundfunk und Telekom regulierungs-GmbH (RTR-GmbH) hat eine Liste zu führen, in die sich diejenige Personen und Unternehmen kostenlos eintragen können, die für sich die Zusendung kommerzieller Kommunikation im Weg der elektronischen Post ausgeschlossen haben. Die in Abs. 1 genannten Diensteanbieter haben diese Liste zu beachten.“ - §7 Abs. 1-2 des E-Commerce Gesetzes.
Diese von der RTR-GmbH geführte Liste wird auch Robinsonliste genannt.
2.3.2 Die europäische Gesetzeslage
Die europäischen Richtlinien bezüglich Werbe E-Mails oder kommerzieller Kommunikation wird in der ISDN Datenschutzrichtlinie 97/66/EG beschrieben. Zusammengefasst ist Werbung via E-Mail grundsätzlich nur unter Angabe des Identität des Absenders und nach vorheriger Zustimmung des Empfängers erlaubt. Die Zustimmung kann gemäß Abs. 2 ISDN Datenschutzrichtlinie 97/66/EG angenommen werden, wenn ein vorheriger Kunde dem potentiellen Versender seine E-Mail Adresse gegeben hat. Allerdings muss ein kostenfreies Ablehnen von weiteren Zusendungen möglich sein.
2.3.3 Die amerikanische Gesetzeslage
In den USA gilt seit dem 1. Jänner 2004 der „Controlling the Assault of Non-Solicited Pornography and Marketing Act of 2003“ (CAN-SPAM-Act). Dieses amerikanische Gesetz sieht vor, dass der Sender von E-Mails keine irreführenden Kontakt- oder Betreff (Subject) Informationen angibt, Werbe E-Mails klar als solche gekennzeichnet sein müssen, eine physische Adresse des Absenders angegeben und dem Empfänger eine Opt-Out Möglichkeit angeboten werden muss.
Im Vergleich zu den Europäischen Verwaltungsbehörden versuchen die US-Behörden eine strenge Vollziehung des Gesetzes und somit eine stärkere Abschreckungswirkung gegen Spammer zu erreichen.
2.3.4 Auswirkungen der Gesetze auf Spammer
Diese Gesetze haben, so scheint es keinerlei Auswirkungen auf Spammer und auf die Anzahl der weltweit verschickten Spam E-Mails. Im Jänner 2004 legte die EU-Kommission eine „Mitteilung über unerbetene Werbenachrichten (Spam) [Kommission d. europ. Gem., 2004]“ vor. Darin wird hingewiesen, dass der Erlass von Rechtsvorschriften nur ein erster Schritt ist, aber keine absolute Lösung des Problems bietet.
Spammer versuchen anonym zu bleiben und aus Ländern mit keinen Gesetzen oder nur geringen Strafen zu operieren. Unterschiedliche Gesetze und Staaten, sowie die Aufdeckung der Identität eines Spammer erschweren eine erfolgreiche Klage. Zusätzlich fallen bis zur einer erfolgreichen Verurteilung nicht zu vernachlässigende Kosten an, sowie rechtliche Unsicherheiten in vielen Fällen. Eine Anklage gegen Spammer für Konsumenten sowie Klein- und Mittelbetriebe ist aus diesen Gründen nicht ratsam und mit einem hohen finanziellen Risiko behaftet, da auch die Schadenersatzhöhe sehr unterschiedlich ermittelt wird. (Siehe Kapitel wirtschaftliche Betrachtung für von Spammer verursachte Schäden.)
2.4 Spam Techniken
Als Spam E-Mails immer häufiger auftraten, wurden Anti-Spam Techniken und Tools entwickelt. Diese Tools wurden hauptsächlich von Administratoren großer Domains mit vielen E-Mail Adressen eingesetzt und konnten Spam sehr erfolgreich verhindern. Spammer antworteten mit verbesserten Techniken und Methoden um die Filter zu umgehen und die Anzahl der versendeten E-Mails zu vergrößern.
2.4.1 E-Mail Adressen
Spammer benötigen für ihre Arbeit eine große E-Mail Liste und eine Möglichkeit E-Mails zu versenden. Nur wenige Promille der versendeten Spam E-Mails sind erfolgreich und führen zu einem Geschäftsabschluss (od. Betrug) mit dem Empfänger. Daher sind große Listen mit unzähligen E-Mail Adressen sehr wichtig, vor allem mit geprüft existierenden Adressen. Die Spammer verwenden unterschiedliche Techniken, um E-Mail Adressen zu sammeln. Dies wird auch als harvesting (engl. harvest) bezeichnet. Die hauptsächlich verwendeten Methoden werden jetzt beschrieben.
2.4.1.1 Datenkauf
Der einfachste Weg aus technischer Sicht ist, die gewünschten Daten zu kaufen. Der Verkauf solcher Daten ist laut §92 des Datenschutzgesetzes (DSG) gesetzlich verboten. Wie in vorhergehenden Kapitel beschrieben halten Gesetze Spammer nicht auf.
Die Daten werden meist von anderen Spammer verkauft, um zusätzlich Geld zu verdienen. Zusätzlich werden Daten manchmal auch von so genannten „Rogue“ (dt.: Schurke) Angestellten eines Unternehmens verkauft. Diese Angestellten haben Zugriff auf jene Daten mit E-Mail Adressen, welche für Spammer interessant sind und verkaufen diese zum Schaden des Unternehmens und deren Kunden. Im Juni 2004 wurde ein American OnLine (AOL) Angestellter verhaftet, weil dieser mehr als 30 Millionen E-Mail Adressen von AOL Kunden verkauft hatte. [ALISTER, 2004]
2.4.1.2 Webseiten
Fast jede Firma und viele Privatpersonen besitzen eine eigene Website im Internet. Die meisten dieser Webseiten bieten eine E-Mail Kontaktmöglichkeit an. In HTML wird ein Link in der Form mailto:user@example.com angegeben. Damit kann ein Besucher einfach mit einem Mausklick eine E-Mail an den angegebenen Empfänger schicken.
Schon seit dem Beginn des Internet gab es automatische Programme, welche den Inhalt einer Webseite versuchen zu speichern. Dabei versuchen diese den Links zu anderen Seiten zu folgen. Solche Programme nennt man Spiders und werden hauptsächlich dafür eingesetzt, das Internet zu durchwandern, um Indexe und Informationen für Suchmaschinen wie zum Beispiel Google zu sammeln. Diese Technik wurde von einigen Spammer leicht verändert, sodass diese nach mailto Links suchen und speichern.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2.4: E-Mail Adressen sammeln mittels Spider
In der Abbildung 2.4 wird die Funktionsweise eines Spam Spiders schematisch dargestellt. Der Spider besucht die Startseite von a.example.com und findet drei Unterseiten. Ein Besuch der ersten Seite ergibt bereits die erste E-Mail Adresse. Auf der dritten Seite von a.example.com wird auf b.example.com verlinkt. Nachdem der Spider nun auch diese Seite analysiert hat wurden insgesamt drei E-Mailadressen gefunden.
Diese Spam Spiders funktionieren sehr gut und liefern in kurzer Zeit eine Menge an E-Mail Adressen. Die Spider Methode zum Sammeln von E-Mail Adressen ist unter Spammers die am häufigsten eingesetzte Technik.
2.4.1.2.1 Schutz gegen Spam Spiders
Um sich vor Spam Spiders schützen zu können gibt es mehrere Methoden folgend werden zwei Methoden genauer beschrieben. Eine Möglichkeit wäre keine einzige E-Mail Adresse auf der Webseite zu veröffentlichen. Damit ein Besucher mit dem Webseiten Inhaber in Kontakt treten kann, muss dieser ein geeignetes Webformular verwenden. Viele Besucher ziehen jedoch eine Kommunikation via E-Mail vor und erwarten auf einer Internetseite auch eine Angabe der E-Mail Adresse. Bei der zweiten Methode werden durch unterschiedliche Darstellungstechniken das Filtern nach E-Mail Adressen erschwert.
Zum Beispiel kann eine alternative Schriftzeichendarstellung gewählt werden. Das Zeichen ‚a’ kann in HTML durch
- a
- a
- a
dargestellt werden. Das Schriftzeichen ‚a’ kann im dezimalen Format als 97 und im hexadezimalen Format als x61 repräsentiert werden. Ein mailto: Link kann nun in diesem Format anstatt der normalen Zeichen erstellt werden. Die alternative Darstellung von mailto:user@example.com würde in einer HTML Datei mit Link wie folgt aussehen:
Abbildung in dieser Leseprobe nicht enthalten
Eine weitere Möglichkeit eine Suche nach einer E-Mail Adresse zu erschweren, ist die Trennung von Username, Domain und dem identifizierenden „@“ Zeichen.
Abbildung in dieser Leseprobe nicht enthalten
Obiger JavaScript Code stellt für einen Spider ein großes Problem dar. Auch bei der Annahme ein Spider könnte JavaScript interpretieren, müsste dieser zusätzlich die Funktion des Code analysieren, um zu erkennen, dass die Variable m1, m2 und m3 zusammen eine E-Mail Adresse ergeben.
2.4.1.2.2 Software
Die so genannten Spam Spider werden meist legal unter dem Begriff „Mailfinder“, „Mailfilter“ und ähnliches für E-Mail Direktmarketingzwecke angeboten. Zum Beispiel das Produkt „Mailfinder“ von der Firma MEDIA KG. Die Software kategorisiert die gefundenen E-Mail Adressen zusätzlich nach Themen. [MEDIAKG, 2005]
2.4.1.3 Mailinglisten und Archive
Mailinglisten(ML) sind nützliche Softwaretools, welche die Kommunikation mit vielen Personen erleichtert. Sie erlauben einem User eine E-Mail an eine einzige Adresse zu senden, welche danach an alle Mitglieder der ML weitergeleitet wird. Spammer verwenden dieses System, eine Spam E-Mail an die ML zu senden, um schnell und einfach viele Personen zu erreichen. Zur Verhinderung fordern die meisten ML neue User zu einer Authentifizierung bei der Anmeldung auf. Dieser manuelle Vorgang unterbindet automatisierte Prozesse von Spammern.
Oft werden ML archiviert und im Internet zur Einsichtnahme veröffentlicht. Wenn ein Spammer oder ein Spam Spider ein ML Archiv erreicht, hat dieser Zugang zu den E-Mail Adressen von allen Personen, welche eine Nachricht an die ML gesendet haben. Für eine Unterbindung müssen alle E-Mail Adressen im ML Archiv geschützt (Siehe 2.4.1.2.1) oder beschädigt bzw. unkenntlich gemacht werden. [ALISTAIR, 1999]
2.4.1.4 Trojanische Software
Fast jeder Internet User besitzt eine E-Mail Kontaktliste beziehungsweis ist diese fester Bestandteil der MTU Software wie zum Beispiel bei Microsoft Outlook. Diese Listen sind interessante Informationsquellen für Spammer. Der Zugriff auf diese kann mit Hilfe einer Trojanischen E-Mail erfolgen. Als Trojanisches Pferd oder Trojaner bezeichnet man in der Computersprache Programme, die sich als nützliche Programme tarnen, aber in Wirklichkeit Malware (Schad-Software) einschleusen und so den Benutzer ausspionieren. Trojaner verstoßen gegen das Datenschutzgesetz und sind daher illegal. Die Kombination aus Trojaner und Virus führt zu einer raschen Verbreitung und kann viele verschiedene Kontaktlisten ausspionieren.
2.4.1.5 Website Registrierungen
Viele Websiten erfordern eine Registrierung des Users mit einer gültigen E-Mail Adresse, damit dieser auf bestimmte Informationen oder Inhalte zugreifen kann. Die Angabe der E-Mail Adresse ist häufig nötig, da diese für Dirketmarketingzwecke gesammelt werden. Seriöse Websites bieten bei der Anmeldung eine „Newsletter“ Option an, mit welcher der User angeben kann, ob dieser Werbemails erhalten will. Spammer stellen spezielle Websites zum Sammeln von E-Mail Adressen ins Internet. Diese Seiten werben meist mit Gratisprodukten, wie Software, Videos und Musik für eine Registrierung.
2.4.1.6 Wörterbuch Angriff
Beim Wörterbuch Angriff handelt es sich um ein „Trial and Error“ Verfahren. Es werden verschiedene Usernamen auf eine bestimmte Domain getestet. Da es einige häufig gebrauchte Namen für E-Mail Adressen gibt, werden diese zuerst überprüft. Ein Angriff auf example.com mit häufigen Namen könnte mit office@example.com, admin@example.com, support@example.com, usw. durchgeführt werden. Daneben kann man auch noch Kombinationen aus weit verbreiteten Vor- und Nachnamen in diversen Formen probieren. Der häufigste im deutschen Sprachraum verwendete Nachname ist Müller (1,6%) [WIKIPEDIA; Familienname] und in Kombination mit einem ebenso gebräuchlichen Vornamen wie z.B.: Franz, ergeben sich Möglichkeiten der Form wie franz.mueller@example.com, f.mueller@example.com, mueller@example.com, usw.
Wenn die Zieladresse (RCPTTO) am Mailserver (Empfänger MTA) nicht existiert kann dieser auf drei unterschiedliche Arten reagieren:
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2.5: Möglichkeiten der Reaktion eines MTA auf eine nicht existierende E-Mail Adresse
(1) Der Mailserver empfängt die E-Mail, reagiert aber nach außen hin nicht. Intern wird die nicht zugestellte E-Mail als Fehler protokolliert. (2) Die meisten Mailserver senden einen „Non Delivery Report“ (NDR), wenn versucht wird, eine E-Mail an eine nicht existierende Adresse zu senden. Das heißt der Mailserver antwortet mit einer E-Mail an die vom Sender angegebene Absender Adresse (MAILFROM). Ist der Absender gefälscht, empfängt eventuell eine falsche Person den NDR. Dadurch kann es zu einer ungewollten E-Mail Kommunikation kommen, welche zusätzliche Bandbreite und Ressourcen benötigt und unter Umständen zu Verwirrung bei falscher Zustellung führt. (3) Der Mailserver kontrolliert noch während dem SMTP Verbindungsvorgang, bevor die kompletten E-Mail Daten empfangen werden, die Richtigkeit der Empfangsadresse. Existiert diese nicht, wird die SMTP Verbindung mit einem Fehler beendet.
Bei (1) nur mit richtiger Absenderadresse und (2) können Spammer feststellen, ob die probierte E-Mail Adresse existiert. Wie effektiv der Wörterbuch Angriff auf E-Mail Adressen funktioniert ist unbekannt. Vermutlich funktioniert dieser Angriff gut, da anhand von Mail Logfiles der Maurer IT Systemlösung KEG Mailserver diese laufend auf die unterschiedlichsten E-Mail Adressen getestet werden.
2.4.1.7 E-Mail Adressen Validierung
Der Aufbau einer großen E-Mail Adressen Datenbank kann durch die oben beschriebenen Methoden erreicht werden. Neben dem Sammeln von neuen E-Mail Adressen versuchen Spammer die Qualität der vorhandenen Adressen zu verbessern. Eine E-Mail Adresse ist nur dann von hoher Qualität, wenn die gesendeten Spam E-Mails auch ankommen und gelesen werden. Dafür wurden eigene Techniken entwickelt um dies festzustellen. Den Prozess kann man am ehesten mit einer Lesebestätigung vergleichen, die gegenüber dem Empfänger versucht wird zu verstecken.
Hierfür müssen einige Voraussetzungen erfüllt werden. Der MUA (wie zum Beispiel Microsoft Outlook) zeigt HTML E-Mails an oder lässt Scriptsprachen wie z.B.: JavaScript zu. Eine quasi Lesebestätigung mittels Scriptsprache erfordert, dass diese vom MUA zugelassen wird, und dass der MUA diverse Möglichkeiten wie zum Beispiel das versenden einer E-Mail hat. Alle gängigen am Markt erhältlichen MUAs unterdrücken die Interpretation von Scriptcode.
Daher ist diese Variante für Spammer zu unsicher und diese verwenden daher meistens HTML E-Mails mit einer externen Bildquelle oder einem opt-out Verweis. Der Bildverweis könnte zum Beispiel so aussehen:
<img src=“http://www.example.com/spam.php?test@example.com“>
Auf dem Server von example.com läuft ein Script (z.B. spam.php), welches ein Bild zurück liefert und zusätzlich die HTTP URL Information test@example.com auslesen kann. Somit wurde festgestellt, dass der Empfänger von test@example.com die empfangene E-Mail gelesen bzw. mindestens im MUA geöffnet hat. Somit ist die E-Mail Adresse in Verwendung. Wenn die E-Mail jedoch für den Empfänger kein Bild anzeigen soll, wird dieses häufig auf eine nahezu unsichtbare Größe von 1x1 Pixel beschränkt. Hersteller von MUAs haben auf diese Validierungstechnik reagiert und Optionen eingebaut, welche Bilder nur nach ausdrücklichem Wunsch des Anwenders bzw. generell keine HTML E-Mails anzeigen.
Die zweite häufig verwendete Möglichkeit ist es, dem Empfänger einen gefälschten Opt-Out Link in der E-Mail anzubieten. Ein angewählter Opt-Out Link bestätigt dem Spammer die Verwendung dieser E-Mail Adresse und ist das Gegenteil von ursprünglichen Idee hinter Opt-Out (Siehe 2.3.1 Die österreichische Gesetzeslage).
2.4.2 Spam Versand
Nur einige Promille der versendeten Spam E-Mails führen zum Erfolg. Daher wird die Anzahl der versendeten E-Mails zum Erfolgsfaktor. Zusätzlich versuchen Spammer anonym zu bleiben, um sich vor strafrechtlichen Konsequenzen zu schützen.
[...]
[1] Domainname für Beispiele gemäß RFC2606. Die Domains example.com, example.net und example.org werden derzeit von der Internet Assigned Numbers Authority (IANA) verwaltet.
- Citar trabajo
- Christian Schuller (Autor), 2005, Zentraler Mailgateway zur informationsabhängigen Filterung von E-Mails, Múnich, GRIN Verlag, https://www.grin.com/document/39502
-
-
-
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X.