Email HTML - HTML email

E-mail HTML é o uso de um subconjunto de HTML para fornecer recursos de formatação e marcação semântica em e-mail que não estão disponíveis com texto simples : o texto pode ser vinculado sem exibir um URL ou quebrar URLs longos em vários pedaços. O texto é quebrado para caber na largura da janela de visualização, em vez de quebrar uniformemente cada linha em 78 caracteres (definido no RFC 5322, que era necessário em terminais de texto mais antigos ). Ele permite a inclusão em linha de imagens, tabelas , bem como diagramas ou fórmulas matemáticas como imagens, que de outra forma são difíceis de transmitir (normalmente usando arte ASCII ).

Adoção

A maioria dos clientes de e-mail gráfico suporta e-mail em HTML, e muitos usam como padrão. Muitos desses clientes incluem um editor de GUI para compor e-mails em HTML e um mecanismo de renderização para exibir os e-mails em HTML recebidos.

Desde a sua concepção, várias pessoas se opuseram veementemente a todo e-mail em HTML (e até mesmo ao próprio MIME ), por uma variedade de razões. Por exemplo, a ASCII Ribbon Campaign defendeu que todos os e-mails devem ser enviados em formato de texto ASCII . A campanha não teve sucesso e foi abandonada em 2013. Embora ainda considerada inadequada em muitas publicações de newsgroups e listas de correio, a sua adoção para correio pessoal e comercial só aumentou com o tempo. Alguns dos que se opuseram fortemente a ele quando ele foi lançado agora o consideram inofensivo.

De acordo com pesquisas feitas por empresas de marketing online , a adoção de clientes de e-mail com capacidade de HTML agora é quase universal, com menos de 3% relatando que usam clientes somente de texto. A maioria dos usuários prefere receber e-mails em HTML em vez de texto simples.

Compatibilidade

O software de e-mail em conformidade com RFC 2822 só é necessário para suportar texto simples, não formatação HTML. O envio de emails formatados em HTML pode, portanto, causar problemas se o cliente de email do destinatário não oferecer suporte. Na pior das hipóteses, o destinatário verá o código HTML em vez da mensagem pretendida.

Entre os clientes de e-mail que oferecem suporte a HTML, alguns não o renderizam de forma consistente com as especificações W3C e muitos e-mails em HTML também não são compatíveis, o que pode causar problemas de renderização ou entrega.

Em particular, a <head> tag, que é usada para abrigar regras de estilo CSS para um documento HTML inteiro, não é bem suportada, às vezes totalmente removida, fazendo com que as declarações de estilo in-line sejam o padrão de fato , embora as declarações de estilo in-line sejam ineficiente e não aproveita bem a capacidade do HTML de separar o estilo do conteúdo. Embora soluções alternativas tenham sido desenvolvidas, isso não causou falta de frustração entre os desenvolvedores de boletins informativos, gerando o projeto de padrões de email de base , que avalia os clientes de email em sua renderização de um teste ácido, inspirado pelos do Web Standards Project , e pressiona os desenvolvedores para melhorar Produtos deles. Para persuadir o Google a melhorar a renderização no Gmail , por exemplo, eles publicaram uma montagem em vídeo de desenvolvedores da web fazendo caretas, resultando na atenção de um funcionário.

Comparação de teste de ácido do "projeto de padrões de email" (em janeiro de 2013) [1]
Clientes Resultado (a partir de)
AOL Webmail Suporte sólido (13 de julho de 2011)
IPhone da Apple Suporte sólido (13 de julho de 2011)
Apple iPad
Apple iPod Touch
Apple Mail Suporte sólido (28 de novembro de 2007)
Apple MobileMe Suporte sólido (15 de agosto de 2008)
Eudora
Eudora OSE com codinome "Penelope" 		Suporte sólido (28 de novembro de 2007)
Microsoft Entourage Suporte sólido (28 de novembro de 2007)
Mozilla Thunderbird Suporte sólido (28 de novembro de 2007)
Windows Live Mail Suporte sólido (28 de novembro de 2007)
Windows Mail Suporte sólido (28 de novembro de 2007)
Yahoo! Mail Beta Suporte sólido (8 de julho de 2011)
Windows Live Hotmail Alguma melhoria recomendada (8 de julho de 2011)
Gmail do Google Melhoria recomendada (13 de julho de 2011)
Lotus Notes 8 Melhoria recomendada (28 de novembro de 2007)
Microsoft Outlook 2007 Melhoria recomendada (28 de novembro de 2007)

Estilo

