VPN से भेजा गया ईमेल: जवाब असल में कहाँ जाता है

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

तीन रास्ते जिन्हें लोग एक में मिला देते हैं

सबमिशन, डिलीवरी और पढ़ना तीन अलग कनेक्शन हैं, और इनमें से सिर्फ़ दो में आपका डिवाइस शामिल है।

Submission: your mail app  -> your mail service
Delivery:   other mail service -> your mailbox service
Reading:    your app now -> your mailbox service

VPN पहले और तीसरे को प्रभावित कर सकता है, क्योंकि ये वे कनेक्शन हैं जो आपका डिवाइस बनाता है। यह दूसरे को प्रभावित नहीं कर सकता, क्योंकि वह रास्ता दो ऐसे मेल सर्वरों के बीच चलता है जिन्हें आप नियंत्रित नहीं करते। जवाब वह पैकेट नहीं है जो उस पते पर लौटता है जिससे आपने भेजा था। यह एक नया संदेश है जिसे दूसरी ओर की मेल सेवा आपकी मेलबॉक्स सेवा तक पहुँचाती है।

जब आप इन तीनों को अलग रखते हैं, तो यह सवाल कि जवाब आप तक पहुँचेगा या नहीं, रहस्यमय रहना बंद कर देता है।

Reply-To फ़ील्ड एक पता है, कोई मार्ग नहीं

RFC 5322 Reply-To को उस मेलबॉक्स या मेलबॉक्सों के रूप में परिभाषित करता है जिन्हें जवाब भेजे जाने चाहिए। इसके बिना सामान्य डिफ़ॉल्ट From मेलबॉक्स है, जब तक जवाब देने वाला व्यक्ति कुछ और न लिखे। दोनों हेडर में बैठे मेल पते हैं। इनमें से कोई भी उस नेटवर्क कनेक्शन को फिर से खोलने का निर्देश नहीं है जिसने मूल संदेश सबमिट किया था।

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

अगर कोई जवाब कहीं अप्रत्याशित जगह जाए, तो टनल पर शक करने से पहले Reply-To और प्रेषक के अपने क्लाइंट सेटिंग्स पढ़िए।

ट्रेस हेडर असल में क्या दर्ज करते हैं

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

अनुमान लगाने के बजाय उन्हें सहेजे गए संदेश से पढ़िए:

grep -E '^(Received|Return-Path|Reply-To|From):' message.eml

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

बाद में मेल पढ़ना एक नया कनेक्शन है

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

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

अगर आप संदेश को यह बताए बिना पढ़ना चाहते हैं कि आपने उसे खोला है, तो रिमोट सामग्री बंद कर दीजिए।

इसे लीक कहने से पहले क्या जाँचें

मूल संदेश के दृश्य और Reply-To फ़ील्ड से शुरू कीजिए। फिर पहचानिए कि आपको परेशान करने वाली Received प्रविष्टियाँ किस सेवा ने जोड़ीं, और इसकी तुलना पुराने फ़ोरम के जवाब के बजाय प्रदाता के मौजूदा दस्तावेज़ से कीजिए।

अंत में, सवालों को अलग कीजिए: सबमिशन सर्वर ने क्या देखा, डिलीवरी श्रृंखला ने क्या जोड़ा, और जब आपने संदेश खोला तब आपके क्लाइंट ने क्या माँगा?

इन तीनों का अलग-अलग जवाब देना IP पेज जाँचने से ज़्यादा काम है, और यही एकमात्र संस्करण है जो ऐसा निष्कर्ष देता है जिसे आप बचा सकते हैं। ईमेल पते को जवाब देना आपके घर का पता नहीं उजागर करता, और इसके लिए पुरानी टनल का खुला रहना ज़रूरी नहीं है।