Deliverability

ARC (Authenticated Received Chain) क्या है?

ARC उन सर्वर को, जो ईमेल फ़ॉरवर्ड या संपादित करते हैं, पहले के प्रमाणीकरण परिणामों के हस्ताक्षरित रिकॉर्ड संरक्षित करने देता है।

एक ईमेल मेलिंग लिस्ट द्वारा बदले जाने से पहले प्रमाणीकरण पास कर सकता है। अगले रिसीवर को वैध प्रोसेसिंग को प्रतिरूपण से अलग करने के लिए उस पहले के परिणाम का साक्ष्य चाहिए।

वैध फ़ॉरवर्डिंग प्रमाणीकरण क्यों तोड़ सकती है?

फ़ॉरवर्डिंग भेजने वाले सर्वर या हस्ताक्षरित कंटेंट को बदल सकती है, जिन पर प्रमाणीकरण जाँचें निर्भर करती हैं।

SPF जाँचता है कि कोई सर्वर उस एनवेलप सेंडर डोमेन के लिए अधिकृत है या नहीं जो डिलीवरी-फ़ेल्योर नोटिस के लिए उपयोग होता है। एक फ़ॉरवर्डर अनधिकृत IP से कनेक्ट कर सकता है।

DKIM एक साइनिंग डोमेन से जुड़े हस्ताक्षर को सत्यापित करता है। सामान्य फ़ॉरवर्ड में हस्ताक्षर बना रह सकता है। कोई मेलिंग लिस्ट जो हस्ताक्षरित Subject या बॉडी बदल दे, उसे अमान्य कर सकती है।

DMARC के लिए ज़रूरी है कि पास होने वाला SPF या DKIM डोमेन दिखाई देने वाले From डोमेन से मेल खाए। इस मेल को अलाइनमेंट कहते हैं। अगर कोई भी तरीका अलाइन्ड पास नहीं देता, तो DMARC फ़ेल हो जाता है, भले ही संदेश वैध हो।

ARC संदेश में क्या जोड़ता है?

प्रत्येक भाग लेने वाला हैंडलर तीन हेडर जोड़ता है, जिन्हें मिलाकर ARC सेट कहते हैं।

हेडरयह कौन-सा साक्ष्य प्रदान करता है
ARC-Authentication-Resultsहैंडलर के बदलावों से पहले देखे गए प्रमाणीकरण परिणाम
ARC-Message-Signatureसंदेश पर एक हस्ताक्षर, जैसा हैंडलर इसे आगे भेजता है
ARC-SealARC सेट और पहले की चेन की सुरक्षा करने वाला हस्ताक्षर

इंस्टेंस नंबर i= सेट्स को क्रम में लगाता है। पहला हैंडलर i=1 का उपयोग करता है। अगला i=2 का उपयोग करता है, जिससे उनका क्रम स्पष्ट रहता है।

सील का cv= मान चेन सत्यापन दर्ज करता है। मान none पहले सेट को चिह्नित करता है। मान pass मौजूदा चेन के सफल सत्यापन को दर्ज करता है। मान fail असफल सत्यापन को दर्ज करता है।

RFC 8617 बताता है कि रिसीवर चेन की अखंडता कैसे सत्यापित करते हैं। सत्यापन यह स्थापित नहीं करता कि हर हैंडलर का रिपोर्ट किया गया आकलन भरोसेमंद है।

क्या एक वैध चेन डिलीवरी की गारंटी देती है?

एक वैध ARC चेन डिलीवरी की गारंटी नहीं देती। यह रिसीवर के अपने हैंडलिंग निर्णय के लिए साक्ष्य प्रदान करती है।

रिसीवर तय करता है कि उन हैंडलर पर भरोसा करना है या नहीं जिन्होंने साक्ष्य प्रदान किया। कोई अज्ञात हैंडलर केवल वैध हस्ताक्षर बनाने से भरोसेमंद नहीं बन जाता।

ARC विनिर्देश Experimental है, यानी यह मूल्यांकन के लिए एक प्रोटोकॉल दस्तावेज़ित करता है, न कि Internet Standards Track विनिर्देश है। डिलीवरी का निर्णय रिसीवर के नियंत्रण में रहता है।

