प्रमाणित रीमेलिंग: प्रत्येक सीमा का स्वामी कौन है?

परिभाषित करें कि रीमेलर किसके लिए जिम्मेदार है

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

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

तीन पहचान प्रश्नों को अलग करें

कनेक्टिंग आईपी और SMTP लिफाफा भेजने वाला बात करने के लिए SPF. हस्ताक्षरित डोमेन और संरक्षित संदेश सामग्री मायने रखती है DKIM. DMARC पूछता है कि क्या योग्य प्रमाणित पहचानकर्ता संदेश के प्रेषक फ़ील्ड से लेखक डोमेन के साथ संरेखित होता है। एक रीमेलर का अपने स्वयं के लिफ़ाफ़ा डोमेन के लिए सफल SPF परिणाम स्वचालित रूप से एक असंबंधित मूल लेखक के लिए एक संरेखित परिणाम नहीं है। ये अलग-अलग प्रश्न हैं, तब भी जब उपयोगकर्ता इंटरफ़ेस एक आश्वस्त "प्रमाणित" लेबल प्रदर्शित करता है। RFC 7208 , खंड 2.4 और RFC 9989 , खंड 4.4 प्रासंगिक सीमाओं को परिभाषित करें.

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

स्वयं के संशोधन जो किसी हस्ताक्षर को तोड़ सकते हैं

एक सेवा जो पादलेख जोड़ती है, एक हस्ताक्षरित विषय फ़ील्ड को बदलती है या संरक्षित सामग्री को फिर से एन्कोड करती है, उसे प्रासंगिक DKIM हस्ताक्षर को समझने की आवश्यकता होती है और कैनॉनिकलाइज़ेशन. कुछ परिवर्तन चयनित विहितीकरण से बचे रहते हैं; अन्य नहीं करते. यह न मानें कि प्रत्येक हेडर परिवर्तन DKIM तोड़ता है, या यह कि "आराम से" कैनोनिकलाइज़ेशन मनमाने ढंग से संपादन की अनुमति देता है। विफलता का निदान करते समय एक मूल प्रति सुरक्षित रखें और वास्तविक हस्ताक्षरित हेडर और बॉडी की तुलना करें। RFC 6376 , अनुभाग 3.4 और 5.4 तंत्र की आपूर्ति करें, किसी विशेष रीमेलर के बारे में कोई वादा नहीं।

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

ARC विश्वास सीमा के साथ साक्ष्य के रूप में मानें

ARC एक मध्यस्थ के प्रमाणीकरण मूल्यांकन और हैंडलिंग की एक सत्यापन योग्य श्रृंखला ले जा सकता है। इसका सत्यापन सौम्य सामग्री को प्रमाणित नहीं करता है या यह स्थापित नहीं करता है कि प्रत्येक सीलिंग डोमेन भरोसेमंद है। अंतिम प्राप्तकर्ता को यह तय करना होगा कि उस जानकारी का उपयोग कैसे किया जाए। श्रृंखला, सीलिंग डोमेन, प्राप्तकर्ता का मूल्यांकन और स्थानीय स्वभाव को अलग-अलग संरक्षित करें। ARC पास संरेखित DKIM पास की स्थानापन्न प्रविष्टि नहीं है। RFC 8617 , धारा 7 और 9.

मानकों की स्थिति के लिए भी एक तारीख की आवश्यकता होती है। 8 नवंबर 2026 को, RFC 8617 प्रायोगिक बना रहेगा। सक्रिय draft-ietf-dmarc-arc-to-historic-01 प्रयोग को समाप्त करने और RFC को ऐतिहासिक में ले जाने का प्रस्ताव करता है; यह एक कार्य प्रगति पर है, कोई अधिनियमित पुनर्वर्गीकरण नहीं। एक सेवा मूल्यांकन को सार्वभौमिक ARC तैनाती या पूर्ण सेवानिवृत्ति को तथ्य के रूप में प्रस्तुत किए बिना उस प्रस्ताव का खुलासा करना चाहिए। वर्तमान ड्राफ्ट स्थिति.

सीमा के माध्यम से एक काल्पनिक संदेश का पालन करें

notices@sender.example से एक काल्पनिक संदेश पर विचार करें, जो एक पूर्व छात्र फारवर्डर के माध्यम से अंतिम मेलबॉक्स में भेजा गया था। मान लें कि मूल स्ट्रीम में एक संरेखित DKIM हस्ताक्षर है। फारवर्डर लिफाफा प्रेषक को अपने डोमेन में बदल देता है लेकिन संरक्षित संदेश को अपरिवर्तित छोड़ देता है। अंतिम प्राप्तकर्ता से अपेक्षित प्रश्न यह है कि क्या वह मूल हस्ताक्षर अभी भी मान्य और संरेखित है। नए लिफाफे का SPF परिणाम एक अलग पहचान प्रश्न का उत्तर देता है। यह उदाहरण एक तर्क अभ्यास है; कोई संदेश, DNS प्रतिक्रिया या रिसीवर परिणाम एकत्र नहीं किया गया था।

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

डिलीवरी का वादा किए बिना जिम्मेदारी स्वीकार करें

जब प्राप्तकर्ता सर्वर संदेश डेटा के बाद सकारात्मक पूर्ण प्रतिक्रिया देता है तो SMTP जिम्मेदारी स्थानांतरित हो जाती है। वह सर्वर तब डिलीवरी या उचित बाद की विफलता प्रबंधन का मालिक होता है। यह परिवहन जिम्मेदारी इनबॉक्स प्लेसमेंट या प्रत्येक बाद के हॉप पर निरंतर प्रमाणीकरण के वादे से भिन्न होती है। एक रीमेलर को उस स्थानांतरण को समझाने के लिए पर्याप्त कतार पहचानकर्ता, टाइमस्टैम्प और बंधे हुए डायग्नोस्टिक रिकॉर्ड को बनाए रखना चाहिए। RFC 5321 , खंड 4.2.5.

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

सबूत अभी भी आवश्यक है

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