E-post send gjennom ein VPN: kvar svaret faktisk hamnar

Du sender ei melding gjennom tunnelen, koplar frå, og svaret kjem neste morgon. Ingenting ved det treng den gamle VPN-adressa, og ingenting ved det går i stykker. E-post rutar ikkje svar til adressa ei melding vart send frå; han rutar dei til ein postkasse. Tre vegar smeltar her saman til eitt spørsmål, og å skilje dei svarar på det meste av uroa.

Tre vegar som folk smeltar saman til éin

Innsending, levering og lesing er tre skilde tilkoplingar, og berre to av dei involverer eininga di.

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åverke den første og den tredje, fordi det er tilkoplingar eininga di lagar. Han kan ikkje påverke den andre, fordi den vegen går mellom to e-posttenarar du ikkje kontrollerer. Eit svar er ikkje ein pakke som kjem tilbake til adressa du sende frå. Det er ei ny melding som e-posttenesta på den andre sida leverer til postkassetenesta di.

Når du held dei tre frå kvarandre, sluttar spørsmålet om svaret finn deg å vere mystisk.

Eit Reply-To-felt er ei adresse, ikkje ei rute

RFC 5322 definerer Reply-To som postkassen eller postkassane svar skal sendast til. Utan det er standardverdien vanlegvis From-postkassen, med mindre personen som svarar skriv noko anna. Begge er e-postadresser i ein header. Ingen av dei er ei instruks om å opne nettverkstilkoplinga som sende den opphavlege meldinga på nytt.

Difor dukkar aldri ei VPN-utgangsadresse opp i svarvegen. Sjølv når innsendingsserveren har registrert den utgangsadressa ein stad, er svaret adressert til ein postkasse, og serveren som sender slår opp e-postvekslaren til domenet i staden for den gamle sockelen din.

Viss eit svar hamnar uventa, les Reply-To og klientinnstillingane til avsendaren sjølv før du mistenkjer tunnelen.

Kva sporehovuda faktisk registrerer

Kvart SMTP-hopp legg til eit Received-hovud framfor som skildrar tilkoplinga det handterte, og det øvste er det siste hoppet før levering. Ei send melding kan difor bere nettverksdetaljar som er verd å gå gjennom, og desse detaljane vert skrivne av serverar, ikkje valde av deg. Kva dei inneheld avheng av innsendingsarkitekturen til leverandøren og handsaminga hans av hovud.

Les dei i staden for å gisse, frå ei lagra melding:

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

Den nyttige disiplinen er å identifisere kva klarert teneste som la til kvart felt. Vilkårleg tekst tidlegare i hovudblokka er ikkje påliteleg prov, og eit produktnamn er ikkje eit permanent løfte om at heimeadressa di alltid er der eller alltid er fråverande.

Å lese e-post seinare er ei ny tilkopling

Når du opnar svaret, koplar klienten din til postkassetenesta di over nettverket du er på no. Det er ei fersk tilkopling med si eiga kjeldeadresse, ikkje ein framhald av gårsdagens innsendingssokkel. Ho følgjer gjeldande policy for nettverket du brukar i det augneblinken.

Fjernt innhald er endå ein tredje ting. Ein e-postklient som lastar eit fjernt bilete eller følgjer ei lenke, gjer ei separat førespurnad under dei gjeldande innstillingane sine, og den førespurnaden kan bere alle identifikatorane meldinga har bygt inn. Det er ikkje SMTP-svaret som kjem til ei gammal adresse, og å handsame det som om det var det, skjuler den reelle eksponeringa.

Slå av fjernt innhald viss du vil lese ei melding utan å kunngjere at du opna ho.

Kva du bør sjekke før du kallar det ein lekkasje

Byrja med visinga av den opphavlege meldinga og Reply-To-feltet. Identifiser deretter kva teneste som la til Received-oppføringane som uroar deg, og samanlikn det med gjeldande dokumentasjon frå leverandøren i staden for eit gammalt forumssvar.

Til slutt, skil spørsmåla: kva observerte innsendingsserveren, kva la leveringskjeda til, og kva bad klienten din om då du opna meldinga?

Å svare på dei tre separat er meir arbeid enn å sjekke ei IP-side, og det er den einaste versjonen som gir ein konklusjon du kan forsvare. Å svare på ei e-postadresse avdekkjer ikkje heimeadressa di, og det krev ikkje at den gamle tunnelen held seg oppe.