एक हस्ताक्षरित संदेश फिर भी स्पैम हो सकता है। उसका साइनिंग डोमेन प्राप्तकर्ता को दिखाए गए पते से भिन्न भी हो सकता है।
DKIM हस्ताक्षर क्या कवर करता है?
DKIM हस्ताक्षर चुने हुए हेडर फ़ील्ड और बॉडी के हैश की सुरक्षा करता है।
h= टैग हस्ताक्षरित हेडर फ़ील्ड सूचीबद्ध करता है। bh= टैग बॉडी हैश रखता है। भेजने वाला सर्वर अपनी निजी कुंजी से हस्ताक्षर बनाता है। रिसीवर इसे संबंधित सार्वजनिक कुंजी से सत्यापित करते हैं।
रिसीवर बॉडी हैश की पुनर्गणना करता है। वह चुने हुए हेडर और हस्ताक्षर हेडर पर भी हस्ताक्षर को सत्यापित करता है, जिसमें वह हैश होता है।
RFC 6376 के अनुसार From हेडर पर हस्ताक्षर करना आवश्यक है। अन्य हेडर फ़ील्ड अहस्ताक्षरित रह सकते हैं। इसलिए एक अहस्ताक्षरित Reply-To जोड़ने से DKIM वैध रह सकता है।
दोहराए गए हेडर को अलग उपचार की आवश्यकता होती है। साइनर किसी हेडर नाम को उसकी वास्तविक संख्या से अधिक बार सूचीबद्ध कर सकता है, ताकि कोई नई प्रति बिना पता चले न जोड़ी जा सके।
रिसीवर सार्वजनिक कुंजी कहाँ ढूँढता है?
रिसीवर साइनिंग डोमेन और सेलेक्टर का उपयोग करके सार्वजनिक कुंजी का पता लगाता है; सेलेक्टर उस कुंजी की पहचान करने वाला नाम है। d= टैग डोमेन देता है। s= टैग सेलेक्टर देता है।
d=example.com और s=foo.bar के लिए, लुकअप नाम foo.bar._domainkey.example.com होता है। सेलेक्टर एक ही साइनिंग डोमेन के तहत अलग-अलग कुंजियों की अनुमति देता है।
रोटेशन के दौरान, नई कुंजी से हस्ताक्षर करने से पहले उसे प्रकाशित करें। पुरानी सत्यापन कुंजी को तब तक उपलब्ध रखें जब तक उससे हस्ताक्षरित संदेश ट्रांज़िट में हैं। उसे समय से पहले हटाने से रिसीवर उन संदेशों को सत्यापित नहीं कर पाएँगे।
फ़ॉर्मेटिंग बदलाव हस्ताक्षर क्यों तोड़ सकते हैं?
कैनोनिकलाइज़ेशन, यानी हस्ताक्षर और सत्यापन से पहले लागू होने वाला नॉर्मलाइज़ेशन, तय करता है कि DKIM किन फ़ॉर्मेटिंग बदलावों को सहन करता है।
c= टैग हेडर और बॉडी के लिए अलग-अलग एल्गोरिदम चुनता है। relaxed/relaxed में, दोनों relaxed नॉर्मलाइज़ेशन का उपयोग करते हैं।
| एल्गोरिदम | हेडर व्यवहार | बॉडी व्यवहार |
|---|---|---|
simple | हेडर फ़ॉर्मेटिंग को संरक्षित रखता है | अंत में खाली पंक्तियों को अनदेखा करता है |
relaxed | हेडर-नाम केस, फ़ोल्डिंग और व्हाइटस्पेस को नॉर्मलाइज़ करता है | व्हाइटस्पेस और अंत की खाली पंक्तियों को नॉर्मलाइज़ करता है |
एक फ़ोल्ड किया हुआ हेडर अगली पंक्ति पर जारी रहता है। Relaxed हेडर प्रोसेसिंग उस फ़ोल्डिंग को सहन करती है। Simple प्रोसेसिंग तब विफल हो सकती है जब कोई सर्वर उसी हेडर को दोबारा फ़ोल्ड करता है।
विफल होने वाले रिले से पहले और बाद में हस्ताक्षरित कंटेंट की तुलना करें, क्योंकि एक अदृश्य फ़ॉर्मेटिंग बदलाव परिणाम की व्याख्या कर सकता है।
DKIM कौन से साइनिंग एल्गोरिदम का समर्थन करता है?
DKIM RSA और Ed25519 साइनिंग एल्गोरिदम का समर्थन करता है, दोनों SHA-256 के साथ संयुक्त हैं।
RFC 8301 के तहत RSA की न्यूनतम कुंजी लंबाई 1,024 बिट है। छोटी कुंजियाँ कुंजी समझौते के विरुद्ध अपर्याप्त प्रतिरोध प्रदान करती हैं।
अनुशंसित RSA आकार कम से कम 2,048 बिट है, जो कुंजी समझौते के विरुद्ध अधिक प्रतिरोध प्रदान करता है। जब आपका साइनिंग सिस्टम इसे सपोर्ट करे तो यही आकार चुनें। विनिर्देश साइनिंग और सत्यापन के लिए rsa-sha1 को निषिद्ध करता है।
RFC 8463 ed25519-sha256 जोड़ता है। एक संदेश अलग-अलग एल्गोरिदम का समर्थन करने वाले रिसीवर के साथ संगतता के लिए RSA और Ed25519 दोनों हस्ताक्षर रख सकता है।
Yahoo का मार्गदर्शन भी न्यूनतम 1,024-बिट DKIM कुंजी की आवश्यकता रखता है।
जब कोई मेलिंग लिस्ट संदेश में बदलाव करती है तो क्या होता है?
कोई बदलाव DKIM को अमान्य कर सकता है जब वह हस्ताक्षर द्वारा कवर किए गए कंटेंट को बदलता है।
फ़ॉरवर्डिंग स्वयं हस्ताक्षरित कंटेंट को नहीं बदलती। एक अक्षुण्ण हस्ताक्षर इसमें बच सकता है। एक जोड़ा गया फ़ुटर बॉडी हैश बदल सकता है। एक पुनर्लिखित हस्ताक्षरित Subject हेडर हस्ताक्षर को अमान्य कर सकता है।
वैकल्पिक l= टैग बॉडी कवरेज को एक निर्दिष्ट बाइट संख्या तक सीमित करता है। l=100 के साथ, पहले 100 नॉर्मलाइज़्ड बाइट के बाद का कंटेंट असुरक्षित रहता है। इसलिए भ्रामक टेक्स्ट जोड़ने से हस्ताक्षर वैध रह सकता है।
जब आपको पूरी बॉडी को सुरक्षित रखना हो तो उस सीमा से बचें। ARC मध्यस्थों को अपने बदलावों से पहले प्रमाणीकरण के हस्ताक्षरित साक्ष्य को संरक्षित करने देता है।
आप Bird के साथ DKIM को कैसे कॉन्फ़िगर करते हैं?
आप अपना भेजने वाला डोमेन रजिस्टर करते समय लौटाया गया DKIM रिकॉर्ड प्रकाशित करते हैं।
API का dkim.mode फ़ील्ड डिफ़ॉल्ट रूप से txt होता है। उस मोड में, सार्वजनिक कुंजी को TXT रिकॉर्ड में प्रकाशित करें। स्कीमा delegated भी सूचीबद्ध करता है। वह मान भेजने वाला डोमेन रजिस्टर करते समय HTTP 422 लौटाता है, इसलिए txt का उपयोग करें।
Bird भेजने वाले डोमेन का उपयोग करने वाले प्रत्येक संगठन के लिए एक अलग कुंजी और सेलेक्टर बनाता है। एक ही डोमेन का उपयोग करने वाले संगठनों को साइनिंग कुंजी साझा करने की आवश्यकता नहीं है।
प्रमाणीकरण गाइड लौटाए गए रिकॉर्ड की व्याख्या करती है।
क्या पास होने वाला हस्ताक्षर यह साबित करता है कि संदेश सुरक्षित है?
पास होने वाला हस्ताक्षर हस्ताक्षरित कंटेंट के लिए ज़िम्मेदारी स्थापित करता है। यह यह स्थापित नहीं करता कि संदेश वांछित या विश्वसनीय है।
यह साइनिंग डोमेन का दृश्यमान From डोमेन से मेल खाना भी आवश्यक नहीं बनाता। DMARC अलाइनमेंट के माध्यम से वह मिलान नियम प्रदान करता है। प्रेषक प्रतिष्ठा, प्रेषक के ट्रैफ़िक का रिसीवर द्वारा मूल्यांकन, एक अलग विचारणीय पहलू है।
संक्षेप में
केवल चुना हुआ कंटेंट सुरक्षित होता है।
DKIM सूचीबद्ध हेडर फ़ील्ड और बॉडी हैश को कवर करता है। असुरक्षित कंटेंट हस्ताक्षर को अमान्य किए बिना बदल सकता है।
सेलेक्टर सत्यापन कुंजियों का पता लगाते हैं।
सेलेक्टर और साइनिंग डोमेन सार्वजनिक कुंजी वाले DNS रिकॉर्ड की पहचान करते हैं।
नॉर्मलाइज़ेशन सत्यापन को प्रभावित करता है।
simple और relaxed एल्गोरिदम फ़ॉर्मेटिंग बदलावों को अलग-अलग तरीके से हैंडल करते हैं।
फ़ॉरवर्डिंग पास होने की गारंटी नहीं देती।
एक अक्षुण्ण हस्ताक्षर फ़ॉरवर्डिंग में बच सकता है, लेकिन हस्ताक्षरित कंटेंट में बदलाव उसे तोड़ सकते हैं।