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 पृष्ठ तपासण्यापेक्षा जास्त काम आहे आणि तुम्ही समर्थन करू शकता असा निष्कर्ष देणारी हीच एकमेव आवृत्ती आहे. ईमेल पत्त्याला उत्तर देणे तुमचा घरचा पत्ता उघड करत नाही आणि जुने टनेल उघडे ठेवण्याची मागणी करत नाही.