Multipurpose Internet Mail Extensions

Multipurpose Internet Mail Extensions o MIME (en español "extensiones multipropósito de correo de internet") son una serie de convenciones o especificaciones dirigidas al intercambio a través de Internet de todo tipo de archivos (texto, audio, vídeo, etc.) de forma transparente para el usuario. Una parte importante del MIME está dedicada a mejorar las posibilidades de transferencia de texto en distintos idiomas y alfabetos. En sentido general las extensiones de MIME van encaminadas a admitir:

• Texto en conjuntos de caracteres distintos de US-ASCII;
• adjuntos que no son de tipo texto;
• cuerpos de mensajes con múltiples partes (multi-part);
• información de encabezados con conjuntos de caracteres distintos de ASCII.

Prácticamente todos los mensajes de correo electrónico escritos por personas en Internet y una proporción considerable de estos mensajes generados automáticamente son transmitidos en formato MIME a través de SMTP. Los mensajes de correo electrónico en Internet están tan cercanamente asociados con el SMTP y MIME que usualmente se les llama mensaje SMTP/MIME.^[1]​

En 1991 la IETF comenzó a desarrollar esta norma y desde 1994 todas las extensiones MIME están especificadas de forma detallada en diversos documentos oficiales disponibles en Internet.

MIME está especificado en seis solicitudes de comentarios (RFC): RFC 2045, RFC 2046, RFC 2047, RFC 2077, RFC 4288 y RFC 4289.

Los tipos de contenido definidos por el estándar MIME tienen gran importancia también fuera del contexto de los mensajes electrónicos. Ejemplo de esto son algunos protocolos de red tales como HTTP de la Web. HTTP requiere que los datos sean transmitidos en un contexto de mensajes tipo correo electrónico aunque los datos pueden no ser un mensaje de correo electrónico propiamente dicho.

En la actualidad ningún programa de correo electrónico o navegador de Internet puede considerarse completo si no acepta MIME en sus diferentes facetas (texto y formatos de archivo).

El protocolo básico de transmisión de mensajes electrónicos de Internet soporta solo caracteres ASCII de 7 bit (véase también 8BITMIME). Esto limita los mensajes de correo electrónico, ya que incluyen solo caracteres suficientes para escribir en un número reducido de lenguajes, principalmente Inglés. Otros lenguajes basados en el Alfabeto latino es adicionalmente un componente fundamental en protocolos de comunicación como HTTP, el que requiere que los datos sean transmitidos como un mensaje de correo electrónico aunque los datos pueden no ser un mensaje de correo electrónico propiamente dicho. Los clientes de correo y los servidores de correo convierten automáticamente desde y a formato MIME cuando envían o reciben (SMTP/MIME) correos electrónicos.

MIME asigna un nombre a cada tipo de datos. Los nombres siguen el siguiente formato:

tipo/subtipo (tipo como subtipo son cadenas de caracteres)

El tipo define la categoría general de los datos y el subtipo define un tipo más específico de esos datos. El tipo puede contener los siguientes valores:

• text: Indica que el contenido es texto plano. Ejemplos de subtipos: html, xml
• multipart: Indica que tiene múltiples partes de datos independientes. Ejemplos de subtipos: form-data, digest
• message: Para encapsular un mensaje existente. Por ejemplo cuando queremos responder a un mensaje de correo incorporando el mensaje origen. Ejemplos de subtipos: partial, rfc822
• image: Indica que es una imagen. Ej de subtipos: png, gif
• audio: Indica que es un audio. Ejemplos de subtipos: mp3, 32kadpcm
• video: Indica que es un video. Ejemplos de subtipos: mpeg, avi
• application: Indica que se trata de datos de aplicación los cuales pueden ser binarios. Ejemplos de subtipos: json, pdf

La presencia de este encabezado indica que el mensaje utiliza el formato MIME. Su valor es típicamente igual a "1.0" por lo que este encabezado aparece como: MIME-Version: 1.0.

Debe señalarse que los implementadores han intentado cambiar el número de versión en el pasado y el cambio ha tenido resultados imprevistos. En una reunión de IETF realizada en julio de 2007 se decidió mantener el número de versión en "1.0" aunque se han realizado muchas actualizaciones a la versión de MIME.

Este encabezado indica el tipo de medio que representa el contenido del mensaje, consiste en un tipo: type y un subtipo: subtype, por ejemplo:

Content-Type: text/plain

A través del uso del tipo multiparte (multipart), MIME da la posibilidad de crear mensajes que tengan partes y subpartes organizadas en una estructura arbórea en la que los nodos hoja pueden ser cualquier tipo de contenido no multiparte y los nodos que no son hojas pueden ser de cualquiera de las variedades de tipos multiparte. Este mecanismo soporta:

• mensajes de texto plano usando text/plain (este es el valor implícito para el encabezado "Content-type:")
• texto más archivos adjuntos (multipart/mixed con una parte text/plain y otras partes que no son de texto, por ejemplo: application/pdf para documentos pdf, application/vnd.oasis.opendocument.text para OpenDocument text). Un mensaje MIME que incluye un archivo adjunto generalmente indica el nombre original del archivo con un encabezado "Content-disposition:" o por un atributo name de Content-Type, por lo que el tipo o formato del archivo se indica usando tanto el encabezado MIME content-type y la extensión del archivo (usualmente dependiente del SO).

Content-Type: application/vnd.oasis.opendocument.text;
    name="Carta.odt"
Content-Disposition: inline;
    filename="Carta.odt"

• reenviar con el mensaje original adjunto (multipart/mixed con una parte text/plain y el mensaje original como una parte message/rfc822)
• contenido alternativo, un mensaje que contiene el texto tanto en texto plano como en otro formato, usualmente HTML (multipart/alternative con el mismo contenido en forma de text/plain y text/html)
• muchas otras construcciones de mensaje

En junio de 1992, MIME (RFC 1341 queda obsoleta por la nueva RFC 2045) define un conjunto de métodos para representar datos binarios usando texto ASCII. El encabezado MIME content-transfer-encoding: indica el método que ha sido usado. La RFC y la lista de IANA definen los siguientes valores, que no son sensibles a mayúsculas ni minúsculas:

• Adecuados para usar con SMTP:
  • 7bit — soporta hasta 998 octetos por línea de código; los caracteres están en el rango entre 1..127 con CR y LF (códigos 13 y 10 respectivamente) que solo pueden aparecer como parte de un fin de línea CRLF. Este es el valor implícito para este encabezado.
  • Quoted printable — usado para codificar secuencias arbitrarias de octetos de forma que satisfaga las reglas de 7bit. Fue diseñado para ser eficiente y en la mayoría de los casos legible para un humano cuando es usado con datos de texto que consisten primariamente en caracteres del conjunto US-ASCII y que también contengan porciones de bytes con valores que están fuera de ese rango.
  • base64 — usado para codificar secuencias arbitrarias de octetos de forma que satisfaga las reglas de 7bit. Tiene una sobrecarga fija al ejecutar el algoritmo y tiene el propósito de ser usado con datos que no sean de texto o textos que contengan pocos valores dentro del rango de ASCII.
• Adecuado para usar con servidores SMTP que soporten 8BITMIME extensiones SMTP:
  • 8bit — soporta hasta 998 octetos por línea de código, los caracteres están en el rango entre 1..256 con CR y LF (códigos 13 y 10 respectivamente) que solo pueden aparecer como parte de un fin de línea CRLF.
• Adecuados solo para usar con servidores SMTP que soporten la extensión SMTP BINARYMIME (RFC 3030):
  • binary — cualquier secuencia de octetos.

No existe una codificación definida explícitamente para enviar datos binarios arbitrarios a través de un transporte SMTP con las extensiones 8BITMIME. Por tanto base64 o quoted-printable (con sus ineficiencias asociadas) tienen que ser usadas aún. Estas restricciones no se aplican a otros usos de MIME como son Servicios Web con adjuntos MIME o MTOM

Desde la RFC 2822, los nombres y valores de los encabezados MIME de mensajes son siempre caracteres ASCII; los valores que contengan otro tipo de caracteres tienen que usar la sintaxis de palabra codificada o encoded-word (RFC 2047) en lugar del texto literal. Esta sintaxis utiliza una cadena de caracteres ASCII que indica el conjunto de caracteres original (el "charset") y el content-transfer-encoding usado para mapear los bytes del conjunto original a caracteres ASCII.

Su forma general es:

   =?charset?codificación?texto codificado?=

• charset puede ser cualquier conjunto de caracteres registrado con IANA. Típicamente coincidirá con el charset del cuerpo del mensaje.
• codificación puede ser: "Q" que denota Q-encoding que es similar a la codificación quoted-printable, o "B" que denota la codificación base64.
• texto codificado es el texto codificado con Q-encoding o base64.

Los códigos ASCII del signo de pregunta (?) y el signo de igualdad (=) no pueden ser representados directamente dado que ellos son usados como delimitadores del encoded-word. El código ASCII reservado para el espacio no puede ser representado directamente porque puede ocasionar que intérpretes antiguos dividan, de forma no deseada, el encoded-word. Para hacer la codificación más pequeña y fácil de leer, el símbolo subrayado (_) se utiliza en lugar del espacio, creando el efecto colateral que este símbolo no se pueda representar directamente. El uso de encoded-word en ciertas partes de los encabezados impone otras restricciones sobre cuáles caracteres pueden o no ser representados directamente.

Por ejemplo:

   Subject: =?utf-8?Q?=C2=A1Hola,_se=C3=B1or!?=

es interpretado como:

   Subject: ¡Hola, señor!

El formato encoded-word no se utiliza para los nombres de los encabezados (por ejemplo Subject). Estos nombres de encabezados son siempre en inglés. Cuando se lee el mensaje con un cliente de correo en otro idioma que no sea Inglés, los nombres de los encabezados son traducidos por el cliente.

Un mensaje MIME multiparte contiene una frontera en el encabezado "Content-type:"; esta frontera, que no puede aparecer en ninguna de las partes, es ubicada entre cada una de ellas, y al inicio y al final del cuerpo del mensaje, como se muestra a continuación:

MIME-Versión: 1.0
Content-type: multipart/mixed; boundary="frontera"

This is a multi-part message in MIME format.
--frontera
Content-type: text/plain

Este es el cuerpo del mensaje
--frontera
Content-type: application/octet-stream
Content-transfer-encoding: base64

PGh0bWw+CiAgPGhlYWQ+CiAgPC9oZWFkPgogIDxib2R5PgogICAgPHA+RXN0ZSBlcyBlbCBjdWVy
cG8gZGVsIG1lbnNhamU8L3A+CiAgPC9ib2R5Pgo8L2h0bWw+Cic=\
--frontera--

Cada parte consiste de su propio encabezado de contenido (cero o más campos de encabezados Content-) y un cuerpo. El contenido multiparte puede estar anidado. El encabezado content-transfer-encoding de un tipo multiparte tiene siempre que ser "7bit", "8bit" o "binary" para evitar las complicaciones impuestas con la presencia de múltiples niveles de decodificación. El bloque multiparte, como un todo, no tiene especificación acerca del conjunto de caracteres (charset); los caracteres no ASCII en los encabezados de la parte son manejados a través de Encoded-Word, y los cuerpos de las partes pueden tener conjuntos de caracteres especificados si aplicase para su tipo de contenido.

Notas:

• Antes de la primera frontera hay un área que es ignorada por clientes de correo electrónico que soportan MIME. Esta área es generalmente usada para poner un mensaje para usuarios de clientes viejos que no soporten MIME.
• No es hasta el momento de enviar el mensaje que el cliente de correo escoge una cadena de caracteres para usar en la frontera entre las partes, esto permite buscar una cadena de texto que no coincida con ninguna porción del cuerpo de ninguna de las partes. Esto típicamente es implementado usando una cadena larga generada aleatoriamente.

El estándar MIME define varios subtipos para mensajes multiparte, estos especifican la naturaleza de la parte del mensaje y su relación con otras partes. El subtipo es especificado en el encabezado "Content-type" para todo el mensaje. Por ejemplo, un mensaje MIME multiparte que usa el subtipo digest tendrá un "Content-Type": "multipart/digest".

La RFC inicialmente define 4 subtipos: mixed, digest, alternate y parallel. Una aplicación que cumpla mínimamente el estándar debe soportar al menos mixed y digest; el resto de los subtipos son opcionales. Otras RFCs definen subtipos adicionales como: signed y form-data.

Lo que sigue es una lista de los subtipos más comúnmente usados:

Multipart/mixed es usado para enviar mensajes o archivos con diferentes encabezados "Content-Type" ya sea en línea o como adjuntos. Si se envían imágenes u otros archivos fácilmente legibles, la mayoría de los clientes de correo electrónico las mostrarán como parte del mensaje (a menos que se especifique de manera diferente el encabezado "Content-disposition"). De otra manera serán ofrecidos como adjuntos. El content-type implícito para cada parte es "text/plain".

Definido en RFC 2046, Sección 5.1.3

Una parte message/rfc822 contiene un mensaje de correo electrónico, incluyendo cualquier encabezado. Rfc822 es un nombre erróneo, dado que el mensaje puede ser un mensaje MIME completo. Es usado también para resúmenes el reenviar mensajes.

Definido en la RFC 2046.

Multipart/digest es una forma simple de enviar múltiples mensajes de texto. El content-type implícito para cada parte es "message/rfc822".

Definido en RFC 2046, Sección 5.1.5.

El subtipo multipart/alternative indica que cada parte es una versión "alternativa" del mismo contenido (o similar), cada una en formatos diferentes denotados por su encabezado "Content-Type". Los formatos son ordenados atendiendo a cuan fieles son al original, con el menos fiel al inicio. Los sistemas pueden escoger la "mejor" representación que ellos son capaces de procesar; en general esta será la última parte que el sistema entiende, a menos que otros factores puedan afectar este comportamiento.

Dado que es poco probable que un cliente quiera enviar una versión que es poco fiel a la versión en texto plano, esta estructura ubica la versión en texto plano (si existe) primero. Esto facilita la tarea de leer los mensajes para los usuarios de clientes que no entienden mensajes multipartes.

Lo que ocurre más comúnmente es usar multipart/alternative para mensajes con dos partes, una como texto plano (text/plain) y una HTML (text/html). La parte en texto plano provee compatibilidad con clientes viejos que no son capaces de entender otros formatos, mientras que la parte HTML permite usar formato de texto y enlaces. Muchos clientes de correo ofrecen al usuario la posibilidad de preferir texto plano sobre HTML; esto es un ejemplo de como factores locales pueden afectar cómo una aplicación selecciona cuál es la "mejor" parte del mensaje para mostrar.

Aunque se pretende que cada parte represente el mismo contenido, esto no es requerido. Algunos filtros antispam examinan únicamente la parte text/plain de un mensaje porque es más fácil de analizar que las partes text/html. Pero los spammers al notar esto, comenzaron a crear mensajes con una parte text/plain que aparenta ser inocua e incluyen la propaganda en la parte text/html. Los mantenedores de programas antispam han modificado sus filtros, penalizando a los mensajes con textos muy diferentes en un mensaje multipart/alternative.

Definido en RFC 2046, Sección 5.1.4

