E-mail verzonden via een VPN: waar het antwoord echt heen gaat

Je stuurt een bericht door de tunnel, verbreekt de verbinding en het antwoord komt de volgende ochtend aan. Niets daaraan heeft het oude VPN-adres nodig en niets daaraan gaat stuk. E-mail routert antwoorden niet naar het adres waarvandaan een bericht is verzonden; het routert ze naar een mailbox. Drie paden worden hier samengevoegd tot één vraag, en ze scheiden beantwoordt het grootste deel van de zorg.

Drie paden die mensen samenvoegen tot één

Inzending, bezorging en lezen zijn drie aparte verbindingen, en slechts twee daarvan betrekken je apparaat.

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

De VPN kan de eerste en de derde beïnvloeden, omdat dat verbindingen zijn die je apparaat maakt. Hij kan de tweede niet beïnvloeden, omdat dat pad tussen twee mailservers loopt die je niet beheert. Een antwoord is geen pakket dat terugkeert naar het adres waarvandaan je hebt verzonden. Het is een nieuw bericht dat de maildienst van de andere kant aflevert bij je mailboxdienst.

Zodra je die drie uit elkaar houdt, houdt de vraag of het antwoord je vindt op mysterieus te zijn.

Een Reply-To-veld is een adres, geen route

RFC 5322 definieert Reply-To als de mailbox of mailboxen waarnaar antwoorden moeten worden gestuurd. Zonder dat veld is de gebruikelijke standaard de From-mailbox, tenzij degene die antwoordt iets anders typt. Beide zijn mailadressen in een header. Geen van beide is een instructie om de netwerkverbinding die het oorspronkelijke bericht heeft ingediend opnieuw te openen.

Daarom verschijnt een VPN-uitgangsadres nooit in het antwoordpad. Zelfs wanneer de inzendingsserver dat uitgangsadres ergens heeft vastgelegd, is het antwoord geadresseerd aan een mailbox, en de verzendende server zoekt de mail exchanger van het domein op in plaats van je oude socket.

Als een antwoord ergens onverwacht belandt, lees dan Reply-To en de eigen clientinstellingen van de afzender voordat je de tunnel verdenkt.

Wat de trace-headers werkelijk vastleggen

Elke SMTP-hop zet een Received-header vooraan die de behandelde verbinding beschrijft, en de bovenste is de laatste hop voor de bezorging. Een ingediend bericht kan dus netwerkdetails bevatten die het bekijken waard zijn, en die details worden door servers geschreven, niet door jou gekozen. Wat erin staat hangt af van de inzendingsarchitectuur van de provider en de manier waarop die met headers omgaat.

Lees ze in plaats van te gokken, uit een opgeslagen bericht:

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

De nuttige discipline is vaststellen welke vertrouwde dienst elk veld heeft toegevoegd. Willekeurige tekst eerder in het headerblok is geen betrouwbaar bewijs, en een productnaam is geen blijvende belofte dat je thuisadres altijd aanwezig of altijd afwezig is.

Mail later lezen is een nieuwe verbinding

Wanneer je het antwoord opent, verbindt je client met je mailboxdienst via het netwerk waar je nu op zit. Dat is een verse verbinding met een eigen bronadres, geen voortzetting van de socket van gisteren. Hij volgt het huidige beleid van het netwerk dat je op dat moment gebruikt.

Externe inhoud is nog een derde ding. Een mailclient die een externe afbeelding laadt of een link volgt, doet een apart verzoek onder zijn huidige instellingen, en dat verzoek kan alle identificatoren bevatten die het bericht heeft ingebed. Het is niet het SMTP-antwoord dat op een oud adres aankomt, en het zo behandelen verbergt de echte blootstelling.

Schakel externe inhoud uit als je een bericht wilt lezen zonder aan te kondigen dat je het hebt geopend.

Wat je moet controleren voordat je het een lek noemt

Begin met de weergave van het oorspronkelijke bericht en het Reply-To-veld. Stel dan vast welke dienst de Received-regels heeft toegevoegd die je verontrusten, en vergelijk dat met de huidige documentatie van de provider in plaats van met een oud forumantwoord.

Ten slotte, scheid de vragen: wat heeft de inzendingsserver waargenomen, wat heeft de bezorgketen toegevoegd, en wat heeft je client aangevraagd toen je het bericht opende?

Die drie apart beantwoorden is meer werk dan een IP-pagina controleren, en het is de enige versie die een conclusie oplevert die je kunt verdedigen. Antwoorden op een e-mailadres onthult je thuisadres niet, en het vereist niet dat de oude tunnel blijft draaien.