Spamabwehr vor Kapitulation: Greifen gängige Methoden noch?

Wenn Fingerprinting teuer und ressourcenintensiv ist, Greylisting nicht mehr wirkt und Blacklisting dem Prinzip der Netzneutralität widerspricht, dass jeder Netzknoten mit jedem anderen frei kommunizieren kann, dann stellt sich die Fragen nach Alternativen.

Ein interessanter Vorschlag kam im Jahre 2004 von Bill Gates: Jede E-Mail soll einen Betrag von etwa einem Cent kosten. Man hätte erwartet, dass er genug von Marketing versteht, und Welle der Entrüstung vorherzusehen, die er mit dem Vorschlag auslöste, einen bisher kostenlosen Dienst im Internet zu einem kostenpflichtigen zu machen.

Doch so absurd ist der Vorschlag nicht. Auf diese Art und Weise hebelt man das Geschäftsmodell der Spammer aus. Ein Spammer muss täglich mehrere Millionen E-Mails aussenden, damit sich die Sache lohnt. Bei einem Preis von einem Cent pro Mail kommen auf den Spammer tägliche „Portokosten“ von einigen zehntausend Euro zu. Private Nutzer, die maximal 100 E-Mails pro Monat versenden, zahlen hingegen nicht mehr als einen Euro.

Erst auf den dritten Blick wird die Undurchführbarkeit deutlich. So müsste beispielsweise ein Sportverein möglicherweise auf Rundschreiben an seine Mitglieder verzichten, weil die Kosten zu hoch sind. Viele seriöse Opt-In-Newsletter müssten eingestellt werden.

Lösen ließe sich die Spamproblematik mit dem Sender-Policy-Framework (SPF). Dabei trägt jeder Domaininhaber selbst im DNS ein, von welchen Rechnern im Internet er E-Mails versendet. Da Spammer echte Domainnamen als Absender verwenden müssen, kann der empfangende SMTP-Server per DNS abfragen, ob die E-Mail von einer IP-Adresse kommt, die der Domaininhaber explizit zugelassen hat.

Ein Spammer kann diesen Mechanismus nur mit IP-Spoofing umgehen. Das können Provider mit heutigen Routing-Protokollen allerdings wirkungsvoll verhindern. Einem Provider, der IP-Spoofing zulässt, muss man mindestens eine aktive Duldung von Spam unterstellen.

Schwieriger gestaltet sich die Problematik von Wegwerf-Domains. Ein Spammer kann eine Domain registrieren, der er einen dazu passenden SPF-Record spendiert. Da sein Botnetz jedoch möglicherweise sehr groß ist, muss er viele und vor allem große Subnetze in den SPF-Record eintragen. Mailserver könnten dann SPF-Records, die mehr als 1000 mögliche SMTP-Server für eine Domain ausweisen, als Spam-Domains einstufen.

SPF funktioniert allerdings nur, wenn sich alle Mailserverbetreiber daran beteiligen. SPF wurde bereits im Jahre 2003 entwickelt und im April 2006 als RFC 4408 mit dem Status „Experimental“ veröffentlicht.

In der Praxis gibt es jedoch Umsetzungsprobleme. Viele Mailer unterstützen keine Auswertung von SPF-Records. Dazu gehören beispielsweise Microsoft Exchange und Sendmail. Hier müssen externe Lösungen implementiert werden. Einer der wenigen SMTP-Server, die SPF von Haus aus beherrschen, ist Communigate.

Viele ISPs haben zwar selbst SPF-Records für ihre Domains im DNS realisiert, für die Domains ihrer Kunden ist es heute oft noch unmöglich, SPF-Records anzulegen. Darüber hinaus zeigen erste Erfahrungen, dass viele SPF-Einträge falsch oder nicht aktuell sind. Das liegt daran, dass man sich durchaus einige Gedanken machen muss, wie man seinen SPF-Eintrag aufbaut. Will man fremde SMTP-Server verwenden, beispielsweise der Firma oder der Universität, verwenden, um Mails mit der eigenen Domain als Absender zu verschicken, so müssen sie im SPF-Record eingetragen und bei Bedarf aktualisiert werden.

Mailserver-Betreiber scheuen sich deshalb vor der Auswertung der SPF-Einträge. Sind sie falsch oder veraltet, kommt es zu False Positives. Außerdem kann es bei der Weiterleitung von E-Mails Probleme geben. Folgt man dabei dem Protokoll nicht exakt, so kann ein Mailer nicht mehr feststellen, dass er für die SPF-Auswertung das weiterleitende E-Mail-Konto verwenden muss.