¿Se han superado las soluciones para el límite máximo de términos interactivos de DNS en el registro SPF?

Como proveedor de alojamiento, enviamos correos electrónicos en nombre de nuestros clientes, por lo que les ayudamos a configurar los registros de correo electrónico DKIM y SPF en su DNS para obtener la capacidad de entrega del correo electrónico a la perfección. Les hemos aconsejado que usen http://mail-tester.com para probar que no se perdieron nada, y me gusta mucho esta herramienta.

Un problema con el que nos hemos encontrado varias veces, y no estoy seguro, es el "límite" de DNS en el registro SPF basado en el nombre de dominio. Entonces, si tienes esto:

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

Obtendrás

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

Al igual que:

Tengo algunas preguntas sobre esto.

1. Cuento seis nombres de dominio aquí, no 10, entonces, ¿por qué afecta a "diez" solicitudes de DNS aquí? Respondido aquí

2. ¿Este término interactivo de 10 DNS limita una advertencia o un error real ? por ejemplo, ¿debería importarnos? Está molestando un poco a nuestros clientes y nos envían un correo electrónico para solicitar asistencia. Respondido aquí

3. ¿Es este límite de término interactivo de 10 DNS un problema real en la web de hoy? Como puede ver, este cliente tiene muchos servicios que le envían correos electrónicos y todos son legítimos. ¿Quizás este límite de DNS se estableció en el año 2000 cuando delegar servicios de correo electrónico como este no era común?

Sí, podemos hacer que nuestros clientes cambien la inclusión a las IP en el registro SPF, pero eso nos pone en apuros si alguna vez cambiamos las IP, un montón de cosas de clientes se romperán. Realmente no quiero hacer eso ...

¿Qué soluciones hay para esto?

1. En la mayoría de los casos ya respondió, tenga en cuenta que incluir Google de esta manera es incorrecto : desea usar _spf.google.como incurrir en una penalización por la redirección:

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

Esa búsqueda consumirá 5/10 por sí sola: 4/10 todavía apesta, pero un 20% menos.

2. Se dejará de procesar y devolver un error permanente - le toca al motor mediante el SPF para decidir cómo se quiere tratar a un error permanente.

3. Sí, sin los límites de procesamiento, los mecanismos SPF podrían usarse como un amplificador DoS contra un tercero o un tercero.

Como solución alternativa, los correos electrónicos pueden provenir de un subdominio de la propiedad principal, community.largecorporation.compor ejemplo.

1. Suponiendo que las redundancias (como las referencias múltiples _spf.google.comy los registros a los que se refiere) solo se cuentan una vez, cuento 17 búsquedas desde el punto donde ya buscó el registro inicial. (Vea abajo.)

2. Se niega a buscar todos los registros necesarios para evaluar su registro SPF porque sería "demasiado trabajo". Presumiblemente, esto significa que tratará su dominio como si no tuviera registro SPF (o posiblemente lo rechace). La especificación dice que esto resulta en permerror , lo que lo deja bastante abierto para que el destinatario decida qué hacer .

3. Creo que el abuso ha aumentado en lugar de disminuir, en general. Este límite parece estar destinado a frustrar dominios de remitentes abusivos que de otro modo podrían abrumar al receptor con enormes cadenas de SPF, lo que podría conducir a DoS.

Creo que si bien la externalización del correo electrónico es común, en realidad no es tan común externalizar el correo electrónico a seis proveedores diferentes. Tendrá que optimizar el registro SPF de alguna manera.
(Por un lado, la referencia a aspmx.googlemail.comparece un desperdicio ya que inmediatamente solo redirige a un nombre diferente).

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

Como la respuesta aceptada a una de las cuestiones vinculadas deja claro, muchas de las herramientas fundamentales para sistemas UNIX en efecto, hacer cumplir este límite (aunque no todos exactamente de la misma manera) por lo que cualquier aplicación SPF que los utiliza - que es casi todo en UNIX - hará cumplir estos límites también. Sistemas Windows son ley para sí mismos, y no pueden arrojar alguna luz sobre ellos.

La solución es tener una tarea programada que evalúa su cadena de registros SPF externalizados, todos ellos expresa como bloques de red IPv4 e IPv6, y las marcas que en su registro. No olvide el -all.

En su caso, desea que los clientes puedan publicar un registro SPF que luego no necesitan mantener. Una posibilidad sería que cada cliente publique un registro que contenga redirect=spf.client1.jeffs-company.example, y luego haga el trabajo preliminar de mantener la lista de bloques de red en jeffs-company.example.

¿Quizás este límite de DNS se estableció en el año 2000 cuando delegar servicios de correo electrónico como este no era común?

El límite dificulta la externalización de su correo electrónico a seis o siete operaciones grandes; pero podría decirse que si está haciendo eso, a todos los efectos prácticos ha perdido el control de su correo electrónico de todos modos.

En algún lugar, algún día, algún programador subcontratado de cuya existencia desconocías por completo y sobre el que no tienes control perderá un punto y coma, y ​​se enviará una tonelada de correos electrónicos falsos con tu imprimatur SPF directamente sobre él. El control total de su correo electrónico requiere un control total de su infraestructura de correo electrónico, y eso es, en mi opinión, totalmente inconsistente con tanta externalización.

Otra forma de solucionar esos problemas es observar qué software se usa exactamente para verificar la configuración de SPF. En mi caso, es cluebringer / PolicyD, que se usa Mail::SPF::Serveral final y que acepta argumentos que relajan los límites codificados de otra manera. El problema es que Cluebringer en sí mismo no admite relajar esos argumentos actualmente , pero eso podría cambiar en el futuro y uno podría simplemente decirle a los proveedores de servicios receptores acerca de esas posibilidades para relajar sus configuraciones.

Si deciden hacerlo, por supuesto, está fuera de control, pero al menos es una posibilidad.