Hispanopedia Wiki
Articulo de referencia

Correo electrónico HTML

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...

Hispanopedia WikiContenido en espanolLectura gratuita

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 puede enlazarse sin mostrar una URL , o dividir 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 a 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 son difíciles de transmitir (normalmente usando arte ASCII ).

Adopción

La mayoría de los clientes de correo electrónico gráficos admiten correo electrónico en formato HTML, y muchos lo utilizan por defecto. Muchos de estos clientes incluyen tanto un editor gráfico para redactar correos electrónicos en HTML como un motor de renderizado para mostrar los correos electrónicos recibidos en este formato.

Desde su concepción, varias personas se han opuesto abiertamente a todo el correo electrónico en formato HTML (e incluso al propio MIME ), por diversas razones. [ 2 ] Por ejemplo, la Campaña del Lazo ASCII abogaba por que todos los correos electrónicos se enviaran en formato de texto ASCII . Los defensores colocaban arte ASCII en sus firmas , con la intención de que pareciera un lazo de concienciación , junto con un mensaje o un enlace a un sitio web de defensa. La campaña no tuvo éxito y se abandonó en 2013. [ 3 ] [ 4 ]

Aunque todavía se considera inapropiado en muchas publicaciones de grupos de noticias y listas de correo, la adopción de HTML para el correo personal y empresarial no ha hecho más que aumentar con el tiempo. Algunos de los que se opusieron firmemente cuando apareció por primera vez ahora lo consideran prácticamente inofensivo. [ 5 ]

Según encuestas realizadas por empresas de marketing online , la adopción de clientes de correo electrónico compatibles con HTML es prácticamente universal, y menos del 3 % afirma utilizar clientes que solo admiten texto. [ 6 ] La mayoría de los usuarios prefiere recibir correos electrónicos en formato HTML en lugar de texto plano. [ 7 ] [ 8 ]

Compatibilidad

El software de correo electrónico que cumple con la RFC 2822 solo debe admitir texto sin formato, no formato HTML. Por lo tanto, enviar correos electrónicos con formato HTML puede causar problemas si el cliente de correo del destinatario no lo admite. En el peor de los casos, el destinatario verá el código HTML en lugar del mensaje original.

Entre los clientes de correo electrónico que sí admiten HTML, algunos no lo renderizan de forma coherente con las especificaciones del W3C , y muchos correos electrónicos en HTML tampoco cumplen con dichas especificaciones, lo que puede provocar problemas de renderizado o de entrega.

En particular, la <head>etiqueta, que se utiliza para albergar reglas de estilo CSS para todo un documento HTML, 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 ineficientes y no aprovechan bien la capacidad de HTML para separar el estilo del contenido . Aunque se han desarrollado soluciones alternativas, [ 9 ] esto ha causado mucha frustración entre los desarrolladores de boletines informativos, dando origen al Email Standards Project, un proyecto de base que califica a los clientes de correo electrónico en su renderizado 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 que mejore el renderizado en Gmail , por ejemplo, publicaron un montaje de vídeo de desarrolladores web haciendo muecas, [ 10 ] lo que resultó en la atención de un empleado.

Estilo

Algunos remitentes pueden abusar del uso de fuentes grandes, coloridas o que distraigan , lo que dificulta la lectura de los mensajes. [ 12 ] Para quienes se ven especialmente afectados por este formato, algunos navegadores permiten al lector modificarlo parcialmente (por ejemplo, Mozilla Thunderbird permite especificar un tamaño mínimo de fuente); sin embargo, estas funciones no están disponibles en todos los navegadores. Además, la diferencia en la apariencia visual entre el remitente y el lector puede ayudar a identificar al autor de cada sección, mejorando así la legibilidad.

Formatos de varias partes

