Conversión de contenido en Exchange Server

  • Artículo

Conversión de contenido es el proceso de formatear correctamente un mensaje para cada destinatario. La decisión de realizar la conversión de contenido en un mensaje depende del destino y el formato del mensaje. Los tipos de conversión de contenido que se producen en Exchange 2016 y Exchange 2019 no cambian con respecto a Exchange 2013:

  • Conversión de mensajes para destinatarios externos: este tipo de conversión de contenido incluye las opciones de conversión formato de encapsulación neutro de transporte (TNEF) y las opciones de codificación de mensajes para destinatarios externos. No es necesario convertir el tipo de contenido de los mensajes enviados a destinatarios dentro de la organización de Exchange. Este tipo de conversión de contenido lo controla el categorizador del servicio de transporte en un servidor de buzones de correo. La categorización se produce en los mensajes cuando se coloca un mensaje recién llegado en la cola de envío. Además de la resolución de destinatario y de enrutamiento, la conversión de contenido se realiza en el mensaje antes de que se ponga en la cola de envío. Si un único mensaje contiene varios destinatarios, el categorizador determina la codificación adecuada para cada destinatario del mensaje. El seguimiento de conversión de contenido no detecta los errores en la conversión de contenido con los que se encuentra el categorizador cuando convierte los mensajes que se envían a los destinatarios externos.

  • Conversión MAPI para destinatarios internos: este tipo de conversión de contenido se controla mediante el servicio de transporte de buzones. El servicio de transporte de buzones existe en los servidores Buzón de correo para transmitir los mensajes entre las bases de datos de buzones de correo en el servidor local y el servicio de transporte en los servidores Buzón de correo. Específicamente, el servicio de envío de transporte de buzones transmite mensajes desde la bandeja de salida del remitente hasta el servicio de transporte en un servidor Buzón de correo. El servicio de entrega de transporte de buzones transmite mensajes desde el servicio de transporte en un servidor Buzón de correo hasta la bandeja de entrada del destinatario. El servicio de envío de transporte de buzones convierte todos los mensajes salientes de MAPI y el servicio de entrega de transporte de buzones convierte todos los mensajes entrantes a MAPI. El seguimiento de la conversión de contenido detecta estos errores de conversión de MAPI. Para obtener más información, vea Managing Content Conversion Tracing.

Formatos de mensajes de Exchange y Outlook

