ईमेल-प्रमाणीकरण मानकों को विकसित करने के लिए एक परिवर्तन रजिस्टर

घटना को निर्णय से अलग करें

एक नया विनिर्देश, रजिस्ट्री अद्यतन, सुधार दावा या प्रदाता नोटिस उत्पादन परिवर्तन को अधिकृत किए बिना जांच शुरू कर सकता है। एक उपयोगी मानक परिवर्तन रजिस्टर पहले घटना को रिकॉर्ड करता है, फिर उसके द्वारा किए गए विश्लेषण और निर्णय को ट्रैक करता है। इसे लिंक की कालानुक्रमिक सूची नहीं बनना चाहिए जिसका वास्तविक मार्गों या कार्यान्वयन संस्करणों से कोई संबंध नहीं है।

के लिए DMARC, कोई परिवर्तन मुख्य नीति मूल्यांकन, समग्र रिपोर्टिंग या विफलता रिपोर्टिंग को प्रभावित कर सकता है। RFC 9989, RFC 9990 और RFC 9991 उन कार्यों को अलग करें. फ़ंक्शन द्वारा ईवेंट को टैग करने से इसे सही स्वामी तक पहुंचाने में मदद मिलती है और हर डोमेन की नीति को फिर से लिखने के लिए एक रिपोर्ट-प्रारूप अपडेट को एक कमांड के रूप में समझने से रोका जा सकता है। RFC 9989 , खंड 6 और परिशिष्ट सी; RFC 9990 , खंड 1; RFC 9991 , खंड 1

स्रोत घटना को बढ़ा-चढ़ाकर बताए बिना कैप्चर करें

प्रत्येक घटना को एक स्थिर पहचानकर्ता दें और उसके स्रोत यूआरएल, प्रकाशन या अवलोकन तिथि, सटीक दस्तावेज़ संस्करण, प्रभावित अनुभाग और परिवर्तन का संक्षिप्त विवरण बनाए रखें। जहां उपयुक्त हो वहां स्नैपशॉट हैश को सुरक्षित रखें ताकि बाद में समीक्षक बाद में बदले गए पृष्ठ से मूल रूप से मूल्यांकन किए गए स्रोत को अलग कर सकें। स्रोत वर्ग रिकॉर्ड करें: विनिर्देश, रजिस्ट्री, सुधार-स्थिति रिकॉर्ड या प्रदाता दस्तावेज़।

घटना के बगल में मानक अभिनेता और शर्तें लिखें। रिसीवर-साइड अनुशंसा स्वचालित रूप से डोमेन-स्वामी की आवश्यकता नहीं है। एक सार्वभौमिक प्रोटोकॉल नियम बने बिना उस उत्पाद के लिए प्रदाता का खाता ऑनबोर्डिंग निर्देश आवश्यक हो सकता है। प्रस्तावित परिवर्तन या अनसुलझा सुधार स्पष्ट रूप से अनंतिम रहना चाहिए।

किसी पुराने आंतरिक नोट से वर्तमान स्थिति का अनुमान न लगाएं। जब निर्णय ताजगी पर निर्भर हो तो आधिकारिक स्रोत की दोबारा जाँच करें। यदि कोई स्रोत अनुपलब्ध है, तो सीमा बनाए रखें और स्वतंत्र विश्लेषण जारी रखें; गुम साक्ष्य को किसी खोज स्निपेट या किसी असमर्थित घोषणा से न बदलें कि परिवर्तन स्वीकार कर लिया गया है।

स्वामित्व वाले कार्यान्वयन पर मानचित्र प्रभाव

प्रभाव अनुभाग में पार्सर, मूल्यांकनकर्ता, रिपोर्टिंग संग्राहक, DNS प्रकाशन वर्कफ़्लो या संभावित रूप से प्रभावित दस्तावेज़ीकरण सेट का नाम होना चाहिए। कार्यान्वयन संस्करण और कॉन्फ़िगरेशन, पोर्टफोलियो समूह, मार्ग स्वामी और प्रासंगिकता का समर्थन करने वाले साक्ष्य रिकॉर्ड करें। "सभी मेल" जैसा व्यापक लेबल शायद ही कभी उपयोगी होता है जब तक कि विश्लेषण वास्तव में हर मार्ग को कवर नहीं करता है।

