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 simple : [1] El texto se puede vincular sin mostrar una URL o dividir URL largas en varias partes. El texto se ajusta para adaptarse 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 antiguas ). 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 son 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 de interfaz gráfica de usuario 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 todo el correo electrónico se enviara en formato de texto ASCII . La campaña no tuvo éxito y se abandonó en 2013. [3] [4] Si bien todavía se considera inapropiado 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ó por primera vez 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 compatibles con HTML es ahora casi universal, y menos del 3 % afirma utilizar clientes que solo admiten texto. [6] La mayoría de los usuarios prefieren recibir correos electrónicos en HTML en lugar de texto sin formato. [7] [8]
El software de correo electrónico que cumple con la norma RFC 2822 solo debe 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 aquellos clientes de correo electrónico que admiten HTML, algunos no lo muestran de forma coherente con las especificaciones del W3C , y muchos correos electrónicos HTML tampoco lo cumplen, lo que puede causar problemas de visualización o entrega.
En particular, la <head>etiqueta, que se utiliza para albergar las 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 , a pesar de que las declaraciones de estilo en línea son ineficientes y no aprovechan bien la capacidad de HTML para separar el estilo del contenido . [ cita requerida ] Aunque se han desarrollado soluciones alternativas, [9] esto ha causado una gran frustración entre los desarrolladores de boletines, generando el Email Standards Project de base , que califica a los clientes de correo electrónico en su representación de una prueba Acid , inspirada en las del Web Standards 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 video de desarrolladores web haciendo muecas, [10] lo que resultó en la atención de un empleado.
Algunos remitentes pueden recurrir excesivamente a fuentes grandes, coloridas o que distraigan , lo que hace que los mensajes sean más difíciles de leer. [11] Para aquellos a quienes les molesta especialmente este formato, algunos agentes de usuario permiten 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, lo que mejora 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 enviarla junto con la versión HTML, para garantizar que pueda ser leída 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 listas de correo [ cita requerida ] 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 requerida ]
El orden de las partes es importante. 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 multiparte con versiones en html y texto sin formato, eso significa enumerar primero la versión en texto sin formato y después la versión html; de lo contrario, el cliente puede mostrar de manera predeterminada la versión en texto sin formato aunque haya una versión html disponible.
El tamaño de un correo electrónico HTML es mayor que el de un texto normal. Incluso si no se utiliza ningún formato especial, se producirá una sobrecarga debido a las etiquetas utilizadas en un documento HTML mínimo, y si se utiliza mucho el formato, 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 normal de un mensaje de varias partes se puede recuperar por sí sola, utilizando el comando FETCH de IMAP . [16]
Aunque la diferencia en el tiempo de descarga entre el correo de texto simple 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 cuando se compara con imágenes, archivos de música u otros archivos adjuntos comunes. [17]
El HTML permite ocultar un enlace, pero mostrarlo como cualquier texto arbitrario, como un nombre de destino fácil de entender. Esto se puede utilizar en ataques de phishing , en los que se engaña a los usuarios para que accedan a un sitio web falso y revelen datos personales (como números de cuenta bancaria) a un estafador.
Si un correo electrónico contiene contenido en línea de un servidor externo, como una imagen , para recuperarlo se requiere una solicitud a ese servidor externo que identifica dónde se mostrará la imagen y otra información sobre el destinatario. Los web bugs son imágenes creadas especialmente (normalmente únicas para cada correo electrónico individual) destinadas a rastrear ese correo electrónico y permitir que el creador sepa que se ha abierto. Entre otras cosas, eso revela que una dirección de correo electrónico es real y puede ser objeto de ataques en el futuro.
Algunos ataques de phishing se basan en características particulares de HTML: [18]
La visualización de contenido HTML con frecuencia implica que el programa cliente recurra a rutinas especiales para analizar y representar el texto codificado en HTML; el contenido mal codificado deliberadamente puede explotar errores en esas rutinas para crear violaciones de seguridad. [ cita requerida ] Las solicitudes de fuentes especiales, etc., también pueden afectar los recursos del sistema. [ cita requerida ]
Durante períodos de mayores amenazas a la red, el Departamento de Defensa de EE. UU. ha convertido el correo electrónico HTML entrante de los usuarios en correo electrónico de texto. [19]
El tipo multipart tiene como objetivo mostrar el mismo contenido de distintas maneras, pero a veces se abusa de este formato; algunos correos electrónicos no deseados aprovechan este 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 correo no deseado en la parte HTML (la que se muestra al usuario).
La mayoría del correo no deseado se envía en formato HTML [ cita requerida ] por estos motivos, por lo que los filtros de spam a veces otorgan puntuaciones de spam más altas a los mensajes HTML. [ cita requerida ]
En 2018 se reveló una vulnerabilidad ( EFAIL ) del procesamiento HTML de muchos clientes de correo electrónico comunes, en la que el texto descifrado de partes de correo electrónico cifradas con PGP o S/MIME se puede enviar como un atributo a una dirección de imagen externa, si se solicita la imagen externa. Esta vulnerabilidad estaba presente en Thunderbird, macOS Mail, Outlook y, posteriormente, Gmail y Apple Mail. [20]
El HTML tiene una adopción casi universal entre los consumidores: una encuesta de consumidores de Jupiter Research descubrió que solo el 3 % recibe solo correos electrónicos de texto.
¿Prefiere recibir correo electrónico en formato HTML o de texto? HTML: 41,95 %, Texto: 31,52 %, Sin preferencia: 26,53 %
¿En qué formato prefiere recibir mensajes de correo electrónico de las empresas? HTML: 88%, Texto sin formato: 12%
{{cite web}}: Enlace externo en |author=