Espace tutos dev’ & informatique 🐧

L’acheminement SMTP des courriels

Publié le
Article sur l'acheminement des mails de l'expéditeur au destinataire

Introduction

« Mais au fait, que se passe t’il lorsque j’envoie un mail ? » 🤔

Une question que l’on ne se pose jamais. Enfin jusqu’à ce qu’on se retrouve avec des problèmes d’acheminement de mail, de passage en spam aléatoire etc. Et quand ça arrive, les informations sur le sujet sont disséminées un peu partout.

Dans cet article, on va voir le parcours effectué par un mail lors de son envoi, et les différents intervenants par lesquels il transite. Outre nous donner une idée des différents emplacements de panne possibles, cela servira de base pour des articles futurs.

Les acteurs de l’envoi de mail, de l’expéditeur au destinataire

Tout comme pour l’envoi d’un courrier postal, un email doit passer entre différentes mains avant de d’arriver dans la boite aux lettres de son destinataire. Commençons donc par voir les différents acteurs de la livraison, résumés dans ce petit schéma, et décrits plus en détail juste après.

Schéma de la livraison d'un courriel via MUA, MSA, MTA et MDA
Transit d’un courriel via le MUA, le MSA, les MTAs et le MDA

Le Mail User Agent lors de la mise en circulation du mail

Le MUA (pour Mail User Agent) est l’outil utilisé par l’émetteur pour envoyer son email.

👉  Sur un site internet il s’agit soit du script traitant la demande d’envoi de mail effectuée sur ce dernier (on peut utiliser par exemple la librairie PHPMailer), ou alors un binaire appelé par le script tel que sendmail.

👉  Dans le cadre d’un envoi classique il s’agit du client mail, tel que Mozilla Thunderbird, Apple Mail ou Microsoft Outlook.

Le MUA se connecte et envoie les données du mail à un serveur appelé le Mail Submission Agent, dont il doit au préalable connaitre les coordonnées (adresse, identifiant, mot de passe). Le protocole utilisé pour communiquer avec lui est le protocole SMTP.

Le Mail Submission Agent, point de départ de l’acheminement

Le MSA (pour Mail Submission Agent) est un serveur qui reçoit les demandes d’envoi de mails de la part des MUAs. Il est 99% du temps soumis à une authentification identifiant et mot de passe afin d’empêcher les envois de courriers indésirables. Il est aussi appelé serveur de courrier sortant (Outgoing mail server) ou plus simplement serveur SMTP dans les documentations des hébergeurs et des fournisseurs d’accès internet.

Si le mail est autorisé, alors le MSA envoie ses données à un Mail Transfer Agent via le protocole SMTP.

💡  On peut parfois utiliser les enregistrements DNS de type SRV (pour Service) d’un domaine pour identifier un MSA. Par exemple, un enregistrement _submission._tcp 10800 IN SRV 0 1 587 mail.example.com. indique un MSA écoutant sur le port 587 à l’adresse mail.example.com.

Les Mail Transfer Agents lors du transit du mail

Le MTA (pour Mail Transfer Agent) est un intermédiaire dans la livraison du mail. Il effectue des opérations comme le filtrage des courriels, ou bien agit en simple relais.

Une fois ses opérations effectuées, le MTA peut transférer le mail à un autre MTA, permettant ainsi d’autres opérations. Il peut aussi transférer le mail au dernier intervenant de la livraison, le Mail Delivery Agent, s’il sait comment le contacter.

💡  Les enregistrements DNS de type MX (pour Mail eXchange) d’un domaine permettent d’identifier un MTA entrant (appelé aussi serveur MX) qui peut être utilisé pour router un courriel vers une adresse mail du domaine. Par exemple, un enregistrement @ 10800 IN MX 10 mail.example.com. indique un MTA à l’adresse mail.example.com, capable de router les mails aux adresses nom@example.com.

Le Mail Delivery Agent lors du dépôt en boite aux lettres

Le MDA (pour Mail Delivery Agent) est l’acteur final de la livraison qui se charge du dépôt en boite aux lettres du mail. Il peut également rencontrer une erreur en cas d’espace insuffisant, AKA de boite aux lettres pleine.

Le cheminement classique d’un email, pas à pas

Voyons à présent un cas concret d’acheminement de mail. Il s’agira d’un envoi de mail depuis un expéditeur fictif alice@fournisseur.com vers un destinataire bob@example.com.

Comme dans la partie précédente, on va commencer par un schéma de l’ensemble que l’on va décrire peu à peu.

