Page d'accueil » comment » Pourquoi un serveur SMTP intermédiaire est-il nécessaire pour envoyer un courrier?

    Pourquoi un serveur SMTP intermédiaire est-il nécessaire pour envoyer un courrier?

    Lorsqu'une personne en apprend plus sur le fonctionnement des clients de messagerie, des serveurs SMTP et de l'ensemble du système de messagerie en ligne, elle peut être curieuse de savoir pourquoi un serveur SMTP intermédiaire est même nécessaire. En gardant cela à l'esprit, le post de SuperUser d'aujourd'hui contient les réponses aux questions d'un lecteur curieux.

    La séance de questions et réponses d'aujourd'hui nous est offerte par SuperUser, une sous-division de Stack Exchange, un groupe de sites Web de questions-réponses dirigé par la communauté..

    Photo gracieuseté de David Schroeder (Flickr).

    La question

    Lecteur SuperUser Tobia veut savoir pourquoi un serveur SMTP intermédiaire est nécessaire pour envoyer du courrier:

    Pourquoi ai-je besoin d'un serveur SMTP intermédiaire pour envoyer du courrier? Pourquoi mon client de messagerie (Outlook ou Thunderbird) ne peut-il pas envoyer de messages directement au domaine SMTP du destinataire??

    Par exemple, si je dois envoyer un courrier à [email protected] avec mon compte Gmail, je l’envoie au smtp.gmail.com serveur; alors ce serveur envoie mon message au serveur MX de exemple.com.

    Pourquoi un serveur SMTP intermédiaire est-il nécessaire pour envoyer du courrier??

    La réponse

    Le contributeur SuperUser, davidgo, a la solution pour nous:

    Il est techniquement possible d'envoyer un courrier directement au serveur SMTP du destinataire depuis votre ordinateur..

    En examinant l'historique, si le serveur SMTP distant est en panne, vous souhaitez qu'un système le gère automatiquement et continue à réessayer. Par conséquent, vous disposez d'un serveur SMTP. De même, à l’époque, tous les serveurs de messagerie n’étaient pas connectés en permanence (les liaisons longue distance étaient onéreuses); le courrier était donc mis en file d’attente et envoyé lorsqu’un lien était établi.

    Pour passer aux services Internet peu coûteux, il est toujours utile de disposer de mécanismes permettant de réessayer d'envoyer du courrier si un serveur est indisponible. Il n'est pas idéal que cette fonctionnalité soit écrite dans le MUA (programme de messagerie agent utilisateur / utilisateur final). Ces fonctions s’intègrent dans un MTA (serveur de messagerie / serveur SMTP).

    Mais les spammeurs deviennent pires. La plupart des messages (plus de 80%) sont du spam. Les fournisseurs de courrier font tout ce qu'ils peuvent pour réduire ce problème et un grand nombre de techniques font des hypothèses sur la manière dont le courrier est livré. Les considérations suivantes sont importantes:

    1. Liste grise: Certains fournisseurs abandonneront automatiquement une connexion de messagerie si l'expéditeur et le destinataire n'ont pas communiqué auparavant et s'attendent à ce qu'ils essaient une seconde fois. Les spammeurs ne réessayent souvent pas alors qu'un serveur SMTP est toujours supposé le faire. Cela réduit le volume de spam d’environ 80%, mais il est difficile de le faire bien que.

    2. Réputation: Il est beaucoup plus probable que quelqu'un qui envoie des messages via un serveur SMTP réputé et réputé soit légitime par rapport à un serveur fly-by-night. Pour se faire une idée de la réputation, les fournisseurs font un certain nombre de choses:

    • Bloquer les adresses dynamiques / client (pas à 100%, mais d’importants morceaux d’Internet ont été cartographiés).
    • Vérifiez si le DNS inversé correspond au DNS avant. Pas très difficile à faire, mais cela montre un certain niveau de responsabilité et de connaissance des meilleures pratiques (quelque chose que beaucoup de blocs d'adresses de clients n'ont pas).
    • Vérifiez la réputation. Lors de la communication avec d'autres serveurs SMTP, de nombreux fournisseurs gardent une trace de la quantité de spam et du volume de courrier envoyé. Ils peuvent réduire la quantité de spam en limitant les connexions et en surveillant ces paramètres. Ceci est fait de nombreuses manières, pas toutes évidentes, mais qui nécessitent un expéditeur connu.
    • SPF et DKIM. Ces mécanismes lient les ressources DNS au nom de domaine pour rendre plus difficile la création de courrier falsifié. Ce serait difficile, mais pas nécessairement impossible à déployer, si le programme de messagerie (MUA) est responsable du courrier sortant..

    Il y a probablement d'autres préoccupations mineures, mais ce sont les principales.


    Avez-vous quelque chose à ajouter à l'explication? Sound off dans les commentaires. Voulez-vous lire plus de réponses d'autres utilisateurs de Stack Exchange doués en technologie? Découvrez le fil de discussion complet ici.