Neuer Anlauf der IETF gegen Spam
Cisco und Yahoo haben zusammen mit Sendmail und einigen Größen der IT-Branche einen Anti-Spam-Vorschlag bei den Internet-Standardisierern eingereicht; auch mit anderen Ideen nimmt die IETF die Diskussion um Anti-Spam-Standards wieder auf.
In der Internet Engineering Task Force (IETF) wird ein neuer Anlauf gestartet, etwas gegen das Problem mit den unerwünschten Werbe-Mails zu tun. Beim IETF-Treffen in Paris stellte Eric Allman, Chief Technology Officer bei Sendmail, das Konzept für DomainKeys Identified Mail (DKIM) vor, für das ein Internet-Draft Anfang Juli eingereicht wurde. DKIM beruht auf einer Kombination des DomainKeys-Vorschlag von Yahoo und des von Cisco vorgelegten Internet Identified Messages.
Cisco und Yahoo hatten bereits Anfang Juni angekündigt, ihre Vorschläge zu einem gemeinsamen Draft zusammenlegen zu wollen. Neben Cisco und Yahoo sowie Sendmail sind inzwischen noch weitere, teilweise große Partner mit aufgesprungen, darunter EarthLink, IBM, Microsoft, PGP Corporation, Strongmail, Tumbleweed,VeriSign und AOL. Damit sind auch die Initiatoren, beziehungsweise Kosponsoren von SenderID/SPF (Microsoft und AOL) mit von der Partie, das wegen patentrechtlicher Ansprüche von Microsoft vor der IETF und wegen zu großer politischen Auseinandersetzungen in der IETF nicht weiterverfolgt wurde. Im Falle von DKIM steht eine endgültige Erklärung zu möglichen Patentansprüchen von Seiten Yahoos noch aus, Allman rechnet mit einer akzeptablen Lösung: "Sollten etwa Lizenzgebühren geltend gemacht werden, würden wir uns zurückziehen." Er stellte in Paris das technische Dokument, Unterlagen zur Signaturpolitik der Sender und eine vorläufige Analyse zum Bedrohungsszenario vor.
Kern des Vorschlags ist die Signierung der Nachricht und ausgewählter Felder im Mailheader. Im Vergleich zu anderen kryptographischen Verschlüsselungsverfahren soll DKIM es dem Nutzer besonders einfach machen: Signieren muss nicht der "naive Nutzer" selbst, das übernimmt vielmehr sein E-Mail-Provider, der für die von ihm verantwortete Zone signiert. "In meinem Fall wird also sendmail.com signieren, ich signiere nicht selbst für meine persönliche Adresse", erklärte Allman. Das reiche auch dann aus, wenn innerhalb einer Domain E-Mail-Adressen missbraucht würden. "Denn die kann der Administrator dann finden."
Die Hinterlegung der öffentlichen Schlüssel erfolgt -- wie bei SPF oder Sender ID -- im Domain Name System, und zwar in einer Subdomain. Dafür soll ein neuer textbasierter Ressource Record geschaffen werden, erklärte Allman. Im Vergleich zu SenderID und SPF werde aber eben nicht nur der letzte Hop durch den Abgleich von IP-Adresse und Domain abgesichert, sondern die gesamte Nachricht. Eine Veränderung der Nachricht auf dem Weg zum Adressaten macht den Schlüssel ungültig, zumindest dann, wenn nicht mit Rücksicht auf Mailinglisten eine variable Länge zugelassen wird. Genau hier gibt es allerdings auch ein Problem mit DKIM: Mailinglisten, über die etwa Unsubscribe-Informationen an die eigentliche Nachricht angehängt werden, zerstören die Authentifikation. Wird andererseits auf die Integration der Länge verzichtet, könnte ein Angreifer einer Mail weitere Information anfügen. Besser schneidet DKIM im Vergleich zu SPF/SenderID beim Mailforwarding ab, bei dem die Mail einfach noch einmal neu signiert wird.
Laut Allman liegen die Hauptvorteile des neuen Vorschlags vor allem darin, dass der Ansatz für den Nutzer komplett transparent ist, keine Anpassungen in den Clients der Nutzer notwendig sind und für die Signierung auf eine dritte, vertrauenswürdige Instanz verzichtet werden kann. Erweiterungen in Richtung Signierung durch den Nutzer selbst sind für die Zukunft denkbar, auch wenn das DNS sich dann fürs Schlüsselmanagement nicht gut eignen würde -- damit könnte gar das DNS über Gebühr belastet werden. Die Effektivität von DKIM wiederum könnte weiter dadurch verbessert werden, dass für E-Mails von unbekannten, aber signierten Domains Reputationsdienste in Anspruch genommen werden. Zunächst soll aber eine möglichst rasch implementierbare Variante geschaffen werden.
Die Meinungen darüber, wie effektive DKIM tatsächlich gegen Spam sein wird, gehen allerdings erst einmal weit auseinander. Pete Resnick, Mitglied des Internet Architecture Board der IETF, sagte gegenüber heise online: "Der Vorschlag kann eine bestimmte Art von Spam erschweren, und zwar, wenn bestimmte Voraussetzungen gegeben sind." Zum Beispiel müssen, wie auch bei SPF und SenderID die Mailprovider mitspielen, damit das System funktioniert. Dann lässt sich nach Ansicht der Experten vor allem etwas gegen Spoofing erreichen. Spammer, die zum Beispiel über eigene, immer neue Domains spammen und sich dafür DNS-Einträge beschaffen, bleiben dagegen unbehelligt.
Eine Reihe von Kritikern forderte daher eine klarere Beschreibung der Sicherheitsprobleme, die DKIM eigentlich lösen will. Konkurrenz zu S-MIME oder anderen Protokollen sei keineswegs beabsichtigt, sagte Allman und verteidigte sich im Übrigen: "Wir haben niemals gesagt, dass das letzte Wort im Kampf gegen Spam sein wird." Vielmehr könne die Methode die Zahl der E-Mails, die es vor der Ablieferung in der Mailbox noch per Inhaltsfilter zu prüfen gilt, weiter einschränken. Es sei durchaus auch denkbar, SPF und DKIM gleichzeitig einzusetzen. Dann allerdings muss vor der Einlieferung der E-Mail gleich mehrfach eine DNS-Abfrage gestartet werden.
Dass das letzte Wort gegen Spam noch keineswegs gesprochen ist, zeigt auch ein brandneuer Anti-Spam-Vorschlag von einer Gruppe der Universität Karlsruhe, der auf der IETF in Paris zirkulierte. Michael Conrad, Hans-Joachim Hof und Roland Bless setzen bei SAVE (Spam Protection by Using Sender Address Verification Extension) ebenfalls auf eine Verifizierung des Absenders, und zwar mittels eines Challenge/Response-Verfahrens. Eine eigene E-Mail wird bei SAVE zunächst in eine Holdbox gepackt und mit einer automatisch generierten, im Vorschlag Puzzle genannten, zu lösenden Aufgabe beantwortet. Dabei kann es sich etwa um ein Bild mit einer Nummernkombination oder einem Hash-Wert handeln. Erst wenn der Sender das Puzzle gelöst hat, wird die E-Mail in die Inbox weitergeschickt; der Absender rückt automatisch auf die Whitelist des Empfängers. Das manuelle Lösen des Puzzles ermöglicht auch dem Nicht-Save-Nutzer, seine E-Mail zu senden, allerdings mit etwas Aufwand.
Laut dem Vorschlag der Autoren können die Puzzles auf allen Ebenen erzeugt werden, auch direkt beim User, sofern ein Provider SAVE nicht implementiert hat. Auf der anderen Seite ist bei Implementierung von SAVE beim Provider auch denkbar, das Puzzle automatisiert lösen zu lassen. Das würde laut den Autoren auch Webmail erleichtern. Gleich zu Beginn haben die Autoren dabei eines klargestellt: "Wir erheben nicht den Anspruch, dass wir die Spam-Lösung haben, aber der Vorschlag lässt sich Schritt für Schritt umsetzen, es könnte ein Start sein ..." (Monika Ermert) (jk)
