ДМАРК
Аутентификация, отчетность и соответствие сообщений на основе домена ( DMARC ) — это протокол аутентификации электронной почты . Он предназначен для того, чтобы дать владельцам доменов электронной почты возможность защитить свой домен от несанкционированного использования, широко известного как подмена электронной почты . Целью и основным результатом внедрения DMARC является защита домена от использования в атаках на корпоративную электронную почту , фишинговой электронной почте, мошенничестве с электронной почтой и других киберугрозных действиях.
После публикации записи DNS DMARC любой получающий сервер электронной почты может аутентифицировать входящее электронное письмо на основе инструкций, опубликованных владельцем домена в записи DNS. Если электронное письмо пройдет аутентификацию, оно будет доставлено, и ему можно будет доверять. Если электронное письмо не проходит проверку, в зависимости от инструкций, содержащихся в записи DMARC, электронное письмо может быть доставлено, помещено в карантин или отклонено.
DMARC расширяет два существующих механизма аутентификации электронной почты: Sender Policy Framework (SPF) и DomainKeys Identified Mail (DKIM). Это позволяет администратору домена публиковать политику в своих записях DNS , чтобы указать, как проверять From: поле, представленное конечным пользователям; как получатель должен реагировать на сбои, а также обеспечивает механизм отчетности о действиях, выполненных в соответствии с этими политиками.
DMARC определен в Internet Engineering Task Force . опубликованном документе RFC 7489 [1] от марта 2015 года как «Информационная». [2]
Обзор
[ редактировать ]Политика DMARC позволяет домену отправителя указывать, что его сообщения электронной почты защищены SPF и/или DKIM, и сообщает получателю, что делать, если ни один из этих методов аутентификации не проходит – например, отклонить сообщение или поместить его в карантин. Политика также может указывать, как получатель электронной почты может сообщать домену отправителя о сообщениях, которые прошли или не прошли. [3]
Эти политики публикуются в общедоступной системе доменных имен (DNS) в виде текстовых записей TXT .
DMARC не определяет напрямую, является ли электронное письмо спамом или иным образом мошенническим. Вместо этого DMARC может потребовать, чтобы сообщение не только прошло проверку DKIM или SPF, но и прошло § Alignment . В соответствии с DMARC сообщение может завершиться ошибкой, даже если оно прошло проверку SPF или DKIM, но не прошло выравнивание. [4]
Настройка DMARC может улучшить доставляемость сообщений от законных отправителей. [5]
Выравнивание
[ редактировать ]DMARC работает, проверяя, что домен в сообщении From: поле (также называемое «RFC5322.From» [2] ) «согласован» с другими аутентифицированными доменными именами. Если какой-либо SPF (указанный с помощью aspf поле) или DKIM (указывается с помощью поля adkim) проверки выравнивания проходят, затем проходит тест выравнивания 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. [2]
DKIM позволяет криптографически подписывать части сообщения электронной почты, при этом подпись должна закрывать поле «От». В заголовке письма DKIM-Signature d= (домен) и s= Теги (селектора) указывают, где в DNS получить открытый ключ для подписи. Действительная подпись доказывает, что подписывающая сторона является владельцем домена и что поле «От» не изменялось с момента применения подписи. В сообщении электронной почты может быть несколько подписей DKIM; DMARC требует одну действительную подпись, если домен в d= тег соответствует домену отправителя, указанному в From: поле заголовка.
DNS-запись
[ редактировать ]Записи DMARC публикуются в DNS с меткой поддомена. _dmarc, например _dmarc.example.com. Сравните это с SPF на example.comи DKIM в selector._domainkey.example.com.
Содержимое записи ресурса TXT состоит из name=value теги, разделенные точкой с запятой, аналогично SPF и DKIM.
Доступные теги: [7]
- adkim , режим выравнивания DKIM
- aspf , режим выравнивания SPF
- fo , варианты отчетов об ошибках
- p , политика (см. ниже),
- pct — процент «плохих» писем, к которым применяется политика.
- rf , формат отчетов об ошибках для конкретных сообщений
- ri , запрошенный интервал между сводными отчетами
- rua , URI для отправки сводных отчетов.
- ruf , URI для отправки отчетов о сбоях/экспертных отчетах
- sp , политика поддоменов,
- v , version,
Например:
"v=DMARC1;p=none;sp=quarantine;pct=100;rua=mailto:[email protected];"
В этом примере объект, контролирующий DNS-домен example.com, намеревается отслеживать частоту сбоев SPF и/или DKIM и не ожидает, что электронная почта будет отправляться с поддоменов example.com. Обратите внимание, что субдомен может публиковать собственную запись DMARC; получатели должны проверить это, прежде чем вернуться к записи домена организации.
Шаг за шагом принятие
[ редактировать ]Протокол предусматривает различные храповые состояния или переходные состояния, позволяющие администраторам почты постепенно переходить от полного отсутствия реализации DMARC к жесткой настройке. [8] [9] [10] Концепция поэтапного внедрения предполагает, что целью DMARC является максимально сильная настройка, что справедливо не для всех доменов. Независимо от намерения, эти механизмы обеспечивают большую гибкость.
Политика
[ редактировать ]Прежде всего, есть три политики:
- none — это политика начального уровня. Получателям не требуется никакого специального обращения, но позволяет домену получать отчеты обратной связи.
- карантин просит получателей относиться к сообщениям, не прошедшим проверку DMARC, с подозрением. У разных получателей есть разные средства для реализации этой цели, например, помечать сообщения или доставлять их в папку со спамом.
- «Отклонить» просит получателей полностью отклонять сообщения, не прошедшие проверку DMARC.
Опубликованную политику можно смягчить, применив ее только к проценту сообщений, не прошедших проверку DMARC. Получателям предлагается выбрать заданный процент сообщений с помощью простого алгоритма выборки Бернулли . Остальные сообщения должны подвергаться более низкой политике; то есть нет, если p=quarantine, карантин, если p=reject. Если не указано, pct по умолчанию равен 100% сообщений. Дело p=quarantine; pct=0; используется, чтобы заставить менеджеров списков рассылки переписать поле «От:», поскольку некоторые не делают этого, когда p=none. [11]
Наконец, политика поддоменов, sp= и недавно добавленная политика отсутствия доменов, np=[12] разрешить настройку политики для определенных поддоменов.
Отчеты
[ редактировать ]DMARC способен создавать два отдельных типа отчетов. Сводные отчеты отправляются на адрес, указанный после rua. Отчеты судебно-медицинской экспертизы отправляются по электронной почте на адрес, следующий за ruf ярлык. Эти почтовые адреса должны быть указаны в формате URI mailto (например, mailto: [email protected] ). Допустимо несколько адресов отчетов, каждый из которых должен быть в полном формате URI, разделенный запятой. [13]
Целевые адреса электронной почты могут принадлежать внешним доменам. В этом случае целевой домен должен настроить запись 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). [14]
Например:
example.com!example.org!1475712000!1475798400.xml.gz.
Содержимое XML состоит из заголовка, содержащего политику, на которой основан отчет, и метаданные отчета, за которыми следует ряд записей. Записи можно помещать в базу данных как отношения и просматривать в табличной форме. Схема XML определена в Приложении C спецификаций. [15] пример необработанной записи представлен на сайте dmarc.org. [16] Здесь мы придерживаемся реляционного примера, который лучше передает природу данных. Записи DMARC также можно напрямую преобразовать в HTML, применив таблицу стилей XSL .
| Исходный IP-адрес | Считать | Расположение | СПФ | ДКИМ | Заголовок из | Домен SPF (результат) | Домен DKIM (результат) | |
|---|---|---|---|---|---|---|---|---|
| 192.0.2.1 | 12 | никто | ✓ Pass | ✓ Pass | example.org | example.org ( ✓ Pass ) | example.org ( ✓ Pass ) | |
| 192.0.2.1 | 1 | никто | ✓ Pass | ✗ Fail | example.org | example.org ( ✓ Pass ) | example.org ( ✗ Fail ) | |
| 192.0.2.28 | 42 | никто | ✗ Fail | ✓ Pass | example.org | example.org ( ✗ Fail ) | example.org ( ✓ Pass ) | forwarder.example ( ✓ Пройдено ) |
| 192.0.2.82 | 21 | никто | ✗ Fail | ✗ Fail | example.org | обсудить список.пример ( ✓ Пройдено ) | example.org ( ✗ Fail ) | обсудить список.пример ( ✓ Пройдено ) |
| ... | ||||||||
Строки группируются по исходному IP-адресу и результатам аутентификации, передавая только количество каждой группы. Крайние левые столбцы результатов, помеченные как SPF и DKIM, показывают результаты по DMARC: пройдены или нет, с учетом выравнивания. Крайние правые с похожими метками показывают имя домена, который утверждает, что участвует в отправке сообщения, и (в скобках) статус аутентификации этого утверждения в соответствии с исходным протоколом, SPF или DKIM, независимо от выравнивания идентификаторов. Справа SPF может появиться не более двух раз, один раз для Return-Path: тест и один раз для HELO тест; DKIM может появляться один раз для каждой подписи, присутствующей в сообщении. В примере первая строка представляет основной поток почты с сайта example.org, а вторая строка — сбой DKIM, например, поломка подписи из-за незначительного изменения при передаче. В третьей и четвертой строках показаны типичные режимы сбоев пересылки и списка рассылки соответственно. Аутентификация DMARC не удалась только для последней строки; это могло бы повлиять на расположение сообщений, если бы на сайте example.org была указана строгая политика.
Расположение : отражает опубликованную политику, фактически примененную к сообщениям none , карантин или отклонение . Помимо этого, не показанного в таблице, DMARC обеспечивает переопределение политики. Некоторые причины, по которым получатель может применить политику, отличную от запрошенной, уже предусмотрены спецификацией:
- перенаправлено
- сохраняя тот же адрес возврата, обычно не нарушает DKIM,
- отобрано
- поскольку отправитель может применить политику только к определенному проценту сообщений,
- доверенный экспедитор
- сообщение пришло из локально известного источника
- список рассылки
- получатель эвристически определил, что сообщение пришло из списка рассылки,
- местная политика
- Получатели, очевидно, могут свободно применять политику, которая им нравится, просто здорово сообщить об этом отправителям,
- другой
- если ничего из вышеперечисленного не применимо, поле комментария позволяет сказать больше.
Судебно-медицинские отчеты
[ редактировать ]Отчеты о криминалистических исследованиях, также известные как отчеты об ошибках, генерируются в режиме реального времени и состоят из отредактированных копий отдельных сообщений, в которых произошел сбой SPF, DKIM или обоих, в зависимости от того, какое значение указано в fo ярлык. Их формат, являющийся расширением формата отчетов о злоупотреблениях , напоминает формат обычных отказов, поскольку они содержат либо «message/rfc822», либо «text/rfc822-headers».
Отчеты судебно-медицинской экспертизы также содержат следующее:
- Источник отправки IP-адреса
- С адреса электронной почты
- Адрес электронной почты получателя
- Тема письма
- Результаты аутентификации SPF и DKIM
- Время получения
- Заголовки сообщений электронной почты, которые включают хост-отправитель, идентификатор сообщения электронной почты, подпись DKIM и любую другую настраиваемую информацию заголовка. [17]
Совместимость
[ редактировать ]Экспедиторы
[ редактировать ]Существует несколько различных типов пересылки электронной почты , некоторые из которых могут нарушить SPF. [18] Это одна из причин, по которой пересылка электронной почты может повлиять на результаты аутентификации DMARC. [19]
Списки рассылки
[ редактировать ]Списки рассылки являются частой причиной законного взлома подписи DKIM домена исходного автора, например, путем добавления префикса к заголовку темы. Возможны несколько обходных путей, [20] [21] и пакеты программного обеспечения для списков рассылки работают над решением. [22]
Отключить все изменения сообщений
[ редактировать ]Этот обходной путь сохраняет стандартный рабочий процесс списка рассылки и применяется несколькими крупными операторами списков рассылки, но исключает добавление в список нижних колонтитулов и префиксов тем. [23] Это требует тщательной настройки почтового программного обеспечения, чтобы гарантировать, что подписанные заголовки не будут переупорядочены или изменены. Неправильно настроенный почтовый сервер может поместить List-id в свой DKIM сообщений, отправляемых в список рассылки, а затем оператор списка будет вынужден отклонить его или выполнить перезапись From:.
From: переписывание
[ редактировать ] Один из самых популярных и наименее навязчивых обходных путей состоит в переписывании From: поле заголовка. Оригинальный адрес автора может быть добавлен в Reply-To: поле. [24] Переписывание может варьироваться от простого добавления .INVALID[примечание 1] к имени домена, к выделению временного идентификатора пользователя, где используется измененная версия адреса пользователя, или используется непрозрачный идентификатор, который сохраняет «реальный» адрес электронной почты пользователя конфиденциальным из списка. Кроме того, отображаемое имя можно изменить, чтобы отображались как автор, так и список (или оператор списка). [25] Эти примеры приведут, соответственно, к одному из следующих результатов:
From: John Doe <[email protected]>
From: John Doe <[email protected]>
From: John Doe <[email protected]>
From: John Doe via MailingList <[email protected]>
Reply-To: John Doe <[email protected]>
Последняя строка, Reply-To:, должен быть спроектирован таким образом, чтобы обеспечить возможность ответа автору, и в этом случае функция ответа в список покрывается предыдущим изменением в From: поле заголовка. Таким образом, исходное значение этих полей меняется на противоположное.
Изменение автора в целом несправедливо и может нарушить ожидаемую связь между значением и внешним видом этих данных. Это также нарушает автоматическое его использование. Существуют сообщества, которые используют списки рассылки для координации своей работы и развертывают инструменты, использующие From: поле для указания авторства вложений. [26]
Другие обходные пути
[ редактировать ]Обертывание сообщения хорошо работает для тех, кто использует почтовый клиент, который понимает упакованные сообщения. Не вносить никаких изменений, возможно, является наиболее очевидным решением, за исключением того, что в некоторых странах они, похоже, требуются по закону, и что регулярная потеря аутентификации SPF может сделать общую аутентификацию более хрупкой. [27]
Поле отправителя
[ редактировать ]Внесение изменений в From: Поле заголовка для прохождения выравнивания DKIM может привести к тому, что сообщение не будет соответствовать разделу 3.6.2 RFC 5322: «Поле «От:» указывает автора(ов) сообщения, то есть почтовый ящик(а) человека( или систему(ы), ответственную(ые) за написание сообщения». Почтовый ящик относится к адресу электронной почты автора. Sender: Доступен заголовок, указывающий, что электронное письмо было отправлено от имени другой стороны, но DMARC проверяет политику только для домена «От» и игнорирует домен «Отправитель». [примечание 2]
И ADSP , и DMARC [4] отклонить использование поля «Отправитель» по нетехническим причинам, поскольку многие пользовательские агенты не отображают это поле получателю.
История
[ редактировать ]Проект спецификации DMARC поддерживается с 30 января 2012 года. [28]
В октябре 2013 года был выпущен GNU Mailman 2.1.16 с возможностью обработки плакатов из домена с политикой DMARC p=reject. [22] Это изменение было направлено на то, чтобы предвидеть проблемы совместимости, ожидаемые в случае применения ограничительных политик к доменам с пользователями-людьми (в отличие от чисто транзакционных почтовых доменов).
В апреле 2014 года Yahoo изменила свою политику DMARC на p=reject, тем самым вызывая неправомерное поведение в нескольких списках рассылки. [29] [30] Несколько дней спустя AOL также изменила свою политику DMARC на p=reject. [31] Эти действия привели к значительному количеству сбоев, и этих провайдеров почтовых ящиков обвинили в том, что они переложили расходы, связанные с собственными сбоями в системе безопасности, на третьи стороны. [32] По состоянию на 2020 год FAQ в официальной вики DMARC содержит несколько предложений по спискам рассылки для обработки сообщений из домена со строгой политикой DMARC. [33] наиболее широко реализованным из них является список рассылки, меняющий заголовок «От» на адрес в собственном домене.
Рабочая группа IETF была сформирована в августе 2014 года для решения проблем DMARC, начиная с проблем совместимости и, возможно, продолжая пересмотренной стандартной спецификацией и документацией. [34] Тем временем существующая спецификация DMARC достигла редакционного состояния, согласованного и реализованного многими. Он был опубликован в марте 2015 года в потоке Independent Submission в категории «Информационные» (нестандартные) под номером RFC 7489. [35]
В марте 2017 года Федеральная торговая комиссия опубликовала исследование использования DMARC предприятиями. [36] Исследование показало, что из 569 предприятий около трети внедрили любую конфигурацию DMARC, менее 10% использовали DMARC для указания серверам отклонять неаутентифицированные сообщения, а большинство внедрили SPF.
Авторы
[ редактировать ]В число разработчиков спецификации DMARC входят: [37] [38]
- Получатели: AOL , Comcast , Google ( Gmail ), Mail.Ru , Microsoft ( Outlook.com , Hotmail ), [39] Netease (163.com, 126.com, 188.com, Yeah.net), XS4ALL , Yahoo , Яндекс
- Отправители: American Greetings , Bank of America , Facebook , Fidelity Investments , JPMorganChase , LinkedIn , [40] PayPal , Твиттер [41]
- Посредники и продавцы: [42] Агари (основатель/генеральный директор Патрик Р. Петерсон), [42] облачный знак, [42] Советник DMARC , [42] Красный Сифт , [42] Путь возврата , [42] Проект доверенного домена , [42] ПроДМАРК , [42]
См. также
[ редактировать ]- Аутентифицированная полученная цепочка (ARC)
- Практика подписания авторского домена
- Индикаторы бренда для идентификации сообщений (BIMI)
- Идентифицированная почта DomainKeys (DKIM)
- Аутентификация по электронной почте
- Сертифицированный адрес электронной почты
- Почтовые серверы с DMARC
- Структура политики отправителей (SPF)
Примечания
[ редактировать ]Ссылки
[ редактировать ]- ^ RFC 7489
- ^ Перейти обратно: а б с Мюррей Кучерави ; Элизабет Цвики (18 марта 2015 г.). Аутентификация сообщений, отчетность и соответствие на основе домена (DMARC) . IETF . дои : 10.17487/RFC7489 . РФК 7489 .
- ^ Терри Зинк (27 сентября 2016 г.). «Как мы переместили microsoft.com в запись ap=quarantine DMARC» . MSDN Блог .
Если это звучит как большая работа, то это потому, что это было
- ^ Перейти обратно: а б Кучерави, М. ; Цвики, Э. (15 июля 2013 г.). «Аутентификация, отчетность и соответствие сообщений на основе домена (DMARC) [проект 01]» . IETF. Приложение A.3, Поле заголовка отправителя . Проверено 24 мая 2016 г.
- ^ «Правила для массовых рассылок – Справка Gmail» . support.google.com . Проверено 24 апреля 2015 г.
- ^ Джон Левин (2 ноября 2017 г.). «Использование общедоступного списка суффиксов» . Разработчики Mailman (список рассылки).
- ^ РФК 7489 . сек. 6.3. дои : 10.17487/RFC7489 .
- ^ «Руководство: Рекомендуемое развертывание DMARC» . гугл.com .
- ^ «Руководство по внедрению: защита домена электронной почты» . cyber.gc.ca . 12 августа 2021 г.
- ^ «Руководство пользователя по Cisco Domain Protection» (PDF) . Cisco.com . 25 мая 2021 г.
- ^ Джонатан Каменс (9 октября 2018 г.). " "p=none" vs. "p=quarantine; pct=0" " (список рассылки).
- ^ Скотт Киттерман (26 июля 2021 г.). Тим Вичински (ред.). Экспериментальное расширение проверки подлинности сообщений, отчетности и соответствия на основе доменов (DMARC) для доменов с публичными суффиксами . IETF . дои : 10.17487/RFC9091 . РФК 9091 .
- ^ «RUA против RUF – объяснение различных типов отчетов DMARC» . Прогист.нет . Проверено 14 декабря 2023 г.
- ^ «Каково обоснование выбора ZIP для сводных отчетов?» . DMARC.org . 2012 . Проверено 3 апреля 2019 г.
Как только GZIP будет зарегистрирован в качестве типа приложения MIME в IANA, группа DMARC рассмотрит его включение в проект.
- ^ Мюррей С. Кучерави ; Элизабет Цвикки, ред. (март 2015 г.). «XML-схема DMARC» . Аутентификация сообщений, отчетность и соответствие на основе домена (DMARC) . IETF . сек. C. doi : 10.17487/RFC7489 . РФК 7489 . Проверено 3 марта 2019 г.
- ^ «Мне нужно реализовать сводные отчеты, как они выглядят?» . DMARC.org . Проверено 26 мая 2016 г.
- ^ «Полное руководство по отчетности DMARC в 2022 году» . 23 августа 2019 г.
- ^ Франк Мартин; Элиот Лир; Тим Дреген; Элизабет Цвикки; Курт Андерсен, ред. (сентябрь 2016 г.). «Псевдоним» . Проблемы совместимости между проверкой подлинности сообщений, отчетностью и соответствием на основе домена (DMARC) и косвенными потоками электронной почты . IETF . сек. 3.2.1. дои : 10.17487/RFC7960 . РФК 7960 . Проверено 14 марта 2017 г.
- ^ «Как пересылка электронной почты влияет на результаты аутентификации DMARC?» . progist.net . 6 января 2023 г.
- ^ Группа исследований по борьбе со спамом . «Уменьшение ущерба DMARC для почты третьих лиц» .
- ^ вики dmarc.org
- ^ Перейти обратно: а б Марк Сапиро (16 октября 2013 г.). «Почтальон и DMARC» . список.орг . Проверено 13 августа 2015 г.
- ^ «Предстоящие изменения для lists.debian.org» . lists.debian.org .
- ^ Эл Айверсон (9 апреля 2014 г.). «Ресурс по спаму: создайте список обсуждений по электронной почте? Вот как бороться с DMARC» . спамресурс.com . Проверено 18 апреля 2014 г.
- ^ «Как Threadable решил проблему DMARC» . Потоковый блог . Проверено 21 мая 2016 г.
- ^ Теодор Цо (18 декабря 2016 г.). «Реалистичные ответы на DMARC» . IETF-обсуждение (список рассылки) . Проверено 14 марта 2017 г.
Тот факт, что поле from не перезаписывается, ВАЖЕН, потому что переписывание поля from нарушит работу команды «git am», поскольку она использует поле From: для заполнения поля from git commit.
- ^ Джон Левин (31 мая 2014 г.). «Уменьшение ущерба DMARC для почты третьих лиц» . вики . АСРГ . Проверено 1 июня 2014 г.
- ^ «История» , dmarc.org.
- ^ Лучиан Константин (8 апреля 2014 г.). «Политика Yahoo по борьбе с подделкой электронной почты нарушает списки рассылки» . Мир ПК . Проверено 15 апреля 2014 г.
- ^ Лора Аткинс (12 апреля 2014 г.). «Заявление Yahoo о политике DMARC» . wordtothewise.com.
- ^ Вишванат Субраманиан (22 апреля 2014 г.). «AOL Mail обновляет политику DMARC на «отклонять » . АОЛ . Архивировано из оригинала 13 августа 2015 года . Проверено 13 августа 2015 г.
- ^ Джон Левин (13 августа 2016 г.). «DMARC и ietf.org» . IETF (список рассылки) . Проверено 10 октября 2016 г.
- ^ «Часто задаваемые вопросы в вики DMARC» . Проверено 15 июля 2020 г.
- ^ «Действие рабочей группы: проверка подлинности, отчетность и соответствие сообщений на основе сформированного домена (dmarc)» . Объявление IETF (список рассылки). 11 августа 2014 года . Проверено 10 октября 2016 г.
- ^ «Часто задаваемые вопросы по DMARC» . dmarc.org .
- ^ «Компании могут помочь остановить фишинг и защитить свои бренды с помощью аутентификации по электронной почте» (PDF) . Федеральная торговая комиссия. 3 марта 2017 г.
- ^ Кучерави, Мюррей; Цвики, Элизабет. «Благодарности» . Аутентификация сообщений, отчетность и соответствие на основе домена (DMARC) . сек. E. ID черновика-kucherawy-dmarc-base-01.
- ^ Участники DMARC (PDF)
- ^ Витальдевара, Криш (10 декабря 2012 г.). «Outlook.com повышает безопасность благодаря поддержке сертификатов DMARC и EV» . Блог Outlook . Майкрософт . Проверено 12 декабря 2012 г.
- ^ Мартин, Франк (20 сентября 2012 г.). «DMARC: новый инструмент для обнаружения подлинных электронных писем» . Инженерный блог LinkedIn . Линкедин . Проверено 17 августа 2013 г.
- ^ Джош Аберант (21 февраля 2013 г.). «Представляем DMARC для электронной почты Twitter.com» . Твиттер.com . Проверено 10 апреля 2014 г.
- ^ Перейти обратно: а б с д и ж г час «История — dmarc.org» . dmarc.org . Проверено 23 сентября 2020 г.
Внешние ссылки
[ редактировать ]- Официальный сайт
- Вики-сайт The Anti Spam Research Group: уменьшение ущерба, наносимого DMARC сторонней почте