|
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 использует ограничительную политику DMARC, это может привести к тому, что сообщение будет помещено в карантин или даже отклонено принимающим сервером. В некоторых случаях это также может привести к удалению получателя из списка участников. Чтобы обойти эту проблему, когда MDaemon обнаруживает, что сообщение для списка приходит из домена с ограничительной политикой DMARC, MDaemon заменит заголовок From: сообщения на адрес списка рассылки. В качестве альтернативы, вы можете настроить MDaemon на отказ принимать любое сообщение для списка, если оно пришло из домена с ограничительной политикой. Последняя опция фактически сделает невозможной публикацию сообщения в список для пользователя из домена с ограничительной политикой. Опция замены заголовка "От:" находится на экране "Заголовки" редактора списка рассылки, а опция отклонения сообщений - на его экране "Настройки". Примечание: SMTP-сервер будет искать политику DMARC отправителя, когда это необходимо для этих связанных с DMARC настроек списка рассылки, даже если соединение освобождено от обработки DMARC.
Использование 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.
См. также:
