E-Mail-Validierung: was ein Regex beweist und was nicht

Vier Fragen, die sich ein Wort teilen

„Ist das eine gültige E-Mail-Adresse?“ ist nicht eine Frage, sondern vier. Sie werden der Reihe nach schwerer, und nur die letzte ist die, die irgendjemand wirklich beantwortet haben wollte — weshalb so viel Validierungscode bei der ersten ausführlich ist und zu den übrigen schweigt.

Hier sind sie, in der Reihenfolge, in der ein Anmeldeformular ihnen begegnet.

Ist es wie eine Adresse geformt?

Eine Syntaxprüfung. Sie läuft im Browser, kostet nichts, und erwischt das getippte Komma und das fehlende @. Sie ist die einzige Schicht, die ehrlich etwas ganz allein ablehnen kann — und selbst dann sollte sie weit weniger ablehnen, als es die meisten Muster tun.

Könnte diese Domain überhaupt Mail annehmen?

Eine DNS-Prüfung. Eine einzige Abfrage sagt, ob irgendetwas, irgendwo, bereit ist, Mail für den Teil nach dem @ anzunehmen. Sie erwischt einen Domainnamen mit einem fehlenden Buchstaben und eine Domain, die letztes Jahr abgelaufen ist, und sie kann Ihnen rein gar nichts über das Postfach sagen.

Existiert dieses Postfach?

Eine SMTP-Prüfung — und diejenige, bei der diese Anleitung am längsten erklärt, warum Sie ihr nicht trauen sollten. Man kann fragen. Die Antwort ist oft ein höfliches Ja von einem Server, der jeden Namen akzeptiert, oder ein absichtlicher vorübergehender Fehlschlag, oder eine Annahme, der Minuten später ein Bounce folgt.

Ist es ihre Adresse?

Nichts auf der technischen Seite kann das beantworten. Eine Adresse kann fehlerfrei, zustellbar und trotzdem die eines anderen sein — um eine Ziffer vertippt, oder absichtlich eingetippt, um an Ihnen vorbeizukommen. Nur eine Nachricht, die ankommt und benutzt wird, klärt die Frage.

Die ersten drei sind billig und beweisen wenig. Die vierte ist die einzige, die den Namen verdient, und sie ist es, die eine Nachricht kostet. Im Folgenden geht es darum, die billigen drei gut einzusetzen, damit die teure nicht verschwendet wird.

Schicht eins: das Muster, und die vier Dinge, die es nicht wissen kann

Es gibt keinen offiziellen regulären Ausdruck für eine E-Mail-Adresse, und es kann auch keinen geben. RFC 5322 definiert eine Grammatik statt eines Musters, und diese Grammatik erlaubt Kommentare in Klammern, gefaltete Leerzeichen und in Anführungszeichen gesetzte Zeichenketten mit fast jedem Zeichen — nichts davon sollte ein echtes Anmeldeformular akzeptieren, und alles davon muss ein originalgetreues Muster tun.

Was es gibt, ist eine bewusst engere Definition, die Browser bereits umsetzen: die, die die HTML-Spezifikation für ein Feld <input type="email"> vorgibt. Sie ist ein gewollter Kompromiss statt einer Abschrift des Standards, Ihr Formular wird schon daran gemessen, bevor auch nur eine Zeile Ihres Codes läuft, und sie ist kurz genug, um sie auf einen Blick zu lesen:

