MIME - MIME

Extensiones multipropósito de correo de Internet ( MIME ) es un estándar de Internet que amplía el formato de los mensajes de correo electrónico para admitir texto en conjuntos de caracteres distintos de ASCII , así como archivos adjuntos de audio, video, imágenes y programas de aplicación. Los cuerpos de los mensajes pueden constar de varias partes y la información de encabezado se puede especificar en juegos de caracteres no ASCII. Los mensajes de correo electrónico con formato MIME se transmiten normalmente con protocolos estándar, como el Protocolo simple de transferencia de correo (SMTP), el Protocolo de oficina postal (POP) y el Protocolo de acceso a mensajes de Internet (IMAP).

El estándar MIME se especifica en una serie de solicitudes de comentarios : RFC 2045 , RFC 2046 , RFC 2047 , RFC 4288 , RFC 4289 y RFC 2049 . La integración con el correo electrónico SMTP se especifica en RFC 1521 y RFC 1522 .

Aunque el formalismo MIME se diseñó principalmente para SMTP, sus tipos de contenido también son importantes en otros protocolos de comunicación . En el Protocolo de transferencia de hipertexto (HTTP) para la World Wide Web , los servidores insertan un campo de encabezado MIME al comienzo de cualquier transmisión Web. Los clientes utilizan el tipo de contenido o el encabezado del tipo de medio para seleccionar una aplicación de visor adecuada para el tipo de datos indicados.

Campos de encabezado MIME

Versión MIME

La presencia de este campo de encabezado indica que el mensaje tiene formato MIME. El valor suele ser "1.0". El campo aparece de la siguiente manera:

MIME-Version: 1.0

Según el co-creador de MIME, Nathaniel Borenstein , el número de versión se introdujo para permitir cambios en el protocolo MIME en versiones posteriores. Sin embargo, Borenstein admitió deficiencias en la especificación que obstaculizaron la implementación de esta función: "No especificamos adecuadamente cómo manejar una versión futura de MIME ... Entonces, si escribe algo que sepa 1.0, ¿qué debe hacer si encuentro 2.0 o 1.1? En cierto modo pensé que era obvio, pero resultó que todos lo implementaron de diferentes maneras. Y el resultado es que sería casi imposible para Internet definir alguna vez un 2.0 o un 1.1 ".

Tipo de contenido

Este campo de encabezado indica el tipo de medio del contenido del mensaje, que consta de un tipo y subtipo , por ejemplo

Content-Type: text/plain

Mediante el uso del tipo multiparte , MIME permite que los mensajes de correo tengan partes organizadas en una estructura de árbol donde los nodos hoja son cualquier tipo de contenido no multiparte y los nodos no hojas son cualquiera de una variedad de tipos multiparte. Este mecanismo admite:

  • mensajes de texto simples con texto / sin formato (el valor predeterminado para "Content-Type:")
  • texto más archivos adjuntos ( multiparte / mezclado con un texto / parte sin formato y otras partes que no son de texto). Un mensaje MIME que incluye un archivo adjunto generalmente indica el nombre original del archivo con el campo "Disposición de contenido", de modo que el tipo de archivo se indica tanto por el tipo de contenido MIME como por la extensión de nombre de archivo (generalmente específica del sistema operativo )
  • responder con el original adjunto ( multiparte / mezclado con un texto / parte simple y el mensaje original como un mensaje / parte rfc822 )
  • contenido alternativo, como un mensaje enviado tanto en texto sin formato como en otro formato como HTML ( multiparte / alternativo con el mismo contenido en formato de texto / sin formato y texto / html )
  • imagen, audio, video y aplicación (por ejemplo, imagen / jpeg , audio / mp3 , video / mp4 y aplicación / msword, etc.)
  • muchas otras construcciones de mensajes

Disposición de contenido

Las especificaciones originales de MIME solo describían la estructura de los mensajes de correo. No abordaron la cuestión de los estilos de presentación. El campo de encabezado de disposición de contenido se agregó en RFC 2183 para especificar el estilo de presentación. Una parte MIME puede tener:

  • una disposición de contenido en línea , lo que significa que debe mostrarse automáticamente cuando se muestra el mensaje, o
  • una disposición de contenido adjunto , en cuyo caso no se muestra automáticamente y requiere algún tipo de acción por parte del usuario para abrirlo.

Además del estilo de presentación, el campo Content-Disposition también proporciona parámetros para especificar el nombre del archivo, la fecha de creación y la fecha de modificación, que pueden ser utilizados por el agente de usuario de correo del lector para almacenar el adjunto.