En la lista siguiente se describen los formatos de mensaje básicos disponibles en Exchange y Outlook:

  • Texto sin formato: un mensaje de texto sin formato solo usa texto US-ASCII como se describe en RFC 5322. El mensaje no puede contener diferentes fuentes o formato de texto. Los dos siguientes formatos se pueden usar para un mensaje de texto sin formato:

    • Los encabezados de mensaje y el cuerpo del mensaje están compuestos por texto US-ASCII. Los adjuntos tendrían que codificarse mediante Uuencode. Uuencode representa una codificación de Unix a Unix y define un algoritmo de codificación para almacenar documentos adjuntos binarios en el cuerpo de un mensaje de correo electrónico mediante el uso de caracteres de texto US-ASCII.

    • El mensaje está codificado en MIME con un valor Content-Type de text/plainy un valor Content-Transfer-Encoding de 7bit para las partes de texto de un mensaje de varias partes. Cualquier dato adjunto del mensaje se codifica con el método de entrecomillado imprimible o Base64. De forma predeterminada, al redactar y enviar un mensaje de texto sin formato en Outlook, el mensaje está codificado con MIME con un valor content-type de text/plain.

  • HTML: un mensaje HTML admite formato de texto, imágenes de fondo, tablas, viñetas y otros elementos gráficos. Por definición, un mensaje con formato HTML tiene que estar codificado en MIME para conservar estos elementos de formato.

  • Formato de texto enriquecido (RTF): RTF admite el formato de texto y otros elementos gráficos. RTF es sinónimo de TNEF (TNEF y RTF se pueden usar indistintamente). El formato de mensaje de texto enriquecido es completamente diferente del formato de documento de texto enriquecido que está disponible en Word.

  • TNEF: el formato de encapsulación neutral de transporte es un formato específico de Microsoft para encapsular las propiedades del mensaje MAPI. Un mensaje TNEF contiene una versión de texto sin formato del mensaje y datos adjuntos que empaqueta la versión con formato original del mensaje. Normalmente, estos datos adjuntos se denominan Winmail.dat. Los datos adjuntos winmail.dat incluyen la siguiente información:

    • Versión original con formato del mensaje (por ejemplo, fuentes, tamaños de texto y colores de texto)
    • Objetos OLE (por ejemplo, imágenes incrustadas o documentos de Office incrustados)
    • Características especiales de Outlook (por ejemplo, formularios personalizados, botones de votación o convocatorias de reunión)
    • Datos adjuntos normales de mensaje que estaban en el mensaje original

    El mensaje de texto sin formato resultante se puede representar en los siguientes formatos:

    • Mensaje compatible con RFC 5322 compuesto solo por texto US-ASCII con datos adjuntos Winmail.dat codificados en Uuencode
    • Un mensaje de varias partes codificado en MIME que tenga un archivo Winmail.dat como datos adjuntos

    Outlook y otros clientes de correo electrónico que entienden completamente TNEF procesan los datos adjuntos winmail.dat y muestran el contenido del mensaje original sin mostrar nunca los datos adjuntos winmail.dat. Email clientes que no entienden TNEF pueden presentar mensajes TNEF de cualquiera de las siguientes maneras:

    • Se muestra la versión de texto sin formato del mensaje y el mensaje contiene datos adjuntos denominados Winmail.dat, Win.dat o algún otro nombre genérico como Att nnnnn.dat o Att nnnnn.eml, donde el marcador de posición nnnnn representa un número aleatorio.
    • La versión de texto sin formato del mensaje se visualiza. Los datos adjuntos en TNEF se ignoran o se quitan. El resultado es un mensaje de texto sin formato.
    • Los servidores de mensajería que entienden el formato TNEF se pueden configurar para quitar los datos adjuntos TNEF de los mensajes entrantes. El resultado es un mensaje de texto sin formato. Además, es posible que algunos clientes de correo electrónico no entiendan el TNEF, pero reconozcan e ignoren los datos adjuntos de TNEF. El resultado es un mensaje de texto sin formato.

    Hay utilidades de terceros que pueden ayudar a convertir los datos adjuntos Winmail.dat.

    TNEF es entendido por todas las versiones de Exchange desde Exchange Server, versión 5.5.

  • Formato de encapsulación neutral de transporte de resumen (STNEF): STNEF es equivalente a TNEF. Sin embargo, los mensajes STNEF están codificados de manera diferente a los mensajes TNEF. En concreto, los mensajes STNEF siempre están codificados con MIME y siempre tienen el valor BinaryContent-Transfer-Encoding . Por consiguiente, el mensaje no se representa en texto sin formato y no aparecen datos adjuntos Winmail.dat en el cuerpo del mensaje. El mensaje entero se representa sólo mediante datos binarios. Los mensajes que tienen un valor Content-Transfer-Encoding de Binary solo se pueden transferir entre servidores de mensajería que admiten y anuncian las extensiones BINARYMIME y CHUNKING SMTP tal como se define en RFC 3030. Los mensajes siempre se transfieren entre servidores de mensajería mediante el comando BDAT , en lugar del comando DATA estándar.

    STNEF es entendido por todas las versiones de Exchange desde Exchange 2000. STNEF se usa automáticamente para todos los mensajes que se transfieren entre los servidores Exchange en la organización desde el modo nativo Exchange Server 2003.

    Exchange nunca manda mensajes con formato STNEF a destinatarios externos. Solamente se pueden enviar mensajes TNEF a destinatarios fuera de la organización de Exchange.

Opciones de conversión de contenido para destinatarios externos

Las opciones de conversión de contenido que puede establecer en una organización Exchange para destinatarios externos se pueden describir en las siguientes categorías:

  • Opciones de conversión TNEF: estas opciones de conversión especifican si TNEF debe conservarse o quitarse de los mensajes que salen de la organización de Exchange.
  • Opciones de codificación de mensajes: estas opciones especifican opciones de codificación de mensajes, como conjuntos de caracteres MIME y no MIME, codificación de mensajes y formatos de datos adjuntos.

Estas opciones de conversión y codificación son independientes las unas de las otras. Por ejemplo, el hecho de que los mensajes TNEF puedan salir de la organización de Exchange no tiene nada que ver con las opciones de configuración de la codificación MIME o la configuración de codificación de texto sin formato de esos mensajes.