Exemple d'acheminement d'un courriel par SMTP
Exemple d’acheminement de courriel via le protocole SMTP

1. L’émetteur saisit et envoie son mail dans son MUA

Alice a au préalable configuré correctement son client mail avec l’adresse de serveur de courrier sortant que son fournisseur d’accès indique dans sa documentation, et les informations d’identifiant utilisateur et mot de passe qui lui ont été fournies. Elle a bien rempli tous les champs du courriel, avec un expéditeur alice@fournisseur.com et un destinataire bob@example.com.

Le Mail User Agent (client mail) établit une connexion au Mail Submission Agent (serveur de courrier sortant) smtp.fournisseur.com sur le port 587 et communique avec lui selon le protocole SMTP.

2. Le mail est envoyé au MSA du fournisseur d’accès

Le Mail Submission Agent vérifie tout d’abord les informations d’authentification transmises par le client mail d’Alice. Comme elles sont correctes, il vérifie qu’il n’y a pas d’erreur dans les données du courriel. Tout va bien de ce côté aussi.

Il établit alors une connexion à un Mail Transfer Agent interne au fournisseur d’accès, localisé à l’adresse prerouting.smtp.fournisseur.com et transfère les informations du mail toujours via le protocole SMTP.

3. Le mail transite par des MTAs internes du fournisseur

Le Mail Transfer Agent interne prerouting analyse le mail pour vérifier qu’il n’est pas un courrier indésirable. Le test étant un succès, il poursuit l’analyse pour en déterminer les conditions de routage. Le mail est-il destiné à quelqu’un d’un domaine extérieur ? La réponse est oui, le destinataire étant bob@example.com. Il détermine alors que le MTA suivant à contacter est outgoing.smtp.fournisseur.com, en charge de la livraison des courriels extérieurs. Il s’y connecte et transfère les données du mail, toujours en respectant le protocole SMTP.

Le second MTA interne outgoing analyse le mail et repère que le destinataire est bob@example.com. Il consulte alors les enregistrements DNS du domaine example.com et découvre @ 10800 IN MX 10 mx.example.com.
Il sait alors qu’il existe un MTA entrant (un serveur MX) capable de router le mail à l’adresse mx.example.com sur le port standard 25. Il s’y connecte et transfère les informations du mail selon le protocole SMTP.

4. Le mail transite par le serveur MX du domaine destinataire

Le MTA entrant mx du domaine example.com vérifie tout d’abord que le mail s’adresse bien à une adresse email locale, ce qui est bien le cas (bob@example.com). Le routage étant autorisé, il le transfère à un MTA interne check.mx.example.com via une connexion SMTP.

5. Le mail transite par des MTAs internes du domaine destinataire

Le MTA interne check vérifie que le mail n’est pas un courrier indésirable et n’est pas bloqué par le destinataire. Comme ce n’est pas le cas, il remet le mail au Mail Delivery Agent capable de gérer la remise en boite aux lettres pour bob@example.com.

6. Le mail est remis au MDA du domaine destinataire

Le Mail Delivery Agent analyse le mail et trouve qu’il est destiné à bob@example.com. Il vérifie si la boite mail existe bien, et si elle n’est pas pleine. Tout va bien, il ajoute le mail dans la boite.

7. Le mail est déposé dans la boite aux lettres du destinataire

Bob n’a plus qu’à utiliser son propre client mail pour consulter le mail qu’il vient de recevoir. Il utilisera pour cela les protocoles POP ou IMAP.
Ca y est, c’est terminé !

Meme : The email has been sent

Alternative A : envoi depuis un site web

Le cas de l’envoi depuis un site internet (par exemple, la soumission d’un formulaire de contact) est identique, si ce n’est qu’au lieu de passer par un client mail, l’expédition se fait depuis un script du site. A part le MUA, le processus ne change donc pas.

Alternative B : envoi via prestataire (MSA sur domaine différent)

Lorsque le MSA est sur un domaine différent (par exemple un envoi de alice@fournisseur.com vers bob@example.com via un MSA du domaine prestataire.com), la logique est toujours la même, sauf que le MSA est dans un domaine tierce-partie. Il y aura certainement un cheminement au sein des MTAs de ce domaine, avant le passage au MTA d’entrée du domaine destinataire.

Cela signifie que pour le MTA d’entrée du domaine destinataire, la machine émettrice du mail appartient au domaine tierce-partie, pas au domaine de l’expéditeur du mail. C’est une différence importante pour certaines validations (par exemple le protocole SPF).

