← RFC Reference

RFC 2046 : MIME Partie 2 — Types de médias

Pourquoi cela existe

RFC 2045 a introduit Content-Type et les encodages de transfert, mais il n'a pas défini quels types de contenu existent ou comment ils se comportent. RFC 2046 comble cette lacune en définissant :

• Les types de médias de niveau supérieur (texte, image, audio, vidéo, application, multipart, message).
• Le mécanisme multipart qui permet à un seul e-mail de contenir plusieurs parties du corps avec un délimiteur de limite.
• Les sous-types multipart spécifiques qui contrôlent la façon dont les clients de messagerie affichent les parties (mixed, alternative, digest, parallel).

C'est le RFC qui rend la messagerie électronique moderne possible. Sans lui, chaque e-mail serait un seul bloc de texte.

Comment cela fonctionne

Les types de médias de niveau supérieur

Le mécanisme Multipart

Les types multipart sont au cœur de RFC 2046. Un message multipart contient un paramètre boundary qui délimite chaque partie :

Content-Type: multipart/mixed; boundary="----=_boundary_001"

------ préambule (ignoré par les clients MIME) ------

------=_boundary_001
Content-Type: text/plain; charset=utf-8

Ceci est la première partie.

------=_boundary_001
Content-Type: text/plain; charset=utf-8

Ceci est la deuxième partie.

------=_boundary_001--
^^^ remarque le -- de fin qui marque la fin

Règles clés pour les limites :

