RFC 5598 – Architecture de la messagerie Internet

Informatif SMTP principal et Format de message Published March 2026

ELI5: Imaginez le courrier électronique comme un système de livraison de colis. Il y a la personne qui écrit la lettre (auteur), le bureau de poste local qui l'accepte (soumission), les centres de tri qui l'acheminent dans tout le pays (relais), et le bureau de poste local à destination qui la met dans votre boîte aux lettres (livraison). RFC 5598 nomme chaque acteur et processus de ce système afin que, lorsque d'autres RFC parlent de « l'MTA » ou du « MSA », tout le monde entend la même chose.

Pourquoi cette RFC existe

Avant la RFC 5598, la communauté du courrier électronique utilisait des termes comme « MTA », « relai » et « passerelle » de manière vague et incohérente. Différentes RFC utilisaient une terminologie différente pour les mêmes concepts. Cela a créé une véritable confusion, particulièrement quand des mécanismes d'authentification comme SPF, DKIM et DMARC avaient besoin de définitions précises de qui faisait quoi dans le chemin du message.

Publiée en 2009 par Dave Crocker, la RFC 5598 fournit un modèle architectural complet pour le courrier électronique Internet. Ce n'est pas une spécification de protocole — elle ne définit aucun nouveau format de fil ou commandes. Au lieu de cela, c'est un cadre de référence qui nomme et définit chaque acteur, rôle et fonction dans l'écosystème du courrier électronique. Presque chaque RFC moderne sur le courrier électronique référence la terminologie de 5598.

Comment ça marche

La RFC 5598 divise le système de courrier électronique en composants fonctionnels distincts organisés autour du parcours du message de l'auteur au destinataire.

Les quatre environnements principaux

L'architecture définit quatre environnements opérationnels par lesquels passe un message :

Environnement de l'agent utilisateur de courrier (MUA) : Où l'utilisateur compose et lit les messages. Votre client de courrier — Gmail, Outlook, Thunderbird, ou votre application appelant une API.
Environnement de l'agent de soumission de courrier (MSA) : Le service qui accepte les messages d'un MUA pour les livrer dans le système de courrier. Fonctionne sur le port 587 selon la RFC 6409, nécessite une authentification.
Environnement de l'agent de transfert de courrier (MTA) : L'infrastructure de routage centrale. Les MTA relaient les messages sur Internet en utilisant SMTP (RFC 5321) sur le port 25.
Environnement de l'agent de livraison de courrier (MDA) : Le système final qui place le message dans la boîte aux lettres du destinataire, le rendant accessible via IMAP, POP3 ou webmail.

Le flux de message

# Le cycle de vie d'un message électronique Auteur (MUA) --composer--> MSA --soumettre--> MTA --relayer--> MTA --livrer--> MDA --stocker--> Destinataire (MUA) # | | | | | # Compose le msg Authentifie, Achemine via Achemine via Stocke dans # avec en-têtes valide, requête DNS MX requête DNS MX la boîte # applique aux lettres aux lettres aux lettres # la politique

Acteurs et rôles clés

Acteur	Abréviation	Rôle
Agent utilisateur de courrier	MUA	Compose et affiche les messages pour l'utilisateur. Le client de courrier.
Agent de soumission de courrier	MSA	Accepte les messages des MUA authentifiés, applique la politique et les injecte dans l'infrastructure MTA.
Agent de transfert de courrier	MTA	Achemine et relaye les messages entre les domaines en utilisant SMTP. L'« épine dorsale » du courrier électronique.
Agent de livraison de courrier	MDA	Livraison finale dans la boîte aux lettres du destinataire. Peut appliquer des règles de filtrage.
Stockage de courrier	MS	Stocke les messages et fournit un accès via IMAP/POP3/JMAP.

Types d'identité

La RFC 5598 fait soigneusement la distinction entre les différentes identités associées à un message :

Identité	Où elle apparaît	Ce qu'elle signifie
Auteur	`From:` en-tête	La personne ou l'entité qui a écrit le message
Expéditeur	`Sender:` en-tête	L'agent qui a réellement transmis le message (quand différent de l'auteur)
Chemin de retour	`MAIL FROM` enveloppe / `Return-Path:` en-tête	Où les rebonds doivent être envoyés ; la partie responsable du transport
Destinataire	`RCPT TO` enveloppe / `To:`/`Cc:` en-têtes	Les destinataires prévus

Cette distinction est extrêmement importante pour l'authentification. SPF valide l'identité du chemin de retour. DKIM peut signer au nom de l'auteur ou d'un intermédiaire. DMARC aligne l'identité de l'auteur avec les résultats SPF et DKIM.

Détails techniques clés

Médiateurs

