Из Википедии, свободной энциклопедии
Перейти к навигации Перейти к поиску
Эта статья о системе проверки электронной почты. Информацию о точке соединения телефонии см. В пункте разграничения .
Не путать с dMarc Broadcasting .

DMARC ( Domain-based Message Authentication, Reporting and Conformance ) - это протокол аутентификации электронной почты . Он разработан, чтобы дать владельцам почтовых доменов возможность защитить свой домен от несанкционированного использования, широко известного как подмена электронной почты . Целью и основным результатом внедрения DMARC является защита домена от использования в атаках компрометации корпоративной электронной почты , фишинговых электронных письмах, мошенничестве по электронной почте и других действиях киберугроз .

После публикации записи DNS DMARC любой принимающий почтовый сервер может аутентифицировать входящую электронную почту на основе инструкций, опубликованных владельцем домена в записи DNS. Если электронное письмо проходит аутентификацию, оно будет доставлено, и ему можно будет доверять. Если электронное письмо не проходит проверку, в зависимости от инструкций, содержащихся в записи DMARC, электронное письмо может быть доставлено, помещено в карантин или отклонено. Например, одна служба пересылки электронной почты доставляет почту, но как «От: no-reply @ <служба пересылки>». [1]

DMARC расширяет два существующих механизма аутентификации электронной почты: Sender Policy Framework (SPF) и DomainKeys Identified Mail (DKIM). Это позволяет административному владельцу домена публиковать политику в своих записях DNS, чтобы указать, какой механизм (DKIM, SPF или оба) используется при отправке электронной почты из этого домена; как проверить From:поле, представленное конечным пользователям; как получатель должен справляться с отказами - и механизм отчетности о действиях, выполненных в соответствии с этими политиками.

DMARC определен в опубликованном документе RFC 7489 инженерной группы Интернета от марта 2015 г. как «информационный». [2]

Обзор [ править ]

Политика DMARC позволяет домену отправителя указывать, что его электронные письма защищены SPF и / или DKIM, и сообщает получателю, что делать, если ни один из этих методов аутентификации не проходит, например, отклонять сообщение или помещать его в карантин. Политика также может указывать, как получатель электронной почты может сообщать домену отправителя о сообщениях, которые прошли и / или не прошли. [3]

Эти политики публикуются в общедоступной системе доменных имен (DNS) в виде текстовых записей TXT .

DMARC не определяет, является ли электронное письмо спамом или иным образом мошенническим. Вместо этого DMARC может потребовать, чтобы сообщение прошло не только проверку DKIM или SPF, но и согласование . В DMARC сообщение может завершиться ошибкой, даже если оно проходит SPF или DKIM, но не может быть согласовано. [4]

Настройка DMARC может положительно повлиять на доставляемость законных отправителей. [5]

Выравнивание [ править ]

DMARC работает, проверяя, что домен в поле сообщения From:(также называемый «RFC5322.From» [2] ) «выровнен» с другими аутентифицированными доменными именами. Если проверка выравнивания SPF или DKIM прошла успешно, значит, проверка выравнивания DMARC прошла успешно.

Расклад может быть строгим или расслабленным. Для строгого согласования доменные имена должны быть идентичными. Для упрощенного согласования должен совпадать верхний уровень «Организационный домен». Организационный домен можно найти, проверив список общедоступных суффиксов DNS и добавив следующую метку DNS. Так, например, «abcdexample.com.au» и «example.com.au» имеют один и тот же организационный домен, потому что существует регистратор, который предлагает клиентам имена в «.com.au». Хотя во время спецификации DMARC существовала рабочая группа IETF по границам доменов, в настоящее время домен организации можно получить только из списка общедоступных суффиксов . [6]

Подобно SPF и DKIM, DMARC использует концепцию владельца домена, объекта или объектов, которые уполномочены вносить изменения в данный домен DNS.

