Share via

Noções Básicas Sobre Conversão de Conteúdo

  • Artigo

 

Aplica-se a: Exchange Server 2010 SP2, Exchange Server 2010 SP3

Tópico modificado em: 2016-11-28

Conversão de conteúdo é o processo de formatar corretamente uma mensagem para cada destinatário. A decisão de executar a conversão de conteúdo em uma mensagem depende do destino e do formato da mensagem que está sendo processada. As mensagens enviadas para destinatários dentro da organização do Microsoft Exchange Server não exigem nenhuma conversão de conteúdo. Somente as mensagens que são enviadas a destinatários externos podem exigir conversão de conteúdo.

Em uma organização do Exchange Server 2010, a conversão de conteúdo é executada pelo categorizador em um servidor que possua a função de servidor Transporte de Hub instalada. A categorização de cada mensagem ocorre depois que uma mensagem recém-chegada é posicionada na fila de Envio. Além da resolução de destinatário e de roteamento, a conversão de conteúdo é executada na mensagem antes que ela seja colocada em uma fila de entrega. Se uma única mensagem contiver vários destinatários, a conversão de conteúdo determinará a codificação apropriada para cada destinatário da mensagem. Em um servidor de Transporte de Borda, ocorre uma abreviatura de categorização, o que não envolve a conversão de conteúdo.

Sumário

Compreendendo a estrutura de mensagens de email

Formatos de mensagem do Exchange 2010 e do Outlook

Elementos da conversão de conteúdo

Conversão de conteúdo executada pelo driver de repositório

Procurando tarefas de gerenciamento relacionadas a conversão de conteúdo? Consulte Gerenciando Servidores de Transporte.

Compreendendo a estrutura de mensagens de email

Para compreender melhor a conversão de conteúdo, é preciso compreender a estrutura de mensagens de email. Uma mensagem SMTP é baseada em texto simples US-ASCII 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 na RFC 2821 e contém as informações necessárias para transmissão e entrega da mensagem. Os destinatários nunca veem o envelope de mensagem, pois ele é gerado pelo processo de transmissão da mensagem e não faz parte realmente dos conteúdos da mensagem.

  • Conteúdo da mensagem   O conteúdo da mensagem é definido na RFC 2822 e consiste dos seguintes elementos:

    • Cabeçalho da mensagem   O cabeçalho da mensagem é uma coleção de campos de cabeçalho. Campos de cabeçalho consistem dm um nome de campo, seguido por dois-pontos (:), seguido por um corpo de campo e finalizado por uma combinação de caracteres de retorno de carro e avanço de linha (CRLF).

      Um nome de campo deve ser composto por caracteres de texto US-ASCII imprimíveis, exceto o caractere de dois-pontos (:). Especificamente, caracteres ASCII que tenham valores de 33 a 57 e de 59 a 126 são permitidos.

      Um corpo de campo pode ser composto por qualquer caractere US-ASCII, exceto de retorno de carro (CR) e avanço de linha (LF). Entretanto, um corpo de campo pode conter a combinação de caracteres CRLF quando usado em desdobramento de cabeçalho. Desdobramento de cabeçalho é a separação de um único corpo de campo de cabeçalho em várias linhas, conforme descrição na seção 2.2.3 da RFC 2822. Outros requisitos de sintaxe de corpo de campo são descritos nas seções 3 e 4 da RFC 2822.

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

Quando mensagens SMTP contêm elementos que não sejam texto simples US-ASCII, a mensagem deve ser codificada para preservar esses elementos. O padrão MIME define um método de codificação de contexto que não seja texto nas mensagens. O MIME permite texto em outros conjuntos de caracteres, anexos sem texto, corpos de mensagem com diversas partes e campos de cabeçalho em outros conjuntos de caracteres. O MIME é definido nas RFCs 2045, 2046, 2047, 2048 e 2077, além de definir uma coleção de campos de cabeçalho que especificam atributos de mensagens adicionais. A tabela a seguir descreve alguns campos de cabeçalho MIME importantes.

Campos de cabeçalho MIME importantes

Nome do campo de 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 em MIME. Esse campo de cabeçalho é exibido após os demais campos de cabeçalho padrão da RFC 2822, mas antes de qualquer outro campo de cabeçalho MIME. Clientes de email que detectam MIME usam esse campo de cabeçalho para identificar uma mensagem codificada em MIME. Quando esse campo de cabeçalho está ausente, os clientes de email que detectam MIME identificam a mensagem como texto simples.

Content-Type:

text/plain

Esse campo de cabeçalho identifica o tipo de mídia do conteúdo da mensagem, conforme descrito na RFC 2046. Um tipo de mídia consiste em um tipo, um subtipo e em 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. Subtipos que começam com "vnd." são de um fornecedor específico. A IANA (Internet Assigned Numbers Authority) 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 multipart permite várias partes de mensagem na mesma mensagem, usando seções definidas por diferentes tipos de mídia. Alguns valores de campo Content-Type incluem text/plain, text/html, multipart/mixed e multipart/alternative.

