Ebook - No Spam

Tobias Eggendorfer
No Spam!
Tobias Eggendorfer
No Spam!
Besser vorbeugen als heilen
Software & Support Verlag GmbH

Frankfurt 2005
Tobias Eggendorfer : No Spam!
Besser vorbeugen als heilen.
Frankfurt, 2005
ISBN 3-935042-71-X
© 2005 Software & Support Verlag GmbH
http://www.software-support-verlag.de
http://www.entwicklerpress.de/buecher/nospam
Ihr Kontakt zum Verlag und Lektorat: lektorat@software-support.biz
Bibliografische Information Der Deutschen Bibliothek

Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen
Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über
http://dnb.ddb.de abrufbar.
Korrektorat: Petra Kienle

Satz: text & form GbR, Carsten Kienle
Umschlaggestaltung: Melanie Hahn
Belichtung, Druck und Bindung: M.P. Media-Print Informationstechnologie GmbH,
Paderborn.
Alle Rechte, auch für Übersetzungen, sind vorbehalten. Reproduktion jeglicher Art
(Fotokopie, Nachdruck, Mikrofilm, Erfassung auf elektronischen Datenträgern oder
andere Verfahren) nur mit schriftlicher Genehmigung des Verlags. Jegliche Haftung
für die Richtigkeit des gesamten Werks kann, trotz sorgfältiger Prüfung durch Autor
und Verlag, nicht übernommen werden. Die Programmbeispiele dienen nur der Er-
klärung und sind nicht ungeprüft für den Produktionseinsatz geeignet. Die im Buch
genannten Produkte, Warenzeichen und Firmennamen sind in der Regel durch deren
Inhaber geschützt.
Inhaltsverzeichnis
Vorwort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Notwendige Vorkenntnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Zum Umgang mit diesem Text . . . . . . . . . . . . . . . . . . . . . . . . . 13
1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.1 Untaugliche Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.2 Spam an der Wurzel bekämpfen . . . . . . . . . . . . . . . . . . . . 16
2 Was ist Spam? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.1 Etwas Geschichte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2 Spam und Recht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3 Unsolicited Bulk E-Mail . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3 Woher haben Spammer die Mailadressen?. . . . . . . . . . . . . . . . 25
3.1 Freiwillige Eingabe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2 Adressen im Internet automatisch sammeln . . . . . . . . . . . 25
3.2.1 Durchsuchen von Internetseiten. . . . . . . . . . . . . . 25
3.2.2 Newsgroups und ähnliche Quellen . . . . . . . . . . . 28
3.2.3 Erraten von Adressen . . . . . . . . . . . . . . . . . . . . . . 29
3.2.4 Adresshandel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4 Grundlegende Vorsichtsmaßnahmen. . . . . . . . . . . . . . . . . . . . . 33
4.1 Umgang mit Mailadressen . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.2 Wegwerfadressen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.3 Newsletter und Ähnliches . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.4 Keinesfalls: gefälschte Absenderadressen . . . . . . . . . . . . . 37
4.5 Webtelefonbücher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.6 Spammer beim Sammeln identifizieren. . . . . . . . . . . . . . . 39
4.7 SMTP-Teergruben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.8 Rechtsweg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5 E-Mail-Adressen von Webseiten verbannen . . . . . . . . . . . . . . . 43
5.1 Adressen fälschen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.2 Verstecken mit HTML-Code . . . . . . . . . . . . . . . . . . . . . . . 46
5.2.1 Kontaktformular. . . . . . . . . . . . . . . . . . . . . . . . . . 47
No Spam! 5
Inhaltsverzeichnis
5.2.2 Tarnen mit HTML . . . . . . . . . . . . . . . . . . . . . . . . 58

5.2.3 Rechtliches. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.3 Bilder und Ähnliches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.3.1 E-Mail-Adresse als Bild. . . . . . . . . . . . . . . . . . . . 67
5.3.2 PDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.3.3 Flash. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.4 JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.4.1 Das Grundprinzip. . . . . . . . . . . . . . . . . . . . . . . . . 72
5.4.2 Eine stabilere Lösung. . . . . . . . . . . . . . . . . . . . . . 74
5.4.3 Theoretische Informatik ausnutzen . . . . . . . . . . . 76
5.4.4 Mit Verschlüsselung. . . . . . . . . . . . . . . . . . . . . . . 77
5.4.5 Harvester mit JavaScript . . . . . . . . . . . . . . . . . . . 83
5.4.6 JavaScript-freie Browser . . . . . . . . . . . . . . . . . . . 84
5.5 Weitere Verfahren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.6 Test auf echten Webseiten . . . . . . . . . . . . . . . . . . . . . . . . . 87
5.7 Test mit echten Harvestern. . . . . . . . . . . . . . . . . . . . . . . . . 89
6 Automatisch tarnen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
6.1 Apache-Modul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
6.1.1 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
6.1.2 Programmierzauber . . . . . . . . . . . . . . . . . . . . . . . 96
6.1.3 Tarnfunktion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
6.1.4 Das Script selbst. . . . . . . . . . . . . . . . . . . . . . . . . . 97
6.2 Tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
7 Missbrauch fertiger Scripten . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
7.1 Missbrauch von Kontaktformularen . . . . . . . . . . . . . . . . . 104
7.1.1 Empfänger als INPUT TYPE HIDDEN . . . . . . . 104
7.1.2 Nutzereingabe im From-Feld. . . . . . . . . . . . . . . . 106
7.1.3 Nutzereingabe sonstiger Header-Felder. . . . . . . . 106
7.1.4 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . 107
7.2 Missbrauch von eCards . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
7.2.1 Hinweise zur Umsetzung . . . . . . . . . . . . . . . . . . . 109
7.3 Send-To-A-Friend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
6
Inhaltsverzeichnis
8 Harvester blockieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

8.1 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
8.2 Überlastungsprophylaxe. . . . . . . . . . . . . . . . . . . . . . . . . . . 124
8.2.1 Semaphoren in PHP . . . . . . . . . . . . . . . . . . . . . . . 125
8.3 Die Lösung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
8.4 Ein Script – viele Namen . . . . . . . . . . . . . . . . . . . . . . . . . . 127
8.5 Suchmaschinen schützen . . . . . . . . . . . . . . . . . . . . . . . . . . 128
8.6 Beispiel-Teergrube . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
8.6.1 Konfiguration der Beispiel-Teergrube . . . . . . . . . 128
8.6.2 Das Script. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
8.7 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
8.8 Weitere Verbesserungsmöglichkeiten . . . . . . . . . . . . . . . . 135
9 Absichern von Mailinglisten und Newslettern . . . . . . . . . . . . . 137
9.1 Sicherheitsziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
9.2 Anmeldeverfahren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
9.2.1 Opt-Out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
9.2.2 Einfacher Opt-In . . . . . . . . . . . . . . . . . . . . . . . . . 138
9.2.3 Double-Opt-In . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
9.2.4 Anmeldebestätigung . . . . . . . . . . . . . . . . . . . . . . 141
9.3 Laufender Betrieb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
9.3.1 Schutz der Mailadressen . . . . . . . . . . . . . . . . . . . 142
9.3.2 Schutz der Liste . . . . . . . . . . . . . . . . . . . . . . . . . . 144
9.4 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
10 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Literaturhinweise. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Stichwortverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
No Spam! 7
Vorwort
Spamfilter sind langsam, fehleranfällig und wirken meiner Meinung nach am

falschen Ende: Sie entfernen Spam erst dann, wenn er auf dem Server des
Empfängers eingetroffen ist und ihm damit bereits Kosten verursacht hat. Das
Ziel sollte daher sein, Spam schon vor der Entstehung zu unterbinden und so
die Investition in aufwendige Spamfilter überflüssig zu machen.
Ich möchte Ihnen in diesem Buch Verfahren und Möglichkeiten der präventi-
ven Spam-Vermeidung vorstellen, die ich entweder selbst entwickelt habe oder
für die ich im Rahmen meiner Recherchen Anregungen und Ideen entdeckte,
die ich dann häufig noch verfeinern konnte.
Mein Ansatz ist dabei zu verhindern, dass Spammer überhaupt in den Besitz
von E-Mail-Adressen gelangen. Dadurch wird ihnen das wichtigste Hand-
werkzeug genommen.
Spammer ernten E-Mail-Adressen vorzugsweise – aber nicht ausschließlich –
von Webseiten. Daher stelle ich hier unter anderem Lösungen vor, wie sich
Webseiten so gestalten lassen, dass Sammelprogramme dort keine E-Mail-
Adressen mehr finden. Dabei werde ich auch eine Lösung implementieren, die
die vorgeschlagenen Verfahren automatisiert durchführt, ohne dass die beste-
henden Webseiten manuell geändert werden müssten.
Zwei große Themenkomplexe in der Spambekämpfung spare ich aus: zum ei-
nen die Konfiguration von Mail-Servern, so dass sie nicht als Open Relay
missbraucht werden können1, und zum anderen die Problematik des „Open
Proxy“. Beide Probleme erscheinen mir zu speziell und sind in der Literatur
mittlerweile ausführlich und ergiebig diskutiert. Zudem setzen beide Lösun-
gen einen Schritt hinter meinem Ansatz an: Sie versuchen, den Versand von
Spam zu behindern, und greifen damit erst dann ein, wenn der Spammer be-
reits E-Mail-Adressen seiner Opfer hat.
Ich hoffe, in der folgenden Darstellung die richtige Mischung aus Theorie und
Praxis gefunden zu haben. Und ich hoffe, dass ich mein Ziel, Ihnen durch an-
schauliche Erklärungen das Verständnis zu erleichtern, erreiche.
1. Siehe z.B.: [COS97] für Sendmail, [HEIN04] für Postfix und [SIL01] sowie [BER03a] für
qmail.
No Spam! 9
Vorwort
In „Notwendige Vorkenntnisse“ gebe ich Ihnen einige Hinweise, welche Vor-

kenntnisse Sie zum Verständnis der einzelnen Kapitel mitbringen sollten. Sie
werden sehen, dass häufig eine gesunde Portion Neugier und Interesse aus-
reicht, um den Beispielen zu folgen.
Leider bin ich auch nur ein Mensch und somit fehlbar – gerade eine erste Aus-
gabe hat den Fehlerteufel in sich. Daher würde ich mich über Feedback, An-
merkungen, konstruktive Kritik, aber auch über eine Sammlung meiner
schönsten Tippfehler und unverständlichsten Sätze freuen. Zu diesem (und
vielen weiteren Zwecken) existiert auf meiner Homepage http://www.eggen-
dorfer.info ein Kontaktformular.
Sollten Sie sehr viele Fehler finden – oder auch reichlich Verbesserungsvor-
schläge haben, dann wird dort auch eine Seite mit entsprechenden Hinweisen
entstehen.
Ich wünsche Ihnen viel Spaß bei der Lektüre!
10
Notwendige Vorkenntnisse
Von meinem Verlag wurde ich mehrfach gefragt, an wen sich das Buch wende.
Das ist schwer zu sagen:
Einige der dargestellten Techniken (in Kapitel 4 und 5) sind für jeden nach-
vollziehbar, der schon mal eine Webseite erstellt hat. Häufig sind dafür noch
nicht einmal detailliertere HTML- oder gar JavaScript-Kenntnisse notwendig.
Diese Lösungsvorschläge wenden sich somit an jeden, der eine eigene Home-
page betreibt. Der notwendige Code ist stets ausführlich erläutert und kann so
fast immer ohne Änderungen auf die eigene Homepage übernommen werden.
In Kapitel 6 stelle ich Ihnen eine Methode vor, wie Sie die in Kapitel 5 erklär-
ten Tarnverfahren automatisch von Ihrem Webserver durchführen lassen kön-
nen. Das Schöne an der Lösung ist, dass Sie Ihre bestehenden Webseiten gar
nicht mehr anfassen müssen, um in den Genuss effektiver Tarnung zu kom-
men.
Der Haken an der Sache? Wie so oft: Bevor man sich faul zurücklehnen kann,
ist etwas Programmierarbeit nötig. Für das Verständnis des vorgestellten Pro-
gramms sind daher Perl-Kenntnisse hilfreich. Um das Konzept zu verstehen,
brauchen Sie aber nur Ihren gesunden Menschenverstand.
Kapitel 7 ist dann etwas für den kleinen Cracker in Ihnen: Wir schauen uns an,
wie typische Scripten auf Webseiten von Spammern missbraucht werden kön-
nen, und diskutieren, wie man sie gegen diese Angriffe abdichten kann. Um
die Ideen dieses Kapitels zu verstehen, sind HTML-Grundkenntnisse und et-
was Fantasie nötig. Um die Programmbeispiele nachvollziehen zu können und
an die eigenen Bedürfnisse anzupassen, sind PHP-Kenntnisse empfehlens-
wert. So stelle ich Ihnen beispielsweise in Kapitel 7.2 ein Verfahren vor, wie
man spamfrei eCards anbieten kann.
Ans Eingemachte gehen wir in Kapitel 8: Wir konstruieren eine Falle für
Spammer. Das Konzept ist wiederum für jedermann verständlich – allerdings
nutzt das vorgestellte PHP-Script zur Umsetzung dann einige trickreiche Pro-
grammiermethoden, die ich Ihnen ausführlich erkläre. Wenn Sie das Script auf
Ihrer eigenen Seite einsetzen wollen, sollten Sie daher PHP beherrschen.
In Kapitel 9 wird es wieder etwas allgemeiner: Wir diskutieren verschiedene
Verfahren, um Mailinglisten vor Spammern zu schützen. Das trifft Sie vor al-
No Spam! 11
Notwendige Vorkenntnisse
lem dann, wenn Sie selbst Newsletter oder Mailinglisten anbieten wollen –
sollte das der Fall sein, so haben Sie auch schon Erfahrung mit der notwendi-
gen Software. Ansonsten liefert Ihnen das Kapitel einige wertvolle Hinweise,
worauf Sie achten sollten, wenn Sie sich irgendwo anmelden.
Generell gilt: Die Erklärungen und Beispiele sind meiner Meinung nach für je-
den verständlich, der ein bisschen gesunde Neugier mitbringt. Die unterstelle
ich Ihnen, sonst hätten Sie kaum dieses Buch in der Hand.
12
Zum Umgang mit diesem Text
Um Programmbefehle zu markieren, verwende ich die folgende Darstellung:

UPDATE leser SET wissen = wissen + 1 WHERE buch_gelesen = true;
Sollten durch den Druck zufällig Zeilenumbrüche an Stellen entstehen, an de-
nen sie nicht hingehören und zu einer Fehlfunktion führen würden, markiere
ich den Zeitpunkt, an dem Sie die Return-Taste drücken dürfen, mit [RET]. So-
weit aber ein Zeilenumbruch nicht stört, verzichte ich im Sinne der besseren
Lesbarkeit auf diesen Zusatz.
Ich verwende im Text relativ großzügig Fußnoten. Häufig gebe ich Ihnen dort
Quellen an, unter denen Sie weitere Detailinformationen zu einem bestimmten
Problemkreis finden können, dessen Darstellung hier den Rahmen sprengen
würde. Manchmal ist es hilfreich, wenn die eigene Neugier geweckt ist, einen
Einstiegspunkt für weitere Recherchen zu finden.
Die Literatur ist dabei mit einem Kürzel im Text angegeben, Sie finden die
vollständigen Angaben unter dem Kürzel im alphabetisch sortierten Literatur-
verzeichnis am Ende des Buchs.
Ich kann keinerlei Garantie für die Fehlerfreiheit der Programmbeispiele über-
nehmen: Zwar habe ich sie ausführlich getestet, einige liefen (und laufen) auf
Webseiten, die massiv von Spammern heimgesucht werden, aber die Scripten
sind hier lediglich aus didaktischen Gründen eingestreut und sollen das Ver-
ständnis erleichtern. Sie sollen Ihnen als Ausgangsbasis zur Entwicklung eige-
ner Lösungen dienen, die Sie vor dem Live-Einsatz natürlich gründlich testen
müssen – insbesondere auf Sicherheitslöcher2.
Jedoch schränke ich das Nutzungsrecht daran ausdrücklich dahingehend ein,
dass keines der Programme, Programmbeispiele oder der vorgestellten Verfah-
ren von Spammern, zur Vorbereitung der Versendung oder der Versendung von
Spam oder ähnlich niederträchtigen Zwecken verwendet werden darf. Eine
solche Verwendung würde ich als Urheberrechtsverstoß verfolgen.
Gegen eine Nutzung zu privaten und wissenschaftlichen Zwecken unter Hin-
weis auf meine Urheberschaft habe ich jedoch keinerlei Einwände.
2. Mit diesem Problem beschäftigen sich ausführlich: [KOZ04], [HOG04] und [VIE01]. Eine
allgemeinere Einführung liefert [PEI04].
No Spam! 13
1 Einführung
Spam lässt Ihren E-Mail-Briefkasten überquellen. Doch warum eigentlich?

Woher haben die Spammer Ihre Adresse? Und was kann man präventiv gegen
Spam tun? Das sind Fragen, mit denen wir uns hier beschäftigen wollen.
1.1 Untaugliche Filter

Dabei klammern wir die Frage nach Spamfiltern bewusst aus: Erstens gibt es
dazu bereits mehr als genug Literatur, zweitens sind die Filter anders als bei
Viren und Würmern nur eingeschränkt wirkungsvoll. Viren und Würmer ha-
ben eindeutige Signaturen, über die sie gut automatisch erkannt werden kön-
nen. Bei Spam gibt es so etwas nicht.
So hilft z.B. ein Filter, der auf bestimmte Schlagwörter reagiert, nichts: Für
Apotheker, Urologen, Kardiologen und Internisten beispielsweise sind E-
Mails mit dem Wort „Viagra“ häufig wichtige Anfragen von Patienten und
nicht unbedingt Spam. Ähnlich werden Uhrenhändler und Juweliere die Be-
griffe „Rolex“, „Cartier“ und „Breitling“ nicht auf ihre Blacklist setzen wol-
len.
Auch die anderen gängigen Filterverfahren scheitern an praktischen Proble-
men: So schlagen manche Autoren vor, E-Mails nur von Rechnern mit festen
IP-Adressen anzunehmen und haben dabei die Rechnung ohne die Telekom-
munikations-Überwachungsverordnung (TKÜV) gemacht: Denn die zwingt
die großen Provider dazu, an ihren Mailservern Abhörvorrichtungen bereitzu-
stellen. Wer das umgehen will, nutzt diese Server nicht, sondern mailt direkt
von seinem PC. Technisch ist das kein Problem.
Vielfach hochgelobt sind so genannte Open-Relay-Blacklists, also schwarze
Listen von Servern, die E-Mails für fremde Domains annehmen und weiterge-
ben („relayen“). Ungünstig ist dabei nur, dass manche Listen so aggressiv sind,
dass sogar seriöse Anbieter wie web.de und GMX regelmäßig dort gesperrt
werden. Mancher Administrator setzt im vollen Vertrauen sogar Listen wie die
von Spamcop als einzigen Filter ein, obwohl Spamcop selbst davor warnt, weil
sie ihre Liste als experimentell und sehr aggressiv einstufen.
Zudem wirkt der Filter schlicht am falschen Ende der „Spam-Kette“. Günsti-
ger wäre es, das Übel Spam an der Wurzel zu packen.
No Spam! 15
1 – Einführung
1.2 Spam an der Wurzel bekämpfen

Die Wurzel ist, so haben eine Studie ([CDT03]) und eigene Untersuchungen3
ergeben, die Veröffentlichung von E-Mail-Adressen auf Webseiten. An diesem
Punkt setze ich an und dokumentiere Verfahren, wie E-Mail-Adressen auf Ho-
mepages für Spammer unsichtbar gemacht werden können.
Später werden wir uns überlegen, wie beispielsweise Kontaktformulare gestal-
tet sein müssen, um zu verhindern, dass sie als „Spamming-Engines“ miss-
braucht werden können. Dabei demonstriere ich Ihnen auch ein Verfahren zum
Anbieten von eCards, ohne Gefahr zu laufen, als Spammer auf Unterlassung in
Anspruch genommen zu werden4.
In einem letzten Schritt werfen wir dann einen Blick auf ein Verfahren, das
Spammern das Sammeln von Adressen vergällen soll.
Zuerst jedoch möchte ich Ihnen zeigen, wie Spammer die Adressen sammeln,
und den Begriff Spam definieren. Immer mehr unerwünschte Mails werden
heutzutage von Würmern und Trojanern versandt, die mit den Methoden die-
ses Buchs nicht kleinzukriegen sind.
Das Problem der Viren, Würmer und Trojaner können wir hier nicht behandeln
– es passt nicht in diesen Rahmen. Auch dazu existiert bereits einiges an Lite-
ratur5.
Parallel zur Erstellung dieses Buchs habe ich einen Kurs für die Volkshoch-
schule München konzipiert, der sich jedoch nur auf die spamsichere Gestal-
tung von Homepages konzentriert und nicht alle präventiven Möglichkeiten
vorstellen sollte – schließlich ist der Zeitrahmen einer solchen Veranstaltung
begrenzt. Die dort beschriebenen Methoden fasste ich für die Zeitschrift „Li-
nux-User“ in einem Beitrag zusammen. Der Beitrag stieß unter den Lesern,
wie zahlreiche Zuschriften belegen, auf sehr großes Interesse und erschien
mittlerweile in Übersetzungen in der internationalen, englischen Ausgabe „Li-
nux-Magazine“, im rumänischen Linux-Magazin „Linux-Magazin Romania“
und in der polnische Ausgabe „Linux Magazine“6.
3. [EGG05a], [EGG05b] und [EGG05c]

4. Siehe dazu http://de.wikipedia.org/wiki/E-Card, dort ist der Volltext der einschlägigen
Urteile verlinkt
5. Siehe dazu: [EGG04d], [EGG05d]
6. Siehe: [EGG04], [EGG04g], [EGG04h], [EGG04f]
16
Spam an der Wurzel bekämpfen
Im deutschsprachigen Linux-Magazin stellte ich erstmals auch ein Verfahren

vor, Spammer zu ärgern – sie also beim Einsammeln von Adressen nachhaltig
zu behindern.7
Im vorliegenden Buch diskutiere ich um einiges ausführlicher, als es im Rah-
men von Artikeln möglich ist, diese und andere Verfahren. Insbesondere wer-
den dabei auch die rechtlichen Konsequenzen dargestellt.
Ich wünsche Ihnen viel Vergnügen bei der Lektüre – und eine spamfreie Zu-
kunft. Die verspricht zumindest [CDT03], hindert man Spammer am Adres-
sensammeln.
7. Siehe: [EGG04a]
No Spam! 17
2 Was ist Spam?
Die Bezeichnung „Spam“ wird heutzutage in einer wesentlich umfassenderen

Bedeutung verwendet als ursprünglich. Viele Anwender verstehen unter Spam
die massenhafte Zusendung von E-Mails unabhängig von deren Inhalt. Insbe-
sondere werden auch die von Würmern automatisch generierten E-Mails von
vielen Anwendern als Spam bezeichnet. Manche gehen sogar noch weiter und
nennen alles Spam, was auch nur in entferntester Form unerwünschte Werbung
darstellen könnte: Einige sprechen von Google-Spam, also manipulierten
Trefferpositionen in einer Google-Suche, und andere von Papier-Spam und
verstehen darunter Postwurfsendungen.
2.1 Etwas Geschichte

Ursprünglich stand Spam für die massenhafte Sendung unerwünschter Wer-
bung in den Newsgroups, speziellen Diskussionsbereichen im Internet. Dort
tauchte auch erstmalig der Begriff „Spam“ auf.
Dabei ist das Wort SPAM zunächst unverfänglich und kommt aus einem völlig
anderen Bereich: SPAM in Großbuchstaben geschrieben ist nämlich als Wort-
marke von der US-amerikanischen Firma Hormel Foods8 geschützt. SPAM
steht dabei als Abkürzung für Spiced Pork and Ham und ist ein penetrant pink
leuchtendes, unnatürlich aussehendes, aber in den USA ubiquitäres Dosen-
fleisch. Dieses Dosenfleisch hat dort offensichtlich Kultcharakter erlangt:
Ähnlich wie für das bei uns bekanntere Nutella gibt es eigene SPAM-Koch-
bücher9 und SPAM-Restaurants.
Den Zusammenhang zwischen diesem Fleischderivat und unerwünschter Wer-
bung erzeugte indirekt Monty Python, ein britischer Komiker. In einer seiner
„Flying Circus“-Folgen möchte ein Gast in einem Restaurant, dessen Speise-
karte ausschließlich Speisen enthält, die in irgendeiner Art auf SPAM basieren,
ein Gericht ohne dieses Fleisch bestellen. Beim Versuch, die Bedienung nach
entsprechenden Angeboten zu fragen, unterbindet ein Wikinger-Chor die
Kommunikation und singt lauthals „Spam, Spam, Spam ...“.
8. Siehe dazu: http://www.spam.com

9. Siehe dazu: [WYM99]
No Spam! 19
2 – Was ist Spam?
In einem Usenet-Posting am 31. März 1993 wurde dann, so die Darstellung in

[GOO04], das erste Mal für unerwünschte Werbung in Newsgroups der Begriff
„Spam“ verwendet. Die damalige Internetgemeinde, der sehr viele Fans von
Monty Pythons Flying Circus angehörten, verstand die Anspielung.
Andere Autoren dokumentieren die Begriffsentstehung nicht so detailliert,
sondern heben auf die massive Kommunikationsstörung und die Analogie zu
diesem Sketch ab: Durch Spam wird jede normale Kommunikation unterbun-
den, das Kommunikationsmedium unbrauchbar gemacht.
So laufen Postfächer wegen Spam über, Mailserver brechen unter der Flut von
Werbemails zusammen und schlecht konfigurierte Filter löschen erwünschte
Nachrichten, weil sie diese fälschlich für Spam halten. Der Mensch, als letzter
in der Reihe, übersieht dann auch noch in den Mail-Massen die erwünschten
Nachrichten. So wird E-Mail unbrauchbar.
Aus der Geschichte, die [McW05] in Romanform erzählt, ergibt sich zunächst
die enge Definition von Spam: Spam sind unerwünschte Werbepostings im
Usenet. Später wurde der Begriff schnell erweitert auf unerwünschte Werbe-E-
Mails, die man ursprünglich „Unsolicited Commercial E-Mail“ oder kurz
UCE nannte.
Tatsächlich gibt es immer wieder Hardliner, die Spam nur in der ursprüngli-
chen, engen Definition der unerwünschten Usenet-Postings verwendet wissen
wollen. So gab es z.B. lang anhaltende, heftige Diskussionen, als der Artikel
über UCE im deutschen Wikipedia10 unter die Überschrift „Spam“ verschoben
wurde. Mittlerweile wird auch dort Spam in der neueren, weiteren Definition
verwendet.
Allerdings ist die überwiegende Meinung in Fachkreisen immer noch, dass un-
ter Spam nur unerwünschte Werbemails zu verstehen sind, nicht jedoch uner-
wünschte Massenmails: Letztere stellen eine Art Oberbegriff dar: Auch Spam-
Mails sind unerwünschte Massenmails, englisch „Unsolicited Bulk E-Mail“
(UBE), aber nicht jede UBE ist Spam.
2.2 Spam und Recht

Spam ist nur dann Spam im Sinne unserer Definition, wenn es sich bei dem In-
halt der Nachricht um unerwünschte E-Mail-Werbung handelt. Die Nachricht
10. http://www.wikipedia.de
20
Spam und Recht
muss also einen werbenden Charakter haben. Dabei fasst die deutsche Recht-
sprechung den Begriff Werbung anwenderfreundlich sehr weit.
Wichtigstes Kriterium ist „unerwünscht“. Eine werbende Mail ist genauso wie
Werbung per Fax, BTX, Telex, SMS oder auch Telefon immer dann uner-
wünscht, wenn sie außerhalb einer Geschäftsbeziehung zugesandt wird und
der Absender nicht mit dem Interesse des Empfängers an seiner Zusendung
rechnen durfte. Durch diese Einschränkung soll der Absender die Chance ha-
ben, neue Geschäftsbeziehungen anbahnen zu können, schließlich gehört das
zum üblichen Geschäftsgebahren.
Allerdings ist der Absender in Bezug auf das mutmaßliche Interesse des Emp-
fängers nach deutscher Rechtsprechung beweispflichtig. Seine Begründung
muss einer objektiven Nachprüfung standhalten.
Die Behauptung, dass jeder Mensch irgendwann einmal eine zwie- oder rot-
lichtige Seite im Netz besuchen würde, reicht also nicht aus, sondern es muss
das konkrete, aktuelle Interesse des Empfängers begründet werden11. Das je-
doch fällt den meisten Spammern schwer.
In einem der Verfahren, die ich gegen Spammer geführt habe, konnte sich der
Spammer in seinen Schriftsätzen noch nicht einmal entscheiden, ob er mich als
Freiberufler oder Privatperson kontaktiert hatte. Damit half ihm die Ausrede,
ich könnte an einer Kontaktaufnahme interessiert gewesen sein, auch nicht
weiter.
Die Annahme, dass der Empfänger der Werbemail auf seiner Homepage eine
E-Mail-Adresse angegeben hätte und damit stillschweigend jeglicher Kontakt-
aufnahme zustimme, reicht ebenso wenig für eine gültige Begründung aus.
Umstritten ist derzeit noch, ob in einer bestehenden Geschäftsbeziehung die
Zusendung von Werbung in beliebigem Umfang geduldet werden muss. Die
überwiegende Mehrheit geht davon aus, dass, sobald der Empfänger der wei-
teren Zusendung von Werbung nachweislich widersprochen hat, sie als uner-
wünscht einzustufen ist und es sich damit um Spam handelt.
Unter anderem deswegen fordert das 2004 aktualisierte Gesetz gegen den un-
lauteren Wettbewerb (UWG) das Vorhandensein eines Abmeldelinks in sol-
chen Newslettern. Allerdings zeigt die Praxis, dass Spammer das Anklicken
eines Abmeldelinks häufig als Bestätigung ansehen, dass Mails an die be-
11. Detaillierter zur Rechtslage [EGG04c] mit zahlreichen weiteren Quellen.
No Spam! 21
2 – Was ist Spam?
spammte Adressen tatsächlich gelesen werden. Solche Adressen werden als

„verified“ unter Spammern zu deutlich höheren Preisen gehandelt. Deshalb ist
es in aller Regel nicht zu empfehlen, einen solchen Link anzuklicken12.
Nicht nur wegen der häufig mit dem Klick auf einen vorgeblichen Abmelde-
link verbundenen Gefahren ist die Form des Widerspruchs dem Widerspre-
chenden überlassen. Insbesondere stellt die Zusendung einer Abmahnung mit
Aufforderung zur Abgabe einer Unterlassungserklärung einen Widerspruch
gegen die Zusendung von weiteren Newslettern dar. Der Vorteil eines Wider-
spruchs per Fax oder Brief ist zudem die Beweisbarkeit. Denn die Beweis-
pflicht für den erfolgten Widerspruch liegt beim Empfänger der Werbung.
Zulässig ist es, Empfängern auf deren ausdrücklichen Wunsch hin E-Mails mit
werbendem Inhalt zuzusenden. Diese Werbung wird zumeist als Newsletter
bezeichnet. Beweispflichtig für die Eintragung in den Newsletter ist der Ver-
sender. Daher empfiehlt sich die Verwendung eines qualifizierten Double-Opt-
In-Verfahrens, um zu verhindern, dass missbräuchlich E-Mail-Adressen Drit-
ter ohne deren Zutun eingetragen werden. Mit diesem Verfahren befasst sich
Kapitel 9.
Wie genau diese Zustimmung zur Zusendung von E-Mail-Werbung jedoch
aussehen muss, ist nicht festgelegt. Häufig konstruieren daher zwielichtige
Anbieter bei Kontaktaufnahme eine Zustimmung über ein Kontaktformular
oder bei Teilnahme an einem Gewinnspiel über die angeblich einbezogenen
AGB. Dabei steht entweder unterhalb des Eingabeformulars im Kleingedruck-
ten, dass der Absender der Nutzung seiner E-Mail-Adresse zu werblichen
Zwecken zustimmt, oder aber, der Surfer muss den Teilnahmebedingungen,
die in diesem Fall aus rechtlicher Sicht AGB darstellen und eine entsprechende
Regelung enthalten, zustimmen.
Aus meiner Sicht ist es fraglich, ob bei einer allgemeinen Anfrage an ein Un-
ternehmen über ein Kontaktformular ein Vertrag zustande kommt, der die Ein-
beziehung von AGB rechtfertigen würde: Es fehlt am Vertragsbindungswillen
des potenziellen Kunden, der Bedingung für einen Vertragsschluss ist. Kommt
aber kein Vertrag zustande, dann können erst recht keine AGB, die ja ein vor-
formuliertes Vertragswerk darstellen, Vertragsbestandteil werden.
Im Fall der Gewinnspielteilnahme wäre kritisch zu prüfen, ob eine Bedingung,
die erhaltenen Daten des Teilnehmers an Dritte weitergeben zu dürfen, und das
12. Siehe dazu z.B. [GOO04]
22
Unsolicited Bulk E-Mail
„Zwangsabonnement“ eines Newsletters nicht überraschende Klauseln sind,

mit denen ein Teilnehmer nicht zu rechnen braucht.
Die Rechtslage ist hier meiner Ansicht nach jedenfalls neu zu beurteilen und
nicht zwangsläufig mit Gewinnspielen, an denen man z.B. durch Ausfüllen ei-
ner Postkarte teilnimmt, vergleichbar: Zum einen muss der Absender Postkar-
ten nicht vollständig ausfüllen, was bei Online-Spielen durch entsprechende
Programmierung verhindert werden kann, und zum anderen verursacht die
postalische Zusendung von Werbung, die bei Offline-Gewinnspielen die übli-
che Konsequenz ist, anders als E-Mail-Werbung beim Empfänger keine Kos-
ten.
Die rechtswissenschaftliche Literatur schweigt sich allerdings zu dieser Frage
derzeit noch aus. Auch in der Rechtsprechung findet sich noch kein entspre-
chendes Urteil.
2.3 Unsolicited Bulk E-Mail

Unter UBE versteht man alle unerwünscht eintreffenden Massenmails – unab-
hängig von ihrem Inhalt und Absender. UCE ist also eine Untermenge von
UBE: Jede Spammail ist UBE, aber nicht jede UBE ist Spam.
Die massenhaft eintreffenden und überaus lästigen Wurm-Mails, die von infi-
zierten Rechnern mit dem Ziel, die Infektion zu streuen, automatisch versandt
werden, sind kein Spam. Bei ihnen handelt es sich ebenso um UBE wie bei
mancher lästigen E-Mail aus dem Bekanntenkreis, in der ein Absender Be-
langlosigkeiten an sein gesamtes Adressbuch versendet, ohne die Blind-Car-
bon-Copy-Funktion (Blind-CC, BCC) seines E-Mail-Programms zu nutzen.
Damit verstößt der Absender nicht nur vollumfänglich gegen die Netiquette13
und handelt sich so schnell den Ruf eines DAU (DAU, dümmster anzunehmen-
der User) ein, sondern er liefert auch gleichzeitig E-Mail-Würmern Futter: Die
durchsuchen mittlerweile E-Mails auf infizierten Systemen nach Mailadressen
neuer Opfer.
Die Unterscheidung zwischen UBE und UCE ist notwendig, da Würmer beim
Sammeln von Adressen ihrer Opfer andere Verfahren verwenden. Daher sind
gegen Würmer die gängigen Anti-Spam-Verfahren machtlos – effektiver ist
der Einsatz eines Virenscanners auf dem Mailserver, der ähnlich wie z.B.
13. Siehe dazu: [FREY02] und [RFC1855]
No Spam! 23
2 – Was ist Spam?
ClamAVs Milter für Sendmail14 Viren und Würmer bereits im SMTP-Dialog

abblockt.
Zudem sollten Arbeitsplatzrechner durch Firewallsysteme und aktuelle Vi-
renscanner geschützt werden und Anwender im Umgang mit Viren geschult
sein. Gerade die Anwenderschulung ist vor dem Hintergrund der zunehmen-
den Verbreitung von Viren und Würmern mittels Trojaner, die einen Menschen
für ihre Ausführung brauchen, eine vielfach unterschätzte Sicherheitsmaßnah-
me, die großes Potenzial birgt.
Die folgenden Maßnahmen zielen einzig auf die Bekämpfung von „echtem“
Spam ab. Gegen UBE, insbesondere das von Würmern verursachte, sind sie
machtlos. Aber dagegen existieren ja bereits effektive Mittel.
14. ClamAV ist ein OpenSource-Virenscanner, den es auf http://www.clamav.org gibt, und
Sendmail ist der wohl am weitesten verbreitete Mailserver, zu finden unter http://www.send-
mail.org. Milter ist ein Kunstwort, das aus „Mail-Filter“ entstanden ist und eine Sendmail-
Schnittstelle zum Filtern von Mails beschreibt. Mehr dazu u.a. in [EGG05d]
24
3 Woher haben Spammer die
Mailadressen?
3.1 Freiwillige Eingabe