El siguiente ejemplo se toma de RFC 2183, donde se define el campo de encabezado:

Content-Disposition: attachment; filename=genome.jpeg;
  modification-date="Wed, 12 Feb 1997 16:29:51 -0500";

El nombre del archivo puede estar codificado como se define en RFC 2231.

A partir de 2010, la mayoría de los agentes de usuarios de correo no siguieron esta prescripción en su totalidad. El cliente de correo Mozilla Thunderbird, ampliamente utilizado, ignora los campos de disposición de contenido en los mensajes y utiliza algoritmos independientes para seleccionar las partes MIME que se mostrarán automáticamente. Thunderbird antes de la versión 3 también envía mensajes recién compuestos con disposición de contenido en línea para todas las partes MIME. La mayoría de los usuarios desconocen cómo establecer la disposición del contenido como adjunto . Muchos agentes de usuario de correo también envían mensajes con el nombre de archivo en el parámetro de nombre del encabezado de tipo de contenido en lugar del parámetro de nombre de archivo del campo de encabezado Content-Disposition . Se desaconseja esta práctica, ya que el nombre del archivo debe especificarse con el nombre del archivo del parámetro o con el nombre y el nombre del archivo de los parámetros .

En HTTP, el campo de encabezado de respuesta Content-Disposition: adjunto se usa generalmente como una sugerencia para que el cliente presente el cuerpo de la respuesta como un archivo descargable. Por lo general, cuando recibe una respuesta de este tipo, un navegador web solicita al usuario que guarde su contenido como un archivo, en lugar de mostrarlo como una página en una ventana del navegador, con el nombre de archivo que sugiere el nombre de archivo predeterminado.

Codificación de transferencia de contenido

En junio de 1992, MIME (RFC 1341, que quedó obsoleto por RFC 2045) definió un conjunto de métodos para representar datos binarios en formatos distintos al formato de texto ASCII. El campo de encabezado content-transfer-encoding: MIME tiene un significado bilateral:

  • Indica si se ha utilizado o no un esquema de codificación de binario a texto además de la codificación original como se especifica en el encabezado Content-Type:
  1. Si se ha utilizado dicho método de codificación de binario a texto, indica cuál.
  2. De lo contrario, proporciona una etiqueta descriptiva para el formato del contenido, con respecto a la presencia de contenido binario o de 8 bits.

La RFC y la lista de codificaciones de transferencia de la IANA definen los valores que se muestran a continuación, que no distinguen entre mayúsculas y minúsculas. Tenga en cuenta que '7 bits', '8 bits' y 'binario' significan que no se utilizó codificación de binario a texto además de la codificación original. En estos casos, el campo de encabezado es realmente redundante para que el cliente de correo electrónico decodifique el cuerpo del mensaje, pero aún puede ser útil como indicador del tipo de objeto que se envía. Los valores ' quoted-printable ' y ' base64 ' le dicen al cliente de correo electrónico que se usó un esquema de codificación de binario a texto y que es necesaria una decodificación inicial adecuada antes de que el mensaje pueda leerse con su codificación original (por ejemplo, UTF-8).

  • Adecuado para su uso con SMTP normal:
    • 7 bits : hasta 998 octetos por línea del rango de códigos 1..127 con CR y LF (códigos 13 y 10 respectivamente) solo se permite que aparezcan como parte de un final de línea CRLF. Este es el valor predeterminado.
    • quoted-printable : se utiliza para codificar secuencias de octetos arbitrarias en una forma que satisfaga las reglas de 7 bits. Diseñado para ser eficiente y en su mayoría legible por humanos cuando se usa para datos de texto que consisten principalmente en caracteres US-ASCII pero que también contienen una pequeña proporción de bytes con valores fuera de ese rango.
    • base64 : se utiliza para codificar secuencias de octetos arbitrarios en una forma que satisfaga las reglas de 7 bits. Diseñado para ser eficiente para datos binarios y de 8 bits sin texto. A veces se utiliza para datos de texto que utilizan con frecuencia caracteres que no son ASCII de EE. UU.
  • Adecuado para su uso con servidores SMTP que admiten la extensión SMTP 8BITMIME (RFC 6152):
    • 8 bits : hasta 998 octetos por línea con CR y LF (códigos 13 y 10 respectivamente) solo se permite aparecer como parte de un final de línea CRLF.
  • Adecuado para su uso con servidores SMTP que admiten la extensión BINARYMIME SMTP (RFC 3030):
    • binario : cualquier secuencia de octetos.

No hay una codificación definida que esté diseñada explícitamente para enviar datos binarios arbitrarios a través de transportes SMTP con la extensión 8BITMIME. Por lo tanto, si BINARYMIME no es compatible, base64 o quoted-printable (con su ineficiencia asociada) a veces siguen siendo útiles. Esta restricción no se aplica a otros usos de MIME, como los servicios web con archivos adjuntos MIME o MTOM .

Palabra codificada

Desde RFC 2822, los valores y nombres de campo de encabezado de mensaje conformes utilizan caracteres ASCII; los valores que contienen datos que no son ASCII deben utilizar la sintaxis de palabra codificada MIME (RFC 2047) en lugar de una cadena literal. Esta sintaxis usa una cadena de caracteres ASCII que indica tanto la codificación de caracteres original (el " juego de caracteres ") como la codificación de transferencia de contenido utilizada para mapear los bytes del juego de caracteres en caracteres ASCII.

El formulario es: " texto codificado de codificación de =?juego de caracteres ". ???=

  • charset puede ser cualquier juego de caracteres registrado con IANA . Normalmente sería el mismo juego de caracteres que el cuerpo del mensaje.
  • la codificación puede ser " Q" que denota codificación Q que es similar a la codificación imprimible entre comillas , o " B" que denota codificación base64 .
  • El texto codificado es el texto codificado en Q o codificado en base64.
  • Una palabra codificada no puede tener más de 75 caracteres, incluido el juego de caracteres , la codificación , el texto codificado y los delimitadores. Si se desea codificar más texto del que cabe en una palabra codificada de 75 caracteres, se pueden utilizar varias palabras codificadas (separadas por CRLF SPACE).

Diferencia entre codificación Q e imprimible entre comillas

Es posible que los códigos ASCII para el signo de interrogación ("?") Y el signo igual ("=") no se representen directamente, ya que se utilizan para delimitar la palabra codificada. Es posible que el código ASCII para el espacio no se represente directamente porque podría provocar que los analizadores más antiguos dividan la palabra codificada de forma indeseable. Para hacer la codificación más pequeña y más fácil de leer, el subrayado se usa para representar el código ASCII para el espacio, creando el efecto secundario de que el subrayado no se puede representar directamente. El uso de palabras codificadas en ciertas partes de los campos de encabezado impone restricciones adicionales sobre qué caracteres pueden representarse directamente.

Por ejemplo,

Subject: =?iso-8859-1?Q?=A1Hola,_se=F1or!?=

se interpreta como "Asunto: ¡Hola, señor!".

El formato de palabra codificada no se utiliza para los nombres de los campos de encabezados (por ejemplo, Asunto ). Estos nombres suelen ser términos en inglés y siempre en ASCII en el mensaje sin formato. Al ver un mensaje con un cliente de correo electrónico que no está en inglés, el cliente puede traducir los nombres de los campos de encabezado.

Mensajes de varias partes

El mensaje de varias partes MIME contiene un límite en el campo de encabezado ; este límite, que no debe ocurrir en ninguna de las partes, se coloca entre las partes, y al principio y al final del cuerpo del mensaje, de la siguiente manera: Content-Type:

MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=frontier

This is a message with multiple parts in MIME format.
--frontier
Content-Type: text/plain

This is the body of the message.
--frontier
Content-Type: application/octet-stream
Content-Transfer-Encoding: base64

PGh0bWw+CiAgPGhlYWQ+CiAgPC9oZWFkPgogIDxib2R5PgogICAgPHA+VGhpcyBpcyB0aGUg
Ym9keSBvZiB0aGUgbWVzc2FnZS48L3A+CiAgPC9ib2R5Pgo8L2h0bWw+Cg==
--frontier--

Cada parte consta de su propio encabezado de contenido (cero o más Content-campos de encabezado) y un cuerpo. El contenido de varias partes se puede anidar. El Content-Transfer-Encodingde un tipo multiparte debe ser siempre "7 bits", "8 bits" o "binario" para evitar las complicaciones que plantearían los múltiples niveles de decodificación. El bloque de varias partes en su conjunto no tiene un juego de caracteres; Los caracteres que no son ASCII en los encabezados de las partes son manejados por el sistema Encoded-Word , y los cuerpos de las partes pueden tener juegos de caracteres especificados si es apropiado para su tipo de contenido.

Notas:

  • Antes del primer límite hay un área que los clientes compatibles con MIME ignoran. Esta área se usa generalmente para enviar un mensaje a los usuarios de clientes antiguos que no son MIME.
  • Depende del cliente de correo remitente elegir una cadena de límite que no entre en conflicto con el texto del cuerpo. Normalmente, esto se hace insertando una larga cadena aleatoria.
  • El último límite debe tener dos guiones al final.

Subtipos de varias partes

El estándar MIME define varios subtipos de mensajes multiparte, que especifican la naturaleza de las partes del mensaje y su relación entre sí. El subtipo se especifica en el Content-Typecampo de encabezado del mensaje general. Por ejemplo, un mensaje MIME de varias partes que utiliza el subtipo de resumen tendría su Content-Typeconjunto como "multipart / digest".

El RFC definió inicialmente cuatro subtipos: mixto, resumen, alternativo y paralelo. Una aplicación mínimamente compatible debe admitir la mezcla y la digestión; otros subtipos son opcionales. Las aplicaciones deben tratar los subtipos no reconocidos como "multipartes / mixtos". Los subtipos adicionales, como los firmados y los datos de formulario, se han definido por separado en otras RFC.

mezclado

multipart / mixed se utiliza para enviar archivos con diferentes Content-Typecampos de encabezado en línea (o como archivos adjuntos). Si envía imágenes u otros archivos fácilmente legibles, la mayoría de los clientes de correo los mostrarán en línea (a menos que se especifique explícitamente con Content-Disposition: archivo adjunto, en cuyo caso se ofrecen como archivos adjuntos). El tipo de contenido predeterminado para cada parte es "texto / sin formato".

El tipo se define en RFC 2046.

digerir

multipart / digest es una forma sencilla de enviar varios mensajes de texto. El tipo de contenido predeterminado para cada parte es "mensaje / rfc822".

El tipo MIME se define en RFC 2046.

alternativa

El subtipo multiparte / alternativo indica que cada parte es una versión "alternativa" del mismo (o similar) contenido, cada una en un formato diferente indicado por su encabezado "Content-Type". El orden de las partes es significativo. RFC1341 establece: En general, los agentes de usuario que componen entidades multiparte / alternativas deben colocar las partes del cuerpo en orden creciente de preferencia, es decir, con el formato preferido al final.

Los sistemas pueden entonces elegir la "mejor" representación que son capaces de procesar; en general, esta será la última parte que el sistema pueda entender, aunque otros factores pueden afectar esto.

Dado que es poco probable que un cliente quiera enviar una versión que sea menos fiel que la versión de texto sin formato, esta estructura coloca la versión de texto sin formato (si está presente) en primer lugar. Esto facilita la vida a los usuarios de clientes que no comprenden los mensajes de varias partes.

Más comúnmente, multipartes / alternativo se usa para el correo electrónico con dos partes, una de texto sin formato (texto / sin formato) y una HTML (texto / html) . La parte de texto sin formato proporciona compatibilidad con versiones anteriores, mientras que la parte HTML permite el uso de formato e hipervínculos. La mayoría de los clientes de correo electrónico ofrecen al usuario la opción de preferir texto sin formato sobre HTML; Este es un ejemplo de cómo los factores locales pueden afectar la forma en que una aplicación elige qué parte "mejor" del mensaje mostrar.

Si bien se pretende que cada parte del mensaje represente el mismo contenido, el estándar no requiere que esto se aplique de ninguna manera. En un momento, los filtros antispam solo examinaban el texto / parte simple de un mensaje, porque es más fácil de analizar que la parte text / html. Pero los spammers eventualmente se aprovecharon de esto, creando mensajes con una parte de texto / simple de apariencia inocua y publicidad en la parte de texto / html. El software anti-spam finalmente se puso al día con este truco, penalizando los mensajes con texto muy diferente en un mensaje de varias partes / alternativo.

El tipo se define en RFC 2046.

relacionado

Un multiparte / relacionado se usa para indicar que cada parte del mensaje es un componente de un todo agregado. Es para objetos compuestos que constan de varios componentes interrelacionados; no se puede lograr una visualización adecuada mostrando individualmente las partes constituyentes. El mensaje consta de una parte raíz (por defecto, la primera) que hace referencia a otras partes en línea, que a su vez pueden hacer referencia a otras partes. Las partes del mensaje son comúnmente referenciadas por Content-ID . La sintaxis de una referencia no está especificada y, en cambio, está dictada por la codificación o el protocolo utilizado en la parte.

Un uso común de este subtipo es enviar una página web completa con imágenes en un solo mensaje. La parte raíz contendría el documento HTML y usaría etiquetas de imagen para hacer referencia a las imágenes almacenadas en las últimas partes.

