Conversão de conteúdo

  • Artigo

Aplica-se a: Exchange Server 2013

A conversão de conteúdo é o processo de formatação correta de uma mensagem para cada destinatário. A decisão de executar a conversão de conteúdo em uma mensagem depende do destino e formato da mensagem que está sendo processada. Em Microsoft Exchange Server 2013, há dois tipos diferentes de conversão de conteúdo:

  • Conversão de mensagem para destinatários externos: esse tipo de conversão de conteúdo inclui as opções de conversão TNEF (Formato de Encapsulamento Neutro de Transporte) e opções de codificação de mensagens para destinatários externos. As mensagens enviadas aos destinatários dentro da organização do Exchange não exigem esse tipo de conversão de conteúdo. Esse tipo de conversão de conteúdo é manipulado pelo categorizador no serviço de transporte no servidor da caixa de correio. A categorização em cada mensagem acontece depois que uma mensagem recém-chegada é colocada na fila De envio. Além da resolução e resolução de roteamento do destinatário, a conversão de conteúdo é executada na mensagem antes que a mensagem seja colocada em uma fila de entrega. Se uma única mensagem contiver vários destinatários, o categorizador determinará a codificação apropriada para cada destinatário de mensagem. O rastreamento de conversão de conteúdo não captura nenhuma falha de conversão de conteúdo que o categorizador encontra ao converter mensagens enviadas para destinatários externos.

  • Conversão MAPI para destinatários internos: esse tipo de conversão de conteúdo é manipulado pelo serviço de Transporte de Caixa de Correio. O serviço de Transporte de Caixa de Correio existe nos servidores da caixa de correio para transmitir mensagens entre bancos de dados de caixa de correio no servidor local e o serviço de transporte em servidores de caixa de correio. Especificamente, o serviço Envio de Transporte da Caixa de Correio transmite mensagens da Caixa de Saída do remetente para o serviço de transporte em um servidor de caixa de correio. O serviço Entrega de Transporte de Caixa de Correio transmite mensagens do serviço de transporte em um servidor de caixa de correio para a caixa de entrada do destinatário. O serviço Envio de Transporte da Caixa de Correio converte todas as mensagens de saída do MAPI e o serviço de Entrega de Transporte de Caixa de Correio converte todas as mensagens de entrada em MAPI. O rastreamento de conversão de conteúdo captura essas falhas de conversão MAPI. Para obter mais informações, consulte Rastreamento de conversão de conteúdo.

Este tópico explica as opções de conversão de mensagem para destinatários externos.

Formatos de mensagem do Exchange e do Outlook