Spammer kennen im Wesentlichen zwei Methoden, um an die E-Mail-Adres-
sen ihrer Opfer zu gelangen: Entweder überzeugen sie ihre potenziellen Opfer,
ihre E-Mail-Adresse auf Webseiten, Papierformularen oder telefonisch frei-
willig zu verraten, meist unter Vorspiegelung eines Gewinnspiels oder eines
freien Zugangs zu meist zwie- bzw. rotlichtigen Seiten. Im Rahmen zweifel-
hafter AGB, häufig auch Teilnahmebedingungen genannt, holen sie sich vom
Opfer sogar noch die Erlaubnis, die so gewonnene E-Mail-Adresse auch an
Dritte weitergeben zu dürfen.
3.2 Adressen im Internet automatisch sammeln

Die alternative Methode setzt nicht auf Leichtgläubigkeit, sondern auf Suchro-
boter, und lässt sich damit vom Anwender selbst viel schlechter kontrollieren
als die freiwillige Weitergabe der E-Mail-Adresse.
3.2.1 Durchsuchen von Internetseiten

Es ist ohne Probleme und ohne großen Aufwand möglich, aus Internetseiten
automatisch E-Mail-Adressen herauszusuchen. Dafür ist (theoretisch) kein be-
sonderes Know-how, sondern lediglich ein leistungsstarker Rechner mit einem
breitbandigen Internetzugang notwendig. Die verbleibende Arbeit erledigen
Linux-Bordmittel oder einige wenige Zeilen in einer Script-Sprache wie
Perl15.
Es gibt auch zahlreiche fertige Programme für solche Zwecke, wie z.B. E-Mail
Hunter! oder Email Spider. Eine Zeit lang wurden diese Programme sogar für
T-Online-Kunden im Download-Bereich von T-Online zur Verfügung gestellt.
15. Hinweise zur Programmierung von Spidern und damit auch Harvestern liefert z.B.
[HEM03]
No Spam! 25
3 – Woher haben Spammer die Mailadressen?
Diese Sammelprogramme sind technisch eigentlich primitiv, denn man muss

nur einen kleinen Pseudo-Browser schreiben, der Internetseiten abruft und
nach allem sucht, was aussieht wie ein Link oder eine E-Mail-Adresse.
Links verfolgt das Programm, um möglichst viele Seiten im Internet zu errei-
chen. Durch gegenseitige Links zwischen Webseiten besteht die Gefahr, dass
eine Art Ring entsteht. Das Programm soll daher jede Seite nur genau einmal
aufsuchen, um sich nicht in einer Endlosschleife zu verheddern. Besuchte Sei-
ten müssen also protokolliert werden.
Die E-Mail-Adressen lassen sich sehr einfach über so genannte regular
expressions16 im HTML-Code finden und auslesen. Dabei können natürlich
E-Mail-Adressen auf verschiedenen Seiten genannt werden, so dass man
einige Doubletten hat. Um diese zu eliminieren, wandelt man sie mit dem
Unix-Befehl tr einheitlich in Kleinbuchstaben um, so dass beim anschließen-
den Sortieren mit dem Programm sort nicht unterschiedliche Groß- und Klein-
schreibung Verwirrung stiftet. Jetzt kann uniq Doubletten erkennen und ent-
sorgen. Das Ergebnis dieser Operationen schreibt man in eine Datei, die man
dann dem Mail-Programm als Eingabe liefert.
Für die Suche muss ein günstiger Einstiegspunkt gewählt werden. Webver-
zeichnisse wie Yahoo bieten sich an, da hier unzählige Links auf jede Menge
Seiten gelistet sind. Damit wird sehr schnell möglichst viel „Internet17“ abge-
grast: Die Zahl der gefundenen E-Mail-Adressen lässt sich so maximieren.
Um Ihnen einen Eindruck davon zu verschaffen, wie einfach dieses Verfahren
ist, gebe ich Ihnen zwei Linux-Befehlszeilen an, die eine solche Suche durch-
führen können.
wget --user-agent="Mozilla/4.0 (compatible; MSIE 5.01; Windows 98)"
-r --span-hosts -t1 --ignore-length --reject
gif,jpg,jpeg,png,mpg,mpeg,avi,zip,gz,tar,css,js
http://www.example.com [RET]
16. Eine Einführung in regular expressions, eine Methode zur Erkennung von bestimmten
Mustern in Zeichenketten, findet sich in [EGG05] oder auch [SEL02],[FRI02] oder
[STU03]. Das Konzept stammt aus der theoretischen Informatik, die mit regulären Aus-
drücken so genannte reguläre Sprachen konstruiert.
17. Ich verwende hier den Begriff „Internet“ und „World Wide Web (www)“ synonym: Das ist
zwar technisch nicht korrekt, entspricht aber dem Sprachgebrauch.
26
Adressen im Internet automatisch sammeln
grep -rhiE "mailto:" ./ | sed "s/.*mailto:$[A-Z0-9_-]\+\(\.[A-Z0-9_-

]*$*@$[A-Z0-9_-]\+\.$\+[A-Z]\{1,4\}\).*/\1/gi" | tr "[:upper:]"
"[:lower:]" | sort | uniq > emailadressen.txt [RET]
Dabei handelt es sich bei der vorgeschlagenen Lösung bewusst noch längst
nicht um eine Optimallösung: Zum einen werden alle Internetseiten vollstän-
dig auf der Platte zwischengespeichert und erst dieses Ergebnis wird anschlie-
ßend auf E-Mail-Adressen untersucht. Sie ahnen sicher, dass dies bei der Viel-
zahl von vorhandenen Seiten einen schier unendlichen Speicherplatzbedarf
bedeuten würde. Zum anderen überprüft das hier verwendete Programm wget,
ob eine Datei robots.txt existiert, mit der Webseiten-Programmierer solchen
automatischen Suchprogrammen den Zugriff auf bestimmte Seitenteile verbie-
ten können18.
Allerdings ist dies eine Konvention, die nur von anständigen Entwicklern ein-
gehalten wird, technisch jedoch problemlos zu umgehen ist und auch umgan-
gen wird. So kann beispielsweise wget über die Konfigurationsdatei .wgetrc
entsprechend konfiguriert werden, genauere Angaben enthalten die Info-Pages
von wget.
Die erste Befehlszeile startet also das Programm wget, das sich dabei als Inter-
net Explorer ausgeben soll, um in den Logfiles der Seitenbetreiber keine ver-
dächtigen Eintragungen zu hinterlassen. Die zusätzlichen Parameter bringen
wget dazu, ausschließlich HTML-Seiten herunterzuladen und Links auch über
unterschiedliche Server zu verfolgen.
wget hat den Vorteil, selbst in der Lage zu sein, Links in den Seiten zu extra-
hieren und zu verfolgen. Somit konnten wir uns hier Entwicklungsarbeit spa-
ren.
In der zweiten Befehlszeile werden die gespeicherten Seiten auf dem Rechner
nach E-Mail-Adressen durchsucht und diese extrahiert. Dies leistet der Befehl
grep in Zusammenarbeit mit sed. grep greift dabei alle Zeilen heraus, in denen
die Zeichenfolge „mailto:“ vorkommt. Diese markiert in einem HTML-Link
eine E-Mail-Adresse.
sed verwendet dann eine regular expression, mit der es aus dem HTML-Link
die E-Mail-Adresse extrahiert.
18. Eine genaue Beschreibung des Formats und Beispiele finden sich in [KOS94] und
[W3CAPPB]
No Spam! 27
Anschließend werden die E-Mail-Adressen mittels des Hilfsprogramms tr

vollständig in Kleinbuchstaben umgewandelt, alphabetisch sortiert (sort) und
dann von Doubletten mittels uniq befreit.
Das Ergebnis dieser Arbeit wird in die Datei emailadressen.txt geschrieben,
die problemlos von jedem anderen Programm genutzt werden kann.
Zwar ist die hier vorgestellte Lösung noch weit von einem Optimum entfernt,
insbesondere die aufwendige Zwischenspeicherung der Webseiten auf der
Platte ist ungünstig. Auch lassen sich unter Umständen E-Mail-Adressen, die
nicht in einer Zeile stehen, nicht fehlerfrei extrahieren und auch so genannte
Session-Ids würden von wget nicht korrekt erkannt und interpretiert, weshalb
noch Endlosschleifen entstehen könnten.
Allerdings ist es beeindruckend, dass man ohne eine einzige Zeile program-
mieren zu können, nur unter Verwendung von Unix-Bordmitteln, schon einen
Minimal-Harvester (harvester, engl. „Erntemaschine“) erstellen kann. Der Ein-
satz von Perl und des LWP-User-Agent führt ähnlich schnell zu Ergebnissen –
jedoch lassen sich dann durch eigene Programmierarbeit die Nachteile des ein-
fachen „wget-Harvesters“ beseitigen.
Alternativ kann man auch wget für diesen Zweck umprogrammieren, schließ-
lich ist es ein OpenSource-Programm, so dass der Quellcode vorliegt und sich
beliebig anpassen lässt.
Tatsächlich ist der Einsatz solcher Harvester derzeit das beliebteste Verfahren.
Der Aufwand ist bei richtiger Programmierung, die mittlerweile Spammern
auch schon abgenommen wird, weil entsprechende Software in großem Um-
fang im Internet angeboten wird, minimal. Zudem kommen, bei geeigneter
Wahl des Startpunkts der Suche, in kürzester Zeit Tausende von E-Mail-Adres-
sen heraus, wie ich durch eigene Tests19 gezeigt habe – und was Sie jederzeit
leicht durch Eingabe der Befehlszeilen oben verifizieren können.
3.2.2 Newsgroups und ähnliche Quellen

Beliebt sind ferner das automatische Durchkämmen von Mailinglisten-Archi-
ven, was häufig auf eine automatische Suche über Internetseiten hinausläuft,
und das Durchsuchen von Newsgroups, den schwarzen Brettern des Internets.
19. Siehe dazu: [CDT03], [EGG04], [EGG04a], [EGG05a], [EGG05b] und [EGG05c]
28
Vorteil ist, dass hier im Allgemeinen jeder Newsgroup-Post einen Treffer lie-
fert und häufig die Adressen valide sind und gelesen werden. Nachteilig dabei
ist, dass zumindest für die Suche in Newsgroups etwas mehr Aufwand notwen-
dig ist, den die meisten Spammer anscheinend scheuen. Allerdings wird dieser
Nachteil durch zahlreiche Webseiten, die Newsgroups in das WWW spiegeln
und somit in Form von Webseiten anbieten, schnell kompensiert. Der bekann-
teste Dienst für diesen Zweck dürfte Google Groups sein, der aus oben ge-
nanntem Grund mittlerweile E-Mail-Adressen in seinem News-Archiv ver-
kürzt und damit verfälscht darstellt.
Auch die Whois-Einträge zu Domainnamen werden von Spammern genutzt:
Dort muss eine gültige E-Mail-Adresse eingetragen sein, die automatisch aus-
gelesen werden kann. In einem Beitrag in der einschlägigen Newsgroup de.ad-
min.net-abuse.mail berichtete Can Filip Sakrak im Dezember 2004, dass auch
PGP-Key-Server20 nach E-Mail-Adressen abgesucht würden. Allerdings sind
diese beiden Methoden derzeit noch eher selten und auch kaum lohnend, da
zahlreiche Anwender dort nicht gelistet sind.
3.2.3 Erraten von Adressen

E-Mail-Adressen lassen sich auch erraten. So gibt es in den Requests for Com-
ments (RFC), die eine Art Internetnorm darstellen, eine Empfehlung, welche
Adressen unter jeder Domain vorhanden sein sollten. Dies sind, neben einigen
anderen, info, webmaster, hostmaster und postmaster, also Adressen, denen
bestimmte Funktionen in Zusammenhang mit Servern zugeordnet sind.
Hat man nun eine Liste von Domains, so kann man auf gut Glück versuchen,
an diese Adressen unter den jeweiligen Domains seinen Werbemüll zu versen-
den, und hat, sofern die Mailserver ordentlich konfiguriert sind, bereits eine
hohe Trefferquote.
Tatsächlich erhalte ich regelmäßig an solche Accounts – beliebt ist vor allem
webmaster und postmaster – Spam.
Allerdings wird diese Methode zunehmend unbeliebt, da diese Adressen häu-
fig fortgeschrittenen Anwendern oder gar Administratoren zugeordnet sind,
die sich massiv gegen Spam wehren und damit zu starke Gegner darstellen.
20. PGP dient zur asymmetrischen Verschlüsselung von E-Mails. Die öffentlichen Schlüssel
werden auf so genannten Key-Servern bereitgestellt. Siehe auch: [EGG04e] oder z.B.
[SCHWE02]
No Spam! 29
Ein anderes Verfahren, das sehr lange z.B. bei web.de funktionierte, war das
Erraten von E-Mail-Adressen. Da web.de einer der größten E-Mail-Anbieter in
Deutschland ist und die meisten Anwender Adressen der Form „vorna-
me.nachname@“ bzw. Variationen davon bevorzugen, lassen sich mit Hilfe ei-
nes Telefonbuchs schon eine Menge Adressen raten.
web.de unterstützte diese Methode versehentlich längere Zeit, da es beim
Empfang einer E-Mail schon beim Lesen des SMTP-Envelope21 überprüfte, ob
der Empfänger der Mail existiert, und eine entsprechende Positiv- oder Fehler-
meldung generierte. Dadurch ließen sich Adressen sehr schnell verifizieren.
Mittlerweile macht auch web.de das, was zahlreiche Mailserver schon lange
vorher taten: Sie nehmen die Mail zunächst anstandslos an, um später eine
Fehlermeldung zu generieren. Dieses Verfahren ist deshalb günstiger, weil die
Verifikation von Adressen so wesentlich mehr Aufwand bedeutet und zudem
nicht nur den Mail-Server auf Empfängerseite belastet, sondern auch den des
Absenders, der ja die eingehenden Fehlermeldungsmails verarbeiten muss –
sofern die Absenderadresse existiert und nicht gefälscht ist. Sonst entstehen
Schleifen von Fehlermeldungsmails oder es werden unbeteiligte Dritte mit
Fehlermeldungen regelrecht bombardiert.
Analog war früher auch das Erraten von E-Mail-Adressen bei AOL sehr ein-
fach: Es gab eine maximale Länge für den so genannten local part, also die
Zeichenfolge, die links vom @ steht. Aufgrund des begrenzten Zeichenvorrats,
der für den local part in Frage kommt, lassen sich allein durch Ausprobieren
ausreichend viele gültige Adressen finden.
Diesen Aufwand zu betreiben, waren Spammer auch nicht immer gewillt – so
kaufte ein Spammer einem mittlerweile ehemaligen AOL-Mitarbeiter für
50.000 US$ einfach ein Kundenverzeichnis mit E-Mail-Adressen ab.
Ebenso war es eine Zeit lang möglich, T-Online-Adressen zu erraten: Jeder
Nutzer hatte eine aus seiner Telefonnummer inklusive Vorwahl und einer zu-
sätzlichen eindeutigen Zahlenfolge bestehende E-Mail-Adresse. Die Telefon-
nummern lassen sich wiederum automatisch aus dem Telefonbuch generieren
– das gibt es zweckmäßiger Weise auf CD-ROM oder online, jeweils mit der
Möglichkeit, die Zielgruppe sogar räumlich einzugrenzen.
21. Ein virtueller Briefumschlag einer E-Mail, den Mailserver generieren und auch wieder ent-
fernen. In Ihrem Mailprogramm bekommen Sie ihn nie zu Gesicht.
30
Aus diesen Darstellung lässt sich folgern, dass die Wahl eines kleineren Pro-
viders unter Umständen günstiger sein kann. Zudem sollte die E-Mail-Adresse
nicht allzu leicht zu erraten sein – was die Nutzbarkeit für den Besitzer der
Adresse wiederum einschränkt: Eine beliebige Zeichenfolge mit Sonderzei-
chen lässt sich nun mal schwer kommunizieren und an Dritte weitergeben.
3.2.4 Adresshandel
Ein weiteres Standbein für Spammer, vor allem für die, die nicht einmal in der
Lage sind, die eben geschilderten einfachen Such- und Ratemethoden zu nut-
zen, liefert der Adresshandel: Dritte generieren nach den oben beschriebenen
Verfahren E-Mail-Adressen und verkaufen sie dann an neue Spammer. Häufig
werden diese Adresslisten wiederum durch Spam beworben – also Spam für
Spam, eine Art Meta-Spam.
Ein Beispiel für so eine Meta-Spam-Mail zeigt Abbildung 3.1.
Abb. 3.1: Meta-Spam: Diese Mail wirbt Spammer-Nachwuchs
No Spam! 31
Teilweise bleiben solche Adresslisten mehrere Jahre im „Handel“: Dadurch

können plötzlich neu eingerichtete, aber noch nicht publizierte E-Mail-Adres-
sen Opfer von Spam werden, nur weil diese Adresse bereits vor einiger Zeit
von jemand anderem genutzt wurde.
Solche Listen findet man immer wieder auch z.B. bei eBay im Angebot. Die
Preise beginnen bei einigen wenigen Euro für einige Millionen Adressen.
32
4 Grundlegende
Vorsichtsmaßnahmen
Ziel ist das Entwickeln von Methoden, mit deren Hilfe sich Spam möglichst
frühzeitig vermeiden lässt. Bereits einige einfache Grundregeln können dazu
einen wertvollen Beitrag leisten.
4.1 Umgang mit Mailadressen