SPF проверяет, что IP-адрес отправляющего сервера авторизован владельцем домена, указанного в команде SMTP MAIL FROM. (Адрес электронной почты в MAIL FROM также называется адресом возврата, отправителем конверта или RFC5321.MailFrom.) Помимо требования прохождения проверки SPF, DMARC дополнительно проверяет соответствие RFC5321.MailFrom с 5322.From. [ необходима цитата ]

DKIM позволяет части сообщения электронной почты быть криптографически подписанным, и подпись должна закрывать поле От. В почтовом заголовке DKIM-Signature теги d=(домен) и s=(селектор) указывают, где в DNS получить открытый ключ для подписи. Действительная подпись доказывает, что подписывающая сторона является владельцем домена и что поле «От» не изменялось с момента применения подписи. В сообщении электронной почты может быть несколько подписей DKIM; Для DMARC требуется одна действительная подпись, в которой домен в d=теге совпадает с доменом отправителя, указанным в From:поле заголовка.

Запись DNS [ править ]

DMARC записи публикуются в DNS с меткой поддомен _dmarc, например _dmarc.example.com. Сравните это с SPF at example.comи DKIM at selector._domainkey.example.com.

Содержимое записи ресурса TXT состоит из name=valueтегов, разделенных точкой с запятой, аналогично SPF и DKIM. Например:

"v = DMARC1; p = none; sp = quarantine; pct = 100; rua = mailto: [email protected];"

Здесь vэто версия, pэто политика, политика spподдомена, pctэто процент «плохих» писем, к которым следует применить политику, и ruaэто URI для отправки агрегированных отчетов. В этом примере субъект, контролирующий домен DNS example.com, намеревается отслеживать частоту отказов SPF и / или DKIM и не ожидает, что электронные письма будут отправляться с поддоменов example.com. Обратите внимание, что поддомен может публиковать свою собственную запись DMARC; получатели должны проверить это, прежде чем вернуться к записи домена организации.

Отчеты [ править ]

DMARC может создавать два отдельных типа отчетов. Сводные отчеты отправляются на адрес, указанный после rua. Отчеты о судебно-медицинской экспертизе отправляются по электронной почте на адрес, следующий за rufтегом. Эти почтовые адреса должны быть указаны в формате URI mailto (например, mailto: [email protected]). Допустимы несколько адресов для отчетов, каждый из которых должен иметь полный формат URI, разделенный запятыми.

Целевые адреса электронной почты могут принадлежать внешним доменам. В этом случае целевой домен должен настроить запись DMARC, чтобы сообщить о своем согласии на их получение, в противном случае можно было бы использовать отчеты для усиления спама . Например, скажем, receiver.exampleполучает почтовое сообщение From: [email protected]и желает сообщить о нем. Если он находит ruf=mailto:[email protected], он ищет подтверждающую запись DNS в пространстве имен, администрируемом целью, например:

sender.example._report._dmarc.thirdparty.example IN TXT "v = DMARC1;"

Сводные отчеты [ править ]

Сводные отчеты отправляются в виде файлов XML , как правило, один раз в день. Субъект упоминает «Отчет домен», который указует имя домена DNS , о котором был создан отчет, и «Отправитель», который является юридическим лицом , выдавшим отчет. Полезная нагрузка находится во вложении с длинным именем файла, состоящим из элементов, разделенных взломом, таких как получатель отчета, начальная и конечная эпохи отчетного периода в виде временных меток в стиле Unix, необязательный уникальный идентификатор и расширение, которое зависит от возможное сжатие (раньше было .zip). [7]

Например: example.com!example.org!1475712000!1475798400.xml.gz.

XML-контент состоит из заголовка, содержащего политику, на которой основан отчет, и метаданные отчета, за которыми следует ряд записей. Записи могут быть помещены в базу данных как отношение и просмотрены в табличной форме. Схема XML определена в Приложении C спецификаций [8], а пример необработанной записи приведен в dmarc.org. [9] Здесь мы придерживаемся реляционного примера, который лучше передает характер данных. Записи DMARC также можно напрямую преобразовать в HTML, применив таблицу стилей XSL .

