DKIM प्रमाणीकरण और वेबहुक सिग्नेचर सत्यापन के बीच क्या अंतर है?

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

मैं रॉ रिक्वेस्ट बॉडी के बजाय पार्स किए गए JSON ऑब्जेक्ट को वेरिफाई क्यों नहीं कर सकता?

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

वेबहुक एंडपॉइंट्स पर रिप्ले अटैक को कैसे रोकूं?

टाइमस्टैम्प वैलिडेशन (5-15 मिनट से पुराने अनुरोधों को अस्वीकार करें) और स्थिर डिलीवरी ID का उपयोग करके रिप्ले डिटेक्शन लागू करें, जो TTL के साथ फास्ट डेटास्टोर में स्टोर किया गया हो ताकि डुप्लिकेट अनुरोधों को पहचाना और अस्वीकार किया जा सके।

LLM एजेंट्स के साथ वेबहुक का उपयोग करते समय कौन से अतिरिक्त सुरक्षा विचार लागू होते हैं?

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

ईमेल साइन्ड बाई: वेबहुक पेलोड की प्रामाणिकता सत्यापित करें

Gmail में “email signed by” देखना (या अन्य क्लाइंट्स में समान UI संकेत) एक अनुस्मारक है कि ईमेल वर्कफ़लो में पहचान और अखंडता महत्वपूर्ण है। लेकिन यदि आप वेबहुक के माध्यम से इनबाउंड ईमेल का उपभोग कर रहे हैं (QA ऑटोमेशन, साइनअप सत्यापन, या LLM एजेंट्स के लिए), तो सुरक्षा सीमा स्थानांतरित हो जाती है: आपका वास्तविक जोखिम अक्सर यह नहीं है कि SMTP संदेश में DKIM था या नहीं, बल्कि यह है कि पार्स किए गए ईमेल को डिलीवर करने वाला HTTP अनुरोध प्रामाणिक है या नहीं।

यह गाइड समझाता है कि “email signed by” का वास्तव में क्या मतलब है, यह वेबहुक-संचालित ऑटोमेशन के लिए पर्याप्त क्यों नहीं है, और वेबहुक पेलोड की प्रामाणिकता को इस तरह से कैसे सत्यापित करें जो रिट्राई, डुप्लिकेट्स और प्रतिकूल इनपुट के तहत टिकी रहे।

यदि आप विशेष रूप से Mailhook का उपयोग कर रहे हैं, तो यह स्ट्रक्चर्ड JSON के रूप में प्राप्त ईमेल के लिए रियल-टाइम वेबहुक नोटिफिकेशन और साइन्ड पेलोड का समर्थन करता है। कैनोनिकल, अप-टू-डेट इंटीग्रेशन कॉन्ट्रैक्ट (सटीक हेडर, सिग्नेचर निर्माण, और उदाहरण) के लिए, उपयोग करें: mailhook.co/llms.txt।

“Email Signed By” का वास्तविक अर्थ

अधिकांश इनबॉक्स UI “signed by” को सर्फेस करते हैं जब संदेश क्रिप्टोग्राफिक प्रमाणीकरण जांच पास कर देता है, आमतौर पर DKIM (DomainKeys Identified Mail)। DKIM एक भेजने वाले डोमेन को संदेश के हिस्सों पर हस्ताक्षर करने की अनुमति देता है ताकि रिसीवर ट्रांजिट में छेड़छाड़ का पता लगा सकें और संदेश को एक डोमेन के साथ जोड़ सकें।

महत्वपूर्ण बारीकी:

DKIM रिसीवर को यह जवाब देने में मदद करता है “क्या यह संदेश संभावित रूप से इस डोमेन के लिए एक अधिकृत भेजने वाले से उत्पन्न हुआ, और क्या इसे ट्रांजिट में संशोधित किया गया?”
DKIM आपके सिस्टम को बाद में वेबहुक प्रदाता से मिलने वाले HTTP अनुरोध को प्रमाणित नहीं करता।

