[ हेडर और डिलीवरी त्रुटियाँ ]

List-Unsubscribe और List-Unsubscribe-Post हेडर

सूची-प्रबंधन लिंक को हस्ताक्षरित एक-क्लिक सदस्यता समाप्त तंत्र से अलग करें, और वास्तविक प्राप्तकर्ताओं की सदस्यता समाप्त किए बिना परीक्षण करें।

EmailAuth अनुसंधान टीम द्वारा · 3 मिनट पढ़ा

[ प्रमुख बिंदु ]

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

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

दोनों क्षेत्रों को एक साथ पढ़ें

RFC 2369 List-Unsubscribe एक सूची कमांड फ़ील्ड के रूप में परिभाषित करता है जिसमें सूची छोड़ने के लिए यूआरएल होते हैं। यह mailto या HTTPS जैसी विधियों का वर्णन कर सकता है। RFC 8058 एक-क्लिक तंत्र के लिए List-Unsubscribe-Post जोड़ता है। बाद वाला List-Unsubscribe में HTTPS URI के साथ List-Unsubscribe =One-Click मान का उपयोग करता है। अकेले मेल्टो विकल्प RFC 8058 HTTPS तंत्र नहीं है। RFC 2369 खंड 3.2, RFC 8058 अनुभाग 3.

एक-क्लिक रिसीवर निर्दिष्ट अनसब्सक्राइब मान के साथ एक HTTPS POST भेजता है। किसी URL का निरीक्षण करने के लिए एक नियमित GET को स्वयं RFC 8058 सदस्यता समाप्त करने की कार्रवाई नहीं करनी चाहिए। यह अंतर मायने रखता है क्योंकि लिंक स्कैनर किसी सूची को छोड़ने के इच्छुक व्यक्ति के बिना भी यूआरएल प्राप्त कर सकते हैं। नैदानिक ​​निरीक्षण को अनधिकृत सदस्यता परिवर्तन में न बदलें।

हस्ताक्षर की आवश्यकता की जाँच करें

RFC 8058 के लिए एक वैध की आवश्यकता है DKIM हस्ताक्षर List-Unsubscribe और List-Unsubscribe-Post दोनों को कवर करता है। किसी हस्ताक्षर की h= सूची में दो फ़ील्ड नाम ढूँढना एक उपयोगी संरचनात्मक जाँच है, लेकिन यह साबित नहीं करता है कि हस्ताक्षर सत्यापित करता है।

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

एक नियंत्रित उदाहरण का प्रयोग करें

सही दो हेडर मानों वाले एक काल्पनिक संदेश पर विचार करें। इसका एकमात्र वैध हस्ताक्षर प्रेषक और विषय को कवर करता है लेकिन सदस्यता समाप्त फ़ील्ड को नहीं। दूसरे हस्ताक्षर में दोनों फ़ील्ड सूचीबद्ध हैं लेकिन सत्यापन विफल रहता है। इस संदेश में दोनों हैं DKIM इसके स्रोत में कहीं न कहीं पास और स्पष्ट कवरेज है, फिर भी कोई भी हस्ताक्षर संयुक्त RFC 8058 आवश्यकता को पूरा नहीं करता है।

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

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

ग्राहक पहचानकर्ताओं को सुरक्षित रखें

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

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

प्रत्येक परत की स्वतंत्र रूप से रिपोर्ट करें

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

[ ले लेना ]

सूची-प्रबंधन लिंक को हस्ताक्षरित एक-क्लिक सदस्यता समाप्त तंत्र से अलग करें, और वास्तविक प्राप्तकर्ताओं की सदस्यता समाप्त किए बिना परीक्षण करें।

[भूमिका के अनुसार]

आपके लिए इसका क्या मतलब है

व्यावहारिक अगले चरणों के लिए अपनी भूमिका चुनें।

आईटी/मेल एडमिन

प्रत्येक परत को अलग से मान्य करें

हेडर सिंटैक्स केवल पहली जांच है।

अगले कदम

  1. दोनों हस्ताक्षरित फ़ील्ड सत्यापित करें.
  2. कवरिंग हस्ताक्षर को पहचानें.
  3. प्राधिकरण के साथ POST व्यवहार का परीक्षण करें।

सीआईएसओ/सेकऑप्स

आकस्मिक सदस्यता क्रियाओं को रोकें

कार्रवाई यूआरएल को यूं ही नहीं लाया जाना चाहिए या साझा नहीं किया जाना चाहिए।

