(Почему) Почта Mail.Ru включает строгий DMARC
На днях мы анонсировали включение строгой DMARC-политики на всех доменах, принадлежащих Почте Mail.Ru. На некоторых доменах, включая bk.ru и mail.ua, политика p=reject включена уже сейчас. В этой статье мы хотим пояснить некоторые технические детали такого включения и дать рекомендации владельцам сервисов, почтовых серверов и списков рассылки.
DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489) — протокол, позволяющий администратору доменной зоны опубликовать политику приема и отправки отчетов для писем, не имеющих авторизации. В качестве протоколов авторизации используются протоколы SPF (RFC 7208) и DKIM (RFC 6376).
При получении письма, у которого в поле отправителя (From:) используется домен example.org, сервер получателя запрашивает политику DMARC домена example, которая публикуется в DNS в виде TXT-записи, например
_dmarc IN TXT "v=DMARC1;p=none;rua=mailto:a@example.org;ruf=mailto:f@example.org;fo=1;"
Для письма проверяется SPF и DKIM; кроме этого, проверяется соответствие (alignment) домена, прошедшего проверку SPF или DKIM, и домена, используемого во From:. Чтобы домен прошел авторизацию DMARC, необходимо, чтобы хотя бы один из механизмов SPF или DKIM прошел авторизацию для домена, совпадающего с точностью до домена организации из адреса From:. Если письмо не проходит авторизацию или домен не совпадает (например, использована DKIM-подпись стороннего домена или адрес в envelope-from не совпадает с адресом From:), применяется политика (в данном случае none, т. е. никаких специальных действий не требуется; возможны также политики reject — не принимать письма и quarantine — складывать письма в папку «Спам»). Статистические отчеты по срабатыванию политики и прошедшим письмам будут отправляться на адрес a@example.org. Также домен, публикующий политику, просит отправлять форензик-отчеты (т. е. отчеты, содержащие как минимум заголовки полученного письма) по всем письмам, не прошедшим авторизацию SPF или DKIM, на адрес f@example.org.
Mail.Ru первым в Рунете поддержал серверную часть DMARC более двух лет назад. А теперь DMARC будет защищать от подделки домены mail.ru. Ранее строгая политика DMARC была включена только для служебных доменов Mail.Ru Group (например, corp.mail.ru), поскольку именно они чаще всего подделываются фишерами. В настоящее время она также применяется для доменов mail.ua и bk.ru, а 18 мая будет распространена на все домены бесплатных почтовых ящиков (list.ru, inbox.ru и mail.ru).
DMARC устраняет самую серьезную проблему электронной почты — отсутствие проверки адреса отправителя. Чаще всего причиной для ввода DMARC называют борьбу с фишинговыми письмами. Отчасти это действительно так — ввод строгой политики DMARC всего несколькими крупными банками США в 2014 году привел к снижению фишинга посредством электронной почты на 6% за год в целом по отрасли. В PayPal объем фишинга за два года после введения политики снизился на 70%.
В случае доменов публичной почты основной причиной является не фишинг. Мы хотим, во-первых, в целом снизить объем спама в Сети: большая его часть идет именно с поддельных адресов, в некоторые дни число таких писем с поддельными адресами mail.ru более чем в 15 раз превышает количество писем, отправляемых пользователями Mail.Ru. Во-вторых, DMARC позволяет оградить пользователей от вторичного спама. Очень часто спамные письма с поддельных адресов генерируют сообщения о невозможности доставки (NDR) и автоответы, которые идут на ящики легитимных пользователей, не отправлявших письмо. Распознать такую ситуацию может быть достаточно сложно, так как в NDR и автоответе отсутствует «спамный» контент. По нашему опыту, внедрение строгой политики DMARC снижает объем вторичного спама в несколько десятков раз.
SPF (RFC 7208) совсем не защищает адрес отправителя, так как работает только с адресом envelope-from, который невидим пользователю. DKIM (RFC 6376) тоже совершенно не защищает адрес отправителя, поскольку является алгоритмом подписи и не указывает, как поступать, если подписи нет или она некорректна. Sender ID (RFC 4406) прикрыт патентами Microsoft и «не взлетел». Ближайшим по функционалу к DMARC был протокол ADSP (RFC 5617), но, в отличие от DMARC, он также «не взлетел» и в 2013 году был переведен в статус Historic, так как почти все крупные игроки рынка отказались от него в пользу DMARC. В отличие от ADSP, работавшего только поверх DKIM, DMARC может использовать разные протоколы аутентификации. В базовом стандарте применяются и DKIM, и SPF. Фактически DMARC комбинирует механизмы, задействованные в Sender ID и ADSP, и дает возможность расширять их в будущем, что значительно улучшает «непрямое» прохождение почты (indirect flows). Уже сейчас можно не сомневаться, что протокол DMARC работает, — серверная часть DMARC поддерживается всеми серьезными почтовыми службами, все крупные игроки либо уже включили DMARC на своих доменах, либо заявили о таком намерении. Среди публичных почтовых служб, включивших DMARC на своих доменах (и принявших основной удар критики от владельцев списков рассылки, о чем речь пойдет ниже), — Yahoo и AOL. С их стороны это было рискованным, но очень нужным решением — иначе протокол могла бы постичь судьба Sender ID и ADSP.
Естественно, у любого протокола есть недостатки. DMARC требует аутентификации отправителя, из-за этого в нескольких ситуациях возникают проблемы:
- Пользователь посылает письма «напрямую» в обход почтового сервера с аутентификацией. Например, веб-мастер отправляет регистрационные письма PHP-скриптом, используя во From: адрес публичной почты. К сожалению, единственное решение — так не делать. Зарегистрируйте почту для своего домена. Mail.Ru предоставляет для этого бесплатный сервис. Даже если вы перейдете на отправку с адреса другой публичной почты, скорее всего, это решение будет временным, поскольку DMARC для своих доменов станут внедрять все крупные почтовые сервисы.
- Списки рассылки. Да, с ними опять есть проблемы, и более существенные, чем в случае с SPF, так как SPF оказался бесполезным именно из-за попыток сохранить совместимость со списками рассылки. Чтобы не нарушать авторизацию DMARC, необходимо либо «не трогать» заголовки, подписанные DKIM (в частности, не менять тему письма), либо перезаписывать отправителя из From:. К счастью, основные менеджеры списков рассылки уже поддерживают корректную работу с DMARC.
- Форварды. В некоторых случаях почтовые серверы меняют содержимое при пересылке, например структуру MIME-частей или разбивку на строки, что может приводить к нарушению DKIM-подписи. В таких случаях мы рекомендуем вместо пересылки почты использовать сбор почты по протоколам POP3/IMAP (reverse POP / reverse IMAP). Mail.Ru первая из почтовых служб реализовала сбор почты по IMAP с сохранением структуры папок. Кроме того, крупные почтовые сервисы, в том числе Mail.Ru, поддерживают белые списки известных форвардеров (known forwarders) — для списков рассылок и других почтовых служб, почта от которых принимается даже в случае нарушения DMARC. Если письма от известного форвардера или списка рассылки блокируются нами по политике DMARC — пожалуйста, сообщите об этом. В будущем проблема форвардов может быть решена реализацией протокола ARC (Authenticated Received Chain), пока этот протокол находится в стадии обсуждения.
- Есть и другие проблемы DMARC, в том числе связанные с безопасностью, особенно при предоставлении forensic-отчетов. Например, возможность раскрывать перенаправления (и таким образом деанонимизировать пользователя) или подписчиков списков рассылки. Все это возможно и без DMARC, но DMARC заметно облегчает задачу. Поэтому мы реализовали функцию анонимайзера — как альтернативу пересылок или разовых/скрытых адресов для списков подписки. Из соображений безопасности мы не планируем предоставлять forensic-отчеты с полной идентификацией получателя недоверенным сторонам.
…я обычный пользователь почты
Ничего делать не требуется. Скорей всего, вы ничего не заметите, только избежите ситуаций «кто-то получил спам/фишинг с моего адреса, а я его не отправлял» и не будете получать непонятные «отлупы».
…я пользуюсь перенаправлениями для сбора почты с нескольких аккаунтов на разных сервисах в общий ящик
Скорее всего, этот функционал будет работать, но чтобы исключить вероятность, что часть писем потеряется, используйте функцию сбора почты с других ящиков.
…я пользуюсь перенаправлениями для заведения скрытых/временных адресов
Перенаправления могут быть обнаружены и раскрыты (для этого достаточно поддержки DMARC сервером получателя, т. е. практически любым сервером). Если это критично для вас, используйте функцию анонимайзера.
…я пользуюсь функционалом «отправлять как» на Gmail (или аналогичным) для отправки писем с адреса Mail.Ru
Следует проверить настройки адреса отправки в Gmail и убедиться, что отправка идет через сервер SMTP mail.ru (smtp.mail.ru, порт 465 с использованием SSL), c корректным логином и паролем. Письма будут отправляться через сервер Mail.Ru с авторизацией отправителя и пройдут проверки SPF/DKIM/DMARC.
…я пользуюсь обратным адресом публичной почты для отправки писем через скрипты на сервере
Так делать не следует. Используйте «Почту для бизнеса» для заведения ящиков в вашем собственном домене (hint: для этого не обязательно обладать бизнесом, достаточно обладать доменом). Используйте адрес собственного домена во всех серверных, автоматических или автоматизированных рассылках.
…я предоставляю клиентам услуги доставки электронных сообщений (ESP)
Не используйте для заголовка From: сообщений адрес отправителя из доменов бесплатной почты. Зарегистрируйте отдельный домен для клиентов, не имеющих собственного домена, настройте для него SPF, DKIM и DMARC. Выделяйте клиенту адрес в этом домене для использования в качестве адреса отправителя и прописывайте перенаправления с выделенного адреса в вашем домене на ящик электронной почты клиента. Клиентам, имеющим собственный домен, рекомендуйте брать адреса из этого домена в качестве адреса отправителя. Можно продолжать использовать адрес клиента в домене бесплатной почты для заголовков Sender: и Reply-To:.
…я администрирую списки рассылки
Обновите программное обеспечение списков рассылки и настройте его в соответствии с рекомендациями совместимости DMARC. Корректно работают Sympa с версии 6.2.6, Dada Mail с версии 7.0.2, Mailman с версии 2.1.16 (лучше 2.1.18), GroupServer с версии 14.06. Возможно, придется включить функцию, которая называется «Sending on behalf of» / «Munge the From: header». Если рекомендации выполнить невозможно (например, используется устаревшее или неподдерживаемое ПО), постарайтесь минимизировать нарушения DMARC, отказавшись от изменения служебных заголовков и содержимого писем, отправляемых в список рассылки, — т. е. не меняйте темы, не добавляйте хидер/футер к письмам, чтобы не нарушать DKIM-сигнатуру письма. Если проблемы с доставкой сохраняются, обратитесь в службу поддержки сервера, который не принимает сообщения.
…я администрирую почтовый домен и хочу опубликовать свою DMARC-политику
Настройте SPF и DKIM для всех отправляемых писем, при этом учтите специфику требований новых версий стандартов. Последняя версия стандарта SPF (RFC 7208) требует наличия SPF-записи не только для основного почтового домена, но и для имен из команды HELO/EHLO, которые, как правило, совпадают с каноническими именами почтовых серверов. Это необходимо для прохождения SPF в случае пустого отправителя, используемого в NDR/MDN. Опубликуйте DMARC-запись с политикой none. Настройте адреса для сбора отчетов rua/ruf. Обратите внимание, что стандарт DMARC требует, чтобы домен, в котором находятся данные адреса, соответствовал домену, для которого запрашиваются отчеты, либо публиковал специальную политику приема отчетов, поэтому получать отчеты на адреса публичных почт так же не получится. Проанализируйте поступающие отчеты, устраните проблемы, связанные с SPF, DKIM и несоответствием (misalign) доменов из вашей сети, идентифицируйте возможные источники легальных писем вне ее (например, рассылки, организованные через внешние сервисы рассылок) и подстройте SPF и DKIM для всех легальных писем. Можно пользоваться услугами специализированных сервисов — Agari, Return Path, Dmarcian. Сервис Dmarcian, помимо платных услуг, предлагает удобный бесплатный инструмент для визуального представления XML-отчетов DMARC. Когда все проблемы будут устранены, переключите политику на reject или quarantine.
…я администрирую почтовый сервер и хочу фильтровать письма по DMARC
Интегрируйте соответствующий фильтр. Фильтрация по DMARC поддерживается практически во всех антиспам-решениях. В качестве отдельных бесплатных DMARC-фильтров, совместимых с основными Linux/UNIX MTA, можно порекомендовать OpenDMARC и yenma.
…я администрирую почтовый сервер/домен и этот ваш SPF/DKIM/DMARC не знаю и знать не хочу
По мере внедрения строгой политики DMARC другими почтовыми доменами ваш домен, не защищенный политикой DMARC, будет все чаще использоваться спамерами как источник фальшивых адресов отправителей, что приведет к постоянному росту вторичного спама и, как следствие, жалоб пользователей. Скорее всего, в результате вы все равно будете вынуждены реализовать SPF/DKIM/DMARC. Но даже если вы сохраните стойкость, когда-нибудь домены без опубликованной политики могут начать восприниматься как подозрительные, в том числе самообучающимися фильтрами, что приведет к проблемам с доставляемостью писем.
…я администрирую почтовый сервер/домен и у меня есть вопросы
Вы можете задать их здесь в комментариях или на Тостере, я стараюсь отслеживать тематические хабы.
Электронная почта часто позиционируется критиками как неменяющийся динозавр из прошлого тысячелетия —, но это не так: она развивается, и очень активно. Все актуальные версии основных стандартов электронной почты приняты в течение последних восьми лет, DMARC стал стандартом всего год назад, а в настоящее время идет работа по стандартизации, например, протоколов Authenticated Received Chain и SMTP Strict Transport Security. Но переход на новые стандарты и протоколы невозможен без поддержки всеми сторонами, и мы очень надеемся, что эта статья поможет и вам включиться в процесс построения более современной, удобной и безопасной экосистемы электронной почты.
