Защита электронной почты с помощью DMARC и ARC

Джон Левин

Спецификация DMARC начиналась как относительно простой метод предотвращения фишинга, который взяли на вооружение известные коммерческие домены. Затем этот метод был переориентирован на борьбу со спамом. Хотя такое перепрофилирование в основном и решило проблему спамового подлога для многих систем, оно также нанесло значительный сопутствующий ущерб спискам рассылки электронной почты. Для того, чтобы справиться с недостатками DMARC, группа крупных провайдеров электронной почты разработала механизм аутентификации ARC, который позволяет в каком-то смысле изучить историю сообщения и узнать, каким образом не согласованное в рамках DMARC сообщение приобрело такой статус.

В современном Интернете электронная почта превратилась в один из самых полезных сервисов, но одновременно стала и наиболее разочаровывающим. Лучшим её свойством стало то, что любой человек может отправить сообщение кому угодно без предварительной договорённости, а худшим недостатком стало то же самое – возможность отправить сообщение кому угодно без предварительной договорённости. По мере того, как в 90-е годы прошлого века и в нулевые нынешнего электронная почта становилась всё более вездесущей, росла и доля сообщений, которые адресаты не хотели бы получать. В 2005 году появились статьи о спаме за авторством Дейва Крокера (Dave Crocker)¹ и Джона Кленсина (John Klensin)². С той поры получили широкое распространение несколько описанных в статье Крокера методов борьбы со спамом, а сама проблема спама стала ещё острее.

Важно проводить различие между спамом – незапрашиваемыми сообщениями, которые распространяются с помощью массовой рассылки, и фишингом (phishing) – письмами, которые отправляются с целью введения получателя в заблуждение с последующей попыткой получить от него данные учётных записей/счетов или другой частной информации. (Некоторые фишинговые письма являются массовыми, а другие отправляются конкретным жертвам; последний метод получил название адресный фишинг (Spear phishing).) Начиная с 2007 года компания PayPal, ставшая одним из самых частых целей фишинга, начала сотрудничать с некоторыми крупными почтовыми системами, стремясь не допустить попадания фишинговых сообщений в почтовые ящики получателей. В основе лежала идея о том, что системы получателя смогут идентифицировать настоящее электронное письмо от PayPal и отбрасывать любые другие сообщения, «притворяющиеся» письмами PayPal. Для того, чтобы обобщить этот метод и способствовать его распространению, в 2012 году отраслевая группа инициировала проект DMARC. В 2015 году спецификация Domain-based Message Authentication, Reporting & Conformance (DMARC) была опубликована в качестве информационного RFC³, и в настоящее время эта технология наиболее широко применяется в крупных почтовых системах.

Принцип работы DMARC заключается в привязывании адреса в заголовке «From:» RFC 5322⁴ сообщения к почтовой аутентификации и в предоставлении возможности оператору домена предлагать получателям почты рекомендации по используемым политикам. Если сообщение проходит успешную валидацию методами Sender Policy Framework (SPF) или DomainKeys Identified Mail (DKIM), а домен при валидации совпадает с доменом в заголовке From:, то сообщение считается «согласованным» с DMARC. Почтовая система-отправитель может публиковать записи политик DMARC в DNS, «требуя», чтобы системы-получатели отправляли на карантин (помещали в папку спама) или отбраковывали несогласованные сообщения. Весь этот механизм очень хорошо работает в изначальной области применения DMARC – почте между бизнесом и потребителем (B2C), в рамках которой отправляющая сторона обычно полностью контролирует все сообщения, отправленные из своего домена. Особенно успешно этот механизм зарекомендовал себя для PayPal. В этой системе вся почта представляет собой вариации на тему «зайдите в свою учётную запись, чтобы узнать, что нового», поэтому случайная потеря некоторых сообщений по причине их неправильной обработки сервисом DMARC не является большой проблемой.

Основополагающие и предыдущие работы в этой области

DMARC полагается на два уже существующих метода аутентификации почты – SPF5 и DKIM6. SPF осуществляет валидацию домена в адресе MAIL FROM: RFC 5321. Домен может опубликовать использующую сложный синтаксис запись SPF, чтобы задать набор IP-адресов.

Если сообщение было отправлено с одного из этих адресов, то SPF-валидация объявляется успешной. (Это очень упрощённое описание; полную информацию см. в [5].) К достоинствам SPF относится простота реализации этого расширения, поскольку для этого не требуется вносить изменения в исходящие сообщения и достаточно лишь единственной записи DNS. Однако с помощью этого метода можно описать лишь ограниченное подмножество способов доставки почты. В большинстве случаев так можно обрабатывать только почту, которую отправитель напрямую посылает получателю без использования переадресации или пересылки; кроме того, это плохо подходит для почты, посланной третьей стороной по поручению отправителя. Хотя SPF и предоставляет код -all, – который рекомендует получателям отбраковывать поступившие из домена сообщения при неудачном результате валидации SPF, большинство почтовых систем не прислушиваются к этому совету из-за слишком высокого процента ложных срабатываний.

