Multipurpose Internet Mail Extensions

La présence de cet en-tête indique que le contenu du message est formaté en MIME. La valeur est typiquement « 1.0 », donc l'en-tête apparaît comme :

MIME-Version: 1.0

Cet en-tête indique le type de média internet du contenu du message, consistant en un type et un sous-type, par exemple :

Content-Type: text/plain

MIME permet aux messages d'avoir plusieurs parties organisées sous forme d'une structure arborescente, en utilisant un type « multipart » pour les nœuds internes.

Ce mécanisme supporte notamment :

• les messages en texte simple avec « text/plain » (la valeur par défaut de l'en-tête « Content-Type: ») ;
• les messages en HTML avec « text/html » ;
• les contenus multiples avec « multipart/mixed » : ceci permet l’envoi d’un message avec pièces jointes, le corps du message constituant une partie (de type « text »), de même que chaque pièce jointe ; généralement, on indique le nom d’une pièce jointe avec un en-tête « Content-Disposition: » (le type du fichier est alors identifié par le type MIME et son extension) ;
• les contenus alternatifs avec « multipart/alternative » : ceci permet l’envoi d’un message contenant plusieurs formats alternatifs (typiquement, texte simple et HTML), le receveur (ou son client de messagerie) choisit alors le format sous lequel il veut visualiser le message.

La spécification du MIME (RFC 2045) définit un ensemble de méthodes ou encodages de transfert (rappelées dans cette liste de l'IANA) pour représenter des données quelconques sous forme de texte ASCII. L'en-tête MIME « Content-Transfer-Encoding » indique la méthode utilisée. Il peut avoir l’une des valeurs (non sensibles à la casse) suivantes :

• appropriées pour l'usage avec SMTP :
  • 7bit — aucune transformation, limité aux caractères de l’ASCII (valeurs 1 à 127) avec au plus 998 octets par ligne et les caractères CR et LF (retour chariot et défilement de ligne, codes 13 et 10 respectivement) réservés pour les fins de ligne (CRLF). C'est la valeur par défaut.
  • quoted-printable — encode des données arbitraires dans un format qui satisfait les règles de 7bit. Étudié pour être efficace et lisible par un humain quand il est utilisé pour encoder du texte comportant une majorité de caractères ASCII.
  • base64 — encode des données arbitraires dans un format qui satisfait les règles de 7bit. Sa taille est fixe par rapport à la taille des données initiales. Il est utilisé pour les données non textuelles ou des textes à base non ASCII.
• appropriées pour les serveurs SMTP qui supportent le transport 8BITMIME (en) comme extension SMTP (en) :
  • 8bit — aucune transformation, séquence d’octets quelconques avec au plus 998 octets par ligne et les caractères CR et LF réservés pour les fins de ligne.
• non appropriée avec SMTP :
  • binary — aucune transformation, séquence quelconque d'octets. Non utilisable avec les courriels SMTP.

Aucun encodage n'est spécialement spécifié pour l'envoi de données binaires arbitraires par les transports SMTP avec l'extension 8BITMIME. Les méthodes Base64 ou Quoted-Printable (avec leurs inefficacités respectives) doivent être utilisées. Ces restrictions ne s'appliquent pas aux autres utilisations de MIME comme les services web avec attachement MIME ou MTOM.

Les codes ASCII pour le point d'interrogation (?) et le signe égal (=) ne devraient pas être représentés directement puisqu'ils sont utilisés pour délimiter les mots encodés. Le code ASCII pour le caractère espace ne devrait pas non plus être utilisé car il peut provoquer des erreurs sur les anciens encodeurs comme une séparation de mot non désirée. Pour rendre l'encodage plus léger et plus aisé à lire, le caractère underscore (« _ ») est utilisé pour représenter l'espace. Par conséquent, le caractère underscore ne peut plus être représenté directement. L'utilisation de mots encodés dans certaines parties des en-têtes impose des restrictions sur les caractères à représenter directement.

Par exemple,

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

est interprété comme :

Subject: ¡Hola, señor!

Le format des mots encodés n'est pas utilisé pour les noms des en-têtes (par exemple « Subject: »). Ces noms d'en-têtes sont toujours en anglais dans le message. Quand le message est visualisé sur un client de courriels non anglophone, les noms d'en-têtes peuvent être traduits par le client.

Le standard MIME définit plusieurs sous-types de messages multi-parties pour en spécifier la nature des différentes parties du message et leurs relations avec les autres parties. Le sous type est spécifié par l'en-tête « Content-type: » du message englobant. Par exemple, un message MIME multi-parties utilisant le sous-type « digest » devrait avoir son en-tête « Content-Type: » à « multipart/digest ». La RFC définit initialement quatre sous-types : « mixed », « alternate », « digest » et « parallel ». Une application doit supporter au moins les sous-types « mixed » et « digest », les autres sont optionnels. Des sous-types additionnels comme « signed » ou « form-data » ont été définis dans d'autres RFC.

Les sous-types suivants sont ceux principalement utilisés :

Le type « multipart/mixed » (défini dans RFC2046, Section 5.1.3) est utilisé pour envoyer des fichiers avec différents en-têtes « Content-type: » (comme pièces-jointes). Si les fichiers sont facilement lisibles ou sont des images, la plupart des clients de courriels affichent ces fichiers directement dans le contenu du message (à moins qu'un en-tête « Content-disposition: » ne spécifie le contraire). Sinon les fichiers sont vus comme des pièces jointes. Le type de contenu par défaut de ces parties est « text/plain ».

La RFC spécifie également que tous les sous-types de « multipart » non reconnus par une implémentation doivent être traités de la même manière que « multipart/mixed ».

Le type « multipart/digest » (défini dans RFC2046, Section 5.1.5) est la manière simple d'envoyer des messages à textes multiples. Le type de contenu par défaut est « message/rfc822 ».

Le type « multipart/alternative » (défini dans RFC2046, Section 5.1.4) indique que chaque partie est une version alternative d'un même contenu dans un format différent. Les formats sont ordonnés dans l'ordre croissant de fidélité au contenu original. Le receveur peut ainsi choisir la meilleure représentation qu'il est capable de traiter, en général, la dernière de la liste.

Comme un client ne veut généralement pas envoyer un contenu moins significatif que le texte brut, celui-ci est envoyé en premier, ce qui permet de simplifier le traitement par les clients ne comprenant pas le type « multipart » car c'est la partie visible en premier.

L'utilisation principale du type « multipart/alternative » est l'envoi de courriels au format HTML avec son équivalent au format texte pour conserver la lisibilité du message pour un client courriel ne pouvant afficher de HTML (client texte).

Bien que chaque partie du message est censée représenter le même contenu, rien ne le garantit. Par exemple, il est plus facile pour un filtre anti pourriel d'analyser la partie texte pur d'un message plutôt que la partie HTML ; alors que l'éditeur de pourriel va plutôt construire un message HTML avec son contenu publicitaire et un message en texte pur anodin ou sans rapport avec sa publicité.

Le type « multipart/related » (défini dans RFC2387) est utilisé pour préciser que les différentes parties ne devraient pas être traitées individuellement mais comme un tout. Le message consiste en une partie racine (la première, par défaut) qui référence les autres parties, qui peuvent aussi référencer d'autres parties. Les parties de messages sont souvent référencées par leur identifiant de contenu (en-tête « Content-ID: »). La syntaxe des références n'est pas spécifiée, elle est laissée à l'intention du protocole utilisé.

Un des usages courant de ce sous-type est l'envoi d'une page web avec ses images en un seul message. La partie racine contient le document HTML et les images sont stockées dans les parties suivantes.

Le type « multipart/report » (défini dans RFC3462) représente un message qui contient des données formatées pour être lues par un serveur de courriels. Il contient une partie de type « text/plain » (ou tout autre contenu facilement lisible) et une autre de type « message/delivery-status » qui contient les données formatées pour le serveur de courriels.

Le type « multipart/signed » (défini dans RFC1847, Section 2.1) est utilisé pour attacher une signature numérique à un message. Il est composé de deux parties : le corps du message et la signature. L'ensemble de la partie corps du message, y compris les en-têtes MIME, est utilisé pour générer la signature. Différents types de signatures sont possibles comme « application/pgp-signature » ou « application/x-pkcs7-signature ».

Le type « multipart/encrypted » (défini dans RFC1847, Section 2.2) est utilisé pour envoyer un contenu chiffré. Sa première partie définit les informations nécessaires pour déchiffrer sa seconde partie (de type « application/octet-stream »).

Le type « multipart/form-data » (défini dans RFC2388) est utilisé pour envoyer les données d'un formulaire. Défini à l'origine comme une partie de HTML 4.0, il est plus couramment utilisé pour envoyer des fichiers via HTTP.

• Type de média internet
• Courrier électronique
• MHTML
• S/MIME (Secure MIME)
• file est une commande Unix qui détermine le type MIME de fichiers.

• (en) Liste des types MIMES enregistrés par l'IANA
• (en) Liste des jeux de caractères