Обходные пути для максимального предела DNS-интерактивных терминов превышены в записи SPF?

Как провайдер хостинга, мы отправляем электронную почту от имени наших клиентов, поэтому мы помогаем им настроить записи электронной почты DKIM и SPF в их DNS, чтобы обеспечить правильную доставку электронной почты. Мы советуем им использовать http://mail-tester.com, чтобы проверить, что они ничего не пропустили, и мне очень нравится этот инструмент.

Одна проблема, с которой мы сталкивались несколько раз, и я не уверен в этом, - это ограничение DNS для записи SPF, основанное на доменном имени. Итак, если у вас есть это:

v=spf1 a include:aspmx.googlemail.com include:campaignmonitor.com include:authsmtp.com include:mail.zendesk.com include:salesforce.com include:_hostedspf.discourse.org ~all

Ты получишь

example.com ... campaignmonitor.com: Maximum DNS-interactive term limit (10) exceeded

Вот так:

У меня есть несколько вопросов по этому поводу.

1. Я насчитал здесь шесть доменных имен, а не 10, так почему же он обращается к «десяти» DNS-запросам здесь? Здесь ответили

2. Является ли этот интерактивный термин 10 DNS предел предупреждением или реальной ошибкой? например, мы должны заботиться? Это немного раздражает наших клиентов, и они обращаются к нам за поддержкой. Ответили здесь

3. Является ли это ограничение 10 интерактивных DNS реальной проблемой в современной сети? Как видите, у этого клиента есть множество служб, отправляющих ему электронную почту, и все они являются законными. Возможно, этот лимит DNS был установлен в 2000 году, когда такие почтовые сервисы не были распространены?

Да, мы можем предложить нашим клиентам изменить IP-адреса в записи SPF, но это ставит нас в тупик, если мы когда-либо изменим IP-адреса, куча клиентов сломается. На самом деле не хочу этого делать ..

Какие есть обходные пути для этого?

1. В основном уже ответили, пожалуйста, обратите внимание, в том числе Google, это неправильно - вы хотите использовать _spf.google.comили понести штраф за перенаправление:

   ○ → host -t txt aspmx.googlemail.com
   aspmx.googlemail.com descriptive text "v=spf1 redirect=_spf.google.com"
   
   ○ → host -t txt _spf.google.com
   _spf.google.com descriptive text "v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"
   

Этот поиск будет потреблять 5/10 все самостоятельно - 4/10 все еще отстой, но на 20% меньше.

2. Он остановит обработку и вернет постоянную ошибку - это зависит от двигателя, использующего SPF, чтобы решить, как он хочет обработать постоянную ошибку.

3. Да - без ограничений обработки механизмы SPF могут использоваться в качестве усилителя DoS против третьей стороны или второй стороны.

В качестве обходного пути электронные письма могут приходить с поддоменов основного свойства, community.largecorporation.comнапример.

1. Предполагая, что избыточности (например, множественные ссылки _spf.google.comи записи, на которые они ссылаются) учитываются только один раз, я считаю 17 поисков с того момента, когда вы уже искали исходную запись. (См. ниже.)

2. Он отказывается искать все записи, необходимые для оценки вашей записи SPF, потому что это будет «слишком много работы». Предположительно это означает, что он будет обрабатывать ваш домен так, как если бы у него не было записи SPF (или, возможно, отклонить его). В спецификации говорится, что это приводит к permerror , что оставляет получателя достаточно открытым, чтобы решить, что делать .

3. Я думаю, что насилие, как правило, идет вверх, а не вниз. Это ограничение, по-видимому, предназначено для того, чтобы помешать доменам-нарушителям-отправителям, которые в противном случае могут переполнить получателя огромными цепочками SPF, что может привести к DoS.

Я думаю, что, несмотря на то, что аутсорсинг электронной почты является распространенным явлением, на самом деле не так уж часто встречать электронную почту для шести различных поставщиков. Вам придется как-то оптимизировать запись SPF.
(С одной стороны, ссылка на aspmx.googlemail.comкажется бесполезной, поскольку она сразу же перенаправляет на другое имя.)