DKIM осуществляет валидацию контента сообщений при помощи добавления в сообщение заголовков криптографической подписи, которые получатель может проверить, используя ключ в DNS. Каждая подпись хранится в поле заголовка DKIM-Signature, содержащем несколько субполей, в том числе для имени домена, добавившего подпись. Успешная валидация подписи DKIM означает, что, во-первых, в сообщение не вносились изменения с момента его подписания, и, во-вторых, домен в подписи берёт на себя ответственность за сообщение. Поскольку DKIM осуществляет валидацию контента сообщения, а не пути, на него не влияет переадресация.

DKIM значительно труднее реализовать, чем SPF, поскольку для него следует так модифицировать программное обеспечение почтовых систем, чтобы оно могло добавлять в каждое исходящее сообщение заголовки для подписи. Кроме того, необходимо, чтобы подписывающая система создавала пары ключей открытый/секретный, публиковала открытый ключ в DNS и вписывала секретный ключ в настройки подписывающего ПО. Валидация DKIM считается неудачной, если в процессе передачи сообщение было изменено – например, когда список рассылки добавляет метку темы или примечание к сообщению, а иногда просто потому, что агент Message Transfer Agent (MTA) изначально не был настроен на добавление подписи. (В крупных компаниях бывает очень трудно отслеживать все компьютеры, отправляющие электронную почту. Как это будет понятно позднее, DMARC помогает решить эту проблему.)

К DKIM имеется опциональное дополнение под названием Author Domain Signing Practices (ADSP)⁸, которое как бы представляет собой прототип DMARC. Домен может опубликовать в DNS запись ADSP, которая предупреждает, что если сообщение с этим доменом в поле From: не имеет действительной подписи DKIM из того же домена, то получатели должны игнорировать такое сообщение. Правила ADSP никогда не применялись за пределами экспериментов, и со временем группа IETF превратила их в историческую (утратившую актуальность) спецификацию.

Развёртывание DMARC

Одна из причин того, почему предыдущие подходы к реализации политик отправителя (такие, как SPF -all и ADSP) потерпели неудачу, заключается в том, что нет никаких способов их протестировать – за исключением включения и последующего наблюдения за результатами. Это выполнимо для небольшого домена с парой почтовых серверов, однако для крупных компаний риск оказался чрезмерно высоким, поскольку они не всегда полностью осведомлены обо всех своих системах, отправляющих электронную почту, а также о настройках таких систем.

В состав DMARC входит целый ряд функций для проверки согласования почты домена перед публикацией рекомендаций по политикам. Там имеются мощные средства для создания отчётов, которые просят другие системы прислать отчёты о почте, претендующей на отправление от имени домена. Перед публикацией любых политик домены неизменно просят о направлении отчётов – с тем, чтобы «увидеть», какие отправляемые ими сообщения согласованы, а какие нет. Это позволяет им исправить проблемы с согласованием до публикации политик.

Валидация DMARC

После поступления сообщения первым шагом валидации DMARC является поиск записи политики DMARC для домена заголовка From:, после чего проводится валидация подписи(ей) DKIM и SPF сообщения и затем возможны операции с самим сообщением. Первый шаг заключается в поиске записи политики для домена From: сообщения – записи DNS TXT. Если этим доменом является marketing.mybiz.example, то сначала проводится поиск в _dmarc.marketing.mybiz.example. Если там обнаруживается запись типа TXT (текстовая запись) с использованием синтаксиса DMARC (например, она начинается с v=DMARC1;), то это и есть искомая запись политики. Если ничего не найдено, то выполняется поиск записи политики в «организационном домене».

Спецификация DMARC содержит умышленно нечёткое определение относительно того, каким образом следует искать организационный домен, однако на практике всегда используется список Mozilla Public Suffix List (PSL)⁹, в котором организационный домен представляет собой наддомен непосредственно под опубликованным суффиксом (суффиксом опубликованного DNS-узла). В данном случае, если домен является типичным доменом верхнего уровня (TLD, Top-Level Domain), который принимает регистрацию на втором уровне, организационным доменом будет mybiz.example. Поэтому будет выполнен поиск записи типа TXT в домене _dmarc.mybiz.example. Если там будет обнаружена такая запись с синтаксисом DMARC, то это и есть запись политики; в противном случае для этого домена отсутствует запись политики.

Запись DMARC представляет собой список пар «ключ=значение» с правилами для проверки согласования того, что следует делать с несогласованной почтой и куда отправлять агрегированные отчеты и отчеты об ошибках. Типичная запись может выглядеть следующим образом:

v=DMARC1; p=none; rua=mailto:dmarc-a@example.net; ri=3600; ruf=mailto:dmarc-f@example.net

