← RFC Reference

Le cycle de vie d'un e-mail

Du moment où vous cliquez sur « Envoyer » au moment où un message apparaît dans la boîte de réception de quelqu'un — chaque étape, chaque protocole, chaque décision en chemin.

Les acteurs

L'Internet Mail Architecture (RFC 5598) définit les rôles qui participent à la livraison des e-mails. Comprendre ces rôles est essentiel car un même logiciel joue souvent plusieurs rôles, et les limites entre eux sont importantes pour comprendre comment le courrier s'écoule.

En pratique, ces rôles sont souvent fusionnés. L'infrastructure de Gmail est simultanément MSA, MTA, MX, MDA et MRA. Postfix peut agir à la fois comme MSA et MTA. Mais les rôles logiques restent distincts, et les comprendre vous aide à déboguer les problèmes de livraison.

Étape 1 : Composition (MUA)

Le cycle de vie commence lorsqu'un utilisateur compose un message dans son client de messagerie, ou lorsqu'une application génère un message par programmation (via une API ou une bibliothèque SMTP).

Le MUA construit le message selon la RFC 5322 (Internet Message Format) :

Décisions clés à ce stade :

• L'en-tête From: identifie l'auteur au destinataire (et c'est ce que DMARC vérifie pour l'alignement).
• Le Message-ID: est généré — un identifiant globalement unique pour ce message spécifique.
• L'encodage MIME est appliqué : les pièces jointes sont codées en Base64, le corps est structuré en multipart si nécessaire.
• Le MUA n'ajoute pas d'en-têtes Received:. Ceux-ci sont ajoutés par chaque serveur qui traite le message.

Étape 2 : Soumission (MUA → MSA)

Le MUA se connecte au MSA (RFC 6409) pour remettre le message. C'est l'étape de soumission.

Ce que le MSA fait à la réception du message :

• Authentifie l'expéditeur. Le MUA doit fournir des identifiants valides (nom d'utilisateur/mot de passe via AUTH). C'est ce qui empêche les gens aléatoires d'utiliser votre serveur de messagerie comme relais ouvert.
• Valide l'enveloppe. Le MSA peut vérifier que le domaine MAIL FROM correspond au domaine de l'utilisateur authentifié.
• Ajoute un en-tête Received: Cela enregistre le premier saut : qui a soumis le message, quand et depuis quelle adresse IP.
• Peut ajouter ou corriger des en-têtes. Le MSA peut ajouter un en-tête Date: s'il manque, générer un Message-ID: si le MUA ne l'a pas fait, et ajouter des en-têtes DKIM-Signature.
• Met le message en file d'attente pour la livraison. Le message entre dans la file d'attente sortante du MTA.

Le chemin de soumission par API

Lorsque vous utilisez un service de messagerie transactionnelle comme Mailer To Go, votre application soumet généralement via une API HTTP plutôt que SMTP. Le serveur API accepte le message, construit l'enveloppe SMTP et les en-têtes, applique la signature DKIM et injecte le message dans la file d'attente du MTA. L'appel API remplace à la fois le MUA et la transaction SMTP MUA-MSA, mais tout ce qui en aval reste identique.

Étape 3 : Routage et transfert (MTA → MTA)

Le MTA d'envoi doit maintenant livrer le message au domaine du destinataire. C'est la phase de relais, régie par la RFC 5321 (SMTP).

Résolution DNS

Le MTA recherche les enregistrements MX pour le domaine du destinataire :

Il essaie d'abord le MX avec la plus basse priorité. Si ce serveur est inaccessible, il bascule vers le suivant. Voir DNS and Mail Routing pour l'algorithme complet, incluant le basculement vers les enregistrements A/AAAA et la gestion Null MX.

Le transfert

À ce stade :

• STARTTLS chiffre la connexion. Sans MTA-STS ou DANE, le MTA d'envoi bascule vers du texte en clair si la négociation TLS échoue. C'est un risque de sécurité — un attaquant actif peut retirer TLS de la connexion.
• Aucune authentification (AUTH) n'est utilisée. Le SMTP serveur-à-serveur sur le port 25 n'exige pas de qualificatifs. Le serveur récepteur s'appuie sur l'adresse IP, SPF, DKIM et DMARC pour vérifier l'expéditeur.
• Un autre en-tête Received: est ajouté. Chaque MTA ajoute un en-tête Received: au début, construisant une chaîne qui documente le chemin du message.
• Le message peut passer par plusieurs MTA. Le routage interne dans les grandes organisations, les règles de forwarding et les listes de diffusion peuvent ajouter des étapes supplémentaires.

