The SPF पीटीआर तंत्र मान्य के माध्यम से कनेक्टिंग होस्ट को अधिकृत करने का एक विरासत तरीका है रिवर्स DNS. वर्तमान SPF मार्गदर्शन कहता है कि इसे प्रकाशित नहीं किया जाना चाहिए क्योंकि यह धीमा है, कुछ डीएनएस-त्रुटि मामलों में अविश्वसनीय है और परिचालन रूप से बोझिल है। यह प्रोटोकॉल का हिस्सा बना हुआ है और अनुपालन मूल्यांकनकर्ताओं को इसका समर्थन करना चाहिए।
यह अंतर मायने रखता है: हतोत्साहित का मतलब सार्वभौमिक रूप से अनदेखा या स्वचालित रूप से अमान्य नहीं है। इस पर निर्भर प्रेषकों की पहचान किए बिना इसे हटाने से वास्तविक प्रमाणीकरण परिणाम बदल सकते हैं। RFC 7208 अनुभाग 5.5 प्रासंगिक मार्गदर्शन प्रदान करता है।
प्रतिस्थापित की जा रही अनुमति को समझें
वैचारिक रूप से, पीटीआर कनेक्टिंग पते के लिए रिवर्स लुकअप से शुरू होता है। इसके बाद यह सत्यापित करने के लिए लौटाए गए नामों को अग्रेषित करता है कि वे कनेक्टिंग पते पर वापस इंगित करते हैं। तंत्र के मिलान के लिए एक मान्य नाम को लक्ष्य डोमेन से मेल खाना चाहिए या उसकी डोमेन सीमा के भीतर होना चाहिए।
यह जाँचने से कहीं अधिक है कि होस्टनाम में कोई परिचित स्ट्रिंग है या नहीं। relay.example.com जैसा नाम example.com के भीतर है; relay.notexample.com नहीं है। केवल उल्टा उत्तर भी अपर्याप्त है: आगे की पुष्टि मायने रखती है।
रिवर्स DNS अक्सर SPF संपादित करने वाले संगठन के बजाय पते के मालिक द्वारा प्रशासित किया जाता है। यह एक अतिरिक्त प्रशासनिक निर्भरता बनाता है जब नीति किसी चुने हुए डोमेन के नीचे होस्टनाम पर निर्भर करती है।
एक कृत्रिम विरासत उदाहरण पर चलें
मान लीजिए example.com प्रकाशित करता है v=spf1 ptr:example.com -all. 192.0.2.55 से एक कनेक्शन आता है। इसका उलटा उत्तर outbound.example.com है, और उस नाम के A उत्तर में 192.0.2.55 शामिल है। इस सरलीकृत फिक्स्चर में, मान्य नाम example.com के भीतर है, इसलिए पीटीआर मेल खाता है।
यदि आगे का पता इसके बजाय 192.0.2.99 है, तो कनेक्टिंग पते के लिए रिवर्स नाम मान्य नहीं है। यदि कोई अन्य मान्य नाम योग्य नहीं है, तो पीटीआर मेल नहीं खाता है और पॉलिसी -all तक पहुंच जाती है। इसी तरह, लक्ष्य डोमेन के बाहर एक मान्य नाम केवल इसलिए योग्य नहीं होता क्योंकि वह समान दिखता है।
ये सिंथेटिक इनपुट के लिए अपेक्षित प्रोटोकॉल परिणाम हैं, उत्पादन डोमेन से अवलोकन नहीं। वास्तविक मूल्यांकन लुकअप और प्रोसेसिंग सीमाएं भी लागू करता है, जिसमें रिवर्स और फॉरवर्ड कार्य की सीमाएं भी शामिल हैं।
दो रिवर्स-डीएनएस निर्णयों को भ्रमित न करें
SPF से पीटीआर तंत्र को हटाने का मतलब सर्वर के PTR रिकॉर्ड को हटाना नहीं है। रिवर्स DNS अभी भी SPF से स्वतंत्र रूप से SMTP संचालन, रिसीवर आवश्यकताओं और प्रतिष्ठा जांच के लिए प्रासंगिक हो सकता है। एक होस्ट के पास उचित रिवर्स DNS हो सकता है, जबकि उसकी SPF नीति में आईपी4, आईपी6 या एक दस्तावेजी प्रदाता का उपयोग शामिल है।
माइग्रेशन को सीमित दायरे में रखें. प्राधिकरण तंत्र को बदलें और अन्य कार्यशील DNS सेटिंग्स को तब तक बनाए रखें जब तक कि एक अलग, उचित परिवर्तन की आवश्यकता न हो।
प्रेक्षित प्रेषकों में से एक प्रतिस्थापन चुनें
आपके नियंत्रण में समर्पित स्थिर निकास के लिए, स्पष्ट आईपी4 और आईपी6 अनुमतियाँ इच्छित पते को दृश्यमान बनाती हैं। प्रबंधित बदलते बुनियादी ढांचे वाली सेवा के लिए, प्रदाता होस्टनाम नियम को फिर से बनाने के बजाय इसके दस्तावेज़ीकृत SPF कॉन्फ़िगरेशन का उपयोग करें।
The एक तंत्र यह उपयुक्त हो सकता है जब एक विशेष रूप से नियंत्रित होस्टनाम का उद्देश्य भेजने वाले पते को परिभाषित करना हो। यह पीटीआर के लिए एक स्वचालित सर्वोत्तम विकल्प नहीं है: यह अनुमति मॉडल को बदलता है और अपनी स्वयं की फॉरवर्ड-डीएनएस निर्भरता बनाता है।
वर्तमान में पीटीआर से गुजरने वाले पतों की एक सूची बनाएं और स्वामित्व साक्ष्य प्राप्त करें। फ़ेलओवर, IPv6 और कम ट्रैफ़िक शामिल करें। कुछ हालिया पते एकत्र न करें और दावा करें कि आपने पूर्ण अनुमति सेट स्थापित कर लिया है।
अनिश्चितता को छिपाए बिना प्रवास करें
एक प्रस्तावित नीति बनाएं जो सत्यापित वैध मार्गों को अधिकृत करे। उस सेट और अनधिकृत नियंत्रणों के लिए पुरानी और नई नीतियों का मूल्यांकन करें। जांचें कि क्या कोई नया अनुदान पुराने अनुदान से अधिक व्यापक है और क्या अज्ञात प्रेषक अनसुलझे हैं।
पिछले रिकॉर्ड को सुरक्षित रखें और वैध वर्कफ़्लो विफलताओं से जुड़ी रोलबैक शर्तों को परिभाषित करें। सामान्य परिवर्तन नियंत्रण के माध्यम से प्रकाशित करें, DNS उत्तरों का निरीक्षण करें और प्रतिनिधि द्वारा प्राप्त संदेशों को सत्यापित करें। यदि कोई वैध प्रेषक विफल रहता है, तो अनुमति जोड़ने से पहले उसकी पहचान और स्वामित्व की पुष्टि करें।
व्यावहारिक उपाय
वास्तविक प्रेषकों के बारे में साक्ष्य का उपयोग करके पीटीआर को SPF प्राधिकरण तंत्र के रूप में रिटायर करें। आवश्यक रिवर्स DNS सुरक्षित रखें, और छिपे हुए होस्टनाम निर्भरता को एक स्पष्ट, रखरखाव योग्य अनुमति मॉडल के साथ बदलें।
अगला निर्णय रिकॉर्ड करें
सिंथेटिक विरासत स्रोत के लिए, उल्टा उत्तर, आगे का उत्तर, मान्य नाम और लक्ष्य-सीमा तुलना को अलग-अलग रखें। फिर प्रस्तावित प्रतिस्थापन की तुलना ज्ञात, फेलओवर और दुर्लभ स्रोतों और अनधिकृत नियंत्रण से करें। यदि एक प्रेषक का स्वामित्व अज्ञात रहता है, तो चुपचाप विस्तार करने के बजाय उस अंतर को रिकॉर्ड करें CIDR. इस समीक्षा में कोई PTR क्वेरी या माइग्रेशन नहीं हुआ।