प्रत्यक्ष प्रभाव को संभावित प्रभाव से अलग करें. एक अभिलिखित तैनात नीतियों के अपरिवर्तित रहने पर भी जनरेटर को संपादकीय अद्यतन की आवश्यकता हो सकती है। एक रिपोर्ट उपभोक्ता को मेल प्राप्तकर्ता के समय स्कीमा हैंडलिंग की आवश्यकता हो सकती है संरेखण तर्क अप्रभावित है. किसी भी सॉफ़्टवेयर रिलीज़ से पहले एक प्रशिक्षण गाइड को सही शब्दावली की आवश्यकता हो सकती है। इन अंतरों से अलग-अलग कार्य और स्वीकृति मानदंड उत्पन्न होने चाहिए।

जब कोई समीक्षा की गई घटना संगठन की भूमिका या कार्यान्वयन को प्रभावित नहीं करती है तो एक स्पष्ट गैर-लागू तर्क जोड़ें। यह इसे नज़रअंदाज़ करने से अलग है। बाद में उत्पाद माइग्रेशन तर्क को अमान्य कर सकता है, इसलिए उन धारणाओं को सुरक्षित रखें जो घटना को स्थायी रूप से दबाने के बजाय पुनर्मूल्यांकन को ट्रिगर करेंगी।

मानकों के अंतर को परीक्षण योग्य प्रश्नों से जोड़ें

एक मानक घटना एक सटीक प्रश्न बनना चाहिए: क्या यह कार्यान्वयन आवश्यक संस्करण मान को पार्स करता है, प्रासंगिक खोज व्यवहार को लागू करता है, या वर्तमान रिपोर्टिंग स्कीमा को संभालता है? RFC 9989 परिवर्तनों का वर्णन करते समय v=DMARC1 को बरकरार रखता है RFC 7489. संस्करण-स्विच कार्य का आविष्कार करने के बजाय रजिस्टर को वास्तविक परिवर्तित व्यवहार को रिकॉर्ड करना चाहिए।

प्रत्येक प्रश्न के लिए, फिक्स्चर संस्करण, अपेक्षित परिणाम, कार्यान्वयन संस्करण और नियोजित अवलोकन विधि की पहचान करें। एक दस्तावेजी समीक्षा प्रस्तावित अपेक्षित परिणाम का समर्थन कर सकती है लेकिन निष्पादित पास का दावा नहीं कर सकती। मतभेदों के लिए एक तर्कसंगत स्वभाव की आवश्यकता होती है: कार्यान्वयन दोष, असमर्थित सुविधा, गलत अपेक्षा, पर्यावरणीय अवरोध या जानबूझकर स्थगित दायरा। RFC 9989 , खंड 4.7 और परिशिष्ट सी

रजिस्टर को सारांश फ़ील्ड में निचोड़ने के बजाय पूर्ण परीक्षण कलाकृतियों से लिंक करना चाहिए। यह निर्णय को पुन: प्रस्तुत करने के लिए आवश्यक साक्ष्य को संरक्षित करते हुए पठनीय रखता है। इस आलेख द्वारा कोई परीक्षण सूट या सॉफ़्टवेयर कार्यान्वयन निष्पादित नहीं किया गया है।

निर्णय और रोलबैक वर्कशीट

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

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

अनुमोदित उत्पादन परिवर्तन के लिए, इसके अलग प्राधिकरण, रोलबैक शर्तों और परिवर्तन के बाद सत्यापन योजना को बनाए रखें। रजिस्टर DNS बदलने, क्रेडेंशियल बनाने, परीक्षण संदेश भेजने या कोड तैनात करने की अनुमति दिए बिना इन रिकॉर्ड्स को इंगित कर सकता है। समीक्षा के लिए तैयार के रूप में चिह्नित प्रविष्टि जारी की गई प्रविष्टि के समान नहीं है।

काल्पनिक परिवर्तन रिकॉर्ड: ऐतिहासिक टैग मार्गदर्शन