В данном случае политика отсутствует (none), отчеты о злоупотреблениях и ошибках отправляются по указанным адресам (rua и ruf), а интервал между запрошенными отчётами составляет один час (ri равен 3600 секундам). У второй проверки на наличие организационного домена двойная цель. Во-первых, вторая проверка облегчает развертывание DMARC в рамках крупных компаний, поскольку одна организационная запись DMARC может отхватывать все субдомены организации. Во-вторых, она охватывает несуществующие субдомены организационного домена в случаях, когда враждебные или ошибочные отправители посылают сообщения, притворяющиеся отправленными из такого субдомена.

Следующим шагом валидации является проверка, согласован ли домен заголовка From: с SPF-идентификатором сообщения. Результатом валидации SPF может быть одно из следующих значений: None, Neutral, Pass, Fail, Softfail, Temperror или Permerror. Для согласования в рамках DMARC допустим только результат Pass.

Запись политики DMARC может требовать строгого согласования SPF. Это означает, что домен From: и SPF-идентификатор должны быть одинаковыми. Или она может требовать нестрогого согласования SPF – в таком случае они лишь должны быть в одном организационном домене. В рамках предыдущего примера, если доменом From: является marketing.mybiz.example, то для нестрогого согласования SPF достаточно SPF-идентификатора mail.mybiz.example или просто mybiz.example. По умолчанию используется нестрогое согласование.

Затем механизм валидации проверяет согласование DKIM. Для каждой действительной подписи DKIM сообщения он сравнивает домен From: с доменом d= подписи. Запись политики может задавать строгое или нестрогое согласование DKIM, которое требует точного совпадения доменов или существования в одном и том же организационном домене соответственно. Если согласована хотя бы одна действительная подпись DKIM, то сообщение считается DKIM-согласованным. Если сообщение согласовано либо в рамках процедуры SPF, либо DKIM, то оно считается согласованным в рамках DMARC.

Если сообщение согласовано, то на этом всё и заканчивается, за исключением, возможно, сохранения некоторых статистических данных для последующих отчётов. Если же оно не согласовано, то ситуация потенциально является гораздо более сложной, если система получателя решит следовать рекомендации политики, что в настоящее время и делает большинство почтовых систем (по крайней мере, по объему обрабатываемой почты).

Запись политики может содержать следующие рекомендации: none, quarantine или reject. Кроме того, она может задавать опциональное процентное значение, определяющее, как часто следует применять политику. Рекомендация none означает, что получатель вправе делать с сообщением всё, что угодно. Рекомендация quarantine означает, что с сообщением следует обращаться с повышенным скептицизмом, возможно, поместив его в папку спама или пометив как подозрительное. Рекомендация reject означает, что получателя просят отклонить сообщение в конце сеанса SMTP и не обрабатывать его дальше. Если процентная доля задана меньше, чем 100, то рекомендация заключается в том, чтобы поступить с указанным процентом несогласованной почты из домена согласно значению рекомендации, а с остальной частью обращаться на один шаг менее сурово. Например, если была рекомендация reject, а процент указан как 25, то четверть несогласованной почты будет отклонена, а оставшиеся три четверти помещены в карантин. (Процент не имеет никакого значения, если политика не задана.)

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

Отчёты DMARC

DMARC включает в себя два мощных средства для создания отчётов. Домен может запросить ежедневные агрегированные отчеты о том, какие IP-адреса отправляли почту с этим доменом в заголовке From: с подробными данными о согласовании DMARC, а также о валидации DKIM и SPF. Агрегированные отчеты отправляют многие крупные почтовые системы, включая Google, Yahoo/AOL, Comcast и Fastmail.

Кроме того, существует возможность запросить копии сообщений, которые не прошли валидацию DMARC, однако по причинам, связанным с защитой личных данных, лишь немногие системы это делают. LinkedIn является единственной крупной почтовой системой США, которая отправляет отчеты об ошибках.

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

Для того, чтобы можно было запрашивать каждый тип отчета, запись политики домена включает в себя метку со списком URI mailto (URI – унифицированный идентификатор ресурса), каждый с опциональным лимитом для максимального размера отчёта, который способна обработать система. По умолчанию интервал отправки агрегированных отчетов равен одному дню.

Агрегированные отчеты представляют собой XML-файл, сжатый с помощью gzip или ZIP, который прикреплён к сообщению электронной почты. Этот XML-файл включает в себя раздел («запись») для каждого отправляющего IP-адреса с подразделами («строка») для каждой комбинации результатов аутентификации. Например, ниже приводится раздел отчёта, описывающий полученную от двух IP-адресов почту, который Google отправил в мою систему Smail:

<record> <row>
<source_ip>2001:470:1f07:1126:0:43:6f73:7461</source_ip> <count>1</count>
<policy_evaluated> <disposition>none</disposition> <dkim>pass</dkim> <spf>pass</spf>
</policy_evaluated> </row>
<identifiers> <header_from>taugh.com</header_from>
</identifiers> <auth_results>
<dkim> <domain>iecc.com</domain> <result>pass</result> <selector>k1912</selector>
</dkim> <dkim>
<domain>taugh.com</domain> <result>pass</result> <selector>k1912</selector>
</dkim> <spf>
<domain>taugh.com</domain> <result>pass</result>
</spf> </auth_results>
</record>
<record> <row>
<source_ip>209.85.220.55</source_ip> <count>4</count>
<policy_evaluated> <disposition>none</disposition> <dkim>fail</dkim> <spf>fail</spf>
</policy_evaluated> </row>
<identifiers> <header_from>taugh.com</header_from>
</identifiers> <auth_results>
<dkim> <domain>googlegroups.com</domain> <result>pass</result> <selector>20161025</selector>
</dkim> <spf>
<domain>googlegroups.com</domain> <result>pass</result>
</spf> </auth_results>
</record>

Первая запись для адреса IPv6 сообщает об отправленном с моего почтового сервера сообщении. У этого сообщения одна действительная подпись SPF и две действительные подписи DKIM: одна с доменом заголовка From: и одна для домена сервера. Это значит, что сообщение согласовано согласно DMARC. Вторая запись описывает четыре сообщения с действительными подписями SPF и DKIM, однако домены SPF и DKIM не совпадают с заголовком From:, поэтому они не считаются согласованными согласно DMARC. Поскольку у второй группы сообщений в качестве идентификаторов аутентификации используется googlegroups.com, они, скорее всего, представляют собой то же самое, упомянутое выше сообщение, которое было изменено и заново отправлено в список рассылки Google Groups. [Поскольку я знаю, что в этот день отправлял только одно сообщение в данный список, это позволяет мне узнать количество подписчиков Gmail в списке. Мне приходилось видеть аналогичные утечки и более крупных списков, например, список, ведущийся группой NANOG (North American Network Operators Group).]

Более крупные почтовые системы получают отчёты с большим количеством сообщений и разделов. Эти отчёты предназначены для автоматической обработки. В настоящее время доступны программы с открытым исходным кодом, которые анализируют такие отчёты и записывают сводную информацию в базу данных¹⁰. Однако чаще эти отчёты напрямую отправляют в такие специализированные службы, как Dmarcian¹¹ или Agari¹², которые предлагают условно-бесплатные сервисы по анализу отчетов: бесплатный простой анализ, а также более сложный анализ и рекомендации по исправлению ситуации за плату.

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

Ниже приводится типичный раздел такого отчёта:

Feedback-Type: auth-failure User-Agent: Lua/1.0 Version: 1.0
Original-Mail-From: nanog-bounces@nanog.org Original-Rcpt-To: xxx@linkedin.com
Arrival-Date: Thu, 26 Dec 2019 19:22:54 +0000 Message-ID: <20191226191849.6BBF111BA67D@ary.qy>
Authentication-Results: dmarc=fail (p=none; dis=none)header.from=iecc.com
Source-IP: 50.31.151.76
Delivery-Result: delivered
Auth-Failure: dmarc
Reported-Domain: iecc.com

Сообщение в отчёте об ошибках могло быть легитимным, но оно либо было несогласованным на момент отправки, либо было изменено в процессе доставки и, таким образом, стало несогласованным. Либо оно могло оказаться мошенническим – попытка фишинга или просто случайный спам, для которого спамовое ПО выбрало ваш домен с целью подделки обратного адреса. Что касается этого конкретного отчёта, то очевидно, что реальное сообщение ретранслировалось через список рассылки NANOG.

Исходный отчёт об ошибках включал полный адрес получателя. Это означает, что просмотрев отчёты об ошибках, любой пользователь, размещающий сообщения на NANOG, может увидеть тех, кто подписан на LinkedIn. Возможность такой утечки данных объясняет, почему большинство сайтов вообще не отправляют отчёты об ошибках, а большая часть из тех, которые это делают, ограничивают отправляемую информацию, обычно включая только заголовки недоставленных сообщений и удаляя адресные данные получателей.

Использование отчётов DMARC для публикации политик

Перед тем, как публиковать политику DMARC с использованием quarantine или reject, операторы доменов должны убедиться в том, что почти вся отправляемая ими почта (максимально близкая к 100% доля) согласована в рамках DMARC. Если SPF-записи домена не охватывают все IP-адреса, посылающие легитимную почту, то это может привести к отправке несогласованных сообщений, которые не смогут пройти валидацию SPF. У некоторых исходящих почтовых агентов MTA (Mail Transfer Agent) могут быть некорректно настроены параметры DKIM (или совсем не настроены), что приведёт к отсутствию согласованной подписи DKIM. В крупных компаниях часто могут возникать ситуации, когда агенты MTA отправляют почту, о которой не знали диспетчеры сети – например, если подразделение настроило собственный локальный сервер или заключило контракт со сторонней системой отправки почты.

