Correo enviado por una VPN: adónde va realmente la respuesta

Envías un mensaje por el túnel, te desconectas y la respuesta llega a la mañana siguiente. Nada de eso necesita la antigua dirección VPN y nada de eso se rompe. El correo no encamina las respuestas a la dirección desde la que se envió un mensaje; las encamina a un buzón. Aquí tres caminos se funden en una sola pregunta, y separarlos responde a la mayor parte de la preocupación.

Tres caminos que la gente funde en uno

Envío, entrega y lectura son tres conexiones separadas, y solo dos de ellas implican tu dispositivo.

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

La VPN puede afectar la primera y la tercera, porque son conexiones que hace tu dispositivo. No puede afectar la segunda, porque ese camino discurre entre dos servidores de correo que no controlas. Una respuesta no es un paquete que vuelve a la dirección desde la que enviaste. Es un mensaje nuevo que el servicio de correo de la otra parte entrega a tu servicio de buzón.

Cuando mantienes esos tres separados, la pregunta de si la respuesta te encontrará deja de ser misteriosa.

Un campo Reply-To es una dirección, no una ruta

El RFC 5322 define Reply-To como el buzón o los buzones a los que deben enviarse las respuestas. Sin él, el valor predeterminado habitual es el buzón From, salvo que la persona que responde escriba otra cosa. Ambos son direcciones de correo dentro de una cabecera. Ninguno es una instrucción de reabrir la conexión de red que envió el mensaje original.

Por eso una dirección de salida de la VPN nunca aparece en el camino de la respuesta. Incluso cuando el servidor de envío registró esa dirección de salida en algún sitio, la respuesta se dirige a un buzón, y el servidor emisor busca el intercambiador de correo del dominio en lugar de tu antiguo socket.

Si una respuesta va a un lugar inesperado, lee Reply-To y la configuración del cliente del remitente antes de sospechar del túnel.

Qué registran realmente las cabeceras de traza

Cada salto SMTP antepone una cabecera Received que describe la conexión que ha gestionado, y la más alta es el último salto antes de la entrega. Un mensaje enviado puede por tanto llevar detalles de red que merece la pena revisar, y esos detalles los escriben servidores, no los eliges tú. Lo que contienen depende de la arquitectura de envío del proveedor y de su tratamiento de las cabeceras.

Léelas en lugar de adivinar, desde un mensaje guardado:

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

La disciplina útil es identificar qué servicio de confianza añadió cada campo. El texto arbitrario anterior en el bloque de cabeceras no es una prueba fiable, y el nombre de un producto no es una promesa permanente de que tu dirección de casa esté siempre presente o siempre ausente.

Leer el correo más tarde es una conexión nueva

Cuando abres la respuesta, tu cliente se conecta a tu servicio de buzón por la red en la que estés ahora. Es una conexión nueva con su propia dirección de origen, no una continuación del socket de envío de ayer. Sigue la política actual de la red que uses en ese momento.

El contenido remoto es todavía una tercera cosa. Un cliente de correo que carga una imagen remota o sigue un enlace hace una petición separada según su configuración actual, y esa petición puede llevar cualquier identificador que el mensaje haya incrustado. No es la respuesta SMTP que llega a una dirección antigua, y tratarla como tal oculta la exposición real.

Desactiva el contenido remoto si quieres leer un mensaje sin anunciar que lo has abierto.

Qué comprobar antes de llamarlo filtración

Empieza por la vista del mensaje original y el campo Reply-To. Luego identifica qué servicio añadió las entradas Received que te preocupan, y compáralo con la documentación actual del proveedor en lugar de con una respuesta antigua de un foro.

Por último, separa las preguntas: qué observó el servidor de envío, qué añadió la cadena de entrega y qué pidió tu cliente cuando abriste el mensaje?

Responder esas tres por separado es más trabajo que mirar una página de IP, y es la única versión que produce una conclusión que puedes defender. Responder a una dirección de correo no revela tu dirección de casa y no exige que el túnel antiguo siga activo.