एक काल्पनिक रजिस्टर प्रविष्टि की कल्पना करें जो बरकरार IANA रजिस्ट्री द्वारा पीसीटी ऐतिहासिक और RFC 9989 को चिह्नित करके वर्तमान मुख्य विनिर्देश से हटाने की व्याख्या करती है। इस घटना को आंतरिक नीति-निर्माण मार्गदर्शिका और संभावित रूप से एक पुराने मूल्यांकनकर्ता को प्रभावित करने वाले के रूप में वर्गीकृत किया गया है। इस उदाहरण के लिए कोई उत्पादन रिकॉर्ड या सॉफ़्टवेयर नहीं बदला गया।

प्रस्तावित कार्रवाई मूल्यांकनकर्ता के व्यवहार को बदलने से पहले कार्यान्वयन-विशिष्ट साक्ष्य का अनुरोध करते हुए गाइड के मानकों के विवरण को अद्यतन करना है। रजिस्टर उन निर्णयों को अलग रखता है। एक काल्पनिक बाद का परीक्षण मूल्यांकनकर्ता की वर्तमान हैंडलिंग को स्थापित कर सकता है, लेकिन यह पांडुलिपि ऐसा कोई अवलोकन प्रदान नहीं करती है। इसका परीक्षण-स्थिति क्षेत्र नियोजित रहता है, पारित नहीं।

प्रविष्टि के पुनर्मूल्यांकन ट्रिगर में एक सॉफ़्टवेयर अपग्रेड, एक प्रदाता परिवर्तन और नया आधिकारिक स्पष्टीकरण शामिल है। उपयोगी आउटपुट सीमित संपादकीय कार्रवाई और परिचालन पकड़ का एक पता लगाने योग्य कारण है। यह कोई व्यापक घोषणा नहीं है कि सभी प्राप्तकर्ताओं ने एक जैसा व्यवहार अपनाया है। IANA DMARC टैग रजिस्ट्री; RFC 9989 , परिशिष्ट ए.6

विनिर्माण प्रगति के बिना रजिस्टर बनाए रखें

किसी लिंक की उम्र के बजाय वास्तविक परिणामों द्वारा निर्धारित तात्कालिकता के साथ, उनके प्रभाव के लिए उपयुक्त ताल पर खुली प्रविष्टियों की समीक्षा करें। स्रोत संदर्भों और निर्णयों को संरक्षित करते हुए डुप्लिकेट को मर्ज करें। किसी प्रविष्टि को तभी बंद करें जब उसके बताए गए स्वीकृति मानदंड पूरे हो जाएं या समीक्षा किए गए निर्णय से काम स्पष्ट रूप से समाप्त हो जाए। एक बंद दस्तावेजी समीक्षा में किसी अनसुलझे उत्पादन कार्य को छिपाना नहीं चाहिए।

कैटलॉग को एक मानक घटना को परीक्षण किए गए परिचालन निर्णय से जोड़ने वाले परिवर्तन रिकॉर्ड की आवश्यकता होती है। यह मसौदा केवल प्रस्तावित रजिस्टर संरचना और काल्पनिक प्रविष्टि प्रदान करता है। परीक्षण किया गया निर्णय, मूल निष्पादन साक्ष्य और मालिक की रिहाई अन्य रिलीज गेटों के साथ खुली रहती है। कोई लाइव कॉन्फ़िगरेशन, परिनियोजन या बाह्य संचार नहीं हुआ.

ऑपरेशनल केस स्टडी के रूप में प्रकाशन से पहले, परीक्षण कलाकृतियों और निर्णय अनुमोदन का समर्थन करते हुए वास्तविक संस्करणित रिकॉर्ड प्राप्त करें। अपवादों और असफल अपेक्षाओं को उपयोगी साक्ष्य के रूप में सुरक्षित रखें। एक रजिस्टर जो दिखाता है कि परिवर्तन क्यों स्थगित किया गया था, उस रजिस्टर की तुलना में अधिक भरोसेमंद है जो लागू किए गए प्रत्येक नए स्रोत को बिना यह प्रदर्शित किए लेबल करता है कि क्या हुआ।