Данные, полученные из отчётов DMARC, показывают оператору IP-адреса, которые отправляют несогласованную почту, и, как правило, позволяют легко определить причину такого несогласования. Меры по исправлению ситуации могут включать обновление SPF-записей домена для добавления отсутствующих агентов MTA, исправление конфигурации подписания DKIM в агентах MTA либо принудительную реализацию правил в отношении несанкционированных почтовых серверов или сторонних отправителей почты. (Многие сторонние исполнители могут осуществлять подписание DKIM с использованием домена клиента, однако для этого нужно обеспечить либо совместное использование секретных ключей подписи, либо делегирование субдерева DNS, которым этот исполнитель сможет управлять.)

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

DMARC против списков рассылки

Первоначально DMARC предназначался для доменов в таких компаниях/организациях как банки, которые в основном отправляют почту в рамках отношений B2B и B2C, и почти не использовался в обычной электронной почте «от человека человеку». В тех случаях, когда компания обдумывает, когда публиковать политику DMARC и какую именно политику публиковать, необходимо учитывать, что часть легитимной почты поступит в несогласованном состоянии из-за промежуточной обработки, которую нельзя описать с помощью DMARC. Поскольку, как предполагается, компания знает, какую почту отправляет, она может сопоставить преимущества снижения угрозы фишинга со стоимостью потерянной почты и принять разумное для себя решение.

В 2014 году AOL и Yahoo – две крупные почтовые системы, обслуживающие индивидуальных потребителей, – были взломаны в ходе несвязанных между собой инцидентов, которые привели к тому, что злоумышленники украли данные миллионов пользователей из их адресных книг. Украденные данные были очень быстро проданы спамерам, которые использовали их для отправки спама пользователям AOL и Yahoo как будто бы от имени друзей. Всё это создало огромную проблему для служб поддержки AOL и Yahoo, так как пользователи жаловались на спам и спрашивали, почему друзья заваливают их спамом. Сначала AOL, а затем и Yahoo «решили» эту проблему, стремительно опубликовав политики DMARC p=reject, которые инструктировали каждую почтовую систему, реализующую DMARC, отклонять любые сообщения электронной почты AOL или Yahoo, не поступающие непосредственно от AOL или Yahoo. Это решение сильно отличалось от описанных ранее действий других компаний. В данном случае целью политики было снижение ущерба от эксплуатационного сбоя; это не приносило почти никаких выгод большинству пользователей и одновременно создавало большие проблемы для пользователей дискуссионных списков.

В любой почтовой системе, предназначенной для индивидуальных потребителей, существует небольшая, но важная часть пользовательской почты, которая является несогласованной, но в то же время легитимной и востребованной получателями. Это часто происходит из-за того, что маршрутизация почты осуществляется не напрямую от отправителя конечным получателям. Особым камнем преткновения остаются дискуссионные списки электронной почты, обычные действия диспетчеров которых превращают большую часть почты в несогласованные сообщения. Такая ситуация может привести к неполучению почты, отправленной подписчикам почтовых систем, которые распространяют политики DMARC на входящие сообщения. Кроме того, это может привести к удалению подписчиков из списков из-за ошибок отправки, вызванных отказами DMARC. (Согласно сведениям, полученным от одного из инсайдеров, Yahoo знала о проблемах со списками рассылки, но всё равно решила опубликовать политику p=reject.) Ещё одним источником несогласованной почты являются сторонние почтовые сервисы. Небольшая организация, например, спортивный клуб или отряд скаутов, часто использует список извещений, где обратным адресом для уведомления является персональный адрес секретаря организации, который, возможно, зарегистрирован в почтовых системах AOL или Yahoo.

Для того, чтобы решить проблемы, которые DMARC создаёт для списков рассылки, был предложен целый ряд обходных путей. Но ни один из них не оказался вполне успешным. Первоначально самый простой подход заключался в том, чтобы попросить пользователей, отправляющих почту с адресов, подпадающих под действие политик DMARC, подписаться на списки с других адресов. Этот подход перестал приносить пользу, когда AOL и Yahoo щёлкнули переключателем.

С тех пор программное обеспечение, управляющее списками рассылки, применяло самые разные подходы для того, чтобы обеспечить согласование сообщений, отправляемых такими списками. В некоторых случаях списки пробовали выключать все функции, которые изменяют сообщения способами, делающими недействительными подписи DKIM, надеясь, что в результате подписи DKIM останутся действительными при переадресации из списка. Этот метод показал не очень хорошие результаты – в том числе потому, что переадресованные сообщения не были согласованы в рамках SPF (список использует собственный адрес «конверта» для управления возвратами), а пользователям нужны вносимые списками изменения, например, добавление меток строки темы для идентификации списка.

