ईमेल प्रमाणीकरण दिशानिर्देश

!! ध्यान दें !! यह दस्तावेज़ इतालवी से स्वचालित रूप से अनुवादित किया गया है।

दिशा-निर्देश

प्रमाणीकरण के लिए ईमेल सेवा का विन्यास

इटली की राष्ट्रीय साइबर सुरक्षा एजेंसी ने ईमेल सेवा की विश्वसनीयता को मजबूत करने और सभी इच्छुक संगठनों के लिए इसकी समग्र सुरक्षा स्तर को बढ़ाने के उद्देश्य से प्रमाणीकरण के लिए ईमेल सेवा को कॉन्फ़िगर करने के लिए दिशानिर्देश प्रकाशित किए हैं।

संस्करण नियंत्रण

अनुक्रमणिका

1 परिचय

1.1. आधार

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

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

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

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

ईमेल संदेशों की गोपनीयता की रक्षा के लिए आवश्यक प्रतिउपाय और प्रोटोकॉल (जैसे कि S/MIME और OpenPGP जो संदेश एन्क्रिप्शन से संबंधित हैं) इन दिशानिर्देशों का विषय नहीं हैं।

1.2. संदर्भ विनियम

1.3. संदर्भ दस्तावेज़

» शीर्ष पर वापस जाएँ

2. नियामक संदर्भ

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

राष्ट्रीय सुरक्षा से जुड़ी देश की सबसे महत्वपूर्ण सेवाओं के लिए उच्चतम स्तर की सुरक्षा राष्ट्रीय साइबर सुरक्षा परिधि द्वारा सुनिश्चित की जाती है, जिसे 21 सितंबर 2019 के अध्यादेश-कानून संख्या 105 द्वारा स्थापित किया गया था और 18 नवंबर 2019 के कानून संख्या 133 द्वारा संशोधित किया गया था। यह विशेष रूप से उच्च स्तर की सुरक्षा प्रदान करने वाले सुरक्षा उपाय प्रदान करता है, जिनका विवरण प्रधानमंत्री के 14 अप्रैल 2021 के अध्यादेश संख्या 81 के अनुलग्नक बी में दिया गया है। ये उपाय सार्वजनिक और निजी संस्थाओं के नेटवर्क, सूचना प्रणालियों और आईटी सेवाओं पर लागू होते हैं, जिन पर राज्य के किसी आवश्यक कार्य का निष्पादन या राज्य के हितों के लिए मौलिक नागरिक, सामाजिक या आर्थिक गतिविधियों के रखरखाव के लिए आवश्यक सेवा का प्रावधान निर्भर करता है, और जिनकी सुरक्षा में सेंध लगने से राष्ट्रीय सुरक्षा को नुकसान हो सकता है।

इसके अतिरिक्त, ईमेल सेवाएं, सार्वजनिक प्रशासन की सभी डिजिटल सेवाओं की तरह, तथाकथित क्लाउड विनियमन के प्रावधानों के अधीन हैं, जिसे 18 अक्टूबर 2012 के अध्यादेश संख्या 179 के अनुच्छेद 33-सेप्टिस के अनुसार अपनाया गया था और राष्ट्रीय साइबर सुरक्षा एजेंसी (एसीएन) द्वारा 27 जून 2024 के निर्देशात्मक अध्यादेश संख्या 21007 के साथ अद्यतन किया गया था। उपरोक्त विनियमन के तहत, सभी सार्वजनिक प्रशासनों को एसीएन द्वारा तैयार किए गए मॉडल के अनुसार अपने डिजिटल डेटा और सेवाओं को सामान्य, महत्वपूर्ण या रणनीतिक के रूप में वर्गीकृत करने का निर्देश दिया गया है। इस गतिविधि का उद्देश्य यह सुनिश्चित करना है कि सार्वजनिक प्रशासन के डिजिटल डेटा और सेवाओं को डिजिटल अवसंरचनाओं और क्लाउड सेवाओं के माध्यम से संसाधित और वितरित किया जाए जो विनियमन में विस्तृत रूप से वर्णित संबंधित वर्गीकरण स्तर से जुड़े जोखिमों के लिए उपयुक्त सुरक्षा आवश्यकताओं सहित आवश्यकताओं को पूरा करती हैं।

विधायी फरमान 4 सितंबर 2024, संख्या 138 (तथाकथित एनआईएस फरमान) निर्देश (ईयू) 2022/2555 को लागू करते हुए, एसीएन निर्धारण 379907/2025 के अनुलग्नक 1 और 2 के माध्यम से, आवश्यक और महत्वपूर्ण संस्थाओं द्वारा एनआईएस फरमान के अनुच्छेद 23 और 24 के तहत दायित्वों के प्रयोजनों के लिए अपनाए जाने वाले बुनियादी सुरक्षा उपायों को भी स्थापित करता है, जिसमें ईमेल सेवाओं सहित नेटवर्क और सूचना प्रणालियों की सुरक्षा को मजबूत करने के लिए एक सुरक्षा ढांचा परिभाषित किया गया है।

» शीर्ष पर वापस जाएँ

3. ईमेल सेवा वास्तुकला

जैसा कि प्रस्तावना में उल्लेख किया गया है, ईमेल सेवा का कामकाज एसएमटीपी प्रोटोकॉल पर आधारित है जो प्रेषक से प्राप्तकर्ता तक ईमेल संदेशों के संचरण को नियंत्रित करता है।

