E-pošta poslana preko VPN-a: kuda odgovor zaista odlazi

Pošaljete poruku kroz tunel, isključite se, i odgovor stigne sledećeg jutra. Ništa u vezi s tim ne traži staru VPN adresu, i ništa se pri tome ne kvari. E-pošta ne usmerava odgovore na adresu s koje je poruka poslata; usmerava ih na poštansko sanduče. Tri puta se ovde stapaju u jedno pitanje, a njihovo razdvajanje odgovara na veći deo brige.

Tri puta koja ljudi stapaju u jedan

Predaja, dostava i čitanje su tri odvojene veze, i samo dve od njih uključuju vaš uređaj.

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

VPN može uticati na prvu i treću, jer su to veze koje vaš uređaj uspostavlja. Ne može uticati na drugu, jer taj put prolazi između dva poštanska servera koja ne kontrolišete. Odgovor nije paket koji se vraća na adresu s koje ste poslali. To je nova poruka koju poštanska služba druge strane dostavlja vašoj službi poštanskog sandučeta.

Kada ta tri držite odvojeno, pitanje da li će vas odgovor naći prestaje da bude tajanstveno.

Polje Reply-To je adresa, a ne ruta

RFC 5322 definiše Reply-To kao poštansko sanduče ili sandučiće na koje odgovore treba slati. Bez njega je uobičajena podrazumevana vrednost From sanduče, osim ako osoba koja odgovara upiše nešto drugo. Oba su poštanske adrese u zaglavlju. Nijedno nije uputstvo da se ponovo otvori mrežna veza koja je predala izvornu poruku.

Zato se adresa VPN izlaza nikada ne pojavljuje na putu odgovora. Čak i kada je server za predaju tu izlaznu adresu negde zabeležio, odgovor se adresira na poštansko sanduče, a server pošiljaoca traži poštanski razmenjivač domena, a ne vaš stari socket.

Ako odgovor ode negde neočekivano, pročitajte Reply-To i sopstvena podešavanja klijenta pošiljaoca pre nego što posumnjate na tunel.

Šta zapisi u zaglavljima za praćenje zaista beleže

Svaki SMTP skok dodaje napred zaglavlje Received koje opisuje obrađenu vezu, a najgornje je poslednji skok pre dostave. Predata poruka zato može nositi mrežne detalje koje vredi pregledati, a te detalje pišu serveri, ne birate ih vi. Šta sadrže zavisi od arhitekture predaje kod pružaoca usluge i njegovog rukovanja zaglavljima.

Čitajte ih umesto da nagađate, iz sačuvane poruke:

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

Korisna disciplina je utvrditi koja je pouzdana usluga dodala svako polje. Proizvoljan tekst ranije u bloku zaglavlja nije pouzdan dokaz, a naziv proizvoda nije trajno obećanje da je vaša kućna adresa uvek prisutna ili uvek odsutna.

Čitanje pošte kasnije je nova veza

Kada otvorite odgovor, vaš klijent se povezuje sa vašom službom poštanskog sandučeta preko mreže na kojoj ste sada. To je sveža veza sa sopstvenom izvornom adresom, a ne nastavak jučerašnjeg socketa za predaju. Ona sledi trenutnu politiku mreže koju u tom trenutku koristite.

Udaljeni sadržaj je opet treća stvar. Klijent e-pošte koji učitava udaljenu sliku ili prati vezu pravi poseban zahtev prema svojim trenutnim podešavanjima, a taj zahtev može nositi sve identifikatore koje je poruka ugradila. To nije SMTP odgovor koji stiže na staru adresu, a tretiranje kao da jeste skriva stvarnu izloženost.

Isključite udaljeni sadržaj ako želite da pročitate poruku a da ne objavite da ste je otvorili.

Šta proveriti pre nego što to nazovete curenjem

Počnite sa prikazom izvorne poruke i poljem Reply-To. Zatim utvrdite koja je usluga dodala zapise Received koji vas brinu i uporedite to sa trenutnom dokumentacijom pružaoca usluge, a ne sa starim odgovorom sa foruma.

Na kraju razdvojite pitanja: šta je server za predaju primetio, šta je dodao lanac dostave i šta je vaš klijent zatražio kada ste otvorili poruku?

Odgovoriti na ta tri odvojeno više je posla nego proveriti IP stranicu, i to je jedina verzija koja daje zaključak koji možete braniti. Odgovor na adresu e-pošte ne otkriva vašu kućnu adresu i ne zahteva da stari tunel ostane uključen.