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 पृष्ठ जाँच्नुभन्दा बढी काम हो, र तपाईंले समर्थन गर्न सक्ने निष्कर्ष दिने एउटै संस्करण त्यही हो। इमेल ठेगानालाई जवाफ दिनुले तपाईंको घरको ठेगाना खुलासा गर्दैन, र पुरानो टनेल खुला राख्नुपर्ने माग गर्दैन।