SPF रिकॉर्ड में अधिकतम DNS-इंटरेक्टिव शब्द सीमा के लिए वर्कअराउंड सीमा पार हो गई है?

16

एक होस्टिंग प्रदाता के रूप में, हम अपने ग्राहकों की ओर से ईमेल भेजते हैं, इसलिए हम उन्हें ईमेल डिलीवर करने का अधिकार पाने के लिए उनके DNS में DKIM और SPF ईमेल रिकॉर्ड स्थापित करने में मदद करते हैं। हम उन्हें परीक्षण करने के लिए http://mail-tester.com का उपयोग करने की सलाह दे रहे हैं कि वे कुछ भी याद न करें, और मुझे यह उपकरण बहुत पसंद है।

एक समस्या जिसे हमने कुछ समय में चलाया है, और मुझे यकीन नहीं है कि डोमेन नाम के आधार पर एसपीएफ रिकॉर्ड पर DNS "सीमा" है। तो अगर आपके पास यह है:

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 नहीं, तो यह यहां "दस" डीएनएस अनुरोधों को क्यों मार रहा है? यहाँ उत्तर दिया गया

  2. क्या यह 10 डीएनएस इंटरैक्टिव शब्द एक चेतावनी या वास्तविक त्रुटि है? हमें परवाह करनी चाहिए? यह हमारे ग्राहकों को थोड़ा परेशान कर रहा है और वे हमें समर्थन के लिए ईमेल करते हैं। यहाँ उत्तर दिया गया

  3. क्या यह 10 डीएनएस इंटरैक्टिव शब्द आज के वेब पर एक वास्तविक समस्या है? जैसा कि आप देख सकते हैं, इस ग्राहक के पास ईमेल भेजने के लिए बहुत सारी सेवाएँ हैं और वे सभी वैध हैं। शायद यह डीएनएस सीमा वर्ष 2000 में सेट की गई थी जब ईमेल सेवाओं को सौंपना इस तरह आम नहीं था?

हां, हम अपने ग्राहकों को एसपीएफ रिकॉर्ड में शामिल आईपी को बदल सकते हैं, लेकिन यह हमें एक बंधन में रखता है अगर हम कभी भी आईपी बदलते हैं, तो ग्राहकों का सामान टूट जाएगा। वास्तव में ऐसा नहीं करना चाहते हैं ..

इसके लिए क्या वर्कअराउंड हैं?

domain-name-system  spf 
— जेफ एटवुड
स्रोत
— माइकल हैम्पटन
डारन, मैंने त्रुटि संदेश के लिए खोज की लेकिन शून्य हिट मिला।
— जेफ एटवुड
2
मुझे उम्मीद नहीं है कि आप इसके लिए कुछ भी खोज पाएंगे। यह एक वास्तविक दुनिया की समस्या के बजाय एक ऑनलाइन परीक्षण उपकरण से आया था (जिसमें आपको लिंक किए गए प्रश्न में PermError संदेश जैसा कुछ दिखाई देगा)।
— माइकल हैम्पटन
मुझे वे अन्य पसंद हैं, लेकिन मैं ऐसे उत्तर नहीं देख रहा हूं जो वर्कअराउंड प्रदान करते हैं? क्या यह 10 लुकअप सीमा वास्तव में व्यवहार में लागू है?
— जेफ एटवुड
1
अपने टूलसेट में dmarcian.com/spf-survey जोड़ें , सुनिश्चित करें कि क्या आप अपने ग्राहकों के लिए SPF प्रदान कर रहे हैं, यह वही SPF नहीं है जिसका आप सीधे उपयोग करते हैं (अपने सम्मिलित spf में 3 पार्टियां शामिल नहीं हैं)
— याकूब इवांस

जवाबों:

8

  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% कम है।

  1. यह प्रसंस्करण को रोक देगा और एक स्थायी त्रुटि लौटाएगा - यह एसपीएफ़ का उपयोग करके इंजन पर निर्भर करता है कि वह कैसे स्थायी त्रुटि का इलाज करना चाहता है।

  2. हां - प्रसंस्करण सीमा के बिना एसपीएफ़ तंत्र को तीसरे पक्ष या दूसरे पक्ष के खिलाफ डीओएस एम्पलीफायर के रूप में इस्तेमाल किया जा सकता है ।

वर्कअराउंड के रूप में, ईमेल मुख्य संपत्ति के उप-डोमेन से आ सकते हैं - community.largecorporation.comउदाहरण के लिए।

— MikeyB
स्रोत
मेरा मानना ​​है कि हालांकि एक उपडोमेन ब्रेक का उपयोग डीकेआईएम करता है? मुझे पता है कि हमें अतीत में इससे परेशानी हुई थी। ऐसा लगता है कि एकमात्र समाधान है।
— जेफ एटवुड
1
@JeffAtwood आम तौर पर डीकेआईएम पर हस्ताक्षर डोमिन द्वारा भेजा जाता है। यदि आप एक उपडोमेन का उपयोग करते हैं, तो उप-डोमेन के साथ हस्ताक्षर करें। हालांकि, यह एक उपडोमेन के लिए हस्ताक्षर करने के लिए कानूनी है, लेकिन प्रसंस्करण नहीं मिल सकता है। हस्ताक्षरित डोमेन के सापेक्ष DKIM रिकॉर्ड बनाने की आवश्यकता है। मूल सत्यापन की अनुमति देने के लिए दस्तावेज़ पर हस्ताक्षर करने के लिए प्रवर्तक के लिए यह भी आम है।
— बिलथोर 25'15
1
जब तक संबंधित एसपीएफ और डीकेआईएम रिकॉर्ड रूट डोमेन के बजाय मेल डोमेन के लिए मौजूद हैं और आप के साथ हस्ताक्षर कर रहे हैं d=subdomain.example.com, यह ठीक रहेगा। सिद्धांत रूप में। बेहतर यह परीक्षण!
— मिकीबी
8

  1. यह मानते हुए कि अतिरेक (जैसे कई संदर्भों _spf.google.comऔर इसके लिए संदर्भित अभिलेखों) को केवल एक बार गिना जाता है, मैं उस बिंदु से 17 लुकअप की गणना करता हूं जहां आपने पहले रिकॉर्ड देखा है। (निचे देखो।)

  2. यह आपके SPF रिकॉर्ड का मूल्यांकन करने के लिए आवश्यक सभी रिकॉर्डों को देखने से इंकार करता है क्योंकि यह "बहुत अधिक काम" होगा। संभवतः इसका मतलब है कि यह आपके डोमेन का इलाज करेगा जैसे कि इसका कोई SPF रिकॉर्ड नहीं था (या संभवतः इसे अस्वीकार कर दिया गया हो)। युक्ति कहती है कि इससे पारर्मेर का परिणाम होता है , जो प्राप्तकर्ता को यह तय करने के लिए काफी खुला छोड़ देता है कि क्या करना है ।

  3. मुझे लगता है कि दुरुपयोग आम तौर पर नीचे की बजाय ऊपर जाता रहा है। यह सीमा अपमानजनक प्रेषक डोमेन को विफल करने के लिए प्रतीत होती है जो अन्यथा SPF की भारी श्रृंखला के साथ प्राप्तकर्ता को अभिभूत करने में सक्षम हो सकती है, संभवतः DoS के लिए अग्रणी है।