A lista a seguir descreve os formatos de mensagem básicos disponíveis no Exchange e no Microsoft Outlook:

  • Texto simples: uma mensagem de texto simples usa apenas texto US-ASCII conforme descrito no RFC 2822. A mensagem não pode conter fontes diferentes ou outra formatação de texto. Os dois formatos a seguir podem ser usados para uma mensagem de texto simples:

    • Os cabeçalhos da mensagem e o corpo da mensagem são compostos por texto US-ASCII. Os anexos devem ser codificados usando Uuencode. O Uuencode representa a codificação Unix-to-Unix e define um algoritmo de codificação para armazenar anexos binários no corpo de uma mensagem de email usando caracteres de texto US-ASCII.

    • A mensagem é codificada por MIME com um valor tipo de conteúdo de texto/simples e um valor de codificação de transferência de conteúdo de 7bits para as partes de texto de uma mensagem multipart. Todos os anexos de mensagem são codificados usando a codificação quoted-printable ou Base64. Por padrão, quando você compõe e envia uma mensagem de texto simples no Outlook, a mensagem é codificada por MIME com um valor tipo de conteúdo de texto/simples.

  • HTML: uma mensagem HTML dá suporte à formatação de texto, imagens em segundo plano, tabelas, pontos de bala e outros elementos gráficos. Por definição, uma mensagem formatada em HTML deve ser codificada por MIME para preservar esses elementos de formatação.

  • Formato de texto avançado (RTF): o RTF dá suporte à formatação de texto e a outros elementos gráficos. RTF é sinônimo de TNEF. TNEF e RTF podem ser usados de forma intercambiável. O formato de mensagem de texto avançado é completamente diferente do formato de documento de texto avançado disponível no Microsoft Word.

    Apenas o Outlook e alguns outros clientes de email MAPI entendem as mensagens RTF.

  • TNEF: O Formato de Encapsulamento Neutro de Transporte é um formato específico da Microsoft para encapsular propriedades de mensagem MAPI. Uma mensagem TNEF contém uma versão de texto com formatação da mensagem e um anexo que carrega a versão formatada original da mensagem. Em geral, esse anexo é chamado de Winmail.dat. O anexo Winmail.dat inclui as seguintes informações:

    • Versão formatada original da mensagem, incluindo, por exemplo, fontes, tamanhos de texto e cores de texto

    • Objetos OLE, incluindo, por exemplo, imagens inseridas ou documentos inseridos do Microsoft Office

    • Recursos especiais do Outlook, incluindo, por exemplo, formulários personalizados, botões de votação ou solicitações de reunião

    • Anexos de mensagem regulares que estavam na mensagem original

      A mensagem de texto simples resultante pode ser representada nos seguintes formatos:

    • Mensagem compatível com RFC 2822 composta apenas por texto US-ASCII com um anexo Winmail.dat codificado em Uuencode

    • Mensagem codificada por MIME multipart que tem um anexo Winmail.dat

      Um cliente de email compatível com MAPI que entende completamente o TNEF, como o Outlook, processa o anexo Winmail.dat e exibe o conteúdo da mensagem original sem nunca exibir o anexo Winmail.dat. Um cliente de email que não entende o TNEF pode apresentar uma mensagem de TNEF de qualquer uma das seguintes maneiras:

    • A versão de texto simples da mensagem é exibida e a mensagem contém um anexo chamado Winmail.dat, Win.dat ou algum outro nome genérico, como Att_nnnnn_.dat ou Att_nnnnn_.eml, em que o espaço reservado nnnnn representa um número aleatório.

    • A versão do texto sem formatação da mensagem é exibida. O anexo TNEF é ignorado ou removido. O resultado é uma mensagem de texto sem formatação.

    • Servidores de mensagens que entendem o TNEF podem ser configurados para remover anexos TNEF de mensagens de entrada. O resultado é uma mensagem de texto sem formatação. Além disso, alguns clientes de email, como o Microsoft Outlook Express, podem não entender o TNEF, mas reconhecer e ignorar anexos TNEF. O resultado é uma mensagem de texto sem formatação.

      Existem utilitários de terceiros que podem ajudar a converter os anexos Winmail.dat

      O TNEF é entendido por todas as versões do Exchange desde Exchange Server versão 5.5.

  • Formato de encapsulamento neutro de transporte de resumo (STNEF): STNEF é equivalente a TNEF. No entanto, as mensagens STNEF são codificadas de forma diferente das mensagens TNEF. Especificamente, as mensagens STNEF são sempre codificadas por MIME e sempre têm um valor de codificação de transferência de conteúdo do Binary. Portanto, não há nenhuma representação de texto simples da mensagem e não há nenhum anexo winmail.dat distinto contido no corpo da mensagem. Toda a mensagem é representada usando apenas dados binários. As mensagens que têm um valor de Transferência de Conteúdo-Codificação do Binary só podem ser transferidas entre servidores de mensagens SMTP que dão suporte e anunciam as extensões BINARYMIME e CHUNKING SMTP, conforme definido no RFC 3030. As mensagens são sempre transferidas entre mensagens SMTP usando o comando BDAT, em vez do comando DATA padrão.

    O STNEF é entendido por todas as versões do Exchange desde o Exchange 2000. O STNEF é usado automaticamente para todas as mensagens transferidas entre servidores do Exchange na organização desde o modo nativo Exchange Server 2003.

    O Exchange nunca envia mensagens STNEF para destinatários externos. Somente as mensagens TNEF podem ser enviadas para destinatários fora da organização do Exchange.

