संशोधन इतिहास को साक्ष्य मानें, अनुमति नहीं
किसी वैध कारण से मेलिंग सूची में पादलेख जोड़ा जा सकता है या विषय फ़ील्ड को संशोधित किया जा सकता है। एक शत्रुतापूर्ण मध्यस्थ किसी संदेश को बदल भी सकता है। महत्वपूर्ण प्रश्न केवल यह नहीं है कि क्या कुछ बदला है, बल्कि यह है कि क्या प्राप्तकर्ता प्रासंगिक इतिहास का पुनर्निर्माण कर सकता है, जिम्मेदार डोमेन को सत्यापित कर सकता है और यह तय कर सकता है कि उस इतिहास का क्या अर्थ है। DKIM2 पहले दो कार्यों के लिए मशीनरी का प्रस्ताव करता है; यह स्वचालित रूप से तीसरे का उत्तर नहीं देता है।
इस स्पष्टीकरण को पिन किया गया है draft-ietf-dkim-dkim2-spec-09, दिनांक 1 नवंबर 2026 और वर्तमान में एक सक्रिय इंटरनेट-ड्राफ्ट। इसके प्रस्तावित सत्यापन में अघोषित संशोधनों और वितरण पथ की निरंतरता पर चिंता व्यक्त की गई है। धारा 14.1 स्पष्ट रूप से उन चेकों को संदेश के मूल्य या घोषित परिवर्तनों की सौम्यता से अलग करती है। एक सत्यापित श्रृंखला पूर्ण विश्वास अनुशंसा नहीं है।
एक मूल लेकिन स्पष्ट रूप से काल्पनिक पथ बनाएँ
तीन आविष्कृत प्रणालियों पर विचार करें: author.larch.example , list.fir.example और inbox.birch.example । पहला एक संदेश बनाता है जिसके मुख्य भाग में दो पंक्तियाँ होती हैं, "एजेंडा" और "शुक्रवार दोपहर।" सूची में बिना किसी मुख्य भाग को बदले एक तीसरी पंक्ति, "सूची पादलेख" जोड़ दी जाती है। मान लें कि डोमेन, लिफ़ाफ़ा पते, घड़ियाँ और कुंजियाँ प्रासंगिक जांच को पूरा करेंगी। ये निर्धारित शिक्षण इनपुट हैं, कोई कैप्चर किया गया संदेश या सबूत नहीं जिसे कोई हस्ताक्षर सत्यापित करता है।
उत्पत्ति के समय, प्रस्तावित प्रतिनिधित्व में मूल हेडर और बॉडी हैश के साथ संदेश-इंस्टेंस m=1 और उस उदाहरण को संदर्भित करते हुए DKIM2-सिग्नेचर i=1 शामिल है। सूची में बदलाव के बाद, दूसरा उदाहरण वर्तमान हैश और पिछले फॉर्म को फिर से बनाने के लिए आवश्यक जानकारी को रिकॉर्ड करता है। सूची उचित अनुक्रम और उदाहरण संदर्भ के साथ अपना स्वयं का हस्ताक्षर जोड़ती है। इस उदाहरण में हैश मान और हस्ताक्षर बाइट्स का जानबूझकर आविष्कार नहीं किया गया है।
बताएं कि व्यंजन पीछे की ओर क्यों चलते हैं
धारा 5 और 12.1 पहले की संदेश सामग्री को दोबारा बनाने की विधि का वर्णन करें। काल्पनिक निकाय मामले में, मूल का पुनर्निर्माण करने का अर्थ है पहली दो वर्तमान पंक्तियों को बनाए रखना और संलग्न पाद लेख को बाहर करना। नुस्खा बताता है कि पुरानी स्थिति को नई स्थिति से कैसे पुनर्प्राप्त किया जाए; यह केवल "पाद लेख जोड़ें" कहने वाला निर्देश नहीं है। एक वास्तविक फिक्स्चर के लिए बाइट-सटीक सामग्री और ड्राफ्ट के सटीक एन्कोडिंग नियमों की आवश्यकता होगी।
हेडर-परिवर्तन संस्करण को अपने स्वयं के पुनर्निर्माण साक्ष्य की आवश्यकता होती है। यदि किसी सूची में विषय उपसर्ग होता है, तो मूल मान पहले हेडर-हैश जांच के लिए पुनर्प्राप्त करने योग्य होना चाहिए। मूल फ़ील्ड, संशोधित फ़ील्ड और रेसिपी को एक साथ रिकॉर्ड करें ताकि एक समीक्षक यह निर्धारित कर सके कि परिवर्तन का ईमानदारी से प्रतिनिधित्व किया गया था या नहीं। रेंडर किए गए मेल-क्लाइंट स्क्रीनशॉट पर भरोसा न करें, जो सत्यापनकर्ता से संबंधित फोल्डिंग, एन्कोडिंग और डुप्लिकेट-फ़ील्ड विवरण छिपा सकता है।
नवीनतम हस्ताक्षर से अधिक सत्यापित करें
अंतर्गत धारा 13, पूर्ण सत्यापन बाद के व्यंजनों को अवरोही क्रम में लागू करने के साथ-साथ हस्ताक्षर श्रृंखला को लागू करके पुनर्निर्माण किए गए पहले संदेश उदाहरणों की जांच करता है। केवल अंतिम प्रदर्शित बॉडी और सबसे हालिया हस्ताक्षर की जाँच करना एक अलग, संकीर्ण ऑपरेशन है। मसौदे में सीमित प्रारंभिक मूल्यांकन के लिए अनंतिम सत्यापन को अलग से परिभाषित किया गया है; दोनों परिणामों में अयोग्य हरा बैज नहीं होना चाहिए।
रिसीवर को डिलीवरी संदर्भ की भी आवश्यकता होती है। धारा 14.4 नवीनतम हस्ताक्षरित लिफाफे की जानकारी की तुलना वास्तविक SMTP लेनदेन से करती है, जबकि पहले के हॉप्स को श्रृंखला नियमों को पूरा करना होगा। धारा 14.8 उपयुक्त हस्ताक्षरित पहचानों के विरुद्ध प्रासंगिक वर्तमान और ऐतिहासिक फ़ील्ड की जाँच करता है। एक सामग्री-मात्र संग्रह उन सभी स्थितियों को स्थापित नहीं कर सकता है यदि उसने मूल लिफाफा और स्वीकृति-समय साक्ष्य खो दिया है।
काल्पनिक पथ के लिए, अपेक्षित समीक्षा क्रम इस प्रकार है: सिंटैक्स और ऑर्डरिंग का निरीक्षण करें, SMTP संदर्भ को बनाए रखें, टाइमस्टैम्प की जांच करें, श्रृंखला और कुंजियों को मान्य करें, हस्ताक्षरों को सत्यापित करें, प्रत्येक प्रासंगिक उदाहरण का पुनर्निर्माण करें, हैश की तुलना करें और प्रामाणिकता से आकलन करें। यह एक प्रस्तावित तर्क ट्रेस है. यह दावा नहीं है कि किसी विशेष सॉफ़्टवेयर पैकेज ने उन चरणों को निष्पादित किया या PASS लौटाया।
अशक्त व्यंजनों और संपादन को दृश्यमान रखें
मसौदा यह इंगित करने के लिए एक शून्य निकाय नुस्खा की अनुमति देता है कि पहले वाले निकाय का पुनर्निर्माण नहीं किया जा सकता है। यह हेडर परिवर्तन के लिए शून्य व्यंजनों की अनुमति नहीं देता है। यह अंतर उस गेटवे के लिए मायने रखता है जो गोपनीय सामग्री को हटा देता है: एक प्रतिवर्ती नुस्खा उसी सामग्री को बरकरार रख सकता है जिसे गेटवे हटाना चाहता था। गोपनीयता समीक्षा में रेसिपी पेलोड की जांच होनी चाहिए, न कि केवल प्राप्तकर्ता को दिखाई देने वाले अंतिम निकाय की।
कोर -09 खंड 13 कहता है कि शून्य रेसिपी के नीचे पहले के बॉडी हैश की जाँच नहीं की जा सकती और संदेश पूरी तरह से सत्यापित नहीं है। स्थानीय नीति फिर भी इसे स्वीकार कर सकती है, उदाहरण के लिए एक उपयुक्त संबंध के तहत। यह लुप्त साक्ष्यों को क्रिप्टोग्राफ़िक रूप से पुनर्स्थापित करने के बराबर नहीं है। प्रयोगशाला को परिणाम पूर्ण सत्यापन का नाम बदलने के बजाय अनुपलब्ध ऐतिहासिक-निकाय जांच और अलग स्थानीय स्वीकृति निर्णय की रिपोर्ट करनी चाहिए।
अनुरोधों को प्रवर्तनीय विश्वास के साथ भ्रमित न करें
अलग CanModify -00 ड्राफ्ट संशोधनों के बारे में प्रवर्तक अनुरोधों की पड़ताल करता है। इसे 2 नवंबर को एक व्यक्तिगत इंटरनेट-ड्राफ्ट के रूप में प्रकाशित किया गया था। इसका उपचार स्थानीय नीति है, और कुछ सौम्य चर्चा स्पष्ट रूप से अधूरी रहती है। इसे सार्वभौमिक परिनियोजित अनुमति प्रणाली के रूप में कोर -09 में विलय नहीं किया जाना चाहिए।
यह ऑपरेटरों के लिए एक व्यावहारिक अंतर पैदा करता है। एक रेसिपी एट्रिब्यूशन का समर्थन कर सकती है, एक प्रवर्तक अनुरोध एक प्राथमिकता व्यक्त कर सकता है, और एक रिसीवर यह तय कर सकता है कि परिणामी संदेश को स्वीकार करना है या नहीं। कोई भी अकेला यह साबित नहीं कर सकता कि संशोधित संदेश सुरक्षित है। समीक्षक नोट्स को यह पहचानना चाहिए कि देखे गए परिणाम वास्तव में उनमें से किस प्रश्न का उत्तर देते हैं, खासकर जब कोई उत्पाद रिपोर्ट "विश्वसनीय" शब्द को परिभाषित किए बिना उपयोग करती है।
सटीक गुम सत्यापन साक्ष्य को अपने पास रखें
सटीक कमीशन है: संस्करण-पिन किए गए ड्राफ्ट मॉडल के माध्यम से एक मूल, संशोधित और सत्यापित संदेश का पता लगाएं। मूल काल्पनिक ट्रेस अपेक्षित संरचना और जांच प्रदान करता है, लेकिन इस पैकेज में कोई हस्ताक्षरित संदेश, गणना की गई हैश, संगत सत्यापनकर्ता आउटपुट या वास्तविक सत्यापित परिणाम मौजूद नहीं है। कमीशनिंग साक्ष्य द्वार एक चित्रण द्वारा बंद होने के बजाय खुला रहता है।
भविष्य के अधिकृत प्रयोग में संदेश प्रपत्र, पुनर्निर्माण डेटा, लिफ़ाफ़ा मेटाडेटा, कुंजी स्नैपशॉट, सॉफ़्टवेयर संस्करण और पूर्ण सत्यापनकर्ता निदान दोनों को संरक्षित किया जाना चाहिए। एक अघोषित-परिवर्तन नियंत्रण और एक अशक्त-नुस्खा संस्करण शामिल करें। तकनीकी और गोपनीयता विशेषज्ञों को किसी भी वास्तविक उपयोग से पहले व्याख्या और प्रदर्शन की समीक्षा करनी चाहिए। उत्पादन प्रयोज्यता, दृश्य समीक्षा और मालिक प्रकाशन अनुमोदन भी उत्कृष्ट हैं; यहां कोई प्रवासन या सार्वभौमिक विश्वास का दावा नहीं किया जाता है।