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 పేజీని తనిఖీ చేయడం కంటే ఎక్కువ పని, మరియు మీరు సమర్థించగల నిర్ణయాన్ని ఇచ్చే ఏకైక సంస్కరణ అదే. ఈమెయిల్ చిరునామాకు ప్రత్యుత్తరం ఇవ్వడం మీ ఇంటి చిరునామాను బహిర్గతం చేయదు, పాత సొరంగం తెరిచి ఉండాలని కోరదు.