Content-Transfer-Encoding

7bit

Esse campo de cabeçalho pode descrever as seguintes informações sobre uma mensagem:

  • O algoritmo de codificação usado para transformar todos os dados binários ou texto não-US-ASCII que existem no corpo da mensagem.

  • Um indicador que descreve a condição atual do corpo da mensagem.

Não pode haver vários valores do cabeçalho do campo Content-Transfer-Encoding em uma mensagem MIME. Quando o campo cabeçalho do Content-Transfer-Encoding é exibido no cabeçalho da mensagem, ele se aplica a todo o corpo da mensagem. Quando o campo cabeçalho do Content-Transfer-Encoding é exibido em uma das partes de uma mensagem com diversas partes, ele se aplica apenas a essa parte da mensagem.

Quando um algoritmo de codificação é aplicado aos dados do corpo da mensagem, eles são transformados em texto simples US-ASCII. Essa transformação permite que a mensagem percorra servidores de mensagens SMTP antigos que só aceitam mensagens em texto US-ASCII. Os valores do campo cabeçalho do Content-Transfer-Encoding que indicam o uso de um algoritmo de codificação no corpo da mensagem são estes:

  • Quoted-printable   Esse 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 em sua maior parte texto US-ASCII, a codificação quoted-printable dará resultados, de certa forma, legíveis e compactos. Todos os caracteres de texto US-ASCII imprimíveis, exceto o sinal de igual ( = ), podem ser representados sem codificação.

  • Base64   Esse algoritmo de codificação se baseia principalmente no padrão PEM (Privacy-Enhanced Mail) que é definido na RFC 1421. A codificação Base64 usa o algoritmo de codificação de alfabeto de 64 caracteres e caracteres de preenchimento de saída definidos pelo PEM para codificar os dados do corpo da mensagem. Uma mensagem codificada em Base64 normalmente é 33% maior que a mensagem original. A codificação Base64 gera um aumento previsível no tamanho da mensagem e é ideal para dados binários e texto não-US-ASCII.

Em geral, você não verá muitos algoritmos de codificação usados na mesma mensagem.

Quando nenhum algoritmo de codificação tiver sido usado no corpo da mensagem, o campo cabeçalho Content-Transfer-Encoding identifica meramente o estado atual dos dados do corpo da mensagem. Os valores a seguir do campo cabeçalho Content-Transfer-Encoding 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 da 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 caracteres 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 ser de 7 bits, ou parte do corpo da mensagem em uma mensagem com diversas partes pode ser de 7 bits. Se a mensagem com diversas partes contiver outras partes que tenham algum dado binário ou texto não-US-ASCII, essa parte da mensagem deverá ser codificada usando os algoritmos de codificação Quoted-printable ou Base64.

    As mensagens que tiverem corpos de 7 bits poderão percorrer 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 ser de 8 bits, ou parte do corpo da mensagem em uma mensagem com diversas partes pode ser de 8 bits. Se a mensagem com diversas partes contiver outras partes que tenham dados binários, essa parte da mensagem deverá ser codificada usando os algoritmos de codificação Quoted-printable ou Base64.

    Mensagens que tiverem corpos de 8 bits só poderão percorrer servidores de mensagens SMTP que aceitarem a extensão SMTP 8BITMIME, conforme definido na RFC 1652, como os servidores executando o Exchange 2010, Exchange Server 2007, Exchange Server 2003, ou Exchange 2000 Server. Especificamente, isso significa que as seguintes condições devem ser verdadeiras:

    • A palavra-chave 8BITMIME deve ser informada na resposta EHLO do servidor.

    • As mensagens ainda serão transferidas usando o comando DATA padrão SMTP. Entretanto, o parâmetro BODY=8BITMIME deverá ser adicionado ao final do comando MAIL FROM.

  • Binary   Esse valor indica que o corpo da mensagem contém texto não-US-ASCII ou dados binários. Especificamente, isso significa que as seguintes condições são verdadeiras:

    • Qualquer seqüê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 tiverem corpos binários só poderão percorrer servidores de mensagens SMTP que aceitarem a extensão SMTP BINARYMIME, conforme definido na RFC 3030, como os servidores executando o Exchange 2010, Exchange 2007, Exchange 2003, ou Exchange 2000. Especificamente, isso significa que as seguintes condições devem ser verdadeiras:

    • A palavra-chave BINARYMIME deve ser informada na resposta EHLO do servidor.

    • A extensão SMTP BINARYMIME só pode ser usada com a extensão SMTP CHUNKING. A Fragmentação permite que corpos de mensagem grandes sejam enviados em vários blocos menores. A fragmentação também é definida na RFC 3030. A palavra-chave CHUNKING também deve ser informada 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 deverá ser adicionado ao final do comando MAIL FROM quando a mensagem tiver um corpo.

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

