Html mail ru attachments html: Скачать файл из письма — Help Mail.ru. Почта

Обзор фишинговых HTML-вложений в электронной почте

Использование вложенных HTML-документов в фишинговых рассылках — один из стандартных приемов злоумышленников. Он позволяет мошенникам не вставлять в тело письма ссылки, которые, как правило, легко детектируются антиспам-движками и почтовыми антивирусами. HTML дает больше возможностей замаскировать фишинговый контент, чем само письмо.

Есть два основных типа HTML-вложений, которые используют злоумышленники: HTML-файлы со ссылкой на мошеннический сайт или полноценные фишинговые страницы. В первом случае злоумышленники могут не только прятать ссылку в файл, но и автоматически перенаправлять пользователя на мошеннический сайт при открытии этого файла. Второй тип HTML-вложений позволяет обходиться без сайтов и экономить на оплате хостинга: фишинговая форма и скрипт, собирающий данные, содержатся непосредственно во вложении. К тому же HTML-файл, как и письмо, можно изменять в зависимости от предполагаемой жертвы и вектора атаки, добиваясь более точной персонализации фишингового контента.

Рис. 1. Пример письма с HTML-вложением

Как устроены фишинговые HTML-вложения

Обычно фишинговые элементы в HTML-вложениях реализованы с помощью JavaScript, который и отвечает за перенаправление пользователя на фишинговый сайт или сбор и отправку учетных данных мошенникам.

Рис. 2. Фишинговая HTML-страница и ее исходный код

Чаще всего в качестве адреса, на который HTML-страница отправляет данные, злоумышленники используют вредоносный сайт, URL которого прописан в скрипте. Некоторые вложения целиком или почти целиком состоят из JS-скрипта.

В исходном коде письма HTML-вложение выглядит как обычный текст, закодированный, как правило, в base64.

Рис. 3. Вид HTML-вложения в исходном коде письма

Если в файле присутствуют вредоносные скрипты или ссылки в виде простого текста, защитному ПО ничто не мешает быстро его распарсить и заблокировать. Чтобы избежать блокировки, злоумышленники прибегают к различным трюкам.

JavaScript-обфускация

JavaScript-обфускация — один из самых популярных приемов для зашумления HTML-вложений. Чтобы URL в файле нельзя было идентифицировать и быстро заблокировать, фишеры сильно искажают и зашумляют либо непосредственно фишинговую ссылку, либо скрипт целиком, а иногда и весь HTML-файл. В некоторых случаях злоумышленники обфусцируют код вручную, но часто они используют готовые инструменты, которых довольно много в открытом доступе, например JavaScript Obfuscator.

Если открыть в текстовом редакторе HTML-вложение из фишингового письма от имени банка HSBC, приведенного на рис. 1, то мы увидим довольно запутанный JS-код, в котором, казалось бы, нет и намека ни на открытие ссылки, ни на другое осмысленное действие.

Рис. 4. Пример обфускации в HTML-вложении

Однако в действительности это обфусцированный скрипт, перенаправляющий пользователя на фишинговый сайт. Для маскировки фишинговой ссылки злоумышленники использовали готовый инструмент, поэтому нам не составило труда деобфусцировать скрипт.

Рис. 5. Деобфусцированный скрипт из вложения в письме от имени банка HSBC: ссылка для перенаправления пользователя на фишинговый сайт

Если скрипт, ссылка или HTML-страница обфусцированы вручную, восстановить исходный код значительно сложнее. Чтобы обнаружить фишинговый контент в таком файле, может потребоваться динамический анализ — запуск и отладка кода.

Кодирование

Иногда злоумышленники используют и более интересные методы. В одном из фишинговых писем нам попалось необычное HTML-вложение. В нем, как и в примере выше, использовался JavaScript. Поскольку код был очень компактным, можно было подумать, что он делает примерно то же, что и код в поддельном письме от HSBC — перенаправляет пользователя на фишинговый сайт. Но при его запуске выяснилось, что в этом маленьком скрипте закодирована полноценная фишинговая страница.

Рис. 6. HTML-файл с использованием метода unescape() — исходный код файла содержит всего пять строк, включая пустую

Рис. 7. Фишинговая страница в HTML-вложении

Трюк, который используют злоумышленники, весьма интересен — они прибегли к устаревшему JS-методу unescape(). При передаче ему последовательности символов %xx она заменяется на эквивалент из кодировки ASCII. Если запустить скрипт и посмотреть на исходный код получившейся страницы, то мы увидим обычный HTML.

Рис. 8. «Декодированный» HTML-файл

