Problèmes d'envoi et de réception de mails. Guide de référence pour le diagnostic et la résolution.

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, par exemple tizio@tizio.it , tente d'envoyer un courriel à un autre utilisateur, tel que caio@caio.it , une série d'opérations techniques très spécifiques sont déclenchées en arrière-plan. Ces opérations sont régies par des protocoles standardisés et orchestrées par de multiples composants ; pourtant, pour l'utilisateur, cela apparaît comme une simple action d'envoi en un clic.

1. Le client de messagerie utilisé par tizio, qui peut être un logiciel comme Outlook, Thunderbird ou un webmail, se connecte au serveur de messagerie chargé de gérer les e-mails sortants pour le domaine tizio.it, par exemple mail.tizio.it. La connexion s'effectue généralement via le protocole SMTP, authentifié et sécurisé, en utilisant les ports 587 (soumission) ou 465 (smtps). Une fois la connexion établie, le client transmet au serveur toutes les informations nécessaires à la composition de l'email : expéditeur (MAIL FROM), destinataire (RCPT TO), des en-têtes tels que Subject, et enfin le corps du message (DATA), en suivant fidèlement la syntaxe fournie par le protocole SMTP.

2. Une fois le processus d'envoi terminé du client vers le serveur de messagerie expéditeur, ce dernier – qui est un logiciel à l'écoute sur le port 25, spécialisé dans la gestion et la transmission des emails – passe à la phase suivante : l'identification du serveur de messagerie de destination. Pour ce faire, effectuez une requête DNS (Domain Name System) en recherchant l'enregistrement MX (Mail Exchanger) du domaine du destinataire, dans ce cas caio.it. Cet enregistrement indique quel serveur est autorisé à recevoir du courrier pour ce domaine.

3. Le DNS du domaine caio.it répondra avec le nom du serveur de messagerie faisant autorité, par exemple mail.caio.it. Le serveur de messagerie expéditeur, donc mail.tizio.it, utilisera cette information pour établir une connexion TCP avec le port 25 de mail.caio.it. Une fois la connexion établie, le serveur tizio transférera le courriel en attente, précédemment reçu par le client de l'utilisateur tizio@tizio.it.

4. Le serveur de messagerie de destination, mail.caio.it, reçoit le message et le place dans la file d'attente des messages entrants. Durant cette phase, le serveur stocke le message sur le système de fichiers local, dans un format structuré qui peut être Maildir (basé sur des répertoires et des fichiers distincts pour chaque message) ou mbox (un seul fichier contenant tous les courriels). Le message est ensuite associé au compte caio@caio.it , prêt à être consulté par le destinataire.

5. Enfin, le destinataire – dans ce cas Caio – utilisera son propre client de messagerie pour accéder au message qu’il vient de recevoir. Cela se produit via un protocole de courrier entrant, POP3 ou IMAP, qui vous permet respectivement de télécharger le message sur votre appareil ou de le consulter tout en le laissant sur le serveur. Une fois la connexion au serveur de courrier entrant établie, le message sera lu et mis à disposition de l'utilisateur.

C'est ce qui se passe en régime normal, c'est-à-dire sans contrôles spécifiques anti-virus et anti-spam.

Jusqu'à présent, pour que tout ce mécanisme fonctionne, les conditions suivantes sont nécessaires :

• 2 serveurs de messagerie entièrement fonctionnels, un pour l'expéditeur et un pour le destinataire

• Les informations d'hôte et d'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 gérer des contrôles supplémentaires, implémentés côté serveur de messagerie, qui jouent un rôle fondamental dans le filtrage du trafic entrant et la défense de l'infrastructure contre le spam, les logiciels malveillants et les tentatives d'abus. Ces mécanismes améliorent non seulement la sécurité et la fiabilité du courrier électronique, mais contribuent également à maintenir une bonne réputation pour les serveurs de messagerie concernés.

Greylisting : Cette technique de défense, à la fois très efficace et simple à mettre en œuvre, consiste à bloquer temporairement un message provenant d'un expéditeur inconnu (identifié par l'adresse IP, l'expéditeur et le destinataire). Le serveur de réception rejette temporairement le message en envoyant un code SMTP « réessayez plus tard ». Ce comportement, qui peut paraître contre-productif, exploite en réalité une faiblesse typique des spambots : ces outils automatisés tentent d'envoyer de gros volumes de messages et ne gèrent pas correctement les renvois temporaires. Les serveurs SMTP légitimes, en revanche, conformément à la spécification RFC, réessaient l'envoi du message après quelques minutes. Cela permet un filtrage initial et efficace entre le trafic légitime et le trafic malveillant. Le principal inconvénient de cette approche est le délai de réception du premier message d'un expéditeur donné, qui peut varier de 10 à 15 minutes, voire plus, surtout si le serveur d'envoi gère lentement les files d'attente de nouvelles tentatives. Après la première livraison réussie, l'expéditeur est ajouté à la liste blanche, temporairement ou définitivement, ce qui accélère les livraisons suivantes.

DNSBL (Liste noire basée sur le DNS) : Il s’agit d’un autre outil de défense puissant. Lorsqu’un serveur de messagerie reçoit une connexion entrante, il effectue une série de requêtes auprès de listes publiques diffusées sur Internet, contenant des adresses IP connues pour le spam ou les comportements suspects. Ces requêtes sont similaires à celles effectuées pour obtenir des enregistrements DNS et sont réalisées via UDP. Si l’adresse IP de l’expéditeur figure sur l’une de ces listes noires, le message peut être automatiquement rejeté, et un message d’erreur est renvoyé à l’expéditeur, indiquant le motif du rejet. Cette approche permet de bloquer proactivement de grandes quantités de spam, mais exige une sélection rigoureuse des listes utilisées afin d’éviter les faux positifs et de limiter l’impact sur les courriels légitimes.