Eine hohe Spam-Vermeidungsquote erreicht man bereits, indem man kritisch
überprüft, wem man wann seine Mailadresse mitteilt: So ist es in aller Regel
nicht empfehlenswert, auf Webseiten z.B. in Gästebüchern oder Foren die ei-
gene Mailadresse anzugeben. Genauso wenig sollte die Mailadresse auf Post-
karten für Gewinnspiele oder auf Messeständen eingetragen werden. Häufig
stellt die anschließend erhaltene Werbung zwar subjektiv Spam dar, objektiv
juristisch gesehen ist sie jedoch mit Einwilligung des Empfängers zugesandt
und damit eben gerade kein Spam mehr.
Auch mit den Mailadressen Dritter sollte sorgfältig umgegangen werden: E-
Mails an mehrere Personen sollten – außer die Empfänger kennen sich alle gut
untereinander – nicht über das To:-Feld, sondern über das Bcc:-Feld versandt
werden. Bcc steht für „Blind Carbon Copy“. Die im Bcc:-Feld angegebenen
Empfänger erhalten die Nachricht, jedoch erfahren die anderen Adressaten
nichts von diesen Empfängern. Die Adressen sind also für alle anderen un-
sichtbar.
Das hat zwei Vorteile: Zum einen können Würmer, die vermehrt zum Spam-
Versand eingesetzt werden, diese Adressen auch nicht erkennen – sie finden
also weniger Opfer. Zum anderen kann der Empfänger nicht aus Versehen eine
Antwort an alle senden. Das wäre dann zwar formal kein Spam, ist aber fast
genauso lästig.
Als Nebeneffekt können Dritte nicht „versehentlich“ eine Adresse an Spam-
mer weitergeben: Sie kennen sie ja gar nicht.
No Spam! 33
4 – Grundlegende Vorsichtsmaßnahmen
4.2 Wegwerfadressen
Sollten Sie tatsächlich einmal an einem Gewinnspiel teilnehmen wollen oder
es aus sonstigem Grund für nötig halten, eine E-Mail-Adresse anzugeben,
empfiehlt sich der Einsatz von Wegwerfadressen.
Es gibt Anbieter, bei denen man E-Mail-Adressen generieren kann, die nur für
eine bestimmte Zeit gültig sind. Das ist vorteilhaft, wenn Sie sicher wissen,
wann die Antwort eintreffen wird.
Einen solchen Dienst bietet Spamhole unter http://www.spamhole.com an. Je-
doch muss man sich dort für jede neu zu erzeugende E-Mail-Adresse erneut
einloggen, was die Nutzung etwas umständlich macht.
Die Alternative sind E-Mail-Adressen, die bei Bedarf vom Mailserver des
Providers automatisch erzeugt werden: MyTrashMail (http://www.mytrash-
mail.com) und dodgeit (http://www.dodgeit.com) erlauben es, eine E-Mail an
einen beliebigen Local-Part22 unter den jeweiligen Domains zu schicken. Die
empfangenen E-Mails können dann über eine Weboberfläche abgerufen wer-
den. Dazu muss kein Passwort angegeben werden, auch muss diese E-Mail-
Adresse nicht vorher auf der Webseite eingetragen werden.
Zum „Login“ reicht es aus, den richtigen Local-Part anzugeben. Das ermög-
licht es auch Dritten, E-Mails zu lesen, indem sie den Local-Part erraten. Beim
Testen der verschiedenen Angebote konnte ich so mit „someone“ als Local-
Part interessante (?) Nachrichten lesen.
Immerhin können E-Mails bei MyTrashMail gelöscht werden – bei dodgeit
nicht, was im Allgemeinen nicht tolerabel sein dürfte. Zudem hat während
meiner Tests dodgeit einige E-Mails nicht angenommen, was gegen eine prak-
tische Nutzung spricht.
MyTrashMail bietet zudem die Möglichkeit, Antwortmails direkt über die
Weboberfläche zu senden. Damit bietet MyTrashMail zusammen mit einem
Anonymisierdienst wie z.B. dem Java Anonymous Proxy der TU-Dresden
(http://anon.inf.tu-dresden.de) eine einfache Möglichkeit, anonym zu mailen.
Eine andere Lösung, zeitlich unbegrenzt gültige, aber mengenmäßig limitier-
bare Accounts zu erzeugen, bietet Spamgourmet (http://www.spamgour-
met.com). Dabei werden die von Spamgourmet empfangenen Nachrichten für
22. Der Teil der Mailadresse vor dem „@“-Symbol
34
Wegwerfadressen
den Absender unsichtbar und vor allem unbemerkt an die eigene E-Mail-
Adresse weitergeleitet.
In diesem Zusammenhang kann man für jede Spamgourmet-E-Mail-Adresse
unter dem eigenen Benutzernamen einstellen, wie viele E-Mails weitergeleitet
werden sollen. Treffen danach noch E-Mails ein, werden sie automatisch von
Spamgourmet gelöscht.
Das Praktische an diesem Dienst ist, dass Spamgourmet-Adressen jederzeit
und ohne die Webseite des Dienstes besuchen zu müssen, generiert werden
können. Damit ist die Funktionalität vergleichbar mit der Lösung von My-
TrashMail, sie bietet jedoch den Vorteil, E-Mails per SMTP weiter an ein de-
finiertes Postfach zuzustellen, und ist damit für Dritte nicht so einfach einzu-
sehen.
In einer erweiterten Konfiguration kann man sogar einrichten, dass Antworten,
die vom eigenen, regulären Mailaccount aus gesendet werden, getarnt werden
und als Absender die für diese Kommunikation gewählte Spamgourmet-
Adresse verwendet wird. Allerdings übernimmt Spamgourmet keine Anony-
misierung – aus dem Header einer Antwortmail ist der Absender unter Um-
ständen noch ersichtlich. Dieses Problem lässt sich aber mit einem E-Mail-
Anonymisierdienst23 bei Bedarf beheben.
Die Weboberfläche von Spamgourmet bietet zusätzliche Optionen an. So ist es
beispielsweise möglich, Absender einzurichten, die bei der Zählung der
E-Mail-Anzahl nicht berücksichtigt werden. Außerdem lässt sich nachträglich
die Zahl der zulässigen Mails verändern.
Zusätzliche Optionen ermöglichen es auch paranoiden Nutzern, mit diesem
Dienst glücklich zu werden: So kann man das Muster der E-Mail-Adressen be-
einflussen, ein Raten durch einen Spammer wird somit unmöglich gemacht
oder deutlich erschwert.
Im Vergleich zu dodgeit und MyTrashMail bietet Spamgourmet den Vorteil,
die E-Mails für Dritte nicht so einfach zugänglich zu machen. Außerdem las-
sen sich bei Spamgourmet die benötigten Adressen on-the-fly generieren, die
empfangenen E-Mails werden an das reguläre Postfach weitergeleitet. Ein Be-
such auf einer Webseite entfällt im Gegensatz zu Spamhole.
23. Diese Dienste nennt man anonymous remailer und lassen sich, sucht man nach diesem
Begriff bei Google, in großer Menge finden. Siehe dazu auch: [EGG05h]
No Spam! 35
4.3 Newsletter und Ähnliches

Spamgourmet kann auch für Newsletter eingesetzt werden, indem bestimmte
Absender auf eine White-List gesetzt werden und somit von der Zählung aus-
genommen sind.
Allgemein sollten für Newsletter-Abos oder Bestellungen bei Unternehmen
besondere, eigene Mailadressen verwendet werden. Dadurch lässt sich die pri-
vate Post von solchen Nachrichten trennen und sehr einfach, ohne den Bekann-
tenkreis mit einer neuen Adresse belästigen zu müssen, die für Newsletter ein-
gesetzte Adresse deaktivieren.
Häufig wird vorgeschlagen – sofern man über einen eigenen Mailserver ver-
fügt –, für jedes Unternehmen eine eigene Adresse zu verwenden. Damit lie-
ßen sich Weiterverkäufer von Adressen leicht identifizieren und man kann die
Adresse bei Missbrauch individuell sperren.
Geht man davon aus, dass wesentlich häufiger Adressen neu angelegt werden,
als welche blockiert werden müssen, so lässt sich diese Lösung nur sinnvoll
mit einem Mailserver realisieren, der über eine so genannte Catch-All-Funkti-
on verfügt. Dabei wird zunächst geprüft, ob die Empfängeradresse eigens de-
finiert wurde. Ist das nicht der Fall, wird sie an eine definierte Adresse weiter-
geleitet.
In sendmail24 lässt sich das in der virtusertable leicht einstellen. So leitet
@mail.example.com %1@example.com
alle Mails, die unter der Domain mail.example.com eingehen, mit unveränder-
tem Local-Part an die Domain example.com weiter. Aus user@mail.examp-
le.com wird damit user@example.com.
Einen „wahren“ Catch-All erzeugt die folgende Zeile:
@example.com catchall
Damit werden alle Mails, die an eine beliebige, nicht anderweitig in der virt-
usertable definierte Adresse unter der Domain example.com gehen, an den
lokalen Benutzer „catchall“ weitergeleitet.
24. Ausführlichere Informationen zu Sendmail und dessen Konfiguration liefert [COS97]
36
Keinesfalls: gefälschte Absenderadressen
Mit dieser Konfiguration lassen sich neue E-Mail-Adressen bei Bedarf wie bei
Spamgourmet schnell anlegen, insbesondere ist eine Bearbeitung der virtuser-
table nicht notwendig.
Allerdings muss zum Blockieren von Adressen die virtusertable bearbeitet
werden:
dontbugme@example.com error:nouser User unkown
Dadurch werden E-Mails an die Adresse dontbugme@example.com schon im
SMTP-Dialog mit der Fehlermeldung „User unkown“ und dem entsprechen-
den SMTP-Fehlercode geblockt. Damit werden sie gar nicht mehr angenom-
men.
Ähnliche Konfigurationsmöglichkeiten bietet auch das für seine Sicherheit
und Stabilität bekannte Mailserver-Programm qmail, erhältlich unter http://
www.qmail.org. Auf der qmail-Webseite findet sich eine an sich ausreichende
Dokumentation. Wer gedruckte Unterlagen bevorzugt, sollte einen Blick in
[SIL01] oder [MAT97], [BER03] und [BER03a] werfen. Analog gilt das für
den sehr bekannten Mailtransferagenten Postfix, für den [HEIN04] wohl das
Standardwerk schlechthin sein dürfte.
Der Einsatz von Wegwerfadressen hilft somit, dem Adresshandel vorzubeugen
und Adresshändler zu identifizieren. Ob jedoch die Aussage, man habe die
Adresse xy@example.com ausschließlich an das Unternehmen XY kommuni-
ziert und somit sei dieses Unternehmen für den Weiterverkauf der Adresse ver-
antwortlich, vor Gericht einen ausreichenden Beweis darstellt, steht auf einem
anderen Blatt. Die einfache Sperrmöglichkeit und die Option, „Gute“ von „Bö-
sen“ zumindest für den eigenen Bedarf zu trennen, sind jedenfalls Pluspunkte
dieses Verfahrens.
Der Einsatz externer Anbieter wie Spamgourmet verringert den eigenen Kon-
figurationsaufwand und spart eigenen Netzverkehr.
4.4 Keinesfalls: gefälschte Absenderadressen

Für die Verwendung in Newsgroups oder in den immer beliebter werdenden
Internetdiskussionsforen wird häufig vorgeschlagen, gefälschte Absender-
adressen zu verwenden. Zwar verhindert das nachhaltig Spam beim Verwender
der Adresse, es kann aber leicht einen unbeteiligten Dritten zum Opfer ma-
chen. Entweder, weil dieser zufällig die (vermeintlich nicht existente) Adresse
No Spam! 37
tatsächlich besitzt, oder aber, weil er als gefälschter Absender für den Spam
herhalten musste und daher mit Fehlermeldungen überschüttet wird.
Gerade das Problem, eine Adresse zu besitzen, von der keiner ihre Existenz an-
nimmt, kenne ich aus eigener Erfahrung: Ich hatte jahrelang die E-Mail-Adres-
se no_spam@iname.com und nospam@acme.com. Iname ist ein Webmail-An-
bieter, der ähnlich wie GMX oder web.de funktioniert und vor allem auf dem
nordamerikanischen Kontinent entsprechend verbreitet ist. ACME kennen si-
cherlich alle Tom & Jerry-Freunde unter Ihnen – und auch viele andere: In fast
allen Zeichentrickserien steht ACME zur Vermeidung von Schleichwerbung
als Firmenname auf verschiedensten Produkten. Die meisten behaupten, es sei
ein Akronym für „A Company that Manufactures Everything“. Die Adresse
nospam@acme.com riecht also auch nach Fälschung. Leider stellten beide An-
bieter ihre Dienste in der ursprünglichen Form ein, so dass Sie mich nicht mehr
unter diesen schönen Adressen erreichen können.
Im worst case könnten, wenn die gefälschte Absenderadresse auch nicht exis-
tiert, Schleifen zwischen den zwei Mailservern, die gegenseitig immer wieder
versuchen, eine (Fehlermeldungs-)Mail zuzustellen, entstehen, was unnötige
Netzlast zur Folge hat.
Wegen dieser unschönen Nebeneffekte ist der Einsatz von gefälschten Adres-
sen nicht zu empfehlen – der gleiche Effekt lässt sich über Wegwerfadressen
genauso erreichen.
Alternativ sind lediglich noch nach /dev/null „geerdete“ Adressen sinnvoll.
Dabei wird automatisch jede an diese Adresse eingehende Mail in den unend-
lich großen virtuellen Papierkorb /dev/null weitergeleitet und somit – ohne
hässliche Fehlermeldungen – entsorgt.
4.5 Webtelefonbücher
Im Internet gibt es diverse „E-Mail-Telefonbücher“, „Personensuchdienste“
und Ähnliches. Zwar können diese Dienste bei der Suche nach einer Person
durchaus nützlich sein, aber sie stellen gleichzeitig eine Fundgrube für Spam-
mer dar.
Daher ist es nicht empfehlenswert, sich auf einer solchen Seite einzutragen.
Möchte man wirklich unter seinem Namen im Internet auffindbar sein, scheint
es zweckmäßiger, eine im Sinne von Suchmaschinen sinnvoll gestaltete Ho-
38
Spammer beim Sammeln identifizieren
mepage zu betreiben, über die man für Menschen, nicht jedoch für Spammer
auffindbar ist.
4.6 Spammer beim Sammeln identifizieren

Da Spam fast ausschließlich aus dem Ausland versandt wird, aber häufig ge-
nug inländische, dubiose Unternehmen bewirbt, liegt es aus präventiver Sicht
nahe, den inländischen Hintermännern das Handwerk zu legen.
Jedoch müssen diese dazu zunächst identifiziert werden können. Das lässt sich
sehr einfach über die von ihnen verwendeten Harvester realisieren: Präsentiert
man jedem Besucher einer Webseite eine eigens für diesen Besucher generier-
te E-Mail-Adresse, dann sammelt jeder Harvester auch diese individuelle
Adresse.
Es muss dabei sichergestellt sein, dass eine solche E-Mail-Adresse eindeutig
ist und eineindeutig der IP-Adresse des Harvesters und seinem exakten Be-
suchszeitpunkt zugeordnet werden kann. Denn dann lässt sich der Rechner,
von dem aus gesammelt wurde, zweifelsfrei identifizieren.
Dabei besteht im Zweifel gegen den Provider des Spammers nach §13a Unter-
lassungsklagengesetz (UklaG) ein Herausgabeanspruch bezüglich der Daten
des Spammers, sollte eine einfache Whois-Anfrage nicht bereits die notwen-
digen Informationen liefern.
Damit kann gegen die deutschen Hintermänner vorgegangen werden und diese
gerichtlich auf Unterlassung in Anspruch genommen werden, wodurch sich
die Zahl der potenziellen Spammer um einen reduziert.
[REHWWW] stellt die Idee und die benötigte Software vor. [REHWWW] be-
richtet auch von einem konkreten Fall, bei dem deutsche Hintermänner von
Spam ausgemacht werden konnten. Leider wurde in diesem Fall bislang noch
keine Klage erhoben, so dass keine Gerichtsentscheidung dazu vorliegt.
4.7 SMTP-Teergruben
[REHWWWa] und [DON04a] möchten Spammern zusätzlich gezielt präpa-
rierte Mailadressen anbieten, für die ein besonders konfigurierter, sehr langsa-
mer Mailserver zuständig ist. Durch die besonders langsamen Antworten des
Mailservers soll der Mailversand des Spammers insgesamt ausgebremst wer-
den.
No Spam! 39
Ich halte das Verfahren allerdings nur für eingeschränkt wirkungsvoll, da es ei-
ner sehr weiten Verbreitung bedarf, um seine Wirkung entfalten zu können.
Das liegt daran, dass ein Spammer üblicherweise zum Mailserver des Empfän-
gers eine Verbindung aufbaut, über die er beliebig viele Mails für diesen Mail-
server einliefern kann. Hat also ein Spammer z.B. 100 Mailadressen unter ei-
ner Domain eingesammelt, dann kann er Mails an alle diese Mailadressen in
einer einzigen Verbindung mit dem Mailserver einliefern. Da die Bremsfunk-
tion nur die bestehende Verbindung betrifft, wird der Versand an andere Mail-
server nicht behindert, denn der erfolgt typisch parallel: Jeder Rechner ist the-
oretisch in der Lage, ca. 64.000 parallele Verbindungen zu verschiedenen
Servern zu unterhalten.
Damit müsste ein großer Anteil aller Mailserver mit solchen Teergruben aus-
gerüstet werden, um wirklich effektiven Schaden bei Spammern hervorzuru-
fen. Andererseits liegen mir aber auch E-Mails von Anwendern solcher Ver-
fahren vor, in denen sie für deren Einsatz von Spammern wüst beschimpft und
bedroht wurden.
Technisch gesehen wird bei solchen Teergruben der SMTP-Dialog künstlich
maximal verzögert, um den ausliefernden Mailserver, der vermutlich einem
Spammer zuzuordnen ist, auszubremsen. Sind ausreichend viele solcher Teer-
gruben im Einsatz, hofft man, damit den Spammer tatsächlich lahm zu legen
und ihn so an der Aussendung weiteren Werbemülls zu hindern.
Die Blockade entsteht, weil die Zahl der maximal gleichzeitig bestehenden
Verbindungen zum Versand von E-Mails nach oben limitiert ist. Durch die
massive Verzögerung der Kommunikation zwischen Client und Server werden
diese Verbindungen besonders lange offen gehalten. In je mehr Teergruben der
Spammer fällt, desto mehr Verbindungen werden so blockiert. Dadurch sinkt
die Versandgeschwindigkeit des Spammers erheblich.
In der Theorie kann man durch solche Teergruben Server von Spammern völ-
lig ausbremsen und damit verhindern, dass sie Spam ausliefern – oder zumin-
dest die Auslieferung so massiv verzögern, dass sie für den Spammer unerträg-
lich lange dauert.
In der Praxis hat das Verfahren jedoch einen wesentlichen Nachteil: Eigentlich
jeder SMTP-Client ist in der Lage, einem SMTP-Server in einer Verbindung
alle Mails für diesen Server zu übermitteln. Er muss dazu nicht mehrere paral-
lele Verbindungen zu diesem Server aufbauen. Da die Teergrube nur genau
eine Verbindung lahm legt, der Spammer aber potenziell mehrere tausend Ver-
40
Rechtsweg
bindungen parallel halten kann, ist der Effekt in der Praxis im Allgemeinen
sehr klein, es sei denn, der Spammer tappt durch Zufall auf einen Schlag in
zahlreiche Teergruben.
Da die Verbreitung solcher Teergruben eher gering sein dürfte, sinkt die Wahr-
scheinlichkeit für den gewünschten Blockadeeffekt leider deutlich.
Zudem muss der Betreiber einer Teergrube sicherstellen, dass er nicht verse-
hentlich mit seinem System „anständige“ Server blockiert. Das wird in aller
Regel dadurch erreicht, dass die Teergruben nur für bestimmte (Sub-)Domains
eingerichtet werden, für die die E-Mail-Adressen ausschließlich auf speziellen
Harvester-optimierten Webseiten kommuniziert werden.
Damit ist der Aufwand für den Betrieb einer Teergrube relativ hoch, was sich
wiederum negativ auf deren Verbreitung auswirkt – und damit auf den Blockade-
effekt.
4.8 Rechtsweg
Die langfristig wirkungsvollste, präventive Anti-Spam-Maßnahme dürfte je-
doch immer noch der Rechtsweg sein: Ist ein Spammer erst mit Ordnungsgel-
dern von bis zu 250.000 € oder bis zu sechs Monaten Ordnungshaft bedroht
und drohen ihm zusätzlich hohe Gerichtskosten, dann schwindet der Vorteil
des Spamming, mit minimalen Kosten eine große Adressatengruppe zu errei-
chen.
Schließlich ist Spamming für den Absender wirtschaftlich interessant: Spam-
mer können immer noch darauf vertrauen, dass ein kleiner Bruchteil der Emp-
fänger tatsächlich die beworbene Dienstleistung gegen Entgelt erwirbt oder er-
werben will, denn wer weiß schon, ob jemand, der seine per Spam beworbenen
Waren über gehackte Server verkauft und damit schon erhebliche kriminelle
Energie beweist, nicht zufällig auch noch die Lieferung vergisst.
Solange die Kosten für den Versand des Spam geringer sind als der zu erwar-
tende Gewinn, rechnet sich diese Werbeform. Durch Ordnungsgelder und -haft
sowie Gerichtskosten sinkt die Gewinnspanne.
Einige Autoren25 sehen zusätzlich bereits nach geltendem Recht auch eine
Strafbarkeit des Spamming an sich – unabhängig von eventuellen Straftaten
25. So allen voran die Dissertation [FRA04a], zusammengefasst in [FRA04].
No Spam! 41
oder Ordnungswidrigkeiten z.B. wegen versuchten Betrugs oder Verstoß ge-

gen das Arznei- und Betäubungsmittelrecht, die der Spammer durch sein An-
gebot verwirklicht. Das erhöht das „unternehmerische“ Risiko nochmals – zu-
mindest für in Deutschland ansässige Spammer.
Eine aktuelle Gesetzesinitiative26 möchte im Teledienstegesetz (TDG) das Fäl-
schen von Header-Daten in E-Mails, das Spammer routinemäßig machen, um
ihre Identität zu verschleiern, unter Strafe stellen. Kritiker befürchten jedoch,
dass dadurch Spam mit korrekten Header-Daten indirekt für zulässig erklärt
wird, und verweisen auf die Strafbarkeit der Verfälschung beweiserheblicher
Daten, die das Fälschen von Header-Daten bereits unter Strafe stellt.
In die wirtschaftliche Richtung gehen zwar auch Vorschläge, den E-Mail-Ver-
sand selbst kostenpflichtig zu machen. Dies würde allerdings zum einen den
großen Vorteil der E-Mail-Kommunikation zunichte machen und zum anderen
sind diese Vorschläge durch die weit verteilte Infrastruktur des Internets prak-
tisch nicht realisierbar. Insbesondere, wenn man bedenkt, dass trotz „Ächtung“
von so genannten Open Relays immer noch zahlreiche27 als Open Relay kon-
figurierte Mailserver in Betrieb sind. Zudem ist die Zahlungsbereitschaft im
Internet nicht sonderlich groß, so dass hier zusätzliche Widerstände bei der
Einführung zu befürchten sind. Schon die von zahlreichen erfahrenen Net-Ci-
tizens befürwortete Abschaffung von Open Relays hat sich trotz des geringen
zusätzlichen Konfigurationsaufwands noch nicht weltweit durchgesetzt.
26. Stand: 03/2005

27. Hinweise über deren Menge liefern die Open Relay Black Lists, z.B. http://www.ordb.org.
42
5 E-Mail-Adressen von Webseiten
verbannen
Homepages lassen sich grob einteilen in „geschäftliche“ und in private Seiten.

Zu Ersteren zählen alle Seiten, die in irgendeiner Hinsicht das Ziel haben, Ein-
nahmen zu generieren: sei es als Informationsquelle über Produkte und die
daraus resultierenden Einkäufe, sei es durch direkten Verkauf von der Home-
page, durch Bannerwerbung oder auch nur durch Links auf ein provisionsori-
entiertes Buch-Partnerprogramm, wie z.B. bei Amazon oder Libri. Wobei im
Fall des provisionsorientierten Partnerprogramms in der rechtswissenschaftli-
chen Diskussion die Gewerbsmäßigkeit umstritten ist.
Eindeutig private Seiten verfolgen keine solche Ziele, sondern bestehen im
Endeffekt „nur“ zum Spaß und Zeitvertreib des Seitenbetreibers.
Für gewerbsmäßig betriebene Internetseiten schreibt §6 Nr. 2 TDG vor, dass
auf der Seite „Angaben, die eine schnelle elektronische Kontaktaufnahme und
unmittelbare Kommunikation mit“ dem Anbieter „ermöglichen, einschließlich
der Adresse der elektronischen Post“ enthalten sein müssen.
Dabei ist der Begriff der Gewerbsmäßigkeit sehr unscharf, da er im Gesetz
nicht definiert ist, was kurz nach Einführung des Gesetzes zu Abmahnwellen
wegen fehlerhaften oder nicht vorhandenen „Impressen“ führte.
Doch auch private Anbieter von Homepages sehen ihre Seiten nur selten als
reinen Selbstzweck, sondern wollen in aller Regel auch Kontaktmöglichkeiten
angeben, um mit den Besuchern der Seite in Diskussion treten zu können.
In allen Fällen ist es daher praktisch notwendig und sinnvoll, auf der Home-
page eine Möglichkeit zur „schnellen, elektronischen Kontaktaufnahme“ vor-
zusehen. Häufig wird darunter eine E-Mail-Adresse verstanden.
Einige wenige Betreiber von Webseiten nennen statt einer E-Mail-Adresse
eine Handynummer und argumentieren, man würde darüber per SMS auch
schnell und elektronisch kommunizieren können. Ob das tatsächlich so zu se-
hen ist, ist bislang von der Rechtsprechung noch nicht entschieden worden.
Stellt man sich auf den Standpunkt, dass eine schnelle elektronische Kommu-
nikation per E-Mail erfolgen kann, dann erfolgt sie sicherlich auch per SMS.
Doch beide Kommunikationswege stellen de facto keinerlei Zustellzeiten si-
No Spam! 43
5 – E-Mail-Adressen von Webseiten verbannen
cher. Insbesondere ergeben sich aus einer E-Mail-Adresse auch keine Ant-
wortzeiten. Schnelligkeit ist also bei E-Mail sicher nicht gewährleistet.
Sieht man aber den Begriff der Schnelligkeit eher weit, wie es die Interpreta-
tion „E-Mail“ suggeriert, dann müsste sich auch der Begriff „elektronisch“
weit auslegen lassen. Damit wäre auch eine Telefonnummer eine Möglichkeit
der schnellen, elektronischen Kontaktaufnahme.
Zudem stellt das Telefon – anders als die E-Mail – die zeitlich unmittelbare
Kommunikation eher sicher, sofern kein Anrufbeantworter oder Sprachcom-
puter den Anruf entgegennimmt. Tatsächlich wird von vielen Autoren sogar –
unter anderem in Hinblick auf die Entstehung des Gesetzes – angenommen,
dass mit der Möglichkeit der schnellen, elektronischen Kontaktaufnahme min-
destens eine Telefonnummer gemeint sei und eben keine E-Mail-Adresse.
Diese Auffassung stützt beispielsweise [GRAV03] und folgert das vor allem
aus der Bundestagsdrucksache 14/6098, die das Telefon explizit als Mittel der
schnellen elektronischen Kontaktaufnahme nennt.
Die Aufforderung jedoch, eine Adresse der elektronischen Post anzugeben, ist
(fast) eindeutig: Damit kann der Gesetzgeber eigentlich nur eine E-Mail-
Adresse gemeint haben, wenn auch die Übersetzung in die Gerichtssprache
Deutsch eher krampfhaft wirkt.
Somit kommt der gewerbsmäßige Homepage-Betreiber um die Angabe einer
E-Mail-Adresse wohl nicht herum, die gelegentlich praktizierte Angabe einer
Handynummer und der Verweis auf SMS erscheinen auf den ersten Blick un-
geeignet.
Andererseits könnte man auch eine Faxnummer als eine Adresse der elektro-
nischen Post ansehen: Das Telefax überträgt Schriftstücke auf elektronischem
Weg und ermöglicht damit einen elektronischen Postversand. Die Faxnummer
ist dabei zur Adressierung notwendig und somit eine Adresse der elektroni-
schen Post. Mit gleicher Argumentation wäre dann auch die SMS elektroni-
sche Post.
Auch die URL eines Kontaktformulars könnte die Adresse der elektronischen
Post darstellen, schließlich lassen sich darüber unmittelbar E-Mails, die ein-
deutig zur elektronischen Post zu zählen sind, versenden.
Allerdings ist auch über diese Spitzfindigkeit bislang von den Gerichten noch
nicht entschieden worden. Will man also auf der sicheren Seite sein und poten-
44
Adressen fälschen
ziell teuren Rechtsstreitigkeiten aus dem Weg gehen, bleibt einem nicht viel
anderes übrig, als eine E-Mail-Adresse im „Impressum“ zu nennen.
Zum Glück fordert das Gesetz nur die „Angabe“ der Adresse. Eine Verlinkung
derart, dass die E-Mail-Adresse in ein E-Mail-Programm übernommen wird,
ist noch nicht notwendig, was auch in Hinblick auf die folgenden Lösungsvor-
schläge günstig ist: Viele von ihnen würden nicht mehr funktionieren, müsste
die Adresse zwangsweise verlinkt werden.
Dabei zeigt sich wieder ein interessanter Denkansatz der Gesetzgeber: Wenn
das Sammeln von Adressen verboten ist und auch der Versand von Spam nicht
erlaubt ist, dann kann beides nicht stattfinden. Das ähnelt Christian Morgen-
sterns Palmström in „Die unmögliche Tatsache“ ([MOR04]), der feststellt,
dass „nicht sein kann, was nicht sein darf“.
5.1 Adressen fälschen

Um der Pflicht oder dem Wunsch nach Angabe einer E-Mail-Adresse nach-
zukommen, ohne jedoch bespammt zu werden, wird häufig zur Irreführung
der Adressjäger eine verfälschte E-Mail-Adresse angegeben: Dabei wird die
E-Mail-Adresse mit Zusätzen nach dem Muster „REMOVE_TO_MAIL_ME“
versehen. Nicht immer jedoch sind diese Zusätze eindeutig und zweifelsfrei zu
erkennen oder zu entfernen. Dann besteht die Gefahr, dass eine falsche E-Mail-
Adresse generiert wird.
Aber selbst, wenn die Zusätze erkennbar sind, kommt es immer wieder vor,
dass versehentlich zuerst an die verfälschte Adresse gemailt wird. Die darauf-
hin zurückkommende Fehlermeldung, so die Verfechter dieser Methode, wür-
de dem Absender schon zu erkennen geben, wie die Adresse korrigiert werden
müsse.
Allerdings entspricht bereits die Annahme nicht der Realität – ein Großteil der
Anwender ignoriert Fehlermeldungen schlicht und macht sich nicht die Mühe,
deren, häufig englischsprachigen, Inhalt zu verstehen. Immer wieder wird von
Anwendern sogar eine generelle Unlust angemeldet, sich mit diesem „Com-
puterzeug“ überhaupt zu befassen, schließlich handle es sich dabei um ein
Werkzeug. Eine Haltung, die für mich nicht nachvollziehbar ist, denn auch der
Umgang mit dem Werkzeug „Auto“ oder „Kettensäge“ erfordert eine Ausein-
andersetzung mit dem Gerät und den zugehörigen Regeln.
No Spam! 45
Allerdings muss man zugestehen, dass die Fehlermeldung nicht sonderlich

aufschlussreich sein kann, denn sie beschreibt ein aus der verfälschten Adresse
resultierendes Problem: beispielsweise, dass der Name des Mailservers nicht
aufgelöst werden konnte, also z.B. „DNS not found“, oder aber, dass der Nut-
zer nicht existiert, z.B. „User unkown“. Beide Fehlermeldungen sind für den
Laien nicht verständlich und weisen auch nicht auf die wahre Fehlerursache
hin – wie sollten sie auch.
Typischerweise enthalten solche Meldungen noch weitere „Diagnostic Infor-
mations“, die für Fachleute verständlich sind, für den Laien aber die wahre
Fehlermeldung so effektiv verbergen, dass sie der Endanwender in einem IT-
englischen Zeichensalat kaum mehr finden kann.
Auf diese Art und Weise werden zahllose Endanwender ausgeschlossen, was
im Allgemeinen nicht im Sinne einer Homepage sein dürfte. Zudem sind sol-
che Fälschungen, wie in Kapitel 4.4 diskutiert, technisch zweifelhaft und ber-
gen zahlreiche Risiken.
Auch mit dem Wunsch des Gesetzgebers, der sich hinter §6 TDG verbirgt, dem
Endverbraucher bessere Kontaktmöglichkeiten zu bieten, ist dieses Vorgehen
meines Erachtens nicht vereinbar. Eine verfälschte E-Mail-Adresse könnte
also durchaus noch zu einer berechtigten Abmahnung wegen eines unvollstän-
digen Impressums führen.
Damit ist der Einsatz von verfälschten E-Mail-Adressen zwar geeignet, um die
Harvester von Spammern zu blockieren, aber ansonsten völlig unbrauchbar.
5.2 Verstecken mit HTML-Code

Somit bleibt als nächste Möglichkeit, die E-Mail-Adresse auf der Seite so an-
zugeben, dass ein Sammelprogramm sie nicht automatisch auswerten kann.
Zum Erkennen von E-Mail-Adressen lassen sich zwei Merkmale nutzen: ein-
mal der Link auf die Adresse:
<A HREF=“mailto:user@example.com“>
Und zum anderen die Adresse selbst:
user@example.com
Für die Suchmethoden der Harvester sind beide nahezu gleich gut zu finden.
46
Verstecken mit HTML-Code
Der mailto-Link jedoch ist noch einen Tick eindeutiger, da so neumodische

Wörter, die ein „@“ anstelle eines „a“ enthalten, nicht fälschlich für E-Mail-
Adressen gehalten werden können. Schließlich verlinkt mailto ausschließlich
Mailadressen.
5.2.1 Kontaktformular
Daher sollte man zunächst alle mailto-Links aus der Homepage entfernen.
Möchte man dennoch den Komfort bieten, durch einen direkten Klick eine
Nachricht an diese Adresse zu verschicken, so empfiehlt sich der Einsatz eines
Kontaktformulars. Dieses Kontaktformular kann man problemlos mit der (zu-
nächst noch lesbar) angegebenen E-Mail-Adresse verlinken.
Ein solcher Link würde also in einem ersten Schritt so aussehen:
<A HREF="./kontakt.html">user@example.com</A>
Durch diese Maßnahme verschwinden alle mailto-Links, die einfach automa-
tisiert zu finden sind, von der Webseite. Diese Quelle für E-Mail-Adressen ist
damit trockengelegt.
Sofern wir im Folgenden in HTML E-Mail-Adressen verstecken, gehe ich im-
mer davon aus, dass sie auf eine Kontaktseite verlinkt werden und nicht mit ei-
nem mailto-Link versehen sind.
Wie sollte ein sicheres Kontaktformular aussehen?

Auch ein Kontaktformular kann von einem Harvester automatisch ausgelesen
werden. Daher sollten weder im Kontaktformular als versteckte Werte noch
auf der Kontaktseite selbst E-Mail-Adressen unmittelbar lesbar angegeben
werden.
Daher sollte das Mail-Script, das vom Kontaktformular aufgerufen wird, auto-
matisch den Empfänger der Nachricht aus einem übergebenen Code ermitteln
können. Der Beispiel-Formmailer in PHP weiter unten ordnet dabei jedem
Empfänger eine Nummer zu. Diese Zuordnung kann vom Harvester nicht um-
gekehrt werden.
Auch das bekannte Perl-Formmailer-Script von Matt Wright (http://www.
scriptarchive.com), das von vielen Webspace-Providern vorinstalliert wird,
kann man so modifizieren.
No Spam! 47
Als Nebeneffekt lässt sich das Kontaktformular nicht mehr zum Versenden
von Spam missbrauchen: Es gab immer wieder Fälle, in denen das Formular
auf der HTML-Seite selbst so modifiziert wurde, dass die E-Mail nicht mehr
an den von der Webseite vorgesehenen Empfänger ging, sondern an andere
Adressaten.
Aus diesem Grund verschickt das Beispielscript Nachrichten auch nur an
Empfänger, die im Script selbst eingetragen sind. Das Script kann ein Angrei-
fer nicht so einfach manipulieren wie eine HTML-Seite, denn um es bearbei-
ten zu können, müsste er sich Zugang zum Server verschafft haben, was in al-
ler Regel weitere Probleme zur Folge hat.
Programmbeispiel Formmailer
Das Script versucht auch, alle Eingaben sehr streng zu überprüfen, um einen
Missbrauch möglichst zu erschweren. Die notwendigen Übergabeparameter
sind im Script selbst dokumentiert und werden im Beispiel unten gezeigt.
Zum Verständnis des Scripts ist es sinnvoll, wenn Sie sich die in das Script ein-
gefügten Kommentare durchlesen. Ich habe versucht, sie möglichst ausführ-
lich zu halten. Dadurch stehen die wichtigen Hinweise direkt an den relevanten
Stellen des Scripts.
<?php
/* *****************************************************************
Formmail-Script in PHP
Autor: Tobias Eggendorfer
(c) 2004, 2005
Fuer die Funktion wird keinerlei Gewaehrleistung uebernommen. Es
handelt sich bei dem Script um ein Beispiel zu Lehrzwecken.
*****************************************************************
*/
/* *****************************************************************
Das Script erwartet als Uebergabeparameter wahlweise per GET oder
POST:
to: Die Nr. des Empfaengers der E-Mail entsprechend dem Index des
Empfaengers im globalen Array empfaenger unten. Default-Wert
ist 0.
Mehrere Empfaenger-Nummern koennen durch Komma getrennt an-
gegeben werden. Beispiel: 1,2,3
48
cc: Adressaten, an die die Mail in cc gehen soll. Ebenfalls als

in Index in das Array empfaenger.
Ist dieses Feld leer, wird kein cc:-Header eingefuegt.
cc an den Absender wird _nicht_ unterstuetzt, wegen der
Gefahr des Missbrauchs des Scriptes als Spamming-Engine.
bcc: Adressaten, an die die Mail in bcc gehen soll. Analog "cc".
subject: Betreff der generierten E-Mail, Default-Wert steht in

der globalen Konstanten "DEF_SUBJECT".
from: E-Mail-Adresse des Absenders. Wird _nicht_ als Absender
der E-Mail eingetragen, um Spammen über Bounces zu vermeiden.
from_name: Name des Absenders.
msg: Nachricht, die der Absender eingegeben hat.
vars: Variablennamen, kommasepariert, die zusätzliche Daten ent-

halten, die in der Mail stehen sollen.
httpvars: http-Umgebungsvariablen, die der Mail angefuegt werden
sollen. Siehe dazu die PHP-Doku.
******************************************************************
*/
/* Konfiguration des Scriptes
*/
define ('DEF_SUBJECT','Mail vom Formular');
/* Dieses Subject wird eingesetzt, wenn kein Subject uebergeben
wurde.
*/
define ('DEF_FROM','sender@example.com');
/* _Gueltige_ E-Mail-Adresse, die als From in der generierten
Nachricht eingetragen wird. Empfehlung: Ihre eigene.
*/
/* Liste der Empfaengeradresse, die Erste hat den Index 0, die zweite
1 usw.
*/
$empfaenger = array (
'einer@example.com', // Index 0
'anderer@example.com', // Index 1
/* oberhalb dieser Zeile weitere Adressen nach dem
Muster oben anfuegen.
No Spam! 49
*/
'' // bitte so stehen lassen
);
/* ****************************************************************
Funktionen
****************************************************************
*/
function valid_csv_numbers($text)
{
/* Testet, ob $text csv-getrennte Ganzzahlen sind.
Wenn ja, wird ein Array mit diesen Zahlen zurueckgeliefert.
Wenn nein, FALSE
*/
$ret_value = FALSE;
if ( isset($text) &&
(($text = trim($text)) != "") &&
(preg_match('/^[0-9]+(,[0-9]+)*$/',$text) != 0)
)
{
$ret_value = split(',',$text);
}
return $ret_value;
}
function to_address_line($numbers)
{
/* setzt die uebergebenen Nummern ueber das array empfaenger
in gueltige E-Mail-Adressen um und schreibt sie so,
dass die PHP-Funktion mail() sie unmittelbar nutzen kann.
$numbers ist ein array. Ist das nicht der Fall, liefert
die Funktion FALSE zurück.
*/
global $empfaenger;
$ret_value = FALSE;
if ( isset($numbers) && is_array($numbers) )
{
$ret_value = '';
foreach ($numbers AS $number)
{
if ( isset($empfaenger[$number]) &&
($empfaenger[$number] != "") &&
50
(preg_match('/^([a-z0-9_.-])+@([a-z0-9-]+.)+[a-z]{2,6}$/i',
$empfaenger[$number]) != 0)
)
{
$ret_value .= $empfaenger[$number].",";
}
} // end foreach
if ($ret_value != "")
{
$ret_value = substr($ret_value,0,-1);
}
else
{
$ret_value=FALSE;
}
}
return $ret_value;
}
function send_header_and_head()
{
header("Last-Modified: ".gmdate("D, d M Y H:i:s")." GMT");
header("Expires: ".gmdate("D, d M Y H:i:s")." GMT");
header("Cache-Control: no-store, no-cache, must-revalidate");
header("Cache-Control: post-check=0, pre-check=0", false);
header("Pragma: no-cache");
header("Content-Encoding: iso-8859-1");
header("Content-Type: text/html");
?><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
<TITLE>Mailformular</TITLE>
</HEAD>
<BODY>
<?php
}
function send_footer()
{
?>
</BODY>
</HTML>
No Spam! 51
<?php
}
function fehler($msg)
{
/* Bricht den Programmlauf mit einer Fehlermeldung ab.
*/
send_header_and_head();
?>
<H1>Fehler</H1>
<P><B>Ihre Mail wurde nicht versandt.</B></P>
<P>Es ist ein Fehler aufgetreten. Die Fehlermeldung
lautet: <?php print $msg; ?></P>
<P>Bitte verwenden Sie den Back-Button Ihres
Browsers, um zur vorhergehenden Seite zurück zu gehen.</P>
<?
send_footer();
die();
}
/* ******************************************************************
Beginn des eigentlichen Programmes
******************************************************************
*/
foreach ($empfaenger AS $adresse)
{
$adresse = trim($adresse);
}
/* validiere Eingabedaten */
$to = isset($_REQUEST["to"]) ?
valid_csv_numbers($_REQUEST["to"]) :
FALSE;
$to = is_array($to) ?
to_address_line ($to) : to_address_line(array(0));
if ($to === FALSE)
{
fehler('Keine gültige Zieladresse gefunden.');
}
$add_header = "";
52
if (isset($_REQUEST["cc"]))
{
$cc = valid_csv_numbers($_REQUEST["cc"]);
$add_header.= is_array($cc) ?
"Cc: ".to_address_line ($cc)."\r\n" : "";
}
if (isset($_REQUEST["bcc"]))
{
$bcc = valid_csv_numbers($_REQUEST["bcc"]);
$add_header.= is_array($bcc) ?
"Bcc: ".to_address_line ($bcc)."\r\n" : "";
}
$add_header .= "From: ".DEF_FROM."\r\n".
"Reply-To: ".DEF_FROM."\r\n";
if ( isset($_REQUEST["subject"]) )
{
$subject = substr(
str_replace("\r","",
str_replace("\n","",
trim(
$_REQUEST["subject"]))),0,60);
if ($subject == "")
{
$subject = DEF_SUBJECT;
}
}
else
{
$subject = DEF_SUBJECT;
}
if ( !isset($_REQUEST["msg"]) ||
(trim($_REQUEST["msg"]) == "")
)
{
fehler('Die übergebene Nachricht war leer. Leere Mails '.
'können Sie über dieses Formular nicht '.
'versenden.');
}
else
{
$msg = $nachricht = trim($_REQUEST["msg"]);
}
No Spam! 53
if ( isset($_REQUEST["vars"]) &&
(trim($_REQUEST["vars"]) != "") &&
(preg_match('/^[a-z0-9_]+(,[a-z0-9_]+)*$/i',
trim($_REQUEST["vars"]))
!== FALSE
)
)
{
$vars = split(',',trim($_REQUEST["vars"]));
$msg.="\n\n\nFolgende Variablen wurden uebergeben:\n\n\n";
foreach ($vars AS $var)
{
$msg .= "$var: ".
(isset($_REQUEST[$var]) ? $_REQUEST[$var] : "").
"\n\n";
}
}
if ( isset($_REQUEST["httpvars"]) &&
(trim($_REQUEST["httpvars"]) != "") &&
(preg_match('/^[a-z0-9_]+(,[a-z0-9_]+)*$/i',
trim($_REQUEST["httpvars"]))
!== FALSE
)
)
{
$vars = split(',',trim($_REQUEST["httpvars"]));
$msg.="\n\n\nFolgende HTTP-Variablen sollen ausgegeben werden:".
"\n\n\n";
foreach ($vars AS $var)
{
$msg .= "$var: ".
(isset($_SERVER[$var]) ? $_SERVER[$var] : "").
"\n\n";
}
}
if ( isset($_REQUEST["from"]) &&
(trim($_REQUEST["from"]) != "")
)
{
54
$msg = "Absender-Email: ".trim($_REQUEST["from"]).

"\n\n".$msg;
}
if ( isset($_REQUEST["from_name"]) &&
(trim($_REQUEST["from_name"]) != "")
)
{
$msg = "Absender-Name: ".trim($_REQUEST["from_name"]).
"\n\n".$msg;
}
$mail_result = @mail($to, $subject, $msg,
$add_header."X-Mailer: Webform\r\n");
if ($mail_result === TRUE)
{
send_header_and_head();
?>
<H1>Nachricht erfolgreich gesendet.</H1>
<P>Ihre Nachricht wurde erfolgreich gesendet.</P>
<P>Zur Kontrolle hier nochmals der Inhalt der Nachricht:
<PRE><?php print str_replace("<","<",
str_replace(">",">",
$nachricht));
?>
</PRE>
</P>
<?php
send_footer();
}
else
{
fehler('Ihre Nachricht konnte nicht versandt werden.');
}
/* *******************************************************************
Ende
*******************************************************************
*/
?>
No Spam! 55
Beispiel-Kontaktformular
Im Iolgenden möchte ich Ihnen eine kleine HTML-Seite an die Hand geben,
die Ihnen einen Eindruck vermittelt, wie das Kontaktformular erzeugt werden
kann. Von optischen Gestaltungsversuchen habe ich dabei bewusst Abstand
genommen – schließlich müssen diese zum Design der fertigen Seite passen.
Außerdem werden Sie auf Ihrer Seite vermutlich auch noch andere Felder als
die von mir genannten nutzen wollen.
Deutlich zu sehen ist, dass in dem Formular keine einzige E-Mail-Adresse ge-
nannt wird. Stattdessen sind die verschiedenen möglichen Empfänger über
eine Zahl codiert. Die Zahl entspricht dem Index in das Array $empfaenger im
PHP-Script oben.
<HTML>
<HEAD>
<TITLE>Muster-Kontaktformular</TITLE>
</HEAD>
<BODY>
<H1>Kontaktformular</H1>
<FORM METHOD="POST" ACTION="./formmail.php">
<INPUT TYPE="HIDDEN" NAME="httpvars"
VALUE="HTTP_USER_AGENT,REMOTE_ADDR" />
<INPUT TYPE="HIDDEN" NAME="vars"
VALUE="telefon,telefax" />
<P>Wen möchten Sie kontaktieren?
<SELECT NAME="to">
<OPTION VALUE="0">Den Webmaster</OPTION>
<OPTION VALUE="1">Den Autor</OPTION>
<OPTION VALUE="0,1">Beide</OPTION>
</SELECT>
</P>
<P>Ihr Name:
<INPUT TYPE="text" NAME="from_name" />
</P>
<P>Ihre E-Mail-Adresse:
<INPUT TYPE="text" NAME="from" />
</P>
<P>Ihre Telefonnummer:
<INPUT TYPE="text" NAME="telefon" />
</P>
56
<P>Ihre Tefaxnummer:
<INPUT TYPE="text" NAME="telefax" />
</P>
<P>Betreff:
<INPUT TYPE="text" NAME="subject" />
</P>
<P>Ihre Nachricht:
<TEXTAREA NAME="msg"></TEXTAREA>
</P>
<P><INPUT TYPE="SUBMIT" VALUE="Senden" />
<INPUT TYPE="Reset" VALUE="Rücksetzen" />
</P>
</FORM>
<P><SMALL>Mit freundlicher Unterstützung von
<A HREF="http://www.eggendorfer.info"
TARGET="_blank">www.eggendorfer.info</A>.
</SMALL></P>
</BODY>
</HTML>
Meinungen zum Kontaktformular

Der Einsatz von Kontaktformularen ist umstritten – einige Anwender mögen
sie überhaupt nicht, da sie dann keine Kopie der verschickten Nachricht in ih-
rem Mailprogramm haben und auch auf dessen gewohnte Funktionalität ver-
zichten müssen. Auch können sich so leicht versehentlich Tippfehler in der
Absenderadresse einschleichen.
Andererseits setzt ein mailto-Link voraus, dass auf dem Rechner des Anwen-
ders ein Mailprogramm installiert ist und dieses Mailprogramm so konfiguriert
ist, dass es auf solche Links reagiert.
Außerdem muss das Mailprogramm mit den richtigen Nutzerdaten konfigu-
riert sein. Das ist häufig in Schulungsräumen, Internetcafés und Ähnlichem
nicht der Fall. Da versendet der sorglose Anwender dann eine E-Mail mit dem
Absender „PC15“ im Local-Part.
Viele Anwender nutzen heutzutage auch gar keine echten Mailprogramme
mehr, sondern bearbeiten ihre Mails ausschließlich in Webmailern. Auch die
starten mit einem Klick auf einen mailto-Link nicht automatisch.
No Spam! 57
Aus meiner Sicht ist der Formmailer daher genauso nutzerfreundlich oder -un-
freundlich wie ein mailto-Link: Es gibt jeweils Szenarien, in denen das eine
oder das andere praktikabler ist. Ein Formmailer ist jedenfalls für alle Nutzer
unmittelbar benutzbar, während ein mailto-Link die geeignete Konfiguration
des Browsers erfordert.
Aus Sicht des Webseitenbetreibers ist der Formmailer jedenfalls deutlich über-
legen: Über ihn finden Harvester kein Futter.
Auf alle Fälle liefert der Formmailer auch einen Weg zur „schnellen, elektro-
nischen“ Kontaktaufnahme und bietet eine Adresse der elektronischen Post. Er
dürfte damit auch den Anforderungen des §6 Nr. 2 TDG genügen.
5.2.2 Tarnen mit HTML

Durch den Einsatz eines Kontaktformulars haben wir die Webseite nun so ge-
staltet, dass Spammer keine mailto-Links mehr finden. Aber auch Zeichen-
ketten nach dem Muster zeichenfolge@zeichenfolge.zeichenfolge lassen sich
gut automatisiert finden. Dabei läuft zwar der Harvester Gefahr, auch Produkt-
namen und Firmennamen, die ganz im Trend ein „@“ enthalten, zu finden und
als E-Mail-Adressen zu deklarieren. Aber die wenigen so gefundenen, fehler-
haften Adressen interessieren Spammer meist nicht – häufig gehen die erzeug-
ten Fehlermeldungen wegen ungültiger Adressen an unbeteiligte Dritte, da die
Absenderadressen der Spammails gefälscht werden.
Es stehen zahllose Möglichkeiten zur Verfügung, in einer HTML-Seite Text zu
verdecken – es sind im Prinzip die gleichen Verfahren, die auch Spammer tag-
täglich einsetzen, um Spamfilter zu umgehen. Wenn Sie deren Methoden auch
durchschauen wollen, lohnt sich ein Blick in [GRA04]. Was gibt es Schöneres,
als den Gegner mit seinen eigenen Waffen zu schlagen?
Zeichen ersetzen
Eine dieser Methoden, die schon seit Jahren bekannt ist und daher durch ge-
eignete Such- und Ersetzalgorithmen in Harvestern leicht umgangen werden
kann, ist das Ersetzen von „@“ durch „at“ und des Punkts „.“ durch „dot“. So
wird aus user@example.com:
user at example dot com
58
Für Menschen bleibt das lesbar und verständlich, Harvester finden auf Anhieb
keine gültige E-Mail-Adresse mehr.
Aus diesem Grund findet man diese Schreibweise auch mittlerweile sehr häu-
fig im Netz. So werden z.B. die E-Mail-Adressen der Kommentatoren im
PHP-Onlinehandbuch auf http://www.php.net so getarnt.
Allerdings gehe ich davon aus, dass diese Methode kaum mehr langfristig er-
folgreich sein wird. Schließlich lässt sich über regular expressions28 mit gerin-
gem Aufwand eine Ersetzung vornehmen.
s/[ \t\r\n]*at[ \t\r\n]*/@/gi
s/[ \t\r\n]*dot[ \t\r\n]*/./gi
reichen dafür bereits aus. Es ist dabei kaum wahrscheinlich, dass so übermäßig
viele ungültige Adressen generiert werden: Dazu müsste nach Entfernen von
Leerzeichen und der Ersetzung von „dot“ durch den Punkt bzw. „at“ durch „@“
ein Zeichenmuster herauskommen, das aussieht wie eine E-Mail-Adresse.
Spammer machen dasselbe, um beispielsweise Viagra-Spam an Spamfiltern
vorbei zuzustellen. Sie ersetzten den Markennamen durch den Wirkstoff-
namen „Sildenafil“ in ihren Werbemails. Mittlerweile taucht auch der Wirk-
stoffname in den Filtern auf, weshalb sie das „a“ in „Viagra“ durch @, das „i“
durch „1“ ersetzen und Leerzeichen einfügen. Somit erhält man jetzt Angebote
für „V 1 @ G R @“.
Spamfilter können mittlerweile solche Tarnungen knacken. Auch Harvester
sollten mit diesen Umschreibungen umgehen können.
HTML-Kommentare
Ebenso beliebt ist bei Spammern das Einfügen von HTML-Kommentaren, um
typische Filterbegriffe unkenntlich zu machen. Genauso lassen sich auch
E-Mail-Adressen vor Harvestern verstecken. Aus
<A HREF=“./kontakt.html“>user@example.com</A>
wird damit
<A HREF="./kontakt.html">userexample.com</A>
28. Siehe z.B. [EGG05] oder auch [SEL02], [FRI02] oder [STU03]
No Spam! 59
Diese Kommentare werden von allen Browsern in der Darstellung unterdrückt,

die E-Mail-Adresse wird fehlerfrei dargestellt. Aber auch diese Kommentare
lassen sich theoretisch von Harvestern mit geringem Aufwand filtern, um so
die E-Mail-Adresse zu extrahieren: Es reicht aus, die Zeichenfolge „“ zu suchen und durch eine leere Zeichenkette zu ersetzen.
Das lässt sich wiederum einfach mit regular expressions bewerkstelligen. Oder
man verwendet den Textbrowser lynx: Mit der Kommandozeilenoption -dump
verwandelt er HTML in Klartext und gibt das gerade richtig für Filter auf der
Standardausgabe aus.
Fast alle vorgestellten Verfahren lassen sich übrigens knacken – die Frage ist
nur, in welchem Verhältnis der Aufwand zum erwarteten Nutzen steht. Der
Aufwand, HTML-Kommentare zu eliminieren und die oben beschriebenen Er-
setzungen rückgängig zu machen, ist jedenfalls so gering und beide Verfahren
sind so verbreitet, dass es sich für Spammer lohnen würde, sie in ihre Harves-
ter zu implementieren.
Gesperrte Schreibweise
Eine ähnliche Idee ist, Adressen gesperrt anzugeben, also zwischen jedem
Buchstaben ein Leerzeichen einzufügen:
u s e r @ e x a m p l e . c o m
Diese Schreibweise lässt sich nur schwer automatisch zusammenfügen: Das
Entfernen der Leerzeichen stellt zwar kein Problem dar, allerdings müssen
auch die Ränder der Adresse richtig erkannt werden. Es darf kein umstehender
Text mit in die Mailadresse einbezogen werden, da sie dadurch ungültig
würde.
Spamfilter haben hier einen Vorteil: Ihnen reicht es aus, ein Teilwort wie z.B.
„Viagra“ zu erkennen. Sie müssen keine E-Mail-Adressen in verwertbarer
Form generieren. Daher ist diese Methode für Spammer in ihren Spammails
zur Umgehung von Spamfiltern ineffizient; im Kampf gegen Harvester hinge-
gen ist sie sehr effektiv, denn diese müssen gültige E-Mail-Adressen generie-
ren. Der Aufwand, umgebende Wörter nicht versehentlich mit in die Adresse
einzubeziehen, steht in keinem Verhältnis zum Nutzen.
Markiert man die Leerzeichen durch geeignete Cascading Style Sheets (CSS)
als unsichtbar, bemerkt der Besucher der Webseite noch nicht einmal diesen
Trick, wie Abbildung 5.1 demonstriert.
60
Abb. 5.1: Darstellung einer gesperrten E-Mail-Adresse

mit geeignetem CSS im Mozilla
Der zugehörige HTML-Code lautet:

<html>
<head>
<title>Gesperrte Darstellung</title>
<style type="text/css">
div.in { visibility:hidden; display:none; }
</style>
</head>
<body>
u<div class="in"> </div>s<div class="in"> </div>e<div class="in">
</div>r<div class="in"> </div>@<div class="in"> </div>e
<div class="in">
</div>x<div class="in"> </div>a<div class="in"> </div>m
<div class="in">
</div>p<div class="in"> </div>l<div class="in"> </div>e
<div class="in">
</div>.<div class="in"> </div>c<div class="in"> </div>o
<div class="in">
</div>m
</body>
</html>
Dabei können im HTML-Quelltext durchaus auch mehrere Leerzeichen, Zei-
lenumbrüche oder sonstige so genannte Whitespace-Zeichen eingefügt wer-
den. Die zusätzlichen Zeichen machen unter Umständen das Erkennen der
Mail-Adresse für einen Harvester aufwendiger, für den Nutzer bleiben sie
transparent, da mehrere Whitespace-Zeichen im HTML-Code von Browsern
in der Darstellung stets nur in ein Leerzeichen verwandelt werden.
No Spam! 61
Die gesperrte Darstellung funktioniert mit allen Browsern und sollte auch
ohne Probleme mit speziellen Ausgabegeräten wie Braille-Zeilen kompatibel
sein.
Ein ähnliches Verfahren wird unter dem Namen Microdot von Spammern ver-
wendet: Anstatt Leerzeichen einzufügen, wird eine extrem kleine Schriftart
gewählt und ein beliebiges, sonstiges Zeichen ausgegeben. Durch die kleine
Schriftart und häufig auch durch die Wahl der Schriftfarbe ist dieses Zeichen
unsichtbar.
Für Spammer ist die aufwendigere Methode notwendig, da Zeichenketten wie
„Viagra“ auch nach dem Entfernen aller Leerzeichen aus einer Mail von
Spamfiltern erkannt werden. Durch den Microdot werden andere Buchstaben
eingestreut, die das Wort unkenntlich machen.
Zum Verstecken der E-Mail-Adresse reicht die Leerzeichenmethode hingegen
aus: Denn auch der reguläre Text auf der Webseite enthält Leerzeichen. Er
würde, entfernt man alle Leerzeichen, mit der Mailadresse verschmelzen und
sie ungültig machen.
HTML-Entities
Eine andere, häufig empfohlene Möglichkeit ist die Verwendung von HTML-
Entities (z.B. [CDT03]). Dabei werden die Zeichen durch ihre ASCII-Codes
und spezielle HTML-Symbole ersetzt.
Der ASCII-Code weist jedem Zeichen in eindeutiger und umkehrbarer Weise
eine Zahl zu.
Aus
<A HREF="./kontakt.html">user@example.com</A>
wird
<A HREF=“./kontakt.html“>user@ex
amplecom</A>
Allerdings lassen sich auch diese Ersetzungen automatisiert rückgängig
machen und bieten damit allenfalls vorübergehenden Schutz. Schon mit einer
Zeile effektivem PHP-Code lässt sich diese Ersetzung automatisch auflösen:
62
#!/usr/local/bin/php
<?
echo preg_replace('/&#([0-9]+);/e',"chr('\${1}')",
file_get_contents('php://stdin'));
?>
Dieses kleine Script liest von der Standardeingabe (STDIN) HTML-Code mit
ASCII-Entities ein und gibt auf der Standardausgabe den Klartext aus. Es mag
ungewöhnlich erscheinen, PHP von der Kommandozeile zu verwenden, aber
PHP bietet den Vorteil, regular expressions mit Funktionen zu koppeln, in die-
sem Fall mit der Funktion chr, die das Zeichen zu einem ASCII-Code ausgibt.
Dadurch lässt sich die Ersetzung so einfach codieren.
Die ab PHP 4.3.0 verfügbare Funktion decode_html_entities() ersetzt zumin-
dest in PHP bis Version 4.3.8 keine numerischen HTML-Entities und ist daher
für diesen Zweck ungeeignet.
Da das Script von STDIN liest und auf STDOUT ausgibt, kann es einfach in
den oben beschriebenen Beispielharvester (Kapitel 3.2.1) eingesetzt werden,
z.B. bevor sed ausgeführt wird.
Damit das Script an der Kommandozeile ausgeführt werden kann, muss PHP
mit dem Command-Line-Interface (CLI) kompiliert werden. Das ist bei den
meisten RPM-Versionen standardmäßig der Fall. Die erste Zeile im Script gibt
an, wo PHP auf dem jeweiligen System installiert ist. Dadurch muss beim Auf-
ruf des Scripts nicht der PHP-Interpreter mit angegeben werden, sondern es
kann direkt von der Kommandozeile aus gestartet werden.
Die Alternative ist wiederum lynx mit der Option -dump: Auch hier werden die
Ersetzungen rückgängig gemacht und die E-Mail-Adressen im Klartext ausge-
geben.
URL-Encoding
Genauso funktioniert das URL-Encoding – und es kämpft mit den gleichen
Restriktionen. Spammer verwenden es gerne in Phishing-Mails, um die Iden-
tität der aufgerufenen Webseite zu verschleiern.
Der Link, der eine E-Mail-Adresse verschleiert, sähe dann so aus:
<A HREF="mailto:%75%73%65%72%40%65%78%61%6D%70%6C%65%2E%63%6F%6D">
E-Mail senden</A>
No Spam! 63
Die Manipulation erfolgt hier also zur Tarnung des Links selbst. Die auf der
Seite angegebene Mailadresse müsste mit anderen Mitteln verdeckt werden.
Auch hier ist es ein Leichtes, die Ersetzungen rückgängig zu machen – der
mailto:-Vorspann, der sich noch dazu nicht verschlüsseln lässt, macht es noch-
mals um einiges leichter, diese Zeichenkette als Mailadresse zu identifizieren.
Das folgende PHP-Script führt wiederum die Rückübersetzung durch:
#!/usr/local/bin/php
<?
echo urldecode(file_get_contents('php://stdin'));
?>
Dabei lassen sich dieses Script sowie das obige Script sehr einfach zu einem
Script vereinen, um damit sowohl URL-Encoding als auch HTML-Entities
rückgängig zu machen. Beide Verfahren versprechen also nur vorübergehend
Sicherheit.
Tabellen
Erfolgversprechender erscheint die Verwendung von Tabellen: Man schreibt
einen mehrzeiligen Text über mehrere Tabellenzellen verteilt. Betrachten wir
das an einem Beispiel:
<HTML>
<HEAD>
<TITLE>Tabellentest</TITLE>
</HEAD>
<BODY>
<H1>Verdeckte Mailadresse</H1>
<TABLE BORDER="0" CELLPADDING="0" CELLSPACING="0">
<TR VALIGN="TOP">
<TD>M<BR />u</TD>
<TD>e<BR />s</TD>
<TD>i<BR />e</TD>
<TD>n<BR />r</TD>
<TD>e<BR />@</TD>
<TD> <BR />e</TD>
<TD>M<BR />x</TD>
<TD>a<BR />a</TD>
<TD>i<BR />m</TD>
<TD>l<BR />p</TD>
64
<TD>a<BR />l</TD>
<TD>d<BR />e</TD>
<TD>r<BR />.</TD>
<TD>e<BR />c</TD>
<TD>s<BR />o</TD>
<TD>s<BR />m</TD>
<TD>e<BR /> </TD>
</TR>
</TABLE>
</BODY>
</HTML>
Diese HTML-Seite erzeugt z.B. im Textbrowser Links die Ausgabe in Abbil-
dung 5.2 (die Schriftgröße in der Terminalemulation wurde stark vergrößert).
Abb. 5.2: E-Mail-Adresse versteckt in einer Tabelle
In Mozilla sieht die Ausgabe etwas verbeult aus, denn Mozilla verwendet als
Standardschrift eine so genannte Proportionalschriftart. Dabei wird für jeden
Buchstaben nur so viel Platz reserviert, wie er wirklich benötigt. Das „i“ ist
also deutlich schmaler als das „m“. Genau diese beiden Zeichen stehen aber in
unserem Beispiel übereinander.
Allerdings lässt sich das optische Problem durch die Wahl von Schriftarten
und -größen, die Formatierung der Tabellenzellen und eventuell auch durch
No Spam! 65
das Zusammenführen von zwei oder mehr Zellen zu einer größeren durchaus
lösen.
In dem Textbrowser Links fällt dieser Effekt nicht auf, da er mit festen Buch-
stabenbreiten arbeitet – wie man in Abbildung 5.2 sieht.
Um das Tabellenlayout zu knacken, muss der Harvester HTML interpretieren
können, die tatsächliche optische Darstellung ermitteln und das Ergebnis die-
ser Bearbeitung auswerten. Das setzt etwas mehr Know-how voraus, als ledig-
lich Kommentare zu entfernen und ASCII-Codes zu ersetzen.
Meines Wissens gibt es derzeit kein Programm, das diese Übersetzung leisten
kann. Mit dieser Art der Tarnung kämpfen ebenfalls die Spamfilter: Denn auch
diese Methode verwenden Spammer in ihren E-Mails, um Begriffe für die
Spamfilter unsichtbar zu machen.
Die Tabelle muss dabei immer mindestens zweizeiligen Text enthalten: Erst
dadurch führt das einfache Entfernen aller HTML-Tags zu sinnlosem Buchsta-
bensalat. In unserem Beispiel lautet der Text ohne HTML-Tags: „Muesienre@
eMxaaimlpalder.ecsosme“.
Zudem hat dieses Verfahren gegenüber allen anderen, die wir jetzt noch be-
trachten werden, den Vorteil, auch mit Textbrowsern kompatibel zu sein. Na-
hezu alle Browser, bis auf Lynx, können Tabellen darstellen. Somit kann die E-
Mail-Adresse von (fast) allen Nutzern vernünftig erkannt werden. Ob auch
spezielle Lesegeräte, wie eine Braille-Zeile, mit dieser Darstellung zurecht-
kommen, ist mir nicht bekannt. Allerdings steht zu befürchten, dass sie
Schwierigkeiten haben dürften.
Die E-Mail-Adresse kann auch hier wieder verlinkt werden – jedoch mit etwas
mehr Aufwand, weil in jeder Tabellenzelle ein Link gesetzt werden muss.
5.2.3 Rechtliches
Sämtlichen Verfahren ist gemein, dass sie mit fast allen verfügbaren Browsern
problemlos funktionieren. Somit sind für jeden Besucher der Seite die E-Mail-
Adressen unmittelbar lesbar. Damit wird eine Adresse der elektronischen Post,
nämlich eine E-Mail-Adresse, dargestellt und dieser Bedingung des §6 Nr. 2
TDG genüge getan. Somit dürften sich aus diesen Codierungsverfahren keine
Angriffsmöglichkeiten für eine Unterlassungsaufforderung konstruieren las-
sen.
66
Bilder und Ähnliches
Insbesondere die Lösung, die mit Einfügen von Leerzeichen arbeitet, ist auch
barrierefrei und zudem kaum zu knacken. Damit stellt das ein effektives Ver-
fahren zur Tarnung der Mailadresse dar.
5.3 Bilder und Ähnliches

Die Codierung der E-Mail-Adresse mit HTML-Mitteln hat vor allem für den
Ersteller der Seite den Nachteil, sehr zeitaufwendig und umständlich zu sein.
Weniger arbeitsaufwendig scheint die Verwendung von Bildern.
5.3.1 E-Mail-Adresse als Bild

Am einfachsten erstelle man dazu einmal die Seite mit einem richtigen Mail-
link, um anschließend einen Screenshot29 der angezeigten Seite mit dem ech-
ten Maillink zu machen und diesen Teil der Grafik auszuschneiden und in einer
GIF-Datei zu speichern30. Es empfiehlt sich dabei, den Hintergrund transpa-
rent zu wählen.
Dann ersetze man in der HTML-Datei den Maillink von
<A HREF=“./kontakt.html“>user@example.com</A>
durch
<A HREF=“./kontakt.html“><IMG SRC="mailadresse.gif"></A>
Auf diesem Weg sieht man der E-Mail-Adresse auf der Seite (fast) nicht an,
dass sie als Bild eingefügt wurde. Für den normalen Surfer, der mit einem gra-
fikfähigen Browser unterwegs ist, der so konfiguriert ist, dass er Bilder an-
zeigt, ist die Mailadresse sichtbar.
Für Anwender, die einen Textbrowser verwenden oder deren Browser per Kon-
figuration so eingestellt ist, dass er keine Bilder anzeigt, bleibt die Mailadresse
dagegen verborgen. Auch dürften Anwender, die beispielsweise über eine
Braille-Zeile surfen, ausgebremst werden.
29. Auf Windows-Rechnern mit der Taste „PrtScr“ bzw. „Druck“, auf Linux-Systemen z.B. mit
The Gimp, erhältlich unter http://www.gimp.org.
30. JPEG ist für solche Grafiken unsinnig – der Kompressionsalgorithmus von JPEG ist eher
auf Fotos optimiert, der von GIF auf solche Bilder.
No Spam! 67
HTML-Hinweise
In jedem Fall sollte für dieses Bild – wie für jedes andere Bild auf einer Home-
page auch – sowohl die Höhe als auch die Breite (HEIGHT=““, WIDTH=““)
angegeben werden, damit der Browser die Seite von Anfang an richtig berech-
nen und darstellen kann.
Außerdem sollte ein aussagekräftiger Alternativtext angegeben werden. Die-
ser Text wird von Textbrowsern immer und von „normalen“ Browsern so lange
angezeigt, bis das Bild geladen wurde. Die meisten grafikfähigen Browser zei-
gen ihn auch an, wenn man mit dem Mauszeiger über das Bild fährt31. Aller-
dings sollte der Alternativtext nicht die E-Mail-Adresse selbst enthalten –
sonst beißt sich die Katze in den Schwanz.
Technische Bewertung
Das Verfahren ist sehr effizient: Würde ein Harvester alle Bilder einer Seite he-
runterladen, steigt das zu übertragende Datenvolumen erheblich. Momentan
beschränken sich diese Programme daher auf das Auslesen von HTML-Seiten,
die im Allgemeinen deutlich kleiner als Bilder sind.
Außerdem müsste der Harvester dann in der Lage sein, GIF-, PNG- und JPEG-
Bilder richtig zu decodieren. Er müsste weiterhin über eine OCR-Software,
also ein Programm zur Zeichenerkennung, verfügen, durch die er dann den in
Bildern enthaltenen Text automatisch extrahieren kann.
Geht man davon aus, dass ein Promille der Bilder im Netz E-Mail-Adressen
enthalten, was wahrscheinlich bereits um einige Zehnerpotenzen zu hoch ge-
griffen ist, dann müssen 1000 Bilder für eine E-Mail-Adresse analysiert wer-
den. Der Rechenzeitaufwand ist gigantisch und nicht sonderlich erfolgverspre-
chend: Die Erkennungsfehler der OCR-Software sind immer noch recht hoch.
Zudem lässt sich die Erkennungsrate durch geschickte Gestaltung des Bilds
weiter verschlechtern.
Außerdem spricht nichts dagegen, das Bild zu zerschneiden und durch mehre-
re, kleine Bilder zu ersetzen. Spätestens jetzt ist die OCR-Software am Ende:
Keines der Bilder enthält eine vollständige E-Mail-Adresse.
31. Ausführlicher dazu: http://www.teamone.de/selfhtml/ bzw. [MÜN02] und [MÜN02a]
68
Rechtliche Bewertung
Fraglich ist natürlich, ob diese Lösung mit §6 Nr. 2 TDG kompatibel ist: Denn
nicht jeder bekommt das Bild zu sehen, die E-Mail-Adresse ist somit nicht im-
mer angegeben. Andererseits kann man heutzutage davon ausgehen, dass die
Surfer in der Mehrheit über einen grafikfähigen Browser verfügen, wie man
diversen Statistiken (z.B. auf [WIL04d]) entnehmen kann. Das ist auch lo-
gisch, denn auf vielen Seiten ist ohne Grafiken gar nichts zu erkennen. Damit
wäre es wenig plausibel, dass ein Surfer ohne grafikfähigen Browser das Im-
pressum und damit die scheinbar fehlende E-Mail-Adresse entdecken könnte.
Somit dürfte sich der Versuch, einen entsprechenden Unterlassungsanspruch
gerichtlich durchzusetzen, mit der Begründung, dass der Seitenbetreiber nicht
für technische Besonderheiten und daraus resultierende Probleme eines Ein-
zelfalls verantwortlich sein kann, abschmettern lassen – wobei das in der
rechtswissenschaftlichen Literatur durchaus umstritten ist ([AND04a]). Denn
auch dem Nutzer eines solchen Browsers ist es nicht unmöglich, die über einen
Alternativtext gekennzeichnete Grafik herunterzuladen und mit einem geeig-
neten Programm zu betrachten.
Zudem kann der Forderung nach unmittelbarer Angabe der E-Mail-Adresse
das schützenswerte Interesse des Seitenbetreibers entgegengehalten werden,
seine E-Mail-Adresse nicht automatisch in die Listen von Spammern eintragen
zu lassen.
Damit dürfte eine Darstellung der E-Mail-Adresse als Grafik meiner Ansicht
nach gerade noch im Rahmen des rechtlich Vertretbaren liegen. Anders ist die
Lage zu beurteilen, wenn die Seite gezielt barrierefrei gestaltet wurde.
5.3.2 PDF
Statt in eine Grafik lässt sich eine E-Mail-Adresse natürlich auch in eine PDF-
Datei schreiben. Auf sie kann man mit einem Link hinweisen; anders als eine
Grafik lässt sie sich jedoch nicht in die Webseite einbinden. §6 Nr. 2 TDG for-
dert aber nur die Angabe einer E-Mail-Adresse. Über die Form ist nichts aus-
gesagt.
Programme zur Darstellung von PDF-Dateien existieren für alle gängigen
Betriebssysteme und Plattformen: Mittlerweile gibt es sogar PDF-Reader für
PalmOS und Symbian. PDF-Dateien können somit von fast allen Systemen
dargestellt werden, bei geeigneter Gestaltung können sie sogar über eine
No Spam! 69
Braille-Zeile ausgegeben werden. Insofern dürfte die rechtliche Lage der für
Grafiken mindestens vergleichbar sein.
Von Nachteil ist jedoch, dass sich der Text aus PDF-Dateien problemlos extra-
hieren lässt, die entsprechenden Funktionen sind beispielsweise im Acrobat
Reader zum Markieren und Kopieren von Text enthalten. Auch eine automati-
sche Umsetzung ist möglich – so durchsucht Google auch PDF-Dateien und
nimmt sie in den Index auf. Diese Extraktion ist dabei unabhängig von einer
eventuell in der PDF-Datei eingerichteten Sperre für „Cut-and-Paste“.
Da auf vielen Webseiten PDF-Dokumente abgelegt sind und viele dieser Do-
kumente die E-Mail-Adresse des Autors enthalten, könnte es sich für Spam-
mer durchaus lohnen, PDF-Dateien von einem Harvester automatisiert auszu-
werten, auch wenn bisher noch kein Harvester bekannt ist, der das leistet.
Der Umweg über eine OCR-Software ist hier nicht notwendig, denn ein PDF-
Dokument enthält eine Beschreibung der Seite. Dabei bleibt, ähnlich wie in ei-
ner HTML-Datei, der Originaltext erhalten32.
Insofern wäre eine Lösung mittels einer PDF-Datei schlechter als die Grafik-
variante und somit ungeeignet.
5.3.3 Flash
Viele Anwender haben heutzutage auch die Möglichkeit, Flash-Filme zu be-
trachten. Diese Filme werden gerne als Intro für Homepages missbraucht und
sollen damit wohl demonstrieren, dass der Gestalter der Seite auch mit Flash
umgehen kann. Daher werden reine Flash-Seiten von erfahrenen Net-Citizens
häufig nicht sonderlich geschätzt, da dort Flash oft nur Selbstzweck ohne Zu-
satznutzen ist.
Allerdings können Flash-Filme auch durchaus sinnvolle Anwendungen reali-
sieren. So lassen sich beispielsweise komplexe, technische Zusammenhänge
interaktiv veranschaulichen. Auch kleine Spiele lassen sich in Flash verwirk-
lichen und können damit ein nettes Gadget sein.
Flash ist interaktiv, insbesondere können in Flash-Filmen Aktionen auf
Mausklicks ausgelöst werden. Flash kann auch Links enthalten und damit
ebenfalls Links auf E-Mail-Adressen. Und Flash lässt sich problemlos in
Webseiten integrieren.
32. Siehe dazu: http://partners.adobe.com/asn/tech/pdf/specifications.jsp
70
Damit könnte man Links auf E-Mails anklickbar mit mailto-Links in einen
Flash-Film packen.
Der Haken an der Sache: Das offizielle Programm von Macromedia, um Flash-
dateien zu generieren, ist sehr teuer. Allerdings gibt es mittlerweile im Netz
zahlreiche Gratislösungen33, die, eventuell mit eingeschränktem Funktionsvor-
rat, das kostenlose Erzeugen von Flash-Dateien ermöglichen.
Auch kann das kostenlose Office-Paket OpenOffice.org (http://www.open-
office.org), dessen Funktionsumfang dem kommerzieller Konkurrenten ent-
spricht und völlig ausreichend ist, um Dokumente wie dieses Buch zu
erstellen, und sein für Forschung und Lehre kostenloser „großer“ Bruder Star-
Office (http://www.sun.com) Präsentationen als Flash-Filme exportieren.
Jedoch setzt das Abspielen von Flash-Filmen die Verfügbarkeit des Flash-
Players voraus. Den gibt es zwar mittlerweile für eine Vielzahl von Plattfor-
men, aber er ist nicht standardmäßig auf allen Systemen verfügbar. Einige An-
wender begründen ihre Weigerung, Flash zu installieren, mit daraus resultie-
renden Sicherheitsrisiken34.
Damit dürfte – anders als bei Grafiken – der Vortrag eines eventuellen Unter-
lassungsklägers aufgrund der Vorschriften des §6 Nr. 2 TDG mehr Substanz
haben und könnte damit auch eher zum Erfolg führen.
Und – zu guter Letzt – auch in Flash-Dateien werden Textinformationen35 im
Prinzip als Text gespeichert. Sie lassen sich somit automatisiert extrahieren,
auch wenn mir bislang keine Anwendung bekannt ist, die das tut.
Die Flash-Lösung hat also – bis auf die Möglichkeit, einen Link direkt einzu-
tragen – keine Vorteile gegenüber einer eingebundenen Grafik, aber erhebliche
Nachteile. Insofern erscheint sie mir weder aus rechtlicher noch aus techni-
scher Sicht empfehlenswert.
33. Beispielsweise auf http://www.openswf.org/, http://drawswf.sourceforge.net/,

http://www.swfx.org/generator/index.jsp und dem gruselig gestalteten
http://www.sophistronix.com/
34. Siehe dazu: [SCHWE04], von realen Fällen berichtet: [BAC04b]
35. Siehe dazu: http://web.archive.org/web/19990210180754/www.macromedia.com/software/
flash/open/spec/
No Spam! 71
5.4 JavaScript
Eine andere Alternative ist es, mit JavaScript die E-Mail-Adresse auf der
Webseite auszugeben. JavaScript kann derzeit von Harvestern noch nicht aus-
geführt werden. Der Aufwand, einen Harvester entsprechend anzupassen,
wäre schlicht zu hoch. Und das, obwohl man sich beispielsweise die Java-
Script-Bibliotheken des OpenSource-Browsers Mozilla herunterladen und in
seinen Harvester integrieren könnte. Da sich aber auf herkömmlichem Weg
noch ausreichend E-Mail-Adressen sammeln lassen, ist der Aufwand unver-
hältnismäßig hoch.
Die meisten Browser können im Gegensatz zu Harvestern mit JavaScript
umgehen. Ausnahmen sind die textbasierten Browser wie Lynx und Links. In
vielen Browsern deaktivieren außerdem Anwender aus Sicherheitsgründen
JavaScript. Gerade die Produkte von Microsoft, die JavaScript mit ActiveX
koppeln, weisen aufgrund von Programmierfehlern insbesondere im ActiveX
erhebliche Sicherheitslücken auf. So sind ActiveX-Controls fast schon Stan-
dard, um ohne Nutzerinteraktion 0190-Dialer zu installieren.
Leider kann man im Internet Explorer JavaScript nur zusammen mit ActiveX
deaktivieren.
Für JavaScript hege ich wegen der begründeten, eingeschränkten Verfügbar-
keit daher grundsätzlich die gleichen Bedenken bezüglich der rechtlichen Im-
plikationen wie ich sie oben für die Flash-Lösung (Seite 70) beschrieben habe.
Allerdings ist JavaScript aus technischer Sicht sehr effektiv.
5.4.1 Das Grundprinzip

Mit JavaScript lässt sich eine E-Mail-Adresse relativ elegant tarnen. Der ein-
fachste Ansatz ist dabei:
<HTML>
<HEAD>
<TITLE>Beispielseite</TITLE>
<SCRIPT LANGUAGE=“JavaScript“>

</SCRIPT>
</HEAD>
72
JavaScript
<BODY>
....

</SCRIPT>
....
</BODY>
</HTML>
Allerdings hat dieser einfache Ansatz gleich zwei Haken: Einmal steht die E-
Mail-Adresse in lesbarer Form direkt in der Datei, zum anderen ist es relativ
umständlich, einen E-Mail-Link anzugeben.
Als Abhilfe für das erste Problem bietet es sich an, das Script aus einer exter-
nen Datei nachzuladen. Das hat zudem den Vorteil, dass man für den Fall einer
Änderung der Mailadresse diese nur einmal für die gesamte Webseite ändern
muss.
Damit entsteht eine zweite Datei, die ich im Folgenden email.js nenne. Sie ent-
hält die notwenigen JavaScripten. Zunächst besteht sie nur aus einer Zeile:
mailadresse = 'user@example.com';
Die HTML-Datei ändert sich dann zu:
<HTML>
<HEAD>
<SCRIPT LANGUAGE="JavaScript" src="./email.js"> </SCRIPT>
</HEAD>
<BODY>
....

</SCRIPT>
....
</BODY>
</HTML>
No Spam! 73
Der Unterschied ist klein – aber effektiv: Harvester laden derzeit keine Java-
Script-Dateien nach, denn den enthaltenen JavaScript-Code können sie nicht
interpretieren. Damit ist die Mailadresse versteckt.
Doch ist es prinzipiell kein Problem, einen Harvester so zu erweitern, dass er
JavaScript-Dateien ebenfalls herunterlädt und nach E-Mail-Adressen durch-
sucht. Damit wäre der Vorteil dahin.
Ein anderer Nachteil wiegt jedoch viel schwerer: Es ist nicht definiert, wann
der Browser die JavaScript-Datei nachlädt. Damit kann es sein, dass der Brow-
ser die JavaScript-Datei noch nicht geladen hat, wenn er zur Funktion docu-
ment.write kommt und diese ausführt. Diese verwendet dann aber eine Variab-
le, deren Wert noch nicht definiert ist, was zum einen zu einem JavaScript-
Fehler führt, zum anderen aber auch dazu, dass keine Mailadresse ausgegeben
wird.
Die Lösung mit der externen JavaScript-Datei ist so also noch unbrauchbar.
5.4.2 Eine stabilere Lösung

Es muss eine stabilere Lösung her – günstigerweise sogar so, dass die notwen-
digen JavaScript-Befehle kürzer werden. Und so, dass das Ganze auch mit ei-
ner externen JavaScript-Datei funktioniert – der Vorteil der einfacheren War-
tung soll erhalten bleiben.
Dazu bietet es sich an, die Datei email.js wie folgt abzuändern:
mailadresse='user@example.com';
function mailMe()
{
document.location.href="mailto:"+mailadresse;
}
Damit ändert sich auch die zugehörige HTML-Datei:
<HTML>
<HEAD>
</HEAD>
<BODY>
....
<A HREF="javascript:mailMe();">E-Mail senden</A>
74
JavaScript
....
</BODY>
</HTML>
Allerdings wird hier keine E-Mail-Adresse ausgegeben, sondern nur ein
E-Mail-Link angelegt. Möchte man die E-Mail-Adresse ausgeben, bleibt ent-
weder das „document.write()“-Problem bestehen oder man müsste die Funk-
tion mailMe() in jede HTML-Datei einfügen. Dann könnte man wiederum pro-
blemlos mit document.write() arbeiten:
<HTML>
<HEAD>
<SCRIPT LANGUAGE="JavaScript">

</SCRIPT>
</HEAD>
<BODY>
....
<A HREF="javascript:mailMe();"><SCRIPT LANGUAGE="JavaScript">

</SCRIPT></A>
....
</BODY>
</HTML>
Ich favorisiere die Verwendung einer externen JavaScript-Datei – dadurch
wird der Pflegeaufwand für die Gesamtseite kleiner – allerdings um den Preis,
die E-Mail-Adresse nicht direkt mittels eines JavaScripts ausgeben zu können.
Möchte man nicht auf die HTML-Verfahren zurückgreifen, kann man die Aus-
gabe in etwas anderer Form auch in JavaScript lösen. Dazu erweitert man die
Datei email.js um eine weitere Funktion:
No Spam! 75
function mailMe()
{
}
function showMail()
{
alert('Die E-Mail-Adresse lautet'+mailadresse+'.');
}
Dazu passt dann beispielsweise die folgende HTML-Datei:
<HTML>
<HEAD>
</HEAD>
<BODY>
....
<A HREF="javascript:mailMe();">E-Mail senden</A><BR />
<A HREF="javascript:showMail();">E-Mail-Adresse anzeigen</A>
....
</BODY>
</HTML>
Die E-Mail-Adresse wird jetzt in einem kleinen JavaScript-Popup angezeigt.
Für welche Variante Sie sich letztlich entscheiden, bleibt Ihnen überlassen. Sie
kennen jetzt einige Beispielmethoden, die Grundlage für Ihre eigenen Weiter-
entwicklungen sein können.
Ich gehe im Folgenden davon aus, dass eine Möglichkeit zur Verfügung steht,
die E-Mail-Adresse auszugeben, und werde weiterhin mit einer Datei email.js
und einer HTML-Seite arbeiten, in der nur ein Link auf die E-Mail-Adresse
existiert.
5.4.3 Theoretische Informatik ausnutzen

Noch ist die bisherige Lösung nicht optimal: In der JavaScript-Datei steht im-
mer noch eine E-Mail-Adresse im Klartext. Damit ist sie leicht von jedem Har-
vester, der sich die Mühe macht, JavaScript-Dateien herunterzuladen, auf-
zufinden. Der Harvester muss dazu noch nicht einmal JavaScript können – es
76
JavaScript
reicht aus, wenn er mit einer regular expression nach etwas sucht, das aussieht
wie eine Mailadresse.
Also wäre eine Lösung sinnvoll, die die Mail-Adresse nicht im Klartext ent-
hält. Viele denken dabei sofort an Verschlüsselung – mit etwas Wissen aus der
theoretischen Informatik geht es aber auch einfacher: Denn grob zusammen-
gefasst sagt der Satz von Rice, dass es kein Programm gibt, das erkennen kann,
was ein anderes Programm macht. Eine Tatsache, die Sie leicht an Ihrem
Virenscanner nachprüfen können: Der lädt regelmäßig Signatur-Updates her-
unter, um auch neue Viren zu erkennen. Könnte er bestehende Programme auf
ihre Funktion untersuchen, würde er auch unbekannte Viren erkennen.
Also reicht es aus, zur Tarnung der Adresse den Harvester zu zwingen, Java-
Script auszuführen. Am einfachsten geht das mit folgender email.js:
localpart='user';
domain='example';
toplevel='com';
mailadresse=localpart;
mailadresse+='@';
mailadresse+=domain+'.'+toplevel;
function mailMe()
{
}
Dort wird die Mailadresse nach und nach aus ihren verschiedenen Teilen zu-
sammengebaut. Das ist für uns Menschen leicht lesbar – ein Harvester müsste,
um die Adresse zu finden, jedoch JavaScript beherrschen.
5.4.4 Mit Verschlüsselung

Um auch für Menschen die unmittelbare Lesbarkeit zu erschweren – ohne je-
doch den Schutz vor Harvestern zu erhöhen –, lässt sich die E-Mail-Adresse
auch mit JavaScript-Mitteln verschlüsseln.
Welches Verfahren dabei zum Einsatz kommt, ist de facto unerheblich: In der
JavaScript-Datei stehen der komplette Dechiffrieralgorithmus und der notwen-
dige Schlüssel. Damit kann jeder, der JavaScript ausführen kann, auch die ver-
schlüsselte E-Mail-Adresse auslesen.
No Spam! 77
Das ist auch in Ordnung so, denn das Ziel ist, dass jeder Browser später die E-
Mail-Adresse anzeigen kann. Es soll nur verhindert werden, dass Harvester die
Adresse auslesen können. Und das wird aufgrund der Annahme, dass Harves-
ter kein JavaScript ausführen, erreicht.
Daher kann ein einfacher Verschlüsselungsalgorithmus angewandt werden,
beispielsweise Cäsars Schiebealgorithmus36. Der wird in verschiedenen Aus-
prägungen empfohlen – manche sagen, dass eine Verschiebung um ein Zei-
chen genüge, da das im Notfall auch ohne JavaScript leicht im Kopf nachge-
rechnet werden könne. Andere schlagen vor, das verbreitete ROT13-Verfahren
zu verwenden. Dabei wird das Alphabet um dreizehn Zeichen verschoben.
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
X Y Z A B C D E F G H I J K L M N O P Q R S T U V W
Abb. 5.3: Beispiel für ein einfaches Schiebealphabet
Abbildung 5.3 zeigt ein Schiebealphabet mit dem Schlüssel 3, also einer Ver-
schiebung um drei Zeichen.
Eine weitere Möglichkeit, die nichts anderes leistet als das Schiebealphabet,
sieht das Anwenden einer XOR-Verknüpfung auf jedes Zeichen vor. XOR ist
ein logischer Operator37, der auf jedes Bit des ASCII-Werts des Zeichens an-
gewandt wird und im Gegensatz zu den anderen booleschen Operatoren den
Vorzug hat, wieder eindeutig umkehrbar zu sein.
Im Ergebnis sind alle diese Verfahren äquivalent. Ich wähle für das Beispiel
hier wegen der einfachen Implementation XOR. Das Symbol für XOR in Java-
Script ist der Circonflexe: ^.
Damit sieht die neue email.js mit dem Schlüsselwert 183 wie folgt aus:
local = new Array (194,196,210,197);
local_part = '';
domain = new Array (210,207,214,218,199,219,210,153,212,216,218);
domain_part = '';
36. Dazu einführend z.B. [EGG04e], detaillierter [BAU93], [BAU00], [BEU02], [BEU02a],
[SIN04] oder auch [SCHWE02]
37. Siehe dazu z.B. [EGG05], dort den Exkurs zur booleschen Algebra
78
JavaScript
for (i=0; i<local.length;

local_part += String.fromCharCode(local[i] ^ 183), i++) ;
for (i=0; i<domain.length;
domain_part += String.fromCharCode(domain[i] ^ 183), i++) ;
mailadresse = local_part + String.fromCharCode(64) + domain_part;
function mailMe()
{
}
Die HTML-Datei selbst ändert sich nicht:
<HTML>
<HEAD>
</HEAD>
<BODY>
....
....
</BODY>
</HTML>
Die JavaScript-Datei definiert zwei Arrays: local und domain. local enthält
alle Zeichen vor dem @-Symbol, in diesem Fall user, in verschlüsselter Form.
domain umfasst alle Zeichen nach dem @-Symbol, in diesem Fall wieder ex-
ample.com.
Die beiden for-Schleifen führen die Entschlüsselung der beiden Teile der Mail-
adresse durch und schreiben die Ergebnisse in local_part bzw. domain_part.
Anschließend werden local_part, das @-Symbol, das den ASCII-Code 64 hat,
und domain_part zu einer E-Mail-Adresse zusammengefügt.
Die for-Schleifen sind in einer verkürzten Form geschrieben. Ausgeschrieben
sieht die Schleife für den Local-Part wie folgt aus, was auf den ersten Blick
vielleicht leichter lesbar ist:
for (i=0; i<local.length; i++)
{
local_part += String.fromCharCode(local[i] ^ 183);
}
No Spam! 79
Damit bleibt ein letztes Problem bestehen: das Verschlüsseln. Denn schließlich
müssen die Zahlenwerte in die beiden Arrays eingefügt werden. Um Ihnen die
dafür nötige Arbeit so leicht wie möglich zu machen, habe ich eine kleine
HTML-Datei vorbereitet, die die notwendigen Funktionen zur Verschlüsse-
lung bereitstellt:
<HTML>
<HEAD>

<TITLE>XOR-Verschlüsselung</TITLE>
<SCRIPT LANGUAGE="JavaScript">

</SCRIPT>
</HEAD>
<BODY>
<H1>Verschlüsseln mit XOR</H1>
<FORM METHOD="GET" ACTION="./xor_encrypt.html"
NAME="krypt" >
<P>Der Schluessel (Ganzzahl zwischen 1 und 255)
<INPUT TYPE="text" NAME="schluessel" />
</P>
<P>Der zu verschluesselnde Text:
<INPUT TYPE="text" NAME="nachricht" />
</P>
<P><INPUT TYPE="BUTTON" VALUE="Verschlüsseln"
onClick='do_it(); return false;'/>
<INPUT TYPE="Reset" VALUE="Rücksetzen" />
</P>
<P>Das Chiffrat:
<TEXTAREA NAME="ausgabe"></TEXTAREA>
</P>
</FORM>
</BODY>
</HTML>
Im Beispiel ist der JavaScript-Code in der Seite bewusst defensiv program-
miert und er prüft alle erhaltenen Eingaben kritisch ab.
[TUCEK] implementiert eine ähnliche Lösung, verwendet jedoch einen wesent-
lich aufwändigeren Verschlüsselungsalgorithmus: Kann der Harvester Java-
Script ausführen, ist die Güte des Verschlüsselungsalgorithmus irrelevant, da
sowohl Algorithmus als auch Schlüssel unmittelbar in JavaScript codiert sind.
82
JavaScript
5.4.5 Harvester mit JavaScript

Wollte man auch JavaScript-fähige Harvester blockieren, müsste man den
Nutzer auffordern, den auf der Seite angegebenen Schlüssel in eine Dialogbox
einzugeben. Das würde eine einfache Mensch-Maschine-Erkennung imple-
mentieren und damit den Harvester nachhaltig ausbremsen. Denn jetzt reicht
es für den Harvester nicht mehr aus, „nur“ JavaScript zu lernen, er muss auch
korrekte Eingaben in eine Benutzerschnittstelle vornehmen können. Das wäre
dann doch etwas zu viel der künstlichen Intelligenz.
Die email.js für eine solche Lösung sieht wie folgt aus:
local = new Array (194,196,210,197);
domain = new Array (210,207,214,218,199,219,210,153,212,216,218);
function decode_mailadresse()
{
domain_part = '';
local_part = '';
schluessel = prompt('Bitte geben Sie die Zahl 183 ein, um die '+
'Mail-Adresse zu erhalten.','');
if ( (isNaN(schluessel) == false) &&
(schluessel == 183)
)
{
local_part += String.fromCharCode(local[i] ^ schluessel),
i++);

domain_part += String.fromCharCode(domain[i] ^ schluessel),
i++);

}
else
{
mailadresse = 'Ihre Eingabe war falsch. Bitte nochmal probieren.';
}
return mailadresse;
}
No Spam! 83
function mailMe()
{
return false;
}
Auch die HTML-Datei muss minimal geändert werden:
<HTML>
<HEAD>
</HEAD>
<BODY onLoad='mailadresse=decode_mailadresse();'>
....
....
</BODY>
</HTML>
Jetzt wird der Besucher beim Aufruf der Seite aufgefordert, die Zahl 183 ein-
zugeben, die dann unmittelbar als Schlüssel verwendet wird. Alternativ könnte
man die Entschlüsselungsfunktion auch aus der Funktion mailMe() aufrufen.
5.4.6 JavaScript-freie Browser

[BELL03] hat einen interessanten Lösungsvorschlag, die JavaScript-Lösung
zu Browsern kompatibel zu gestalten, die kein JavaScript unterstützen. Die
Idee basiert darauf, einen Link auf die Kontaktseite bei verfügbarem Java-
Script durch einen Link auf die E-Mail-Adresse zu ersetzen. Dadurch erhalten
Nutzer, die ohne JavaScript surfen, die Kontaktseite angeboten. Bei Nutzern,
die über JavaScript verfügen, wird ein mailto-Link ausgeführt.
Dazu muss die weiter oben beschriebene email.js wiederum nur minimal ge-
ändert werden – ich verzichte hier wieder auf die Mensch-Maschine-Erken-
nung, da ich sie für zu aufwendig halte.
local = new Array (194,196,210,197);
local_part = '';
domain = new Array (210,207,214,218,199,219,210,153,212,216,218);
domain_part = '';
84
JavaScript

local_part += String.fromCharCode(local[i] ^ 183), i++) ;
domain_part += String.fromCharCode(domain[i] ^ 183), i++) ;
function mailMe()
{
return false;
}
Die HTML-Seite ändert sich dann zu:
<HTML>
<HEAD>
</HEAD>
<BODY>
....
<A HREF="kontakt.html" onClick="return mailMe();">E-Mail senden</A>
....
</BODY>
</HTML>
Dadurch, dass die Funktion mailMe() den Wert false zurückgibt, wird der Link
zum Kontaktformular von einem JavaScript-fähigen Browser nicht aufgeru-
fen, sondern nur der mailto-Link ausgeführt. Möchte man dieses Verhalten än-
dern, muss man lediglich den Rückgabewert von mailMe() auf true setzen.
Ein Browser ohne JavaScript ignoriert das JavaScript und linkt direkt zum
Kontaktformular.
Irreführend für den Nutzer könnte es noch sein, dass in der Statuszeile des
JavaScript-fähigen Browsers der Link auf das Kontaktformular ausgegeben
wird. Das lässt sich jedoch durch folgende Änderung des Links in der HTML-
Datei beheben:
<A HREF="kontakt.html" onClick="return mailMe();"
onMouseOver="self.status=mailadresse; return true;"
onMouseOut="self.status=''; return true;">E-Mail senden</A>
Dieser Lösungsansatz dürfte sich auch günstig auf die oben dargestellte recht-
liche Problematik bei der Verwendung von JavaScript auswirken. Dort stützte
No Spam! 85
sich die Argumentation im Wesentlichen darauf, dass viele Nutzer JavaScript

