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 sin formato : [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 ).
La mayoría de los clientes de correo electrónico gráficos admiten correo electrónico HTML y muchos lo utilizan de forma predeterminada. Muchos de estos clientes incluyen un editor 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 correo electrónico HTML (e incluso al propio MIME ), por diversas razones. [2] Por ejemplo, la campaña ASCII Ribbon abogó por que todos los correos electrónicos deberían enviarse en formato de texto ASCII . La campaña no tuvo éxito y fue abandonada 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 cuando salió a la luz ahora lo ven como mayormente 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 utiliza clientes de sólo texto. [6] La mayoría de los usuarios prefieren recibir correos electrónicos HTML en lugar de texto sin formato. [7] [8]
El software de correo electrónico que cumpla con RFC 2822 solo es necesario para admitir texto sin formato, no formato HTML. Por lo tanto, enviar 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 representan de manera consistente con las especificaciones del W3C y muchos correos electrónicos HTML tampoco lo son, lo que puede causar problemas de procesamiento o entrega.
En particular, la <head>etiqueta, que se utiliza 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 sean ineficientes y no logran aprovechar la capacidad del HTML para separar el estilo del contenido. [ cita necesaria ] 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 según su interpretación de una prueba ácida, inspirada en las de los Estándares Web. Project y presiona a los desarrolladores para que mejoren sus productos. Para persuadir a Google de mejorar la representación en Gmail , por ejemplo, publicaron un montaje de vídeo de desarrolladores web haciendo muecas, [10] que atrajo la atención de un empleado.
Algunos remitentes pueden confiar excesivamente en fuentes grandes, coloridas o que distraen , lo que hace que los mensajes sean más difíciles de leer. [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 globalmente. 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.
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 de formato importante. (Por ejemplo, una ecuación matemática puede perder un superíndice y adquirir un significado completamente nuevo).Content-Type: multipart/alternativemultipart/alternativetext/plaintext/html
Muchas [ cita necesaria ] listas de correo bloquean deliberadamente el correo electrónico HTML, ya sea eliminando la parte HTML para dejar solo la parte de texto sin formato o rechazando el mensaje completo. [ cita necesaria ]
El orden de las piezas 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 sin formato, eso significa enumerar la versión de texto sin formato primero y la versión html después; de lo contrario, el cliente puede mostrar de forma predeterminada la versión de texto sin formato aunque haya una versión html disponible.
El correo electrónico HTML es más grande que el texto sin formato. Incluso si no se utiliza ningún 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 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 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]
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), visitándolo y revelando sin querer 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 que el correo electrónico se ha abierto. 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 objetivo 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 todos los correos electrónicos HTML entrantes en correos electrónicos 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 no deseados aprovechan el formato para engañar a los filtros de spam haciéndoles creer que el mensaje es legítimo. Lo hacen incluyendo contenido inofensivo en la parte de texto del mensaje y colocando el spam en la parte HTML (la que se muestra al usuario).
La mayor parte del spam de correo electrónico se envía en HTML [ cita necesaria ] por estos motivos, por lo que los filtros de spam a veces otorgan puntuaciones de spam más altas a los mensajes HTML. [ cita necesaria ]
En 2018 se reveló EFAIL , una vulnerabilidad grave que podría revelar el contenido real de los correos electrónicos HTML cifrados a un atacante.
HTML tiene una adopción casi universal entre los consumidores: una encuesta de consumidores de Jupiter Research encontró que solo el 3% recibe solo correos electrónicos de texto.
¿Prefieres recibir correo electrónico HTML o de texto?
HTML: 41,95%, Texto: 31,52%, Sin preferencia: 26,53%
¿En qué formato prefieres recibir mensajes de correo electrónico de las empresas?
HTML: 88%, texto sin formato: 12%
{{cite web}}: Enlace externo en |author=