El tipo se define en RFC 2387.

reporte

multipart / report es un tipo de mensaje que contiene datos formateados para que los lea un servidor de correo. Se divide entre un texto / sin formato (o algún otro contenido / tipo fácilmente legible) y un mensaje / estado de entrega, que contiene los datos formateados para que los lea el servidor de correo.

El tipo se define en RFC 6522.

firmado

Un mensaje multiparte / firmado se utiliza para adjuntar una firma digital a un mensaje. Tiene exactamente dos partes del cuerpo, una parte del cuerpo y una parte de la firma. Toda la parte del cuerpo, incluidos los campos de mímica, se utiliza para crear la parte de la firma. Son posibles muchos tipos de firmas, como "application / pgp-signature" (RFC 3156) y "application / pkcs7-signature" ( S / MIME ).

El tipo se define en RFC 1847.

cifrado

Un mensaje de varias partes / cifrado tiene dos partes. La primera parte tiene información de control necesaria para descifrar la segunda parte de la aplicación / flujo de octetos. De manera similar a los mensajes firmados, existen diferentes implementaciones que se identifican por sus tipos de contenido separados para la parte de control. Los tipos más comunes son "application / pgp-encrypted" (RFC 3156) y "application / pkcs7-mime" ( S / MIME ).

El tipo MIME definido en RFC 1847.

formulario-datos

El tipo MIME multipart / form-data se utiliza para expresar valores enviados a través de un formulario. Originalmente definido como parte de HTML 4.0, se usa más comúnmente para enviar archivos con HTTP . Se especifica en RFC 7578, reemplazando a RFC 2388. ejemplo

x-reemplazo-mixto

El tipo de contenido multipart / x-mixed-replace se desarrolló como parte de una tecnología para emular el envío y la transmisión del servidor a través de HTTP.

Todas las partes de un mensaje de reemplazo mixto tienen el mismo significado semántico. Sin embargo, cada parte invalida - "reemplaza" - las partes anteriores tan pronto como se recibe por completo. Los clientes deben procesar las partes individuales tan pronto como lleguen y no deben esperar a que termine todo el mensaje.

Desarrollado originalmente por Netscape , todavía es compatible con Mozilla , Firefox , Safari y Opera . Se usa comúnmente en cámaras IP como el tipo MIME para transmisiones MJPEG . Fue compatible con Chrome para los recursos principales hasta 2013 (las imágenes aún se pueden mostrar con este tipo de contenido).

rango de bytes

El multipart / byterange se usa para representar rangos de bytes no contiguos de un solo mensaje, HTTP lo usa cuando un servidor devuelve múltiples rangos de bytes y se define en RFC 2616.

Documentación RFC

  • RFC  1426 , Extensión de servicio SMTP para transporte MIME de 8 bits . J. Klensin , N. Freed , M. Rose , E. Stefferud , D. Crocker. Febrero de 1993.
  • RFC  1847 , Security Multiparts para MIME: Multipartes / Signed y Multipartes / Encrypted
  • RFC  3156 , seguridad MIME con OpenPGP
  • RFC  2045 , MIME Part One: Formato de los cuerpos de mensajes de Internet
  • RFC  2046 , MIME Parte dos: Tipos de medios . N. Freed, Nathaniel Borenstein . Noviembre de 1996.
  • RFC  2047 , MIME Tercera parte: Extensiones de encabezado de mensaje para texto no ASCII . Keith Moore . Noviembre de 1996.
  • RFC  4288 , MIME Parte cuatro: Especificaciones de tipo de medio y procedimientos de registro .
  • RFC  4289 , MIME Parte cuatro: Procedimientos de registro . N. Freed, J. Klensin. Diciembre de 2005.
  • RFC  2049 , MIME Parte cinco: Criterios de conformidad y ejemplos . N. Freed, N. Borenstein. Noviembre de 1996.
  • RFC  2183 , Comunicación de información de presentación en mensajes de Internet: el campo de encabezado de disposición de contenido . Troost, R., Dorner, S. y K. Moore. Agosto de 1997.
  • RFC  2231 , valor de parámetro MIME y extensiones de palabras codificadas: juegos de caracteres, idiomas y continuaciones . N. Freed, K. Moore. Noviembre de 1997.
  • RFC  2387 , el tipo de contenido MIME multiparte / relacionado
  • RFC  1521 , Mecanismos para especificar y describir el formato de los cuerpos de mensajes de Internet

Ver también

Referencias

Otras lecturas

enlaces externos