Skip Navigation

Strategien gegen Spam

Die aktuelle Zunahme von Spam hat in den Medien beträchtliche Beachtung gefunden und große Teile der IT-Branche neu sensibilisiert.

Ungezählte Software-Anbieter stellen der Bedrohung ihre Out-of-the-box Produkte entgegen und versuchen mit den aktuellen und zukünftigen Tricks der Spammer Schritt zu halten. Dabei hat sich Spam längst zu einem Problem entwickelt, dass sich technisch nicht mehr lösen läßt.

Das Transportprotokoll der E-Mail Kommunikation SMTP ist in einer friedlicheren Zeit entwickelt und etabliert worden und zeigt heute – wo jede zweite E-Mail unerwünscht ist – seine Beschränkungen. Auch in naher Zukunft wird sich an dieser Problematik nichts verändern.

Im Rahmen des Vortrages »Strategien gegen Spam« für den Workshop »Spam-Abwehr« des Competence Center for Applied Security Technology (CAST) am 19. Februar 2004 wurden diese Themen aufgearbeitet und in einer einführenden Übersicht präsentiert. Die Vortragsunterlagen stehen zum Download bereit (im OpenOffice- und im PDF-Format). Eine inhaltlich stark erweiterte und aktualisierte Fassung steht Ihnen ebenfalls zum Download zur Verfügung (PDF-Format; ca. 1 MB).

Bitte beachten Sie, dass diese Seite zu Ihrer freien Verfügung steht und gemäß der GNU Free Documentation License verwendet werden kann. (Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License Version 1.1.).

Was ist Spam?

Nach einer Reihe unterschiedlicher Bezeichnungen für unverlangt versendete Massen-E-Mails, die in den 80er Jahren entstanden (»mass mail abuse«, »broadcast mail«, »junkmail«), haben sich schließlich die Begriffe »Unsolicited Bulk Email« bzw. »Unsolicited Broadcast Email« (UBE) und »Unsolicited Commercial Email« (UCE) als offizielle Bezeichnungen durchgesetzt.

  • Unsolicited (dt. unverlangt, unerbeten, unaufgefordert): Die Zusendung der E-Mail wurde nicht explizit vom Empfänger angefordert oder erwartet.
  • Bulk (dt. Masse, Menge): identische Nachrichten wurden an eine nicht-triviale Anzahl von Empfängern versendet. Ab welcher Zahl von Empfängern eine Nachricht als UBE gelten kann, ist nicht definiert.
  • Commercial (dt. kommerziell, gewerblich): Die E-Mail wirbt i.d.R. für kommerzielle Produkte und Dienstleistungen.

Obwohl UCE und UBE häufig synonym verwendet werden, sind kommerzielle Massen-E-Mails nur eine Untermenge von UBE. Beispiele für nicht-kommerzielle UBE sind politische oder karitative Mailings, Kettenbriefe, virtuelle Unterschriftenaktionen oder Witze. Selbst wenn der Zweck eines Massenmailings in einigen Fällen aus ethischen oder anderen Gründen durchaus gutgeheißen werden kann, handelt es sich doch in der Regel um »Spam« (UBE).

Diese üblicherweise gebrauchte Bezeichnung »Spam« ist aus einem Monty Python Sketch entstanden, in dem eine Gruppe Wikinger mit ansteigendem Crescendo im Chor »Spam, Spam, Spam, ...« singt und dadurch alle anderen Gespräche erstickt. Die Verwendung des Ausdruckes »Spam« für UCE und UBE greift dieses Bild auf.

»Spam« hat dagegen nichts mit dem Lebensmittel »SPAM« (für »Spiced Pork and Ham«) der Firma Hormel gemein, auch wenn gelegentlich Abbildungen von SPAM-Konserven im Zusammenhang mit UBE gezeigt werden.

Wie wird Spam versendet?

Der Versand von E-Mails ist technisch gesehen – anders als z.B. das Abrufen einer Webseite – keine direkte Verbindung zwischen den beiden Endpunkten der Kommunikation (hier dem Absender und dem Empfänger der E-Mail).