ARC किसे लागू करना चाहिए?

फ़ॉरवर्डर और मेलिंग लिस्ट ARC का उपयोग डाउनस्ट्रीम रिसीवर के लिए प्रमाणीकरण साक्ष्य संरक्षित करने में करते हैं।

आपकी भूमिकासंबंधित कार्य
मूल प्रेषकअपने मेल को अलाइन्ड डोमेन से प्रमाणित करें
फ़ॉरवर्डर या मेलिंग लिस्टआने वाली चेन का मूल्यांकन करें और संदेश प्रोसेस करते समय ARC सेट जोड़ें
रिसीवरउपलब्ध चेन को सत्यापित करें और तय करें कि किन हैंडलर पर भरोसा करना है

Yahoo का प्रेषक मार्गदर्शन फ़ॉरवर्डर से ARC लागू करने के लिए कहता है। ऐसा करने से प्राप्तकर्ता फ़ॉरवर्डिंग से प्रभावित वैध मेल का मूल्यांकन कर सकते हैं। रिसीवर अभी भी तय करते हैं कि इसे स्वीकार करना है या नहीं।

अगर आपका सीधा मेल DMARC में फ़ेल होता है, तो उसका प्रमाणीकरण या अलाइनमेंट ठीक करें। ARC सील जोड़ने से मूल डोमेन मिसमैच की मरम्मत नहीं होती।

मूल प्रेषक फ़ॉरवर्ड किए गए मेल के बारे में क्या कर सकता है?

मूल प्रेषक अलाइन्ड DKIM प्रदान कर सकता है जो हस्ताक्षरित कंटेंट बरकरार रहने पर फ़ॉरवर्डिंग में टिका रहता है।

जिन हेडर को सुरक्षा चाहिए उन पर हस्ताक्षर करें। ऐसी बॉडी-लंबाई सीमा से बचें जो जोड़े गए कंटेंट को अहस्ताक्षरित छोड़ दे। DKIM साइनिंग इन विकल्पों की व्याख्या करता है।

अगर कोई बाद का हैंडलर हस्ताक्षरित कंटेंट संपादित करता है, तो पहले के परिणाम का साक्ष्य संरक्षित करने के लिए उस हैंडलर की भागीदारी ज़रूरी है। ARC उसे वह साक्ष्य दर्ज करने का तरीका देता है। रिसीवर अभी भी तय करता है कि इसे कितना महत्व देना है।

संक्षेप में

  1. फ़ॉरवर्डिंग और संपादन प्रमाणीकरण को प्रभावित कर सकते हैं।

    बदला हुआ भेजने वाला सर्वर SPF को तोड़ सकता है। हस्ताक्षरित कंटेंट बदलने से DKIM टूट सकता है।

  2. प्रत्येक भाग लेने वाला हैंडलर एक ARC सेट जोड़ता है।

    तीन हेडर प्रमाणीकरण परिणाम दर्ज करते हैं, आउटगोइंग संदेश पर हस्ताक्षर करते हैं और चेन को सील करते हैं।

  3. एक वैध चेन डिलीवरी की गारंटी नहीं देती।

    रिसीवर तय करते हैं कि मध्यस्थों पर भरोसा करना है या नहीं और उनके साक्ष्य का उपयोग कैसे करना है।

  4. मूल प्रेषकों और मध्यस्थों के कार्य अलग-अलग होते हैं।

    मूल प्रेषक अपने मेल को प्रमाणित करते हैं। मध्यस्थ अपने बदलावों से पहले देखे गए परिणामों का साक्ष्य संरक्षित कर सकते हैं।

व्यवहार में लाएँ।

इस विषय के लिए डॉक्यूमेंटेशन, गाइड और उदाहरणों के साथ आगे बढ़ें। संसाधन अंग्रेज़ी में हैं।

अभ्यास करें और इम्प्लीमेंटेशन ब्रीफ़ पाएँ

उसी नेटवर्क पर बनाएँ।

एक टेस्ट API key आपको तुरंत मिल जाती है। भुगतान विधि जोड़ने और सेंडर सत्यापित करने पर प्रोडक्शन अनलॉक होता है।

आपका अगला आइडिया।
जुड़ने के लिए तैयार।