<lookup of example.com A>                   #1
$ dig aspmx.googlemail.com TXT +short       #2
"v=spf1 redirect=_spf.google.com"
$ dig _spf.google.com TXT +short            #3
"v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"
$ dig _netblocks.google.com TXT +short      #4
"v=spf1 ip4:64.18.0.0/20 ip4:64.233.160.0/19 ip4:66.102.0.0/20 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:74.125.0.0/16 ip4:173.194.0.0/16 ip4:207.126.144.0/20 ip4:209.85.128.0/17 ip4:216.58.192.0/19 ip4:216.239.32.0/19 ~all"
$ dig _netblocks2.google.com TXT +short     #5
"v=spf1 ip6:2001:4860:4000::/36 ip6:2404:6800:4000::/36 ip6:2607:f8b0:4000::/36 ip6:2800:3f0:4000::/36 ip6:2a00:1450:4000::/36 ip6:2c0f:fb50:4000::/36 ~all"
$ dig _netblocks3.google.com TXT +short     #6
"v=spf1 ~all"
$ dig campaignmonitor.com TXT +short        #7
"google-site-verification=HcHoB67Mph6vl5_x4gK5MN9YwN5gMgfZYdNmsP07tIg"
"v=spf1 mx ptr ip4:23.253.29.45/29 ip4:203.65.192.250 include:cmail1.com include:_spf.google.com include:stspg-customer.com ~all"
$ dig cmail1.com TXT +short                 #8
"google-site-verification=HSJ8sL4AxQo0YHHNk9RwDqs0p3lJPGmc1nCrSsmous8"
"mailru-verification: 95d4c6eb0645b43c"
"v=spf1 ip4:103.28.42.0/24 ip4:146.88.28.0/24 ip4:163.47.180.0/22 ip4:203.55.21.0/24 ip4:204.75.142.0/24 ~all"
$ dig stspg-customer.com TXT +short         #9
"v=spf1 ip4:166.78.68.221 ip4:166.78.69.146 ip4:23.253.182.103 ip4:192.237.159.42 ip4:192.237.159.43 ip4:167.89.46.159 ip4:167.89.64.9 ip4:167.89.65.0 ip4:167.89.65.100 ip4:167.89.65.53 -all"
$ dig authsmtp.com TXT +short               #10
"v=spf1 include:spf-a.authsmtp.com include:spf-b.authsmtp.com ~all"
"google-site-verification=skc1TleK4GylDiNZUayfvWWgqZIxmmiRj4KgXlCgB8E"
$ dig spf-a.authsmtp.com TXT +short         #11
"v=spf1 ip4:62.13.128.0/24 ip4:62.13.129.128/25 ip4:62.13.136.0/22 ip4:62.13.140.0/22 ip4:62.13.144.0/22 ip4:62.13.148.0/23 ip4:62.13.150.0/23 ip4:62.13.152.0/23 ~all"
$ dig spf-b.authsmtp.com TXT +short         #12
"v=spf1 ip4:72.52.72.32/28 ip4:64.49.192.16/29 ip4:209.61.188.242 ip4:64.49.192.24 ip4:64.49.192.25 ip4:64.49.210.64/29 ip4:64.49.210.72/30 ip4:64.49.210.76 ip4:64.49.210.77 ip4:64.49.210.78 ~all"
$ dig mail.zendesk.com TXT +short           #13
"v=spf1 ip4:192.161.144.0/20 ip4:185.12.80.0/22 ip4:96.46.150.192/27 ip4:174.137.46.0/24 ~all"
$ dig salesforce.com TXT +short             #14
"adobe-idp-site-verification=898b7dda-16a9-41b7-9b84-22350b35b562"
"MS=749862C9F42827A017A6EA2D147C7E96B3006061"
"MS=ms68630177"
"v=spf1 include:_spf.google.com include:_spfblock.salesforce.com include:_qa.salesforce.com ip4:136.146.208.16/28 ip4:136.146.210.16/28 ip4:136.146.208.240/28 ip4:136.146.210.240/28 ip4:85.222.130.224/28 ip4:136.147.62.224/28 ip4:136.147.46.224/28 mx ~all"
$ dig _spfblock.salesforce.com TXT +short   #15
"v=spf1 ip4:96.43.144.0/20 ip4:182.50.76.0/22 ip4:202.129.242.0/23 ip4:204.14.232.0/21 ip4:62.17.146.128/26 ip4:64.18.0.0/20 ip4:207.126.144.0/20 ip4:68.232.207.20 ip4:207.67.38.45 ip4:198.245.81.1 ip4:198.245.95.4/30 ip4:136.146.128.64/27  ~all"
$ dig _qa.salesforce.com TXT +short         #16
"v=spf1 ip4:199.122.122.176/28 ip4:199.122.121.112/28 ip4:199.122.122.240/28 ip4:66.231.95.0/29 ~all"
$ dig _hostedspf.discourse.org TXT +short   #17
"v=spf1 ip4:64.71.148.0/29 ip6:2001:470:1:3c2::/64 -all"

Как понятно из принятого ответа на один из связанных вопросов , многие из базовых инструментов для систем UNIX действительно применяют этот предел (хотя и не все точно так же), поэтому любая реализация SPF, которая их использует, - почти все в UNIX - будет применять эти ограничения также. Системы Windows сами по себе являются законом, и я не могу пролить на них свет.

Обходной путь должен иметь работу cron, которая оценивает вашу цепочку внешних записей SPF, выражает их все как сетевые блоки ipv4 и ipv6 и вносит это в вашу запись. Не забывать -all.

В вашем случае вы хотите, чтобы клиенты могли публиковать записи SPF, которые они не должны поддерживать. Один из вариантов - каждый клиент публикует запись, содержащую redirect=spf.client1.jeffs-company.example, а затем вы выполняете работу по поддержанию списка сетевых блоков по адресу jeffs-company.example.

Возможно, этот лимит DNS был установлен в 2000 году, когда такие почтовые сервисы не были распространены?

Ограничение затрудняет передачу вашей электронной почты на шесть или семь крупных операций; но, возможно, если вы делаете это, вы в любом случае потеряли контроль над своей электронной почтой.

Где-нибудь, однажды, какой-нибудь программист, работающий по субподряду, о существовании которого вы совершенно не знали и над которым у вас нет никакого контроля, собирается неправильно поставить точку с запятой, и тонна поддельных электронных писем будет отправлена ​​прямо с вашей подписью SPF. Полный контроль над вашей электронной почтой требует полного контроля над вашей почтовой инфраструктурой, и это, на мой взгляд, совершенно несовместимо с таким большим количеством аутсорсинга.

Другой способ обойти эти проблемы - посмотреть, какое именно программное обеспечение используется для проверки настроек SPF. В моем случае это cluebringer / PolicyD, который Mail::SPF::Serverв конце использует и принимает аргументы, ослабляющие иначе жестко заданные ограничения. Проблема в том, что сам cluebringer не поддерживает ослабление этих аргументов в настоящее время , но это может измениться в будущем, и можно будет просто сообщить принимающим поставщикам услуг об этих возможностях ослабить их настройки.

Если они решат сделать это, конечно, из-под контроля, но это по крайней мере шанс.