भले ही एक संदेश पूर्ण रूप से DKIM-साइन्ड हो, एक दुर्भावनापूर्ण अभिकर्ता अभी भी कोशिश कर सकता है:

आपके वेबहुक एंडपॉइंट को एक नकली “नया ईमेल प्राप्त” पेलोड के साथ स्पूफ करना
OTP फ़्लो को फिर से ट्रिगर करने के लिए एक पुराने वैध पेलोड को रिप्ले करना
यदि आपका सत्यापन रॉ बॉडी पर कंप्यूट नहीं किया गया है तो JSON फ़ील्ड्स के साथ छेड़छाड़ करना

इसलिए “email signed by” को ईमेल के लिए उपयोगी संदर्भ के रूप में मानें, वेबहुक प्रमाणीकरण के विकल्प के रूप में नहीं।

DKIM बनाम वेबहुक सिग्नेचर: दो अलग ट्रस्ट समस्याएं

मैकेनिज्म	यह क्या प्रमाणित करता है	यह कहां लागू होता है	यह आपको किससे सुरक्षित नहीं रखता
DKIM (“email signed by” के रूप में दिखाया गया)	डोमेन द्वारा साइन किए गए ईमेल संदेश के हिस्से	SMTP और मेलबॉक्स रिसीप्ट	फर्जी HTTP वेबहुक कॉल्स, रिप्ले डिलीवरी, आपकी अपनी पार्सिंग/नॉर्मलाइज़ेशन पाइपलाइन
वेबहुक सिग्नेचर	आपके एंडपॉइंट पर डिलीवर किया गया HTTP अनुरोध बॉडी	आपकी एप्लिकेशन सीमा	“वैध” ईमेल जिसमें दुर्भावनापूर्ण सामग्री हो (प्रॉम्प्ट इंजेक्शन, SSRF लिंक्स, आदि)

ऑटोमेशन में सर्वोत्तम प्रथा दोनों को सत्यापित करना है:

वेबहुक सिग्नेचर को सत्यापित करें यह साबित करने के लिए कि अनुरोध आपके प्रदाता से आया है।
वेबहुक सत्यापित होने के बाद भी ईमेल सामग्री को अविश्वसनीय इनपुट के रूप में मानें।

DKIM मानकों की पृष्ठभूमि के लिए, देखें RFC 6376।

थ्रेट मॉडल: आप किससे बचाव कर रहे हैं

जब आपका सिस्टम वेबहुक के माध्यम से JSON के रूप में इनबाउंड मेल प्राप्त करता है, तो मान लें कि हमलावर सामान्य विफलता मोड्स की कोशिश करेंगे जो सामान्य डिस्ट्रिब्यूटेड-सिस्टम व्यवहार की तरह भी दिखते हैं:

स्पूफिंग: सीधे आपके वेबहुक एंडपॉइंट पर अनुरोध भेजना
रिप्ले: साइड इफेक्ट्स को फिर से ट्रिगर करने के लिए पहले से वैध अनुरोध को फिर से भेजना
बॉडी टैम्परिंग: फ्रेमवर्क का फायदा उठाना जो JSON को फिर से सीरियलाइज़ करते हैं और गलती से एक अलग बाइट रिप्रेजेंटेशन को वेरिफाई करते हैं
हेडर कन्फ्यूजन: क्रिप्टोग्राफिक सत्यापन के बजाय IP अलाउलिस्ट या “User-Agent” स्ट्रिंग्स पर निर्भर रहना
रिट्राई एम्प्लिफिकेशन: कई डाउनस्ट्रीम एक्शन ट्रिगर करना क्योंकि आपका हैंडलर इडेमपोटेंट नहीं है

