Extensiones multipropósito de correo de Internet (MIME) oextensiones multifunción El correo de Internetes unestándar de Internetque amplía elformatodedatosde loscorreos electrónicospara admitir texto en unacodificación de caracteresdiferenteaASCII, contenido que no es texto, contenido múltiple e información de encabezado en codificaciones que no seanASCII. Dado que los correos electrónicos generalmente se envían a través deSMTPen formato MIME, estos correos electrónicos a menudo se denominan correos electrónicosSMTP / MIME.
Originalmente, SMTP fue diseñado para transferir solo archivos de texto (codificados en ASCII ). Con la llegada de la multimedia y el uso creciente de aplicaciones ofimáticas, ha surgido la necesidad de intercambiar, además de archivos de texto, archivos binarios (formato de aplicaciones ofimáticas, imágenes, sonidos, archivos comprimidos).
Los tipos de contenido definidos por el estándar MIME se pueden utilizar para fines distintos al envío de correos electrónicos, en protocolos de comunicación como HTTP para la World Wide Web .
MIME se especifica inicialmente en cinco RFC : RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049. RFC 2045 se complementa con RFC 2077. RFC 2048 , ahora obsoleto, se reemplaza por RFC 6838 y RFC 4289.
El protocolo básico de transmisión de correo electrónico, SMTP, solo admite caracteres ASCII (que tienen una longitud de 7 bits ). Esto limita los correos electrónicos a los mensajes que solo incluyen estos caracteres, que es una pequeña cantidad de idiomas como el inglés . ASCII no admite otros idiomas basados en el alfabeto latino , incluidos los signos diacríticos , por lo que estos mensajes no se pueden representar correctamente en los correos electrónicos básicos.
MIME define mecanismos para enviar otros tipos de información, como texto que utiliza codificaciones de caracteres distintas de ASCII (y, por lo tanto, posiblemente en un idioma que no sea el inglés) o datos binarios (incluidos archivos que contienen imágenes , sonidos , películas o programas de computadora ).
MIME también es un componente fundamental de los protocolos de comunicación como HTTP , que requieren el envío de datos en el mismo contexto que el envío de correos electrónicos , Aunque esos datos no sean correos electrónicos. La integración o extracción de datos en formato MIME generalmente la realiza automáticamente el cliente de correo electrónico o el servidor de correo electrónico cuando se envía o recibe el correo electrónico.
El formato de correo electrónico básico se define en RFC 2822, que es una actualización de RFC 822. Estos estándares especifican el formato de los encabezados y el cuerpo de los correos electrónicos que contienen texto, así como encabezados generales como " To: ", " Subject: ", " From: " O " Date: " . MIME define un conjunto de encabezados adicionales para el tipo de contenido del mensaje (" Content‑Type: ") y su codificación de transferencia (" Content-Transfer-Encoding: "). La codificación de transferencia es la forma de traducir el contenido del mensaje a ASCII. Gracias a esta traducción, el contenido inicial puede contener datos arbitrarios de 8 bits (texto en UTF-8 , archivo binario, etc.). MIME también define un mecanismo para usar esta funcionalidad en los encabezados de los mensajes; esto permite, por ejemplo, acentos en el asunto de un correo electrónico o en el nombre de un destinatario.
MIME es extensible. Su definición incluye un método para registrar nuevos tipos de contenido u otros valores de atributo.
Uno de los otros propósitos explícitos de la definición de MIME es no tener que cambiar los servidores de correo preexistentes y permitir que el correo electrónico básico funcione correctamente con clientes preexistentes. Este objetivo se logra por el hecho de que los atributos de los mensajes MIME son opcionales y que el comportamiento predeterminado es la creación de un mensaje de texto sin MIME que puede ser interpretado correctamente por un cliente.
La presencia de este encabezado indica que el contenido del mensaje está formateado en MIME. El valor suele ser "1.0", por lo que el encabezado aparece como:
MIME-Version: 1.0Este encabezado indica el tipo de medio de Internet del contenido del mensaje, que consta de un tipo y un subtipo , por ejemplo:
Content-Type: text/plainMIME permite que los mensajes tengan varias partes organizadas en una estructura de árbol , utilizando un tipo " multipart " para los nodos internos.
Este mecanismo apoya en particular:
La especificación MIME ( RFC 2045 ) define un conjunto de métodos de transferencia o codificaciones (recordadas en esta lista de IANA ) para representar cualquier dato en forma de texto ASCII. El encabezado MIME " Content-Transfer-Encoding " indica el método utilizado. Puede tener uno de los valores (no susceptible de rotura ) a continuación:
No se especifica ninguna codificación para enviar datos binarios arbitrarios a través de transportes SMTP con la extensión 8BITMIME. Deben utilizarse los métodos Base64 o Quoted-Printable (con sus respectivas ineficiencias). Estas restricciones no se aplican a otros usos de MIME, como los servicios web con archivos adjuntos MIME o MTOM .
Los datos de texto (tipo " text ") se escriben en una determinada codificación de caracteres , por ejemplo latin-9 o UTF-8 . Esta codificación se puede especificar con el atributo charset= “ Content-Type: ” del encabezado “ ”. Esto puede tomar cualquier valor definido por IANA . Por ejemplo :
Content-Type: text/plain; charset=utf-8Esta codificación no debe confundirse con la codificación de transferencia , especificada por el encabezado " Content-Transfer-Encoding: ". En el caso del contenido textual, las dos codificaciones se aplican sucesivamente. Por ejemplo :
Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ceci est un message encod=C3=A9 en UTF-8, puis transform=C3=A9 en ASCII par la m=C3=A9thode "Quoted-Printable".En este ejemplo, la letra "é" está codificada en UTF-8 por dos bytes de valores hexadecimales C3 y A9, que a su vez están codificados en Quoted-Printable por la secuencia " =C3=A9 ".
A partir de RFC 2822 , los nombres de los encabezados de los mensajes y sus valores siempre están en caracteres ASCII. Los valores que contienen datos que no son ASCII deben utilizar la sintaxis de " palabra codificada " de MIME ( RFC 2047 ) en lugar de los valores de texto estándar. Esta sintaxis usa cadenas de caracteres ASCII para especificar la codificación original del texto (equivalente al atributo de charset=encabezado Content-Type:) y la codificación de transferencia (equivalente al encabezado Content-Transfer-Encoding:).
La sintaxis es:
=?encodage?méthode?texte?=Los códigos ASCII para el signo de interrogación ( ?) y el signo igual ( =) no deben representarse directamente, ya que se utilizan para delimitar palabras codificadas. El código ASCII para el carácter de espacio tampoco debe usarse, ya que puede causar errores en codificadores más antiguos, como una separación de palabras no deseada. Para hacer la codificación más ligera y más fácil de leer, el carácter de subrayado (" _ ") se utiliza para representar el espacio. Por lo tanto, el carácter de subrayado ya no se puede representar directamente. El uso de palabras codificadas en determinadas partes de los encabezados impone restricciones a los caracteres que se van a representar directamente.
Por ejemplo,
Subject: =?utf-8?Q?=C2=A1Hola,_se=C3=B1or!?=se interpreta como:
Asunto: ¡Hola, señor!El formato de palabra codificada no se utiliza para los nombres de los encabezados (por ejemplo, " Subject: "). Estos nombres de encabezados siempre están en inglés en el mensaje. Cuando el mensaje se ve en un cliente de correo electrónico que no habla inglés, el cliente puede traducir los nombres de los encabezados.
Un mensaje MIME de varias partes especifica una línea de separación en el encabezado " Content-type: ", a través del atributo " boundary= ". Esta separación, que no debería aparecer en ningún otro lugar, se coloca entre las partes y al principio y al final del cuerpo del mensaje de la siguiente manera:
Content-type: multipart/mixed; boundary="''frontière''" MIME-version: 1.0 This is a multi-part message in MIME format. --''frontière'' Content-type: text/plain This is the body of the message. --''frontière'' Content-type: application/octet-stream Content-transfer-encoding: base64 PGh0bWw+CiAgPGhlYWQ+CiAgPC9oZWFkPgogIDxib2R5PgogICAgPHA+VGhpcyBpcyB0aGUg Ym9keSBvZiB0aGUgbWVzc2FnZS48L3A+CiAgPC9ib2R5Pgo8L2h0bWw+Cg== --''frontière''--Cada una de estas partes consta de su propio encabezado de contenido (cero, uno o más campos de encabezado Content-*:) y un cuerpo. Se pueden incluir varias partes en otras partes múltiples, cada una con su propio límite. El campo Content-Transfer-Encoding:de un tipo multiparte debe ser " 7bit ", " 8bit " o " binary " para evitar problemas al decodificar diferentes capas de multiparte. El bloque de varias partes no tiene un juego de caracteres, los caracteres que no son ASCII en los encabezados son procesados por el sistema de palabras codificadas y los cuerpos pueden tener un juego de caracteres específico apropiado para su contenido.
Notas:
El estándar MIME define varios subtipos de mensajes multiparte para especificar la naturaleza de las diferentes partes del mensaje y sus relaciones con otras partes. El subtipo se especifica mediante el encabezado " Content-type: " del mensaje adjunto. Por ejemplo, un mensaje MIME de varias partes que usa el subtipo " digest " debe tener su encabezado " Content-Type: " a " multipart/digest ". El RFC Define inicialmente cuatro subtipos: " mixed ", " alternate ", " digest " y " parallel ". Una aplicación debe admitir al menos los subtipos “ mixed ” y “ digest ”, los demás son opcionales. Se han definido subtipos adicionales como " signed " o " form-data" en otras RFC .
Se utilizan principalmente los siguientes subtipos:
mixedEl tipo " multipart/mixed " (definido en RFC2046, Sección 5.1.3 ) se utiliza para enviar archivos con diferentes " Content-type: " encabezados (como archivos adjuntos). Si los archivos son fácilmente legibles o son imágenes, la mayoría de los clientes de correo electrónico muestran estos archivos directamente en el contenido del mensaje (a menos que un encabezado " Content-disposition: " especifique lo contrario). De lo contrario, los archivos se ven como archivos adjuntos. El tipo de contenido predeterminado para estas partes es " text/plain ".
La RFC también especifica que todos los subtipos de " multipart " no reconocidos por una implementación deben tratarse de la misma manera que " multipart/mixed ".
digestEl tipo " multipart/digest " (definido en RFC2046, Sección 5.1.5 ) es la forma sencilla de enviar varios mensajes de texto. El tipo de contenido predeterminado es " message/rfc822 ".
alternativeEl tipo " multipart/alternative " (definido en RFC2046, Sección 5.1.4 ) indica que cada parte es una versión alternativa del mismo contenido en un formato diferente. Los formatos están ordenados en orden ascendente de fidelidad al contenido original. El receptor puede así elegir la mejor representación que es capaz de procesar, en general, la última de la lista.
Dado que un cliente generalmente no desea enviar contenido menos significativo que el texto sin formato, esto se envía primero, lo que simplifica el procesamiento para los clientes que no entienden el tipo " multipart " ya que esta es la parte visible del texto .
El uso principal del tipo " multipart/alternative " es enviar correos electrónicos en formato HTML con su equivalente en formato de texto para mantener la legibilidad del mensaje para un cliente de correo electrónico que no puede mostrar HTML (cliente de texto).
Aunque se supone que cada parte de la publicación representa el mismo contenido, no hay garantía. Por ejemplo, es más fácil para un filtro de spam escanear la parte de texto sin formato de un mensaje en lugar de la parte HTML; mientras que el editor de spam, en cambio, construirá un mensaje HTML con su contenido publicitario y un mensaje de texto sin formato que sea inofensivo o no relacionado con su publicidad.
El tipo " multipart/related " (definido en RFC2387 ) se utiliza para especificar que las diferentes partes no deben tratarse individualmente sino como un todo. El mensaje consta de una parte raíz (la primera, de forma predeterminada) que hace referencia a otras partes, que también pueden hacer referencia a otras partes. A menudo se hace referencia a partes de los mensajes por su identificador de contenido (encabezado " Content-ID: "). No se especifica la sintaxis de las referencias, se deja a la intención del protocolo utilizado.
Uno de los usos habituales de este subtipo es enviar una página web con sus imágenes en un solo mensaje. La parte raíz contiene el documento HTML y las imágenes se almacenan en las siguientes partes.
reportEl tipo " multipart/report " (definido en RFC3462 ) representa un mensaje que contiene datos formateados para ser leídos por un servidor de correo electrónico. Contiene una parte de tipo " text/plain " (u otro contenido de fácil lectura) y otra de tipo " message/delivery-status " que contiene los datos formateados para el servidor de correo.
signedEl tipo " multipart/signed " (definido en RFC1847, Sección 2.1 ) se utiliza para adjuntar una firma digital a un mensaje. Se compone de dos partes: el cuerpo del mensaje y la firma. Toda la parte del cuerpo del mensaje, incluidos los encabezados MIME, se utiliza para generar la firma. Son posibles diferentes tipos de firmas como " application/pgp-signature " o " application/x-pkcs7-signature ".
encryptedEl tipo " multipart/encrypted " (definido en RFC1847, Sección 2.2 ) se utiliza para enviar contenido cifrado . Su primera parte define la información necesaria para descifrar su segunda parte (de tipo " application/octet-stream ").
form-dataEl tipo " multipart/form-data " (definido en RFC2388 ) se utiliza para enviar datos desde un formulario. Originalmente definido como parte de HTML 4.0 , se usa más comúnmente para enviar archivos a través de HTTP .