Preguntas más frecuentes acerca de MIME y la conversión de contenido en Exchange 2000 Server y en Exchange Server 2003

Resumen

Este artículo incluye respuestas a preguntas frecuentes sobre el estándar MIME y los métodos de codificación que hacen posible que los sistemas de correo diferentes a trabajar juntos. En este artículo se explica brevemente cómo solucionar los mensajes de correo distorsionado o ilegible en un entorno de Microsoft Exchange.

Más información

Trimestre 1: ¿Qué es el formato de un mensaje de correo electrónico?

A1: Mensajes de correo electrónico de Internet siguen los estándares de formato que se definen en RFC 2822. Un mensaje se compone de campos de encabezado y un cuerpo. Los campos de encabezado se denominan colectivamente el "encabezado" del mensaje. El cuerpo del mensaje es opcional. Puede enviarse un mensaje sin un cuerpo, pero no sin un encabezado.

El encabezado contiene una secuencia de líneas de caracteres que tienen una sintaxis especial, tal como se define en el estándar de formato RFC 2822. El cuerpo contiene una secuencia de caracteres que siguen a la cabecera y que están separados de la cabecera por una línea vacía (es decir, una línea que no tiene nada antes del retorno de carro) y avance de línea [CRLF].

Campos de encabezado son líneas que se componen de un nombre de campo seguido de dos puntos (:), seguido de un cuerpo de campo y finalizado por un carácter CRLF. Un nombre de campo debe estar compuesto de caracteres US-ASCII imprimibles (es decir, caracteres que tienen valores entre 33 y 126, ambos inclusive), excepto los dos puntos. Los dos puntos se utilizan como un carácter de separación.

Un cuerpo de campo puede estar compuesto de caracteres US-ASCII, excepto el carácter CRLF. Sin embargo, un cuerpo de campo puede contener un carácter CRLF cuando se utiliza en el encabezado de plegado y desplegado. Plegado es cuando, para su comodidad, aparece una sola línea en varias líneas. Despliegue es el inverso de este. Todos los cuerpos del campo deben seguir la sintaxis descrita en las secciones 3 y 4 del formato RFC 2822 estándar.

El cuerpo del mensaje puede incluir una o más secciones. Cada sección de cuerpo está separado por un límite. El parámetro de límite es una cadena de texto que comienza con dos guiones (--).

P2: ¿Qué es MIME?

A2: MIME es un estándar que puede utilizarse para incluir el contenido de varios tipos en un único mensaje. MIME amplía el formato de Protocolo Simple de transferencia de correo (SMTP) de mensajes de correo para incluir contenido múltiple, textual y no textual. Partes del mensaje pueden ser imágenes, audio, o establece el texto de caracteres diferentes. El estándar MIME se deriva de RFC como 2821 y 2822.

P3: ¿Cómo Exchange trata MIME?

A3: Hay tres componentes principales de Exchange que realizan la conversión de contenido:
  • El componente IMAIL es el componente principal que convierte los mensajes de Internet a MAPI / Exchange formato y viceversa. También comprueba la integridad del mensaje.
  • El componente EXMIME es responsable por la traducción de mensajes de Internet en las representaciones de objeto interno de Exchange y para generar los mensajes con formato MIME.
  • El componente RFHTML convierte los mensajes de formato de texto enriquecido (RTF) a HTML y viceversa, según la configuración en el cliente de Microsoft Outlook y la configuración en el equipo de Exchange Server.

P4: ¿Cuáles son los requisitos mínimos de un mensaje de correo electrónico en formato MIME?

A4: Un mensaje de correo electrónico en formato MIME tendrán normalmente un encabezado y un cuerpo. Como mínimo, un mensaje MIME debe tener un encabezado. El cuerpo es opcional. La sección de encabezado incluye un encabezado MIME versión 1.0 (uno por cada mensaje, tal como se define en RFC 2822).

