Anti-Spam – Neben direkten Maßnahmen gegen Mail-Müll, seien es einfache Blacklists oder aufwändige Analysefilter, will eine Reihe von Anbietern die Mail selbst abhärten. Drei Verfahren stehen in Konkurrenz, die der elektronischen Post Authentifizierung beibringen wollen.

Es ist wie mit diesen Handy-Klingeltönen. Schon mal jemanden getroffen, der seine Umwelt mit dem »Crazy Frog«-Song nervt? Höchst selten. Anscheinend aber verdienen die Klingelton-Anbieter genügend Geld, denn sie pflastern die Werbezeiten zu später und früher Stunde mit ihren Clips zu.

Gleiches gilt für Spam. Niemand will jemals darauf reagiert, geschweige denn die Angebote wahrgenommen haben.Es wirkt aber so, dass beispielsweise genügend Männer ein zu »kurzes« Verhältnis zu ihrem besten Stück haben. Wie sonst ist zu erklären, dass Spam immer noch mit Maschinchen, Saugapparaten und ähnlichem Folterwerkzeug werben, um das Verhältnis zu »verlängern«? Die Spam-Schreiber verdienen damit Geld.Wie viel, ist schwer zu sagen,wie bei allen Graumärkten.Die führenden Anti-Spam- Anbieter, seien es Provider oder Hersteller,meiden es bisher, Schätzungen zu wagen. Gesichert ist indes, dass die Spam-Flut nicht nachlässt.Das zeigen einmal Statistiken führender Hersteller und Dienstleister.Bill Gates sagt, das Spam-Problem werde sich in wenigen Jahren erübrigt haben.

Möge er Recht behalten, aber wie realistisch ist seine Annahme? Es ist in der Tat zu viel Geld im Spiel, als dass sich die Spam-Entwickler nicht neue Wege einfallen lassen würden, sobald die Gegenseite bevorzugte Distributionstechniken mit geschickten Gegenmaßnahmen blockiert. Heute ist und bleibt es wichtig, Spam zu bekämpfen. Einerseits technisch über Anti-Spam- Filter.Die Real-World Labs haben daher fünf dieser Software-Tools daraufhin untersucht,wie geschickt sie die Müll-Mails von legalen Nachrichten unterscheiden.Ein anderer Weg sind Authentifizierungsverfahren, die die Industrie grob gesagt in das SMTP-Protokoll einbetten will.Die Internet-Engineering-Task-Force, zuständiges Gremium, hat aus drei Vorschlägen auszuwählen. Zur Disposition stehen »Sender Policy Framework« (SPF), Sender-ID und »Domain Keys Identified Mail« (DKIM).

Sage, wer du bist

Das SPF funktioniert prinzipiell wie ein »Reverse- MX«-Eintrag. Die SPF-Einträge teilen anderen Mail-Servern mit, welche Out-Bound-Server Mails an den eigenen Server schicken dürfen.Die Einträge sind ausgearbeitete DNS-TXT-Records. Sie können auch einen »Confidence Level «, eine Vertrauenswürdigkeitsstufe, mitgeben. Dieser hilft dem Empfänger-E-Mail-System dabei, die Authentizität der Quelle zu bewerten. Das Verfahren ist kostenlos, erfordert aber einige Modifikationen an der Mail-Software. Eine ganze Reihe von Clients,Anti-Spam-Geräten und Message-Transfer-Agents (MTA) beherrschen es bereits. Glaubt man dem Analysten Forrester, veröffentlichen derzeit 25 bis 30 Prozent aller Mail-Domains eigene SPF-Records. Damit ist SPF das derzeit am meisten benutzte Authentifizierungsverfahren.

SPF überprüft, ob der Sender und die »from«- Adresse im SMTP-Protokoll ausdrücklich über den betreffenden Mail-Server Nachrichten ver-schicken dürfen. Die Outbound- Mail-Server bei AOL beispielsweise sollten daher niemals Mails verschicken, die als Sender Hotmail- Adressen enthalten.Wenn ein SPFfähiger Server eine solche Meldung erhält, prüft er den SPF-Eintrag von Hotmail. Er findet so schnell heraus, dass der sendende AOL-Server keine Mails mit der Hotmail-Adresse als Quelle verschicken darf. Der Hotmail- DNS-Server liefert diese Antworten in seinen eigenen SPF-Einträgen nebst Confidence-Level. Auf Basis dieser Informationen weiß der Empfänger-Server wiederum,dass es sich wahrscheinlich um Spam handelt, und leitet entsprechende Maßnahmen ein.