एसएमटीपी प्रोटोकॉल को मूल रूप से ¹⁹⁸² में एक स्टोर-एंड-फॉरवर्ड प्रोटोकॉल के रूप में परिभाषित किया गया था। इसमें प्रेषक अपने मेल क्लाइंट, जिसे तकनीकी भाषा में मेल यूजर एजेंट (एमयूए) कहा जाता है, के माध्यम से एक संदेश उत्पन्न करता है, जो इसे प्रेषक के मेल सर्वर को भेजता है। यह, मेल ट्रांसफर एजेंट (एमटीए) नामक एक घटक के माध्यम से, संदेश को आगे भेजता है, संभवतः एक या अधिक मध्यवर्ती एमटीए के माध्यम से भी, इसे गंतव्य मेल सर्वर के एमटीए तक पहुंचाता है। प्राप्तकर्ता उपयोगकर्ता अपने मेल क्लाइंट (एमयूए) के माध्यम से संदेश तक पहुंचता है। [1]

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

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

इस दिशानिर्देश में हम SPF, DKIM और DMARC प्रोटोकॉल के कॉन्फ़िगरेशन पर ध्यान केंद्रित करते हैं ताकि मेल सर्वर ईमेल संदेशों की प्रामाणिकता और अखंडता को सत्यापित कर सकें।

» शीर्ष पर वापस जाएँ

4. धमकियाँ

पिछले अध्याय में प्रस्तुत एसएमटीपी प्रोटोकॉल को शुरू में अपेक्षाकृत छोटे अकादमिक नेटवर्क में संचालित करने के लिए डिज़ाइन किया गया था और इसमें प्रेषित संदेशों की सुरक्षा या प्रेषक प्रमाणीकरण से संबंधित पहलुओं को ध्यान में नहीं रखा गया था [1] ।

ईमेल के बढ़ते प्रसार और एसएमटीपी प्रोटोकॉल की अंतर्निहित कमजोरियों ने समय के साथ ऐसे हमलों के उद्भव को बढ़ावा दिया है, जिनके मुख्य प्रकारों को निम्नलिखित अनुच्छेदों में संक्षेप में दर्शाया गया है।

4.1. प्रेषक स्पूफिंग

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

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

प्रेषक का ईमेल पता: लिफाफा-प्रेषक और संदेश-प्रेषक

ईमेल संदेश प्रारूप में प्रेषक का ईमेल पता दर्शाने के लिए दो अलग-अलग फ़ील्ड होते हैं। इन फ़ील्ड्स को 'envelop-from' और 'message-from' नाम दिया गया है: पहला (जिसे 'return-path' भी कहा जाता है क्योंकि यह उस ईमेल पते को निर्दिष्ट करता है जिस पर ईमेल प्राप्तकर्ता तक न पहुँचने पर उत्पन्न होने वाले किसी भी त्रुटि संदेश को भेजा जाना चाहिए) वह पता है जिसका उपयोग संदेश को सही ढंग से रूट करने के लिए किया जाता है, जबकि दूसरा वह पता है जो प्राप्तकर्ता को प्राप्त संदेश के हेडर में प्रदर्शित होता है।

पारंपरिक डाक के माध्यम से एक लिफाफे के अंदर पत्र भेजने के उदाहरण से तुलना करें तो, लिफाफे पर लिखा हुआ 'लिफाफे से भेजने वाले का पता' होता है, जबकि 'संदेश भेजने वाले का' पत्र में मौजूद शीर्षक होता है जो यह दर्शाता है कि पत्र किसने लिखा है।

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

संदेश भेजने वाले के नाम (प्राप्तकर्ता द्वारा प्राप्त संदेश के हेडर में प्रदर्शित प्रेषक का ईमेल पता) और लिफाफे से भेजने वाले के नाम (संदेश भेजने के लिए उपयोग किया जाने वाला प्रेषक का ईमेल पता) दोनों स्तरों पर किसी भी प्रेषक को इंगित करना वास्तव में संभव है।

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

4.2. फ़िशिंग

फ़िशिंग एक साइबर हमले की तकनीक है जिसका उद्देश्य धोखाधड़ी से जानकारी (जैसे, उदाहरण के लिए, लॉगिन क्रेडेंशियल, क्रेडिट कार्ड नंबर, या अन्य संवेदनशील डेटा) प्राप्त करना है, आमतौर पर विश्वसनीय प्रेषकों से उत्पत्ति का अनुकरण करने वाले भ्रामक संदेश भेजकर ³ ।

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

वैकल्पिक रूप से, प्राप्तकर्ता द्वारा पहचाने जाने योग्य प्रेषक पते/डोमेन के समान एक प्रेषक पते/डोमेन का उपयोग किया जा सकता है, उदाहरण के लिए, संदेश की स्पष्ट प्रामाणिकता को मजबूत करने के लिए तथाकथित प्रदर्शन नाम ^{4 को} बदलकर।

फिशिंग संदेश भेजने के लिए, हमलावर द्वारा पहले से ही हैक किए गए वैध खातों का भी उपयोग किया जा सकता है।

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

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

फिशिंग का एक प्रकार स्पीयर फिशिंग कहलाता है, जिसमें हमलावर पीड़ित की प्रोफाइल को जानता है और उसे विशेष रूप से निशाना बनाता है।

एक सामान्य फ़िशिंग ईमेल के विपरीत, एक स्पीयर फ़िशिंग संदेश उपयोगकर्ता को यह विश्वास दिलाने के लिए अधिक सटीक प्रासंगिक जानकारी का उपयोग करता है कि वे एक विश्वसनीय प्रेषक के साथ बातचीत कर रहे हैं [2] ।

4.3. संदेश में छेड़छाड़

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

परिणामस्वरूप, गोपनीयता भंग होने के अलावा, प्राप्त संदेश मूल रूप से प्रेषक द्वारा तैयार किए गए संदेश से मेल नहीं खा सकता है।

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

संदेश की स्पष्ट प्रामाणिकता पर भरोसा करते हुए, प्राप्तकर्ता को संभावित रूप से हानिकारक कार्य करने के लिए प्रेरित किया जा सकता है, जैसे कि लॉगिन क्रेडेंशियल साझा करना, भुगतान को अधिकृत करना या दुर्भावनापूर्ण फ़ाइलें खोलना।

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

» शीर्ष पर वापस जाएँ

5. प्रतिउपाय

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

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

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

