E-mail sendt over en VPN: hvor svaret faktisk ender

Du sender en besked gennem tunnelen, afbryder forbindelsen, og svaret ankommer næste morgen. Intet ved det har brug for den gamle VPN-adresse, og intet ved det går i stykker. E-mail sender ikke svar til den adresse, en besked blev sendt fra; den sender dem til en postkasse. Tre veje smelter her sammen til ét spørgsmål, og ved at skille dem ad besvarer man det meste af bekymringen.

Tre veje, som folk smelter sammen til én

Aflevering, levering og læsning er tre separate forbindelser, og kun to af dem involverer din enhed.

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

VPN'en kan påvirke den første og den tredje, fordi det er forbindelser, din enhed opretter. Den kan ikke påvirke den anden, fordi den vej går mellem to mailservere, du ikke kontrollerer. Et svar er ikke en pakke, der vender tilbage til den adresse, du sendte fra. Det er en ny besked, som den anden sides mailtjeneste leverer til din postkassetjeneste.

Når du holder de tre adskilt, holder spørgsmålet om svaret finder dig op med at være mystisk.

Et Reply-To-felt er en adresse, ikke en rute

RFC 5322 definerer Reply-To som den postkasse eller de postkasser, som svar skal sendes til. Uden feltet er standarden sædvanligvis From-postkassen, medmindre den person, der svarer, skriver noget andet. Begge er mailadresser i en header. Ingen af dem er en instruktion om at genåbne den netværksforbindelse, der afleverede den oprindelige besked.

Derfor optræder en VPN-udgangsadresse aldrig i svarvejen. Selv når afleveringsserveren har registreret den udgangsadresse et eller andet sted, er svaret adresseret til en postkasse, og afsenderens server slår domænets mailudveksler op i stedet for din gamle socket.

Hvis et svar ender uventet, så læs Reply-To og afsenderens egne klientindstillinger, før du mistænker tunnelen.

Hvad sporeheaderne faktisk registrerer

Hvert SMTP-hop tilføjer en Received-header, der beskriver den forbindelse, det håndterede, og den øverste er det sidste hop før levering. En afleveret besked kan derfor bære netværksdetaljer, der er værd at gennemgå, og disse detaljer skrives af servere, ikke valgt af dig. Hvad de indeholder, afhænger af udbyderens afleveringsarkitektur og dens håndtering af headere.

Læs dem i stedet for at gætte, fra en gemt besked:

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

Den nyttige disciplin er at identificere, hvilken betroet tjeneste der tilføjede hvert felt. Vilkårlig tekst tidligere i headerblokken er ikke pålideligt bevis, og et produktnavn er ikke et permanent løfte om, at din hjemadresse altid er til stede eller altid er fraværende.

At læse mail senere er en ny forbindelse

Når du åbner svaret, forbinder din klient til din postkassetjeneste over det netværk, du er på nu. Det er en frisk forbindelse med sin egen kildeaddresse, ikke en fortsættelse af gårsdagens afleveringssocket. Den følger den aktuelle politik for det netværk, du bruger i det øjeblik.

Fjernt indhold er endnu en tredje ting. En mailklient, der indlæser et fjernt billede eller følger et link, laver en separat anmodning under sine aktuelle indstillinger, og den anmodning kan bære alle de identifikatorer, beskeden har indlejret. Det er ikke SMTP-svaret, der ankommer til en gammel adresse, og at behandle det som om det var, skjuler den reelle eksponering.

Slå fjernt indhold fra, hvis du vil læse en besked uden at bekendtgøre, at du åbnede den.

Hvad du skal kontrollere, før du kalder det en lækage

Begynd med visningen af den oprindelige besked og Reply-To-feltet. Identificér derefter, hvilken tjeneste der tilføjede de Received-poster, der bekymrer dig, og sammenlign det med udbyderens aktuelle dokumentation i stedet for et gammelt forumsvar.

Til sidst, skil spørgsmålene ad: hvad observerede afleveringsserveren, hvad tilføjede leveringskæden, og hvad anmodede din klient om, da du åbnede beskeden?

At besvare de tre separat er mere arbejde end at tjekke en IP-side, og det er den eneste version, der giver en konklusion, du kan forsvare. At svare på en e-mailadresse afslører ikke din hjemadresse, og det kræver ikke, at den gamle tunnel forbliver oppe.