Solutions de contournement pour la limite maximale de termes DNS-Interactive dépassée dans l'enregistrement SPF?

En tant que fournisseur d'hébergement, nous envoyons des e-mails au nom de nos clients, nous les aidons donc à configurer les enregistrements de messagerie DKIM et SPF dans leur DNS pour obtenir la délivrabilité des e-mails. Nous leur avons conseillé d'utiliser http://mail-tester.com pour tester qu'ils n'ont rien manqué, et j'aime beaucoup cet outil.

Un problème que nous avons rencontré plusieurs fois, et je n'en suis pas sûr, est la "limite" DNS sur l'enregistrement SPF basé sur le nom de domaine. Donc, si vous avez ceci:

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

Tu auras

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

Ainsi:

J'ai quelques questions à ce sujet.

1. Je compte six noms de domaine ici, pas 10, alors pourquoi est-ce qu'il y a "dix" requêtes DNS ici? Répondu ici

2. Ce terme interactif de 10 DNS limite-t-il un avertissement ou une véritable erreur? Par exemple, devrions-nous nous en soucier? Cela harcèle un peu nos clients et ils nous envoient un e-mail pour obtenir de l'aide. Répondu ici

3. Cette limite de 10 termes interactifs DNS est-elle un vrai problème sur le Web d'aujourd'hui? Comme vous pouvez le voir, ce client dispose de nombreux services d'envoi d'e-mails pour eux et ils sont tous légitimes. Peut-être que cette limite DNS a été fixée en 2000 lorsque la délégation de services de messagerie comme celui-ci n'était pas courante?

Oui, nous pouvons faire en sorte que nos clients modifient l'inclusion en IP dans l'enregistrement SPF, mais cela nous met dans une impasse si nous changeons un IP, un tas de trucs des clients se briseront. Je ne veux vraiment pas faire ça ..

Quelles sont les solutions de contournement pour cela?

1. Surtout déjà répondu, veuillez noter que l'inclusion de Google de cette façon est incorrecte - vous souhaitez utiliser _spf.google.comou encourir une pénalité pour la redirection:

   ○ → 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"
   

Cette recherche consommera 5/10 à elle seule - 4/10 est toujours nul, mais 20% de moins.

2. Il arrêtera le traitement et retournera une erreur permanente - c'est au moteur qui utilise le SPF de décider comment il veut traiter une erreur permanente.

3. Oui - sans les limites de traitement, les mécanismes SPF pourraient être utilisés comme amplificateur DoS contre un tiers ou un tiers.

Pour contourner ce problème, les e-mails peuvent provenir d'un sous-domaine de la propriété principale, community.largecorporation.compar exemple.

1. En supposant que les redondances (comme les références multiples _spf.google.comet les enregistrements auxquels il se réfère) ne sont comptées qu'une seule fois, je compte 17 recherches à partir du moment où vous avez déjà recherché l'enregistrement initial. (Voir ci-dessous.)

2. Il refuse de rechercher tous les enregistrements nécessaires pour évaluer votre enregistrement SPF car ce serait "trop ​​de travail". Vraisemblablement, cela signifie qu'il traitera votre domaine comme s'il n'avait pas d'enregistrement SPF (ou éventuellement le rejeterait). La spécification dit que cela se traduit par un permerror , ce qui laisse assez de latitude au destinataire pour décider quoi faire .

3. Je pense que la violence a augmenté plutôt que diminué, en général. Cette limite semble être censée contrecarrer les domaines d'expéditeur abusifs qui pourraient autrement submerger le destinataire avec d'énormes chaînes de SPF, pouvant conduire à DoS.

Je pense que même si l'externalisation de la messagerie électronique est courante, il n'est pas si courant d'externaliser la messagerie électronique vers six fournisseurs différents. Vous devrez en quelque sorte optimiser l'enregistrement SPF.
(D'une part, la référence à aspmx.googlemail.comsemble inutile car cela redirige immédiatement vers un nom différent.)

<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"

Comme la réponse acceptée à l'une des questions liées le montre clairement, de nombreux outils sous-jacents pour les systèmes UNIX appliquent effectivement cette limite (mais pas tous exactement de la même manière), donc toute implémentation SPF qui les utilise - qui est presque entièrement sous UNIX - imposera également ces limites. Les systèmes Windows sont une loi en eux-mêmes et je ne peux pas les éclairer.

La solution consiste à avoir un travail cron qui évalue votre chaîne d'enregistrements SPF externalisés, les exprime tous sous forme de netblocks ipv4 et ipv6, et en fait votre enregistrement. N'oubliez pas le -all.

Dans votre cas, vous souhaitez que les clients puissent publier un enregistrement SPF qu'ils n'ont alors pas besoin de conserver. Une possibilité serait de demander à chaque client de publier un enregistrement contenant redirect=spf.client1.jeffs-company.example, et vous effectuez ensuite les démarches nécessaires pour maintenir la liste des netblocks à jeffs-company.example.

Peut-être que cette limite DNS a été fixée en 2000 lorsque la délégation de services de messagerie comme celui-ci n'était pas courante?

La limite rend difficile l'externalisation de votre courrier électronique à six ou sept grandes opérations; mais sans doute si vous faites cela, vous avez de toute façon perdu le contrôle de votre courrier électronique.

Quelque part, un jour, un programmeur sous-traité dont vous ignoriez complètement l'existence et sur lequel vous n'avez aucun contrôle va égarer un point-virgule, et une tonne de faux e-mails seront envoyés avec votre imprimatur SPF carrément dessus. Le contrôle total de vos e-mails nécessite un contrôle total de votre infrastructure de messagerie, ce qui, à mon avis, est totalement incompatible avec une telle externalisation.

Une autre façon de contourner ces problèmes consiste à déterminer quel logiciel est utilisé exactement pour vérifier les paramètres SPF. Dans mon cas, c'est cluebringer / PolicyD, qui utilise Mail::SPF::Serverà la fin et qui accepte des arguments assouplissant des limites autrement codées en dur. Le problème est que cluebringer lui - même ne prend pas en charge le relâchement de ces arguments actuellement , mais cela pourrait changer à l'avenir et on pourrait simplement informer les fournisseurs de services récepteurs de ces possibilités de détendre leurs paramètres.

S'ils décident de le faire, c'est bien sûr hors de leur contrôle, mais c'est au moins une chance.