Normalerweise sendet das E-Mail Programm des Absenders die Nachricht (zusammen mit den Empfängerangaben) an den SMTP-Server (siehe RFC 2554) seines Internet Service Providers (ISP, z.B. T-Online). Dieser SMTP-Server (»relay«, »smarthost«) erkennt an der Empfänger-Adresse, für welche Domain die Nachricht bestimmt ist und befragt ggf. einen DNS-Server nach der Adresse des zuständigen SMTP-Servers (»MX-Record«), um die E-Mail (wieder per SMTP) an diesen weiterzuleiten. Unter Umständen passiert die E-Mail mehrere SMTP-Server, bevor sie schließlich beim zuständigen Server eintrifft, der die E-Mail als Nachricht für einen lokalen Benutzer erkennt und über ein lokales Mailsystem in das Postfach des Empfängers einsortiert. Von dort wird sie vom Empfänger in der Regel über das POP3-Protokoll (siehe RFC 1939) abgeholt und in seinem E-Mail Programm angezeigt.

Korrekt konfigurierte SMTP-Server akzeptieren E-Mails nur, wenn Ihnen entweder der Empfänger einer E-Mail (um sie in dessen Postfach auszuliefern) oder deren Absender bekannt sind.

Da das SMTP-Protokoll per se keine Authentisierung kennt und die Absender-Angabe leicht gefälscht werden kann, erfordert die korrekte Konfiguration einen oder mehrere Mechanismen zur Sicherstellung einer legitimen Nutzung zum Mailversand. Die wichtigsten sind:

  • ACLs: Benutzer mit festvergebenen IP-Adressen (z.B. in Firmennetzen) können den SMTP-Server zum Mail-Versand nutzen. Die Konfiguration erfolgt über ACLs (Access Control List). Firewalls und andere Maßnahmen verhindern darüberhinaus den unerlaubten Zugriff.
  • SMTP-after-POP3: Benutzer mit wechselnden IP-Adressen (»Roaming Users«) authentisieren sich über einen Zugriff auf ein POP3-Konto (hier müssen sie eine Benutzerkennung und ein Passwort verwenden). Die Verwendung des SMTP-Servers wird dann für die jeweils aktuelle IP-Adresse für einen gewissen Zeitraum gestattet. Die aktuelle IP-Adresse wird temporär zur ACL hinzugefügt.
  • SMTP-AUTH: Eine Erweiterung des SMTP-Protokolls (siehe RFC 2554) ermöglicht eine Authentisierung über Benutzerkennung und Passwort (und einen Machanismus wie CRAM-MD5 oder andere). Nicht alle gängigen E-Mail Programme unterstützen diese Erweiterung.

Während IP-basierte ACL-Lösungen (auch SMTP-after-POP3) keinen Schutz gegen die Fälschung von IP-Adressen bieten, ist SMTP-AUTH ein brauchbares Verfahren zur Absicherung von SMTP-Servern gegen Missbrauch.

Nicht oder ungenügend abgesicherte SMTP-Server werden als »Open Relay« bezeichnet. Sie ermöglichen jedermann den Versand von (auch anonymen) E-Mails. Spammer – die in der Regel anonym bleiben wollen – verwenden offene Relays zum Versand von Spam.

Verständlicherweise schützt keines dieser Verfahren vor Spam, der direkt an den zuständigen SMTP-Server der Empfänger-Adresse versendet wird (»Direct-to-MX«).

Offene Relays, Formmailer und Zombies