aus Sicherheitsgründen deaktivieren.
Diese Lösung bemüht sich aber auch um Surfer ohne JavaScript: Diesen wird
ein Kontaktformular angeboten. Nutzern, die über JavaScript verfügen, wird
die E-Mail-Adresse unmittelbar ausgegeben. Durch die so gewährleistete hohe
Kompatibilität dürfte es schwer fallen, einen Unterlassungsanspruch wegen
der Verwendung eines unvollständigen Impressums durchzusetzen.
5.5 Weitere Verfahren

[GUN04] berichtet, dass Harvester in zunehmenden Maße auf Suchmaschinen
zurückgreifen, um Webseiten mit E-Mail-Adressen zu finden, und gar nicht
mehr die Links auf Webseiten verfolgen.
Dieses Verhalten konnte ich aber nicht bestätigen: Die von mir getesteten Har-
vester verfolgten durchaus Links auf Webseiten. Auch die Zugriffe auf meine
Teergrube, die ich in Kapitel 8 beschreibe, dokumentieren, dass Links gefolgt
wird. Dieses Verhalten wird auch in den einschlägigen Diskussionsforen viel-
fältig beschrieben.
Harvester nutzen zwar teilweise Suchmaschinen, um die Seiten „zielgruppen-
gerecht“ ausfindig zu machen, die sie anschließend nach Mailadressen abgra-
sen. Allerdings scheint es mir ineffizient, nur nach Mail-Links zu suchen.
Würde jedoch tatsächlich nur nach mailto-Links gesucht, dann ließen sich
mailto-Links mit einem einfachen Redirect verstecken, wie es [WILLI02] vor-
schlägt. Dazu muss serverseitig ein einfaches Script laufen, das aus einem
übergebenen Parameter den passenden Redirect konstruiert.
Die einfachste Lösung dazu stellt [WILLI02] selbst vor – ohne jedoch eventu-
elle Sicherheitsprobleme zu berücksichtigen. Nach seinem Vorschlag reicht
die folgende Seite aus:
<HTML>
<HEAD>
</HEAD>
<BODY>
....
<A HREF="mail.php?user=user">E-Mail senden</A>
....
86
Test auf echten Webseiten
</BODY>
</HTML>
Das aufgerufene PHP-Script mail.php soll die folgende Form haben:
<?
header("Location: " . ($user? "mailto:$user@example.com" :
"http://$HTTP_HOST/"));
?>
Führt man eine kritischere Prüfung des Eingabenparameters über regular ex-
pressions durch, überprüft man, ob der HTTP-Parameter Host tatsächlich ge-
setzt ist, der erst ab HTTP/1.1 existiert, und erweitert man dieses Script mög-
lichst so, wie den Formmailer im Kapitel „Programmbeispiel Formmailer“,
der nur numerische Parameter akzeptiert, dann könnte dieser Ansatz funktio-
nieren. Allerdings nur unter der falschen Annahme, dass Harvester keinen
Links folgen – ansonsten liefert man die Mailadresse auf dem Präsentierteller.
Daher erscheinen mir die anderen in diesem Kapitel vorgeschlagenen Verfah-
ren effizienter.
5.6 Test auf echten Webseiten

Um die Leistungsfähigkeit der beschriebenen Verfahren zu prüfen, führte ich
einen Test durch. Dazu habe ich eine neue Webseite eingerichtet, die verschie-
dene E-Mail-Adressen mit einigen der hier beschriebenen Verfahren tarnt.
Die dafür verwendeten Domains wurden meinen Recherchen zufolge vorher
von keinem anderen verwendet. Insofern ist davon auszugehen, dass unter die-
ser Domain bis zum Start der Tests noch keine E-Mail-Adressen existierten, so
dass die Ergebnisse durch solche Effekte nicht verfälscht sind.
Auf einfachen Webseiten, habe ich entsprechend der obigen Vorschläge
codierte E-Mail-Adressen versteckt. Dabei waren die entsprechenden Berei-
che mittels geeigneter CSS für normale Besucher unsichtbar, um zu ver-
hindern, dass ein Mensch „versehentlich“ die Adressen liest und sie bei News-
lettern anmeldet.
Durch ebenso unsichtbare Verlinkung der Testseiten von vielen tausend Web-
seiten weltweit habe ich sichergestellt, dass möglichst viele Harvester die Sei-
ten besuchten. Das hat auch sehr gut geklappt. Durch die unsichtbaren Links
war gewährleistet, dass hauptsächlich automatische Suchprogramme auf die
Seite gelangten und nur wenig Menschen.
No Spam! 87
Um die Mailmenge zu dokumentieren, konfigurierte ich einen Mailserver so

um, dass er die eingehenden E-Mails sortiert nach der verwendeten E-Mail-
Adresse in eine Datenbank einträgt. Für jede Tarnmethode habe ich natürlich
eine gesonderte Mailadresse verwendet.
Der Test zeigte, dass im Klartext genannte E-Mail-Adressen bevorzugt be-
spammt werden. Das geschah unabhängig vom Kontext der Seite: Auch eine in
einem JavaScript-Bereich genannte Klartextadresse wurde bespammt.
Daraus lassen sich zwei Erkenntnisse über das Verhalten von Harvestern ablei-
ten:
1. Ob eine E-Mail-Adresse mit mailto: verlinkt ist oder im Klartext unmittel-
bar angegeben wird, ist unerheblich. Harvester scheinen nach Zeichenket-
ten vom Muster „zeichenfolge@zeichenfolge.tld“ zu suchen.
2. Harvester ignorieren den Kontext der Seite.
Als Konsequenz folgt, dass E-Mail-Adressen also keinesfalls unmittelbar ge-
nannt werden dürfen.
Interessant ist, dass auch an die per Entities getarnte Adresse Nachrichten ge-
schickt wurden. Offensichtlich machen sich Harvester bereits die Mühe,
HTML-Entities aufzulösen.
Die Ergebnisse stimmen mit den Ergebnissen aus [CDT03] überein. Spammer
sammeln offensichtlich die Adressen ihrer Opfer mittels Harvestern von Web-
seiten ab.
Die im Vergleich zu [CDT03] zusätzlich getesteten Verschlüsselungs- und
Tarnverfahren erwiesen sich als effizient – gleichzeitig hat sich aber auch ge-
zeigt, dass einfache Verfahren, die nur auf einer Zeichenersetzung beruhen,
wie die Tarnung via HTML-Entities, bereits jetzt unsicher sind. Es ist davon
auszugehen, dass in Zukunft bald alle Harvester damit umgehen können, wenn
diese Verfahren zunehmende Verbreitung finden. Das dürfte auch für URL-en-
coding gelten.
Das eigentlich einfache Verfahren, eine Mailadresse mit Leerzeichen aufzu-
blähen, hat sich als zuverlässiger Schutz erwiesen. Es dürfte sich auch tech-
nisch schwierig gestalten, es automatisch zu erkennen und zu entschlüsseln.
88
Test mit echten Harvestern
5.7 Test mit echten Harvestern

Um die Testergebnisse von oben zu bestätigen, habe ich auf einem Testrechner
voll funktionsfähige Demoversionen von vier kommerziell erhältlichen Har-
vestern installiert.
Abb. 5.4: Screenshot von Harvester 1
Abb. 5.5: Ergebnis von Harvester 2
No Spam! 89
Zwei der drei Programme (siehe Abbildung 5.4 und Abbildung 5.5) fanden nur
die im Klartext angegebenen E-Mail-Adressen. Dabei wurde scheinbar nur
nach dem Muster einer E-Mail-Adresse gesucht, nicht nach dem Link-Beginn
mailto:.
Die beiden anderen scheinen ausschließlich nach „mailto:“ gesucht zu haben:
Sie fanden nur derart verlinkte E-Mail-Adressen (Abbildung 5.6). So wurden
auch die verlinkten, getarnten Adressen entdeckt. Jedoch verfügten beide Pro-
gramme über keine Funktion, um die Entities bzw. die URL-Verschlüsselung
in den Klartext zurückzuführen.
Damit sind zwei der drei von diesen beiden Programmen gefundenen mutmaß-
lichen Mailadressen nicht als Zieladressen für Spam brauchbar, da die notwen-
dige Entschlüsselung in RFC-konforme Mailadressen nicht durchgeführt wur-
de, wie man in Abbildung 5.6 sieht. Allerdings ist der Entschlüsselungsschritt,
wie ich in Kapitel 5.4.4 gezeigt habe, trivial.
Das überrascht, denn eines der Programme wird damit beworben, dass es auf
den Internet Explorer aufsetzen würde und auch mit aufwendig und geschickt
getarnten Seiten keine Probleme habe.
Abb. 5.6: Ergebnis von Harvester 3
90
Test mit echten Harvestern
Im Ergebnis bestätigt sich dadurch der Test mit den Webseiten: Aufwendiger
getarnte Adressen werden nicht gefunden. Auch wurde die externe JavaScript-
Datei von keinem Programm nachgeladen.
Beide Tests bestätigen somit, dass die vorgestellten Verfahren zur Tarnung von
E-Mail-Adressen effizient sind und dass es unter dem Gesichtspunkt der
Spamprävention sinnvoll ist, keine mailto-Links zu verwenden.
No Spam! 91
6 Automatisch tarnen
[WHA01] schlägt für dynamisch generierte Webseiten vor, die Ausgabe der
E-Mail-Adresse abhängig vom Besucher unterschiedlich zu gestalten: Besucht
ein Harvester die Seite, soll keine Mailadresse ausgegeben werden, bei Men-
schen jedoch schon. Die Unterscheidung soll dabei anhand des gesendeten
User-Agent, einer Identifikation des Browsers, erfolgen.
[WHA01] stellt dazu fertige Java-Server-Pages zur Verfügung, die das grobe
Funktionsprinzip vorstellen sollen. Allerdings sind – wie er selbst in einer
E-Mail-Diskussion sagte – bei seiner Lösung noch einige Verbesserungen
denkbar, insbesondere wird bei Harvester-Verdacht stets ein Serverfehler
„HTTP 500“ zurückgemeldet, der auf eine Misskonfiguration des Webservers
hinweist. Dadurch wird zwar keine E-Mail-Adresse ausgegeben, aber ein legi-
timer Besucher der Seite erhält auch keine Informationen, sondern bekommt
den Eindruck, dass der Betreiber des Servers einen Fehler gemacht hat.
Zudem ist die Unterscheidung von Mensch und Harvester wie in dem von ihm
vorgelegten Vorschlag nur über den gesendeten User-Agent sehr fehlerträch-
tig: Schon der von mir oben beschriebene Minimal-Harvester auf wget-Basis
(Kapitel 3.2.1) meldet sich mit einem User-Agent, der keinen Verdacht erwe-
cken soll. Das ist ein Vorgehen, von dem anzunehmen ist, dass es dem Stan-
dard bei Harvestern entspricht. Das bestätigen auch meine Experimente mit re-
alen Harvestern und der Teergrube. Bis auf wenige Ausnahmen senden sie
unauffällige User-Agents.
Eine etwas elaboriertere Lösung, die jedoch auch nur anhand des User-Agent
eine Mensch-Maschine-Unterscheidung vornimmt, stellt [GUN04] vor. Er
blockiert die IP-Adresse des Harvesters automatisiert über eine stateless-Fire-
wall auf Basis von ipchains38. Die Firewall wird dabei dynamisch über ein in
Perl geschriebenes Apache-Modul aktualisiert.
Doch [GUN04] berichtet selbst, dass seine Sperrentscheidung ausschließlich
anhand des User-Agent bereits durch einen geeignet modifizierten Harvester
umgangen wurde.
38. Eine Einführung in die Verwendung von ipchains liefert z.B. [ZIE99]
No Spam! 93
6 – Automatisch tarnen
Dennoch hat die Idee ihren Reiz: Könnte man sicher Harvester von regulären
Benutzern unterscheiden, wäre es problemlos möglich, wieder seine E-Mail-
Adresse auf der Webseite zu veröffentlichen, ohne Gefahr zu laufen, Opfer von
Spam zu werden. Doch gerade an der sicheren Erkennung scheitert das Verfah-
ren. Der User-Agent beispielsweise ist nur bedingt geeignet: Er kann beliebig
manipuliert werden.
Möchte man weitere Verdachtsmomente nutzen, wie die Surfgeschwindigkeit
oder den Abruf von Bilddateien, stößt man schnell an die Grenzen des verbin-
dungslosen HTTP. Das Protokoll bietet keine Möglichkeit zur Identifizierung
zusammenhängender Zugriffe. Da Harvester zur Tarnung teilweise erhebliche
Zeitspannen zwischen zwei Zugriffen abwarten, müsste man zudem giganti-
sche Datenmengen durchsuchen.
Betrachtet man den Aufwand der Lösung, die sinnvoll mit gewichteten Krite-
rien arbeitet, ist man kurz davor, einen eigenen, maßgeschneiderten Webserver
entwickeln zu müssen, um eine halbwegs zuverlässige Lösung zu konstruieren
– oder man modifiziert z.B. den Apache-Webserver39. Den Aufwand wird
wohl kaum jemand ernsthaft betreiben wollen, zumal dann auch Sicherheits-,
Stabilitäts- und Kompatibilitätsfragen zu lösen sind.
Auch ist es häufig nicht möglich, auf einem angemieteten Webserver die Ser-
versoftware auszutauschen oder nach eigenem Bedarf zu erweitern. Somit
wäre eine solche Lösung nur für einen sehr kleinen Nutzerkreis tauglich.
6.1 Apache-Modul
Daher erscheint es einfacher, Webseiten standardmäßig mit getarnten Mail-
adressen auszuliefern. Dabei sollten alle Seiten, die vom Webserver aus-
geliefert werden, automatisch so verändert werden, dass die angezeigten
E-Mail-Adressen getarnt sind. Das sollte natürlich ohne Änderung der beste-
henden Seiten möglich sein und auch mit dynamisch generierten Seiten funk-
tionieren.
39. Ein verbreiteter, modular erweiterbarer OpenSource-Webserver. Zu finden unter http://

httpd.apache.org
94
Apache-Modul
Mit einem Apache-Modul40 lässt sich das realisieren: Apache bietet zusammen
mit mod_perl41 die Möglichkeit, Ausgabefilter42 zu schreiben. Diese Filter set-
zen im Ausgabestrom an und sehen alle Daten, bevor sie endgültig zum Client
gesendet werden. Dadurch können auch dynamisch generierte Seiten automa-
tisch modifiziert werden. Außerdem müssen die bestehenden HTML-Seiten
nicht verändert werden.
Da es sich dabei um einen Ausgabefilter handelt, funktioniert der Ansatz un-
abhängig vom Dateityp und damit auch mit dynamisch erzeugtem Inhalt. Der
Filter bearbeitet aber nur Ausgabedaten vom Typ „text/plain“ und „text/html“.
Ein solcher Filter kann nun mit regular expressions Mailadressen finden und
sie dann mit einem der oben beschriebenen Verfahren tarnen.
6.1.1 Installation
Das weiter unten vollständig dargestellte Script sollte auf einem Linux-System
in eines der Include-Verzeichnisse von Perl installiert werden, z.B. nach /usr/
lib/perl5/site_perl/MyApache. Der Dateiname muss ObMail.pm lauten. Wie
bei Perl-Modulen üblich, müssen Verzeichnisname und Dateiname dem Mo-
dulnamen entsprechen.
Um den Filter zu aktivieren, müssen in die Konfigurationsdatei des Apache die
folgenden Zeilen aufgenommen werden:
SetHandler modperl
PerlModule MyApache::ObMail
<Directory /var/www/html>
PerlOutputFilterHandler MyApache::ObMail
</Directory>
Nach einem Neustart des Apache wird jede Ausgabe, bevor sie zum Client ge-
sandt wird, durch diesen Filter geschickt. Der Webserver zerlegt dabei die
Ausgabe in speichergerechte Happen, sucht nach Zeichenketten, die eine
E-Mail-Adresse sein könnten, und ersetzt sie durch ihre getarnte Version.
40. Allgemein dazu: [STEI99]

41. Siehe dazu: [FÖR05]
42. Siehe auch: http://www.perl.com/lpt/a/2003/04/17/filters.html
No Spam! 95
6.1.2 Programmierzauber
Da der Eingabepuffer wahrscheinlich kleiner als der zu bearbeitende Daten-
strom ist, wird die Ausgabe in mehrere Teilen zerlegt bearbeitet. Diese Zerle-
gung übernimmt der Webserver unabhängig vom Inhalt. Dadurch kann es auch
passieren, dass eine Mailadresse getrennt wird.
Um Mailadressen korrekt zu erkennen, zerlegt daher der Ausgabefilter die Puf-
ferdaten anhand von Whitespaces: Eine E-Mail-Adresse enthält keine White-
spaces. Alle Zeichen nach dem letzten Whitespace werden abgetrennt und dem
nächsten Datenhappen vorangestellt. Das geschieht über die Variable $left-
over.
Dieser Überhang wird dem nächsten Puffer vorangestellt. Damit können
E-Mail-Adressen auch über Puffergrenzen hinweg gefunden werden.
Ein kleines Beispiel erläutert das. Sei „Die Adresse lautet user@“ der erste
Puffer und „example.com. Weitere Informat“ der Inhalt des Puffers im zweiten
Durchlauf. Dann wird in der ersten Runde „Die Adresse lautet“ aus dem Puffer
extrahiert und „user@“ nach $leftover verschoben. Für die zweite Runde wird
der Puffer „example.com. Weitere Informat“ vorne durch $leftover ergänzt, so
dass jetzt „user@example.com Weitere Informat“ im Puffer steht. Nun kann
der Filter eine E-Mail-Adresse eindeutig erkennen.
Für einen Angreifer könnte aber gerade dieser Zwischenspeicher eine geeig-
nete Angriffsfläche bieten: Schafft er es, einen Datenstrom einzuschleusen,
der keine Whitespaces enthält, wächst $leftover und damit auch der Puffer mit
der Zeit über alle Grenzen. Es entsteht ein so genannter Pufferüberlauf, der aus
Sicherheitssicht zu erheblichen Gefahren führen kann.
Um das zu verhindern, darf der Puffer maximal doppelt so groß werden wie die
eingestellte Pufferobergrenze. Wird er zu groß, wird der Pufferinhalt unverän-
dert ausgegeben. Dadurch könnten zwar Adressen versehentlich nicht getarnt
werden, aber dafür ist das System vor solchen Angriffen geschützt.
6.1.3 Tarnfunktion
Die gesamte Tarnung der Adresse findet in der Funktion obfuscate statt. Da-
durch können Sie das Script jederzeit einfach anpassen und andere Ersetzungs-
muster integrieren oder das verwendete Muster weiter verfeinern.
96
Apache-Modul
Die E-Mail-Adressen werden dabei von der regular expression in der While-
Schleife einzeln gefunden und stehen unmittelbar hinter dem Schleifenkopf in
der Variablen $1.
Im Beispiel wird die Adresse mit Leerzeichen aufgebläht, das Verfahren hat
sich wie oben dargestellt als besonders effektiv erwiesen.
6.1.4 Das Script selbst

