Das Standardisierungsvorhaben bei der IETF nimmt Vorschläge aus mehreren Quellen auf. Dazu zählen Microsofts "Caller ID", das "Sender Policy Framework" (SPF) der Firma pobox.com und die SMTP Submitter Extension von Sendmail. Allen ist gemeinsam, dass sie ein Defizit des etablierten Mail-Transportsystems beheben wollen. Das Simple Mail Transfer Protocol (SMTP) gilt nämlich als vertrauendes Protokoll, das grundsätzlich von der Korrektheit der Absenderinformationen ausgeht.
Diese Tatsache öffnet sämtlichen Formen des Missbrauchs Tür und Tor, allen voran dem Diebstahl vertraulicher Informationen ("Phishing") und dem Versand von Spam. Phishing-Angriffe werden dadurch erleichtert, dass Mail-Empfänger eher bereit sind, private Daten weiterzugeben, wenn beispielsweise die gefälschte Absenderadresse auf die Domäne eines Finanzinstituts lautet. Spam-Versender erhoffen sich hingegen eine höhere Antwortquote, wenn ihre Junk-Mail vermeintlich aus der Domäne eines bekannten Unternehmens stammt.
Der in Arbeit befindliche IETF-Standard unter der Bezeichnung SenderID soll verhindern, dass zwielichtige Elemente die Absenderdaten von Mails fälschen, insbesondere die Ursprungsdomäne ("Address Domain Spoofing"). Unternehmen könnten in Zukunft darauf vertrauen, dass im Namen ihrer Internet-Domäne kein Spam versandt wird.
Berechtigung von Mail-Servern im DNS überprüfen
Um dieses Ziel zu erreichen, plant die IETF-Arbeitsgruppe, alle zum Versand berechtigten Mail-Server einer Domäne in das DNS einzutragen ("SPF Record"). Dort findet sich heute nur eine Liste von Adressen, die eingehende Mails entgegennehmen sollen ("MX Record"). Microsoft bietet bereits einen Online-Wizard (http://www.anti-spamtools.org/) an, mit dessen Hilfe man die korrekten Informationen für den DNS-Server erzeugen kann. Jeder Mail Transfer Agent (MTA) sollte anhand dieser Einträge vor der Weitergabe einer Mail überprüfen, ob sie von einem berechtigten Server stammt. Dafür extrahiert er den Domänennamen aus einem Feld des Message-Headers (Resent-Sender, Resent-From, Sender, From).
Um unzulässige Nachrichten noch vor der Weiterleitung blockieren zu können, sieht eine Erweiterung von SMTP vor, die Ursprungsdomäne in einem neuen Feld des Protokolls ("SUBMITTER") einzutragen.
Aufgrund der geplanten Verifi-zierungsfunktionen erfordert SenderID, dass bestehende Mail-Systeme modifiziert werden. So müssen MTAs zukünftig in der Lage sein, den SPF-Eintrag aus dem Domain Name Service (DNS) zu lesen. Außerdem erfordert der geplante Standard, dass diese Systeme die Ursprungsdomäne aus dem Kopf der Nachricht extrahieren. Zur Umsetzung der optionalen SUBMITTER-Erweiterung bedarf es einer Veränderung der SMTP-Implementierung.
Dämpfer für allzu übertriebene Erwartungen
Die Arbeitsgruppe dämpft die in Zusammenhang mit SenderID geschürten Erwartungen, wonach diese Technologie das Spam-Problem in den Griff bekommen könnte. Sie verhindert nur, dass Junk-Mail im Namen einer falschen Domäne in Umlauf gebracht wird.
Spammer können natürlich auch weiterhin ihre eigenen Domänen registrieren und von dort aus ihr Unwesen treiben. Diese Einschränkung gilt auch für einen alternativen Vorschlag von Yahoo, der vorsieht, den öffentlichen Schlüssel für eine Domäne im DNS zu hinterlegen. Jede Mail müsste dann mit dem privaten Schlüssel des Absenders signiert werden, so dass deren Authentizität überprüft werden könnte. Dieses Verfahren würde es zudem erlauben, Veränderungen am Inhalt einer Nachricht zu entdecken. (ws)
Abb: Der Weg zum SenderID-Standard
Hausaufgaben für Hersteller, ISPs und Anwender, wenn sie in ihren Mail-Systemen den in zwei Phasen geplanten Standard umsetzen wollen. Quelle: Microsoft