электронное письмо в формате HTML
 |
Электронная почта в формате HTML это использование подмножества HTML для — обеспечения возможностей форматирования и семантической разметки в электронной почте , которые недоступны для обычного текста : [1] Текст можно связать без отображения URL-адреса или разбиения длинных URL-адресов на несколько частей. Текст переносится по ширине окна просмотра, а не равномерно разбивает каждую строку на 78 символов (определено в RFC 5322, что было необходимо на старых текстовых терминалах ). Он позволяет вставлять изображения, таблицы , а также диаграммы или математические формулы в виде изображений, которые иначе трудно передать (обычно с использованием символов ASCII ).
Принятие
[ редактировать ]Большинство графических почтовых клиентов поддерживают электронную почту в формате HTML, и многие используют его по умолчанию. Многие из этих клиентов включают в себя как редактор графического интерфейса для составления электронных писем в формате HTML, так и механизм рендеринга для отображения полученных электронных писем в формате HTML.
С момента его создания многие люди открыто выступали против всей электронной почты в формате HTML (и даже самого MIME ) по разным причинам. [2] Например, кампания ASCII Ribbon Campaign выступала за то, чтобы все электронные письма отправлялись в ASCII текстовом формате . Кампания оказалась неудачной и была прекращена в 2013 году. [3] [4] Хотя во многих новостных группах и списках рассылки все еще считается неприемлемым, его применение для личной и деловой почты со временем только возросло. Некоторые из тех, кто решительно выступал против этого метода, когда он впервые появился, теперь считают его в основном безвредным. [5]
Согласно опросам компаний, занимающихся онлайн-маркетингом , внедрение почтовых клиентов с поддержкой HTML в настоящее время почти повсеместно, при этом менее 3% сообщают, что используют только текстовые клиенты. [6] Большинство пользователей предпочитают получать электронные письма в формате HTML вместо обычного текста. [7] [8]
Совместимость
[ редактировать ]Программное обеспечение электронной почты, соответствующее RFC 2822, должно поддерживать только обычный текст, а не форматирование HTML. Поэтому отправка электронных писем в формате HTML может привести к проблемам, если почтовый клиент получателя не поддерживает эту функцию. В худшем случае получатель увидит HTML-код вместо предполагаемого сообщения.
Среди тех почтовых клиентов, которые поддерживают HTML, некоторые не отображают его в соответствии со спецификациями W3C , и многие электронные письма в формате HTML также не соответствуют требованиям, что может вызвать проблемы с рендерингом или доставкой.
В частности, <head> Тег, который используется для размещения правил стиля CSS для всего HTML-документа, не поддерживается должным образом, а иногда полностью удаляется, в результате чего встроенные объявления стилей становятся де-факто стандартом , хотя встроенные объявления стилей неэффективны и не могут быть реализованы. воспользуйтесь преимуществами способности HTML отделять стиль от содержания. [ нужна ссылка ] Несмотря на то, что были разработаны обходные пути, [9] это вызвало немалое разочарование среди разработчиков информационных бюллетеней, породив массовый проект стандартов электронной почты, который оценивает почтовые клиенты по результатам их прохождения «кислотного теста», вдохновленный проектом веб-стандартов , и лоббирует разработчиков с целью улучшения их продуктов. Например, чтобы убедить Google улучшить рендеринг в Gmail , они опубликовали видеомонтаж гримасничающих веб-разработчиков. [10] что приводит к вниманию со стороны сотрудника.
| Клиенты | Результат (по состоянию на) |
|---|---|
| Веб-почта AOL | Твердая поддержка (13 июля 2011 г.) |
| Яблоко айфон | Твердая поддержка (13 июля 2011 г.) |
| Apple iPad | |
| Apple iPod Тач | |
| Apple Почта | Твердая поддержка (28 ноября 2007 г.) |
| Apple MobileMe | Твердая поддержка (15 августа 2008 г.) |
| Юдора Юдора ОСЕ под кодовым названием «Пенелопа». | Твердая поддержка (28 ноября 2007 г.) |
| Microsoft Антураж | Твердая поддержка (28 ноября 2007 г.) |
| Мозилла Тандерберд | Твердая поддержка (28 ноября 2007 г.) |
| Почта Windows Live | Твердая поддержка (28 ноября 2007 г.) |
| Почта Windows | Твердая поддержка (28 ноября 2007 г.) |
| Yahoo! Почта бета | Твердая поддержка (8 июля 2011 г.) |
| Windows Live Hotmail | Рекомендуется некоторое улучшение (8 июля 2011 г.) |
| Google Gmail | Рекомендуется улучшение (13 июля 2011 г.) |
| Лотос Нотс 8 | Рекомендовано улучшение (28 ноября 2007 г.) |
| Microsoft Outlook 2007 | Рекомендовано улучшение (28 ноября 2007 г.) |
Стиль
[ редактировать ]Некоторые отправители могут чрезмерно полагаться на крупные, красочные или отвлекающие шрифты , что затрудняет чтение сообщений. [11] Для тех, кого особенно беспокоит такое форматирование, некоторые пользовательские агенты позволяют читателю частично переопределять форматирование (например, Mozilla Thunderbird позволяет указывать минимальный размер шрифта); однако эти возможности не доступны глобально. Кроме того, разница во внешнем виде между отправителем и читателем может помочь отличить автора каждого раздела, улучшая читабельность.
Многочастные форматы
[ редактировать ]Многие почтовые серверы настроены на автоматическое создание текстовой версии сообщения и отправку ее вместе с HTML-версией, чтобы гарантировать, что оно может быть прочитано даже текстовыми почтовыми клиентами , используя Content-Type: multipart/alternative, как указано в RFC 1521. [12] [13] [14] Само сообщение имеет тип multipart/alternative, и содержит две части, первая из которых типа text/plain, который читается только текстовыми клиентами, а второй с text/html, который читается клиентами с поддержкой HTML. Однако в текстовой версии может отсутствовать важная информация о форматировании. (Например, математическое уравнение может потерять верхний индекс и приобрести совершенно новый смысл.)
Много [ нужна ссылка ] Списки рассылки намеренно блокируют электронную почту в формате HTML, либо удаляя HTML-часть и оставляя только текстовую часть, либо отвергая все сообщение. [ нужна ссылка ]
Порядок частей имеет большое значение. В RFC1341 говорится, что: В общем, пользовательские агенты, составляющие составные/альтернативные сущности, должны размещать части тела в порядке возрастания предпочтений, то есть предпочтительный формат должен быть последним. [15] Для составных электронных писем с версиями в формате HTML и обычным текстом это означает, что сначала указывается версия в виде обычного текста, а затем версия в формате html, в противном случае клиент может по умолчанию отображать версию в виде обычного текста, даже если доступна версия в формате html.
Размер сообщения
[ редактировать ]Электронная почта в формате HTML больше обычного текста. Даже если не используется специальное форматирование, накладные расходы будут связаны с тегами, используемыми в минимальном HTML-документе, а если форматирование используется интенсивно, они могут быть намного выше. Сообщения, состоящие из нескольких частей, с дубликатами одного и того же контента в разных форматах, еще больше увеличивают размер. Однако текстовую часть сообщения, состоящего из нескольких частей, можно получить самостоятельно с помощью . команды FETCH IMAP [16]
Хотя разница во времени загрузки между обычной текстовой почтой и почтой со смешанными сообщениями (которая может составлять десять и более раз) вызывала беспокойство в 1990-х годах (когда большинство пользователей обращались к серверам электронной почты через медленные модемы ), при современном соединении эта разница составляет для большинства людей пренебрежимо мал, особенно по сравнению с изображениями, музыкальными файлами или другими распространенными вложениями. [17]
Уязвимости безопасности
[ редактировать ]HTML позволяет скрыть ссылку, но отобразить ее в виде произвольного текста, например, удобного для пользователя целевого имени. Это можно использовать в фишинговых атаках, в ходе которых пользователей обманом заставляют получить доступ к поддельному веб-сайту и раскрыть мошеннику личные данные (например, номера банковских счетов).
Если электронное письмо содержит встроенное содержимое с внешнего сервера, например изображение , для его получения требуется запрос к внешнему серверу, который определяет, где изображение будет отображаться, и другую информацию о получателе. Веб-ошибки — это специально созданные изображения (обычно уникальные для каждого отдельного электронного письма), предназначенные для отслеживания этого электронного письма и позволяющие его создателю узнать, что электронное письмо было открыто. Помимо прочего, это показывает, что адрес электронной почты является реальным и может стать мишенью в будущем.
Некоторые фишинговые атаки основаны на определенных функциях HTML: [18]
- Олицетворение бренда с помощью процедурно сгенерированной графики (такая графика может выглядеть как изображение, защищенное товарным знаком, но избежать проверки безопасности, поскольку отсутствует файл)
- Текст, содержащий невидимые символы Юникода или шрифт нулевой высоты, чтобы запутать сканирование безопасности.
- URI, специфичный для жертвы: вредоносная ссылка кодирует специальную информацию, которая позволяет персонализировать поддельный сайт (представляя его как учетную запись жертвы), чтобы сделать его более убедительным.
Отображение содержимого HTML часто требует, чтобы клиентская программа вызывала специальные процедуры для анализа и отображения текста в формате HTML; намеренно неправильно закодированный контент может затем использовать ошибки в этих процедурах для нарушения безопасности. [ нужна ссылка ] Запросы на специальные шрифты и т. д. также могут влиять на системные ресурсы. [ нужна ссылка ]
В периоды роста сетевых угроз Министерство обороны США преобразовывало входящую электронную почту пользователя в формате HTML в текстовую электронную почту. [19]
Тип multipart предназначен для отображения одного и того же содержимого разными способами, но иногда этим злоупотребляют; некоторый почтовый спам использует этот формат, чтобы заставить спам-фильтры поверить в то, что сообщение является законным. Они делают это, включая безобидный контент в текстовую часть сообщения и помещая спам в HTML-часть (ту, которая отображается пользователю).
Большая часть спама по электронной почте рассылается в формате HTML. [ нужна ссылка ] по этим причинам спам-фильтры иногда придают HTML-сообщениям более высокий рейтинг спама. [ нужна ссылка ]
В 2018 году была обнаружена уязвимость ( EFAIL ) обработки HTML многих распространенных почтовых клиентов, из-за которой расшифрованный текст частей электронной почты, зашифрованных PGP или S/MIME, может быть отправлен в качестве атрибута на внешний адрес изображения, если внешний адрес изображение запрошено. Эта уязвимость присутствовала в Thunderbird, macOS Mail, Outlook, а позже в Gmail и Apple Mail. [20]
См. также
[ редактировать ]- Обогащенный текст — HTML-подобная система для электронной почты с использованием MIME.
- Электронная почта
Ссылки
[ редактировать ]- ^ «Текстовая электронная почта против электронной почты в формате HTML – плюсы и минусы | Thunder Mailer – программное обеспечение для массовой рассылки по электронной почте» . Thundermailer.com . Проверено 30 января 2016 г.
- ^ Электронная почта в формате HTML: по возможности отключайте его!
- ^ «Официальная домашняя страница кампании Ascii Ribbon» . Архивировано из оригинала 11 марта 2010 года . Проверено 30 января 2016 г.
- ^ «Отключение ленточной кампании ASCII — форум Pale Moon» . forum.palemoon.org . Архивировано из оригинала 3 февраля 2016 года . Проверено 30 января 2016 г.
- ^ Электронная почта в формате HTML: опрос (Скот Хакер, автор книги « Почему HTML в электронной почте — плохая идея» ), обсуждает, как его чувства изменились с 1990-х годов.
- ^ «Статистика и показатели электронного маркетинга – EmailLabs» . 29 марта 2007 г. Архивировано из оригинала 29 марта 2007 г. Проверено 30 января 2016 г.
HTML пользуется почти универсальным признанием среди потребителей: опрос потребителей Jupiter Research показал, что только 3% получают только текстовые электронные письма.
- ^ Гроссман, Эдвард (9 июля 2002 г.). «Использование почтового клиента в реальном мире: достоверные данные | ClickZ» . clickz.com . Проверено 30 января 2016 г.
Вы предпочитаете получать электронные письма в формате HTML или текстовые сообщения? HTML: 41,95%, Текст: 31,52%, Нет предпочтений: 26,53%
- ^ «Наука электронного маркетинга» . SlideShare.net . Проверено 30 января 2016 г.
В каком формате вы предпочитаете получать электронные письма от компаний? HTML: 88%, обычный текст: 12%
- ^ Диалект < http://dialect.ca/ >. «Premailer: сделайте CSS встроенным для электронной почты в формате HTML» . Premailer.dialect.ca . Проверено 24 июня 2012 г.
{{cite web}}: Внешняя ссылка в|author= - ^ «Призыв Gmail 2008 | Проект стандартов электронной почты» . Электронная почта-standards.org. Архивировано из оригинала 15 мая 2012 года . Проверено 24 июня 2012 г.
- ^ Шобе, Мэтт (12 октября 2004 г.). «Довольно справедливый аргумент против электронной почты в формате HTML» . Burningdoor.com. Архивировано из оригинала 24 апреля 2012 года . Проверено 24 июня 2012 г.
- ^ RFC 1521 7.2.3. Подтип Multipart/alternative
- ^ «TN1010-11-2: Multipart/Alternative — изящная обработка почтовых клиентов, страдающих HTML-фобией» (PDF) . Проверено 24 июня 2012 г.
- ^ «Одновременная отправка электронной почты в формате HTML и обычного текста» . Wilsonweb.com. 28 апреля 2000 года . Проверено 24 июня 2012 г.
- ^ «RFC1341, раздел 7.2. Тип содержимого Multipart» . Проверено 15 июля 2014 г.
- ^ «Действительно ли мы хотим отправлять веб-страницы по электронной почте?» . Дсв.су.се. Проверено 24 июня 2012 г.
- ^ Электронная почта в формате HTML – все еще зло?
- ^ «Методы отслеживания тенденций в электронной почте: как современные фишинговые письма скрываются на виду» . Microsoft.com. 18 августа 2021 г.
- ^ «Министерство обороны запрещает использование электронной почты в формате HTML и Outlook Web Access» . nextgov.com. 22 декабря 2006 года . Проверено 22 июня 2024 г.
- ^ «Дефекты Efail десятилетней давности могут привести к утечке открытого текста электронных писем, зашифрованных с помощью PGP и S/MIME» . arstechnica.com . 14 мая 2018 г.