Das folgende Script wurde mit Apache 2.0 und mod_perl 1.99 unter Fedora
Core 2 und Core 3 erfolgreich getestet. Es sollte allerdings auch mit anderen
Versionen zusammenarbeiten können. Vor einem Einsatz in einer Produk-
tivumgebung empfiehlt sich in jedem Fall ein gründlicher Test.
Zusätzliche Hinweise in Ergänzung zu den obigen Erläuterungen finden sich
in eingestreuten Kommentaren.
# Perl-Filter für Apache 2.0
#
# Zur automatischen Tarnung von E-Mail-Adressen.
#
# (c) 2004, 2005 Tobias Eggendorfer
package MyApache::ObMail;
use strict;
use warnings;
use Apache::Filter ();
use Apache::RequestRec ();
use APR::Table ();
use Apache::Const -compile => qw(OK DECLINED);
use constant BUFF_LEN => 10240;
# Die Groesse des Eingabepuffers ist die hauptsaechliche
# Determinante der Performance des Scripts. Sie sollte durch
# Tests z.B. mit ApacheBench individuell optimiert werden.
# Ein zu kleiner Puffer bremst unnoetig, ein zu großer
# erfordert swap-Speicher und bremst dadurch.
sub obfuscate
{
# Hier wird die Mailadresse verschluesselt
# Als Parameter wird ein Bufferinhalt übergeben, der
# möglicher Weise Mailadressen enthält.
my $line = shift;
No Spam! 97
my $mail_regexp = '[A-Za-z_0-9.-]+@([A-Za-z_0-9-]+\.)+[A-Za-z]{2,6}';
my $adr = undef;
while ( $line =~ /($mail_regexp)/g )
{
# Adresse in einzelne Zeichen zerlegen und
# dann mit Leerzeichen dazwischen wieder
# eintragen.
# Hier kann nach Bedarf ein anderes Verfahren
# eingesetzt werden. Die Adresse steht in $1.
$adr = join(' ',split(//,$1));
# Alle Vorkommen der Adresse in der Zeile

# ersetzen.
# Vorsicht: Wenn oben das Verfahren geaendert
# wurde und dort mit einer RegExp gearbeitet
# wurde, koennte $1 hier den falschen Wert haben!
$line =~ s/(.*)$1(.*)/$1$adr$2/gi;
} # end while mail_regexp
return $line;
}
sub handler
{
# Diese Funktion wird vom Apache aufgerufen
# und kuemmert sich um die blockweise
# Bearbeitung der Daten.
my $f = shift;
unless ($f->ctx)
{
# Nur beim ersten Besuch pruefen
unless ($f->r->content_type =~ m!text/(html|plain)!i )
{
# Nur Text-Daten bearbeiten
# Bei anderen Daten wird "abgelehnt" gemeldet.
return Apache::DECLINED;
} # end unless
# Wir veraendern die bereits berechnete Content-Length
# daher wird sie zurueckgesetzt.
$f->r->headers_out->unset('Content-Length');
} # end unless
98
Apache-Modul
my $leftover = $f->ctx;
while ($f->read(my $buffer, BUFF_LEN))
{
$buffer = $leftover . $buffer if defined $leftover;
if (length($buffer) > (2*BUFF_LEN))
{
# Zu lange keine Leerzeichen gefunden =>
# Gefahr eines Bufferoverflow.
$f->print(obfuscate($buffer));
$buffer = $leftover = "";
}
else
{
$buffer =~ /(.*)(\s\S*)\z/gs;
$leftover = $2;
$buffer = obfuscate($1);
$f->print($buffer);
} # end if bufferoverflow
} # end while read
if ($f->seen_eos)
{
# Dateiende erreicht - Rest ausgeben.
if (defined $leftover)
{
$leftover=obfuscate($leftover);
$f->print(scalar $leftover);
}
}
else
{
# Weitere Daten vorhanden, Rest an den
# naechsten Aufruf uebergeben.
$f->ctx($leftover) if defined $leftover;
} # end if
# Erfolgreiche Bearbeitung rückmelden
return Apache::OK;
}
1;
No Spam! 99
6.2 Tuning
Erwartungsgemäß bremst der Filter die Auslieferung von Webseiten. Zwar
werden Apache-Perl-Module mit mod_perl beim Start des Webservers kompi-
liert, so dass der Nachteil der interpretierten Sprache minimal ist, aber das
Analysieren des Ausgabestroms beansprucht auch Rechenzeit und Speicher-
platz.
Allerdings ist die Verzögerung selbst unter stärkster Belastung, wie man sie
mit dem in Apache 2.0 enthaltenen Benchmark Apache Bench simulieren
kann, bei üblichen HTML-Dateigrößen kaum messbar: In einem Test habe ich
1000 exakt parallele Zugriffe auf eine HTML-Datei simuliert, die Ausliefe-
rungszeit für eine kleine Webseite verlängerte sich von 1,5 ms auf 2,3 ms. Das
sind Schwankungen, die für normale Besucher nicht erkennbar sind, da zu vie-
le weitere Faktoren, wie die verfügbare Netzwerkbandbreite, hineinspielen.
Dabei lässt sich die Performance des Ausgabefilters noch sehr gut entspre-
chend des individuellen Systems tunen: Je nach Größe des Puffers, die in der
Konstanten BUFF_LEN eingestellt wird, schwankt die Zugriffszeit. Das liegt
einfach an der Speicherauslastung: Je größer der Puffer, desto mehr Speicher
muss der Filter belegen. Je öfter der Filter parallel läuft, das heißt je mehr pa-
rallele Zugriffe erfolgen, und je größer der Puffer, desto schneller ist der Ar-
beitsspeicher des Systems voll und der Server muss anfangen, Speicher auf die
langsame Festplatte auszulagern.
Das Ziel ist nun, durch Testen die für den eigenen Server und die Zugriffszah-
len optimierte Puffergröße zu ermitteln. Dazu sollten Sie sich zunächst überle-
gen, wie viel parallele Zugriffe Ihr Server abarbeiten muss.
Die Auslastung des eigenen Servers lässt sich leicht anhand der Logfiles
herausfinden: Viele Programme, die Webserver-Logs analysieren, geben
direkt die mittlere Anzahl paralleler Zugriffe aus.
Private Homepages haben kaum parallele Zugriffe – dazu sind die Zugriffs-
zahlen einfach zu gering. Hier bietet es sich an, Performance-Tests mit zehn
konkurrierenden Zugriffen durchzuführen, da ist dann schon genug Luft nach
oben enthalten. Anders sieht das bei großen Webportalen aus: Hier können
leicht mehrere tausend parallele Zugriffe erfolgen.
100
Tuning
Um den Puffer jetzt sinnvoll anzupassen, lohnt es sich, nachzusehen, wie viel
Speicher aktuell frei ist. Die Information liefert z.B. das Programm top oder
cat /proc/meminfo
Die Größe des freien Speichers dividiert durch die geschätzte Maximalzahl pa-
ralleler Zugriffe liefert dann einen ersten Anhalt für die Puffergröße. Bei z.B.
25 MByte freiem Speicher und 1000 parallelen Zugriffen wäre ein erster Test-
wert 25 KByte.
Mit dem Wert und Apache Bench lässt sich dann die mittlere Zugriffszeit be-
stimmen. Jetzt heißt es, alternative Werte zu testen. Dabei macht es Sinn, zu-
nächst in jeder Richtung mit 5 und 10 KByte zusätzlichem oder verkleinertem
Puffer zu testen, daraus lässt sich häufig schon die Richtung ableiten.
Dabei machen Puffergrößen über 64 KByte praktisch selten Sinn: Die wenigs-
ten HTML-Dateien sind größer. Wenn die Seite sowieso schon komplett in den
Puffer passt, dann ist auch durch einen größeren Puffer kein Performancege-
winn mehr zu erwarten.
Auf meinem Testsystem war eine Puffergröße von 10 KByte optimal. Wurde
die Größe z.B. auf 1 KByte verkleinert, benötigte der Benchmark etwa fünfmal
mehr Zeit. War jedoch eine größere Puffergröße von 20 KByte eingestellt,
musste mein Testsystem bereits swappen und verlor durch die Festplattenzu-
griffe Leistung – die Laufzeit des Benchmark verlängerte sich um etwa den
Faktor 10.
Wichtig ist, dass nach jeder Änderung der Puffergröße der Apache selbst neu
gestartet werden muss, da das Perl-Modul kompiliert im Speicher liegt und
Änderungen in der Datei selbst sonst nicht erkannt werden.
Insgesamt lässt sich durch geschicktes Tuning die Verzögerung, die durch den
Filter zwangsläufig entsteht, so weit reduzieren, dass Besucher der Seite sie
nicht mehr bemerken. Da der Filter sich auch um dynamisch, z.B. mit PHP
oder Perl, erzeugte Seiten kümmert, ist der minimale Performance-Verlust im
Verhältnis zum erzielten Spamschutz leicht vertretbar.
No Spam! 101
7 Missbrauch fertiger Scripten
Auf fast allen Webseiten findet sich mindestens ein serverseitiges Script: sei es
entweder ein Kontaktformular, die Send-To-A-Friend-Funktion oder ein
Grußkarten-Script. Alle diese Scripte können unter Umständen als Spamming-
Engines verwendet werden, also als Hilfsmittel, um Spam unerkannt zu ver-
senden.
Die Problematik der Grußkarten ist in etwa der Send-To-A-Friend-Funktion
vergleichbar – in beiden Fällen wird ein Teil der Webseite einem Dritten wei-
terempfohlen: einmal in Form einer elektronischen Postkarte, im anderen Fall
als Hinweis, dass diese Seite einen interessanten Beitrag enthält. Send-To-A-
Friend findet sich entsprechend bei zahlreichen Online-Shops unter dem Be-
griff „Einem Freund empfehlen“ oder bei Online-Magazinen.
In beiden Fällen kann eine Mitstörerhaftung43 des Seitenbetreibers an über die-
se Funktionen versandtem Spam entstehen, da der Seitenbetreiber Nutznießer
der E-Mail-Werbung ist: Seine Seite wird beworben. Böswillige Zeitgenossen
können also den Betreiber einer Seite massiv schädigen, indem sie gezielt als
spammerfeindlich bekannte Personen anschreiben und dann abwarten, dass
eine Unterlassungsklage eingereicht wird. In einem der in Fußnote 43 zitierten
Urteile wurde dem Kläger dann auch eine Nachricht mit dem viel sagenden
Text „mit spammenswerten Grüßen“ zugesandt, wie man im Urteilstext nach-
lesen kann.
Man mag das als mut- und böswillig bezeichnen, vielleicht auch den Verdacht
eines „Abmahnwahns“ unterstellen, andererseits ist ein solches Script tatsäch-
lich hervorragend zu missbrauchen, um völlig anonym Spam zu versenden. Es
erfüllt also die gleiche Funktion wie ein Open Relay oder ein Open Proxy. In-
sofern ist verständlich, dass einem solchen Treiben durch die entsprechende
Unterlassungsverfügung Einhalt geboten werden soll.
43. Siehe dazu u.a.: LG München I, Urteil vom 5.11.2002, Az: 33 O 17030/02, LG München
„Milch macht schön“, Urteil vom 15.04.2003, Az: 33 O 5791/03, OLG München, Urteil
vom 12.02.2004, AZ: 8 U 4223/03, AG Hamburg, Urteil vom 04.03.2003, Az.: 36A C 37/
03, LG Rostock, Beschluss vom 24.06.2003, Az.: 1 S 49/03 zu AG Rostock, Urteil vom
28.01.2003, Az.: 43 C 68/02
No Spam! 103
7 – Missbrauch fertiger Scripten
Genau das Gleiche gilt für schlecht programmierte oder fehlerhaft konfigurier-
te Kontaktformulare, die für den Versand von Spam missbraucht werden kön-
nen. So ermöglichen es manche Formmailer, Dritte in CC zu nehmen oder las-
sen sich gar als Versandprogramm für Spam missbrauchen.
Möglichkeiten, die eigenen Scripten vor solchem Missbrauch zu schützen und
seine Seite so zu gestalten, dass auch Online-Grußkarten versandt werden kön-
nen, stelle ich im Folgenden vor.
7.1 Missbrauch von Kontaktformularen

Ein Kontaktformular besteht typischerweise aus mehreren Eingabefeldern, in
die der Absendername, die E-Mail-Adresse des Absenders, ein Subject und die
Nachricht eingetragen werden können. Die Daten werden per HTTP zum Ser-
ver übertragen, wo ein PHP oder Perl-Script aus ihnen eine E-Mail erzeugt und
an eine definierte Adresse versendet. Dieses Script wird in Anlehnung an das
bekannte formmail.pl, das unter http://www.scriptarchive.com/formmail.html
zum Download bereitsteht (von Matt Wright gerne „Formmailer“ genannt).
7.1.1 Empfänger als INPUT TYPE HIDDEN

Die erste Schwachstelle bei vorgefertigten Formmailern ist deren Flexibilität:
Häufig wird das Script über zusätzliche, versteckte Eingabefelder in der
HTML-Seite konfiguriert. Dort wird häufig auch der Empfänger der Nachrich-
ten eingetragen.
Dieser Eintrag ist sehr einfach zu manipulieren: Entweder lädt man sich die
Datei auf den eigenen Rechner herunter und ersetzt dort die Zieladresse und
korrigiert den ACTION-Parameter des Forms oder man manipuliert die Seite
direkt „im Internet“. Dazu bietet sich z.B. der DOM-Inspector von Mozilla an.
Abbildung 7.1 zeigt die Manipulation eines Formulars am Beispiel des Bei-
spiel-Kontaktformulars in Kapitel 8.2. Dort wird das verdeckte Eingabefeld
„HTTP_VARS“ manipuliert. Analog könnte auch dort eine eingetragene
E-Mail-Adresse ersetzt werden und damit der Inhalt des Formulars an einen
Dritten gesandt werden.
Allerdings dürfte es relativ aufwendig sein, über diese Schwachstelle automa-
tisiert zu spammen.
104
Missbrauch von Kontaktformularen
Abb. 7.1: Manipulation des Beispielkontaktformulars

mit dem DOM-Inspector
Andererseits ist der Aufwand zur Behebung minimal: Das in Kapitel 5.2.1 vor-
gestellte Beispiel-Formmail-Script in PHP verwendet anstatt der E-Mail-
Adresse des Empfängers eine eindeutige Identifikationsnummer. Modifiziert
No Spam! 105
die ein Angreifer, erreicht er entweder niemanden oder einen anderen eingetra-
genen Empfänger. Insofern wird dadurch der potenzielle Schaden begrenzt, zu-
dem verschwindet eine nicht verschlüsselte E-Mail-Adresse aus der Webseite.
7.1.2 Nutzereingabe im From-Feld

Häufig wird als Absender vom Formmailer die vom Surfer eingetragene
E-Mail-Adresse eingesetzt. Zusammen mit einer Manipulation des Adressaten
kann so Spam über Bounces generiert werden: Eine fehlerhafte Empfänger-
adresse (oder auch nur ein Problem auf dem Server des Empfängers) führt zu
einer Fehlermeldung, die dem Opfer, dessen Adresse als From-Adresse einge-
geben wurde, zugestellt wird.
Daher sollte der From-Header, so wie im Beispiel-Formmail-Script, mit einer
definierten Adresse des Serverbetreibers im Script vorbelegt werden. Das hat
allerdings den Nachteil, dass zum Beantworten einer Nachricht, die über das
Formular versandt wurde, die eingegebene E-Mail-Adresse des Absenders aus
dem Body der Mail herauskopiert werden muss.
7.1.3 Nutzereingabe sonstiger Header-Felder

Offensichtlich spamfreundlich ist die unmittelbare Eingabe eines Cc- oder
Bcc-Felds. Daher dürfen diese Felder im Beispiel-Formmail-Script ebenfalls
nur mit den eindeutigen Identifikationsnummern belegt werden.
Genauso ist ein Subject-Feld ein möglicher Angriffsort: Häufig wird das Sub-
ject als Mail-Subject in den Header der Mail übernommen. Schafft der Angrei-
fer es nun, in das Subject einen Zeilenumbruch einzutragen, kann er problem-
los eine zusätzliche Header-Zeile einfügen.
Am einfachsten geht das Einfügen von Zeilenumbrüchen, indem der Angreifer
die Webseite notfalls lokal so modifiziert, dass anstelle eines einzeiligen Ein-
gabefelds ein mehrzeiliges Eingabefeld verwendet wird. Der Angreifer muss
also
<input type="text" name="beispiel"/>
durch
<textarea name="beispiel"></textarea>
ersetzen.
106
Missbrauch von eCards
Um einen solchen Angriff zu erschweren, entfernt der Beispiel-Formmailer

sämtliche Zeilenumbrüche aus dem Subject, obwohl das in der aktuellen Ver-
sion der PHP-Funktion mail() nicht notwendig ist: Sie eliminiert selbständig
Zeilenumbrüche. Allerdings findet sich der Fehler häufig in Perl-Scripten,
weshalb hier bewusst etwas zu restriktiv programmiert wurde.
Zusätzlich verkürzt der Formmailer das Subject auf maximal 60 Zeichen.
Letzteres soll im Wesentlichen Probleme mit Mailclients verhindern, die mit
Längenobergrenzen für Subjects arbeiten und zudem die Darstellung der Mails
in einer Liste im Mailclient übersichtlicher gestalten.
7.1.4 Zusammenfassung
Diese typischen Angriffsmöglichkeiten finden sich in zahlreichen fertigen
Kontaktformularen wieder, teilweise auch in den von Providern im Rahmen
von „Standard-CGIs“ bereitgestellten Formularen, was aus haftungsrecht-
licher Sicht interessante Fragen aufwirft – dazu allerdings mehr bei
[SCHOE04].
Sind die typischen Angriffsszenarien bekannt, lassen sie sich relativ einfach
blockieren – das zeigt das Script in Kapitel 5.2.1.
Um zu verhindern, dass ein Kontaktformular von einem Programm genutzt
wird, wird häufig der Einsatz eines Verfahrens empfohlen, das einen Mensch
von einer Maschine unterscheidet. Nur Menschen können und dürfen das For-
mular dann verwenden. Eine Auswahl solcher Verfahren stellt [CAPTCHA]
vor. Allerdings arbeiten die meisten dieser Verfahren mit der Anzeige von Bil-
dern, so dass Sehbehinderte in aller Regel von der Nutzung ausgeschlossen
werden.
Zudem sind findige Spammer bereits auf die Idee gekommen, die Auswahlfra-
gen, die im Rahmen solcher Mensch-Maschine-Überprüfungen gezeigt wer-
den, auf anderen Seiten als Preisausschreiben einzustellen und somit ahnungs-
lose Dritte als Helfer einzusetzen.
7.2 Missbrauch von eCards

Elektronische Postkarten können unmittelbar an einen beliebigen Empfänger
gesandt werden. Das macht sie für Spammer äußerst nützlich: Lassen sich sol-
che Postkarten scriptgesteuert versenden, ist der Spammer hervorragend ge-
tarnt.
No Spam! 107
Es wurden bereits verschiedene Verfahren erdacht, die diesen Missbrauch ver-

hindern sollen. Typischerweise wird vom Seitenbetreiber eine Nutzerregistrie-
rung gefordert, ohne die kein Versand möglich ist. Gibt es später Beschwer-
den, lässt sich darüber zudem der Schädiger identifizieren, so dass gegen ihn
vorgegangen werden kann.
Gleichzeitig kann der Anbieter bestimmten, unerwünschten Nutzern den Zu-
gang zu seiner Seite verwehren. Allerdings ist das nur eine Krücke, schließlich
lässt sich – wie auch das Wikipedia-Projekt zeigt – kaum sicherstellen, das
sich Vandalen nicht wieder unter einem anderen Nutzernamen erneut anmel-
den. Gerade da die Täter häufig mit dynamisch vergebenen IP-Adressen arbei-
ten, lässt sich kein wirkungsvoller Schutz realisieren. Auch feste IP-Adressen
lassen sich über Anonymisierdienste wie den Java Anonymous Proxy der TU
Dresden (http://anon.inf.tu-dresden.de) leicht verstecken, um IP-basierte
Sperren auszuhebeln. Wie das funktioniert, beschreibt z.B. [EGG05g].
Es bedarf also einer Lösung, die sicherstellt, dass eCards nicht zum Spammen
missbraucht werden können. Ein Grundprinzip dafür hat der bekannte Münch-
ner Anwalt Freiherr Günther von Gravenreuth44 unter anderem in einem Ver-
fahren vor dem AG München beschrieben: Er schlägt vor, den Versender der
eCard diese auch tatsächlich selbst aus seinem Mailprogramm absenden zu
lassen, wodurch sich das Haftungsproblem des Webseitenbetreibers von selbst
löst, da dieser kaum für die Kommunikation Dritter verantwortlich gemacht
werden kann.
Die Idee dahinter ist einfach: Der Anwender wählt wie üblich zunächst die ge-
wünschte Postkarte aus, gibt die Namen von Absender und Empfänger und die
Nachricht ein und klickt auf Senden. Anstatt jedoch vom Server eine E-Mail
generieren zu lassen, wird eine neue Webseite ausgegeben, auf der ein Link an-
gegeben ist. Diesen Link muss der Absender von Hand in eine E-Mail kopie-
ren, die er mit seinem eigenen Mailprogramm versendet.
Der Empfänger klickt in der E-Mail den Link an. Ein serverseitiges Script lie-
fert dann seine Karte aus, genauso wie bei jeder anderen Grußkarte auch. Für
den Empfänger ist diese Lösung also völlig transparent. Als Nebeneffekt bleibt
es ihm erspart, dass seine Adresse auf einer unbekannten Webseite eingetragen
wird und dort möglicherweise in die Hände von Spammern gelangt.
44. Dessen Webseite sich unter http://www.gravenreuth.de findet.
108
Ein Script, das die Grundfunktionalität dieser Lösung realisiert, möchte ich Ih-
nen hier vorstellen. Dieses Script stellt ein Grundgerüst für den Versand von
spamfreien eCards zur Verfügung und bietet noch genügend Raum für eigene
Erweiterungen.
7.2.1 Hinweise zur Umsetzung
Nutzer-freundlich
Da Mailprogramme Zeilen im Allgemeinen nach spätestens 72 Zeichen um-
brechen, wie es unter anderem [RFC0821] und [RFC1855] empfehlen, sollte
der ausgegebene Link kürzer sein, damit der Empfänger der Nachricht sich
nicht die Mühe machen muss, den Link manuell zusammenzusetzen. Das er-
reicht man am einfachsten, indem das Script im DocumentRoot eines virtuel-
len Webservers läuft, den man gegebenenfalls mit einer eigenen Subdomain
wie z.B. cards.example.com einrichten kann.
Die Abholkennung sollte auch möglichst kurz sein, darf aber nicht vorhersag-
bar sein. Im Beispiel wird als Schlüssel ein md5-Hash verwendet, der schwer
vorherzusagen und mit 32 Zeichen auch ausreichend lang ist, um selbst dem
geduldigsten Ratespielfan den Spaß zu nehmen.
Eine geeignete Adresse nach diesem Muster wäre dann z.B. mit exakt 70 Zei-
chen Länge:
http://cards.example.com/cards.php?id=12345678901234567890123456789012
Admin-freundlich
Nicht nur das Leben des Besuchers soll leicht sein, sondern auch das des Ad-
mins. Schließlich ist die Pflege des eigenen Webservers aufwendig genug, da-
her findet das Script neue Bilder automatisch und stellt sie als Postkarte zur
Verfügung. Es reicht also aus, ein neues Bild in das Bildverzeichnis zu kopie-
ren.
Die Erkennung ist in der Funktion list_pics() implementiert. Sie sucht in einem
bestimmten Verzeichnis (Konstante IMG_PATH) alle Bilddateien und liefert
sie als Liste zurück.
Dazu nutzt sie das PHP-Objekt dir, mit dem ein Verzeichnis vollständig auf-
gelistet werden kann. Den jeweils nächsten Eintrag liefert die Funktion read().
No Spam! 109
Wenn kein Eintrag mehr vorhanden ist, wird false zurückgegeben. Damit läuft
die while-Schleife genau so lange, bis alle Dateien gefunden wurden. In der
Schleife wird zusätzlich überprüft, ob es sich bei der gefundenen Datei um ein
Verzeichnis handelt.
Mit der Funktion eregi, die reguläre Ausdrücke unabhängig von der Groß- und
Kleinschreibung prüft, testet die Funktion dann, ob die gefundene Datei ein
Bild ist. Was ein Bild ist, steht in der Konstanten IMG_TYPE. Für diese Prü-
fung wird eine regular expression verwendet, die die Dateiendung mit einer
vorgegebenen Liste von Dateiendungen von Bildern vergleicht.
Wurde ein Bild gefunden, liefert die PHP-Funktion GetImageSize die Höhe
und Breite in Pixel.
Grußkarten zwischenspeichern
Bis zur Abholung werden die Grußkarten auf dem Server in einer MySQL-Da-
tenbank zwischengespeichert. Der SQL-Befehl zum Anlegen der notwendigen
Tabelle lautet:
CREATE TABLE karten (id varchar(32) NOT NULL default '!' PRIMARY KEY,
von varchar(40) NOT NULL default '', an varchar(40) NOT NULL default
'', pic varchar(255) NOT NULL default '', dat date NOT NULL default
'0000-00-00', msg text NOT NULL);
Die Datenbank wird in der Konstanten DB_NAME eingetragen, Nutzername
und Passwort in DB_USER bzw. DB_PASS.
Nach einer bestimmten Frist (Konstante DAYS) werden die Karten auto-
matisch gelöscht.
Das Eintragen der Karte erledigt die Funktion save_card(). Sie versucht, SQL-
Injections45 durch mysql_real_escape_string zuvorzukommen, und verhindert
die Vergabe doppelter Kartennummern.
Es ist zwar sehr unwahrscheinlich, dass zwei Karten den gleichen md5-Hash
haben, denn die Wahrscheinlichkeit dafür, einen md5-Hash zu finden, der
identisch ist mit einem bereits vorhandenen, beträgt rechnerisch 3∗10–39.
Reicht es aus, dass der md5-Hash mit einem beliebigen anderen, bereits vor-
handenen md5-Hash identisch ist, hängt die Trefferwahrscheinlichkeit von der
45. Dazu z.B.: [PEI04] oder auch [SHI05]
110
Menge der bereits vorhandenen Datensätze ab. Wie Sie die Wahrscheinlichkeit
berechnen können, finden Sie in zahlreichen Stochastik-Büchern unter dem
Stichwort „Geburtstagsparadoxon“ erläutert. Auch Wikipedia (http://www.wi-
kipedia.de) bietet dazu einen sehr gut erklärten Artikel.
Praktisch ist es bei md5-Hashes trotzdem notwendig, dass sehr viele Karten in
der Datenbank abgelegt sind, damit die Wahrscheinlichkeit für eine doppelte
Karten-Id relevante Größenordnungen erreicht. Theoretisch kann es aber pas-
sieren und würde dann zu einer unschönen Fehlermeldung führen. Möchte
man Software ordentlich entwickeln, sollte man zumindest versuchen, alle
Fehlerquellen, die theoretisch denkbar und dem Entwickler bewusst sind, aus-
zuschließen – es bleiben noch genügend, die man trotzdem übersieht und dann
später Ursache gravierender Sicherheitslöcher sein können.
Daher und um jedes Restrisiko auszuschließen, prüft die Funktion „save_card“
zusätzlich nach, ob die neue Id bereits in der Datenbank vorkommt. Dazu nutzt
sie aus, dass die Id in der Datenbank als Primärschlüssel verwendet wird.
Was ein Primärschlüssel ist, erläutert ausführlich [EGG05]. Ganz allgemein
gilt: Er muss eindeutig sein, es darf auf keinen Fall zweimal den gleichen Pri-
märschlüssel in einer Datenbanktabelle geben. Damit muss die Karten-Id in
ihrer Tabelle eineindeutig sein. Wenn das nicht der Fall ist, also eine doppelte
Karten-Id vergeben wurde, liefert MySQL beim Einfügen eine Fehlermeldung
zurück, den Fehler 1062.
Wenn dieser Fehler aufgetreten ist, wird eine neue zufällige Karten-Id gene-
riert und ein neuer Eintrageversuch unternommen. Diese Prüfung und das ge-
gebenenfalls notwendige Erzeugen einer neuen Karten-Id werden in der Do-
While-Schleife so lange wiederholt, bis eine eindeutige Karten-Id gefunden
wurde. Da die Wahrscheinlichkeit schon für eine doppelte Karten-Id äußerst
gering ist, ist es praktisch unwahrscheinlich, dass bei mehreren Versuchen hin-
tereinander doppelte Karten-Ids erwischt werden, zumal sie dank ihres Be-
rechnungsverfahrens nicht vorhersagbar sind. Dennoch könnte das Programm
an dieser Stelle in eine Endlosschleife geraten, wenn es immer wieder bereits
vorhandene Karten-Ids generiert. Wegen des großen Vorrats an solchen Ids
müsste dafür allerdings jeder Mensch mehrere Milliarden Karten versenden,
was als unrealistisch angenommen werden kann. Möchten Sie auch für diesen
Fall – ganz im Sinne einer ordentlichen Software-Entwicklung – vorsorgen,
dann müsste die do-while-Schleife um eine zusätzliche Abbruchbedingung er-
gänzt werden, die beispielsweise nach zehn Schleifendurchläufen greift. Diese
No Spam! 111
Fehlersituation muss dann allerdings auch im weiteren Programmablauf abge-

fangen werden.
Das Gegenstück zu save_card() ist get_card(). Mit der Funktion wird die Karte
wieder aus der Datenbank geholt. Das ist wesentlich weniger spektakulär. Die
Karte wird beim Abholen nicht automatisch gelöscht. Das ist auch sinnvoll,
denn so kann sie der Absender mehrmals anschauen – aber auch der Empfän-
ger.
Löschen alter Karten

Sollte das Script häufig genutzt werden, besteht deshalb irgendwann die Ge-
fahr, dass die Datenbank überläuft. Schließlich wird jede jemals versandte
Karte eingetragen. Damit das nicht passiert, wird in der Datenbank mitproto-
kolliert, wann die Karte angelegt wurde. Nach Ablauf der in der Konstanten
DAYS festgelegten Zeit werden Karten gelöscht. Diese Aufgabe übernimmt
die Funktion clean_db().
Hauptprogramm
Im Hauptprogramm wird anhand der Übergabeparameter entschieden, was zu
tun ist. Wurde z.B. eine Karten-Id übergeben, dann möchte der Nutzer sehr
wahrscheinlich eine Karte abholen. Wurden Inhalte einer Karte übergeben,
dann soll sie wohl angelegt werden und ohne alle Parameter wird angeboten,
eine neue Karte zu erstellen.
Das Script geht davon aus, dass eine neuere PHP-Version zum Einsatz kommt,
bei der aus Sicherheitsgründen die globale Einstellung register_globals auf off
gesetzt ist. Damit können Übergabeparameter nicht mehr wie normale Variab-
len verwendet werden, sondern müssen aus einem assoziativen Array zunächst
ausgelesen werden. Das senkt das Risiko, dass durch fehlerhafte Variablenin-
itialisierung Sicherheitslöcher46 entstehen.
Verbesserungen und Erweiterungen

Für den Produktiveinsatz sollte auf alle Fälle eine ordentliche Fehlerbehand-
lung ergänzt werden, so dass der zuständige Webmaster mitbekommt, dass
etwas nicht funktioniert. Momentan führen Fehler nur zu einem Abbruch des
46. Siehe dazu: http://de3.php.net/manual/de/security.registerglobals.php
112
Scripts. Außerdem müssen die Eingabedaten auf Zulässigkeit geprüft werden.

Entsprechende Hinweise sind jeweils als Kommentare im Script enthalten.
Die Benutzeroberfläche ist bewusst minimalistisch, lässt sich aber schnell
durch den Einsatz von CSS aufpeppen. Optisch schön wäre außerdem bei grö-
ßeren Bildmengen eine thematische Gruppierung der Bilder in Unterverzeich-
nissen, in denen dann automatisch wie in list_pics() gesucht wird. Auch eine
mehrseitige Darstellung bei sehr vielen Bildern wäre wünschenswert, um dem
Nutzer kilometerlanges Scrollen zu ersparen.
Auch aus Sicherheitssicht besteht noch Potenzial für Verbesserungen: Einmal
kann ein Kartenschreiber HTML- und JavaScript-Code in seine Karte ein-
schleusen, der unter Umständen die Darstellung der zugehörigen Webseite
stört oder eine so genannte Cross-Site-Scripting-Attacke ermöglicht. Zum an-
deren wird nicht überprüft, ob das angegebene Bild wirklich auf dem Server
existiert und eine Bilddatei ist. Damit besteht die Gefahr, dass ein Angreifer
fremde Bilder oder gar Scripte in die Grußkarte einschleust.
Das Script
<?
/* *****************************************************************
Spamfreie Grusskarten in PHP
(c) 2004, 2005
*****************************************************************
*/
/* Konfiguration
*/
/* Einstellungen fuer die Datenbank
*/
define(DB_NAME,"karten"); /* DB-Name */
define(DB_HOST,"localhost"); /* MySQL-Server */
define(DB_PORT,"3306"); /* MySQL-Server-Port */
define(DB_USER,"karten"); /* MySQL-User */
define(DB_PASS,"gruss"); /* und sein Passwort */
define(DB_TAB,"karten"); /* verwendete Tabelle */
/* weitere Einstellungen
*/
define(IMG_PATH,"./images/"); /* rel. Pfad zu den Bildern */
No Spam! 113
define(IMG_TYPE,"jpg|jpeg|gif"); /* was sind "Bilder" */

define(DAYS,5); /* Wieviel Tage bleibt eine Karte
gespeichert? */
/* Funktionen
*/
function send_http_header()
/* Sendet im Header, dass die Seite nicht
gecached werden darf.
*/
{
} // end function
function connect_db()
/* Stellt Verbindung zur DB her.
Im Fehlerfall brutal: die().
Rueckgabewert: conn_id
*/
{
$connid = mysql_connect(DB_HOST.":".DB_PORT,DB_USER,DB_PASS);
if ($connid==0)
{
/* Fehlerbehandlung einsetzen!
*/
die ("Fehler (1) aufgetreten.");
} // end if
if (!mysql_select_db(DB_NAME))
{
- mysql_errno($connid)
- mysql_error($connid)
*/
die ("Fehler (2) aufgetreten.");
} // end if
return $connid;
114
} // end function
function list_pics()
/* Erzeugt eine Liste der Bilder mit
- Dateiname
- Width
- Height
*/
{
$folder = dir(IMG_PATH);
unset($piclist);
while ($entry = $folder->read())
{
if ((!(is_dir($entry))) && (eregi("\.(".IMG_TYPE.")$",$entry)))
{
$pic[0] = $folder->path.$entry;
$tmparr = @GetImageSize($folder->path.$entry);
/* Mögliche Fehler abfangen! */
$pic[1] = $tmparr[0];
$pic[2] = $tmparr[1];
$piclist[] = $pic;
} // end if
} // end while
return $piclist;
} // end function
function save_card($from, $to, $pic, $msg)
/* Traegt eine Karte in die Datenbank ein.
Rueckgabewert: Id der Karte oder
FALSE wenn Eintragen fehlschlug.
*/
{
global $connid; /* Datenbankverbindungsid */
/* Zeichenketten f_r die Query escapen.
Bei 4.0.3 < PHP < 4.3.0 stattdessen:
mysql_escape_string(string)
verwenden.
*/
$qfrom = mysql_real_escape_string($from);
$qto = mysql_real_escape_string($to);
$qmsg = mysql_real_escape_string($msg);
$qpic = mysql_real_escape_string($pic);
No Spam! 115
/* Eindeutige Id erzeugen, die nicht

vorhersagbar ist.
*/
$id = md5($from.",".$to.",".$msg);
do
{
/* md5 ist potentiell nicht eindeutig!
*/
$query = "INSERT INTO ".DB_TAB.
" (id, von, an, pic, msg, dat) VALUES (".
"\"".$id."\",".
"\"".$qfrom."\",".
"\"".$qto."\",".
"\"".$qpic."\",".
"\"".$qmsg."\",".
"\"".date("Y-m-d")."\")";
$res = mysql_query($query);
$errno = mysql_errno($connid);
if ($errno == 1062)
{
/* Doppelter Primaerschluessel
=> Neue Id berechnen
*/
$id = md5($from.",".$to.",".$msg.",".
uniqid(rand(), true));
} // end if $errno == 1062
} while ($errno == 1062);
$id = ($res === FALSE) ? FALSE : $id;
return $id;
}
function get_card($id)
/* Holt Karte mit Id aus der Datenbank.
Rueckgabewert: Array mit (From, To, Pic, Msg),
wenn Karte vorhanden, sonst false.
*/
{
116
/* $id: Eingabeparameter, also escapen. Siehe

auche save_card().
*/
$qid = mysql_real_escape_string($id);
$query = "SELECT von, an, pic, msg FROM ".DB_TAB.
" WHERE id = \"".$qid."\"";
if ($res === FALSE)
{
- mysql_errno($connid);
- mysql_error($connid);
*/
die("Fehler (4) aufgetreten.");
}
$row = mysql_fetch_assoc($res);
mysql_free_result($res);
return $row;
}
function clean_db()
/* Loescht alte Karten aus der Datenbank
*/
{
$query = "DELETE FROM karten WHERE dat < \"".

date("Y-m-d", mktime(0, 0, 0,
date("m"),date("d")-DAYS,date("Y"))).
"\"";
if ($res === FALSE)

{
- mysql_errno($connid);
- mysql_error($connid);
*/
die("Fehler (5) aufgetreten.");
}
No Spam! 117
/* Hauptteil
*/
/* Variablen initialisieren.
*/
$abholen = false;
$eingetragen = false;
$ueberschrift = "Karte versenden";
$nachricht = "<p>Bitte wählen Sie die Karte ".
"unten.</p>";
/* _bergabeparameter abfragen.
Annahme: register_globals off
*/
$card_id = $_REQUEST["id"];
$send = $_REQUEST["send"];
$from = $_REQUEST["from"];
$to = $_REQUEST["to"];
$msg = $_REQUEST["msg"];
$pic = $_REQUEST["pic"];
$connid = connect_db();
clean_db();
if (isset($card_id) && ($card_id != ""))
{
/* Nutzer moechte Karte abholen.
*/
$abholen = true;
$karte = get_card($card_id);
$ueberschrift = "Karte abholen";
$nachricht = "";
}
if (isset($send) && ($send == "yes"))
{
/* Achtung! Keine Sicherheitspruefung
der Eingabedaten. Sollte durchgefuehrt
werden!
118
Insbesondere:
a) Steht in $pic ein gueltiger
Dateiname eines Bildes?
b) Enthaelt $msg, $from oder $to
HTML-Tags?
*/
$card_id = save_card($from, $to, $pic, $msg);
$eingetragen = ($card_id !== FALSE);
if ($eingetragen === TRUE)
{
$ueberschrift = "Karte eingetragen.";
$nachricht = "<p>Senden Sie den Link unten dem ".
"Empfaenger per Mail. Er kann ".
"sich damit die Karte abholen.</p>".
"<p><A HREF=\"?id=".$card_id."\">".
"http://".$HTTP_HOST.
$SCRIPT_NAME."?id=".$card_id."</A></p>".
"<p>Ihre Karte ist unten nochmal ".
"angezeigt.</p>";
$karte = get_card($card_id);
}
else
{
$ueberschrift = "Fehler beim Eintragen.";
$nachricht = "<p>Fehler beim Eintragen.</p>";
}
}
mysql_close($connid);
/* Damit beginnt HTML-Ausgabe. Dort gibt

es drei grosse Richtungen:
- Karte abholen
- Karte versenden
- Karte eingetragen.
*/
send_http_header();
<html>
<head>
No Spam! 119
<title>Grusskarten-Service</title>

</head>
<body>
<h1><? print $ueberschrift; ?></h1>
<? print $nachricht; ?>
<hr>
<?
if (($abholen == true) || ($eingetragen == true))
{
?>
<table>
<tr>
<td><img src="<? print $karte["pic"]; ?>"></td>
<td><p>Von: <? print $karte["von"]; ?></p>
<p>An: <? print $karte["an"]; ?></p>
<p>Nachricht:</p>
<p><? print nl2br($karte["msg"]); ?></p>
</td>
</tr>
</table>
<p>Noch eine Karte <A HREF="<? print $SCRIPT_NAME; ?>">
senden?</p>
<?
}
else
{
/* Versenden.
*/
$pic_list = list_pics();
?>
<form method="post" action="<? print $SCRIPT_NAME; ?>">
<input type="hidden" name="send" value="yes">
<table>
<?
/* Ausgabe der Bilder
*/
120
for ($i=0; $i<count($pic_list); $i++)

{
?>
<tr>
<td><input type="radio" name="pic" value="<?
print $pic_list[$i][0]; ?>"></td>
<td><img src="<? print $pic_list[$i][0];
?>" width="<? print $pic_list[$i][1];
?>" height="<? print $pic_list[$i][2]; ?>"></td>
</tr>
<?
} // end for i
?>
</table>
<p>Geben Sie hier Ihre Nachricht ein.</p>
<table>
<tr>
<td>Von:</td>
<td><input type="text" name="from" maxlength="40"></td>
</tr>
<tr>
<td>An:</td>
<td><input type="text" name="to" maxlength="40"></td>
</tr>
<tr>
<td>Nachricht:</td>
<td><textarea wrap="virtual" name="msg"></textarea></td>
</tr>
</table>
<input type="submit" value="Senden">
</form>
<?
} // end if
?>
</body>
</html>
No Spam! 121
7.3 Send-To-A-Friend
Eine ähnliche missbrauchsichere Lösung lässt sich auch für die „send to a
friend“-Funktionalität konstruieren. Dabei wird dann ein geeigneter Mailto-Link
ausgegeben. So ist das beispielsweise bei Mobile.de (http://www.mobile.de)
gelöst. Dort enthielt die Funktion allerdings zum Zeitpunkt des Entstehens dieses
Buchs noch Fehler: Das Fragezeichen in einer URL mit GET-Parametern muss
geeignet codiert werden, da es in einer mailto-URL eine eigene Bedeutung hat.
Will man also die Empfehlung „Besuchen Sie die Seite http://www.examp-
le.com/?foo=bar“ aussprechen, sollte der zugehörige mailto-Link wie folgt
lauten:
mailto:subject=Eine%20Empfehlung&body%3DBesuchen%20Sie%20die%20Seite%
20http%3A//www.example.com/%3Ffoo%3Dbar
Nur dann wird auch der Link in der Mail unter allen Bedingungen korrekt wie-
dergegeben. Beachtet man diese Kleinigkeit nicht, schneiden ihn einige Mail-
programme ab dem Fragezeichen ab, was den GET-Parameter einleitet.
122
8 Harvester blockieren
Eine Möglichkeit, Harvestern und damit Spammern das Leben schwer zu ma-
chen, ist es, E-Mail-Adressen für solche Programme unlesbar auf Webseiten
anzugeben. Ein anderer Ansatz sieht vor, die Sammelgeschwindigkeit der Har-
vester zu reduzieren. Denn dann würden sich zum einen die benötigte Zeit,
zum anderen aber auch die Kosten zur Adressgewinnung durch die Spammer
deutlich erhöhen.
Als Nebeneffekt kann man, hält man Harvester überdurchschnittlich lange auf
einer Seite fest, erreichen, dass sich die High-Ports des Clients47 zuziehen und
der Harvester auch andere Seiten außer der eigenen nicht absuchen kann. Man
erreicht also einen doppelten Nutzen48.
8.1 Anforderungen
Die wesentliche Idee ist, den Harvester in einer Endlosschleife zu fangen, die
zusätzlich die Webseite nur extrem verzögert ausliefert. Idealerweise soll die
Falle so konstruiert sein, dass sich der Harvester in ihr für immer verfängt.
Diese Anforderung lässt sich einfach realisieren durch ein Script, das eine
HTML-Seite ausgibt, die n-mal unter einer anderen URL auf sich selbst ver-
weist. Gleichzeitig gibt es jede Ausgabezeile mit einer Verzögerung aus, was
eine sehr langsame Verbindung simuliert.
Doch wäre das allein zu gefährlich, denn Spider von Suchmaschinen, wie z.B.
der Googlebot, sollen nicht durch die Falle blockiert werden.
Endlosschleifen bergen zudem noch die Gefahr, durch die generierte Server-
last den eigenen Webserver zu überlasten. Daher muss die Zahl der parallelen
Instanzen eines solchen Scripts limitiert werden.
47. Jede TCP-Verbindung von einem Client zu einem Server funktioniert so, dass sich der
Client einen beliebigen, noch unbenutzten Port zwischen 1024 und 65535 (High-Port)
aussucht und von diesem aus zum definierten Port verbindet, im Fall des HTTP wäre das
der Port 80. So benötigt der Client für jede Verbindung einen eigenen Port.
48. Die ursprüngliche Idee habe ich in [EGG04a] veröffentlicht. Die Lösung hier ist etwas ver-
feinert und enthält noch einige weitere Tricks, um die Teerfalle noch besser zu verbergen.
No Spam! 123
8 – Harvester blockieren
8.2 Überlastungsprophylaxe
Dabei sollte eine Anfrage des Harvesters in einer Warteschleife gehalten und
vom Server nicht schon wegen Überlastung abgewiesen werden. Insbesondere
muss der restliche Serverbetrieb ohne Komplikationen weiterlaufen. Das ist
insbesondere wichtig für den Fall, dass auf dem Server noch weitere Websei-
ten liegen, die von menschlichen Surfern abgefragt werden sollen.
Zu bedenken ist jedoch: Wer sich Spammer zum Feind macht, indem er deren
Harvester blockiert, sollte sich durchaus überlegen, ob es sinnvoll ist, ausge-
rechnet auf dem Server, der die Teerfalle beherbergt, gleichzeitig auch produk-
tive Seiten zu betreiben. Denn dadurch vergrößert sich die Gefahr, dass der
Server Ziel von Angriffen wird, wodurch Seiten Dritter potenziell gefährdet
werden können. Aber auch die Teergrube selbst muss gegen externe Angriffe
sehr gut abgesichert werden.
Wie man einen guten Schutz gegen solche Hacker-Angriffe erreichen kann,
stellen unter anderem [KOZ04], [HOG04], [VIE01], [PEI04], [LOC04],
[KIR00], [ANO01], [McN04] und [ZIE99] aus verschiedenen Blickwinkeln
dar, weshalb ich diese Frage hier offen lassen möchte.
Einzig der Frage, wie sich ein Denial-Of-Service der Teergrube durch Über-
lastung mit Anfragen verhindern lässt, möchte ich mich hier widmen. Denn
diese Frage ist nicht ganz trivial: Unmittelbar über eine Ausgabe des Pro-
gramms ps lässt sich nicht erkennen, wie viele Anfragen die Teergrube aktuell
bearbeitet, vor allem wenn die Teergrube ein PHP-Script ist.
PHP stellt auch intern keine Funktionen bereit, die es unmittelbar ermögli-
chen, die Zahl parallel laufender Instanzen eines Scripts zu ermitteln. Somit
muss eine eigene Lösung konstruiert werden.
Als erster Ansatz könnten gemeinsam genutzte Dateien dienen, in denen ein
Zähler hochgezählt wird, der die Zahl der aktuell laufenden Prozesse wieder-
gibt. Das Problem ist hier der parallele Zugriff auf eine Datei: Die entstehen-
den Konkurrenzsituationen müssen abgefangen werden.
Diesen Programmieraufwand könnte man an ein Datenbanksystem delegieren,
das Transaktionen unterstützt und somit eine Prüfung und das fallweise Inkre-
mentieren eines Zählers in einer unteilbaren Aktion ermöglicht.
Doch beide Verfahren scheitern an der Gefahr, dass Scripten, bevor sie den
Zähler wieder in einer atomaren Aktion dekrementieren, abnorm terminieren
124
Überlastungsprophylaxe
könnten. Günstig wäre es also, wenn man PHP oder dem Betriebssystem die
Überwachung der laufenden Prozesse überlassen könnte.
Nebenbei belastet der Datenbank- bzw. Dateizugriff auch das System und ver-
braucht relativ viel Ressourcen. Die Überwachung des aktuellen Zählerstands
lässt sich nur durch ein Busy-Waiting realisieren: Der Prozess muss immer
wieder den Zähler selbst kontrollieren. Das kostet Rechenleistung.
Sparsamer wäre es, wenn das System das Script selbständig aus einem Bereit-
schaftszustand in den aktiven Zustand49 zurückholt, sobald der Zähler wieder
unter der Obergrenze liegt. Damit würde keine Rechenleistung verschwendet.
Genau das ermöglichen Semaphoren, ein Mittel der Interprozesskommunika-
tion: Die atomaren Dijkstra-Operationen P(s) und V(s), die auf einem Sema-
phor s wirken, stehen für das Betreten und Verlassen eines so genannten kriti-
schen Abschnitts50.
Da die P-Operation prüft, ob der Semaphor einen Wert größer null hat, und ihn
dann dekrementiert, kann man über die Initialisierung des Semaphors festle-
gen, wie viele parallele Instanzen des Scripts gleichzeitig laufen können.
Der Einsatz von Semaphoren stellt sogar die eleganteste Möglichkeit zur Lö-
sung dar: Das Betriebssystem kümmert sich um die Verwaltung der Sema-
phoren, man erspart sich Busy-Waiting, das Rechenleistung fordert. Zudem
werden die Semaphoren für den Fall einer vorzeitigen, abnormen Terminie-
rung eines Prozesses überwacht. Scheinbar unendlich laufende Geisterprozes-
se, die die Oberschranke sukzessive verringern, können so nicht auftreten.
8.2.1 Semaphoren in PHP

Auch in PHP ist der Einsatz von Semaphoren möglich, jedoch muss PHP dazu
mit System V Semaphore Support kompiliert worden sein. Dies wird über die
configure-Option
--enable-sysvsem
49. Zu den verschiedenen Zuständen eines Prozesses in einem Betriebssystem siehe z.B.
[TAN02]
50. Ausführlicher dazu z.B.: [TAN02], [SCHOA] und [WIE99]
No Spam! 125
erreicht. Unter Umständen ist also eine Neuübersetzung von PHP nötig. Für ei-
nige RPM51-Installationen gibt es Ergänzungs-RPMs, die die notwendigen
Funktionen ftok, sem_get, sem_acquire, sem_release und sem_remove ohne
Neukompilierung zur Verfügung stellen.
ftok generiert einen für die Verwendung von Semaphoren geeigneten, eindeu-
tigen Schlüssel. Die PHP-Dokumentation empfiehlt, zur Generierung den Da-
teinamen des Skripts als Parameter zu übergeben, was sich durch das Makro
__FILE__ einfach realisieren lässt.
sem_get generiert auf Basis des Schlüssels dann den notwendigen Semaphor,
allerdings nur, wenn er noch nicht existiert. Ansonsten wird ein Handle auf den
bereits bestehenden Semaphor zurückgegeben. Für das verwendende Script ist
dies transparent.
sem_acquire führt die P-Operation auf den via sem_get erzeugten Semaphor
durch, sem_release entspricht der V-Operation.
Mit sem_remove kann der Semaphor gelöscht werden. Allerdings ist das un-
günstig, da alle anderen Prozesse, die diesen Semaphor zu dem Zeitpunkt be-
reits mit sem_get angefordert haben, dann Fehlermeldungen generieren. Durch
den parallelen Ablauf der Prozesse lässt es sich nicht vorhersagen, welcher
Prozess den Semaphor endgültig löschen darf. Die Löschung muss in dieser
Anwendung also vom System veranlasst werden.
8.3 Die Lösung

Weiter unten ist ein einfaches PHP-Script dargestellt, das eine HTML-Datei
ausgibt, die mehrere, unterschiedliche Links mit stets unterschiedlicher Be-
schreibung enthält.
Zum Erzeugen der Links wird die PHP-Funktion uniq_id und deren md5-hash
verwendet. Die md5-Hashes werden anschließend zufällig verkürzt, um realen
Links ähnlicher zu sein und nicht durch eine konstante Länge aufzufallen. Zu-
dem werden die Dateinamenserweiterungen der Links zufällig aus einer Liste
ausgewählt. Die Wahrscheinlichkeit für mehrere unterschiedliche Links pro
Seite ist damit ausreichend hoch.
51. RPM: RedHat Package Manager
126
Ein Script – viele Namen
Für die Beschreibung der Links werden Wörter zufälliger Länge über einem
definierten Alphabet generiert. Indem einige Symbole in diesem Alphabet
häufiger verwendet werden, wird erreicht, dass die zufälligen Wörter natür-
lichsprachigen Wörtern ähnlicher sind. Das Alphabet kann auch sinnvolle
Wörter und Buchstabenkombinationen enthalten, um eine noch bessere Täu-
schung zu erreichen. Das Beispielscript unten deutet das an.
8.4 Ein Script – viele Namen

Als nächstes Problem stellt sich die Frage, wie einem Script unendlich viele
Namen zugeordnet werden können. Hierfür gibt es zwei zweckmäßige Mög-
lichkeiten, die jeweils für den Besucher der Seite transparent sind.
Einmal kann die Konfiguration des Apache so gewählt werden, dass ein Alias
gesetzt wird. Dazu wird die Konfiguration des (Virtual-)Host in der httpd.conf
für den Fall, dass das Script index.php heißt und im Verzeichnis /spamfight/
liegt, wie folgt ergänzt:
<Directory /spamfight>
AliasMatch ^/spamfight/[A-Za-z0-9]+\.[A-Za-z0-9]+$ /spamfight/index.php
</Directory>
Alternativ lässt sich auch mit einem ErrorDocument arbeiten – dann muss die
Serverkonfiguration nicht verändert werden, eine zusätzliche Zeile in der
.htaccess im gewählten Verzeichnis reicht aus:
ErrorDocument 404 /spamfight/index.php
Um den Eindruck zu erwecken, dass kein Fehler aufgetreten sei, überschreibt
das Beispielscript den HTTP 404-Status mit „HTTP/1.1 200 OK“.
404 ist die wohl bekannteste Fehlermeldung eines Webservers: “Document not
found“, auf Deutsch: „Datei nicht gefunden“. Für den Fall eines solchen Feh-
lers ist es möglich, eine eigene Fehlermeldung zu hinterlegen, das erledigt die
Einstellung ErrorDocument. Die Fehlermeldung darf dabei auch ein vom
Webserver ausführbares Programm sein, in diesem Fall eine PHP-Datei.
Der Trick ist nun, dass die von einem Programm zurückgemeldeten HTTP-
Header und damit auch Stati Vorrang vor denen haben, die der Webserver au-
tomatisch generiert. Das Argument für dieses Verhalten ist einfach: Das Pro-
gramm wird für sich selbst besser als der Webserver wissen, warum es einen
bestimmten Header wie setzt.
No Spam! 127
Genau das ermöglicht es uns, den HTTP-Status mit dem Wert „200“ zu über-
schreiben. Dieser Wert steht für „Alles ok“.
8.5 Suchmaschinen schützen

Damit Suchmaschinen-Robots nicht in die Falle tappen, muss eine robots.txt
(siehe dazu [KOS94] und [W3CAPPB]) angelegt werden, die im Hauptver-
zeichnis des (virtuellen) Servers stehen muss. Sie könnte wie folgt aussehen:
User-agent: *
Disallow: /spamfight/
Dabei macht man sich zunutze, dass die Harvester der Spammer in aller Regel
die robots.txt ignorieren, um mehr E-Mail-Adressen zu finden. Suchmaschi-
nen halten sich jedoch an den Standard und riskieren damit nicht, in die Falle
zu tappen.
8.6 Beispiel-Teergrube
Dieses Script implementiert eine einfache Harvester-Teerfalle, so wie ich sie
oben beschrieben habe. Die wesentlichen Ideen sind oben erläutert – Hinweise
zur Programmierung sind in den Quellcode in Form von Kommentaren einge-
arbeitet.
Beachten Sie bitte, dass auch bei diesem Script das Error-Handling nur sehr
einfach implementiert ist – für reale Anwendungen sollte es entsprechend er-
weitert werden.
8.6.1 Konfiguration der Beispiel-Teergrube

Der Anfangswert der Semaphore wird über die Konstante MAX_CONCUR-
RENT_USERS eingestellt und definiert damit gleichzeitig die maximale Zahl
an parallelen Zugriffen auf das Script.
Die Wartezeit zwischen der Ausgabe zweier Links wird über sleep und die
Konstante TIME_WAIT in Sekunden recht grobkörnig definiert. Hier kann mit
usleep und der Angabe der Verzögerung in µs in TIME_WAIT eine genauere
Abstufung erreicht werden.
Die gesamte Laufzeit des Scripts ergibt sich damit grob aus dem Produkt der
Zahl der generierten Links, definiert in LINKS_GENERATED, und TIME_
128
Beispiel-Teergrube
WAIT. Für praktische Anwendungen sollte sie nach meinen Tests nicht mehr
als 15 Sekunden betragen.
Das Alphabet, über das die Wörter erzeugt werden, kann in $alphabet variiert
werden. Je mehr sinnvolle Buchstabenkombinationen es enthält und je näher
die Buchstabenwiederholungen im Alphabet an die reale Buchstabenvertei-
lung einer Sprache52 herankommen, desto wahrscheinlicher entstehen schein-
bar sinnvolle Wörter53, desto weniger leicht lässt sich das Script erkennen.
Dasselbe gilt für die Dateinamenerweiterungen, die in $extensions festgelegt
werden können.
Eine Erweiterung für den Wortgenerator sähe vor, nach einem Leerzeichen mit
einer bestimmten Wahrscheinlichkeit mit einem Großbuchstaben zu beginnen.
Die maximale Länge eines Worts liegt zwischen den beiden Konstanten
MIN_WORD_LEN und MAX_WORD_LEN. Gemessen wird sie in Symbo-
len des Alphabets: Besteht ein Symbol aus mehreren Zeichen, kann so die ma-
ximale Wortlänge überschritten werden.
8.6.2 Das Script

<?
/* *****************************************************************
Teerfalle für Harvester in PHP
(c) 2004, 2005
*****************************************************************
*/
/* Konfiguration
*/
define("LINKS_GENERATED",5); /* Wieviele Links werden pro Seite
* erzeugt?
*/
define("TIME_WAIT",1); /* Zeit in Sekunden, die zwischen
* der Ausgabe zweier Links
* gewartet wird.
*/
52. Dazu bietet jede kryptanalytische Literatur, beispielsweise auch [BAU00], Statistiken an.
53. Nach dem Grundsatz der [RFC2795]
No Spam! 129
define("MAX_CONCURRENT_USERS",5);
/* Wie oft das Script maximal parallel
* laufen darf.
*/
define("SEM_PERMS",0660); /* Rechte der Semaphore, analog dem
* Unix File-System.
*/
define("MIN_WORD_LEN",5); /* Die minimale Länge eines Wortes
* über $alphabet
*/
define("MAX_WORD_LEN",30); /* Die maximale Länge eines Wortes
*/
$extensions = array ('php','php3','php4','phtml','shtml',
'html','htm','xhtml');
/* Mögliche Dateinamenserweiterungen
* die das Script fuer seine
* zufaelligen Links verwendet.
*/
$alphabet = array ('a','a','a','a',
'b','b','b',
'c',
'd','d',
'e','e','e','e','e','e',
'f','f',
'g','g',
'h','h',
'i','i','i','i','i',
'j',
'k','k','k',
'l','l',
'm','m','m',
'n','n','n','n','n',
'o','o','o','o','o',
'p','p',
'q',
'r','r','r','r','r',
's','s','s','s','s',
't','t','t','t',
'u','u','u','u','u',
'v',
130
Beispiel-Teergrube
'w',
'x',
'y',
'z',
' ',' ',' ',' ',' ',' ',
'. ',
', ',
': ',
'der ',
'die ',
'das ');
/* Alphabet, ueber dem Woerter fuer die Links
* zufaellig generiert werden koennen. Durch
* Wiederholung einzelner Zeichen wird deren
* Auftretenswahrscheinlichkeit gesteuert.
*/
/* HTTP-Header ausgeben
Die Anfrage liefert immer OK, falls Einsatz ueber Error-Handler
Die Seite ist immer neu, um eventuelle Proxies zu umgehen.
Zusätzlich werden entsprechende Header für Proxies mitgesandt,
die Proxies anweisen, die Seite nicht zwischenzuspeichern.
Content-Encoding wird wegen W3C-Konformitaet gesandt.
*/
header("HTTP/1.1 200 OK");
header("Status: 200 OK");
/* HTML-Kopf ausgeben.
Das META-Tag ergänzt nochmal die Angaben in der robots.txt und
macht unmißverständlich klar, daß die Seite und alle Links auf
ihr auf keinen Fall für Spider gedacht sind. Harvester ignorieren
aber auch diesen Wink mit dem Gartenzaun fröhlich.
*/
<html>
<head>
No Spam! 131
<title>Links zu vielen E-Mail-Adressen...</title>

<META name="ROBOTS" content="NOINDEX, NOFOLLOW">
</head>
<body bgcolor="#ffffff" text="#000000" link="#0000ff" vlink="#800080"
alink="#ff0000">
<H1>Willkommen in Spammer's Paradise.</H1>
<?
/* Ausgabe erzwingen. Dadurch tröpfeln einige Bytes über die Leitung,
für den entfernten Rechner entsteht der Eindruck einer langsamen
Anbindung.
Würde man nicht "flushen", würde der Webserver unter Umständen mit
der Übertragung der Seite warten, bis sie vollständig generiert ist,
was aufgrund der (gewünscht) langen Zeit zu einem Timeout beim
Harvester führen könnte. Das wollen wir aber möglichst vermeiden.
*/
flush();
/* Key fuer Semaphore erzeugen.
*/
$sem_key = ftok (__FILE__,'T');
if ($semkey != -1)
{
/* Key wurde korrekt erzeugt.
*/
$sem_id = sem_get($sem_key,MAX_CONCURRENT_USERS,SEM_PERMS);
if ($sem_id !== FALSE)
{
/* Eine Semaphore konnte erzeugt / gefunden werden.
*/
if ( sem_acquire($sem_id) )
{
/* Kritischer Abschnitt.
* P($sem_id) war erfolgreich.
*/
/* Erzeuge die Links
*/
for ($i=0; $i<LINKS_GENERATED; $i++)
{
/* Die Beschreibung des Links steht in $word
*/
$word = '';
132
Beispiel-Teergrube
for ($j=0; $j<=rand(MIN_WORD_LEN,MAX_WORD_LEN); $j++)

{
$word .= $alphabet[rand(0,count($alphabet)-1)];
}
/* Bestimme den Ausschnitt des zufälligen md5-Hashs,
* der als Dateinname verwendet werden soll.
*/
$basis = rand(0,15);
print "<P><A HREF=\"".
substr(md5(uniqid(rand(), true)),
$basis,$basis+rand(5,27-$basis)).
".".
$extensions[rand(0,count($extensions)-1)].
"\">".
$word.
"</A></P>\n";
flush(); /* Ausgabe erzwingen. */
sleep(TIME_WAIT); /* Verzögerung erzeugen */
}
/* Kritischer Abschnitt Ende
* V($sem_id)
*/
if ( !sem_release($sem_id) )
{
/* Da passierte was, was nicht passieren sollte:
* V($sem_id) ist fehlgeschlagen.
* Hier sollte der Admin des Servers informiert
* werden!
*/
die ('Internal Error');
}
} // end if sem_acquire
} // end if sem_id !== FALSE
} // end if semkey != -1
/* HTML-Footer.
*/
?>
</BODY>
</HTML>
No Spam! 133
8.7 Test
Auch diese Idee habe ich auf ihre Wirksamkeit untersucht. Ich habe dazu einen
virtuellen Root-Server bei einem großen, europäischen Hoster angemietet, um
meinen eigenen Server aus der Schusslinie von Angreifern zu nehmen. Zudem
hatte dieser Provider – neben günstigen Preisen – den Vorteil, ein hohes, aber
limitiertes Transfervolumen und eine feste, sich nicht automatisch verlängern-
de Vertragslaufzeit anzubieten.
Den Server habe ich – so weit das unter den Einschränkungen virtueller Root-
Server möglich ist, gegen Angriffe gesichert. Insbesondere entfernte ich dazu
jede überflüssige Software von dem System. Denn jede zusätzliche Codezeile
erhöht die Wahrscheinlichkeit eines Programmierfehlers, den ein Angreifer
ausnutzen könnte. Die Dienste, die ich unbedingt laufen lassen musste, kom-
pilierte ich von Hand. Das hat den Vorteil, dass – zumindest in einem gewissen
Umfang – Speicheradressen variieren und damit Angriffe wie Buffer und
Stack Overflows oder Format-String-Schwachstellen erschwert werden kön-
nen.
Für den Server wurde eine eigene Domain registriert und die DNS-Einträge
wurden so eingerichtet, dass jede beliebige Subdomain unter dieser Domain
ebenfalls auf den Server verwies.
Das vorgestellte Script habe ich zur zusätzlichen Tarnung so erweitert, dass der
Servername um eine zufällig gewählte Subdomain ergänzt werden konnte. Da-
bei wurde die Ergänzung nicht immer, sondern zufallsgesteuert vorgenommen.
Dadurch sollten Harvester weiter in die Irre geführt werden: Selbst wenn sie
durch Zeitbeschränkungen oder sonstige Einstellungen eine Subdomain als
uninteressant einstufen würden, blieben sie in der Falle. Zudem wird so eine
Obergrenze für die Zahl der verfolgten Links pro Hostnamen umgangen, die
häufig zur Vermeidung von Endlosschleifen in Spider implementiert werden54.
Die Wartezeit pro Link habe ich für den Test auf 0,75 Sekunden beschränkt,
um realen Harvestern, die teilweise mit Zeitgrenzen arbeiten, ausreichend
schnelle Antworten zu liefern. Die Auslieferung einer Seite dauert so im
Schnitt 15 Sekunden. Das bestätigten auch die Logfiles des Webservers.
54. Siehe dazu: [HEM03]
134
Weitere Verbesserungsmöglichkeiten
Auch diese Testseite wurde von zahlreichen Spamfeinden verlinkt. Viele ha-
ben dabei das Konzept durchschaut, dass beliebige, zufällige Datei- und Host-
namen möglich sind, und unterschiedliche Links auf den Server gesetzt.
Tatsächlich funktionierte die Teergrube auch in der Praxis: Die ausführlichen
Logfiles des Webservers zeigten immer wiederkehrende Zugriffe von be-
stimmten IP-Adressen. Von mehreren dieser IP-Adressen wurde in de.ad-
min.net-abuse.mail unabhängig davon berichtet55, dass auf den entsprechen-
den Rechnern Harvester laufen.
Bereits einen knappen Monat nach Inbetriebnahme der Seite verfingen sich die
ersten Harvester. Sie waren zu diesem Zeitpunkt bereits 5 Tage in der Falle und
erzeugten dabei bis zu 700 Page-Impressions. Mit zunehmender Laufzeit der
Falle wuchsen die Zugriffszahlen weiter: Bereits wenige Tage später verfing
sich ein Harvester so gründlich, dass er innerhalb von zwei Tagen fast 14.000
Zugriffe auf unterschiedliche Seiten versuchte.
Vier Monate nach dem Start war der Spitzenreiter immer noch derselbe Rech-
ner mit fast 14.000 Zugriffen. Platz zwei erreichte gut die Hälfte: 7512 Abrufe.
Beim Schreiben des Buchs führte ein neuer Harvester mit 19.000 Zugriffen die
Hitliste an.
Ich habe zudem meine Test-Harvester gegen die Testseite laufen lassen. Alle
haben sich wie erwartet in den Fallen verfangen. Eines der Programme hatte
dabei zum Schutz vor unendlicher Rekursion eine maximale Linktiefe: Der
Wert war per Default auf 30 gestellt. Da jede Seite zwanzig Eigenlinks auslie-
fert, stattet dieses Programm der Teergrube trotzdem 2030 = 1,07 ∗ 1039 Besu-
che ab. Bei einer Besuchszeit von ca. 15 Sekunden pro Seite wäre dieser Har-
vester 1,61 ∗ 1040 Sekunden beschäftigt gewesen.
Im Ergebnis ist also festzustellen, dass mit einer solchen Teerfalle tatsächlich
Harvester gefangen werden können.
8.8 Weitere Verbesserungsmöglichkeiten

Für einen praktischen Einsatz wünschenswert wäre eine große Verteilung sol-
cher Fallen im Netz, um eine hohe Trefferquote durch die Harvester zu errei-
chen. Um ein Blacklisting dieser Server zu unterbinden, sollten die Fallen häu-
55. Siehe z.B. den Thread unter http://groups-beta.google.com/group/de.admin.net-

abuse.mail/browse_thread/thread/2ae2304f4def109d
No Spam! 135
fig umziehen und unter zahlreichen Domainnamen erreichbar sein. Wegen der
zusätzlich wechselnden IP-Adressen wäre ihr Betrieb mittels eines Dienstes
wie DynDNS an einer DSL-Flatrate günstig.
Um die Anwender dieser Sammelprogramme nicht zu schnell auf die Falle
aufmerksam zu machen, wäre es sinnvoll, wenn auf jeder Trefferseite einige
E-Mail-Adressen ausgegeben werden – die dann zu einer SMTP-Teergrube
führen, wie sie z.B. [DON04a] und [REHWWWa] beschreiben. Das ist vorteil-
haft, weil die Programme während der Laufzeit die gefundenen E-Mail-Adres-
sen an ihre Benutzer melden. Dadurch sieht der Spammer seine Adressen-
sammlung wachsen, der Harvester liefert für seinen Benutzer scheinbar
nützliche Daten aus.
Die so gefundenen Adressen sind jedoch für Werbezwecke unbrauchbar. Da
sie zudem an SMTP-Teergruben hängen, wird der Spammer zusätzlich noch
beim Versand seiner Werbenachrichten blockiert.
Zu beachten ist dabei jedoch, dass einige Harvester Mengenlimits für die Zahl
von E-Mail-Adressen haben – vermutlich wegen der zunehmenden Verbrei-
tung von Teergruben im Netz. Daher sollten pro Ausgabeseite nicht mehr als
zwei E-Mail-Adressen angezeigt werden.
Je mehr solcher Teergruben existieren und je mehr Adressen durch geeignete
Tarnung unsichtbar gemacht werden, desto uninteressanter wird es für Spam-
mer, E-Mail-Adressen mit Hilfe von Spidern zu ermitteln, da der Zeitaufwand
für die Suche im Verhältnis zu den gültigen Mailadressen zu groß wird.
Tatsächlich gibt es immer wieder Meldungen, denen zufolge Spammer mittler-
weile dazu übergehen, E-Mail-Adressbücher wurminfizierter Computer aus-
zulesen und als Zieladressen ihrer Spammails zu nutzen. Allerdings lassen sich
diese Infektionen mit relativ geringem Aufwand ebenfalls vermeiden, so dass
auch diese Quelle mittelfristig versiegen dürfte.
136
9 Absichern von Mailinglisten
und Newslettern
Mailinglisten und Newsletter sind aus technischer Sicht relativ ähnlich. Mai-
linglisten bieten allen Mitgliedern die Möglichkeit, Nachrichten per E-Mail
auszutauschen, und ermöglichen damit eine Diskussion. Newsletter sind dage-
gen eingeschränkte Mailinglisten: Hier dürfen nur ein oder wenige ausge-
zeichnete Mitglieder Mails senden. Newsletter werden daher üblicherweise
nicht zur Diskussion, sondern zum Einweg-Nachrichten-Versand genutzt. Ty-
pische Newsletter enthalten Werbung für Produkte oder ein Unternehmen, ei-
nige bieten auch aktuelle Informationen zu beliebigen Themen.
9.1 Sicherheitsziele
In jedem Fall werden über eine Mailadresse zahlreiche Empfänger erreicht.
Kann ein Spammer also die Adresse eines Newsletters oder einer Mailingliste
in seinen Besitz bringen und dorthin Nachrichten senden, erreicht er mit gerin-
gem Aufwand zahlreiche Empfänger.
Aber auch die Liste der Adressaten allein ist für Spammer Gold wert: Sie ent-
hält ausschließlich gültige, aktuell gelesene Mailadressen. Solche so genann-
ten „verified“ Adressen werden unter Spammern zu deutlich höheren Preisen
gehandelt.
Damit ergeben sich zwei Sicherheitsziele bezüglich Mailinglisten und News-
lettern: Einmal muss sichergestellt werden, dass nur berechtigte Personen
Nachrichten an die Listen schicken dürfen, um einen Missbrauch der Listen-
adresse durch Spammer zu verhindern. Zum anderen muss die Liste der
E-Mail-Adressen vor unberechtigtem Zugriff wirkungsvoll geschützt werden.
Ein weiteres Problem habe ich weiter oben in Zusammenhang mit E-Cards und
der Send-To-A-Friend-Funktion bereits angesprochen: Es kommt immer wie-
der vor, dass versehentlich oder vorsätzlich Mailadressen von unbeteiligten
Dritten bei solchen Diensten angemeldet werden. Für diesen Dritten stellt sich
jede Nachricht aus der Mailingliste oder des Newsletters als UBE bzw. Spam
dar. Vor solchen Bedienfehlern muss die Listensoftware auch schützen.
No Spam! 137
9 – Absichern von Mailinglisten und Newslettern
9.2 Anmeldeverfahren
Zum Anmelden an Mailinglisten gibt es allgemein drei Verfahren, die sehr
ausführlich unter anderem in http://www.spamhaus.org/mailinglists.html und
[GOO04] beschrieben sind: Das Spam-gefährlichste nennt man gemeinhin
„Opt-Out“. Das heißt, man wird ohne eigenes Zutun angemeldet und muss sich
explizit abmelden, um keine weiteren Nachrichten mehr zu empfangen. Die
Alternativen sind so genannte „Opt-In“-Verfahren, bei denen man sich explizit
anmelden muss. Je nach Absicherung von Bedienfehlern spricht man von
„Single-Opt-In“ oder „Double-Opt-In“.
Im ersten Fall wird die Anmeldung unmittelbar akzeptiert, im zweiten wird die
neue E-Mail-Adresse verifiziert, indem an sie eine E-Mail gesandt wird, die
dann bestätigt werden muss. Erfolgt diese Bestätigung nicht, wird die Mail-
adresse nicht in den jeweiligen Verteiler aufgenommen.
9.2.1 Opt-Out
Offensichtlich ist das Opt-Out-Verfahren bei Spammern beliebt: Die Anmel-
dung ist überflüssig, man kann einfach geharvestete Adressen verwenden und
diese anmailen. Es besteht für den Empfänger kein Schutz vor unberechtigter
Eintragung. Die Existenz einer Opt-Out-Möglichkeit dokumentiert dabei häu-
fig auch nur das Verständnis der Spammer vom amerikanischen CAN-SPAM-
Act, der einen Abmeldelink fordert. Denn der Link ist entweder funktionslos,
führt ins Leere oder er dient gar der Verifikation der Empfängeradresse.
Eine solche Art der Anmeldung an einem Newsletter ermöglicht es nach deut-
schem Recht, den Betreiber des Newsletters abzumahnen und zur Unterlas-
sung aufzufordern. Zusammen mit den allfälligen Beschwerden beim Provider
des Versenders und der typisch daraus resultierenden Zugangssperre, entsteht
für einen seriösen, aber schlecht beratenen Betreiber eines solchen Newsletters
erheblicher Schaden – für den Spammer steigt das wirtschaftliche und rechtli-
che Risiko erheblich.
9.2.2 Einfacher Opt-In

Daher bietet sich der Einsatz eines Opt-In-Verfahrens an. Denn dann hat der
Empfänger der Zusendung von E-Mails zugestimmt. Dabei ist Opt-In so zu
verstehen, dass der Empfänger entweder durch Zusendung einer E-Mail an ei-
138
Anmeldeverfahren
nen Listserver oder aber durch Eingabe seiner Mailadresse auf einer Webseite
explizit der Zusendung von E-Mail-Werbung zugestimmt hat. Manche Spam-
mer fassen den Begriff „Opt-In“ dagegen sehr weit und verstehen unter Opt-In
auch die Eintragung einer Mailadresse durch einen Harvester, was man übli-
cherweise eher als Opt-Out bezeichnen würde.
Beim einfachen Opt-In wird die Mailadresse des Empfängers nicht geprüft.
Somit ist es jedem möglich, einen Dritten einzutragen. Das muss nicht mutwil-
lig geschehen, auch versehentliche Tippfehler können eine falsche Eintragung
zur Folge haben. So könnte der Besitzer der Adresse stefanie@example.com
sich vertippen und versehentlich z.B. steffanie@example.com eingeben – die
einer anderen Steffi gehört. Die erhält dann Nachrichten, ohne sie bestellt zu
haben.
Daher ist auch die Verwendung eines einfachen Opt-Ins gefährlich. Denn die
Beweislast für die korrekte Eintragung der Mailadresse in die Liste liegt beim
Versender. Kann dieser nicht zweifelsfrei nachweisen, dass sich genau derje-
nige angemeldet hat, der angemailt wurde, ist er unterlassungs- und gegebe-
nenfalls auch schadensersatzpflichtig.
Dabei ist die Beweisführung für den Listenbetreiber extrem aufwendig: Die
meisten Internetsurfer verwenden dynamische IP-Adressen, über die sie nur
mit hohem Aufwand, wenn überhaupt, zurückverfolgt werden können. Damit
lässt sich aus den Daten, die der Webserver zur Verfügung hat, der tatsächliche
Übeltäter kaum ermitteln.
9.2.3 Double-Opt-In
Diese Lücke schließt das Double-Opt-In-Verfahren. Manche Autoren bezeich-
nen es auch als „confirmed Opt-In“ oder qualifiziertes Opt-In. Die Begriffe
sind synonym.
Der Ablauf der Anmeldung beginnt ähnlich wie beim Opt-In-Verfahren: Der
Interessent trägt seine E-Mail-Adresse in ein Formular ein oder schickt an ei-
nen Listenserver eine Anmeldemail. Um Tippfehler in der Mailadresse und
Anmeldungen durch Dritte zu verhindern, wird vom Listserver eine E-Mail an
die genannte Adresse generiert. Die E-Mail enthält eine interne, eineindeutige,
nicht vorhersagbare Nummer, die der Empfänger dieser E-Mail wahlweise per
E-Mail zurückschicken oder auf einer Webseite eintragen muss. Teilweise
No Spam! 139
wird der Eintragevorgang erleichtert, indem ein Link mit dieser Nummer als
GET-Parameter mit gesandt wird.
Erst nach dieser Bestätigung wird die E-Mail-Adresse tatsächlich am Newslet-
ter angemeldet.
Diese zusätzliche Bestätigung wird als sicher erachtet, weil zum Abrufen der
E-Mail üblicherweise ein Passwort notwendig ist und somit nur der tatsächli-
che Inhaber der Mailadresse die zugesandte Nummer kennen sollte.
Ein solches Anmeldeverfahren ist auch aus rechtlicher Sicht günstig: Es be-
weist zumindest dem ersten Anschein nach, dass sich der Empfänger tatsäch-
lich angemeldet hat. Der Empfänger muss nun diesen Beweis erschüttern.
Praktisch jedoch ist dieses Verfahren teilweise schwierig: Viele Anwender
sind schlicht überfordert, die gewünschte Rückmail zu senden oder den not-
wendigen Link anzuklicken. Als Betreiber einiger Mailinglisten habe ich zu-
mindest diese Erfahrung machen müssen. Immer wieder erreichen mich Mails
von potenziellen Teilnehmern, die diesen zusätzlichen Schritt nicht ausgeführt
haben und sich wunderten, warum sie keine Mails bekommen.
Sinnvollerweise verifiziert man auch die E-Mail-Adressen solcher Teilnehmer
– dann allerdings manuell durch wechselseitige Kommunikation, bevor man
sie an der Liste anmeldet. Schließlich kann sich auch in die Absenderadresse
einer Mail ein Schreibfehler eingeschlichen haben.
Das Double-Opt-In-Verfahren ist meines Erachtens trotz der Schwäche, man-
che Anwender zu überfordern, das einzig sinnvolle System für Anmeldungen
bei E-Mail-Verteilern, denn es schützt den Betreiber effektiv vor Missbrauch
seiner Infrastruktur. Dass das Verfahren manche Anwender überfordert, lässt
sich vermutlich nie ganz vermeiden.
Man kann lediglich versuchen, diesen zweiten Opt-In-Schritt DAU-sicher zu
gestalten. Dabei scheint es günstiger, einen Link anzugeben, statt eine Ant-
wort-E-Mail mit einem definierten Text zu fordern. Auch empfiehlt es sich,
eine ausführliche Beschreibung auf Deutsch einzufügen, die erklärt, warum
der Link angeklickt werden soll. Englischsprachige Texte scheinen von durch-
schnittlichen DAUs generell ignoriert oder nicht verstanden zu werden.
Zudem sollte, sofern die Anmeldung über eine Webseite erfolgen kann, in der
Umgebung des Anmeldelinks das Double-Opt-In-Verfahren erläutert werden
und eine Kontaktmöglichkeit angeboten werden, für den Fall, dass es Schwie-
rigkeiten gibt.
140
Laufender Betrieb
Immer wieder werden aber auch Stimmen laut, die sich gegen ein zu einfaches
Anmeldeverfahren aussprechen. Sie argumentieren, dass Personen, die nicht in
der Lage sind, einfache Anweisungen in einer E-Mail zu befolgen, auch nicht
in der Lage sein werden, sich später abzumelden, wozu wiederum der Versand
einer E-Mail notwendig wäre. Vielmehr würden sie sich, wenn sie den ehedem
bestellten Newsletter nicht mehr lesen wollen, über den Betreiber als ver-
meintlichen Spammer beschweren. Reale Fälle belegen dieses Verhalten. Ge-
rade in solchen Fällen ist die Beweiskraft eines Double-Opt-In nicht zu unter-
schätzen.
9.2.4 Anmeldebestätigung
Viele Listserver bieten neben dem Double-Opt-In zusätzlich die Option, An-
meldeanträge durch den Listmaster zusätzlich bestätigen zu lassen. Dabei wird
zuerst die übliche Double-Opt-In-Routine durchlaufen und anschließend der
Listmaster über den neuen Interessenten informiert. Der Listmaster muss nun
diese Anmeldung manuell bestätigen.
Dieser letzte Schritt macht vor allem dann Sinn, wenn die Liste entweder nur
einem geschlossenen Personenkreis zugänglich sein soll, von dem die E-Mail-
Adressen bekannt oder nachfragbar sind, oder, wenn man die Mailadressen je-
des Anmeldeantrags individuell prüfen möchte, um beispielsweise unliebsame
Mitglieder von Anfang an zu blockieren.
Diese Maßnahme ist allerdings nur bei kleineren Listen sinnvoll – prasseln täg-
lich zahllose Anmeldungen auf den Listserver ein, ist diese zusätzliche Über-
prüfung häufig nicht mehr realisierbar.
9.3 Laufender Betrieb

Die Liste der E-Mail-Adressen der Mitglieder muss im laufenden Betrieb vor
dem unberechtigten Zugriff Dritter geschützt werden. Gleichzeitig muss ver-
hindert werden, dass Spammer an die Listenadresse ihre Werbemails schicken
können.
No Spam! 141
9.3.1 Schutz der Mailadressen

Zum Schutz der Mailadressen der Mitglieder sollten sie keinesfalls veröffent-
licht werden: In Zusammenhang mit dem jeweiligen Thema der Liste ist das
sonst eine einfache Möglichkeit, zielgruppengerecht zu spammen.
Archivfunktion
Allerdings kollidiert das Ziel in vielen Fällen mit dem Wunsch nach einem Ar-
chiv der Liste im WWW. In einem solchen Archiv werden die Nachrichten, die
über die Liste ausgetauscht wurden, mit den wichtigsten Header-Informatio-
nen angezeigt und durchsuchbar gemacht.
Solche Listenarchive können vielfältigen Nutzen stiften: Lassen sie sich mit
Suchmaschinen durchsuchen, können auch Nicht-Listenmitglieder auf Ergeb-
nisse der Diskussionen in der Liste zugreifen. So können Nachrichten aus den
Mailinglisten bei Securityfocus oder Insecure von Dritten gelesen werden, um
stattgefundene Angriffe zu analysieren.
Durch das Archiv können so ständig wiederkehrende Standardfragen aus der
Liste ferngehalten werden, die Mailflut wird eingedämmt, die Teilnehmer der
Liste können sich auf wesentliche und bislang unbeantwortete Fragen konzen-
trieren.
Für Dritte, die über eine Suchmaschine auf die Mailingliste stoßen, ist dabei
ein vollwertiges Archiv wegen des erhaltenen Kontext in aller Regel günstiger
als eine FAQ.
Lässt sich das Archiv von Suchmaschinen durchsuchen, ist es zwangsläufig
auch für Harvester suchbar. Da Suchmaschinen erwünscht sind, bleiben Har-
vester zwangsläufig nicht aus, daher sollten bei Ausgabe des Archivs die Mai-
ladressen mit einem der weiter oben beschriebenen Verfahren für Harvester
unlesbar gemacht werden – oder man verwendet das derzeit bei Google-
Groups verwendete Verfahren, bei dem E-Mail-Adressen durch Einfügen von
drei Punkten „...“ verkürzt werden, was sie für Spammer wertlos macht.
Allerdings ist es dann auch einem Leser des Archivs unmöglich, Kontakt zum
Ursprungsposter aufzunehmen. Gerade bei ungewöhnlichen oder sehr aufwen-
digen Fragen und Lösungsideen kann aber das eine gewünschte Funktion sein.
Daher bietet es sich an, eines der in diesem Buch beschriebenen Verfahren zu
verwenden.
142
Laufender Betrieb
Möchte man das Archiv nur für den internen Gebrauch nutzen, lässt sich das
viel einfacher realisieren: Man schützt die Archivseiten mit einem Passwort,
das nur die Mitglieder der Liste kennen sollten.
Dieses Verfahren verwendet beispielsweise die Mailingliste Notfallrettung56.
Das Passwort für den Mitgliederbereich wird dabei einmal monatlich geändert
und vom Listmaster per E-Mail an die Listenmitglieder kommuniziert.
Ein Harvester sollte nicht im Besitz des Passworts sein und bleibt damit aus-
gesperrt – vorausgesetzt, der Webserver wurde sinnvoll konfiguriert. Sinnvoll
ist allerdings, das Passwort regelmäßig zu wechseln, damit Spammer nicht zu
einfach in seinen Besitz gelangen können – auch wenn die HTTP-Basic-Au-
thentication nicht gegen Brute-Force-Angriffe geschützt ist.
Adressenlisten
Der Listserver benötigt intern zur Weiterleitung einer Mail an alle Mitglieder
eine Liste mit deren E-Mail-Adressen. Diese Liste sollte keinesfalls abrufbar
sein – was jedoch zahlreiche Listserver in ihrer Standardkonfiguration ermög-
lichen.
So muss in Majordomo57 der Befehl who, der die Mailadressen aller Listenmit-
glieder ausgibt, zunächst in der Konfiguration gesperrt werden. Andere List-
server, wie z.B. mailman58, bieten ähnliche Funktionen an, die auch deaktiviert
werden sollten.
Gleichzeitig muss sichergestellt sein, dass die Listen nicht über eine Webseite
– womöglich über einen Directory-Traversal-Angriff – ausgelesen werden
können. Daher sollte, wird die Liste auf einem Rechner betrieben, der gleich-
zeitig auch als Webserver fungiert, das Listenverzeichnis nur für die Listen-
software lesbar sein, keinesfalls jedoch für den Nutzer, unter dessen Rechten
der Webserver läuft.
Haben verschiedene Nutzer Shell- oder FTP-Zugriff auf einen solchen Server,
sollten auch diese aufgrund der Nutzerrechte keine Möglichkeit haben, die
Mailinglisten auszulesen. Notfalls müssen Access Control Lists (ACL) imple-
mentiert werden.
56. Zu finden unter http://www.mailingliste-notfallrettung.de

57. Siehe http://www.greatcircle.com/majordomo/
58. Siehe z.B. [HEIN05] und [HEIN04]
No Spam! 143
Hinweise zur allgemeinen Absicherung eines Servers geben unter anderem

[ANO01], [TAN02], [McN04], [KIR00] oder auch [LOC04].
9.3.2 Schutz der Liste

Auch die E-Mail-Adresse der Liste selbst kann Ziel von Spam sein. Spam an
eine Listenadresse ist aus Sicht des Spammers sehr effizient – je nach Liste
werden so leicht mehrere hundert bis tausend Mitglieder mit einer einzigen
Mailadresse erreicht. Aber auch zufälliges Bespammen der Liste, weil die Lis-
tenadresse beispielsweise von einem Harvester gefunden wurde, ist lästig und
sollte vermieden werden.
Einschränken der Sender

Majordomo und auch Mailman bieten daher an, die Liste der Personen, die
Nachrichten an die Liste schicken dürfen, zu beschränken.
In Diskussionslisten dürfen im Allgemeinen alle Mitglieder Nachrichten schi-
cken, daher wird man diese Liste so konfigurieren, dass nur Mitglieder posten
dürfen. Das lässt sich bei Majordomo durch eine Zeile im Config-File der Liste
einrichten:
restrict_post = beispiel
Dabei ist „beispiel“ der Name der Datei, in der die Mitglieder der Liste aufge-
listet sind. Die Datei heißt dabei genauso wie die Liste.
Manche Listenmitglieder verfügen über mehrere Mailadressen und möchten
mit allen Adressen posten können, jedoch nur auf einer Adresse mailen. Das
lässt sich durch eine zusätzliche Datei beispiel.zusatz realisieren, die diese
Zweitadressen enthält. Die notwendige Direktive im Config-File lautet dann:
restrict_post = beispiel:beispiel.zusatz
Einschränken der Inhalte

Einige Mailinglisten, z.B. die Bug-Mailingliste von MySQL, sollen nach De-
finition für alle Nutzer offen stehen. Insbesondere darf auch jemand an diese
Listen posten, der kein Mitglied ist. Das ist auch sinnvoll, denn die Fehler und
Probleme, auf die Anwender von MySQL stoßen, sollen auf einfachem Weg an
das MySQL-Entwicklerteam kommuniziert werden.
144
Laufender Betrieb
Um hier einen Schutz vor Spam zu erreichen, müssen Nachrichten häufig be-
stimmte Code-Wörter enthalten. Im Fall der genannten Bug-Mailingliste ist
das „How to reproduce:“. Enthält eine Nachricht nicht diesen Text, wird sie zu-
rückgewiesen.
Dieser Schutz gegen Spam lässt sich allerdings bewusst aushebeln. Das setzt
aber immerhin voraus, dass der Spammer gezielt diese Mailingliste belästigen
möchte. Insofern erscheint diese Lösung als ein sinnvoller Kompromiss zwi-
schen den Zielen: Zugänglichkeit für die Allgemeinheit und Schutz vor Spam.
Schutz des Alias

Majordomo nutzt die Funktion der Aliase für E-Mail-Adressen intensiv. So
müsste bei der Verwendung von Sendmail59 die /etc/aliases für eine Mailing-
liste mit dem Namen „beispiel“ unter anderem um folgende Zeilen erweitert
werden:
beispiel: "|/path/to/majordomo/wrapper resend -l beispiel beispiel.out"
beispiel.out: :include:/path/to/majordomo/lists/beispiel
Damit werden zunächst alle Mails, die auf dem lokalen Account „beispiel“
eintreffen, an den Majordomo übergeben, der sie nach einer Prüfung an den lo-
kalen Account „beispiel.out“ weiterleitet. Dieser Account ist ein Alias für die
E-Mail-Adressen, die in der Datei /path/to/majordomo/lists/beispiel stehen,
der Liste der Empfänger der Mailingliste.
Ein Spammer, der gezielt diese Liste mit seinen Werbemails belästigen möch-
te, könnte nun auf die Idee kommen, eine E-Mail direkt an „beispiel.out“ zu
senden. Diese Adresse könnte er beispielsweise aus veröffentlichten Header-
Daten in einem öffentlich zugänglichen Archiv der Mailingliste erlangt haben.
Selbst wenn diese Adresse über die „virtusertable“ nicht zugeordnet ist, kann
sie von außen erreicht werden, indem eine Nachricht direkt an die Adresse
beispiel.out@lists.example.com gesendet wird – wenn die Mailingliste auf
lists.example.com läuft.
Einen derartigen Angriff kann man zumindest dadurch erschweren, dass man
in /etc/mail/virtusertable die folgende Zeile einträgt:
beispiel.out@lists.example.com :error:nouser User unkown
59. Siehe dazu http://www.sendmail.org und [COS97]
No Spam! 145
Die Zeile muss gegebenenfalls für andere Hostnamen des Listservers zusätz-
lich eingefügt werden. Damit kann zumindest nicht mehr mittels eines Bulk-
mailers an diese Adresse gemailt werden.
Allerdings ist es noch möglich, sich direkt mit dem SMTP-Server auf dem
Listserver zu verbinden und im SMTP-Envelope die Zeile „RCPT TO: bei-
spiel.out“ anzugeben und damit die Mail an die Liste zuzustellen.
Auch dieser Angriff lässt sich noch weiter erschweren, indem in der /etc/mail/
sendmail.cf zusätzliche Konfigurationsanweisungen gegeben werden, die an-
hand von regular expressions den Header der Mail prüfen und nach bestimm-
ten Mustern suchen, die vom Majordomo eingefügt werden, von einem An-
greifer jedoch sehr wahrscheinlich nicht eingefügt würden.
Die genaue Darstellung dieser Konfiguration würde jedoch den Rahmen dieser
Darstellung sprengen. Weitergehende Erläuterungen finden sich dazu auf
http://www.sendmail.org/m4/anti_spam.html und in [COS97].
Ein geschickter Angreifer könnte auch diesen Schutz wiederum umgehen, in-
dem er geeignete Header-Daten fälscht und mitliefert. Dazu müsste er natür-
lich die relevanten Header-Informationen erraten. Der Aufwand dürfte jedoch
in aller Regel in keinem Verhältnis zum Nutzen für einen Spammer stehen.
Die Alternative ist, dass er eine Mail mit gefälschten Absenderdaten ver-
schickt, so dass sie den Anschein erweckt, sie käme von einem Listenmitglied.
Außer einer Moderation der Liste gibt es gegen diesen Angriff derzeit keine
Möglichkeiten.
9.4 Zusammenfassung
Werden alle beschriebenen Maßnahmen umgesetzt, lassen sich Mailinglisten,
die ohne Zweifel ein wichtiges Kommunikationsmittel im Internet darstellen,
problemlos betreiben. Die Maßnahmen stellen in ihrer Kombination einerseits
sicher, dass der Betreiber der Liste nicht versehentlich zum Mitstörer an Spam
wird, andererseits garantieren sie, dass ein Spammer sich nicht auf einfache
Weise der Liste zur Aussendung seiner Werbung bemächtigen kann.
146
10 Zusammenfassung
Alle vorgestellten Methoden zielen darauf ab, Spam zu verhindern, bevor er

Mailboxen überfüllt und die E-Mail-Kommunikation unmöglich macht. Dazu
biete ich Ihnen im Wesentlichen zwei verschiedene Verfahren an: Das erste
verfolgt das Ziel, Harvester am Auffinden von E-Mail-Adressen zu hindern.
Das ist rein passiv.
Die Alternative ist ein aktives Bekämpfen der Harvester durch eine Teergrube,
die die Harvester ausbremst und dadurch blockiert. Das ist deutlich aggressiver
und sollte gründlich überlegt werden. Die vorgestellte Teergrube klammert da-
bei ordentliche Spider durch eine geeignete robots.txt aus, wodurch sie die
gängigen Standards respektiert – ein Verhalten, das leider längst nicht alle
Teergruben im Netz an den Tag legen.
Da die Teergrube eine Art Angriff auf Harvester darstellt, läuft ihr Betreiber
auch eher Gefahr, Opfer von Gegenangriffen zu werden. Sie sollten sich dieses
Problems, falls Sie eine Falle betreiben wollen, stets bewusst sein und entspre-
chende Sicherheitsvorkehrungen treffen.
Denkbar ist es auch, eine Teergrube noch aggressiver agieren zu lassen – so
könnte man über einen Cron-Job die Rechner, die am häufigsten auf die Falle
zugreifen, aus den Logfiles heraussuchen und diese automatisiert einem Deni-
al-of-Service-Angriff auszusetzen. Da die meisten Harvester unter Windows
laufen, eröffnen sich zahlreiche Möglichkeiten – sei es der Ping-of-death60
oder der kürzlich wieder aufgetretene LAND-Angriff auf Windows-XP-Syste-
me61.
Allerdings begibt man sich mit solcherlei Selbstjustiz schnell in eine rechtlich
bedenkliche Situation und läuft Gefahr, selbst wegen Straftaten verurteilt zu
werden. Nicht nur die Strafbarkeit, sondern auch moralische Erwägungen
sprechen gegen ein solches Vorgehen. Schließlich soll der eigene E-Mail-Ac-
count vor Spam geschützt werden und nicht ein Rechner eines möglicherweise
unbeteiligten Dritten gehackt werden.
60. Dieses Beispiel ist bewusst gewählt – die meisten Systeme sind dagegen mittlerweile
immun. Siehe dazu z.B. [PEI04], [ZIE99]
61. Siehe dazu z.B.: [KUC05] mit weiteren Quellen
No Spam! 147
10 – Zusammenfassung
Dabei ist der rechtliche Rahmen nicht nur im aktiven Kampf gegen Spammer
relevant, sondern auch und erst recht beim passiven Tarnen der Mailadressen.
Schließlich fordert das Gesetz die Angabe einer E-Mail-Adresse. Daher sind
die vorgestellten Verfahren alle vor dem Hintergrund der möglichen rechtli-
chen Implikationen diskutiert worden.
Meine eigene Studie und [CDT03] belegen, dass eine effiziente Tarnung der
E-Mail-Adressen auf einer Webseite die Zusendung von Spam nachhaltig ver-
hindern kann. [CDT03] hat zudem herausgefunden, dass auch das nachträgli-
che Entfernen einer E-Mail-Adresse von einer Webseite zu einer Spamreduk-
tion führen kann.
Günstig ist die derzeitige Rechtsprechung in Deutschland, hat sich doch ein-
mal eine Spammail in die eigene Mailbox verirrt: Es wird einheitlich ein so-
wohl wettbewerbs- als auch haftungsrechtlicher Unterlassungsanspruch gegen
den Spammer als gegeben angenommen. Dabei fühlt sich die deutsche Justiz
aufgrund des Begehungsortprinzips weltweit zuständig, lediglich die Zustel-
lung ins Ausland könnte sich schwierig gestalten.
In Deutschland ist die strafrechtliche Relevanz von Spamming noch umstrit-
ten62, auch wenn mittlerweile Gesetzesinitiativen existieren, die ähnlich dem
US-amerikanischen CAN-SPAM-Act die Fälschung von Header-Daten unter
Strafe stellen wollen.
Eben dieses Fälschen wurde in den USA mittlerweile einigen Spammern zum
Verhängnis: Die ersten sind bereits verhaftet63.
Um einer Strafe zu entgehen und sich auch vor den vorgestellten Verfahren
besser zu schützen, gehen Spammer leider mittlerweile vermehrt dazu über,
Würmer und Trojaner einzusetzen, die auf den Festplatten der infizierten
Rechner nach E-Mail-Adressen suchen.
Allerdings lässt sich der eigene Rechner mit minimalem Aufwand, durch die
Installation geeigneter und vor allem korrekt konfigurierter Firewall-Systeme
und Virenscanner, vor diesen Schadprogrammen schützen64.
62. Siehe z.B.: [FRA04] und [FRA04a]

63. Siehe dazu: [LÖD04]
64. Werfen Sie dazu einen Blick in: [EGG04d], [EGG05d] und [ZIE99].
148
Zusammenfassung
Insgesamt erscheint mir die Kombination aus sinnvoll gestalteten Webseiten,

sicheren Systemen und einer harten Rechtsprechung wesentlich erfolgverspre-
chender als die mühselige Einführung neuer, einschränkender Systeme zum E-
Mail-Versand65 – das Internet ist schließlich nicht mehr das ARPANET, das in
einer Nacht auf das IP-Protokoll umgestellt werden konnte.
65. Siehe dazu z.B.: [BAG04]
No Spam! 149
Literaturhinweise
[AND04a] Andresen, Fred, Recht einfach. Leser fragen, der Linux-Magazin-

Ratgeber antwortet. Webimpressum als Grafik, 2004, in: Linux Magazin
10/2004, Linux New Media, München
[ANO01] Anonymous, Maximum Linux Security. A Hacker's Guide to
protecting your Linux, Sams Publishing, Indianapolis, 2001
[BAC04b] Bachfeld, Daniel, Erste Fälle von Phishing-Opfern bekannt
geworden [Update], 2004, http://www.heise.de/newsticker/meldung/50398
[BAG04] Bager, Jo, Fischer von Molland, Michael, Wider die E-Mail-
Massen. Neue Verfahren gegen Spam, 2004, in: c't, Heise, Hannover
[BAU00] Bauer, Friedrich L., Entzifferte Geheimnisse. Methoden und
Maximen der Kryptologie, Springer Verlag, Berlin, 2000
[BAU93] Bauer, Friedrich L., Kryptologie, Springer, Berlin, 1993
[BELL03] Bell, Keith, Obfuscating e-mail addresses, 2003, http://
www.december14.net/ways/js/nospam.shtml
[BER03] Berbig, Frank, E-Post vom Sonderling. Ein Mailserver auf Basis
von Qmail, 2003, in: Linux Magazin 05/2003, Linux New Media,
München
[BER03a] Berbig, Frank, Safer Mail. Qmail abdichten, 2003, in: Linux
Magazin 08/2003, Linux New Media, München
[BEU02] Beutelspacher, Albrecht, Kryptologie, Vieweg, Wiesbaden, 2002
[BEU02a] Beutelspacher, Albrecht, Geheimsprachen. Geschichte und
Techniken, Beck, München, 2002
[CAPTCHA] von Ahn, Luis, Blum, Manuel, Hopper, Nicholas, Langford,
John, The Captcha-Project. Telling Humans and Computer apart
(Automatically), 2004, http://www.captcha.net
[CDT03] Center for Democracy and Technology, Why am I getting all this
spam?, 2003, http://www.cdt.org/speech/spam/030319spamreport.pdf
[COS97] Costales, Bryan, Allman, Eric, Sendmail. Second Edition, O'Reilly,
Sebastopol, 1997
No Spam! 151
Literaturverzeichnis
[DON04a] Donnerhacke, Lutz, Teergrubing Wrapper, 2004, http://www.iks-

jena.de/mitarb/lutz/usenet/antispam.html
[EGG04] Eggendorfer, Tobias, Privatadresse. Homepages spamsicher
gestalten, 2004, in: Linux User 05/2004, Linux New Media, München
[EGG04a] Eggendorfer, Tobias, Ernte - nein danke. E-Mail-Adressenjägern
auf Webseiten eine Falle stellen, 2004, in: Linux Magazin 09/2004, Linux
New Media, München
[EGG04c] Eggendorfer, Tobias, Stop Spam, Eigenverlag der Münchner
Volkshochschule, München, 2004
[EGG04d] Eggendorfer, Tobias, Safer Surfing, Eigenverlag der Münchner
Volkshochschule, München, 2004
[EGG04e] Eggendorfer, Tobias, Sicher Mailen. Kryptographie im Internet,
Eigenverlag der Münchner Volkshochschule, München, 2004
[EGG04f] Eggendorfer, Tobias, Adres zastrzezony. Projektowanie stron
internetowych chronionych przed spamem, Linux New Media, München,
2004
[EGG04g] Eggendorfer, Tobias, Private address. Design spamproof
homepages, Linux New Media, München, 2004
[EGG04h] Eggendorfer, Tobias, Fara spam - Tehnici prin care va puteti face
adresa email invizibila pentru spidere, Linux New Media, München, 2004
[EGG05] Eggendorfer, Tobias, Datenbanksysteme für
Wirtschaftsinformatiker. Eine Einführung, BoD, Norderstedt, 2005
[EGG05a] Eggendorfer, Tobias, Methoden der präventiven
Spambekämpfung im Internet, 2005
[EGG05b] Eggendorfer, Tobias, Möglichkeiten der Prävention der
Zusendung unerwünschter Werbe-E-Mails, 2005, in: Lecture Notes in
Informatics, Köllen Verlag, Bonn
[EGG05c] Eggendorfer, Tobias, Spam proof homepage design. Methods and
results of an ongoing study, ApacheCon Europe 2005
[EGG05d] Eggendorfer, Tobias, Gegengift. Virenscanner auf Linux-Servern:
Fünf Hersteller im Vergleich, in: Linux Magazin Sonderheft 03/2005,
Linux New Media, München, 2005
152
Literaturhinweise
[EGG05g] Eggendorfer, Tobias, Mix it, Baby. Mit dem Java Anonymous
Proxy unbeobachtet surfen, 2005, in: Linux Magazin 08/2005, Linux New
Media, München
[EGG05h] Eggendorfer, Tobias, Anonyme E-Mail, 2005, in: Linux Magazin
08/2005, Linux New Media, München
[FÖR05] Förtsch, Torsten, Eingriff ins Getriebe. Apache-interna mit
mod_perl programmieren, Linux New Media, München, 2005
[FRA04] Frank, Thomas, You've got (Spam-)Mail. Zur Strafbarkeit von E-
Mail-Werbung, 2004, in: Computer und Recht, Dr. Otto Schmidt Verlag,
Köln
[FRA04a] Frank, Thomas, Zur strafrechtlichen Bewältigung des Spamming,
2004
[FREY02] Freyermuth, Gundolf S., Kommunikette 2.0, dpunkt, Heidelberg,
2002
[FRI02] Friedl, Jeffrey E. F., Mastering Regular Expressions, O'Reilly,
Sebastopol, 2002
[GOO04] Goodman, Danny, Spam Wars. Our last best chance to defeat
spammers, scammers, and hackers, Selected Books, New York, 2004
[GRA04] Graham-Cumming, John, Die Tricks der Spammer, 2004, in:
Hackin9, Software-Wydawnictwo Sp. z.o.o, Warschau
[GRAV03] Freiherr von Gravenreuth, Günther, Kleinjung, Alexander J.,
Sind kostenpflichtige Mehrwertdienste-Rufnummern im Rahmen der
Anbieterkennung gemäß §6 TDG zulässig?, 2003, http://www.jurpc.de/
aufsatz/20030273.htm
[GUN04] Gunton, Neil, Stopping Spambots: A Spambot Trap. Using Linux,
Apache, mod_perl, Perl, MySQL, ipchains and Embperl, 2004, http://
www.neilgunton.com/spambot_trap/
[HEIN04] Heinlein, Peer, Das Postfix Buch. Sichere Mailserver mit Linux,
Open Source Press, München, 2004
[HEIN05] Heinlein, Peer, Massenversand. Workshop: Mailinglisten mit
Mailman sicher betreiben, 2005, in: Linux Magazin, Linux New Media,
München
[HEM03] Hemenway, Kevin, Calishain, Tara, Spidering Hacks. 100
Industrial-Strength Tips & Tools, O'Reilly, Sebastopol, 2003
No Spam! 153
[HOG04] Hoglund, Greg, McGraw, Gary, Exploiting Software. How to

break code, Addison-Wesley, Boston, 2004
[KIR00] Kirch, Olaf; Dawson, Terry, Linux Network Administrator's Guide,
Second Edition, O'Reilly, Sebastopol, 2000
[KOS94] Koster, Martijn, A Standard for Robot Exclusion, 1994, http://
www.robotstxt.org/wc/norobots.html
[KOZ04] Koziol, Jack et. al., The Shellcoder's Handbook. Discovering and
Exploiting Security Holes, Wiley Publishing, Indianapolis, 2004
[KUC05] Kuch, Erich, Uralter LAND-Angriff funktioniert wieder im
aktuellen Windows, 2005, in: Heise Newsticker, Heise, Hannover
[LOC04] Lockhart, Andrew, Network Security Hacks. 100 Industrial-
Strength Tips & Tools, O'Reilly, Sebastopol, 2004
[LÖD04] Löding, Torge, Verhaftungswelle gegen Spammer in den USA,
2004, http://www.heise.de/newsticker/meldung/50375
[MAT97] Matzke, Sascha, Q-Mail - Eine echte Alternative, 1997, in: Linux
Magazin 05/97, Linux New Media, München
[McN04] McNab, Chris, Network Security Assessment, O'Reilly,
Sebastopol, 2004
[McW05] McWilliams, Brian, Spam Kings. The Real Story Behind the High-
Rolling Hucksters pushing porn, pills, and @*#?% Enlargements, O'Reilly,
Sebastopol, 2005
[MOR04] Morgenstern, Christian, Gedichte, Insel, Frankfurt, 2004
[MÜN02] Münz, Stefan, HTML & Web-Publishing Handbuch (Band 1).
HTML - JavaScript - CSS - DHTML, Franzis, Poing, 2002
[MÜN02a] Münz, Stefan, HTML & Web-Publishing Handbuch (Band 2).
XML - DTDs - Perl/CGI, Franzis, Poing, 2002
[PEI04] Peikari, Cyrus, Chuvakin, Anton, Security Warrior. Know Your
Enemy, O'Reilly, Sebastopol, 2004
[REHWWW] Rehbein, Daniel, Adressensammler identifizieren – Ein
Beispiel, o. A., http://spamfang.rehbein.net
[REHWWWa] Rehbein, Daniel, Gift für Harvester - Aus meiner
Entwicklung, 2003, http://www.daniel-rehbein.de/spamgift.html
154
Literaturhinweise
[RFC0821] Postel, Jonathan B., Simple Mail Transfer Protocol, 1982,

http://www.ietf.org/rfc/rfc0821.txt (u.a.)
[RFC1855] Hambridge, Sally, RFC 1855. Netiquette Guidelines, 1995,
http://www.ietf.org/rfc/rfc1855.txt
[RFC2795] Christey, Steven M., RFC2795: The Infinite Monkey Protocol
Suite (IMPS), 2000, http://www.ietf.org/rfc/rfc2795.txt
[SCHOE04] Schoengarth, Anita, Application Service Providing, Otto
Schmidt, Köln, 2004
[SCHWE02] Schwenk, Jörg, Sicherheit und Kryptographie im Internet. Von
sicherer E-Mail bis zur IP-Verschlüsselung, Vieweg, Braunschweig, 2002
[SCHWE04] Schwenk, Jörg, Visual Spoofing, 2004, http://www.nds.rub.de/
forschung/gebiete/UI/VS/
[SEL02] Selig, Marc-André, Reguläre Ausdrücke. Nadel im Heuhaufen,
2002, in: Linux User, Linux New Media, München
[SHI05] Shiflett, Chris, PHP Security Briefing, 2005
[SIL01] Sill, Dave, The qmail Handbook, Apress, Berkeley, 2001
[SIN04] Singh, Simon, Geheime Botschaften. Die Kunst der
Verschlüsselung von der Antike bis in die Zeiten des Internet, dtv,
München, 2004
[STEI99] Stein, Lincoln D., MacEachern, Doug, Writing Apache Module
with Perl and C, O'Reilly, Sebastopol, 1999
[STU03] Stubblebine, Tony, Regular Expression. Pocket Reference,
O'Reilly, Sebastopol, 2003
[TAN02] Tanenbaum, Andrew S., Moderne Betriebssysteme, Pearson
Studium, München, 2002
[TUCEK] Tucek, Jim, Email Protector Version 4.06. Download Email
Protector, o. A. (Stand: 3.10.2004), http://www.jracademy.com/~jtucek/
email/download.php
[VIE01] Viega, John, McGraw, Gary, Building Secure Software. How to
Avoid Security Problems the Right Way, Addison-Wesley, Boston, 2001
[W3CAPPB] W3C, W3C Recommendations. Appendix B: Performance,
Implementation and Design, o. A., http://w3.org/TR/REC-html40/
appendix/notes.html
No Spam! 155
[WHA01] Whalley, Carl, Spam-free mailto:tags. How to use mailto:

functionality whilst preventing web crawlers from leeching your email
addresses, 2001, http://www.carmichael-data.com/art20011223.jsp
[WIE99] Wielsch, Michael; Prahm, Jens; Eßer, Hans-Georg, Linux intern.
Technik, Administration und Programmierung, Data Becker, Düsseldorf,
1999
[WIL04d] Wilkens, Andreas, Internet Explorer dominiert weiter in Europa,
2004, http://www.heise.de/newsticker/meldung/47706
[WILLI02] Williams, Steve, Thwarting Spambots, 2002, http://www.sbw.org/
spambot/
[WYM99] Wyman Carolyn, Spam: A Biography, Harvest Books, Fort
Washington, 1999
[ZIE99] Ziegler, Robert L., Linux Firewalls, New Riders, Indianapolis, 1999
156
Stichwortverzeichnis
§6 Nr. 2 TDG 43, 66, 69, 71 E

0190-Dialer 72 eCard 107
Eingabepuffer 96
A Elektronische Postkarte 107
Abmahnung 46 E-Mail-Anonymisierdienst 35
Absenderadresse, gefälschte 37 E-Mail-Werbung, unerwünschte 20
ActiveX-Control 72 Endlosschleife 123
Adresse der elektronischen Post 43, 44 ErrorDocument 127
Adressen, „verified“ 137
Adresshandel 31 F
Alias 127 Filter 15
Apache 95, 127 Flash 71
Apache Bench 100 Formmailer 47
Apache-Modul 95 Forum 33
Ausgabefilter 95
Ausgabestrom 95 G
Gästebuch 33
B Gesetz gegen den unlauteren Wettbewerb
BCC 23, 33 (UWG) 21
Beweislast 139 Gewerbsmäßigkeit 43
Blind-Carbon-Copy-Funktion 23, 33 Googlebot 123
Google-Spam 19
C grep 27
CAN-SPAM-Act 138
Cäsars Schiebealgorithmus 78 H
Cascading Style Sheets (CSS) 60 Harvester 25
Catch-All 36 HTML-Kommentar 59
Command-Line-Interface (CLI) 63 HTTP 404 127
Cross-Site-Scripting-Attacke 113 HTTP 500 93
HTTP/1.1 200 OK 127
D
Dechiffrieralgorithmus 77 I
Denial-Of-Service 124 Impressum 45
Dijkstra-Operationen 125 ipchains 93
document.write 74
dodgeit 34 J
DOM-Inspector 104 Java Anonymous Proxy 34
Double-Opt-In 138 JavaScript 72, 74
JPEG 67
No Spam! 157
K R
Kontaktaufnahme, schnelle 43 register_ globals 112
Kontaktformular 47, 56, 104 regular expression 26
REMOVE_TO_MAIL_ ME 45
L robots.txt 27, 128
local part 30
lynx: 60 S
Sammelgeschwindigkeit 123
M Satz von Rice 77
Mailingliste 137 Schlüssel 77
mailman 143 Screenshot 67
Majordomo 143 sed 27
Microdot 62 Semaphor 125
Mitstörerhaftung 103 sendmail 36, 145
mod_perl 95 Single-Opt-In 138
Monty Python 19 sleep 128
MyTrashMail 34 SMS 43
SMTP-Teergrube 39
N SPAM 19
Newsgroup 19, 28 Spamcop 15
Newsletter 137 Spamfilter 15
Spamgourmet 34
O Spamhole 34
OpenOffice.org 71 Spamming-Engine 103
Open-Relay-Blacklist 15 Spider 25, 123
Opt-In 138 SQL-Injection 110
confirmed 139 Standardausgabe 63
qualifiziertes 139 Standardeingabe 63
Opt-Out 138 StarOffice 71
Ordnungsgeld 41 STDIN 63
Ordnungshaft 41 STDOUT 63
P T
P(s) 125 Tabelle 64
Papier-Spam 19 Tarnen mit HTML 58
PDF 69 Teerfalle 124
PGP-Key-Server 29 Teergrube 40, 124
P-Operation 125 Telefonnummer 44
Proportionalschriftart 65
Puffergrenzen 96 U
UBE 20
Q UCE 20
qmail 37 Unsolicited Bulk E-Mail 20
158
Unsolicited Commercial E-Mail 20 W

Unterlassungsklagengesetz (UKlaG) 39 Webseiten, dynamische 93
URL-Encoding 63 Wegwerfadresse 34
User-Agent 93 wget 27
usleep 128 Whitespace 61
Whois-Eintrag 29
V
V(s) 125 X
Verschlüsseln 77 XOR 78
virtusertable 36, 145
V-Operation 126
No Spam! 159
Der Autor
Tobias Eggendorfer hat Wirtschaftsingenieurwesen, technische Informatik

und Informatik studiert und jeweils mit Diplom sowie Computer Science
mit einem Master of Science abgeschlossen. Darüber hinaus hat er ein
rechtswissenschaftliches Studium mit den Schwerpunkten Wirtschafts- und
Arbeitsrecht absolviert.
Er arbeitet freiberuflich als IT-Berater, hat einen Lehrauftrag im Bereich der
Informatik an einer Fachhochschule und unterrichtet außerdem an einer
Fachschule für Datenverarbeitung.
Sein Forschungsschwerpunkt liegt derzeit im Bereich der Spambekämpfung
und -vermeidung.
Ausführlichere Informationen über ihn finden sich auf seiner Webseite
http://www.eggendorfer.info.
160

Ebook - No Spam

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Ebook - No Spam

Hochgeladen von

Copyright:

Verfügbare Formate

Tobias Eggendorfer

Software & Support Verlag GmbH

© 2005 Software & Support Verlag GmbH

Ihr Kontakt zum Verlag und Lektorat: lektorat@software-support.biz

Bibliografische Information Der Deutschen Bibliothek

Korrektorat: Petra Kienle

5.2.2 Tarnen mit HTML . . . . . . . . . . . . . . . . . . . . . . . . 58

8 Harvester blockieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

Spamfilter sind langsam, fehleranfällig und wirken meiner Meinung nach am

In „Notwendige Vorkenntnisse“ gebe ich Ihnen einige Hinweise, welche Vor-

Ich wünsche Ihnen viel Spaß bei der Lektüre!

Um Programmbefehle zu markieren, verwende ich die folgende Darstellung:

Spam lässt Ihren E-Mail-Briefkasten überquellen. Doch warum eigentlich?

1.1 Untaugliche Filter

1.2 Spam an der Wurzel bekämpfen

3. [EGG05a], [EGG05b] und [EGG05c]

Im deutschsprachigen Linux-Magazin stellte ich erstmals auch ein Verfahren

Die Bezeichnung „Spam“ wird heutzutage in einer wesentlich umfassenderen

2.1 Etwas Geschichte

8. Siehe dazu: http://www.spam.com

In einem Usenet-Posting am 31. März 1993 wurde dann, so die Darstellung in

2.2 Spam und Recht

11. Detaillierter zur Rechtslage [EGG04c] mit zahlreichen weiteren Quellen.

spammte Adressen tatsächlich gelesen werden. Solche Adressen werden als

12. Siehe dazu z.B. [GOO04]

„Zwangsabonnement“ eines Newsletters nicht überraschende Klauseln sind,

2.3 Unsolicited Bulk E-Mail

13. Siehe dazu: [FREY02] und [RFC1855]

ClamAVs Milter für Sendmail14 Viren und Würmer bereits im SMTP-Dialog

3.1 Freiwillige Eingabe

3.2 Adressen im Internet automatisch sammeln

3.2.1 Durchsuchen von Internetseiten

Diese Sammelprogramme sind technisch eigentlich primitiv, denn man muss

grep -rhiE "mailto:" ./ | sed "s/.*mailto:\([A-Z0-9_-]\+\(\.[A-Z0-9_-

Anschließend werden die E-Mail-Adressen mittels des Hilfsprogramms tr

3.2.2 Newsgroups und ähnliche Quellen

3.2.3 Erraten von Adressen

Abb. 3.1: Meta-Spam: Diese Mail wirbt Spammer-Nachwuchs

Teilweise bleiben solche Adresslisten mehrere Jahre im „Handel“: Dadurch

4.1 Umgang mit Mailadressen

22. Der Teil der Mailadresse vor dem „@“-Symbol

4.3 Newsletter und Ähnliches

24. Ausführlichere Informationen zu Sendmail und dessen Konfiguration liefert [COS97]

4.4 Keinesfalls: gefälschte Absenderadressen

4.6 Spammer beim Sammeln identifizieren

25. So allen voran die Dissertation [FRA04a], zusammengefasst in [FRA04].

oder Ordnungswidrigkeiten z.B. wegen versuchten Betrugs oder Verstoß ge-

26. Stand: 03/2005

Homepages lassen sich grob einteilen in „geschäftliche“ und in private Seiten.

5.1 Adressen fälschen

Allerdings muss man zugestehen, dass die Fehlermeldung nicht sonderlich

5.2 Verstecken mit HTML-Code

Der mailto-Link jedoch ist noch einen Tick eindeutiger, da so neumodische

Wie sollte ein sicheres Kontaktformular aussehen?

cc: Adressaten, an die die Mail in cc gehen soll. Ebenfalls als

subject: Betreff der generierten E-Mail, Default-Wert steht in

msg: Nachricht, die der Absender eingegeben hat.

vars: Variablennamen, kommasepariert, die zusätzliche Daten ent-

$msg = "Absender-Email: ".trim($_REQUEST["from"]).

Meinungen zum Kontaktformular

5.2.2 Tarnen mit HTML

Diese Kommentare werden von allen Browsern in der Darstellung unterdrückt,

Abb. 5.1: Darstellung einer gesperrten E-Mail-Adresse