MIME

La présence de ce champ d'en-tête indique que le message est au format MIME. Sa valeur est généralement « 1.0 ». Ce champ se présente comme suit :

Version MIME : 1.0

Selon Nathaniel Borenstein , co-créateur de MIME , la numérotation des versions a été introduite pour permettre des modifications du protocole MIME dans les versions ultérieures. Cependant, Borenstein a reconnu des lacunes dans la spécification qui ont entravé la mise en œuvre de cette fonctionnalité :

Nous n'avons pas suffisamment précisé comment gérer une future version MIME. … Donc, si vous écrivez un programme qui reconnaît la version 1.0, que devez-vous faire si vous rencontrez les versions 2.0 ou 1.1 ? Cela me semblait évident, mais il s'avère que chacun l'a implémenté différemment. Résultat : il serait quasiment impossible pour Internet de définir un jour une version 2.0 ou 1.1.

Les spécifications MIME originales décrivaient uniquement la structure des messages électroniques. Elles n'abordaient pas la question des styles de présentation. Le champ d'en-tête Content-Disposition a été ajouté dans la RFC 2183 pour spécifier le style de présentation. Une partie MIME peut contenir :

• une disposition de contenu en ligne , ce qui signifie qu'il doit s'afficher automatiquement lorsque le message est affiché, ou
• une disposition du contenu de pièce jointe , auquel cas elle n'est pas affichée automatiquement et nécessite une action de l'utilisateur pour l'ouvrir.

Outre le style de présentation, le champ Content-Disposition fournit également des paramètres permettant de spécifier le nom du fichier, sa date de création et sa date de modification, qui peuvent être utilisés par l'agent utilisateur de messagerie du destinataire pour stocker la pièce jointe.

L'exemple suivant est tiré de la RFC 2183, où le champ d'en-tête est défini :

Content-Disposition: attachment; filename=genome.jpeg; modification-date="Mer., 12 févr. 1997 16:29:51 -0500";

Le nom de fichier peut être encodé conformément à la RFC 2231.

En 2010, la majorité des clients de messagerie ne respectaient pas pleinement cette recommandation. Le client de messagerie Mozilla Thunderbird, largement utilisé, ignore les champs Content-Disposition des messages et utilise des algorithmes indépendants pour sélectionner automatiquement les parties MIME à afficher. Les versions de Thunderbird antérieures à la version 3 envoient également les nouveaux messages avec une disposition de contenu intégrée pour toutes les parties MIME. La plupart des utilisateurs ignorent comment définir la disposition de contenu sur « attachment » . De nombreux clients de messagerie envoient également les messages avec le nom du fichier dans le paramètre « name » de l’en-tête Content-Type au lieu du paramètre « filename » du champ d’en-tête Content-Disposition . Cette pratique est déconseillée, car le nom du fichier doit être spécifié soit avec le paramètre « filename » , soit avec les deux paramètres « filename » et « name » .

En HTTP, l'en-tête de réponse Content-Disposition: attachment indique généralement au client de présenter le corps de la réponse comme un fichier téléchargeable. En règle générale, à la réception d'une telle réponse, le navigateur invite l'utilisateur à enregistrer son contenu dans un fichier plutôt que de l'afficher comme une page web, le nom de fichier suggéré étant le nom par défaut.

En juin 1992, MIME (RFC 1341, depuis lors obsolète (RFC 2045)) a défini un ensemble de méthodes pour représenter des données binaires dans des formats autres que le format texte ASCII. Le champ d'en-tête MIME « content-transfer-encoding » a une double signification :

• Il indique si un schéma d'encodage binaire-texte a été utilisé en plus de l'encodage d'origine spécifié dans l'en-tête Content-Type :

1. Si une telle méthode d'encodage binaire-texte a été utilisée, elle est précisée.
2. Sinon, elle fournit une étiquette descriptive du format du contenu, en ce qui concerne la présence de contenu 8 bits ou binaire.