• Chaque partie est précédée de -- + la chaîne limite sur sa propre ligne.
• La limite finale a également -- ajouté après elle (par exemple, --boundary--).
• La chaîne limite ne doit pas apparaître dans aucune partie du corps. Utilisez une longue chaîne aléatoire.
• Le contenu avant la première limite (le préambule) et après la limite finale (l'épilogue) sont ignorés par les clients MIME.

Sous-types Multipart

Le sous-type indique au client de messagerie comment afficher les parties. C'est là que réside la subtilité.

multipart/mixed — Parties séquentielles

Le type multipart le plus courant. Les parties sont affichées dans l'ordre. Utilisé pour « corps du message + pièces jointes » :

Content-Type: multipart/mixed; boundary="----=_mixed"

------=_mixed
Content-Type: text/plain; charset=utf-8

Voici le rapport que vous avez demandé.

------=_mixed
Content-Type: application/pdf; name="report.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="report.pdf"

JVBERi0xLjQKJeLjz9MK...

------=_mixed--

multipart/alternative — Même contenu, formats différents

Contient plusieurs versions du même contenu. Le client de messagerie choisit la meilleure qu'il peut afficher. Les parties sont ordonnées du plus simple au plus riche — la dernière partie est préférée :

Content-Type: multipart/alternative; boundary="----=_alt"

------=_alt
Content-Type: text/plain; charset=utf-8

Bienvenue dans notre service !

------=_alt
Content-Type: text/html; charset=utf-8

<h1>Bienvenue dans notre service !</h1>
<p>Nous sommes heureux de vous avoir.</p>

------=_alt--

C'est ainsi que fonctionne chaque e-mail HTML bien formé : la réserve text/plain vient en premier, la version text/html vient en dernier. Un client qui supporte HTML affiche le HTML ; un client en texte brut affiche le texte.

multipart/related — Parties liées

Utilisé lorsque les parties se référencent les unes aux autres. Le cas d'usage le plus courant est un e-mail HTML avec des images intégrées. Le HTML référence les images par ID de contenu (URLs cid:) :

Content-Type: multipart/related; boundary="----=_rel"

------=_rel
Content-Type: text/html; charset=utf-8

<p>Découvrez notre logo :</p>
<img src="cid:logo@example.com" alt="Logo" />

------=_rel
Content-Type: image/png
Content-Transfer-Encoding: base64
Content-ID: <logo@example.com>

iVBORw0KGgoAAAANSUhEU...

------=_rel--

multipart/digest — Collection de messages

Une variante de mixed où le type de contenu par défaut pour chaque partie est message/rfc822 au lieu de text/plain. Utilisé par les digests de listes de diffusion. Rarement vu dans la messagerie électronique moderne.

Détails techniques clés

Imbrication de types Multipart

La véritable puissance de MIME vient de l'imbrication. Un e-mail de marketing typique avec des images intégrées et une pièce jointe ressemble à ceci :

; La structure standard pour un e-mail HTML avec des images intégrées + pièces jointes

Content-Type: multipart/mixed           ← externe : corps + pièces jointes
  |
  |-- multipart/alternative              ← corps : texte ou HTML
  |     |-- text/plain                    ← réserve texte brut
  |     |-- multipart/related             ← HTML + images intégrées
  |           |-- text/html               ← le corps HTML
  |           |-- image/png (cid:logo)    ← image intégrée
  |
  |-- application/pdf (attachment)       ← pièce jointe

Cette imbrication à trois niveaux est le modèle standard utilisé par pratiquement toutes les bibliothèques de messagerie et les fournisseurs de services de messagerie.

Le type message/rfc822

Encapsule un message e-mail complet en tant que partie du corps. Utilisé pour transférer des messages en tant que pièces jointes et dans les notifications de rebond (RFC 3462 multipart/report). Le message encapsulé possède ses propres en-têtes (From, To, Subject, etc.) et son corps.

La réserve application/octet-stream

Lorsque le type de contenu d'un fichier est inconnu, utilisez application/octet-stream. Cela indique au client de le traiter comme des données binaires génériques et déclenche généralement une invite de téléchargement. C'est l'équivalent MIME de « Je ne sais pas ce que c'est ; enregistrez-le et découvrez-le vous-même ».

Exigences de limite

La chaîne limite a des règles spécifiques :

• Longueur maximale de 70 caractères.
• Composé d'alphanumériques ASCII plus un ensemble limité de caractères spéciaux : '()+_,-./:=? et espace.
• Ne doit pas apparaître dans aucune partie du corps enclosée.
• En pratique, utilisez une longue chaîne aléatoire comme ----=_Part_12345_67890.1234567890.

Erreurs courantes

• Utiliser multipart/mixed au lieu de multipart/alternative pour texte+HTML. Si vous placez text/plain et text/html dans un conteneur mixed, le client affichera les deux (ou affichera du texte et proposera HTML en téléchargement). Utilisez alternative pour que le client choisisse le meilleur format.
• Mauvais ordre de partie dans multipart/alternative. Format le plus simple en premier, le plus riche en dernier. Si vous placez HTML avant texte brut, certains clients afficheront la version texte brut même si HTML est disponible.
• Images intégrées sans multipart/related. Si vous référencez une URL cid: en HTML mais que l'image se trouve dans une partie sœur multipart/mixed au lieu d'un conteneur multipart/related, de nombreux clients ne résoudront pas la référence.
• Crochets d'angle Content-ID manquants. La valeur d'en-tête Content-ID doit être entourée de crochets d'angle : <image001@example.com>. La référence cid: en HTML les omet : src="cid:image001@example.com".
• Collisions de limite. L'utilisation d'une chaîne limite courte ou prévisible (comme boundary ou ---) risque d'apparaître dans le contenu du corps, ce qui corrompt la structure du message. Utilisez toujours des limites aléatoires.
• Oubli du -- final. La limite de fermeture doit se terminer par -- (par exemple, --boundary--). L'absence de ceci fait que les analyseurs attendent d'autres parties et peut entraîner un message garni ou incomplet.

Impact sur la délivrabilité

• multipart/alternative correct est essentiel. Les filtres anti-spam s'attendent à ce que les e-mails HTML bien formés incluent une alternative text/plain. Son absence est un signal de spam. Les parties texte et HTML doivent avoir à peu près le même contenu — une partie texte d'une ligne avec une partie HTML de 50 KB semble suspecte.
• Les images intégrées augmentent le score de spam. L'utilisation intensive de multipart/related avec de nombreuses images intégrées (surtout lorsque l'e-mail est principalement composé d'images avec peu de texte) déclenche les heuristiques de spam d'images. Préférez les images hébergées avec des URLs https:// aux références cid: pour les e-mails de marketing.
• Les types de pièces jointes comptent. Les pièces jointes exécutables (.exe, .js, .bat) sont bloquées ou mises en quarantaine par pratiquement tous les fournisseurs de messagerie. Même les fichiers .zip contenant des exécutables seront signalés. Limitez-vous à des types sûrs : PDF, formats d'image courants, documents de bureau.
• Les messages surdimensionnés rebondissent. De nombreux fournisseurs rejettent les messages dépassant 25 Mo (certains dépassant 10 Mo). N'oubliez pas que l'encodage base64 ajoute une surcharge de 33 %. Une pièce jointe de 20 Mo devient un e-mail d'environ 27 Mo.
• MIME correctement structuré signale la légitimité. Un MIME bien formé avec imbrication correcte, limites valides et déclarations Content-Type appropriées indique aux filtres anti-spam que ce message a été généré par un logiciel de messagerie légitime, et non par un outil de spam fait à la main.

Related RFCs