Da Spammer – besonders natürlich in Ländern, die Spamming juristisch verfolgen – anonym bleiben wollen, werden sie in aller Regel einen fremden Rechner zum Versenden ihrer Massenmails verwenden. Dafür bieten sich im wesentlichen die folgenden Möglichkeiten:

  • Offene Relays: damit werden SMTP-Server bezeichnet, die aufgrund eines Konfigurationsfehlers oder Schwächen der eingesetzten Software grundsätzlich jedem Absender den Versand von E-Mails gestatten. In den letzten Jahren ist der Versand von Spam über offene Relays deutlich zurückgegangen.
  • Formmailer: viele Betreiber von Web-Seiten bieten ihren Besuchern die Möglichkeit über ein Formular mit ihnen in Verbindung zu treten. Die Verwendung eines Formulars bietet einen gewissen Schutz für die hinterlegte Adresse und kann den Besucher zwingen, bestimmte Angaben über sich selbst machen zu müssen, bevor ein Kontakt zustande kommt. Technisch sind derartige Formulare meist so realisiert, dass nach vollständigem Ausfüllen und Abschicken vom dahinter liegenden Skript eine E-Mail an den Webseiten-Betreiber gesendet wird. Leider ist eine Reihe von verbreiteten Skripten zur Abwicklung dieses Vorganges nicht mit den nötigen Sicherungsmaßnahmen versehen um Angriffe zu verhindern. Gelingt dem Spammer ein Angriff, kann er das Formular missbrauchen, um E-Mails an beliebige Empfänger zu versenden.
  • Zombies: sind an das Internet angeschlossene Computer, die in der Folge eines Befalls durch Viren, Würmer oder Trojaner, unter der Kontrolle eines Eindringlings stehen und von diesem für den Versand von Spam eingesetzt oder vermietet werden. In der Regel ist den Besitzern dieser Rechner nicht bekannt, dass ihr System unter fremder Kontrolle steht und für den Spam-Versand missbraucht wird. Spammer verfügen heutzutage über große Rechner-Netze, sog. »Zombie-Farmen«. Tatsächlich wird der größte Teil des aktuellen Spam-Versandes über Zombies abgewickelt.

All diese Formen des Versandes von Spam setzen einen (zumindest temporär) an das Internet angebundenen Rechner voraus, der über eine IP-Adresse identifiziert werden kann. In der Regel sind Mail- (offene Relays) und Web-Server (Formmailer) mit statischen Adressen ausgestattet und können darüber leicht wiedererkannt werden. Zombies nisten sich meist auf Arbeitsplatz-Rechnern ein, die über Einwahlverbindungen (»Dial-In«; Modem, ISDN oder DSL) mit dem Internet verbunden sind und keine statischen sondern wechselnde IP-Adressen besitzen.

Blockierung von IP-Adressen über DNSBL

Einige kommerzielle und nicht-kommerzielle Organisationen verwalten und verbreiten Listen mit IP-Adressen potentieller Spammer (DNSBL, »DNS-delivered Blocking/Blackhole List«). Angepasste und um DNSBL-Funktionalität erweiterte SMTP-Server können, sobald ein anderer Rechner eine Verbindung zum SMTP-Port herstellt, den Status von dessen IP-Adresse abfragen und – falls das sendende System als potentieller Spammer gelistet ist – die Übertragung der E-Mail mit einer Fehlermeldung abbrechen (meist 451 oder 553).

Die folgenden Organisationen bieten DNSBL:

Der Vorteil einer DNSBL-basierten Anti-Spam-Strategie ist der frühzeitige Ansatz. Statt E-Mails generell entgegenzunehmen und durch Content-Filter zu analysieren (was System-Ressourcen verbraucht), werden bereits die SMTP-Verbindungen von potentiellen Spammern blockiert.

Die wichtigsten Nachteile ergeben sich aus der technischen Implementierung. DNSBL blockiert jeden SMTP-Verkehr von den gelisteten IP-Adressen, und damit auch E-Mails von legitimen Absendern, die zwar den gleichen SMTP-Server verwenden, aber keinen Spam versenden (Collateral Damage). Diese »Sippenhaft« rechtfertigen DNSBL-Befürworter mit dem (auch finanziellen) Schaden, der durch Spam entsteht und fordern betroffene Absender auf, Druck auf ihre Service Provider auszuüben, offene Relays zu schließen und Spammer vom Netz zu nehmen.

Gegen Spam, der über Zombie-Rechner versendet wird, helfen DNSBL-basierte Strategien nur begrenzt. Hier führt der Umstand, dass die infizierten Rechner zum einen meist dynamische Adressen besitzen, und zum anderen in großer Zahl (»Farmen«) zur Verfügung stehen, zu einer Reduzierung der Effektivität dieses Ansatzes. Da aber Zombie-Rechner in aller Regel über Einwahlverbindungen an das Internet angebunden sind, schlagen einige Administratoren vor, die gesamten dynamischen Adressbereiche zumindest der großen Service-Provider global zu blocken. Sie argumentieren damit, dass die Provider ihren Kunden immer Mailserver für den Versand ihrer eigenen E-Mails zur Verfügung stellen, so dass der Betrieb eines SMTP-Servers auf der dynamischen IP-Adresse nicht notwendig sei.