Сейчас вместо unescape() в JavaScript используются методы decodeURI() и decodeURIComponent(), но большинство современных браузеров до сих пор поддерживают unescape(). Мы не можем сказать наверняка, почему злоумышленники обратились именно к устаревшему методу, однако это может быть связано с тем, что современные методы с большей вероятностью интерпретируются и детектируются антиспам-движками.

За первые четыре месяца 2022 года защитные решения «Лаборатории Касперского» обнаружили почти 2 миллиона писем, содержащих вредоносные HTML-вложения. Чуть менее половины из них были выявлены и заблокированы в марте — 851 328 писем. Январь был самым тихим месяцем, за который наши антиспам-решения обнаружили 299 859 писем с фишинговыми HTML-вложениями.

Количество обнаруженных писем с вредоносными HTML-вложениями, январь — апрель 2022 г. (скачать)

Заключение

Фишеры используют различные уловки, чтобы избежать блокировки рассылок и заманить на мошенническую страницу как можно больше пользователей. HTML-вложения с частично или полностью обфусцированным кодом — один из распространенных их приемов. HTML-файлы позволяют злоумышленникам использовать скрипты, обфусцировать вредоносный контент, чтобы затруднить его обнаружение, и рассылать фишинговую страницу в виде вложения, а не ссылки.

Защитные решения «Лаборатории Касперского» детектируют HTML-вложения, содержащие скрипты, вне зависимости от степени обфускации кода.

FileMaker 18: как отправлять HTML письма командой Insert From URL

Перевод + комментарии.

Оригинал статьи: FileMaker 18: How to Send HTML Emails Using Insert from URL

Автор статьи:  Mislav Kos

Обновление от 15 августа 2019 :

Оригинальный демо-файл использует функцию TextEncode для преобразования тела письма в файл. Эта функция начинает работать мучительно долго, если email содержит «тяжелые» прикрепленные файлы, например, требуется больше минуты, чтобы преобразовать в файл письмо с аттачментом весом в 3 МБ.

Демо-файл был заменен более новой версией, использующей специальные команды (script steps) для записи почтового сообщения во временную папку и последующего считывания этого файла в переменную-контейнер. С большими прикрепленными файлами (attachments) это работает намного лучше.

Обновление от 11 сентября 2019:

Заменен демо-файл, исправлен баг.

HTML Emails (электронные письма в формате HTML)

FileMaker 18 добавил в список поддерживаемых интернет-протоколов, поддерживаемых командой Insert From URL еще несколько: SMB, LDAP(S), SMTP(S). Полный перечень поддерживаемых протоколов теперь включает HTTP(S), FTP(S), FILE, SMB, LDAP(S), SMTP(S). Эта статья акцентирует внимание на использовании cURL и SMTP протокола для отправки электронной почты в формате HTML.

До FileMaker 18 письма в простом текстовом формате можно было отправлять с помощью команды Send Mail. FileMaker 17 добавил возможность включать в письмо несколько прикрепленных файлов. Теперь же можно отправлять письма с любым форматированием с множеством прикрепленных файлов. Но эта процедура не так проста, как команда Send Mail. Эта статья разжевывает многое из того, что вы должны знать, а для дополнительного практического изучения прилагается демо-файл.

Мой комментарий. На самом деле все операции с протоколами передачи данных в сети выполняет не FileMaker, а специальная библиотека libcurl, которая установлена на всех операционных системах. С помощью этой же библиотеки трансфер данных осуществляют другие программы (например, PHP). FileMaker посредством команды Insert From URL и ее настроек позволяет обратиться к этой библиотеке и использовать ее возможности. 
Отсюда следует, что

а) список поддерживаемых протоколов и в дальнейшем может расширяться;

б) справка по libcurl имеет для разработчиков известную ценность 🙂

Insert From URL

Чтобы отправить письмо [в оригинале — в формате HTML, но вообще это касается любых писем — А. В.], требуется указать следующие параметры команды Insert From URL:

• Target — сохраняет результат выполнения команды cURL
• URL — определяет адрес SMTP сервера, к которому будет обращаться cURL
• Verify SSL Certificates — определяет, нужно ли проверять SSL сертификат сервера SMTP
• cURL options — указывает опции, используемые для оптимальной настройки команды cURL

URL

Параметр URL указывает, какой именно протокол  (SMTP или SMTPS) должен быть использован, правильное доменное имя почтового сервере и порт.

Вот несколько примеров для SMTP URLs:

• smtp://smtp.mydomain.com:25/
• smtps://internal-smtp.mydomain.com:465/

