Conversion de contenu dans Exchange Server

  • Article

La conversion de contenu est le processus consistant à mettre correctement en forme un message pour chaque destinataire. La décision d’exécuter une conversion de contenu sur un message dépend de la destination et du format du message. Les types de conversion de contenu qui se produisent dans Exchange 2016 et Exchange 2019 sont inchangés par rapport à Exchange 2013 :

  • Conversion de message pour les destinataires externes : ce type de conversion de contenu inclut les options de conversion TNEF (Transport Neutral Encapsulation Format) et les options d’encodage de message pour les destinataires externes. Les messages envoyés à des destinataires à l'intérieur de l'organisation Exchange ne nécessitent pas ce type de conversion de contenu. Ce type de conversion de contenu est géré par le catégoriseur dans le service de transport du serveur de boîtes aux lettres. Une catégorisation de chaque message intervient après qu'un nouveau message a été placé dans la file d'attente de soumission. En plus de la résolution des destinataires et de la résolution du routage, une conversion de contenu est appliquée au message avant son placement dans la file d'attente de remise. Si un seul message contient plusieurs destinataires, le catégoriseur détermine l'encodage approprié pour chaque destinataire. Le suivi de conversion de contenu ne capture aucune erreur de conversion de contenu que le catégoriseur rencontre lors de la conversion des messages envoyés à des destinataires externes.

  • Conversion MAPI pour les destinataires internes : ce type de conversion de contenu est géré par le service de transport de boîtes aux lettres. Le service de transport de boîtes aux lettres, qui existe sur les serveurs de boîtes aux lettres, permet de transmettre des messages entre des bases de données de boîtes aux lettres du serveur local et le service de transport de serveurs de boîtes aux lettres. Plus précisément, le service de dépôt de transport de boîtes aux lettres transmet des messages depuis la boîte d'envoi de l'expéditeur vers le service de transport d'un serveur de boîtes aux lettres. Le service de remise de transport de boîtes aux lettres transmet les messages du service de transport d'un serveur de boîtes aux lettres à la boîte de réception du destinataire. Le service de dépôt de transport de boîtes aux lettres convertit tous les messages sortants à partir du format MAPI et le service de remise de transport de boîtes aux lettres convertit tous les messages entrants au format MAPI. Le suivi de conversion de contenu capture ces erreurs de conversion MAPI. Pour plus d'informations, consultez la rubrique Managing Content Conversion Tracing.

Formats de message Exchange et Outlook

La liste suivante répertorie les formats de message de base disponibles dans Exchange et Outlook :

  • Texte brut : un message en texte brut utilise uniquement du texte US-ASCII, comme décrit dans RFC 5322. Le message ne peut pas contenir des polices différentes ni de mise en forme du texte. Les deux formats suivants peuvent être utilisés pour un message en texte brut :

    • Les en-têtes et le corps du message sont composés de texte US-ASCII. Les pièces jointes doivent être codées à l'aide de l'algorithme Uuencode. Uuencode est une abréviation de « Unix-to-Unix encoding » qui définit un algorithme d’encodage pour le stockage de pièces jointes binaires dans le corps d’un message électronique à l’aide de caractères de texte US-ASCII.

    • Le message est encodé en MIME avec une valeur Content-Type de text/plainet une valeur Content-Transfer-Encoding de 7bit pour les parties de texte d’un message en plusieurs parties. Toute pièce jointe d'un message est codée à l'aide d'un codage Quoted-printable ou Base64. Par défaut, lorsque vous composez et envoyez un message en texte brut dans Outlook, le message est encodé en MIME avec la valeur Content-Type de text/plain.

  • HTML : un message HTML prend en charge la mise en forme du texte, les images d’arrière-plan, les tableaux, les puces et d’autres éléments graphiques. Par définition, un message au format HTML doit être codé MIME pour conserver ces éléments de mise en forme.

  • Rtf (Rich Text Format) : RTF prend en charge la mise en forme du texte et d’autres éléments graphiques. RTF est synonyme de TNEF (les formats TNEF et RTF peuvent être utilisés de façon interchangeable). Ce format RTF est totalement différent du format RTF disponible dans Word.

  • TNEF : le format d’encapsulation neutre du transport est un format spécifique à Microsoft pour l’encapsulation des propriétés de message MAPI. Un message TNEF contient une version du message en texte brut et une pièce jointe qui contient la version mise en forme d'origine du message. Généralement, cette pièce jointe est nommée Winmail.dat. La pièce jointe Winmail.dat inclut les informations suivantes :

    • version mise en forme d'origine du message (par exemple, les polices, les tailles et les couleurs de texte) ;
    • objets OLE (par exemple, des images ou des documents Office imbriqués) ;
    • fonctionnalités Outlook spéciales (par exemple, des écrans personnalisés, des boutons de vote ou des demandes de réunion) ;
    • pièces jointes au message d'origine

    Le message en texte brut obtenu peut être représenté dans les formats suivants :

    • message conforme à la norme RFC 5322 composé uniquement de texte US-ASCII avec une pièce jointe Winmail.dat codée en Uuencode ;
    • message en plusieurs parties codé MIME contenant une pièce jointe Winmail.dat

    Outlook et d'autres clients de messagerie qui comprennent parfaitement le format TNEF, traitent la pièce jointe Winmail.dat et affichent le contenu du message d'origine sans jamais afficher la pièce jointe Winmail.dat. Des clients de messagerie ne prenant pas en charge le format TNEF peuvent présenter des messages TNEF de l'une des manières suivantes :

    • La version en texte brut du message s’affiche et le message contient une pièce jointe nommée Winmail.dat, Win.dat ou un autre nom générique tel que Att nnnnn.dat ou Att nnnnn.eml où l’espace réservé nnnnn représente un nombre aléatoire.
    • La version en texte brut du message s'affiche. La pièce jointe TNEF est ignorée ou supprimée. Le résultat est un message en texte brut.
    • Les serveurs de messagerie qui prennent en charge le format TNEF peuvent être configurés pour supprimer les pièces jointes TNEF des messages entrants. Le résultat est un message en texte brut. En outre, certains clients de messagerie peuvent ne pas prendre en charge le format TNEF, mais reconnaître et ignorer les pièces jointes TNEF. Le résultat est un message en texte brut.

    Certains utilitaires tiers peuvent aider à convertir des pièces jointes Winmail.dat.

    TNEF est pris en charge par toutes les versions d'Exchange depuis Exchange Server version 5.5.

  • Summary Transport Neutral Encapsulation Format (STNEF) : STNEF équivaut à TNEF. Toutefois, les messages STNEF sont codés différemment des messages TNEF. Plus précisément, les messages STNEF sont toujours encodés MIME et ont toujours la valeur BinaryContent-Transfer-Encoding . C'est pourquoi il n'y a pas de représentation en texte brut du message ni de pièce jointe Winmail.dat distincte contenue dans le corps du message. Le message entier est représenté uniquement à l'aide de données binaires. Les messages qui ont une valeur Content-Transfer-Encoding de Binary ne peuvent être transférés qu'entre des serveurs de messagerie qui prennent en charge et annoncent les extensions SMTP BINARYMIME et CHUNKING définies dans la norme RFC 3030. Les messages sont toujours transférés entre serveurs de messagerie à l'aide de la commande BDAT au lieu de la commande DATA standard.

    Le format STNEF est pris en charge par toutes les versions d'Exchange depuis Exchange 2000. Le format STNEF est automatiquement utilisé pour tous les messages transférés entre des serveurs Exchange au sein de l'organisation, et ce depuis le mode natif d'Exchange Server 2003.

    Exchange n'envoie jamais de message au format STNEF à des destinataires externes. Seuls des messages TNEF peuvent être envoyés à des destinataires en dehors de l'organisation Exchange.

Options de conversion de contenu pour des destinataires externes

Les options de conversion de contenu configurables dans une organisation Exchange pour des destinataires externes sont décrites dans les catégories suivantes :

  • Options de conversion TNEF : ces options de conversion spécifient si TNEF doit être conservé ou supprimé des messages qui quittent l’organisation Exchange.
  • Options d’encodage de message : ces options spécifient des options d’encodage de message, telles que les jeux de caractères MIME et non MIME, l’encodage des messages et les formats de pièces jointes.

Ces options de conversion et de codage sont indépendantes l'une de l'autre. Par exemple, le fait que des messages TNEF puissent quitter l'organisation Exchange n'est pas lié aux paramètres d'encodage MIME ou de texte brut de ces messages.

Vous pouvez indiquer la conversion de contenu à divers niveaux de l'organisation Exchange, tels que décrits dans la liste suivante :

  • Paramètres de domaine distant : les domaines distants définissent les paramètres pour les transferts de messages sortants entre l’organisation Exchange et les domaines externes. Même si vous ne créez pas d’entrée de domaine distant pour des domaines spécifiques, il existe un domaine distant prédéfini, nommé Default, qui s’applique à tous les espaces d’adressage distants (*). Pour plus d’informations sur les domaines distants, consultez la rubrique Remote Domains.

  • Paramètres d’utilisateur de messagerie et de contact de messagerie : les utilisateurs de messagerie et les contacts de messagerie sont similaires, car les deux ont des adresses de messagerie externes et contiennent des informations sur les personnes extérieures à l’organisation Exchange. La différence principale est la suivante : les utilisateurs de messagerie disposent de comptes qui peuvent être utilisés pour se connecter à Active Directory et accéder à des ressources de l'organisation. Pour plus d'informations, consultez la rubrique Recipients.

  • Paramètres Outlook : vous pouvez définir ces options de mise en forme et d’encodage des messages dans Outlook :

    • Format du message : vous pouvez définir le format de message par défaut pour tous les messages. Vous pouvez également remplacer le format de message par défaut à mesure que vous composez un message spécifique.
    • Format de message Internet : vous pouvez contrôler si les messages TNEF sont envoyés aux destinataires distants ou s’ils sont d’abord convertis dans un format plus compatible. Vous pouvez également spécifier diverses options de codage pour les messages envoyés à des destinataires distants. Ces paramètres ne s'appliquent pas aux messages envoyés à des destinataires au sein de l'organisation Exchange.
    • Format de message de destinataire Internet (Outlook 2010 ou version antérieure) : vous pouvez contrôler si les messages TNEF sont envoyés à des contacts spécifiques dans votre dossier Contacts. Ces options de conversion ne sont pas disponibles pour des destinataires dans l'organisation Exchange.
    • Options d’encodage des messages des destinataires Internet (Outlook 2010 ou version antérieure) : vous pouvez contrôler les options d’encodage MIME ou texte brut pour des contacts spécifiques dans votre dossier Contacts. Ces options de conversion ne sont pas disponibles pour des destinataires dans l'organisation Exchange.
    • Options internationales : vous pouvez contrôler les jeux de caractères utilisés dans les messages.

    Pour plus d’informations sur ces paramètres, consultez Options de conversion TNEF et Options d’encodage de message dans Exchange Server.

Compréhension de la structure des messages électroniques

Pour mieux comprendre les options de conversion de contenu pour les destinataires externes, vous devez comprendre la structure des messages électroniques. Un message SMTP est basé sur du texte brut US-ASCII 7 bits pour la composition et l'envoi de messages électroniques. Un message SMTP standard comprend les éléments suivants :

  • Enveloppe de message : l’enveloppe du message est définie dans RFC 5321. Elle contient les informations requises pour transmettre et remettre le message. Les destinataires ne voient jamais l'enveloppe du message, car elle est générée par le processus de transmission du message et ne fait pas partie du contenu du message.

  • Contenu du message : le contenu du message est défini dans RFC 5322. Il comprend les éléments suivants :

    • En-tête de message : l’en-tête de message est une collection de champs d’en-tête. Les champs d'en-tête se composent d'un champ name, suivi du caractère deux-points ( : ), suivi d'un champ body, puis d'une combinaison de caractères de retour chariot/retour à la ligne (CR/LF).

      Un champ name doit être composé de caractères de texte US-ASCII imprimables, à l'exception du caractère deux-points ( : ). Plus précisément, les caractères ASCII autorisés doivent avoir des valeurs comprises entre 33 et 57 et entre 59 et 126.

      Un champ body peut contenir tout caractère US-ASCII, à l’exception du caractère de retour chariot (CR) et du caractère de retour à la ligne (LF). Toutefois, un champ body peut contenir la combinaison de caractères CR/LF en cas d’utilisation dans le pliage d’en-tête. Le pliage d'en-tête est la séparation d'un champ body d'en-tête en plusieurs lignes conformément à la description de la section 2.2.3 de la norme RFC 5322. D'autres exigences de syntaxe concernant le champ body sont décrites dans les sections 3 et 4 de la norme RFC 5322.

    • Corps du message : le corps du message est une collection de lignes de caractères de texte US-ASCII qui apparaît après l’en-tête du message. L'en-tête du message et le corps du message sont séparés par une ligne vide qui se termine par la combinaison de caractères CR/LF. Le corps du message est facultatif. Une ligne de texte dans le corps du message doit compter moins de 998 caractères. Les caractères CR et LF ne peuvent apparaître ensemble que pour indiquer la fin d'une ligne.

