RFC 2049 : MIME Partie 5 — Critères de conformité et exemples

Voie de normalisation MIME — Extensions Multipurposes Internet Mail Published March 2026

ELI5: Les RFC 2045-2047 définissent les règles MIME. La RFC 2049 est l'examen : elle énonce précisément ce que votre logiciel doit faire pour être conforme à MIME et fournit des exemples travaillés pour vérifier votre implémentation. Si MIME était un code du bâtiment, ce serait la liste de contrôle d'inspection.

Pourquoi cela existe

La spécification MIME s'étend sur quatre RFC techniques (2045, 2046, 2047, et 2048). Les implémenteurs ont besoin d'une réponse claire à : « quel est le minimum que mon logiciel doit gérer pour être conforme à MIME ? » RFC 2049 fournit cette réponse, ainsi que des messages de test canoniques que les implémenteurs peuvent utiliser pour vérifier leurs analyseurs.

Sans document de conformité, différentes implémentations supporteraient différents sous-ensembles de MIME, entraînant des défaillances d'interopérabilité. RFC 2049 établit le minimum : chaque système conscient de MIME doit au moins gérer ces types de contenu, encodages et structures.

Comment cela fonctionne

RFC 2049 définit deux niveaux de conformité, chacun avec des exigences spécifiques.

Exigences de l'agent d'envoi

Un agent d'envoi conforme à MIME (MUA ou bibliothèque de courrier) doit :

Toujours inclure MIME-Version: 1.0 dans chaque message qui utilise des fonctionnalités MIME.
Inclure un en-tête Content-Type quand le corps est autre que du texte ASCII simple.
Utiliser un Content-Transfer-Encoding valide qui garantit que le corps du message peut survivre au transport par des passerelles SMTP 7 bits (base64 ou quoted-printable pour le contenu non-ASCII).
Encoder correctement les champs d'en-tête en utilisant les mots codés RFC 2047 quand des caractères non-ASCII apparaissent dans des en-têtes comme Subject ou les noms d'affichage From.
Générer des délimiteurs multipart valides qui n'apparaissent dans aucune partie du corps incluse.

Exigences de l'agent de réception

Un agent de réception conforme à MIME doit :

Reconnaître MIME-Version: 1.0 et traiter le message comme encodé en MIME.
Analyser les en-têtes Content-Type et Content-Transfer-Encoding, y compris tous les paramètres.
Décoder base64 et quoted-printable encodages de transfert de contenu.
Gérer tous les types multipart — au minimum multipart/mixed, multipart/alternative, multipart/digest, et multipart/parallel. Les sous-types multipart inconnus doivent être traités comme multipart/mixed.
Gérer message/rfc822 — afficher le message encapsulé ou au moins le proposer pour enregistrement.
Gérer les types de contenu non reconnus avec grâce — proposer d'enregistrer la partie du corps en tant que fichier plutôt que de crasher ou de la supprimer silencieusement. Les types non reconnus doivent être traités comme application/octet-stream.
Décoder les mots codés RFC 2047 dans les champs d'en-tête.
Gérer le paramètre charset sur les types texte, supportant au minimum US-ASCII et ISO-8859-1, et idéalement UTF-8.

Principe de robustesse

RFC 2049 réaffirme la loi de Postel pour MIME : être strict dans ce que vous envoyez, libéral dans ce que vous acceptez. Un récepteur conforme doit faire un meilleur effort pour afficher même des messages MIME légèrement malformés plutôt que de les rejeter d'emblée.

Détails techniques clés

Exemples canoniques

RFC 2049 inclut des exemples développés de messages MIME. Voici le schéma pour un message multipart/alternative bien formé avec du texte brut et du HTML :

MIME-Version: 1.0
From: sender@example.com
To: recipient@example.com
Subject: MIME conformance test
Content-Type: multipart/alternative; boundary="boundary42"

--boundary42
Content-Type: text/plain; charset=us-ascii

This is the plain text version.

--boundary42
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><body><p>This is the <strong>HTML</strong> version.</p></body></html>

--boundary42--

Gestion des types inconnus

Une exigence de conformité clé : quand un agent de réception rencontre un Content-Type qu'il ne comprend pas, il doit le traiter comme application/octet-stream et proposer de l'enregistrer. Cette règle assure la compatibilité prospective — de nouveaux types de médias peuvent être définis sans casser les clients existants.

