VPN-i kaudu saadetud e-kiri: kuhu vastus tegelikult läheb

Saadate sõnumi tunnelist läbi, katkestate ühenduse ja vastus saabub järgmisel hommikul. Miski selles ei vaja vana VPN-i aadressi ja miski selles ei lähe katki. E-post ei suuna vastuseid aadressile, millelt sõnum saadeti; see suunab need postkasti. Kolm teed surutakse siin kokku üheks küsimuseks ja nende eraldamine vastab suuremale osale murest.

Kolm teed, mille inimesed üheks suruvad

Esitamine, kohaletoimetamine ja lugemine on kolm eraldi ühendust ning ainult kaks neist hõlmavad teie seadet.

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

VPN saab mõjutada esimest ja kolmandat, sest need on ühendused, mille teie seade loob. Teist see mõjutada ei saa, sest see tee kulgeb kahe postiserveri vahel, mida te ei kontrolli. Vastus ei ole pakett, mis naaseb aadressile, millelt saatsite. See on uus sõnum, mille teise poole postiteenus toimetab teie postkastiteenusesse.

Kui hoiate need kolm lahus, lakkab küsimus, kas vastus teid leiab, olemast mõistatuslik.

Reply-To väli on aadress, mitte marsruut

RFC 5322 määratleb Reply-To postkasti või postkastidena, kuhu vastused tuleb saata. Ilma selleta on tavaline vaikeväärtus From postkast, kui vastaja ei kirjuta midagi muud. Mõlemad on päises asuvad postiaadressid. Kumbki ei ole korraldus avada uuesti võrguühendust, mis algse sõnumi esitas.

Seetõttu ei esine VPN-i väljumisaadress kunagi vastuse teel. Isegi kui esitusserver on selle väljumisaadressi kuskil kirja pannud, on vastus adresseeritud postkasti ning saatja server otsib domeeni postivahendajat, mitte teie vana socketit.

Kui vastus läheb kuhugi ootamatusse kohta, lugege Reply-To välja ja saatja enda kliendiseadeid enne, kui kahtlustate tunnelit.

Mida jälituspäised tegelikult kirja panevad

Iga SMTP hüpe lisab ette Received päise, mis kirjeldab käsitletud ühendust, ja kõige ülemine on viimane hüpe enne kohaletoimetamist. Esitatud sõnum võib seega kanda võrgudetaile, mida tasub üle vaadata, ja neid detaile kirjutavad serverid, mitte teie. Mida need sisaldavad, sõltub teenusepakkuja esitusarhitektuurist ja päiste käsitlemisest.

Lugege neid oletamise asemel salvestatud sõnumist:

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

Kasulik distsipliin on teha kindlaks, milline usaldusväärne teenus iga välja lisas. Päisebloki varasem suvaline tekst ei ole usaldusväärne tõend ning tootenimi ei ole jääv lubadus, et teie koduaadress on alati olemas või alati puudub.

Posti hilisem lugemine on uus ühendus

Kui vastuse avate, ühendub teie klient teie postkastiteenusega võrgu kaudu, milles te praegu olete. See on värske ühendus omaenda lähteaadressiga, mitte eilse esitus-socketi jätk. See järgib selle võrgu kehtivat poliitikat, mida te sel hetkel kasutate.

Kaugsisu on jälle kolmas asi. E-postiklient, mis laadib kaugpildi või järgib linki, teeb oma kehtivate seadetega eraldi päringu ja see päring võib kanda kõiki identifikaatoreid, mille sõnum on lisanud. See ei ole vanale aadressile saabuv SMTP vastus ja selle nii kohtlemine varjab tegelikku kokkupuudet.

Lülitage kaugsisu välja, kui soovite sõnumit lugeda ilma teatamata, et selle avasite.

Mida kontrollida enne, kui nimetate seda lekkeks

Alustage algse sõnumi vaatest ja Reply-To väljast. Seejärel tehke kindlaks, milline teenus lisas Received kirjed, mis teid muretsema panevad, ja võrrelge seda teenusepakkuja kehtiva dokumentatsiooniga, mitte vana foorumivastusega.

Lõpuks eraldage küsimused: mida esitusserver täheldas, mida lisas kohaletoimetamise ahel ja mida küsis teie klient, kui sõnumi avasite?

Nende kolme eraldi vastamine on rohkem tööd kui IP-lehe kontrollimine ja see on ainus versioon, mis annab järelduse, mida saate kaitsta. E-posti aadressile vastamine ei avalda teie koduaadressi ega nõua, et vana tunnel avatuks jääks.