Комментарии 20
Почему-то и у вас, и у Гугла sp может принимать значения r и s. А в rfc написано: reject, quarantine и none.
Это мы ошиблись в хелпе. Поправили: help.mail.ru/mail-help/postmaster/dmarc. При разработке старались в точности придерживаться стандарта. Спасибо, что нашли ошибку!
А это все не загнется так же как OMF?
Вряд ли. Мы последовательно улучшаем жизнь рассыльщиков. Проект Постмастер ( postmaster.mail.ru ) и поддержка DMARC — это только начало.
Если вопрос о самом стандарте, то, согласно данным dmarc.org, со стороны MBP его уже поддерживают AOL, Comcast, Google, Mail.ru, Microsoft, NetEase, Xs4All и Yahoo! — порядка 60% всех почтовых ящиков в мире.
Со стороны отправителей — половина из Top20 доменов крупнейших рассыльщиков уже опубликовали политику DMARC для своих доменов.
И это все только за год после публикации стандарта, что говорит о восстребованности технологии.
Со стороны отправителей — половина из Top20 доменов крупнейших рассыльщиков уже опубликовали политику DMARC для своих доменов.
И это все только за год после публикации стандарта, что говорит о восстребованности технологии.
планируется ли экспорт данных с postmaster.mail.ru?
Теория — это хорошо. Реальность куда неприятнее.
Имеем домен. Неважно, что на нем — сайт магазина, форум, публичный почтовый сервис, либо это просто конторский почтовый домен.
Вопрос: какую политику нам задать в spf? Как ни крути, никто не напишет про свой момент «руби с плеча». Максимум — «смотреть подозрительнее», а если бы было значение «не считать спамом», им бы все и пользовались.
Примерно так получается:
1. Магазины и вообще публичные сайты постараются сделать так, чтобы их почта все же попадала в ящик, притом не в папку «Спам» (кстати, часть людей используют POP3 доступ, и папку «Спам» просто не читают).
2. Публичный почтовый сервис — он что не укажет, все равно (на примере mail.ru вполне показательно видно: спамеры тупо через их же сервера отсылают спам, и его никакой spf не отобьет; при этом часть людей из почтовых клиентов используют адреса на mail.ru, но отсылают через smtp своего провайдера или конторский — т.е. у «нормальных» писем spf может не проверяться).
3. Контора любая, заточенная не под высокие материи борьбы с ветряными мельницами, а под бизнес и получения прибыли, вполне может плевать на красоту идеи spf и прочего, главное, чтобы они (и их партнеры) получали рабочую почту. Что-то вроде «пусть у меня на компе хоть 100 вирусов, мне на нем работать надо» — что с этим поделать? Ведь ИТ в компаниях помогает бизнесу, а не мешает.
Вот и получается, что борьба со спамом — проблема ИТ-ная, в реальном мире есть 3 состояния: «о, спама нет, отлично!», «мне послали письмо, оно пропало по пути», и «как достал спам, сделайте что-нибудь!» А вот случая «готов потерять часть почты, но спам видеть не хочу» — такое мало кто говорит :)
Имеем домен. Неважно, что на нем — сайт магазина, форум, публичный почтовый сервис, либо это просто конторский почтовый домен.
Вопрос: какую политику нам задать в spf? Как ни крути, никто не напишет про свой момент «руби с плеча». Максимум — «смотреть подозрительнее», а если бы было значение «не считать спамом», им бы все и пользовались.
Примерно так получается:
1. Магазины и вообще публичные сайты постараются сделать так, чтобы их почта все же попадала в ящик, притом не в папку «Спам» (кстати, часть людей используют POP3 доступ, и папку «Спам» просто не читают).
2. Публичный почтовый сервис — он что не укажет, все равно (на примере mail.ru вполне показательно видно: спамеры тупо через их же сервера отсылают спам, и его никакой spf не отобьет; при этом часть людей из почтовых клиентов используют адреса на mail.ru, но отсылают через smtp своего провайдера или конторский — т.е. у «нормальных» писем spf может не проверяться).
3. Контора любая, заточенная не под высокие материи борьбы с ветряными мельницами, а под бизнес и получения прибыли, вполне может плевать на красоту идеи spf и прочего, главное, чтобы они (и их партнеры) получали рабочую почту. Что-то вроде «пусть у меня на компе хоть 100 вирусов, мне на нем работать надо» — что с этим поделать? Ведь ИТ в компаниях помогает бизнесу, а не мешает.
Вот и получается, что борьба со спамом — проблема ИТ-ная, в реальном мире есть 3 состояния: «о, спама нет, отлично!», «мне послали письмо, оно пропало по пути», и «как достал спам, сделайте что-нибудь!» А вот случая «готов потерять часть почты, но спам видеть не хочу» — такое мало кто говорит :)
DMARC он не для борьбы со спамом, DMARC это в первую очередь именно защита от поддельных писем.
Строгую политику SPF задавать нельзя, т.к. SPF бьется на пересылках. А вот строгую политику DKIM — волне можно.Т.е. сделать так, чтобы с вашего домена шли только подписанные DKIMом письма. При этом DKIM не портится от пересылок.
Строгую политику SPF задавать нельзя, т.к. SPF бьется на пересылках. А вот строгую политику DKIM — волне можно.Т.е. сделать так, чтобы с вашего домена шли только подписанные DKIMом письма. При этом DKIM не портится от пересылок.
В примере «v=DMARC1; p=none; rua=mailto: postmaster@exampledomain.ru»
лишний пробел после двоеточия.
лишний пробел после двоеточия.
Столкнулся с проблемой пересылки писем.
Есть ящик на O365, допустим, vpupkin@company.ru.
На ящике настроена пересылка писем на личный аккаунт, допустим, vpupkin@gmail.com.
В итоге, часть писем не доходит с ошибкой:
На домене rassilka.ru стоит политика v=DMARC1; p=reject; adkim=s; aspf=r; rf=afrf; pct=100
Вот и получается что будут отклоняться пересылаемые письма от доменов где стоит reject.
Есть ящик на O365, допустим, vpupkin@company.ru.
На ящике настроена пересылка писем на личный аккаунт, допустим, vpupkin@gmail.com.
В итоге, часть писем не доходит с ошибкой:
550 5.7.23 The message was rejected because of Sender Policy Framework violation -> 550 5.7.1 Unauthenticated email from rassilka.ru is not accepted due to;domain's DMARC policy.
Please contact the administrator of;rassilka.ru domain if this was a legitimate mail.
Please visit; https://support.google.com/mail/answer/2451690 to learn about the;DMARC initiative.На домене rassilka.ru стоит политика v=DMARC1; p=reject; adkim=s; aspf=r; rf=afrf; pct=100
Вот и получается что будут отклоняться пересылаемые письма от доменов где стоит reject.
Проясните пожалуйста, а то путаница в голове:
1 — Правильно ли я понимаю, что в политике DMARC учитывается не сама проверка pass/fail от SPF/DKIM, а проверка соответствия доменов?
2 — Если хотя бы одна из проверок доменов в SPF либо DKIM, прошла, тогда считается что и проверка DMARC прошла?
3 — Во время учета домена из DKIM, сравнивается домен из поля d= сигнатуры и RFC5322.From?
4 — Во время учета домена из SPF, сравнивается домен из RFC5321.From (а это есть Return-Path) и RFC5322.From?
5 — Если в письме несколько DKIM сигнатур (от оригинального домена и от домена на котором настроена пересылка) то по какому алгоритму идет проверка?
1 — Правильно ли я понимаю, что в политике DMARC учитывается не сама проверка pass/fail от SPF/DKIM, а проверка соответствия доменов?
2 — Если хотя бы одна из проверок доменов в SPF либо DKIM, прошла, тогда считается что и проверка DMARC прошла?
3 — Во время учета домена из DKIM, сравнивается домен из поля d= сигнатуры и RFC5322.From?
4 — Во время учета домена из SPF, сравнивается домен из RFC5321.From (а это есть Return-Path) и RFC5322.From?
5 — Если в письме несколько DKIM сигнатур (от оригинального домена и от домена на котором настроена пересылка) то по какому алгоритму идет проверка?
1. Учитывается результат проверки при условии соответствия доменов. Т.е. если во From домен example.com, то SPF или DKIM для домена example.org не будет учитываться в DMARC, т.к. это разные организационные домены.
2. Совершенно верно, но при условии выполнения п.1
3. Да, сравнивается домен из d= или i=
4. Да, сравнивается домен из RFC5321.From (при пустом From используется домен из RFC5321.Helo). Return-Path не совсем то же самое, это заголовок который добавляется в сообщение при доставке в ящик конечного пользователя, как правило (но не обязательно) он так же содержит RFC5321.From.
5. Достаточно чтобы была хотя бы одна валидная DKIM-сигнатура соответствующая домену из RFC5322.From. Сигнатуры от других доменов и невалидные сигнатуры никак не влияют. Правда бывают ошибки реализации, например мы засабмитили такой патч в exim (можно за него проголосовать).
2. Совершенно верно, но при условии выполнения п.1
3. Да, сравнивается домен из d= или i=
4. Да, сравнивается домен из RFC5321.From (при пустом From используется домен из RFC5321.Helo). Return-Path не совсем то же самое, это заголовок который добавляется в сообщение при доставке в ящик конечного пользователя, как правило (но не обязательно) он так же содержит RFC5321.From.
5. Достаточно чтобы была хотя бы одна валидная DKIM-сигнатура соответствующая домену из RFC5322.From. Сигнатуры от других доменов и невалидные сигнатуры никак не влияют. Правда бывают ошибки реализации, например мы засабмитили такой патч в exim (можно за него проголосовать).
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
DMARC: защитите вашу рассылку от подделок