La RFC et la liste des encodages de transfert de l'IANA définissent les valeurs ci-dessous, qui ne sont pas sensibles à la casse. « 7bit », « 8bit » et « binary » indiquent qu'aucun encodage binaire n'a été appliqué à l'encodage d'origine. Dans ce cas, le champ d'en-tête est inutile pour le client de messagerie lors du décodage du corps du message, mais il peut néanmoins indiquer le type d'objet envoyé. Les valeurs « quoted-printable » et « base64 » signalent au client de messagerie qu'un encodage binaire a été utilisé et qu'un décodage initial approprié est nécessaire avant que le message puisse être lu dans son encodage d'origine (par exemple, UTF-8).

• Convient pour une utilisation avec un protocole SMTP standard :
  • 7 bits – jusqu'à 998 octets par ligne, pour les valeurs de code comprises entre 1 et 127. Les caractères CR et LF (codes 13 et 10 respectivement) ne sont autorisés que s'ils font partie d'une fin de ligne CRLF. Il s'agit de la valeur par défaut.
  • quoted-printable – utilisé pour encoder des séquences d'octets arbitraires dans un format respectant les règles de l'encodage 7 bits. Conçu pour être efficace et généralement lisible par l'humain lorsqu'il est utilisé pour des données textuelles composées principalement de caractères US-ASCII, mais contenant également une petite proportion d'octets dont les valeurs sont hors de cette plage.
  • Base64 est utilisé pour encoder des séquences d'octets arbitraires dans un format respectant les règles de l'encodage 7 bits. Il est conçu pour être efficace avec les données binaires et 8 bits non textuelles. Il est parfois utilisé pour les données textuelles contenant fréquemment des caractères non ASCII américains.
• Convient pour une utilisation avec les serveurs SMTP prenant en charge l' extension SMTP 8BITMIME (RFC 6152) :
  • 8 bits – jusqu’à 998 octets par ligne avec CR et LF (codes 13 et 10 respectivement) autorisés à apparaître uniquement dans le cadre d’une fin de ligne CRLF.
• Convient pour une utilisation avec les serveurs SMTP prenant en charge l'extension SMTP BINARYMIME (RFC 3030) :
  • binaire – toute séquence d'octets.

Aucun encodage n'est défini spécifiquement pour l'envoi de données binaires arbitraires via SMTP avec l'extension 8BITMIME. Par conséquent, si BINARYMIME n'est pas pris en charge, les encodages base64 ou quoted-printable (malgré leurs performances parfois limitées) restent parfois utiles. Cette restriction ne s'applique pas aux autres utilisations de MIME, telles que les services Web avec pièces jointes MIME ou MTOM .

Les codes ASCII du point d'interrogation (« ? ») et du signe égal (« =" ») ne peuvent être représentés directement, car ils servent à délimiter le mot encodé. Le code ASCII de l'espace ne peut pas non plus être représenté directement, car cela pourrait entraîner une segmentation indésirable du mot encodé par les anciens analyseurs syntaxiques. Afin de réduire la taille de l'encodage et d'en faciliter la lecture, le caractère de soulignement est utilisé pour représenter le code ASCII de l'espace, ce qui a pour conséquence que ce caractère ne peut pas être représenté directement. L'utilisation de mots encodés dans certaines parties des champs d'en-tête impose des restrictions supplémentaires quant aux caractères pouvant être représentés directement.

Par exemple,

Subject: =?iso-8859-1?Q?=A1Hola,_se=F1or!?=

est interprété comme « Sujet : ¡Hola, señor! ».

Le format de mot encodé n'est pas utilisé pour les noms des champs d'en-tête (par exemple, Sujet ). Ces noms sont généralement des termes anglais et toujours au format ASCII dans le message brut. Lors de la consultation d'un message avec un client de messagerie non anglophone, les noms des champs d'en-tête peuvent être traduits par ce dernier.

