MÍMICA

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

• mensajes de texto simples que utilizan text/plain (el valor predeterminado para "Content-Type: ")
• Texto más archivos adjuntos ( multiparte/mixto con una parte de texto/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 encabezado "Content-Disposition", de modo que el tipo de archivo se indica tanto por el tipo de contenido MIME como por la extensión del nombre de archivo (generalmente específica del sistema operativo ).
• Responder con el original adjunto ( multiparte/mixto con una parte de texto/simple y el mensaje original como parte de mensaje/rfc822 )
• contenido alternativo, como un mensaje enviado tanto en texto simple como en otro formato como HTML ( multipart/alternative con el mismo contenido en formato text/plain y text/html )
• imagen, audio, vídeo y aplicación (por ejemplo, imagen/jpeg , audio/mp3 , vídeo/mp4 , aplicación/msword , entre otros).

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:

• 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 del contenido de un archivo 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 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:

• Indica si se ha utilizado o no un esquema de codificación binario a texto sobre la codificación original, tal como se especifica en el encabezado Content-Type:

1. Si se ha utilizado algún método de codificación binario a texto, se indica cuál.
2. En caso contrario, proporciona una etiqueta descriptiva para el formato del contenido, con respecto a la presencia de contenido de 8 bits o binario.

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

• Adecuado para usar 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) que solo pueden aparecer como parte de un final de línea CRLF. Este es el valor predeterminado.
  • quoted-printable : se utiliza para codificar secuencias arbitrarias de octetos en un formato que cumpla con las reglas de 7 bits. Está diseñado para ser eficiente y legible en su mayor parte por humanos cuando se utiliza 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 arbitrarias de octetos en un formato que cumpla con las reglas de 7 bits. Diseñado para ser eficiente con datos binarios y de 8 bits que no sean texto. A veces se utiliza para datos de texto que utilizan con frecuencia caracteres que no son US-ASCII.
• Adecuado para usar con servidores SMTP que admitan 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 permitidos para aparecer como parte de un final de línea CRLF.
• Adecuado para usar con servidores SMTP que admitan la extensión SMTP BINARYMIME (RFC 3030):
  • binario – cualquier secuencia de octetos.

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 ". ???=

• El conjunto de caracteres puede ser cualquier conjunto de caracteres registrado en IANA . Normalmente, sería el mismo conjunto de caracteres que el cuerpo del mensaje.
• La codificación puede ser " Q" que denota una codificación Q similar a la codificación imprimible entre comillas , o " B" que denota una codificación base64 .
• El texto codificado es el texto codificado en Q o en base64.
• Una palabra codificada no puede tener más de 75 caracteres, incluidos charset , encoding , encoded text y 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).

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:

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

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.

• RFC 1426, Extensión del servicio SMTP para transporte MIME de 8 bits . J. Klensin , N. Freed , M. Rose , E. Stefferud y D. Crocker. Febrero de 1993.
• RFC 1847, Seguridad multipartes para MIME: multiparte/firmada y multiparte/cifrada
• RFC 3156, Seguridad MIME con OpenPGP
• RFC 2045, MIME Parte uno: Formato de los cuerpos de los mensajes de Internet
• RFC 2046, MIME Parte dos: Tipos de medios . N. Freed, Nathaniel Borenstein . Noviembre de 1996.
• RFC 2047, MIME Parte tres: extensiones de encabezado de mensaje para texto no ASCII . Keith Moore . Noviembre de 1996.
• RFC 4288, MIME Parte cuatro: Especificaciones de tipos de medios 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 Content-Disposition . Troost, R., Dorner, S. y K. Moore. Agosto de 1997.
• RFC 2231, Valores de parámetros MIME y extensiones de palabras codificadas: conjuntos de caracteres, idiomas y continuaciones . N. Freed, K. Moore. Noviembre de 1997.
• RFC 2387, El tipo de contenido relacionado/multiparte MIME
• RFC 1521, Mecanismos para especificar y describir el formato de los cuerpos de los mensajes de Internet
• RFC 7578, Devolución de valores desde formularios: multipart/form-data

• 8BITMIME
• Codificación de binario a texto
• Encapsulación directa de mensajes de Internet (DIME): un protocolo propuesto por Microsoft, ahora reemplazado , pensado como un MIME simplificado, principalmente para su uso en servicios web .
• Tipo de medio
• Vinculación e incrustación de objetos (OLE)
• S/MIME
• Protocolo simple de transferencia de correo (SMTP)
• SOAP con archivos adjuntos
• Unicode y correo electrónico
• Codificación Uuen
• VPIM

• Hughes, L (1998). Protocolos, estándares e implementación de correo electrónico en Internet . Artech House Publishers. ISBN 978-0-89006-939-4.
• Johnson, K (2000). Protocolos de correo electrónico de Internet: guía para desarrolladores . Addison-Wesley Professional. ISBN 978-0-201-43288-6.
• Loshin, P (1999). Estándares esenciales de correo electrónico: RFC y protocolos prácticos . John Wiley & Sons. ISBN 978-0-471-34597-8.
• Rhoton, J (1999). Guía del programador para correo de Internet: SMTP, POP, IMAP y LDAP . Elsevier. ISBN 978-1-55558-212-8.
• Wood, D (1999). Programación del correo electrónico en Internet . O'Reilly. ISBN 978-1-56592-479-6.

• Tipos de medios MIME: comprende una lista de directorios de tipos y subtipos de contenido, mantenida por la Autoridad de Números Asignados de Internet .
• Lista de conjuntos de caracteres
• Configuración correcta de los tipos MIME del servidor
• Una descripción fácil de seguir de los mensajes de varias partes de MH y nmh
• "Los chicos de MIME: Cómo dos gurús de Internet cambiaron el correo electrónico para siempre". 1 de febrero de 2011.
• Comprobador MIME PHP gratuito en línea
• Validador de correo electrónico MIME gratuito en línea