7 juillet 2019

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

Pourquoi les e-mails ne sont-ils pas envoyés ? Pourquoi les mails ne sont-ils pas reçus ?

Problèmes d'envoi et de réception de courrier Bannière

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 massimo@tizio.it par exemple, essayez d'envoyer un e-mail à caio@caio.it, voici ce qui se passe dans les coulisses :

  1. 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
  2. À 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).
  3. 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.
  4. 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
  5. 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
  6. À 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.
  7. À 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 :

  1. 2 serveurs de messagerie entièrement fonctionnels, un pour l'expéditeur et un pour le destinataire
  2. 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.
  3. 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.

Vous avez des doutes ? Vous ne savez pas par où commencer ? Contactez-nous !

Nous avons toutes les réponses à vos questions pour vous aider à faire le bon choix.

Discute avec nous

Discutez directement avec notre support avant-vente.

0256569681

Contactez-nous par téléphone pendant les heures de bureau 9h30 - 19h30

Contactez-nous en ligne

Ouvrez une demande directement dans l'espace contact.

INFORMATIONS

Managed Server Srl est un acteur italien leader dans la fourniture de solutions système GNU/Linux avancées orientées vers la haute performance. Avec un modèle d'abonnement peu coûteux et prévisible, nous garantissons que nos clients ont accès à des technologies avancées en matière d'hébergement, de serveurs dédiés et de services cloud. En plus de cela, nous proposons des conseils système sur les systèmes Linux et une maintenance spécialisée en SGBD, sécurité informatique, Cloud et bien plus encore. Nous nous distinguons par notre expertise dans l'hébergement de CMS Open Source de premier plan tels que WordPress, WooCommerce, Drupal, Prestashop, Joomla, OpenCart et Magento, soutenus par un service d'assistance et de conseil de haut niveau adapté aux administrations publiques, aux PME et à toutes tailles.

Red Hat, Inc. détient les droits de Red Hat®, RHEL®, RedHat Linux® et CentOS® ; AlmaLinux™ est une marque commerciale d'AlmaLinux OS Foundation ; Rocky Linux® est une marque déposée de la Rocky Linux Foundation ; SUSE® est une marque déposée de SUSE LLC ; Canonical Ltd. détient les droits sur Ubuntu® ; Software in the Public Interest, Inc. détient les droits sur Debian® ; Linus Torvalds détient les droits sur Linux® ; FreeBSD® est une marque déposée de la FreeBSD Foundation ; NetBSD® est une marque déposée de la Fondation NetBSD ; OpenBSD® est une marque déposée de Theo de Raadt. Oracle Corporation détient les droits sur Oracle®, MySQL® et MyRocks® ; Percona® est une marque déposée de Percona LLC ; MariaDB® est une marque déposée de MariaDB Corporation Ab ; REDIS® est une marque déposée de Redis Labs Ltd. F5 Networks, Inc. détient les droits sur NGINX® et NGINX Plus® ; Varnish® est une marque déposée de Varnish Software AB. Adobe Inc. détient les droits sur Magento® ; PrestaShop® est une marque déposée de PrestaShop SA ; OpenCart® est une marque déposée d'OpenCart Limited. Automattic Inc. détient les droits sur WordPress®, WooCommerce® et JetPack® ; Open Source Matters, Inc. détient les droits sur Joomla® ; Dries Buytaert détient les droits sur Drupal®. Amazon Web Services, Inc. détient les droits sur AWS® ; Google LLC détient les droits sur Google Cloud™ et Chrome™ ; Facebook, Inc. détient les droits sur Facebook® ; Microsoft Corporation détient les droits sur Microsoft®, Azure® et Internet Explorer® ; La Fondation Mozilla détient les droits sur Firefox®. Apache® est une marque déposée de The Apache Software Foundation ; PHP® est une marque déposée du groupe PHP. CloudFlare® est une marque déposée de Cloudflare, Inc. ; NETSCOUT® est une marque déposée de NETSCOUT Systems Inc. ; ElasticSearch®, LogStash® et Kibana® sont des marques déposées d'Elastic NV. Ce site n'est affilié, sponsorisé ou autrement associé à aucune des entités mentionnées ci-dessus et ne représente aucune de ces entités de quelque manière que ce soit. Tous les droits sur les marques et noms de produits mentionnés sont la propriété de leurs titulaires respectifs des droits d'auteur. Toutes les autres marques mentionnées appartiennent à leurs titulaires. MANAGED SERVER® est une marque déposée au niveau européen par MANAGED SERVER SRL Via Enzo Ferrari, 9 62012 Civitanova Marche (MC) Italie.

Retour en haut de page