E-pošta, poslana prek VPN: kam odgovor v resnici pride

Pošljete sporočilo skozi tunel, se odklopite in odgovor pride naslednje jutro. Nič pri tem ne potrebuje starega naslova VPN in nič se ne pokvari. E-pošta ne usmerja odgovorov na naslov, s katerega je bilo sporočilo poslano; usmerja jih v poštni predal. Tu se tri poti zlijejo v eno vprašanje, in če jih ločite, odgovorite na večino skrbi.

Tri poti, ki jih ljudje zlijejo v eno

Oddaja, dostava in branje so tri ločene povezave, in le dve od njih vključujeta vašo napravo.

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

VPN lahko vpliva na prvo in tretjo, ker sta to povezavi, ki jih vzpostavi vaša naprava. Ne more vplivati na drugo, ker ta pot poteka med dvema poštnima strežnikoma, ki jih ne nadzorujete. Odgovor ni paket, ki se vrne na naslov, s katerega ste poslali. To je novo sporočilo, ki ga poštna storitev druge strani dostavi vaši storitvi poštnega predala.

Ko te tri držite ločeno, vprašanje, ali vas bo odgovor našel, ni več skrivnostno.

Polje Reply-To je naslov, ne pot

RFC 5322 opredeljuje Reply-To kot poštni predal ali predale, na katere je treba pošiljati odgovore. Brez njega je običajna privzeta vrednost predal From, razen če oseba, ki odgovarja, vpiše kaj drugega. Oba sta poštna naslova v glavi. Nobeden ni navodilo, naj se omrežna povezava, ki je oddala izvirno sporočilo, znova odpre.

Zato se naslov izhoda VPN nikoli ne pojavi na poti odgovora. Tudi ko je strežnik za oddajo ta izhodni naslov nekje zabeležil, je odgovor naslovljen na poštni predal, pošiljajoči strežnik pa išče poštnega izmenjevalnika domene in ne vašega starega vtičnice.

Če odgovor pristane kje nepričakovano, preberite Reply-To in lastne nastavitve odjemalca pošiljatelja, preden sumite na tunel.

Kaj sledilne glave v resnici zabeležijo

Vsak skok SMTP spredaj doda glavo Received, ki opisuje obdelano povezavo, in najvišja je zadnji skok pred dostavo. Oddano sporočilo lahko zato nosi omrežne podrobnosti, ki jih velja pregledati, in te podrobnosti pišejo strežniki, ne izbirate jih vi. Kaj vsebujejo, je odvisno od arhitekture oddaje pri ponudniku in njegovega ravnanja z glavami.

Berite jih, namesto da ugibate, iz shranjenega sporočila:

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

Koristna disciplina je ugotoviti, katera zaupanja vredna storitev je dodala vsako polje. Poljubno besedilo prej v bloku glav ni zanesljiv dokaz, ime izdelka pa ni trajna obljuba, da je vaš domači naslov vedno prisoten ali vedno odsoten.

Poznejše branje pošte je nova povezava

Ko odprete odgovor, se vaš odjemalec poveže s storitvijo poštnega predala prek omrežja, v katerem ste zdaj. To je sveža povezava z lastnim izvornim naslovom, ne nadaljevanje včerajšnjega vtičnice za oddajo. Sledi trenutni politiki omrežja, ki ga v tistem trenutku uporabljate.

Oddaljena vsebina je spet tretja stvar. Odjemalec pošte, ki naloži oddaljeno sliko ali sledi povezavi, izvede ločeno zahtevo po svojih trenutnih nastavitvah, in ta zahteva lahko nosi vse identifikatorje, ki jih je sporočilo vgradilo. To ni odgovor SMTP, ki prispe na star naslov, in obravnavanje kot takega skrije resnično izpostavljenost.

Izklopite oddaljeno vsebino, če želite brati sporočilo, ne da bi objavili, da ste ga odprli.

Kaj preveriti, preden to imenujete puščanje

Začnite s pogledom izvirnega sporočila in poljem Reply-To. Nato ugotovite, katera storitev je dodala vnose Received, ki vas skrbijo, in to primerjajte s trenutno dokumentacijo ponudnika, ne s starim odgovorom s foruma.

Na koncu ločite vprašanja: kaj je opazil strežnik za oddajo, kaj je dodala dostavna veriga in kaj je vaš odjemalec zahteval, ko ste sporočilo odprli?

Odgovoriti na te tri ločeno je več dela kot preveriti stran IP in je edina različica, ki da sklep, ki ga lahko zagovarjate. Odgovor na elektronski naslov ne razkrije vašega domačega naslova in ne zahteva, da star tunel ostane vklopljen.