27 февраля в 17:14

DMARC: защитите вашу рассылку от подделок

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

Такие письма причиняют ущерб адресатам, что, в конечном счете, сказывается на репутации как самих добропорядочных сервисов, так и почтовых провайдеров.

Теперь мы даем сервисам, которые ведут свои рассылки, возможность защититься от такого рода подделок с помощью технологии DMARC (dmarc.org), которую мы поддержали первыми среди крупных почтовых сервисов в рунете.



Как работает DMARC


Суть технологии проста: вы как владелец домена, с которого ведутся рассылки, можете прописать в DNS своего домена политику, определяющую, что делать с письмами, которые признаны поддельными.

Письма могут быть пропущены, положены в папку «Спам» или вообще не приняты почтовым сервером.

Для работы этой технологии требуется настроить SPF для вашего домена и подписывать каждое письмо DKIM-подписью. При этом домен DKIM должен совпадать с доменом в заголовке From.

При получении письма наш сервер проверит валидность SPF и DKIM. В случае, если проверка и DKIM и SPF не пройдена, к письму будет применена DMARC-политика вашего домена.

Я уже хочу. Что мне делать?


Первое, что необходимо сделать — решить, как будет внедряться DMARC. Мы рекомендуем делать это не сразу, а постепенно:

  • Сначала включить только получение отчетов и пропускать все письма. Это необходимо, чтобы убедиться, что все письма корректно подписаны.
  • Далее можно включить применение политики только на какой-то небольшой процент траффика с помощью опции pct
  • Если в отчетах не обнаружено проблем, можно включать политику на 100%


Такой пошаговый подход позволит вовремя выявить проблемы с DKIM-подписью, если они есть, и исправить их прежде, чем политика будет развернута на 100%.

Для включения политики DMARC нужно разместить в DNS-записи вашего сайта новую TXT-запись вида:

_dmarc.exampledomain.ru.	3600	IN	TXT	"v=DMARC1; p=none; rua=mailto: [email protected] " 


В таком виде запись означает, что все поддельные письма нужно пропускать, а отчеты надо высылать на ящик [email protected]; exampledomain.ru необходимо заменить на ваш домен.

Если вы хотите получать отчеты на домен, который не совпадает с доменом DMARC, вам необходимо разместить TXT-запись для почтового домена специального вида. Допустим, ваш домен с DMARC — exampledomain.ru, а получать отчеты вы хотите на домен test.ru. В таком случае необходимо в DNS домена test.ru добавить TXT-запись вида:

exampledomain.ru._report._dmarc.test.ru.  3600  IN   TXT "v=DMARC1"


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

Как выглядит отчет?


Ежедневные агрегированные отчеты приходят в формате XML с адреса [email protected].

Ниже — пример отчета о том, что с одного IP-адреса было отправлено 20 писем, и все они прошли проверку.

  <feedback>
    <report_metadata>
      <date_range>
        <begin>1361304000</begin>
        <end>1361390400</end>
      </date_range>
      <email>[email protected]</email>
      <extra_contact_info>http://corp.mail.ru/en</extra_contact_info>
      <org_name>Mail.Ru</org_name>
      <report_id>1361304000874948</report_id>
    </report_metadata>
    <policy_published>
      <adkim>r</adkim>
      <aspf>r</aspf>
      <domain>adan.ru</domain>
      <p>none</p>
      <pct>100</pct>
      <sp>none</sp>
    </policy_published>
    <record>
      <auth_results>
        <dkim>
          <domain>adan.ru</domain>
          <result>pass</result>
        </dkim>
        <spf>
          <domain>adan.ru</domain>
          <result>pass</result>
        </spf>
      </auth_results>
      <identifiers>
        <header_from>adan.ru</header_from>
      </identifiers>
      <row>
        <count>20</count>
        <policy_evaluated>
          <disposition>none</disposition>
          <dkim>pass</dkim>
          <spf>pass</spf>
        </policy_evaluated>
        <source_ip>176.9.9.172</source_ip>
      </row>
    </record>
  </feedback>

