Partage via

Conversion de contenu

  • Article

S’applique à : Exchange Server 2013

La conversion de contenu est le processus consistant à mettre correctement en forme un message pour chaque destinataire. La décision d’effectuer une conversion de contenu sur un message dépend de la destination et du format du message en cours de traitement. Dans Microsoft Exchange Server 2013, il existe deux types de conversion de contenu :

  • 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égorisateur dans le service de transport sur le 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 Suivi de la conversion de contenu.

Cette rubrique explique les options de conversion de message pour les destinataires externes.

Formats de message Exchange et Outlook

La liste suivante décrit les formats de message de base disponibles dans Exchange et Microsoft Outlook :

  • Texte brut : un message en texte brut utilise uniquement du texte US-ASCII, comme décrit dans RFC 2822. 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 codé MIME avec une valeur Content-Type de text/plain et une valeur Content-Transfer-Encoding de 7bit pour les parties texte d’un message à 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 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. TNEF et RTF peuvent être utilisés indifféremment. Le format de message en texte enrichi est complètement différent du format de document de texte enrichi disponible dans Microsoft Word.

    Seuls Outlook et quelques autres clients de messagerie MAPI comprennent les messages RTF.

  • 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 d’origine mise en forme du message, y compris, par exemple, les polices, les tailles de texte et les couleurs du texte

    • Objets OLE, y compris, par exemple, des images incorporées ou des documents Microsoft Office incorporés

    • Fonctionnalités Spéciales d’Outlook, notamment, les formulaires personnalisés, les boutons de vote ou les 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 RFC 2822 composé uniquement de texte US-ASCII avec une pièce jointe Winmail.dat encodée en Uuencode

    • message en plusieurs parties codé MIME contenant une pièce jointe Winmail.dat

      Un client de messagerie compatible MAPI qui comprend parfaitement TNEF, tel qu’Outlook, traite la pièce jointe Winmail.dat et affiche le contenu du message d’origine sans jamais afficher la pièce jointe Winmail.dat. Un client de messagerie ne comprenant pas le format TNEF peut présenter un message 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 tels que Microsoft Outlook Express peuvent ne pas comprendre 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 Content-Transfer-Encoding binary. 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 dont la valeur Content-Transfer-Encoding est Binary ne peuvent être transférés qu’entre des serveurs de messagerie SMTP qui prennent en charge et publient les extensions SMTP BINARYMIME et CHUNKING, comme défini dans RFC 3030. Les messages sont toujours transférés entre les messages SMTP à 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 (*).

  • 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 principale différence est que les utilisateurs de messagerie ont des comptes qui peuvent être utilisés pour se connecter au domaine Active Directory et accéder aux ressources de l’organisation.

  • Paramètres Outlook : Dans Outlook, vous pouvez définir les options de mise en forme et d’encodage des messages décrites dans la liste suivante :

    • 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 : vous pouvez contrôler si les messages TNEF sont envoyés à des destinataires spécifiques ou s’ils sont d’abord convertis dans un format plus compatible. Vous pouvez définir les options de conversion de contacts spécifiques dans votre dossier Contacts, et vous pouvez remplacer les options de conversion d’un destinataire spécifique dans les champs À, Cc ou Cci lorsque vous composez un message. Ces options de conversion ne sont pas disponibles pour des destinataires dans l'organisation Exchange.

    • Options d’encodage des messages des destinataires Internet : vous pouvez contrôler les options d’encodage MIME ou texte brut pour des contacts spécifiques dans votre dossier Contacts, et vous pouvez remplacer les options de conversion d’un destinataire spécifique dans les champs À, Cc ou Cci lorsque vous composez un message. 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.

Options de conversion TNEF

Vous pouvez spécifier les options de conversion TNEF aux niveaux suivants :

  • paramètres de domaine distant.
  • Paramètres d’utilisateur de messagerie et de contact de messagerie
  • Paramètres Outlook, notamment :
    • format des messages
    • format de message Internet
    • Format de message de destinataire Internet

Options d’encodage des messages

