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 પૃષ્ઠ તપાસવા કરતાં વધુ કામ છે અને એ જ એકમાત્ર આવૃત્તિ છે જે તમે સમર્થન કરી શકો તેવો નિષ્કર્ષ આપે છે. ઈમેલ સરનામાને જવાબ આપવાથી તમારું ઘરનું સરનામું જાહેર થતું નથી અને એ જૂની ટનલ ચાલુ રાખવાની માંગ કરતું નથી.