RFC 6532 – En-têtes de courrier électronique internationalisés

Norme proposée SMTP principal et format de message Obsoletes RFC 5322 Published March 2026

ELI5: Avant cette RFC, si vous vouliez écrire un nom comme « Müller » ou une ligne d'objet en japonais dans un en-tête d'email, vous deviez l'encoder en un charabia illisible comme `=?UTF-8?B?...?=`. La RFC 6532 dit « utilisez simplement UTF-8 directement ». La ligne From peut dire `田太郎 ` en texte brut, et l'objet peut être dans n'importe quelle langue sans astuces d'encodage. L'email a la même apparence sur le fil que sur l'écran.

Pourquoi ce RFC existe

Le format original des messages électroniques (RFC 5322) limite les champs d'en-tête aux caractères US-ASCII. Pour inclure du texte non-ASCII dans les en-têtes comme Objet, les noms d'affichage De, ou les commentaires d'adresse, les expéditeurs devaient utiliser les mots codés de RFC 2047 — un système encombrant qui code en Base64 ou Q-encode le texte et l'enveloppe dans les marqueurs =?charset?encoding?...?=.

Ce système fonctionne mais produit des en-têtes illisibles sous leur forme brute, difficiles à implémenter correctement, et limités dans leurs emplacements possibles. Par exemple, les mots codés RFC 2047 ne peuvent pas être utilisés dans la partie locale d'une adresse électronique.

