Conversão de conteúdo em Exchange Server

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. Os tipos de conversão de conteúdo que ocorrem no Exchange 2016 e no Exchange 2019 estão inalterados em relação ao Exchange 2013:

• 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 em um servidor de 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 Gerenciando o rastreamento de conversão de conteúdo.

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 Outlook:

• Texto simples: uma mensagem de texto simples usa apenas texto US-ASCII conforme descrito no RFC 5322. 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 text/plain, e um valor 7bit de codificação de transferência de conteúdo 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 text/plain.

• 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 Word.

• 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 (por exemplo, fontes, tamanhos de texto e cores de texto)
  • Objetos OLE (por exemplo, imagens inseridas ou documentos inseridos do Office)
  • Recursos especiais do Outlook (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 5322 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

  O Outlook e outros clientes de email que entendem completamente o TNEF processam o anexo Winmail.dat e exibem o conteúdo da mensagem original sem nunca exibir o anexo Winmail.dat. Email clientes que não entendem que o TNEF pode apresentar mensagens 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 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 pelo MIME e sempre têm o valor BinaryContent-Transfer-Encoding . 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 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 servidores de mensagens 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 (*). Para obter mais informações sobre domínios remotos, consulte Remote Domains.

• 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 usar para fazer logon no Active Directory e acessar recursos na organização. Para mais informações, consulte Destinatários.

• Configurações do Outlook: você pode definir estas opções de formatação e codificação de mensagens no Outlook:

  • 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 (Outlook 2010 ou anterior): você pode controlar se as mensagens TNEF são enviadas para contatos específicos na pasta Contatos. 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 de destinatário da Internet (Outlook 2010 ou anterior): você pode controlar as opções mime ou codificação de texto simples para contatos específicos em sua pasta Contatos. 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.

  Para obter mais informações sobre essas configurações, consulte opções de conversão TNEF e opções de codificação de mensagens em Exchange Server.

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 de mensagem: o envelope da mensagem é definido no RFC 5321. 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 5322. 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 5322. Outros requisitos de sintaxe do corpo do campo são descritos nas seções 3 e 4 do RFC 5322.

  • 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 no RFC 2045, RFC 2046, RFC 2047, RFC 4288, RFC 4289 e RFC 2049. O MIME define uma coleção de campos de cabeçalho que especifica atributos de mensagem adicionais. As seções a seguir descrevem alguns campos importantes de cabeçalho MIME.

MIME-Version campo de cabeçalho

Valor padrão: 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 5322 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.

Campo cabeçalho Tipo de Conteúdo

Valor padrão: text/plain

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:

  • Tipos que começam com x- não são padrão. 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 text/plain, text/html, multipart/mixede multipart/alternative.

• Um subtipo: subtipos que começam com vnd. são específicos do fornecedor.

• Um ou mais parâmetros opcionais: por exemplo, um charset= parâmetro que define a codificação de caracteres MIME.

Campo de cabeçalho Transferência de Conteúdo

Valor padrão: 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 mais antigos que só dão suporte a mensagens no texto US-ASCII. Os valores de campo de cabeçalho Transferência de Conteúdo que indicam que um algoritmo de codificação foi usado no corpo da mensagem são:

• Quoted-printable: 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: com base principalmente no padrão PEM (email aprimorado para privacidade) definido no RFC 4648. 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 valores de campo de cabeçalho Transferência de Conteúdo que indicam que nenhum algoritmo de codificação foi usado no corpo da mensagem são:

• 7bit: indica que os dados do corpo da mensagem já estão no formato RFC 5322. 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 7 bits ou parte do corpo da mensagem em uma mensagem de várias partes pode ser de 7 bits. 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 com corpos de 7 bits podem viajar entre servidores de mensagens usando o comando DATA padrão.

• 8bit: 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 ser de 8 bits ou parte do corpo da mensagem em uma mensagem de várias partes pode ser de 8 bits. 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 com corpos de 8 bits só podem viajar entre servidores de mensagens que dão suporte à extensão SMTP 8BITMIME , conforme definido no RFC 6152, como o Exchange 2000 Server ou posterior. 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 BODY=8BITMIME parâmetro deve ser adicionado ao final do comando MAIL FROM .

• Binary: 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 que dão suporte à extensão BINYMIME SMTP, conforme definido no RFC 3030, como o Exchange 2000 Server ou posterior. 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 BODY=BINARYMIME parâmetro deve ser adicionado ao final do comando MAIL FROM quando a mensagem tiver um corpo de mensagem.

Os valores 7bit, 8bite Binary nunca existem juntos na mesma mensagem multipart (os valores são mutuamente exclusivos). Os Quoted-printable valores ou Base64 podem aparecer em um corpo de mensagem multipart de 7 bits ou 8 bits, mas nunca em um corpo de mensagem binária. Se um corpo de mensagem de várias partes contiver diferentes partes compostas por conteúdo de 7 bits e 8 bits, toda a mensagem será classificada como de 8 bits. Se um corpo de mensagem multiparte contiver diferentes partes compostas por conteúdo binário, de 7 bits, 8 bits e 7 bits, toda a mensagem será classificada como binária.

Campo cabeçalho disposição de conteúdo

Valor padrão: Attachment

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 válidos são:

• Inline: o anexo é exibido no corpo da mensagem.

• Attachment: o arquivo anexado aparece como um anexo regular separado do corpo da mensagem. Outros parâmetros também estão com esses valores (por exemplo, , Filenamee Creation-dateSize).