El correo electrónico HTML es el uso de un subconjunto de HTML para proporcionar capacidades de formato y marcado semántico en el correo electrónico que no están disponibles con texto plano : [1] El texto se puede vincular sin mostrar una URL o dividir las URL largas en varias partes. El texto se ajusta para ajustarse al ancho de la ventana de visualización, en lugar de dividir uniformemente cada línea en 78 caracteres (definido en RFC 5322, que era necesario en terminales de texto más antiguos ). Permite la inclusión en línea de imágenes, tablas , así como diagramas o fórmulas matemáticas.como imágenes, que de otro modo serían difíciles de transmitir (normalmente utilizando arte ASCII ).
Adopción
La mayoría de los clientes de correo electrónico gráfico admiten el correo electrónico HTML y muchos lo utilizan de forma predeterminada. Muchos de estos clientes incluyen un editor de GUI para redactar correos electrónicos HTML y un motor de renderizado para mostrar los correos electrónicos HTML recibidos.
Desde su concepción, varias personas se han opuesto abiertamente a todo el correo electrónico HTML (e incluso al propio MIME ), por diversas razones. [2] Por ejemplo, la campaña ASCII Ribbon recomendó que todos los correos electrónicos se envíen en formato de texto ASCII . La campaña no tuvo éxito y se abandonó en 2013. [3] [4] Si bien todavía se considera inapropiada en muchas publicaciones de grupos de noticias y listas de correo, su adopción para el correo personal y comercial solo ha aumentado con el tiempo. Algunos de los que se opusieron firmemente a él cuando salió a la luz ahora lo ven como en su mayoría inofensivo. [5]
Según encuestas realizadas por empresas de marketing online , la adopción de clientes de correo electrónico con capacidad HTML es ahora casi universal, y menos del 3% informa que utilizan clientes de solo texto. [6] La mayoría de los usuarios prefieren recibir correos electrónicos HTML en lugar de texto sin formato. [7] [8]
Compatibilidad
El software de correo electrónico que cumple con RFC 2822 solo es necesario para admitir texto sin formato, no formato HTML. Por lo tanto, el envío de correos electrónicos con formato HTML puede generar problemas si el cliente de correo electrónico del destinatario no lo admite. En el peor de los casos, el destinatario verá el código HTML en lugar del mensaje deseado.
Entre los clientes de correo electrónico que admiten HTML, algunos no lo procesan de manera coherente con las especificaciones de W3C , y muchos correos electrónicos HTML tampoco son compatibles, lo que puede causar problemas de reproducción o entrega.
En particular, la etiqueta, que se usa para albergar reglas de estilo CSS para un documento HTML completo, no está bien soportada, a veces se elimina por completo, lo que hace que las declaraciones de estilo en línea sean el estándar de facto , aunque las declaraciones de estilo en línea son ineficaz y no aprovecha la capacidad de HTML para separar el estilo del contenido. [ cita requerida ] Aunque se han desarrollado soluciones alternativas, [9] esto ha causado mucha frustración entre los desarrolladores de boletines, generando el Proyecto de Estándares de Correo Electrónico de base , que califica a los clientes de correo electrónico en su interpretación de una prueba ácida, inspirada en los de los Estándares Web Proyecta y presiona a los desarrolladores para que mejoren sus productos. Para persuadir a Google de que mejorara el procesamiento en Gmail , por ejemplo, publicaron un montaje de video de desarrolladores web haciendo muecas, [10] lo que resultó en la atención de un empleado.
Clientela | Resultado (a partir de) |
---|---|
Webmail de AOL | Soporte sólido (13 de julio de 2011) |
IPhone de Apple | Soporte sólido (13 de julio de 2011) |
IPad de Apple | |
IPod Touch de Apple | |
Correo de Apple | Soporte sólido (28 de noviembre de 2007) |
Apple MobileMe | Soporte sólido (15 de agosto de 2008) |
Eudora Eudora OSE con nombre en código "Penélope" | Soporte sólido (28 de noviembre de 2007) |
Entourage de Microsoft | Soporte sólido (28 de noviembre de 2007) |
Mozilla Thunderbird | Soporte sólido (28 de noviembre de 2007) |
Windows Live Mail | Soporte sólido (28 de noviembre de 2007) |
Correo de Windows | Soporte sólido (28 de noviembre de 2007) |
Yahoo! Correo Beta | Soporte sólido (8 de julio de 2011) |
Windows Live Hotmail | Se recomiendan algunas mejoras (8 de julio de 2011) |
Google Gmail | Mejora recomendada (13 de julio de 2011) |
Lotus Notes 8 | Mejora recomendada (28 de noviembre de 2007) |
Microsoft Outlook 2007 | Mejora recomendada (28 de noviembre de 2007) |
Estilo
Algunos remitentes pueden depender excesivamente de fuentes grandes, coloridas o que distraen , lo que dificulta la lectura de los mensajes. [11] Para aquellos especialmente molestos por este formato, algunos agentes de usuario hacen posible que el lector anule parcialmente el formato (por ejemplo, Mozilla Thunderbird permite especificar un tamaño de fuente mínimo); sin embargo, estas capacidades no están disponibles a nivel mundial. Además, la diferencia en la apariencia óptica entre el remitente y el lector puede ayudar a diferenciar al autor de cada sección, mejorando la legibilidad.
Formatos de varias partes
Muchos servidores de correo electrónico están configurados para generar automáticamente una versión de texto sin formato de un mensaje y enviarlo junto con la versión HTML, para garantizar que pueda ser leído incluso por clientes de correo electrónico de solo texto , utilizando el , como se especifica en RFC 1521. [12 ] [13] [14] El mensaje en sí es de tipo y contiene dos partes, la primera de tipo , que es leída por clientes de solo texto, y la segunda con , que es leída por clientes con capacidad HTML. Sin embargo, es posible que a la versión de texto sin formato le falte información importante de formato. (Por ejemplo, una ecuación matemática puede perder un superíndice y adquirir un significado completamente nuevo).Content-Type: multipart/alternative
multipart/alternative
text/plain
text/html
Muchas listas de correo [ cita requerida ] bloquean deliberadamente el correo electrónico HTML, ya sea eliminando la parte HTML para dejar la parte de texto sin formato o rechazando el mensaje completo. [ cita requerida ]
El orden de las partes es significativo. RFC1341 establece que: En general, los agentes de usuario que componen entidades multiparte / alternativas deben colocar las partes del cuerpo en orden creciente de preferencia, es decir, con el formato preferido al final. [15] Para correos electrónicos de varias partes con versiones html y de texto plano, eso significa enumerar la versión de texto plano primero y la versión html después; de lo contrario, el cliente puede mostrar de forma predeterminada la versión de texto plano aunque haya una versión html disponible.
Tamaño del mensaje
El correo electrónico HTML es más grande que el texto sin formato. Incluso si no se utiliza un formato especial, habrá una sobrecarga de las etiquetas utilizadas en un documento HTML mínimo, y si el formato se utiliza mucho, puede ser mucho mayor. Los mensajes de varias partes, con copias duplicadas del mismo contenido en diferentes formatos, aumentan aún más el tamaño. Sin embargo, la sección de texto sin formato de un mensaje de varias partes se puede recuperar por sí sola, utilizando el comando FETCH de IMAP . [dieciséis]
Aunque la diferencia en el tiempo de descarga entre el correo de texto sin formato y el correo de mensajes mixtos (que puede ser un factor de diez o más) fue motivo de preocupación en la década de 1990 (cuando la mayoría de los usuarios accedían a los servidores de correo electrónico a través de módems lentos ), en una conexión moderna la diferencia es insignificante para la mayoría de las personas, especialmente en comparación con imágenes, archivos de música u otros archivos adjuntos comunes. [17]
Vulnerabilidades de seguridad
HTML permite que un enlace se muestre como texto arbitrario, de modo que en lugar de mostrar la URL completa, un enlace puede mostrar solo una parte o simplemente un nombre de destino fácil de usar. Esto se puede utilizar en ataques de phishing , en los que se engaña a los usuarios haciéndoles creer que un enlace apunta al sitio web de una fuente autorizada (como un banco), visitarlo y revelar involuntariamente detalles personales (como números de cuentas bancarias) a un estafador. .
Si un correo electrónico contiene errores web (contenido en línea de un servidor externo, como una imagen ), el servidor puede alertar a un tercero de que se ha abierto el correo electrónico. Este es un riesgo potencial para la privacidad , ya que revela que una dirección de correo electrónico es real (para que pueda ser dirigida en el futuro) y revela cuándo se leyó el mensaje.
El contenido HTML requiere que los programas de correo electrónico utilicen motores para analizar, representar y mostrar el documento. Esto puede generar más vulnerabilidades de seguridad, denegación de servicio o bajo rendimiento en computadoras más antiguas.
Durante los períodos de aumento de las amenazas a la red, el Departamento de Defensa de EE. UU. Convierte todo el correo electrónico HTML entrante en correo electrónico de texto. [18]
El tipo de varias partes está destinado a mostrar el mismo contenido de diferentes maneras, pero a veces se abusa de esto; algunos correos electrónicos no deseados aprovechan el formato para engañar a los filtros de correo no deseado y hacerles creer que el mensaje es legítimo. Para ello, incluyen contenido inocuo en la parte de texto del mensaje y colocan el spam en la parte HTML (lo que se muestra al usuario).
La mayoría de los correos no deseados se envían en HTML [ cita requerida ] por estas razones, por lo que los filtros de correo no deseado a veces otorgan puntuaciones más altas a los mensajes HTML. [ cita requerida ]
En 2018 se dio a conocer EFAIL , una vulnerabilidad grave que podría revelar el contenido real de los correos electrónicos HTML cifrados a un atacante.
Ver también
- Correo electrónico de texto sin formato : la forma más simple de correo electrónico que no admite el formato enriquecido
- Texto enriquecido : un sistema similar a HTML para correo electrónico que usa MIME
- Producción de correo electrónico
Referencias
- ^ "Correo electrónico de texto vs correo electrónico HTML - Los pros y los contras | Thunder Mailer - Software de correo electrónico masivo" . www.thundermailer.com . Consultado el 30 de enero de 2016 .
- ^ HTML Email: ¡Siempre que sea posible, apáguelo!
- ^ "La página de inicio oficial de la campaña Ascii Ribbon" . Archivado desde el original el 11 de marzo de 2010 . Consultado el 30 de enero de 2016 .
- ^ "Cierre de la campaña de cintas ASCII - Foro Pale Moon" . forum.palemoon.org . Archivado desde el original el 3 de febrero de 2016 . Consultado el 30 de enero de 2016 .
- ^ HTML Email: The Poll (Scot Hacker, creador del muy vinculado por qué HTML en el correo electrónico es una mala idea analiza cómo han cambiado sus sentimientos desde la década de 1990)
- ^ "Estadísticas y métricas de marketing por correo electrónico - EmailLabs" . 29 de marzo de 2007. Archivado desde el original el 29 de marzo de 2007 . Consultado el 30 de enero de 2016 .
HTML tiene una adopción casi universal entre los consumidores: una encuesta de consumidores de Jupiter Research encontró que solo el 3% recibe solo mensajes de correo electrónico de texto.
- ^ Grossman, Edward (9 de julio de 2002). "Uso de clientes de correo electrónico en el mundo real: los datos duros | ClickZ" . www.clickz.com . Consultado el 30 de enero de 2016 .
¿Prefieres recibir correo electrónico HTML o de texto? HTML: 41,95%, Texto: 31,52%, Sin preferencia: 26,53%
- ^ "La ciencia del marketing por correo electrónico" . www.slideshare.net . Consultado el 30 de enero de 2016 .
¿En qué formato prefiere recibir mensajes de correo electrónico de empresas? HTML: 88%, texto sin formato: 12%
- ^ Dialecto < http://dialect.ca/ >. "Premailer: hacer CSS en línea para correo electrónico HTML" . Premailer.dialect.ca . Consultado el 24 de junio de 2012 .
- ^ "La apelación de Gmail 2008 | Proyecto de estándares de correo electrónico" . Email-standards.org. Archivado desde el original el 15 de mayo de 2012 . Consultado el 24 de junio de 2012 .
- ^ Shobe, Matt (12 de octubre de 2004). "Un argumento bastante justo contra el correo electrónico HTML" . Burningdoor.com. Archivado desde el original el 24 de abril de 2012 . Consultado el 24 de junio de 2012 .
- ^ RFC 1521 7.2.3. El subtipo multiparte / alternativo
- ^ "TN1010-11-2: Multiparte / Alternative - Manejo elegante de clientes de correo electrónico con fobia al HTML" (PDF) . Consultado el 24 de junio de 2012 .
- ^ "Envío de correo electrónico HTML y texto sin formato simultáneamente" . Wilsonweb.com. 28 de abril de 2000 . Consultado el 24 de junio de 2012 .
- ^ "RFC1341 Sección 7.2 El tipo de contenido de varias partes" . Consultado el 15 de julio de 2014 .
- ^ "¿Realmente queremos enviar páginas web por correo electrónico?" . Dsv.su.se . Consultado el 24 de junio de 2012 .
- ^ Correo electrónico HTML - ¿Sigue siendo malvado?
- ^ "DOD prohibe el uso de correo electrónico HTML, Outlook Web Access" . fcw.com . Consultado el 23 de junio de 2015 .