Anti-Spam-Kämpfer werden bescheiden

Neue Mail-Signaturen, die per DNS-Abfrage die Authentizität des Senders validieren helfen, sollen weiterentwickelt werden. Eine Mehrheit von Entwicklern votierte beim Herbstreffen der Internet Engineering Task Force (IETF) in Vancouver für die Einrichtung einer Arbeitsgruppe zum so genannten Domain Keys Identified Mail (DKIM). DKIM beruht auf einem gemeinsamen Vorschlag von Cisco, Sendmail und Yahoo. Das Interesse an DKIM sei groß, lobten die Befürworter und zitierten unter anderem einen Unterstützerbrief der Bank of America, die an der Absicherung der von ihr versandten E-Mails interessiert ist. Neben Cisco, Sendmail und Yahoo hätten auch weitere Firmen DKIM im Test. Ambitioniertes Ziel der DKIM-Entwickler: Bis zum September 2006 soll der Standard stehen, wenn die Internet Engineering Steering Group (IESG) der Gründung der Arbeitsgruppe zustimmt.

Bei DKIM werden die E-Mails vom sendenden Mail Transfer Agent (MTA) oder Mail User Agent (MUA) signiert, der zugehörige Schlüssel ist im DNS hinterlegt. Der Empfänger-MTA kann darüber die Signaturen prüfen. Vorteil des Verfahrens ist laut Eric Allman von Sendmail, dass es für Endnutzer kaum Veränderungen bedeutet, keine große Public-Key-Infrastruktur hinterlegt werden muss und auch keine Zertifizierungsstellen gebraucht werden. Insgesamt ist DKIM daher auch nicht teuer, meinte Allman. Im Unterschied zu Sender Policy Framework (SPF) werde aber nicht nur der Weg, sondern die ganze Nachricht validiert. Domain-Besitzer können dabei selbst entscheiden, welche Teile der Mail signiert werden – bis hin zur Signierung von Header und Text plus zusätzlicher Sicherungen über Hashwerte.

Heftig gestritten wurde beim IETF-Treffen allerdings über mögliche "unbeabsichtigte Nebenwirkungen". Sam Hartman, Bereichsdirektor Sicherheit in der IETF, warnte während der Sitzung: "DKIM kann die E-Mail-Architektur ändern, indem es die Signaturen obligatorisch macht beziehungsweise ohne sie einen schlechteren Service erhält." Hartman sagte, für eine solche Veränderung der E-Mail-Architektur bedürfe es aber einer Grundsatzentscheidung der IETF. Verschiedene Entwickler rieten vor allem, die Sender Signing Policy (SSP) nicht in den Standardisierungsprozess aufzunehmen. Allman hat dazu einen gesonderten RFC für die DKIM-Protokollfamilie entworfen.

Die SSP soll dem Empfänger eine Überprüfung der für die Domain geltenden Policy ermöglichen. Das sei vor allem deshalb notwendig, weil mindestens in der Übergangsphase Mails vieler Domains gar nicht signiert würden und ein Blick auf eine fehlende Policy dies kläre. Mittels SSP kann schließlich hinterlegt werden, ob zwingend jede von einer Domain versandte E-Mail signiert wird oder nicht. Außerdem wird bestimmt, ob Signaturen von Dritten (etwa bei über Mailinglisten versandten E-Mails) von der Domain zu akzeptieren sind. Solche Bestimmungen grenzen aus Sicht einzelner Teilnehmer an "Regulierung" oder "Gesetzgebung". Allmans Koautor Jim Fenton von Cisco sprach dagegen eher von einem "Rat" für die Anwender.

Mögliche Probleme von DKIM sollen innerhalb der DKIM-Arbeitsgruppe besprochen werden. Immerhin haben die DKIM-Autoren auf Kritik bereits reagiert und in einer Bedrohungsanalyse klargestellt, dass DKIM alleine Spammer, Phisher oder Spoofer nicht stoppen werde. Es sei vielmehr ein Baustein, der, klug eingesetzt, diesen das Leben schwerer machen werde. Mögliche Erweiterungen, die Empfängern auch Auskünfte über ihnen unbekannte Domains geben – so genannte Reputation-Services – sollen erst im zweiten Schritt entwickelt werden. Für Probleme mit Mailinglisten sind im neuen Basisentwurf weniger strenge Signaturregeln vorgesehen.

Einen zu geringen Effekt bei möglicherweise erheblichen Auswirkungen für das Mailsystem befürchten Kritiker aber trotz der gewachsenen Bescheidenheit der Anti-Spam-Entwickler. Beobachter wie der ehemalige IETF-Vorsitzende Harald Alvestrand warnten dagegen, die Barrieren für die Gründung einer Arbeitsgruppe zu hoch zu setzen. In diesem Fall würde sich die IETF von der Entwicklung selbst abschneiden. (Monika Ermert) / (jk)