Alle diese Einträge beginnen mit »v=spf1«. Der Parameter zeigt an, dass es sich um einen SPF-Eintrag handelt.Nach diesem String folgt eine Liste mit autorisierten Sending- Mail-Servern. Das Verfahren unterstützt dazu Schlüsselbegriffe wie »ptr«, die all jene Hosts beschreibt, welche in der Domain zu Hause sind. Der allgemeine Parameter »mx« definiert alle MX-Hosts.Der letzte Teil legt einen der vier Confidence-Level fest: »fail«, »softfail«, »pass« oder »neutral«. Diesen Wert greift der Empfänger-Server als einen Indikator für seine Entscheidung auf. Die Einträge werden inzwischen von E-Mail-Providern wie AOL, Hotmail oder Roadrunner sowie von großen Unternehmen wie Ebay veröffentlicht.

Wer möchte, kann sich die Einträge über DNS-Query-Werkzeuge anschauen. Die Vorteile des Verfahrens sind eindeutig: Einfach DNS-Einträge hinzufügen, und schon können andere die SPF abrufen. Wer seinen MTA um das Verfahren erweitert, darf die Definitionen anderer abrufen und sie als Grundlage dafür nutzen, zwischen legaler und Spam- Nachricht zu unterscheiden.

Aber das Verfahren hat auch seine Grenzen. Es hält Phishing nicht auf. Denn es prüft nur die Returnund nicht die »from«-Adresse, die die Anwender am Ende in ihren Clients sehen.Auch mobile Anwender werden Probleme haben, da sie immer die SMTP-Server-Adresse jenes ISPs verwenden, dessen Internet-Leitung sie gerade nutzen. Der Empfänger der Mail wird die SPF des ISPs nicht mit dem User in Einklang bringen und alle seine Nachrichten im schlimmsten Fall blockieren. Dies ließe sich mit »SMTP AUTH« unterbinden. Anwender müssten sich dann per Name und Passwort beim Outbound- SMTP-Server registrieren.Die Webseite »www.openspf.org« enthält einen Wizard, der Unternehmen bei der Einrichtung dieses Verfahrens unterstützt.Der entsprechende Internet-Draft ist unter www.ieft.org/internet-drafts/draft-schlitt-spfclassic- 2.txt zu finden.

Die Idee mit Sender-ID

Sender-ID ist eine Erweiterung zu SPF und rückwärts kompatibel.Microsoft hat es für ihre Mail- Dienste ins Leben gerufen. Sie zeigen die Sender- ID-Parameter auch in den User-Interfaces an. Das Verfahren greift wie SPF auf die DNSTXTs zurück. Der Hauptunterschied zwischen beiden ist, dass Sender-ID auch die »from«- Adresse im Body der Mail prüft, statt nur in den SMTP-Layer zu schauen. Damit kann das Verfahren Phishing besser bekämpfen. Und es kostet wie SPF nichts.Wer es einsetzen möchte,muss nur einen DNS-Eintrag einrichten.Aber wie SPF wird Sender-ID bei mobilen Anwendern und bei einigen Diensten problematisch.

Die größte Sorge bereitet Microsofts unsägliches Patentlizenzmodell. Organisationen wie AOL, Apache oder die Open-Source-Initiative (OSI) haben ihre Unzufriedenheit in der darin verwendeten Sprachregelung klar ausgedrückt. Diese Gruppe ist überzeugt, dass ein Hersteller keine Monopolstellung bei solch wichtigen Kernspezifikationen einnehmen dürfe. Die Open-Source-Gemeinde ist vor allem darüber gestolpert, dass Microsoft von seinen Konkurrenten Einsicht verlangt, sobald diese Sender-ID selbst branden oder weitergeben wollen. Damit hätte der Software-Gigant Einblick in die Geschäftsabsichten der Lizenznehmer.

