Войти
Электронное письмо в формате HTML - это использование подмножества из HTML для форматирования и возможности семантической разметки в электронной почте, которые недоступны с обычным текстом : текст может быть связан без отображения URL или разрыва длинных URL-адресов в му несколько штук. Текст переносится по ширине окна просмотра, вместо того, чтобы равномерно разбивать каждую строку на 78 символов (определено в RFC 5322, что было необходимо на старых текстовых терминалах ). Он позволяет встраивать изображения, таблицы, а также диаграммы или математические формулы в виде изображений, которые иначе трудно передать (обычно с использованием ASCII art ).
Большинство графических почтовых клиентов поддерживают электронную почту в формате HTML, и многие используют его по умолчанию. Многие из этих клиентов включают в себя редактор GUI для составления электронных писем HTML и механизм визуализации для отображения полученных писем HTML.
С момента его создания ряд людей открыто выступали против всей электронной почты HTML (и даже самого MIME ) по ряду причин. Например, кампания ASCII Ribbon Campaign выступала за то, чтобы все электронные письма отправлялись в текстовом формате ASCII. Кампания не увенчалась успехом и была прекращена в 2013 году. Хотя она по-прежнему считается неуместной во многих публикациях в группах новостей и списках рассылки, ее распространение для личной и деловой почты со временем только увеличилось. Некоторые из тех, кто решительно выступал против этого, когда он впервые появился, теперь считают его в основном безвредным.
Согласно опросам компаний, занимающихся онлайн-маркетингом, использование почтовых клиентов с поддержкой HTML сейчас почти повсеместно, менее 3% респондентов сообщили, что используют только текстовые клиенты. Большинство пользователей предпочитают получать электронные письма в формате HTML, а не в виде обычного текста.
Программное обеспечение электронной почты, соответствующее RFC 2822, требуется только для поддержки обычного текста, а не форматирования HTML. Поэтому отправка электронных писем в формате HTML может привести к проблемам, если почтовый клиент получателя не поддерживает его. В худшем случае получатель увидит HTML-код вместо предполагаемого сообщения.
Среди тех почтовых клиентов, которые действительно поддерживают HTML, некоторые не отображают его в соответствии со спецификациями W3C, и многие электронные письма HTML также не соответствуют требованиям, что может вызвать проблемы с отображением или доставкой.
В частности, тег , который используется для размещения правил стиля CSS для всего документа HTML, плохо поддерживается, иногда полностью удаляется, в результате чего встроенные объявления стиля становятся стандарт де-факто, даже несмотря на то, что встроенные объявления стилей неэффективны и не используют возможности HTML для отделения стиля от содержимого. Несмотря на то, что были разработаны обходные пути, это вызвало немало разочарований среди разработчиков информационных бюллетеней, что породило grassroots проект стандартов электронной почты, который оценивает почтовые клиенты по их выполнению кислотного теста, вдохновленного те из проекта веб-стандартов, и лоббирует разработчиков с целью улучшения их продуктов. Чтобы убедить Google улучшить рендеринг в Gmail, например, они опубликовали видеомонтаж с гримасой веб-разработчиков, что привлекло внимание сотрудника.
| Клиенты | Результат (по состоянию на) |
|---|---|
| Веб-почта AOL | Надежная поддержка (13 Июль 2011 г.) |
| Apple iPhone | Надежная поддержка (13 июля 2011 г.) |
| Apple iPad | |
| Apple iPod Touch | |
| Apple Mail | Solid поддержка (28 ноября 2007 г.) |
| Apple MobileMe | Надежная поддержка (15 августа 2008 г.) |
| Eudora. Eudora OSE под кодовым названием «Пенелопа» | Надежная поддержка (28 ноября 2007 г.) |
| Microsoft Entourage | Надежная поддержка (28 ноября 2007 г.) |
| Mozilla Thunderbird | Надежная поддержка (28 ноября 2007 г.) |
| Почта Windows Live | Надежная поддержка (28 ноября 2007 г.) |
| Windows Почта | Надежная поддержка (28 ноября 2007 г.) |
| Yahoo! Mail Бета | Надежная поддержка (8 июля 2011 г.) |
| Windows Live Hotmail | Рекомендуются некоторые улучшения (8 июля 2011 г.) |
| Google Gmail | Рекомендуется улучшение (13 июля 2011 г.) |
| Lotus Notes 8 | Рекомендуется улучшение (28 ноября 2007 г.) |
| Microsoft Outlook 2007 | Рекомендуется улучшение (28 ноября 2007 г.) |
Некоторые отправители могут чрезмерно полагаться на крупные, красочные или отвлекающие шрифты, что затрудняет чтение сообщений. Для тех, кого особенно беспокоит это форматирование, некоторые пользовательские агенты позволяют читателю частично переопределить форматирование (например, Mozilla Thunderbird позволяет указать минимальный размер шрифта); однако эти возможности не доступны во всем мире. Кроме того, различие во внешнем виде отправителя и читателя может помочь отличить автора каждого раздела, улучшая читаемость.
Многие почтовые серверы настроены на автоматическое создание текстовой версии сообщения и отправку его вместе с HTML-версией, чтобы его можно было прочитать даже по тексту. -только почтовые клиенты, использующие Content-Type : multipart/alternative , как указано в RFC 1521. Само сообщение имеет тип multipart / alternateи содержит две части: первая имеет тип text / plain, которую читают только текстовые клиенты, а вторая - <67.>text / html, который читается клиентами с поддержкой HTML. Однако в текстовой версии может отсутствовать важная информация о форматировании. (Например, математическое уравнение может потерять верхний индекс и получить совершенно новое значение.)
Многие списки рассылки намеренно блокируют электронную почту HTML, либо удаляя часть HTML, чтобы просто оставить простой текст или отклонение всего сообщения.
Порядок частей имеет значение. RFC1341 утверждает, что: Обычно пользовательские агенты, составляющие составные / альтернативные сущности, должны размещать части тела в порядке возрастания предпочтения, то есть с предпочтительным форматом последним. Для составных писем с html- и обычными текстовыми версиями это означает перечисление сначала текстовой версии, а затем html-версии, в противном случае клиент может по умолчанию отображать текстовую версию, даже если доступна html-версия.
Электронное письмо в формате HTML больше обычного текста. Даже если не используется специальное форматирование, будут накладные расходы из-за тегов, используемых в минимальном HTML-документе, а при интенсивном использовании форматирования они могут быть намного выше. Сообщения, состоящие из нескольких частей, с дублированными копиями одного и того же контента в разных форматах, еще больше увеличивают размер. Тем не менее, простой текстовый раздел сообщения, состоящего из нескольких частей, может быть получен сам по себе с помощью команды FETCH IMAP.
Хотя разница во времени загрузки между обычным текстовым и смешанным сообщениями (что может быть в десять и более раз) вызывало беспокойство в 1990-х годах (когда большинство пользователей получали доступ к почтовым серверам через медленные модемы ), при современном подключении разница незначительна для большинства людей, особенно когда по сравнению с изображениями, музыкальными файлами или другими распространенными вложениями.
HTML позволяет отображать ссылку в виде произвольного текста, поэтому вместо отображения полного URL-адреса может отображаться ссылка только его часть или просто удобное для пользователя целевое имя. Это может быть использовано в фишинговых атаках, при которых пользователи обманываются, полагая, что ссылка ведет на сайт авторитетного источника (например, банка), посещают его и непреднамеренно раскрывают личные данные (например, банк номера счетов) мошеннику.
Если электронное письмо содержит веб-ошибок (встроенный контент с внешнего сервера, например изображение ), сервер может предупредить третью сторону о том, что электронное письмо было открыт. Это потенциальный риск конфиденциальности, раскрывающий, что адрес электронной почты реальный (так, чтобы он мог быть выбран в будущем), и раскрытие того, когда сообщение было прочитано. По этой причине все современные популярные почтовые клиенты (начиная с 2019 года) не загружают внешние изображения до тех пор, пока пользователь не запросит об этом.
HTML-контент требует, чтобы программы электронной почты использовали механизмы для анализа, визуализации и отображения документа. Это может привести к большему количеству уязвимостей безопасности, отказу в обслуживании или снижению производительности на старых компьютерах.
В периоды роста сетевых угроз министерство обороны США преобразует все входящие сообщения электронной почты в формате HTML в текстовые сообщения.
Тип multipart предназначен для отображения одного и того же содержимого по-разному, но это иногда злоупотребляют; некоторый электронный спам использует формат, чтобы обмануть спам-фильтры, заставив их поверить в то, что сообщение является законным. Они делают это, включая безобидный контент в текстовую часть сообщения и помещая спам в HTML-часть (которая отображается пользователю).
По этим причинам большая часть спама в электронной почте отправляется в формате HTML, поэтому фильтры спама иногда дают более высокий балл спаму для сообщений HTML.
В 2018 году была обнаружена EFAIL, серьезная уязвимость который может раскрыть злоумышленнику фактическое содержание зашифрованных электронных писем в формате HTML.