मुझे लगता है कि ईमेल को आउटसोर्स करते समय, यह छह अलग-अलग प्रदाताओं को ईमेल को आउटसोर्स करने के लिए वास्तव में सामान्य नहीं है। आपको किसी तरह एसपीएफ रिकॉर्ड को अनुकूलित करना होगा।
(एक बात के लिए, यह संदर्भ 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"
— हाकन लिंडक्विस्ट
स्रोत
5

जैसा कि लिंक किए गए प्रश्नों में से एक के लिए स्वीकृत उत्तर स्पष्ट करता है, UNIX सिस्टम के लिए अंतर्निहित कई उपकरण वास्तव में इस सीमा को लागू करते हैं (हालांकि सभी ठीक उसी तरह से नहीं) इसलिए कोई भी SPF कार्यान्वयन जो उनका उपयोग करता है - जो लगभग UNIX पर है - उन सीमाओं को भी लागू करेगा। विंडोज सिस्टम खुद के लिए एक कानून है, और मैं उन पर कोई प्रकाश नहीं डाल सकता।

वर्कअराउंड एक क्रॉन जॉब है जो आउटसोर्स एसपीएफ रिकॉर्ड की आपकी श्रृंखला का मूल्यांकन करता है, उन सभी को आईपीवी 4 और आईपीवी 6 नेटब्लॉक के रूप में व्यक्त करता है, और जो आपके रिकॉर्ड में बनाता है। मत भूलना -all।

आपके मामले में, आप चाहते हैं कि ग्राहक एक एसपीएफ़ रिकॉर्ड प्रकाशित करने में सक्षम हों जो उन्हें तब बनाए रखने की आवश्यकता नहीं है। एक संभावना यह होगी कि प्रत्येक ग्राहक के पास एक रिकॉर्ड प्रकाशित होना चाहिए redirect=spf.client1.jeffs-company.example, और फिर आप नेटब्लॉक की सूची को बनाए रखने की कानूनी कार्रवाई करेंगे jeffs-company.example।

शायद यह डीएनएस सीमा वर्ष 2000 में सेट की गई थी जब ईमेल सेवाओं को सौंपना इस तरह आम नहीं था?

सीमा आपके ईमेल को छह या सात बड़े ऑपरेशनों के लिए आउटसोर्स करना कठिन बना देती है; लेकिन यकीनन अगर आप ऐसा कर रहे हैं कि आपके पास वैसे भी आपके ईमेल पर नियंत्रण खो चुके सभी व्यावहारिक उद्देश्य हैं।

कहीं, किसी दिन, कुछ उप-उप-अनुबंधित प्रोग्रामर जिनके अस्तित्व में आप पूरी तरह से अनजान थे और जिन पर आपका कोई नियंत्रण नहीं है, वे एक अर्धविराम को गलत करने जा रहे हैं, और एक टन फर्जी ईमेल आपके एसपी के साथ भेजा जाएगा। आपके ईमेल के पूर्ण नियंत्रण के लिए आपके ईमेल अवसंरचना के पूर्ण नियंत्रण की आवश्यकता होती है, और यह मेरी राय में पूरी तरह से उस आउटसोर्सिंग के साथ असंगत है।

— मैड हैटर
स्रोत
0

उन समस्याओं के आसपास काम करने का एक और तरीका यह है कि एसपीएफ-सेटिंग्स की जांच के लिए किस सॉफ्टवेयर का उपयोग किया जाता है। मेरे मामले में यह क्लूब्रिंगर / पालिसी है, जो Mail::SPF::Serverअंत में उपयोग करता है और यह तर्क को शिथिल करता है अन्यथा कठोर-कोडित सीमाएं। समस्या यह है कि वर्तमान में क्लेब्रिंगर अपने आप में उन तर्कों को शिथिल करने का समर्थन नहीं करता है , लेकिन भविष्य में उनमें बदलाव हो सकता है और कोई सेवा प्रदाताओं को अपनी सेटिंग्स को शिथिल करने की संभावनाओं के बारे में बताने में सक्षम हो सकता है।

यदि वे ऐसा करने का निर्णय लेते हैं तो निश्चित रूप से नियंत्रण से बाहर हैं, लेकिन यह कम से कम एक मौका है।

— थोरस्टोन शूइंग
स्रोत
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.