В записи Office365 SPF слишком много поисков

По некоторым нелепым административным причинам у нас есть разделенный домен с одним почтовым ящиком на Office365, который требует от нас добавления include:outlook.comв нашу запись SPF. Проблема заключается в том, что для этого правила требуется девять поисков DNS из максимум 10.

Серьезно, это ужасно. Просто посмотрите на это:

v=spf1
include:spf-a.outlook.com
include:spf-b.outlook.com
ip4:157.55.9.128/25
include:spfa.bigfish.com
include:spfb.bigfish.com
include:spfc.bigfish.com
include:spf-a.hotmail.com
include:_spf-ssg-b.microsoft.com
include:_spf-ssg-c.microsoft.com
~all

Учитывая , что у нас есть собственная большой иш почтовой системы мы должны иметь правила a, mx, include:_spf1.mydomain.comи include:_spf2.mydomain.comкоторый ставит нас в 13 DNS - запросах , которые вызывают PERMERRORы со строгими SPF валидаторами, и полностью недостоверной / непредсказуемый проверкой с нестрогими / плохо реализованными валидаторами ,

Можно ли как-то исключить 3 из этих include:правил из раздутой записи outlook.com, но все же охватывать серверы, используемые O365?

Редактировать:

Комментаторы отметили, что мы должны просто использовать более короткую spf.protection.outlook.comзапись. Несмотря на то , что это новость для меня, и это короче, это только одна запись короче:

spf.protection.outlook.com
  include:spf-a.outlook.com
  include:spf-b.outlook.com
  include:spf-c.outlook.com
  include:spf.messaging.microsoft.com
    include:spfa.frontbridge.com
    include:spfb.frontbridge.com
    include:spfc.frontbridge.com

Edit²

Я полагаю, что мы можем технически сократить это до:

v=spf1 a mx include:_spf1.mydomain.com include:_spf2.mydomain.com include:spf-a.outlook.com include:spf-b.outlook.com include:spf-c.outlook.com include:spfa.frontbridge.com include:spfb.frontbridge.com include:spfc.frontbridge.com ~all

но потенциальные проблемы, которые я вижу с этим:

Мы должны быть в курсе любых изменений в родительском spf.protection.outlook.comи spf.messaging.microsoft.comзаписи. Если что-то будет изменено или добавлено [не дай бог], нам придется вручную обновить наш, чтобы отразить это.
С нашим фактическим доменным именем длина записи составляет 260 символов, что потребует 2 строки для записи TXT, и я, честно говоря, не верю, что все DNS-клиенты и распознаватели SPF там правильно примут запись TXT длиннее 255 байт. ,

email spf microsoft-office-365

— Sammitch
источник

Не можете ли вы просто добавить spf.protection.outlook.com для всего Office365? technet.microsoft.com/en-us/library/hh852557.aspx

— Холодная T

Почему запись SPF для O365 не является простой текущей? include:spf.protection.outlook.com (любопытно, если честно, никогда не видел, что вы настроили ... портал сказал вам, чтобы вы все это поместили?)

— TheCleaner

Вся документация, которую я нашел, сказала, чтобы использовать include:outlook.com, так spf.protection.outlook.comновость для меня. Проблема остается, так как эта запись все еще требует 8 поисков, и мне нужно уменьшить ее до 6 или ниже.

— Саммит

Не забудьте сосчитать два поиска PTR в «spfa.frontbridge.com». Согласно RFC 7208 они также учитывают ограничение до 10 просмотров. :(

— Мартейн Химельс

Ответы:

С недавнего времени Microsoft «исправила» эту проблему, избавившись от всех вложенных записей и использовав вместо этого 2 или 3 записи «ptr»:

$ dig TXT spf.protection.outlook.com
spf.protection.outlook.com. IN  TXT "v=spf1 ptr:protection.outlook.com ptr:o365filtering.com -all"

$ dig TXT spf.messaging.microsoft.com
spf.messaging.microsoft.com. IN TXT "v=spf1 ptr:protection.outlook.com ptr:messaging.microsoft.com ptr:o365filtering.com -all"

Вот в чем проблема: хотя это поможет клиентам Office 365 избегать удержания ниже PermError «Слишком много поисков» ... это делает это, заставляя каждый почтовый сервер в мире выполнять (дорогой) поиск PTR для каждого подключенного к ним IP-адреса.

Согласно спецификации SPF :

Если это вообще возможно, вам следует избегать использования этого механизма в своей записи SPF, поскольку это приведет к большему количеству дорогостоящих поисков DNS.

— Джон Харт
источник

@ChrisS - я тоже об этом думал, однако в спецификации SPF говорится, что механизм «ptr:» должен проверяться обоими способами для взаимного DNS - принимающий почтовый сервер должен сначала выполнить PTR на IP, а затем выполнить A на Полученное имя хоста и IP-адрес должны быть указаны в записи А. Поэтому я не думаю, что это дыра в безопасности, по крайней мере, не для соответствия реализации SPF.

— Джон Харт

Ах, хорошая находка там. Я не знал об этой оговорке.

— Крис С

Мы также нашли эту проблему. Microsoft «рекомендует» использовать Office 365 исключительно для электронной почты, поскольку сейчас нет места для добавления новых элементов.

То, как мы обошли это, было двояким.

Во-первых, мы можем сократить поиск DNS, добавив другие записи как явные записи IPv4. Это позволяет нам добавить несколько явных IP-адресов, прежде чем мыinclude:outlook.com

Во-вторых, мы создали отдельный поддомен в нашем основном домене для Office 365. Таким образом, электронные письма @ foo.company.com получают SPF Office 365, а электронные письма @ comapny.com получают наш обычный SPF. Это не идеально, но, к счастью, все места, где мы использовали Office 365, могут использовать адреса электронной почты в поддомене, а не в базовом домене.

— Стив Шипвей
источник