Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 34
Для доменов третьего уровня можно использовать wildcard-записи (со звездочкой): www.openspf.org/FAQ/The_demon_question
Правда, их поддерживают не все панели управления.
Правда, их поддерживают не все панели управления.
По какой-то причине, ни в одном клиенте нет проверки SPF и DKIM по умолчанию. У меня стоит замечательное дополнение ThunderSec для Thunderbird, которое выводит огромную красную панель, если вдруг есть какие-то проблемы с SPF, DKIM и DNSBL. Сразу дает понять, кто есть кто, если сервер вдруг пропустил письмо.
Я еще такую штуку начинал писать, но как-то забросил:
spf.valdikss.org.ru
spf.valdikss.org.ru
Хорошая идея, на деле потерявшая смысл из-за: необязательности ее использования, политик вида ~ вместо -, и из-за кривых рук админов вмех мастей. Лично имел радость, когда почта с нашего домена не доходила до одного из банков, админы которого настроилт проверялку spf как-то не так (притом на просьбу решить вопрос на их стороне ответ был один — мы банк, у нас все ок, ищите проблему у себя; наша spf-запись была правильной).
По факту получаем, что технолгия как бы есть, но работает вполсилы, отчего не уважаема и не набирает авторитета. С учетом ее возраста можно считать, что по-настоящему она уже не «взлетела». Увы.
По факту получаем, что технолгия как бы есть, но работает вполсилы, отчего не уважаема и не набирает авторитета. С учетом ее возраста можно считать, что по-настоящему она уже не «взлетела». Увы.
Да, технология не новая, но все же она работает и учитывается всеми крупными почтовыми сервисами. Поэтому, SPF лучше иметь, чем не иметь. А если хочется большей надежности и новой технологии — есть DKIM/DMARC.
Интересно было бы посмотреть на заголовки писем, отчет анти-спам фильтра и spf домена, чтобы выяснить причину.
Интересно было бы посмотреть на заголовки писем, отчет анти-спам фильтра и spf домена, чтобы выяснить причину.
Если я поведусь на советы и пропишу "-all", не будет ли это мешать при пересылке/перенаправлении письма почтовыми хостерами? Иногда получаю dmarc-отчеты, в которых в качестве отправителя указан ip mail.ru. Письма то проходят, т. к. настроен dkim, но не всех же он есть.
Если ваше письмо будет безусловно перенаправлено другому адресату, то, действительно, может возникнуть проблема, так как SPF проверяет только последний хоп, а пересылаемый сервер не будет иметь права на отправку. В данном случае можно использовать механизм SoftFail (~).
Проблема в том, что SPF проверяет только параметр Return-Path, а не From. Пользователи же видят именно From. Так что штука практически бесполезная в контексте защиты от фишинга и нужна больше для защиты от спама ответными сообщениями об ошибках.
Вот. Золотой комментарий! Эта тема в топике вообще не рассмотрена.
Не только для защиты от спама ответными сообщениями, кстати, но еще и для того, чтобы ваш домен какой нибудь SpamHaus не забанил якобы за рассылку спама.
Не только для защиты от спама ответными сообщениями, кстати, но еще и для того, чтобы ваш домен какой нибудь SpamHaus не забанил якобы за рассылку спама.
Для этого есть DMARC
И еще:
https://tools.ietf.org/html/rfc7208#section-2.1
Тут же говорится про MAIL FROM?
An SPF-compliant domain publishes valid SPF records as described in
Section 3. These records authorize the use of the relevant domain
names in the «HELO» and «MAIL FROM» identities by the MTAs specified
therein.
https://tools.ietf.org/html/rfc7208#section-2.1
Тут же говорится про MAIL FROM?
Очень сумбурная статья путающая спам и фишинг, жесткие правила и эвристику.
По порядку:
Если вы заходили на openspf.org, то там с 14 года висит новость о новом RFC7202, который ставит точку в одном из самом неудачном «эксперименте» IETF — вводе переходного периода для ввода нового RR — SPF. Победил TXT — нужно теперь указывать только TXT для SPF записи.
Только если у вас на поддомене есть MX запись! По SMTP RFC вы вообще не должны принимать почту с несуществующих доменов и у которых нет MX записи. (Для гарантированной доставки в RFC всё еще есть отступление на доставку, если у этого же домена есть A запись, но это нужно было, скорее, на заре интернета и сейчас этим можно пренебречь).
Вообще говорить о спаме в разрезе SPF/DKIM/DMARC некорректно. Потому что это защиты против фишига. У них жесткие правила, они защищают конкретны вещи. Тогда как антиспам, используя статистику, базы ip, репутационные базы, сложную эвристику текста сообщений запрещают письма с нежелательным содержимым. Если вы направите письмо от microsoft.ru с полезным содержимым, то оно никогда в спам и не попадет, но будет фишингом.
DMARC — это предписывающая запись для результатов проверки DKIM, потом, на всяких случай SPF (если dkim по каким-то причинам сломался или поврежден). SPF защищает только envelope-from (smtp mail from). DKIM — From: (и другие поля) уже в самом письме. И подставить красивый envelope-from не составляет труда для спамера или, наример, при некорректных пересылках писем. Поэтому у всех стоят ~softfail политики, нужные для подстраховки при DMARC проверке, в которой SPF проверятся только как pass.
у домена нет MX — fallback на A. Поэтому оно вообще было доставлено. Gmail с довольно странными политиками, где-то сверх жесткими и не по RFC, а где-то довольно мягкими. Но реальный спам вы им всё равно не доставите :)
Если нет MX — зачем там SPF? Нужно только DMARC, который защищает от спуфинга в From:, потому что это вы не можете контролировать.
Настраивайте DMARC и вам репорты будут на ваш ящик приходить. Ну или тот же dmarcian.com вам красиво это разложит в статистику.
Итого:
Вся ваша статья должна быть про DMARC! SPF с жесткой политикой (-all) сама по себе принесет скорее вред, чем пользу.
Указывайте запрещающие политики в DMARC для доменов, которые не рассылают почту.
Проверяйте DMARC для других и настраивайте для своих доменов.
По порядку:
SPF (Sender Policy Framework) представляет из себя текстовую запись в SPF и/или TXT-записи
Если вы заходили на openspf.org, то там с 14 года висит новость о новом RFC7202, который ставит точку в одном из самом неудачном «эксперименте» IETF — вводе переходного периода для ввода нового RR — SPF. Победил TXT — нужно теперь указывать только TXT для SPF записи.
Важно понимать, что SPF-запись не наследуется на поддомены. Для каждого домена третьего (и ниже) уровней необходима своя запись.
Только если у вас на поддомене есть MX запись! По SMTP RFC вы вообще не должны принимать почту с несуществующих доменов и у которых нет MX записи. (Для гарантированной доставки в RFC всё еще есть отступление на доставку, если у этого же домена есть A запись, но это нужно было, скорее, на заре интернета и сейчас этим можно пренебречь).
анти-спам системы используют… Анализ SPF/DMARC записей домена и цифровой подписи DKIM. Чтобы предотвратить отправку спама/вирусов или другой информации от «вашего имени» достаточно лишь добавить соответствующую SPF/TXT-запись к домену
Вообще говорить о спаме в разрезе SPF/DKIM/DMARC некорректно. Потому что это защиты против фишига. У них жесткие правила, они защищают конкретны вещи. Тогда как антиспам, используя статистику, базы ip, репутационные базы, сложную эвристику текста сообщений запрещают письма с нежелательным содержимым. Если вы направите письмо от microsoft.ru с полезным содержимым, то оно никогда в спам и не попадет, но будет фишингом.
DMARC — это предписывающая запись для результатов проверки DKIM, потом, на всяких случай SPF (если dkim по каким-то причинам сломался или поврежден). SPF защищает только envelope-from (smtp mail from). DKIM — From: (и другие поля) уже в самом письме. И подставить красивый envelope-from не составляет труда для спамера или, наример, при некорректных пересылках писем. Поэтому у всех стоят ~softfail политики, нужные для подстраховки при DMARC проверке, в которой SPF проверятся только как pass.
А вот письмо от имени домена «microsoft.ru» прошло проверку и у SpamAssassin и у Gmail, так как оно не защищено
у домена нет MX — fallback на A. Поэтому оно вообще было доставлено. Gmail с довольно странными политиками, где-то сверх жесткими и не по RFC, а где-то довольно мягкими. Но реальный спам вы им всё равно не доставите :)
Рекомендуется создавать SPF-записи для всех доменов второго уровня
Если нет MX — зачем там SPF? Нужно только DMARC, который защищает от спуфинга в From:, потому что это вы не можете контролировать.
(здесь вы увидите кто отправляет письма от имени вашего домена)
Настраивайте DMARC и вам репорты будут на ваш ящик приходить. Ну или тот же dmarcian.com вам красиво это разложит в статистику.
Итого:
Вся ваша статья должна быть про DMARC! SPF с жесткой политикой (-all) сама по себе принесет скорее вред, чем пользу.
Указывайте запрещающие политики в DMARC для доменов, которые не рассылают почту.
Проверяйте DMARC для других и настраивайте для своих доменов.
Если вы заходили на openspf.org, то там с 14 года висит новость о новом RFC7202, который ставит точку в одном из самом неудачном «эксперименте» IETF — вводе переходного периода для ввода нового RR — SPF. Победил TXT — нужно теперь указывать только TXT для SPF записи.
Согласен.
Только если у вас на поддомене есть MX запись! По SMTP RFC вы вообще не должны принимать почту с несуществующих доменов и у которых нет MX записи. (Для гарантированной доставки в RFC всё еще есть отступление на доставку, если у этого же домена есть A запись, но это нужно было, скорее, на заре интернета и сейчас этим можно пренебречь).
Это было бы правильно. В любом случае, лучше иметь -all на всех доменах второго уровня, которые не используются. На них в последствии могут «повесить» A-записи.
у домена нет MX — fallback на A. Поэтому оно вообще было доставлено. Gmail с довольно странными политиками, где-то сверх жесткими и не по RFC, а где-то довольно мягкими. Но реальный спам вы им всё равно не доставите :)
Реальный спам больших объемов, конечно не доставить, а вот доставить точечное письмо, думаю, можно.
Если нет MX — зачем там SPF? Нужно только DMARC, который защищает от спуфинга в From:, потому что это вы не можете контролировать.
Согласен. Но, пока нет DMARC лучше иметь SPF :)
Большое спасибо за столь полезный комментарий!
FYI: если при разборе SPF требуется >10 запросов к DNS можете считать свой SPF невалидным — Gmail его признает валидным, а вот Google Apps при роутинге в группах рассылки такие письма «съедает», это реально известный мне «артефакт». Проверить можно dmarcian'ом
FYI2: DMARC это, конечно, круто, но кто его смотрит? Ответ: да почти никто! Настраивали DMARC и почти не получали отчетов.
Итого:
— сначала настройте A и PTR записи (MX иметь хорошо, но на практике совсем не обязательно, если вы не принимаете почту)
— дальше SPF (можно сделать один общий и делать include:_spf.your-domain.tld)
— если мало — DKIM
На блеклисты можно не обращать внимания (проблемы могут быть только с A&T'шным DNSBL — эти *** игнорируют любую попытку связаться, выяснить в чем дело).
FYI2: DMARC это, конечно, круто, но кто его смотрит? Ответ: да почти никто! Настраивали DMARC и почти не получали отчетов.
Итого:
— сначала настройте A и PTR записи (MX иметь хорошо, но на практике совсем не обязательно, если вы не принимаете почту)
— дальше SPF (можно сделать один общий и делать include:_spf.your-domain.tld)
— если мало — DKIM
На блеклисты можно не обращать внимания (проблемы могут быть только с A&T'шным DNSBL — эти *** игнорируют любую попытку связаться, выяснить в чем дело).
К сожалению, от статьи действительно может быть больше вреда чем пользы. Есть такие аспекты:
- На доменах с «живыми» пользователями нельзя использовать потитику -all
существуют списки рассылки и редиректоры (например перенаправления с одного ящика в другой), которые не меняют адрес в SMTP-конверте. Ваши пользователи на смогут писать пользователям на адреса-редиректоры и в списки рассылки, т.к. SPF будет биться.
Политику -all можно использовать только на «тразакционных» доменах, в которых находятся только ролевые адреса.
- Для «живых» получателей нельзя реджектить письма по результатам только SPF проверки
по тем же самым причинам — они не смогут устанавливать редиректы на свой ящик и получать письма из списков рассылки. Поэтому строго следовать результатам SPF так же можно только на «ролевых» ящиках.
По этим двум причинам ни один Mailbox Provider не устанавливает политику -all для своих доменов и не реджектит письмо только на основании SPF. Так что ваш эксперимент с письмам от microsoft на google в общем-то был ошибочен, SPF так не работает.
- При установке SPF "-all" для поддоменов скорей всего отломается хождение NDR (отчетов о доставке письма от Mailer Daemon).
Письма от Mailer Daemon (отчеты о доставке) идут с пустым MAIL FROM:. По RFC 7208 в таком случае проверяется имя из HELO сервера. Как минимум для этого имени (или имен) необходима дополнительная SPF-запись. Если вы поставите "-all" для всех поддоменов, то получите проблемы.
- DMARC это не шифрование
это политика, в которой вы можете в явном виде указать, как следует поступать с письмами от вашего домена, которые не проходят аутентификацию. Я бы настоятельно рекомендовал вам до включения "-all" в SPF вместо "~all" сделать запись DMARC для получения отчетов. По этим отчетам вы сможете понять, какое количество валидных писем вы можете потенциально потерять.
- SPF не принесет вам профита. Внедрение SPF для вашего домена не дает вам никакой пользы.
SPF никак не повлияет ни на количество входящего спама ни на возможность подделать ваш адрес.
SPF защищает только адрес конверта, который не видим получателю. Об этом выше сказали. Точно так же, сам по себе не работает DKIM. Поэтому имеет смысл использовать SPF только как один из механизмов аутентификации отправителя письма в рамках политики DMARC.
К сожалению, от статьи действительно может быть больше вреда чем пользы.
На доменах с «живыми» пользователями нельзя использовать потитику -all
В статье я не призываю устанавливать жесткий механизм Fail для «боевых доменов» (только для доменов, которыми не пользуются), я призываю обратить на это внимание. Проверьте SPF и DMARC-записи 10-и крупных компаний России и вы увидите, что об этом задумываются немногие. Хороший пример — www.nalog.ru/rn77/news/activities_fts/5771252 (ни SPF, ни DMARC нету).
Для «живых» получателей нельзя реджектить письма по результатам только SPF проверки
по тем же самым причинам — они не смогут устанавливать редиректы на свой ящик и получать письма из списков рассылки. Поэтому строго следовать результатам SPF так же можно только на «ролевых» ящиках.
Все зависит от компании и ее политик безопасности. В некоторых сферах пересылка писем с рабочего почтового ящика на персональный запрещена.
Согласен, что для реджектить такие письма не лучший вариант, но учитывать эту проверку анти-спам фильтр должен (это будет дополнительный минус балл к репутации письма).
При установке SPF "-all" для поддоменов скорей всего отломается хождение NDR (отчетов о доставке письма от Mailer Daemon).
Письма от Mailer Daemon (отчеты о доставке) идут с пустым MAIL FROM:. По RFC 7208 в таком случае проверяется имя из HELO сервера. Как минимум для этого имени (или имен) необходима дополнительная SPF-запись. Если вы поставите "-all" для всех поддоменов, то получите проблемы.
Это было учтено в статье:
SPF-записи рекомендуется создавать не только для доменов, но и для почтовых серверов, которые занимаются отправкой писем в интернет. Это необходимо, чтобы пройти HELO/EHLO Test принимающего сервера. Стандартная запись: «mx.example.com. IN TXT «v=spf1 a -all»».
DMARC это не шифрование
Так никто обратного не утверждает.
SPF никак не повлияет ни на количество входящего спама ни на возможность подделать ваш адрес.
Если говорить о защите от спама, я думаю, что это улучшит качество анализа, пусть и совсем немного. При том, я советую включать проверку и SPF и DKIM и DMARC.
Если говорить о подделке домена, то согласен, решать проблему нужно комплексно, но начать можно SPF :)
Спасибо полезный за комментарий!
Проблема с DMARC еще в том, что это совершенно отвратительно работает со списками рассылки. Цитата из FAQ по DMARC:
А из реально «жестких» примеров я видел paypal.com и amazon.com, причем первый ставит вообще reject.
Is there special handling required to receive DMARC email from mailing lists?
Mailing lists usually do not take authorship of the emails they relay. It means the From: header in the email will not contain the domain name of the mailing list, and if the mailing list add DKIM to all its emails, DKIM d= will not match. If the domain in the From: header is from an organization that publishes a DMARC record, the email is likely to not be delivered. If emails from mailing lists are important to your users, you may therefore consider to apply specific rules for emails coming from mailing lists. These rules can be assimilated to a sort of whitelist, but you need to be careful, as to not allow others to exploit these rules. You could take benefit of the «Original Authentication Results» header of mailing lists that support this feature.
А из реально «жестких» примеров я видел paypal.com и amazon.com, причем первый ставит вообще reject.
$ dig +short _dmarc.paypal.com txt
"v=DMARC1\; p=reject\; rua=mailto:d@rua.agari.com\; ruf=mailto:dk@bounce.paypal.com,mailto:d@ruf.agari.com"
$ dig +short _dmarc.amazon.com txt
"v=DMARC1\; p=quarantine\; pct=100\; rua=mailto:dmarc-reports@bounces.amazon.com\; ruf=mailto:dmarc-reports@bounces.amazon.com"
Yahoo (3й в мире по количеству активных пользователей почтовый сервис) и AOL (5й в мире) используют p=reject уже достаточно давно.
То есть получается, что пользователи не могут настроить себе редирект на другой ящик и участвовать в подавляющем большинстве рассылок? Как они живут вообще тогда, интересно.
Редиректы будут работать, т.к. редиректы не меняют заголовков письма и не бьют DKIM-подпись (исключения были, например до недавнего времени Рамблер менял To:). Так же нормально будут работать списки рассылки, которые не меняют содержимое, тему письма и другие подписанные заголовки. Крупные списки рассылки, например Google Groups уже ведут себя корректно по отношению к DMARC, и в From: подставляют свой адрес при изменении содержимого писем, а не адрес оригинального отправителя и переподписывают письмо своим DKIM.
Вообще строгий DMARC будут вводить все крупные провайдеры, и довольно скоро, так что владельцам списков рассылки уже надо быть к этому готовыми.
Вообще строгий DMARC будут вводить все крупные провайдеры, и довольно скоро, так что владельцам списков рассылки уже надо быть к этому готовыми.
а какие планы у mail.ru?
p=reject используется пока только на технологических и рассылочных доменах, технически мы уже готовы к ее включению на доменах с ящиками пользователей, но необходима предварительная работа с community чтобы избежать потенциального «шока» от включения, чем мы и планируем заняться.
Прямо сейчас мы не просто поддерживаем DMARC, но и начинаем показывать уведомления на тех письмах, которые пока проходят проверку из-за p=none, но могут попасть под более строгие фильтры в будущем. Это должно сподвигнуть администраторов почтовых серверов и рассылок исправить потенциальные проблемы. Когда закончим внедрение этой фичи напишем статью о том, как все это работает и какие планы на ближайшее будущее.
Прямо сейчас мы не просто поддерживаем DMARC, но и начинаем показывать уведомления на тех письмах, которые пока проходят проверку из-за p=none, но могут попасть под более строгие фильтры в будущем. Это должно сподвигнуть администраторов почтовых серверов и рассылок исправить потенциальные проблемы. Когда закончим внедрение этой фичи напишем статью о том, как все это работает и какие планы на ближайшее будущее.
Проясните следующее:
Я настроил у себя p=none, получаю отчеты от разных провайдеров со сводной статистикой.
Кто-то (из пользователей) настроил у себя отправку писем с from: мой-домен.tld, при этом письмо не проходит через мои сервера и теоретически дропнется в DMARC.
Вроде как есть этот отчет, но если серьезно, то на мой взгляд, он бесполезный. Я вижу только IP последнего received и временной промежуток. Нет ни оригинального From: или To:, нет темы, нет message-id. Ничего.
Что я должен делать с этими отчетами? У меня есть только информация, что письмо прошло не через мои сервера (факт получения отчета) и IP (например, какой-то IP из пула DSL в США). Я не могу узнать даже пользователя, который отправлял письмо. Что делать дальше?
1) внедрить p=reject и тупо потерять множество писем?
2) добавить этот неизвестный IP в +ip4:x.x.x.x в DNS?
3) не внедрять DMARC вообще? Какой тогда смысл.
Я настроил у себя p=none, получаю отчеты от разных провайдеров со сводной статистикой.
Кто-то (из пользователей) настроил у себя отправку писем с from: мой-домен.tld, при этом письмо не проходит через мои сервера и теоретически дропнется в DMARC.
Вроде как есть этот отчет, но если серьезно, то на мой взгляд, он бесполезный. Я вижу только IP последнего received и временной промежуток. Нет ни оригинального From: или To:, нет темы, нет message-id. Ничего.
Что я должен делать с этими отчетами? У меня есть только информация, что письмо прошло не через мои сервера (факт получения отчета) и IP (например, какой-то IP из пула DSL в США). Я не могу узнать даже пользователя, который отправлял письмо. Что делать дальше?
1) внедрить p=reject и тупо потерять множество писем?
2) добавить этот неизвестный IP в +ip4:x.x.x.x в DNS?
3) не внедрять DMARC вообще? Какой тогда смысл.
На самом деле смысла много, даже с p=none, просто проблемы надо решать, если они появляются. И способов много:
Во-первых использовать на постороннем сервере ваш домен без вашего ведома — в общем-то это именно то, с чем борется DMARC. Поэтому я и пишу, что в первую очередь, надо работать с community, чтобы сообщество понимало, что так делать не надо.
Во-вторых, имея IP адрес, вы почти всегда можете отследить всю необходимую информацию по собственным логам (если кто-то настроил отправку с вашего домена и не шлет на ваши адреса — это немного странно). Настроить у себя проверку DMARC не сложно, помимо «референсного» OpenDMARC могу порекомендовать еще очень неплохой, хотя и малоизвестный проект yenma.
В-третьих, в DMARC кроме аггрегированных отчетов есть еще forensic (включаются через fo= и ruf= в _dmarc-записи), правда большая часть мейлбокс-провайдеров пока не шлет форенсик-отчеты из соображений безопасности. Ситуация может измениться, когда DMARC будет окончательно принят как стандарт. Сейчас из крупных сервисов forensic-отчеты шлют Microsoft и Linkedin. Forensic-отчет включает в себя практически полный набор заголовков, а иногда и текст письма.
В-четвертых, mail.ru на таких письмах будет показывать предупреждение о возможной подмене отправителя. А mail.ru это примерно половина всех русскоязычных получателей и это лишний повод для «Кто-то (из пользователей)» так не делать.
В-пятых, на уровне крупных организаций, можно воспользоваться услугами специализирующихся на безопасности и доставляемости электронной почты компаний, таких как ReturnPath и Agari. Последняя практически полностью специализируется на DMARC. Они «умеют» получать forensic-информацию даже от тех провайдеров, которые не дадут ее вам напрямую.
Во-первых использовать на постороннем сервере ваш домен без вашего ведома — в общем-то это именно то, с чем борется DMARC. Поэтому я и пишу, что в первую очередь, надо работать с community, чтобы сообщество понимало, что так делать не надо.
Во-вторых, имея IP адрес, вы почти всегда можете отследить всю необходимую информацию по собственным логам (если кто-то настроил отправку с вашего домена и не шлет на ваши адреса — это немного странно). Настроить у себя проверку DMARC не сложно, помимо «референсного» OpenDMARC могу порекомендовать еще очень неплохой, хотя и малоизвестный проект yenma.
В-третьих, в DMARC кроме аггрегированных отчетов есть еще forensic (включаются через fo= и ruf= в _dmarc-записи), правда большая часть мейлбокс-провайдеров пока не шлет форенсик-отчеты из соображений безопасности. Ситуация может измениться, когда DMARC будет окончательно принят как стандарт. Сейчас из крупных сервисов forensic-отчеты шлют Microsoft и Linkedin. Forensic-отчет включает в себя практически полный набор заголовков, а иногда и текст письма.
В-четвертых, mail.ru на таких письмах будет показывать предупреждение о возможной подмене отправителя. А mail.ru это примерно половина всех русскоязычных получателей и это лишний повод для «Кто-то (из пользователей)» так не делать.
В-пятых, на уровне крупных организаций, можно воспользоваться услугами специализирующихся на безопасности и доставляемости электронной почты компаний, таких как ReturnPath и Agari. Последняя практически полностью специализируется на DMARC. Они «умеют» получать forensic-информацию даже от тех провайдеров, которые не дадут ее вам напрямую.
Реальный кейс:
1) Есть мой домен example.com, я настроил p=quarantine (понаблюдать).
2) Есть домен партнера partner.com, у них есть список рассылки вида group123@partner.com, в который входят получатели user1@example.com, user2@example.com
3) Мой пользователь user3@example.com шлет на group123@partner.com, в результате user1 и user2 получают это письмо помарканое как спам, потому что From: указан как example.com, а IP в SPF не из моих блоков.
4) В результате, если был бы p=reject, то письмо пропало бы вовсе.
На партнера повлиять нельзя (в плане настройки его серверов).
Замкнутый круг =(
1) Есть мой домен example.com, я настроил p=quarantine (понаблюдать).
2) Есть домен партнера partner.com, у них есть список рассылки вида group123@partner.com, в который входят получатели user1@example.com, user2@example.com
3) Мой пользователь user3@example.com шлет на group123@partner.com, в результате user1 и user2 получают это письмо помарканое как спам, потому что From: указан как example.com, а IP в SPF не из моих блоков.
4) В результате, если был бы p=reject, то письмо пропало бы вовсе.
На партнера повлиять нельзя (в плане настройки его серверов).
Замкнутый круг =(
Некропост дедектед.
Ссылка на сайт проекта не http://www.openspf.org/ а http://www.open-spf.org/
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Значимость SPF