पूछें कि प्रस्तावित अपग्रेड वास्तव में क्या बदलता है
एक दावा कि एक मंच एक पेशकश करता है DMARCbis अपग्रेड को वर्तमान मानक, बदले जा रहे कार्यान्वयन व्यवहार और परिवर्तन के कारगर होने के प्रमाण की पहचान करनी चाहिए। इसे किसी आविष्कारित DNS रिकॉर्ड को स्विच करने के अनुरोध के रूप में स्वीकार नहीं किया जाना चाहिए DMARC संस्करण। बरकरार रखा वर्तमान RFC 9989 अभी भी केस-संवेदी संस्करण मान DMARC1 निर्दिष्ट करता है। एक नया मानक दस्तावेज़ और एक नया कार्यान्वयन रिलीज़ प्रकाशित नीति में एक नए संस्करण टोकन के समान नहीं है।
यह आलेख मानकों से जुड़ी तत्परता समीक्षा का प्रस्ताव करता है। यह दावा नहीं करता कि EmailAuth लागू करता है RFC 9989 पूरी तरह से, कि प्रत्येक रिसीवर ने इसे अपना लिया है या अपग्रेड किया गया है। कोई DNS रिकॉर्ड, पार्सर, रिसीवर या उत्पादन कॉन्फ़िगरेशन नहीं बदला गया था। किसी के भी रोलआउट को मंजूरी देने से पहले समीक्षा में मानक परिवर्तन, आपूर्तिकर्ता कार्यान्वयन दावों और देखी गई अंतरसंचालनीयता को अलग किया जाना चाहिए।
संस्करण-स्विच शॉर्टकट को अस्वीकार करें
RFC 9989 की नीति-रिकॉर्ड परिभाषा बताती है कि संस्करण टैग का एकमात्र संभावित मान DMARC1 है और अन्यथा भिन्न संस्करण मान निर्दिष्ट प्रसंस्करण के तहत रिकॉर्ड को अनदेखा कर देता है। इसलिए v=DMARC2 को प्रकाशित करने का प्रस्ताव इस RFC का मानक-आधारित माइग्रेशन निर्देश नहीं है। उत्पाद लेबल पर भरोसा करने के बजाय प्रस्तावक से किसी भी अनुशंसित रिकॉर्ड परिवर्तन का समर्थन करने वाले सटीक अनुभाग की पहचान करने के लिए कहें।
डैशबोर्ड सेटिंग का नाम बदलने पर भी यही सावधानी लागू होती है। DMARCbis नामक एक सेटिंग एक पार्सर सुविधा, एक नीति-खोज एल्गोरिदम या रिपोर्टिंग व्याख्या को सक्षम कर सकती है, लेकिन इसका अर्थ दस्तावेज़ीकृत होने तक उत्पाद-विशिष्ट है। वास्तविक समर्थित व्यवहार, रिलीज़ संस्करण और सीमाएं रिकॉर्ड करें। यह अनुमान न लगाएं कि किसी सेटिंग को टॉगल करने से बाहरी रिसीवर अपडेट हो जाते हैं, हर रिकॉर्ड सही ढंग से फिर से लिखता है या सभी वैध भेजने वाले वर्कफ़्लो को सत्यापित करता है।
इन्वेंटरी प्रासंगिक मानकों में परिवर्तन करती है
एक केंद्रित चेकलिस्ट बनाने के लिए RFC 9989 की परिवर्तन चर्चा और मानक अनुभागों का उपयोग करें। एक महत्वपूर्ण क्षेत्र डीएनएस-आधारित नीति और संगठनात्मक-डोमेन खोज है, जिसमें शामिल है DNS ट्री वॉक. यह एक कार्यान्वयन व्यवहार है, न कि केवल मौजूदा रिकॉर्ड में डालने के लिए एक नई स्ट्रिंग। समर्थन का दावा करने वाले आपूर्तिकर्ता को यह बताना चाहिए कि कौन सी खोज और संरेखण यह जिन मामलों को संभालता है और वास्तविक उत्पाद संस्करण के लिए व्यापक साक्ष्य प्रदान करता है।
एक अन्य स्पष्ट परिवर्तन वर्तमान विनिर्देश से पीसीटी टैग को हटाना है। परिशिष्ट A.6 इतिहास की व्याख्या करता है और मान y और n के साथ परीक्षण टैग t का परिचय देता है, जिसे पूर्व पीसीटी मान 0 और 100 के अनुप्रयोग के अनुरूप बताया गया है। यह प्रत्येक ऐतिहासिक प्रतिशत मान के एक कंबल यांत्रिक प्रतिस्थापन या एक वादे को उचित नहीं ठहराता है कि प्रत्येक रिसीवर नए व्यवहार को लागू करता है। नीतिगत अंतर प्रस्तावित करने से पहले सटीक वर्तमान शब्दार्थ और प्रासंगिक परिनियोजन जनसंख्या की समीक्षा करें।
प्रोटोकॉल आवश्यकताओं को प्रदाता पात्रता नियमों से अलग रखें
एक प्रदाता उत्पाद पात्रता आवश्यकताओं को प्रकाशित कर सकता है जो मौजूदा तैनाती सम्मेलनों को संदर्भित करता है। उन आवश्यकताओं को अपने वर्तमान स्रोत की समीक्षा की आवश्यकता है और प्रोटोकॉल दस्तावेज़ बदल जाने के कारण चुपचाप दोबारा नहीं लिखा जाना चाहिए। इसके विपरीत, एक ऐतिहासिक प्रदाता निर्देश RFC 9989 की मानक सामग्री को फिर से परिभाषित नहीं करता है। स्पष्ट अंतर, स्रोत दिनांक और कार्यान्वयन प्रश्न को रिकॉर्ड करें जिसके समाधान की आवश्यकता है न कि यह दिखावा करें कि दोनों परतें समान हैं।
यह पांडुलिपि परीक्षण टैग, ट्री-वॉक व्यवहार या किसी अन्य संशोधित सुविधा के लिए सार्वभौमिक रिसीवर समर्थन का दावा नहीं करती है। तत्परता मूल्यांकन में यह पहचानना चाहिए कि संगठन किन घटकों को नियंत्रित करता है और कौन से बाहरी हैं। एक प्रेषक अपने स्वयं के कार्यान्वयन या नीति को केवल समर्थित दायरे में ही अपडेट कर सकता है; यह सभी प्राप्त प्रणालियों को अपग्रेड करने के लिए बाध्य नहीं कर सकता। इसलिए संगतता निष्कर्षों को वैश्विक अपनाने की धारणा के बजाय प्रमाणित, प्रमाणित साक्ष्य की आवश्यकता होती है।
अलग रिपोर्टिंग मानक और पार्सर तैयारी
RFC 9990 DMARC समग्र रिपोर्टिंग को एक अलग विनिर्देश के रूप में परिभाषित करता है। एक प्लेटफ़ॉर्म के नीति मूल्यांकनकर्ता और रिपोर्ट-अंतर्ग्रहण पार्सर की अपग्रेड आवश्यकताएं अलग-अलग हो सकती हैं। पूछें कि कौन से रिपोर्टिंग प्रारूप, फ़ील्ड और सत्यापन व्यवहार समर्थित हैं, और पुरानी रखी गई रिपोर्टें कैसे व्याख्या योग्य बनी रहती हैं। यह न मानें कि नीति-खोज कार्यान्वयन को बदलने से प्रत्येक रिपोर्टिंग वर्कफ़्लो या ऐतिहासिक विश्लेषण स्वचालित रूप से अपडेट हो जाता है।
मूल्यांकन के लिए उपयोग किए गए उत्पाद रिलीज़ और बनाए गए मानक संदर्भों को पिन करें। यदि एक पार्सर को एक असमर्थित फ़ील्ड या रिपोर्ट संस्करण का सामना करना पड़ता है, तो उसके व्यवहार को शून्य गतिविधि के रूप में चुपचाप व्याख्या करने के बजाय दस्तावेज़ीकृत और परीक्षण किया जाना चाहिए। मूल रिपोर्ट उद्गम को सुरक्षित रखें और प्रमाणीकरण परिणामों से गायब टिप्पणियों को अलग करें। इस आलेख के लिए किसी रिपोर्ट पार्सर का उपयोग नहीं किया गया था, और कोई परीक्षण स्थिरता वास्तविक रिसीवर रिपोर्ट के रूप में प्रस्तुत नहीं की गई है।
एक मानक-से-कार्यान्वयन मैट्रिक्स बनाएं
आरएफसी अनुभाग, मानक व्यवहार, वर्तमान उत्पाद व्यवहार, प्रस्तावित परिवर्तन, प्रभावित घटक, साक्ष्य संदर्भ और अनसुलझे सीमा के साथ प्रासंगिक आवश्यकता के अनुसार एक पंक्ति बनाएं। अलग-अलग प्रेषक नीति प्रकाशन, प्राप्तकर्ता मूल्यांकन, संगठनात्मक-डोमेन खोज, रिपोर्ट निर्माण और रिपोर्ट अंतर्ग्रहण। एक प्लेटफ़ॉर्म उनमें से केवल कुछ भूमिकाएँ ही निभा सकता है, इसलिए असमर्थित भूमिकाओं को निहितार्थ द्वारा कार्यान्वित के रूप में गिना जाने के बजाय दायरे से बाहर चिह्नित किया जाना चाहिए।
मौजूदा वैध नीतियों, अमान्य संस्करण मानों, खोज सीमाओं, संरेखण संबंधों और जहां लागू हो, रिपोर्टिंग संगतता के लिए प्रतिनिधि मामले जोड़ें। सटीक फिक्स्चर को एक योग्य समीक्षक द्वारा मानक पाठ और उत्पाद की समर्थित भूमिका के अनुसार डिज़ाइन किया जाना चाहिए। यह मसौदा कार्यान्वयन अनुरूपता सूट प्रदान नहीं करता है या यह दावा नहीं करता है कि उदाहरणों का एक छोटा सा सेट पूर्ण अनुपालन साबित करता है। प्रत्येक देखे गए परिणाम के लिए इनपुट, उत्पाद संस्करण और अपेक्षित व्यवहार को बनाए रखने की आवश्यकता होती है।
किसी भी रिकॉर्ड परिवर्तन को प्रेषक की तत्परता से जोड़ें
यदि मूल्यांकन DNS नीति में बदलाव का प्रस्ताव करता है, तो एक सटीक अंतर, स्वामित्व रिकॉर्ड, व्यवसाय अनुमोदन, सत्यापन योजना और रोलबैक मानदंड तैयार करें। प्रेषक-दर-प्रेषक तत्परता मैट्रिक्स के माध्यम से वैध प्रेषण वर्कफ़्लो को दृश्यमान रखें। मानकों का उन्नयन यह साबित नहीं करता है कि प्रत्येक आपूर्तिकर्ता ने प्रमाणीकरण संरेखित कर लिया है या प्रत्येक महत्वपूर्ण वर्कफ़्लो अप्रभावित जारी रहेगा। परिचालन तत्परता को छोड़ने के कारण के रूप में नए कार्यान्वयन लेबल का उपयोग न करें।
रिकॉर्ड करें कि परिवर्तन क्या प्रदर्शित कर सकता है और क्या नहीं। आधिकारिक DNS साक्ष्य किसी विशेष समय पर प्रकाशन दिखा सकते हैं; विश्वसनीय प्राप्त-संदेश साक्ष्य एक स्कोप्ड प्रमाणीकरण परिणाम दिखा सकते हैं; समग्र रिपोर्ट अपने बनाए हुए कवरेज के भीतर पैटर्न दिखा सकते हैं। कोई भी अकेले सार्वभौमिक अंतरसंचालनीयता स्थापित नहीं करता है। रोलबैक योजना में कैश्ड स्थिति और बाहरी कार्यान्वयन के अंतर को ध्यान में रखना चाहिए, न कि केवल पुरानी कॉन्फ़िगरेशन फ़ाइल को पुनर्स्थापित करने की क्षमता को ध्यान में रखना चाहिए।
काल्पनिक निदान: एक अनुरोधित DMARC2 रिकॉर्ड
एक काल्पनिक आपूर्तिकर्ता अपग्रेड का प्रस्ताव करता है और खरीदार को पॉलिसी के संस्करण मूल्य को DMARC2 में बदलने के लिए कहता है। खरीदार मानक संदर्भ मांगता है और पाता है कि RFC 9989 अभी भी DMARC1 निर्दिष्ट करता है। प्रस्तावित संस्करण स्विच को असमर्थित के रूप में खारिज कर दिया गया है, जबकि व्यापक कार्यान्वयन समीक्षा जारी है: आपूर्तिकर्ता के पास खोज या रिपोर्टिंग व्यवहार में वैध परिवर्तन हो सकते हैं जिनके लिए अलग साक्ष्य की आवश्यकता होती है।
टीम अपने मार्केटिंग नाम के आधार पर संपूर्ण अपग्रेड को स्वीकार या अस्वीकार करने के बजाय वास्तविक उत्पाद रिलीज के लिए एक स्कोप्ड रेडीनेस मैट्रिक्स और प्रदर्शित परिणामों का अनुरोध करेगी। यह एक काल्पनिक समीक्षा अभ्यास है, न कि कोई वास्तविक आपूर्तिकर्ता निर्देश या कोई देखी गई उत्पादन खराबी। कोई रिकॉर्ड प्रकाशित नहीं किया गया और किसी रिसीवर का परीक्षण नहीं किया गया। उदाहरण से पता चलता है कि कैसे एक सटीक मानक प्रश्न एक गलत शॉर्टकट को संभावित उपयोगी कार्यान्वयन कार्य से अलग कर सकता है।
अपग्रेड को पूर्ण कहने से पहले प्रदर्शित दायरे की आवश्यकता है
एक उपयोगी निष्कर्ष लागू किए गए मानकों से जुड़े परिवर्तनों, कवर की गई भूमिकाओं, बरकरार रखे गए सबूतों और अभी भी अज्ञात बाहरी संगतता की पहचान करता है। यह नहीं कहना चाहिए कि संगठन अब संस्करण दो का उपयोग करता है या सभी रिसीवर समान रूप से व्यवहार करते हैं। अपग्रेड एक कार्यान्वयन और तत्परता मूल्यांकन है, न कि एक सार्वभौमिक स्विच।
कैटलॉग को मानकों से जुड़े तत्परता मूल्यांकन और प्रदर्शित, दायरे वाले कार्यान्वयन परिणामों की आवश्यकता होती है। वे मूल परिणाम खुले रहते हैं. मानव विशेषज्ञ समीक्षा, स्रोत प्रयोज्यता, उत्पादन मार्ग, पहुंच और मालिक की रिहाई भी खुली रहती है। यह मसौदा एक समीक्षा पद्धति और काल्पनिक उदाहरण प्रदान करता है, न कि अनुरूपता साक्ष्य, एक तैनात माइग्रेशन या पूर्ण EmailAuth समर्थन का दावा।