Email na ipinadala sa VPN: saan talaga napupunta ang sagot

Nagpapadala ka ng mensahe sa lagusan, nadidiskonekta, at dumarating ang sagot kinaumagahan. Wala sa mga ito ang nangangailangan ng lumang VPN address, at wala ring nasisira. Hindi itinuturo ng email ang mga sagot sa address na pinagpadalhan ng mensahe; itinuturo ito sa isang mailbox. Tatlong landas ang pinagsasama dito sa isang tanong, at ang paghihiwalay sa kanila ay sumasagot sa malaking bahagi ng pagkabahala.

Tatlong landas na pinagsasama ng mga tao sa isa

Ang pagsusumite, paghahatid at pagbasa ay tatlong magkakaibang koneksyon, at dalawa lamang sa kanila ang may kinalaman sa iyong device.

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

Maaaring maapektuhan ng VPN ang una at ikatlo, dahil mga koneksyong ginagawa ng iyong device ang mga iyon. Hindi nito maaapektuhan ang ikalawa, dahil ang landas na iyon ay dumadaan sa pagitan ng dalawang mail server na hindi mo kontrolado. Ang sagot ay hindi isang packet na bumabalik sa address na pinagpadalhan mo. Ito ay isang bagong mensahe na inihahatid ng mail service ng kabilang panig sa iyong mailbox service.

Kapag pinaghiwalay mo ang tatlong iyon, hindi na mahiwaga ang tanong kung mahahanap ka ng sagot.

Ang field na Reply-To ay isang address, hindi isang ruta

Itinatakda ng RFC 5322 ang Reply-To bilang mailbox o mga mailbox na dapat padalhan ng mga sagot. Kung wala ito, ang karaniwang default ay ang From mailbox, maliban kung may ibang itina-type ang taong sumasagot. Pareho silang mail address na nasa header. Wala sa kanila ang utos na buksan muli ang network connection na nagsumite ng orihinal na mensahe.

Kaya hindi kailanman lumilitaw ang exit address ng VPN sa landas ng sagot. Kahit naitala ng submission server ang exit address na iyon sa kung saan, ang sagot ay nakapadala sa isang mailbox, at hinahanap ng nagpapadalang server ang mail exchanger ng domain sa halip na ang luma mong socket.

Kung ang isang sagot ay napunta sa hindi inaasahang lugar, basahin ang Reply-To at ang sariling mga setting ng client ng nagpadala bago mo paghinalaan ang lagusan.

Ano ba talaga ang itinatala ng mga trace header

Bawat SMTP hop ay nagdaragdag ng Received header sa unahan na naglalarawan sa koneksyong hinawakan nito, at ang pinakamataas ay ang huling hop bago ang paghahatid. Kaya ang isinumiteng mensahe ay maaaring magdala ng mga detalye ng network na dapat suriin, at ang mga detalyeng iyon ay sinusulat ng mga server, hindi mo pinipili. Ang nilalaman nila ay depende sa arkitektura ng pagsusumite ng provider at sa paraan ng paghawak nito sa mga header.

Basahin ang mga ito sa halip na manghula, mula sa naka-save na mensahe:

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

Ang kapaki-pakinabang na disiplina ay tukuyin kung aling pinagkakatiwalaang serbisyo ang nagdagdag ng bawat field. Ang arbitraryong teksto na mas maaga sa header block ay hindi mapagkakatiwalaang ebidensya, at ang pangalan ng produkto ay hindi permanenteng pangako na ang iyong tirahan ay laging naroroon o laging wala.

Ang pagbasa ng mail mamaya ay isang bagong koneksyon

Kapag binuksan mo ang sagot, kumokonekta ang iyong client sa iyong mailbox service sa network kung nasaan ka ngayon. Ito ay isang bagong koneksyon na may sariling source address, hindi pagpapatuloy ng socket ng pagsusumite kahapon. Sinusunod nito ang kasalukuyang patakaran ng network na ginagamit mo sa sandaling iyon.

Ang remote content ay isa pang ikatlong bagay. Ang mail client na naglo-load ng malayong larawan o sumusunod sa link ay gumagawa ng hiwalay na kahilingan ayon sa kasalukuyang mga setting nito, at ang kahilingang iyon ay maaaring magdala ng anumang identifier na ikinabit ng mensahe. Hindi ito ang SMTP na sagot na dumarating sa lumang address, at ang ituring itong ganoon ay nagtatago ng tunay na pagkakalantad.

Patayin ang remote content kung gusto mong basahin ang mensahe nang hindi ipinapaalam na binuksan mo ito.

Ano ang dapat suriin bago mo itong tawaging leak

Magsimula sa view ng orihinal na mensahe at sa field na Reply-To. Pagkatapos, tukuyin kung aling serbisyo ang nagdagdag ng mga entry na Received na nakakabahala sa iyo, at ihambing iyon sa kasalukuyang dokumentasyon ng provider sa halip na sa lumang sagot sa forum.

Sa huli, ihiwalay ang mga tanong: ano ang naobserbahan ng submission server, ano ang idinagdag ng chain ng paghahatid, at ano ang hiniling ng iyong client noong binuksan mo ang mensahe?

Ang pagsagot sa tatlong iyon nang hiwalay ay mas maraming trabaho kaysa sa pagsuri ng pahina ng IP, at ito ang tanging bersyon na nagbibigay ng konklusyong maipagtatanggol mo. Ang pagsagot sa isang email address ay hindi naglalantad ng iyong tirahan, at hindi nito hinihiling na manatiling bukas ang lumang lagusan.