Строки DMARC совокупной записи в табличной форме
Исходный IPСчитатьДиспозицияSPFDKIMЗаголовок изSPF домен (результат)Домен DKIM (результат) 
192.0.2.112никто✓  Пройти✓  Пройтиexample.orgexample.org ( ✓  Пройдено )example.org ( ✓  Пройдено ) 
192.0.2.11никто✓  Пройти✗  Неудачаexample.orgexample.org ( ✓  Пройдено )example.org ( ✗  Ошибка ) 
192.0.2.2842никто✗  Неудача✓  Пройтиexample.orgexample.org ( ✗  Ошибка )example.org ( ✓  Пройдено )forwarder.example ( ✓  Пройден )
192.0.2.8221 годникто✗  Неудача✗  Неудачаexample.orgdiscusslist.example ( ✓  Pass )example.org ( ✗  Ошибка )discusslist.example ( ✓  Pass )
...

Строки сгруппированы по исходному IP-адресу и результатам аутентификации, передавая только количество каждой группы. Крайние левые столбцы результатов, помеченные как SPF и DKIM, показывают результаты DMARC, прошедшие или нет, с учетом выравнивания. Крайние правые, с похожими метками, показывают имя домена, который утверждает, что участвует в отправке сообщения, и (в скобках) статус аутентификации этого запроса в соответствии с исходным протоколом, SPF или DKIM, независимо от согласования идентификаторов. Справа SPF может появляться не более двух раз: один раз для Return-Path:теста и один раз дляHELOтестовое задание; DKIM может отображаться один раз для каждой подписи в сообщении. В этом примере первая строка представляет основной поток почты от example.org, а вторая строка - сбой DKIM, например нарушение подписи из-за незначительного изменения при передаче. Третья и четвертая строки показывают типичные режимы сбоев пересылки и списка рассылки соответственно. Аутентификация DMARC завершилась неудачно только для последней строки; это могло повлиять на размещение сообщений, если бы example.org установил строгую политику.

Расположение отражает политику опубликования фактически применяется к сообщениям, ни один , карантин или отклонить . Наряду с этим, не показанным в таблице, DMARC обеспечивает переопределение политики. Некоторые причины, по которым получатель может применять политику, отличную от запрошенной, уже предусмотрены в спецификации:

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

Криминалистические отчеты [ править ]

Криминалистические отчеты, также известные как отчеты о сбоях, создаются в режиме реального времени и состоят из отредактированных копий отдельных писем, в которых произошел сбой SPF, DKIM или обоих, в зависимости от того, какое значение указано в foтеге. Их формат, являющийся расширением формата сообщений о злоупотреблениях , напоминает формат обычных отказов в том, что они содержат либо «message / rfc822», либо «text / rfc822-headers».

Совместимость [ править ]

Экспедиторы [ править ]

Существует несколько различных типов пересылки электронной почты , некоторые из которых могут нарушить SPF. [10]

Списки рассылки [ править ]

Списки рассылки являются частой причиной законной поломки DKIM-подписи исходного домена автора, например, путем добавления префикса в заголовок темы. Возможен ряд обходных путей [11], и программные пакеты списков рассылки работают над решениями. [12]

Отключить все изменения сообщений [ править ]

Этот обходной путь сохраняет стандартный рабочий процесс списка рассылки и принят несколькими операторами крупных списков рассылки, но исключает добавление в список нижних колонтитулов и префиксов тем. [13] Это требует тщательной настройки почтового программного обеспечения, чтобы гарантировать, что подписанные заголовки не переупорядочены или изменены. Неправильно сконфигурированный почтовый сервер может указать List-id в своем DKIM сообщений, отправленных в список рассылки, а затем оператор списка будет вынужден отклонить его или выполнить перезапись From :.

From:переписывание [ править ]

