Комментарии 20
Почему-то и у вас, и у Гугла sp может принимать значения r и s. А в rfc написано: reject, quarantine и none.
+1
Это мы ошиблись в хелпе. Поправили: help.mail.ru/mail-help/postmaster/dmarc. При разработке старались в точности придерживаться стандарта. Спасибо, что нашли ошибку!
+1
А это все не загнется так же как OMF?
0
Вряд ли. Мы последовательно улучшаем жизнь рассыльщиков. Проект Постмастер ( postmaster.mail.ru ) и поддержка DMARC — это только начало.
0
Тогда еще вопрос — мне сказали что будет возможность аватар сделать для писем таких, что как раз на postmaster.mail.ru такая возможность будет. Вы не в курсе? Особенно по срокам интересно. У тех кто успел как-то есть иконки, а у нас вот увы.
0
Если вопрос о самом стандарте, то, согласно данным dmarc.org, со стороны MBP его уже поддерживают AOL, Comcast, Google, Mail.ru, Microsoft, NetEase, Xs4All и Yahoo! — порядка 60% всех почтовых ящиков в мире.
Со стороны отправителей — половина из Top20 доменов крупнейших рассыльщиков уже опубликовали политику DMARC для своих доменов.
И это все только за год после публикации стандарта, что говорит о восстребованности технологии.
Со стороны отправителей — половина из Top20 доменов крупнейших рассыльщиков уже опубликовали политику DMARC для своих доменов.
И это все только за год после публикации стандарта, что говорит о восстребованности технологии.
+2
планируется ли экспорт данных с postmaster.mail.ru?
0
Теория — это хорошо. Реальность куда неприятнее.
Имеем домен. Неважно, что на нем — сайт магазина, форум, публичный почтовый сервис, либо это просто конторский почтовый домен.
Вопрос: какую политику нам задать в 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 состояния: «о, спама нет, отлично!», «мне послали письмо, оно пропало по пути», и «как достал спам, сделайте что-нибудь!» А вот случая «готов потерять часть почты, но спам видеть не хочу» — такое мало кто говорит :)
0
DMARC он не для борьбы со спамом, DMARC это в первую очередь именно защита от поддельных писем.
Строгую политику SPF задавать нельзя, т.к. SPF бьется на пересылках. А вот строгую политику DKIM — волне можно.Т.е. сделать так, чтобы с вашего домена шли только подписанные DKIMом письма. При этом DKIM не портится от пересылок.
Строгую политику SPF задавать нельзя, т.к. SPF бьется на пересылках. А вот строгую политику DKIM — волне можно.Т.е. сделать так, чтобы с вашего домена шли только подписанные DKIMом письма. При этом DKIM не портится от пересылок.
0
В примере «v=DMARC1; p=none; rua=mailto: postmaster@exampledomain.ru»
лишний пробел после двоеточия.
лишний пробел после двоеточия.
0
Столкнулся с проблемой пересылки писем.
Есть ящик на 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.
0
Проясните пожалуйста, а то путаница в голове:
1 — Правильно ли я понимаю, что в политике DMARC учитывается не сама проверка pass/fail от SPF/DKIM, а проверка соответствия доменов?
2 — Если хотя бы одна из проверок доменов в SPF либо DKIM, прошла, тогда считается что и проверка DMARC прошла?
3 — Во время учета домена из DKIM, сравнивается домен из поля d= сигнатуры и RFC5322.From?
4 — Во время учета домена из SPF, сравнивается домен из RFC5321.From (а это есть Return-Path) и RFC5322.From?
5 — Если в письме несколько DKIM сигнатур (от оригинального домена и от домена на котором настроена пересылка) то по какому алгоритму идет проверка?
1 — Правильно ли я понимаю, что в политике DMARC учитывается не сама проверка pass/fail от SPF/DKIM, а проверка соответствия доменов?
2 — Если хотя бы одна из проверок доменов в SPF либо DKIM, прошла, тогда считается что и проверка DMARC прошла?
3 — Во время учета домена из DKIM, сравнивается домен из поля d= сигнатуры и RFC5322.From?
4 — Во время учета домена из SPF, сравнивается домен из RFC5321.From (а это есть Return-Path) и RFC5322.From?
5 — Если в письме несколько DKIM сигнатур (от оригинального домена и от домена на котором настроена пересылка) то по какому алгоритму идет проверка?
0
1. Учитывается результат проверки при условии соответствия доменов. Т.е. если во From домен example.com, то SPF или DKIM для домена example.org не будет учитываться в DMARC, т.к. это разные организационные домены.
2. Совершенно верно, но при условии выполнения п.1
3. Да, сравнивается домен из d= или i=
4. Да, сравнивается домен из RFC5321.From (при пустом From используется домен из RFC5321.Helo). Return-Path не совсем то же самое, это заголовок который добавляется в сообщение при доставке в ящик конечного пользователя, как правило (но не обязательно) он так же содержит RFC5321.From.
5. Достаточно чтобы была хотя бы одна валидная DKIM-сигнатура соответствующая домену из RFC5322.From. Сигнатуры от других доменов и невалидные сигнатуры никак не влияют. Правда бывают ошибки реализации, например мы засабмитили такой патч в exim (можно за него проголосовать).
2. Совершенно верно, но при условии выполнения п.1
3. Да, сравнивается домен из d= или i=
4. Да, сравнивается домен из RFC5321.From (при пустом From используется домен из RFC5321.Helo). Return-Path не совсем то же самое, это заголовок который добавляется в сообщение при доставке в ящик конечного пользователя, как правило (но не обязательно) он так же содержит RFC5321.From.
5. Достаточно чтобы была хотя бы одна валидная DKIM-сигнатура соответствующая домену из RFC5322.From. Сигнатуры от других доменов и невалидные сигнатуры никак не влияют. Правда бывают ошибки реализации, например мы засабмитили такой патч в exim (можно за него проголосовать).
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
DMARC: защитите вашу рассылку от подделок