SPF kaydında maksimum DNS Etkileşimli terim sınırı için geçici çözümler aşıldı mı?

Bir barındırma sağlayıcısı olarak, müşterilerimiz adına e-posta gönderiyoruz, bu nedenle DNS'lerinde DKIM ve SPF e-posta kayıtlarını ayarlamalarına yardımcı oluyoruz. Hiçbir şeyi kaçırmadıklarını test etmek için http://mail-tester.com kullanmalarını öneriyoruz ve bu aracı çok beğendim.

Birkaç kez karşılaştığımız bir sorun ve emin değilim, etki alanı adına dayalı olarak SPF kaydındaki DNS "sınırı" dır. Eğer buna sahipseniz:

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

Alacaksınız

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

Şöyle ki:

Bununla ilgili bazı sorularım var.

1. Burada 10 değil altı alan adı sayıyorum, neden "on" DNS isteğini burada tıklıyor? Burada cevaplandı

2. Bu 10 DNS etkileşimli terimi bir uyarı mı yoksa gerçek bir hata mı? örneğin umursamalıyız? Müşterilerimizi biraz rahatsız ediyor ve destek için bize e-posta gönderiyorlar. Burada cevaplandı

3. Bu 10 DNS etkileşimli terim sınırı bugünün web'inde gerçek bir sorun mu? Gördüğünüz gibi, bu müşterinin onlar için e-posta gönderen birçok hizmeti var ve hepsi meşru. Belki de bu DNS limiti, böyle e-posta hizmetleri için temsilci seçmenin yaygın olmadığı 2000 yılında belirlendi?

Evet, müşterilerimizin SPF kaydındaki IP'leri dahil etmesini değiştirebiliriz, ancak IP'leri değiştirirsek bizi bağlar, bir grup müşterinin işi kırılır. Gerçekten bunu yapmak istemiyorum ..

Bunun için hangi çözümler var?

1. Çoğunlukla zaten yanıtlandı, lütfen Google'ı bu şekilde dahil etmenin yanlış olduğunu unutmayın - _spf.google.comyeniden yönlendirme için kullanmak veya bir ceza almak istiyorsunuz :

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

Bu arama kendi başına 5/10 tüketecek - 4/10 hala berbat ama% 20 daha az.

2. İşlemeyi durdurur ve kalıcı bir hata döndürür - kalıcı bir hatayı nasıl tedavi etmek istediğine karar vermek SPF'yi kullanan motora bağlıdır.

3. Evet - işlem sınırları olmadan SPF mekanizmaları üçüncü taraflara veya ikinci taraflara karşı DoS amplifikatörü olarak kullanılabilir .

Geçici bir çözüm olarak, e-postalar ana mülkün bir alt alan adından gelebilir - community.largecorporation.comörneğin.

1. Fazlalıkların (birden fazla başvuru _spf.google.comve başvurduğu kayıtlar gibi) yalnızca bir kez sayıldığını varsayarsak , ilk kaydı zaten aradığınız noktadan 17 arama sayıyorum. (Aşağıya bakınız.)

2. "Çok fazla iş" olacağı için SPF kaydınızı değerlendirmek için gerekli tüm kayıtlara bakmayı reddediyor. Muhtemelen bu, alan adınıza SPF kaydı yokmuş gibi davranacağı (veya muhtemelen reddedeceği) anlamına gelir. Spesifikasyon , bunun alıcıya ne yapacağına karar vermesini oldukça açık bırakan permerror ile sonuçlandığını söylüyor .

3. Genel olarak kötüye kullanımın aşağıdan ziyade arttığını düşünüyorum. Bu sınırın, alıcıyı potansiyel olarak DoS'a yol açacak olan muazzam SPF zincirleri ile boğabilecek olabilecek kötü niyetli gönderici alanlarını engellemek anlamına geldiği görülmektedir.

E-posta dış kaynak kullanımı yaygın olsa da, aslında altı farklı sağlayıcıya e-posta dış kaynak kullanımı yaygın değildir. SPF kaydını bir şekilde optimize etmeniz gerekecek.
(Bir kere, aspmx.googlemail.comhemen farklı bir isme yönlendirdiği için referans israf gibi görünüyor.)

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

Gibi bağlantılı sorulardan birine kabul cevap UNIX neredeyse hepsi - anlaşılır kılmakta UNIX sistemleri için temel araçları birçok aslında bu sınırı (hepsi değil ama tam da aynı şekilde) tüm SPF uygulaması hangi böylece bunları kullanır uyguluyorsunuz - bu sınırları da uygular. Windows sistemleri kendi başlarına bir yasadır ve onlara ışık tutamam.

Çözüm, dış kaynaklı SPF kayıtları zincirinizi değerlendiren, hepsini ipv4 ve ipv6 netblocks olarak ifade eden ve bunu kaydınıza dönüştüren bir cron işine sahip olmaktır. Unutma -all.

Sizin durumunuzda, müşterilerin daha sonra saklamaları gerekmeyen bir SPF kaydı yayınlamasını istersiniz. Bir olasılık, her müşterinin içeren bir kayıt yayınlaması olabilir redirect=spf.client1.jeffs-company.exampleve daha sonra adresindeki netblock listesini koruma ilkesini yaparsınız jeffs-company.example.

Belki de bu DNS limiti, böyle e-posta hizmetleri için temsilci seçmenin yaygın olmadığı 2000 yılında belirlendi?

Bu sınır, e-postanızı altı veya yedi büyük işlem için dışarıdan tedarik etmeyi zorlaştırır; ancak tartışmalı olarak tüm pratik amaçlar için zaten e-posta kontrolünü kaybetti.

Bir yerde, bir gün, varlığının tamamen farkında olmadığınız ve üzerinde kontrolünüz olmayan bazı alt-alt sözleşmeli programcılar noktalı virgülleri yanlış yerleştirecekler ve SPF imprimatur'unuzla bir ton sahte e-posta gönderilecek. E-postanızın tam kontrolü, e-posta altyapınızın tam kontrolünü gerektirir ve bence bu çok dış kaynak kullanımıyla tamamen tutarsızdır.

Bu sorunların üstesinden gelmenin bir başka yolu, SPF ayarlarını kontrol etmek için tam olarak hangi yazılımın kullanıldığına bakmaktır. Benim durumumda cluebringer / PolicyD, Mail::SPF::Serversonunda kullanır ve aksi takdirde sabit kodlanmış sınırları rahatlatıcı argümanları kabul eder . Sorun şu ki, cluebringer'ın kendisi şu anda bu argümanların rahatlamasını desteklemiyor , ancak bu gelecekte değişebilir ve bir kişi servis sağlayıcılara bu ayarları rahatlatmak için bu olasılıkları söyleyebilir.

Bunu yapmaya karar verirlerse elbette kontrol edilemezler, ama en azından bir şans.