L’accès à la rencontre, qui est financée par le Fonds National de la Recherche Scientifique, est gratuit. Elle s’adresse tant aux concepteurs qu’aux utilisateurs de données issus des mondes scientifiques et industriels.

Deux membres de la « section Recherche » de Smals et, en particulier, de son Centre de Compétence en Qualité de données, y présenteront une intervention.

On trouvera le formulaire d’inscription, les modalités pratiques ainsi qu’une présentation détaillée des exposés et intervenants sur le site web de l’ULB via le lien suivant : programme détaillé et inscription. Les inscriptions seront clôturées le 23 janvier 2014.

Le FNRS insiste sur le caractère pluridisciplinaire du groupe en le mentionnant simultanément sur son site web dans les catégories suivantes : sciences appliquées et sciences humaines et politiques.

Après un bref rappel historique de vingt ans de recherches en matière d’évaluation et d’amélioration de la qualité des bases de données, en particulier au sein de l’egovernment, la rencontre se poursuivra par un exposé sur un thème d’actualité aux enjeux stratégiques : la qualité des adresses e-mail. La réunion se terminera par une table ronde au cours de laquelle tous les participants qui le souhaitent seront invités à intervenir et sera suivie d’une réception.

Programme :

13h30 Café et accueil des participants

14h00 Mot d’accueil par Seth van Hooland, Chargé de cours à l’ULB et Président du Master en Sciences et Technologies de l’Information et de la Communication (MaSTIC)

14h10 « Du stemma codicum au data tracking » : vingt ans de recherche en matière d’évaluation et d’amélioration de la qualité des bases de données, par Isabelle Boydens, Présidente du groupe de contact FNRS « Analyse critique et amélioration de la qualité de l’information numérique », Professeur ordinaire à l’ULB et responsable du « Data Quality Competence Center » au sein du département Recherche de Smals

14h45 Email Address Reliability, par Vandy Berten, Maître de Conférence à l’ULB et ICT Researcher chez Smals

16h15 Débat et table ronde. Modérateur : Anthony Cleve, Secrétaire du groupe de contact FNRS « Analyse critique et amélioration de la qualité de l’information numérique », Professeur à la Faculté d’Informatique de l’Université de Namur et Chargé de cours au sein du MaSTIC de l’ULB

16h45 Réception

Mis à part les aspects techniques qui suivront, il sera également nécessaire de s’interroger sur les questions éthiques liées au suivi d’un e-mail. La frontière entre les techniques permettant d’améliorer la qualité d’une base de données et celles portant atteinte à la vie privée des gens est floue et sans doute facile à franchir. Nous ne présentons dans cet articleque les considérations purement technologiques, et laissons au lecteur le soin d’évaluer si, dans son cas particulier, il a lieu de s’assurer qu’un e-mail a bien été lu.

Il existe principalement trois façons de vérifier la consultation. La première consiste à utiliser, dans un logiciel tel qu’Outlook, Eudora ou Thunderbird, l’option « Accusé de réception ». En fonction de la configuration du logiciel de lecture d’e-mail du destinataire, un e-mail de confirmation sera ou non renvoyé. L’inconvénient de cette solution est son manque de standardisation : une demande d’accusé de réception d’Outlook ne marchera  vraisemblablement pas chez Eudora, et encore moins si le destinataire utilise un « webmail » tel que Gmail ou Hotmail. Cette méthode n’est en général pas utilisée par les solutions d’envoi automatique.

La seconde solution consiste à intégrer dans le texte de l’e-mail un lien à cliquer (ou URL), que ce soit pour accéder à la suite du message, ou pour se connecter à un service. Ce lien, unique et spécifique au destinataire,  ne conduira pas directement vers la page de destination, mais vers une page intermédiaire, qui pourra enregistrer le fait que ce lien a été cliqué, avant de rediriger automatiquement l’utilisateur vers la bonne page.

La troisième technique utilise le langage « HTML », principalement utilisé pour la mise en page des sites Web, pour intégrer une image unique, spécifique à cet envoi, souvent invisible, mais dont la source se trouve sur un serveur dédié, qui peut enregistrer le fait que l’image a été téléchargée.