Opções de conversão de conteúdo para destinatários externos

As opções de conversão de conteúdo que você pode definir em uma organização do Exchange para destinatários externos podem ser descritas nas seguintes categorias:

  • Opções de conversão TNEF: essas opções de conversão especificam se o TNEF deve ser preservado ou removido das mensagens que saem da organização do Exchange.

  • Opções de codificação de mensagens: essas opções especificam opções de codificação de mensagens, como mime e conjuntos de caracteres não MIME, codificação de mensagens e formatos de anexo.

Essas opções de conversão e codificação são independentes umas das outras. Por exemplo, se as mensagens TNEF podem sair da organização do Exchange não estão relacionadas às configurações de codificação MIME ou às configurações de codificação de texto simples dessas mensagens.

Você pode especificar a conversão de conteúdo em vários níveis da organização do Exchange, conforme descrito na lista a seguir:

  • Configurações de domínio remoto: domínios remotos definem as configurações para transferências de mensagens de saída entre a organização exchange e domínios externos.. Mesmo que você não crie entradas de domínio remoto para domínios específicos, há um domínio remoto predefinido chamado Default que se aplica a todos os espaços de endereço remoto (*).

  • Configurações de contato de usuário e email: os usuários de email e os contatos de email são semelhantes porque ambos têm endereços de email externos e contêm informações sobre pessoas fora da organização do Exchange. A principal diferença é que os usuários de email têm contas que podem ser usadas para fazer logon no domínio do Active Directory e acessar recursos na organização.

  • Configurações do Outlook: no Outlook, você pode definir as opções de formatação e codificação de mensagens descritas na lista a seguir:

    • Formato de mensagem: você pode definir o formato de mensagem padrão para todas as mensagens. Você pode substituir o formato padrão da mensagem ao escrever uma mensagem específica.

    • Formato de mensagem na Internet: você pode controlar se as mensagens TNEF são enviadas para destinatários remotos ou se elas são convertidas pela primeira vez em um formato mais compatível. Você também pode especificar várias opções de codificação de mensagem para mensagens enviadas para destinatários remotos. Essas configurações não se aplicam a mensagens enviadas a destinatários na organização exchange.

    • Formato de mensagem do destinatário da Internet: você pode controlar se as mensagens TNEF são enviadas para destinatários específicos ou se elas são convertidas pela primeira vez em um formato mais compatível. Você pode definir as opções de conversão para contatos específicos na pasta Contatos e pode substituir as opções de conversão para um destinatário específico nos campos To, Cc ou Bcc enquanto compõe uma mensagem. Essas opções de conversão não estão disponíveis para destinatários na organização do Exchange.

    • Opções de codificação de mensagens do destinatário da Internet: você pode controlar as opções mime ou codificação de texto simples para contatos específicos em sua pasta Contatos, e você pode substituir as opções de conversão para um destinatário específico nos campos To, Cc ou Bcc enquanto compõe uma mensagem. Essas opções de conversão não estão disponíveis para destinatários na organização do Exchange.

    • Opções internacionais: você pode controlar os conjuntos de caracteres usados nas mensagens.

Opções de conversão de TNEF

Você pode especificar as opções de conversão TNEF nos seguintes níveis:

  • Configurações de domínio remoto
  • Configurações de contato de email e usuário de email
  • Configurações do Outlook, incluindo:
    • Formato de mensagem
    • Formato de mensagem da Internet
    • Formato de mensagem de destinatário da Internet

Opções de codificação de mensagem

Você pode especificar as opções de codificação de mensagens nos seguintes níveis:

  • Configurações de domínio remoto
  • Configurações de contato de email e usuário de email
  • Configurações do Outlook, incluindo:
    • Formato de mensagem
    • Mensagem de Internet
    • Formato de mensagem de destinatário da Internet
    • Opções de codificação de conjunto de caracteres de mensagem

Para obter informações detalhadas, consulte Opções de codificação de mensagens.