Один из самых популярных и наименее назойливых обходных путей состоит в переписывании From:поля заголовка. Затем в Reply-To:поле можно добавить исходный адрес автора . [14] Перезапись может варьироваться от простого добавления .INVALID[примечания 1] к имени домена до выделения временного идентификатора пользователя, где используется непрозрачный идентификатор, что сохраняет «настоящий» адрес электронной почты пользователя в секрете из списка. Кроме того, отображаемое имя можно изменить, чтобы отображались как автор, так и список (или оператор списка). [15] Эти примеры приведут, соответственно, к одному из:

От:  Джон  Доу <[email protected]> От:  Джон  Доу <[email protected]> От:  Джон  Доу  через  MailingList <[email protected]> и Ответить:  Джон  Доу <[email protected]>

Последняя строка Reply-To:,, должна быть спроектирована так, чтобы учесть функциональность ответа автору, в случае, если функция ответа на список охвачена предыдущим изменением в From:поле заголовка. Таким образом, исходное значение этих полей меняется на противоположное.

Изменение автора в целом несправедливо и может нарушить ожидаемую взаимосвязь между значением и внешним видом этого элемента. Это также нарушает его автоматическое использование. Есть сообщества, которые используют списки рассылки для координации своей работы и развертывают инструменты, которые используют From:поле для атрибуции авторства вложений. [16]

Другие обходные пути [ править ]

Перенос сообщения хорошо работает для тех, кто использует почтовый клиент, который понимает упакованные сообщения. Невыполнение каких-либо изменений, возможно, является наиболее очевидным решением, за исключением того, что в некоторых странах они, по-видимому, должны быть выполнены по закону, и что регулярная потеря аутентификации SPF может сделать общую аутентификацию более хрупкой. [17]

Поле отправителя [ править ]

Внесение изменений в From:поле заголовка для прохождения согласования DKIM может привести к тому, что сообщение не будет соответствовать разделу 3.6.2 RFC 5322: «В поле« От: »указываются авторы сообщения, то есть почтовые ящики. человека или системы, ответственных за написание сообщения ". Под почтовым ящиком подразумевается адрес электронной почты автора. Sender:Заголовок доступен для указания того, что письмо было отправлено от имени другой стороны, но DMARC проверяет только политика От домена и игнорирует домен отправителя. [заметка 2]

И ADSP, и DMARC [4] отклоняют использование поля отправителя на нетехнических основаниях, что многие пользовательские агенты не отображают его получателю.

История [ править ]

Проект спецификации DMARC поддерживается с 30 января 2012 года. [18]

В октябре 2013 года был выпущен GNU Mailman 2.1.16 с опциями для обработки плакатов из домена с политикой DMARC p=reject. [12] В этом изменении предпринимались попытки предвидеть проблемы совместимости, ожидаемые в случае применения ограничительных политик к доменам с пользователями-людьми (в отличие от чисто транзакционных почтовых доменов).

В апреле 2014 года Yahoo изменила свою политику DMARC на p=reject, что привело к некорректному поведению в нескольких списках рассылки. [19] Несколько дней спустя AOL также изменила свою политику DMARC на p=reject. [20] Эти действия привели к значительным сбоям в работе, и этих провайдеров почтовых ящиков обвиняли в том, что они переложили издержки, связанные с собственными сбоями безопасности, на третьих лиц. [21] По состоянию на 2020 год, FAQ в официальной вики-странице DMARC содержит несколько предложений по спискам рассылки для обработки сообщений из домена со строгой политикой DMARC, [22] из которых наиболее широко применяется список рассылки, изменяющий «От» заголовок на адрес в собственном домене.

В августе 2014 года была сформирована рабочая группа IETF для решения проблем DMARC, начиная с проблем совместимости и, возможно, продолжая работу над пересмотренной стандартной спецификацией и документацией. [23] Между тем, существующая спецификация DMARC достигла редакционного уровня, согласованного и реализованного многими. Он был опубликован в марте 2015 года в потоке независимых представлений в категории «Информационная» (нестандартная) как RFC 7489. [24]