Существует множество готовых средств, делающих обработку этих отчетов удобнее. Найти их можно на сайте DMARC: http://www.dmarc.org/resources.html.

А что дальше?


Подробнее о настройке DMARC можно прочитать в справке http://help.mail.ru/mail-help/postmaster/dmarc. Включайте и комментируйте — будем благодарны за вопросы, замечания и идеи.

Денис Аникин,
технический директор Почты Mail.Ru
+40
4630
29
danikin 23,3

комментарии (10)

+1
porutchik, #
Почему-то и у вас, и у Гугла sp может принимать значения r и s. А в rfc написано: reject, quarantine и none.
+1
danikin, #
Это мы ошиблись в хелпе. Поправили: help.mail.ru/mail-help/postmaster/dmarc. При разработке старались в точности придерживаться стандарта. Спасибо, что нашли ошибку!
0
Richard_Ferlow, #
А это все не загнется так же как OMF?
0
danikin, #
Вряд ли. Мы последовательно улучшаем жизнь рассыльщиков. Проект Постмастер ( postmaster.mail.ru ) и поддержка DMARC — это только начало.
0
Richard_Ferlow, #
Тогда еще вопрос — мне сказали что будет возможность аватар сделать для писем таких, что как раз на postmaster.mail.ru такая возможность будет. Вы не в курсе? Особенно по срокам интересно. У тех кто успел как-то есть иконки, а у нас вот увы.
0
danikin, #
Возможность в планах есть. А сроки мы традиционно не раскрываем.
+2
meschansky, #
Если вопрос о самом стандарте, то, согласно данным dmarc.org, со стороны MBP его уже поддерживают AOL, Comcast, Google, Mail.ru, Microsoft, NetEase, Xs4All и Yahoo! — порядка 60% всех почтовых ящиков в мире.
Со стороны отправителей — половина из Top20 доменов крупнейших рассыльщиков уже опубликовали политику DMARC для своих доменов.
И это все только за год после публикации стандарта, что говорит о восстребованности технологии.
0
fenidik, #
планируется ли экспорт данных с postmaster.mail.ru?
0
danikin, #
Вы про экспорт статистики в csv? Да, а планах есть
0
achekalin, #
Теория — это хорошо. Реальность куда неприятнее.

Имеем домен. Неважно, что на нем — сайт магазина, форум, публичный почтовый сервис, либо это просто конторский почтовый домен.

Вопрос: какую политику нам задать в spf? Как ни крути, никто не напишет про свой момент «руби с плеча». Максимум — «смотреть подозрительнее», а если бы было значение «не считать спамом», им бы все и пользовались.

Примерно так получается:
1. Магазины и вообще публичные сайты постараются сделать так, чтобы их почта все же попадала в ящик, притом не в папку «Спам» (кстати, часть людей используют POP3 доступ, и папку «Спам» просто не читают).
2. Публичный почтовый сервис — он что не укажет, все равно (на примере mail.ru вполне показательно видно: спамеры тупо через их же сервера отсылают спам, и его никакой spf не отобьет; при этом часть людей из почтовых клиентов используют адреса на mail.ru, но отсылают через smtp своего провайдера или конторский — т.е. у «нормальных» писем spf может не проверяться).
3. Контора любая, заточенная не под высокие материи борьбы с ветряными мельницами, а под бизнес и получения прибыли, вполне может плевать на красоту идеи spf и прочего, главное, чтобы они (и их партнеры) получали рабочую почту. Что-то вроде «пусть у меня на компе хоть 100 вирусов, мне на нем работать надо» — что с этим поделать? Ведь ИТ в компаниях помогает бизнесу, а не мешает.

Вот и получается, что борьба со спамом — проблема ИТ-ная, в реальном мире есть 3 состояния: «о, спама нет, отлично!», «мне послали письмо, оно пропало по пути», и «как достал спам, сделайте что-нибудь!» А вот случая «готов потерять часть почты, но спам видеть не хочу» — такое мало кто говорит :)

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.