E-post som skickas via ett VPN: vart svaret egentligen tar vägen

Du skickar ett meddelande genom tunneln, kopplar från, och svaret kommer nästa morgon. Ingenting av det behöver den gamla VPN-adressen, och ingenting av det går sönder. E-post dirigerar inte svar till adressen ett meddelande skickades från; den dirigerar dem till en postlåda. Tre vägar smälter här samman till en enda fråga, och att skilja dem åt besvarar det mesta av oron.

Tre vägar som människor smälter samman till en

Inlämning, leverans och läsning är tre separata anslutningar, och bara två av dem involverar din enhet.

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

VPN:et kan påverka den första och den tredje, eftersom det är anslutningar som din enhet gör. Det kan inte påverka den andra, eftersom den vägen går mellan två e-postservrar som du inte kontrollerar. Ett svar är inte ett paket som återvänder till adressen du skickade från. Det är ett nytt meddelande som den andra sidans e-posttjänst levererar till din postlådetjänst.

När du håller de tre isär slutar frågan om svaret hittar dig att vara mystisk.

Ett Reply-To-fält är en adress, inte en rutt

RFC 5322 definierar Reply-To som den postlåda eller de postlådor som svar ska skickas till. Utan det är standardvärdet vanligen From-postlådan, om inte personen som svarar skriver något annat. Båda är e-postadresser i ett huvud. Ingen av dem är en instruktion att öppna nätverksanslutningen som skickade det ursprungliga meddelandet igen.

Därför dyker aldrig en VPN-utgångsadress upp i svarsvägen. Även när inlämningsservern har registrerat den utgångsadressen någonstans är svaret adresserat till en postlåda, och servern som skickar slår upp domänens e-postväxel i stället för din gamla socket.

Om ett svar hamnar någonstans oväntat, läs Reply-To och avsändarens egna klientinställningar innan du misstänker tunneln.

Vad spårhuvudena faktiskt registrerar

Varje SMTP-hopp lägger till ett Received-huvud framför som beskriver anslutningen det hanterade, och det översta är det sista hoppet före leveransen. Ett insänt meddelande kan därför bära nätverksdetaljer som är värda att gå igenom, och dessa detaljer skrivs av servrar, inte valda av dig. Vad de innehåller beror på leverantörens inlämningsarkitektur och dess hantering av huvuden.

Läs dem i stället för att gissa, från ett sparat meddelande:

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

Den användbara disciplinen är att identifiera vilken betrodd tjänst som lade till varje fält. Godtycklig text tidigare i huvudblocket är inte tillförlitligt bevis, och ett produktnamn är inte ett permanent löfte om att din hemadress alltid finns där eller alltid saknas.

Att läsa e-post senare är en ny anslutning

När du öppnar svaret ansluter din klient till din postlådetjänst över det nätverk du är på nu. Det är en färsk anslutning med egen källadress, inte en fortsättning på gårdagens inlämningssocket. Den följer den aktuella policyn för det nätverk du använder i det ögonblicket.

Fjärrinnehåll är ännu en tredje sak. En e-postklient som laddar en fjärrbild eller följer en länk gör en separat begäran enligt sina nuvarande inställningar, och den begäran kan bära vilka identifierare som helst som meddelandet bäddat in. Det är inte SMTP-svaret som anländer till en gammal adress, och att behandla det som om det vore det döljer den verkliga exponeringen.

Stäng av fjärrinnehåll om du vill läsa ett meddelande utan att meddela att du öppnade det.

Vad du bör kontrollera innan du kallar det en läcka

Börja med visningen av det ursprungliga meddelandet och Reply-To-fältet. Identifiera sedan vilken tjänst som lade till de Received-poster som oroar dig, och jämför det med leverantörens aktuella dokumentation i stället för ett gammalt forumsvar.

Till sist, skilj på frågorna: vad observerade inlämningsservern, vad lade leveranskedjan till, och vad begärde din klient när du öppnade meddelandet?

Att svara på de tre separat är mer arbete än att kontrollera en IP-sida, och det är den enda versionen som ger en slutsats du kan försvara. Att svara på en e-postadress avslöjar inte din hemadress, och det kräver inte att den gamla tunneln hålls uppe.