company_banner

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:postmaster@exampledomain.ru " 


    В таком виде запись означает, что все поддельные письма нужно пропускать, а отчеты надо высылать на ящик postmaster@exampledomain.ru; 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 с адреса dmarc_support@corp.mail.ru.

    Ниже — пример отчета о том, что с одного IP-адреса было отправлено 20 писем, и все они прошли проверку.
    
      <feedback>
        <report_metadata>
          <date_range>
            <begin>1361304000</begin>
            <end>1361390400</end>
          </date_range>
          <email>dmarc_support@corp.mail.ru</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
    Mail.Ru Group 790,39
    Строим Интернет
    Поделиться публикацией
    Комментарии 20
    • +1
      Почему-то и у вас, и у Гугла sp может принимать значения r и s. А в rfc написано: reject, quarantine и none.
      • +1
        Это мы ошиблись в хелпе. Поправили: help.mail.ru/mail-help/postmaster/dmarc. При разработке старались в точности придерживаться стандарта. Спасибо, что нашли ошибку!
      • 0
        А это все не загнется так же как OMF?
        • 0
          Вряд ли. Мы последовательно улучшаем жизнь рассыльщиков. Проект Постмастер ( postmaster.mail.ru ) и поддержка DMARC — это только начало.
          • 0
            Тогда еще вопрос — мне сказали что будет возможность аватар сделать для писем таких, что как раз на postmaster.mail.ru такая возможность будет. Вы не в курсе? Особенно по срокам интересно. У тех кто успел как-то есть иконки, а у нас вот увы.
            • 0
              Возможность в планах есть. А сроки мы традиционно не раскрываем.
          • +2
            Если вопрос о самом стандарте, то, согласно данным dmarc.org, со стороны MBP его уже поддерживают AOL, Comcast, Google, Mail.ru, Microsoft, NetEase, Xs4All и Yahoo! — порядка 60% всех почтовых ящиков в мире.
            Со стороны отправителей — половина из Top20 доменов крупнейших рассыльщиков уже опубликовали политику DMARC для своих доменов.
            И это все только за год после публикации стандарта, что говорит о восстребованности технологии.
          • 0
            планируется ли экспорт данных с postmaster.mail.ru?
            • 0
              Вы про экспорт статистики в csv? Да, а планах есть
            • 0
              Теория — это хорошо. Реальность куда неприятнее.

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

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

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

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

                Строгую политику SPF задавать нельзя, т.к. SPF бьется на пересылках. А вот строгую политику DKIM — волне можно.Т.е. сделать так, чтобы с вашего домена шли только подписанные DKIMом письма. При этом DKIM не портится от пересылок.
              • 0
                В примере «v=DMARC1; p=none; rua=mailto: postmaster@exampledomain.ru»
                лишний пробел после двоеточия.
                • 0
                  Судя по моим DMARC логам 10% доменов эту ошибку тупо скопипастила :)
                  • 0
                    10% рунета?
                    • 0
                      Наверное, не помню, надо проверить.
                      Таких записей, на которые OpenDMARC ругается «Can't parse ...» — действительно много. Проверил их несколько — везде пробелы после mailto.
                • 0
                  Столкнулся с проблемой пересылки писем.
                  Есть ящик на O365, допустим, vpupkin@company.ru.
                  На ящике настроена пересылка писем на личный аккаунт, допустим, vpupkin@gmail.com.
                  В итоге, часть писем не доходит с ошибкой:
                  550 5.7.23 The message was rejected because of Sender Policy Framework violation -> 550 5.7.1 Unauthenticated email from rassilka.ru is not accepted due to;domain's DMARC policy.
                  Please contact the administrator of;rassilka.ru domain if this was a legitimate mail.
                  Please visit; https://support.google.com/mail/answer/2451690 to learn about the;DMARC initiative.

                  На домене rassilka.ru стоит политика v=DMARC1; p=reject; adkim=s; aspf=r; rf=afrf; pct=100
                  Вот и получается что будут отклоняться пересылаемые письма от доменов где стоит reject.
                  • 0
                    Чтобы такого не было, письма должны подписываться DKIM.
                  • 0
                    Проясните пожалуйста, а то путаница в голове:
                    1 — Правильно ли я понимаю, что в политике DMARC учитывается не сама проверка pass/fail от SPF/DKIM, а проверка соответствия доменов?
                    2 — Если хотя бы одна из проверок доменов в SPF либо DKIM, прошла, тогда считается что и проверка DMARC прошла?
                    3 — Во время учета домена из DKIM, сравнивается домен из поля d= сигнатуры и RFC5322.From?
                    4 — Во время учета домена из SPF, сравнивается домен из RFC5321.From (а это есть Return-Path) и RFC5322.From?
                    5 — Если в письме несколько DKIM сигнатур (от оригинального домена и от домена на котором настроена пересылка) то по какому алгоритму идет проверка?
                    • 0
                      1. Учитывается результат проверки при условии соответствия доменов. Т.е. если во From домен example.com, то SPF или DKIM для домена example.org не будет учитываться в DMARC, т.к. это разные организационные домены.
                      2. Совершенно верно, но при условии выполнения п.1
                      3. Да, сравнивается домен из d= или i=
                      4. Да, сравнивается домен из RFC5321.From (при пустом From используется домен из RFC5321.Helo). Return-Path не совсем то же самое, это заголовок который добавляется в сообщение при доставке в ящик конечного пользователя, как правило (но не обязательно) он так же содержит RFC5321.From.
                      5. Достаточно чтобы была хотя бы одна валидная DKIM-сигнатура соответствующая домену из RFC5322.From. Сигнатуры от других доменов и невалидные сигнатуры никак не влияют. Правда бывают ошибки реализации, например мы засабмитили такой патч в exim (можно за него проголосовать).
                      • 0
                        Спасибо, весьма ценная информация :-)

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

                    Самое читаемое