Las extensiones multipropósito de correo de Internet ( MIME ) son un estándar de Internet que extiende 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 aplicaciones. Los cuerpos de los mensajes pueden constar de varias partes y la información del encabezado puede especificarse en juegos de caracteres que no sean ASCII. Los mensajes de correo electrónico con formato MIME normalmente se transmiten 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 fue diseñado 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 encabezado del tipo de contenido o del tipo de medio para seleccionar una aplicación de visualización adecuada para el tipo de datos indicado.
MIME se originó a partir del Andrew Messaging System, que era parte del Proyecto Andrew desarrollado en la Universidad Carnegie Mellon (CMU), como una alternativa multiplataforma al formato de datos específico de Andrew. [1]
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:
Versión MIME: 1.0
Según el cocreador 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 característica: "No especificamos adecuadamente cómo manejar una futura versión MIME... Entonces, si escribes algo que sabe 1.0, ¿qué deberías hacer si ¿Encontrar 2.0 o 1.1? Pensé que era obvio, pero resultó que cada uno lo implementó de diferentes maneras. Y el resultado es que sería casi imposible para Internet definir alguna vez un 2.0 o un 1.1". [2]
Este campo de encabezado indica el tipo de medio del contenido del mensaje, que consta de un tipo y un subtipo , por ejemplo
Tipo de contenido: texto/sin formato
Mediante el uso del tipo multiparte , MIME permite que los mensajes de correo tengan partes dispuestas en una estructura de árbol donde los nodos hoja son cualquier tipo de contenido que no sea multiparte y los nodos que no son hoja sean cualquiera de una variedad de tipos multiparte. Este mecanismo soporta:
Las especificaciones MIME originales 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:
Además del estilo de presentación, el campo Contenido-Disposición también proporciona parámetros para especificar el nombre del archivo, la fecha de creación y la fecha de modificación, que el agente de usuario de correo del lector puede utilizar para almacenar el archivo adjunto.
El siguiente ejemplo está tomado del RFC 2183, donde se define el campo de encabezado:
Contenido-Disposición: adjunto; nombre de archivo=genoma.jpeg; fecha-modificación="Miércoles, 12 de febrero de 1997 16:29:51 -0500";
El nombre del archivo puede codificarse como se define en RFC 2231.
En 2010, la mayoría de los agentes usuarios de correo no siguieron plenamente esta prescripción. El ampliamente utilizado cliente de correo Mozilla Thunderbird 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 anterior a la versión 3 también envía mensajes recién redactados con disposición de contenido en línea para todas las partes MIME. La mayoría de los usuarios no saben cómo configurar la disposición del contenido como archivo adjunto . [3] Muchos agentes de usuario de correo también envían mensajes con el nombre del 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 parámetro filename o con ambos parámetros filename y name . [4]
En HTTP, el campo del encabezado de respuesta Disposición de contenido: archivo adjunto generalmente se usa como una sugerencia para que el cliente presente el cuerpo de la respuesta como un archivo descargable. Normalmente, al recibir 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, donde el nombre de archivo sugiere el nombre de archivo predeterminado.
En junio de 1992, MIME (RFC 1341, desde entonces obsoleto por RFC 2045) definió un conjunto de métodos para representar datos binarios en formatos distintos del formato de texto ASCII. El campo de encabezado content-transfer-encoding: MIME tiene un significado bilateral:
El 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. '7 bits', '8 bits' y 'binario' significan que no se utilizó ninguna codificación de binario a texto además de la codificación original. En estos casos, el campo del encabezado es en realidad redundante para que el cliente de correo electrónico decodifique el cuerpo del mensaje, pero aún así puede ser útil como indicador de qué tipo de objeto se está enviando. Los valores ' quoted-printable ' y ' base64 ' le indican al cliente de correo electrónico que se utilizó un esquema de codificación de binario a texto y que es necesaria una descodificación inicial adecuada antes de que el mensaje pueda leerse con su codificación original (por ejemplo, UTF-8).
No hay ninguna 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 servicios web con archivos adjuntos MIME o MTOM .
Desde RFC 2822, los nombres y valores de los campos de encabezado de mensajes conformes utilizan caracteres ASCII; los valores que contienen datos que no son ASCII deben utilizar la sintaxis de palabras codificadas MIME (RFC 2047) en lugar de una cadena literal. Esta sintaxis utiliza 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 asignar los bytes del juego de caracteres a caracteres ASCII.
El formulario es: " texto codificado con codificación de juego de =?caracteres ".???=
Q" que denota codificación Q que es similar a la codificación imprimible entre comillasB , o " " que denota codificación base64 .Los códigos ASCII para el signo de interrogación ("?") y el signo igual ("=") no pueden representarse 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 causar que los analizadores más antiguos dividan la palabra codificada de manera no deseada. Para hacer que la codificación sea más pequeña y más fácil de leer, se utiliza el guión bajo para representar el código ASCII para el espacio, creando el efecto secundario de que el guión bajo no se puede representar directamente. El uso de palabras codificadas en determinadas 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 encabezado (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 del encabezado.
El mensaje MIME de varias partes contiene un límite en el campo del encabezado Content-Type:; 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:
Versión MIME: 1.0 Tipo de contenido: multiparte / mixto ; límite = frontera Este es un mensaje con varias partes en formato MIME.--frontier Tipo de contenido: texto / plano Este es el cuerpo del mensaje.--frontier Tipo de contenido: aplicación / octeto-stream Codificación de transferencia de contenido: base64 PGh0bWw+CiAgPGhlYWQ+CiAgPC9oZWFkPgogIDxib2R5PgogICAgPHA+VGhpcyBpcyB0aGUg Ym9keSBvZiB0aGUgbWVzc2FnZS48L3A+CiAgPC9ib2R5Pgo8L2h0bWw+Cg== --frontera--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 siempre debe ser "7 bits", "8 bits" o "binario" para evitar las complicaciones que plantearían los múltiples niveles de decodificación. El bloque multiparte en su conjunto no tiene juego de caracteres; Los caracteres no 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:
El estándar MIME define varios subtipos de mensajes de varias partes, que especifican la naturaleza de las partes del mensaje y su relación entre sí. El subtipo se especifica en el Content-Typecampo del encabezado del mensaje general. Por ejemplo, un mensaje MIME de varias partes que utilice el subtipo de resumen tendría su Content-Typeconfiguración como "multiparte/digest".
El RFC definió inicialmente cuatro subtipos: mixto, resumido, alternativo y paralelo. Una aplicación que cumpla mínimamente debe admitir la mezcla y la digestión; otros subtipos son opcionales. Las aplicaciones deben tratar los subtipos no reconocidos como "multiparte/mixtos". Desde entonces, se han definido por separado subtipos adicionales, como datos firmados y de formulario, en otros RFC.
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: adjunto, en cuyo caso se ofrecerán como archivos adjuntos). El tipo de contenido predeterminado para cada parte es "texto/sin formato".
El tipo se define en RFC 2046. [5]
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. [6]
El subtipo multiparte/alternativo indica que cada parte es una versión "alternativa" del mismo contenido (o similar), cada una en un formato diferente indicado por su encabezado "Tipo de contenido". El orden de las piezas 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. [7]
Luego, los sistemas pueden elegir la "mejor" representación que sean 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) primero. Esto facilita la vida a los usuarios de clientes que no entienden los mensajes de varias partes.
Más comúnmente, multipart/alternative se utiliza para correos electrónicos con dos partes, una de texto sin formato (text/plain) y otra HTML (text/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 a HTML; Este es un ejemplo de cómo los factores locales pueden afectar la forma en que una aplicación elige qué "mejor" parte del mensaje mostrar.
Si bien se pretende que cada parte del mensaje represente el mismo contenido, el estándar no exige que esto se aplique de ninguna manera. Hubo un tiempo en que los filtros antispam solo examinaban la parte de texto/sin formato de un mensaje, [8] porque es más fácil de analizar que la parte de texto/html. Pero los spammers finalmente se aprovecharon de esto, creando mensajes con una parte de texto sin formato de aspecto inofensivo y publicidad en la parte de texto/html. El software antispam finalmente se dio cuenta de este truco, penalizando los mensajes con texto muy diferente en un mensaje de varias partes/alternativo. [8]
El tipo se define en RFC 2046. [9]
Se utiliza multiparte/relacionado 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 suelen ser 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 está definido en RFC 2387.
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 está definido en RFC 6522.
Un mensaje firmado/de varias partes 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. La parte completa del cuerpo, incluidos los campos mime, se utiliza para crear la parte de la firma. Son posibles muchos tipos de firma, como "application/pgp-signature" (RFC 3156) y "application/pkcs7-signature" ( S/MIME ).
El tipo está definido en RFC 1847. [10]
Un mensaje cifrado/de varias partes tiene dos partes. La primera parte tiene información de control que se necesita 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. [11]
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, que reemplaza a RFC 2388. ejemplo
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 en su totalidad. Los clientes deben procesar las partes individuales tan pronto como lleguen y no deben esperar a que termine el mensaje completo.
Desarrollado originalmente por Netscape , [12] todavía es compatible con Mozilla , Firefox , Safari y Opera . Se utiliza comúnmente en cámaras IP como tipo MIME para transmisiones MJPEG . [13] Chrome lo admitió para los recursos principales hasta 2013 (las imágenes aún se pueden mostrar usando este tipo de contenido). [14]
El rango de bytes/multiparte 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.