Мой комментарий.  Протокол smtps следует указывать, если для диалога с почтовым сервером вы используете SSL-соединение. В большинстве почтовых серверов для SSL соединения используется порт 465 (в оригинальной статье в примере указан порт 587)

cURL Options

cURL опции указывают дополнительные инструкции для доставки почтовых сообщений. В таблице ниже описаны и прокомментированы некоторые опции (обязательные и просто полезные):

--mail-from <address>	Это email address человека, отправляющего почту. Указывайте только адрес; напр., [email protected]. Не добавляйте имя, как в примере ниже: Liam Lopez <[email protected]>.
–-mail-rcpt <address>	Используйте эту опцию, чтобы передать “To”, “Cc”, и “Bcc” адреса. Не помещайте всех получателей в одну строку. Вместо этого, повторите эту опцию для каждого получателя. Например: --mail-rcpt [email protected] --mail-rcpt [email protected]
–-user <account>:<password>	Не требуется, если SMTP server не требует аутентификации.
--upload-file <file>	Эта опция сообщает cURL где найти почтовое сообщение, которое должно быть отправлено (почтовое сообщение — это именно файл/контейнер, а не текст). В файлмейкере можно написать переменную ( напр., $mailFile) вместо <file>. Получить эту переменную можно преобразованием текста в контейнер функцией TextEncode($MessageAsText; «utf-8»; 3) Далее мы рассмотрим формат файла почтового сообщения более подробно.
–-trace <trace>	Эта опция заставит сохранить всю информацию об исполнении команды, что может быть весьма полезно для отладки. В файлмейкере можно на месте <trace> просто указать переменную, например, $trace
––show-error	Эта опция заставит функцию Get(LastExternalErrorDetail) возвращать информацию об ошибке
–-ssl-reqd	Требуется SSL/TLS. В URL в этом случае в качестве протокола указывается “smtps”.
––ssl	Пытаться использовать (но не обязательно) SSL/TLS.

***

Мой комментарий. Последние две опции мне ни разу не приходилось использовать для серверов, использующих ssl соединение. Достаточно было указать протокол smtps и порт 465

На этом месте я позволю себе небольшое отступление. Я расскажу о том, как работает SMTP протокол, как физически происходит отправка почты. Это даст понимание, какие cURL опции вообще требуются и почему.

Во время отправки почты происходит серия шагов, приложение как бы вступает в «диалог» с почтовым сервером, начиная обмениваться с ним сообщениями. Для того, чтобы этот диалог состоялся, приложение должно должно прежде всего указать сетевой адрес SMTP сервера и порт. В команде Insert From URL адрес задается параметром URL. Приложение «подаст сигнал» почтовому серверу, что у него есть новое письмо для отправки. Приложение указывает, от чьего имени будет отправляться сообщение (–mail-from <address>), сервер проверяет валидность адреса этого почтового ящика и что он не внесен в черные списки, после этого он устанавливает, должна ли проводиться аутентификация, проверяет логин и пароль  ( –user <account>:<password>) и сообщает о своей готовности принять почту. Далее приложение передает адреса, на которые сообщение должно быть отправлено (–mail-rcpt <address>), они верифицируются сервером. Наконец, сервер сообщает о готовности принять собственно почтовое сообщение (–upload-file <file>) и только тогда ему передается собственно файл электронного письма. Когда сервер принял файл, он передает код ответа ОК, а затем сообщает о том, удалось ли ему немедленно отправить почтовое сообщение адресату, либо же сообщение поставлено в очередь для отправки. Все это (диалог с сервером) делается приложением автоматически в течение сеанса связи с сервером, и повлиять на это разработчик не может никак.

Протокол организует отправку письма таким образом, чтобы нагрузка на сервер была минимальной. Электронное письмо и вся сопутствующая информация отправляются не одним пакетом, а дозированно, частями. В самом деле, зачем серверу загружать в себя целиком все сообщение (которое вместе с приложенными файлами может достигать огромных размеров), если потом окажется, что не был указан адресат или отправитель не знает логина и пароля к почтовому ящику?

Здесь важно понять и запомнить только один момент. Как мы увидим далее, само почтовое сообщение (message, –upload-file <file>) ТОЖЕ содержит в себе информацию FROM, TO, CC, BCC. Но все, что указывается в теле письма, никак не влияет на то, кому на самом деле письмо направляется. Это влияет лишь на то, как письмо отображается у получателя в почтовом клиенте. Информация может абсолютно не совпадать: то есть письмо может быть отправлено с одного почтового ящика, а у получателя в почтовом клиенте в графе FROM отображается совершенно иное; письмо адресовано множеству людей, а получатель  в графе TO видит лишь себя…

Итак, при отправке почтового сообщения приложение (FileMaker + curl) передает информацию, состоящую из двух частей. Часть информации (опции cURL) влияет на то, каким сервером, с какого почтового ящика, кому сообщение будет направляться. Другая часть информации — собственно сообщение (содержится в файле –upload-file <file>) — влияет на то,

что увидит пользователь в своем почтовом клиенте и как это будет почтовым клиентом отображаться. Следующие разделы статьи как раз посвящены тому, как правильно составлять письмо и как управлять отображением сообщения у конечного получателя.

Для примера — стандартный набор cURL опций для команды Insert From URL:

--mail-from [email protected]
--mail-rcpt [email protected]
--mail-rcpt [email protected]
--mail-rcpt [email protected]
--user [email protected]:Fdv9kK0sfR2
--dump-header $cURL_headerDump 
--show-error 
--trace $trace 
--upload-file $message

***

Message Format [формат сообщения]

Адрес почтового сервера (SMTP URL) и опции cURL сообщают утилите cURL, куда отправлять письмо, кому и как, но они прямо не указывают, ЧТО отправить. cURL опции лишь содержат ссылку на файл с письмом, который включает в себя собственно содержание того, что должно быть отправлено.  Этот файл, называемый «сообщением» (message), должен быть составлен в соответствии с определенными правилами форматирования.

Правила могут быть довольно сложными, эта сложность в значительной степени обусловлена тем, что каждый новый почтовый стандарт стремится быть совместимым с предыдущими версиями, которые он заменяет. Примером этого является правило, требующее использовать 7-битные US-ASCII символы в каждой строке текста, при этом длина строки не должна превышать 78 символов (подробнее об этом позже).

В ходе моего тестирования я обнаружил различия в степени соблюдения некоторых из этих правил. Я предполагаю, что это происходит из-за различий в том, как различные SMTP-серверы и почтовые клиенты реализовали стандарты, определяющие, как работает интернет-почта, подобно тому, как поддержка HTML и JavaScript по-разному реализована в разных веб-браузерах. Урок из этого состоит в том, что вы можете в обход стандарта заставить что-то работать для определенного SMTP-сервера или почтового клиента, но если один из этих факторов впоследствии изменится, это может привести к нарушению функциональности

MIME Formatting

В простейшем случае, если почтовое сообщение состоит только из символов ASCII, и ни одна из строк в сообщении не превышает 998 символов, и письмо не имеет прикрепленных файлов, то сообщение может быть составлено всего из одной «части».

В более сложных случаях, почтовое сообщение может использовать форматирование MIME (Multipurpose Internet Mail Extensions) для того, чтобы можно было в одном письме использовать разные кодировки, прикреплять файлы, или добавлять альтернативные версии сообщения.

Почтовое сообщение всегда состоит из двух секций: «заголовка» и «тела». В случае, если наше письмо состоит из нескольких MIME частей (multipart message, составное сообщение), то его «тело» разделяется на множество самостоятельных частей, каждое из которых в свою очередь будет иметь собственные «заголовок» и «тело».

В каждой части такого составного сообщения в его заголовке должен быть указан его MIME-тип, чтобы явно обозначить тип контента, включенного в эту часть

Ниже приведены некоторые MIME-типы и их обозначения :

• Plain text: text/plain
• HTML text: text/html
• PNG image: image/png
• PDF: application/pdf
• Zip: application/zip

Полный перечень типов MIME вы можете найти здесь.

Чтобы сообщить почтовому клиенту, где заканчивается одна часть и начинается другая, каждая часть составного сообщения разделяется специальным маркером (boundary), который должен представлять собой строку из печатаемых 7-битных ASCII символов (коды с 32 по 126) длиной в 70 символов или меньше. Эта строка не должна больше встречаться нигде во вложенных частях. Вот пример допустимого маркера: gc0p4Jq0M2Yt08j34c0p.

Каждый раз, когда маркер используется [в тексте сообщения для разделения частей], он сопровождается двумя дефисами слева, а если этот маркер употреблен в последний раз, чтобы показать завершение части, то два дефиса добавляются и справа.

(Мой комментарий. Любое почтовое сообщение — это ничто иное, как длинная простыня текста, которая составлена в строгом соответствии с требованиями стандартов). Для того, чтобы почтовый клиент правильно отобразил это письмо, мы должны явно указать, из скольких частей состоит письмо, как эти части можно отделить друг от друга ( с помощью какого маркера) и как следует интерпретировать (отображать) ту или иную часть. Благодаря таким «подсказкам» (указание MIME-типа) почтовый клиент покажет простой текст как простой текст, HTML текст отобразит отформатированным, прикрепленную картинку отобразит как картинку, а прикрепленный PDF файл отобразит как соответствующего вида иконку).