El subtipo multipart/related es usado para indicar que las partes del mensaje no deben ser consideradas individualmente sino como agregados de un todo. El mensaje consiste de una parte raíz (implícitamente la primera) que hace referencia a otras partes, las que a su vez pueden hacer referencia a otras partes. Las partes son comúnmente referenciadas por el encabezado: "Content-ID". La sintaxis de la referencia no está especificada sino que está dictada por la codificación o el protocolo usado en la parte que contiene la referencia.

Un uso común de este subtipo es para enviar páginas web completas con imágenes en un único mensaje. La parte raíz contendría el documento HTML, que usaría etiquetas HTML para imágenes, para referirse a las imágenes almacenadas en partes subsiguientes.

Definido en RFC 2387

Multipart/report es un tipo de mensaje que contiene datos formateados para que un servidor de correo lo intérprete. Está entre un text/plain (o algún otro tipo de contenido fácilmente legible) y un message/delivery-status.

Definido en RFC 3462

El subtipo multipart/signed es usado para adjuntar una firma digital al mensaje. Esta tiene dos partes, una parte cuerpo y una parte firma. La parte del cuerpo completa, incluyendo los encabezados MIME, es usada para crear la parte de la firma. Existen muchos tipos de firmas, como application/pgp-signature y application/x-pkcs7-signature.

Definido en RFC 1847, Sección 2.1

Un mensaje multipart/encrypted tiene dos partes. La primera contiene información de control que es necesaria para descifrar la segunda parte, de tipo: application/octet-stream.

Definido en RFC 1847, Sección 2.2

Como su nombre lo indica, multipart/form-data es usada para expresar valores enviados a través de un formulario. Originalmente definido como parte de HTML 4.0, es mayormente utilizado para enviar archivos vía HTTP.

Definido en RFC 2388

El tipo de contenido multipart/x-mixed-replace fue desarrollado como parte de una tecnología para emular server push y streaming sobre HTTP.

Todas las partes de un mensaje mixed-replace poseen el mismo significado semántico. Sin embargo, cada parte invalida - "reemplaza" - a la parte previa tan pronto como es recibida completamente. Los clientes deben procesar la parte individual al momento de su llegada y no deben esperar a que termine el mensaje completo.

Desarrollado originalmente por Netscape, aún es soportado por Mozilla, Firefox, Safari (pero no en Safari para iPhone) y Opera, pero tradicionalmente ignorada por Microsoft.

• S/MIME
• Correo electrónico y unicode
• Correo electrónico
• SMTP
• POP3
• IMAP

RFC 1847

Multiparte Seguro para MIME: Multipart/Signed y Multipart/Encrypted

RFC 2045

MIME Parte Uno: Formato y Cuerpo de Mensajes de Internet.

RFC 2046

MIME Parte Dos: Tipos de Medios. N. Freed, Nathaniel Borenstein, noviembre 1996.

RFC 2047

MIME Parte Tres: Extensiones para Encabezados de Mensaje para texto no ASCII. Keith Moore. Noviembre 1996.

RFC 4288

MIME Parte Cuatro: Especificación de Tipos de Medios y Procedimientos de Registro de los mismos.

RFC 4289

MIME Parte Cuatro: Procedimientos de Registro. N. Freed, J. Klensin. December 2005.

RFC 2049

MIME Parte Cinco: Criterio de Conformidad y Ejemplos. N. Freed, N. Borenstein. Noviembre 1996.

RFC 2231

Valores de Parámetros MIME y Extensiones Encoded Word : Conjuntos de Caracteres, Lenguajes, y Continuaciones. N. Freed, K. Moore. Noviembre 1997.

RFC 2387

El Content-type MIME Multipart/Related

RFC 1521

Mecanismos para Especificar y Describir el Formato de los Cuerpos de los Mensajes de Internet.

• Listado de tipos MIME
• Listado de tipos MIME registrados por IANA
• Referencia de MIME en w3schools