Combien de fois ai-je vu une adresse de
courrier parfaitement légale être refusée par un
formulaire d'inscription quelconque, en général avec une remarque
désobligeante, du genre "ERREUR : Votre adresse email est invalide". À quoi
est-ce dû ? Au fait que le plupart du temps, les programmeurs qui ont
écrit cette vérification ne connaissent pas les règles de syntaxe des
adresses de courrier et ne se rendent pas compte qu'il en existe plus
de variétés qu'ils ne l'imaginent.
Lorsqu'un formulaire sur le Web vous demande d'indiquer une adresse
de courrier électronique, le programme situé
derrière vérifie souvent la syntaxe de ladite adresse. Bien sûr, le
mieux serait de tester l'adresse, en y envoyant un mot de passe, par
exemple. C'est ce que font en général les formulaires d'abonnement à
une liste de diffusion. Si cette méthode est un
très bon test (si le message est reçu, c'est, par définition, que
l'adresse est valide), elle est plus complexe à programmer, nécessite
de garder un état (ce qui a été envoyé, ce qui a été confirmé), et elle
peut ennuyer le destinataire.
Aussi, le test se limite souvent à la syntaxe : on vérifie, par
exemple (attention, je prends exprès un exemple
complètement faux) que l'adresse correspond à l'expression rationnelle[A-Za-z0-9_\-\.]+@[A-Za-z0-9\-\.]+, qui autorise
postmaster@example.org mais pas
stephane+blog@bortzmeyer.org qui est pourtant
parfaitement légale.
J'utilise en général des "adresses plus" comme
stephane+blog@bortzmeyer.org car elles permettent
facilement de trier son courrier (on la retrouve dans l'en-tête
Delivered-To). Le MTA est
configuré pour délivrer à la boîte dont le nom précède le signe plus (en Sieve, cela se fait avec le )
et on peut donc créer sans formalité une infinité d'adresses. À chaque
formulaire que je remplis, je laisse une adresse différente,
comportant le nom de l'organisation qui gère le formulaire, ce qui me
permet de savoir ensuite d'où vient l'adresse par laquelle on me
joint. Ce n'est pas forcément le signe plus qui est utilisé, d'ailleurs
(le MTAPostfix permet
de configurer ce caractère avec l'option
recipient_delimiter, MMDFutilisait le signe égal, qui a les mêmes problèmes).
Mais le résultat est que je me fais jeter par de nombreux sites
Web. Par exemple, je cherchais à louer un serveur dédié Kimsufi pour l'hébergement de ce
blog mais je n'ai jamais réussi à me créer un compte client chez OVH, le fournisseur, car celui-ci
s'obstine à refuser mon adresse. J'ai finalement choisi SliceHost qui avait pile la même
bogue, mais qui l'a corrigée en quelques heures (alors que, la plupart du
temps, les rapports de bogue sur ce sujet sont ignorés).
Le manque de main d'œuvre pour le développement (une
technologie comme XForms ou comme les formulaires de HTML 5 simplifiera peut-être
les choses dans le futur) fait que les programmes de vérification des
données saisies, qu'ils soient écrits en
Javascript, PHP ou un
autre langage, sont en général assez bâclés. Il est exceptionnel que
leur auteur vérifie la norme qui régit la syntaxe des adresses de
courrier, le , section 3.4. À leur
décharge, il faut préciser que ladite norme est redoutable. Par
exemple, toutes les adresses suivantes sont valides :
{tropdur}@example.orgc&a@hotmail.comdirecteur@arts-premiers.museum (j'ai vu une
fois un code Javascript qui vérifiait que le
TLD avait moins de quatre lettres, ce qui est
absurde vue l'existence de .museum ou
.travel)"Stephane[Bortzmeyer]"@laposte.net
Alors, quel conseil donner au programmeur ? D'abord, il faut bien
voir qu'il a très peu de chances de vérifier une adresse par une
simple expression rationnelle. Certes,
Tom Christiansen l'a fait
mais tout le monde n'est pas Tom Christiansen (lisez la très
intéressante
page de test des expressions). La syntaxe des adresses est décrite
par une grammaire, pas par une
expression rationnelle. Si on veut analyser
tous les cas, il faut utiliser un vrai analyseur syntaxique. N'est-ce pas trop lourd pour une simple et
vague vérification ? Dans ce cas, une approche raisonnable est de ne
pas chercher à vérifier tous les cas mais de se contenter d'une
vérification légère. Par exemple, le ,
qui normalise le format de syndicationAtom a choisi une méthode simple et radicale :
atomEmailAddress = xsd:string { pattern = ".+@.+"
}. Cette expression est trop laxiste (elle accepte
"foo bar[@truc.machin) mais elle attrape quand
même une partie des erreurs, en ne refusant aucune adresse légale (ce
que je trouve pire que d'accepter des adresses illégales). (Les pros
des expressions rationnelles - comme Pascal
Courtois qui m'a signalé celle-ci - auront noté que,
si le moteur d'expressions est gourmand - greedy,
il faut réécrire l'expression en .+?@.+.)
Pour PHP, je recommande très chaudement un
excellent article de Douglas Lovell dans le Linux Journal,
Validate
an E-Mail Address with PHP, the Right Way, qui décrit
très bien la difficulté du problème et propose des solutions. Je
partage notamment son inquiétude que « There is some danger
that common usage and widespread sloppy coding will establish a de
facto standard for e-mail addresses that is more restrictive than the
recorded formal standard. »
J'ai parlé dans cet article du cas de formulaires Web
d'enregistrement, qui vous demandent votre adresse de courrier. Mais
Emmanuel Haguet me signale qu'il y a plus fort : des
webmails comme celui
d'Orange qui refusent d'envoyer du courrier aux
adresses qu'ils jugent, bêtement, non standards.
Quelques autres références intéressantes :
Un bon validateur en ligne
qui semble complètement conforme au RFC.What
is the best regular expression for validating email
addresses? sur StackOverflow.(Transmis par Pierre Beyssac) Un bon
article de Derrick Pallas sur WTF, avec plein
de commentaires intéressants(Transmis par Jean-Marc Liotier) Un bon
article sur la vanité des expressions rationnelles pour valider
des adresses de courrier. Si vous y tenez, voici quelques exemples d'expressions
qui marchent partiellement.Pour PHP, une outil
de validation des adresses qui semble
correct. C'est certainement mieux que les bricolages maison des
neuneus PHP typiques.Un article qui, notamment, explique les pièges de la syntaxe des
adresses (avec malheureusement une référence complètement dépassée au
très vieux ).Un autre bon article, par Sinjo, avec d'intéressants commentaires.Une réflexion de Matt Swanson sur ce sujet.Un autre bon article en anglais est celui de Dominic Sayers.Un exemple erroné pour PostgreSQL, par un auteur qui s'y connait davantage en expressions rationnelles qu'en courrier électronique.
J'espère que cet article aura convaincu quelques auteurs de
formulaires d'accepter toutes les adresses de courrier
légales. Espérons. En attendant, je publie
régulièrement les noms de ceux qui sont mal configurés. Il existe aussi un autre projet de publication.