Als nachteilig angesehen werden muss auch die Abhängigkeit vom Anbieter des DNSBL-Dienstes. Durch die Verwendung von Blackhole Listen übergibt der Administrator eines SMTP-Servers einen großen Teil der Kontrolle an einen Dritten. Dieser könnte beliebige IP-Adressen in seine Listen aufnehmen und so Zensur ausüben.

Ungeachtet der genannten Probleme reduziert alleine der Einsatz sorgfältig und konservativ ausgewählter DNSBL-Dienste das Spam-Aufkommen spürbar.

Schlagen Sie Ihre IP-Adresse im Openrbl DNSBL Lookup nach.

Einsatz serverseitiger bzw. clientseitiger Spam-Filter

Spam-Filter ermöglichen die Analyse einer E-Mail (Header und Body) nach unterschiedlichen Kriterien und geben eine Einschätzung über die Wahrscheinlichkeit ab, ob die untersuchte Nachricht Spam enthält oder nicht.

Da Spam-Versender in der Regel Ihre E-Mails nicht als UBE kennzeichnen (es gibt nationale juristische Offensiven, die dies erzwingen wollen), existieren zur Analyse eingehender Nachrichten keine objektiven Kriterien. Aktuelle Spam-Filter arbeiten daher mit verschiedenen Bewertungsverfahren, um Spam hinreichend genau zu erkennen. Das Auftreten mehrerer Merkmale erhöht dabei die Wahrscheinlichkeit; das Überschreiten eines Schwellenwertes indiziert eine positive Erkennung. Wird Spam erkannt, kann die Nachricht in Quarantäne gestellt oder mit einer Markierung (im Betreff z.B. durch Voranstellen von »[SPAM?]« oder in eigenen Header-Feldern, z.B. »X-Spam-Status: Yes«) versehen ausgeliefert werden, um dem Empfänger eine Filterung zu ermöglichen.

Da Spam-Filter keine 100%-ige Genauigkeit bei der Erkennung bieten können, ist der Markierungsansatz sicher vorzuziehen.

Die folgenden Abschnitte zeigen gängige Verfahren zur Erkennung von Spam. Einige bis alle sollten in aktuellen Spam-Filtern implementiert sein.

Typische Formulierungen (Phrases)

Spam enthält oft eine Reihe von Textformulierungen, die typisch sind für UCE und die besonders beim Auftreten mehrerer typischer Formulierungen Indizien zur Erkennung liefern. Beispiele für englischsprachige Phrases sind:

  • check or money order
  • MILLION DOLLARS
  • PURE PROFIT
  • No EXPERIENCE
  • Free money
  • click to remove yourself
  • VIAGRA
  • Big Boobs
  • adult entertainment
  • instant access
  • impotence cure

Für sich genommen sollten die gezeigten Formulierungen keinen Alarm schlagen, da die Wahrscheinlichkeit zu hoch ist, dass sie auch in legitimer E-Mail auftreten können.

Typische Eigenschaften der E-Mail

Spam weist oft Eigenschaften auf, die legitime E-Mails in der Regel nicht besitzen. Einige Beispiele sind:

  • Das Header-Feld »User-Agent« zeigt nicht auf ein bekanntes E-Mail Programm (z.B. Outlook Express).
  • Eine oder mehrere Zeilen sind komplett in Großbuchstaben geschrieben.
  • Die E-Mail hat keinen (korrekten) Absender.
  • Die E-Mail verweist darauf, dass sie nach »Senate Bill 1618« kein Spam sei (der Verweis ist irrelevant und ein Indiz für Spam).
  • Die Betreff-Zeile enthält viele Leerzeichen, Großbuchstaben o.ä.
  • Das Datum der E-Mail ist ungültig.
  • Die Nachricht enthält Spam-typische HTML-Auszeichnungen.

Eine gute Übersicht über mögliche Formulierungen und Eigenschaften bietet die Webseite von SpamAssassin.