SPF (Sender Policy Framework) : Il s’agit d’un mécanisme de validation permettant au domaine de l’expéditeur de spécifier, via des enregistrements TXT spécifiques dans le DNS, les adresses IP ou les hôtes autorisés à envoyer des courriels en son nom. Lorsqu’un serveur reçoit un message, il peut effectuer une vérification SPF pour s’assurer que l’adresse IP d’envoi figure bien dans cette liste. Dans le cas contraire, le courriel peut être signalé comme suspect ou rejeté. Le SPF est très utile pour lutter contre l’usurpation d’identité (envoi de courriels avec des adresses d’expéditeur falsifiées) et constitue une première barrière contre le phishing et le spam. Cependant, le SPF ne protège pas le contenu du message et ne garantit pas que le courriel n’a pas été altéré lors de sa transmission.

DKIM (DomainKeys Identified Mail) est une technologie d'authentification permettant à une organisation de signer numériquement ses messages sortants. La signature, générée à l'aide d'une clé privée, est insérée dans l'en-tête du message. Le destinataire peut ensuite vérifier l'authenticité et l'intégrité du message grâce à la clé publique publiée dans le DNS du domaine de l'expéditeur. DKIM garantit que le message n'a pas été modifié pendant son transfert et certifie qu'il provient bien de l'expéditeur. Ce mécanisme est transparent pour l'utilisateur final, la vérification étant effectuée directement par le serveur de messagerie du destinataire. Contrairement au chiffrement de bout en bout, qui protège le contenu contre les interceptions, DKIM se concentre sur l'authenticité de l'expéditeur et est utilisé par les fournisseurs de services de messagerie pour déterminer le niveau de confiance à accorder au message.

Anti-spam / Anti-virus:une fois les vérifications précédentes passées, le message est analysé en fonction de son contenu. Les systèmes anti-spam modernes attribuent un score à chaque e-mail reçu, en évaluant des facteurs tels que la présence de mots-clés suspects, de pièces jointes dangereuses, de modèles de spam typiques, d'URL internes, de langue utilisée, de réputation IP de l'expéditeur et bien plus encore. Si le score dépasse un certain seuil (généralement 5), le message est classé comme SPAM. Selon la configuration du filtre côté serveur ou côté client, le message peut être automatiquement déplacé vers le dossier SPAM, ou il peut être délivré normalement mais avec un changement d'objet, par exemple en préfixant des étiquettes telles que [SPAM] o ***SPAM***.

Dans ce cas, pour que le message soit reçu correctement par l'adresse du destinataire, l'expéditeur doit assurer une série de bonnes pratiques fondamentales. Tout d’abord, l’IP du serveur de messagerie d’envoi ne doit pas être répertoriée dans un DNSBL. De plus, le message doit être correctement structuré : il est essentiel de rédiger un sujet cohérent, d'inclure un corps de texte lisible (en évitant le HTML pur avec une seule image, par exemple), et d'éviter les pièces jointes potentiellement nuisibles ou interdites, comme les exécutables. .exe, scénario .bat, .vbs, ou des fichiers compressés suspects. Toute anomalie peut augmenter le score SPAM et compromettre sa livraison.

Il est également important de souligner clairement une notion trop souvent sous-estimée : lorsqu’un email n’arrive pas à destination, ou n’est pas reçu, la responsabilité peut incomber à la fois à l’expéditeur et au destinataire. Il est faux de supposer que le coupable est toujours « celui qui l’attend ». Par exemple, si l'un de nos clients ou fournisseurs nous envoie un email depuis un serveur répertorié dans une liste noire DNSBL, la responsabilité lui incombe entièrement : c'est lui qui n'envoie pas l'email selon les règles minimales d'hygiène SMTP. Notre serveur, en rejetant cet e-mail, fait exactement ce qu’il est censé faire : protéger notre infrastructure contre des sources potentiellement malveillantes.

Il est également important de se rappeler que le courrier électronique n’est pas, et n’a jamais été, un outil conçu pour la communication instantanée. Son architecture est asynchrone et de type « best-effort » : la livraison n'est pas garantie, n'est pas immédiate et peut être sujette à des retards ou des erreurs. Toute utilisation du courrier électronique comme système « en temps réel » est, techniquement, une utilisation abusive.

Chaque fois qu'un e-mail n'est pas remis, le système d'envoi (à moins qu'il n'ait été mal configuré) renvoie un message d'erreur, appelé rebond, qui comprend un code SMTP et une description du problème. Lire attentivement ces messages d'erreur permet, sans l'ombre d'un doute, de comprendre l'origine du problème : s'il s'agit de notre blocage, s'il s'agit d'une erreur de l'expéditeur, si l'adresse n'existe pas, ou si le message a été rejeté pour des raisons de sécurité.

Trop souvent, ces erreurs sont ignorées ou négligées, et des problèmes liés au respect (ou au non-respect) des règles sont signalés comme des pannes. Prendre quelques minutes pour lire le contenu du message d'erreur peut éviter des communications inutiles ou infondées avec le service d'assistance de l'entreprise.