Tölvupóstur sendur yfir VPN: hvert fer svarið í raun

Þú sendir skilaboð í gegnum göngin, aftengir þig, og svarið kemur morguninn eftir. Ekkert við það þarf gamla VPN-vistfangið, og ekkert við það brotnar. Tölvupóstur beinir svörum ekki á vistfangið sem skilaboð voru send frá; hann beinir þeim á pósthólf. Þrjár leiðir renna hér saman í eina spurningu, og aðgreining þeirra svarar stórum hluta áhyggjunnar.

Þrjár leiðir sem fólk rennir saman í eina

Innsending, afhending og lestur eru þrjár aðskildar tengingar, og aðeins tvær þeirra varða tækið þitt.

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

VPN getur haft áhrif á fyrstu og þriðju, því það eru tengingar sem tækið þitt býr til. Það getur ekki haft áhrif á aðra, því sú leið liggur milli tveggja póstþjóna sem þú stjórnar ekki. Svar er ekki pakki sem snýr aftur á vistfangið sem þú sendir frá. Það er ný skilaboð sem póstþjónusta hins aðilans afhendir pósthólfsþjónustunni þinni.

Þegar þú heldur þessum þremur aðskildum hættir spurningin um hvort svarið finni þig að vera ráðgáta.

Reply-To svæði er vistfang, ekki leið

RFC 5322 skilgreinir Reply-To sem pósthólfið eða pósthólfin sem svara á til. Án þess er venjulegt sjálfgefið gildi From pósthólfið, nema sá sem svarar skrifi eitthvað annað. Bæði eru póstvistföng í haus. Hvorugt er fyrirmæli um að opna aftur nettenginguna sem sendi upprunalegu skilaboðin.

Þess vegna birtist útgangsvistfang VPN aldrei á svarleiðinni. Jafnvel þegar innsendingarþjónninn hefur skráð það útgangsvistfang einhvers staðar, er svarið beint á pósthólf, og sendandi þjónninn flettir upp póstskiptum lénsins í stað gamla sokkans þíns.

Ef svar fer eitthvert óvænt, lestu Reply-To og eigin stillingar biðlara sendandans áður en þú grunar göngin.

Hvað hausarnir í rakningunni skrá í raun

Sérhver SMTP-stökk bætir framan við Received-haus sem lýsir tengingunni sem hún annaðist, og sá efsti er síðasta stökkið fyrir afhendingu. Sent skilaboð geta því borið netupplýsingar sem vert er að fara yfir, og þær upplýsingar skrifa þjónar, ekki þú. Hvað þær innihalda fer eftir innsendingararkitektúr veitandans og meðferð hans á hausum.

Lestu þær í stað þess að giska, úr vistuðum skilaboðum:

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

Gagnleg aga er að greina hvaða trausta þjónusta bætti hverju svæði við. Handahófskenndur texti fyrr í hausblokkinni er ekki áreiðanleg sönnun, og vöruheiti er ekki varanlegt loforð um að heimilisfang þitt sé alltaf til staðar eða alltaf fjarverandi.

Að lesa póst síðar er ný tenging

Þegar þú opnar svarið tengist biðlarinn þinn pósthólfsþjónustunni þinni yfir það net sem þú ert á núna. Þetta er fersk tenging með eigin upprunavistfangi, ekki framhald innsendingarsokkans frá í gær. Hún fylgir gildandi stefnu netsins sem þú notar á þeirri stundu.

Fjarlægt efni er enn þriðja atriðið. Póstbiðlari sem hleður fjarlægri mynd eða fylgir hlekk gerir aðskilda beiðni samkvæmt núverandi stillingum sínum, og sú beiðni getur borið hvaða auðkenni sem skilaboðin felldu inn. Það er ekki SMTP-svarið sem berst á gamalt vistfang, og að líta á það sem slíkt felur raunverulega útsetningu.

Slökktu á fjarlægu efni ef þú vilt lesa skilaboð án þess að tilkynna að þú hafir opnað þau.

Hvað á að athuga áður en þetta er kallað leki

Byrjaðu á sýn upprunalegu skilaboðanna og Reply-To svæðinu. Greindu síðan hvaða þjónusta bætti við Received-færslunum sem valda þér áhyggjum, og berðu það saman við gildandi skjöl veitandans frekar en gamalt svar á spjallborði.

Að lokum, aðskildu spurningarnar: hvað tók innsendingarþjónninn eftir, hvað bætti afhendingarkeðjan við, og hvað bað biðlarinn þinn um þegar þú opnaðir skilaboðin?

Að svara þessum þremur aðskildum er meiri vinna en að skoða IP-síðu, og það er eina útgáfan sem gefur niðurstöðu sem þú getur varið. Að svara tölvupóstfangi afhjúpar ekki heimilisfang þitt, og það krefst þess ekki að gömlu göngin haldist uppi.