5.1. SPF

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

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

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

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

यदि कोई संगठन अपनी ईमेल सेवा को पूर्णतः या आंशिक रूप से किसी तृतीय पक्ष, जैसे कि क्लाउड प्रदाता, को आउटसोर्स करता है, तो उसे यह सुनिश्चित करना होगा कि ऐसे प्रदाताओं द्वारा भेजे गए संदेश SPF जांच से गुजरें। इसके लिए, संगठन को अपने SPF रिकॉर्ड में उन IP पतों को शामिल करना चाहिए जिनसे प्रदाता संगठन के डोमेन की ओर से ईमेल भेजते हैं।

स्वचालित ईमेल फ़ॉरवर्डिंग के मामले में, चूंकि संदेशों को आमतौर पर एक मध्यवर्ती सर्वर द्वारा रीडायरेक्ट किया जाता है, इसलिए अंतिम डिलीवरी करने वाला IP पता प्रेषक डोमेन द्वारा मूल रूप से अधिकृत IP पते से मेल नहीं खाता है। ऐसे मामलों में, SPF सत्यापन विफल न हो, इसके लिए किसी भी मध्यवर्ती फ़ॉरवर्डिंग सर्वर को भी अधिकृत करना आवश्यक है, या SRS (सेंडर रीराइटिंग स्कीम) या ARC (ऑथेंटिकेटेड रिसीव्ड चेन) जैसी विधियों का उपयोग करना चाहिए, जो विशेष रूप से कई मध्यवर्ती फ़ॉरवर्डिंग सर्वरों की उपस्थिति में अधिक प्रभावी हो सकती हैं।

यह बात विशेष रूप से ध्यान देने योग्य है कि एसपीएफ के सही मायने में प्रभावी होने के लिए, इसे न केवल भेजने वाले द्वारा, बल्कि प्राप्तकर्ता द्वारा भी सही ढंग से कॉन्फ़िगर किया जाना चाहिए। विशेष रूप से:

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

5.1.1. एसपीएफ रिकॉर्ड

एक SPF रिकॉर्ड TXT प्रकार का DNS रिकॉर्ड होता है जिसका नाम प्रेषक डोमेन से मेल खाता है और जिसकी सामग्री संस्करण को इंगित करने ^वाले अनुभाग और निर्देशों की एक श्रृंखला से बनी ^होती है जो प्रेषक डोमेन के IP पते और एक निर्देश के बीच मिलान होने पर प्राप्तकर्ता के मेल सर्वर के व्यवहार को इंगित करती है।

निर्देश एक ऐसे तंत्र द्वारा गठित किए जाते हैं जिसके पहले एक क्वालिफायर होता है। एसपीएफ रिकॉर्ड में उपयोग किए जाने वाले मुख्य तंत्र [2] हैं:

• ip4 अधिकृत IPv4 पतों की सूची बनाता है;
• ip6 अधिकृत IPv6 पतों की सूची बनाता है;
• a , डोमेन के A रिकॉर्ड में मौजूद IP पतों को अधिकृत करता है;
• mx , डोमेन के MX रिकॉर्ड से संबंधित IP पतों को अधिकृत करता है;
• include , किसी अन्य डोमेन के SPF रिकॉर्ड में मौजूद IP पतों को अधिकृत करता है;
• 'all ' उन सभी आईपी पतों को दर्शाता है जिन्हें अन्य तंत्रों के माध्यम से स्पष्ट रूप से अधिकृत नहीं किया गया है।

विशेष रूप से, सभी यह तंत्र उन आईपी पतों से आने वाले संदेशों के लिए नीतियां स्थापित करने की अनुमति देता है जिन्हें पिछले तंत्रों द्वारा घोषित नहीं किया गया है।

इसके अलावा, एसपीएफ तंत्रों से संबद्ध करने के लिए निम्नलिखित योग्यताएं प्रदान करता है:

• + (पास) इंगित करता है कि संबंधित तंत्र से मेल खाने वाले आईपी पते अधिकृत हैं। यदि कोई अन्य निर्दिष्ट नहीं किया गया है तो यह डिफ़ॉल्ट क्वालिफायर है;
• - (असफलता) इंगित करता है कि संबंधित तंत्र से मेल खाने वाले आईपी पते अधिकृत नहीं हैं;
• ~ (सॉफ्टफेल) इंगित करता है कि संबंधित तंत्र से मेल खाने वाले आईपी पते संभवतः अधिकृत नहीं हैं। यह पिछली घोषणा की तुलना में अधिक अनिश्चित घोषणा है। ऐसे मामलों में संदेश को स्वीकार किया जाना चाहिए, लेकिन गहन विश्लेषण के लिए चिह्नित किया जाना चाहिए। इसका उपयोग उदाहरण के लिए डिबगिंग मामलों में या जब यह अनुमान लगाया जाता है कि एसपीएफ सत्यापन सफल नहीं हो सकता है, तब किया जाता है।
• ? (तटस्थ) इंगित करता है कि संबंधित तंत्र से मेल खाने वाले आईपी पतों के लिए कोई संकेत नहीं दिया गया है। डिफ़ॉल्ट व्यवहार संदेश को स्वीकार करना है।

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

किसी भी स्थिति में, इस निर्देश का कभी भी उपयोग न करने की सलाह दी जाती है। +सभी (या इसके समकक्ष) सभीक्योंकि यह सभी आईपी पतों के प्राधिकरण के अनुरूप होगा।

एसपीएफ रिकॉर्ड के उदाहरण

किसी विशिष्ट आईपी पते को अधिकृत करें

v=spf1 ip4:203.0.113.0 -all

