Hispanopedia WikiMIME ( 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, vídeo, imágenes y programas de aplicación. El cuerpo de los mensajes puede constar de varias partes y la información de la cabecera puede especificarse en conjuntos de caracteres no ASCII. Los mensajes de correo electrónico con formato MIME se transmiten normalmente mediante protocolos estándar, como el Protocolo simple de transferencia de correo (SMTP), el Protocolo de oficina de correos (POP) y el Protocolo de acceso a mensajes de Internet (IMAP).
MIME es un estándar de Internet , especificado en las siguientes publicaciones de solicitud de comentarios (RFC): 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 se diseñó 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 inicio de cualquier transmisión web. Los clientes utilizan el encabezado de tipo de contenido para seleccionar una aplicación de visualización adecuada para el tipo de datos indicado.
Historia
MIME se originó a partir del Andrew Messaging System, que formaba parte del Andrew Project desarrollado en la Universidad Carnegie Mellon (CMU), como una alternativa multiplataforma al formato de datos específico de Andrew. [ 1 ]
campos de encabezado MIME
Versión MIME
La presencia de este campo de encabezado indica que el mensaje tiene formato MIME. Su valor suele ser "1.0". El campo aparece de la siguiente manera:
Versión MIME: 1.0
Según Nathaniel Borenstein , cocreador de MIME , 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 dificultaron la implementación de esta característica:
No especificamos adecuadamente cómo manejar una futura versión MIME. ... Entonces, si escribes algo que conoce la versión 1.0, ¿qué debes hacer si te encuentras con la 2.0 o la 1.1? Pensé que era obvio, pero resultó que cada uno lo implementó de manera diferente. Y el resultado es que sería prácticamente imposible que Internet definiera alguna vez una versión 2.0 o una 1.1. [ 2 ]
Disposición del contenido
Las especificaciones MIME originales solo describían la estructura de los mensajes de correo. No abordaban el tema 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 del 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 el agente de usuario de correo del lector puede utilizar para almacenar el archivo adjunto.
El siguiente ejemplo está tomado de RFC 2183, donde se define el campo de encabezado:
Content-Disposition: attachment; filename=genome.jpeg; fecha-de-modificación="Mié, 12 Feb 1997 16:29:51 -0500";
El nombre del archivo puede estar codificado según lo definido en RFC 2231.
En 2010, la mayoría de los clientes de correo electrónico no seguían esta recomendació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, antes de la versión 3, también envía mensajes recién redactados con content-disposition en línea para todas las partes MIME. La mayoría de los usuarios desconocen cómo configurar content-disposition como attachment . [ 3 ] Muchos clientes de correo electrónico también envían mensajes con el nombre del 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 del 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: attachment se usa generalmente para indicar al cliente que presente el cuerpo de la respuesta como un archivo descargable. Normalmente, al recibir dicha respuesta, un navegador web solicita al usuario que guarde el contenido como un archivo, en lugar de mostrarlo como una página en una ventana del navegador, con el nombre de archivo sugerido por defecto.
Codificación de transferencia de contenido
En junio de 1992, MIME (RFC 1341, posteriormente obsoleto por RFC 2045) definió un conjunto de métodos para representar datos binarios en formatos distintos al formato de texto ASCII. El campo de encabezado MIME content-transfer-encoding: tiene un significado bidireccional:
- Indica si se ha utilizado o no un esquema de codificación de binario a texto además de la codificación original especificada en el encabezado Content-Type:
- Si se ha utilizado algún método de codificación de binario a texto, se indica cuál.
- En caso contrario, proporciona una etiqueta descriptiva para el formato del contenido, con respecto a la presencia de contenido binario o de 8 bits.
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 binaria a texto además de la codificación original. En estos casos, el campo de encabezado es redundante para que el cliente de correo electrónico decodifique el cuerpo del mensaje, pero aún puede ser útil como indicador del tipo de objeto que 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 binaria 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 su uso con SMTP normal:
- 7 bits : hasta 998 octetos por línea del rango de código 1..127, con CR y LF (códigos 13 y 10 respectivamente) permitidos únicamente como parte de un final de línea CRLF. Este es el valor predeterminado.
- quoted-printable : se utiliza para codificar secuencias de octetos arbitrarias en un formato que cumple con las reglas de 7 bits. Está diseñado para ser eficiente y, en su mayor parte, legible para 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 de octetos arbitrarias en un formato que cumple con las reglas de 7 bits. Está diseñado para ser eficiente con datos binarios y de 8 bits que no son texto. A veces se utiliza para datos de texto que frecuentemente usan caracteres que no son US-ASCII.
- Adecuado para su uso con servidores SMTP que admiten 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) que solo pueden aparecer como parte de un final de línea CRLF.
- Adecuado para su uso con servidores SMTP que admiten la extensión SMTP BINARYMIME (RFC 3030):
- binario – cualquier secuencia de octetos.
No existe ninguna codificación definida específicamente para enviar datos binarios arbitrarios mediante protocolos SMTP con la extensión 8BITMIME. Por lo tanto, si BINARYMIME no es compatible, base64 o quoted-printable (con su consiguiente ineficiencia) pueden resultar útiles en ocasiones. Esta restricción no se aplica a otros usos de MIME, como los servicios web con archivos adjuntos MIME o MTOM .
Palabra codificada
Desde la RFC 2822, los nombres y valores de los campos de encabezado de mensaje que cumplen con la norma utilizan caracteres ASCII; los valores que contienen datos que no son ASCII deben usar la sintaxis de palabra codificada 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 conjunto 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 la codificación Q que es similar a la codificación quoted-printable , o "B" que denota la 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, incluyendo el conjunto de caracteres , la codificación , el texto codificado y los delimitadores. Si se desea codificar más texto del que cabe en una palabra codificada de 75 caracteres, se pueden usar varias palabras codificadas (separadas por CRLF y espacio).
Diferencia entre codificación Q y quoted-printable
Los códigos ASCII para el signo de interrogación ("?") y el signo de igual ("=") no se pueden representar directamente, ya que se utilizan para delimitar la palabra codificada. El código ASCII para el espacio tampoco se puede representar directamente porque podría provocar que los analizadores sintácticos antiguos dividan la palabra codificada de forma indeseada. Para que la codificación sea más pequeña y fácil de leer, se utiliza el guion bajo para representar el código ASCII del espacio, lo que tiene como efecto secundario que el guion bajo no se pueda 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 palabra codificada 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 aparecen en 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.
Mensajes multipartes
El mensaje multipart 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 ; boundary = frontier Este es un mensaje con varias partes en formato MIME. --frontier Content-Type: text / plain Este es el cuerpo del mensaje. --frontier Content-Type: application / octet-stream Content-Transfer-Encoding: base64PGh0bWw+CiAgPGhlYWQ+CiAgPC9oZWFkPgogIDxib2R5PgogICAgPHA+VGhpcyBpcyB0aGUg Ym9keSBvZiB0aGUgbWVzc2FnZS48L3A+CiAgPC9ib2R5Pgo8L2h0bWw+Cg== --frontera--Cada parte consta de su propio encabezado (cero o más Content-campos de encabezado) y un cuerpo. El contenido multiparte puede estar anidado. El Content-Transfer-Encodingtipo de un bloque multiparte siempre debe ser "7bit", "8bit" o "binario" para evitar las complicaciones que supondrían los múltiples niveles de decodificación. El bloque multiparte en su conjunto no tiene un conjunto de caracteres; los caracteres no ASCII en los encabezados de las partes se gestionan mediante el sistema de palabras codificadas , y los cuerpos de las partes pueden tener conjuntos de caracteres especificados si son apropiados para su tipo de contenido.
Notas:
- Antes del primer límite hay un área que los clientes compatibles con MIME ignoran. Esta área se usa generalmente para mostrar un mensaje a los usuarios de clientes antiguos que no son compatibles con MIME.
- Es responsabilidad del cliente de correo remitente elegir una cadena de delimitación que no entre en conflicto con el cuerpo del mensaje. Normalmente, esto se logra insertando una cadena aleatoria larga.
- El último límite debe tener dos guiones al final.
subtipos multiparte
El estándar MIME define varios subtipos de mensajes multipartes, 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 completo. Por ejemplo, un mensaje MIME multipartes que utilice el subtipo digest se definiría Content-Typecomo "multipart/digest".
Inicialmente, la RFC definió cuatro subtipos: mixto, resumen, alternativo y paralelo. Una aplicación que cumpla con los requisitos mínimos debe admitir los subtipos mixto y resumen; los demás subtipos son opcionales. Las aplicaciones deben tratar los subtipos no reconocidos como "multipart/mixed". Posteriormente, se han definido subtipos adicionales, como signed y form-data, en otras RFC.
mezclado
El formato 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: attachment, en cuyo caso se ofrecerán como archivos adjuntos). El tipo de contenido predeterminado para cada parte es "text/plain".
El tipo está definido en RFC 2046. [ 5 ]
digerir
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 ]
alternativa
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 sean capaces de procesar; en general, esta será la última parte que el sistema pueda comprender, aunque otros factores pueden influir en ello.
Dado que es improbable que un cliente desee enviar una versión menos fiel que la versión en texto plano, esta estructura coloca la versión en texto plano (si está presente) en primer lugar. Esto facilita la vida a los usuarios de clientes que no entienden los mensajes multipartes.
Generalmente, el formato multipart/alternative se utiliza para correos electrónicos con dos partes: una de texto sin formato (text/plain) y otra en HTML (text/html) . La parte de texto sin formato garantiza la 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 al usuario la opción de priorizar el texto sin formato sobre el HTML; este es un ejemplo de cómo los factores locales pueden influir en la forma en que una aplicación elige qué parte del mensaje mostrar.
Aunque se pretende que cada parte del mensaje represente el mismo contenido, el estándar no exige que esto se aplique de ninguna manera. En el pasado, los filtros antispam solo examinaban la parte text/plain de un mensaje, [ 8 ] porque es más fácil de analizar que la parte text/html. Pero los spammers se aprovecharon de esto, creando mensajes con una parte text/plain de apariencia inofensiva y publicitando en la parte text/html. El software antispam finalmente detectó este truco, penalizando los mensajes con texto muy diferente en un mensaje multipart/alternative. [ 8 ]
El tipo se define en RFC 2046. [ 9 ]
relacionado
Se utiliza la etiqueta multipart/related para indicar que cada parte del mensaje es un componente de un todo agregado. Se emplea para objetos compuestos formados por varios componentes interrelacionados ; la visualización correcta no se logra 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, las cuales, 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 está especificada y viene 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 está definido en el RFC 2387.
informe
El tipo de mensaje multipart/report contiene datos formateados para que un servidor de correo los lea. Se divide entre un campo text/plain (u otro tipo de contenido fácilmente legible) y un campo message/delivery-status, que contiene los datos formateados para que el servidor de correo los lea.
El tipo está definido en RFC 6522.
firmado
Un mensaje multipart/signed se utiliza para adjuntar una firma digital a un mensaje. Consta de dos partes: una parte principal y una parte de firma. La firma se crea utilizando la totalidad de la parte principal, incluidos los campos MIME. Existen muchos tipos de firma posibles, como "application/pgp-signature" (RFC 3156) y "application/pkcs7-signature" ( S/MIME ).
El tipo está definido en RFC 1847. [ 10 ]
cifrado
Un mensaje multipartes/encriptado tiene dos partes. La primera parte contiene información de control necesaria para descifrar la segunda parte, application/octet-stream. Al igual que con los mensajes firmados, existen diferentes implementaciones que se identifican por sus distintos tipos de contenido 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 ]
datos de formulario
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 usa con mayor frecuencia para enviar archivos con HTTP . Está especificado en RFC 7578 , que reemplaza a RFC 2388. Ejemplo
x-mixed-replace
El tipo de contenido multipart/x-mixed-replace se desarrolló como parte de una tecnología para emular el envío de datos desde el servidor y la transmisión 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 en cuanto se recibe por completo. Los clientes deben procesar las partes individuales en cuanto llegan y no deben esperar a que finalice el mensaje completo.
Desarrollado originalmente por Netscape , [ 12 ] todavía es compatible con Mozilla , Firefox , Safari y Opera . Se usa comúnmente en cámaras IP como tipo MIME para transmisiones MJPEG . [ 13 ] Chrome lo admitió para recursos principales hasta 2013 (aún se pueden mostrar imágenes usando este tipo de contenido). [ 14 ]
rango de bytes
El formato multipart/byterange se utiliza para representar rangos de bytes no contiguos de un mismo mensaje; HTTP lo utiliza cuando un servidor devuelve varios rangos de bytes y está definido en la RFC 2616.
Documentación RFC
- RFC 1426 , Extensión del servicio SMTP para transporte MIME de 8 bits . J. Klensin , N. Freed , M. Rose , E. Stefferud , D. Crocker. Febrero de 1993.
- RFC 1847 , Seguridad de múltiples partes para MIME: Multipart/Signed y Multipart/Encrypted
- 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 , Parte tres de MIME: Extensiones de encabezado de mensaje para texto no ASCII . Keith Moore . Noviembre de 1996.
- ( RFC 4288 , Parte cuatro de MIME: Especificaciones de tipo de medio y procedimientos de registro . Obsoleto por RFC 6838).
- RFC 6838 , Especificaciones de tipo de medio y procedimientos de registro . J. Klensin , N. Freed , T. Hansen. Enero de 2013. (Sustituye a RFC 4288).
- RFC 4289 , Parte cuatro de MIME: Procedimientos de registro . J. Klensin , N. Freed . 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 , Extensiones de valores de parámetros MIME y palabras codificadas: conjuntos de caracteres, idiomas y continuaciones . N. Freed , K. Moore. Noviembre de 1997.
- RFC 2387 , El tipo de contenido MIME Multipart/Related
- 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
Véase también
- Encapsulación directa de mensajes de Internet (DIME) : un protocolo propuesto por Microsoft, ahora obsoleto, concebido como una versión simplificada de MIME, principalmente para su uso en servicios web.
- Enlace e incrustación de objetos : tecnología desarrollada por Microsoft.
- SOAP con archivos adjuntos
- Unicode y correo electrónico : relación entre Unicode y correo electrónico
- Uuencoding – Forma de codificación de binario a texto
- VPIM
Referencias
- ↑ Terry Gliedt (27 de mayo de 1996). "Mensajes: un servicio de correo multimedia" .
- ↑ "Historia de MIME" . Network World . Febrero de 2011.
- ↑ Giles Turnbull (14 de diciembre de 2005). "Forzando a Thunderbird a tratar correctamente los archivos adjuntos salientes" . Centro de desarrollo de Mac de O'Reilly . Consultado el 1 de abril de 2010 .
- ↑ Ned Freed (22 de junio de 2008). "Parámetros de nombre y nombre de archivo" . Consultado el 3 de abril de 2017 .
- ↑ RFC 2046, Sección 5.1.3
- ↑ RFC 2046, Sección 5.1.5
- ↑ "RFC1341 Sección 7.2 El tipo de contenido multiparte" . Consorcio World Wide Web . Consultado el 15 de julio de 2014 .
- 1 2 "Descripción general de las técnicas de filtrado antispam" (PDF) . Revista Internacional de Investigación en Ingeniería y Tecnología . 4 (1). Enero de 2017. S2CID 212596952. Recuperado el 20 de febrero de 2020 .
- ↑ RFC 2046, Sección 5.1.4
- ↑ RFC 1847, Sección 2.1
- ↑ RFC 1847, Sección 2.2
- ↑ "Una exploración de los documentos dinámicos" . Netscape. Archivado del original el 3 de diciembre de 1998.
- ↑ "Documentación de configuración del monitor de la cámara web" . DeskShare. Archivado del original el 11 de mayo de 2010.
- ↑ "249132 - Eliminar la compatibilidad con los recursos principales multipart/x-mixed-replace - chromium - Monorail" . bugs.chromium.org . Consultado el 10 de octubre de 2017 .
Lecturas adicionales
- Hughes, L (1998). Protocolos, estándares e implementación del 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 aplicados a la práctica . John Wiley & Sons. ISBN 978-0-471-34597-8.
- Rhoton, J (1999). Guía del programador para el correo electrónico por Internet: SMTP, POP, IMAP y LDAP . Elsevier. ISBN 978-1-55558-212-8.
- Wood, D (1999). Programación de correo electrónico por Internet . O'Reilly. ISBN 978-1-56592-479-6.
Enlaces externos
- Tipos de medios MIME : comprende una lista de directorios de tipos y subtipos de contenido, mantenidos 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 sencilla de los mensajes multipartes 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 de PHP en línea gratuito
- Validador de correo electrónico MIME en línea gratuito
- MÍMICA