यदि आपका डाउनस्ट्रीम उपभोक्ता एक LLM एजेंट है, तो दांव अधिक हैं: एक फर्जी या रिप्ले ईमेल एक इंस्ट्रक्शन इंजेक्शन बन सकता है या एजेंट को सत्यापन ईमेल फिर से भेजने, लिंक्स पर क्लिक करने, या सीक्रेट्स को एक्सफिल्ट्रेट करने का कारण बन सकता है।

प्रैक्टिस में “वेबहुक पेलोड प्रामाणिकता सत्यापित करें” का क्या मतलब होना चाहिए

एक सुरक्षित वेबहुक सत्यापन फ़्लो में आमतौर पर निम्नलिखित सभी शामिल होते हैं:

1) रॉ रिक्वेस्ट बॉडी पर कंप्यूट किए गए सिग्नेचर को वेरिफाई करें

केवल बाइट सीक्वेंस जिस पर दोनों पक्ष सहमत हो सकते हैं वह रॉ HTTP रिक्वेस्ट बॉडी है। कई वेबहुक उल्लंघन पार्स किए गए ऑब्जेक्ट (या एक प्रिटी-प्रिंटेड JSON स्ट्रिंग) को वेरिफाई करने के बजाय प्राप्त सटीक बाइट्स को वेरिफाई करने से आते हैं।

कार्यान्वयन नियम:

अपने फ्रेमवर्क द्वारा प्राप्त रॉ बॉडी बाइट्स को कैप्चर करें।
अपने वेबहुक सीक्रेट का उपयोग करके अपेक्षित सिग्नेचर की गणना करें।
कॉन्स्टेंट-टाइम तुलना का उपयोग करके सिग्नेचर की तुलना करें।

सिग्नेचर कैसे निर्मित किए जाते हैं यह प्रदाता के अनुसार भिन्न होता है (HMAC, detached JWS, asymmetric signing)। हेडर नाम या कैनोनिकलाइज़ेशन नियमों का अनुमान न लगाएं।

Mailhook वेबहुक नोटिफिकेशन के लिए साइन्ड पेलोड प्रदान करता है, लेकिन आपको mailhook.co/llms.txt में सटीक कॉन्ट्रैक्ट का पालन करना चाहिए।

2) रिप्ले रिस्क को कम करने के लिए टाइमस्टैम्प टॉलरेंस लागू करें

अकेला सिग्नेचर प्रामाणिकता साबित करता है, लेकिन ताजगी नहीं।

टाइमस्टैम्प आवश्यकता जोड़ें:

प्रदाता-आपूर्ति टाइमस्टैम्प हेडर या फ़ील्ड की आवश्यकता है।
एक छोटी विंडो से पुराने अनुरोधों को अस्वीकार करें (आमतौर पर 5 मिनट, कभी-कभी रिट्राई और क्यू के आधार पर 1 से 15 मिनट)।
क्लॉक स्क्यू पर विचार करें और एक स्पष्ट टॉलरेंस सेट करें।

यदि आपको लंबी देरी का समर्थन करना है, तो टाइमस्टैम्प चेक को रिप्ले स्टोरेज (अगला सेक्शन) के साथ जोड़ें।

3) डिलीवरी ID का उपयोग करके रिप्ले डिटेक्शन जोड़ें

यहां तक कि वैध प्रदाता भी वेबहुक को रिट्राई करते हैं। हमलावर भी रिप्ले करते हैं।

इसलिए आपके हैंडलर को चाहिए:

एक स्थिर इवेंट आइडेंटिफायर (डिलीवरी ID, इवेंट ID, मैसेज ID, या प्रदाता-विशिष्ट idempotency key) निकालें।
इसे एक फास्ट डेटा स्टोर में TTL के साथ स्टोर करें।
डुप्लिकेट्स को अस्वीकार करें या no-op करें।

यदि आपका वेबहुक साइड इफेक्ट्स ट्रिगर करता है (OTP को consumed के रूप में मार्क करना, खाता बनाना, वर्कफ़्लो को अप्रूव करना) तो यह वैकल्पिक नहीं है।

