नागरिक-सेवा पोर्टल: रसीदें, अनुस्मारक और स्थिति सूचनाएं प्रमाणित करें

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

प्रत्येक अधिसूचना को राज्य परिवर्तन से जोड़ें

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

प्रत्येक ईवेंट को भेजने वाले एप्लिकेशन, विक्रेता किरायेदार, डोमेन से मैप करें, लिफाफा भेजने वाला, DKIM डोमेन और चयनकर्ता. वेब पोर्टल का डोमेन और TLS प्रमाणपत्र यह नहीं दिखाता कि कौन सा सिस्टम ईमेल भेजता है। एक एप्लिकेशन एकीकरण प्रत्येक अधिसूचना परिवार के लिए एक अलग प्रदाता का चयन कर सकता है, तब भी जब सभी संदेश समान दृश्य डिज़ाइन साझा करते हैं।

परिवर्तन के इर्द-गिर्द डिज़ाइन परीक्षण, न कि केवल सुखद पथ

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

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

तय करें कि टूटी हुई यात्रा को कौन रोकता है

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

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

केवल प्रतिशत के बजाय पूर्णता की निगरानी करें

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

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

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

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

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

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

एक बासी-अनुस्मारक उदाहरण का समाधान करें

मान लें कि काल्पनिक मामला सी-01 अपॉइंटमेंट संस्करण 1 10:00 जीएसटी था और संस्करण 2 इसे उसी दिन 11:00 जीएसटी पर ले जाता है। संरेखित DKIM पास करने के लिए पहले से ही कतारबद्ध संस्करण-1 अनुस्मारक निर्धारित है। इसका पहचान परिणाम 10:00 बजे चालू नहीं होता है। शेड्यूलिंग स्वामी को स्वीकृत रद्दीकरण या प्रतिस्थापन नियम लागू करना चाहिए, आधिकारिक पोर्टल में वर्तमान नियुक्ति को सत्यापित करना चाहिए और जांचना चाहिए कि क्या वास्तव में सुधार दिया गया था। यदि संदेश में संस्करण 2 है लेकिन कोई विश्वसनीय प्रमाणीकरण प्रमाण नहीं है, तो मेल रूट की अलग से जांच करें। यहां कोई वास्तविक मामला, संदेश, पुनर्निर्धारण कार्य या सुधार प्रेषण का उपयोग नहीं किया गया था।

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

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 सर्वर स्वीकृति जिम्मेदारी को बाद के वितरण परिणामों से अलग करता है। यहां सेक्टर वर्कफ़्लो विकल्प संपादकीय अनुशंसाएं हैं; कानूनी दायरा, कारक उपयुक्तता और स्थानीय प्राधिकरण को अपनी स्वयं की जवाबदेह समीक्षा की आवश्यकता है।