Списки рассылки остановились на двух общих подходах противодействия DMARC¹³. Наиболее распространённый заключается в том, чтобы вставлять адрес списка в заголовок From:. Это позволяет списку добавлять подпись DKIM со своим собственным доменом и обеспечивать DMARC-согласование сообщения. Например, если входящее сообщение включало:

From: Steve C <steve@aol.com>
To: nodule@lists.example.com

Список может переписать это как:

From: Steve C via the nodule list <nodule@lists.example.com>
To: somelist@lists.example.com
Reply-To: Steve <steve@aol.com>

Переписанный заголовок From: обычно включает комментарий к адресу автора и имя списка. Фактический адрес автора добавляется в заголовок Reply-To: либо иногда в заголовок Cc:. Такой подход позволяет реализовать согласование DMARC, поскольку список может добавить DKIM-подпись lists.example.com, но затрудняет обработку отправляемой почты из списка. Почтовые агенты пользователя обрабатывают заголовок Reply-To: по-разному, что приводит к путанице относительно того, отвечает ли кто-то автору сообщения, списку или обоим. Добавляя ещё больше беспорядка к этой путанице, некоторые списки переписывают заголовки для сообщений только в тех доменах автора, которые публикуют политику DMARC. А это приводит к тому, что сообщения из одного и того же списка имеют разные заголовки.

Другой подход заключается в том, чтобы переписать заголовок From: с заменой проблемного адреса автора на другой адрес, который согласован в рамках DMARC, но, тем не менее, представляет автора. Например, мои списки рассылки переписали бы заголовки предыдущего примера так, чтобы изменить адрес автора лишь посредством добавления суффикса локального домена:

From: Steve C <steve@aol.com.dmarc.fail>
To: nodule@lists.example.com

dmarc.fail представляет собой реальный домен, зарегистрированный мною. (Он был доступен.) Я публикую запись MX record для *.dmarc.fail для того, чтобы получать любую почту, отправленную на переписанные адреса. Переписанное сообщение, как и письма, отправленные списками рассылки, имеет DKIM-подпись dmarc.fail и поэтому оно корректно согласовано в рамках DMARC. При переписывании адреса программой управления списком она создаёт для переписанного адреса переадресовочную запись, которая перенаправляет на исходный адрес. Через несколько дней переадресовочные записи удаляются – для того, чтобы ответы, отправленные вскоре после исходного письма, поступили автору, однако переадресация весьма ограничена и поэтому не очень полезна для передачи стороннего спама.

Этот метод работает относительно хорошо. Поскольку меняется только заголовок From:, это не оказывает никакого воздействия на Reply-To: или другое поведение почты, но при этом легко распознаётся идентификатор автора. Прочие системы реализовали ту же идею – возможно, в менее пассивно-агрессивной манере. Рабочие списки рассылки IETF переписывают адрес в локальную часть (адреса электронной почты), например:

From: Steve C <steve=40aol.com@lists.ietf.org>

Коммерческий сервис списков рассылки LISTSERV переписывает адрес в непрозрачный локальный адрес, а настоящий адрес помещает в заголовок Reply-To:

From: Steve C <00000006b01fa96f-dmarc-request@lists.example.com>
Reply-To: Steve C <steve@aol.com>, Nodule list <nodule@lists.example.com>

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

Ещё один подход к преодолению недостатков DMARC, используемый некоторыми списками, состоит в «обёртывании» сообщения путём вкладывания его в виде MIME-элемента внутрь внешнего сообщения от списка. В большинстве списков рассылки имеется опция MIME-сжатия, позволяющая отправлять однодневные сообщения в виде набора MIME-элементов внутри отдельного ежедневного сообщения. Фактически этот процесс превращает каждое письмо в состоящий из одного сообщения дайджест. Обычно адрес списка помещается в заголовок From: внешнего сообщения, при этом внутреннее письмо остаётся неизменным.

Чисто технически этот подход должен работать хорошо, поскольку в нём используется существующие, давно унифицированные функции электронной почты согласно RFC 5322. Для того, чтобы это проверить, я провёл несколько экспериментов, но результаты оказались очень плохими, так как почтовые агенты пользователя обрабатывают прикреплённые MIME-сообщения как нечто второстепенное. И хотя внутреннее письмо обычно отображается разборчиво, во многих случаях на него невозможно ответить без выполнения дополнительных громоздких шагов, а иногда это не удаётся вовсе. При этом обработка составных сообщений или писем с вложениями не отличалась последовательностью. Группа IETF провела эксперименты с несколькими типами MIME-оболочек и решила, что переписывание заголовка From: является лучшим выбором из всех плохих вариантов.

