Validation email : ce qu’une regex prouve, ou pas

Quatre questions qui partagent un seul mot

« Cette adresse email est-elle valide ? » n’est pas une seule question. Ce sont quatre questions, elles deviennent plus difficiles dans l’ordre, et la dernière est la seule à laquelle quiconque voulait vraiment une réponse — ce qui explique pourquoi tant de code de validation s’attarde sur la première et reste muet sur le reste.

Les voici, dans l’ordre où un formulaire d’inscription les rencontre.

A-t-elle la forme d’une adresse ?

Une vérification de syntaxe. Elle tourne dans le navigateur, ne coûte rien, et attrape la virgule tapée par erreur et le @ manquant. C’est la seule couche qui puisse honnêtement rejeter quoi que ce soit à elle seule — et même alors, elle devrait rejeter bien moins que la plupart des motifs ne le font.

Ce domaine peut-il seulement recevoir du courrier ?

Une vérification DNS. Une seule requête dit si quoi que ce soit, quelque part, accepte de recevoir du courrier pour la partie après le @. Elle attrape un nom de domaine à qui il manque une lettre et un domaine expiré l’an dernier, et elle ne peut strictement rien vous dire sur la boîte.

Cette boîte existe-t-elle ?

Une vérification SMTP — celle à laquelle ce guide consacrera le plus de temps à vous dire de ne pas faire confiance. Vous pouvez demander. La réponse est souvent un oui poli d’un serveur qui accepte tous les noms, ou un échec temporaire délibéré, ou une acceptation suivie d’un bounce quelques minutes plus tard.

Est-ce son adresse ?

Rien du côté technique ne peut répondre à ça. Une adresse peut être impeccable, joignable, et appartenir à quelqu’un d’autre — mal tapée d’un chiffre, ou tapée exprès pour vous berner. Seul un message qui arrive et qui est utilisé referme la question.

Les trois premières sont bon marché et prouvent peu. La quatrième est la seule à mériter le nom, et c’est celle qui coûte un message. Tout ce qui suit consiste à bien dépenser les trois premières pour que la coûteuse ne soit pas gaspillée.

Couche un : le motif, et les quatre choses qu’il ne peut pas savoir

Il n’existe pas d’expression régulière officielle pour une adresse email, et il ne peut pas y en avoir. La RFC 5322 définit une grammaire plutôt qu’un motif, et cette grammaire autorise des commentaires entre parenthèses, des espaces repliés et des chaînes entre guillemets contenant presque n’importe quel caractère — rien de tout cela qu’un vrai formulaire d’inscription ne devrait accepter, et tout cela qu’un motif fidèle doit accepter.

Ce qui existe, c’est une définition volontairement plus étroite que les navigateurs implémentent déjà : celle que la spécification HTML donne pour un champ <input type="email">. C’est un compromis assumé plutôt qu’une transcription du standard, c’est à quoi votre formulaire est déjà tenu avant même qu’une ligne de votre code ne s’exécute, et c’est assez court pour se lire d’un coup :

/^[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])?)*$/

Utilisez celui-là, ou celui que votre plateforme fournit déjà. Les quatre ci-dessous sont la même couche, et le choix de l’un d’eux compte moins que ce que vous en faites ensuite :

Quel que soit celui que vous utilisez, ce qui compte, c’est ce sur quoi il reste muet. Un motif qui renvoie vrai vous a dit une chose, et quatre non-choses.

Pas que le domaine existe

Une adresse sur un domaine que personne n’a jamais enregistré passe tous les motifs de cette section. Rien n’a été recherché et rien n’a été contacté ; aucune expression régulière n’a jamais fait de requête réseau.

Pas que la boîte existe

Même sur un domaine réel, le motif n’a aucun avis sur la partie avant le @. Cette partie appartient au seul serveur destinataire, et c’est précisément ce que le DNS ne vous dira jamais.

Pas qu’elle est joignable

Un domaine peut avoir un enregistrement impeccable et un serveur de messagerie éteint depuis un mois. La syntaxe est une propriété d’une chaîne ; la joignabilité est une propriété du monde à l’instant où vous appuyez sur envoyer.

Pas qu’elle appartient à la personne qui la tape

La mauvaise adresse la plus courante dans n’importe quelle base de données est une adresse réelle, joignable, appartenant à quelqu’un qui ne s’est jamais inscrit — parce qu’une lettre a été mal tapée, ou parce que le formulaire a été rempli avec un mensonge plausible.

Ce qui est légal, et ce qui est rejeté à tort