Nous allons maintenant présenter les deux dernières techniques, en mettant en avant leurs avantages, inconvénients, faiblesses et incertitudes.

Redirection de liens

L’adresse d’une page web sur un site dynamique peut contenir des paramètres. Ils suivent en général un « ? », et sont une succession de couples « attribut=valeur » séparés par des « & ». Supposons que dans un e-mail, on place une icône ou texte avec un hyperlien vers l’adresse :

http://mysite.com/track?mail=albert@gmail.com&dest=www.smals.be

Il sera alors très facile, sur le site mysite.com, d’enregistrer le fait que albert@gmail.com a cliqué sur le lien (on suppose qu’Albert est le seul à avoir reçu ce lien), et de le rediriger automatiquement vers www.smals.be, sans même qu’il s’aperçoive qu’il est passé par une page intermédiaire. L’inconvénient de ce procédé est d’une part qu’il devient très évident que l’on tente de tracer cette adresse, et d’autre part qu’il est très facile, pour un utilisateur mal intentionné, de faire valider n’importe quelle adresse. De plus, si cela convient pour rediriger vers une adresse aussi simple que www.smals.be, des problèmes se poseront pour rediriger vers des adresses plus complexes. En effet, si l’adresse vers laquelle on veut rediriger contient elle-même des paramètres, ce système ne permet pas de faire la différence entre les paramètres de l’URL de base et celle de l’URL de redirection.

On utilise en général un algorithme, nommé Base64, qui permet de convertir une chaîne d’octets en une chaîne de caractères, compatible avec une URL (l’adresse d’une page web).  L’algorithme Base64 transforme chaque groupe de 3 caractères en un nouveau groupe de 4 caractères, parmi les suivants : A-Z, a-z, 0-9, +, /, =. La chaîne transformée est donc un tiers plus longue que la chaîne d’origine. Cet algorithme traduirait par exemple

« albert@gmail.com;www.smals.be/a_page »

en

« YWxiZXJ0QGdtYWkuY29tO3d3dy5zbWFscy5iZS9hX3BhZ2U=»

Ce qui pourrait nous donner comme adresse du lien :

http://mysite.com/track?YWxiZXJ0QGdtYWkuY29tO3d3dy5zbWFscy5iZS9hX3BhZ2U=

On aurait donc typiquement, dans le mail, le code HTML suivant :

La page générée pourrait sur mysite.com pourrait être la suivante :

qui redirige automatiquement vers la page www.smals.be/a_page.

Cela ne suffit pas encore à empêcher un utilisateur malveillant de valider une mauvaise adresse, ou de se faire rediriger vers un autre page. On peut, avant d’utiliser l’algorithme Base64, chiffrer le texte à inclure avec une clé secrète.

Quelques remarques sur cette technique :

