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.
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).
Introducción 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.
Nomenclatura de tipos 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
MIME headers MIME-Version 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.
Content-Type 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
Content-Transfer-Encoding 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
Encoded-Word 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.
Diferencias entre Q-encoding y quoted-printable
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.
Mensajes multiparte 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.