El. laiškas, išsiųstas per VPN: kur iš tikrųjų nukeliauja atsakymas

Siunčiate žinutę tuneliu, atsijungiate, o atsakymas ateina kitą rytą. Tam nereikia seno VPN adreso ir niekas tam nesugenda. El. paštas neperadresuoja atsakymų į adresą, iš kurio buvo išsiųsta žinutė; jis nukreipia juos į pašto dėžutę. Trys keliai čia suplakami į vieną klausimą, o juos atskyrus atsakoma į didžiąją dalį nerimo.

Trys keliai, kuriuos žmonės suplaka į vieną

Pateikimas, pristatymas ir skaitymas yra trys atskiri ryšiai, ir tik du iš jų susiję su jūsų įrenginiu.

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

VPN gali paveikti pirmąjį ir trečiąjį, nes tai ryšiai, kuriuos užmezga jūsų įrenginys. Jis negali paveikti antrojo, nes tas kelias eina tarp dviejų pašto serverių, kurių jūs nekontroliuojate. Atsakymas nėra paketas, grįžtantis į adresą, iš kurio siuntėte. Tai nauja žinutė, kurią kitos pusės pašto tarnyba pristato jūsų pašto dėžutės tarnybai.

Kai tuos tris laikote atskirai, klausimas, ar atsakymas jus ras, nustoja būti paslaptingas.

Reply-To laukas yra adresas, o ne maršrutas

RFC 5322 apibrėžia Reply-To kaip pašto dėžutę ar dėžutes, kurioms turi būti siunčiami atsakymai. Be jo įprasta numatytoji reikšmė yra From dėžutė, nebent atsakantis asmuo įveda ką nors kita. Abu yra pašto adresai, esantys antraštėje. Nė vienas nėra nurodymas iš naujo atidaryti tinklo ryšį, kuris pateikė pradinę žinutę.

Štai kodėl VPN išėjimo adresas niekada nepasirodo atsakymo kelyje. Net kai pateikimo serveris tą išėjimo adresą kažkur užrašė, atsakymas adresuojamas pašto dėžutei, o siunčiantis serveris ieško domeno pašto mainų serverio, o ne jūsų seno lizdo.

Jei atsakymas nueina kažkur netikėtai, perskaitykite Reply-To ir paties siuntėjo kliento nustatymus, prieš įtardami tunelį.

Ką iš tikrųjų užrašo sekimo antraštės

Kiekvienas SMTP šuolis priekyje prideda Received antraštę, apibūdinančią apdorotą ryšį, o viršutinė yra paskutinis šuolis prieš pristatymą. Todėl pateikta žinutė gali nešti tinklo detales, kurias verta peržiūrėti, ir tas detales rašo serveriai, o ne jūs. Ką jos turi, priklauso nuo teikėjo pateikimo architektūros ir jo elgesio su antraštėmis.

Skaitykite jas, o ne spėliokite, iš išsaugotos žinutės:

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

Naudinga disciplina yra nustatyti, kuri patikima tarnyba pridėjo kiekvieną lauką. Savavališkas tekstas anksčiau antraščių bloke nėra patikimas įrodymas, o produkto pavadinimas nėra amžinas pažadas, kad jūsų namų adresas visada yra arba visada jo nėra.

Pašto skaitymas vėliau yra naujas ryšys

Kai atidarote atsakymą, jūsų klientas prisijungia prie jūsų pašto dėžutės tarnybos per tinklą, kuriame dabar esate. Tai naujas ryšys su savu šaltinio adresu, o ne vakarykščio pateikimo lizdo tęsinys. Jis laikosi to tinklo, kurį tuo metu naudojate, dabartinės politikos.

Nuotolinis turinys yra dar trečias dalykas. Pašto klientas, įkeliantis nuotolinį vaizdą ar sekantis nuorodą, pagal dabartinius nustatymus atlieka atskirą užklausą, ir toje užklausoje gali būti bet kokių identifikatorių, kuriuos žinutė įterpė. Tai ne SMTP atsakymas, atkeliaujantis į seną adresą, ir traktuojant jį taip paslepiama tikroji ekspozicija.

Išjunkite nuotolinį turinį, jei norite perskaityti žinutę nepaskelbdami, kad ją atidarėte.

Ką patikrinti, prieš vadinant tai nutekėjimu

Pradėkite nuo pradinės žinutės rodinio ir Reply-To lauko. Tada nustatykite, kuri tarnyba pridėjo Received įrašus, kurie jus neramina, ir palyginkite tai su dabartine teikėjo dokumentacija, o ne su senu forumo atsakymu.

Galiausiai atskirkite klausimus: ką pastebėjo pateikimo serveris, ką pridėjo pristatymo grandinė ir ko paprašė jūsų klientas, kai atidarėte žinutę?

Atsakyti į šiuos tris atskirai yra daugiau darbo nei patikrinti IP puslapį, ir tai vienintelė versija, kuri duoda išvadą, kurią galite apginti. Atsakymas į el. pašto adresą neatskleidžia jūsų namų adreso ir nereikalauja, kad senas tunelis liktų atidarytas.