Muchos servidores de correo electrónico están configurados para generar automáticamente una versión de texto plano de un mensaje y enviarla junto con la versión HTML, para asegurar que pueda ser leída incluso por clientes de correo electrónico solo de texto , utilizando el formato especificado en RFC 1521. [ 13 ] [ 14 ] [ 15 ] El mensaje en sí es de tipo y contiene dos partes, la primera de tipo , que es leída por clientes solo de texto, y la segunda con , que es leída por clientes compatibles con HTML. Sin embargo, la versión de texto plano puede carecer de 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 bloquean deliberadamente los correos electrónicos en formato HTML, ya sea eliminando la parte HTML para dejar solo el texto sin formato o rechazando el mensaje completo.

El orden de las partes es importante. RFC1341 establece que: En general, los agentes de usuario que componen entidades multipart/alternativas deben colocar las partes del cuerpo en orden creciente de preferencia, es decir, con el formato preferido al final. [ 16 ] Para correos electrónicos multipart con versiones html y de texto plano, esto significa listar primero la versión de texto plano y después la versión html, de lo contrario el cliente podría mostrar por defecto 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 plano. Incluso sin formato especial, existe la sobrecarga de las etiquetas utilizadas en un documento HTML mínimo, y si se utiliza mucho formato, puede ser mucho mayor. Los mensajes multipartes, con copias duplicadas del mismo contenido en diferentes formatos, aumentan aún más el tamaño. Sin embargo, la sección de texto plano de un mensaje multipartes se puede recuperar por separado utilizando el comando FETCH de IMAP . [ 17 ]

Aunque la diferencia en el tiempo de descarga entre el correo de texto plano y el correo de mensajes mixtos (que puede ser de diez veces o más) era 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 si se compara con imágenes, archivos de música u otros archivos adjuntos comunes. [ 18 ]

Vulnerabilidades de seguridad

HTML permite ocultar un enlace, pero mostrarlo como cualquier texto, como un nombre descriptivo. Esto se puede usar en ataques de phishing , en los que se engaña a los usuarios para que accedan a un sitio web falso y revelen información personal (como números de cuenta bancaria) a un estafador.

If an email contains inline content from an external server, such as a picture, retrieving it requires a request to that external server which identifies where the picture will be displayed and other information about the recipient. Web bugs are specially created images (usually unique for each individual email) intended to track that email and let the creator know that the email has been opened. Among other things, that reveals that an email address is real, and can be targeted in the future.

