company_banner

(Почему) Почта Mail.Ru включает строгий DMARC



    На днях мы анонсировали включение строгой DMARC-политики на всех доменах, принадлежащих Почте Mail.Ru. На некоторых доменах, включая bk.ru и mail.ua, политика p=reject включена уже сейчас. В этой статье мы хотим пояснить некоторые технические детали такого включения и дать рекомендации владельцам сервисов, почтовых серверов и списков рассылки.

    Что такое DMARC?


    DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489) — протокол, позволяющий администратору доменной зоны опубликовать политику приема и отправки отчетов для писем, не имеющих авторизации. В качестве протоколов авторизации используются протоколы SPF (RFC 7208) и DKIM (RFC 6376).

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


    При получении письма, у которого в поле отправителя (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).

    Зачем это Mail.Ru?


    DMARC устраняет самую серьезную проблему электронной почты — отсутствие проверки адреса отправителя. Чаще всего причиной для ввода DMARC называют борьбу с фишинговыми письмами. Отчасти это действительно так — ввод строгой политики DMARC всего несколькими крупными банками США в 2014 году привел к снижению фишинга посредством электронной почты на 6% за год в целом по отрасли. В PayPal объем фишинга за два года после введения политики снизился на 70%.

    В случае доменов публичной почты основной причиной является не фишинг. Мы хотим, во-первых, в целом снизить объем спама в Сети: большая его часть идет именно с поддельных адресов, в некоторые дни число таких писем с поддельными адресами mail.ru более чем в 15 раз превышает количество писем, отправляемых пользователями Mail.Ru. Во-вторых, DMARC позволяет оградить пользователей от вторичного спама. Очень часто спамные письма с поддельных адресов генерируют сообщения о невозможности доставки (NDR) и автоответы, которые идут на ящики легитимных пользователей, не отправлявших письмо. Распознать такую ситуацию может быть достаточно сложно, так как в NDR и автоответе отсутствует «спамный» контент. По нашему опыту, внедрение строгой политики DMARC снижает объем вторичного спама в несколько десятков раз.

    Разве всего этого не было в SPF (DKIM, Sender-ID, ADSP)?


    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 требует аутентификации отправителя, из-за этого в нескольких ситуациях возникают проблемы:

    1. Пользователь посылает письма «напрямую» в обход почтового сервера с аутентификацией. Например, веб-мастер отправляет регистрационные письма PHP-скриптом, используя во From: адрес публичной почты. К сожалению, единственное решение — так не делать. Зарегистрируйте почту для своего домена. Mail.Ru предоставляет для этого бесплатный сервис. Даже если вы перейдете на отправку с адреса другой публичной почты, скорее всего, это решение будет временным, поскольку DMARC для своих доменов станут внедрять все крупные почтовые сервисы.
    2. Списки рассылки. Да, с ними опять есть проблемы, и более существенные, чем в случае с SPF, так как SPF оказался бесполезным именно из-за попыток сохранить совместимость со списками рассылки. Чтобы не нарушать авторизацию DMARC, необходимо либо «не трогать» заголовки, подписанные DKIM (в частности, не менять тему письма), либо перезаписывать отправителя из From:. К счастью, основные менеджеры списков рассылки уже поддерживают корректную работу с DMARC.
    3. Форварды. В некоторых случаях почтовые серверы меняют содержимое при пересылке, например структуру MIME-частей или разбивку на строки, что может приводить к нарушению DKIM-подписи. В таких случаях мы рекомендуем вместо пересылки почты использовать сбор почты по протоколам POP3/IMAP (reverse POP / reverse IMAP). Mail.Ru первая из почтовых служб реализовала сбор почты по IMAP с сохранением структуры папок. Кроме того, крупные почтовые сервисы, в том числе Mail.Ru, поддерживают белые списки известных форвардеров (known forwarders) — для списков рассылок и других почтовых служб, почта от которых принимается даже в случае нарушения DMARC. Если письма от известного форвардера или списка рассылки блокируются нами по политике DMARC — пожалуйста, сообщите об этом. В будущем проблема форвардов может быть решена реализацией протокола ARC (Authenticated Received Chain), пока этот протокол находится в стадии обсуждения.
    4. Есть и другие проблемы DMARC, в том числе связанные с безопасностью, особенно при предоставлении forensic-отчетов. Например, возможность раскрывать перенаправления (и таким образом деанонимизировать пользователя) или подписчиков списков рассылки. Все это возможно и без DMARC, но DMARC заметно облегчает задачу. Поэтому мы реализовали функцию анонимайзера — как альтернативу пересылок или разовых/скрытых адресов для списков подписки. Из соображений безопасности мы не планируем предоставлять forensic-отчеты с полной идентификацией получателя недоверенным сторонам.

    Что мне делать, если…


    …я обычный пользователь почты

    Ничего делать не требуется. Скорей всего, вы ничего не заметите, только избежите ситуаций «кто-то получил спам/фишинг с моего адреса, а я его не отправлял» и не будете получать непонятные «отлупы».

    …я пользуюсь Почтой для бизнеса для своего домена

    Изменения затронут только публичные домены Mail.Ru. Чтобы ваш домен был защищен DMARC, необходимо самостоятельно опубликовать политику.

    …я отправляю письма через почтовый сервер своего интернет-провайдера

    Для адресов обслуживаемых Mail.Ru необходимо настроить отправку через SMTP-серверы mail.ru с авторизацией по инструкциям.

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

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

    …я пользуюсь перенаправлениями для заведения скрытых/временных адресов

    Перенаправления могут быть обнаружены и раскрыты (для этого достаточно поддержки 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, proofpoint, 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. Но переход на новые стандарты и протоколы невозможен без поддержки всеми сторонами, и мы очень надеемся, что эта статья поможет и вам включиться в процесс построения более современной, удобной и безопасной экосистемы электронной почты.
    Mail.Ru Group 795,15
    Строим Интернет
    Поделиться публикацией
    Комментарии 86
    • +3
      Ох. Если я отправляю письмо с сервера (PHP) скриптом, для домена site.ru я делаю поддомен mailer.site.ru, указываю у поддомена SPF с IP адресом сервера отправителя, A-запись с сервером отправителя, в поле From указываю noreply@mailer.site.ru. — мне надо беспокоиться, или надо для поддомена mailer тоже делать почту-на-домене?
      Аналогичный вопрос, когда кроме SPF есть ещё DKIM.
      • +2
        DMARC проверяет align для организационного домена. Организационный домен это например example.org или example.or.uk (т.е. первый поддомен в домене, открытом для регистрации). Список доменов открытых для регистрации обычно берется из http://publicsuffix.org. Т.е. если в SPF сработает mailer.example.org а в From будет example.org — это нормально, т.е. организационный домен в данном случае example.org и он совпадает.

        • 0
          Это кроме случая, когда домен site.ru публикует DMARC-политику с полем aspf=s, s (strict) требует строгого соответствия домена из SPF и домена из From.
          Ну и вообще — если site.ru не публикует DMARC-политику, то беспокоиться о DMARC не надо.
        • 0
          smtp.mail.ru, порт 465 с использованием SSL

          А почему вы используете устаревший протокол SMTPS вместо STARTTLS на порте 587?
          • 0
            STARTTLS и SSL здесь используются не для обозначения шифрования, т.к. в обоих случаях используется TLS, а для удобства различения двух технологий.
            Поэтому протокол не является устаревшим, на самом деле в обоих случаях используется шифрование TLS. Я считаю, что TLS на выделенном порту немного более безопасен, т.к. в нему отсутствует специфичные для STARTTLS pre-TLS атаки, такие как CVE-2011-0411, CVE-2014-3556, CVE-2015-6409, CVE-2011-1575 и т.п.

            P.S. Mail.Ru поддерживает и то и другое.
            • 0
              Mail.Ru поддерживает и то и другое.

              Вот только в справке это не отражено (как и у Яндекса), а некоторые современные приложения не поддерживают SMTPS и народ путается.
              • 0
                Мы добавили тот вариант, который чаще поддерживается + расписали рекомендованные варианты для разных почтовых программ. Если есть какая-то популярная программа, которую забыли — напишите, добавим и ее. Боюсь, что если мы добавим в справке оба варианта, путаницы будет не меньше, а больше.
          • –6
            Привет, Майл.РУ.
            Вашу техподдержку не дождешься, поэтому спрошу здесь. Так получилось, что оригиналы одного фотоальбома у меня лежали только на фотохостинге Мейл.ру. И вы своими очередными «прорывными» изменениями их по#ерили.
            Как теперь можно скачать полноразмерное фото с «моего мира» mail.ru?
            Имеется ввиду фото не с тем разрешением, в котором оно открывается, а с тем, которое было при залитии фото на фото.мэйл.ру
            Возможно ли такое, если да, то как можно осуществить?
            Я загружал фото в альбом с сохранением оригинала! Это было еще тогда, когда проект Фото.мейл.ру был отдельным от «моего мира». До недавнего времени эта возможность была. А теперь только пережатые фотки, оригиналов больше нет. Хотя информация в EXIF осталась.
            • +1
              Что я должен сделать как владелец доменного имени (скажем, site.ru), если я выбрал почтовым провайдером компанию Яндекс (то есть А- и МХ- записи указывают на яндекс), чтобы при доставке писем на mail.ru не возникало неприятных неожиданностей?
              • +1
                Пока вы не опубликуете DMARC-политику для site.ru каких-либо проблем, связанных с DMARC у вас не возникнет.
                Чтобы правильно и без проблем внедрить DMARC вам надо сделать следующее:
                1. в SPF-запись добавить IP серверов с которых вы шлете письма напрямую + включить SPF-политику яндекса через include:_spf.yandex.ru или redirect=_spf.yandex.ru.
                2. на pdd сгенерировать DKIM-ключ для pdd и прописать его в своей зоне. На самом деле он уже сгенерирован и найти его можно запросом
                host mail._domainkey.securityvulns.ru dns1.yandex.ru
                даже если ваша зона хостится не у Яндекса.
                3. Прописать сгенерировать и прописать ключи для всех остальных серверов рассылающих почту от site.ru (следует использовать другие селекторы DKIM)
                4. Прописать DMARC-политику, для начала нестрогую.
              • 0
                А что делать, если провайдер не хочет\не может прописать обратную запись PTR, чтобы письма проходили проверку SPF?
                • +1
                  SPF не связан с обратной зоной и будет проходить независимо от PTR.
                  Но да, проблемы у вас будут. Mail.Ru принимает почту и при отсутствии PTR, но, например AOL принципиально не принмает письма с сервера без PTR записей. Вариантов два — менять провайдера или уносить сервер на хостинг.
                  • 0
                    А зачем прописывать PTR для SPF? Это разве обязательное требование?
                    И на какой домен должен указывать PTR, когда почтовик на этом IP обслуживает несколько доменов?
                    • 0
                      PTR никак не связан с SPF, кроме случаев, когда в SPF применяется конструкция типа ptr:mail.example.com, но многие серверы проверяют PTR, поэтому он должен:
                      1. быть
                      2. имя, на которое он указывает, должно корректно резолвиться обратно в тот же IP-адрес
                      Если интересно, есть вот такая статья, там в том числе есть про IP-адреса, PTR и прочие технические требования.
                      • 0
                        Понял, благодарю. Тогда в этом действительно есть логика.
                        • 0
                          В нашем случае есть клиент, у которого почта на хостинге и не ими управляется. Там есть и проверка PTR, и проверка DKIM.
                          Таких клиентов с серьёзным подходом к почте, к сожалению, мало.
                          Намного больше, которые используют mail.ru. И хорошо, если эти адреса не будут подделываться спамерами, потому что из-за таких клиентов пришлось добавить в исключения этот домен, иначе проблемы с получением писем у наших менеджеров.

                          Может подскажете даже, как можно грамотно разрулить настройку почты в случае двух провайдеров интернета (active\passive), и при этом проходить все проверки?
                          При условии, если не менять второго провайдера, где нет обратной записи PTR и не уносить почту на хостинг.
                          • 0
                            Если у вас два подключения к двум провайдерам — заведите на почтовый сервер IP адреса от обоих провайдеров (напрямую или через проброс/трансляцию порта), опубликуйте две MX-записи, с разными приоритетами, если какой-то из провайдеров предпочтительней или с одинаковыми, если они равнозначны. В SPF запись включите все IP адреса всех серверов. Если один из провайдеров не предоставляет PTR-записи — избегайте использовать выделенный им IP адрес для отправки почты. Для этого, например, добавляйте маршрут через него на почтовом сервере с большей метрикой. Для входящей почты наличие PTR значения не имеет.
                            • 0
                              Ну сейчас так и сделано. Но поскольку я новичок в этом, то постоянно сомнения — правильно ли, может есть способы правильней.
                              Да и смущают EHLO\HELO.
                              Каждому IP не присвоить одинаковый FQDN ведь.
                              • 0
                                Не надо присваивать одинаковый — вполне допустимо чтобы он был разный, но для каждого имени используемого в HELO надо создать дополнительную SPF-запись.
                                Для прохождения DMARC'а письмами от MAILER-DAEMON надо чтобы домен во From: у этих писем либо отсутствовал (что не очень хорошо) либо совпадал с точностью до организационного домена с именем из HELO. Т.е. если в HELO у вас будет relay1.mail.example.org в во From: mailer-daemon@mail.example.org или mailer-daemon@relay1.mail.example.org и для relay1.mail.example.org будет опубликована отдельная SPF-запись — SPF-DMARC пройдет.

                                И совсем не обязательно, чтобы HELO совпадал с PTR.
                                • 0
                                  Я правильно понимаю, что вместо одной записи:
                                  v=spf1 a:mail1.domain.ru a:mail2.domain.ru ip4:11.22.33.44 ip4:55.66.77.88 ?all
                                  Должно быть две:
                                  v=spf1 a:mail1.domain.ru ip4:11.22.33.44 ?all
                                  v=spf1 a:mail2.domain.ru ip4:55.66.77.88 ?all
                                  ?all — требуется, чтобы наши письма доходили до того самого клиента, ибо им письма приходят уже изменёнными сервером пересылки (то есть не от имени нашего сервера).
                                  • 0
                                    нет, ни в коем случае. Двух записей для одного домена быть не должно. Надо примерно так:

                                    domain.ru. IN TXT "v=spf1 a:mail1.domain.ru a:mail2.domain.ru ip4:11.22.33.44 ip4:55.66.77.88 ?all"
                                    mail1.domain.ru. IN TXT "v=spf1 include:domain.ru -all"
                                    mail2.domain.ru. IN TXT "v=spf1 include:domain.ru -all"


                    • 0
                      «p=none» просто делает всю эту историю бесполезной. Так же как в SPF все пишут "~all".

                      Если бы крупные игроки договорились, набрались мужества и поставили p=reject, -all, то это бы дало существенный буст борьбе со спамом. Да, ценой небольших потерь писем, но оно того стоило.
                      • 0
                        Отчасти да, именно поэтому мы внедряем p=reject.
                        Но все таки не совсем, p=none позволяет получать репорты и оценить масштабы трагедии. Внедрение DMARC для крупных доменов со сложной структурой писем гораздо сложней, чем может показаться и без подобной информации практически невозможен. Мы выявили/устранили у себя порядка сотни различных проблем, прежде чем рискнуть включить p=reject.
                        • 0
                          При настройке, reject -all сразу ставить нежелательно.
                          Хороший совет от Google — последовательное развертывание DMARC.
                          support.google.com/a/answer/2466563?hl=ru
                          • 0
                            Да я имелл ввиду, что в принципе никто не включает SPF в стрикт: только что проверил: Гугл, Яндекс, Майлру, все в ~all. SPF у этих ребят уж сколько лет, а все ~. На DMARC конечно есть надежда, поскольку есть репортинг.
                        • –2
                          …я пользуюсь перенаправлениями для сбора почты с нескольких аккаунтов на разных сервисах в общий ящик
                          На случай если это не будет работать, вам следует решить эту проблему с другими крупными почтовиками. В противном случае найух ваш почтовик который не принимает письма и не отправляет в спам всякие купончики от которых не отписаться и которые ежедневно помечаются как спам.
                          • 0
                            Так вот в чем дело… а я то думаю, что же случилось. Раньше ящик был завален спамом, будто фильтров у вас вообще не было, а теперь, да, спама в основную папку приходит мало. НО мне приходится теперь периодически лицезреть содержимое папки «спам», потому что теперь туда попадают и нормальные письма. Да, классно, что вы внедрили что-то передовое, но может стоит протестировать на реальных пользователях, а не «у кого не доходят письма, тот сам виноват», какой мне смысл от фильтра, который зарубает нужные мне письма.
                            • 0
                              Нет, DMARC здесь непричем, он не влияет напрямую ни на объем спама в вашем ящике ни на прохождение обычных писем. Если какие-то письма попадают в папку спам — не забывайте нажимать на них «Не спам», это гарантирует, что в дальнейшем письма от данного отправителя в спам не попадут. Если проблема повторяется — обратитесь в службу поддержки, мы обязательно выявим и устраним причину.
                            • 0
                              «Пользователь <делает что-то>. К сожалению, единственное решение — так не делать.»
                              Это всё, что вам нужно знать о mail.ru.

                              Огромная головная боль администратора хостинга. Почему-то ни один из крупных игроков почтовых услуг не доставляет таких проблем, какие прилетают от mail.ru. Oh wait… никто кроме них вообще не доставляет проблем.
                              • 0
                                Расскажите с какими проблемами, связанными с внедрениями DMARC вы, как хостер столкнулись — обязательно постараемся учесть, помочь, посоветовать.
                                • 0
                                  судя по всему, с проблемами, связанными с внедрениями DMARC, мы ещё только будем сталкиваться. пока остальных хватает.

                                  btw, вы упомянули белые списки. они у вас реализованы только для DMARC или есть некие общесистемные? по этому поводу у меня недавно получился отличный диалог с вашей поддержкой, которая поведала что белых списков нет и никогда не было. только как вот при этом быть с тем, что у меня сохранилась переписка, когда нас добавляли в белые списки по запросу, я не знаю. параллельная реальность, не иначе.
                                  • 0
                                    DMARC не затрагивает хостеров. С трудностями могут столкнуться некоторые ваши клиенты, это может привести к обращению в службу поддержки, но обращение в данном случае легко конвертируется в продажу услуги — хостинга для почтового домена, доработки серверных скриптов.

                                    У Mail.Ru действительно нет (и не будет) общесистемных белых списков, список известных форвардеров действует исключительно на проверку DMARC и не отключает другие проверки. Если письмо не будет отброшено по другим признакам, то оно попадет в ящик пользователя, но на нем будет показываться уведомление о возможной подделке адреса отправителя.
                                    • 0
                                      зато хостеров отлично затрагивает блокировка по IP, в том числе за, цитата: «Дело в том, что с IP-адреса xxx.xxx.xxx.xxx отправляется большое количество писем на невалидные адреса.» WUT?!
                                      мы устали бороться, обращение в службу поддержки, к сожалению, конвертируется теперь только в настоятельную рекомендацию не иметь с вашим сервисом дел.
                                      • 0
                                        Вы как-то ограничиваете/следите за спамом рассылаемым с хостинговых сервисов? Если у вас есть выделенная сеть, можно подписаться на FBL
                                        http://fbl.postmaster.appsmail.ru/
                                        и получать все жалобы на спам из вашей сети. Аналогичные сервисы есть и у других почтовых служб
                                        http://wiki.asrg.sp.am/wiki/Feedback_loop_links_for_some_email_providers
                                        Если речь идет о shared hosting, я бы рекомендовал вам достаточно жестко рейтлимитить отправку писем каждым клиентом.
                                        Если вы никак не ограничиваете клиентов на shared hosting'ах, то в случае если кто-то из клиентов, например, начинает перебор адресов (что произошло, судя по ответу саппорта) — будет блокироваться отправка почты для IP адреса, это срабатывание рейтлимитов, которые любая почтовая служба применяет для подобной активности.
                                        • 0
                                          перебора не было. по переписке с поддержкой я уже понял, что объяснять про shared что-то бесполезно…
                                          просто здесь «любая почтовая служба» стоит читать как «mail.ru» =) почему-то только вам пришло в голову присвоить себе полномочия решать, что все письма с IP должны тупо режектиться на основании странных метрик о несуществующих адресах.
                                          там судя по переписке с саппортом ещё много веселья, и судя по формулировкам, вы к ним имеете прямое отношение =) от одного только отношения к почтовым редиректам было бы очень смешно, если бы вы не были так популярны на постсоветском пространстве. вот и приходится раз за разом объяснять, что вы слишком многое на себя берёте и мы бессильны что-либо с этим сделать. раньше (лет пять назад, емнип) хоть можно было что-то обсудить, белые списки были, опять же. сейчас, видимо, уже всё, терминальная стадия.
                                          • +1
                                            Эм. А подскажите мне где вы работаете, я ваши блоки адресов тоже занесу в персональный блок лист. Правильно mail.ru делает. Если вы не хотите бороться со спамом с вашего ip, не подписаны на FBL, то чего вы жалуетесь?

                                            Шаред хостеры с их безобразным отношением к безопасности и непрофессиональными разработчиками сайтов это второй по объему источник спама. Первый (зомби из клиентских сетей) рубится PBL, а вот на вас управы нет ибо можно с водой ребенка выплеснуть.
                                            • 0
                                              с наших ip не рассылается спам, у нас не совсем shared, ближе к saas
                                              • 0
                                                Ну, вот у меня тоже Saas и существенных проблем не было. Вообще, возможно, объемы не те (до 70 000 в день во все стороны). Процент не активных ящиков там велик, но мы стараемся такие вещи отслеживать и чистить базу от мертвяков, хотя это затруднительно с юридической точки зрения. При этом клиенты, которые с головой дружат и используют SPF на своих доменах вообще проблем не испытывают.
                                                • 0
                                                  ну вот да, чистить базы на клиентских инсталляциях как-то не очень, не так ли? =)

                                                  что ещё более усугулбяется тем, что кое-кто удаляет ящики после какого-то периода неактивности. вот он был хороший живой ящик, а вот ты уже злостный спамер, потому что посмел отправить письмо на несуществующий адрес. неплохо, майлру, неплохо.
                                                  • 0
                                                    Разумеется не очень, но клиенты нам платят в том числе и за это.
                                              • 0
                                                а жалуемся мы на то, что при количестве исходящих спамных писем равном ноль целых ноль десятых долбаный mail.ru отлично блокирует серверы целиком. так не делает никто больше, ни гугл, ни яндекс. даже на параноидальный аол почта ходит без проблем. раньше майлру нас заносили в белые списки, сейчас этот функционал упразднили.
                                        • 0
                                          Какой установлен порядок внесения своего домена в этот белый список DMARC? Support в ответ на
                                          [Ticket#2016052721031437] дал ссылку на эту статью и ни какой конкретики.

                                          У нас маленький почтовый сервер на 50 человек, люди часто используют mail.ru в качестве основного ящика, а наш используют для официальных писем. И ставят редирект, который с включением DMARC на mail.ru перестал работать. Правда, вроде только в случае, если с mail.ru кто-то послал письмо на наш почтовый адрес, где стоит редирект на mail.ru же почтовый адрес респондента… Хотелось бы решить этот вопрос не нагибая пользователей. Учитывая популарность mail.ru среди пользователей — ситуация вроде должна быть довольно распространённая, но нигде внятного описания я не нашёл (довольно долго листал\искал по help.mail.ru и просто гуглил), хотя может не те поисковые запросы использовал…

                                          Кстати, вариант со сборщиком почты не очень хорош и его хотелось бы избежать, иногда люди используют почту, как чат, с редиректом почта доходит мгновенно и за минуту может быть отправленно несколько сообщений с обоих сторон. Плюс, если человек меняет пароль — редирект продолжает работать, а сборщик — нет.
                                          • 0
                                            Сейчас редирект не будет работать только в такой ситуации: есть user1@mail.ru с него письма редиректятся в user@company.ru а с него обратно на mail.ru, например в user2@mail.ru и при этом кто-то из пользователей mail.ru, например user3@mail.ru будет писать на user1@mail.ru. Попросите пользователей избегать двойных редиректов между разными сервисами.

                                            Могу еще порекомендовать воспользоваться biz.mail.ru, это снимет большую часть проблем.

                                            Если в какой-то другой ситуации возникают проблемы — перешлите полный текст сообщения о невозможности доставки, я разберусь.
                                            • 0
                                              Такая же проблема с редиректом. Двойного редиректа нет. Только user1@mail.ru -> user@company.ru — >user2@mail.ru.
                                              Все детали есть в тикете Ticket#2016072621040891. Если у вас нет туда доступа, скажите куда прислать ответ сервера.
                                              • 0
                                                Если редирект организован так, что меняет содержимое письма не меняя From — это приведет блокировке письма по DMARC. Необходимо либо исправить редирект так, чтобы он не менял содержимое письма, либо организовать редирект так, чтобы он подставлял авторизованный From, либо отказаться от редиректа и использовать сбор почты.
                                                • 0
                                                  У меня Exchange 2010, используется стандартный механизм пересылки. Получается, теперь нельзя использовать редирект на адреса mail.ru? Где тут борьба со спамом? Если вы ведете такой учет, то это вам в копилку минусов от введения DMARC.
                                                  • 0
                                                    Доставку на любые адреса крупных почт — серверная часть DMARC поддерживается и GMail и Yahoo и даже outlook.com. Т.е. письма при такой пересылке вы теряли давно, т.к. строгий DMARC давно используют многие домены, но не замечали этого пока не начали теряться письма от mail.ru.
                                  • 0
                                    Наконец-то, не прошло и 10 лет. Может хоть теперь поменьше спама будет приходить
                                    • 0
                                      Если про отсутствие авторизации почты — то прошло не только 10, но и 25 лет, а если про внедрение DMARC — то работа над ним началась в 2012-2013 годах, стандартом он стал в 2015, Mail.Ru поддерживает DMARC с 2014го.
                                      • 0
                                        последние год-полтора спама стало приходить больше чем до этого. причем валиться именно в inbox. DMARC?
                                        • 0
                                          Нет, скорей это связано с «засвеченностью» ящика — чем дольше живет адрес электронной почты, тем больше спама на него идет. В целом объем спама последние годы достаточно стабилен, а объем спама доходящего до инбокса снижается. Не забывайте нажимать кнопку «Спам» — она не просто переносит письмо в соответствующую папку, она отписывает вас от рассылки, помогает категоризировать рассылку и сделать так, чтобы похожие письма не доходили вам и другим пользователям и шлет жалобы администраторам сетей / сервисов рассылок о том, что клиент нарушает правила рассылок.
                                          • 0
                                            Причем тут засвеченность? Пусть идет сколько хочет но валится в папку спам. Оно же у меня в inbox идет. И вы думаете я кнопку спам не нажимаю?
                                    • 0
                                      Ох, офигенно.
                                      А теперь о проблемах. Использую личную почту и отдельно заведенный ящик на mail.ru для отправки писем через php скрипт.
                                      1. Если отправлять через специальный ящик, то у вас система не учитывает заходы по smtp (заходов по imap или pop нет, как и заходов через веб-морду) — ящик блокируется через какое-то время для отправки писем.
                                      2. Завести почту для бизнеса — сделайте поддержку кириллических доменов сначала в почте для бизнеса.
                                      3. Хостинг на рег.ру. Резолвится обратно в технический домен по номеру пользователя, висят несколько доменов — что делать для «чайников»?

                                      А то я если честно просто фигею, кириллическим доменам уже около 6 лет, а никто их нормально не поддерживает. И иногда даже до смешного доходит, как в истории с Яндекс.Маркетом.
                                      • 0
                                        В качестве feature request: можете включить отступы с переносами в своих отчётах и отправлять их с отдельного ящика (вместо noreply@corp.mail.ru)?
                                        Даже у Yahoo это сделано нормально, а ваши отчёты нечитаемы человеком.
                                        • 0
                                          Про адрес знаем, поменяем.
                                          «Человекочетамость» для XML не подразумевалась, она увеличит отчеты примерно на 15-20%, а по некоторым доменам они уже превышают 500 мегабайт. Насколько это действительно требуется? Можно открыть отчет в браузере, например FF или пользоваться
                                          DMARC XML-to-Human Converter.
                                          • 0
                                            Не особо, я уже подписался на сервис от Postmark, но такой формат неприятно удивил. От Google они приходят в читаемом виде, да и zip должен сжимать пробелы.
                                        • 0
                                          Есть ли какая-нибудь инструкция, как настроить почтовый сервер Communigate для нормальной отправки почты, чтобы письма не реджектились?
                                          15:54:10.14 5 SMTP-129695(list.ru) inp: 550 5.7.1 This message was not accepted due to domain owner DMARC policy (RFC 7489) https://help.mail.ru/mail-help/postaster/dmarc

                                          По ссылке help.mail.ru/mail-help/postaster/dmarc описана настройка DNS-сервера. Правильно ли я понял, что почтовик тут не при чем?

                                          Отправляю из php (From: ***@list.ru) через свой communigate сервер на хостинге. Доступ к communigate через учетку smtp. DNS-сервер тоже свой. Как проще решить проблему, не меняя настройки smtp в php-скриптах? (для вебмастера изменения должны быть незаметны)
                                          • 0
                                            Правильная инструкция — не использовать From: ***@list.ru, т.к. ваш сервер не авторизован отправлять почту с этого адреса.
                                            • 0
                                              А неправильная? Можно ли как то реализовать такой сценарий, чтобы не было ошибки и сообщения уходили:
                                              Пользователь отправляет данные через контактную форму сайта, указывая свой email на *mail.ru, которые подставляется в поля From и Reply-to, но данные сообщения не доходят, а возвращются пользователю обратно с ошибкой:

                                              SMTP error from remote mail server after end of data:
                                              host gmail-smtp-in.l.google.com [64.233.164.26]:
                                              550-5.7.1 Unauthenticated email from inbox.ru is not accepted due to domain's
                                              550-5.7.1 DMARC policy. Please contact administrator of inbox.ru domain if this
                                              550-5.7.1 was a legitimate mail. Please visit
                                              550-5.7.1 https://support.google.com/mail/answer/2451690 to learn about DMARC
                                              550 5.7.1 initiative. w135si31728617lfd.40 - gsmtp


                                              Отправлять пробовал через авторизованный ящик со своего домена, а также через сервер mailgun.org (SPF и DKIM прописаны). Какая существует возможность избавиться от проблем с отправкой?
                                              • 0
                                                Да, существует. Если не использовать адрес пользователя в поле From:, а использовать адрес вашего домена, для которого вы прописали SPF и DKIM — то письма будут уходить.
                                                • 0
                                                  А Reply-to в таком случае возможно ставить пользовательский (те *mail.ru)?
                                                  • 0
                                                    Да, в статье это есть.
                                          • 0
                                            Прошу прощения за непонятливость, но у меня проблема с этим DMARC, прошу помощи.

                                            Суть проблемы mail.ru блокирует письма. я администрирую сервис обратной связи formm.ru, сервис подменяет поле «Reply-To».
                                            Зачем это делать?! В этом суть сервиса, например:
                                            — Некий web мастер хочет разместить форму обратной связи на бесплатном хостинге
                                            — Он генерирует на нашем сайте форму и размещает у себя html код
                                            — Посетитель его сайта отправляет сообщение через эту форму, указав при этом свой обратный email
                                            — сервис formm.ru получает данное сообщение и отправляет web мастеру на почту
                                            — Соответственно в поле «Reply-To» подставляется email отправителя сообщения, что бы web мастер прочитав письмо ответил на письмо нажав кнопку ответить. И письмо попадет туда куда нужно. Кроме того, web мастер в списке писем видит, что письма у него пришли от конкретных пользователей, а не от нашего сервиса.

                                            Естественно я понимаю, что спамеры так же используют данную возможность и с этим нужно нещадно бороться.
                                            На сколько я понимаю я нарушаю политику DMARC и письма блокируются справедливо.
                                            Но мне то, что делать? Подскажите.
                                            • 0
                                              DMARC не накладывает ограничений на поле Reply-To, только ограничения на поле From:
                                            • 0
                                              Да, Вы правы, «From» тоже подменяем, попробую подправить, может, что то получится.

                                              писал на support@corp.mail.ru, там шлют ссылки на эту статью в том числе. Ни какой реальной помощи. А сервисом formm.ru пользуются более 3500 пользователей mail.ru почты.

                                              Это не 1-2 и даже не 100 человек, можно проявить немного больше внимания, а в идиале в «белый список» внести. Или такого количества пользователей маловато для «белого списка»?

                                              • 0
                                                Спасибо!
                                                Вы мне очень помогли, мне достаточно подменять поле Reply-To, а я зачем то еще From подменял, поправил, должно все работать.

                                                Хотя вопрос про «белый список» сохраняется.
                                                • 0
                                                  Отправка новых писем с адреса пользователя не имеет отношения к форвардингу, делать так — это в принципе некорректно.
                                                • 0
                                                  Это и не форвардинг. Это услуга по пересылке сообщения от посетителя к владельцу сайта.
                                                  Услуга, кстати востребованная, есть даже платные аналоги.

                                                  Вы пишите в статье:
                                                  Кроме того, крупные почтовые сервисы, в том числе Mail.Ru, поддерживают белые списки известных форвардеров (known forwarders) — для списков рассылок и других почтовых служб, почта от которых принимается даже в случае нарушения DMARC.


                                                  Вот наш сервис и есть «другие почтовые службы».

                                                  Кстати, блокировок стало меньше, но часть писем блокируется все равно:
                                                  Action: failed
                                                  Status: 5.7.1
                                                  Remote-MTA: dns; mxs.mail.ru
                                                  Diagnostic-Code: smtp; 550 5.7.1 This message was not accepted due to domain
                                                  owner DMARC policy (RFC 7489)

                                                  From теперь правильный, что не так?
                                                  • 0
                                                    Либо From все еще неправильный, либо вы опубликовали DMARC для своего домена и часть писем не проходят SPF/DKIM. Смотрите по журналам сервера.
                                                    • 0
                                                      Да, Вы опять правы, в скрипте было два варианта указания From, теперь вроде бы все ок.
                                                      Спасибо!
                                                  • 0
                                                    z3apa3a Подключил почту для бизнеса, установил требуемые SPF/DKIM записи.
                                                    Есть такой известный сервис рассылки mailchimp.com, так там предлагается также установить SPF/DKIM. Реально ли это совместить, чтобы делать рассылку через них?
                                                    Нужные записи для mailchimp:
                                                    DKIM — Create a CNAME record for k1._domainkey.yoursite.com with this value: dkim.mcsv.net.
                                                    SPF — Create a TXT record for yoursite.com with this value: v=spf1 include:servers.mcsv.net ?all
                                                    • 0
                                                      Да, реально. Включите их SPF-политику в свою запись через include, а DKIM — сгенерируйте отдельный ключ+селектор.
                                                      • 0
                                                        Подскажите как объединить эти 2 SPF записи в одну:

                                                        сейчас там — v=spf1 redirect=_spf.mail.ru
                                                        нужно объединить с v=spf1 include:servers.mcsv.net ?all

                                                        Такое нашел — If the REDIRECT function is used, no other mechanisms can be included in the SPF record, including the “all” mechanism.
                                                        • 0
                                                          Промахнулся, ответил ниже.
                                                    • 0
                                                      v=spf1 include:servers.mcsv.net redirect=_spf.mail.ru
                                                      • 0
                                                        не пропускает почему-то
                                                        SPF: TXT record containing 'include:servers.mcsv.net' not found.
                                                        А если вместо redirect тоже include попробовать сделать, так будет работать?
                                                        • 0
                                                          Да, можно
                                                          v=spf1 include:servers.mcsv.net include:_spf.mail.ru ~all
                                                          но проблема скорей всего не в этом, скиньте лучше имя домена, можно в личку.
                                                          • 0
                                                            в профиле указан сайт
                                                            • 0
                                                              Все нормально с записью, возможно проблемы с валидацией на стороне mailchimp, попробуйте с include.
                                                              • 0
                                                                да, сработало с include, спасибо!
                                                                mail.ru будет работать без изменений в таком варианте записи?
                                                    • 0

                                                      Вы сломали нам рассылку. Спасибо!

                                                      • 0
                                                        Пожалуйста, но этой статье больше года и вряд ли политика DMARC домена mail.ru может влиять на вашу рассылку. Если ваша рассылка попадает под политики DMARC, значит вы ее неправильно делаете.
                                                        • 0

                                                          Что значит «врядли»? Именно она и влияет:


                                                          • с мейлру кто-то послал мейл
                                                          • мейл форварднулся мейлманом
                                                          • в нём поломались подписи
                                                          • мейл пришёл в гугл
                                                          • мейлру завещал такие емейлы с поломатыми подписями режектить
                                                          • гугл послушно мейл режектнул и послал баунс
                                                          • мейлман словил баунс, один, второй, третий…
                                                          • мейлман решил, что у гуглоюзера неверно сконфигурён сервер (перманентный режект), мейлман удалил гуглоюзера из рассылки

                                                          И так на каждый мейл из мейру.


                                                          О, да, есть решение: запретить мейлоюзеров, но хотелось бы без этого

                                                          • 0
                                                            Так запретите, только сразу запретите еще юзеров Yahoo, AOL и все крупные корпорации, т.к. у них тоже строгий DMARC, а с этого года придется запретить gmail, hotmail/outlook и Yandex, т.к. они тоже анонсировали внедрение строгого DMARC. В общем лучше вообще сразу всех запрещать, чтобы много раз в конфигурацию не лазить.

                                                            Или таки, как в mailman надо настроить dmarc_moderation_action с действием Munge From, но это как-то менее радикально, да еще и документацию читать надо.
                                                            • 0

                                                              Munge From — уродство, которое коряжит адреса. Это не решение. Решение — отменить DMARC. Эта спецификация никогда не должна была увидеть свет.

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

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