Le parcours d'un e-mail

Module 1: Comment fonctionne l'e-mail · Temps de lecture : 9 minutes

Objectif pédagogique : À l'issue de cette leçon, vous pourrez décrire étape par étape comment un e-mail arrive de l'expéditeur au destinataire, et indiquer à chaque étape quel programme ou quel serveur effectue le travail.

Notions clés : programme de messagerie (MUA), serveur d'envoi (MSA, submission), serveur de messagerie (MTA), enregistrement MX, file d'attente, remise (MDA), boîte mail, récupération (IMAP/POP3), enveloppe, en-têtes

Le courrier électronique, c'est comme la poste, pas un message de chat

Quand vous envoyez un message de chat, il passe par une seule entreprise : l'application de l'expéditeur et celle du destinataire communiquent avec les mêmes serveurs. L'e-mail fonctionne différemment. L'expéditeur et le destinataire peuvent chacun se trouver chez un fournisseur différent : l'un chez un hébergeur, l'autre chez Gmail, un troisième chez Microsoft 365 ou sur le serveur de sa propre entreprise. Pourtant, l'e-mail arrive à destination. Cela fonctionne parce que tous les serveurs de messagerie du monde suivent les mêmes règles.

On peut très bien comparer l'e-mail au courrier postal. Vous écrivez une lettre (le message), vous la glissez dans une enveloppe avec une adresse (l'enveloppe), vous la déposez dans la boîte aux lettres (le serveur d'envoi), la société postale détermine où se trouve l'adresse (la recherche MX), achemine la lettre vers le bon centre de tri (le serveur de messagerie destinataire), qui la dépose dans la boîte aux lettres du destinataire (la boîte mail). Le destinataire vient la chercher quand cela lui convient.

Les étapes en détail

Imaginons qu'Anna envoie un e-mail depuis anna@example.com vers jan@example.net. Voici ce qui se passe :

Chez les petits fournisseurs, le MSA, le MTA et le MDA sont souvent un seul et même programme sur un seul serveur. Chez les grands fournisseurs, ce sont des clusters distincts. Pour vous, cela ne change pas grand-chose : ce sont des rôles, pas des boîtiers.

Remarquez la différence entre l'étape 1 et l'étape 4. Les deux utilisent SMTP, le Simple Mail Transfer Protocol (RFC 5321). Mais à l'étape 1, vous vous connectez et utilisez le port 587 ou 465 : on appelle cela la submission (RFC 6409). À l'étape 4, deux serveurs communiquent entre eux sur le port 25, sans authentification : le serveur destinataire accepte le courrier pour ses propres domaines, quel que soit l'expéditeur. Dans la leçon 1.4, vous découvrirez pourquoi cette séparation existe.

Étape 3 en détail : la recherche MX

Le serveur expéditeur ne sait pas de lui-même où example.net reçoit son courrier. Il interroge le DNS :

example.net.   3600  IN  MX  10 mx1.mailprovider.example.
example.net.   3600  IN  MX  20 mx2.mailprovider.example.

Le nombre le plus bas a la priorité. Le serveur essaie d'abord mx1, et si celui-ci ne répond pas, mx2. Il interroge ensuite l'adresse IP correspondant à ce nom (enregistrement A ou AAAA) et établit la connexion.

Deux cas particuliers que vous pouvez rencontrer dans la pratique :

• Aucun enregistrement MX. L'expéditeur essaie alors l'enregistrement A ou AAAA du domaine lui-même (le « MX implicite » décrit dans la RFC 5321, paragraphe 5.1). Il s'agit d'un vestige du passé qui ne fonctionne pas de manière fiable ; tout domaine recevant du courrier devrait disposer d'un enregistrement MX.
• Un null MX : 0 . Cela signifie : « ce domaine ne reçoit jamais de courrier » (RFC 7505). Le domaine example.com en possède un. L'expéditeur abandonne immédiatement et renvoie un message d'erreur, au lieu de continuer à essayer pendant des jours.

Vous trouverez le fonctionnement précis des enregistrements MX et des priorités dans la leçon 4.1 du cours DNS.

La file d'attente : l'e-mail peut prendre un peu de temps

Un e-mail n'arrive pas toujours en une seconde. Si le serveur destinataire ne répond pas, ou indique « réessayez plus tard » (un code commençant par un 4), l'e-mail reste dans la file d'attente du serveur d'envoi. Celui-ci réessaie plus tard, en espaçant de plus en plus les tentatives. La RFC 5321 (paragraphe 4.5.4.1) recommande d'attendre au moins 30 minutes entre les tentatives et de n'abandonner qu'après 4 à 5 jours. De nombreux serveurs envoient après quelques heures un avertissement préalable (« delayed », pas encore remis) puis, après quelques jours, le message d'erreur définitif.

C'est l'un des grands atouts de l'e-mail : si un serveur de messagerie est en panne pendant une heure, aucun courrier n'est perdu. C'est aussi pour cette raison qu'un e-mail arrive parfois seulement plusieurs heures plus tard. Dans le module 6, vous verrez comment reconnaître ce type de retard.

Enveloppe et en-têtes : deux adresses

Comme pour le courrier postal, un e-mail comporte deux types d'adresses :

• L'enveloppe. Ce sont les adresses que les serveurs utilisent entre eux au cours de l'échange SMTP : MAIL FROM (l'expéditeur pour les messages d'erreur, visible ensuite sous le nom Return-Path) et RCPT TO (le destinataire). Les serveurs remettent le courrier en se basant sur l'enveloppe.
• Les en-têtes (headers). C'est ce qui figure dans la lettre elle-même : From:, To:, Cc:, Subject:, Date:. C'est ce que votre programme de messagerie affiche.

En général, ces adresses sont identiques, mais pas toujours. Un destinataire en Cci figure bien dans l'enveloppe, mais pas dans les en-têtes ; c'est pourquoi les autres destinataires ne le voient pas. Un service de newsletter met sa propre adresse comme expéditeur dans l'enveloppe, afin que les messages d'erreur lui soient adressés, tandis que c'est votre adresse qui figure dans le champ From:. Et un fraudeur peut mettre ce qu'il veut dans le champ From:.

Pourquoi cela importe : SPF vérifie l'expéditeur de l'enveloppe, l'utilisateur voit le champ From:. C'est la raison d'être de DMARC, qui relie ces deux éléments (module 4).

Où cela peut mal tourner

Grâce à ce schéma, vous pouvez vous demander, pour chaque problème, à quelle étape cela coince.

• L'envoi échoue (message d'erreur immédiat dans votre programme) : étape 1 ou 2. Il s'agit presque toujours d'un paramétrage : port, authentification, mot de passe (module 2).
• Vous recevez un bounce : étape 4 ou 5. Le serveur destinataire a refusé l'e-mail, ou l'adresse n'existe pas (module 6).
• L'e-mail arrive, mais dans le dossier spam : étape 5. Le destinataire ne fait pas confiance à l'e-mail (modules 4 et 5).
• Le destinataire ne voit rien, et vous ne recevez aucun message d'erreur : l'e-mail est peut-être encore dans une file d'attente, ou a été filtré silencieusement chez le destinataire. Les journaux du serveur d'envoi sont alors utiles (module 6).
• Aucun courrier n'arrive pour votre domaine : étape 3. Les enregistrements MX sont incorrects, par exemple après un déménagement (module 8).

