इच्छित डिलीवरी से वैध हस्ताक्षर को अलग करें
जब हस्ताक्षरित सामग्री को डिलीवरी के संदर्भ में पुन: उपयोग किया जाता है तो मूल हस्ताक्षरकर्ता का इरादा नहीं होता है तो दोबारा खेलना संभव है। हस्ताक्षर गणितीय रूप से मान्य रह सकते हैं क्योंकि कवर किए गए बाइट्स नहीं बदले हैं। इसका मतलब यह नहीं है कि हस्ताक्षरकर्ता ने असीमित पुनर्वितरण को अधिकृत किया है, और यह हर दोहराए गए संदेश को हमला नहीं बनाता है। एक उपयोगी विश्लेषण पूछता है कि कौन सा संदर्भ प्रमाणित है, किस पक्ष ने आगे की डिलीवरी की और एक रिसीवर वास्तव में क्या देख सकता है।
RFC 6376 अनुभाग 8.6 परिचालन संबंधी निर्णय की आवश्यकता वाली सीमाओं के रूप में रीप्ले और स्पैम पर चर्चा करता है। DKIM2 कार्य एक मजबूत हस्ताक्षर एल्गोरिदम को संपूर्ण उत्तर मानने के बजाय अतिरिक्त मार्ग और प्राप्तकर्ता संदर्भ का प्रस्ताव करता है। यह आलेख उपयोग करता है कोर ड्राफ्ट -09, दिनांक 1 नवंबर 2026। यह कार्य प्रगति पर है, कोई प्रकाशित एंटी-रीप्ले गारंटी नहीं है।
दो काल्पनिक वितरण संदर्भों की तुलना करें
क्लासिक-डीकेआईएम शिक्षण मामले में, एक सेवा एकल इच्छित मेलबॉक्स पर भेजे गए संदेश पर हस्ताक्षर करती है। एक तीसरा पक्ष संदेश प्राप्त करता है और अन्य प्राप्तकर्ताओं को अपरिवर्तित हस्ताक्षरित सामग्री भेजता है। यह मानते हुए कि हस्ताक्षरित सामग्री और सत्यापन की शर्तें बरकरार हैं, हस्ताक्षर अभी भी सत्यापित किया जा सकता है। समस्या उस हस्ताक्षरित कलाकृति का पुन: उपयोग है, जरूरी नहीं कि उसके मुख्य भाग में परिवर्तन या हस्ताक्षर कुंजी से समझौता हो।
DKIM2 तुलना के लिए, मान लीजिए कि मूल नवीनतम हस्ताक्षर birch.example पर एक काल्पनिक पते पर डिलीवरी का वर्णन करता है। एक अलग पते पर डिलीवरी करते समय उसी हस्ताक्षरित लिफाफे की जानकारी का पुन: उपयोग करने से ड्राफ्ट की नवीनतम-हॉप प्राप्तकर्ता तुलना विफल हो जानी चाहिए। धारा 14.4 के लिए आवश्यक है कि प्रत्येक वास्तविक आरसीपीटी टू पता हस्ताक्षरित आरटी मान में प्रदर्शित हो, हालाँकि आरटी में अतिरिक्त प्राप्तकर्ता हो सकते हैं। डोमेन केस-असंवेदनशील रूप से तुलना करते हैं; स्थानीय भागों को निर्दिष्ट नियमों के तहत सटीक मिलान की आवश्यकता होती है।
यह एक निर्धारित तुलना है, किसी मेल सर्वर से प्राप्त प्रतिलेख नहीं। यह प्रस्ताव द्वारा जांचे गए अतिरिक्त संदर्भ को अलग करता है। यह दावा नहीं करता है कि केवल DKIM2 कुंजी प्रकाशित करने से एक मौजूदा रिसीवर उन तुलनाओं को निष्पादित करता है, या कि एक विरासत रिसीवर पुन: उपयोग किए गए संदेश को अस्वीकार कर देता है।
जब कोई मध्यस्थ कोई छूट जोड़ता है तो जिम्मेदारी का पालन करें
एक रीप्लेइंग सिस्टम इसके बजाय एक नया वैध हॉप जोड़ सकता है। प्रस्तावित श्रृंखला तब सभी श्रृंखला जांचों के अधीन, आगे की हैंडलिंग से जुड़ी एक हस्ताक्षरित पहचान दर्ज करती है। यह उपयोगी गुण है, लेकिन यह स्वचालित रूप से कार्रवाई को दुर्भावनापूर्ण लेबल नहीं करता है। एक वैध फारवर्डर डिलीवरी जिम्मेदारी भी जोड़ता है। प्राप्तकर्ता को अभी भी मार्ग अपेक्षाओं और मध्यस्थ की प्रतिष्ठा या भूमिका का मूल्यांकन करने की आवश्यकता है।
धारा 15.1 मूल संदेश-उदाहरण m=1 हेडर और बॉडी हैश के साथ-साथ मध्यस्थ उपस्थिति और विस्फोटित ध्वज के बार-बार अवलोकन का उपयोग करने का वर्णन करता है। यह एक सार्वभौमिक वैश्विक डेटाबेस या एक निश्चित वॉल्यूम सीमा को परिभाषित नहीं करता है जिसका प्रत्येक कार्यान्वयन को उपयोग करना चाहिए। केवल एक देखे गए संदेश वाला रिसीवर अनदेखी प्रतियों की गिनती करके बार-बार डिलीवरी स्थापित नहीं कर सकता है।
फटा हुआ झंडा रिपोर्ट करता है कि एक सिस्टम कई पतों पर भेज रहा है। इससे यह पहचानने में मदद मिलती है कि फैन-आउट का दावा कहां किया गया है; यह इस बात का प्रमाणपत्र नहीं है कि प्रशंसकों का स्वागत था। यह सुरक्षित रखें कि कौन सा हस्ताक्षर उस पर है और क्या मार्ग के लिए वह व्यवहार अपेक्षित था। एक डैशबोर्ड जो ध्वज को "रीप्ले सेफ" तक कम कर देता है, उस निर्णय संदर्भ को खारिज कर देगा जिसे ड्राफ्ट उजागर करना चाहता है।
तुलना में वैध दोहराव रखें
एक बड़ी प्राप्तकर्ता सेवा सामान्य थोक वितरण से समान संदेशों का सामना कर सकती है। कई प्राप्तकर्ता उन प्रतियों को भी अग्रेषित कर सकते हैं जो एक ही सेवा में पुनः एकत्रित हो जाती हैं। प्रोटोकॉल पुनः प्रयास कभी-कभी डुप्लिकेट उत्पन्न कर सकता है। मसौदे में इन भेदों पर स्पष्ट रूप से चर्चा की गई है। इसलिए समान हैश की गिनती मूल्यांकन के लिए एक इनपुट है, न कि एक स्टैंडअलोन निर्णय कि किसी भी दूसरी प्रति को अवरुद्ध किया जाना चाहिए।
एक मूल प्रयोगशाला योजना में कम से कम चार मामले होने चाहिए: प्रत्यक्ष इच्छित वितरण, एक अघोषित प्राप्तकर्ता परिवर्तन के साथ आगे पुनर्वितरण, एक उचित रूप से घोषित मध्यस्थ फैन-आउट, और वैध पुन: अभिसरण। जहां संभव हो, संदेश सामग्री को ठीक रखें ताकि स्पष्टीकरण मार्ग संदर्भ को अलग कर दे। फिर प्राप्तकर्ता की दृश्यता बदलती रहती है: एक प्रति, कई प्रतियाँ और अधूरी ऐतिहासिक टिप्पणियाँ। वे प्रस्तावित मामले हैं, इस आलेख के लिए पूर्ण किए गए प्रयोग नहीं।
मूल घड़ी संदर्भ को सुरक्षित रखें
धारा 14.3 जब कोई हस्ताक्षर SMTP स्वीकृति से चौदह दिन से अधिक पुराना हो या स्वीकृति के सापेक्ष भविष्य में एक दिन से अधिक पुराना हो तो पूर्ण-सत्यापन पात्रता को अस्वीकार कर देता है। ड्राफ्ट के लिए उस स्वीकृति समय की सटीक जानकारी आवश्यक है। किसी संग्रहीत संदेश को आज की घड़ी के अनुसार दोबारा जांचना, यह जांचने से भिन्न प्रश्न का उत्तर दे सकता है कि उसके आने पर क्या वैध था।
इसलिए पूर्वव्यापी जांच के लिए मूल आगमन मेटाडेटा की आवश्यकता होती है, न कि केवल एक सहेजी गई संदेश फ़ाइल की। देखे गए समय स्रोत, टाइमस्टैम्प मान, प्रासंगिक DNS /कुंजी संदर्भ और सत्यापनकर्ता संस्करण को बनाए रखें। बाद में गुम हुई कुंजी या बदला हुआ रिकॉर्ड भी यह स्थापित नहीं करता है कि मूल सत्यापनकर्ता ने क्या देखा था। जब तक साक्ष्य मजबूत निष्कर्ष का समर्थन नहीं करता, तब तक "ऐतिहासिक सत्यापन को पुन: पेश नहीं किया जा सकता" को "मूल हस्ताक्षर अमान्य था" से अलग किया जा सकता है।
सट्टा रीप्ले नियंत्रण से बचें
ड्राफ्ट का वैकल्पिक नॉन क्रिएटर के उपयोग के लिए उपलब्ध है, जैसे बाद में डिलीवरी-स्थिति की जानकारी को सहसंबंधित करना। यह अपने आप में एक मानकीकृत एक बार उपयोग वाली प्रवर्तन सेवा नहीं है। इसी प्रकार, पहले भी auth= sender-policy discussion एक अलग प्रस्ताव और मिश्रित-परिनियोजन प्रश्नों से संबंधित है। इसे व्यवस्थित कोर -09 सिंटैक्स के रूप में या इस बात के प्रमाण के रूप में प्रस्तुत नहीं किया जाना चाहिए कि प्रत्येक फारवर्डर संगत व्यवहार का विज्ञापन करता है।
कार्यान्वयन के रीप्ले दावे को एक बंधे हुए प्रश्न के रूप में मानें: कौन से इनपुट को बनाए रखा जाता है, कितने समय तक, किस प्राप्त नोड्स में, किस गलत-सकारात्मक नियंत्रण के साथ? केवल एक सफल क्रिप्टोग्राफ़िक जांच ही नहीं, बल्कि बार-बार किए गए अवलोकनों और मार्ग विश्लेषण के साक्ष्य भी मांगें। गोपनीयता और भंडारण निहितार्थ उस समीक्षा में शामिल हैं क्योंकि पता लगाने का संदर्भ संदेशों में डिलीवरी मेटाडेटा जमा कर सकता है।
बताएं कि यह तुलना क्या स्थापित करती है और क्या स्थापित नहीं करती है
सटीक कमीशन है: किसी क्लासिक की तुलना करें DKIM ड्राफ्ट के विशिष्ट प्रस्तावित डिटेक्शन मॉडल के साथ परिदृश्य को दोबारा चलाएं। उपरोक्त काल्पनिक तुलना लिफ़ाफ़ा बाइंडिंग, मध्यस्थ एट्रिब्यूशन, बार-बार मूल-उदाहरण अवलोकन, समय और दृश्यता सीमा की व्याख्या करती है। यह दस्तावेजी विश्लेषण है, न कि मापी गई पहचान दर, पुनरुत्पादित हमला या रिसीवर इंटरऑपरेबिलिटी परिणाम।
वास्तविक मामले, संस्करणित कार्यान्वयन, बरकरार सत्यापनकर्ता आउटपुट और विशेषज्ञ स्वीकृति खुली रहती है। सुरक्षा स्वामी को भविष्य में किसी भी नियंत्रित प्रयोग को बिना किसी अनचाहे ट्रैफ़िक या उत्पादन-नीति परिवर्तन के अनुमोदित करना होगा। साइट, दृश्य और प्रकाशन द्वार भी उत्कृष्ट बने हुए हैं। बचाव योग्य निष्कर्ष यह है कि प्रस्ताव पुन: उपयोग का पता लगाने और उसे जिम्मेदार ठहराने के लिए संदर्भ जोड़ता है, जबकि वास्तविक प्रभावशीलता कार्यान्वयन, टिप्पणियों और प्राप्तकर्ता के निर्णय पर निर्भर करती है।