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, essayez d'envoyer un e-mail à un autre utilisateur, comme caio@caio.it, une série d'opérations techniques très spécifiques sont activées qui se déroulent en arrière-plan. Ces opérations sont régies par des protocoles standardisés et orchestrées par plusieurs composants, mais apparaissent à l’utilisateur 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 d'envoi, donc mail.tizio.it, utilisera ces informations pour établir une connexion TCP au port 25 de mail.caio.it. Une fois la connexion établie, le serveur tizio transmettra l'e-mail à la file d'attente, préalablement 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 du courrier entrant. À ce stade, le serveur se charge de stocker le message au sein du système de fichiers local, dans un format structuré qui peut être Maildir (basé sur des répertoires et des fichiers séparés pour chaque message) ou mbox (un fichier unique contenant tous les e-mails). 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.

Liste grise:C'est une technique de défense très efficace et simple à mettre en œuvre. Lorsqu'un message est reçu d'un expéditeur inconnu (en fonction de la combinaison IP, expéditeur et destinataire), le serveur de réception rejette temporairement le courrier avec un code SMTP « réessayer 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 redirections temporaires. Cependant, les serveurs SMTP légitimes, conformément à la spécification RFC, réessaieront d'envoyer le message après quelques minutes. Cela permet une première sélection, déjà significative, 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 e-mail d'un expéditeur donné, qui peut varier de 10 à 15 minutes, voire plus, surtout si le serveur d'envoi est lent à gérer les files d'attente de nouvelles tentatives. Cependant, après la première livraison réussie, l'expéditeur est « mis sur liste blanche » temporairement ou définitivement, ce qui accélère les envois ultérieurs.

DNSBL (Liste des trous noirs basée sur DNS) : il s'agit d'un autre outil de défense puissant. Lorsqu'un serveur de messagerie reçoit une connexion entrante, il envoie une série de requêtes à des listes publiques sur Internet contenant des adresses IP connues pour être des spammeurs ou suspectes. Ces requêtes sont similaires à celles effectuées pour obtenir des enregistrements DNS et sont effectuées via le protocole UDP. Si l'IP de l'expéditeur apparaît sur l'une de ces listes noires, le message peut être automatiquement rejeté, renvoyant un message d'erreur à l'expéditeur contenant la raison du rejet. Cette approche vous permet de bloquer de manière proactive de grandes quantités de spam, mais nécessite une sélection minutieuse des listes que vous utilisez pour éviter les faux positifs et limiter l'impact sur les e-mails légitimes.

SPF (Sender Policy Framework) : est un mécanisme de validation qui permet au domaine de l'expéditeur de spécifier, via des enregistrements TXT spécifiques dans le DNS, quelles adresses IP ou quels hôtes sont autorisés à envoyer des e-mails au nom de ce domaine. Lorsqu'un serveur reçoit un message, il peut effectuer une vérification SPF pour s'assurer que l'adresse IP d'envoi est effectivement incluse dans cette liste. Dans le cas contraire, l’e-mail peut être marqué comme suspect ou rejeté. Le SPF est très utile pour contrer le spoofing, c'est-à-dire l'envoi d'e-mails avec des adresses d'expéditeur falsifiées, et représente une première barrière contre le phishing et le spam. Cependant, SPF ne protège pas le contenu du message et ne garantit pas que l’e-mail n’a pas été modifié en cours de route.

DKIM (DomainKeys Identified Mail) : est une technologie d'authentification qui permet à une organisation de signer numériquement les 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, à son tour, peut vérifier l'authenticité du message et son intégrité à l'aide de 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 le transport et certifie qu'il provient réellement de la personne qui prétend l'avoir envoyé. Ce mécanisme n'est pas visible pour l'utilisateur final, car la vérification est gérée directement par le serveur de messagerie récepteur. Contrairement au cryptage de bout en bout, qui protège le contenu des regards extérieurs, DKIM se concentre sur l'authenticité de l'expéditeur et est utilisé par les fournisseurs pour prendre des décisions sur la manière de traiter le message en termes de confiance.

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 nous finissons par signaler comme des défauts des problèmes qui sont en fait simplement liés au respect (ou non) des règles. Il suffirait de prendre quelques minutes pour lire le contenu du rebond pour éviter des communications inutiles ou infondées au helpdesk de l'entreprise.