← RFC Reference

RFC 2045 : MIME Partie 1 — Format des corps de messages Internet

Pourquoi cela existe

RFC 5322 (et son prédécesseur RFC 822) ont défini les messages électroniques comme du texte US-ASCII pur avec une longueur de ligne maximale de 998 caractères. C'était acceptable en 1982. Ce ne l'est pas pour les e-mails modernes, qui doivent transporter :

• Du texte dans des jeux de caractères non-ASCII (UTF-8, ISO-8859-*, etc.)
• Du contenu HTML avec des styles intégrés et des images
• Des pièces jointes (PDF, images, archives)
• Plusieurs parties du corps (texte + HTML + pièces jointes dans un message)

MIME (Extensions de courrier Internet multifonctionnel) est une suite de cinq RFC qui étendent le courrier électronique pour gérer tout cela tout en restant rétro-compatible avec l'infrastructure ASCII originale. RFC 2045 est la partie 1 : elle définit les champs d'en-tête et les mécanismes de codage qui rendent tout le reste possible.

Comment cela fonctionne

RFC 2045 introduit trois champs d'en-tête critiques et deux schémas de codage.

L'en-tête MIME-Version

Tout message MIME doit inclure :

MIME-Version: 1.0

Cela signale aux clients de messagerie receveurs que le message utilise les conventions MIME. Sans cet en-tête, le message est traité comme du texte US-ASCII pur selon RFC 5322. La version est 1.0 depuis 1996 et n'a jamais changé.

L'en-tête Content-Type

Déclare le type de média et le sous-type du corps, ainsi que des paramètres facultatifs :

Content-Type: type/subtype; parameter=value

Exemples :

; E-mail en texte brut en UTF-8
Content-Type: text/plain; charset=utf-8

; E-mail HTML
Content-Type: text/html; charset=utf-8

; Pièce jointe PDF
Content-Type: application/pdf; name="invoice.pdf"

; Message multipart (texte + HTML + pièces jointes)
Content-Type: multipart/mixed; boundary="----=_Part_123"

Si aucun Content-Type n'est présent, la valeur par défaut est text/plain; charset=us-ascii — conservant la rétro-compatibilité avec les messages pré-MIME.

L'en-tête Content-Transfer-Encoding

SMTP a été conçu pour transporter du texte ASCII 7 bits avec des lignes ne dépassant pas 998 caractères. Les données binaires (images, PDF) et le texte 8 bits (UTF-8) doivent être codés pour respecter ces contraintes. RFC 2045 définit cinq encodages de transfert :

Encodage Quoted-Printable

Conçu pour un texte qui est principalement ASCII avec des caractères non-ASCII occasionnels. Chaque octet non-ASCII est codé comme =XX où XX est la valeur hexadécimale. Les lignes plus longues que 76 caractères sont enveloppées en douceur avec = à la fin.

; Original : « René sent the café menu »
Content-Transfer-Encoding: quoted-printable

Ren=C3=A9 sent the caf=C3=A9 menu

Le =C3=A9 est l'encodage UTF-8 de é (U+00E9), chaque octet étant codé en hexadécimal.

Encodage Base64

Encode les données binaires arbitraires en caractères ASCII (A-Z, a-z, 0-9, +, /). Chaque 3 octets d'entrée devient 4 caractères ASCII. Les lignes sont enveloppées à 76 caractères.

Content-Type: image/png; name="logo.png"
Content-Transfer-Encoding: base64

iVBORw0KGgoAAAANSUhEUgAAABgAAAAYCAYAAADgdz34
AAAABHNCSVQICAgIfAhkiAAAAAlwSFlzAAAApgAAAKYB
zN+OGwAAABl0RVh0U29mdHdhcmUAd3d3Lmlua3NjYXBl

Détails techniques clés

L'en-tête Content-Disposition

Bien que ne faisant pas partie de RFC 2045 lui-même (il provient de RFC 2183), Content-Disposition est étroitement lié et universellement utilisé avec MIME :

; Afficher en ligne (p. ex., une image intégrée)
Content-Disposition: inline

; Proposer comme pièce jointe téléchargeable
Content-Disposition: attachment; filename="report.pdf"

Un message MIME complet

