|
DMARC |
Прокрутить Назад Начало Далее Больше |
В версии MDaemon Pro реализована поддержка DMARC (Domain-based Message Authentication, Reporting & Conformance). Эта техническая спецификация предназначена для борьбы со спамом и "фишерскими" сообщениями, способными скрывать свое истинное происхождение путем подделки заголовковFrom:. Технология DMARC позволит владельцам доменов использовать Систему доменных имен (Domain Name System) для информирования серверов получателя о собственных политиках DMARC, в которых прописаны правила обработки корреспонденции, которая выдает себя за почту с вашего домена, в действительности не являясь таковой. Политика, которую сервер-получатель извлекает посредством DNS-запроса во время обработки входящего сообщения, может требовать отклонения сообщений, не прошедших проверку или их отправки в карантин. Одним из вариантов может являться и отсутствие каких-либо принимаемых мер (сообщение будет обрабатываться в обычном режиме). В дополнение к политике в DNS-записи DMARC конкретного домена может содержаться запрос к серверу на отправку на указанный адрес отчетов DMARC. В отчетах может указываться количество входящих сообщений, выдающих себя за почту с вашего домена, сведения о проваленных и пройденных попытках авторизации и подробная информация о любых обнаруженных отказах. Благодаря отчетам DMARC вы можете, к примеру, оценить эффективность используемых в организации процедур авторизации электронной почты или узнать как часто имена ваших доменов используются в фальшивых письмах.
В диалоговом окне "Параметры безопасности" в разделе "Проверка подлинности пользователя" доступны три экрана для настройки механизмов верификации и составления отчетов DMARC: Верификация DMARC, Отчеты DMARC и Настройки DMARC.
Верификация DMARC
В рамках процесса верификации DMARC сервер MDaemon отправляет DNS-запрос к домену, указанному в заголовке "From:каждого входящего сообщения. Этот запрос позволяет выяснить, использует ли этот домен технологию DMARC, и если использует, то получить его записьDNS DMARC, в которой содержатся действующие политики и другая полезная информация по DMARC. Дополнительно DMARC использует технологииSPFиDKIM. Для успешной верификации DMARC каждое сообщение должно обязательно пройти хотя бы одну из этих проверок. После успешного прохождения проверки приложение будет обрабатываться в рамках стандартных процедур доставки и фильтрации MDaemon. Если проверка провалена, то дальнейшую судьбу сообщения определит действующая в рамках домена политика DMARC и правила обработки подобных сообщений, предусмотренные настройками MDaemon.
Если сообщение не прошло верификацию DMARC, а для домена DMARC установлена политика "p=none", к сообщению не будут применяться никакие штрафные санкции и оно будет обработано сервером в обычном режиме. Напротив, если домен DMARC применяет запрещающую политику "p=quarantine" или "p=reject," сервер MDaemon может автоматически отбраковать сообщение и отправить его в принадлежащую получателю папку для спама (нежелательной корреспонденции). При использовании политики "p=reject" MDaemon способен отклонять сообщения, не прошедшие проверку. В зависимости от действующей политики, сервер MDaemon также добавит к сообщению заголовок "X-MDDMARC-Fail-policy: quarantine" или "X-MDDMARC-Fail-policy: reject". При обнаружении сообщений с таким заголовком вы сможете настроить фильтр содержания на выполнение определенных действий - например, организовать их отправку в особую папку для последующего изучения.
Верификация DMARC включена по умолчанию и рекомендована к использованию в большинстве конфигураций MDaemon.
Отчеты DMARC
Запись DMARC, к которой сервер MDaemon обращается путем DNS-запроса, может содержать разные теги, свидетельствуюшие о том, что владелец домена хочет получать сводные отчеты DMARC или отчеты об отказах, которые касаются сообщений, выдающих себя за письма с данного домена. Параметры на экране "Отчеты DMARC" предназначены для указания того, хотите ли вы отправлять запрошенные типы отчетов или нет. Здесь также можно указать метаданные, которые должны содержать такие отчеты. Сводные отчеты отправляются каждый день, ровно в полночь по всемирному скоординированному времени, а отчеты об отказах генерируются непосредственно в момент инцидента. Отчеты всегда отправляются в виде вложенного сжатого файла XML, а в глобальной сети можно найти множество инструментов, которые помогут получателю анализировать эти отчеты и извлекать из них полезную информацию.
По умолчанию MDaemon не отправляет сводных отчетов или отчетов об отказах. Для их отправки вам необходимо включить соответствующие опции в окне Отчеты DMARC.
Настройки DMARC
На экране Настройки DMARC можно настроить разнообразные параметры, например, определить содержимое отчетов DKIM, организовать регистрацию DNS-записей DMARC в журнале или обновить список публичных суффиксов, используемый функцией DMARC.
Верификация DMARC и списки рассылок
Поскольку основная задача DMARC заключается в том, чтобы убедиться в подлинности домена, указанного в заголовке "From:", серверу-отправителю необходимо разрешить отправку сообщений от имени этого домена. Это может привести к возникновению неожиданных неполадок в работе почтовых рассылок. В рамках почтовой рассылки распространение сообщений от имени членов списка, находящихся за пределами домена, является стандартной практикой. Заголовок From: в таких случаях остается неизменным. Таким образом, когда принимающий сервер попытается применить верификацию DMARC к одному из таких сообщений, может оказаться, что сервер-отправитель официально не связан с доменом, указанным в поле "From:. Если домен DMARC использует ограничивающую политику, то такое сообщение может быть отправлено в карантин или даже отклонено принимающим сервером. А в отдельных случаях результатом возникшего недоразумения может стать автоматическое удаление пользователя из списка членов рассылки. Чтобы избежать этой проблемы, необходимо обеспечить замену заголовка "From:в сообщениях рассылки от домена с ограничительной политикой DMARC, на адрес списка рассылки. Вы также можете настроить сервер MDaemon таким образом, чтобы он отказывался принимать любые сообщения для списков, если оно отправлено доменом, использующим ограничительную политику. Последний способ лишит пользователей с доменов запрещающей полтикой возможности публикации сообщений в списках. Опцию, заменяющую заголовок "From:", можно найти в редакторе почтовых рассылок на страницеЗаголовки. Опция, отклоняющая сообщения, находится на экранеНастройки.
Использование DMARC на ваших доменах MDaemon
Если вы собираетесь использовать DMARC на одном из ваших доменов и готовы предоставить принимающим серверам, также поддерживающим эту технологию, возможность верификации сообщений, выдающих себя за почту с вашего домена, вам понадобятся особым образом оформленные DNS-записи SPF и DKIM для домена. Для использования DMARC вы должны обеспечить корректную работу хотя бы одного из этих механизмов. Если вы используете DKIM, вы должны будете настроить параметры подписывания сообщений домена в окнеDKIM-подписи. Кроме того вам понадобится DNS-запись DMARC для домена. Путем запроса DNS о такой специально отформатированной записи TXT принимающий сервер сможет определить вашу политику DMARC и получить ответы на ряд дополнительных вопросов, в том числе узнать, какие средства авторизации вы используете, хотите ли вы получать сводные отчеты, на какие почтовые адреса должны отправляться эти отчеты и др.
После того как вы правильно настроили DMARC и начали получать отчеты DMARC в формате XML, вам понадобится один из многочисленных инструментов, позволяющих интерпретировать эти отчеты и выявлять потенциальные проблемы. Для вашего удобства в папке \MDaemon\App\ доступен инструмент DMARC Reporter. Инструкции по его использованию вы найдете в файле DMARCReporterReadMe.txt.
Настройка ресурсной записи DMARC TXT
Ниже вы найдете краткий обзор основных, наиболее распространенных компонентов записи DMARC. Более подробную информацию можно найти на сайте:www.dmarc.org.
Поле "Владелец" (Owner)
Поле "Владелец" (также иногда называется "Имя" или "левая часть") является обязательным элементом ресурсной записи DMARC, которое всегда имеет следующий вид "_dmarc", впрочем, иногда она может принимать и такой вид "_dmarc.domain.name",если вы хотите уточнить домены или субдомены, к которым применяется запись.
Пример:
Запись DMARC для доменаexample.com
_dmarc IN TXT "v=DMARC1;p=none"
Эта запись будет применяться ко всей эл. почте от user@example.com или от любых субдоменов example.com, таких, как user@support.example.com, user@mail.support.example.com и др.
_dmarc.support.example.com IN TXT "v=DMARC1;p=none"
Эта запись применяется только к электронной почте от user@support.example.com и не касается писем, отправленных, например с адреса user@example.com.
_dmarc.support IN TXT "v=DMARC1;p=none"
Эта запись применяется к электронной почте от user@support.example.com, user@a.support.example.com, user@a.b.support.example.com и др.
Теги записи DMARC и их значения
Обязательные теги
Тег |
Значение |
Примечания |
v= |
DMARC1 |
Это тег "Version", который должен стоять первым в текстовой части записи DMARC. Хотя значения других тегов DMARC не чувствительны к регистру, значение тегаv=должно указываться символами верхнего регистра:DMARC1. Пример: _dmarc IN TXT "v=DMARC1;p=none" |
p= |
none quarantine reject |
Это тег "Policy", который должен стоять вторым в записи DMARC, сразу за тегомv=. p=noneозначает, что принимающий сервер не должен предпринимать никаких действий по результатам запроса DMARC. Сообщения, не прошедшие проверку DMARC не должны отклоняться или отправляться в карантин по этой причине. Впрочем, к этим сообщениям могут применяться указанные штрафные санкции по иным причинам, например в случае проваленной проверки спам-фильтром или другими средствами защиты, не связанными с DMARC. Использование политики p=noneв некоторых случаях называют "мониторингом" или "режимом мониторинга", покольку она может использоваться в сочетании с тегомrua=для получения от принимающего домена сводных отчетов о ваших сообщениях, при этом сами сообщения не будут наказываться за проваленную проверку DMARC. Эта политика может использоваться для тщательного тестирования вашей конфигурации DMARC до тех пор, пока вы не будете готовы к переходу к более жесткой политикеp=quarantine. Используйте политику p=quarantine, если вы хотите, чтобы принимающий почтовый сервер с подозрением относился к сообщениям, содержащим ваш адрес в заголовкеFrom:, но не способным пройти проверку DMARC. В зависимости от локальной политики сервера, такие сообщения могут стать объектом более пристального внимания, перенаправлены в папку со спамом, переданы на другой сервер и др. p=rejectозначает, что вы хотите, чтобы принимающий сервер отклонял любые сообщения, не прошедшие верификацию DMARC. Некоторые серверы, впрочем, могут все же принять такое сообщение для его последующей отправки в карантин или более тщательного изучения. Это наиболее жесткая политика, к которой следует прибегать лишь в тех случаях, когла вы абсолютно уверены в необходимости подобных ограничений. Например, если вы разрешаете пользоваелям подписываться на сторонние рассылки, работать с сервисами маршрутизации, "лайкать" записи в социальных сетях или "делиться" различной информацией с друзьями, применение политикиp=rejectпочти наверняка сделает невозможной указанную активность и может привести к отклонению некоторых легитимных сообщений. Кроме того, иногда в результате действия политики пользователи будут автоматически отписаны от определенных почтовых рассылок. Пример: _dmarc IN TXT "v=DMARC1;p=quarantine;rua=mailto:dmarc-report@example.net" |
Опциональные теги
Все перечисленные ниже теги являются опциональными. При отсутствии одного из этих тегов в записи принимается его значение по умолчанию.
Тег |
Значение |
Примечания |
sp= |
none quarantine reject — По умолчанию: Если тегsp=не используется, в отношении домена и его субдоменов будет действовать политика, определяемая тегом p=. |
Этот тег предназначен для выбора политики для субдоменов того домена, к которому применяется запись DMARC. К примеру, если этот тег используется в записи для домена example.com, то политика, определяемая тегомp=, будет применяться к сообщениям с example.com, а политикаsp=будет применяться к сообщениям с субдоменов example.com, таких как mail.example.com. При отсутствии указанного тега политика для домена и субдоменов определяется тегомp=. Пример: _dmarc IN TXT "v=DMARC1;p=quarantine;sp=reject" |
rua= |
Список перечисленных через запятую почтовых адресов, на которые должны отправляться сводные отчеты DMARC. Адреса должны указываться в виде идентификаторов URI в записи следующего вида: — По умолчанию: none Если этот тег не используется, сводные отчеты отправляться не будут. |
Этот тег означает, что вы хотите получать сводные отчеты DMARC от серверов, которые принимают сообщения, утверждающие, что являются почтой с вашего домена. Укажите один или несколько адресов электронной почты в качестве идентификаторов URI в записи следующего вида: mailto:user@example.com.Многочисленные URI отделяются друг от друга запятыми. Пример: _dmarc IN TXT "v=DMARC1;p=quarantine;rua=mailto:user01@example.com,mailto:user02@example.com" Обычно эти адреса относятся к домену, к которому применяется данная запись. Если же вы хотите отправлять отчеты на почтовый адрес, относящийся к другому домену, в файле зоны DNS этого домена также должна присутствовать особая запись, позволяющая ему принимать отчеты DMARC. Образец записи для example.com: _dmarc IN TXT "v=DMARC1;p=quarantine;rua=mailto:non-local-user@example.net" Необходимая запись на example.net: example.com._report._dmarc TXT "v=DMARC1" |
ruf= |
Список перечисленных через запятую почтовых адресов, на которые должны отправляться отчеты об отказах DMARC. Адреса должны указываться в виде идентификаторов URI в записи следующего вида: — По умолчанию: none Если этот тег не используется, отчеты об отказах отправляться не будут |
Этот тег означает, что вы хотите получать отчеты об отказах DMARC от серверов, которые принимают сообщения, утверждающие, что являются почтой с вашего домена.Отчеты отправляются при выполнении условий, определяемых тегомfo=. При отсутствии тегаfo=используются настройки по умолчанию и отчеты об отказе отправляются в тех случаях, если сообщение не прошло ни одной проверки DMARC (например, провалило верификацию SPF и DKIM). Укажите один или несколько адресов электронной почты в качестве идентификаторов URI в записи следующего вида:mailto:user@example.comМногочисленные URI отделяются друг от друга запятыми. Пример: _dmarc IN TXT "v=DMARC1;p=quarantine;ruf=mailto:dmarc-failures@example.com" Обычно эти адреса относятся к домену, к которому применяется данная запись. Если же вы хотите отправлять отчеты на почтовый адрес, относящийся к другому домену, в файле зоны DNS этого домена также должна присутствовать особая запись, позволяющая ему принимать отчеты DMARC. Образец записи для example.com: _dmarc IN TXT "v=DMARC1;p=quarantine;ruf=mailto:non-local-user@example.net" Необходимая запись на example.net: example.com._report._dmarc TXT "v=DMARC1" |
Более подробную информацию о спецификации DMARC ищите на сайтеwww.dmarc.org.
См. также:
