Обходные пути для максимального лимита условий DNS-Interactive превышены в записи 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
Вот так:
У меня есть вопросы по этому поводу.
Я насчитываю здесь шесть доменных имен, а не 10, так почему же здесь выполняется «десять» DNS-запросов?Ответил здесьЭто ограничение в 10 интерактивных терминов DNS предупреждение или настоящий ошибка? например мы должны заботиться? Это немного раздражает наших клиентов, и они пишут нам о поддержке.Ответил здесьЯвляется ли ограничение в 10 интерактивных терминов DNS реальной проблемой в современной сети? Как видите, у этого покупателя есть много сервисов, отправляющих им электронную почту, и все они являются законными. Возможно, этот лимит DNS был установлен в 2000 году, когда делегирование таких почтовых сервисов не было обычным явлением?
Да, мы можем попросить наших клиентов изменить включение IP-адресов в записи SPF но это ставит нас в тупик, если мы когда-нибудь изменим IP-адреса, множество вещей клиентов сломается. На самом деле не хочу этого делать ..
Какие есть обходные пути для этого?
Предполагая, что избыточности (например, несколько ссылок на
_spf.google.comи записи, на которые он ссылается) подсчитываются только один раз, я считаю 17 поисков с того момента, когда вы уже искали исходную запись. (Увидеть ниже.)Он отказывается искать все записи, необходимые для оценки вашей записи SPF, потому что это было бы «слишком много работы». Предположительно это означает, что он будет относиться к вашему домену так, как если бы он не имел записи SPF (или, возможно, отклонил ее). В спецификации говорится, что это приводит к пермеррор, который оставляет возможность получателю решить, что ему делать.
Я думаю, что злоупотребления в целом росли, а не падали. Это ограничение, по-видимому, предназначено для предотвращения злоупотреблений доменами отправителя, которые в противном случае могли бы перегружать получателя огромными цепочками 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"
В основном уже ответил, обратите внимание, включая 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% меньше.
Так и будет остановить обработку и вернуть постоянную ошибку - это зависит от движка, использующего SPF, чтобы решить, как он хочет обрабатывать постоянную ошибку.
Да - без ограничений на обработку SPF-механизмы могут быть используется как усилитель DoS против третьей стороны или второй стороны.
В качестве обходного пути электронные письма могут приходить из поддомена основного ресурса - community.largecorporation.com например.
Так как принятый ответ на один из связанных вопросов ясно дает понять, что многие базовые инструменты для систем 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 в конце концов, и это принимает аргументы ослабление жестко установленных ограничений. Проблема в том, что сама подсказка в настоящее время не поддерживает ослабление этих аргументов, но это может измениться в будущем, и можно будет просто сообщить принимающим поставщикам услуг об этих возможностях, чтобы ослабить их настройки.
Если они решат это сделать, это, конечно, неконтролируемо, но это, по крайней мере, шанс.