En mettant tout ensemble — un message avec des corps texte et HTML, plus une pièce jointe :

MIME-Version: 1.0
From: sender@example.com
To: recipient@example.com
Subject: Invoice attached
Content-Type: multipart/mixed; boundary="----=_outer"

------=_outer
Content-Type: multipart/alternative; boundary="----=_inner"

------=_inner
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Please find your invoice attached.

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

<p>Please find your invoice attached.</p>

------=_inner--
------=_outer
Content-Type: application/pdf; name="invoice.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="invoice.pdf"

JVBERi0xLjQKJeLjz9MKMSAwIG9iago8PCAvVHlwZSAv
Q2F0YWxvZyAvUGFnZXMgMiAwIFIgPj4KZW5kb2JqCg==

------=_outer--

Notez la structure : multipart/mixed contient le corps et la pièce jointe. Le corps lui-même est multipart/alternative avec des versions texte et HTML. Voir RFC 2046 pour tous les détails sur les types multipart.

Paramètre Charset

Le paramètre charset sur les types text/* déclare l'encodage des caractères. Pour les e-mails modernes, utilisez toujours utf-8 :

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

Les jeux de caractères hérités comme iso-8859-1, windows-1252 et shift_jis sont toujours rencontrés mais ne doivent pas être utilisés dans les nouveaux messages.

Erreurs courantes

• En-tête MIME-Version: 1.0 manquant. Sans cet en-tête, certains clients de messagerie ignorent Content-Type et traitent le corps comme du texte ASCII pur. Votre e-mail HTML s'affichera sous forme de code source brut.
• Content-Transfer-Encoding incorrect pour les données binaires. L'envoi d'une pièce jointe binaire avec l'encodage 7bit la corrompra — les octets nuls et les caractères à haut bit sont endommagés. Utilisez toujours base64 pour le contenu binaire.
• Paramètre charset manquant ou incorrect. L'omission du charset devient par défaut us-ascii. Si votre texte contient des caractères UTF-8, ils s'afficheront sous forme de caractères illisibles. Déclarez toujours charset=utf-8.
• Les lignes dépassent 998 caractères. RFC 5322 impose une limite de ligne de 998 caractères. Base64 enveloppe à 76 caractères. Quoted-printable utilise des sauts de ligne souples. Le texte 8bit brut doit également respecter cette limite, sinon les serveurs intermédiaires peuvent tronquer ou rejeter le message.
• Utiliser 8bit sans vérifier le support du serveur. L'encodage 8bit nécessite que le serveur receveur annonce 8BITMIME dans sa réponse EHLO. Si ce n'est pas le cas, utilisez quoted-printable ou base64 à la place.
• La chaîne de délimitation apparaît dans le contenu du corps. Le délimitateur multipart ne doit pas apparaître dans aucune partie du corps. Utilisez une chaîne de délimitation longue et aléatoire pour éviter les collisions.

Impact sur la livraison

• Une structure MIME appropriée est non-négociable. MIME malformé déclenche les filtres anti-spam. MIME-Version manquant, délimitateurs incorrects ou encodages incorrects sont tous des signaux d'alarme que les filtres anti-spam recherchent.
• Envoyez toujours multipart/alternative. Incluez à la fois les parties text/plain et text/html. Les messages avec seulement HTML sont pénalisés par de nombreux filtres anti-spam. La partie texte sert également de secours pour les clients en texte brut.
• Utilisez base64 pour les pièces jointes, quoted-printable pour le texte. C'est la combinaison universellement compatible. Cela fonctionne sur tous les serveurs SMTP et les clients de messagerie.
• Maintenez la taille des pièces jointes raisonnable. L'encodage base64 ajoute 33 % de surcharge. Un fichier de 7,5 Mo devient un e-mail de 10 Mo. De nombreux serveurs rejettent les messages dépassant 25 Mo. Certains au-delà de 10 Mo.
• L'exactitude du charset prévient les bogues de rendu. Déclarer charset=utf-8 et encoder réellement en UTF-8 garantit que votre e-mail s'affiche correctement dans le monde entier. Les déclarations de charset incompatibles causent du mojibake (texte garbled) et des plaintes de support.

Related RFCs