Vérificateur d’adresse email

Qu’est-ce qu’un vérificateur d’adresse email ?

Un vérificateur d’adresse email répond à la question de savoir si une chaîne est bien formée en tant qu’adresse. Les formulaires d’inscription en emploient un pour attraper les fautes de frappe avant qu’elles ne coûtent une réinitialisation de mot de passe, les listes de diffusion pour contenir les retours, et les développeurs y reviennent lorsqu’une expression régulière recopiée sur internet s’est mise à refuser un client dont l’adresse est parfaitement légale.

L’ennui, c’est qu’il n’y a pas de réponse unique, et ce sont les spécifications elles-mêmes qui le disent. La norme HTML définit ce qu’accepte un champ <input type=email> et qualifie sa propre définition, en ces termes, de « violation délibérée du RFC 5322 », la norme d’internet pour le format des messages. Elle avance trois raisons : le RFC 5322 est trop strict avant l’arobase, trop vague après, et trop permissif en autorisant commentaires, espaces et chaînes entre guillemets qui laisseraient perplexe à peu près tout le monde.

Les trois griefs se vérifient, et la conséquence est ce que cette page existe pour montrer : aucune des deux normes ne contient l’autre. Chacune accepte des adresses que l’autre refuse. D’où deux verdicts côte à côte, avec le nom de la règle qui a tranché.

Comment s’en servir

1. Collez vos adresses, une par ligne. Une seule suffit et une liste de plusieurs milliers passe aussi. Les lignes vides sont ignorées plutôt que comptées comme des échecs, et les espaces autour sont retirés : coller une colonne de tableur fait donc ce que vous attendez.
2. Lisez les deux étiquettes de chaque ligne. L’une est la règle des formulaires HTML, celle qui décide si le navigateur laissera soumettre le champ. L’autre est le RFC 5322, celle qu’implémente une bibliothèque de messagerie. Quand elles divergent, la ligne est signalée, car c’est le cas qui vaut d’être connu.
3. Lisez le motif en dessous. Quelle que soit la norme qui a rejeté l’adresse, la ligne du dessous indique quelle règle l’a fait : un point mal placé, une partie locale entre guillemets, un commentaire entre parenthèses, un trait d’union en bordure d’étiquette de domaine. Un verdict sans motif ne sert pas à grand-chose quand il faut décider si l’on corrige l’adresse ou le vérificateur.

Là où les deux normes se séparent

Trois adresses d’allure banale sont valides pour la règle HTML et invalides pour le RFC 5322, et toutes trois tiennent aux points. Le RFC 5322 construit la partie précédant l’arobase avec un « dot-atom », des morceaux de texte reliés par des points isolés ; un point doublé, initial ou final casse donc la grammaire. Le motif du HTML autorise simplement des points n’importe où dans cette suite de caractères, si bien que john..doe@example.com passe un formulaire de navigateur et échoue sur un analyseur strict.

Nettement plus d’adresses vont dans l’autre sens. Le RFC 5322 permet que la partie précédant l’arobase soit une chaîne entre guillemets, donc "john..doe"@example.com est légale : les guillemets font des points des données et non de la structure. Il admet des commentaires entre parenthèses presque partout, si bien que john.doe(comment)@example.com s’analyse sans encombre. Il autorise un domaine littéral entre crochets, aussi bien user@[192.168.0.1] que la forme IPv6. Et sa grammaire de domaine ne comporte aucune règle sur les étiquettes, ce que la norme HTML appelle « trop vague » : user@-example.com et une étiquette de domaine de 64 caractères sont syntaxiquement correctes pour le RFC 5322 et toutes deux refusées par le navigateur.

La lecture pratique, c’est que la règle du HTML est un compromis délibéré et non une erreur. Elle est plus étroite là où le RFC est permissif sur des choses que personne n’écrit, et plus large là où le RFC est pointilleux sur des choses que les gens écrivent vraiment. Pour valider un champ de formulaire, imiter le navigateur est en général le bon choix. Pour écrire un analyseur de courrier, ce ne l’est pas.

Limites assumées

Aucune des deux colonnes ne dit si le courrier arriverait réellement. C’est une troisième question à part entière — le domaine existe-t-il, a-t-il un serveur de messagerie, la boîte existe-t-elle, acceptera-t-elle le message — et elle demande des requêtes DNS et une conversation SMTP. Une page tournant dans votre navigateur ne peut rien faire de tout cela, et cet outil ne prétend pas le contraire. Quiconque affirme vérifier la délivrabilité sans envoyer de message devine à partir d’une liste de domaines connus, ou fait le travail sur un serveur auquel vous confiez votre liste.

Les limites de longueur méritent d’être connues et sont plus étranges qu’il n’y paraît. Le RFC 5321 plafonne la partie précédant l’arobase à 64 octets et le domaine à 255. Les 254 caractères au total qu’utilise toute bibliothèque de validation ne figurent dans le corps d’aucun RFC : ils viennent d’un erratum vérifié contre le RFC 3696, qui les déduit de la limite de 256 octets d’un forward-path, moins les deux chevrons qu’un chemin est tenu de porter autour de l’adresse. Un erratum antérieur disait 256 et a été corrigé exactement de ces deux caractères. Poussez l’arithmétique d’un cran et il en sort une curiosité : 64 plus un plus 255 font 320, largement au-dessus de 254, si bien que les deux maximums partiels ne peuvent jamais être atteints ensemble dans une adresse réelle.

Les longueurs sont ici comptées en octets et non en caractères, parce que c’est ce que dit le RFC. Pour une adresse ASCII ordinaire les deux chiffres coïncident, mais un caractère accentué occupe deux octets et un emoji quatre : une adresse d’apparence courte peut donc être plus longue sur le réseau qu’à l’écran.

Les deux normes implémentées ici sont purement ASCII, et c’est une vraie limite plutôt qu’un oubli. Les adresses internationalisées — caractères non ASCII avant ou après l’arobase — relèvent de spécifications ultérieures, et leur prise en charge par les logiciels de messagerie est assez inégale pour que les déclarer valides sans autre forme de procès serait une autre manière de mentir. Quand il en passe une, l’outil indique quel caractère l’a provoquée au lieu d’échouer en silence.

Une chose que cet outil ne fait pas, délibérément, c’est deviner les fautes de frappe. Suggérer que gmial.com voulait dire gmail.com suppose une liste de fournisseurs populaires, et une telle liste est un instantané qui vieillit sans prévenir et finit par corriger ceux qui utilisent réellement un domaine plus modeste.

Pourquoi est-ce gratuit ?

Parce que cela ne coûte rien à faire tourner. Les deux normes sont implémentées dans votre navigateur, donc les adresses que vous collez ne quittent pas votre machine — ce qui compte ici plus qu’ailleurs, puisqu’une liste de diffusion est précisément ce qu’il ne faut pas téléverser chez un inconnu pour la faire vérifier.

Pas de compte, pas de plafond sur le nombre d’adresses vérifiées d’un coup, et rien qui soit réservé à une formule payante. L’implémentation est confrontée à un véritable analyseur RFC 5322 plutôt qu’à des attentes écrites à la main, et à l’expression régulière que la norme HTML publie elle-même : les verdicts de cette page sont donc défendables.