Content-Disposition

Anexo

Esse campo de cabeçalho instrui um cliente de email habilitado para MIME sobre como exibir um arquivo anexado, e é descrito na RFC 2183. Os valores desse campo podem ser Inline ou Attachment. Quando o valor desse campo é Inline, o anexo é exibido no corpo da mensagem. Quando o valor desse campo for Attachment, o arquivo anexado é exibido como anexo comum, separado do corpo da mensagem. Outros parâmetros estão disponíveis quando o valor é Attachment, como Filename, Creation-date e Size.

Formatos de mensagem do Exchange 2010 e do Outlook

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

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

    • Os cabeçalhos e o corpo da mensagem são compostos por texto US-ASCII. Anexos devem ser codificados usando Uuencode. Uuencode representa a codificação de Unix para 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 em MIME com um valor Content-Type de text/plain, e um valor Content-Transfer-Encoding de 7 bits para as partes do texto de uma mensagem com diversas partes. Todos os anexos da mensagem são codificados usando a codificação Quoted-printable ou Base64. Por padrão, quando você redige e envia uma mensagem de texto simples no Outlook, a mensagem é codificada em MIME com um valor Content-Type de text/plain.

  • HTML   Uma mensagem HTML aceita formatação de texto, imagens de fundo, tabelas, pontos de marcação e outros elementos gráficos. Por definição, uma mensagem formatada em HTML deve ser codificada em MIME para preservar esses elementos de formatação.

  • Rich text format (RTF)    RTF aceita formatação de texto e outros elementos gráficos. RTF é sinônimo de TNEF (Transport Neutral Encapsulation Format). TNEF e RTF podem ser usados alternadamente.

    Somente o Outlook e alguns clientes MAPI de e-mail entendem as mensagens RTF. MAPI é uma arquitetura de sistema de mensagens desenvolvida por Microsoft que permite que diversos aplicativos interajam com diferentes sistemas de mensagens entre diversas plataformas de hardware. O MAPI está integrado na arquitetura COM (Modelo de Objeto Componente). O Outlook usa o MAPI na comunicação com caixas de correio em um computador que esteja executando o Exchange 2010 com a função de servidor Caixa de Correio instalada.

    O formato de mensagem rich text é completamente diferente do formato de documento rich text que está disponível no Microsoft Word.

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

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

    • Objetos OLE, incluindo, por exemplo, figuras incorporadas ou documentos do Microsoft Office incorporados

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

    • Anexos de mensagem comuns que estavam na mensagem original

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

    • Uma mensagem compatível com a RFC 2822, composta apenas de texto US-ASCII com um anexo Winmail.dat, codificada em Uuencode

    • Uma mensagem com diversas partes codificada em MIME que tenha um anexo Winmail.dat

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

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

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

    • Servidores de mensagens que entendem TNEF podem ser configurados para remover anexos TNEF das 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 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 anexos Winmail.dat.

    O TNEF é compreendido pelo Exchange 2010, Exchange 2007, Exchange 2003, Exchange 2000 e Exchange Server versão 5.5. As mensagens TNEF são transferidas entre servidores de mensagens SMTP usando o verbo de comando DATA padrão. O TNEF é usado automaticamente pelo Exchange com base nas seguintes situações:

    • Exchange 2003   Se a organização do Exchange estiver em modo misto, o TNEF será usado nas mensagens transferidas entre servidores Exchange que estiverem em grupos de roteamento diferentes.

    • Exchange 2000   O TNEF é usado nas mensagens transferidas entre servidores Exchange que estão em grupos de roteamento diferentes.

  • STNEF (Summary Transport Neutral Encapsulation Format)   STNEF é equivalente a TNEF. Entretanto, mensagens STNEF são codificadas de modo diferente das mensagens TNEF. Especificamente, as mensagens STNEF são sempre codificadas em MIME e sempre têm um valor Binary para Content-Transfer-Encoding. Conseqüentemente, não há representação de texto simples da mensagem e nem anexo Winmail.dat distinto contido no corpo da mensagem. A mensagem inteira é representada usando apenas dados binários. As mensagens que tiverem um valor Content-Transfer-Encoding definido como Binary só poderão ser transferidas entre servidores de mensagens SMTP que aceitarem e informarem as extensões SMTP BINARYMIME e CHUNKING, conforme definido na RFC 3030. As mensagens são sempre transferidas entre servidores de mensagens SMTP usando o comando BDAT, em vez do comando DATA padrão.

    O STNEF é compreendido pelo Exchange 2010, Exchange 2007, Exchange 2003 e Exchange 2000. O STNEF será usado automaticamente pelo Exchange se as seguintes condições forem verdadeiras:

    • Exchange 2010   O STNEF é usado em todas as mensagens transferidas entre servidores Exchange na organização.

    • Exchange 2007   O STNEF é usado em todas as mensagens transferidas entre servidores Exchange na organização.

    • Exchange 2003   Se a organização do Exchange estiver em modo nativo, o STNEF será usado em todas as mensagens transferidas entre os servidores Exchange na organização.

    • Exchange 2000 Server   O STNEF é usado nas mensagens transferidas entre servidores Exchange que estão nos mesmos grupos de roteamento. Um hotfix não aceito também habilita o Exchange 2000 a usar o STNEF nas mensagens transferidas entre servidores Exchange em grupos de roteamento diferentes.

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