Mise en file d'attente et nouvelles tentatives

Si le MX récepteur retourne une erreur temporaire 4xx (serveur occupé, greylisting, limite de débit), le MTA d'envoi met le message en file d'attente et essaie plus tard. Les calendriers de nouvelles tentatives utilisent généralement un backoff exponentiel : 15 minutes, 30 minutes, 1 heure, 2 heures, etc. Si le message ne peut pas être livré après la période de nouvelle tentative (généralement 4–5 jours), le MTA génère un message de rebond (DSN) et l'envoie à l'expéditeur de l'enveloppe.

Étape 4 : Réception (MX)

Le MX récepteur (le MTA qui accepte le courrier entrant pour le domaine du destinataire) est l'endroit où la plupart du filtrage se produit. C'est le gardien.

Au moment de la connexion, avant l'arrivée de tout contenu du message :

• Vérification de la réputation IP. Le MX récepteur vérifie l'adresse IP de connexion par rapport à sa base de données de réputation interne et aux listes de blocage externes.
• Vérification DNS inversée. L'adresse IP devrait avoir un enregistrement PTR valide qui se résout à la même adresse IP.
• Limitation de débit. Les connexions excessives depuis la même adresse IP peuvent être limitées.

Pendant la phase d'enveloppe :

• Validation du destinataire. La boîte aux lettres existe-t-elle ? Sinon : 550 5.1.1 User unknown.
• Vérification SPF. Le domaine MAIL FROM est vérifié par rapport à son enregistrement SPF pour vérifier que l'adresse IP d'envoi est autorisée.

Après DATA (le message complet est reçu) :

• Vérification DKIM. La signature DKIM est validée par rapport à la clé publique dans DNS.
• Évaluation DMARC. Les résultats SPF et DKIM sont vérifiés pour l'alignement DMARC avec l'en-tête From:.
• Filtrage de contenu. Le message passe par les filtres anti-spam : analyse de contenu, vérification d'URL, classification bayésienne, modèles d'apprentissage automatique.
• En-tête Authentication-Results ajouté. Le MX enregistre les résultats de tous les contrôles d'authentification dans un en-tête Authentication-Results.

Étape 5 : Livraison (MDA)

L'agent de livraison de courrier prend le message qui a passé le filtrage et le dépose dans la boîte aux lettres du destinataire. Dans de nombreux systèmes, le MDA est intégré au serveur MX plutôt que d'être un processus séparé.

Les responsabilités du MDA :

• Sélection de la boîte aux lettres. Déterminer quelle boîte aux lettres (compte utilisateur) reçoit le message en fonction de l'adresse RCPT TO, des alias et des règles de routage.
• Placement dans les dossiers. En fonction du verdict du filtre anti-spam et des règles définies par l'utilisateur, le message va dans la boîte de réception, le dossier Spam/Indésirables, un libellé spécifique (Gmail) ou un dossier personnalisé (règles Sieve).
• Filtrage Sieve. De nombreux systèmes de messagerie prennent en charge Sieve (RFC 5228), un langage pour les règles de filtrage de courrier définies par l'utilisateur. Les règles peuvent classer les messages dans des dossiers, les transférer, les rejeter ou déclencher des réponses de vacances automatiques.
• Application de quota. Si la boîte aux lettres est pleine, le MDA peut rejeter le message avec 452 4.2.2 Mailbox full ou 552 5.2.2 Mailbox full.
• Notification. Le MDA peut déclencher une notification push sur les appareils de l'utilisateur (alerte de nouveau courrier).

À ce stade, le message est au repos dans le magasin de messagerie du destinataire. La transaction SMTP est terminée. La responsabilité du MTA d'envoi s'est terminée lorsqu'il a reçu le 250 OK du MX récepteur.

Étape 6 : Récupération (MRA → MUA)

Le client de messagerie du destinataire récupère le message du magasin de messagerie à l'aide de l'un des trois protocoles :

IMAP (RFC 9051)

Le protocole d'accès au courrier dominant. IMAP conserve les messages sur le serveur et synchronise l'état (lu/non lu, drapeaux, dossiers) entre plusieurs clients. Le client télécharge d'abord les en-têtes du message et récupère les corps complets à la demande. Les modifications apportées sur un client (marquer comme lu, déplacer dans un dossier) se reflètent sur tous les clients.

POP3 (RFC 1939)

Le protocole plus ancien et plus simple. POP3 télécharge les messages vers le client et (par défaut) les supprime du serveur. Il ne synchronise pas l'état entre les clients. Largement supplanté par IMAP, mais toujours utilisé dans certains scénarios.

