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

Seleccione idioma Seleccione idioma
Id. de artículo: 836555 - Ver los productos a los que se aplica este artículo
Expandir todo | Contraer todo

Resumen

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

Más información

Trimestre 1: ¿Cuál es el formato de un mensaje de correo electrónico?

A1: Mensajes de correo electrónico de Internet cumplir las normas 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 enviar 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 RFC 2822 formato estándar. El cuerpo contiene una secuencia de caracteres que siguen el encabezado y que están separados entre el encabezado por una línea en blanco (es decir, una línea que no tenga nada antes de retorno de carro) y avance de línea [CRLF].

Los campos de encabezado son líneas que están formadas por un nombre de campo seguido por un signo de dos puntos ((:), seguido por un organismo de campo y finalizadas por un carácter CRLF. Un nombre de campo debe estar compuesto de caracteres US-ASCII imprimibles (es decir, los caracteres que tengan valores comprendidos entre 33 y 126, ambos inclusive), excepto los dos puntos. Los dos puntos se utilizan como un carácter de separación.

El cuerpo de un campo puede estar compuesto de caracteres US-ASCII, excepto el carácter CRLF. Sin embargo, el cuerpo de un campo puede contener un carácter CRLF cuando se utiliza en el encabezado plegable y despliegue. Plegable es cuando, para mayor comodidad, aparece una sola línea en varias líneas. Despliegue es el inverso de esto. Todos los cuerpos de campo deben seguir la sintaxis descrita en los puntos 3 y 4 del formato RFC 2822 estándar.

El cuerpo del mensaje puede incluir una o varias 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 solo 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 en caracteres diferente. El estándar MIME se deriva de las solicitudes de cambio como 2821 y 2822.

Trimestre 3: ¿Cómo Exchange trata MIME?

A3: Hay tres componentes principales en Exchange que llevan a cabo la conversión de contenido:
  • El componente IMAIL es el componente central que convierte los mensajes de Internet a la interfaz MAPI / Exchange formato y viceversa. También comprueba la integridad del mensaje.
  • El componente EXMIME es responsable de traducir los 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 con formato MIME?

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

La sección de cuerpo se incluyen:
  • Tipo de contenido (Esto es opcional. El valor predeterminado es text/plain, tal como se define en RFC 2822 5.2.)
  • Encabezado Content-Transfer-Encoding (Esto es opcional. El valor predeterminado es de 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 la versión MIME?

A5: El campo de encabezado de la versión MIME indica un mensaje con formato MIME. Los mensajes que se envían desde software anterior que no son compatibles con MIME no es necesario 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 los datos en un campo.

Algunos de los tipos de encabezado son multipart/mixed, varias partes/alternativos, text/plain, text/html, aplicación/Applefile contienen, 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 controlar datos multimedia.

Para solucionar temporalmente los sistemas que no se controlan 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 entrecomillado 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 está formado por 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.

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

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

Cuando se envía a un destinatario/servidor del 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, destinos de destino de Exchange y SMTP determinan también cómo Exchange Server 2003 codifica correo.

En modo mixto, Exchange Server 2003 se codifica como entrecomillado imprimible o de 7 bits (formato TNEF) cuando se envía entre los dos servidores/destinatarios en distintos grupos de enrutamiento y a Internet.

En modo nativo, Exchange Server 2003 codifica en formato binario (TNEF de resumen) cuando se envía a un destinatario/servidor en el mismo o en otros grupos de enrutamiento.

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

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

P12: ¿Cómo hace ¿Datos adjuntos de identificador de Exchange?

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

Sin embargo, cuando se leen mensajes desde un cliente MAPI, IMAIL asigna los elementos correspondientes en el formato de Internet a las propiedades de MAPI. De hecho, antes de que incluso se entrega un mensaje de Internet a un buzón, un conjunto mínimo de las propiedades de MAPI debe promoverse desde el mensaje de Internet; Éstas 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 a partir del 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 las propiedades MIME nativas al formato MAPI.

Durante la conversión de contenido en Exchange Server 2003, cuando se procesa un mensaje entrante de MIME a un cliente, IMAIL hace lo siguiente:
  1. IMAIL busca un (de nombre de archivo completoNombre.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 alguno, IMAIL pasa a la
    HKEY_CLASSES_ROOT / / base de datos/content-type MIME
    subclave para 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 hay nombres de archivo se especifican en los encabezados Content-Disposition o Content-type, IMAIL busca un tipo de contenido coincidente. Si encuentra alguno, los datos adjuntos tendrán el formato de ATTnombre.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: ¿Qué es la estructura del mensaje completo?

A13: El siguiente es un ejemplo de un mensaje completo, con todos los encabezados que se muestra. Por lo general, los destinatarios verán sólo las partes de cuerpo. Se han agregado comentarios entre paréntesis.

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


P14: ¿Por qué las direcciones de correo aparecen en el cuerpo de mi mensaje?

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

El primer "carácter CRLF CRLF" separa los encabezados de mensaje de Internet del cuerpo del mensaje. Estos encabezados se conocen como encabezados de P1. Los encabezados de P1 son los encabezados de sobres y no forman parte del mensaje de Internet que se procesa mediante IMAIL.

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

También puede recibir mensajes de correo electrónico a través de un sistema UNIX, a través de un servidor de seguridad o a través de una protección antivirus. Además, un dispositivo de análisis de contenido de otros fabricantes puede estar en la red. Si tiene aplicaciones o dispositivos similares de la red, compruebe los límites de destinatarios. Evitar el uso de tales dispositivos o aplicaciones en las pruebas de diagnóstico.

Respuesta a P15: ¿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 que se encuentran en el mensaje. Debe asegurarse de que el cliente donde se ve el mensaje tiene páginas de códigos instaladas que coinciden con el juego 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 se ven los sucesos 12002 y 12003 en el registro de la aplicación?

A16: Estos eventos de registro de aplicación son de la fuente de almacén de información de Exchange y son los errores de conversión de contenido. Algunos de estos mensajes se pueden pasar por alto y no tienen ningún efecto en los mensajes recibidos. Pero si ve muchos de los siguientes mensajes en los registros de aplicación, vea si los clientes tienen problemas al abrir los mensajes HTML.

Si éste es el caso, establecer información de diagnóstico más como versiones de service pack, copias de mensajes de problemas, copias de registros de aplicación y del 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. </CRLF></CRLF>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 Exchange muestra el mensaje que utiliza el encabezado Content-Disposition MIME de "inline" como datos adjuntos
P18: ¿Por qué veo "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:
  • "Éste es un mensaje con varias partes en formato MIME."
  • "Este mensaje está en formato MIME. Debido a que su lector de correo no entiende este formato, parte o la totalidad de este mensaje puede no ser legible."

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

Para solucionar este problema, active mensaje archivado en el servicio de correo de Internet de Microsoft Exchange. Para activar mensaje archivado, 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 de receptor de archivo, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:
307798La utilidad Archive Sink está disponible en el Service Pack 2
P19: ¿Por qué es el tamaño de mi correo aproximadamente un 33% mayor de lo que espero y ¿por qué resulta codificado 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 GB18030 HZ_GB, Big5,


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

A20: Los mensajes que 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 envía desde Internet a un equipo entrante de Internet de Exchange Server 2003 y, a continuación, en otro equipo de Exchange Server 2003.
El mensaje puede aparecer correctamente en Inbound Internet Exchange Server 2003, pero borroso en el back-end de Exchange Server. También pueden cambiar estos síntomas si se reduce el número de destinatarios del 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):
    http://www.ietf.org/rfc/RFC2822.txt?number=2822
    Puede experimentar este problema si los mensajes se retransmiten a un equipo con Exchange Server 2003 mediante el uso de datos binarios o por operaciones de fragmentación. Operaciones de fragmentación es una extensión al formato SMTP que es compatible con datos que se envían en fragmentos.

    Cuando Exchange Server 2003 recibe un mensaje que tenga 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, a continuación, se supone que esta línea no es un elemento de encabezado e 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 de fecha, seguido de una línea en blanco o un carácter CRLF.
  • Límites de longitud de línea. Existen muchas implementaciones de que, con arreglo a los requisitos de transporte del documento RFC 2821, no aceptan los mensajes que tienen más de 1.000 caracteres por línea, incluyendo el carácter CRLF. Por lo tanto, las aplicaciones de correo no deben crear este tipo de mensajes. Para solucionar temporalmente este problema, desactive la opción el ESMTP verbo (o fragmentar) la función en el equipo de Exchange Server y los equipos de Exchange Server para dar formato a la fuerza los mensajes de SMTP típico aplicar formato al que se se retransmite el mensaje. Para obtener más información, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:
    257569Cómo desactivar algunos verbos ESMTP en Exchange 2000 Server y en Exchange Server 2003
    821733 Los mensajes entrantes es ilegible si la línea para tiene más de 1.022 caracteres

Referencias

Para obtener más información acerca del estándar para el formato de ARPA Internet text messages, consulte RFC 822. Para ello, visite el siguiente sitio Web de IETF:
http://www.ietf.org/rfc/rfc0822.txt?number=822
Para obtener más información acerca de MIME, consulte RFC 2045, 2046, 2047, 2048 y 2049. Para ello, visite los siguientes sitios Web de IETF:
http://www.ietf.org/rfc/rfc2045.txt?number=2045
http://www.ietf.org/rfc/rfc2046.txt?number=2046
http://www.ietf.org/rfc/Rfc2047.txt?number=2047
http://www.ietf.org/rfc/rfc2048.txt?number=2048
http://www.ietf.org/rfc/rfc2049.txt?number=2049
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:
http://www.ietf.org/rfc/rfc2183.txt?number=2183

Propiedades

Id. de artículo: 836555 - Última revisión: domingo, 16 de diciembre de 2012 - Versión: 5.0
La información de este artículo se refiere a:
  • Microsoft Exchange Server 2003 Enterprise Edition
  • Microsoft Exchange Server 2003 Standard Edition
  • Microsoft Exchange 2000 Server Standard Edition
Palabras clave: 
kbFAQ kbinfo kbmt KB836555 KbMtes
Traducción automática
IMPORTANTE: Este artículo ha sido traducido por un software de traducción automática de Microsoft (http://support.microsoft.com/gp/mtdetails) en lugar de un traductor humano. Microsoft le ofrece artículos traducidos por un traductor humano y artículos traducidos automáticamente para que tenga acceso en su propio idioma a todos los artículos de nuestra base de conocimientos (Knowledge Base). Sin embargo, los artículos traducidos automáticamente pueden contener errores en el vocabulario, la sintaxis o la gramática, como los que un extranjero podría cometer al hablar el idioma. Microsoft no se hace responsable de cualquier imprecisión, error o daño ocasionado por una mala traducción del contenido o como consecuencia de su utilización por nuestros clientes. Microsoft suele actualizar el software de traducción frecuentemente.
Haga clic aquí para ver el artículo original (en inglés): 836555

Enviar comentarios

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com