Trendthema: Kinetic Email
3. März 2016Von Download-Hamstern und Flüchtermeisen
30. Mai 2016Kein Newsletter für René Fön
27 Mai 2016
Im Mail-Inhalt ermöglicht UTF8 schon lange das Anzeigen von Umlauten und Sonderzeichen. Doch wie sieht es in der Adresszeile aus? Unser Test ergab: In der Verarbeitung von Mailadressen bleiben Freemailer und E-Mail-Marketing-Plattformen konservativ.
René Fön macht sich an seine erste Aufgabe. Als neuer (fiktiver) Mitarbeiter erhielt er am ersten Arbeitstag nicht nur ein Schlüsselband für den Büroschlüssel, sondern auch eine Mailadresse: réne.fön@publicare.de. Rundum ausgestattet soll er nun testen, ob eine B2C Mailing-Kampagne auch auf Freemailern korrekt dargestellt wird. „Als erstes legst Du Dir bei den gängigen Freemail-Anbietern einen Account an“, steht in der Mail seiner Teamleiterin.
Kaum hat der junge Mitarbeiter mit dem Anmelden begonnen, treibt es ihm kalten Schweiß auf die Stirn. Egal wie oft René seine Wunschadresse „rené.fön“ eingibt, GMX und Web.de verwandeln sie jedes Mal in „rene.foen“.
Auch abgewandelte Varianten des Namens René Fön werden nicht akzeptiert: Keiner der Freemail-Provider von T-Online über Gmail bis zu Mail.de erlaubt „rene.fön“, „rené.fon“ oder „rené.fön“ als Teil der E-Mail-Adresse. René bleibt nichts anderes übrig, als sich bei den kostenlosen Anbietern mit einem Usernamen ohne Sonderzeichen zu registrieren.
Nur 7-Bit-ASCII im Local-Part
Ein einzelner Name oder eine Kombination aus Name und Vorname mit einem Punkt oder Bindestrich in der Mitte ist landläufig als Username bekannt. Aus Sicht der IETF handelt es sich um den „Local Part“, dessen Handling im RFC 6531 und im RFC 5321 festgelegt ist.
Sind UTF8-kodierte Sonderzeichen im Local-Part tatsächlich nicht erlaubt? Der 2012 veröffentlichte RFC 6531 gibt sich hier schwammig. Prinzipiell sind Non-ASCII-Characters, also deutsche und alle anderen Sonderzeichen, im kompletten Mailheader erlaubt. Aktuell bleibt jedoch das Parsen des Local-Parts unverändert.
„Although the characters in the are permitted to contain non-ASCII characters, the actual parsing of the and the delimiters used are unchanged from the base email specification [RFC5321]. Any domain name to be looked up in the DNS MUST conform to and be processed as specified for Internationalizing Domain Names in Applications (IDNA) [RFC5890].“
Im Abschnitt 4.1.3 des RFC 5321 wird erklärt, dass Non-ASCII-Characters in Mailbox-Namen und Mail-Kommandos eben nicht erlaubt sind. Das heißt: Prinzipiell ist UTF8 im Local-Part erlaubt, es ist jedoch jedem Mailsystem freigestellt, ob und wann es mehr als den im RFC 5321 definierten Zeichenumfang unterstützt.
Trotzdem ist mindestens ein Mailserver am Markt, der SMTPUTF8 in der kompletten Empfängeradresse parst: Postfix ab Version 3.0.0.
Newsletter-Abonnement mit Umlauten
Jetzt ist René neugierig und möchte wissen, ob es an den Freemail-Providern liegt, dass er keine Sonderzeichen im Username benutzen kann. Er weiß dass in Domainnamen Umlaute schon länger zulässig sind. Die erste deutsche Umlautdomain „Öko.de“ wurde immerhin 2004 registriert. Also legt er sich eine eigene Umlaut-E-Mail-Domain an und treibt seinen Test auf die Spitze, indem er auch im Domainteil der E-Mail-Adresse einen Umlaut verwendet. René legt sich die folgenden drei Adressen an:
- rené.fön@begrüßung.de
- rene.fon@begrüßung.de
- xn--ren-dma.xn--fn-fka@begrüßung.de
Mit diesen drei Adressen will sich René nun zu verschiedenen Newslettern anmelden, um herauszufinden, wie verschiedene große E-Mailmarketing-Dienstleister mit den Umlautadressen umgehen.
Kann er sich mit den Adressen bei den großen deutschen E-Mail-Dienstleistern als Abonnent registrieren? Und falls ja: werden E-Mails an diese Adressen auch zugestellt?
Wie aus den Ergebnissen im ersten Abschnitt ableitbar, hat die erste Mailadresse wenig Aussicht auf Erfolg. Variante 2 und 3 sollten jedoch angenommen und verarbeitet werden.
Bei Adressvariante 3 handelt es sich um Punycode. Das Kodierungsverfahren macht Unicode-Zeichenketten wieder kompatibel zu ASCII. Es wurde bereits 2003 für das Handling internationalisierter Domainnamen entworfen und sollte inzwischen allgemein bekannt sein.
Lediglich Agnitas und Inxmail akzeptierten René Föns Mailadresse. Die anderen lehnen alle drei Adressvarianten aufgrund „ungültiger Zeichen“ ab.
Punycode: Entwickler in der Pflicht
Dass selbst Punycode oft bei der Validierung durchfällt, lässt sich mit dem doppelten Bindestrich erklären. Zentrales Element von Punycode ist die Zeichenfolge xn--, die in realen Namen und Wörtern praktisch nicht vorkommt. Leider sind die beiden aufeinanderfolgenden Bindestriche so obskur, dass beispielsweise Web.de die Zeichenfolge nicht in Usernamen zulässt.
Gerade beim Aufbau umfangreicher Systeme verlassen sich Entwickler oft auf Utilities zur Validierung von Mailadressen. Diese Bibliotheken halten sich jedoch nicht lange mit Kompatibilitätsfragen auf. Die Mailadressen-Validierung der PHP-Funktion filter_var ist für ihre Rätselhaftigkeit sogar berüchtigt.
Anstatt Sonderzeichen und Punycode abzulehnen scheint es nachhaltiger, wenn die verarbeitenden Applikationen jede E-Mail-Adresse grundsätzlich als Punycode kodiert ablegen und dekodiert ausliefern.
Fazit: Bei Sonderzeichen auf Nummer sicher gehen
Bei René Fön währte die Freude über die gelungene Anmeldung bei den Newslettern von Agnitas und Inxmail nur bis zum nächsten Sendetermin des Newsletters. Denn obwohl seine E-Mail-Adressen den Anmeldeprozess ohne Fehlermeldung passierten, kam bei René Fön kein einziger Newsletter an.
Noch immer sind Browser, E-Mail-Clients und Mail-Server in Betrieb, die internationalisierten Mailadressen keine Beachtung schenken oder sie grundsätzlich ablehnen. E-Mail-Marketing-Dienstleister, die solch konservative Systeme einsetzen, minimieren Risiken, verzichten jedoch gleichzeitig auf Kunden aus dem In- und Ausland.
Letztendlich hat sich René Fön entschieden, nur noch ASCII-konforme Adressen zu verwenden, bis sich das Handling internationalisierter Mailadressen durchsetzt. Seine Adressen hat er jedoch nicht gelöscht, sondern Weiterleitungen eingerichtet. Wer weiß, vielleicht erhält er doch irgendwann noch einen der abonnierten Newsletter.