Checksummen-Prüfung

Da Spam selten an wenige Empfänger versendet wird, verfolgt ein Ansatz zur Erkennung von Spam die Sammlung von Prüfsummen (»Fingerabdrücken«) manuell gesichteter und als UBE klassifizierter E-Mails. Die Spam-Filter-Software berechnet über eingehende E-Mails entsprechende Prüfsummen und gleicht diese mit dem Anbieter des Verfahrens ab. Im positiven Fall ist die Prüfsumme dort als Spam gelistet und ein sehr zuverlässiges Indiz dafür, dass die untersuchte Nachricht ebenfalls Spam ist (schließlich ist sie vollständig oder zumindest im hohen Maße identisch und generiert eine identische Prüfsumme). Aktuelle Verfahren versuchen geringfügige Änderungen am Nachrichten-Text nicht in die Prüfsummenberechnung einfließen zu lassen, um dadurch höhere Erkennungraten zu erreichen.

Die bekanntesten Vertreter und Anbieter von Prüfsummen-Datenbanken sind:

DNSBL-Prüfung

Auch das o.g. Verfahren zur Ermittlung von offenen Relays über DNSBL kann (sofern nicht auf Ebene des SMTP-Server umgesetzt) in Spam-Filter-Software implementiert werden und zur Spam-Erkennung beitragen. Ein Vorteil ist, dass gelistete IP-Adressen als Indiz für Spam gelten, eine Blockierung aber nicht generell erfolgen muss. Kollateral-Schäden werden dadurch verringert.

Statistische Verfahren, Bayesian Filter

Mit dem Bayesian-Filter-Verfahren können große Mengen (mehrere hundert bis tausend Nachrichten) handverlesene Spam- und legitime E-Mails statistisch ausgewertet werden. Dabei werden Worthäufigkeiten analysiert und für spätere Analysen von Nachrichten mit unbekanntem Status gespeichert. Neue E-Mails werden einer statistischen Auswertung unterzogen und mit dem bisherigen Datenbestand abgeglichen. Die Erkennungsrate ist dabei sehr hoch (ca. 99.5%). Der Nachteil eines statistischen Verfahrens liegt im zwingenden Vorhandensein von großen Mengen an Spam, die manuell zusammengestellt werden müssen. Für den Einsatz in serverseitigen Spam-Filtern scheidet das Verfahren daher in aller Regel aus. In E-Mail Programmen – vor allem weil dort handverlesene UBE in einem eigenen Verzeichnis vorgehalten werden kann – bietet sich der Einsatz dagegen an.

Weitere Infos finden Sie auf den Seiten von Paul Graham.

Body-URI-basierte Blocklisten

Angeregt durch eine Publikation von Paul Graham entwickelte sich ein Verfahren zur Erkennung von Spam auf der Grundlage der Links, die im Text einer E-Mail beworben werden. Wenn innerhalb einer E-Mail Webseiten beworben werden, können die zugehörigen Adressen (URI) als verlässliche Informationen angesehen werden. In der Folge kann man das Auftauchen von häufig in Spam beworbenen Adressen als Indiz für Spam werten.

In der Praxis wird dafür ein Verfahren namens RHSBL eingesetzt, dass analog zu DNSBL funktioniert, aber statt einer Abfrage über die IP eine Abfrage über den URI verwendet. Gegenüber DNSBL besteht allerdings ein zusätzlicher Aufwand bei der Überprüfung von Body-URIs darin, die Web-Adressen zuverlässig aus dem Textkörper der E-Mail zu extrahieren.

Jeff Chan bietet mit SURBL - Spam URI Realtime Blocklists eine Reihe von Blocklisten, mit denen sich sehr erfolgreich Spam erkennen läßt.

Beispiel: SpamAssassin

Der Spam-Filter SpamAssassin kombiniert in seiner aktuellen Version die meisten der gezeigten Verfahren in seiner Bewertung untersuchter E-Mails (Bayesian Filtering ab Version 2.50, Body-URI-Checks ab Version 3.0). Eine legitime Mail wird von SpamAssassin z.B. folgendermaßen markiert (im Header): 