Entender a estrutura das mensagens de email

Para entender melhor as opções de conversão de conteúdo para destinatários externos, você precisa entender a estrutura das mensagens de email. Uma mensagem SMTP é baseada em texto US-ASCII simples de 7 bits para compor e enviar mensagens de email. Uma mensagem SMTP padrão consiste nos seguintes elementos:

  • Envelope da mensagem: o envelope da mensagem é definido no RFC 2821. O envelope de mensagem contém informações necessárias para transmitir e entregar a mensagem. Os destinatários nunca veem o envelope da mensagem, pois ele é gerado pelo processo de transmissão de mensagens e não faz parte do conteúdo da mensagem.

  • Conteúdo da mensagem: o conteúdo da mensagem é definido no RFC 2822. O conteúdo da mensagem consiste nos seguintes elementos:

    • Cabeçalho da mensagem: o cabeçalho da mensagem é uma coleção de campos de cabeçalho. Os campos de cabeçalho consistem em um nome de campo, seguidos por um ponto (:) caractere, seguido por um corpo de campo e encerrado por uma combinação de caracteres CR/LF (retorno de transporte/alimentação de linha).

      • Um nome de campo deve ser composto por caracteres de texto US-ASCII imprimíveis, exceto o cólon (:) Caractere. Especificamente, caracteres ASCII que têm valores de 33 a 57 e 59 a 126 são permitidos.

      • Um corpo de campo pode ser composto por caracteres US-ASCII, exceto pelo caractere CR (retorno de carruagem) e pelo caractere LF (feed de linha). No entanto, um corpo de campo pode conter a combinação de caracteres CR/LF quando usado na dobra de cabeçalho. A dobra de cabeçalho é a separação de um único corpo de campo de cabeçalho em várias linhas, conforme descrito na seção 2.2.3 do RFC 2822. Outros requisitos de sintaxe do corpo do campo são descritos nas seções 3 e 4 do RFC 2822.

    • Corpo da mensagem: o corpo da mensagem é uma coleção de linhas de caracteres de texto US-ASCII que aparece após o cabeçalho da mensagem. O cabeçalho da mensagem e o corpo da mensagem são separados por uma linha em branco que termina com a combinação de caracteres CR/LF. O corpo da mensagem é opcional. Qualquer linha de texto no corpo da mensagem deve ter menos de 998 caracteres. Os caracteres CR e LF só podem aparecer juntos para indicar o fim de uma linha.

Quando as mensagens SMTP contêm elementos que não são texto US-ASCII simples, a mensagem deve ser codificada para preservar esses elementos. O padrão MIME define um método de codificação de conteúdo em mensagens que não são texto. O MIME permite texto em outros conjuntos de caracteres, anexos sem texto, corpos de mensagens multiparte e campos de cabeçalho em outros conjuntos de caracteres. O MIME é definido em RFC 2045, RFC 2046, RFC 2047, RFC 2048 e RFC 2077. O MIME define uma coleção de campos de cabeçalho que especifica atributos de mensagem adicionais. A tabela a seguir descreve alguns campos importantes de cabeçalho MIME.

Campos de cabeçalho MIME importantes

Nome do campo cabeçalho Valor padrão Descrição
MIME-Version 1.0 Esse campo de cabeçalho é o primeiro campo de cabeçalho MIME que aparece em uma mensagem formatada por MIME. Esse campo de cabeçalho é exibido após os outros campos de cabeçalho rfc 2822 padrão, mas antes de qualquer outro campos de cabeçalho MIME. Os clientes de email com reconhecimento MIME usam esse campo de cabeçalho para identificar uma mensagem codificada pelo MIME. Quando esse campo de cabeçalho está ausente, os clientes de email com reconhecimento MIME identificam a mensagem como texto simples.
Content-Type texto/simples Esse campo de cabeçalho identifica o tipo de mídia do conteúdo da mensagem, conforme descrito no RFC 2046. Um tipo de mídia consiste em um tipo, um subtipo e um ou mais parâmetros opcionais, como um parâmetro charset= que define a codificação de caracteres MIME. Tipos que começam com "x-" não são padrão. Os subtipos que começam com "vnd". são específicos do fornecedor. A IANA (Autoridade de Números Atribuídos à Internet) mantém uma lista de tipos de mídia registrados. Para obter mais informações, consulte Tipos de Mídia MIME.