Incluye la sección body:
  • Tipo de contenido (Esto es opcional. El valor predeterminado es texto sin formato, tal como se define en RFC 2822 5.2.)
  • Encabezado Content-Transfer-Encoding (Esto es opcional. El valor predeterminado es 7 bits, tal como se define en RFC 2822 6.1.)
  • Encabezado Content-Disposition (Esto es opcional).
  • Identificador del contenido (Esto es opcional).


P5: ¿Qué es un encabezado de versión MIME?

A5: El campo de encabezado de versión MIME denota un mensaje con formato MIME. Mensajes que se envían desde el software anterior que no son compatibles con MIME no tienen este campo. Los clientes de correo utilizan la ausencia de este campo para distinguir los mensajes no MIME.

P6: ¿Qué es un encabezado Content-type?

A6: El campo Content-Type se utiliza para especificar el tipo y subtipo de datos en un campo.

Algunos de los tipos de encabezado son multipart/mixed, multipart/alternative, texto sin formato, texto/html, aplicación/applefile, ms-tnef/aplicaciones y application/octet-stream.

Q7: ¿Qué es Content-Transfer-Encoding?

A7: Diferentes sistemas de correo controlan datos de forma diferente, y algunos sistemas de correo anteriores no pueden manejar los datos multimedia.

Para evitar los sistemas que no pueden procesar datos multimedia, un esquema de codificación se utiliza para convertir los datos en un formato uniforme de 7 bits. Cuando el destinatario recibe el mensaje, los datos se restauran a su formato original. Algunos ejemplos de formatos de Content-Transfer-Encoding son:
  • Entrecomillado imprimible
  • Base64
  • 8-bit
  • 7-bit
  • Binario


P8: Cómo Transfer-Encoding se implementa en Exchange 5.5?

A8: Exchange 5.5 se codifica en formato imprimible o en formato de 7 bits, según sea necesario. Además, Exchange 5.5 codifica los mensajes en formato base64 si el 25% del mensaje se compone de caracteres de 8 bits (es decir, los caracteres que están fuera del intervalo de US-ASCII). Esto se aplica sólo al cuerpo del mensaje; los datos adjuntos siempre están codificados en base64.

Q9: Cómo Transfer-Encoding se implementa en Exchange 2000 Server?

A9: Límites para grupos de enrutamiento y los destinos de destino SMTP determinan cómo Exchange 2000 Server codifica correo. Exchange 2000 se codificará como Entrecomillado imprimible o 7 bits o formato de encapsulación de neutro para el transporte (TNEF) cuando se envía entre dos servidores y destinatarios de diferentes grupos de enrutamiento y a Internet.

Cuando se envía a un destinatario o servidor en el mismo grupo de enrutamiento, Exchange 2000 Server se codificará en binario o TNEF de resumen.

P10: Cómo Transfer-Encoding se implementa en Microsoft Exchange Server 2003?

A10: Cuando los límites del grupo de enrutamiento, Exchange y SMTP destinos de destino también determinan cómo Exchange Server 2003 codifica correo.

En el modo mixto de Exchange Server 2003 codifica como Entrecomillado imprimible o 7 bits (formato TNEF) cuando se envía entre dos servidores y destinatarios de diferentes grupos de enrutamiento y a Internet.

En modo nativo, Exchange Server 2003 codifica en binario (TNEF de resumen) al enviar a un destinatario o servidor en el mismo o a otros grupos de enrutamiento.

Q11: ¿Qué es un encabezado Content-Disposition?

A11: Este encabezado se identifica si una sección aparecerán como datos adjuntos o aparecen en el cuerpo del mensaje.

P12: ¿Cómo Exchange trata los datos adjuntos?

A12: Exchange Server 2003 guarda los mensajes de Internet en su formato nativo. Esto significa que si se leen los mensajes de un cuenta Internet formato cliente como Outlook Express, se representará en su formato original.

Sin embargo, cuando se leen los mensajes desde un cliente MAPI, IMAIL asigna los elementos correspondientes en el formato de Internet a las propiedades MAPI. De hecho, antes de que un mensaje de Internet incluso se entrega en un buzón, un conjunto mínimo de propiedades MAPI debe promoverse desde el mensaje de Internet; Estos incluyen PR_SENT_REPRESENTING, PR_SUBJECT y tabla de destinatarios.

