วิธีแก้ปัญหาสำหรับข้อ จำกัด ของข้อกำหนด 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

ชอบมาก

ฉันมีคำถามบางอย่างเกี่ยวกับเรื่องนี้

1. ฉันนับชื่อโดเมนหกชื่อที่นี่ไม่ใช่ 10 ดังนั้นทำไมจึงกดปุ่ม DNS "สิบ" ที่นี่ ตอบที่นี่

2. นี่คือ 10 DNS แบบโต้ตอบคำ จำกัด การเตือนหรือข้อผิดพลาดจริงหรือไม่? เช่นเราควรดูแล มันจู้จี้ลูกค้าของเราเล็กน้อยและพวกเขาส่งอีเมลถึงเราเพื่อขอความช่วยเหลือ ตอบที่นี่

3. นี่คือ 10 DNS แบบโต้ตอบคำ จำกัด ปัญหาที่แท้จริงในเว็บของวันนี้? อย่างที่คุณเห็นลูกค้ารายนี้มีบริการมากมายที่ส่งอีเมลถึงพวกเขาและพวกเขาทั้งหมดถูกต้องตามกฎหมาย บางทีข้อ จำกัด DNS นี้ถูกตั้งค่าในปี 2000 เมื่อมอบหมายบริการอีเมลเช่นนี้ไม่ธรรมดา

ใช่เราสามารถให้ลูกค้าของเราเปลี่ยนการรวมเป็น IP ในบันทึก SPF ได้แต่นั่นทำให้เราต้องผูกมัดหากเราเปลี่ยน IPs สิ่งที่ลูกค้าจำนวนมากจะแตกสลาย ไม่อยากทำอย่างนั้นจริงๆ

มีวิธีแก้ปัญหาอะไรสำหรับสิ่งนี้

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 netblocks และทำให้มันกลายเป็นบันทึกของคุณ อย่าลืม-all

ในกรณีของคุณคุณต้องการให้ลูกค้าสามารถเผยแพร่ระเบียน SPF ซึ่งลูกค้าไม่จำเป็นต้องบำรุงรักษา หนึ่งเป็นไปได้จะมีลูกค้าแต่ละเผยแพร่บันทึกที่มีredirect=spf.client1.jeffs-company.exampleและคุณแล้วทำ legwork ของการรักษารายการ netblocks jeffs-company.exampleที่ที่

บางทีข้อ จำกัด DNS นี้ถูกตั้งค่าในปี 2000 เมื่อมอบหมายบริการอีเมลเช่นนี้ไม่ธรรมดา

ขีด จำกัด ทำให้ยากที่จะ outsource อีเมลของคุณไปยังการดำเนินงานขนาดใหญ่หกหรือเจ็ดครั้ง แต่เนื้อหาถ้าคุณทำอย่างนั้นคุณมีเพื่อการปฏิบัติทั้งหมดจะสูญเสียการควบคุมอีเมลของคุณอยู่แล้ว

สักวันหนึ่งโปรแกรมเมอร์ย่อยที่มีอยู่ซึ่งคุณไม่รู้จักอย่างสมบูรณ์และผู้ที่คุณไม่สามารถควบคุมได้จะใส่เครื่องหมายอัฒภาคในทางที่ผิดและอีเมลปลอมจำนวนหนึ่งจะถูกส่งไปพร้อมกับค่า SPF ที่แน่นอนของคุณ การควบคุมอีเมลของคุณอย่างสมบูรณ์นั้นจำเป็นต้องมีการควบคุมโครงสร้างพื้นฐานอีเมลของคุณอย่างเต็มที่และในความคิดของฉันนั้นไม่สอดคล้องกับการเอาท์ซอร์สมาก

อีกวิธีหนึ่งในการแก้ไขปัญหาเหล่านี้คือการดูว่าซอฟต์แวร์ชนิดใดที่ใช้ตรวจสอบการตั้งค่า SPF ในกรณีของฉันมัน cluebringer / PolicyD ซึ่งใช้Mail::SPF::Serverในตอนท้ายและยอมรับข้อโต้แย้งที่ผ่อนคลายข้อ จำกัด ฮาร์ดโค้ด ปัญหาคือว่า cluebringer เองไม่สนับสนุนการผ่อนคลายข้อโต้แย้งเหล่านั้นในปัจจุบันแต่มันอาจจะเปลี่ยนไปในอนาคต

หากพวกเขาตัดสินใจที่จะทำเช่นนั้นแน่นอนว่าอยู่นอกเหนือการควบคุมของคน แต่อย่างน้อยก็มีโอกาส