На днях мы анонсировали включение строгой 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 требует аутентификации отправителя, из-за этого в нескольких ситуациях возникают проблемы:
- Пользователь посылает письма «напрямую» в обход почтового сервера с аутентификацией. Например, веб-мастер отправляет регистрационные письма 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. Но переход на новые стандарты и протоколы невозможен без поддержки всеми сторонами, и мы очень надеемся, что эта статья поможет и вам включиться в процесс построения более современной, удобной и безопасной экосистемы электронной почты.
Комментарии (47)
navion
27.04.2016 16:39smtp.mail.ru, порт 465 с использованием SSL
А почему вы используете устаревший протокол SMTPS вместо STARTTLS на порте 587?
z3apa3a
27.04.2016 16:47STARTTLS и SSL здесь используются не для обозначения шифрования, т.к. в обоих случаях используется TLS, а для удобства различения двух технологий.
Поэтому протокол не является устаревшим, на самом деле в обоих случаях используется шифрование TLS. Я считаю, что TLS на выделенном порту немного более безопасен, т.к. в нему отсутствует специфичные для STARTTLS pre-TLS атаки, такие как CVE-2011-0411, CVE-2014-3556, CVE-2015-6409, CVE-2011-1575 и т.п.
P.S. Mail.Ru поддерживает и то и другое.navion
27.04.2016 16:58Mail.Ru поддерживает и то и другое.
Вот только в справке это не отражено (как и у Яндекса), а некоторые современные приложения не поддерживают SMTPS и народ путается.z3apa3a
27.04.2016 17:04Мы добавили тот вариант, который чаще поддерживается + расписали рекомендованные варианты для разных почтовых программ. Если есть какая-то популярная программа, которую забыли — напишите, добавим и ее. Боюсь, что если мы добавим в справке оба варианта, путаницы будет не меньше, а больше.
Jeditobe
27.04.2016 16:58-6Привет, Майл.РУ.
Вашу техподдержку не дождешься, поэтому спрошу здесь. Так получилось, что оригиналы одного фотоальбома у меня лежали только на фотохостинге Мейл.ру. И вы своими очередными «прорывными» изменениями их по#ерили.
Как теперь можно скачать полноразмерное фото с «моего мира» mail.ru?
Имеется ввиду фото не с тем разрешением, в котором оно открывается, а с тем, которое было при залитии фото на фото.мэйл.ру
Возможно ли такое, если да, то как можно осуществить?
Я загружал фото в альбом с сохранением оригинала! Это было еще тогда, когда проект Фото.мейл.ру был отдельным от «моего мира». До недавнего времени эта возможность была. А теперь только пережатые фотки, оригиналов больше нет. Хотя информация в EXIF осталась.
ilya_pu
27.04.2016 17:01+1Что я должен сделать как владелец доменного имени (скажем, site.ru), если я выбрал почтовым провайдером компанию Яндекс (то есть А- и МХ- записи указывают на яндекс), чтобы при доставке писем на mail.ru не возникало неприятных неожиданностей?
z3apa3a
27.04.2016 17:13+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-политику, для начала нестрогую.
LoadRunner
27.04.2016 17:29А что делать, если провайдер не хочет\не может прописать обратную запись PTR, чтобы письма проходили проверку SPF?
z3apa3a
27.04.2016 17:35+1SPF не связан с обратной зоной и будет проходить независимо от PTR.
Но да, проблемы у вас будут. Mail.Ru принимает почту и при отсутствии PTR, но, например AOL принципиально не принмает письма с сервера без PTR записей. Вариантов два — менять провайдера или уносить сервер на хостинг.
devpreview
27.04.2016 20:34А зачем прописывать PTR для SPF? Это разве обязательное требование?
И на какой домен должен указывать PTR, когда почтовик на этом IP обслуживает несколько доменов?z3apa3a
27.04.2016 21:16PTR никак не связан с SPF, кроме случаев, когда в SPF применяется конструкция типа ptr:mail.example.com, но многие серверы проверяют PTR, поэтому он должен:
1. быть
2. имя, на которое он указывает, должно корректно резолвиться обратно в тот же IP-адрес
Если интересно, есть вот такая статья, там в том числе есть про IP-адреса, PTR и прочие технические требования.LoadRunner
27.04.2016 22:07В нашем случае есть клиент, у которого почта на хостинге и не ими управляется. Там есть и проверка PTR, и проверка DKIM.
Таких клиентов с серьёзным подходом к почте, к сожалению, мало.
Намного больше, которые используют mail.ru. И хорошо, если эти адреса не будут подделываться спамерами, потому что из-за таких клиентов пришлось добавить в исключения этот домен, иначе проблемы с получением писем у наших менеджеров.
Может подскажете даже, как можно грамотно разрулить настройку почты в случае двух провайдеров интернета (active\passive), и при этом проходить все проверки?
При условии, если не менять второго провайдера, где нет обратной записи PTR и не уносить почту на хостинг.z3apa3a
27.04.2016 22:24Если у вас два подключения к двум провайдерам — заведите на почтовый сервер IP адреса от обоих провайдеров (напрямую или через проброс/трансляцию порта), опубликуйте две MX-записи, с разными приоритетами, если какой-то из провайдеров предпочтительней или с одинаковыми, если они равнозначны. В SPF запись включите все IP адреса всех серверов. Если один из провайдеров не предоставляет PTR-записи — избегайте использовать выделенный им IP адрес для отправки почты. Для этого, например, добавляйте маршрут через него на почтовом сервере с большей метрикой. Для входящей почты наличие PTR значения не имеет.
LoadRunner
28.04.2016 04:55Ну сейчас так и сделано. Но поскольку я новичок в этом, то постоянно сомнения — правильно ли, может есть способы правильней.
Да и смущают EHLO\HELO.
Каждому IP не присвоить одинаковый FQDN ведь.z3apa3a
28.04.2016 11:21Не надо присваивать одинаковый — вполне допустимо чтобы он был разный, но для каждого имени используемого в 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.LoadRunner
28.04.2016 11:51Я правильно понимаю, что вместо одной записи:
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
?all — требуется, чтобы наши письма доходили до того самого клиента, ибо им письма приходят уже изменёнными сервером пересылки (то есть не от имени нашего сервера).
v=spf1 a:mail2.domain.ru ip4:55.66.77.88 ?allz3apa3a
28.04.2016 12:28нет, ни в коем случае. Двух записей для одного домена быть не должно. Надо примерно так:
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"
acmnu
27.04.2016 17:36«p=none» просто делает всю эту историю бесполезной. Так же как в SPF все пишут "~all".
Если бы крупные игроки договорились, набрались мужества и поставили p=reject, -all, то это бы дало существенный буст борьбе со спамом. Да, ценой небольших потерь писем, но оно того стоило.z3apa3a
27.04.2016 17:40Отчасти да, именно поэтому мы внедряем p=reject.
Но все таки не совсем, p=none позволяет получать репорты и оценить масштабы трагедии. Внедрение DMARC для крупных доменов со сложной структурой писем гораздо сложней, чем может показаться и без подобной информации практически невозможен. Мы выявили/устранили у себя порядка сотни различных проблем, прежде чем рискнуть включить p=reject.
djv57
28.04.2016 14:16При настройке, reject -all сразу ставить нежелательно.
Хороший совет от Google — последовательное развертывание DMARC.
support.google.com/a/answer/2466563?hl=ruacmnu
28.04.2016 14:38Да я имелл ввиду, что в принципе никто не включает SPF в стрикт: только что проверил: Гугл, Яндекс, Майлру, все в ~all. SPF у этих ребят уж сколько лет, а все ~. На DMARC конечно есть надежда, поскольку есть репортинг.
AlexGluck
27.04.2016 19:40-2…я пользуюсь перенаправлениями для сбора почты с нескольких аккаунтов на разных сервисах в общий ящик
На случай если это не будет работать, вам следует решить эту проблему с другими крупными почтовиками. В противном случае найух ваш почтовик который не принимает письма и не отправляет в спам всякие купончики от которых не отписаться и которые ежедневно помечаются как спам.
rusevgen
27.04.2016 22:06Так вот в чем дело… а я то думаю, что же случилось. Раньше ящик был завален спамом, будто фильтров у вас вообще не было, а теперь, да, спама в основную папку приходит мало. НО мне приходится теперь периодически лицезреть содержимое папки «спам», потому что теперь туда попадают и нормальные письма. Да, классно, что вы внедрили что-то передовое, но может стоит протестировать на реальных пользователях, а не «у кого не доходят письма, тот сам виноват», какой мне смысл от фильтра, который зарубает нужные мне письма.
z3apa3a
27.04.2016 22:15Нет, DMARC здесь непричем, он не влияет напрямую ни на объем спама в вашем ящике ни на прохождение обычных писем. Если какие-то письма попадают в папку спам — не забывайте нажимать на них «Не спам», это гарантирует, что в дальнейшем письма от данного отправителя в спам не попадут. Если проблема повторяется — обратитесь в службу поддержки, мы обязательно выявим и устраним причину.
maxout
28.04.2016 09:40«Пользователь <делает что-то>. К сожалению, единственное решение — так не делать.»
Это всё, что вам нужно знать о mail.ru.
Огромная головная боль администратора хостинга. Почему-то ни один из крупных игроков почтовых услуг не доставляет таких проблем, какие прилетают от mail.ru. Oh wait… никто кроме них вообще не доставляет проблем.z3apa3a
28.04.2016 12:18Расскажите с какими проблемами, связанными с внедрениями DMARC вы, как хостер столкнулись — обязательно постараемся учесть, помочь, посоветовать.
maxout
28.04.2016 12:46судя по всему, с проблемами, связанными с внедрениями DMARC, мы ещё только будем сталкиваться. пока остальных хватает.
btw, вы упомянули белые списки. они у вас реализованы только для DMARC или есть некие общесистемные? по этому поводу у меня недавно получился отличный диалог с вашей поддержкой, которая поведала что белых списков нет и никогда не было. только как вот при этом быть с тем, что у меня сохранилась переписка, когда нас добавляли в белые списки по запросу, я не знаю. параллельная реальность, не иначе.z3apa3a
28.04.2016 12:53DMARC не затрагивает хостеров. С трудностями могут столкнуться некоторые ваши клиенты, это может привести к обращению в службу поддержки, но обращение в данном случае легко конвертируется в продажу услуги — хостинга для почтового домена, доработки серверных скриптов.
У Mail.Ru действительно нет (и не будет) общесистемных белых списков, список известных форвардеров действует исключительно на проверку DMARC и не отключает другие проверки. Если письмо не будет отброшено по другим признакам, то оно попадет в ящик пользователя, но на нем будет показываться уведомление о возможной подделке адреса отправителя.maxout
28.04.2016 13:03зато хостеров отлично затрагивает блокировка по IP, в том числе за, цитата: «Дело в том, что с IP-адреса xxx.xxx.xxx.xxx отправляется большое количество писем на невалидные адреса.» WUT?!
мы устали бороться, обращение в службу поддержки, к сожалению, конвертируется теперь только в настоятельную рекомендацию не иметь с вашим сервисом дел.z3apa3a
28.04.2016 15:18Вы как-то ограничиваете/следите за спамом рассылаемым с хостинговых сервисов? Если у вас есть выделенная сеть, можно подписаться на FBL
http://fbl.postmaster.appsmail.ru/
и получать все жалобы на спам из вашей сети. Аналогичные сервисы есть и у других почтовых служб
http://wiki.asrg.sp.am/wiki/Feedback_loop_links_for_some_email_providers
Если речь идет о shared hosting, я бы рекомендовал вам достаточно жестко рейтлимитить отправку писем каждым клиентом.
Если вы никак не ограничиваете клиентов на shared hosting'ах, то в случае если кто-то из клиентов, например, начинает перебор адресов (что произошло, судя по ответу саппорта) — будет блокироваться отправка почты для IP адреса, это срабатывание рейтлимитов, которые любая почтовая служба применяет для подобной активности.maxout
28.04.2016 15:32перебора не было. по переписке с поддержкой я уже понял, что объяснять про shared что-то бесполезно…
просто здесь «любая почтовая служба» стоит читать как «mail.ru» =) почему-то только вам пришло в голову присвоить себе полномочия решать, что все письма с IP должны тупо режектиться на основании странных метрик о несуществующих адресах.
там судя по переписке с саппортом ещё много веселья, и судя по формулировкам, вы к ним имеете прямое отношение =) от одного только отношения к почтовым редиректам было бы очень смешно, если бы вы не были так популярны на постсоветском пространстве. вот и приходится раз за разом объяснять, что вы слишком многое на себя берёте и мы бессильны что-либо с этим сделать. раньше (лет пять назад, емнип) хоть можно было что-то обсудить, белые списки были, опять же. сейчас, видимо, уже всё, терминальная стадия.acmnu
28.04.2016 19:26+1Эм. А подскажите мне где вы работаете, я ваши блоки адресов тоже занесу в персональный блок лист. Правильно mail.ru делает. Если вы не хотите бороться со спамом с вашего ip, не подписаны на FBL, то чего вы жалуетесь?
Шаред хостеры с их безобразным отношением к безопасности и непрофессиональными разработчиками сайтов это второй по объему источник спама. Первый (зомби из клиентских сетей) рубится PBL, а вот на вас управы нет ибо можно с водой ребенка выплеснуть.maxout
28.04.2016 19:38с наших ip не рассылается спам, у нас не совсем shared, ближе к saas
acmnu
28.04.2016 19:56Ну, вот у меня тоже Saas и существенных проблем не было. Вообще, возможно, объемы не те (до 70 000 в день во все стороны). Процент не активных ящиков там велик, но мы стараемся такие вещи отслеживать и чистить базу от мертвяков, хотя это затруднительно с юридической точки зрения. При этом клиенты, которые с головой дружат и используют SPF на своих доменах вообще проблем не испытывают.
maxout
28.04.2016 20:17ну вот да, чистить базы на клиентских инсталляциях как-то не очень, не так ли? =)
что ещё более усугулбяется тем, что кое-кто удаляет ящики после какого-то периода неактивности. вот он был хороший живой ящик, а вот ты уже злостный спамер, потому что посмел отправить письмо на несуществующий адрес. неплохо, майлру, неплохо.
maxout
28.04.2016 19:43а жалуемся мы на то, что при количестве исходящих спамных писем равном ноль целых ноль десятых долбаный mail.ru отлично блокирует серверы целиком. так не делает никто больше, ни гугл, ни яндекс. даже на параноидальный аол почта ходит без проблем. раньше майлру нас заносили в белые списки, сейчас этот функционал упразднили.
sluge
28.04.2016 11:23Наконец-то, не прошло и 10 лет. Может хоть теперь поменьше спама будет приходить
z3apa3a
28.04.2016 11:32Если про отсутствие авторизации почты — то прошло не только 10, но и 25 лет, а если про внедрение DMARC — то работа над ним началась в 2012-2013 годах, стандартом он стал в 2015, Mail.Ru поддерживает DMARC с 2014го.
sluge
28.04.2016 11:42последние год-полтора спама стало приходить больше чем до этого. причем валиться именно в inbox. DMARC?
z3apa3a
28.04.2016 12:22Нет, скорей это связано с «засвеченностью» ящика — чем дольше живет адрес электронной почты, тем больше спама на него идет. В целом объем спама последние годы достаточно стабилен, а объем спама доходящего до инбокса снижается. Не забывайте нажимать кнопку «Спам» — она не просто переносит письмо в соответствующую папку, она отписывает вас от рассылки, помогает категоризировать рассылку и сделать так, чтобы похожие письма не доходили вам и другим пользователям и шлет жалобы администраторам сетей / сервисов рассылок о том, что клиент нарушает правила рассылок.
sluge
28.04.2016 12:35Причем тут засвеченность? Пусть идет сколько хочет но валится в папку спам. Оно же у меня в inbox идет. И вы думаете я кнопку спам не нажимаю?
WolfTheGrey
30.04.2016 20:08Ох, офигенно.
А теперь о проблемах. Использую личную почту и отдельно заведенный ящик на mail.ru для отправки писем через php скрипт.
1. Если отправлять через специальный ящик, то у вас система не учитывает заходы по smtp (заходов по imap или pop нет, как и заходов через веб-морду) — ящик блокируется через какое-то время для отправки писем.
2. Завести почту для бизнеса — сделайте поддержку кириллических доменов сначала в почте для бизнеса.
3. Хостинг на рег.ру. Резолвится обратно в технический домен по номеру пользователя, висят несколько доменов — что делать для «чайников»?
А то я если честно просто фигею, кириллическим доменам уже около 6 лет, а никто их нормально не поддерживает. И иногда даже до смешного доходит, как в истории с Яндекс.Маркетом.
ainu
Ох. Если я отправляю письмо с сервера (PHP) скриптом, для домена site.ru я делаю поддомен mailer.site.ru, указываю у поддомена SPF с IP адресом сервера отправителя, A-запись с сервером отправителя, в поле From указываю noreply@mailer.site.ru. — мне надо беспокоиться, или надо для поддомена mailer тоже делать почту-на-домене?
Аналогичный вопрос, когда кроме SPF есть ещё DKIM.
z3apa3a
DMARC проверяет align для организационного домена. Организационный домен это например example.org или example.or.uk (т.е. первый поддомен в домене, открытом для регистрации). Список доменов открытых для регистрации обычно берется из http://publicsuffix.org. Т.е. если в SPF сработает mailer.example.org а в From будет example.org — это нормально, т.е. организационный домен в данном случае example.org и он совпадает.
z3apa3a
Это кроме случая, когда домен site.ru публикует DMARC-политику с полем aspf=s, s (strict) требует строгого соответствия домена из SPF и домена из From.
Ну и вообще — если site.ru не публикует DMARC-политику, то беспокоиться о DMARC не надо.