La plupart des bugs de validation ne sont pas de mauvaises adresses qui sont passées. Ce sont des gens qui n’ont pas pu s’inscrire, et ils n’apparaissent jamais dans un journal que quelqu’un lit — le formulaire a dit non, et ils sont allés ailleurs. Ces six-là le font le plus souvent.

Et trois nombres, qui méritent d’être écrits dans votre code parce qu’ils ne changent pas :

64 caractères

Le maximum que peut faire la partie avant le @. Plus long que ça, ce n’est pas une adresse longue, ce n’est pas une adresse.

255 caractères

Le maximum que peut faire le domaine, points compris. Rien de légitime n’en a jamais approché, et cette limite existe surtout pour que vous en ayez une.

254 caractères

Le maximum que peut faire l’adresse entière quand un serveur la transporte — ce qui est moins que les deux nombres ci-dessus additionnés. C’est celui-là qu’il faut mettre dans la colonne de la base de données et dans le maxlength du champ.

Couche deux : une requête, et ce qu’elle établit

La partie après le @ est un domaine, et un domaine a un endroit où mettre le courrier, ou il n’en a pas. Une seule requête DNS y répond en quelques millisecondes, et c’est la vérification la plus rentable de tout ce guide — parce que l’erreur qu’elle attrape, un nom de domaine légèrement mal tapé, est de loin l’échec réel le plus courant qui soit.

$ dig +short MX example.com

Une réponse signifie qu’un hôte a été nommé. L’absence de réponse ne signifie pas l’absence de courrier : un domaine sans enregistrement MX mais avec un enregistrement A reçoit quand même, parce que les expéditeurs s’y replient. Il y a quatre issues possibles, et seules deux d’entre elles sont des échecs.

Là où cette vérification tourne mal, ce n’est jamais la requête elle-même. C’est l’endroit où elle a été placée — sur le chemin critique, à chaque frappe, avec un échec qui bloque l’envoi. Six règles la gardent utile :

1. Lancez-la quand le champ est terminé, pas pendant qu’il est tapé. Une requête quand le focus quitte le champ, ou une à l’envoi. Une requête par frappe est une requête par frappe.
2. Mettez d’abord le domaine en minuscules. Le DNS s’en moque, mais votre cache non : deux orthographes du même domaine, c’est une requête, pas deux.
3. Demandez le MX, et repliez-vous sur A. Deux requêtes, dont seule la seconde est conditionnelle. Une bibliothèque qui ne vérifie que le MX rejettera des domaines qui fonctionnent.
4. Mettez la réponse en cache pendant quelques minutes. Une poignée de domaines représente la plupart des inscriptions partout, donc la plupart des requêtes deviennent des non-requêtes.
5. Échouez ouvert. Si le résolveur expire, acceptez l’adresse. Une mauvaise minute chez votre fournisseur DNS ne doit jamais devenir un formulaire qui repousse tout le monde.
6. Suggérez une correction ; ne l’appliquez jamais. Quand le domaine est à une lettre d’un domaine courant, proposez la correction comme quelque chose à cliquer. Réécrire silencieusement ce que quelqu’un a tapé, c’est ainsi qu’un lien de confirmation part chez un inconnu.

La requête a un coût qui mérite d’être connu : c’est le premier moment où votre formulaire parle au monde extérieur de quelque chose qu’un visiteur a tapé. Là où cela compte, l’alternative est de sauter entièrement cette couche et de laisser le message lui-même être toute la vérification.

Couche trois : interroger le serveur, et pourquoi la réponse n’en est pas une

Il existe un moyen de demander à un serveur de messagerie s’il acceptera une adresse donnée sans rien lui envoyer. Ouvrez la conversation, nommez un expéditeur, nommez le destinataire, lisez la réponse à cette seule commande, et raccrochez avant le message :

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

Le 250 après RCPT TO est ce que tout service de vérification d’adresse au monde vend en fin de compte. Cela vaut la peine d’être précis sur le peu que cela vaut.

Un domaine catch-all dit oui à tout

Un domaine configuré pour accepter n’importe quel nom — ce que fait ce service, et ce que font un grand nombre de domaines d’entreprise — répond 250 pour une adresse que personne n’a jamais utilisée. La réponse est vraie, et ce n’est pas une information.

Un serveur prudent répond 450 exprès

Greylisting refuse la première tentative d’un expéditeur inconnu et lui demande de revenir sous peu. Un vrai expéditeur le fait ; une sonde ne le fait jamais. Cet échec temporaire est une non-réponse délibérée, et le lire comme « aucune boîte de ce nom » est exactement l’erreur qu’il a été conçu pour produire.