Поэтому для каждой части предусмотрен собственный заголовок)

MIME Parts (MIME-разделы)

Существует три типа разделов MIME и, следовательно, три вида маркеров.

Alternative: Маркер “alternative” отделяет альтернативные части сообщения (внутри раздела Alternative). Например, вы отправляете письмо в формате HTML, но опасаетесь, что получатель не сможет прочитать это письмо, потому что пользуется слишком старым почтовым клиентом: его приложение не отображает форматированный текст. Тогда вы в почтовом сообщении можете дополнить HTML-версию письма альтернативной текстовой  версией; она будет отображена, если по каким-то причинам невозможно отобразить HTML. Строго говоря, альтернативных частей может быть сколько угодно (например, PDF/HTML/plain text), но получатель при просмотре почтового сообщения увидит только одну из них.

Два других типа MIME-разделов связаны с вложениями (attachments).  Вложения могут быть встроены в само сообщение электронной почты (напр., в виде картинки, баннера), а могут быть прикреплены к письму таким образом, что прежде чем их открыть, получатель письма должен будет их скачать (такие вложения обычно отображаются в виде значка внизу письма).

Related: маркеры «related» отделяют встроенные вложения одно от другого и от сообщения, в которое они встраиваются.  MIME-раздел Related может использоваться, например, для оформления красивого HTML текста с картинками или фотографиями (HTML будет ссылаться на картинки, которые прикреплены к письму).

Mixed: Маркеры «mixed» отделяют не встраиваемые вложения одно от другого и от остальной части сообщения. Стандартное письмо из приложения файлмейкер с одним или несколькими вложениями, оформляется с помощью именно этого MIME-раздела.

Вероятно на этом месте у вас уже закружилась голова от обилия деталей, поэтому, надеюсь, иллюстрация ниже поможет лучше во всем разобраться.

Секция основного заголовка  может содержать такие поля, как From, To, Cc, Subject, и Date, но помните, что поля To и CC не используются для того, чтобы определить, кому письмо должно быть доставлено. Такая информация определяется cURL опциями (о чем рассказано выше). Аналогом может служить бумажное письмо, которое содержит адрес доставки и на конверте, и в самом письме. Для доставки используется только адрес, указанный на конверте. Адрес же, отображаемый в верхней части письма, помещается туда только для информации.

MIME Format Example (Пример MIME-форматирования)

Ниже приведен пример простого почтового сообщения без MIME форматирования (без MIME разделов):

From: Liam Lopez <[email protected]>
To: Cameron Turner <[email protected]>, April Wright <[email protected]>,
 Theodore Hall <[email protected]>
Cc: Zara Allen <[email protected]>
Subject: Test
Date: Wed, 14 May 2019 19:34:21
Content-Type: text/html; charset="utf8"
<html><body>Hello, here is my <b>bold</b> email message. </body></html>

Несколько моментов, на которые стоит обратить внимание (!!!):

• «Тело» почтового сообщения отделяется от секции заголовка пустой строкой.
• Каждая строка отделяется символами CRLF (перевод каретки+новая строка).
• Каждая строка должна иметь длину менее 78 символов. Технический лимит составляет на самом деле 998 символов, но рекомендуется ограничиться 78. Более длинные строки должны разбиваться на несколько строк, начинающихся с символа «пробел».
• Сообщение (и «заголовок» и «тело») должны состоять из 7-битных символов ASCII.
• Адреса Bcc обычно не включаются в заголовок письма.

(Мой комментарий. Пробелы в начале и особенно в конце строки в секции заголовка сложно разглядеть, но именно они обычно и служат источником проблем. Если письмо доходит адресату в «странном виде», проверяйте пробелы)

Для MIME-форматированных сообщений, не-ASCII данные могут быть конвертированы в 7-bit ASCII с помощью кодирования в “quoted-printable” или base64 (RFC 2045). Если контент сообщения состоит преимущественно из латиницы, то кодирование “quoted-printable” считается предпочтительным, поскольку упрощает решение возникающих проблем. Обе названные схемы кодирования автоматически разбивают контент на строки длиной 76 символов.

Quoted-printable Encoded Text

Ниже пример того, как выглядит текст, закодированный в quoted-printable:

Original:

Congratulations to Luka Modrić ??⚽ for winning the Ballon d'Or!

