
read receipts
जिस ईमेल को आपने अपने आप को फॉरवर्ड किया, वह स्पैम में क्यों उतरा
आपने कुछ गलत नहीं किया। SPF ने किया। यह वह मकैनिज्म है जिसे आपका प्रदाता समझाएगा ही नहीं।
अपने पुराने खाते से नए खाते में ऑटो-फॉरवर्ड सेट अप करें, और कुछ मेल चुपचाप स्पैम में गायब हो जाएगा — यह इसलिए नहीं कि आपका प्रदाता खराब है, बल्कि इसलिए कि फॉरवर्डिंग यह बदल देती है कि संदेश कौन भेज रहा है, लेकिन क्रिप्टोग्राफिक प्रमाण को नहीं बदलती। SPF गलत सर्वर को चेक करता है, DMARC वर्डिक्ट फेल में बदल जाता है, और आपने अपने आप को भेजा हुआ वह वाजिब ईमेल क्वारेंटीन में चला जाता है। इसका समाधान एक नाम रखता है: ARC, जिसे 2019 में RFC 8617 में परिभाषित किया गया था।
फॉरवर्डिंग मेरी मेल को SPF फेल करने क्यों देती है?
क्योंकि SPF उस अंतिम सर्वर को चेक करता है जो संदेश को रिले करता है, और फॉरवर्डिंग उस सर्वर को बदल देती है। SPF — Sender Policy Framework — एक DNS रिकॉर्ड है जो सूचीबद्ध करता है कि कौन से IP पते किसी डोमेन के लिए मेल भेजने की अनुमति दी गई है। जब bank.com आपको एक रसीद भेजता है, तो प्राप्त करने वाला सर्वर जांचता है: क्या यह एक IP से आया है जिसे bank.com ने अधिकृत किया है? हां। पास।
अब उस रसीद को अपने Gmail से अपने नए पते पर फॉरवर्ड करें। Google के सर्वर इसे आगे रिले करते हैं। अंतिम प्राप्त करने वाला सर्वर SPF जांच चलाता है और पूछता है: क्या Google को bank.com के लिए भेजने की अनुमति है? नहीं, इसे नहीं है। SPF फेल करता है। Google का स्वयं का Workspace डॉक्युमेंटेशन यह स्पष्ट रूप से बताता है — फॉरवर्ड की गई मेल SPF फेल करती है क्योंकि फॉरवर्डिंग सर्वर मूल डोमेन के SPF रिकॉर्ड में नहीं है। कुछ भी स्पूफ नहीं किया गया। जांच बस गलत हॉप को देख रही है।
तो इसे स्पैम में क्यों भेजता है?
DMARC। SPF के अकेले फेल होने से पहले बचना संभव था; DMARC ने इसे एक वर्डिक्ट में बदल दिया। DMARC SPF और DKIM को एक साथ जोड़ता है और प्राप्त करने वालों को बताता है कि जब दोनों फेल हों तब क्या करें: कुछ नहीं, क्वारेंटीन, या अस्वीकार। 2024 तक, बड़े भेजने वालों के पास कोई विकल्प नहीं था — Google और Yahoo ने अपने उपयोगकर्ताओं को 5,000 से अधिक संदेश भेजने वाले किसी को भी DMARC की आवश्यकता करना शुरू कर दिया।
DKIM, दूसरा स्तंभ, एक ऐसा हस्ताक्षर है जो संदेश में बेक किया जाता है। सिद्धांत में यह फॉरवर्डिंग के बाद भी बना रहता है, क्योंकि यह सामग्री को हस्ताक्षरित करता है, रूट को नहीं। व्यावहार में, कुछ भी जो संदेश को छूता है उसे तोड़ देता है। एक मेलिंग लिस्ट जो एक "आप सदस्य हैं, यहां सदस्यता समाप्त करें" फूटर जोड़ता है, एक सर्वर जो विषय पंक्ति को फिर से लिखता है, यहां तक कि एक पंक्ति के लपेटने के तरीके में परिवर्तन — हस्ताक्षर अब मेल नहीं खाता, और DKIM भी फेल करता है। अब दोनों स्तंभ नीचे हैं, DMARC फेल कहता है, और आपकी अपनी रसीद जंक फोल्डर में है।
ARC क्या है और क्या यह वास्तव में इसे ठीक करता है?
ARC — Authenticated Received Chain, RFC 8617 — एक ईमानदार फॉरवर्डर को यह गारंटी देने देता है कि मेल इसे छूने से पहले प्रमाणीकरण पास कर चुकी थी। फॉरवर्डिंग सर्वर संदेश को एक सील किए गए रिकॉर्ड के साथ स्टैम्प करता है जो कहता है "जब यह मेरे तक पहुंचा, SPF और DKIM वैध थे — जिस हॉप को आप सत्यापित नहीं कर सकते उसके लिए मेरे शब्द पर विश्वास करें।" अंतिम प्राप्त करने वाला, यदि वह उस फॉरवर्डर पर विश्वास करता है, तो DMARC फेल को ओवरराइड कर सकता है और डिलीवर कर सकता है।
पकड़ "यदि वह विश्वास करता है" में है। ARC एक पासवर्ड नहीं है; यह एक प्रतिष्ठा प्रणाली है। एक प्राप्त करने वाला वजन करता है कि क्या ARC सील करने वाला एक ज्ञात, अच्छे व्यवहार वाला ऑपरेटर है। Google दोनों ARC हेडर स्टैम्प करता है और उन्हें उन भेजने वालों से सम्मानित करता है जिन पर वह विश्वास करता है, यही वजह है कि एक Gmail-से-Gmail फॉरवर्ड आमतौर पर बना रहता है जबकि कुछ प्राचीन विश्वविद्यालय रिले के माध्यम से फॉरवर्ड नहीं होता।
यदि आप फॉरवर्डिंग स्वयं चलाते हैं, तो दो ठोस कदम मदद करते हैं। Server-Side Redirect / SRS-स्टाइल रीराइटिंग का उपयोग करें यदि आपका होस्ट इसे प्रदान करता है, जो एनवेलप भेजने वाले को फिर से लिखता है ताकि SPF मूल डोमेन के बजाय आपके फॉरवर्डर के विरुद्ध जांच करे। और उन प्रदाताओं के बीच फॉरवर्डिंग को प्राथमिकता दें जो दोनों ARC का समर्थन करते हैं। यदि आप खातों को एकीकृत कर रहे हैं और चाहते हैं कि गंतव्य प्रमाणीकरण बिखरे को आपके लिए संभाले, यह ठीक उस प्रकार की प्लंबिंग है जिसके लिए एक AI ईमेल प्लेटफॉर्म बनाया गया है।
मुझे अपने प्रदाता को दोष देना कब बंद करना चाहिए?
जब पैटर्न "केवल फॉरवर्ड की गई मेल फेल होती है" हो, तो प्रदाता अपना काम सही तरीके से कर रहा है — प्रोटोकॉल समस्या है। यह संकेत है: लापता संदेश के हेडर खोलें और Authentication-Results पंक्ति को देखें। यदि आप spf=fail को एक भेजने वाले IP के साथ देखते हैं जो मूल भेजने वाले के बजाय एक फॉरवर्डर से संबंधित है, तो वह SPF गलत हॉप को जांच रहा है। यदि dkim=fail उस मेल पर दिखाई देता है जो एक लिस्ट या एक रिले के माध्यम से गई जो संदेशों को संपादित करता है, तो यह एक विकृत हस्ताक्षर है, जालसाजी नहीं।
अप्रिय सत्य यह है कि ईमेल प्रमाणीकरण दो दशकों में एक ऐसी प्रणाली पर बोल्ट किया गया था जो कभी नहीं मानती थी कि कोई झूठ बोलेगा। SPF 2006 में आया, DKIM 2007 में, DMARC 2015 में, ARC 2019 में — प्रत्येक एक छेद को पैच करते हुए जो पिछले वाले ने खोला। फॉरवर्डिंग वह सीम है जहां ये चारों एक दूसरे से रगड़ते हैं, और आपका इनबॉक्स वह जगह है जहां आप घर्षण को महसूस करते हैं।
स्रोत
- IETF RFC 8617 — Authenticated Received Chain (ARC) specification, 2019
- Google Workspace Admin Help — SPF, forwarding and authentication for forwarded mail
- Google Email sender guidelines — 2024 bulk sender DMARC requirements and 5,000/day threshold