Correu enviat per una VPN: on va realment la resposta

Envieu un missatge pel túnel, us desconnecteu i la resposta arriba l'endemà al matí. Res d'això no necessita l'adreça VPN antiga i res d'això no es trenca. El correu no encamina les respostes a l'adreça des de la qual es va enviar un missatge; les encamina a una bústia. Aquí tres camins s'ajunten en una sola pregunta, i separar-los respon a la major part del neguit.

Tres camins que la gent ajunta en un

Enviament, lliurament i lectura són tres connexions separades, i només dues d'elles impliquen el vostre dispositiu.

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

La VPN pot afectar la primera i la tercera, perquè són connexions que fa el vostre dispositiu. No pot afectar la segona, perquè aquell camí va entre dos servidors de correu que no controleu. Una resposta no és un paquet que torna a l'adreça des de la qual vau enviar. És un missatge nou que el servei de correu de l'altra banda lliura al vostre servei de bústia.

Quan manteniu aquests tres separats, la pregunta de si la resposta us trobarà deixa de ser misteriosa.

Un camp Reply-To és una adreça, no una ruta

El RFC 5322 defineix Reply-To com la bústia o bústies a les quals s'han d'enviar les respostes. Sense aquest camp, el valor predeterminat habitual és la bústia From, tret que la persona que respon escrigui una altra cosa. Totes dues són adreces de correu dins d'una capçalera. Cap de les dues no és una instrucció de reobrir la connexió de xarxa que va enviar el missatge original.

Per això una adreça de sortida de la VPN no apareix mai en el camí de la resposta. Fins i tot quan el servidor d'enviament va registrar aquella adreça de sortida en algun lloc, la resposta s'adreça a una bústia, i el servidor emissor busca el servidor d'intercanvi de correu del domini en lloc del vostre antic sòcol.

Si una resposta va a un lloc inesperat, llegiu Reply-To i la configuració del client del remitent abans de sospitar del túnel.

Què registren realment les capçaleres de traça

Cada salt SMTP afegeix una capçalera Received que descriu la connexió que ha gestionat, i la més alta és l'últim salt abans del lliurament. Per tant, un missatge enviat pot portar detalls de xarxa que val la pena revisar, i aquests detalls els escriuen servidors, no els trieu vosaltres. El que contenen depèn de l'arquitectura d'enviament del proveïdor i de com tracta les capçaleres.

Llegiu-les en lloc d'endevinar, des d'un missatge desat:

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

La disciplina útil és identificar quin servei de confiança va afegir cada camp. El text arbitrari anterior al bloc de capçaleres no és una prova fiable, i el nom d'un producte no és una promesa permanent que la vostra adreça de casa hi sigui sempre o que sempre hi falti.

Llegir el correu més tard és una connexió nova

Quan obriu la resposta, el vostre client es connecta al vostre servei de bústia per la xarxa on sou ara. És una connexió nova amb la seva pròpia adreça d'origen, no una continuació del sòcol d'enviament d'ahir. Segueix la política actual de la xarxa que feu servir en aquell moment.

El contingut remot és encara una tercera cosa. Un client de correu que carrega una imatge remota o segueix un enllaç fa una petició separada segons la seva configuració actual, i aquesta petició pot portar qualsevol identificador que el missatge hagi incrustat. No és la resposta SMTP que arriba a una adreça antiga, i tractar-la com a tal amaga l'exposició real.

Desactiveu el contingut remot si voleu llegir un missatge sense anunciar que l'heu obert.

Què cal comprovar abans de dir-ne una fuita

Comenceu per la vista del missatge original i el camp Reply-To. Després identifiqueu quin servei va afegir les entrades Received que us preocupen, i compareu-ho amb la documentació actual del proveïdor en lloc d'una resposta antiga d'un fòrum.

Finalment, separeu les preguntes: què va observar el servidor d'enviament, què va afegir la cadena de lliurament i què va demanar el vostre client quan vau obrir el missatge?

Respondre aquestes tres per separat és més feina que mirar una pàgina d'IP, i és l'única versió que produeix una conclusió que podeu defensar. Respondre a una adreça de correu no revela la vostra adreça de casa i no requereix que el túnel antic segueixi aixecat.