Multipurpose Internet Mail Extensions (MIME) ou Extensions multifonctions du courrier Internet^[1] est un standard internet qui étend le format de données des courriels pour supporter des textes en différents codage des caractères autres que l'ASCII, des contenus non textuels, des contenus multiples, et des informations d'en-tête en d'autres codages que l'ASCII. Les courriels étant généralement envoyés via le protocole SMTP au format MIME, ces courriels sont souvent appelés courriels SMTP/MIME.

À l'origine, SMTP avait été prévu pour ne transférer que des fichiers textes (codés en ASCII). Avec l'apparition du multimédia et l'utilisation croissante des applications bureautiques, le besoin s'est fait sentir d'échanger, en plus des fichiers textes, des fichiers binaires (format des applications bureautiques, images, sons, fichiers compressés).

Les types de contenus définis par le standard MIME peuvent être utilisés à d'autres fins que l'envoi de courriels, dans les protocoles de communication comme le HTTP pour le World Wide Web.

MIME est initialement spécifié dans cinq RFC : RFC 2045^[2], RFC 2046^[3], RFC 2047^[4], RFC 2048^[5], RFC 2049^[6]. La RFC 2045 est complétée par la RFC 2077^[7]. La RFC 2048, maintenant obsolète, est remplacée par les RFC 6838^[8] et RFC 4289^[9].

Introduction

Le protocole de base de transmission de courriels, SMTP, ne supporte que les caractères ASCII (qui font 7 bits). Cela limite les courriels aux messages qui n'incluent que ces caractères, soit un petit nombre de langages comme l'anglais. Les autres langages basés sur l'alphabet latin incluant des diacritiques ne sont pas supportés par l'ASCII, ces messages ne peuvent donc pas être correctement représentés dans des courriels basiques.

MIME définit des mécanismes pour l'envoi d'autres sortes d'informations, comme des textes utilisant des codages de caractères autres que l'ASCII (et pouvant donc être dans une autre langue que l’anglais), ou des données binaires (dont des fichiers contenant des images, des sons, des films ou des programmes informatiques).

MIME est également un composant fondamental des protocoles de communications comme HTTP, qui requièrent l'envoi de données dans le même contexte que l'envoi de courriels, même si ces données ne sont pas des courriels. L'intégration ou l'extraction des données au format MIME est généralement automatiquement effectuée par le client de messagerie ou par le serveur de messagerie électronique quand le courriel est envoyé ou reçu.

Le format de base des courriels est défini dans la RFC 2822^[10] qui est une mise à jour de la RFC 822^[11]. Ces standards spécifient le format des en-têtes et du corps des courriels contenant du texte, ainsi que les en-têtes généraux comme « To: », « Subject: », « From: » ou « Date: ». MIME définit un ensemble d'en-têtes additionnels pour le type de contenu du message (« Content‑Type: ») et son encodage de transfert (« Content-Transfer-Encoding: »). L’encodage de transfert est la façon de traduire le contenu du message vers l’ASCII. Grâce à cette traduction, le contenu initial peut contenir des données 8 bits arbitraires (texte en UTF-8, fichier binaire, etc.). MIME définit également un mécanisme pour utiliser cette fonctionnalité dans les en-têtes du message ; ceci autorise par exemple des accents dans le sujet d’un courriel ou dans le nom d’un destinataire.

MIME est extensible. Sa définition inclut une méthode pour enregistrer de nouveaux types de contenus ou d'autres valeurs d'attributs.

Un des autres buts explicites de la définition de MIME est de ne pas avoir à changer les serveurs de messagerie électronique préexistants, et de permettre le fonctionnement correct des courriels de base avec les clients préexistants. Ce but est réalisé par le fait que les attributs de messages MIME sont optionnels et que le comportement par défaut est la création d'un message textuel sans MIME qui peut être interprété correctement par un client.

En-têtes MIME

MIME-Version: 1.0

Content-Type: text/plain

Encodage du texte