; Type inconnu rencontré par un client
Content-Type: application/vnd.custom-format
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="data.custom"

; Le client conforme traite ceci comme application/octet-stream
; et propose à l'utilisateur un dialogue « Enregistrer sous »

Sous-types multipart inconnus

De même, les sous-types multipart inconnus doivent être traités comme multipart/mixed. Cela signifie que le client affiche chaque partie séquentiellement. Par exemple, multipart/report (défini plus tard dans RFC 3462) s'affichera toujours correctement dans les anciens clients qui le traitent comme mixte.

Support minimal de charset

Les implémentations conformes doivent supporter au minimum :

US-ASCII — la base
ISO-8859-1 — caractères d'Europe occidentale (Latin-1)

En pratique, toute implémentation moderne doit supporter UTF-8. Ne pas le faire en 2024+ est un manquement à la conformité par essence, même si la spécification de 1996 ne l'exigeait pas.

La limite MIME/non-MIME

Les messages sans en-tête MIME-Version: 1.0 sont traités comme du texte ASCII brut pré-MIME, indépendamment du fait qu'ils contiennent accidentellement des en-têtes Content-Type. L'en-tête MIME-Version est le gardien : sans lui, le traitement MIME ne s'active pas.

Erreurs courantes

Planter sur les Content-Types inconnus. La spécification est explicite : traiter les types inconnus comme application/octet-stream. Les bibliothèques qui lèvent des exceptions sur les types inconnus ne sont pas conformes et se casseront à mesure que de nouveaux types de médias seront enregistrés.
Traiter les sous-types multipart inconnus comme des erreurs. Ils doivent être traités comme multipart/mixed. Un bogue courant est de rejeter ou d'ignorer multipart/report, multipart/signed, ou d'autres types d'extension.
Ignorer le charset sur les types text/*. Le contenu texte sans déclaration de charset dépend par défaut de US-ASCII. L'afficher comme UTF-8 peut fonctionner pour le contenu ASCII mais produira une sortie garbled pour les messages ISO-8859-1 hérités.
Supprimer MIME-Version des messages transférés. Lors du transfert ou du renvoi, l'en-tête MIME-Version doit être préservé. Sans lui, le client récepteur peut ne pas traiter la structure MIME du tout.
Décodage base64/QP partiel. Les deux décodeurs doivent gérer les cas limites : remplissage base64, sauts de ligne soft QP (=\r\n), et espace blanc de fin. Les décodeurs incomplets produisent une sortie corrompue pour les messages légitimes.
Ne pas proposer d'option d'enregistrement pour les parties non affichables. Un client conforme doit permettre à l'utilisateur d'enregistrer n'importe quelle partie du corps, même s'il ne peut pas l'afficher. Supprimer silencieusement les parties viole la spécification et perd des données.

Impact sur la délivrabilité

La structure MIME conforme est une base de délivrabilité. Les messages non conformes — MIME-Version manquante, délimiteurs multipart cassés, encodages incorrects — sont des caractéristiques des outils de spam. Les filtres anti-spam utilisent la conformité MIME comme signal de qualité.
Inclure à la fois text/plain et text/html. Les exemples de RFC 2049 démontrent multipart/alternative avec les deux formats. Ce n'est pas juste une bonne pratique ; de nombreux filtres anti-spam pénalisent les messages HTML uniquement. La partie text/plain doit avoir du contenu significatif, pas seulement « Afficher cet e-mail dans votre navigateur ».
Un Content-Transfer-Encoding valide prévient la corruption. Un message qui déclare quoted-printable mais contient des données 8 bits brutes sera mutilé par les passerelles SMTP 7 bits. Cela cause des défaillances de rendu au destinataire, même si le message atteint la boîte de réception.
Les déclarations de charset correctes préviennent le mojibake. Déclarer charset=us-ascii pour du contenu UTF-8 rend les caractères accentués illisibles. Les destinataires peuvent signaler le message comme spam plutôt que d'essayer de le décoder.
MIME bien formé améliore le rendu entre clients. Un message conforme à MIME s'affiche correctement dans Gmail, Outlook, Apple Mail, Thunderbird et les clients mobiles. Les messages non conformes peuvent s'afficher dans un client mais se casser dans un autre, causant des plaintes et des désinscriptions.