Accès Web et API

Les interfaces de webmail (Gmail, Outlook.com) et les applications mobiles accèdent au magasin de messagerie via des API propriétaires ou JMAP (RFC 8620), contournant entièrement IMAP/POP3. Le message ne quitte jamais les serveurs du fournisseur — le client l'affiche via une requête web.

Où les choses tournent mal : Modes de défaillance à chaque étape

Échecs de soumission

L'authentification échoue (mauvais mot de passe, jeton expiré), le MSA rejette le message (dépassement de la limite de taille, violation de politique) ou la connexion expire. L'utilisateur voit immédiatement une erreur.

Échecs de routage

La résolution DNS échoue (pas d'enregistrements MX, expiration de DNS), tous les hôtes MX sont inaccessibles ou chaque MX retourne une erreur permanente. Après épuisement des nouvelles tentatives, l'expéditeur reçoit un rebond (DSN).

Rejet au moment de la réception

Le MX récepteur rejette le message au moment de SMTP : adresse IP bloquée (550), authentification échouée (550 5.7.1), destinataire inconnu (550 5.1.1) ou rejet de contenu (554). Le MTA d'envoi génère une notification de rebond à l'expéditeur de l'enveloppe.

Filtrage post-acceptation

Le MX a accepté le message (250 OK) mais le MDA le route vers le dossier spam en fonction de l'analyse de contenu et du score de réputation. L'expéditeur ne reçoit pas de rebond — le message a été techniquement « livré » — mais le destinataire ne le voit jamais. C'est le problème de livrabilité le plus courant et le plus difficile à diagnostiquer.

Boîte aux lettres pleine

La boîte aux lettres du destinataire est pleine. Selon l'implémentation, c'est soit un rejet au moment de RCPT TO, soit un rebond généré après acceptation de DATA.

Les en-têtes racontent l'histoire

Chaque étape du cycle de vie ajoute des en-têtes au message. Lire les en-têtes de bas en haut reconstitue le voyage :

Les en-têtes Received: sont les miettes de pain. Chacun enregistre l'hôte d'envoi, l'hôte récepteur, le protocole utilisé (ESMTP, ESMTPS pour TLS, ESMTPSA pour authentifié+TLS), un ID de file d'attente et un horodatage. Voir Anatomy of Email Headers pour un guide complet.

Le chemin de la messagerie transactionnelle

Lorsqu'une application envoie du courrier via un service comme Mailer To Go, le cycle de vie est légèrement différent :

1. L'application appelle l'API. Votre application envoie une requête POST avec le contenu du message, les destinataires et les métadonnées.
2. Le service construit le message. Il construit la structure MIME, ajoute les en-têtes requis (Date, Message-ID, List-Unsubscribe si applicable) et applique la signature DKIM avec la clé de votre domaine.
3. Le MTA du service envoie le message. Le message est envoyé depuis l'adresse IP du service vers le MX du destinataire via SMTP sur le port 25, avec STARTTLS.
4. Le reste est identique. La réception MX, les contrôles d'authentification, le filtrage de contenu, la livraison MDA et la récupération client procèdent tous comme décrit ci-dessus.

La différence clé : votre application ne parle jamais directement SMTP. L'API abstrait la couche d'envoi entière. Mais le message traverse toujours la même infrastructure, subit les mêmes contrôles d'authentification et est évalué par les mêmes filtres anti-spam.

Points clés à retenir

• La messagerie électronique a six étapes distinctes : composition, soumission, transfert, réception, livraison et récupération. Chaque étape implique différents protocoles et différents acteurs.
• L'enveloppe et le message sont séparés. MAIL FROM / RCPT TO (l'enveloppe) peuvent différer de From: / To: (le message). Cette distinction compte pour l'authentification, les rebonds et Bcc.
• La plupart du filtrage se produit à la réception. Le MX récepteur est l'endroit où l'authentification, la réputation et le contenu sont évalués. C'est l'étape qui détermine la boîte de réception ou le spam.
• Un 250 OK signifie accepté, pas livré dans la boîte de réception. Le MX récepteur peut toujours router le message vers le spam, ou le MDA peut le rejeter plus tard (boîte aux lettres pleine, règles Sieve).
• Les en-têtes Received: documentent le voyage. Lisez-les de bas en haut pour tracer le chemin d'un message. C'est l'outil de débogage le plus utile pour les problèmes de livraison.
• Chaque saut ajoute de la latence et du risque. Plus de sauts signifie plus de chances d'échec, de retard ou de modification de contenu (ce qui peut casser les signatures DKIM).

Lectures supplémentaires

Related RFCs