Otras propiedades MAPI como PR_BODY, PR_HTML y PR_ATTACH_DATA_BIN se calculan desde el formato de Internet a petición. Conversión se produce cuando un cliente MAPI solicita el mensaje por primera vez. Exchange 2000 Server, a continuación, promueve esas propiedades MIME nativas al formato MAPI.

Durante la conversión de contenido en Exchange Server 2003, cuando se procesa un mensaje entrante de MIME en un cliente, IMAIL hace lo siguiente:
  1. IMAIL busca un nombre de archivo completo (nombre. ext) en el encabezado MIME. Si se encuentra un nombre, se utiliza el nombre de archivo.
  2. IMAIL busca un nombre de archivo parcial. Si encuentra uno, IMAIL examina la subclave HKEY_CLASSES_ROOT / / base de datos/content-type MIMEpara asignar una extensión de nombre de archivo para el tipo de contenido. Si se encuentra un tipo de contenido coincidente, dicha extensión se agrega a los datos adjuntos. Si no se encuentra ningún tipo de contenido coincidente, se utiliza el nombre de archivo parcial.
  3. Si no se especifica ningún nombre de archivo en los encabezados Content-type o Content-Disposition, IMAIL busca un tipo de contenido coincidente. Si encuentra uno, el adjunto tendrá el formatonombreATT. ext, donde ext es la extensión que está asociada con este tipo de contenido Si no se encuentra ningún tipo de contenido coincidente, se utiliza una extensión de "ATT". Exchange 2000 Server requiere un nombre de archivo en el encabezado Content-type.


Respuesta a P13: ¿Cuál es la estructura del mensaje completo?

A13: El siguiente es un ejemplo de un mensaje completo, con todos los encabezados que se muestran. Los destinatarios verán generalmente sólo las partes del cuerpo. Se han agregado comentarios entre corchetes.

Received: from SMTP server (server1.example1.com IP address) 
by Receiver SMTP version 1.0 (server2.example2.com IP address);

Mon, 28 Oct 2002 08:42:42 -0500 (EST)

Message-ID: <006@example1.com>

From: "User1" <user1@example1.com> (RFC 2822 sender)

To: "User2" user2@example2.com> (RFC 2822 recipient)

Subject: A test message to see if you can see me now!

Date: Mon, 8 Nov 2002 13:46:54 +0100

MIME-Version: 1.0

Content-Type: multipart/mixed;
boundary="----=_NextPart_000_005A_01C27E88.79B98A90"

X-Priority: 3

Return-Path: user1@domain1.com

X-OriginalArrivalTime: 28 Oct 2002 13:45:00.0541 (UTC)
FILETIME=[35F0A2D0:01C27E88]



This is a multi-part message in MIME format (If you see this in the message
body, there is a problem. Notice there is no space or CRLF in the headers in the previous text. There must be no space until the message body itself)



This message is in MIME format. Since your mail reader does not understand this
format, some or all of this message may not be legible. (If you see this in the
message body, there is a problem)



------=_NextPart_000_005A_01C27E88.79B98A90 (Boundary)



Content-Type: text/plain;

charset="iso-8859-1"

Content-Transfer-Encoding: 7bit



Can you see me now??! (This is the text of the message. You see this in your mail client.)



------=_NextPart_000_005A_01C27E88.79B98A90 (Boundary. See Multipart/Mixed
definition earlier in this article.)

Content-Type: image/jpeg;

name="Haloweenpictures.jpg"

Content-Transfer-Encoding: base64 (All attachments in Exchange 2000 Server are encoded by using base64 and bloat 33%.)

Content-Disposition: attachment;

filename="Haloweenpictures.jpg"



/9j/4AAQSkZJRgABAQEBLAEsAAD/2wB/9j/4AAQSkZJRgABAQEBLAEsAAD/2wB (Base64 data in raw format. This is the picture being encoded in binary format; to
be repackaged later back as a picture.)

