MIME ( Multipurpose Internet Mail Extensions ) es un estándar 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 del encabezado puede especificarse en conjuntos de caracteres distintos de 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).
MIME es un estándar de Internet . 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 de tipo de contenido o tipo de medio para seleccionar una aplicación de visualización adecuada para el tipo de datos indicado.
MIME se originó a partir del Sistema de mensajería Andrew, 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 dificultaban la implementación de esta característica: "No especificamos adecuadamente cómo manejar una futura versión de MIME... Entonces, si escribes algo que conoce la versión 1.0, ¿qué deberías hacer si te encuentras con la 2.0 o la 1.1? Pensé que era obvio, pero resultó que todos lo implementaron de diferentes maneras. Y el resultado es que sería prácticamente imposible para Internet definir alguna vez una versión 2.0 o una 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 organizadas en una estructura de árbol donde los nodos de hoja son cualquier tipo de contenido no multiparte y los nodos no hoja son cualquiera de una variedad de tipos multiparte. Este mecanismo admite (no exhaustivamente):
Las especificaciones MIME originales solo describían la estructura de los mensajes de correo. No abordaban la cuestión de los estilos de presentación. El campo de encabezado content-disposition 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 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 archivo adjunto.
El siguiente ejemplo está tomado de RFC 2183, donde se define el campo de encabezado:
Disposición del contenido: adjunto; nombre_archivo=genome.jpeg; fecha-de-modificación="miércoles, 12 de febrero de 1997 16:29:51 -0500";
El nombre del archivo puede codificarse según se define en RFC 2231.
A partir de 2010, la mayoría de los agentes de usuario de correo no siguieron esta prescripción por completo. El cliente de correo Mozilla Thunderbird, ampliamente utilizado, ignora los campos content-disposition 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 compuestos con disposición de contenido en línea para todas las partes MIME. La mayoría de los usuarios no saben cómo establecer la disposición de contenido en attached . [3] Muchos agentes de usuario de correo también envían mensajes con el nombre de archivo en el parámetro name del encabezado content-type en lugar del parámetro filename del campo de encabezado Content-Disposition . Esta práctica no se recomienda, ya que el nombre de archivo debe especificarse con el parámetro filename o con ambos parámetros filename y name . [4]
En HTTP, el campo de encabezado de respuesta Content-Disposition: attached se utiliza generalmente como una sugerencia para que el cliente presente el cuerpo de la respuesta como un archivo descargable. Normalmente, cuando se 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, y el nombre del archivo sugiere el nombre de archivo predeterminado.
En junio de 1992, MIME (RFC 1341, que quedó obsoleto a partir de 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:
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. '7bit', '8bit' y 'binary' significan que no se utilizó ninguna codificación de binario a texto sobre la codificación original. En estos casos, el campo de encabezado es en realidad redundante para que el cliente de correo electrónico decodifique el cuerpo del mensaje, pero aún 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 decodificación inicial adecuada antes de que el mensaje pueda leerse con su codificación original (por ejemplo, UTF-8).
No existe 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 no se admite BINARYMIME, 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 la RFC 2822, los nombres y valores de los campos de encabezado de mensajes que cumplen con los requisitos 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 " conjunto de caracteres ") como la codificación de transferencia de contenido utilizada para asignar los bytes del conjunto de caracteres a caracteres ASCII.
El formato es: " codificación =?de caracteres , texto codificado ".???=
Q" que denota una codificación Q similar a la codificación imprimible entre comillas , o " B" que denota una codificación base64 .Los códigos ASCII para el signo de interrogación ("?") y el signo igual ("=") no se pueden representar directamente, ya que se utilizan para delimitar la palabra codificada. El código ASCII para el espacio no se puede representar directamente porque podría provocar que los analizadores antiguos dividan la palabra codificada de forma no deseada. Para 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, lo que crea el efecto secundario de que el guión bajo no se puede representar directamente. El uso de palabras codificadas en ciertas partes de los campos de encabezado impone restricciones adicionales sobre qué caracteres se pueden representar directamente.
Por ejemplo,
Subject: =?iso-8859-1?Q?=A1Hola,_se=F1or!?=
se interpreta como "Asunto: ¡Hola, señor!".
El formato de palabras codificadas 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 están en formato ASCII en el mensaje original. Al visualizar un mensaje con un cliente de correo electrónico que no esté en inglés, es posible que el cliente traduzca los nombres de los campos de encabezado.
El mensaje multiparte MIME contiene un límite en el campo de encabezado Content-Type:; este límite, que no debe aparecer 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: multipart / mixed ; bounder = frontier Este es un mensaje con varias partes en formato MIME.--frontier Tipo de contenido: texto / sin formato Este es el cuerpo del mensaje.--frontier Tipo de contenido: aplicación / octet-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-Encodingtipo de un bloque de varias partes siempre debe ser "7 bits", "8 bits" o "binario" para evitar las complicaciones que se plantearían por los múltiples niveles de decodificación. El bloque de varias partes en su conjunto no tiene un conjunto 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 conjuntos de caracteres especificados si es apropiado para su tipo de contenido.
Notas:
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 multiparte que utilice el subtipo de resumen tendría su Content-Typeconjunto como "multiparte/digest".
En un principio, la RFC definió cuatro subtipos: mixto, de resumen, alternativo y paralelo. Una aplicación mínimamente compatible debe admitir los subtipos mixto y de resumen; los demás subtipos son opcionales. Las aplicaciones deben tratar los subtipos no reconocidos como "multiparte/mixtos". Desde entonces, se han definido por separado subtipos adicionales, como los firmados y los de datos de formulario, en otras RFC.
multipart/mixed se utiliza para enviar archivos con diferentes Content-Typecampos de encabezado en línea (o como archivos adjuntos). Si se envían imágenes u otros archivos de fácil lectura, la mayoría de los clientes de correo los mostrarán en línea (a menos que se especifique explícitamente con Content-Disposition: attached, en cuyo caso se ofrecerán como archivos adjuntos). El tipo de contenido predeterminado para cada parte es "text/plain".
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 "message/rfc822".
El tipo MIME se define en RFC 2046. [6]
El subtipo multipart/alternative indica que cada parte es una versión "alternativa" del mismo contenido (o similar), cada una en un formato diferente indicado por su encabezado "Content-Type". El orden de las partes es importante. RFC1341 establece: En general, los agentes de usuario que componen entidades multipart/alternative deben colocar las partes del cuerpo en orden creciente de preferencia, es decir, con el formato preferido al final. [7]
Los sistemas pueden entonces elegir la "mejor" representación que son capaces de procesar; en general, ésta será la última parte que el sistema pueda entender, aunque otros factores puedan afectar esto.
Dado que es poco probable que un cliente desee enviar una versión menos fiel que la versión de texto simple, esta estructura coloca la versión de texto simple (si está presente) en primer lugar. Esto facilita la vida a los usuarios de clientes que no entienden los mensajes de varias partes.
Por lo general, se utiliza multipart/alternative para correos electrónicos con dos partes, una de texto simple (text/plain) y otra HTML (text/html) . La parte de texto simple 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 una opción para que el usuario prefiera el texto simple en lugar del HTML; este es un ejemplo de cómo los factores locales pueden afectar la forma en que una aplicación elige qué parte del mensaje mostrar "mejor".
Si bien se pretende que cada parte del mensaje represente el mismo contenido, la norma no exige que esto se cumpla de ninguna manera. En un momento dado, los filtros antispam solo examinaban la parte textual/plain de un mensaje, [8] porque es más fácil de analizar que la parte textual/html. Pero los spammers finalmente se aprovecharon de esto, creando mensajes con una parte textual/plain de apariencia inocua y publicidad en la parte textual/html. El software antispam finalmente se puso al día con este truco, penalizando los mensajes con texto muy diferente en un mensaje multiparte/alternativo. [8]
El tipo se define en RFC 2046. [9]
Se utiliza un multipart/related para indicar que cada parte del mensaje es un componente de un todo agregado. Se utiliza 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 se suelen referenciar mediante Content-ID . La sintaxis de una referencia no se especifica y, en cambio, está determinada 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 partes posteriores.
El tipo se define 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 de fácil lectura) 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.
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. La parte del cuerpo completa, 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 se define en RFC 1847. [10]
Un mensaje multiparte/encriptado tiene dos partes. La primera parte tiene información de control que se necesita para desencriptar 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 utiliza con mayor frecuencia para enviar archivos con HTTP . Se especifica en RFC 7578, que reemplaza a RFC 2388.
El tipo de contenido multipart/x-mixed-replace fue desarrollado como parte de una tecnología para emular el envío y la transmisión de mensajes 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 reciben por completo. Los clientes deben procesar las partes individuales tan pronto como llegan y no deben esperar a que finalice todo el mensaje.
Originalmente desarrollado por Netscape , [12] todavía es compatible con Mozilla , Firefox , Safari y Opera . Se utiliza comúnmente en cámaras IP como el tipo MIME para transmisiones MJPEG . [13] Chrome lo admitió para los recursos principales hasta 2013 (aún se pueden mostrar imágenes utilizando este tipo de contenido). [14]
multipart/byterange se utiliza para representar rangos de bytes no contiguos de un solo mensaje, lo utiliza HTTP cuando un servidor devuelve múltiples rangos de bytes y está definido en RFC 2616.