La RFC 5598 identifie une catégorie cruciale d'acteurs appelée médiateurs — des entités qui reçoivent un message et le republisent ensuite, le modifiant potentiellement en cours de route :

Liste de diffusion : Reçoit un message, ajoute des en-têtes de liste, modifie possiblement le sujet ou le corps, et redistribue aux abonnés. La liste devient le nouvel expéditeur MAIL FROM.
Passerelle : Convertit entre le courrier électronique et un autre système de messagerie (par exemple, courrier électronique vers SMS, courrier électronique vers télécopie).
Renvoyeur/Redistributeur : Transfère ou redistribue le courrier, comme les adresses d'anciens élèves qui transmettent.

Les médiateurs sont la raison principale pour laquelle l'authentification du courrier électronique est complexe. Quand une liste de diffusion change l'expéditeur de l'enveloppe et modifie le message, SPF échoue (la nouvelle IP de l'expéditeur n'est pas autorisée pour le domaine d'origine) et DKIM peut échouer (le corps a été modifié). C'est exactement le problème que ARC (RFC 8617) a été conçu pour résoudre.

ADMD : domaine de gestion administratif

La RFC 5598 introduit le concept d'une ADMD — la limite administrative d'une opération de courrier. Une ADMD est une organisation qui exploite un ou plusieurs services de courrier sous une seule autorité administrative. Exemples :

Une entreprise exécutant son propre serveur Exchange est une ADMD.
Gmail/Google Workspace est une ADMD.
Un service de courrier transactionnel comme MailerToGo est une ADMD.

Les messages franchissent les limites ADMD quand ils quittent l'infrastructure de courrier d'une organisation et entrent dans celle d'une autre. Les décisions d'authentification et de confiance se produisent à ces limites.

Enveloppe vs contenu

L'architecture formalise les deux couches de chaque message électronique :

Enveloppe : Les informations au niveau SMTP (MAIL FROM, RCPT TO) utilisées pour l'acheminement. Créées lors de la soumission et modifiées à chaque saut.
Contenu : Les en-têtes et le corps du message tels que définis par la RFC 5322. Destinés à être immuables après la composition, bien que les médiateurs puissent les modifier.

Erreurs courantes

Confondre MTA et MSA. Le MSA (port 587, authentifié) et le MTA (port 25, serveur à serveur) servent des objectifs différents. Envoyer un courrier d'application directement à un MTA distant sur le port 25 — en contournant un MSA — saute l'authentification et l'application de la politique. La plupart des fournisseurs cloud bloquent le port 25 sortant pour cette raison.
Ignorer le problème des médiateurs. Si vous appliquez strictement DMARC (p=reject) sans considérer que vos messages peuvent passer par des listes de diffusion, ces messages transférés seront rejetés à la destination. Comprendre le concept de médiateur vous aide à planifier cela.
Traiter From: comme l'expéditeur. L'en-tête From: identifie l'auteur, non l'expéditeur du transport. SPF vérifie l'expéditeur de l'enveloppe, non l'en-tête From. Cette distinction est toute la base de l'alignement DMARC.
Supposer une topologie plate. Les messages ne vont pas toujours directement de l'expéditeur au destinataire. Ils peuvent passer par plusieurs MTA, des listes de diffusion, des services de renvoi et des passerelles. Chaque saut peut modifier l'enveloppe et potentiellement le contenu.
Ne pas comprendre les limites ADMD. Quand vous déléguez l'envoi à un service de courrier, le message franchit une limite ADMD. SPF, DKIM et DMARC doivent être configurés pour tenir compte de cette délégation.

Impact sur la délivrabilité

Architecture de soumission appropriée. Utiliser un MSA (port 587 avec authentification) plutôt que d'injecter directement dans un MTA garantit que vos messages sont correctement authentifiés et conformes à la politique dès le départ. Des services comme MailerToGo agissent comme votre MSA.
Alignement de l'authentification. Comprendre quelle identité chaque mécanisme d'authentification vérifie — SPF vérifie le chemin de retour, DKIM signe au nom d'un domaine, DMARC aligne ceux-ci avec l'en-tête From — nécessite de comprendre le modèle d'identité de la RFC 5598.
Gestion du renvoi et des listes. Si vos destinataires utilisent des services de renvoi ou des listes de diffusion (médiateurs), vos messages peuvent échouer l'authentification à la destination finale. Comprendre le rôle du médiateur vous aide à diagnostiquer « pourquoi mon message passant DMARC a-t-il été rejeté ? »
Traitement des rebonds. L'architecture distingue entre l'auteur (en-tête From) et le chemin de retour (MAIL FROM). Les rebonds vont au chemin de retour. Si vous configurez correctement votre chemin de retour, vous pouvez traiter automatiquement les rebonds sans les confondre avec les réponses à l'auteur.