परिभाषित करें कि स्वीकृति का क्या अर्थ होगा
एक डोमेन पोर्टफोलियो में कर्मचारी मेल, लेनदेन संबंधी एप्लिकेशन, मार्केटिंग सेवाएं, निष्क्रिय नाम और प्रत्यायोजित उपडोमेन शामिल हो सकते हैं। कॉर्पोरेट डोमेन के पास एक हरा चेक यह स्थापित नहीं करता है कि ये विभिन्न मार्ग सही ढंग से व्यवहार करते हैं। एक स्वीकृति पैक को परीक्षणों को सूचीबद्ध करने से पहले मूल्यांकन किए जा रहे डोमेन, पहचान, कार्यान्वयन और मार्गों को परिभाषित करना चाहिए। इसका उद्देश्य एक निश्चित रिलीज निर्णय का समर्थन करना है, न कि सार्वभौमिक अनुपालन बैज का निर्माण करना।
वर्तमान कोर DMARC विशिष्टता है RFC 9989, समग्र रिपोर्टिंग के साथ RFC 9990 और विफलता रिपोर्टिंग RFC 9991. माइग्रेशन समीक्षा को उन कार्यों को अलग करना चाहिए। प्रोटोकॉल रिकॉर्ड अभी भी स्वयं को v=DMARC1; विनिर्देश में परिवर्तन से DMARC2 नामक DNS मान नहीं बनता है। विनिर्देश संस्करण और ऑन-वायर रिकॉर्ड मान को पैक में अलग-अलग फ़ील्ड के रूप में रखें। RFC 9989 , खंड 4.7 और परिशिष्ट सी
पोर्टफोलियो को केवल स्वामित्व के आधार पर नहीं, बल्कि व्यवहार के आधार पर विभाजित करें
ऐसे समूह बनाएं जिनके सदस्य एक सार्थक परिचालन संपत्ति साझा करते हैं: एक कर्मचारी-मेल मार्ग, एक विशेष आपूर्तिकर्ता एकीकरण, एक प्रत्यायोजित उपडोमेन मॉडल या एक गैर-भेजने वाला नीति दायरा। प्रत्येक डोमेन को एक ही टेम्पलेट में बाध्य करने के बजाय अपवादों को सुरक्षित रखें। एक ही व्यवसाय के स्वामित्व वाले दो डोमेन विभिन्न प्रदाताओं और नीति-खोज पथों का उपयोग कर सकते हैं, जबकि कई ब्रांड एक अंतर्निहित मार्ग साझा कर सकते हैं।
प्रत्येक समूह के लिए, व्यवसाय स्वामी, DNS स्वामी, आवेदन भेजने वाले, प्रासंगिक प्रेषक और प्रमाणीकरण डोमेन, और समीक्षाधीन कार्यान्वयन को रिकॉर्ड करें। प्रस्तावित उदाहरण सूची से वास्तविक उत्पादन सूची को अलग करें। किसी परिसंपत्ति रजिस्टर में किसी डोमेन की उपस्थिति यह साबित नहीं करती है कि उसकी सभी भेजने वाली धाराएँ मिल गई हैं। अज्ञात मार्गों को अंतराल के रूप में दृश्यमान रहना चाहिए, चुपचाप स्वीकृत के रूप में नहीं गिना जाना चाहिए।
तय करें कि पैक क्या स्थापित कर सकता है। ऑफ़लाइन पार्सर फिक्स्चर नामित कार्यान्वयन के तहत निर्दिष्ट इनपुट हैंडलिंग प्रदर्शित कर सकते हैं, लेकिन वे लाइव DNS उपलब्धता या प्राप्त-संदेश व्यवहार को साबित नहीं करते हैं। एक DNS स्नैपशॉट एक समय में नीति खोज का समर्थन कर सकता है, लेकिन यह प्रत्येक रिसीवर की तैनाती नहीं दिखाता है। रिलीज़ निर्णय के दौरान इन साक्ष्य स्तरों को स्पष्ट रखें।
विशिष्ट प्रोटोकॉल परीक्षण परिवार बनाएँ
नीति परीक्षणों में वैध और अमान्य संस्करण प्लेसमेंट और मूल्य, समर्थित टैग, नीति खोज और प्रासंगिक DNS ट्री-वॉक व्यवहार शामिल होना चाहिए। संरेखण परीक्षणों को कच्चे में अंतर करना चाहिए SPF या DKIM के साथ तालमेल से सफलता RFC5322 .से कार्यक्षेत्र। ऐसे मामलों को शामिल करें जहां एक संरेखित तंत्र पास हो जाता है और दूसरा विफल हो जाता है, इसलिए पैक को DMARC सफलता के लिए गलती से दोनों को पास करने की आवश्यकता नहीं होती है।
रिपोर्टिंग परीक्षण अलग-अलग परिवारों में होते हैं। समग्र रिपोर्टिंग की अपनी खोज, बाह्य-गंतव्य सत्यापन और XML संरचना होती है। विफलता रिपोर्टिंग का एक अलग प्रारूप और गोपनीयता सतह होती है। एक सफल नीति विश्लेषण इस बात का प्रमाण नहीं है कि रिपोर्ट वितरण या सुरक्षित रिपोर्ट प्रसंस्करण काम करता है। कार्यान्वयन-विशिष्ट व्यवहार को अलग से चिह्नित करते हुए, पैक को प्रत्येक अपेक्षित परिणाम को उस सटीक अनुभाग से जोड़ना चाहिए जो इसे प्रदान करता है। RFC 9989 , खंड 4.4, 4.7 और 4.10; RFC 9990 , खंड 3, 4 और परिशिष्ट ए; RFC 9991 , धारा 4 और 5
संस्करण फिक्स्चर और अवलोकन एक साथ
प्रत्येक फिक्स्चर को एक पहचानकर्ता, सामग्री हैश, उद्देश्य, स्रोत आवश्यकता, इनपुट धारणाएं और अपेक्षित परिणाम की आवश्यकता होती है। प्रत्येक निष्पादन के लिए कार्यान्वयन नाम और संस्करण, कॉन्फ़िगरेशन, निष्पादन समय, देखे गए परिणाम, लॉग और समीक्षक की आवश्यकता होती है। यदि फिक्स्चर बदलता है, तो उसी पहचानकर्ता के तहत पुराने इनपुट को चुपचाप बदलने के बजाय एक नया संस्करण संरक्षित करें। अन्यथा स्पष्ट सुधार व्यवहार में सुधार के बजाय आसान परीक्षणों के कारण हो सकता है।
देखे गए रन की व्याख्या करने से पहले अपेक्षित परिणाम अवश्य लिखे जाने चाहिए। जब कोई परिणाम अलग होता है, तो वर्गीकृत करें कि क्या अपेक्षा गलत थी, कार्यान्वयन अलग था, स्थिरता अमान्य थी या पर्यावरण ने सार्थक परीक्षण को रोक दिया था। छोड़ी गई या अवरुद्ध की गई परीक्षा पास नहीं है। स्थानीय नीति द्वारा स्वीकार किए गए परिणाम को प्रासंगिक विवेक को समझाए बिना मानक-अनुरूप के रूप में पुनः लेबल नहीं किया जाना चाहिए।
रहस्यों और अनावश्यक संदेश सामग्री को फिक्स्चर से दूर रखें। प्रयोगशाला कार्य के लिए बंधे हुए, अधिकृत सिंथेटिक इनपुट और उत्पादन मार्गों के लिए अलग से अनुमोदित साक्ष्य का उपयोग करें। यह आलेख परीक्षण संदेश भेजने, रिकॉर्ड बदलने या प्रदाता खातों तक पहुंच के लिए निष्पादित फिक्स्चर सूट या प्राधिकरण प्रदान नहीं करता है।
पोर्टफोलियो स्वीकृति कार्यपत्रक
वर्कशीट को एक पोर्टफोलियो समूह को स्थिरता पहचानकर्ताओं, अपेक्षित परिणामों, देखे गए परिणामों, अनसुलझे मतभेदों और एक रिलीज निर्णय से जोड़ना चाहिए। एक कवरेज कॉलम शामिल करें जिसमें दिखाया गया हो कि कौन से डोमेन या रूट दर्शाए गए हैं और वह समूहीकरण क्यों उचित है। एक प्रतिनिधि मामला एक दस्तावेजी निष्कर्ष का समर्थन कर सकता है, लेकिन यह चुपचाप असंबंधित कार्यान्वयन या आपूर्तिकर्ताओं के लिए प्रमाण नहीं बन सकता है।
मूल साक्ष्य, मानव समीक्षा, स्रोत प्रयोज्यता, उत्पादन मार्ग, दृश्य पहुंच और मालिक की रिहाई के लिए अलग गेट कॉलम जोड़ें। ऑफ़लाइन पार्सर परीक्षण पास होने पर भी ये गेट खुले रह सकते हैं। रिकॉर्ड करें कि प्रत्येक को कौन बंद कर सकता है और किस कलाकृति की आवश्यकता है। रिलीज़ स्वामी को असमर्थित दायरे को छुपाने वाले प्रतिशत के बजाय एक संक्षिप्त अपवाद सूची देखनी चाहिए।
पैक में रोलबैक और पुनर्मूल्यांकन ट्रिगर भी होना चाहिए। प्रदाता परिवर्तन, DNS प्रतिनिधिमंडल परिवर्तन, नया भेजने का मार्ग या विनिर्देश स्पष्टीकरण पहले की स्वीकृति धारणा को अमान्य कर सकता है। उस घटना को संरक्षित करें जिसके लिए पुनर्मूल्यांकन की आवश्यकता है और प्रभावित फिक्स्चर परिवारों को ताकि अगली समीक्षा बिखरे हुए टिकटों से इरादे के पुनर्निर्माण के बजाय एक ज्ञात आधार रेखा से शुरू हो।
काल्पनिक पोर्टफोलियो निर्णय
कर्मचारी मेल, एक रसीद सेवा और एक निष्क्रिय ब्रांड डोमेन के साथ एक काल्पनिक पोर्टफोलियो की कल्पना करें। प्रस्तावित पैक दो भेजने वाले मार्गों के लिए संरेखण मामले और सभी तीन समूहों को नीति-खोज मामले आवंटित करता है। एक काल्पनिक प्रयोगशाला कार्यान्वयन वैध संस्करण मान को सही ढंग से संभालता है लेकिन एक खोज स्थिरता पर भिन्न होता है। वास्तव में कोई निष्पादन नहीं हुआ; ये रिलीज़ निर्णय को दर्शाने वाली आविष्कृत स्थितियाँ हैं।
संपूर्ण पोर्टफोलियो को तैयार चिह्नित करना सही प्रतिक्रिया नहीं होगी क्योंकि अधिकांश मामले स्वीकार्य प्रतीत होते हैं। समीक्षक खोज अंतर को बनाए रखेगा, पहचान करेगा कि कौन से समूह इस पर निर्भर हैं और उस दायरे को जारी करने से पहले कार्यान्वयन साक्ष्य मांगेंगे। रसीद सेवा को अभी भी अपने स्वयं के अधिकृत मार्ग साक्ष्य की आवश्यकता होगी, भले ही प्रयोगशाला संरेखण तर्क सही हो।
एक प्रस्तावित परिणाम उत्पादन तत्परता बनाए रखते हुए एक सीमित ऑफ़लाइन व्यवहार को स्वीकार कर सकता है। यह अंतर शर्मिंदा करने के बजाय उपयोगी है: यह मालिक को ठीक-ठीक बताता है कि सबूत क्या समर्थन करते हैं। उदाहरण यह दावा नहीं करता है कि नामित रिसीवर ने RFC 9989 अपनाया है या वास्तविक डोमेन ने परीक्षण पास कर लिया है।
मूल साक्ष्य खुला रहता है
कैटलॉग के लिए एक संस्करणयुक्त फिक्स्चर सेट और अपेक्षित-बनाम-अवलोकित परिणामों की आवश्यकता होती है, न कि केवल एक चेकलिस्ट की। यह पांडुलिपि वर्णन करती है कि उस पैक को कैसे बनाया जाए, लेकिन कोई फिक्सचर निष्पादन, लाइव क्वेरी या देखे गए परिणाम प्रदान नहीं किए गए हैं। इसलिए मूल साक्ष्य की आवश्यकता खुली रहती है, जैसा कि सभी छह रिलीज़ गेट्स पर होता है।
परिचालन प्रकाशन से पहले, एक योग्य समीक्षक को यह सत्यापित करना चाहिए कि प्रत्येक अपेक्षित परिणाम का वर्तमान आधिकारिक आधार है और प्रत्येक अवलोकन बताए गए कार्यान्वयन संस्करण से संबंधित है। किसी स्रोत उद्धरण को निष्पादन लॉग के विकल्प के रूप में न मानें। अंतिम स्वीकृति दावे में कवर किए गए पोर्टफोलियो दायरे, इसके अपवाद और बकाया परिचालन निर्भरता का नाम होना चाहिए।