RFC 6532 met à jour RFC 5322 pour permettre UTF-8 directement dans les en-têtes de courrier électronique. Combiné avec RFC 6531 (SMTPUTF8 pour l'enveloppe SMTP), cela permet un courrier électronique complètement internationalisé où les adresses, les noms d'affichage, les sujets et autres en-têtes peuvent tous utiliser des scripts natifs sans contournement de codage.

Comment ça marche

Le message est transmis via SMTP avec l'extension SMTPUTF8 (RFC 6531), signalant que le message utilise du contenu internationalisé.
Les champs d'en-tête peuvent contenir des octets UTF-8 bruts partout où RFC 5322 autorise le texte.
Les adresses électroniques dans les en-têtes (De, À, Cc, Répondre-À) peuvent contenir des caractères UTF-8 dans la partie locale et la partie domaine.
Le Content-Type pour le bloc d'en-tête du message est implicitement message/global (défini dans RFC 6532) au lieu du traditionnel message/rfc822.
Les clients de messagerie récepteurs qui supportent RFC 6532 affichent les en-têtes nativement. Les clients qui ne le supportent pas peuvent afficher des octets UTF-8 bruts ou échouer à analyser les en-têtes.

Exemples d'en-têtes

En-têtes codés RFC 2047 traditionnels vs. en-têtes RFC 6532 :

# Ancien façon : mots codés RFC 2047 (illisibles sur le fil) From: =?UTF-8?B?w4ltaWxpZSBEdXBvbnQ=?= <emilie@example.fr> Subject: =?UTF-8?B?5Lya6K2w44Gu56K66KqN?= To: =?UTF-8?B?5bGx55Sw5aSq6YOO?= <taro@example.jp> # Nouveau façon : RFC 6532 avec UTF-8 brut (lisible par l'homme) From: Émilie Dupont <émilie@exemple.fr> Subject: 会議の確認 To: 田太郎 <田太郎@例.jp>

Un message complètement internationalisé :

From: 田太郎 <田太郎@例.jp> To: Émilie Dupont <émilie@exemple.fr> Subject: 会議の確認 Date: Wed, 11 Mar 2026 19:00:00 +0900 Message-ID: <20260311.001@例.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 来週の会議を確認します。

Détails techniques clés

message/global vs. message/rfc822

RFC 6532 introduit un nouveau type MIME : message/global. Ceci est fonctionnellement identique à message/rfc822 mais signale que le message peut contenir UTF-8 dans les en-têtes. Lorsqu'un message est transmis avec SMTPUTF8, les messages attachés et les messages transférés doivent utiliser message/global au lieu de message/rfc822 :

Type MIME	Codage des en-têtes	Utilisation
`message/rfc822`	ASCII uniquement (RFC 2047 pour non-ASCII)	Courrier électronique traditionnel
`message/global`	UTF-8 autorisé nativement	Courrier électronique internationalisé

Où UTF-8 est autorisé

RFC 6532 permet UTF-8 dans tous les emplacements de champs d'en-tête où RFC 5322 autorise le texte :

Noms d'affichage : From: 田太郎 <taro@example.jp>
Parties locales d'adresse : To: <田太郎@example.jp>
Noms de domaine : Cc: <user@例.jp>
Champs non structurés : Subject: 会議の確認
Commentaires : From: user@example.com (山田太郎)

Considérations de signature DKIM

Les signatures DKIM couvrent des en-têtes spécifiques. Lorsque ces en-têtes contiennent UTF-8 brut, le processus de signature et de vérification doit gérer correctement les octets. La balise DKIM h= liste les en-têtes à signer, et la canonicalisation s'applique aux octets UTF-8 bruts. L'expéditeur et le vérificateur doivent traiter la même séquence d'octets pour que les signatures correspondent.

Compatibilité rétroactive

Les messages RFC 6532 ne sont pas compatibles avec les systèmes de messagerie qui ne comprennent que RFC 5322. Un serveur ou un client qui reçoit un message message/global mais ne supporte pas RFC 6532 peut :

Afficher des octets UTF-8 bruts (que la plupart des clients modernes traitent raisonnablement bien)
Échouer à analyser les en-têtes d'adresse contenant des caractères non-ASCII
Casser la vérification DKIM si l'implémentation ne gère pas les en-têtes UTF-8

Erreurs courantes

Utiliser des en-têtes RFC 6532 sans SMTPUTF8 dans l'enveloppe. Si la session SMTP n'a pas utilisé le paramètre SMTPUTF8, le message doit utiliser des mots codés RFC 2047 pour le contenu d'en-tête non-ASCII. Les en-têtes RFC 6532 ne sont valides que s'ils sont envoyés via RFC 6531.
Mélanger RFC 2047 et UTF-8 brut dans le même en-tête. Choisissez une approche par message. Si vous envoyez via SMTPUTF8, utilisez UTF-8 brut. Sinon, utilisez RFC 2047 partout. Les mélanger crée une ambiguïté d'analyse.
Utiliser message/rfc822 pour les pièces jointes internationalisées. Lors du transfert ou de l'attachement d'un message qui contient des en-têtes UTF-8, utilisez message/global comme type MIME, pas message/rfc822.
Ignorer la normalisation Unicode. Le même caractère visuel peut avoir plusieurs représentations d'octets en Unicode. Utilisez la normalisation NFC de manière cohérente pour les adresses de messagerie et le contenu des en-têtes pour éviter les défaillances de correspondance et de vérification.
Supposer que tous les clients de messagerie restituent correctement UTF-8. Bien que les clients modernes gèrent bien UTF-8, certains clients plus anciens ou embarqués peuvent ne pas le faire. Pour les e-mails transactionnels critiques, considérez si votre audience comprend des utilisateurs sur des systèmes hérités.
Casser DKIM en modifiant les en-têtes UTF-8 en transit. Certains systèmes de traitement de courrier normalisent ou réencodent le texte UTF-8. Toute modification d'un en-tête signé par DKIM, même la modification de la forme de normalisation Unicode, invalide la signature.

Impact sur la délivrabilité

Meilleur affichage pour les destinataires internationaux. Les noms d'affichage et les sujets en script natif paraissent professionnels et dignes de confiance. Le charabia d'encoded-word dans les en-têtes peut confondre les destinataires et déclencher la suspicion.
DKIM doit gérer correctement UTF-8. Si votre implémentation DKIM signe des en-têtes UTF-8 et le vérificateur les traite différemment (normalisation différente, codage différent), la signature échoue. Cela impacte directement l'alignement DMARC et la délivrabilité.
Soutien croissant du fournisseur. Gmail, Outlook.com et d'autres grands fournisseurs supportent les en-têtes RFC 6532. Les messages avec des en-têtes UTF-8 propres sont affichés correctement par ces fournisseurs.
Requis pour les adresses complètement internationalisées. Vous ne pouvez pas avoir une adresse électronique internationalisée sans en-têtes RFC 6532. À mesure que l'adoption EAI augmente, le support de ce RFC devient essentiel pour atteindre les utilisateurs mondiaux.
La stratégie de secours compte. Pour une délivrabilité maximale, générez à la fois une version message/global (pour les serveurs compatibles SMTPUTF8) et une version rétrogradée RFC 2047 (pour les autres). Votre infrastructure d'envoi doit choisir en fonction des capacités du destinataire.