Elementos da conversão de conteúdo

Conversão de conteúdo é a ação de formatar corretamente uma mensagem para cada destinatário externo. Essa conversão é executada pelo categorizador em um servidor de Transporte de Hub.

As opções de conversão de conteúdo que você pode definir em uma organização do Exchange 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 mensagem   Essas opções especificam as opções de codificação de mensagem, como conjuntos de caracteres MIME e não-MIME, codificação de mensagem e formatos de anexo.

Essas opções de conversão e codificação não dependem uma da outra. Por exemplo, o fato de as mensagens TNEF poderem ou não sair da organização do Exchange nada tem a ver com as definições de codificação MIME ou de texto simples dessas mensagens.

Você pode especificar a conversão de conteúdo em diversos níveis da organização do Exchange, conforme descrição 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 do Exchange 2010 e os domínios fora da floresta do Active Directory. Mesmo que você não crie entradas de domínio remoto para domínios específicos, há um domínio remoto predefinido denominado Padrão que se aplica a todos os espaços de endereçamento remotos ( * ).

  • Configurações de usuário e contato de email   Usuários de email são semelhantes a contatos de email - 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 entre eles é que os usuários de email possuem contextos de segurança que podem ser usados para fazer logon no domínio do Active Directory e acessar os recursos para os quais obtiveram permissão.

  • Configurações do Outlook   O Outlook permite que você defina as opções de formatação e codificação da mensagem, conforme descrito na lista a seguir:

    • Formato da mensagem   Você pode definir o formato de mensagem padrão para todas as mensagens. É possível substituir o formato padrão da mensagem à medida que você compõe uma mensagem específica.

    • Formato de mensagem da Internet   Você pode controlar se as mensagens TNEF são enviadas a destinatários remotos ou se, primeiramente, são convertidas para um formato mais compatível. Também é possível especificar várias opções de codificação para mensagens enviadas a destinatários remotos. Essas configurações não se aplicam a mensagens enviadas a destinatários na organização Exchange.

    • Formato de mensagem de destinatário da Internet   Você pode controlar se as mensagens TNEF são enviadas a destinatários específicos ou se, primeiramente, são convertidas para um formato mais compatível. Você pode definir as opções de conversão de contatos específicos em sua pasta Contatos, e pode substituir as opções de conversão de um destinatário específico nos campos Para:, Cc:, ou Cco:. 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 mensagem de destinatário da Internet   Você pode controlar as opções de codificação MIME ou texto simples para contatos específicos em sua pasta Contatos, e pode ainda substituir as opções de conversão para um destinatário específico nos campos Para:, Cc:, ou Cco:. 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 que são 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

  • Outlook configurações, incluindo:

    • Formato de mensagem

    • Formato de mensagem da Internet

    • Formato de mensagem de destinatário da Internet

Para obter informações detalhadas, consulte Opções de conversão de TNEF.

Opções de codificação de mensagem

Você pode especificar as opções de mensagem nos seguintes níveis:

  • Configurações de domínio remoto

  • Configurações de contato de email e usuário de email

  • Outlook configurações, incluindo:

    • Formato de mensagem

    • Mensagem da 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 mensagem.

Conversão de conteúdo executada pelo driver de repositório

O driver de armazenamento também executa a conversão de conteúdo. Ele existe nos servidores de Transporte de Hub para transportar mensagens entre as caixas de correio nos servidores de Caixa de Correio e na fila de envio. Especificamente, o driver de repositório transporta as mensagens da Caixa de Saída do remetente para a fila de envio no servidor de Transporte de Hub, bem como transporta as mensagens da fila de envio no servidor de Transporte de Hub para a Caixa de Entrada do destinatário. O driver de repositório converte todas as mensagens de saída de MAPI e todas as mensagens de entrada para MAPI. O controle da conversão de conteúdo captura essas falhas de conversão do driver de repositório.

Para obter mais informações, consulte Rastreamento de conversão de conteúdo.

 © 2010 Microsoft Corporation. Todos os direitos reservados.