Quoted-printable:

Congratulations to Luka Modri=C4=87 =F0=9F=87=AD=F0=9F=87=B7=E2=9A=BD for w=
inning the Ballon d'Or!

К сожалению, FileMaker не имеет встроенной функции кодирования в quoted-printable, поэтому я использовал кодирование в base64 в файле примера.

Additional MIME Examples (дополнительные примеры использования MIME)

Вот несколько дополнительных наглядных примеров, показывающих как составляются почтовые сообщения ( MIME и не MIME) .

Знак абзаца (¶) используется для обозначения мест, где следует вставить пустую строку.  Для упрощения, некоторые фрагменты текста представлены «заполнителями» (placeholders). Последние обозначены угловыми скобками, например: <<EMAIL_MESSAGE_HTML_TEXT>>.

HTML Email Only

Первый пример показывает простое электронное письмо в формате HTML, оформленное без использования MIME

Когда я тестировал отправку писем этого типа, у меня получалось включать в текст символы не ASCII, но стандарт указывает, что должны использоваться только печатаемые 7-битные ASCII символы. Это еще один пример высказанного ранее мнения о том, что разные SMTP-серверы и почтовые клиенты реализуют стандарты по-разному, в том числе создавая поддержку, которая позволяет расширить правила. Тем не менее, если вы хотите быть уверенными, что ваша имплементация отправки почты будет продолжать работать независимо от того, какой сервер или клиент используется, лучше придерживаться правил, установленных стандартами.

Рис. 1 – Простое  HTML письмо без выделения MIME разделов

HTML Email + Attached Files (HTML письмо + вложенные файлы)

Второй пример показывает два вложения, добавленные к HTML письму. В этом случае вложения НЕ встроены в сообщение, они отображаются в виде иконок, на которые нужно кликнуть, чтобы скачать.

Рис 3 – Два вложения, добавленные к электронному письму в формате HTML

<<preamble message>> здесь добавлено для того, чтобы почтовые клиенты, не совместимые с MIME, могли отобразить сообщение, понятное пользователю. Преамбула может содержать какой угодно текст, например:

This is a message in MIME format.  If you see this, your mail reader does not support this format.

HTML Email + Embedded Files + Attached Files (HTML письмо + встроенные файлы + прикрепленные файлы)

Следующие пример добавляет два дополнительных вложения, но не так, как предыдущие. Эти файлы встроены в письмо, составляют часть его содержимого. Такой эффект достигается, если параметру «content disposition» присвоить значение «inline» .

Рис 4 – Два файла, встроенных в письмо

Обычно в текст письма встраивают файлы-картинки. Когда HTML для электронного письма построен, в нем можно прописать ссылку на эти вложения, используя идентификатор (Content ID), который определен в заголовке. Например, предположим, что content ID для одного из вложений определен следующим образом:

Content-ID: <[email protected]>

Тогда картинка внутри HTML будет иметь такую ссылку:

<img src="cid:[email protected]">

Plain Text Email + HTML Email + Embedded Files + Attached Files

Последний пример использует маркер «alternative» для добавления plain text версии электронного сообщения.

Рис 5 – Добавление plain text версии к электронному письму

Using Encoded-Words in Message Headers (использование Encoded-Words в заголовках сообщений)

Предшествующие примеры описывали, как можно закодировать тело (body) сообщения, чтобы учесть наличие в нем не ASCII символов, но что если заголовок сообщения (header) тоже содержит неподдерживаемые символы?

Например, имя получателя или тема письма могут содержать символы за пределами 7-битного диапазона ASCII. В этом случае, вы можете использовать Encoded-Words, чтобы конвертировать последовательность не поддерживаемых символов, используя следующий синтаксис:

=?charset?encoding?encoded-text?=

Предположим, например, что тема электронного письма состоит просто из следующего улыбающегося эмодзи: ?

Будучи преобразованным в base64 encoded-word, заголовок темы сообщения может отображаться как:

Subject: =?UTF-8?B?8J+Yiw==?=

В этом примере, кодировка (charset) указана как as “UTF-8”, конвертация задана литерой “B” ( base64), и собственно конвертированный текст указан как “8J+Yiw==”, что является base64 эквивалентом смайлика ?

Конвертировать текст можно двумя способами: base64 (опция задается литерой  “B”) и  quoted-printable (опция задается литерой «Q»)

Похожим образом, следующий заголовок получателя письма (To)…

To: 老子 <laotzu@email. com>

…может быть преобразован в:

To: =?UTF-8?B?6ICB5a2Q?= <[email protected]>