La norme MIME définit différents sous-types de messages multiparties, qui précisent la nature des parties du message et leurs relations. Le sous-type est indiqué dans l' HTML (text/html) . La partie en texte brut assure la compatibilité avec les versions antérieures, tandis que la partie HTML permet la mise en forme et l’insertion de liens hypertextes. La plupart des clients de messagerie offrent à l’utilisateur la possibilité de privilégier le texte brut au HTML ; c’est un exemple de la façon dont des facteurs locaux peuvent influencer le choix, par une application, de la partie du message à afficher le plus approprié.

Bien que chaque partie du message soit censée représenter le même contenu, la norme n'impose aucunement cette contrainte. Auparavant, les filtres anti-spam n'examinaient que la partie text/plain d'un message , car elle est plus facile à analyser que la partie text/html. Cependant , les spammeurs ont fini par exploiter cette faille, créant des messages avec une partie text/plain d'apparence anodine et de la publicité dans la partie text/html. Les logiciels anti-spam ont fini par détecter cette pratique, pénalisant les messages contenant un texte très différent dans un message multipart/alternative

Le type est défini dans la RFC 2046.

L'attribut multipart/related indique que chaque partie d'un message fait partie d'un ensemble. Il est destiné aux objets composés de plusieurs éléments interdépendants ; un affichage correct ne peut être obtenu en affichant individuellement les parties constituantes. Le message comprend une partie racine (par défaut, la première) qui référence d'autres parties, lesquelles peuvent à leur tour référencer d'autres parties. Les parties du message sont généralement référencées par leur identifiant de contenu (Content-ID ). La syntaxe d'une référence n'est pas spécifiée et dépend de l'encodage ou du protocole utilisé dans la partie.HTML et utilise des balises image pour référencer les images stockées dans les parties suivantes.

Ce type est défini dans la RFC 2387.

Le type de message multipart/report contient des données formatées pour être lues par un serveur de messagerie. Il est divisé en deux parties : text/plain (ou tout autre contenu/type facilement lisible) et message/delivery-status, qui contient les données formatées pour être lues par le serveur de messagerie.

Ce type est défini dans la RFC 6522.

Un message multipart/signed permet d'apposer une signature numérique sur un message. Il comporte deux parties : le corps du message et la signature. L'intégralité du corps du message, y compris les champs MIME, sert à créer la signature. Plusieurs types de signatures sont possibles, comme « application/pgp-signature » ​​(RFC 3156) et « application/pkcs7-signature » ​​( S/MIME ).

Le type est défini dans la RFC 1847.

Un message multipart/encrypted comporte deux parties. La première contient les informations de contrôle nécessaires au déchiffrement de la seconde partie, de type application/octet-stream. À l'instar des messages signés, il existe différentes implémentations, identifiées par le type de contenu spécifique de la partie de contrôle. Les types les plus courants sont « application/pgp-encrypted » (RFC 3156) et « application/pkcs7-mime » ( S/MIME ).

Le type MIME défini dans la RFC 1847.

Le type MIME multipart/form-data est utilisé pour exprimer les valeurs soumises via un formulaire. Initialement défini dans le cadre de HTML 4.0, il est principalement utilisé pour l'envoi de fichiers via HTTP . Il est spécifié dans la RFC 7578 , qui remplace la RFC 2388. Exemple

Le type de contenu multipart/x-mixed-replace a été développé dans le cadre d'une technologie visant à émuler le push serveur et la diffusion en continu sur HTTP.

Dans un message à remplacement mixte, tous les éléments ont la même signification. Cependant, chaque élément invalide – « remplace » – les éléments précédents dès sa réception complète. Les clients doivent traiter chaque élément dès son arrivée et ne doivent pas attendre la fin du message.Netscape [ ce type de contenu est toujours pris en charge par Mozilla , Firefox , Safari et Opera . Il est couramment utilisé dans les caméras IP comme type MIME pour les flux MJPEG . Chrome le prenait en charge pour les ressources principales jusqu'en 2013 (les images peuvent encore être affichées avec ce type de contenu)

Le format multipart/byterange est utilisé pour représenter des plages d'octets non contiguës d'un seul message ; il est utilisé par HTTP lorsqu'un serveur renvoie plusieurs plages d'octets et est défini dans la RFC 2616.