Si des messages SMTP contiennent des éléments qui ne sont pas du texte brut US-ASCII, il faut coder le message pour préserver ces éléments. La norme MIME définit une méthode de codage du contenu non textuel des messages. MIME autorise du texte dans d'autres jeux de caractères, des pièces jointes sans texte, des corps de message en plusieurs parties et des champs d'en-tête dans d'autres jeux de caractères. MIME est défini dans les normes RFC 2045, RFC 2046, RFC 2047, RFC 4288, RFC 4289 et RFC 2049. MIME définit un ensemble de champs d'en-tête qui spécifient des attributs de message supplémentaires. Les sections suivantes décrivent certains champs d’en-tête MIME importants.

champ d’en-tête MIME-Version

Valeur par défaut : 1.0

Ce champ d'en-tête est le premier champ d'en-tête MIME apparaissant dans un message au format MIME. Ce champ d'en-tête apparaît après les autres champs d'en-tête RFC 5322 standard mais avant tout autre champ d'en-tête MIME. Les clients de messagerie compatibles MIME utilisent ce champ d'en-tête pour identifier un message encodé MIME. Lorsque ce champ d'en-tête est absent, les clients de messagerie compatibles MIME identifient le message comme étant en texte brut.

Champ d’en-tête Content-Type

Valeur par défaut : text/plain

Ce champ d'en-tête identifie le type de média du contenu du message, comme décrit dans la norme RFC 2046. Un type de média se compose des éléments suivants :

  • Type :

    • Les types qui commencent par x- ne sont pas standard. L'IANA (Internet Assigned Numbers Authority) conserve une liste des types de médias enregistrés. Pour plus d'informations, consultez la page relative aux types de médias MIME.

    • Le type de média multipart permet de composer un message contenant plusieurs parties en utilisant des sections définies par différents types de médias. Certaines valeurs de champ Content-Type incluent text/plain, text/html, multipart/mixedet multipart/alternative.

  • Un sous-type : les sous-types commençant par vnd. sont spécifiques au fournisseur.

  • Un ou plusieurs paramètres facultatifs : par exemple, un charset= paramètre qui définit l’encodage de caractères MIME.

Champ d’en-tête Content-Transfer-Encoding

Valeur par défaut : 7bit

Ce champ d'en-tête peut décrire les informations suivantes sur un message :

  • l'algorithme de codage utilisé pour transformer toute donnée texte ou binaire non-US-ASCII existant dans le corps du message.
  • un indicateur décrivant la condition actuelle du corps du message.

Le champ d'en-tête Content-Transfer-Encoding d'un message MIME peut prendre plusieurs valeurs. Lorsque le champ d'en-tête Content-Transfer-Encoding apparaît dans l'en-tête du message, il s'applique à l'ensemble du corps du message. Lorsque le champ d'en-tête Content-Transfer-Encoding apparaît dans une des parties d'un message en plusieurs parties, il ne s'applique qu'à cette partie du message.

Quand un algorithme de codage est appliqué aux données du corps du message, celles-ci sont transformées en texte brut US-ASCII. Cette transformation permet au message de transiter sur des serveurs de messagerie plus anciens qui ne prennent en charge que les messages en texte US-ASCII. Les valeurs du champ d'en-tête Content-Transfer-Encoding indiquant qu'un algorithme de codage a été utilisé pour le corps du message sont les suivantes :

  • Quoted-printable: utilise des caractères US-ASCII imprimables pour encoder les données du corps du message. Si le texte du message d'origine est essentiellement du texte US-ASCII, le codage Quoted-printable fournit des résultats relativement lisibles et compacts. Tous les caractères de texte US-ASCII imprimables à l'exception du signe égal (=) peuvent être représentés sans codage.

  • Base64: basé principalement sur la norme pem (Privacy-Enhanced Mail) définie dans RFC 4648. Le codage Base64 utilise l'algorithme de codage alphabétique de 64 caractères et les caractères de remplissage de sortie définis par PEM pour coder les données du corps du message. Un message codé Base64 est généralement 33 % plus volumineux que le message d'origine. Le codage Base64 crée un accroissement prévisible de la taille du message et convient parfaitement pour des données binaires et du texte non US-ASCII.

Il est rare que plusieurs algorithmes de codage soient utilisés dans le même message.