Puede especificar la conversión del contenido a diferentes niveles de la organización de Exchange tal y como se describe en la siguiente lista:

  • Configuración de dominio remoto: los dominios remotos definen la configuración de las transferencias de mensajes salientes entre la organización de Exchange y los dominios externos. Incluso si no crea entradas de dominio remoto para dominios específicos, hay un dominio remoto predeterminado llamado Predeterminado que se aplica a todos los espacios de direcciones remotos (*). Para obtener más información sobre los dominios remotos, consulte Dominios remotos.

  • Configuración de contactos de correo y usuario de correo: los usuarios de correo y los contactos de correo son similares porque ambos tienen direcciones de correo electrónico externas y contienen información sobre personas ajenas a la organización de Exchange. La principal diferencia es que los usuarios de correo tienen cuentas que pueden usar para iniciar sesión en Active Directory y acceder a los recursos de la organización. Para más información, consulte Destinatarios.

  • Configuración de Outlook: puede establecer estas opciones de codificación y formato de mensaje en Outlook:

    • Formato de mensaje: puede establecer el formato de mensaje predeterminado para todos los mensajes. Puede invalidar el formato de mensaje predeterminado al tiempo que escribe un mensaje específico.
    • Formato de mensaje de Internet: puede controlar si los mensajes TNEF se envían a destinatarios remotos o si se convierten primero a un formato más compatible. También puede especificar diferentes opciones de codificación para mensajes que se envían a destinatarios remotos. Esta configuración no se aplica a los mensajes enviados a destinatarios de la organización de Exchange.
    • Formato de mensaje de destinatario de Internet (Outlook 2010 o anterior): puede controlar si los mensajes TNEF se envían a contactos específicos en la carpeta Contactos. Estas opciones de conversión no están disponibles para destinatarios de la organización de Exchange.
    • Opciones de codificación de mensajes de destinatario de Internet (Outlook 2010 o anterior): puede controlar las opciones de codificación mime o texto sin formato para contactos específicos en la carpeta Contactos. Estas opciones de conversión no están disponibles para destinatarios de la organización de Exchange.
    • Opciones internacionales: puede controlar los conjuntos de caracteres usados en los mensajes.

    Para obtener más información sobre esta configuración, vea Opciones de conversión de TNEF y Opciones de codificación de mensajes en Exchange Server.

Información sobre la estructura de los mensajes de correo electrónico

Para comprender mejor las opciones de conversión de contenido para los destinatarios externos, necesita comprender la estructura de los mensajes de correo electrónico. Un mensaje SMTP se basa en un texto US-ASCII de 7 bits sin formato para componer y enviar mensajes de correo electrónico. Un mensaje SMTP estándar consiste en los siguientes elementos:

  • Sobre de mensaje: el sobre del mensaje se define en RFC 5321. El sobre del mensaje contiene la información necesaria para transmitir y entregar el mensaje. Los destinatarios nunca ven el sobre del mensaje, porque se genera mediante el proceso de transmisión de mensajes y en realidad no forma parte del contenido del mensaje.

  • Contenido del mensaje: el contenido del mensaje se define en RFC 5322. El contenido del mensaje consta de los siguientes elementos:

    • Encabezado de mensaje: el encabezado del mensaje es una colección de campos de encabezado. Los campos de encabezado consisten en el nombre del campo, seguido de dos puntos (:), después el cuerpo del campo y por último una combinación de caracteres de retorno de carro y avance de línea (CR/LF).

      Un nombre de campo tiene que estar compuesto por caracteres de texto US-ASCII imprimibles, a excepción del carácter de los dos puntos (:). En concreto, se permiten los caracteres ASCII que tengan valores comprendidos entre 33 y 57 y entre 59 y 126.

      Un cuerpo de campo puede estar compuesto por cualquier carácter US-ASCII, excepto los caracteres de retorno de carro (CR) y de avance de línea (LF). Sin embargo, un cuerpo de campo puede contener una combinación de caracteres CR/LF cuando se usa en un doblado de encabezado. El plegado de encabezados es la separación de un cuerpo de campo de encabezado único en varias líneas, como se describe en la sección 2.2.3 de RFC 5322. Otros requisitos de sintaxis del cuerpo del campo se describen en las secciones 3 y 4 de RFC 5322.

    • Cuerpo del mensaje: el cuerpo del mensaje es una colección de líneas de caracteres de texto US-ASCII que aparece después del encabezado del mensaje. El encabezado del mensaje y el cuerpo del mensaje están separados por una línea en blanco que termina con la combinación de caracteres CR/LF. El cuerpo de mensaje es opcional. Cualquier línea de texto en el cuerpo del mensaje tiene que tener menos de 998 caracteres. Los caracteres de retorno de carro y de avance de línea solamente aparecen juntos para indicar el final de una línea.

