BIMI रिकॉर्ड प्रदर्शन की गारंटी नहीं है
A BIMI रिकॉर्ड बिल्डर प्रस्तावित DNS दावे को प्रारूपित करने में मदद कर सकता है, लेकिन यह गारंटी नहीं दे सकता कि रिसीवर लोगो दिखाएगा। प्रकाशन, परिसंपत्ति वैधता, चिह्न साक्ष्य, प्रमाणीकरण पात्रता और रिसीवर नीति अलग-अलग शर्तें हैं। बिल्डर को प्रत्येक क्षेत्र के पीछे के निर्णयों की व्याख्या करनी चाहिए और यह पहचानना चाहिए कि क्या असत्यापित रह गया है। उन सीमाओं के बिना एक प्रतिलिपि योग्य रिकॉर्ड एक उपयोगी कॉन्फ़िगरेशन सहायता को एक असमर्थित वादे में बदल सकता है।
बरकरार रखा गया BIMI समूह कार्यान्वयन गाइड जबकि, व्यावहारिक सेटअप का वर्णन करता है Google का सेटअप दस्तावेज़ इसकी रिसीवर-विशिष्ट आवश्यकताओं का वर्णन करता है। कोई भी स्रोत यह साबित नहीं करता है कि EmailAuth एक बिल्डर को लागू करता है या प्रत्येक रिसीवर समान व्यवहार करता है। यह पांडुलिपि आउटपुट और परीक्षण आवश्यकताओं का प्रस्ताव करती है; वास्तविक डोमेन के लिए कोई रिकॉर्ड तैयार नहीं किया गया, प्रकाशित या स्कैन नहीं किया गया।
डोमेन और चयनकर्ता संदर्भ स्थापित करें
इच्छित भेजने वाले डोमेन को रिकॉर्ड करें, चयनकर्ता, DNS प्रकाशन स्वामी और अनुमोदित लोगो पहचान। एक बिल्डर को चुपचाप यह नहीं मान लेना चाहिए कि डिफ़ॉल्ट चयनकर्ता प्रत्येक संदेश या प्रत्येक ब्रांड वर्कफ़्लो का प्रतिनिधित्व करता है। BIMI समूह का चयनकर्ता मार्गदर्शन चयनकर्ता के उपयोग और संदेश सिग्नलिंग से उसके संबंध की व्याख्या करता है। लागू चयनकर्ता को इच्छित भेजने की प्रक्रिया से जुड़ा होना चाहिए न कि केवल इसलिए चुना जाना चाहिए क्योंकि उसका DNS नाम परिचित है।
रखना BIMI चयनकर्ता नाम से अलग DKIM चयनकर्ता. वे अलग-अलग उद्देश्यों की पूर्ति करते हैं और अलग-अलग लुकअप संदर्भों पर कब्जा करते हैं। एक बिल्डर को अपने द्वारा प्रस्तावित प्रकाशन स्वामी के नाम की व्याख्या करनी चाहिए, जिसमें यह भी शामिल होना चाहिए कि DNS संपादक सापेक्ष या पूरी तरह से योग्य नामों की अपेक्षा कैसे करता है। इसे किसी डोमेन प्रत्यय की आँख बंद करके नकल नहीं करनी चाहिए या यह दावा नहीं करना चाहिए कि एक प्रदाता का इनपुट कन्वेंशन हर जगह लागू होता है। मौजूदा स्थिति और प्रदाता के व्यवहार को प्रकाशन से पहले अधिकृत समीक्षा की आवश्यकता होती है।
प्रत्येक प्रस्तावित क्षेत्र की व्याख्या करें
एनोटेशन को संस्करण दावे, लोगो-स्थान फ़ील्ड और लक्षित मार्गदर्शन या विनिर्देश संस्करण द्वारा समर्थित किसी भी साक्ष्य-स्थान फ़ील्ड की पहचान करनी चाहिए। इसमें बताया जाना चाहिए कि कौन से मान आपूर्ति किए गए हैं, कौन से प्लेसहोल्डर हैं और इच्छित रिसीवर के लिए उनकी आवश्यकता क्यों है। डोमेन स्वामी की स्वीकृति और इस साक्ष्य के बिना कि समापन बिंदु इच्छित संपत्ति प्रदान करता है, वास्तविक यूआरएल या प्रमाणपत्र स्थान सम्मिलित न करें।
अज्ञात या असमर्थित फ़ील्ड को बिल्डर के स्वयं के सत्यापन में स्पष्ट हैंडलिंग की आवश्यकता होती है। क्योंकि BIMI मार्गदर्शन और प्रस्ताव विकसित होते हैं, उपकरण को प्रत्येक टैग के लिए एक सार्वभौमिक प्रसंस्करण नियम का आविष्कार करने के बजाय इसके समर्थित नियम सेट की पहचान करनी चाहिए। परीक्षण योजना को उस इनपुट को अलग करना चाहिए जिसे बिल्डर उस दावे से उत्पन्न करने से इनकार करता है कि प्रत्येक रिसीवर एक अपरिचित दावे को कैसे संभालता है। यहां किसी भी असमर्थित-टैग व्यवहार का परीक्षण नहीं किया गया।
संपत्ति और HTTPS पूर्वापेक्षाएँ सत्यापित करें
BIMI ग्रुप एसवीजी मार्गदर्शन सख्त एसवीजी पोर्टेबल/सिक्योर प्रोफ़ाइल का वर्णन करता है। किसी बिल्डर को किसी छवि यूआरएल को समकक्ष साक्ष्य के रूप में स्वीकार नहीं करना चाहिए। प्रस्तावित आउटपुट में संरचनात्मक और दृश्य समीक्षा को अलग रखते हुए, एक अनुमोदित परिसंपत्ति को बरकरार रखी गई सामग्री हैश और सत्यापन रिकॉर्ड के साथ संदर्भित करना चाहिए। ब्राउज़र में दिखाई देने वाला लोगो अभी भी प्रासंगिक प्रोफ़ाइल आवश्यकताओं में विफल हो सकता है।
Google को अपने दस्तावेज़ सेटअप में BIMI फ़ाइलों के लिए HTTPS होस्टिंग की आवश्यकता है। बिल्डर को यह पहचानना चाहिए कि क्या होस्टिंग एंडपॉइंट की जाँच की गई है और क्या प्राप्त बाइट्स स्वीकृत संपत्ति से मेल खाते हैं। HTTPS ट्रांसपोर्ट साक्ष्य मार्क-सर्टिफिकेट पात्रता या रिसीवर डिस्प्ले स्थापित नहीं करता है। यदि कोई फ़ेच नहीं किया गया है, तो आउटपुट को https उपसर्ग को एक सफल कनेक्शन परीक्षण मानने के बजाय असत्यापित कहना चाहिए।
स्कोप मार्क साक्ष्य और रिसीवर आवश्यकताएँ
Google के बनाए गए मार्गदर्शन में कहा गया है कि Gmail एक समर्थित की आवश्यकता है VMC या CMC और वीएमसी-संबंधित चेकमार्क भेद का वर्णन करता है। अन्य प्राप्तकर्ताओं के पास अलग-अलग पात्रता नियम हो सकते हैं। बिल्डर को यह पूछना चाहिए कि कौन से रिसीवर मायने रखते हैं और साक्ष्य-स्थान फ़ील्ड को सार्वभौमिक रूप से पर्याप्त या अनावश्यक के रूप में प्रस्तुत करने से पहले अपनी वर्तमान आवश्यकताओं का हवाला देना चाहिए। यूआरएल दर्ज करने से प्रमाणपत्र खरीद या जारीकर्ता की मंजूरी निहित नहीं होती है।
The Yahoo BIMI मार्गदर्शन VMC आवश्यकताओं और अन्य पात्रता संबंधी विचारों के उपचार सहित एक अलग रिसीवर दायरे को दर्शाता है। यह कंट्रास्ट सावधानीपूर्वक प्राप्तकर्ता-विशिष्ट समीक्षा का समर्थन करता है, न कि यह दावा कि प्रकाशित चेकलिस्ट को पूरा करने वाला प्रत्येक संदेश एक लोगो प्रदर्शित करेगा। बिल्डर को अपूर्ण कॉन्फ़िगरेशन को गारंटीकृत ब्रांड दृश्यता के रूप में लेबल करने से बचना चाहिए।
DMARC पात्रता और प्रेषक की तैयारी को अलग रखें
BIMI रिसीवर मार्गदर्शन DMARC-संबंधित शर्तों को लागू कर सकता है, लेकिन एक बिल्डर को यह नहीं मानना चाहिए कि DNS प्रवर्तन नीति प्रत्येक वैध प्रेषक को संरेखित करती है। RFC 9989 वर्तमान को परिभाषित करता है DMARC व्यवहार और उसकी सीमाएँ। प्रस्तावित BIMI आउटपुट को लोगो सेटअप फॉर्म को संतुष्ट करने के लिए प्रमाणीकरण नीति को चुपचाप बदलने के बजाय एक अलग तत्परता मूल्यांकन से लिंक करना चाहिए।
जहां रिसीवर दस्तावेज़ीकरण उन सम्मेलनों का उपयोग करता है जो वर्तमान प्रोटोकॉल शब्दावली से भिन्न होते हैं, स्रोत तिथियों और प्रयोज्यता प्रश्न को बनाए रखते हैं। किसी नीति को स्वचालित रूप से दोबारा न लिखें या नए संस्करण टोकन का आविष्कार न करें। BIMI बिल्डर का कार्य DMARC संशोधित करने, मार्क साक्ष्य खरीदने या आपूर्तिकर्ता के भेजने के कॉन्फ़िगरेशन को बदलने की अनुमति नहीं है। उन निर्णयों को अपने स्वयं के अनुमोदित दायरे और सत्यापन की आवश्यकता होती है।
एक सटीक-रिकॉर्ड परिवर्तन योजना तैयार करें
मौजूदा स्थिति का निरीक्षण करना और एक इच्छित अंतर तैयार करना प्रकाशन से अलग है। बिल्डर को एक अनुमोदित रिकॉर्ड के प्रतिस्थापन को उसी मालिक के प्रतिस्पर्धी दावे को जोड़ने से अलग करना चाहिए। RFC 1035 TXT संरचना को परिभाषित करता है, जिसमें स्ट्रिंग्स के बीच अंतर भी शामिल है एक अभिलिखित और अलग रिकॉर्ड. परिवर्तन योजना में असंबंधित TXT डेटा और संपूर्ण प्रभावित रिकॉर्ड सेट को सुरक्षित रखें।
पुनर्स्थापना सामग्री, मालिक की मंजूरी और परिवर्तन के बाद की अवलोकन योजना को रिकॉर्ड करें। जेनरेट की गई स्ट्रिंग को स्वचालित रूप से DNS लेखन को अधिकृत नहीं करना चाहिए। यदि उपकरण प्रकाशन का समर्थन करता है, तो उस क्षमता के लिए किरायेदार बंधन, अनुमोदन और सत्यापन के अलग-अलग साक्ष्य की आवश्यकता होती है; यह पांडुलिपि कोई दावा नहीं करती कि EmailAuth इसे प्रदान करता है। इस अभ्यास के लिए कोई DNS स्थिति पढ़ी या बदली नहीं गई।
एक एनोटेटेड-बिल्डर वर्कशीट
डोमेन, चयनकर्ता, सटीक प्रकाशन स्वामी, प्रस्तावित दावा, प्रत्येक क्षेत्र का उद्देश्य, संपत्ति हैश, समापन बिंदु साक्ष्य, चिह्न-साक्ष्य स्थिति और इच्छित रिसीवर के साथ एक वर्कशीट बनाएं। स्रोत-नियम संस्करण, वर्तमान-स्थिति संदर्भ, इच्छित अंतर, अनुमोदन स्वामी और अनसुलझे पूर्वापेक्षाएँ जोड़ें। आउटपुट वैधता, परिचालन तत्परता और रिसीवर डिस्प्ले को अलग-अलग स्थितियों के रूप में रखें।
आवश्यक परीक्षण मामलों में सकारात्मक समर्थित दावा, अमान्य इनपुट, डुप्लिकेट रिकॉर्ड और असमर्थित फ़ील्ड शामिल होने चाहिए। अधिकृत परीक्षण चलाने के बाद प्रत्येक मामले में मूल इनपुट, अपेक्षित व्यवहार और वास्तविक टूल आउटपुट की आवश्यकता होती है। किसी फिक्स्चर को पारित का लेबल न दें क्योंकि प्रस्तावित आउटपुट प्रशंसनीय लगता है। एक दस्तावेज़ीकरण उदाहरण एक निष्पादित बिल्डर परीक्षण नहीं है, और इस मसौदे में न तो कोई उत्पादन रिकॉर्ड है और न ही मापा परिणाम शामिल हैं।
काल्पनिक निदान: प्रदर्शन साक्ष्य के बिना एक वैध दावा
एक काल्पनिक टीम एक लोगो की ओर इशारा करते हुए वाक्यात्मक रूप से प्रशंसनीय BIMI रिकॉर्ड तैयार करती है और मानती है कि अब प्रत्येक प्राप्तकर्ता इसे देखेगा। प्रस्तावित समीक्षा पूछती है कि क्या परिसंपत्ति प्रोफ़ाइल से मेल खाती है, क्या HTTPS पुनर्प्राप्ति सत्यापित की गई थी, कौन से चिह्न साक्ष्य मौजूद हैं और कौन सी रिसीवर आवश्यकताएं लागू होती हैं। रिकॉर्ड का स्वरूपण स्वयं इनमें से किसी भी प्रश्न का उत्तर नहीं देता है।
टीम प्रदर्शन तत्परता को अनसुलझा छोड़ देगी और लापता अधिकृत साक्ष्य एकत्र करेगी। यह केवल बिल्डर का दर्जा हरित बनाने के लिए प्रमाणपत्र नहीं खरीदेगा या प्रमाणीकरण नीति में बदलाव नहीं करेगा। यह परिदृश्य काल्पनिक है और वास्तविक रिसीवर विफलता या उत्पाद सीमा का वर्णन नहीं करता है। यह दर्शाता है कि आउटपुट को एनोटेट और सशर्त क्यों रहना चाहिए।
केवल प्रदर्शित दावा ही प्रकाशित करें
कैटलॉग को एक एनोटेटेड रिकॉर्ड और सकारात्मक, अमान्य, डुप्लिकेट और असमर्थित-टैग परीक्षण मामलों की आवश्यकता होती है। वे मूल कलाकृतियाँ खुली रहती हैं, जैसे मानव विशेषज्ञ समीक्षा, स्रोत प्रयोज्यता, उत्पादन मार्ग, पहुंच और मालिक की रिहाई। यह मसौदा आवश्यकताओं और एक काल्पनिक अभ्यास की आपूर्ति करता है, न कि कार्यान्वित उपकरण व्यवहार या लोगो प्रदर्शन का वादा। एक प्रकाशन योग्य उदाहरण को रिसीवर के विवेक को दृश्यमान रखते हुए वास्तविक समर्थित आउटपुट और परीक्षणों को बनाए रखना चाहिए।