E-Mail-Adressen validieren: was eine Syntaxprüfung zeigen kann und was nicht

Worum es geht

Eine Adresse hat die Form local-part@domain. RFC 5321 begrenzt den Local-Part auf 64 Oktette, einen Domainnamen auf 255 Oktette und einen gesamten Vorwärts- oder Rückwärtspfad auf 256 und legt fest, dass der Local-Part als gross-/kleinschreibungssensitiv zu behandeln ist, wobei davon abgeraten wird, das auszunutzen. Die Grammatik von RFC 5322 erlaubt zusätzlich in Anführungszeichen gesetzte Local-Parts, Kommentare und faltbaren Leerraum, die fast niemand verwendet. Der HTML-Standard definiert für <input type=email> bewusst eine einfachere Grammatik: eine Folge von atext-Zeichen und Punkten, @, dann durch Punkte getrennte Labels von höchstens 63 Zeichen; er bezeichnet dies als absichtlichen Verstoss (willful violation) gegen RFC 5322, dessen Syntax er als für Formulare gleichzeitig zu streng vor dem @, zu vage danach und insgesamt zu lax beschreibt. Internationalisierte Adressen mit Local-Parts ausserhalb von ASCII sind in RFC 6531 (der Erweiterung SMTPUTF8) definiert und funktionieren nur, wenn jeder Server auf dem Weg sie unterstützt.

Warum es wichtig ist

Kein regulärer Ausdruck kann feststellen, ob ein Postfach existiert, ob die besitzende Person es selbst eingegeben hat oder ob es die Mail annehmen wird. Zu strenge Prüfungen weisen reale Personen zurück (Plus-Adressierung, Apostrophe, neuere Top-Level-Domains); zu laxe Prüfungen lassen user@localhost und Tippfehler durch, die später zu Bounces und Reputationsschäden führen.

So wird es angewendet

• Die Syntax nach der Definition des HTML-Standards prüfen (oder mit der eingebauten Browserprüfung) sowie die Längengrenzen einhalten; bei öffentlichen Websites einen Punkt in der Domain verlangen.
• Minimal normalisieren: Leerraum entfernen, die Domain in Kleinbuchstaben umwandeln, den Local-Part so belassen, wie er eingegeben wurde.
• Bei der Registrierung prüfen, dass die Domain einen MX-Eintrag hat (oder ersatzweise einen A/AAAA-Eintrag); einen fehlgeschlagenen Lookup als "bitte diese Adresse prüfen" behandeln, nicht als harte Zurückweisung, da DNS vorübergehend nicht verfügbar sein kann.
• Den Besitz mit einem Bestätigungslink oder -code nachweisen; ein Abtasten des Empfängerservers auf SMTP-Ebene ist unzuverlässig und wirkt wie Missbrauch.
• Explizit entscheiden, ob SMTPUTF8-Adressen akzeptiert werden. Unterstützt der versendende Anbieter sie nicht, bereits bei der Registrierung mit einer klaren Meldung zurückweisen, statt erst beim Versand zu scheitern.
• Für häufige Domain-Tippfehler Korrekturvorschläge machen, sie aber nie automatisch anwenden.

Stolpersteine

+ im Local-Part zurückweisen oder eine Top-Level-Domain, weil sie länger als vier Zeichen ist. Den Local-Part in Kleinbuchstaben umwandeln, was eine gross-/kleinschreibungssensitive Kennung verändert. Listen von Wegwerf-Domains als Sicherheitsmassnahme behandeln. Die Adresse als Primärschlüssel verwenden: Adressen ändern sich, und zwei Personen können sich eine teilen.

Der Null-MX-Eintrag

RFC 7505 erlaubt es einer Domain, zu erklären, dass sie keine Mail annimmt, indem sie einen einzelnen Eintrag MX 0 . veröffentlicht. Ein Lookup, der nur prüft, ob ein MX-Eintrag existiert, akzeptiert dadurch genau jene Domains, die sich bewusst ausgeschlossen haben; die Registrierungsprüfung braucht deshalb einen weiteren Zweig: MX auflösen; ist die einzige Antwort 0 ., mit einer Meldung zurückweisen, dass die Domain keine Mail annimmt; gibt es gewöhnliche MX-Einträge, akzeptieren; gibt es keine, wie von RFC 5321 erlaubt auf A oder AAAA ausweichen; und Resolver-Fehler als "bitte diese Adresse prüfen" behandeln, nicht als Zurückweisung. Dieselbe Regel gehört auch in die Versandpipeline, wo ein Null-MX ein dauerhafter Fehlschlag ist, der niemals in die Retry-Queue gelangen sollte.