/^[a-zA-Z0-9.!#$%&'*+\/=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$/

Verwenden Sie das, oder das, was Ihre Plattform schon mitbringt. Alle vier unten sind dieselbe Schicht, und welche Sie wählen, ist eine kleinere Entscheidung als das, was Sie danach tun:

Welches davon Sie auch verwenden — entscheidend ist, wozu es schweigt. Ein Muster, das „wahr“ zurückgibt, hat Ihnen eine Sache gesagt und über vier andere geschwiegen.

Nicht, dass die Domain existiert

Eine Adresse auf einer Domain, die nie jemand registriert hat, besteht jedes Muster in diesem Abschnitt. Nachgeschlagen wurde nichts, und kontaktiert wurde niemand; noch nie hat ein regulärer Ausdruck eine Netzwerkanfrage gestellt.

Nicht, dass das Postfach existiert

Selbst bei einer echten Domain hat das Muster keine Meinung zum Teil vor dem @. Dieser Teil gehört allein dem empfangenden Server, und genau das ist es, was DNS Ihnen nie sagen wird.

Nicht, dass sie zustellbar ist

Eine Domain kann einen fehlerfreien Eintrag haben und trotzdem einen Mailserver, der seit einem Monat abgeschaltet ist. Syntax ist eine Eigenschaft einer Zeichenkette; Zustellbarkeit ist eine Eigenschaft der Welt in dem Moment, in dem Sie auf Senden drücken.

Nicht, dass sie der Person gehört, die sie eintippt

Die häufigste schlechte Adresse in jeder Datenbank ist eine echte, zustellbare, die jemandem gehört, der sich nie angemeldet hat — weil ein Buchstabe vertippt wurde, oder weil das Formular mit einer plausibel aussehenden Lüge ausgefüllt wurde.

Was legal ist, und was zu Unrecht aussortiert wird

Die meisten Validierungsfehler sind nicht schlechte Adressen, die durchgekommen sind. Es sind Menschen, die sich nicht anmelden konnten, und sie tauchen in keinem Protokoll auf, das je jemand liest — das Formular sagte Nein, und sie gingen woandershin. Diese sechs tun das am häufigsten.

Und drei Zahlen, die es wert sind, in Ihren Code geschrieben zu werden, weil sie sich nicht ändern:

64 Zeichen

Mehr darf der Teil vor dem @ nicht sein. Alles Längere ist keine lange Adresse, es ist keine Adresse.

255 Zeichen

Mehr darf die Domain nicht sein, Punkte eingerechnet. Nichts Legitimes kam dem je nahe, und die Grenze existiert vor allem, damit Sie überhaupt eine haben.

254 Zeichen

Mehr darf die gesamte Adresse nicht sein, wenn ein Server sie transportiert — was weniger ist als die beiden Zahlen von oben zusammengezählt. Diese gehört in die Datenbankspalte und in das maxlength des Feldes.

Schicht zwei: eine Abfrage, und was sie klärt

Der Teil nach dem @ ist eine Domain, und eine Domain hat entweder einen Ort, an den Mail kann, oder sie hat keinen. Eine einzige DNS-Abfrage beantwortet das in wenigen Millisekunden, und sie ist die wertvollste Prüfung in dieser gesamten Anleitung — weil der Fehler, den sie erwischt, ein leicht falsch getippter Domainname, mit Abstand der häufigste echte Fehlschlag überhaupt ist.

$ dig +short MX example.com

Eine Antwort bedeutet, dass ein Host benannt wurde. Keine Antwort bedeutet nicht keine Mail: Eine Domain ohne MX-Eintrag, aber mit einem A-Eintrag, empfängt trotzdem, weil Absender darauf ausweichen. Es gibt vier mögliche Ergebnisse, und nur zwei davon sind Fehlschläge.

Wo diese Prüfung schiefgeht, ist nie die Abfrage selbst. Es ist, wohin die Abfrage gesetzt wurde — auf den kritischen Pfad, pro Tastenanschlag, mit einem Fehlschlag, der das Absenden blockiert. Sechs Regeln halten sie nützlich:

1. Führen Sie sie aus, wenn das Feld fertig ausgefüllt ist, nicht während des Tippens. Eine Abfrage, wenn der Fokus das Feld verlässt, oder eine beim Absenden. Eine Abfrage pro Tastenanschlag ist eine Abfrage pro Tastenanschlag.
2. Schreiben Sie die Domain zuerst klein. DNS ist das egal, Ihrem Cache nicht: Zwei Schreibweisen derselben Domain sind eine Abfrage, nicht zwei.
3. Fragen Sie nach MX, und weichen Sie auf A aus. Zwei Abfragen, von denen nur die zweite bedingt ist. Eine Bibliothek, die nur MX prüft, wird funktionierende Domains ablehnen.
4. Speichern Sie die Antwort für ein paar Minuten im Cache. Eine Handvoll Domains macht überall die meisten Anmeldungen aus, sodass aus den meisten Abfragen gar keine Abfrage mehr wird.
5. Im Zweifel akzeptieren. Läuft der Resolver in ein Timeout, akzeptieren Sie die Adresse. Eine schlechte Minute bei Ihrem DNS-Anbieter darf nie zu einem Formular werden, das alle abweist.
6. Schlagen Sie eine Korrektur vor; nehmen Sie sie nie selbst vor. Ist die Domain einen Buchstaben von einer gängigen entfernt, bieten Sie die Korrektur zum Anklicken an. Stillschweigend umzuschreiben, was jemand eingetippt hat, ist der Weg, auf dem ein Bestätigungslink bei einem Fremden landet.

Die Abfrage hat einen Preis, den man kennen sollte: Sie ist der erste Moment, in dem Ihr Formular mit der Außenwelt über etwas spricht, das ein Besucher eingetippt hat. Wo das eine Rolle spielt, besteht die Alternative darin, diese Schicht ganz zu überspringen und die Nachricht selbst die ganze Prüfung sein zu lassen.

Schicht drei: den Server fragen, und warum die Antwort keine ist

Es gibt eine Möglichkeit, einen Mailserver zu fragen, ob er eine bestimmte Adresse annehmen würde, ohne ihr etwas zu senden. Die Verbindung öffnen, einen Absender nennen, den Empfänger nennen, die Antwort auf genau diesen einen Befehl lesen und vor der Nachricht auflegen:

220 mx1.example.com ESMTP ready
EHLO checker.example.net
250 mx1.example.com
MAIL FROM:<probe@example.net>
250 2.1.0 Ok
RCPT TO:<someone@example.com>
250 2.1.5 Ok
QUIT
221 2.0.0 Bye

Die 250 nach RCPT TO ist es, was letztlich jeder Adressverifizierungsdienst der Welt verkauft. Es lohnt sich, genau zu sein, wie wenig sie wert ist.

Eine Catch-all-Domain sagt zu allem Ja

Eine Domain, die so eingerichtet ist, dass sie jeden Namen akzeptiert — was dieser Dienst tut, und was sehr viele Firmendomains auch tun —, antwortet mit 250 auf eine Adresse, die nie jemand benutzt hat. Die Antwort stimmt, und sie ist keine Information.

Ein sorgfältiger Server sagt absichtlich 450

Greylisting weist den ersten Versuch eines unbekannten Absenders zurück und bittet ihn, es bald wieder zu versuchen. Ein echter Absender tut das; eine Sonde nie. Dieser vorübergehende Fehlschlag ist eine absichtliche Nicht-Antwort, und ihn als „kein solches Postfach“ zu lesen, ist genau der Fehler, den er erzeugen soll.

Manche Server nehmen erst an und lehnen danach ab

Große Anbieter nehmen die Nachricht während der Konversation routinemäßig an und entscheiden erst später über sie, wodurch aus einer Ablehnung ein Bounce wird, der erst Minuten eintrifft, nachdem Ihre Sonde sauber zurückgekommen ist.

Manche Server sagen zu allen Nein, die sie nicht kennen

Ein Server, der entschieden hat, dass Ihre Adresse ein Fremder ist, kann den Empfänger aus Gründen ablehnen, die nichts mit dem Empfänger zu tun haben. Gemessen haben Sie Ihren eigenen Ruf, nicht dessen Postfach.

Und sie verbraucht den Ruf, den Sie eigentlich schützen wollten

Eine Verbindung, die Empfänger nennt und nie etwas sendet, hat genau die Form eines Adress-Harvestings, weil sie eines ist. Das in großem Umfang von der eigenen Adresse aus zu tun, ist der schnellste Weg auf eine Sperrliste — und ein gesperrter Absender ist einer, dessen echte Nachrichten nicht mehr ankommen.

Es gibt einen einzigen engen Fall, in dem die Sonde wirklich nützlich ist: eine einzelne Adresse, von Hand geprüft, auf einer Domain, die Sie selbst betreiben oder anfassen dürfen. Als Schritt innerhalb eines Anmeldeformulars ist sie langsam, häufig falsch, und gelegentlich schädlich für genau das, was sie eigentlich schützen sollte.

Rollenadressen, Wegwerf-Domains und die Liste, die Sie gleich kaufen

Zwischen der Domain-Abfrage und der echten Nachricht sitzt eine Familie von Prüfungen, bei denen es überhaupt nicht um Gültigkeit geht. Es geht darum, ob Sie diese Adresse wollen — eine geschäftliche Entscheidung im technischen Kostüm —, und allein deshalb lohnt es sich, sie von den drei Schichten drumherum zu trennen.

Rollenadressen

Namen wie info@, support@ und admin@. Sie sind echt, und meist ein gemeinsam genutztes Postfach statt einer Person, was sie zu einem schlechten Zuhause für alles macht, wofür ein Passwort dahintersteckt. Es lohnt sich, sie zu markieren. Selten lohnt es sich, sie abzulehnen.

Wegwerf-Domains

Adressen wie die, die diese Seite ausgibt, auf Domains, die existieren, um weggeworfen zu werden. Sie gegen eine öffentliche Liste davon zu prüfen, ist fair genug, solange Sie ehrlich damit sind, dass jede solche Liste unvollständig und schon an dem Tag, an dem Sie sie herunterladen, leicht veraltet ist.

Freemailer-Adressen

Manche Geschäftsformulare weisen alles zurück, was keine Firmendomain ist. Das ist eine Richtlinie, manchmal die richtige, und sie verdient es, als Richtlinie geschrieben zu werden — ein Satz, den der Besucher lesen kann — statt in etwas versteckt zu werden, das sich Validierung nennt.

Beinahe-Treffer bekannter Domains

Der Name eines bekannten Anbieters mit einem falschen Buchstaben. Dieser Fall ist anders als die anderen drei: Er ist keine Richtlinie, er erwischt einen echten Fehler, und die Person ist immer froh darüber. Es ist der einzige Eintrag hier, den zu bauen sich lohnt.

Die ersten drei teilen eine Eigenschaft, die sie schwer zu beurteilen macht: Sie können messen, was sie durchlassen, und Sie können nicht messen, was sie kosten.

Wir haben hier ein offensichtliches Eigeninteresse, also hier die ehrliche Version. Steckt hinter Ihrem Formular eine kostenlose Testphase mit etwas Teurem dahinter, spart Ihnen das Ablehnen von Wegwerf-Domains Geld, und Sie sollten es tun. Ist es ein Newsletter, ein Download oder ein Konto, für das jemand bezahlt, besteuern Sie damit vor allem die Vorsichtigen — und die Vorsichtigen sind die, die lesen, was Sie verschicken.

Schicht vier: die Nachricht, die die Prüfung ist

Alles oben grenzt das Feld nur ein. Nichts davon stellt die einzige Tatsache fest, auf die es ankommt — dass diese Adresse die Person vor Ihnen erreicht —, und genau eine Sache tut das: etwas dorthin senden und zusehen, ob es benutzt wird.

Das ist die Schleife, die fast jede Anmeldung schon hat und die die Hälfte von ihnen als Formsache behandelt:

1. Akzeptieren Sie die Adresse nach einer einzigen großzügigen Prüfung. Das Muster im Browser, und sonst nichts, was zwischen dem Besucher und dem Knopf steht.
2. Legen Sie das Konto unbestätigt an. Kein Halt im Formular, kein Bildschirm mit „ausstehend“: Die Person ist drin, und was sie noch nicht kann, ist die Handvoll Dinge, für die die Adresse tatsächlich gebraucht wird.
3. Senden Sie eine Nachricht mit einem Einmal-Link oder -Code. Eine einzige, mit Ablaufdatum, gebunden an genau dieses Konto und genau diese Adresse und keine andere.
4. Lassen Sie den Link der Beweis sein. Ein Klick, oder ein zurückgetippter Code, ist die gesamte Verifizierung. Nichts sonst in dieser Anleitung liefert eine auch nur annähernd so solide Antwort.
5. Geben Sie ihnen einen Weg zurück. Ein sichtbares „Erneut senden“, und eine Möglichkeit, die Adresse zu ändern, ohne das Konto zu verlieren — denn der häufigste Grund, warum ein Link nie angeklickt wird, ist ein Tippfehler, den die Person jetzt endlich sehen kann.
6. Lassen Sie die unbestätigten ablaufen. Ein stiller Aufräumdurchgang nach einer festen Frist verhindert, dass sich Tippfehler und Wegwerf-Adressen zu einer Liste anhäufen, der niemand traut.

Das schafft ein praktisches Problem, und es ist der Grund, warum diese Seite existiert. Diese Schleife ist inzwischen der wichtigste Pfad im Produkt, und sie zu testen bedeutet, immer wieder echte Mail an einer Adresse zu empfangen, die Sie kontrollieren — innerhalb einer Pipeline, ohne dass ein Mensch ein Postfach öffnet.

Eine Adresse auf einer der öffentlichen Domains braucht keine Anmeldung und keinen Schlüssel, und was dort ankommt, ist eine Sekunde später über HTTP lesbar:

$ curl -sG https://grabmail.io/api/v1/mailbox \
  --data-urlencode "address=signup-42@grabmail.io"

Von dort aus kann eine Testsuite einen ganzen Verifizierungsablauf von Anfang bis Ende steuern, oder eine eigene Domain kann hierher zeigen, sodass jeder Lauf eine Adresse bekommt, die es nie zuvor gegeben hat. Nachrichten werden 5 Tage aufbewahrt und dann gelöscht, was die richtige Lebensdauer für eine Testfixture ist und die falsche für ein Postfach.

Was tatsächlich ins Formular gehört

Verdichtet, in der Reihenfolge, in der der Code läuft:

1. Trimmen, und nur trimmen. Leerraum an beiden Enden ist ein Artefakt des Einfügens und nie beabsichtigt. Sonst steht es Ihnen nicht zu, an der Zeichenkette etwas zu ändern.
2. Gegen ein großzügiges Muster prüfen. Das des Browsers, oder das Ihrer Plattform. Weisen Sie das fehlende @ und das getippte Komma zurück, und sonst nichts.
3. Die Länge bei 254 deckeln. Eine Zahl, in der Spalte und im Feld, und eine ganze Klasse von Eingaben, über die Sie nicht mehr nachdenken müssen.
4. Die Domain abfragen, abseits des kritischen Pfads, im Zweifel akzeptierend. MX und dann A, gecacht, und nie ein Grund, ein Absenden zu blockieren, das sonst funktioniert hätte.
5. Eine Korrektur anbieten, keine vornehmen. Ein Buchstabe von einer gängigen Domain entfernt ist eine Frage, die man stellt, kein Befund, nach dem man handelt.
6. Die Nachricht senden. Das ist die Validierung. Alles davor war Triage.
7. Sagen Sie in Worten, was falsch ist. Das ist der Teil, der entscheidet, ob überhaupt jemand fertig wird:

Achten Sie darauf, wie viele Zeilen dasselbe Falsche sagen. „Bitte geben Sie eine gültige E-Mail-Adresse ein“ ist überall die Standardmeldung, weil sie für jeden Fall stimmt und in keinem davon nützlich ist: In drei von fünf Zeilen war die Adresse gültig, und die Person, die sie eingetippt hat, hat keine Möglichkeit herauszufinden, in welcher Zeile sie steckt.

Die Kurzversion

1. Trimmen Sie die Zeichenkette. Ändern Sie sonst nichts daran.
2. Prüfen Sie gegen ein großzügiges Muster — das des Browsers oder das Ihrer Plattform — und lassen Sie es dabei. Schreiben Sie kein eigenes.
3. Weisen Sie alles über 254 Zeichen zurück, und legen Sie eine Spalte dieser Größe an.
4. Fragen Sie MX für die Domain ab, weichen Sie auf A aus, cachen Sie das Ergebnis, tun Sie es abseits des kritischen Pfads, und akzeptieren Sie die Adresse, wenn die Abfrage fehlschlägt.
5. Lehnen Sie eine Domain ab, die sich nicht auflöst, und eine Domain, die einen Null-MX veröffentlicht. Akzeptieren Sie alles andere, was DNS Ihnen liefert.
6. Bieten Sie einen Rechtschreibvorschlag an, wenn die Domain ein Beinahe-Treffer ist. Wenden Sie ihn nie selbst an.
7. Entscheiden Sie getrennt, und schriftlich, ob Sie Wegwerf- oder Rollenadressen blockieren — und warum.
8. Senden Sie eine Nachricht mit einem Einmal-Link, behandeln Sie den Klick als die Verifizierung, und machen Sie das erneute Senden und das Korrigieren der Adresse leicht.
9. Testen Sie diese Schleife gegen ein echtes Postfach, einschließlich der Pfade, auf denen sie fehlschlägt, und löschen Sie unbestätigte Konten nach einem festen Zeitplan.

Neun Zeilen, und nur die letzten beiden stellen überhaupt etwas fest. Die anderen sieben existieren, damit sich die Nachricht am Ende von ihnen lohnt.

Fragen