Vous pouvez spécifier les options d’encodage des messages aux niveaux suivants :

  • paramètres de domaine distant.
  • Paramètres d’utilisateur de messagerie et de contact de messagerie
  • Paramètres Outlook, notamment :
    • format des messages
    • Message Internet
    • Format de message de destinataire Internet
    • options de codage de jeu de caractères de message

Pour plus d’informations, consultez Options d’encodage de message.

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 du message : l’enveloppe du message est définie dans RFC 2821. 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 2822. 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 corps de champ d’en-tête unique en plusieurs lignes, comme décrit dans la section 2.2.3 de la RFC 2822. Les autres exigences de syntaxe du corps de champ sont décrites dans les sections 3 et 4 de la norme RFC 2822.

    • 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 RFC 2045, RFC 2046, RFC 2047, RFC 2048 et RFC 2077. MIME définit un ensemble de champs d'en-tête qui spécifient des attributs de message supplémentaires. Le tableau suivant décrit certains champs d'en-tête MIME importants.

Champs d’en-tête MIME importants

Nom de champ d'en-tête Valeur par défaut Description
MIME-Version 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 2822 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.
Content-Type 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 consiste en un type, un sous-type et un ou plusieurs paramètres facultatifs, tel qu’un paramètre charset= définissant le codage de caractères MIME. Les types qui commencent par « x- » ne sont pas standard. Les sous-types qui commencent par « vnd . » sont spécifiques au fournisseur. 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 comprennent text/plain, text/html, multipart/mixed et multipart/alternative.
Content-Transfer-Encoding 7 bits 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 SMTP 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 qui indiquent qu’un algorithme d’encodage a été utilisé sur le corps du message sont les suivantes :

  • Quoted-printable : cet algorithme d’encodage 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 : cet algorithme d’encodage est principalement basé sur la norme PEM (Privacy-Enhanced Mail) définie dans RFC 1421. 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 suivantes du champ d’en-tête Content-Transfer-Encoding indiquent qu’aucun algorithme d’encodage n’a été utilisé sur le corps du message :

  • 7 bits : cette valeur indique que les données du corps du message sont déjà au format RFC 2822. 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 entier peut être 7 bits, ou une partie du corps du message dans un message en plusieurs parties 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.

    Les messages qui ont des corps 7 bits peuvent circuler entre les serveurs de messagerie SMTP à l’aide de la commande DATA standard.

  • 8 bits : cette valeur 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 entier du message peut être 8 bits, ou une partie du corps du message dans un message en plusieurs parties 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 qui ont un corps 8 bits peuvent uniquement circuler entre les serveurs de messagerie SMTP qui prennent en charge l’extension SMTP 8BITMIME telle que définie dans RFC 1652, tels que les serveurs exécutant Exchange 2000 Server ou des versions plus récentes. 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 paramètre BODY=8BITMIME doit être ajouté à la fin de la commande MAIL FROM.
  • Binaire : cette valeur indique que le corps du message contient du texte ou des données binaires 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 qui ont des corps binaires peuvent uniquement voyager entre les serveurs de messagerie SMTP qui prennent en charge l’extension SMTP BINARYMIME telle que définie dans RFC 3030, tels que les serveurs exécutant Exchange 2000 Server ou des versions plus récentes. 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 paramètre BODY=BINARYMIME doit être ajouté à la fin de la commande MAIL FROM si le message contient un corps de message.

Les valeurs 7 bits, 8 bits et Binaire n’existent jamais ensemble dans le même message en plusieurs parties. Les valeurs s’excluent mutuellement. Les valeurs Quoted-printable 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 différentes parties composées de contenu 7 bits et 8 bits, l’ensemble du message est classé comme 8 bits. Si un corps de message en plusieurs parties contient différentes parties composées de contenu 7 bits, 8 bits et binaire, l’ensemble du message est classé comme binaire.
Content-Disposition Pièce jointe 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 de ce champ peuvent être Inline ou Attachment. Si la valeur de ce champ est Inline, la pièce jointe s’affiche dans le corps du message. Si la valeur de ce champ est Attachment, le fichier joint s’affiche comme pièce jointe ordinaire séparée du corps du message. D’autres paramètres sont disponibles si la valeur est Attachment, tels que Filename, Creation-date et Size.