Zum Inhalt

Schlechte Idee: E-Mailadressen mit regex prüfen

Forbidden Mail AdressViele Internetseiten erfordern als Log-In die E-Mailadresse. Was passiert aber, wenn man seine elektronische Postadresse nicht in das Registrierungsfeld eingeben kann? Dann hat jemand wohl die RFC 2822 nicht gelesen. Denn viele Seiten lassen eigentlich erlaubte Sonderzeichen nicht zu.

Schuld daran könnte sein, dass diese Seiten die E-Mailadressen mit regex prüfen – das geht üblicherweise nicht gut. Reguläre Ausdrücke (kurz: regex) decken viele Anwendungsfälle ab – mit aber nur einem Ausdruck eine E-Mailadresse auf Konformität zu prüfen gehört aber meiner Meinung nicht dazu.

Beispiele für gültige Adressen

Plus-Adressen

Wie im Artikel Sichere E-Mailadressen für Facebook geschrieben, lassen sich Adressen von Google Mail mit einem Plus versehen. Das sind gültige Adressen nach RFC 2822.

  • user+example@gmail.com
  • my-address+extension@web.de
  • no-name-adress+suffix@gmx.de

Die letzten Beiden E-Mailadressen gehören aber nicht zum Konto my-adress@web.de oder no-name-adress@gmx.de. GMX und Web.de unterstützen diese Plus-Adressierung nicht. Ein anderer Anbieter, der diese Funktion unterstützt, ist etwa fastmail.fm.

Local Part in E-Mails

Der Teil vor dem @-Zeichen (Klammeraffe) kann nahezu vollständig beliebig gewählt werden. Es können sogar Zeichen verwendet werden, an die man zunächst gar nicht denkt – etwa das @-Zeichen selbst! Wichtig ist nur, wie man es einfügt.

Laut Wikipedia sind auch andere Zeichen gültig. Zu den erlaubten Zeichen in E-Mailadressen gehön etwa:

  • Ausrufezeichen (!)
  • Apostroph-Ersatzzeichen (‚)
  • Fragezeichen (?)
  • Gleichheitszeichen (=)
  • Geschweifte Klammern ({ })
  • Zirkumflex (^)
  • Dollar-Währungssymbol ($)
  • Sternchen (*)
  • Prozent (%)
  • Kaufmanns-Und/Ampersand (&)
  • Maskierte Leerzeichen (\ oder “ „)
  • Maskierte Anführungszeichen (\“)
  • Maskierter Klammeraffe/At-Zeichen (\@ oder „@“)
  • Maskiertes Komma (\, oder „,“)

Ein regulärer Ausdruck müsste also den Local Part vom Rest trennen und separat prüfen – das ist außerordentlich schwierig. Hinzu kommt noch, dass Kommentare in Klammern erlaubt sind, in denen wiederum weitere Zeichen verwendet werden dürfen. Der reguläre Ausdruck bläht sich hiermit noch weiter auf. Kommen noch maskierte Zeichen hinzu, etwa durch den Backslash oder durch Anführungszeichen, so ist der Reguläre Ausdruck alleine für den Local Part fast unmöglich zu erzeugen.

Reguläre Ausdrücke

Schlechte, übliche Versuche

Ein sehr schlechter regulärer Ausdruck zum Prüfen einer E-Mailadresse wäre etwa folgender (bitte nicht nutzen!):

Warum ist dieser Ausdruck schlecht? Ganz einfach: Er lässt keine Plus-Zeichen zu, aber auch viele andere eigentlich erlaubte Zeichen nicht – siehe oben. Außerdem erlaubt sie ungültige Domainnamen, wie etwa example..com (man beachte die beiden Punkte).

Variante von DevShed

