Pourquoi ai-je besoin d'un serveur SMTP?

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

Par exemple, si je dois envoyer un courrier électronique address@example.comavec mon compte Gmail, je l’envoie au smtp.gmail.comserveur; puis ce serveur enverra mon message au serveur MX de example.com.

Il est techniquement possible d'envoyer un courrier électronique directement au serveur SMTP du destinataire à partir de 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 à le réessayer. Vous disposez donc 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 coûtaient cher, de sorte que le courrier était mis en file d’attente et envoyé lors de l’établissement d’un lien.

Pour aller là où Internet est bon marché, il est toujours utile de disposer de mécanismes permettant de réessayer d'envoyer un courrier électronique en cas d'indisponibilité d'un serveur. De plus, cette fonctionnalité n'est pas idéale pour que cette fonctionnalité soit écrite dans le MUA (programme de messagerie agent / utilisateur final). Ces fonctions s’intègrent dans un MTA (serveur de messagerie / serveur SMTP).

Mais il y a pire - les spammeurs . La plupart des courriels (plus de 80%) sont du spam. Ainsi, 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 manière dont le courrier électronique est envoyé). Voici des considérations 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, car les spammeurs ne le font pas souvent, alors qu'un serveur SMTP est toujours supposé le faire. Cela réduit les volumes de spam d'environ 80%. C'est nul de devoir le faire cependant.