X-Spam-Status: No, hits=-102.4 required=8.0
        tests=FWD_MSG,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01,
              USER_AGENT_APPLEMAIL,USER_IN_WHITELIST
        version=2.44-zeitform_1.05
X-Spam-Level:

Der X-Spam-Status gibt Auskunft über die Spam-Wahrscheinlichkeit (hier -102.4 Punkte, gegenüber 8.0 Punkten als Schwellenwert für eine positive Spam-Erkennung) und die erfolgreich durchgeführten Tests (hier hat USER_IN_WHITELIST deutlich zur Reduzierung der Spam-Wahrscheinlichkeit beigetragen).

Eine als Span erkannte Nachricht wird z.B. so markiert: 

X-Spam-Status: Yes, hits=20.4 required=8.0
        tests=BEST_PORN,BIG_FONT,CLICK_BELOW,CLICK_HERE_LINK,
              CTYPE_JUST_HTML,DATE_IN_FUTURE_06_12,FREE_PORN,
              HTML_FONT_COLOR_BLUE,HTML_FONT_COLOR_NAME,
              HTML_FONT_COLOR_RED,HTML_FONT_INVISIBLE,HTML_WITH_BGCOLOR,
              INVALID_DATE,RAZOR2_CHECK,RCVD_IN_BL_SPAMCOP_NET,
              RCVD_IN_OSIRUSOFT_COM,RCVD_IN_SBL,SPAM_PHRASE_21_34,
              UNSUB_PAGE,USER_AGENT_MOZILLA_XM,X_OSIRU_SPAM_SRC
        version=2.44-zeitform_1.05
X-Spam-Level: ********************
X-Spam-Flag: YES
X-Spam-Report:   20.40 hits, 8 required;
 * -0.1 -- X-Mailer header indicates a non-spam MUA (Netscape)
 *  1.5 -- Invalid Date: header (not RFC 2822)
 *  0.5 -- BODY: Possible porn - Best, Largest Porn Collections
 *  0.5 -- BODY: Possible porn - Free Porn
 *  0.3 -- BODY: Asks you to click below
 *  1.9 -- BODY: Spam phrases score is 21 to 34 (high)
            [score: 24]
 *  0.3 -- BODY: HTML font color is same as background
 *  0.3 -- BODY: FONT Size +2 and up or 3 and up
 *  0.3 -- BODY: HTML font color has unusual name
 *  0.3 -- BODY: HTML mail with non-white background
 *  0.3 -- BODY: HTML font color is red
 *  0.2 -- BODY: HTML font color is blue
 *  0.3 -- BODY: Tells you to click on a URL
 *  0.1 -- URI: URL of page called "unsubscribe"
 *  3.9 -- Listed in Razor2, see http://razor.sf.net/
 *  1.1 -- Date: is 6 to 12 hours after Received: date
 *  2.0 -- RBL: Received via a relay in bl.spamcop.net
            [RBL check: found xx.xx.xx.xx.bl.spamcop.net.]
 *  0.4 -- RBL: Received via a relay in relays.osirusoft.com
            [RBL check: found xx.xx.xx.xx.relays.osirusoft.com.]
 *  3.2 -- RBL: Received via SBLed relay, see http://www.spamhaus.org/sbl/
            [RBL check: found xx.xx.xx.xx.sbl.spamhaus.org.]
 *  2.7 -- RBL: DNSBL: sender is Confirmed Spam Source
 *  0.4 -- HTML-only mail, with no text version

Der X-Spam-Status kennzeichnet die E-Mail als Spam (mit einer Wahrscheinlichkeit von 20.4 von benötigten 8.0 Punkten). Zusätzlich bildet X-Spam-Level die Punktezahl graphisch ab und das Header-Feld X-Spam-Flag ist gesetzt (»YES«). Beide Felder ermöglichen eine differenzierte Filterung im E-Mail Programm. Unter X-Spam-Report werden alle erfolgreich angewandten Regeln gelistet, die zur Erkennung als Spam geführt haben. Aus dieser Liste wird im Beispiel ersichtlich, dass diese E-Mail (bzw. ihr Absender) sowohl typische Formulierungen und Eigenschaften von Spam enthält, als auch in Razor (Checksummen-Prüfung) und diversen DNSBL-Listen aufgeführt ist.