Чтобы больше узнать о правилах и синтаксе преобразования encoded-word, читайте стандарт RFC 2047.

Conclusions and Demo File (выводы и демо-файл)

Теперь у нас есть возможность отправлять почту в формате HTML, но это достигается более сложным способом по сравнению с командой Send Mail.

Get the demo file

Прилагаемый демо-файл включает в себя сценарий, который берет большую часть работы на себя. Сценарий написан так, что его можно копировать, переносить в ваши решения без необходимости создавать новые таблицы или поля. Однако скрипт использует пользовательские функции “GetMIMEType” и “ErrorMessage”, поэтому вам придется скопировать их перед копированием скрипта.

Демо-файл поддерживает полностью стилизованные письма, которые можно создавать, используя HTML или форматирование текста в файлмейкере (используя функцию GetAsCSS). Вложения могут быть обозначены как встроенные (“Inline”), или как обычные, не встроенные (“Attachment”).

Однако, демонстрационный файл не поддерживает альтернативные части MIME, которые используются для предоставления альтернативных версий почтового сообщения. И он не выполняет разбиения строк или кодирования заголовков. Так что если заголовки в вашем электронном сообщений (напр, тема или адрес электронной почты получателя) содержат не ASCII символы или имеют длину больше 998 символов, письмо возможно не будет отправлено.

Если у вас нет SMTP-сервера, доступного для тестирования, вы можете создать Gmail  акаунт и использовать SMTP-сервер Gmail. Если у вас включена двухфакторная аутентификация (а вы должны ее включить), вам потребуется создать пароль для конкретного приложения. Вы можете следовать  этим инструкциям, чтобы сделать так.

Ну, и в заключении я хотел бы поблагодарить моих коллег  Brian Engert и Marcelo Piñeyro за их помощь в подготовке данного поста и демо-файла.

References (ссылки)

• Message format for non-MIME emails: https://en.wikipedia.org/wiki/Email#Message_format
• RFC 5322 standard for non-MIME emails: https://tools. ietf.org/html/rfc5322
• Wikipedia article on MIME messages (includes links to the relevant RFC standards): https://en.wikipedia.org/wiki/MIME
• Message header fields: https://www.iana.org/assignments/message-headers/message-headers.xhtml
• Encoded-word syntax (RFP 2047): https://tools.ietf.org/html/rfc2047
• Complete list of MIME types: https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types/Complete_list_of_MIME_types
• An excellent guide to multi-part MIME messages written by Daniel Clark: http://qcode.co.uk/post/70

Мой комментарий. Последнюю часть я оставил без изменений. От себя добавлю ссылки на переведенные на русский язык стандарты и спецификации, и прочие полезные ресурсы по теме
RFC 5321 — Протокол SMTP

RFC 1521 — Почтовый стандарт MIME

Список MIME типов для импорта

Еще один список MIME типов

Коды ошибок SMTP сервера

ruby ​​— Отправка электронного письма в формате HTML с вложением

спросил 9 лет, 6 месяцев назад

Изменено 9 лет, 1 месяц назад

Просмотрено 11 тысяч раз

У меня есть вопрос о net/smtp

Для писем в формате html вы должны установить это в заголовке письма тип содержимого: text/html . Однако, если вы хотите отправить вложение, вам нужно изменить его на тип контента : multipart/mixed . Что сделало бы электронную почту в формате html… больше не в формате html.

Итак, вопрос… как выполнить и то, и другое? HTML и вложение?

Спасибо

• ruby ​​
• электронная почта
• mime
• вложения электронной почты

Каждая часть составного электронного письма имеет свой тип MIME. Таким образом, несмотря на то, что тип содержимого электронной почты «составной/смешанный», каждое вложение имеет свой собственный тип MIME (текст, HTML и т. д.).

Вот пример составного письма из MIME и HTML в электронной почте Дуга Стейнванда:

 Кому: [email protected]
Тема: тест MIME
Тип контента: составной/смешанный; граница = "границаСтрока"
--theBoundaryString
В этой части идет обычное текстовое сообщение. Обратите внимание, что это
имеет пустую строку перед началом, что означает, что это
часть не имеет дополнительных заголовков. 
--theBoundaryString
Тип содержимого: текст/html
Контент-передача-кодирование: 7 бит
Content-Disposition: встроенный
База контента: "http://somewebsite.com/"
Это
проверить.
--theBoundaryString--
 

Здесь видно, что текстовое вложение не имеет явного типа содержимого. Если вложение не имеет явного типа содержимого, это US ASCII TEXT. Вложение HTML имеет тип содержимого «text/html». Могут быть и другие вложения, каждое со своим типом MIME.