Certains serveurs acceptent d’abord et refusent ensuite

Les grands fournisseurs prennent couramment le message pendant la conversation et décident plus tard, ce qui transforme un refus en bounce arrivant des minutes après que votre sonde est revenue propre.

Certains serveurs disent non à tous ceux qu’ils ne reconnaissent pas

Un serveur qui a décidé que votre adresse est celle d’un inconnu peut refuser le destinataire pour des raisons qui n’ont rien à voir avec le destinataire. Ce que vous avez mesuré, c’est votre propre réputation, pas leur boîte.

Et cela dépense la réputation que vous cherchiez à protéger

Une connexion qui nomme des destinataires et n’envoie jamais rien a exactement la forme d’une récolte d’annuaire, parce que c’en est une. Le faire en volume depuis votre propre adresse est le chemin le plus rapide vers une liste de blocage — et un expéditeur sur liste de blocage est un expéditeur dont les vrais messages cessent d’arriver.

Il y a un cas restreint où la sonde est réellement utile : une seule adresse, vérifiée à la main, sur un domaine que vous gérez ou que vous avez la permission d’aller sonder. Comme étape dans un formulaire d’inscription, elle est lente, souvent fausse, et parfois nuisible à la chose même qu’elle a été ajoutée pour protéger.

Adresses de rôle, domaines jetables, et la liste que vous êtes sur le point d’acheter

Entre la requête de domaine et le vrai message se trouve toute une famille de vérifications qui ne concernent pas la validité du tout. Elles concernent le fait de savoir si vous voulez de cette adresse, ce qui est une décision commerciale déguisée en décision technique — et qui mérite d’être séparée des trois autres couches rien que pour cette raison.

Adresses de rôle

Des noms comme info@, support@ et admin@. Ils sont réels, et il s’agit généralement d’une boîte partagée plutôt que d’une personne, ce qui en fait un mauvais logement pour tout ce qui a un mot de passe derrière. Ça mérite d’être signalé. Ça mérite rarement d’être refusé.

Domaines jetables

Des adresses comme celles que ce site distribue, sur des domaines qui existent pour être jetés. Les vérifier par rapport à une liste publique de ce genre est assez raisonnable, du moment que vous êtes honnête sur le fait que toute liste de ce type est incomplète et légèrement dépassée le jour où vous la téléchargez.

Adresses de fournisseur gratuit

Certains formulaires professionnels refusent tout ce qui n’est pas un domaine d’entreprise. C’est une politique, c’est parfois la bonne, et elle mérite d’être écrite comme une politique — une phrase que le visiteur peut lire — plutôt que cachée à l’intérieur d’une chose appelée validation.

Domaines courants, à une lettre près

Le nom d’un fournisseur bien connu avec une lettre erronée. Celui-là ne ressemble pas aux trois autres : ce n’est pas une politique, ça attrape une vraie erreur, et la personne est toujours contente. C’est la seule entrée ici qui mérite d’être construite.

Les trois premières partagent une propriété qui les rend difficiles à juger : vous pouvez mesurer ce qu’elles laissent passer, et vous ne pouvez pas mesurer ce qu’elles coûtent.

Nous avons un intérêt évident ici, donc voici la version honnête. Si ce qui se trouve derrière votre formulaire est un essai gratuit avec quelque chose de coûteux attaché, refuser les domaines jetables vous fera économiser de l’argent, et vous devriez le faire. Si c’est une newsletter, un téléchargement, ou un compte que quelqu’un paie, vous taxez surtout les prudents — et les prudents sont ceux qui lisent ce que vous envoyez.

Couche quatre : le message qui est la vérification

Tout ce qui précède resserre le champ. Rien de tout cela n’établit le seul fait qui compte — que cette adresse atteint la personne en face de vous — et une seule chose le fait : envoyer quelque chose là-bas, et regarder si c’est utilisé.

Voici la boucle que presque toutes les inscriptions ont déjà, et que la moitié d’entre elles traitent comme une formalité :