O tipo de mídia multiparte permite várias partes de mensagem na mesma mensagem usando seções definidas por diferentes tipos de mídia. Alguns valores de campo tipo de conteúdo incluem texto/planície, texto/html, multipart/mixed e multipart/alternative.
Codificação de transferência de conteúdo 7bit Este campo de cabeçalho pode descrever as seguintes informações sobre uma mensagem:
  • O algoritmo de codificação usado para transformar qualquer texto não US-ASCII ou dados binários existentes no corpo da mensagem.
  • Um indicador que descreve a condição atual do corpo da mensagem.

Pode haver vários valores do campo cabeçalho Transferência de Conteúdo-Codificação em uma mensagem MIME. Quando o campo cabeçalho Transferência de Conteúdo-Codificação aparece no cabeçalho da mensagem, ele se aplica a todo o corpo da mensagem. Quando o campo cabeçalho Transferência de Conteúdo-Codificação é exibido em uma das partes de uma mensagem de várias partes, ele se aplica apenas a essa parte da mensagem.

Quando um algoritmo de codificação é aplicado aos dados do corpo da mensagem, os dados do corpo da mensagem são transformados em texto us-ASCII simples. Essa transformação permite que a mensagem viaje por servidores de mensagens SMTP mais antigos que só dão suporte a mensagens no texto US-ASCII. Os valores do campo cabeçalho transferência-codificação de conteúdo que indicam que um algoritmo de codificação foi usado no corpo da mensagem são os seguintes:

  • Imprimível entre aspas: este algoritmo de codificação usa caracteres US-ASCII imprimíveis para codificar os dados do corpo da mensagem. Se o texto da mensagem original for principalmente texto US-ASCII, a codificação imprimível entre aspas fornecerá resultados um pouco legíveis e compactos. Todos os caracteres de texto US-ASCII imprimíveis, exceto o caractere de sinal igual (=) podem ser representados sem codificação.
  • Base64: esse algoritmo de codificação baseia-se principalmente no padrão PEM (email aprimorado para privacidade) definido no RFC 1421. A codificação base64 usa o algoritmo de codificação de alfabeto de 64 caracteres e os caracteres de preenchimento de saída definidos pelo PEM para codificar os dados do corpo da mensagem. Uma mensagem codificada do Base64 normalmente é 33% maior que a mensagem original. A codificação base64 cria um aumento previsível no tamanho da mensagem e é ideal para dados binários e texto não US-ASCII.

Normalmente, você não verá vários algoritmos de codificação usados na mesma mensagem.