Почтовый гем упрощает отправку и анализ электронных писем, состоящих из нескольких частей. Он стабилен, хорошо поддерживается и широко используется.

В этом примере из файла README показано, как отправить письмо, состоящее из нескольких частей: текстовой и HTML-части:

 почта = Mail.deliver сделать
  на '[email protected]'
  от «Микель Линдсаар »
  subject 'Первое составное электронное письмо, отправленное через Mail'
  text_part сделать
    body 'Это обычный текст'
  конец
  html_part сделать
    content_type 'текст/html; кодировка = UTF-8'
    body ' 
Это HTML
 '
  конец
конец
 

2

Зарегистрируйтесь или войдите в систему

Зарегистрируйтесь с помощью Google

Зарегистрироваться через Facebook

Зарегистрируйтесь, используя электронную почту и пароль

Опубликовать как гость

Электронная почта

Требуется, но не отображается

Опубликовать как гость

Электронная почта

Требуется, но не отображается

HTML-вложений остаются популярными среди участников фишинга в 2022 году

HTML-файлы остаются одними из самых популярных вложений, используемых в фишинговых атаках в течение первых четырех месяцев 2022 года, что свидетельствует о том, что этот метод остается эффективным против антиспамовых систем и хорошо работает с жертвами сами себя.

HTML (язык гипертекстовой разметки) — это язык, который определяет значение и структуру веб-контента. Файлы HTML представляют собой документы с интерактивным содержимым, разработанные специально для цифрового просмотра в веб-браузерах.

В фишинговых сообщениях HTML-файлы обычно используются для перенаправления пользователей на вредоносные сайты, загрузки файлов или даже для локального отображения фишинговых форм в браузере.

Поскольку HTML не является вредоносным, вложения, как правило, не обнаруживаются продуктами для обеспечения безопасности электронной почты, поэтому они хорошо попадают в почтовые ящики получателей.

Фишинговое вложение HTML, имитирующее логин Microsoft
Источник: BleepingComputer

Статистические данные «Лаборатории Касперского» показывают, что тенденция использования вложений HTML во вредоносных клиентов в первые четыре месяца года.

Кульминация цифр пришлась на март 2022 года, когда данные телеметрии «Лаборатории Касперского» насчитали 851 000 обнаружений, а падение до 387 000 в апреле могло быть лишь кратковременным сдвигом.

Обнаружение вредоносных HTML-вложений (Kaspersky)

Как HTML ускользает от обнаружения

Фишинговые формы, механизмы перенаправления и элементы кражи данных в HTML-вложениях обычно реализуются с использованием различных методов, от простых перенаправлений до запутывания JavaScript и скрыть фишинговые формы.

При наличии в сообщениях электронной почты вложения кодируются с помощью base64, что позволяет защищенным почтовым шлюзам и антивирусным программам легко сканировать вложения на наличие вредоносных URL-адресов, сценариев или других действий.

Чтобы избежать обнаружения, злоумышленники обычно используют JavaScript во вложениях HTML, которые будут использоваться для создания вредоносной фишинговой формы или перенаправления.

Использование JavaScript во вложениях HTML для сокрытия вредоносных URL-адресов и поведения называется контрабандой HTML и стало очень популярным методом за последние несколько лет.

Чтобы еще больше усложнить обнаружение вредоносных скриптов, субъекты угроз запутывают их с помощью свободно доступных инструментов, которые могут принимать пользовательскую конфигурацию для получения уникального и, следовательно, менее вероятного обнаружения результата и, таким образом, уклоняться от обнаружения.

Например, в ноябре мы сообщали, что злоумышленники использовали код Морзе в своем HTML-вложении, чтобы скрыть фишинговую форму, которая отображалась во вложении HTML при открытии.

Исходный код фишингового вложения в формате HTML

«Лаборатория Касперского» отмечает, что в некоторых случаях злоумышленники используют методы кодирования, включающие устаревшие функции, такие как «unescape()», которая заменяет последовательности символов «%xx» в строке их эквивалентами ASCII.

Хотя сегодня эта функция была заменена функциями decodeURI() и decodeURIComponent(), большинство современных браузеров по-прежнему поддерживают ее. Тем не менее, средства безопасности и механизмы защиты от спама, которые больше ориентируются на текущие методы, могут его игнорировать.

Заключение

Всплеск распространения HTML-вложений впервые наблюдался в 2019 году, но в 2022 году они по-прежнему широко используются в фишинговых кампаниях, поэтому их следует рассматривать как тревожные сигналы.