Some phishing attacks rely on particular features of HTML:[19]

  • Brand impersonation with procedurally-generated graphics (such graphics can look like a trademarked image but evade security scanning because there is no file)
  • Text containing invisible Unicode characters or with a zero-height font to confuse security scanning
  • Victim-specific URI, where a malicious link encodes special information which allows a counterfeit site to be personalized (appearing as the victim's account) so as to be more convincing.

Displaying HTML content frequently involves the client program calling on special routines to parse and render the HTML-coded text; deliberately mis-coded content can then exploit mistakes in those routines to create security violations. Requests for special fonts, etc, can also impact system resources.

During periods of increased network threats, the US Department of Defense has converted user's incoming HTML email to text email.[20]

The multipart type is intended to show the same content in different ways, but this is sometimes abused; some email spam takes advantage of the format to trick spam filters into believing that the message is legitimate. They do this by including innocuous content in the text part of the message and putting the spam in the HTML part (that which is displayed to the user).

Most email spam is sent in HTML for these reasons, so spam filters sometimes give higher spam scores to HTML messages.

In 2018 a vulnerability (EFAIL) of the HTML processing of many common email clients was disclosed, in which decrypted text of PGP or S/MIME encrypted email parts can be caused to be sent as an attribute to an external image address, if the external image is requested. This vulnerability was present in Thunderbird, macOS Mail, Outlook, and later, Gmail and Apple Mail.[21]

See also

References

  1. ↑ "Correo electrónico de texto vs. correo electrónico HTML: ventajas e inconvenientes | Thunder Mailer: software de envío masivo de correos electrónicos" . thundermailer.com . Consultado el 30 de enero de 2016 .
  2. ↑ Correo electrónico HTML: ¡Siempre que sea posible, desactívelo!
  3. ↑ "Página web oficial de la Campaña de la Cinta ASCII" . Archivado del original el 11 de marzo de 2010. Consultado el 30 de enero de 2016 .
  4. ↑ "Cierre de la campaña de la cinta ASCII – Foro Pale Moon" . forum.palemoon.org . Archivado del original el 3 de febrero de 2016. Consultado el 30 de enero de 2016 .
  5. ↑ Correo electrónico HTML: La encuesta (Scot Hacker, autor del artículo tan compartido " ¿Por qué usar HTML en el correo electrónico es una mala idea?" , analiza cómo han cambiado sus opiniones desde la década de 1990).
  6. ↑ "Estadísticas y métricas de marketing por correo electrónico – EmailLabs" . 29 de marzo de 2007. Archivado del 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 únicamente correos electrónicos en formato de texto.
  7. ↑ Grossman, Edward (9 de julio de 2002). "Uso real de clientes de correo electrónico: datos concretos | ClickZ" . clickz.com . Consultado el 30 de enero de 2016. ¿Prefiere recibir correos electrónicos en formato HTML o texto plano? HTML: 41,95 %, Texto plano: 31,52 %, Sin preferencia: 26,53 %
  8. ↑ "La ciencia del marketing por correo electrónico" . slideshare.net . Consultado el 30 de enero de 2016. ¿En qué formato prefiere recibir los correos electrónicos de las empresas? HTML: 88%, Texto sin formato: 12%
  9. ↑ "Premailer: cómo insertar CSS en línea para correos electrónicos HTML" . Premailer.dialect.ca . Consultado el 24 de junio de 2012 .
  10. ↑ "La apelación de Gmail de 2008 | Proyecto de estándares de correo electrónico" . Email-standards.org. Archivado del original el 15 de mayo de 2012. Consultado el 24 de junio de 2012 .
  11. ↑ "Inicio" . Proyecto de estándares de correo electrónico . Archivado del original el 14 de enero de 2013. Consultado el 22 de diciembre de 2024 .
  12. ↑ Shobe, Matt (12 de octubre de 2004). "Un argumento bastante sólido contra el correo electrónico HTML" . Burningdoor.com. Archivado del original el 24 de abril de 2012. Recuperado el 24 de junio de 2012 .
  13. ↑ RFC 1521 7.2.3. El subtipo multiparte/alternativo
  14. ↑ "TN1010-11-2: Multipart/Alternative – Manejo adecuado de clientes de correo electrónico que no admiten HTML" (PDF) . Consultado el 24 de junio de 2012 .
  15. ↑ "Envío simultáneo de correo electrónico en HTML y texto plano" . Wilsonweb.com. 28 de abril de 2000. Consultado el 24 de junio de 2012 .
  16. ↑ "RFC1341 Sección 7.2 El tipo de contenido multiparte" . Consultado el 15 de julio de 2014 .
  17. ↑ "¿Realmente queremos enviar páginas web por correo electrónico?" . Dsv.su.se . Consultado el 24 de junio de 2012 .
  18. ↑ Correo electrónico HTML: ¿Sigue siendo malvado?
  19. ↑ "Técnicas de detección de tendencias en correos electrónicos: cómo los correos electrónicos de phishing modernos se ocultan a plena vista" . Microsoft.com. 18 de agosto de 2021.
  20. ↑ "El Departamento de Defensa prohíbe el uso de correo electrónico HTML y Outlook Web Access" . nextgov.com. 22 de diciembre de 2006. Consultado el 22 de junio de 2024 .
  21. ↑ "Vulnerabilidades de Efail de hace una década pueden filtrar el texto sin cifrar de correos electrónicos cifrados con PGP y S/MIME" . arstechnica.com . 14 de mayo de 2018.
  • https://www.caniemail.com/