E-Mail-Adressen bestanden jahrzehntelang aus einem eng begrenzten Zeichenvorrat: lateinische Buchstaben, Ziffern, eine Handvoll Satzzeichen. Wer keinen lateinischen Namen schreibt, musste ihn umschreiben — für einen großen Teil der Welt eine tägliche kleine Zumutung. Zwei Erweiterungen haben das behoben, und beide bringen ein Sicherheitsproblem mit, das die meisten Mailprogramme bis heute nicht lösen.
Zwei Erweiterungen, nicht eine
Eine Adresse hat zwei Teile, und sie wurden getrennt internationalisiert.
Der Domainteil hinter dem @ darf seit den frühen 2000er Jahren Zeichen jenseits des lateinischen Alphabets tragen. Technisch geschieht das über eine Umschrift: müller.de wird intern zu xn--mller-kva.de. Diese Umschrift heißt Punycode, ist eindeutig umkehrbar, und das DNS sieht davon nur die ASCII-Fassung. Deshalb funktionieren solche Domains überall.
Der lokale Teil vor dem @ ist die jüngere und schwierigere Erweiterung. Für ihn gibt es keine Umschrift — hier stehen echte UTF-8-Zeichen in der Nachricht. Damit das funktioniert, muss jeder beteiligte Server die SMTP-Erweiterung SMTPUTF8 beherrschen. Fehlt sie an einer einzigen Stelle der Kette, wird die Nachricht abgewiesen.
Der Unterschied ist praktisch bedeutsam: Eine Adresse wie info@müller.de ist unbedenklich. Eine Adresse wie müller@firma.de ist es nicht — sie kann unterwegs an einem Server scheitern, den man weder kennt noch beeinflussen kann.
Der Punkt, an dem es unangenehm wird
Verschiedene Schriftsysteme enthalten Zeichen, die gleich aussehen und verschieden sind. Das kyrillische а (U+0430) und das lateinische a (U+0061) werden in nahezu jeder Schriftart identisch dargestellt. Dasselbe gilt für е und e, о und o, р und p, с und c.
Warum Browser das besser gelöst haben
In der Adresszeile eines Browsers ist dieser Angriff weitgehend erledigt, und zwar durch eine Regel, die auf den ersten Blick grob wirkt: Enthält ein Domainname Zeichen aus mehreren Schriftsystemen, oder passt das Schriftsystem nicht zur eingestellten Sprache, zeigt der Browser die Punycode-Fassung an. Aus einer täuschend echten Domain wird dann sichtbar xn--….
Mailprogramme tun das überwiegend nicht. Sie zeigen die Absenderadresse so an, wie sie geschrieben steht — oft sogar nur den Anzeigenamen, und die Adresse gar nicht. Der Schutz, den man aus dem Browser gewohnt ist, existiert hier schlicht nicht.
Wofür das ausgenutzt wird
- Absender, die aussehen wie ein Geschäftspartner. Kombiniert mit einem laufenden Vorgang und einer geänderten Bankverbindung ist das die klassische Rechnungsumleitung.
- Domains, die vollständig registriert und mit SPF, DKIM und DMARC ausgestattet sind. Wichtig zu verstehen: Diese Nachricht ist technisch korrekt authentifiziert. Sie kommt von der Domain, die sie behauptet — nur ist das eine andere Domain als die, die der Leser meint. Kein Prüfverfahren schlägt hier an, weil keines etwas zu beanstanden hat.
- Links im Nachrichtentext, die auf die Zwillingsdomain führen und dort eine echte Anmeldeseite nachbauen.
Der zweite Punkt ist der wichtigste und wird regelmäßig übersehen. Ein grüner Haken bei der Absenderprüfung sagt nichts darüber aus, ob die Domain die richtige ist. Er sagt nur, dass sie zu sich selbst passt.
Was hilft
Beim Lesen: Der Anzeigename ist wertlos, die Adresse ist es fast auch — entscheidend ist, wie sie sich auflöst. Wer bei einer Zahlungsaufforderung unsicher ist, kopiert die Adresse in ein Textfeld und sieht nach, ob alle Zeichen sind, wofür sie sich ausgeben. Praktikabler im Alltag ist die Regel, die ohnehin gilt: Eine geänderte Bankverbindung wird nicht per E-Mail bestätigt, sondern über eine Nummer, die man bereits hat. Weitere Merkmale, an denen sich solche Nachrichten erkennen lassen, stehen in einem eigenen Artikel.
Beim Bauen von Formularen: Selbstgeschriebene Prüfausdrücke für Adressen scheitern hier in beide Richtungen. Sie lassen entweder gültige internationale Adressen nicht durch — was echte Nutzer aussperrt — oder sie nehmen alles an. Die belastbare Prüfung ist ohnehin eine andere: eine Bestätigungsmail an die Adresse schicken. Wer nur die Zeichenkette prüft, prüft die falsche Sache.
Beim Betrieb einer Marke: Die naheliegende Abwehr — alle ähnlichen Domains selbst registrieren — funktioniert bei lateinischen Verwechslungen noch halbwegs und bei Unicode nicht mehr. Die Zahl der optisch identischen Schreibweisen ist zu groß, um sie zu kaufen. Was hilft, ist Überwachung: Es gibt öffentliche Verzeichnisse aller neu ausgestellten TLS-Zertifikate, und eine Domain, die den eigenen Namen nachahmt, taucht dort auf, sobald jemand sie in Betrieb nimmt.
Und die eigene Adresse?
Wenn Sie eine Domain mit Sonderzeichen betreiben, richten Sie die ASCII-Schreibweise als zweite Domain ein und leiten Sie weiter. Nicht wegen der Technik — die funktioniert — sondern wegen der Menschen, die die Adresse am Telefon durchgeben müssen.
Und beim lokalen Teil vor dem @: Solange Sie nicht wissen, dass alle Ihre Gegenstellen SMTPUTF8 beherrschen, ist eine Adresse aus lateinischen Zeichen die Wahl, die zuverlässig ankommt. Das ist keine Empfehlung, mit der man zufrieden sein müsste — es ist der Stand der Umsetzung.