Pourquoi ai-je besoin d'un serveur SMTP intermédiaire pour envoyer du courrier ? Pourquoi mon client (Outlook, Thunderbird) ne peut-il pas envoyer des messages directement au domaine SMTP du destinataire ?
Par exemple, si je dois envoyer un courriel à address@example.com avec mon compte Gmail, je l'envoie à la smtp.gmail.com et ensuite ce serveur enverra mon message au serveur MX de example.com .
Il est techniquement possible d'envoyer un courriel directement au serveur SMTP du destinataire depuis votre ordinateur.
D'un point de vue historique, si le serveur SMTP distant est en panne, vous voulez qu'un système le gère automatiquement et réessaie sans cesse, d'où l'existence 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 coûteuses, de sorte que le courrier était mis en file d'attente et envoyé lorsqu'une liaison était établie.
Dans les pays où l'Internet est bon marché, il est toujours utile de disposer de mécanismes permettant de réessayer d'envoyer des messages électroniques si un serveur n'est pas disponible, et il n'est pas idéal que cette fonctionnalité soit écrite dans le MUA (agent de messagerie/programme de messagerie de l'utilisateur final). Ces fonctions s'intègrent dans un MTA (serveur de messagerie/serveur SMTP).
Mais il y a pire spammeurs . La plupart des courriers électroniques (bien plus de 80 %) sont des spams. Les fournisseurs de courrier font donc tout ce qu'ils peuvent pour réduire ce problème - et un grand nombre de techniques font des hypothèses sur la façon dont le courrier électronique est délivré - les points suivants sont des considérations importantes :
Greylisting : Certains fournisseurs interrompent automatiquement une connexion de courrier si l'expéditeur et le destinataire n'ont pas communiqué auparavant, et s'attendent à ce qu'ils essaient une deuxième fois - car les spammeurs ne le font souvent pas, alors qu'un serveur SMTP est toujours censé le faire. Cela permet de réduire les volumes de spam d'environ 80 %. Mais ça craint d'avoir à le faire.
Réputation : Il est beaucoup plus probable qu'une personne envoyant des e-mails par le biais d'un serveur SMTP connu et réputé soit légitime qu'un serveur de fortune. Pour se faire une idée de leur réputation, les fournisseurs font un certain nombre de choses :
Bloquer les adresses dynamiques / clients (Pas à 100%, mais de grandes parties d'Internet ont été cartographiées).
Regardez que le reverse DNS correspond au forward DNS : 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.
Réputation : Lorsqu'ils communiquent avec d'autres serveurs SMTP, de nombreux fournisseurs suivent la quantité de spam et les volumes d'e-mails envoyés et peuvent réduire la quantité de spam en limitant les connexions et en gardant un œil sur ces paramètres. (Il existe 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 domaine afin de rendre la falsification du courrier plus difficile, et serait difficile (mais pas nécessairement impossible) à réaliser. nécessairement impossible à déployer si le programme de messagerie (MUA) est responsable du courrier sortant. (Ajouté pour rendre cette réponse plus complète car elle a déjà été acceptée. Le crédit pour cette réponse devrait aller aux posters ci-dessous car elle m'a échappé, mais elle est 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 des messages directement au domaine SMTP du destinataire ?
En 1991 - et pendant la majeure partie du début des années 90 et même avant - vous pourriez être en mesure de faire ce que vous décrivez. Mais la réalité en 2015 est que, bien qu'il soit techniquement possible d'envoyer un courrier électronique à n'importe qui à partir de n'importe quelle machine sur laquelle est installé un service de messagerie, le monde du SPAM a rendu cette méthode effectivement inutile.
Lorsque vous utilisez un "vrai" service SMTP, des éléments sont définis comme les enregistrements PTR, les enregistrements SPF et même les DomainKeys qui sont tous établis dans un seul et unique but : garantir que le SMTP qui envoie le message est légitime. Et s'il ne l'est pas ? Filtrez le message dans un dossier SPAM ou dans le "grand abîme" de la suppression. Voici une description de chacun de ces éléments :
PTR (Pointer Record/Reverse DNS Record) : Vérification au niveau du serveur. Comme expliqué ici Un enregistrement PTR est utilisé pour faire correspondre une interface réseau (IP) à un nom d'hôte. Cela signifie que si vous avez une adresse 123.456.789.0 sur votre serveur SMTP qui envoie des e-mails pour smtp.example.com alors un enregistrement PTR approprié pour cela serait smtp.example.com . Cela semble trop simple, mais cela fonctionne puisque le seul qui puisse réellement définir un enregistrement PTR est le propriétaire de l'adresse IP et qu'il ne peut être défini que sur son matériel. Il s'agit donc d'un point de vérification de l'identité du propriétaire/exploitant/gestionnaire de cette adresse IP.
SPF (Sender Policy Framework) : Vérification du niveau d'entrée DNS du nom d'hôte. Un enregistrement SPF comme expliqué ici -Il s'agit essentiellement d'un enregistrement DNS établi par le détenteur du nom de domaine qui fournit une liste d'adresses IP et de noms d'hôtes de 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 électroniques. Disons donc qu'un serveur dont l'adresse IP est 123.456.789.9 envoie des courriels pour example.com . Nous savons déjà que smtp.example.com utilise 123.456.789.0 mais un enregistrement SPF pour example.com peut déclarer : "Hé ! 123.456.789.9 est un bon serveur ! Il est réglo ! Respectez ses emails !"
DKIM (DomainKeys Identified Mail) : Vérification du niveau des messages électroniques. Comme expliqué ici et sur Wikipedia DKIM est un système de validation du courrier électronique conçu pour détecter l'usurpation d'identité en fournissant un mécanisme permettant aux échangeurs de courrier récepteurs de vérifier que le courrier entrant provenant d'un domaine est autorisé par les administrateurs de ce domaine et que le courrier (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é ou modifié au cours du transport. Il s'agit également d'un autre point de vérification dans la chaîne "Êtes-vous légitime ou êtes-vous un SPAM ?
En fin de compte, un serveur SMTP public digne de ce nom aura au moins deux de ces éléments (PTR et SPF) définis pour vérifier que le serveur SMTP et le courriel associé sont légitimes. Tout le monde n'utilise pas DKIM, mais il s'agit d'une autre couche de validation qui devient de plus en plus populaire de nos jours, les spammeurs devenant de plus en plus tenaces dans leurs efforts pour envoyer du SPAM.
Les autres réponses sont toutes excellentes, et le spam y est pour beaucoup.
Mais il existe en fait une réponse plus simple et plus générique : les fonctionnalités. L'envoi de courrier électronique par SMTP est en fait 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 ; il vaut mieux utiliser un logiciel dédié (sendmail, postfix, etc. sont les plus importants dans le monde *nix, Exchange dans le monde Windows).
Par exemple, même au niveau le plus basique, un "vrai" serveur SMTP doit au moins être capable de résoudre les enregistrements MX. Il doit ensuite négocier des fonctionnalités (principalement TLS, mais il y a aussi d'autres fonctionnalités). Il doit gérer des files d'attente pour les nouvelles tentatives, générer des rapports de non-livraison, etc.
Et ce n'est que la fonctionnalité de base, indispensable, sans laquelle le serveur ne fonctionnerait même pas. Cela n'inclut même pas des choses comme la réécriture d'adresses, mailertables. Sans parler de la douzaine d'autres protocoles que sendmail et al supportent, comme UUCP.
L'implémentation du SMTP dans Outlook, Thunderbird, etc. est très minime - au mieux, elle équivaut à l'utilisation d'un hôte intelligent sur sendmail, voire plus.
Le courrier électronique est un sujet très sensible sur le plan de la sécurité, et il est préférable d'avoir un ou quelques serveurs gérés de manière centralisée pour le gérer, plutôt que des centaines ou des 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 des messages directement au domaine SMTP du destinataire ?
Vous pourriez créer un programme de courrier électronique qui ferait cela, et je ne doute pas que d'autres l'aient déjà fait (ou tenté).
Vous écrirez essentiellement un outil qui est à la fois un MUA (mail user agent) et un MTA (mail transfer agent).
La raison pour laquelle cette fonction est traditionnellement séparée en différents outils, le MTA résidant "côté serveur", est qu'un MTA qui envoie du courrier via l'internet ouvert est considérablement plus complexe à écrire et à configurer, et qu'il bénéficie également de la présence d'un serveur fiable "toujours disponible".
Un MTA doit le faire :
Rechercher et se connecter à des serveurs auxquels il ne fait pas confiance, ou qui peuvent se comporter de manière incorrecte, et traiter les conditions d'erreur d'une manière raisonnable qui ne perd pas de courrier.
Gérer les serveurs qui sont hors service et les acheminer vers d'autres serveurs ou mettre le courrier en file d'attente pour une nouvelle tentative ultérieure. Ce système fonctionne mieux sur un processus de serveur qui est "toujours connecté" à l'internet. Cela implique également que l'agent de transfert du courrier ait besoin de ses propres zones de stockage pour le courrier mis en file d'attente.
Gérer une gamme de capacités de serveur différentes, en ajustant le comportement en fonction des capacités du serveur récepteur.
Signaler à l'utilisateur les conditions d'erreur ou les cas où le courrier n'est pas distribuable, afin que le courrier ne soit pas simplement perdu.
Avoir d'excellentes pratiques de sécurité et être très conscient de la sécurité.
Idéalement, ils doivent résider sur un serveur fiable, toujours connecté, avec une adresse IP stable et une entrée DNS inverse, c'est-à-dire une connexion Internet adaptée aux serveurs publics. Cela permet aux autres systèmes de ne pas détecter le courrier envoyé en tant que spam.
Compte tenu de ces exigences, il est logique d'héberger le serveur SMTP sur un serveur public toujours actif quelque part, et d'essayer d'utiliser un outil adapté à cette tâche particulière.
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