Quando nenhum algoritmo de codificação foi usado no corpo da mensagem, o campo cabeçalho Content-Transfer-Encoding simplesmente identifica a condição atual dos dados do corpo da mensagem. Os seguintes valores do campo cabeçalho transferência-codificação de conteúdo indicam que nenhum algoritmo de codificação foi usado no corpo da mensagem:

  • 7bit: Esse valor indica que os dados do corpo da mensagem já estão no formato RFC 2822. Especificamente, isso significa que as seguintes condições devem ser verdadeiras:
    • Todas as linhas de texto devem ter menos de 998 caracteres.
    • Todos os caracteres devem ser texto US-ASCII que tenham valores de caractere de 1 a 127.
    • Os caracteres CR e LF só podem ser usados juntos para indicar o fim de uma linha de texto.

    Todo o corpo da mensagem pode ter 7bits ou parte do corpo da mensagem em uma mensagem de várias partes pode ter 7bits. Se a mensagem multipart contiver outras partes que tenham dados binários ou texto não US-ASCII, essa parte da mensagem deve ser codificada usando os algoritmos de codificação Quoted-printable ou Base64.

    Mensagens que têm corpos de 7bits podem viajar entre servidores de mensagens SMTP usando o comando DATA padrão.

  • 8bit: esse valor indica que os dados do corpo da mensagem contêm caracteres não US-ASCII. Especificamente, isso significa que as seguintes condições devem ser verdadeiras:
    • Todas as linhas de texto devem ter menos de 998 caracteres.
    • Um ou mais caracteres no corpo da mensagem têm valores maiores que 127.
    • Os caracteres CR e LF só podem ser usados juntos para indicar o fim de uma linha de texto.

    Todo o corpo da mensagem pode ter 8bits ou parte do corpo da mensagem em uma mensagem de várias partes pode ser 8bit. Se a mensagem multipart contiver outras partes que têm dados binários, essa parte da mensagem deve ser codificada usando os algoritmos de codificação Quoted-printable ou Base64.

    Mensagens que têm corpos de 8bits só podem viajar entre servidores de mensagens SMTP que dão suporte à extensão SMTP 8BITMIME, conforme definido no RFC 1652, como servidores que executam o Exchange 2000 Server ou versões mais recentes. Especificamente, isso significa que as seguintes condições devem ser verdadeiras:

    • A palavra-chave 8BITMIME deve ser anunciada na resposta EHLO do servidor.
    • As mensagens ainda são transferidas usando o comando DATA padrão do SMTP. No entanto, o parâmetro BODY=8BITMIME deve ser adicionado ao final do comando MAIL FROM.
  • Binário: esse valor indica que o corpo da mensagem contém dados binários ou texto não US-ASCII. Especificamente, isso significa que as seguintes condições são verdadeiras:
    • Qualquer sequência de caracteres é permitida.
    • Não há limitação de comprimento de linha.
    • Elementos de mensagem binária não exigem codificação.

    Mensagens que têm corpos binários só podem viajar entre servidores de mensagens SMTP que dão suporte à extensão BINYMIME SMTP, conforme definido no RFC 3030, como servidores que executam o Exchange 2000 Server ou versões mais recentes. Especificamente, isso significa que as seguintes condições devem ser verdadeiras:

    • A palavra-chave BINARYMIME deve ser anunciada na resposta EHLO do servidor.
    • A extensão BINYMIME SMTP só pode ser usada com a extensão SMTP CHUNKING. O dimensionamento permite que corpos de mensagens grandes sejam enviados em vários pedaços menores. O chunking também é definido no RFC 3030. A palavra-chave CHUNKING também deve ser anunciada na resposta EHLO do servidor.
    • As mensagens são transferidas usando o comando BDAT em vez do comando DATA padrão.
    • O parâmetro BODY=BINARYMIME deve ser adicionado ao final do comando MAIL FROM quando a mensagem tiver um corpo de mensagem.

Os valores 7bit, 8bit e Binary nunca existem juntos na mesma mensagem multipart. Os valores são mutuamente exclusivos. Os valores quoted-printable ou Base64 podem aparecer em um corpo de mensagem multiparte de 7bits ou 8bits, mas nunca em um corpo de mensagem binária. Se um corpo de mensagem multiparte contiver diferentes partes compostas por conteúdo de 7bits e 8bits, toda a mensagem será classificada como 8bit. Se um corpo de mensagem multiparte contiver diferentes partes compostas por conteúdo binário, de 7bits e 8bits, toda a mensagem será classificada como Binária.
Disposição de Conteúdo Anexo Este campo de cabeçalho instrui um cliente de email habilitado para MIME sobre como ele deve exibir um arquivo anexado e é descrito no RFC 2183. Os valores desse campo podem ser embutidos ou anexos. Quando o valor desse campo é embutido, o anexo é exibido no corpo da mensagem. Quando o valor desse campo é Anexo, o arquivo anexado aparece como um anexo regular separado do corpo da mensagem. Outros parâmetros estão disponíveis quando o valor é Anexo, como Nome do Arquivo, Data de Criação e Tamanho.