Weitere Strategien

Whitelisting, Digitale Signaturen und Habeas Warrant Mark

Der restriktivste Ansatz im Kampf gegen Spam erlaubt den erfolgreichen Versand von E-Mails nur in solchen Fällen, in denen die E-Mail bestimmte Anforderungen erfüllt. Die folgenden Beispiele erläutern diese Strategie:

  • Whitelist: Nur Absender, die in einer Liste (Whitelist) geführt und damit dem Empfänger bekannt sind, dürfen E-Mails an den Empfänger versenden. Der bekannte Spam-Filter Tagged Message Delivery Agent (TMDA) beispielsweise versendet in allen anderen Fällen eine Bestätigungsnachricht an den Absender mit der Bitte, diese zu beantworten. Erst dann wird die ursprüngliche E-Mail zugestellt und der Absender in die Whitelist aufgenommen. Spam wird durch dieses Verfahren äußerst zuverlässig geblockt, allerdings entsteht ein nicht unerheblicher Aufwand für alle legitimen Absender, die nicht in der Whitelist aufgeführt sind. Wer Whitelist-Filter verwendet, muss damit rechnen, dass eine Reihe von Absendern sich weigern wird mit dem Empfänger zu kommunizieren.
  • Digitale Signaturen: Digitale Signaturen (S/MIME) erlauben dem Absender das Unterschreiben einer Mail und damit dem Empfänger das Überprüfen dessen Identität. Bei der Verwendung von Digitalen Signaturen zur Bekämpfung von Spam werden nur E-Mails zugestellt, die signiert sind. Spam-Versender würden durch eine Signatur ihre Anonymität einbüssen. Damit ist nicht zu rechnen. Leider ist die Verwendung von Digitalen Signaturen – außer in geschlossenen Benutzergruppen – nicht sehr verbreitet.
  • Habeas Warrant Mark: Die Firma Habeas bietet mit ihrem »warrant mark« eine Möglichkeit, E-Mails als Spam-frei zu kennzeichnen. Der Absender fügt zu diesem Zweck einen speziellen Text in den Header seiner E-Mail ein. Da Habeas auf diesen Text ein Copyright hält und die Verwendung in Spam untersagt und juristisch verfolgt, kann eine entsprechend gekennzeichnet E-Mail als legitime Nachricht gelten.

Die gezeigten Verfahren stellen sicher, dass die positiv erkannten Nachrichten kein Spam sind. Werden alle anderen E-Mails blockiert, entsteht hoher Kollateral-Schaden. Sinnvoll erscheint in jedem Fall eine Einbindung in Spam-Filter, die auf der Basis von Positiv-Listen den Wert einer Spam-Wahrscheinlichkeit deutlich herabsetzen, die Spam-Erkennung aber anderen Verfahren überläßt.

Kontextabhängige E-Mail Adressen

Anwender mit einem entsprechend großen Adress-Pool können für jeden Korrespondenz-Partner eine eigene E-Mail Adresse verwenden. Beim Empfang von E-Mails muss dann geprüft werden, ob Nachrichten an die verwendete Empfänger-Adresse von der zugeordneten erwarteten Absender-Adresse geschickt wurden. E-Mails von anderen Absendern können als illegitim verworfen werden. Diese Maßnahme erweist sich als wirksam gegen den Missbrauch von E-Mail Adressen durch Adresshandel, erfordert aber – im Gegensatz zum Lösungsansatz von TMDA – keine weiteren Aktionen von legitimen Absendern. Der Aufwand zur Verwaltung der Zuordnungen bzw. der zugehörigen Filterregeln im E-Mail Client ist aber nicht trivial.

qmail bietet beispielsweise durch die Verwendung von Adresserweiterungen in der Form benutzer-erweiterung@domain.com Benutzern zusätzlich zur Adresse benutzer@domain.com einen unbeschränkten Pool an weiteren Adressen. Leider haben nur wenige Anbieter von POP3-Konten vergleichbare Funktionalitäten implementiert.

