पूछें कि स्रोत किस प्रश्न का उत्तर दे सकता है
A DMARC जांच में कई सवालों के जवाब देने की आवश्यकता हो सकती है: प्रकाशित प्रोटोकॉल किस व्यवहार को निर्दिष्ट करता है, कौन से टैग नाम पंजीकृत हैं, क्या सुधार में एक आधिकारिक स्वभाव है, और एक विशेष कार्यान्वयन वास्तव में क्या करता है। इन प्रश्नों के लिए अलग-अलग साक्ष्य की आवश्यकता होती है। खोज परिणाम, रजिस्ट्री पंक्ति और उत्पाद स्क्रीनशॉट को विनिमेय प्राधिकारी के रूप में मानने से गलत निर्णय पर सही तथ्य लागू करना आसान हो जाता है।
RFC 9989 इसमें वर्तमान कोर DMARC विनिर्देश शामिल हैं। समग्र और विफलता रिपोर्टिंग अलग-अलग निर्दिष्ट की गई है RFC 9990 और RFC 9991. उनका अलगाव तब मायने रखता है जब कोई स्रोत नीति मूल्यांकन के बजाय रिपोर्ट प्रारूप, बाहरी प्राधिकरण या गोपनीयता पर चर्चा करता है। " DMARC " का हवाला देने के बजाय दावे का समर्थन करने वाले सटीक दस्तावेज़ और अनुभाग को रिकॉर्ड करें जैसे कि यह एक अविभाज्य पृष्ठ था। RFC 9989 , खंड 6 और परिशिष्ट सी; RFC 9990 , खंड 1; RFC 9991 , खंड 1
किसी विनिर्देश को उसके दायरे और मानक भाषा के साथ पढ़ें
दस्तावेज़ संख्या, शीर्षक, प्रकाशन संदर्भ, अनुभाग और सटीक आवश्यकता भाषा को सुरक्षित रखें। MUST, SHOULD, MAY या व्याख्यात्मक उदाहरण के समान नहीं है। अभिनेता की भी पहचान करें: डोमेन स्वामी, मेल प्राप्तकर्ता, रिपोर्ट जनरेटर या रिपोर्ट उपभोक्ता। किसी प्राप्तकर्ता के मूल्यांकन व्यवहार के बारे में एक बयान आवश्यक रूप से डोमेन मालिक को एक नया DNS टैग प्रकाशित करने का निर्देश नहीं देता है।
किसी वाक्य को चेकलिस्ट में निकालने से पहले आसपास की स्थितियों को पढ़ें। कोई नियम केवल नीति खोज के बाद ही लागू हो सकता है, केवल बाहरी रिपोर्ट गंतव्य पर, या केवल तभी जब कोई प्राप्तकर्ता किसी विशेष प्रबंधन कार्रवाई को चुनता है। शर्त को हटाने से उपयोगी मार्गदर्शन एक झूठी सार्वभौमिक आवश्यकता में बदल सकता है। कामकाजी साक्ष्य रिकॉर्ड में शर्त को आवश्यकता के साथ रखें।
एक प्रकाशित विनिर्देश सार्वभौमिक परिनियोजन साबित नहीं करता है। कार्यान्वयन संस्करण और कॉन्फ़िगरेशन की अलग से जाँच की जानी चाहिए। इसी तरह, यह स्वचालित रूप से प्रत्येक संगठन के लिए एक कानूनी दायित्व नहीं है। किसी भी संविदात्मक, विनियामक या खरीद आवश्यकता को मानक-ट्रैक दस्तावेज़ से अनुमान लगाने के बजाय अपने स्वयं के वर्तमान अधिकार और दायरे की आवश्यकता होती है।
असाइनमेंट के लिए रजिस्ट्री का उपयोग करें, संपूर्ण एल्गोरिदम का नहीं
बरकरार IANA DMARC रजिस्ट्री पंजीकृत टैग, उनके संदर्भ, स्थिति और विवरण के लिए एक प्राथमिक स्रोत है। कैप्चर की गई रजिस्ट्री में, DMARC टैग तालिका RFC 9989 संदर्भ देती है और इसके साथ pct ऐतिहासिक को चिह्नित करती है RFC 7489 संदर्भ। ऐतिहासिक विन्यास शब्दावली को वर्तमान पंजीकृत स्थिति से अलग करते समय यह उपयोगी साक्ष्य है।
रजिस्ट्री पंक्ति पूर्ण प्रसंस्करण एल्गोरिदम या विक्रेता के रोलआउट शेड्यूल की आपूर्ति नहीं करती है। शब्दार्थ और प्रबंधन के लिए विनिर्देशन के लिए इसके संदर्भ का पालन करें। एक ऐतिहासिक टैग प्रविष्टि को एक असमर्थित दावे में परिवर्तित नहीं किया जाना चाहिए कि प्रत्येक तैनात रिसीवर उस टैग वाले रिकॉर्ड को अस्वीकार कर देता है। किसी परिणाम की भविष्यवाणी करने से पहले लागू पार्सिंग नियम और वास्तविक कार्यान्वयन व्यवहार निर्धारित करें।
रजिस्ट्री कैप्चर दिनांक और उपयोग की गई सटीक पंक्ति को बनाए रखें। प्रशिक्षण दस्तावेज़ में रजिस्ट्री सामग्री पुराने स्क्रीनशॉट से स्वतंत्र रूप से बदल सकती है। एक समीक्षा में यह स्पष्ट होना चाहिए कि क्या यह मौजूदा बरकरार असाइनमेंट का वर्णन कर रहा है या पुराने कार्यान्वयन के लिए प्रासंगिक ऐतिहासिक प्रविष्टि का वर्णन कर रहा है। IANA DMARC टैग रजिस्ट्री
ड्राफ्ट और सुधार दावों को सावधानी से संभालें
RFC 2026 विकसित इंटरनेट-ड्राफ्ट और आरएफसी तंत्र के माध्यम से प्रकाशन के बीच अंतर बताता है। यह आलेख किसी अधूरे प्रस्ताव को स्थापित कार्यान्वयन आवश्यकता के रूप में मानने से बचने के लिए उस ऐतिहासिक प्रक्रिया स्रोत का संकीर्ण रूप से उपयोग करता है। यह दावा नहीं करता है कि 1996 का पाठ प्रत्येक मौजूदा IETF प्रक्रिया या बाद की प्रक्रिया अद्यतन का पूरा विवरण है।
एक मसौदा मूल्यवान शोध संदर्भ हो सकता है, लेकिन इसका सटीक संस्करण बनाए रखें और इसकी स्थिति का ईमानदारी से वर्णन करें। किसी प्रस्ताव को केवल इसलिए तैनाती दावे में न बदलें क्योंकि वह आधिकारिक साइट पर दिखाई देता है। रिपोर्ट किए गए सुधार पर भी यही अनुशासन लागू होता है: यह दावा कि शब्दांकन गलत है, वर्तमान आधिकारिक व्यवहार को स्थापित करने या कार्यान्वयन को कैसे बदलना चाहिए, यह स्थापित करने के लिए पर्याप्त नहीं है। RFC 2026 , खंड 2.2
वर्तमान त्रुटिपूर्ण स्थिति असत्यापित बनी हुई है। प्रस्तावित सुधार पर भरोसा करने से पहले, इसकी आधिकारिक आरएफसी संपादक प्रविष्टि का निरीक्षण करें, इसके पहचानकर्ता और वर्तमान स्वभाव को रिकॉर्ड करें, और जांचें कि यह प्रासंगिक आवश्यकता को कैसे प्रभावित करता है। यह मार्गदर्शिका यह स्थापित नहीं करती है कि कोई विशिष्ट त्रुटि स्वीकार, सत्यापित या लागू है।
प्राधिकरण तुलना कार्यपत्रक
प्रत्येक निर्णय-प्रासंगिक दावे के लिए एक पंक्ति बनाएँ। दावा, अभिनेता, स्थिति, स्रोत वर्ग, सटीक यूआरएल, बरकरार रखी गई तारीख, दस्तावेज़ संस्करण या रजिस्ट्री पंक्ति, उद्धृत आवश्यकता और व्याख्या शामिल करें। सुधार स्थिति और प्रभावित कार्यान्वयन संस्करण के लिए एक अलग कॉलम जोड़ें। यदि इनमें से कोई भी अज्ञात है, तो अनुमानित डिफ़ॉल्ट के बजाय एक स्पष्ट अनसुलझा स्थिति का उपयोग करें।
दूसरे खंड में संघर्षों को रिकॉर्ड किया जाना चाहिए। क्या कोई प्रदाता मार्गदर्शिका मौजूदा यूआई का दस्तावेजीकरण करते समय ऐतिहासिक शब्दावली का उपयोग करती है? क्या रजिस्ट्री की स्थिति पुराने उदाहरण से भिन्न है? क्या प्रस्तावित इरेटम एक ऐसे किनारे के मामले को चुनौती देता है जिसका कार्यान्वयन कभी परीक्षण नहीं किया गया है? प्रत्येक विवाद के लिए एक विस्तृत समाधान योजना की आवश्यकता होती है, किसी व्यापक निर्देश की नहीं कि जो भी पेज सबसे नया लगे उस पर भरोसा किया जाए।
स्वीकृति के लिए एक समीक्षक को परिचालन निर्णय को उचित प्राधिकारी तक पहुंचाने और इसे वास्तविक कार्यान्वयन साक्ष्य से अलग करने की आवश्यकता होती है। एक स्रोत तुलना पूरी हो सकती है जबकि उत्पादन परिवर्तन अवरुद्ध रहता है। इसके विपरीत, एक कार्यान्वयन परीक्षण यह स्थापित किए बिना व्यवहार दिखा सकता है कि व्यवहार किसी विवादित आवश्यकता की पसंदीदा व्याख्या है।
काल्पनिक निदान: एक परिचित नमूना टैग
एक काल्पनिक आंतरिक मार्गदर्शिका की कल्पना करें जो पीसीटी को वर्तमान सार्वभौमिक रोलआउट नियंत्रण के रूप में प्रस्तुत करती है। एक समीक्षक ने मौजूदा बरकरार IANA प्रविष्टि को ऐतिहासिक और RFC 9989 में प्रासंगिक परिवर्तन चर्चा के रूप में चिह्नित किया है। इस उदाहरण में कोई लाइव नीति नहीं बदली गई और किसी रिसीवर का परीक्षण नहीं किया गया।
समर्थित संपादकीय सुधार पुराने निर्देश को बिना योग्यता के वर्तमान मूल मानक के रूप में प्रस्तुत करना बंद करना है। इसका तात्पर्य यह नहीं है कि सभी प्रदाताओं ने पहले ही समर्थन हटा दिया है या किसी संगठन को प्रत्येक उत्पादन रिकॉर्ड से टैग को तुरंत हटा देना चाहिए। समीक्षक को प्रभावित मार्गदर्शिका, स्रोत साक्ष्य और सत्यापन की आवश्यकता वाले कार्यान्वयन को रिकॉर्ड करना चाहिए।
यदि कोई किसी भिन्न व्याख्या को उचित ठहराने के लिए किसी कथित त्रुटि का हवाला देता है, तो उसे अधिकार के रूप में उपयोग करने से पहले उसकी सटीक स्थिति की जाँच की जानी चाहिए। इस पांडुलिपि में वह चेक अनुपलब्ध है, इसलिए जिम्मेदार निष्कर्ष एक खुला सुधार-स्थिति आइटम है, कोई आविष्कृत संकल्प नहीं। उदाहरण पूर्ण माइग्रेशन के बजाय स्रोत अनुशासन को दर्शाता है।
खुले साक्ष्य और प्रकाशन की स्थिति
कैटलॉग को वर्तमान आरएफसी, IANA और इरेटा स्थिति की जांच करने और प्रभावित कार्यान्वयन संस्करण को रिकॉर्ड करने की आवश्यकता है। वर्तमान में रखे गए आरएफसी और रजिस्ट्री साक्ष्य दस्तावेजी चर्चा का समर्थन करते हैं, लेकिन वर्तमान इरेटम-स्थिति सत्यापन और कार्यान्वयन-संस्करण साक्ष्य खुले रहते हैं। यह सीमा पांडुलिपि को पूर्ण परिचालन स्रोत निर्णय के रूप में प्रस्तुत करने से रोकती है।
सभी छह रिलीज गेट खुले रहेंगे। एक योग्य समीक्षक को मूल-साक्ष्य गेट को बंद करने से पहले एक अधिकृत उपलब्ध स्रोत के माध्यम से अनसुलझे सुधार की स्थिति पर दोबारा गौर करना चाहिए। कोई DNS परिवर्तन, सॉफ़्टवेयर रोलआउट, कानूनी प्रतिबद्धता या प्रदाता खाता पहुंच नहीं हुई। उपयोगी वितरण स्पष्ट साक्ष्य सीमाओं के साथ एक स्रोत-चयन विधि है, यह दावा नहीं है कि प्रत्येक अस्पष्टता का समाधान कर दिया गया है।