Il arrive parfois que l'envoi d'un e-mail entraîne un échec d'envoi ou de non réception. du message. Bien comprendre à quel des deux cas nous sommes confrontés n'est pas aisé précisément, car dans les deux cas il est difficile d'établir si nous sommes confrontés à un défaut d'envoi ou à un défaut de réception et nécessite des investigations d'un niveau technique pas toujours possible par le 'utilisateur final.
A qui la faute alors ? L'expéditeur ou le destinataire ?
Il est à noter que l'envoi d'un e-mail et sa réception impliquent une série d'opérations « en coulisses » absolument non triviales qui déterminent sans conteste le succès ou l'échec de l'envoi et de la réception.
Bien que l'envoi d'un e-mail soit à la portée de tous, il est également vrai qu'il existe des milliers de serveurs de messagerie, chacun avec son propre logiciel et chacun avec sa propre configuration, qui peuvent parfois ne pas communiquer entre eux en raison de problèmes techniques et d'une configuration incorrecte.
Supposons un scénario réel
Lorsqu'un utilisateur avec email tizio@tizio.it par exemple, essayez d'envoyer un e-mail à caio@caio.it, voici ce qui se passe dans les coulisses :
- Le client de messagerie de Tizio se connecte au serveur de messagerie délégué pour gérer le courrier du domaine tizio.it, par exemple mail.tizio.it
- À son tour, une demande est faite au serveur de messagerie autoritaire qui écoute sur le port 25 et invité à envoyer un e-mail au destinataire caio@caio.it. Cette requête est faite suivant une syntaxe pour le protocole SMTP qui décrit brièvement, l'expéditeur (MAIL FROM), le destinataire (RCPT TO), le sujet (SUBJECT) et le corps du mail (DATA).
- Une fois la transmission de l'e-mail du client de messagerie au serveur de messagerie terminée, le serveur de messagerie (qui n'est rien de plus qu'un programme serveur qui écoute sur le port 25, utilisé pour recevoir et envoyer des e-mails) fait une requête à le DNS essayant d'obtenir l'enregistrement MX (Mail eXchanger) pour le domaine en question.
- Par exemple, le DNS du domaine caio.it répondra que le serveur de messagerie faisant autorité pour le domaine caio.it sera mail.caio.it
- Le serveur de messagerie mail.tizio.it se connectera alors au port 25 du serveur de messagerie mail.caio.it en établissant une connexion TCP et transférera le courrier qu'il avait dans la file d'attente qui lui a été envoyé par le client de messagerie (outlook ou thunderbird par exemple ) de l''utilisateur tizio@tizio.it
- À ce stade, le serveur de messagerie du destinataire mail.caio.it aura dans la file d'attente le courrier destiné à un utilisateur de son domaine (caio@caio.it) et devra en quelque sorte le livrer dans un fichier à l'intérieur d'un dossier sur le serveur , normalement au format Maildir ou Mailbox.
- À ce stade, le destinataire se connectera via son client de messagerie à un serveur de messagerie pop3 ou imap entrant qui est utilisé pour recevoir le message précédemment délivré par le serveur de messagerie.
C'est ce qui se passe en régime normal, c'est-à-dire sans vérifications antivirus et antispam spécifiques.
Jusqu'à présent, pour faire fonctionner ce mécanisme, vous avez besoin des conditions suivantes :
- 2 serveurs de messagerie entièrement fonctionnels, un pour l'expéditeur et un pour le destinataire
- Les informations sur l'hôte et l'IP sur les serveurs de messagerie sont publiées dans les entrées DNS (appelées zones) des domaines en question.
- Faire une requête DNS implique d'avoir un serveur DNS fonctionnel avec les informations correctes publiées, en particulier l'enregistrement MX
Configurations avancées avec contrôles de l'expéditeur et du contenu.
Dans une configuration avancée, vous devez également faire face à des contrôles supplémentaires, tels que :
Liste grise : refuse d'accepter l'e-mail de l'expéditeur pendant quelques minutes. Dans le cas d'un vrai serveur de messagerie et non d'un spammeur, il sera reporté. Dans le cas des robots de spam, il n'est souvent pas reporté, vous commencez donc à faire une sélection de bons et de mauvais courriers. Il en résulte un retard d'environ 10 à 15 minutes (mais même plus) du premier message d'un nouvel expéditeur pour le nouveau mois.
DNSBL : se produit si l'adresse IP d'un expéditeur est publiée dans les listes mondiales de spammeurs via des requêtes UDP (similaires à celles utilisées pour les requêtes DNS). S'il est présent, le message est rejeté et le serveur de messagerie expéditeur le renverra à l'expéditeur en précisant le motif du refus de livraison.
SPF : est un système de validation des e-mails conçu pour détecter les tentatives d'usurpation d'e-mail. Le système offre aux administrateurs d'un domaine de messagerie un mécanisme qui leur permet de définir les hôtes autorisés à envoyer des messages à partir de ce domaine, permettant au destinataire de vérifier leur validité. La liste des hébergeurs autorisés à envoyer des e-mails pour un domaine donné est publiée dans le Domain Name System (DNS) de ce domaine, sous la forme d'enregistrements TXT spécialement formatés. L'hameçonnage, et parfois même le spam, utilisent de fausses adresses d'expéditeur, de sorte que la publication et la vérification des enregistrements SPF peuvent être considérées en partie comme une technique anti-spam.
DKIM : DomainKeys Identified Mail (DKIM) est une méthode d'authentification de courrier électronique conçue pour empêcher l'usurpation d'identité. Il permet au destinataire d'un e-mail de vérifier l'origine du message, afin de s'assurer de l'authenticité de l'expéditeur. DKIM est utilisé pour lutter contre le phishing et le spam par courrier électronique.
Sur le plan technique, DKIM permet à un domaine d'associer son nom à un email en y apposant une signature numérique. La vérification est effectuée à l'aide de la clé publique du signataire publiée dans le DNS du domaine. La signature garantit que le message électronique (y compris les pièces jointes) n'a pas été modifié depuis que la signature a été placée. Habituellement, les signatures DKIM ne sont pas visibles pour les utilisateurs car elles sont apposées ou vérifiées par les fournisseurs de services (SP). Pour cette raison, DKIM diffère du cryptage de bout en bout, qui n'implique pas d'interactions avec des tiers.
Antispam / Antivirus : en fonction du contenu, des mots-clés et des pièces jointes, le message sera noté. Dépassé un certain score (généralement 5), le message sera marqué comme SPAM et sera livré soit dans le dossier SPAM, soit dans un courrier normal avec le sujet du message changé en quelque chose comme [SPAM] Objet du message , ou *** SPAM *** Objet du message.
Dans ce cas, pour que le message soit reçu de l'adresse du destinataire, l'expéditeur doit assurez-vous que votre adresse IP de serveur de messagerie n'est pas répertoriée comme source de SPAM dans le DNSBL, doit avoir la prévoyance de suivre les règles standards de rédaction d'un email comme écrire l'objet, insérer un texte dans le corps du message, éviter d'envoyer des fichiers presque toujours interdits comme les exécutables (.exe,.com, .pif, .bat, etc..).
De plus, un concept doit être mis par écrit : lorsque l'email n'arrive pas ou n'est pas reçu, la faute peut être la nôtre comme elle peut être l'interlocuteur.
Si notre fournisseur ou client nous envoie un email depuis une adresse répertoriée dans DNSBL, c'est de sa faute s'il n'envoie pas en respectant les règles, et non de la nôtre que nous rejetons automatiquement le message car il s'agit de SPAM.
Il faut dire aussi que le courrier ce n'est pas un outil de communication en temps réel, la la livraison n'est pas garantie et que tout usage autre que celui pour lequel il a été conçu est un usage incorrect.
Chaque message d'erreur qu'il renvoie comporte un code d'identification ainsi qu'une description du problème.
En lisant ces informations, nous pouvons savoir sans aucun doute si le problème vient de nous ou de l'autre interlocuteur.
Il suffirait d'avoir l'envie et de prendre la peine de lire ces erreurs pour éviter de tâtonner dans le noir éviter les communications inappropriées avec le service d'assistance de l'entreprise.