Eine weitere Variante in PHP sieht vielleicht so aus (Quelle: http://www.devshed.com/c/a/PHP/Email-Address-Verification-with-PHP/2):

Auch diese Variante begeht größere Fehler:

  1. Es werden abermals erlaubte Zeichen nicht zugelassen, etwa das Prozent (%).
  2. Die Unterteilung in User und Mail ist zwar an sich nicht dumm, aber die Routine scheitert an einem maskierten (und erlaubten!) \@ im Usernamen.
  3. Die DNS-Prüfung klingt zunächst sinnvoll – aber eine gültige Absender-Domain muss nicht zwingend ihren MX-Record veröffentlichen.

Interessanterweise erhielt diese Variante trotzdem viele 4-Sterne-Bewertungen. Es soll also kein Affront gegen den Autor dieses Codes sein. Trotzdem auch diese Variante bitte nicht nutzen.

Beispiele für schlechte E-Mail-Prüfungen

Viele Webseiten verwenden solche falschen Validatoren. Ein paar Beispiele möchte ich hier auflisten. Dabei soll das kein Angriff auf die Seitenbetreiber sein – ich möchte lediglich darstellen, dass diese Seiten nicht alle theoretisch gültigen Adressen annehmen.

GMail

Bei Google’s E-Maildienst GMail lassen sich E-Mails nicht an alle gültigen Adressen verschicken, wie auf dem Bildschirmfoto zu sehen ist. Dabei fallen etwa Kommentare, Anführungszeichen und maskierte Klammeraffen (@) unter den Tisch. Gültig ist aber eine Mail à la user+word%tag@gmail.com.

Facebook

Facebook unterstützt die Angabe von Plus-Zeichen, so dass man etwa bei Google Mail ein eigenes Schlagwort reservieren kann (user+facebook@gmail.com). Bei Prozentzeichen macht Facebook aber nicht mit und lehnt diese als ungültig ab.

Piwik

Auch bei der Open-Source-Self-Hosting-Webanalyselösung Piwik ist nicht alles machbar. Ähnlich wie bei Facebook und Google sind zwar +-Zeichen erlaubt, aber auch hier verschluckt sich der Filter am Prozent-Zeichen (%).

Deutsche Post E-Filiale

Man könnte und sollte meinen, ein Unternehmen, welche schon Deutsch Post heißt, kennt sich auch damit besonders gut aus. Leider ist genau das Gegenteil der Fall. Die Deutsche Post schneidet schlechter ab, als viele anderen Dienstleister. Hier wird sogar das Plus-Zeichen verboten, so dass ein einfaches Setzen von Filtern in z.B. GMail nicht möglich ist.

Am 8. Februar 2013 habe ich die Post per Mail darauf aufmerksam gemacht, dass die E-Mailprüfung gültige E-Mailadressen ausschließe. Leider erhielt ich als Antwort ein schwaches „wir kümmern uns“. Seitdem habe ich nichts mehr seitens der Post gehört. Ein echtes Ärgernis!

Courier & Sendmail

Interessanterweise konnte ich das Senden per Terminal nur schwerlich testen. Für die Mailweiterleitung per .courier-Dateien habe ich entsprechende Weiterleitungen angelegt. Zurück kam immer ein Fehler bei Senden. Ob Courier also RFC 2822-Konform ist, kann ich durch meinen Test nicht sagen. Aber das Tool „mail“ in seinen zahlreichen Variationen (z.B. GNU mailutils) ist es sicherlich nicht.

Beispiele für bessere Mail-Prüfungen

WordPress.org

Wer ein selbstinstalliertes (selbstgehostetes) WordPress-System nutzt, darf sich freuen: Jeder Benutzer kann hier E-Mailadressen mit z.B. Prozentzeichen und Plus hinterlegen. Allerdings werden auch hier eigentlich erlaubte Adressen, wie „Benutzer mit Leerzeichen“@gmail.com nicht zugelassen.

Gallerie

Wann ist eine E-Mail gültig?

Anforderungen aus RFC 2822

Folgende Anforderungen ergeben sich aus der RFC 2822:

  1. Eine E-Mailadresse besteht aus dem Local Part und der Domain, durch ein @-Zeichen separiert (RFC 2822 3.4.1).
  2. Der Local Part besteht aus Buchstaben, Zahlen und den oben angegebenen Zeichen, mit Punkten (.) als Trennzeichen, aber ohne Punkt am Anfang, am Ende, oder zwei nebeneinander (RFC 2822 3.2.4).
  3. Der Local Part  darf darf aus einem Text in Anführungszeichen bestehen. Das bedeutet, alle möglichen Zeichen – auch Leerzeichen – dürfen in doppelten Anführungszeichen („) eingeschlossen werden (RFC 2822 3.2.5).
  4. Maskierte Paare (etwa \@) sind gültige Komponenten des Local Parts einer E-Mailadresse. Sie sind als Altlast aus RFC 822 mit aufgenommen worden (RFC 2822 4.4).
  5. Der Local Part darf 64 Zeichen nicht überschreiten (RFC 2821 4.5.3.1).
  6. Eine Domain besteht aus Bezeichnern, die über Punkte getrennt werden (RFC 1035 2.3.1).
  7. Domainbeezeichner fangen mit einem alphanumerischen Zeichen an, gefolgt von null oder oder mehr alphabetischen, numerischen Zeichen, oder dem Bindestrich (-). Sie enden alphanumerisch (RFC 1035 2.3.1).
  8. Ein einziges Label innerhalb der Domain darf 63 Zeichen nicht überschreiten (RFC 1035 2.3.1).
  9. Die gesamtlänge der Domain darf 255 Zeichen nicht überschreiben (RFC 2821 4.5.3.1).
  10. Die Domain muss vollqualifiziert sein, und auf einen DNS-Ressource Record des Typs A oder MX auflösbar sein (RFC 2821 3.6).

Ein besserer E-Mail-Validator

Aus den oben genannten 10 Punkten lässt sich ein besserer E-Mailvalidator basteln. Eine erste Version kommt vom Linux-Journal, 2007. Aus dem bereitgestellten Code habe ich Funktionen extrahiert, sie auf Basis der dortigen Kommentare erweitert und als eine Klasse neu zusammengestellt.

Die Prüfung über DNS-Einträge berücksichtigt nun auch IPv6, und die Domain wird erst auf prinzipielle Gültigkeit geprüft, bevor ein DNS-Check erfolgt. Das spart sehr viele Ressourcen.

Download beider Dateien (Klasse mit statischer Methode und Testcase): mailcheck.tar.

Hier nocheinmal der Quellcode ausgeschrieben:

Mailcheck.php

mailchecktest.php

Alternativen

Die Prüfung kann auch in JavaScript erfolgen, etwa mittels des oben erwähnten mailcheck.js. Allerdings hat auch dieses Fehler, wie bereits beobachtet, und verwirft eigentlich gültige RFC 2822-Adressen.

Die meisten »scheinbaren« Alternativen (siehe Codebeispiele weiter oben) sind aber sehr schlecht – und lassen trotzdem ungültige Mailadressen durch. Das ist ein noch viel größeres Ärgernis!

Aussicht und Fazit

Die Frage ist, ob man als Seitenbetreiber überhaupt alle gültigen Adressen zulassen möchte. Ein User sollte wenigstens ein Plus und ein Prozentzeichen eingeben können – daher meine Tests in der Galerie. Aber ob man maskierte @-Zeichen und Anführungszeichen, Kommentare etc. wirklich braucht ist fraglich. Immerhin kann man diese nicht einmal per Google Mail oder bei anderen Anbietern empfangen.

Gerade die Pluszeichen sind bei GMail äußerst praktisch. Daher weise ich einige Dienste ab und zu auf deren „Fehler“ hin. Aber meistens ist es für die Katz, den Anbietern ist es egal.

Published inBasiswissenHow Tos

Schreibe den ersten Kommentar

    Schreibe einen Kommentar

    Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.