लॉन्च तिथि से पहले प्रोजेक्ट के स्वामी को निर्णय दें
BIMI ब्रांड प्रबंधन, कानूनी समीक्षा, DNS प्रशासन, ईमेल संचालन और वेब होस्टिंग के बीच की सीमाओं को पार करता है। एक परियोजना तब भी रुक सकती है जब प्रत्येक टीम अपना कार्य पूरा कर ले: विपणन एक लोगो को मंजूरी देता है, एक प्रमाणपत्र दूसरे संस्करण को कवर करता है, और तीसरी फ़ाइल पर DNS बिंदु। पहला वितरण योग्य एक सहमत दायरा और स्वीकृति रिकॉर्ड होना चाहिए जो उन निर्णयों को जोड़ता है।
एक समन्वयक का नाम बताइए जो अनसुलझे निर्भरताओं को दृश्यमान रख सकता है। भेजने वाले डोमेन, मेल स्ट्रीम, लक्ष्य रिसीवर और वांछित डिस्प्ले सतहों को परिभाषित करें। "हमारा लोगो हर जगह प्रदर्शित करें" कोई परीक्षण योग्य आवश्यकता नहीं है। एक संकीर्ण लक्ष्य, जैसे कि दस्तावेजित Gmail पात्रता के लिए एक अनुमोदित प्रेषक को तैयार करना और एक अलग से पहचाने गए ऐप्पल मेल प्राप्त करने का पथ, टीम को आशाजनक प्रदर्शन के बिना इकट्ठा करने के लिए ठोस सबूत देता है।
BIMI समूह ने चेतावनी दी है कि भाग लेने वाले मेलबॉक्स प्रदाता अपने स्वयं के प्रदर्शन मानदंड लागू करते हैं। प्राप्तकर्ता-विशिष्ट मैट्रिक्स को एक बार कॉपी करके भुला दी गई संगतता चेकलिस्ट के बजाय एक नियोजन इनपुट के रूप में मानें। BIMI कार्यान्वयन मार्गदर्शिका.
साक्ष्यों को विभाजित किए बिना जिम्मेदारियों को विभाजित करें
विपणन को अनुमोदित ब्रांड संस्करण की आपूर्ति करनी चाहिए और बताना चाहिए कि इसका उपयोग कहां किया जाएगा। कानूनी या ब्रांड-अधिकार स्वामी को यह स्थापित करना चाहिए कि उस चिह्न का उपयोग कौन कर सकता है, कौन सी इकाई इसे नियंत्रित करती है और कौन सा प्रमाणपत्र मार्ग उपयुक्त है। ईमेल व्यवस्थापक को प्रस्तावित प्रमाणीकरण नीति से प्रभावित प्रत्येक वैध प्रेषक की सूची बनानी चाहिए। DNS और होस्टिंग मालिकों को अपने परिवर्तन नियंत्रण, सार्वजनिक समापन बिंदु और पुनर्प्राप्ति विकल्पों की पहचान करनी चाहिए।
निर्णयों को एक प्रस्तावित स्वीकृति पैकेट में संग्रहीत करें। प्रत्येक अनुमोदन के लिए एक दायरे, दिनांक और संदर्भित संपत्ति या कॉन्फ़िगरेशन संस्करण की आवश्यकता होती है। जब कई फ़ाइलें एक नाम साझा करती हैं तो "लोगो स्वीकृत" अपर्याप्त है। एक फ़ाइल हैश अनुमोदन को विशिष्ट बाइट्स से जोड़ता है, जबकि डोमेन सूची इसे एक परिभाषित प्रेषक दायरे से जोड़ती है। यह यहां प्रस्तावित एक परिचालन नियंत्रण है, यह दावा नहीं है कि कोई अनुमोदन प्राप्त किया गया है।
समन्वयक को उन लोगों की भी पहचान करनी चाहिए जो खर्च, प्रमाणपत्र नामांकन, बाहरी डेटा साझाकरण और DNS परिवर्तनों को मंजूरी दे सकते हैं। तकनीकी तैयारी स्वयं उन परिणामी कार्रवाइयों को अधिकृत नहीं करती है। उन स्वीकृतियों को संपादक के इस निर्णय से अलग रखें कि लेख या चेकलिस्ट पूरी हो गई है।
प्रमाणीकरण तत्परता को पहला तकनीकी मील का पत्थर बनाएं
मजबूत प्रवर्तन का अनुरोध करने से पहले, डोमेन का उपयोग करने वाले विपणन, लेन-देन, समर्थन और कर्मचारी मेल की सूची बनाएं। प्रासंगिक मार्गों के लिए वास्तविक प्राप्त-संदेश पहचान और परिणामों का निरीक्षण करें। DMARC संरेखित प्रमाणित पहचानकर्ताओं का मूल्यांकन करता है, इसलिए एक भेजने वाला प्लेटफ़ॉर्म "DKIM सक्षम" स्क्रीन यह साबित नहीं कर सकती कि डोमेन के संदेश रिसीवर तक पहुँचते हैं। RFC 9989 , अनुभाग 4.3-4.4.
ईमेल स्वामी को तत्परता और उत्कृष्ट प्रेषकों के बारे में एक विशिष्ट अनुशंसा देनी चाहिए। यदि आवश्यक मेल असत्यापित रहता है तो ब्रांड लॉन्च को रोक देना चाहिए। समाधान प्रमाणीकरण को सही करना या अधिकृत योजना को सीमित करना है, न कि आँख बंद करके प्रवर्तन को अपनाना और आशा करना कि लोगो निर्णय को मान्य करेगा।
रिकॉर्ड प्रदाता संगतता उनके स्वयं के कार्य आइटम के रूप में चेतावनी देती है। Google का BIMI मार्गदर्शन अभी भी सूचीबद्ध है pct=100, जबकि RFC 9989 प्रतिशत टैग हटा दिया गया. न तो किसी परियोजना प्रबंधक और न ही किसी डिज़ाइनर को लाइव नीति को बदलकर उस विसंगति को चुपचाप हल करना चाहिए। रिलीज़ से पहले ईमेल विशेषज्ञ से प्राप्तकर्ता की आवश्यकताओं और इच्छित नीति व्यवहार का दस्तावेजीकरण करने के लिए कहें। गूगल BIMI सेटअप; RFC 9989 , परिशिष्ट ए.6.
कलाकृति को फ़्रीज़ करने से पहले प्रमाणपत्र मार्ग का समाधान करें
Gmail के लिए, Google का वर्तमान दस्तावेज़ VMCs और CMCs को स्वीकार करता है, जबकि इसका चेकमार्क VMC-सत्यापित प्रेषकों से संबद्ध है। इसका VMC पथ के लिए एक योग्य पंजीकृत ट्रेडमार्क की आवश्यकता है; ए CMC जारीकर्ता-विशिष्ट आवश्यकताओं का पालन करता है। कानूनी को यह मानने के बजाय प्रासंगिक जारीकर्ता मानदंड प्राप्त करना चाहिए कि दो उत्पाद विनिमेय अधिकार, सत्यापन या प्रदर्शन परिणाम प्रदान करते हैं। गूगल BIMI सेटअप.
टीम द्वारा किसी उत्पादन परिसंपत्ति के लिए प्रतिबद्ध होने से पहले जारीकर्ता या जिम्मेदार प्रमाणपत्र ऑपरेटर से स्वीकृत चिह्न, कवर किए गए डोमेन और नवीनीकरण प्रक्रिया की पुष्टि करवाएं। मौसमी डिज़ाइन या अधिग्रहण-संबंधित लोगो को नई समीक्षा की आवश्यकता हो सकती है। अनुमोदित होस्टेड फ़ाइल को केवल इसलिए अधिलेखित न करें क्योंकि नई कलाकृति बेहतर दिखती है; संकेतक और साक्ष्य के बीच संबंध वैध रहना चाहिए।
Apple मेल का BIMI पथ एक अन्य स्वामी का परिचय देता है: प्राप्तकर्ता मेलबॉक्स प्रदाता। Apple दस्तावेज़ चेक और हेडर प्रदान करता है जिन्हें प्रदाता को प्रदान करना होगा। प्रेषक की प्रमाणपत्र खरीद उस प्राप्तकर्ता पक्ष की भागीदारी का स्थान नहीं ले सकती। यदि वांछित हो तो Apple ब्रांडेड मेल को प्रमाणपत्र कार्य में चुपचाप जोड़ने के बजाय एक अलग व्यवसाय-सत्यापन परियोजना के रूप में रखें। Apple BIMI सर्वर मार्गदर्शन.
ठोस निकास साक्ष्य के साथ चरणबद्ध हैंडऑफ़ का उपयोग करें
प्रस्तावित पाँच-चरणीय हैंडऑफ़ अच्छी तरह से काम करता है: दायरे को मंजूरी देना; प्रमाणीकरण तत्परता साबित करें; परिसंपत्ति और साक्ष्य मार्ग को स्वीकृत और मान्य करना; होस्ट किए गए संसाधनों और DNS दावे को सत्यापित करें; फिर नियंत्रित प्राप्ति-पक्ष अवलोकन एकत्र करें। प्रत्येक चरण में अगले मालिक की पहचान होनी चाहिए और किस कारण से काम रुकेगा।
एक काल्पनिक परियोजना में, विपणन एक केंद्रित वर्ग लोगो को मंजूरी देता है, लेकिन कानूनी ने इसकी प्रमाणपत्र पात्रता की पुष्टि नहीं की है। जब डिज़ाइन तकनीकी रूप से मान्य उम्मीदवार तैयार करता है तो DNS होल्ड पर रहता है। झूठे लॉन्च दावे के बिना यह उपयोगी प्रगति है। दूसरी काल्पनिक स्थिति में, प्रमाणपत्र उपलब्ध है लेकिन एक आवश्यक प्रेषक अभी भी विफल रहता है संरेखण. टीम प्रवर्तन परिवर्तन रखती है और चेकलिस्ट को पास करने के लिए उसे इन्वेंट्री से हटाने के बजाय उस प्रेषक पर काम करती है।
जहां अधिकृत हो वहां पिछले दावे और होस्ट किए गए संसाधनों को बनाए रखें, और यदि आवश्यक हो तो बीआईएमआई-विशिष्ट परिवर्तन को उलटने के तरीके पर सहमत हों। सामान्य लोगो रोलबैक के रूप में प्रमाणीकरण सुरक्षा को कमजोर नहीं किया जाना चाहिए। किसी पुराने URL या दावे की पुनर्स्थापना के लिए भी सत्यापन की आवश्यकता होती है क्योंकि कैश और प्राप्त करने का व्यवहार दृश्यमान प्रभाव में देरी कर सकता है।
साक्ष्य और रखरखाव की जिम्मेदारियों को परिभाषित करें
प्रस्तावित मैट्रिक्स दस्तावेजी पात्रता को देखे गए परिणामों से अलग करता है। प्रत्येक रिसीवर पंक्ति के लिए, वर्तमान स्रोत, प्रमाणपत्र प्रयोज्यता, वास्तविक DNS प्रतिक्रिया, सटीक संपत्ति संस्करण, सार्वजनिक फ़ेच परिणाम और नियंत्रित संदेश प्रमाणीकरण का अनुरोध करें। मेलबॉक्स प्रदाता, क्लाइंट और दिनांक के साथ प्रदर्शन परिणाम रिकॉर्ड करें। लॉन्च मीटिंग पूरी होने पर भी गुम साक्ष्य खुले रहते हैं।
मार्क-सर्टिफिकेट नवीनीकरण, HTTPS प्रमाणपत्र निरंतरता, परिसंपत्ति परिवर्तन, प्रेषक ऑनबोर्डिंग और स्रोत-नीति परिवर्तन के लिए चल रहे स्वामित्व को निर्दिष्ट करें। परीक्षा उत्तीर्ण करना एक दिनांकित अवलोकन है, पूरे डोमेन का स्थायी प्रमाणीकरण नहीं।
कैटलॉग के लिए "एक रिसीवर-विशिष्ट पात्रता मैट्रिक्स और DNS , लोगो, प्रमाणपत्र और संदेश प्रमाणीकरण के लिए साक्ष्य" की आवश्यकता होती है। इस मसौदे में मैट्रिक्स केवल एक योजना दस्तावेज़ है। कोई मूल परिनियोजन साक्ष्य, खरीदारी, सबमिशन, किरायेदार परिवर्तन या प्रदर्शन परीक्षण नहीं किए गए। वे गेट, स्वतंत्र तकनीकी समीक्षा और अधिकृत मालिक का रिलीज़ निर्णय बकाया है।