ऊपर दिखाया गया SPF रिकॉर्ड SPF संस्करण 1 का उपयोग करता है और इसके माध्यम से अधिकृत करता है। आईपी4 तंत्र आईपी पता 203.0.113.0 (वास्तव में, चूंकि इसके लिए कोई विशेषण निर्दिष्ट नहीं है) आईपी4 तंत्र, डिफ़ॉल्ट + (अप्रत्यक्ष रूप से उपयोग किया जाता है)। -सभी द्वारा गठित निर्देश सभी तंत्र और - (असफल) क्वालिफायर यह निर्दिष्ट करता है कि अन्य सभी पते अधिकृत नहीं हैं।

एक विशिष्ट आईपी एड्रेस स्पेस को अधिकृत करें

v=spf1 ip4:203.0.113.0/24 -all

ऊपर दिखाया गया SPF रिकॉर्ड पिछले वाले के समान है, लेकिन यह सभी IP पतों को अधिकृत करता है। 203.0.113.0/24 पता स्थान।

एकाधिक आईपी पतों को अधिकृत करें

v=spf1 ip4:203.0.113.22 ip4:203.0.113.44 -सभी

ऊपर दर्शाया गया SPF रिकॉर्ड केवल IPv4 पतों को ही अधिकृत करता है। 203.0.113.22 और 203.0.113.44.

MX रिकॉर्ड पते और एक विशिष्ट डोमेन को अधिकृत करें

v=spf1 mx include:spf.emailprovider.it -all

ऊपर दर्शाया गया SPF रिकॉर्ड केवल उसी डोमेन के MX रिकॉर्ड के IP पतों और उस डोमेन के अधिकृत IP पतों को ही अधिकृत करता है। spf.emailprovider.it (उदाहरण के लिए, किसी ईमेल सेवा प्रदाता का डोमेन)।

5.1.2. प्रमाणीकरण प्रक्रिया

यदि SPF सत्यापन करने के लिए सही ढंग से कॉन्फ़िगर किया गया है, तो प्राप्तकर्ता का मेल सर्वर नया ईमेल संदेश प्राप्त होने पर, लिफाफे-प्रेषक फ़ील्ड में दिए गए पते के आधार पर, प्रेषक डोमेन के रिकॉर्ड वाले DNS सर्वर से क्वेरी करके प्रेषक डोमेन का SPF रिकॉर्ड प्राप्त करता है। उदाहरण के लिए, यदि लिफाफे-प्रेषक फ़ील्ड में दिया गया पता यह है: alice@example.comप्राप्तकर्ता का मेल सर्वर डोमेन का SPF रिकॉर्ड प्राप्त करता है। example.com.

इसके बाद प्राप्तकर्ता का मेल सर्वर SPF सत्यापन करता है और SPF रिकॉर्ड का विश्लेषण करके यह निर्धारित करता है कि जिस IP पते से संदेश प्राप्त हुआ है, वह ईमेल भेजने के लिए अधिकृत है या नहीं। example.com डोमेन। यदि ईमेल संदेश एसपीएफ सत्यापन में सफल हो जाता है, तो वह प्राप्तकर्ता को भेज दिया जाता है।

उदाहरण के लिए, यदि किसी व्यक्ति का एसपीएफ रिकॉर्ड example.com डोमेन थे v=spf1 ip4:203.0.113.22 -all सत्यापन तभी सफल होगा जब प्रेषक सर्वर का आईपी पता सही हो। 203.0.113.22जबकि किसी अन्य पते के लिए यह विफल हो जाएगा।

» शीर्ष पर वापस जाएँ

5.2. डीकेआईएम

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

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

इस पैराग्राफ के बाद के अनुभागों में डीकेआईएम के हस्ताक्षर और रिकॉर्ड को दर्शाया गया है।

एसपीएफ की तरह, डीकेआईएम को भी प्रेषक और प्राप्तकर्ता द्वारा सही ढंग से कॉन्फ़िगर किया जाना चाहिए, और विशेष रूप से:

• प्रेषक को अपने मेल सर्वर को डीकेआईएम हस्ताक्षर उत्पन्न करने और संबंधित डीएनएस सर्वर में डीकेआईएम रिकॉर्ड प्रकाशित करने के लिए कॉन्फ़िगर करना होगा;
• प्राप्तकर्ता को अपने मेल सर्वर को इस प्रकार कॉन्फ़िगर करना होगा कि वह प्राप्त संदेशों पर डीकेआईएम सत्यापन करे।

5.2.1. डीकेआईएम हस्ताक्षर

DKIM हस्ताक्षर संदेश के मुख्य भाग और शीर्षलेखों के निर्दिष्ट तत्वों से उत्पन्न होता है और इसमें कुंजी-मान युग्मों की एक श्रृंखला होती है जो उन तत्वों को निर्दिष्ट करती है जिनमें शामिल हैं:

• v : प्रोटोकॉल संस्करण ¹⁰ ;
• ए : प्रयुक्त एन्क्रिप्शन एल्गोरिथम ¹¹ ;
• डी : संदेश की प्रामाणिकता घोषित करने वाला हस्ताक्षर डोमेन ¹² ;
• s : चयनकर्ता जो इंगित करता है कि DNS रिकॉर्ड में किस DKIM सार्वजनिक कुंजी की तलाश करनी है ¹³ ;
• h : हस्ताक्षर में शामिल ईमेल हेडर की सूची ¹⁴ ;
• bh : संदेश निकाय का हैश बेस64 प्रारूप में एन्कोड किया गया ¹⁵ ;
• बी : निजी कुंजी के साथ उत्पन्न और बेस64 प्रारूप में एन्कोड किया गया वास्तविक डिजिटल हस्ताक्षर ¹⁶ ;
• x : हस्ताक्षर की वैधता तिथि;
• c : मानकीकरण का प्रकार।

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

5.2.2. डीकेआईएम रिकॉर्ड

