Internationalisierte E-Mail-Adressen erschweren Spam-Bekämpfung

Signaturen nach DKIM, um das Spoofen von E-Mail-Adressen zu verhindern, werden durch das Zurückwandeln nicht-englischer E-Mail-Adressen in ASCII-kompatible Formate gebrochen.

In Pocket speichern vorlesen Druckansicht 46 Kommentare lesen
Lesezeit: 4 Min.
Von
  • Monika Ermert

Die Internationalisierung des Domain Name System (DNS) wurde lange gefordert, aber sie bringt auch ein paar Probleme mit sich. Das Zurückwandeln nicht-englischer E-Mail-Adressen in ASCII-kompatible Formate etwa bricht die so genannten DKIM-Signaturen (Domainkeys Identified Mail), die das Spoofen der E-Mail-Adressen verhindern sollen. Zwar ist die fast fertige Standardserie für die neuen nicht-englischen E-Mail-Header noch als experimentell angekündigt, trotzdem verständigten sich die Experten bei der Internet Engineering Task Force (IETF) bei ihrem Treffen in Chicago darauf, das Problem in den Standardtexten vorsichtshalber zu erwähnen.

DKIM ist von der IETF im RFC 4871 als Anti-Spam-Protokoll festgehalten. Die Technik identifiziert Sender nicht mehr anhand von IP-Adressen, sondern an Signaturen, die mit den Domain-Namen von Firmen und Organisationen verbunden sind und als neue Einträge im DNS (_domainkey Record) bereitgestellt werden. Die Nachrichten signiert das Mail-System beim Versand automatisch: Der Empfänger der E-Mail muss die Signatur nur noch mit der des Versenders vergleichen.

Um Nutzern aus der nicht-englischsprachigen Welt beziehungsweise Sprachgemeinschaften mit nicht-lateinischen Schriftsystemen, eigene E-Mail-Adressen zu verschaffen, werden bei der IETF sowohl SMTP also auch die aktuelle Form der Header erweitert und UTF8-fähig gemacht. Nach der Standardisierung internationalisierter Domains, die schon bald auch auf oberster Stufe in die DNS-Rootzone eingetragen werden sollen, können damit auch links des Klammeraffen (@) in Mailadressen kyrillische, chinesische oder arabische Namen erscheinen.

Die Möglichkeit zum Zurückwandeln (downgrading) der nicht-englischen E-Mail-Adressen betrachtet man bei der IETF allerdings als zwingend, da man nicht davon ausgehen kann, dass Mailserver überall in der Welt sofort die neuen Adressen unterstützen wird. Ein eigener RFC-Entwurf widmet sich allein den möglichen Downgrading-Mechanismen. Um die Zustellung zu garantieren, muss irgendwo auf dem Weg vom Sender zum Empfänger die Rückübersetzung gemacht werden, sei es beim Mail User Agent, beim Mail Transfer Agent, beim Message Submission Agent oder beim Mail Delivery Agent.

Ganz ohne Probleme wird es sicher nicht abgehen, wenn die E-Mail-Welt plötzlich nicht mehr rein english/lateinisch sein wird. Ein Problem kam beim Treffen in Chicago prominent zur Sprache – das Problem nicht mehr validierbarer Signaturen etwa beim DKIM-Protokoll. Das Zurückwandeln der internationalisierten Adressen sorgt dafür, dass Header und Adressen gegenüber den signierten Varianten verändert werden. Genau das sei übrigens der Grund, warum man etwa bei PGP oder auch bei S/MIME auf die Signatur des E-Mail-Headers verzichtet habe, sagt SMTP-Experte John Klensin.

Belassen die DKIM-Nutzer es erst einmal dabei, dass Signaturversagen schlicht als nicht vorhandene Signatur behandelt wird, kommen die Mailpartner noch glimpflich davon. "In der Praxis sehen wir aber, dass E-Mail verworfen wird, weil sie etwa keine geltenden SPF-Header hat", warnt Klensin. Eine ähnliche Praxis beim Einsatz von DKIM könnte also dazu führen, dass die nicht-englische Mail zwar die Hürde ins nicht-internationalisierte E-Mail-Umfeld schafft, aber am Ende doch nicht beim Empfänger ankommt. Generell erwartet man bei der IETF noch eine ganze Reihe von Anpassungsschwierigkeiten bei der Internationalisierung. Eine Vielzahl von Arbeitsgruppen im IETF-Arbeitsbereich Sicherheit habe sich in Chicago explizit mit dem Thema befasst, sagte Sam Hartmann, einer der beiden Chefs des Arbeitsbereichs. Mit dem Abschied vom reinen US-ASCII wird die DNS-Welt auf jeden Fall komplexer.

Einen Überblick über die Standards zur Internationalisierung der E-Mail-Adressen findet sich in RFC 4952. (Monika Ermert) / (jk)