En pratique : à quoi cela ressemble avec un pack d'hébergement

Avec un pack d'hébergement WebOké, un seul serveur par pack assume tous les rôles : votre programme de messagerie remet l'e-mail à ce serveur (étapes 1 et 2), le serveur l'envoie vers l'extérieur (étapes 3 et 4) et reçoit le courrier pour votre domaine (étape 5). Dans DirectAdmin, vous pouvez utiliser Suivi des e-mails pour voir, message par message, s'il a été remis. Chez d'autres fournisseurs, le fonctionnement est comparable ; cette fonctionnalité s'y appelle par exemple « suivi des messages » ou « mail log ».

Résumé

• Un e-mail va de votre programme de messagerie (MUA), via le serveur d'envoi (MSA/MTA), jusqu'au serveur destinataire (MTA/MDA), puis jusqu'au programme de messagerie du destinataire.
• L'envoi depuis votre programme se fait en SMTP-submission avec authentification (587/465) ; les serveurs communiquent entre eux en SMTP sur le port 25 ; la récupération se fait via IMAP ou POP3.
• Le serveur expéditeur recherche les enregistrements MX du domaine situé après le @. Un null MX (0 .) signifie : ce domaine ne reçoit pas de courrier.
• Un e-mail qui ne peut pas être remis immédiatement reste dans la file d'attente et de nouvelles tentatives sont effectuées pendant plusieurs jours.
• L'enveloppe (Return-Path) et les en-têtes (From) correspondent à deux expéditeurs différents. SPF examine le premier, l'utilisateur le second.

Quiz

Exercice

Exercice Z1.1 : Trouver le premier serveur de messagerie. Recherchez les enregistrements MX de gmail.com (ou de votre propre domaine). Indiquez quel serveur est essayé en premier, avec son numéro de priorité, et une adresse IP (IPv4 ou IPv6) de ce serveur. Le programme interroge les mêmes données en direct et vérifie votre réponse.

Pour aller plus loin

Les étapes décrites dans ces articles valent pour les panneaux de WebOké ; chez d'autres fournisseurs, le fonctionnement est comparable.

• Explication du processus d'envoi des e-mails / SMTP
• Guide DirectAdmin 8.7: IMAP ou POP3 : quelle est la différence ?
• Cours DNS gratuit 4.1: Enregistrements MX et priorité
• RFC 5321 (SMTP), paragraphe 5.1 (MX et MX implicite) et 4.5.4.1 (nouvelles tentatives) ; RFC 7505 (null MX)