Les données textuelles (type « text ») sont écrites selon un certain encodage de caractères, par exemple latin-9 ou UTF-8. Cet encodage peut être précisé avec l’attribut « charset= » de l’en-tête « Content-Type: ». Celui-ci peut prendre n’importe quelle valeur définie par l’IANA. Par exemple :

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

Cet encodage ne doit pas être confondu avec l’encodage de transfert, précisé par l’en-tête « Content-Transfer-Encoding: ». Dans le cas d’un contenu textuel, les deux encodages sont appliqués successivement. Par exemple :

Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Ceci est un message encod=C3=A9 en UTF-8, puis transform=C3=A9 en ASCII par
la m=C3=A9thode "Quoted-Printable".

Dans cet exemple, la lettre « é » s’encode en UTF-8 par deux octets de valeurs hexadécimales C3 et A9, qui sont à leur tour encodés en Quoted-Printable par la séquence « =C3=A9 ».

Mots encodés

Depuis la RFC 2822, les noms des en–têtes de messages et leurs valeurs sont toujours en caractères ASCII. Les valeurs qui contiennent des données non ASCII doivent utiliser la syntaxe dite « encoded-word » de MIME (RFC 2047) à la place des valeurs textuelles standards. Cette syntaxe utilise des chaînes de caractères ASCII aussi bien pour préciser l'encodage original du texte (équivalent de l’attribut charset= de l’en-tête Content-Type:) que l’encodage de transfert (équivalent de l’en-tête Content-Transfer-Encoding:).

La syntaxe est :

=?encodage?méthode?texte?=

• encodage peut être n'importe quel encodage de caractères enregistré par l'IANA. Typiquement, c'est le même que pour le corps du message.
• méthode est une lettre désignant l’encodage de transfert : soit « Q » pour Q-encoding — encodage similaire à Quoted-Printable —, soit « B » pour Base64.
• texte est le texte encodé.

Subject: =?utf-8?Q?=C2=A1Hola, _se=C3=B1or!?=

Message en plusieurs parties

Un message MIME multi-partie spécifie une ligne de séparation dans l'en-tête « Content-type: », via l’attribut « boundary= ». Cette séparation, qui ne doit apparaître nulle part ailleurs, est placée entre les parties et au début et à la fin du corps du message comme suit :

 Content-type: multipart/mixed; boundary="''frontière''"
 MIME-version: 1.0
 This is a multi-part message in MIME format.
 --''frontière''
 Content-type: text/plain
 This is the body of the message.
 --''frontière''
 Content-type: application/octet-stream
 Content-transfer-encoding: base64
 PGh0bWw+CiAgPGhlYWQ+CiAgPC9oZWFkPgogIDxib2R5PgogICAgPHA+VGhpcyBpcyB0aGUg
 Ym9keSBvZiB0aGUgbWVzc2FnZS48L3A+CiAgPC9ib2R5Pgo8L2h0bWw+Cg==
 --''frontière''--

Chacune de ces parties consiste en son propre en-tête de contenu (zéro, un ou plusieurs champs d'en-tête Content-*:) et un corps. Des parties multiples peuvent être incluses dans d'autres parties multiples avec pour chacune leur propre frontière. Le champ Content-Transfer-Encoding: d'un type à parties multiples doit être « 7bit », « 8bit » ou « binary » pour éviter les problèmes de décodage des différentes couches de parties multiples. Le bloc multi-parties n'a pas de jeu de caractères, les caractères non ASCII dans les en-têtes sont traités par le système des mots encodés et les corps peuvent avoir un jeu de caractères spécifié approprié à leur contenu.

Notes :

• la zone se trouvant avant le premier séparateur est ignorée par les clients MIME. Cette zone est généralement utilisée pour stocker un message à l'attention des clients ne supportant pas MIME ;
• le choix du séparateur de parties revient au programme client. Celui-ci doit le choisir de façon à éviter toute collision avec le contenu des différents contenus. Généralement, le séparateur est généré à partir d'une longue chaîne de caractères aléatoires.

Références

RFC 1847

Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted

RFC 2231

MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations. N. Freed, K. Moore. November 1997.

RFC 2387

The MIME Multipart/Related Content-type

Voir aussi