Alguns remetentes podem depender excessivamente de fontes grandes, coloridas ou que distraem , tornando as mensagens mais difíceis de ler. Para aqueles especialmente incomodados com esta formatação, alguns agentes de usuário possibilitam ao leitor substituir parcialmente a formatação (por exemplo, o Mozilla Thunderbird permite especificar um tamanho mínimo de fonte); no entanto, esses recursos não estão disponíveis globalmente. Além disso, a diferença na aparência óptica entre o remetente e o leitor pode ajudar a diferenciar o autor de cada seção, melhorando a legibilidade.

Formatos de várias partes

Muitos servidores de e-mail são configurados para gerar automaticamente uma versão de texto simples de uma mensagem e enviá-la junto com a versão HTML, para garantir que ela possa ser lida mesmo por clientes de e - mail somente texto , usando o , conforme especificado no RFC 1521. A mensagem em si é do tipo e contém duas partes, a primeira do tipo , que é lida por clientes somente de texto, e a segunda com , que é lida por clientes habilitados para HTML. A versão em texto simples pode estar faltando informações de formatação importantes, entretanto. (Por exemplo, uma equação matemática pode perder um sobrescrito e assumir um significado totalmente novo.) Content-Type: multipart/alternativemultipart/alternativetext/plaintext/html

Muitas listas de discussão bloqueiam deliberadamente o e-mail em HTML, removendo a parte HTML para apenas deixar a parte do texto simples ou rejeitando a mensagem inteira.

A ordem das peças é significativa. A RFC1341 afirma que: Em geral, os agentes de usuário que compõem entidades multiparte / alternativas devem colocar as partes do corpo em ordem crescente de preferência, ou seja, com o formato preferencial por último. Para e-mails multipartes com versões em html e texto simples, isso significa listar a versão em texto simples primeiro e a versão em html depois dela, caso contrário, o cliente pode usar como padrão mostrar a versão em texto simples mesmo que uma versão em html esteja disponível.

Tamanho da mensagem

O e-mail em HTML é maior do que o texto simples. Mesmo que nenhuma formatação especial seja usada, haverá uma sobrecarga das tags usadas em um documento HTML mínimo e, se a formatação for muito usada, pode ser muito maior. Mensagens com várias partes, com cópias duplicadas do mesmo conteúdo em formatos diferentes, aumentam ainda mais o tamanho. A seção de texto simples de uma mensagem de várias partes pode ser recuperada por si mesma, no entanto, usando o comando FETCH do IMAP .

Embora a diferença no tempo de download entre texto simples e mensagem mista (que pode ser um fator de dez ou mais) fosse uma preocupação na década de 1990 (quando a maioria dos usuários acessava servidores de e-mail através de modems lentos ), em uma conexão moderna a diferença é insignificante para a maioria das pessoas, especialmente quando comparado a imagens, arquivos de música ou outros anexos comuns.

Vulnerabilidades de segurança

O HTML permite que um link seja exibido como um texto arbitrário, de modo que, em vez de exibir o URL completo, um link pode mostrar apenas parte dele ou simplesmente um nome de destino amigável. Isso pode ser usado em ataques de phishing , nos quais os usuários são levados a acreditar que um link aponta para o site de uma fonte autorizada (como um banco), visitando-o e revelando acidentalmente detalhes pessoais (como números de contas bancárias) a um golpista .

Se um e-mail contiver bugs da web (conteúdo embutido de um servidor externo, como uma imagem ), o servidor pode alertar um terceiro que o e-mail foi aberto. Este é um risco potencial de privacidade , revelando que um endereço de e-mail é real (para que possa ser direcionado no futuro) e revelando quando a mensagem foi lida.

O conteúdo HTML requer que os programas de e-mail usem mecanismos para analisar, processar e exibir o documento. Isso pode levar a mais vulnerabilidades de segurança, negação de serviço ou baixo desempenho em computadores mais antigos.

Durante os períodos de aumento das ameaças à rede, o Departamento de Defesa dos Estados Unidos converte todos os e-mails HTML recebidos em e-mails de texto.

O tipo multiparte destina-se a mostrar o mesmo conteúdo de maneiras diferentes, mas às vezes é abusado; algum spam de e-mail aproveita o formato para enganar os filtros de spam, fazendo-os acreditar que a mensagem é legítima. Eles fazem isso incluindo conteúdo inócuo na parte do texto da mensagem e colocando o spam na parte HTML (aquela que é exibida para o usuário).

A maior parte do spam de e-mail é enviada em HTML por esses motivos, portanto, os filtros de spam às vezes atribuem pontuações mais altas de spam às mensagens HTML.

Em 2018, o EFAIL foi revelado, uma vulnerabilidade grave que poderia revelar o conteúdo real de e-mails HTML criptografados a um invasor.

Veja também

Referências