Le format d’adresse e-mail est l’une des rares choses que tout développeur croit déjà connaître, et l’une des rares où cette croyance est généralement plus étroite que la norme et plus large que ce que les services acceptent. Les règles sont courtes : une adresse se coupe en deux autour de l’arobase, et chaque moitié a une limite de longueur exprimée en octets. Les complications viennent de partout ailleurs — des parties locales entre guillemets, des caractères internationaux, et de l’écart entre ce qu’une spécification permet et ce qu’un vrai service acceptera.
Les deux moitiés autour de l’arobase
Une adresse comporte une partie locale à gauche de l’arobase et un domaine à droite. La partie locale est l’affaire du système récepteur : à l’intérieur de son domaine, il peut interpréter cette étiquette comme il l’entend, ce qui explique que deux services puissent traiter la même étiquette de manières complètement différentes.
Le domaine est la partie que le système de messagerie au sens large doit pouvoir trouver, ce qui explique qu’il soit régi par les règles des domaines plutôt que par celles du courrier. Quand un message est envoyé, le côté expéditeur recherche le domaine pour trouver le serveur qui accepte le courrier pour lui, et le message est ensuite proposé à ce serveur. Sans un enregistrement de domaine nommant un serveur récepteur, le message n’a nulle part où aller.
Cette séparation est aussi là où commence le conseil pratique : validez le domaine strictement, car se tromper signifie du courrier qui ne pourra jamais être livré, et soyez indulgent avec la partie locale, car être strict à cet endroit ne fait que rejeter des adresses qui auraient fonctionné.
Quelle longueur une adresse peut-elle atteindre ?
La norme publique fixe des limites sur les deux moitiés et sur le total. Ce sont des nombres d’octets, pas des nombres de caractères, ce qui compte dès que des caractères non ASCII sont en jeu.
| Partie | Limite standard |
|---|---|
| Partie locale | 64 octets |
| Domaine | 255 octets |
| Adresse entière, chevrons compris | 256 octets |
Une convention d’ingénierie bien connue est encore plus étroite : de nombreux services limitent l’adresse entière à environ 254 caractères, car ce chiffre tombe juste quand on tient compte de la syntaxe autour d’une adresse. Cette convention n’est pas la norme, et la traiter comme telle est la façon dont une colonne de base de données finit un caractère trop courte pour une adresse légitime.
La leçon pour quiconque conçoit un formulaire ou une table est de dimensionner les champs selon la norme et de stocker les octets que vous avez réellement reçus. Tronquer une adresse en silence est pire que de la refuser, car le compte créé ne pourra jamais rien recevoir.
Ce que la norme permet mais que la plupart des services rejettent
La syntaxe est bien plus permissive que le courrier que la plupart des gens reçoivent. Parmi les formes que la norme autorise figurent une partie locale écrite entre guillemets, des commentaires entre parenthèses, un domaine écrit comme une adresse entre crochets plutôt qu’un nom, et — selon les extensions d’internationalisation — des caractères non ASCII dans l’une ou l’autre moitié.
Très peu de services acceptent tout cela. Beaucoup rejettent d’emblée les parties locales entre guillemets, la plupart ignorent les commentaires, et la prise en charge d’un domaine entre crochets est rare. Les adresses non ASCII existent et fonctionnent dans certains environnements, mais presque tout service grand public se comporte comme si la forme ASCII était la seule.
La conclusion à retenir pour votre propre code est précise : une vérification de syntaxe n’est pas une affirmation sur le monde. La réussir signifie que l’adresse est bien formée. Cela ne signifie pas qu’un service l’acceptera, et cela ne signifie pas que le compte derrière elle existe.
Pourquoi une adresse valide est-elle quand même refusée ?
Trois raisons, aucune liée à la syntaxe.
La première est que le domaine peut ne pas accepter de courrier du tout. Une adresse syntaxiquement parfaite sur un domaine sans serveur récepteur, ou dont le serveur refuse tout le courrier, est non livrable. C’est exactement le cas qu’une boîte jetable est conçue pour éviter : l’outil de courrier temporaire vous donne une adresse sur un domaine qui accepte du courrier à l’instant même, si bien que le chemin de livraison est la partie que vous n’avez pas à organiser.
La deuxième est une règle propre à un service. Un produit peut restreindre les domaines qu’il accepte, ou les caractères qu’il autorise dans un nom d’utilisateur, pour des raisons qui n’ont rien à voir avec la norme. Ces restrictions sont de la politique, et elles devraient être décrites comme telles plutôt que déguisées en validation.
La troisième est la gestion de la casse et des espaces. La moitié du domaine est insensible à la casse ; la partie locale y est techniquement sensible, même si en pratique presque rien ne distingue la casse à cet endroit. Un espace de début ou de fin collé depuis un document est une cause fréquente de refus qui ressemble à une erreur de syntaxe, et cela vaut la peine de le supprimer avant la validation plutôt qu’après.
Créer des adresses que les services acceptent
Quand vous avez besoin d’une adresse qu’un produit quelconque acceptera sans discuter, la forme la plus sûre est la plus banale : des lettres et des chiffres ordinaires avant l’arobase, un domaine conventionnel après, pas de guillemets, pas de commentaires, pas de domaine entre crochets, pas de ponctuation exotique. Cette forme passe essentiellement tous les validateurs en usage.
La page de courrier temporaire produit des adresses exactement de ce genre, et vous pouvez choisir vous-même un préfixe quand un formulaire refuse des étiquettes trop courtes ou qui semblent générées automatiquement. Comme l’adresse est créée pour vous plutôt qu’enregistrée, le courrier qui arrive appartient à la démarche que vous avez lancée, et la boîte peut être abandonnée ensuite. Si vous hésitez entre cela et un arrangement plus durable, courrier temporaire contre alias expose la différence.
Tout ce qui est abordé ici décrit la forme d’une adresse, pas une personne. Aucune adresse, quelle qu’elle soit, ne devrait être traitée comme une vraie identité, et une adresse syntaxiquement correcte ne vous dit rien sur qui, le cas échéant, se trouve derrière.
Pour les développeurs : validation, largeur des champs et casse
Trois habitudes préviennent la plupart des défauts de traitement d’adresses.
Rendez la validation permissive et par couches. Vérifiez qu’il y a exactement une arobase hors citation, que les deux moitiés sont non vides, et que le domaine a la structure qu’un domaine doit avoir. Résistez à la tentation de rejeter quoi que ce soit d’autre, car les formes exotiques que vous rejetez peuvent être exactement les adresses que l’on vous a demandé d’accepter. Si un service avec lequel vous vous intégrez a des règles plus étroites, appliquez ces règles à la frontière d’intégration et dites-le dans le message d’erreur.
Dimensionnez le stockage selon la norme. Donnez à la partie locale assez de place pour 64 octets, au domaine assez pour 255, et au champ entier assez pour 256, ponctuation comprise. Testez délibérément la limite avec une longue partie locale, car l’entrée trop longue est le cas qui tronque en silence.
Normalisez délibérément, et documentez ce que vous normalisez. Supprimer les espaces et mettre le domaine en minuscules sont des opérations sûres et attendues. Mettre la partie locale en minuscules est courant mais constitue techniquement une modification de l’adresse, donc faites-en une décision que vous pouvez assumer plutôt qu’un accident d’une fonction utilitaire.
Séparez ensuite les deux questions dans vos tests : cette adresse est-elle bien formée, et est-elle livrable ? Une seule assertion couvrant les deux finira par se tromper sur l’une d’elles. L’article sur les tests de parcours de vérification couvre ce qu’il faut faire une fois qu’une adresse passe le premier contrôle et que le courrier doit réellement arriver.
Étapes suivantes
Prenez la colonne d’adresses de votre produit et mesurez-la par rapport au tableau ci-dessus ; si elle est dimensionnée selon la convention plutôt que selon la norme, élargissez-la avant que l’adresse de quelqu’un soit tronquée à l’inscription. Ouvrez ensuite la page de courrier temporaire et générez une adresse à la forme banale, afin de voir ce que votre validateur fait d’une entrée qui est sans ambiguïté acceptable.