4) फेल क्लोज़्ड, और “सत्यापन” को “प्रोसेसिंग” से अलग करें

एक साफ डिज़ाइन है:

सत्यापन परत: सिग्नेचर, टाइमस्टैम्प, रिप्ले चेक
प्रोसेसिंग परत: JSON पार्स करें, मैसेज/आर्टिफैक्ट द्वारा डुप्लिकेट हटाएं, OTP या लिंक निकालें, कार्य को क्यू में डालें

यदि सत्यापन विफल हो जाता है:

4xx (अक्सर 401/403) रिटर्न करें और एन्क्यू न करें।

यदि प्रोसेसिंग विफल हो जाती है:

केवल तभी 2xx रिटर्न करें जब आपने रिट्राई के लिए इवेंट को सुरक्षित रूप से persist कर दिया हो, या 5xx रिटर्न करें ताकि प्रदाता रिट्राई करे। जानबूझकर चुनें।

5) सीक्रेट्स को लॉग्स से बाहर रखें और एंडपॉइंट की सुरक्षा करें

न्यूनतम स्वच्छता:

वेबहुक सीक्रेट्स को सीक्रेट्स मैनेजर में स्टोर करें।
सीक्रेट्स को रोटेट करें और रोटेशन के दौरान डुअल वैलिडेशन का समर्थन करें।
केवल HTTPS का उपयोग करें।
साझा लॉग्स में रॉ सिग्नेचर, सीक्रेट्स, या पूर्ण ईमेल बॉडी को लॉग न करें।

एक प्रदाता-अज्ञेयवादी सत्यापन चेकलिस्ट (कोड रिव्यू के लिए कॉपी/पेस्ट)

एजेंट्स या CI पाइपलाइन्स को इनबाउंड ईमेल इवेंट्स पर भरोसा करने से पहले इसे रिव्यू गेट के रूप में उपयोग करें:

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

रेफरेंस आर्किटेक्चर: पोलिंग फॉलबैक के साथ वेबहुक-फर्स्ट

वेबहुक डिलीवरी इनबाउंड मेल प्राप्त करने का सबसे कम-लेटेंसी तरीका है, लेकिन प्रोडक्शन सिस्टम को कभी-कभार डिलीवरी विफलताओं के लिए लचीला होना चाहिए।

ऑटोमेशन-फर्स्ट इनबॉक्स सिस्टम में एक सामान्य पैटर्न है:

जब ईमेल आता है तो वेबहुक जल्दी ट्रिगर करता है।
आपका हैंडलर प्रामाणिकता सत्यापित करता है, रिकॉर्ड persist करता है, और कार्य को क्यू में डालता है।
यदि वेबहुक मिस हो जाता है या देर हो जाती है, तो आपका वर्कफ़्लो फॉलबैक के रूप में इनबॉक्स API को पोल कर सकता है।

Mailhook वेबहुक नोटिफिकेशन और पोलिंग API दोनों का समर्थन करता है, जो निर्धारणात्मक QA और एजेंट वर्कफ़लो के लिए उपयोगी है जहां आप “push first, pull as backup” चाहते हैं।

एक सरल फ़्लो डायग्राम दिखाता है कि इनबाउंड ईमेल SMTP के माध्यम से टेम्प इनबॉक्स प्रदाता तक पहुंचता है, फिर कस्टमर एंडपॉइंट पर साइन्ड वेबहुक POST, फिर सत्यापन (सिग्नेचर, टाइमस्टैम्प, रिप्ले चेक), फिर persistence/queue, और अंत में एक ऑटोमेशन वर्कर या LLM एजेंट न्यूनीकृत JSON दृश्य का उपभोग करता है।

LLM एजेंट्स के लिए व्यावहारिक नोट्स: प्रामाणिकता आवश्यक है, पर्याप्त नहीं