DKIM रिकॉर्ड को TXT प्रकार के DNS रिकॉर्ड में संरक्षित किया जाता है, जिसका नाम इस प्रकार होता है। चयनकर्ता._डोमेन कुंजी.डोमेन, कहाँ _डोमेनकी यह एक लेबल है जिसका उपयोग यह इंगित करने के लिए किया जाता है कि DNS रिकॉर्ड वास्तव में एक DKIM रिकॉर्ड है। DKIM रिकॉर्ड की सामग्री में कुंजी-मान युग्मों की एक श्रृंखला होती है जो तत्वों को निर्दिष्ट करती है, जिनमें से:

• v : प्रोटोकॉल संस्करण;
• k : कुंजी का प्रकार, जो डिफ़ॉल्ट रूप से RSA होता है;
• p : बेस64 प्रारूप में एन्कोड की गई सार्वजनिक कुंजी।

डीकेआईएम रिकॉर्ड का उदाहरण

नाम: s1._domainkey.example.com
कीमत: v=DKIM1; के=आरएसए; p=Y2hpYXZ1cHViYmxpY2FkaWVzZW1waW8h...

उदाहरण डीकेआईएम रिकॉर्ड चयनकर्ता से संबद्ध है s1 की example.com डोमेन, संस्करण 1 का उपयोग करता है और इसमें बेस64 प्रारूप में एन्कोड की गई RSA सार्वजनिक कुंजी शामिल है (Y2hpYXZ1cHViYmxpY2FkaWVzZW1waW8h...).

5.2.3. प्रमाणीकरण प्रक्रिया

यदि प्रेषक और प्राप्तकर्ता दोनों के मेल सर्वरों पर DKIM प्रोटोकॉल सही ढंग से कॉन्फ़िगर किया गया है, तो DKIM प्रमाणीकरण और सत्यापन प्रक्रिया के संचालन के लिए प्रेषक मेल सर्वर पैराग्राफ 5.2.1 में वर्णित अनुसार संदेश का DKIM हस्ताक्षर बनाता है, जिसे संदेश में ही जोड़ दिया जाता है। विशेष रूप से, DKIM हस्ताक्षर में निम्नलिखित शामिल होते हैं: डी हस्ताक्षर डोमेन को फ़ील्ड करें¹⁷ और इसमें बी हस्ताक्षर करने वाले डोमेन की निजी कुंजी से उत्पन्न संदेश के डिजिटल हस्ताक्षर को दर्ज करें।

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

5.2.4. क्रिप्टोग्राफिक पहलू

क्रिप्टोग्राफिक मोर्चे पर, डीकेआईएम ने ऐतिहासिक रूप से आरएसए एल्गोरिदम का उपयोग किया है, विशेष रूप से आरएसए-एसएचए256 संस्करण में, जिसे 2007 से मानक माना जाता है। आरएफसी 8463 द्वारा पेश किया गया नया विकल्प एड25519-SHA256 है, जो अण्डाकार वक्रों पर आधारित डिजिटल हस्ताक्षर का एक आधुनिक रूप है जो अधिक दक्षता और बहुत अधिक कॉम्पैक्ट कुंजियों की गारंटी देता है।

तकनीकी स्तर पर, 2048 बिट्स की कुंजी लंबाई वाला RSA सार्वभौमिक मानक बना हुआ है, लेकिन इसकी कुंजियाँ लंबी होती हैं और हस्ताक्षर अपेक्षाकृत बड़े होते हैं, जबकि Ed25519 नौ गुना छोटी कुंजियाँ और चार गुना छोटे हस्ताक्षर प्रदान करता है, और हस्ताक्षर प्रदर्शन RSA 2048 की तुलना में तीस गुना तक बेहतर है। इन लाभों के बावजूद, वास्तविक दुनिया में इसका समर्थन सीमित है: 2026 में Ed25519 को केवल कुछ ही प्रदाताओं द्वारा सत्यापित किया गया है, जबकि कुछ प्रमुख ऑपरेटर हस्ताक्षर या सत्यापन दोनों का विश्वसनीय रूप से समर्थन नहीं करते हैं, जिससे यह उत्पादन में एकमात्र समाधान के रूप में अनुपयुक्त हो जाता है।

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

दीर्घकालिक सुरक्षा के संबंध में, यह याद रखना महत्वपूर्ण है कि न तो RSA और न ही Ed25519 भविष्य के क्वांटम कंप्यूटरों द्वारा हमलों के प्रति प्रतिरोधी हैं [3] , और पोस्ट-क्वांटम एल्गोरिदम की ओर संक्रमण के लिए नए DKIM मानकों की आवश्यकता होगी जो वर्तमान में मौजूद नहीं हैं, जिससे अगली पीढ़ी के क्रिप्टोग्राफी विकास और इस क्षेत्र में भविष्य के ACN अनुशंसाओं की निगरानी करना आवश्यक हो जाता है।

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

» शीर्ष पर वापस जाएँ

5.3. डीएमएआरसी

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

विशेष रूप से, DMARC एक प्रमाणीकरण तंत्र प्रस्तुत करता है - जिसे संरेखण कहा जाता है - जो SPF और DKIM द्वारा प्रमाणित डोमेन और संबंधित डोमेन के बीच पत्राचार को सत्यापित करता है। संदेश प्रेषक प्राप्त संदेश का फ़ील्ड। ध्यान दें कि संरेखण जाँच के बीच संदेश प्रेषक यदि संबंधित SPF/DKIM सत्यापन विफल हो जाता है तो फ़ील्ड और SPF/DKIM डोमेन किसी भी स्थिति में विफल हो जाते हैं (चित्र 4 देखें)।

संरेखण को सत्यापित किया जा सकता है कठोर वह मोड, जिसमें SPF/DKIM द्वारा प्रमाणित डोमेन और संबंधित डोमेन के बीच सटीक मिलान आवश्यक है। संदेश प्रेषक क्षेत्र, या आरामजहां प्राथमिक डोमेन का मेल खाना ही पर्याप्त है, भले ही उपडोमेन अलग-अलग हों।

