एकाधिक BIMI रिकॉर्ड और चयनकर्ता विरोध

एक संदेश और एक इच्छित दावे से शुरुआत करें

एक डोमेन में कई हो सकते हैं BIMI उन सभी का उपयोग करते हुए प्रत्येक संदेश के बिना दावे। इच्छित डिज़ाइन विशिष्ट उपयोग करता है चयनकर्ता विभिन्न दावों की पहचान करने के लिए नाम। संघर्ष एक अलग स्थिति है: एक मालिक के नाम पर डुप्लिकेट उम्मीदवार रिकॉर्ड, परस्पर विरोधी चयनकर्ता हेडर, या एक भेजने वाला प्लेटफ़ॉर्म जो ऑपरेटर की अपेक्षा के अलावा किसी अन्य चयनकर्ता को चुनता है। उन रिकॉर्ड्स को हटाने से पहले इन मामलों का अलग से निदान करें जो किसी अन्य वैध मेल स्ट्रीम का समर्थन कर सकते हैं।

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

चयनकर्ताओं को डुप्लिकेट रिकॉर्ड से अलग करें

BIMI समूह मार्गदर्शन प्रपत्र चयनकर्ता के अभिकथन नामों का वर्णन करता है। _bimi.domain , जब कोई विकल्प नहीं चुना जाता है तो पारंपरिक चयनकर्ता के रूप में डिफ़ॉल्ट होता है। यह एक BIMI-चयनकर्ता हेडर का वर्णन करता है जिसमें BIMI संस्करण और चयनकर्ता नाम होता है, जो दावे का चयन करने के लिए दृश्यमान डोमेन के साथ संयुक्त होता है। विभिन्न चयनकर्ताओं के अंतर्गत अलग-अलग दावे एकाधिक लोगो के लिए तंत्र हैं; एक ही नाम पर कई प्रतिस्पर्धी दावे जोड़ना एक ही डिज़ाइन नहीं है। BIMI चयनकर्ता मार्गदर्शन

एक सूची के लिए, प्रत्येक मालिक का नाम, इच्छित स्ट्रीम, संपत्ति और जिम्मेदार टीम को सूचीबद्ध करें। default._bimi.example.com seasonal._bimi.example.com से और भेजने वाले उपडोमेन के अंतर्गत समान रूप से नामित रिकॉर्ड से अलग करें। ये उदाहरण नाम उदाहरणात्मक हैं, न कि वे रिकॉर्ड जिनसे पूछताछ की गई थी। उनके अर्थों को एक एकल "डोमेन में BIMI है" परिणाम में विलय न करें, क्योंकि संदेश का चयनित नाम प्रासंगिक प्रारंभिक बिंदु है।

TXT डेटा को DNS रिकॉर्ड के रूप में पढ़ें, संपादक पंक्तियों के रूप में नहीं

DNS TXT संसाधन रिकॉर्ड में एक या अधिक वर्ण स्ट्रिंग हो सकते हैं। उस तार-स्तरीय संरचना का मतलब है कि एक डिस्प्ले में कई उद्धृत टुकड़े जरूरी नहीं कि कई रिकॉर्ड हों। इसके विपरीत, दो अलग-अलग रिकॉर्ड प्रदाता इंटरफ़ेस में एक समूहीकृत प्रविष्टि की तरह दिख सकते हैं। यह निर्णय लेने से पहले कि डोमेन में डुप्लिकेट दावे हैं, वास्तविक लौटाई गई रिकॉर्ड सीमाओं का निरीक्षण करें। RFC 1035 TXT प्रारूप

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

भेजने वाली पाइपलाइन के माध्यम से चयनकर्ता का पता लगाएं

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

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

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

एक विश्वसनीय सत्यापन सीमा स्थापित करें

Authentication-Results यह तभी उपयोगी है जब उपभोक्ता को पता हो कि इसे किस विश्वसनीय प्रणाली ने उत्पादित किया है। एक मनमाना हेडर में एक अविश्वसनीय दावा शामिल हो सकता है। RFC 8601 इस ट्रस्ट सीमा का वर्णन करता है; स्रोत के बिना चिपकाए गए परिणाम को स्वीकार करने के बजाय रिसीवर-मूल साक्ष्य या किसी अन्य स्पष्ट रूप से विश्वसनीय सत्यापनकर्ता का उपयोग करें। BIMI निर्णय रखें, DMARC परिणाम और DKIM जांच में अलग कवरेज. RFC 8601 ट्रस्ट सीमाएँ

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

मूल चयनकर्ता-संघर्ष कार्यपत्रक

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

• संदेश की पहचान: प्राप्ति का समय, डोमेन से दृश्यमान और अधिकृत साक्ष्य स्थान।
• चयनकर्ता स्थिति: अनुपस्थित, एकल या एकाधिक हेडर घटनाएँ, सटीक बनाए गए मानों के साथ।
• हस्ताक्षर कवरेज: संरेखित DKIM पहचान, हस्ताक्षरित-हेडर सूची और विश्वसनीय सत्यापन परिणाम।
• DNS लक्ष्य: चयनित स्वामी का नाम, सार्वजनिक प्रतिक्रिया, रिकॉर्ड सीमाएँ और अवलोकन समय।
• अभिकथन स्वामित्व: इच्छित स्ट्रीम, परिसंपत्ति, प्रमाणपत्र निर्भरता और DNS परिवर्तन स्वामी।
• संघर्ष: डुप्लिकेट दावे, बेमेल चयनकर्ता, अहस्ताक्षरित प्राथमिकता या अनसुलझे रिसीवर व्यवहार।
• प्रस्तावित सुधार: सटीक प्रभावित रिकॉर्ड या कॉन्फ़िगरेशन, अनुमोदन और रोलबैक योजना भेजना।
• समापन: ताजा नियंत्रित संदेश, संबंधित DNS अवलोकन और विश्वसनीय रिसीवर परिणाम।

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

काल्पनिक उदाहरण: दो टीमें डिफ़ॉल्ट नाम साझा करती हैं

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

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

केवल वही शृंखला बंद करें जो देखी गई थी

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

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