Immer nur auf Webstandards herumzuhacken ist auf Dauer etwas eintönig. Darum hacke ich heute einmal auf einer anderen Gruppe von Standards herum: Mailadressen.

E‑Mail-Adressen — das haben sie “Messengern” und dergleichen voraus — sind bekanntlich oft langlebig, so mancher Mensch im Bekanntenkreis könnte eine E‑Mail-Adresse haben, deren Alter zwei Jahrzehnte bereits erreicht hat. Viele der heutigen Digitalisierten waren damals noch gar nicht geboren.

Zugrunde liegen, jeweils aufgeteilt in verschiedene RFC-Dokumente, zwei verschiedene Standards (einer für den Teil vor dem @, den so genannten “local part”, und einer für den Teil nach dem @, den so genannten “domain part”), wobei mit dem Aufkommen von Unicodedomains beide Standards eine Erweiterung bekamen, die die Nutzung von UTF-8-Zeichen in beiden Hälften optional erlauben, so lange das “@” bestehen bleibt. Einige der definierenden RFC-Dokumente dienen nur dem Zweck, die anderen RFC-Dokumente zu erklären: RFC 3696 etwa gibt einen groben Überblick über die Validierung von URL- und URI-Formaten, sozusagen “für Dummies”. Das sowieso schon unübersichtliche Regelwerk kennt wiederum so viele Ausnahmen, dass sogar in der englischsprachigen Wikipedia beispielhaft Mailadressen als “ungültig” stehen, von denen allerdings anscheinend niemand — die RFCs eingeschlossen — weiß, warum.

Hinzu kommt, dass zwischen Standard und gelebter Praxis wie auch im Web ein größer werdender Graben aufgetan wurde, oft innerhalb desselben Dienstes; so unterstützt etwa die Weboberfläche von Google Mail das Anlegen von Mailadressen mit Sonderzeichen darin nicht, der dazu gehörende Mailserver allerdings — technisch gesehen — durchaus. Eine Validierung nach dem Kriterium, welche Mailadressen der eigene Anbieter für “gültig” hält, ist allerdings ohne direkten Zugriff auf diese Mailserver nicht ohne weiteres möglich.

Als wären die Standards nicht auch ohne solche Sperenzchen merkwürdig genug. Es gilt zum Beispiel die Regel, dass sehr wohl bestimmte Zeichen oder Zeichenfolgen nachträglich als “ungültig” (deprecated) gekennzeichnet werden können, was aber natürlich nicht heißt, dass man seine alten Mailadressen nicht mehr weiterbenutzen darf. Ein Beispiel: Ich hätte mir vor langer Zeit die Mailadresse musik.ist.“supi”@provider.tld anlegen können. Da gemäß RFC 5322 von einer Kombination aus Text innerhalb und außerhalb von Anführungszeichen im “local part” aber inzwischen abgeraten wird, dürfte ich sie bei einem Anbieter, der sich strikt an den Standard hält, nicht mehr anlegen — nur nutzen dürfte ich sie noch, denn damit eine Mailadresse existieren kann, muss sie erst einmal gültig sein und sollte damit eben auch überall akzeptiert werden. Schrödingers Mailadresse.

Wie man erkennen kann, ist die regelkonforme Validierung eine sehr anstrengende Arbeit. Eine Abdeckung der Standards mit einem regulären Ausdruck, wie es im Web gemeinhin empfohlen wird, wäre vermutlich machbar, aber kaum mehr vernünftig lesbar. Selbstverständlich könnte sich die Menschheit auch darauf einigen, dass in E‑Mail-Adressen nur ein kleiner Teil des ASCII-Zeichensatzes erlaubt sein darf, oder eine E‑Mail-Adresse valide ist, sobald genau ein einziges “@” darin vorkommt, aber der Sinn hinter Standards ist es ja, dass die Menschheit nicht besonders gut darin ist, sich ohne aufgeschriebene Regeln auf irgendetwas zu einigen.

Um selbst künftig ein wenig weniger genervt von diesem Wildwuchs zu sein, habe ich libvldmail programmiert. Hierbei handelt es sich um eine portable Bibliothek ohne besondere Abhängigkeiten mit einem kompakten API, deren einziger Zweck es ist, E‑Mail-Adressen standardkonform als “ist valide” oder “ist nicht valide” zu kennzeichnen. Die Bibliothek ist vermutlich noch nicht ganz fertig, aber durchaus schon funktionsfähig. Der Quellcode liegt bis auf Weiteres auf GitHub herum, je nach Erfolg oder Misserfolg schließe ich aber einen Wechsel zu einer anderen Plattform nicht aus. GitHub ist mir zutiefst unsympathisch.