उदाहरण के लिए, आराम डोमेन के लिए मोड sub1.example.com और sub2.example.com DMARC सत्यापन उद्देश्यों के लिए एक संरेखण पाया जाएगा (चूंकि प्राथमिक डोमेन, example.com(यह वही है)। कठोर हालांकि, इस मोड में डोमेन के बीच सटीक मिलान न होने के कारण DMARC अलाइनमेंट चेक विफल हो जाएगा।

अलाइनमेंट सत्यापन के माध्यम से, भले ही कोई हमलावर SPF और/या DKIM जांचों को पास करने में कामयाब हो जाए, संदेश प्रेषक से भिन्न लिफाफा-से SPF और/या प्रमाणित हस्ताक्षर डोमेन द्वारा प्रमाणित होने पर भी, DMARC विसंगति का पता लगा लेगा, जिससे प्रेषक की पहचान का सुसंगत और विश्वसनीय सत्यापन सुनिश्चित होगा। [2].

¹⁹ डीएमएआरसी सत्यापन में विफल रहने वाले संदेशों के प्रबंधन के लिए नीतियां प्रेषक डोमेन के सापेक्ष डीएनएस सर्वर के टीएक्सटी रिकॉर्ड में निर्दिष्ट की जाती हैं जिसे डीएमएआरसी रिकॉर्ड कहा जाता है और इस पैराग्राफ के बाद के अनुभाग में दर्शाया गया है।

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

SPF और DKIM की तरह, DMARC को भी प्रेषक और प्राप्तकर्ता द्वारा सही ढंग से कॉन्फ़िगर किया जाना चाहिए, और विशेष रूप से:

• प्रेषक को अपने डीएनएस में डीएमएआरसी रिकॉर्ड प्रकाशित करना होगा जिसमें उन नीतियों का उल्लेख हो जिनके तहत डीएमएआरसी सत्यापन में विफल होने वाले संदेशों का प्रबंधन किया जाएगा;
• प्राप्तकर्ता को अपने मेल सर्वर को इस तरह से कॉन्फ़िगर करना होगा कि वह प्राप्त संदेशों पर DMARC सत्यापन निष्पादित करे।

5.3.1. डीएमएआरसी रिकॉर्ड

DMARC रिकॉर्ड नाम की संरचना इस प्रकार है: _dmarc.डोमेन, कहाँ _dmarc यह एक लेबल है जिसका उपयोग यह इंगित करने के लिए किया जाता है कि DNS रिकॉर्ड एक DMARC रिकॉर्ड है और कार्यक्षेत्र यह वह क्षेत्र है जिसका उल्लेख नीति में किया गया है।

DMARC रिकॉर्ड में कुंजी-मान युग्मों की एक श्रृंखला होती है जो उन तत्वों को निर्दिष्ट करती है जिनके बीच:

• v : डीएमएआरसी प्रोटोकॉल संस्करण ²⁰ ;
• पी: DMARC सत्यापन में विफल होने वाले संदेशों पर लागू होने वाली नीति, निम्न में से कोई एक मान ले सकती है कोई नहीं, संगरोधन, अस्वीकार करना;
• एएसपीएफ: एसपीएफ जांच पर लागू करने के लिए संरेखण मोड (हो सकता है) आराम, डिफ़ॉल्ट मान, या कठोर);
• अदकिम: डीकेआईएम जांच पर लागू करने के लिए संरेखण मोड (हो सकता है) आराम, डिफ़ॉल्ट मान, या कठोर);
• rua : ईमेल पते जिन पर प्रेषक डोमेन से प्राप्त संदेशों पर सांख्यिकीय और सारांश जानकारी सहित समग्र रिपोर्ट भेजी जानी हैं;
• ruf : उन ईमेल पतों की सूची जिन पर प्रेषक डोमेन से प्राप्त उन व्यक्तिगत संदेशों की विस्तृत रिपोर्ट भेजी जानी है जिनका DMARC सत्यापन विफल रहा।

डीएमएआरसी रिकॉर्ड का उदाहरण

नाम:
_dmarc.example.com
कीमत:
v=DMARC1; p=अस्वीकार करें; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-fail@example.com; adkim=s; aspf=s