Хотя все эти методы и позволяют спискам рассылки отправлять согласованные с DMARC письма, ни один из них не работает настолько хорошо, чтобы списки могли вернуться в ситуацию до внедрения DMARC.

ARC

Несмотря на то, что объём почты, который крупные провайдеры получают через списки рассылки, весьма невелик – где-то около 1-2% от количества не относящихся к спаму сообщений, пользователи сильно заинтересованы в её получении. После ряда лет, в течение которых они получали многочисленные жалобы, несколько крупных провайдеров услуг электронной почты разработали механизм аутентификации Authenticated Received Chain (ARC), который помогает им обрабатывать желаемую, но не согласованную пользовательскую почту.

Очевидным способом обращения с несогласованной почтой из списков рассылки является внесение её в белый список. Крупные почтовые системы очень хорошо знают, где находятся такие списки (во всем мире количество хостов списков рассылки скорее всего составляет примерно 10 000), поэтому они могут просто, без всяких условий принимать почту из таких списков, зная, что она нужна их пользователям. Однако при таком подходе возникает другая проблема – списки рассылки не очень хорошо отсортировывают спам, что приводит к постоянным «протечкам» спама через них.

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

Целью механизма ARC является добавление к сообщению «цепи опеки», которая показывает, что с ним происходило при каждой переадресации. Этот метод позволяет конечной принимающей системе задним числом принимать решения по фильтрации спама на основе того, что случилось с сообщением в переадресующих системах.

ARC работает на базе существующей технологии электронной почты. Он адаптирует заголовок Authentication-Results (A-R)¹⁴, который многие почтовые системы вставляют во входящее письмо для записи статуса аутентификации сообщения на момент его получения агентом MTA. Ниже приводится типичный заголовок A-R, который мой почтовый агент MTA вставил во входящее сообщение, поступившее от принадлежащего Apple сайта me.com:

Authentication-Results: iecc.com; spf=pass spf.mailfrom=xxx@me.com spf.helo=mr85p00im-hyfv06011401.me.com smtp.remote-ip="17.58.23.191"; dkim=pass header.d=me.com header.s=1a1hai header.a=rsa-sha256; dmarc=pass header.from=me.com (p=quarantine, pct=100)

В первом поле записано имя системы, добавившей заголовок, после чего следуют группы результатов аутентификации – в данном примере для SPF, DKIM и DMARC. Каждая группа включает результат и релевантные пункты, например, конверт MAIL FROM и отправляющий IP-адрес для SPF. Все поля являются опциональными, за исключением имени системы; они добавляются только для тех типов аутентификации, которые проверила система. ARC объединяет модифицированный заголовок A-R и два заголовка DKIM-подобных подписей в «пломбу» ARC, которая предназначена для описания прохождения сообщения через такую систему, как, например, диспетчер списков рассылки. У отдельного сообщения может быть несколько пломб ARC, если оно прошло через ряд переадресующих систем.

Каждой пломбе присваивается номер, начиная с 1 для той, которая добавлена первой. Каждый заголовок в пломбе ARC имеет пункт i=, который указывает, частью какой пломбы он является.

Ниже приводится пример заголовков в пломбе ARC:

ARC-Message-Signature: i=1; a=rsa-sha256; d=microsoft.com; s=abcd; h=From:Date:... ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass …; dkim=pass …
ARC-Seal: i=1; a=rsa-sha256; s=abcd; d=microsoft.com; cv=none; b=j7M/jt9eVP…

Подпись ARC-Message-Signature (AMS) почти идентична подписи DKIM, но с добавлением поля i=. Она предназначена для покрытия обычных заголовков и тела сообщения на момент его отправки из подписывающей системы. Если система внесла изменения в сообщение, то AMS применяется после таких изменений. При получении сообщения будет действительной самая последняя подпись AMS – за исключением ситуации, когда промежуточная система модифицировала сообщение после применения пломбы ARC, но не добавила собственную пломбу.

Заголовок ARC-Authentication-Results (AAR) сообщает статус аутентификации на момент получения сообщения «пломбирующей» системой, т.е. до того, как любые изменения были отражены в AMS.

Заголовок ARC-Seal представляет собой DKIM-подобную подпись, которая охватывает только три заголовка пломбы ARC, обеспечивая валидацию самой пломбы. Кроме того, она показывает, оставалась ли нетронутой цепочка пломб ARC при пломбировании сообщения, используя для этого поле cv= (значение цепочки). Если пломба является самой первой, то значение цепочки равно «none», поскольку предыдущая пломба отсутствует. Для любой последующей пломбы значение цепочки равно «pass», если предыдущая пломбы была действительной (успешная валидация DKIM-подобных подписей), а у предыдущей пломбы было cv=none или cv=pass. В противном случае значение цепочки равно «fail».