В марте 2017 года Федеральная торговая комиссия опубликовала исследование использования DMARC предприятиями. [25] Исследование показало, что из 569 предприятий примерно треть реализовала любую конфигурацию DMARC, менее 10% использовали DMARC для указания серверам отклонять неаутентифицированные сообщения, а большинство внедрило SPF.

Авторы [ править ]

В состав спецификации DMARC входят: [26] [27]

  • Получатели: AOL , Comcast , Google ( Gmail ), Mail.Ru , Microsoft ( Outlook.com , Hotmail ), [28] Netease (163.com, 126.com, 188.com, yeah.net), XS4ALL , Yahoo , Яндекс
  • Отправители: American Greetings , Bank of America , Facebook , Fidelity Investments , JPMorganChase , LinkedIn , [29] PayPal , Twitter [30]
  • Посредники и поставщики: [31] Agari (основатель / генеральный директор Патрик Р. Петерсон), [31] Cloudmark, [31] Red Sift , [31] ReturnPath , [31] Проект доверенного домена [31]

См. Также [ править ]

  • Полученная цепочка с проверкой подлинности (ARC)
  • Авторские методы подписания доменов
  • Почта с идентификационными ключами домена (DKIM)
  • E-mail аутентификация
  • Сертифицированная электронная почта
  • Почтовые серверы с DMARC
  • Структура политики отправителя (SPF)

Заметки [ править ]

  1. ^ INVALID - это домен верхнего уровня, зарезервированный RFC 2606 для такого использования.
  2. ^ Использование поля отправителя ремейлерами упоминается (в контексте DKIM, а не DMARC) в разделах B.1.4 и B.2.3 RFC 4871.