1. Acceptez l’adresse sur une seule vérification permissive. Le motif dans le navigateur, et rien d’autre entre le visiteur et le bouton.
2. Créez le compte non vérifié. Pas de blocage du formulaire, pas d’écran « en attente » : la personne est dedans, et ce qu’elle ne peut pas encore faire, c’est la poignée de choses pour lesquelles l’adresse est réellement nécessaire.
3. Envoyez un seul message portant un lien ou un code à usage unique. Un seul, avec une expiration, lié à ce compte et à cette adresse, et à aucun autre.
4. Laissez le lien être la preuve. Un clic, ou un code retapé, est toute la vérification. Rien d’autre dans ce guide ne produit une réponse aussi solide, et de loin.
5. Donnez-leur un moyen de revenir en arrière. Un « renvoyer » visible, et un moyen de changer l’adresse sans perdre le compte — parce que la raison la plus courante pour laquelle un lien n’est jamais cliqué est une faute de frappe que la personne peut enfin voir maintenant.
6. Faites expirer ceux que personne n’a confirmés. Un nettoyage discret après une période fixe empêche les fautes de frappe et les adresses jetables de s’accumuler en une liste à laquelle personne ne fait confiance.

Ce qui crée un problème pratique, et c’est la raison pour laquelle ce site existe. Cette boucle est maintenant le parcours le plus important du produit, et la tester veut dire recevoir du vrai courrier à une adresse que vous contrôlez — encore et encore, à l’intérieur d’un pipeline, sans qu’un humain n’ouvre une boîte de réception.

Une adresse sur l’un des domaines publics ne demande ni inscription ni clé, et tout ce qui y arrive est lisible via HTTP la seconde d’après :

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

À partir de là, une suite de tests peut piloter tout un parcours de vérification de bout en bout, ou un domaine que vous possédez peut être pointé ici pour que chaque exécution obtienne une adresse qui n’a jamais existé auparavant. Les messages sont conservés 5 jours puis supprimés, ce qui est la bonne durée de vie pour une fixture de test, et la mauvaise pour une boîte.

Ce qu’il faut vraiment mettre dans le formulaire

En condensé, dans l’ordre où le code s’exécute :

1. Coupez les espaces, et seulement ça. Les espaces à chaque extrémité sont un artefact de copier-coller et ne sont jamais voulus. Rien d’autre dans la chaîne n’est à vous de changer.
2. Faites correspondre un seul motif permissif. Celui du navigateur, ou celui de votre plateforme. Refusez le @ manquant et la virgule tapée par erreur, et ne refusez rien d’autre.
3. Plafonnez la longueur à 254. Un seul nombre, dans la colonne et dans le champ, et toute une classe d’entrées à laquelle vous pouvez arrêter de penser.
4. Faites la requête de domaine hors du chemin critique, en échouant ouvert. MX puis A, mise en cache, et jamais une raison de bloquer un envoi qui aurait autrement fonctionné.
5. Proposez une correction ; ne l’imposez pas. Être à une lettre d’un domaine courant est une question à poser, pas un constat sur lequel agir.
6. Envoyez le message. C’est ça, la validation. Tout ce qui précède n’était que du triage.
7. Dites ce qui ne va pas, avec des mots. C’est la partie qui décide si quelqu’un va jusqu’au bout :

Remarquez combien de lignes disent la même chose fausse. « Veuillez saisir une adresse e-mail valide » est le message par défaut partout parce qu’il est vrai dans tous les cas et utile dans aucun : dans trois lignes sur cinq, l’adresse était valide, et la personne qui l’a tapée n’a aucun moyen de découvrir dans quelle ligne elle se trouve.

La version courte

1. Coupez les espaces de la chaîne. Ne changez rien d’autre.
2. Faites correspondre un seul motif permissif — celui du navigateur ou celui de votre plateforme — et arrêtez-vous là. N’écrivez pas le vôtre.
3. Rejetez tout ce qui dépasse 254 caractères, et stockez une colonne de cette taille.
4. Recherchez le MX du domaine, repliez-vous sur A, mettez ça en cache, faites-le hors du chemin critique, et acceptez l’adresse quand la requête échoue.
5. Refusez un domaine qui ne se résout pas et un domaine qui publie un MX nul. Acceptez tout le reste de ce que le DNS vous donne.
6. Proposez une suggestion d’orthographe quand le domaine est à une lettre près. Ne l’appliquez jamais vous-même.
7. Décidez séparément, et par écrit, si vous bloquez les adresses jetables ou de rôle — et pourquoi.
8. Envoyez un message avec un lien à usage unique, traitez le clic comme la vérification, et rendez faciles le renvoi et la correction de l’adresse.
9. Testez cette boucle contre une vraie boîte de réception, y compris les parcours où elle échoue, et supprimez les comptes non confirmés selon un calendrier régulier.

Neuf lignes, et seules les deux dernières établissent quoi que ce soit. Les sept autres existent pour que le message au bout d’elles vaille la peine d’être envoyé.

Questions