Si aucun algorithme de codage n'est utilisé dans le corps du message, le champ d'en-tête Content-Transfer-Encoding identifie simplement la condition actuelle des données du corps du message. Les valeurs du champ d'en-tête Content-Transfer-Encoding indiquant qu'aucun algorithme de codage n'a été utilisé pour le corps du message sont les suivantes :

  • 7bit: indique que les données du corps du message sont déjà au format RFC 5322. Plus précisément, cela signifie que les conditions suivantes doivent être remplies :

    • Les lignes de texte doivent compter moins de 998 caractères.

    • Tous les caractères doivent être des caractères de texte US-ASCII de la plage de valeurs 1 à 127.

    • Les caractères CR et LF ne peuvent apparaître ensemble que pour indiquer la fin d'une ligne de texte.

      Le corps du message tout entier peut être 7 bits ou, s'il s'agit d'un message en plusieurs parties, seule une partie du message peut être 7 bits. Si le message en plusieurs parties contient d'autres parties comprenant des données binaires ou du texte non US-ASCII, cette partie du message doit être codée à l'aide des algorithmes de codage Quoted-printable ou Base64.

      Des messages ayant un corps 7 bits peuvent transiter entre des serveurs de messagerie grâce à la commande DATA standard.

  • 8bit: indique que les données du corps du message contiennent des caractères non-US-ASCII. Plus précisément, cela signifie que les conditions suivantes doivent être remplies :

    • Les lignes de texte doivent compter moins de 998 caractères.

    • Un ou plusieurs caractères du corps du message ont des valeurs supérieures aux valeurs US-ASCII 127.

    • Les caractères CR et LF ne peuvent apparaître ensemble que pour indiquer la fin d'une ligne de texte.

      Le corps du message tout entier peut être 8 bits ou, s'il s'agit d'un message en plusieurs parties, seule une partie du message peut être 8 bits. Si le message en plusieurs parties contient d'autres parties comprenant des données binaires, cette partie du message doit être codée à l'aide des algorithmes de codage Quoted-printable ou Base64.

      Les messages dont le corps est en 8 bits ne peuvent transiter qu'entre des serveurs de messagerie qui prennent en charge l'extension SMTP 8BITMIME définie dans la norme RFC 6152, tels que Exchange 2000 Server ou des versions ultérieures. Plus précisément, cela signifie que les conditions suivantes doivent être remplies :

    • Le mot-clé 8BITMIME doit être annoncé dans la réponse EHLO du serveur.

    • Les messages sont malgré tout transférés à l'aide de la commande DATA standard du protocole SMTP. Toutefois, le BODY=8BITMIME paramètre doit être ajouté à la fin de la commande MAIL FROM .

  • Binary: indique que le corps du message contient des données binaires ou texte non-US-ASCII. Plus précisément, cela signifie que les conditions suivantes sont remplies :

    • Toute séquence de caractères est autorisée.

    • Il n'existe aucune limitation à la longueur de ligne.

    • Les éléments de message binaires ne nécessitent pas de codage.

      Les messages dont le corps est binaire ne peuvent transiter qu'entre des serveurs de messagerie qui prennent en charge l'extension SMTP BINARYMIME définie dans la norme RFC 3030, tels que Exchange 2000 Server ou des versions ultérieures. Plus précisément, cela signifie que les conditions suivantes doivent être remplies :

    • Le mot-clé BINARYMIME doit être annoncé dans la réponse EHLO du serveur.

    • L'extension SMTP BINARYMIME ne peut être utilisée qu'avec l'extension SMTP CHUNKING. Chunking permet d’envoyer des corps de message volumineux en plusieurs blocs de plus petite taille. L'extension Chunking est également définie dans la norme RFC 3030. Le mot-clé CHUNKING doit également être annoncé dans la réponse EHLO du serveur.

    • Les messages sont transférés à l'aide de la commande BDAT au lieu de la commande DATA standard.

    • Le BODY=BINARYMIME paramètre doit être ajouté à la fin de la commande MAIL FROM lorsque le message a un corps de message.

Les valeurs 7bit, 8bitet Binary n’existent jamais ensemble dans le même message en plusieurs parties (les valeurs s’excluent mutuellement). Les Quoted-printable valeurs ou Base64 peuvent apparaître dans un corps de message en plusieurs parties 7 bits ou 8 bits, mais jamais dans un corps de message binaire. Si un corps de message en plusieurs parties contient plusieurs parties composées de contenu 7 bits et 8 bits, le message entier est classifié 8 bits. Si un corps de message en plusieurs parties contient plusieurs parties composées de contenu 7 bits, 8 bits et binaire, le message entier est classifié binaire.

Champ d’en-tête Content-Disposition

Valeur par défaut : Attachment

Ce champ d'en-tête indique à un client de messagerie compatible MIME la manière d'afficher un fichier joint ; il est décrit dans la norme RFC 2183. Les valeurs valides sont les suivantes :

  • Inline: la pièce jointe s’affiche dans le corps du message.

  • Attachment: le fichier joint apparaît sous la forme d’une pièce jointe standard distincte du corps du message. D’autres paramètres ont également ces valeurs (par exemple, Filename, Creation-dateet Size).