Penanganan untuk batas maksimum syarat DNS-Interaktif terlampaui dalam catatan SPF?

Sebagai penyedia hosting, kami mengirim email atas nama klien kami, jadi kami membantu mereka mengatur catatan email DKIM dan SPF dalam DNS mereka untuk mendapatkan pengiriman email yang tepat. Kami telah menyarankan mereka untuk menggunakan http://mail-tester.com untuk menguji bahwa mereka tidak melewatkan apa pun, dan saya sangat menyukai alat ini.

Satu masalah yang kami alami beberapa kali, dan saya tidak yakin, adalah "batas" DNS pada catatan SPF berdasarkan nama domain. Jadi, jika Anda memiliki ini:

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

Anda akan mendapatkannya

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

Seperti itu:

Saya punya beberapa pertanyaan tentang ini.

1. Saya menghitung enam nama domain di sini, bukan 10, jadi mengapa itu memukul "sepuluh" permintaan DNS di sini? Dijawab di sini

2. Apakah 10 istilah interaktif DNS ini membatasi peringatan atau kesalahan nyata ? misalnya apakah kita harus peduli? Ini sedikit mengganggu pelanggan kami dan mereka mengirim email kepada kami untuk dukungan. Dijawab di sini

3. Apakah batas istilah interaktif 10 DNS ini merupakan masalah nyata di web saat ini? Seperti yang Anda lihat, pelanggan ini memiliki banyak layanan mengirim email untuk mereka dan mereka semua sah. Mungkin batas DNS ini ditetapkan pada tahun 2000 ketika mendelegasikan layanan email seperti ini tidak umum?

Ya, kami dapat meminta pelanggan mengubah cantuman ke IP dalam catatan SPF tapi itu membuat kami terikat jika kami pernah mengubah IP, banyak barang pelanggan akan pecah. Benar-benar tidak ingin melakukan itu ..

Penanganan apa yang ada untuk ini?

1. Sebagian besar sudah dijawab, harap dicatat bahwa Google dengan cara ini salah - Anda ingin menggunakan _spf.google.comatau dikenakan penalti untuk pengalihan:

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

Pencarian itu akan mengkonsumsi 5/10 semuanya sendiri - 4/10 masih menyebalkan tetapi 20% lebih sedikit.

2. Ini akan berhenti memproses dan mengembalikan kesalahan permanen - terserah mesin menggunakan SPF untuk memutuskan bagaimana ia ingin memperlakukan kesalahan permanen.

3. Ya - tanpa batas pemrosesan, mekanisme SPF dapat digunakan sebagai penguat DoS terhadap pihak ketiga atau pihak kedua.

Sebagai solusinya, email dapat berasal dari subdomain dari properti utama - community.largecorporation.commisalnya.

1. Dengan asumsi bahwa redundansi (seperti beberapa referensi _spf.google.comdan catatan yang merujuknya) hanya dihitung satu kali, saya menghitung 17 pencarian dari titik di mana Anda sudah melihat catatan awal. (Lihat di bawah.)

2. Itu menolak untuk mencari semua catatan yang diperlukan untuk mengevaluasi catatan SPF Anda karena itu akan "terlalu banyak bekerja". Agaknya ini berarti akan memperlakukan domain Anda seolah-olah tidak memiliki catatan SPF (atau mungkin menolaknya). Spesifikasi mengatakan bahwa ini menghasilkan permerror , yang membuatnya cukup terbuka bagi penerima untuk memutuskan apa yang harus dilakukan .

3. Saya pikir pelecehan telah naik daripada turun, secara umum. Batas ini tampaknya dimaksudkan untuk menggagalkan domain pengirim yang kasar yang mungkin dapat membanjiri penerima dengan rantai SPF yang sangat besar, yang berpotensi mengarah ke DoS.

Saya pikir walaupun outsourcing email adalah hal biasa, sebenarnya tidak umum untuk melakukan outsourcing email ke enam penyedia berbeda. Anda harus mengoptimalkan catatan SPF entah bagaimana.
(Untuk satu hal, referensi untuk aspmx.googlemail.comtampak boros karena itu langsung dialihkan ke nama yang berbeda.)

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

Karena jawaban yang diterima untuk salah satu pertanyaan terkait memperjelas, banyak alat yang mendasari untuk sistem UNIX memang memberlakukan batas ini (meskipun tidak semua dengan cara yang persis sama) sehingga setiap implementasi SPF yang menggunakannya - yang hampir semuanya ada di UNIX - akan menegakkan batasan itu juga. Sistem Windows adalah hukum bagi diri mereka sendiri, dan saya tidak bisa menjelaskannya.

Solusinya adalah memiliki pekerjaan cron yang mengevaluasi rantai catatan SPF Anda yang di-outsourcing-kan, menyatakan semuanya sebagai ipv4 dan ipv6 netblock, dan membuatnya menjadi catatan Anda. Jangan lupakan-all .

Dalam kasus Anda, Anda ingin pelanggan dapat mempublikasikan catatan SPF yang kemudian tidak perlu mereka pertahankan. Salah satu kemungkinan adalah meminta setiap pelanggan menerbitkan catatan yang berisi redirect=spf.client1.jeffs-company.example, dan Anda kemudian melakukan kerja keras untuk mempertahankan daftar netblock dijeffs-company.example .

Mungkin batas DNS ini ditetapkan pada tahun 2000 ketika mendelegasikan layanan email seperti ini tidak umum?

Batasnya memang membuat sulit untuk melakukan outsourcing email ke enam atau tujuh operasi besar; tetapi bisa dibilang jika Anda melakukan itu Anda memiliki untuk semua tujuan praktis kehilangan kendali atas email Anda pula.

Di suatu tempat, suatu hari nanti, beberapa programmer sub-subkontrak yang keberadaannya Anda benar-benar tidak sadar dan siapa yang Anda tidak memiliki kontrol akan salah menempatkan koma, dan satu ton email palsu akan dikirim dengan imprimatur SPF Anda tepat di atasnya. Kontrol penuh atas email Anda memerlukan kontrol penuh atas infrastruktur email Anda, dan itu menurut saya sepenuhnya tidak konsisten dengan banyak outsourcing.

Cara lain untuk mengatasi masalah tersebut adalah dengan melihat perangkat lunak mana yang digunakan untuk memeriksa pengaturan SPF. Dalam kasus saya ini cluebringer / PolicyD, yang digunakan Mail::SPF::Serverpada akhirnya dan yang menerima argumen yang meringankan batasan yang sulit dikodekan. Masalahnya adalah cluebringer itu sendiri tidak mendukung argumen-argumen tersebut saat ini , tetapi itu mungkin akan berubah di masa depan dan orang mungkin dapat dengan mudah memberi tahu penyedia layanan penerima tentang kemungkinan-kemungkinan untuk mengendurkan pengaturan mereka.

Jika mereka memutuskan untuk melakukannya tentu saja di luar kendali orang, tetapi setidaknya itu kesempatan.