अगले कदम

  1. प्राप्तकर्ता टोकन को सुरक्षित रखें।
  2. नियंत्रित परीक्षण खातों का उपयोग करें.
  3. समापन बिंदु परीक्षण का दायरा रिकॉर्ड करें.

संस्थापक/गैर-तकनीकी

किसी सूची को विश्वसनीय बनाएं

एक दृश्यमान लिंक और एक प्रमाणित एक-क्लिक प्रवाह विभिन्न उपयोगकर्ता पथ प्रदान करता है।

अगले कदम

  1. सदस्यता समाप्त करने वाले स्वामी को नियुक्त करें.
  2. परीक्षण सदस्यता का प्रयोग करें.
  3. असमर्थित इंटरफ़ेस वादों से बचें.

[ पूछे जाने वाले प्रश्न ]

अक्सर पूछे जाने वाले प्रश्नों

क्या बॉडी लिंक वन-क्लिक हेडर के समान है?

नहीं, वे अलग-अलग तंत्र हैं और उनका मूल्यांकन अलग से किया जाना चाहिए।

क्या RFC 8058 के लिए केवल मेल्टो ही पर्याप्त है?

नहीं, एक-क्लिक तंत्र के लिए HTTPS URI की आवश्यकता होती है।

List-Unsubscribe-Post में क्या मान है?

List-Unsubscribe=One-Click.

क्या दोनों सदस्यता समाप्त शीर्षकों पर हस्ताक्षर किए जाने चाहिए?

हाँ। RFC 8058 दोनों को कवर करने वाले वैध DKIM हस्ताक्षर की आवश्यकता है।

क्या केवल h= कवरेज ही अनुपालन सिद्ध करता है?

नहीं, हस्ताक्षर की वैधता और समापन बिंदु व्यवहार भी मायने रखता है।

क्या यूआरएल खोलने से किसी को सदस्यता समाप्त कर देनी चाहिए?

GET RFC 8058 अनसब्सक्राइब पोस्ट नहीं है। निरीक्षण के दौरान वास्तविक परिवर्तन न करें।

क्या सदस्यता समाप्त लेनदेन वास्तव में निष्पादित किया गया था?

नहीं, यह आलेख एक काल्पनिक हस्ताक्षर-चयन उदाहरण और एक अधिकृत परीक्षण योजना प्रदान करता है, न कि निष्पादित सदस्यता समाप्त लेनदेन।

क्या पूर्ण सदस्यता समाप्त यूआरएल संवेदनशील हो सकता है?

हाँ। इसमें प्राप्तकर्ता-विशिष्ट कार्रवाई टोकन शामिल हो सकता है और इसे तदनुसार संभाला जाना चाहिए।

[ सूत्रों का कहना है ]

सूत्रों का कहना है

  1. RFC 2369 : मेलिंग सूची कमांड फ़ील्ड

    धारा §3.2

  2. RFC 8058 : एक-क्लिक सदस्यता समाप्त करें

    धारा §3.1 · §3.2 · §4 · §5 · §6

  3. RFC 6376 : DKIM हस्ताक्षर

    धारा §3.5 · §5.4 · §6.1

[ शब्दकोष ]

शब्दकोष

एक-क्लिक सदस्यता समाप्त करें
RFC 8058 हस्ताक्षरित-हेडर तंत्र HTTPS POST के माध्यम से सदस्यता समाप्त करने का अनुरोध करता है।
हेडर हस्ताक्षर कवरेज
हेडर फ़ील्ड DKIM हस्ताक्षर की h= सूची में शामिल हैं।
कार्रवाई टोकन
किसी URL या अनुरोध में एक मान जो किसी विशिष्ट परिवर्तन को अधिकृत कर सकता है।

उद्यम उद्गम

शीर्ष वित्तीय संस्थान और सरकारें ही क्यों? अपने ईमेल सुरक्षा डैशबोर्ड हटा दिए।

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

EmailAuth एजेंटिक ईमेल उद्गम मंच है। हमारे एजेंट लागू करते हैं p=reject, तृतीय-पक्ष प्रेषकों को संरेखित रखें और अपने डोमेन को पूर्ण रूप से स्थानांतरित करें RFC 9989 अनुपालन, नया DMARC मानक, मानव-इन-द-लूप ऑडिटेबिलिटी के साथ।

सरकारों बड़े उद्यम टियर-1 वित्तीय संस्थान

सास · समर्पित किरायेदारी · एयर-गैप्ड ऑन-प्रिमाइसेस · BYOK एन्क्रिप्शन

ज्ञानधार