यहां तक कि पूर्ण रूप से प्रमाणित वेबहुक भी शत्रुतापूर्ण सामग्री डिलीवर कर सकते हैं, क्योंकि हमलावर आपके डिस्पोज़ेबल इनबॉक्सेस पर वास्तविक ईमेल भेज सकते हैं।

एजेंट सुरक्षा के लिए:

न्यूनीकृत JSON दृश्य (subject, from, received_at, और निकाले गए आर्टिफैक्ट) को प्राथमिकता दें, रॉ HTML नहीं।
एजेंट्स को ईमेल में मिले मनमाने लिंक्स को “ब्राउज़” करने से बचें।
सत्यापन लिंक्स के लिए होस्ट अलाउलिस्ट जोड़ें (और सख्त नियमों के साथ रीडायरेक्ट्स को सर्वर-साइड रिज़ॉल्व करने पर विचार करें)।
एजेंट एक्शन पर सख्त बजट रखें (कोई repeated “resend code” लूप नहीं)।

यहां स्ट्रक्चर्ड JSON डिलीवरी मदद करती है: यह भंगुर HTML स्क्रैपिंग के बजाय निर्धारणात्मक, न्यूनतम एक्सट्रैक्टर बनाना आसान बनाती है।

उदाहरण स्यूडोकोड (संरचना, प्रदाता-विशिष्ट नहीं)

लक्ष्य प्रदाता विवरण का आविष्कार किए बिना नियंत्रण प्रवाह दिखाना है।

raw_body = getRawRequestBodyBytes(req)
sig = req.headers["Signature"]
timestamp = req.headers["Signature-Timestamp"]

if !sig or !timestamp:
  return 401

if isTooOld(timestamp, toleranceSeconds=300):
  return 401

expected = computeSignature(secret, timestamp, raw_body)
if !constantTimeEquals(sig, expected):
  return 403

delivery_id = parseJson(raw_body).delivery_id
if seenRecently(delivery_id):
  return 200  // idempotent accept
markSeen(delivery_id, ttl=24h)

enqueueForProcessing(raw_body)
return 200

Mailhook के लिए इसे सही तरीके से लागू करने के लिए (वास्तविक हेडर नाम, साइन्ड स्ट्रिंग कैसे निर्मित की जाती है, और कौन से ID उपलब्ध हैं), mailhook.co/llms.txt में कॉन्ट्रैक्ट का पालन करें।

Mailhook कहां फिट होता है (आपकी सुरक्षा मुद्रा बदले बिना)

Mailhook उन वर्कफ़लो के लिए डिज़ाइन किया गया है जहां ईमेल सॉफ्टवेयर सिस्टम का इनपुट है, जिसमें LLM एजेंट्स और QA ऑटोमेशन शामिल हैं:

API के माध्यम से डिस्पोज़ेबल इनबॉक्स बनाएं
इनबाउंड ईमेल को स्ट्रक्चर्ड JSON के रूप में प्राप्त करें
रियल-टाइम वेबहुक नोटिफिकेशन प्राप्त करें (प्लस फॉलबैक के रूप में पोलिंग)
साइन्ड वेबहुक पेलोड के साथ प्रामाणिकता सत्यापित करें
तुरंत साझा डोमेन का उपयोग करें, या जब आपको सख्त नियंत्रण की आवश्यकता हो तो कस्टम डोमेन लाएं

यदि आप “email as an event stream” पाइपलाइन बना रहे हैं, तो महत्वपूर्ण निष्कर्ष यह है: अपने वेबहुक को एक सार्वजनिक API सर्फेस की तरह मानें। ईमेल लेयर पर “email signed by” को सत्यापित करना सहायक है, लेकिन वेबहुक पेलोड प्रामाणिकता को सत्यापित करना वही है जो आपके ऑटोमेशन की सुरक्षा करता है।

कार्यान्वयन विवरण, उदाहरण, और कैनोनिकल इंटीग्रेशन कॉन्ट्रैक्ट के लिए, यहां शुरू करें: Mailhook llms.txt।