Ссылки [ править ]

  1. ^ "FAQ" . ForwardEmail . Проверено 15 июня 2020 . Если отправитель настроил DMARC в своем домене таким образом, что обычная пересылка не удалась, то мы используем этот подход перезаписи «дружественный от», чтобы электронное письмо попало в ваш почтовый ящик, а не было отклонено.
  2. ^ a b > «RFC 7489 - доменная аутентификация сообщений, отчетность и соответствие (DMARC)» . datatracker.ietf.org .
  3. ^ Терри Зинк (27 сентября 2016 г.). «Как мы переместили microsoft.com в запись ap = quarantine DMARC» . Блог MSDN . Если это звучит как большая работа, это потому, что это было
  4. ^ a b Kucherawy, M .; Цвикки, Э. (15 июля 2013 г.). «Доменная проверка подлинности сообщений, отчетность и соответствие (DMARC) [черновик 01]» . IETF. Приложение A.3, Поле заголовка отправителя . Проверено 24 мая +2016 .
  5. ^ «Рекомендации для массовых отправителей - Справка Gmail» . support.google.com . Проверено 24 апреля 2015 года .
  6. ↑ Джон Левин (2 ноября 2017 г.). «Использование списка публичных суффиксов» . Разработчики Mailman (Список рассылки).
  7. ^ "Каково обоснование выбора ZIP для сводных отчетов?" . DMARC.org . 2012 . Проверено 3 апреля 2019 . Как только GZIP будет зарегистрирован в качестве типа приложения MIME в IANA, группа DMARC будет рассматривать его как включение в черновик.
  8. ^ Мюррей С. Кучерави; Элизабет Цвикки, ред. (Март 2015 г.). «Схема XML DMARC» . Аутентификация сообщений, отчетность и соответствие на основе домена (DMARC) . IETF . сек. C. doi : 10.17487 / RFC7489 . RFC 7489 . Проверено 3 марта 2019 .
  9. ^ "Мне нужно реализовать сводные отчеты, как они выглядят?" . DMARC.org . Проверено 26 мая 2016 .
  10. ^ Франк Мартин; Элиот Лир; Тим Дреген; Элизабет Цвикки; Курт Андерсен, ред. (Сентябрь 2016 г.). «Псевдоним» . Проблемы взаимодействия между доменной аутентификацией сообщений, отчетностью и соответствием (DMARC) и косвенными потоками электронной почты . IETF . сек. 3.2.1. DOI : 10,17487 / RFC7960 . RFC 7960 . Проверено 14 марта 2017 года .
  11. ^ dmarc.org вики
  12. ^ a b Марк Сапиро (16 октября 2013 г.). «Почтальон и DMARC» . list.org . Проверено 13 августа 2015 года .
  13. ^ «Предстоящие изменения для lists.debian.org» . lists.debian.org .
  14. ↑ Эл Айверсон (9 апреля 2014 г.). «Ресурс спама: создать список обсуждений по электронной почте? Вот как бороться с DMARC» . spamresource.com . Проверено 18 апреля 2014 года .
  15. ^ «Как Threadable решил проблему DMARC» . Потоковый блог . Проверено 21 мая +2016 .
  16. ^ Теодор Ts'o (18 декабря 2016). «Реалистичные ответы на DMARC» . IETF-Discussion (список рассылки) . Проверено 14 марта 2017 года . Тот факт, что поле from не перезаписывается, ВАЖНО, потому что перезапись поля from приведет к поломке команды "git am", поскольку она использует поле From: для заполнения поля git commit's from.
  17. ↑ Джон Левин (31 мая 2014 г.). «Снижение ущерба DMARC для сторонней почты» . вики . ASRG . Проверено 1 июня 2014 .
  18. ^ "История" , dmarc.org
  19. Перейти ↑ Lucian Constantin (8 апреля 2014 г.). «Политика противодействия спуфингу электронной почты Yahoo нарушает списки рассылки» . Мир ПК . Проверено 15 апреля 2014 года .
  20. ^ Вишванат Субраманян (22 апреля 2014). «AOL Mail обновляет политику DMARC на« отклонить » » . AOL . Архивировано из оригинального 13 августа 2015 года . Проверено 13 августа 2015 года .
  21. ↑ Джон Левин (13 августа 2016 г.). «DMARC и ietf.org» . IETF (список рассылки) . Проверено 10 октября +2016 .
  22. ^ "FAQ в вики DMARC" . Дата обращения 15 июля 2020 .
  23. ^ «Действие РГ: сформированная аутентификация сообщений на основе домена, отчетность и соответствие (dmarc)» . IETF-Announce (список рассылки). 11 августа 2014 . Проверено 10 октября +2016 .
  24. ^ "DMARC FAQ" . dmarc.org .
  25. ^ «Компании могут помочь остановить фишинг и защитить свои бренды с помощью аутентификации по электронной почте» (PDF) . Федеральная торговая комиссия. 3 марта 2017.
  26. ^ Мюррей, Кучерави; Элизабет, Цвикки. «Доменная проверка подлинности сообщений, отчетность и соответствие (DMARC)» . tools.ietf.org .
  27. ^ Участники DMARC (PDF)
  28. ^ Vitaldevara, Криш (10 декабря 2012). «Outlook.com повышает безопасность за счет поддержки сертификатов DMARC и EV» . Блог Outlook . Microsoft . Проверено 12 декабря 2012 года .
  29. ^ Мартин, Франк (20 сентября 2012 г.). «DMARC: новый инструмент для обнаружения подлинных электронных писем» . Инженерный блог LinkedIn . Linkedin . Проверено 17 августа 2013 года .
  30. ^ Josh Aberant (21 февраля 2013). «Представляем DMARC для электронной почты Twitter.com» . twitter.com . Проверено 10 апреля 2014 года .
  31. ^ a b c d e f "История - dmarc.org" . dmarc.org . Проверено 23 сентября 2020 года .

Внешние ссылки [ править ]

  • Официальный сайт
  • Wiki Anti Spam Research Group: Снижение ущерба DMARC для сторонней почты