Cuando los mensajes SMTP contienen elementos que no son texto sin formato US-ASCII, el mensaje tiene que ir codificado para preservar esos elementos. El estándar MIME define un método de codificación de contenido de mensajes que no es de texto. MIME permite texto con otros conjuntos de caracteres, datos adjuntos sin texto, cuerpos de mensajes de varias partes y campos de encabezado en otros conjuntos de caracteres. MIME se define en RFC 2045, RFC 2046, RFC 2047, RFC 4288, RFC 4289 y RFC 2049. MIME define una colección de campos de encabezado que especifica atributos de mensaje adicionales. En las secciones siguientes se describen algunos campos de encabezado MIME importantes.

MIME-Version campo de encabezado

Valor predeterminado: 1.0

Este campo de encabezado es el primer campo de encabezado MIME que aparece en un mensaje con formato MIME. Este campo de encabezado aparece después de los otros campos de encabezado ESTÁNDAR RFC 5322, pero antes de cualquier otro campo de encabezado MIME. Los clientes de correo electrónico para MIME usan este campo de encabezado para identificar un mensaje codificado con MIME. Cuando no existe este campo de encabezado, los clientes de correo electrónico para MIME identifican el mensaje como texto sin formato.

Campo de encabezado Content-Type

Valor predeterminado: text/plain

Este campo de encabezado identifica el tipo de medio del contenido del mensaje tal y como se describe en RFC 2046. Un tipo de medio consta de:

  • Un tipo:

    • Los tipos que comienzan por x- no son estándar. Internet Assigned Numbers Authority (IANA) tiene una lista de los tipos de medio registrados. Para obtener más información, consulte Tipos de medios MIME.

    • El tipo de medio multiparte permite varias partes de mensaje dentro del mismo mensaje mediante secciones definidas por diferentes tipos de medio. Algunos valores de campo Content-Type incluyen text/plain, text/html, multipart/mixedy multipart/alternative.

  • Subtipo: los subtipos que comienzan por vnd. son específicos del proveedor.

  • Uno o varios parámetros opcionales: por ejemplo, un charset= parámetro que define la codificación de caracteres MIME.

Campo de encabezado Content-Transfer-Encoding

Valor predeterminado: 7bit

Este campo de encabezado puede describir la siguiente información de un mensaje:

  • El algoritmo de codificación que se usó para transformar cualquier texto no EE. UU.-ASCII o datos binarios que se hallan en el cuerpo del mensaje.
  • Un indicador que describe la condición actual del cuerpo del mensaje.

Puede haber varios valores del campo de encabezado Content-Transfer-Encoding en un mensaje MIME. Cuando el campo encabezado Content-Transfer-Encoding aparece en el encabezado del mensaje, se aplica a todo el cuerpo del mensaje. Cuando el campo encabezado Content-Transfer-Encoding aparece en una de las partes de un mensaje de varias partes, solo se aplica a esa parte del mensaje.

Cuando se aplica un algoritmo de codificación a los datos del cuerpo de un mensaje, estos se transforman en texto US-ASCII sin formato. Esta transformación permite que el mensaje viaje a través de servidores de mensajería antiguos que solo admiten mensajes en texto US-ASCII. Los valores del campo de encabezado Content-Transfer-Encoding que indican que se usó un algoritmo de codificación en el cuerpo del mensaje son:

  • Quoted-printable: usa caracteres US-ASCII imprimibles para codificar los datos del cuerpo del mensaje. Si el texto del mensaje original es principalmente texto ASCII de EE. UU., la codificación imprimible entre comillas proporciona resultados algo legibles y compactos. Todos los caracteres de texto US-ASCII imprimibles excepto el carácter de signo igual (=) se pueden representar sin codificación.

  • Base64: se basa principalmente en el estándar de correo mejorado de privacidad (PEM) definido en RFC 4648. La codificación Base64 usa el algoritmo de codificación del alfabeto de 64 caracteres, así como caracteres de relleno de salida que están definidos en PEM para codificar los datos del cuerpo del mensaje. Un mensaje codificado con Base64 suele ser un 33% mayor que el mensaje original. La codificación con Base64 crea un incremento predecible en el tamaño del mensaje y es óptimo para los datos binarios y texto que no sea US-ASCII.

Por lo general, no se ven los diferentes algoritmos de codificación usados en el mismo mensaje.

