Nous 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 [email protected], soit de [email protected]. 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 …