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

Lorsqu’une personne en apprend davantage 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. Dans cet esprit, l’article de questions-réponses sur les superutilisateurs d’aujourd’hui a les réponses aux questions d’un lecteur curieux.

La session de questions et réponses d’aujourd’hui nous est offerte par SuperUser, une subdivision de Stack Exchange, un regroupement communautaire de sites Web de questions-réponses.

Photo gracieuseté de David Schroeder (Flickr).

La question

Le 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 des e-mails? Pourquoi mon client de messagerie (Outlook ou Thunderbird) est-il incapable d’envoyer des messages directement au domaine SMTP du destinataire?

Par exemple, si je dois envoyer du 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 example.com.

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

La réponse

Le contributeur SuperUser Davidgo a la réponse pour nous:

Il est techniquement possible d’envoyer des e-mails directement au serveur SMTP du destinataire depuis votre ordinateur.

En regardant cela à partir d’une base historique, si le serveur SMTP distant est en panne, vous voulez qu’un système le gère automatiquement et continue à réessayer, vous avez donc un serveur SMTP. De même, dans l’ancien temps, tous les serveurs de messagerie n’étaient pas connectés en permanence (les liaisons longue distance coûtaient cher), de sorte que le courrier était mis en file d’attente et envoyé lorsqu’un lien était établi.

Passant là où les services Internet sont bon marché, il est toujours utile de disposer de mécanismes pour réessayer d’envoyer du courrier si un serveur n’est pas disponible. Il n’est pas idéal que cette fonctionnalité soit écrite dans le MUA (Mail user agent / end user mail program). Ces fonctions s’intègrent dans un MTA (serveur de messagerie / serveur SMTP).

Mais la situation empire: les spammeurs. La plupart des e-mails (plus de 80%) sont du spam. Les fournisseurs de messagerie font tout ce qu’ils peuvent pour réduire ce problème et un grand nombre de techniques émettent des hypothèses sur la façon 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 deuxième fois. Les spammeurs ne réessaient souvent pas alors qu’un serveur SMTP est toujours censé le faire. Cela réduit le volume de spam d’environ 80%, mais c’est nul de devoir le faire.

2. Réputation: Il est beaucoup plus probable qu’une personne qui envoie du courrier via un serveur SMTP réputé et connu 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 de grandes parties d’Internet ont été mappées).
  • Vérifiez si le DNS inversé correspond au DNS direct. Ce n’est pas très difficile à faire, mais cela montre un certain niveau de responsabilité et de connaissance des meilleures pratiques (ce que beaucoup de blocs d’adresses 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 gardant un œil sur ces paramètres. Il y a de nombreuses façons de procéder, 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 la falsification du courrier plus difficile et 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? Sonnez dans les commentaires. Vous voulez lire plus de réponses d’autres utilisateurs de Stack Exchange férus de technologie? Consultez le fil de discussion complet ici.

En relation :  Pourquoi vous devez cesser d'utiliser l'enregistrement automatique dans Microsoft Office 365
Moyens Staff
Moyens I/O Staff vous a motivé, donner des conseils sur la technologie, le développement personnel, le style de vie et des stratégies qui vous aider.