उदाहरण DMARC रिकॉर्ड इससे संबद्ध है example.com डोमेन, संस्करण 1 का उपयोग करता है और निर्दिष्ट करता है अस्वीकार करना DMARC सत्यापन में विफल होने वाले संदेशों के लिए नीति, अनुरोध करना कठोर तरीका (एसएसपीएफ और डीकेआईएम डोमेन के संरेखण के सत्यापन के लिए और ईमेल पते पर समग्र रिपोर्ट भेजने के लिए। dmarc-reports@example.com और विफलता रिपोर्ट पते पर भेजें dmarc-fail@example.com.

5.3.2. डीएमएआरसी नीतियां

जैसा कि पिछले पैराग्राफ में बताया गया है, DMARC रिकॉर्ड उस नीति को दर्शाता है जिसे प्राप्तकर्ता मेल सर्वर को उन संदेशों के लिए लागू करना चाहिए जो DMARC सत्यापन में पास नहीं होते हैं। संभावित नीतियां निम्नलिखित हैं:

• कोई नहीं : प्रेषक डोमेन डीएमएआरसी सत्यापन में विफल रहने वाले संदेशों की डिलीवरी के संबंध में कोई संकेत नहीं देता है;
• क्वारंटाइन : प्रेषक डोमेन इंगित करता है कि डीएमएआरसी सत्यापन में विफल रहने वाले संदेशों को संदिग्ध माना जाना चाहिए (उदाहरण के लिए, आगे की जांच के अधीन, स्पैम के रूप में माना जाना या संदिग्ध के रूप में लेबल किया जाना);
• अस्वीकार करें : प्रेषक डोमेन इंगित करता है कि DMARC सत्यापन में विफल होने वाले संदेशों को अस्वीकार कर दिया जाना चाहिए।

5.3.3. नीति सत्यापन और आवेदन प्रक्रिया

यदि प्रेषक और प्राप्तकर्ता दोनों के मेल सर्वरों पर DMARC प्रोटोकॉल सही ढंग से कॉन्फ़िगर किया गया है, तो संदेश प्राप्त होने पर प्राप्तकर्ता मेल सर्वर संबंधित सत्यापन करने के लिए SPF और DKIM रिकॉर्ड, साथ ही DMARC सत्यापन भी करता है (अनुच्छेद 5.2.4 के आरंभ में विस्तृत)। यदि संदेश DMARC सत्यापन में उत्तीर्ण नहीं होता है, तो DMARC रिकॉर्ड में इंगित नीति (कोई नहीं, संगरोधन या अस्वीकार करना) लागू की गई है।

ध्यान दें कि प्रत्येक मेल सर्वर संदेश की डिलीवरी सुनिश्चित करने के लिए स्थानीय नियम और नीतियां अपना सकता है, जिसमें SPF, DKIM और DMARC सत्यापन के परिणामों को भी ध्यान में रखा जाता है। इसलिए, आमतौर पर, उपरोक्त सत्यापन के बाद एक अतिरिक्त निर्णय प्रक्रिया (चित्र 5 में "मानक फ़िल्टर") होती है, जिसमें आगे की जांच (जैसे, उदाहरण के लिए, एंटी-स्पैम और एंटी-मैलवेयर फ़िल्टर) भी शामिल हो सकती हैं।

इसके अलावा, प्राप्तकर्ता मेल सर्वर निम्नलिखित जानकारी भेज सकता है:

• दिए गए पते पर रुआ डीएमएआरसी रिकॉर्ड का वह क्षेत्र, प्रेषक डोमेन से प्राप्त संदेशों पर सांख्यिकीय और सारांश जानकारी के साथ समग्र रिपोर्ट;
• दिए गए पते पर रूफ डीएमएआरसी रिकॉर्ड का फ़ील्ड, प्रेषक डोमेन से प्राप्त उन व्यक्तिगत संदेशों पर विस्तृत रिपोर्ट जो डीएमएआरसी सत्यापन में विफल रहे।

» शीर्ष पर वापस जाएँ

6. निष्कर्ष

जैसा कि पिछले अध्याय में चर्चा की गई है, प्रेषक डोमेन प्रतिरूपण से जुड़े खतरों का सर्वोत्तम ढंग से मुकाबला करने के लिए यह आवश्यक है कि तीनों जांचे गए प्रोटोकॉल संयुक्त रूप से लागू किए जाएं और विशेष रूप से, [3] :

• प्रेषक डोमेन DNS में SPF, DKIM और DMARC रिकॉर्ड सही ढंग से प्रकाशित करता है;
• प्रेषक के मेल सर्वर को DKIM का उपयोग करके संदेशों पर हस्ताक्षर करने के लिए कॉन्फ़िगर किया गया है;
• प्राप्तकर्ता के मेल सर्वर को SPF और DKIM सत्यापन करने और DMARC नीतियों को लागू करने के लिए कॉन्फ़िगर किया गया है।

प्रोटोकॉल कार्यान्वयन के संदर्भ में, निम्नलिखित अनुशंसाएँ भी तैयार की गई हैं [2] :

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

अधिक जानकारी के लिए, संदर्भ दस्तावेज़ों में सूचीबद्ध संसाधनों को देखें।

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

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

» शीर्ष पर वापस जाएँ

परिशिष्ट ए: सुरक्षा उपाय

राष्ट्रीय साइबर सुरक्षा परिधि (पीएसएनसी)

PR.IP-1: आईटी सिस्टम और औद्योगिक नियंत्रण प्रणालियों के विन्यास के लिए संदर्भ प्रथाओं (तथाकथित बेसलाइन) को परिभाषित और प्रबंधित किया जाता है, जिसमें सुरक्षा सिद्धांतों (जैसे, न्यूनतम कार्यक्षमता का सिद्धांत) को शामिल किया जाता है।

1. श्रेणी ID.AM के संबंध में भी, कम से कम निम्नलिखित बातों को दर्शाने वाला एक विस्तृत अद्यतन दस्तावेज़ उपलब्ध है:
   • ए) आईटी और औद्योगिक नियंत्रण प्रणालियों के विन्यास विकसित करने के लिए अपनाई गई सुरक्षा नीतियां और केवल अपनाए गए विन्यासों की तैनाती;
   • ख) उपयोग में लाई गई आईटी और औद्योगिक नियंत्रण प्रणाली विन्यासों की सूची और संबंधित संदर्भ प्रथाओं का उल्लेख;
   • ग) सुरक्षा नीतियों के अनुपालन में योगदान देने वाली प्रक्रियाओं, कार्यप्रणालियों और प्रौद्योगिकियों का उपयोग।

क्लाउड विनियमन – सार्वजनिक प्रशासन के लिए डिजिटल अवसंरचना और सेवाएं

PR.IP-01: आईटी सिस्टम और औद्योगिक नियंत्रण प्रणालियों के विन्यास के लिए संदर्भ प्रथाओं (तथाकथित बेसलाइन) को परिभाषित और प्रबंधित किया जाता है, जिसमें सुरक्षा सिद्धांतों (जैसे, न्यूनतम कार्यक्षमता का सिद्धांत) को शामिल किया जाता है।