2. Réputation: il est beaucoup plus probable que quelqu'un qui envoie un courrier électronique via un serveur SMTP réputé et connu soit légitime, au lieu d'un serveur virtuel. Pour se faire une idée de la réputation, les fournisseurs font un certain nombre de choses:

   1. Bloquer les adresses dynamiques / client (pas à 100%, mais de gros morceaux d’Internet ont été cartographiés).

   2. Regardez si le DNS inversé correspond au DNS avant: ce n’est pas très difficile à faire, mais montre un certain niveau de responsabilité et une connaissance des meilleures pratiques, ainsi que de nombreux blocs d’adresses clients n’ayant pas.

   3. Réputation: lorsqu'ils communiquent avec d'autres serveurs SMTP, de nombreux fournisseurs gardent une trace de la quantité de spam et des volumes de courrier électronique envoyés et peuvent réduire la quantité de spam en limitant les connexions et en surveillant ces paramètres. (Il y a beaucoup de façons de le faire, toutes non évidentes, mais qui nécessitent un expéditeur connu).

   4. SPF et DKIM: ces mécanismes associent les ressources DNS au nom de domaine pour rendre plus difficile la création de courrier falsifié (mais pas nécessairement impossible à déployer si le programme de messagerie (MUA) est responsable du courrier sortant. (Ajouté pour rendre cette réponse plus complet car il a déjà été accepté. Le mérite en revient aux affiches ci-dessous, cela m’a glissé dans l’esprit mais qui reste néanmoins très valable)

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

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

En 1991, et presque tout au début des années 90 et même avant, vous pourrez peut-être faire ce que vous décrivez. Mais la réalité en 2015 est que, bien que l’on puisse techniquement envoyer un courrier électronique à n’importe qui, de n’importe quelle machine sur laquelle un service de messagerie est installé, le monde du SPAM a rendu cette méthode inutilisable.

Lorsque vous utilisez un «vrai» service SMTP, les choses sont définies comme les enregistrements PTR, les enregistrements SPF et même les DomainKeys qui sont tous établis dans un seul but: garantir que le SMTP qui envoie le message est légitime. Et si ça ne l'est pas? Filtrez le message dans un dossier SPAM ou dans le «grand abysse» de la suppression. Voici un aperçu de chacun de ces éléments:

• PTR (enregistrement de pointeur / enregistrement DNS inversé): vérification au niveau du serveur. Comme expliqué ici , un enregistrement PTR est utilisé pour mapper une interface réseau (IP) sur un nom d'hôte. Cela signifie que si vous avez une adresse 123.456.789.0sur votre serveur SMTP qui envoie des courriels pour smtp.example.comun enregistrement PTR approprié, ce serait smtp.example.com. Cela semble trop simple, mais cela fonctionne car le seul qui puisse réellement définir un enregistrement PTR est le propriétaire de l'adresse IP et celle-ci ne peut être définie que sur son matériel. Donc, il agit comme un point de vérification pour qui possède / exécute / gère cette adresse IP.

• SPF (Sender Policy Framework): vérification du niveau d'entrée du nom d'hôte DNS. Un enregistrement SPF — comme expliqué ici — est en principe un enregistrement DNS défini par le détenteur du nom de domaine qui fournit une liste d'adresses IP et de noms d'hôte des serveurs autorisés à envoyer des courriers électroniques pour ce nom de domaine. Il s’agit là encore d’une autre étape de vérification qui garantit que seul le véritable propriétaire du nom de domaine d’un serveur SMTP peut envoyer des messages. Donc, disons un serveur avec l'adresse IP de qui 123.456.789.9envoie des emails pour example.com. Nous savons déjà que cela smtp.example.comutilise 123.456.789.0, mais une entrée d’enregistrement SPF example.compeut indiquer «Hey! 123.456.789.9est un bon serveur! Il est légitime! Respectez ses emails! "

• DKIM (DomainKeys Identified Mail): vérification du niveau de messagerie. Comme expliqué ici et sur Wikipedia , «DKIM est un système de validation de courrier électronique conçu pour détecter l’usurpation de courrier électronique en fournissant un mécanisme permettant à des échangeurs de messagerie de vérifier que le courrier entrant provenant d’un domaine est autorisé par les administrateurs de ce domaine et que le courrier électronique (y compris les pièces jointes). n'a pas été modifié pendant le transport. »En utilisant des hachages cryptographiques, DKIM vérifie que le courrier lui-même n'a pas été filtré ni falsifié pendant le transit. Cela sert également de point de vérification supplémentaire dans la chaîne «Êtes-vous légitime ou êtes-vous du spam?».

Ainsi, à la fin, un serveur SMTP grand public ayant au moins deux de ces éléments (PTR et SPF) configuré pour vérifier que le serveur SMTP et le courrier électronique associé sont légitimes. Tout le monde n’utilise pas DKIM, mais c’est une autre couche de validation qui devient de plus en plus populaire à mesure que les SPAMmers deviennent plus tenaces dans leurs efforts d’envoi de SPAM.

La plupart des FAI résidentiels bloquent le port TCP 25 (SMTP) afin de vous empêcher de participer à un réseau de courrier indésirable. Si votre ordinateur est infecté, votre ordinateur peut commencer à envoyer du spam sur l'ordre de quelqu'un d'autre.

Les autres réponses sont toutes excellentes et le spam y est pour beaucoup.

Mais il existe en réalité une réponse plus simple, plus générique: les fonctionnalités. L'envoi de courrier électronique via SMTP est en réalité une entreprise très complexe. Même sans spam, vous ne voudriez pas implémenter l’ensemble des fonctionnalités du protocole SMTP dans chaque client de messagerie; vous avez intérêt à utiliser un logiciel dédié (sendmail, postfix, etc., sont les plus gros logiciels dans le monde * nix, Exchange dans le monde Windows).

Par exemple, même au plus basique, un "vrai" serveur SMTP doit au moins être capable de résoudre les enregistrements MX. Ensuite, il doit négocier les fonctionnalités (principalement TLS, mais il existe aussi d'autres fonctionnalités). Il doit gérer les files d'attente de tentatives, générer des rapports de non-remise, etc.

Et ce n’est là que la fonctionnalité de base, indispensable, sans laquelle le serveur ne fonctionnerait même pas. Cela n'inclut même pas des choses telles que la réécriture d'adresses, les mailertables. Sans oublier la douzaine d'autres protocoles pris en charge par sendmail et al, tels que UUCP.

L'implémentation SMTP dans Outlook, Thunderbird, etc. est très minime - au mieux, équivaut à peu près à utiliser un hôte actif sur sendmail, le cas échéant.

Problème connexe, mais distinct: le courrier électronique est un sujet très sensible à la sécurité et vous souhaitez qu’un ou plusieurs serveurs gérés centralement le gèrent, au lieu de centaines, voire de milliers, de serveurs individuels sur chaque poste de travail.

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

Vous pourriez créer un programme de messagerie électronique qui le ferait, et je n’ai aucun doute que d’autres l’ont déjà fait (ou tenté).

Vous seriez essentiellement en train d’écrire un outil qui est à la fois un agent de messagerie (MUA) et un agent de transfert de courrier (MTA).

La raison pour laquelle cela est traditionnellement séparé en différents outils, avec le MTA résidant «côté serveur», est qu’un MTA qui envoie des messages via Internet ouvert est beaucoup plus complexe à écrire et à configurer, et qu’il est avantageux de résider sur un serveur distant. fiable "toujours sur" le serveur.

Un MTA doit:

• Recherchez et connectez-vous à des serveurs auxquels il ne fait pas confiance, ou qui risquent de mal se comporter, et gérez les conditions d'erreur de manière rationnelle sans perdre de courrier.

• Traitez les serveurs hors service et dirigez-vous vers d'autres serveurs ou mettez le courrier en file d'attente pour une nouvelle tentative ultérieure. Cela fonctionne mieux sur un processus serveur "toujours connecté" à Internet. Cela implique également que l'agent de transfert de courrier a besoin de ses propres zones de stockage pour le courrier mis en file d'attente.

• Traitez avec une gamme de capacités de serveur différentes, en ajustant le comportement en fonction des capacités du serveur de réception.

• Signalez à l'utilisateur les conditions d'erreur ou les messages non distribuables afin qu'ils ne soient pas simplement perdus.

• Ayez d'excellentes pratiques de sécurité et soyez très attentif à la sécurité.

• Idéalement, résidez sur un serveur fiable, toujours connecté, avec une adresse IP stable et une entrée DNS inversée, c'est-à-dire une connexion Internet adaptée aux serveurs ouverts au public. Cela aide les autres systèmes à ne pas détecter le courrier envoyé en tant que spam.

Compte tenu de ces exigences, il est judicieux d'installer le serveur SMTP sur un serveur ouvert, accessible au public, et d'utiliser un outil adapté à cette tâche.

Une autre chose à considérer est de recevoir les emails retournés . Au minimum, tous les courriels sortants ont une adresse FROM où une réponse peut être envoyée (utilisateur inconnu, réponse de vacances, etc.). Pour que l'adresse de retour soit résolue, un enregistrement MX doit exister pointant vers l'emplacement de la boîte de réception des retours. Sauf si vous envoyez des courriels à partir d'un ordinateur avec une adresse IP statique toujours active, vous aurez besoin d'un serveur pour gérer ces messages entrants. Ceci est généralement (mais pas toujours) géré par le même service.

GMail, Outlook 365 et Yahoo Mail sont des exemples de services de messagerie utilisés par des personnes qui envoient des messages. Pour l'envoi de courriels commerciaux, il existe des services tels que MailChimp, Marketo et Eloqua qui sont très efficaces pour envoyer des courriels en masse à une entreprise et gérer des tâches telles que les rebonds, les limitations et la délivrabilité.

Voir: https://en.m.wikipedia.org/wiki/Bounce_address