/9j/4AAQSkZJRgABAQEBLAEsAAD/2wB/9j/4AAQSkZJRgABAQEBLAEsAAD/2wB

/9j/4AAQSkZJRgABAQEBLAEsAAD/2wB/9j/4AAQSkZJRgABAQEBLAEsAAD/2wB

------=_NextPart_000_005A_01C27E88.79B98A90--



Q14: ¿Por qué direcciones de correo se muestran en el cuerpo del mensaje?

A14: El primer "CRLF CRLF" en la secuencia MIME denota el principio del cuerpo del mensaje. Por lo tanto, si hay una secuencia CRLF > < CRLF >< entre dos encabezados, el cliente (Microsoft Outlook o Microsoft Outlook Express) mostrará un mensaje ilegible.

El primer "CRLF CRLF" separa los encabezados de mensaje de Internet del cuerpo del mensaje. Estos encabezados se conocen como encabezados P1. Encabezados P1 son encabezados de sobres y no forman parte del mensaje de Internet que es procesado por IMAIL.

Exchange se puede reenviar a un host inteligente, dispositivo de digitalización contenido, pared antivirus o firewall. Software de firewall de otros fabricantes puede distorsionar a veces mensajes.

También puede recibir mensajes de correo electrónico a través de un sistema UNIX, a través de un firewall o a través de una pared de virus. Además, puede ser un dispositivo de exploración de contenidos de terceros en la red. Si tiene aplicaciones o dispositivos similares en la red, compruebe los límites de destinatarios. Evitar el uso de tales dispositivos o aplicaciones de pruebas de diagnóstico.

Q15: ¿Por qué signos de interrogación aparecen en mi mensaje?

A15: Si aparecen signos de interrogación en el mensaje, significa que el sistema no sabe cómo traducir algunos caracteres ANSI o Unicode en el mensaje. Debe asegurarse de que el cliente donde se ve el mensaje tiene instaladas páginas de códigos que coinciden con el conjunto de caracteres de entrada. Por ejemplo, asegúrese de que la estación de trabajo de Windows tiene la configuración regional para japonés instalada para ver los mensajes que se escriben en japonés.

P16: ¿Por qué tengo dificultades para abrir los mensajes HTML y aparece en el registro de aplicación sucesos 12002 y 12003?

A16: Estos eventos de registro de la aplicación están en el almacén de información de Exchange de origen y están de conversión de contenido. Algunos de estos mensajes pueden omitirse y no tienen ningún efecto en los mensajes recibidos. Pero si ve muchos de estos mensajes en los registros de aplicación, consulte si los clientes tienen problemas al abrir mensajes HTML.

Si éste es el caso, establecer más información de diagnóstico como las versiones de service pack, copias de los mensajes de problema, copias de los registros de aplicación y sistema y a continuación, solucionar problemas.

Q17: ¿Por qué a veces veo el cuerpo del mensaje como datos adjuntos?

A17: Debe establecer información sobre el origen del mensaje. Debe establecer todos los detalles del servidor de origen. Debe investigar si el remitente está en una red de UNIX. Para obtener más información acerca de este problema, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:

323482 muestra un mensaje que utiliza el encabezado Content-Disposition MIME de "en línea" como datos adjuntos de Exchange

Q18: ¿Por qué veo "Esto es un mensaje de varias partes en formato MIME." o "este mensaje está en formato MIME." en el cuerpo del correo electrónico?

A18: Puede ver uno de estos procedimientos en el cuerpo de texto:
  • "Esto es un mensaje de varias partes en formato MIME."
  • "Este mensaje está en formato MIME. Porque su lector de correo no entiende este formato, algunos o todos de este mensaje pueden no ser legibles."

Este texto se inserta delante del primer límite, está normalmente presente en cada mensaje en varias partes y no es visible para el cliente, a menos que haya un problema con el formato de correo electrónico. Por ejemplo, un salto de línea que se han insertado en el mensaje en la posición incorrecta.