Cuando no se ha usado ningún algoritmo de codificación en el cuerpo del mensaje, el campo de encabezado Content-Transfer-Encoding simplemente identifica la condición actual de los datos del cuerpo del mensaje. Los valores del campo de encabezado Content-Transfer-Encoding que indican que no se usaron algoritmos de codificación en el cuerpo del mensaje son:

  • 7bit: indica que los datos del cuerpo del mensaje ya están en formato RFC 5322. En concreto, significa que las siguientes condiciones deben ser verdaderas:

    • Todas las líneas de texto han de contener menos de 998 caracteres.

    • Todos los caracteres deben estar en formato EE. UU.-ASCII y tener valores de carácter entre 1 y 127.

    • Los caracteres de retorno de carro y de avance de línea solamente pueden usarse juntos para indicar el final de una línea.

      Todo el cuerpo del mensaje puede ser de 7 bits o parte del cuerpo del mensaje en un mensaje de varias partes puede ser de 7 bits. Si el mensaje multiparte contiene otras partes que tienen datos binarios o texto no US-ASCII, esa parte del mensaje tiene que ser codificada con los algoritmos de codificación de entrecomillado imprimible o Base64.

      Los mensajes que tienen cuerpos de 7 bits pueden viajar entre servidores de mensajería mediante el comando DATA estándar.

  • 8bit: indica que los datos del cuerpo del mensaje contienen caracteres ascii que no son de EE. UU. En concreto, significa que las siguientes condiciones deben ser verdaderas:

    • Todas las líneas de texto deben contener menos de 998 caracteres.

    • Uno o más de los caracteres en el cuerpo de mensaje tiene valores superiores a 127.

    • Los caracteres de retorno de carro y de avance de línea solamente pueden usarse juntos para indicar el final de una línea.

      Todo el cuerpo del mensaje puede ser de 8 bits o parte del cuerpo del mensaje en un mensaje de varias partes puede ser de 8 bits. Si el mensaje multiparte contiene otras partes que tienen datos binarios, esa parte del mensaje tiene que ser codificada con los algoritmos de codificación de entrecomillado imprimible o Base64.

      Los mensajes que tienen cuerpos de 8 bits solo pueden viajar entre servidores de mensajería que admiten la extensión SMTP de 8BITMIME tal como se define en RFC 6152, como Exchange 2000 Server o posterior. En concreto, significa que las siguientes condiciones deben ser verdaderas:

    • La palabra clave 8BITMIME debe anunciarse en la respuesta EHLO del servidor.

    • Los mensajes se siguen transfiriendo mediante el comando SMTP estándar DATA . Sin embargo, el BODY=8BITMIME parámetro debe agregarse al final del comando MAIL FROM .

  • Binary: indica que el cuerpo del mensaje contiene texto no US-ASCII o datos binarios. En concreto, significa que las siguientes condiciones son verdaderas:

    • Se permite cualquier secuencia de caracteres.

    • No hay límite de longitud de línea.

    • Los elementos de mensaje binarios no necesitan codificación.

      Los mensajes que tienen cuerpos binarios solo pueden viajar entre servidores de mensajería que admiten la extensión BINARYMIME SMTP tal como se define en RFC 3030, como Exchange 2000 Server o posterior. En concreto, significa que las siguientes condiciones deben ser verdaderas:

    • La palabra clave BINARYMIME debe anunciarse en la respuesta EHLO del servidor.

    • La extensión SMTP BINARYMIME solo se puede usar con la extensión SMTP CHUNKING . Fragmentación permite que se manden los cuerpos de mensaje grandes en varios y pequeños fragmentos. La fragmentación también se define en RFC 3030. La palabra clave CHUNKING también debe anunciarse en la respuesta EHLO del servidor.

    • Los mensajes se transfieren mediante el comando BDAT en lugar del comando DATA estándar.

    • El BODY=BINARYMIME parámetro debe agregarse al final del comando MAIL FROM cuando el mensaje tiene un cuerpo de mensaje.

Los valores 7bit, 8bity Binary nunca existen juntos en el mismo mensaje de varias partes (los valores son mutuamente excluyentes). Los Quoted-printable valores o Base64 pueden aparecer en un cuerpo de mensaje multiparte de 7 o 8 bits, pero nunca en un cuerpo de mensaje binario. Si un cuerpo de mensaje de varias partes contiene diferentes partes compuestas por contenido de 7 y 8 bits, todo el mensaje se clasifica como de 8 bits. Si un cuerpo de mensaje de varias partes contiene diferentes partes compuestas por contenido binario de 7 bits, 8 bits y , todo el mensaje se clasifica como binario.

Campo de encabezado Content-Disposition

Valor predeterminado: Attachment

Este campo de encabezado indica al cliente de correo electrónico con MIME cómo debería visualizar unos documentos adjuntos, tal y como se describe en RFC 2183. Los valores admitidos son:

  • Inline: los datos adjuntos se muestran en el cuerpo del mensaje.

  • Attachment: el archivo adjunto aparece como un archivo adjunto normal independiente del cuerpo del mensaje. Otros parámetros también están con estos valores (por ejemplo, , FilenameCreation-datey Size).