Email inviata tramite una VPN: dove va davvero la risposta

Invii un messaggio attraverso il tunnel, ti disconnetti e la risposta arriva la mattina dopo. Niente di tutto ciò ha bisogno del vecchio indirizzo VPN e niente si rompe. La posta elettronica non instrada le risposte verso l'indirizzo da cui è stato inviato un messaggio; le instrada verso una casella di posta. Qui tre percorsi vengono fusi in un'unica domanda, e separarli risponde alla maggior parte della preoccupazione.

Tre percorsi che le persone fondono in uno

Inoltro, consegna e lettura sono tre connessioni separate, e solo due di esse coinvolgono il tuo dispositivo.

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

La VPN può influire sulla prima e sulla terza, perché sono connessioni che il tuo dispositivo effettua. Non può influire sulla seconda, perché quel percorso passa tra due server di posta che non controlli. Una risposta non è un pacchetto che torna all'indirizzo da cui hai inviato. È un nuovo messaggio che il servizio di posta dell'altra parte consegna al tuo servizio di casella di posta.

Quando tieni separati questi tre, la domanda se la risposta ti troverà smette di essere misteriosa.

Un campo Reply-To è un indirizzo, non una rotta

La RFC 5322 definisce Reply-To come la casella o le caselle di posta a cui vanno inviate le risposte. Senza di esso, il valore predefinito abituale è la casella From, a meno che chi risponde digiti qualcos'altro. Entrambe sono indirizzi di posta dentro un'intestazione. Nessuna delle due è un'istruzione a riaprire la connessione di rete che ha inviato il messaggio originale.

Ecco perché un indirizzo di uscita VPN non compare mai nel percorso della risposta. Anche quando il server di inoltro ha registrato da qualche parte quell'indirizzo di uscita, la risposta è indirizzata a una casella di posta, e il server mittente cerca il mail exchanger del dominio invece del tuo vecchio socket.

Se una risposta finisce in un posto inatteso, leggi Reply-To e le impostazioni del client del mittente prima di sospettare del tunnel.

Che cosa registrano davvero le intestazioni di traccia

Ogni salto SMTP antepone un'intestazione Received che descrive la connessione gestita, e la più in alto è l'ultimo salto prima della consegna. Un messaggio inviato può quindi portare dettagli di rete che vale la pena esaminare, e quei dettagli sono scritti dai server, non scelti da te. Che cosa contengono dipende dall'architettura di inoltro del provider e dalla sua gestione delle intestazioni.

Leggile invece di indovinare, da un messaggio salvato:

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

La disciplina utile è identificare quale servizio fidato ha aggiunto ogni campo. Il testo arbitrario più in alto nel blocco delle intestazioni non è una prova affidabile, e il nome di un prodotto non è una promessa permanente che il tuo indirizzo di casa sia sempre presente o sempre assente.

Leggere la posta più tardi è una nuova connessione

Quando apri la risposta, il tuo client si connette al tuo servizio di casella di posta attraverso la rete su cui ti trovi ora. È una connessione nuova con il proprio indirizzo di origine, non la continuazione del socket di inoltro di ieri. Segue la politica attuale della rete che stai usando in quel momento.

Il contenuto remoto è ancora una terza cosa. Un client di posta che carica un'immagine remota o segue un collegamento effettua una richiesta separata secondo le sue impostazioni attuali, e quella richiesta può portare qualsiasi identificatore il messaggio abbia incorporato. Non è la risposta SMTP che arriva a un vecchio indirizzo, e trattarla come tale nasconde l'esposizione reale.

Disattiva il contenuto remoto se vuoi leggere un messaggio senza annunciare che l'hai aperto.

Che cosa controllare prima di parlare di fuga di dati

Inizia dalla vista del messaggio originale e dal campo Reply-To. Poi identifica quale servizio ha aggiunto le voci Received che ti preoccupano, e confrontalo con la documentazione attuale del provider invece che con una vecchia risposta di un forum.

Infine, separa le domande: che cosa ha osservato il server di inoltro, che cosa ha aggiunto la catena di consegna, e che cosa ha richiesto il tuo client quando hai aperto il messaggio?

Rispondere a queste tre separatamente è più faticoso che controllare una pagina IP, ed è l'unica versione che produce una conclusione che puoi difendere. Rispondere a un indirizzo email non rivela il tuo indirizzo di casa e non richiede che il vecchio tunnel resti attivo.