Para solucionar este problema, activar mensaje archivado en el servicio Internet Mail de Microsoft Exchange. Para activar mensaje archivado, utilizar la utilidad Archive Sink de Exchange Server 2003, guardar el mensaje como .eml o .pst y, a continuación, realice un análisis más. Para obtener más información acerca de la característica del receptor de archivo, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:

307798 the Archive Sink utility está disponible en el Service Pack 2

Q19: ¿Por qué es el tamaño de mi correo aproximadamente un 33% mayor al esperado, y por qué es codificada en base64 incluso cuando no contiene los datos adjuntos?



A19: Este comportamiento se produce si utiliza los siguientes juegos de caracteres:
  • Japonés Shift-JIS

  • KOR

  • EUC Japonés

  • Coreano ISO-2202-KR
  • Taiwán ISO-2202-TW

  • Chino ISO-2202-CN

  • Chino HZ_GB, Big5, GB18030


Q20: ¿Cuáles son los otros problemas conocidos y comunes?

A20: Los mensajes se retransmiten desde un servidor de Exchange Server 2003 a otro pueden aparecer distorsionados y los destinatarios del mensaje pueden aparecer en el cuerpo del mensaje.

Por ejemplo, esto puede ocurrir en un mensaje que se enruta desde Internet a un equipo entrante de Internet de Exchange Server 2003 y, a continuación, a otro equipo de Exchange Server 2003.
El mensaje podría aparecer correctamente en la entrada Internet Exchange Server 2003, pero borroso en el back-end de Exchange Server. Estos síntomas también pueden cambiar si se reduce el número de destinatarios en el mensaje. Este problema puede aparecer por varias razones, pero las dos razones más comunes son:
  • Encabezados de mensaje RFC 2822 que tienen más de 1000 o 1024 caracteres en una línea, en lugar de 998 caracteres en una línea. Para obtener más información, consulte Request for Comments (RFC) 2822. Para ello, visite el siguiente sitio Web de Internet Engineering Task Force (IETF):Puede experimentar este problema si los mensajes se retransmiten a un equipo de Exchange Server 2003 utilizando datos binarios o agrupamiento. El agrupamiento es una extensión para el formato SMTP que admita datos enviados en fragmentos.

    Cuando Exchange Server 2003 recibe un mensaje que tiene más de 998 caracteres en una línea, el servicio SMTP analiza el encabezado y descubre que la línea es más de 1000 caracteres. El servicio SMTP entonces asume esta línea no es un elemento de encabezado y lo incluye en el cuerpo.

    El servicio SMTP en el equipo de Exchange Server, a continuación, volver a escribir sus propios encabezados, incluyendo el ID de mensaje y un encabezado fecha, seguido por una línea en blanco o un carácter CRLF.
  • Límites de longitud de la línea. Existen muchas implementaciones que, de conformidad con los requisitos de transporte de RFC 2821, no aceptan mensajes que tienen más de 1000 caracteres por línea, incluyendo el carácter CRLF. Por lo tanto, las aplicaciones de correo no deben crear este tipo de mensajes. Para evitar este problema, desactivar la capacidad ESMTP verbo (o fragmentar) en el equipo de Exchange Server y forzar a los equipos de Exchange Server para dar formato a los mensajes SMTP típico formato cuando se reenvía el mensaje. Para obtener más información, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:

    257569 cómo desactivar verbos ESMTP en Exchange 2000 Server y en Exchange Server 2003

    821733 mensaje entrante es ilegible si la línea para supera los 1.022 caracteres

Referencias

Para obtener más información acerca del estándar para el formato de los mensajes de texto de Internet ARPA, consulte RFC 822. Para ello, visite el siguiente sitio Web de IETF:Para obtener más información acerca de MIME, vea RFC 2045, 2046, 2047, 2048 y 2049. Para ello, visite los siguientes sitios Web de IETF:Para obtener más información acerca del campo de encabezado Content-Disposition, consulte RFC 2183. Para ello, visite el siguiente sitio Web de IETF:
Propiedades

Id. de artículo: 836555 - Última revisión: 17 ene. 2017 - Revisión: 1

Comentarios