Was ist eine Mailadresse, und was nicht?

Eine Anwendung, die mit potenziell misstrauenswürdigen externen Stellen (so zum Beispiel mit Anwendern) kommuniziert, ist gut beraten, die von draußen hineinkommenden Daten auf Plausibilität zu prüfen. Ohne korrekt ausgeführtes Input Sanitizing ist man anfällig gegen Codeeinschleusung und andere böse Dinge.

Weniger schön ist es allerdings, wenn der Code zum Input Sanitizing über sein Ziel hinausschießt, und gültige Eingaben deswegen abgelehnt werden. Besonders häufig erlebe ich dies in Eingabefeldern, die eine Mailadresse aufnehmen sollen.

Leider ist es außerordentlich schwer, in einem Programm festzustellen, ob eine Mailadresse gültig ist oder nicht. Hier zur Auffrischung des sicher vorhandenen Grundlagenwissens die aus RFC2822 entnommene Definition der Syntax einer Mailadresse:

addr-spec       =       local-part “@” domain
local-part      =       dot-atom / quoted-string / obs-local-part
domain          =       dot-atom / domain-literal / obs-domain
dot-atom        =       [CFWS] dot-atom-text [CFWS]
dot-atom-text   =       1*atext *(“.” 1*atext)
atext           =       ALPHA / DIGIT / ; Any character except controls,
                        “!” / “#” /     ;  SP, and specials.
                        “$” / “%” /     ;  Used for atoms
                        “&” / “’” /
                        “*” / “+” /
                        “-” / “/” /
                        “=” / “?” /
                        “^” / “_” /
                        “” / “{” /
                        “|” / “}” /
                        “~”

Besonders interessant ist die Definition von “atext”, steht da doch drin, welche Zeichen in Mailadressen gültig sind. Das sind deutlich mehr, als man üblicherweise in Eingabedaten einer Webanwendung haben möchte.

So kommt es dazu, dass viele Webanwendungen zwar Mailadressen nach dem 0815-Muster vorname.nachname@domain.example akzeptieren, aber schon bei so “ungewöhnlichen” Dingen wie mh+blog-zugschlus-de@zugschlus.de oder mh---komischefirma@zugschlus.de die rote Karte “Bitte geben Sie eine gültige Mailadresse ein” zeigen.

Wie oben schön erwähnt: Dollarzeichen, Anführungszeichen jeder Art, Ausrufungszeichen, Sterne, Tilden, Doppelkreuz und Schrägstrich will man eigentlich nicht in einer Webanwendung von außen annehmen, denn man kann streng genommen nie wissen, wie schlecht die Scripts, die außerhalb der eigenen Anwendung zum Einsatz kommen, gemacht sind. Sprich: Selbst wenn man selbst alle Eventualitäten abdeckt, weiß man nie, ob man nicht weiter “hinten” im System trotzdem Ärger zulässt.

Aber: Pluszeichen werden in Mailadressen seit 20 Jahren als Zustellhinweis verwendet. Bei einer Mailadresse im Format name+suffix@domain.example wird die Mail zugestellt, als wäre sie an name@domain.example adressiert. Der Teil zwischen dem Pluszeichen und dem Klammeraffen steht aber lokalen Filtern zur Verfügung. Ich verwende dies, um eingehende Mail gleich vorzusortieren. Andere Leute nutzen diese Eigenschaft als Spamfilter, denn viele Spammer schneiden die Adresse am Pluszeichen ab und versuchen, ihren Spam an suffix@domain.example abzusenden. Existiert diese Mailadresse nicht, misslingt dies.

Leider nehmen viele Webanwendungen keine geplussten Mailadressen an, weil sie das Pluszeichen für ungültig halten. Noch schlimmer ist es, wenn das vermeintlich ungültige Zeichen stillschweigend in ein anderes Zeichen - zum Beispiel ein zu einer wirklich ungültigen Mailadresse führendes Leerzeichen - umgesetzt wird.

Da solche Webanwendungen eine erschreckend hohe Verbreitung haben, habe ich mein Mailsystem so umgebaut, dass ich die Zeichenkette “---” wie ein Pluszeichen verwenden kann. So wird bei mir name---suffix@domain.example genauso wie name+suffix@domain.example behandelt. Ich bin sehr erstaunt darüber, dass es auch Webanwendungen gibt, die “---” in Mailadressen nicht sehen wollen. Dafür gibt es nun wirklich überhaupt keine technische Grundlage mehr.

So, nun zur eigentlichen Frage: Wie unterscheidet man eine gültige Mailadresse von einer ungültigen. Leider ist dieses Problem schon in der ersten Stufe, der syntaktischen Prüfung, kaum lösbar. Will man wirklich eine syntaktische Prüfung machen, kann man sich im Perl Cookbook angucken, wie Tom Christiansen sich - erfolglos - daran versucht. Die einzige IMO gangbare Möglichkeit ist zu prüfen, ob ein Klammeraffe existiert und ob vor und hinter dem Klammeraffen nur “gültige” Zeichen auftauchen. Von sauberer Programmierung entbindet das freilich nicht, denn man muss auch “böse” Zeichen wie die oben aufgelisteten durchlassen.

Das wirklich interessante, die semantische Prüfung, kriegt man auch nicht ordentlich hin. Man kann zwar gucken, ob die angegebene Domain existiert und laut DNS am Mailverkehr teilnimmt. Man kann auch prüfen, ob ein Mailserver auf den angegebenen IP-Adressen läuft. Zuletzt kann man auch versuchen, eine Mail an die passende Mailadresse zu senden. Das hat allerdings den Nachteil, dass sie bei einem wirklich existierenden Empfänger auch wirklich ankommt. Das will man eventuell nicht. Außerdem gibt es Mailserver, die auch Mails für nicht existierende Adressen annehmen und dann - eine beliebige Zeitspanne später - einen Bounce ausstellen. Somit muss die Antwort auf den Wunsch, eine Mailadresse auf semantische Korrektheit zu prüfen, spontan “Vergiss es” lauten.

Die einzige wirklich sichere Verifikation einer Mailadresse ist, eine Mail hinzusenden, und den Menschen hinter der Adresse zu bitten, den Empfang der Testmail - zum Beispiel durch Klick auf einen enthaltenen Link oder Antwort auf die Testmail - zu bestätigen. Dieses als Confirmed Opt-In bekannte Verfahren ist aber für viele Anwendungen totaler Overkill.

Da ich selbst in meinem E-Mail-Verkehr massiv auf geplusste Mailadressen setze, habe ich in meinem Wiki eine Hall of Shame angelegt, in der ich die Betreiber nicht konformer Webanwendungen wohlwollend erwähne. Und ja, dort findet man durchaus auch die “großen” der Branche.

Fazit: Die Erkennung korrekter Mailadressen ist nichttrivial, aber machbar. Es gibt genau keinen Grund, gültige Mailadressen wie name+suffix@domain.example oder name---suffix@domain.example abzulehnen. Wenn man damit anfängt, kann man auch gleich Mailadressen mit mehr als drei Zeichen in der Top Level Domain oder einem Punkt im Local Part ablehnen. Ich kann - ganz persönlich - den Kollegen Webentwicklern nur zurufen: Leute, macht Eure Hausaufgaben und lernt die technischen Grundlagen Eures Kerngeschäfts.