1. एप्लिकेशन सुरक्षा के संदर्भ में नीतियां और प्रक्रियाएं परिभाषित की जाती हैं ताकि एप्लिकेशन सुरक्षा सुविधाओं की योजना बनाने, उन्हें साकार करने और बनाए रखने के लिए पर्याप्त सहायता प्रदान की जा सके, जिनकी समीक्षा और अद्यतन कम से कम वार्षिक रूप से किया जाना चाहिए।
2. श्रेणी ID.AM के संबंध में भी, कम से कम निम्नलिखित बातों को दर्शाने वाला एक विस्तृत अद्यतन दस्तावेज़ उपलब्ध है:
   • ए) आईटी और औद्योगिक नियंत्रण प्रणालियों के विन्यास विकसित करने के लिए अपनाई गई सुरक्षा नीतियां और केवल अपनाए गए विन्यासों की तैनाती;
   • ख) उपयोग में लाई गई आईटी और औद्योगिक नियंत्रण प्रणाली विन्यासों की सूची और संबंधित संदर्भ प्रथाओं का उल्लेख;
   • ग) सुरक्षा नीतियों के अनुपालन में योगदान देने वाली प्रक्रियाओं, कार्यप्रणालियों और प्रौद्योगिकियों का उपयोग।
3. विभिन्न अनुप्रयोगों की सुरक्षा के लिए बुनियादी आवश्यकताओं को परिभाषित और दस्तावेजीकृत किया गया है।
4. परिभाषित सुरक्षा आवश्यकताओं और अनुपालन दायित्वों के पालन के स्तर की निगरानी के लिए उपयोगी तकनीकी प्रकृति के मापदंडों को परिभाषित और कार्यान्वित किया जाता है।
5. एप्लिकेशन सुरक्षा के लिए एप्लिकेशन भेद्यता शमन और पुनर्प्राप्ति की एक प्रक्रिया है, जो संभव होने पर निवारण को स्वचालित करती है।
6. ऑपरेटिंग सिस्टम और एप्लिकेशन के साथ डिवाइस की अनुकूलता को सत्यापित करने की एक प्रक्रिया है।
7. ऑपरेटिंग सिस्टम, पैचिंग और/या एप्लिकेशन के संदर्भ में एक भिन्नता प्रबंधन प्रणाली मौजूद है।

क्लाउड विनियमन – सार्वजनिक प्रशासन के लिए क्लाउड सेवाएं

PR.IP-01: आईटी सिस्टम और औद्योगिक नियंत्रण प्रणालियों के विन्यास के लिए संदर्भ प्रथाओं (तथाकथित बेसलाइन) को परिभाषित और प्रबंधित किया जाता है, जिसमें सुरक्षा सिद्धांतों (जैसे, न्यूनतम कार्यक्षमता का सिद्धांत) को शामिल किया जाता है।

1. एप्लिकेशन सुरक्षा के संदर्भ में नीतियां और प्रक्रियाएं परिभाषित की जाती हैं ताकि एप्लिकेशन सुरक्षा सुविधाओं की योजना बनाने, उन्हें साकार करने और बनाए रखने के लिए पर्याप्त सहायता प्रदान की जा सके, जिनकी समीक्षा और अद्यतन कम से कम वार्षिक रूप से किया जाना चाहिए [IaaS, SaaS]।
2. श्रेणी ID.AM के संबंध में भी, कम से कम निम्नलिखित बातों को दर्शाने वाला एक विस्तृत अद्यतन दस्तावेज़ उपलब्ध है:
   • ए) आईटी और औद्योगिक नियंत्रण प्रणालियों के विन्यास विकसित करने के लिए अपनाई गई सुरक्षा नीतियां और केवल अपनाए गए विन्यासों की तैनाती;
   • ख) उपयोग में लाई गई आईटी और औद्योगिक नियंत्रण प्रणाली विन्यासों की सूची और संबंधित संदर्भ प्रथाओं का उल्लेख;
   • ग) सुरक्षा नीतियों के अनुपालन में योगदान देने वाली प्रक्रियाओं, कार्यप्रणालियों और प्रौद्योगिकियों का उपयोग [SaaS]।
3. विभिन्न अनुप्रयोगों की सुरक्षा के लिए बुनियादी आवश्यकताओं को परिभाषित और दस्तावेजीकृत किया गया है।
4. परिभाषित सुरक्षा आवश्यकताओं और अनुपालन दायित्वों के पालन के स्तर की निगरानी के लिए उपयोगी तकनीकी प्रकृति के मेट्रिक्स परिभाषित और कार्यान्वित किए जाते हैं। 5. एप्लिकेशन सुरक्षा के लिए एप्लिकेशन भेद्यता निवारण और पुनर्प्राप्ति की एक प्रक्रिया है, जहां संभव हो वहां सुधार को स्वचालित किया जाता है।
5. ऑपरेटिंग सिस्टम और एप्लिकेशन [PaaS, SaaS] के साथ डिवाइस की अनुकूलता को मान्य करने की एक प्रक्रिया है।
6. ऑपरेटिंग सिस्टम, पैचिंग और/या एप्लिकेशन [PaaS, SaaS] के संदर्भ में एक भिन्नता प्रबंधन प्रणाली मौजूद है।

NIS 2

PR.PS-01: कॉन्फ़िगरेशन प्रबंधन पद्धतियों को स्थापित और लागू किया जाता है।

1. कम से कम प्रासंगिक सूचना और नेटवर्क प्रणालियों के लिए, उनकी सुरक्षित आधारभूत कॉन्फ़िगरेशन (मजबूत) को एक अद्यतन सूची में परिभाषित और प्रलेखित किया जाता है।
2. उपाय GV.PO-01 में उल्लिखित नीतियों के अनुपालन में, बिंदु 1 के संबंध में प्रक्रियाओं को अपनाया और प्रलेखित किया जाता है।

» शीर्ष पर वापस जाएँ

ग्रन्थसूची

[1] एनआईएसटी, «तकनीकी नोट 1945».
[2] एनआईएसटी, «एनएसआईटी विशेष प्रकाशन 800-177 संशोधन 1»
[3] राष्ट्रीय साइबर सुरक्षा एजेंसी, «पोस्ट-क्वांटम और क्वांटम क्रिप्टोग्राफी - क्वांटम खतरे की तैयारी»।
[4] राष्ट्रीय साइबर सुरक्षा एजेंसी, «ईमेल प्रमाणीकरण ढांचा».

» शीर्ष पर वापस जाएँ