Es empfiehlt sich daher, SPF einzusetzen und zu warten,wie sich die Streitigkeiten entwickeln. Beide Verfahren sind ohnehin im Draft-Status, wobei SPF dank der breiten Akzeptanz es wohl als Erstes zur Standardreife bringt. Wer sich über Sender-ID informieren möchte, findet Details unter www.microsoft.com/mscorp/safety/technologies/senderid/default .mspx. Der Draft ist unter www.ietf.org/internet- drafts/draft-lyon-senderid-pra-01 und /draft-lyon-senderid-core-01« zu finden.

Der Dritte im Bunde

Yahoo hat seine Idee mit einem verwandten Verfahren von Cisco zu DKIM vereint. Beide haben diesen Ansatz in der Mitte des vergangenen Jahres vorgestellt. Es wird inzwischen von mehr als einem Dutzend Firmen unterstützt.Der DKIMAnsatz signiert ausgehende Mails mit einem privaten Schlüssel.Empfänger-Server prüfen,ob der Schlüssel in der Nachricht tatsächlich aus der bekannten Quelle stammt. Dazu nutzen sie eine Kombination aus DNS und Public-Keys.Auf diese Weise kann das Verfahren auch die Integrität der Nachricht bewerten, was die anderen zwei nicht beherrschen. DKIM ist aber auch noch nicht standardisiert. Wer es einsetzen möchte,muss seine Mail-Infrastruktur dagegen stärker anpassen als bei den anderen Verfahren. Da ausgehende Nachrichten digital signiert werden, muss der lokale Server diese Aufgabe übernehmen. Wer DKIM-Parameter in externen Mails auslesen möchte, ist darauf angewiesen, dass die Gegenseite sie bereits beherrscht. Viele MTAs unterstützen es zum Glück bereits. Unter dem Strich muss der Administrator aber seine Mail-Server-Software aufrüsten, um DKIM zu verwenden.

Damit der Server Mails signiert,muss ihm ein Public-Private-Schlüsselpaar zugewiesen werden. Der Public-Key ist als TXT-Resource einzutragen, wobei Letztere an die Policy des Subdomain- Domainkeys gebunden sein muss. Yahoo verwendet selbst eine Policy mit dem Namen »s1024«, um ihre Nachrichten zu signieren. Der Public-Key ist folglich unter »s1024._domainkey- yahoomail.com« zu finden. Der private Schlüssel dagegen wird in die DKIM-fähige Mail- Software eingespielt und an die Policy gekoppelt. Versendet ein User eine Nachricht über den DKIM-Outbound-Server, so signiert der Server die Nachricht mit dem Schlüssel und Teilen des Headers sowie des Body-Texts. Die digitale Signatur wird wie die Informationen zum Headerund Verschlüsselungsalgorithmus als Header in die Mail eingepackt.

Erreicht diese Nachricht einen DKIM-fähigen Empfänger, so wird er den Header dazu nutzen, ihre Authentizität zu bewerten. Dank der Information in der Domainkey-Signatur kann der Server den Public-Key per DNS abrufen. Im Yahoo-Fall würde er den Schlüssel per DNS unter »s1024._domainkey-yahoo.com« finden. Mit diesem Schlüssel, den korrekten Algorithmen und dem Header der Nachricht ist er nun in der Lage, die richtige digitale Signatur zu generieren und diese mit dem Pendant in der Mail abzugleichen. Ist die Signatur gültig, leitet der Server die Nachricht an den Empfänger weiter. Falls nicht, sind alle typischen Gegenmaßnahmen bis hin zur Quarantäne möglich.

Der größte Nachteil des Verfahrens: Es muss sowohl in- als auch outbound unterstützt werden. Zudem steigert DKIM die Last auf den Mail- Servern, da sie mehr DNS-Lookups durchführen und einen Teil ihrer CPU-Kraft für Signieraufgaben aufwenden müssen.Wer mehr über das Verfahren erfahren möchte, findet Details unter »antispam.yahoo.com/domainkeys«. Die IETF-Drafts sind unter www.ietf.org.internetdrafts/draft-allman-dkim-ssp-01.txt und /draftdelany- domainkeys-base-03.txt« abgelegt.

pm@networkcomputing.de