Vérifier une adresse e-mail : un problème facile ? Partie II

mailNous avons vu dans l’article précédent comment vérifier qu’une adresse électronique était susceptible d’exister, en en vérifiant la syntaxe, ou, autrement dit, qu’elle était grammaticalement correcte. Nous y avons montré que, pour faire les choses le plus précisément possible, et donc éliminer d’entrée de jeu un maximum d’adresses erronées, la problématique était bien plus complexe qu’imaginée généralement. Bien sûr, dans un système bien conçu, chaque adresse introduite par un utilisateur dans la base de données engendre l’envoi d’un courriel contenant un lien de confirmation. Dans ce cas, il n’est pas nécessaire d’être très rigoureux sur la vérification syntaxique, puisque par définition, une adresse mal formée ne passera pas l’étape de la confirmation. Mais on a souvent à faire à des listings contenant des grandes quantités d’adresses qui n’ont jamais passé ne fût-ce que le plus élémentaire des tests syntaxiques.

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 :

C:\>nslookup -q=mx gmail.com
[…] Non-authoritative answer:
gmail.com mail exchanger = 5 gmail-smtp-in.l.google.com.
gmail.com mail exchanger = 10 alt1.gmail-smtp-in.l.google.com.
gmail.com mail exchanger = 20 alt2.gmail-smtp-in.l.google.com.
[…]

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) :

C:\>telnet gmail-smtp-in.l.google.com. 25
Trying 173.194.78.26…
Connected to gmail-smtp-in.l.google.com.
[…] EHLO bxl.mapetitesociete.be
250-mx.google.com at your service, [91.183.59.xxx] […] MAIL FROM:<albert.leroy@bxl.mapetitesociete.be>
250 2.1.0 OK pn9si600796wjc.42 – gsmtp
RCPT TO:<leroy.mariecelestine@gmail.com>
550-5.1.1 The email account that you tried to reach does not exist.
[…] RCPT TO:<mariecelestine.leroy@gmail.com>
250 2.1.5 OK pn9si600796wjc.42 – gsmtp
QUIT
221 2.0.0 closing connection pn9si600796wjc.42 – gsmtp

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 …

This entry was posted in E-gov and tagged , by Vandy Berten. Bookmark the permalink.
avatar

About Vandy Berten

Consultant Recherche chez Smals depuis mai 2013. Vandy était auparavant Professeur Assistant à l'ULB, où il enseignait les langages de programmation. Il a obtenu une thèse de doctorat dans la même institution en 2007. Il a été d'octobre 2015 à septembre 2018 chargé du cours de "Visualisation des données et de l'information", à l'ULB. Depuis quelques années, s'est spécialisé dans les techniques de Data Science, incluant le "(social) network analytics", le "data quality", le "machine learning", en particulier dans le domaine de la détection de la fraude.

2 thoughts on “Vérifier une adresse e-mail : un problème facile ? Partie II

  1. merci pour ce second épisode, vous avez l’art du feuilleton! j’attends impatiemment le prochain épisode.
    Vous semblez être en train de répondre que la question que vous posez n’a pas de solution, ou du moins, pas de solution satisfaisante (à moins que vous ne sortiez un lapin de votre chapeau en ccl?) mais vous avez, sans doute volontairement, posé la question en termes très généraux, de sorte que, implicitement, vous prenez la position d’un collecteur d’adresses en vue de spams ou pis encore. Dans ce cas, votre réponse négative est réjouissante et nous, les cibles, sommes un peu rassurés!
    Si la réponse reste négative, ne faut-il pas changer d’angle de vue et s’interroger sur la fonction de réaction des “clients”? quand je m’inscris sur un site de vente à distance, je fais attention au libellé de mon adresse parce que je veux suivre l’acheminement, pouvoir contacter le vendeur etc. Si les “clients” n’ont pas d’incitation (ou nécessité ou obligation sanctionnée) à donner leur adresse exacte, ça me paraît sans espoir…

    • À ma connaissance, il n’y a pas de solution 100% fiable pour s’assurer qu’un e-mail existe toujours. Même l’envoi d’un e-mail avec un lien à cliquer ne permet jamais de valider que ceux qui prennent la peine de le faire. Ceci dit, avec des moyens accessibles à beaucoup (création d’un serveur de mail, enregistrement adéquats dans les serveurs DNS, …), on peut arriver à un taux de fiabilité élevé (qui va bien évidemment dépendre du profil des adresses ; si l’on n’a que des adresses chez Gmail, on pourra toutes les valider).
      Mais on ne pourra jamais maintenir une bases de données d’adresses un minimum à jour si l’utilisateur n’a pas un intérêt (financier ou autre) à donner une adresse correcte, et à la mettre à jour, même en utilisant les meilleures techniques …

Leave a Reply to besson Cancel reply

Your email address will not be published. Required fields are marked *