Einem Konzept von Daniel A. Rehbein folgend generieren die beiden hier gezeigten Perl-Funktionen verschlüsselte Adresserweiterungen, die neben dem Datumsstempel auch eine IP-Adresse enthalten. Werden auf einer Webseite Adressen veröffentlicht, die dynamisch aus der IP Adresse des zugreifenden Rechners generiert werden, können empfangene Spam-Mails dann einer IP-Adresse zugeordnet werden. Die zusätzliche Verschlüsselung dient der Beweisbarkeit bei eventuellen juristischen Schritten. 

# usage:
#
# my $ip   = $ENV{REMOTE_ADDR};   # e.g. "146.140.8.123"
# my $time = time;                # unix timestamp
# my $key  = "0123456789ABCDEF";  # key for Blowfish
#
# to generate the spamtrap string:
#
# my $string = spamtrap_encode($ip, $time, $key);  # e.g. 78c1ed6da0322b3a
#
# to decode:
#
# ($ip, $time) = spamtrap_decode($string, $key);
#     returns ip address and timestamp

sub spamtrap_encode
  {
     my ($ip, $time, $key) = @_;
     return unless $key;
     return unless $time > 0;

     return unless $ip =~ /^(d+).(d+).(d+).(d+)$/o;
     my $inkey = pack("H16", $key);
     my $plaintext = join("", map { chr } split (/./, $ip)) .
                     pack("L", $time);
     use Crypt::Blowfish;
     my $cipher = new Crypt::Blowfish $inkey;
     my $string = unpack("H*", $cipher->encrypt($plaintext));
     return $string;
  }

sub spamtrap_decode
  {
     my ($string, $key) = @_;
     return unless $key;
     return unless $string =~ /[0-9a-f]{16}/o;
     my $inkey = pack("H16", $key);
     use Crypt::Blowfish;
     my $cipher = new Crypt::Blowfish $inkey;
     my $plaintext = $cipher->decrypt(pack("H*", $string));
     my $time = unpack("L", substr($plaintext, 4, 4));
     my $ip = join(".", map { ord } split //, substr($plaintext, 0, 4));
     return wantarray ? ($ip, $time) : "$ip $time";
  }

Stehen keine Möglichkeiten zur Verwendung kontextabhängiger Adress-Erweiterungen zur Verfügung, läßt sich das entsprechende Verhalten durch die Verwendung von POP3-Accounts diverser Freemail-Anbieter nachbilden. Je nach entgegen gebrachtem Vertrauen, gibt man potentiellen Kommunikationspartnern dann eine dieser Adressen und kann den Account ggf. stilllegen, sollte sich das Spam-Aufkommen häufen.

Verzicht auf Veröffentlichung

Ein beliebter Ratschlag zur Reduzierung von Spam ist der Verzicht auf die Publikation der eigenen E-Mail Adresse oder doch zumindest die Verwendung einer obskuren Form der Veröffentlichung. Durch die Publikation einer Adresse z.B. in der Form benutzer at domain dot com wird den Erntemaschinen der Spammer das erfolgreiche Sammeln der E-Mail Adresse erschwert oder bei fehlender technischer Finesse gar verhindert. Beispiele für derart »geschützte« Adressen sind:

  • benutzer at domain dot com und vergleichbare Formen
  • Adressen oder Adressteile als Graphiken
  • Durch JavaScript verschlüsselte Adressen
  • Schutz der Adresse durch Captcha-Technologien. Beispiel: Kontaktadresse

Während die Nachteile eines völligen Publikationsverzichtes evident sind, verlangen die verschleierten Veröffentlichungsformen in der Regel einen zusätzlichen Aufwand zur Kontaktaufnahme oder erfordern zusätzliche Technologien (z.B. aktiviertes JavaScript), der Nutzen ist hingegen zweifelhaft.

Im Kampf gegen Adress-Ernte-Roboter werden u.a. Spam-Fallen eingesetzt, die Webseiten mit unzähligen ungültigen E-Mail Adressen generieren und damit die gesammelten realen Adressenbestände verunreinigen (»poison«) und im Wert mindern (z.B. Wpoison).

Stimm gegen Spam!

Bitte beachten Sie auch die Literaturhinweise innerhalb der genannten RFCs.

| Mailserver | Webserver | Weitere Infos | Kontakt |
| Startseite | Mailserver | Webserver | Weitere Infos | Kontakt |