Если почтовая система получает сообщение с действительной цепочкой ARC от заслуживающего доверия источника, она может использовать информацию пломб ARC для внесения исключений в свою политику DMARC. В качестве простого примера давайте представим, что поступает сообщение, несогласованное в рамках DMARC, но имеющее действительную цепочку пломб ARC. В одной из пломб заголовок AAR показывает, что сообщение было согласовано в рамках DMARC (dmarc=pass), а домен header.from был тем же, что имеется в настоящее время в сообщении. Это означает, что рассогласование произошло из-за изменений, внесённых переадресующей системой. Если эта переадресующая система считается заслуживающей доверия (например, это хост дискуссионных списков), то получающая система может принять решение о доставке сообщения. При этом возможен более сложный анализ, однако я ожидаю, что подобный тип анализа с поиском типичных операций списка рассылки будет наиболее распространённым. Поскольку вредоносные системы способны добавлять поддельные пломбы ARC, этот анализ имеет смысл только для почты, поступающей из заслуживающих доверия источников. Для почтовых систем, которые слишком малы для сбора надёжных данных об отправляющих им почту хостах, идентификация достаточно достоверных источников, к которым можно применить исключения ARC, вероятно станет проблемой. В настоящее время предпринимаются усилия по созданию разделяемых списков заслуживающих доверия хостов (для списков рассылки), которые, возможно, окажутся достаточно плодотворными, поскольку количество активных хостов списков невелико и изменяется довольно медленно.

К настоящему времени внедрение ARC уже началось, но этот механизм ещё не является достаточно распространённым, чтобы списки рассылки прекратили направленную против DMARC «порчу» заголовков. Библиотеки Python и Perl для DKIM уже добавили поддержку ARC¹⁵. Диспетчер списков рассылки Sympa 6.2 поддерживает ARC, как и GNU Mailman 3.1 (но не версии Mailman 2.x).

Крупные почтовые системы, включая Gmail от Google и outlook.com от Microsoft, обеспечивают некоторую поддержку ARC. Как Gmail, так и outlook.com ставят пломбы ARC на пересылаемую почту и почту от списков рассылки, но еще не используют их для фильтрации сообщений, за исключением экспериментальных целей. Лишь несколько списков рассылки уже добавили пломбы ARC, частично по причине отсутствия поддержки ARC в ПО управления списками, которым они в настоящее время пользуются, и частично из-за того, что диспетчеры списков не знают об ARC.

Выводы

Спецификация DMARC начиналась как относительно простой метод предотвращения фишинга, который взяли на вооружение известные коммерческие домены – например, домены банков и поставщиков платёжных услуг. Затем потребительские почтовые системы AOL и Yahoo переориентировали этот метод на борьбу со спамом, который подделывал адреса их пользователей. Хотя такое перепрофилирование в основном и решило проблему спамового подлога для этих систем, оно также нанесло значительный сопутствующий ущерб спискам рассылки электронной почты. Несмотря на то, что многие списки пытались найти пути для обхода проблем DMARC, все эти методы имели изъяны, которые в конечном итоге приводили к неудовлетворительному результату. Для того, чтобы справиться с недостатками DMARC, группа крупных провайдеров электронной почты изобрела механизм аутентификации ARC, который позволяет в каком-то смысле изучить историю сообщения и узнать, каким образом не согласованное в рамках DMARC сообщение приобрело такой статус.

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

Список источников и дополнительная литература

1. Dave Crocker, «Challenges in Anti-Spam Efforts», The Internet Protocol Journal, Volume 8, No. 4, December 2005.

2. John Klensin, «Another Look at Spam», The Internet Protocol Journal, Volume 8, No. 4, December 2005.

3. Murray Kucherawy and Elizabeth Zwicky, Eds., «Domain-based Message Authentication, Reporting, and Conformance (DMARC)», RFC 7489, March 2015.

4. Peter W. Resnick, «Internet Message Format», RFC 5322, October 2008.

5. Scott Kitterman, «Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1», RFC 7208, April 2014.

6. Murray Kucherawy, David Crocker, and Tony Hansen, «DomainKeys Identified Mail (DKIM) Signatures», RFC 6376, September 2011.

7. John C. Klensin, «Simple Mail Transfer Protocol», RFC 5321, October 2008.

8. John Levine, Mark Delany, Eric Allman, and Jim Fenton, «DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)», RFC 5617, August 2009.

9. See https://publicsuffix.org/ for the PSL, and https:// wiki.mozilla.org/Public_Suffix_List for a description of its use and history.

10. See https://www.taugh.com/rddmarc/

11. Dmarcian: www.dmarcian.com

12. Agari: www.agari.com

13. Mailman and DMARC, https://wiki.list.org/DEV/DMARC

14. Murray Kucherawy, «Message Header Field for Indicating Message Authentication Status», RFC 8601, May 2019.

15. See https://pypi.org/project/dkimpy/  for the Python library, and https://metacpan.org/release/Mail-DKIM  for the Perl library.