Alternative C : domaines expéditeur et destinataire identiques

Lorsque le domaine d’expédition est de destination sont identiques (par exemple un envoi de alice@example.com vers bob@example.com via un MSA du domaine example.com) le processus est similaire mais raccourci :

🔘  Il n’y a pas besoin d’interroger les enregistrements MX du domaine destinataire vu qu’il s’agit du même domaine et que normalement le MSA connait la configuration de ce dernier. C’est évidemment toujours possible en cas de besoin.

🔘  Le mail n’a pas besoin de quitter le domaine émetteur pour rejoindre le domaine de destination. Cela réduit les erreurs de communications éventuelles.

Pour aller plus loin dans l’acheminement des courriels

On me parle de serveur SMTP, où est-ce dans la chaine de livraison ?

C’est vrai que l’on n’a pas trop utilisé ce terme. La plupart des gens dans le milieu du web s’en servent alors autant l’aborder rapidement.

Techniquement un serveur SMTP est une partie d’un logiciel permettant de recevoir des connexions utilisant le protocole SMTP. Tout échange de mail entre 2 intervenants de la chaine basé sur ce protocole utilise un client SMTP chez celui qui transfère le courriel, et un serveur SMTP chez celui qui reçoit le courriel transféré. Un serveur SMTP peut donc soit être un MSA, soit un MTA.

Dans la pratique, les gens du web appellent serveur SMTP le serveur de courrier sortant, c’est à dire le MSA.

Mail Submission Agent et Mail Transfer Agent, quelles différences ?

Le MSA et le MTA partagent plusieurs similarités. Ils reçoivent des emails via le protocole SMTP et peuvent les transmettre à d’autres MTAs via ce même protocole. Il y a cependant des différences notables.

👉  Un MSA (serveur de courrier sortant) est soumis à authentification, afin de lutter contre le spam. Il peut cependant router les mails vers n’importe quel destinataire. Par exemple, un MSA mail.example.com peut tout à fait router du courrier vers un destinataire nom@autredomaine.com.
Les enregistrements DNS SRV indiquent l’adresse et le port des MSAs : _submission._tcp 10800 IN SRV 0 1 587 mail.example.com.
Les ports usuels des MSAs sont les ports 587, 465 et 2525.

👉  Un MTA d’entrée de domaine (serveur MX) n’est pas soumis à authentification. En contrepartie, il n’accepte de router que des mails vers des adresses locales au domaine. Par exemple, un serveur MX mail.example.com n’acceptera de router que les mails vers des adresses nom@example.com.
Les enregistrements DNS MX indiquent l’adresse des MTAs d’entrée : @ 10800 IN MX 10 mail.example.com.
Le port standard des MTAs est le port 25, qui est souvent bloqué chez les fournisseurs d’accès grand public.

👉  Un MTA intermédiaire est inaccessible depuis l’extérieur. Il n’est connu que dans son domaine, et est protégé derrière un firewall (pare-feu).

Puis-je obtenir le numéro de port depuis l’enregistrement DNS MX ?

Non, un enregistrement DNS Mail eXchange ne présente que l’adresse d’un MTA entrant d’un domaine, sans le numéro de port. Cela a pour conséquences :

🔘  Si un MTA écoute sur un port inconnu, alors il faut tester individuellement les ports jusqu’à trouver le bon. C’est non-envisageable dans le cadre de la livraison d’un courriel qui doit être rapide.

🔘  Si un MTA entrant d’un domaine doit pouvoir accepter du courrier envoyé depuis d’autres domaines, il doit écouter sur le port 25 qui est le standard. Si ce n’est pas le cas, les MTAs des autres domaines ne sauront pas comment le joindre.

Conclusion

On en sait un peu plus sur ce qui se passe lors d’un envoi de courrier. Enfin tout du moins sur le trajet parcouru, qui inclut plusieurs acteurs situés au sein de plusieurs domaines.

Dans un prochain article on verra plus en détails les échanges via connexion SMTP, les problématiques de protocole SPF et d’autres choses utiles.

D’ici là bon code, à la prochaine !

Références

RFC 5321 sur le protocole SMTP – Internet Engineering Task Force
RFC 6409 sur la séparation entre MTA et MSA – Internet Engineering Task Force

Photo de profil de Loïc Burtin Code Colibri développeur web à Dijon

A propos de l'auteur

Loïc Burtin

Développeur web indépendant, avec une tendance à couper les plumes en quatre pour que les sites se chargent plus rapidement.

Partagez cet article  =>