सरकारी ईमेल प्रमाणीकरण: सार्वजनिक सेवाओं, प्रत्यायोजित डोमेन और ठेकेदारों को मैप करें

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

संगठन चार्ट के बजाय सेवा का पालन करें

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

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

प्रत्यायोजित-डोमेन सीमा स्थापित करें

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

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

परिवर्तन के दौरान सेवा निरंतरता को सुरक्षित रखें

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

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

तीन लिखित मार्ग अभिलेखों के माध्यम से कार्य करें

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

• नागरिक पोर्टल: डोमेन portal.civic.example से दृश्यमान; DKIM d=portal.civic.example; चयनकर्ता डेमो1; मान लें कि DKIM केवल इस लिखित मामले के लिए पास है। SPF पहचान से मेल और परिणाम अज्ञात; अन्य हस्ताक्षर अज्ञात; वास्तविक नीति खोज और वितरण अज्ञात। प्रस्तावित स्वामी: डिजिटल सेवा स्वामी। अगली कार्रवाई: इस सटीक किरायेदार के लिए एक अधिकृत नमूना और विश्वसनीय रिसीवर परिणाम प्राप्त करें।
• प्रत्यायोजित एजेंसी: डोमेन agency.civic.example से दृश्यमान; DKIM d=agency.civic.example; चयनकर्ता डेमो2; मान लें कि DKIM केवल इस लिखित मामले के लिए पास है। पहचान से SPF मेल और परिणाम अज्ञात; अन्य हस्ताक्षर अज्ञात; वास्तविक नीति खोज और वितरण अज्ञात। प्रस्तावित स्वामी: एजेंसी संचार स्वामी। अगली कार्रवाई: पहले रूट के परिणाम को इनहेरिट करने के बजाय इस अलग रूट और उसके व्यावसायिक ईवेंट की पुष्टि करें।
• ठेकेदार अनुस्मारक: डोमेन notices.civic.example से दृश्यमान; DKIM d=provider.example.net; चयनकर्ता डेमो3; मान लें कि DKIM केवल इस लिखित मामले के लिए पास है। पहचान से SPF मेल और परिणाम अज्ञात; अन्य हस्ताक्षर अज्ञात; वास्तविक नीति खोज और वितरण अज्ञात। प्रस्तावित स्वामी: अनुबंध प्रबंधक. अगली कार्रवाई: इस किरायेदार के समर्थित संरेखित हस्ताक्षर पथ के लिए सत्यापित आपूर्तिकर्ता से पूछें; प्राधिकरण को उसके संपूर्ण नेटवर्क तक विस्तृत न करें.

पहले दो निर्धारित हस्ताक्षरों के लिए, d= बिल्कुल से डोमेन के बराबर है, इसलिए पहचानकर्ता सख्त और साथ ही आराम से संतुष्ट करता है संरेखण. निर्धारित सफल DKIM परिणाम को देखते हुए, उन काल्पनिक संदेशों के लिए एक संरेखित प्रमाणीकरण पथ मौजूद है। तीसरा हस्ताक्षरकर्ता जानबूझकर लेखक डोमेन से असंबंधित है और वह संरेखित पथ प्रदान नहीं कर सकता है। तीसरे संदेश को DMARC विफलता न कहें: संरेखित SPF या कोई अन्य संरेखित पासिंग DKIM हस्ताक्षर अभी भी तंत्र को संतुष्ट कर सकता है, और वे इनपुट अज्ञात हैं। किसी भी पंक्ति से वास्तविक परिनियोजन या इनबॉक्स प्लेसमेंट का अनुमान न लगाएं।

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

एक ठोस रिलीज़ निर्णय असाइन करें

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

अनुपालन का दावा किए बिना मानकों को लागू करें

RFC 9989 धारा 4.4 और 5.3.5 संरेखण और तंत्र भेद का समर्थन करें। इसकी धारा 7.4 अप्रत्यक्ष-मेल इंटरऑपरेबिलिटी के बारे में चेतावनी देती है: डोमेन का उपयोग करना p=reject वैध DKIM उपयोग करना चाहिए, अकेले SPF नहीं, और सामान्य प्रयोजन मेल-सूची के उपयोग के लिए विशेष देखभाल की आवश्यकता होती है। रूट इन्वेंट्री स्वयं अस्वीकार को लागू करने की अनुमति नहीं है। RFC 6376 धारा 3.4-3.7 और 6.1 हस्ताक्षरित इनपुट और सत्यापन का वर्णन करें। RFC 9990 धारा 3.1 रिपोर्टिंग संदर्भ प्रदान करता है, न कि प्रति-प्राप्तकर्ता आगमन प्रमाण। RFC 5321 धारा 4.2.5 सर्वर स्वीकृति जिम्मेदारी को बाद के वितरण परिणामों से अलग करता है। यहां सेक्टर वर्कफ़्लो विकल्प संपादकीय अनुशंसाएं हैं; कानूनी दायरा, कारक उपयुक्तता और स्थानीय प्राधिकरण को अपनी स्वयं की जवाबदेह समीक्षा की आवश्यकता है।