• Dans l’exemple ci-dessus, le lien contient directement deux informations : une adresse e-mail, et une URL de redirection. On aurait également pu placer ces deux informations dans une base de données, et ne reprendre que l’identifiant dans le lien, ce qui aurait eu l’avantage de réduire la taille du lien, mais a l’inconvénient d’exiger de stocker plus d’information.
• Le lien permet de savoir qu’albert@gmail.com a cliqué sur un lien vers le site web de Smals, mais ne permet pas de savoir dans quel e-mail. En effet, si ce lien apparaît dans cinq e-mails différents qu’il a reçus, on ne saura pas lequel a été ouvert. Cependant, dans notre cas, ce qui nous intéresse, c’est de savoir que l’adresse e-mail albert@gmail.com est toujours active, et pas spécifiquement de savoir quels sont les e-mails qui ont été ouverts. Si le but est différent, il faudra rajouter un identifiant supplémentaire dans le lien.
• Si Albert fait suivre (ou « forwarde ») l’e-mail qu’il a reçu à sa sœur Marie-Célestine, et qu’elle clique sur le lien, ça sera toujours l’adresse d’Albert qui sera validée, même si elle le fait six mois après avoir reçu l’e-mail, et qu’entretemps Albert est passé chez un autre fournisseur. Bien que peu probable comme scénario, il montre que le mécanisme n’est pas infaillible.
• Cette technique ne marchera que si on rend presque indispensable de cliquer sur un lien. Il faut donc mettre en place des stratégies de marketing et de communication pour inciter les destinataires à ces actions. Ce peut être par exemple en ne plaçant dans l’e-mail qu’une accroche suivie d’un lien « lire la suite », ou en y incluant des liens vers des documents importants, voire obligatoires.
• Si l’URL de redirection (http://www.smals.be/a_page dans notre exemple) est relativement simple et apparaît clairement dans le texte, un utilisateur ne désirant pas se faire « traquer » pourra directement taper (ou copier-coller) l’adresse dans son navigateur, sans cliquer sur le lien.

Image avec identifiant unique

Il y a deux façons d’intégrer une image dans un e-mail. La première consiste à l’envoyer en pièce jointe, la seconde consiste à la laisser sur un serveur web, et à indiquer dans le code de l’e-mail son adresse. La première solution a l’inconvénient d’alourdir la taille des e-mails. La seconde a pour désavantage que l’affichage des images est souvent désactivé par défaut, pour éviter justement les techniques que nous décrivons ici. Les e-mails apparaissent alors dans une version purement textuelle, avec un message du type « Pour préserver votre confidentialité, les images distantes ne sont pas chargées. Cliquer ici pour afficher les images ».

Le principe consiste donc à inclure dans le code HTML de l’e-mail une image distante, qui sera différente pour chaque courrier envoyé (si l’on veut savoir que ce courrier précis a été consulté), ou à tout le moins, pour chaque destinataire (si l’on veut juste s’assurer qu’une adresse est toujours active). Le serveur web sur lequel se trouvera l’image pourra donc identifier quel est le courrier à l’origine du chargement, ce qui permettra de s’assurer que le message est bien ouvert, et donc que l’adresse est toujours active. Pour identifier l’image, ou pourra utiliser les mêmes techniques que ci-dessus, le nom de l’image contenant donc soit une version chiffrée de l’adresse e-mail, soit un identifiant dans une base de données.

Les outils de « tracking » du marché (voir ci-dessous pour plus de détails) incluent souvent une image qui n’affecte pas la mise en page, en général une image d’un pixel blanc. D’autres images peuvent aussi être incluses, mais n’ont pas besoin d’être identifiables.

À nouveau, il faudra mettre en place des stratégies de marketing et de communication pour encourager les destinataires à accepter l’affichage des images. Rendre les e-mails quasiment illisibles sans image pourrait avoir l’effet inverse, et inciter le lecteur à considérer le message comme une publicité inutile et non sollicité, et à l’envoyer directement dans sa corbeille. L’idéal est d’envoyer tous les messages d’une plateforme avec le même expéditeur, ce qui permettra au destinataire d’autoriser l’affichage des images pour tous les messages provenant de cet expéditeur. Par ailleurs, on peut indiquer à l’utilisateur que s’il accepte les images, il ne sera pas nécessaire d’utiliser des techniques plus invasives, tels qu’un blocage de l’interface tant qu’un lien de confirmation envoyé par e-mail n’a pas été cliqué.

Comme dans la section précédente, si un utilisateur fait suivre le courrier, on ne pourra pas différencier l’ouverture du courrier original de celle du courrier transféré.

Remarquons que, à notre connaissance, l’affichage d’image distante ne compromet en rien la sécurité. Mises à part les pièces jointes infectées, le principal risque de contamination en ouvrant un e-mail est la présence de code JavaScript dans l’e-mail, qui est bloqué par la plupart des clients mails, tant webmail qu’applicatifs. On ne peut donc pas utiliser le JavaScript pour valider une adresse e-mail.

Par ailleurs, certains outils de « tracking » se servent de l’image incluse pour détecter où a été ouvert l’e-mail. En effet, lorsque l’image est téléchargée sur le serveur, celui peut obtenir l’adresse IP de la machine effectuant la requête, et, grâce à cette adresse, trouver l’origine géographique de l’ouverture. Si cette technique peut marcher avec de client mail « à la » Outlook, le résultat est plus aléatoire avec les webmails (Gmail, Hotmail, …). En effet, avec Gmail, c’est le navigateur qui télécharge lui-même l’image, et on peut donc le localiser. Avec Hotmail, par contre, ce sont les serveurs d’Hotmail qui téléchargent d’abord l’image, avant d’en envoyer une copie au navigateur. De ce fait-là, le serveur où se trouve l’image ne peut que localiser les serveurs d’Hotmail.

Dans cet article-ci, nous irons un cran plus loin : nous allons regarder comment il est (parfois) possible de vérifier qu’une adresse existe vraiment, c’est-à-dire qu’il existe bien un fournisseur de courrier électronique ayant un utilisateur au nom indiqué. Nous allons pour ce faire entrer dans certains détails d’un des protocoles utilisés pour l’envoi de courrier électronique : le protocole SMTP.

Serveur MX et protocole SMTP

Supposons que notre ami Albert veut ajouter sa sœur Marie-Célestine à son carnet d’adresses, mais il n’est plus sûr de son adresse : il s’agit soit de mariecelestine.leroy@gmail.com, soit de leroy.mariecelestine@gmail.com. La première chose à faire pour valider l’existence d’une adresse électronique (syntaxiquement correcte) est d’en extraire son nom de domaine, puis d’identifier, grâce au service DNS, le nom du serveur responsable des adresses de ce domaine. Ceci peut se faire facilement à l’aide d’une fenêtre DOS sous Windows, ou d’un terminal sous Linux ou Mac OS. Pour identifier, dans notre exemple, le serveur responsable des adresses « gmail.com », on utilisera pour ce faire la commande « nslookup -q=mx gmail.com » (pour Name Server Lookup), qui produira typiquement comme résultat :

Ceci nous indique qu’il faut maintenant s’adresser au serveur de mail répondant au nom de gmail-smtp-in.l.google.com (les autres étant à utiliser lorsque le premier ne répond pas). On parle aussi de serveur MX, pour Mail eXchange.

Il est aussi possible de recevoir un message d’erreur en tapant cette commande. Cela peut principalement vouloir dire deux choses : soit le nom de domaine n’existe pas ; soit il existe, mais ne gère pas de courrier électronique. On pourrait par exemple avoir qu’il existe un site web www.mapetitesociete.be, mais qu’il n’existe pas d’adresse @mapetitesociete.be. Si une telle erreur s’est produite, ça ne sert à rien d’aller plus loin : l’adresse recherchée n’existe par définition pas.

S’il n’y a pas eu d’erreur, on peut maintenant « parler » à ce serveur, grâce au protocole « SMTP » (Simple Mail Transfer Protocol). Ce protocole est en fait le langage qu’utilisera un programme tel que Outlook, Thunderbird, Mail, ou le programme de gestion de courrier électronique de votre smartphone. Toujours dans la même fenêtre de commande, à l’aide du programme « telnet », Albert fait « comme si » il était un de ces logiciels et qu’il voulait envoyer un courrier, et effectue les manœuvres suivantes (en rouge, les commandes qu’il tape) :

Suivant le protocole SMTP, il commence par se « présenter » : il dit quel nom de domaine il gère (commande « EHLO »), puis indique quel est l’expéditeur du courrier (commande « MAIL FROM: »), bien que dans notre cas, aucun courrier ne sera réellement envoyé.

On y voit qu’à la première commande « RCPT TO », la réponse du serveur commence par 550, code indiquant que l’adresse n’existe pas. Un message plus verbeux l’explicite ensuite. Par contre, lors de la seconde invocation de la commande, la réponse débute par 250, code indiquant que tout s’est bien passé, et que la seconde adresse introduite existe bel et bien (il s’agit d’un exemple fictif)

En principe, pour réellement envoyer un courriel, il aurait fallu, à la place du « QUIT », introduire le contenu (sujet, corps du texte, pièces jointes, …). Le but de notre ami Albert étant simplement de vérifier l’existence d’une adresse et non d’envoyer un courrier, il s’arrête là et rien n’est envoyé à la destination.

Remarquons que le texte qui suit le code « 550 » est typiquement ce que l’on va retrouver dans un retour de mail suite à un envoi erroné à une adresse inexistante. Ces mails d’erreur sont généralement appelés  « bounce mail ». On en distingue deux catégories : les  « hards », qui représentent des problèmes définitifs (adresse inexistante, nom de domaine non valable…), et les  « softs », pour les problèmes temporaires (boîte pleine, serveur temporairement indisponible…)

Difficultés

Malheureusement, si l’exemple précédent marche très bien pour vérifier les adresses de Gmail, ce n’est pas toujours aussi facile, et ce pour de nombreuses raisons. Il faut d’abord savoir que le protocole SMTP est très ancien : il date du début des années ’80, soit bien avant l’invention du web ! À cette époque, les problèmes de sécurité et de spams n’étaient pas ce qu’ils sont aujourd’hui, et ils n’ont que très peu été pris en compte. Cependant, ce protocole est tellement répandu qu’il est très difficile d’imposer un nouveau standard qui comblerait ses lacunes. De nombreux gestionnaires ont dès lors choisi de faire évoluer leurs serveurs de façon non standard, entraînant des comportements très différents et difficiles à interpréter. Quelques explications :

• Dans l’exemple ci-dessus, l’expéditeur mentionné utilise un nom de domaine qui n’existe pas (bxl.mapetitesociete.be), sans que ça ne pose le moindre problème aux serveurs de Gmail. En fait, dans la plupart des cas, on peut envoyer un courriel avec n’importe quel expéditeur, sans le moindre contrôle. Certains serveurs font cependant plus de vérifications.
• En temps normal, un programme d’envoi de mail ne contacte pas directement le serveur « SMTP » de la destination : il contacte typiquement le serveur SMTP de son FAI (fournisseur d’accès à Internet, tel que belgacom, telenet, …), de son entreprise ou de son université, qui contacte lui-même le serveur de la destination. De la même façon que si je veux envoyer une lettre dans une ville voisine, je ne dois pas la déposer dans une boîte de la ville de destination, mais bien de ma ville, et c’est la poste qui se chargera de l’acheminement. Certains serveurs vérifient que la machine à l’origine de la requête est soit un de ses membres (client d’un FAI, machine au sein de l’entreprise, …), soit qu’elle vient d’un autre serveur SMTP, et pas d’une machine « lambda ». Si Gmail effectuait ce test, la requête ci-dessus ne marcherait donc pas. Selon nos tests, un petit quart des serveurs de mail effectuent ces vérifications supplémentaires.
• Dans le cas où le serveur de mail n’a pas confiance en l’expéditeur, certains l’annoncent clairement par un message d’erreur, d’autres acceptent toutes les adresses comme si elles existaient, sans message d’erreur. C’est par exemple le cas des serveurs de Yahoo. Pour savoir si on est dans ce cas, il suffit en général de vérifier une ou plusieurs adresses aléatoires et très longues, avec le même nom de domaine : si elles sont toutes acceptées, c’est probablement que le serveur accepte tout. Il ne sera dès lors pas possible de vérifier des adresses.
• Les codes d’erreurs, pourtant standard, ne sont pas utilisés de façon universelle. Par exemple, bien que le code « 550 » soit défini par les standards comme l’erreur d’une boîte inexistante, il est parfois également utilisé pour signifier que la requête est refusée pour des raisons évoquées plus haut, ou que la boîte est pleine. Le message qui suit peut aider à savoir dans quelle situation l’on se trouve, mais il est dès lors difficile d’automatiser la chose avec un haut niveau de fiabilité pour de grandes listes d’adresses.
• Si l’on veut vérifier massivement des adresses, il faut être prudent. En effet, certains serveurs n’aiment pas ces vérifications, et vont bloquer (ou blacklister) l’expéditeur, entre quelques minutes et quelques heures. Il s’agit en effet d’une technique de spammeur, pour trouver des adresses existantes.

Outils

Dans la pratique, il n’est pas nécessaire de faire ces manipulations pour vérifier l’existence d’une adresse, car il existe des outils qui le font à votre place, avec plus ou moins de succès : http://verify-email.org/, http://www.verifyemailaddress.org/, http://www.ip-tracker.org/, http://bulkemailverifier.com/, http://tools.email-checker.com/, …

Cependant, pour une adresse erronée de chez Yahoo, le premier indique qu’elle n’existe pas, les deux suivants qu’elle existe, et les derniers sont incapables de répondre… Manifestement, la majorité de ces outils effectuent leurs tests à partir de machines qui ne sont pas des serveurs de mail, et donc à qui d’autres serveurs de mail un peu suspicieux ne font pas confiance.

La suite

On a pu, grâce à l’article précédent, déterminer qu’une adresse était « grammaticalement » correcte. Avec cet article-ci, on peut s’assurer que le nom de domaine est correct, et, avec un degré de certitude variable, que l’adresse existe bien. On n’a jusqu’ici pas vérifié que quelqu’un relevait effectivement le courrier dans cette boîte. Dans certains cas, on pourra s’en assurer. La suite au prochain numéro …

Il existe des méthodes qui permettent de maintenir à jour une base de données d’adresses électroniques autant que faire se peut. Il existe également des techniques permettant, lorsqu’une personne renseigne une adresse électronique, d’en vérifier la validité. On peut également mettre en place des stratégies permettant de s’assurer qu’une « boite aux lettres » électronique est toujours consultée. Ces méthodes feront l’objet de blogs ultérieurs. Malheureusement, de nombreuses sociétés et organismes possèdent des listes d’adresses qui n’ont jamais fait l’objet des plus simples vérifications. Jusqu’à présent en effet, l’adresse électronique d’un client ou d’un citoyen était considérée comme une information accessoire et sans intérêt, un peu comme l’a souvent été le fax. Encore aujourd’hui, nombreuses sont les personnes qui doivent fournir un numéro de fax à des sociétés qui n’ont même plus l’appareil pour en envoyer … Mais de nos jours, on se rend compte qu’avoir des listes d’adresses électroniques de mauvaise qualité coûte beaucoup d’argent, et nuit tant à la crédibilité qu’à l’efficacité. Il faut donc nettoyer un lourd passé. Ce premier article propose quelques pistes permettant de nettoyer un tel listing.

Décomposition d’une adresse

Une adresse électronique est composée de plusieurs éléments. Prenons comme exemple l’adresse (fictive)

albert.leroy@bxl.mapetitesociete.be

Cette adresse est composée principalement de trois éléments :

1. Un « nom d’utilisateur » (ou username) : « albert.leroy » ;

2. Un « nom de domaine », qui décrit la société qui fournit l’adresse électronique : « bxl.mapetitesociete.be » ;

3. Un « nom de domaine de premier niveau » (ou Top Level Domain, que nous dénommerons TLD), qui est la partie la plus à droite du nom de domaine, avec le dernier point : « .be ».

Nous allons maintenant parcourir ces éléments dans l’ordre inverse, pour en mettre en avant les difficultés. Mais dans un premier temps, intéressons-nous à quelques considérations que l’on pourrait qualifier de grammaticales.

Vérification syntaxique

La première chose à faire afin de s’assurer de l’exactitude d’une adresse électronique est d’en vérifier sa syntaxe, ou son format. Par analogie, la syntaxe d’un code postal belge précise qu’il doit être composé de quatre chiffres. Mais, bien entendu, tout code respectant la syntaxe n’est pas pour autant un code postal : « 1234 » respecte bien la syntaxe d’un code postal, mais ne désigne aucune ville. Il en va de même pour les adresses électroniques, avec, bien évidemment, une syntaxe de loin plus complexe.

Dans la réalité, la plupart des systèmes acceptant des adresses électroniques ne font soit aucun test syntaxique, soit en font mais sont trop permissifs (c’est-à-dire qu’ils acceptent des adresses syntaxiquement incorrectes), ou, au contraire, trop contraignants (c’est-à-dire qu’ils refusent des adresses correctes). C’est que vérifier la syntaxe des adresses est bien plus complexe que ce qu’il n’y parait …

Il faut certes qu’il y ait un « @ » (arobase), qu’il n’y ait pas d’espace et qu’il y ait au moins un point dans le nom de domaine. On serait étonné du nombre de personnes, qui, par distraction ou intentionnellement, encodent un numéro de téléphone, une adresse postale ou un site web dans le champ destiné aux adresses électroniques.

Syntaxe du nom de domaine

Si l’adresse contient effectivement un @, on peut ensuite vérifier la syntaxe du nom de domaine. Dans la pratique, aujourd’hui et dans la plupart des cas, les noms de domaine peuvent contenir des caractères latins simples (non accentués, sans cédilles, … en d’autres termes, sans signe diacritique), peu importe la casse (majuscule ou minuscule), des chiffres, des tirets, ou des points. Avec quelques contraintes supplémentaires : le tiret, comme le point, doivent toujours être entourés de caractères ou de chiffres de part et d’autre, et ne peuvent ni débuter, ni terminer le nom de domaine, ni, par conséquent, être consécutifs.

Mais les choses ne vont plus rester simples longtemps. En effet, les caractères plus génériques sont officiellement acceptés, et commencent à se répandre. Par exemple, en Belgique, depuis juin 2013, des noms de domaines accentués sont acceptés pour les adresses « .be ». C’est ce qu’on appelle les « Internationalized Domain Name », ou IDN, et que chaque pays doit approuver. La France l’a également fait, mais pas les Pays-Bas. Et pour ne pas faire les choses simplement, la liste des caractères acceptés n’est pas la même dans tous les pays : les noms de domaines « .be », acceptent par exemple les caractères þ, ð et ø (Thorn, Eth et le o barré, empruntés à des alphabets scandinaves), ce qui n’est pas le cas de noms en « .fr ».

Cependant, outre des problèmes de sécurité, il est peu probable que les sociétés migrent totalement leur nom de domaine vers des domaines accentués, au risque de se voir refuser l’accès à bien des services qui ne seraient pas encore « compatibles IDN ». On peut donc imaginer que l’adresse albert.leroy@bxl.mapetitesociete.be co-existera avec albert.leroy@bxl.mapetitesociété.be pendant encore un moment, en étant synonyme l’une de l’autre.

Syntaxe du nom d’utilisateur

Si la vérification syntaxique d’un nom de domaine risque d’être compliquée à l’avenir, c’est déjà le cas pour la vérification du nom d’utilisateur. En effet, il existe des standards internationaux décrivant le format de la première partie d’une adresse électronique, mais les principaux fournisseurs (yahoo, gmail, hotmail, …) ne les respectent pas. Par exemple, les standards précisent une longue liste de caractères à accepter, dont les caractères accentués, mais aussi des caractères tels que « # », « $ », « * », « / », « ! »… Cependant, la plupart des fournisseurs ne les acceptent pas.

Hotmail, Belgacom ou Telenet n’acceptent que les caractères latins simples (non-accentués), les chiffres, le point, le tiret et le tiret bas. Yahoo y rajoute la contrainte que le nom d’utilisateur ne peut contenir qu’un seul point. Par ailleurs, Yahoo n’accepte plus le tiret aujourd’hui, alors que c’était le cas par le passé. Ses adresses doivent de plus contenir entre 4 et 32 caractères.

Gmail a décidé de pousser le non-conformisme encore plus loin. Les tirets et tirets bas ne sont pas acceptés, et les points sont acceptés, mais ignorés. En d’autres termes, l’adresse albert.leroy@gmail.com est un synonyme de albertleroy@gmail.com. Par ailleurs, le « + » permet d’insérer des commentaires : albert.leroy+blahblah@gmail.com est également synonyme des deux précédentes. De plus, les adresses Gmail doivent contenir entre 6 et 30 caractères, sans compter les points, ni ce qui suit un « + ».

Notre expérience a montré que de nombreuses adresses ont pu être invalidées à partir de listing sur base de critères spécifiques au nom de domaine, alors que des critères plus généralistes les avait acceptées.

Validation du « Top Level Domain »

Vérifier l’existence du nom de domaine de premier niveau (TLD), tel que « .be », « .com », ou « .travel » était jusqu’il y a peu relativement simple (et ça l’est encore dans beaucoup de cas). Il n’existait que plus ou moins 280 TLD, dont la liste, gérée par l’IANA est disponible en ligne et était relativement statique. Elle ne contenait par ailleurs que des caractères latins simples, sans accents, et pas de chiffres.

Mais deux nouvelles tendances vont prochainement changer la donne, comme c’est le cas pour les noms de domaines.

Premièrement, il existe aujourd’hui un certain nombre de nouveaux TLD « exotiques », contenant des caractères non-occidentaux : .中國 pour la Chine, .சிங்கப்பூர் pour Singapour, ou encore الجزائر. en Algérie. Remarquez la présence du point à la fin du TLD, puisque l’arabe s’écrit de droite à gauche.

Par ailleurs, la généralisation des TLD (« generic Top Level Domain ») permettra dans le futur d’avoir un TLD plus personnalisé. On attend les TLD « .brussels » et « .vlaanderen » pour l’été 2014. On pourra donc prochainement voir apparaître une adresse de la forme albert.leroy@mapetitesociété.brussels. Il ne sera donc plus possible de consulter une simple liste pour valider le TLD …

Validation du nom de domaine

Il ne suffit pas à un prétendu nom de domaine d’être syntaxiquement correct et de contenir un TLD valide pour en être pour autant valide. Le nom de domaine bxl.mapetitesociete.be, par exemple, n’existe pas. Malheureusement, il n’est pas possible de gérer une liste de noms de domaines existants et de les comparer avec celui d’une adresse. Rien que pour le TLD « .be », il y a eu, en moyenne en 2012, plus de 1300 changements par jour, incluant nouveaux noms et disparitions, sur un total de 1.300.000. Fin 2012, on a enregistré quotidiennement en moyenne et au niveau mondial plus de 65.000 nouveaux noms de domaine, pour un total de 250 millions !

La seule façon de le savoir est d’interroger les annuaires d’Internet, que l’on nomme Domain Name Servers, ou DNS. C’est le mécanisme qui permet de taper «http://www.google.be/ » plutôt que « http://173.194.77.94 », autrement moins convivial. Mais c’est aussi le mécanisme qui permet, au travers d’une requête dite « MX » (pour Mail eXchange), d’indiquer le serveur de mail qui gère les adresses d’un nom de domaine particulier. Par exemple, il nous indiquera que les adresses « @smals.be » sont gérées par un serveur nommé « mailgater.smals.be », ou que le serveur «gmail-smtp-in.l.google.com » gère les courriels à destination des adresses « @gmail.com ». Ces vérifications peuvent être faites soit automatiquement au travers d’un programme spécialisé, soit à la main, avec un outil tel que http://mxtoolbox.com/.

La suite

Une fois que l’on sait qu’une adresse est syntaxiquement correcte et que son nom de domaine (incluant le TLD) existe et gère bien des adresses électroniques, il reste encore deux étapes. Premièrement, on peut s’assurer qu’il existe bien une boite aux lettres correspondant au nom d’utilisateur. Il se peut que, soit une adresse ait mal été renseignée, soit elle n’existe plus, la personne ayant changé de fournisseur ou de travail.

Mais il ne suffit pas qu’une adresse soit totalement valide pour qu’un courrier arrive bien à destination ; il faut encore que quelqu’un y relève le courrier !

Plus de détails sur ces derniers éléments dans le prochain numéro …