Correo enviado por unha VPN: a onde vai realmente a resposta

Envías unha mensaxe polo túnel, desconéctaste e a resposta chega á mañá seguinte. Nada diso necesita a antiga dirección VPN e nada diso rompe. O correo non encamiña as respostas á dirección desde a que se enviou unha mensaxe; encamínaas a unha caixa de correo. Aquí tres camiños xúntanse nunha soa pregunta, e separalos responde á maior parte da preocupación.

Tres camiños que a xente xunta nun

Envío, entrega e lectura son tres conexións separadas, e só dúas delas implican o teu dispositivo.

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

A VPN pode afectar a primeira e a terceira, porque son conexións que fai o teu dispositivo. Non pode afectar a segunda, porque ese camiño discorre entre dous servidores de correo que non controlas. Unha resposta non é un paquete que volve á dirección desde a que enviaches. É unha mensaxe nova que o servizo de correo da outra parte entrega ao teu servizo de caixa de correo.

Cando mantés eses tres separados, a pregunta de se a resposta te atopará deixa de ser misteriosa.

Un campo Reply-To é unha dirección, non unha ruta

O RFC 5322 define Reply-To como a caixa de correo ou as caixas de correo ás que se deben enviar as respostas. Sen el, o valor predeterminado habitual é a caixa From, salvo que a persoa que responde escriba outra cousa. Ambas son direccións de correo dentro dunha cabeceira. Ningunha é unha instrución de reabrir a conexión de rede que enviou a mensaxe orixinal.

Por iso unha dirección de saída da VPN nunca aparece no camiño da resposta. Mesmo cando o servidor de envío rexistrou esa dirección de saída nalgún lugar, a resposta diríxese a unha caixa de correo, e o servidor emisor busca o intercambiador de correo do dominio en lugar do teu antigo socket.

Se unha resposta vai a un lugar inesperado, le Reply-To e a configuración do cliente do remitente antes de sospeitar do túnel.

Que rexistran realmente as cabeceiras de traza

Cada salto SMTP antepón unha cabeceira Received que describe a conexión que xestionou, e a máis alta é o último salto antes da entrega. Unha mensaxe enviada pode, por tanto, levar detalles de rede que paga a pena revisar, e eses detalles escríbenos servidores, non os elixes ti. O que conteñen depende da arquitectura de envío do provedor e do seu tratamento das cabeceiras.

Léas en lugar de adiviñar, desde unha mensaxe gardada:

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

A disciplina útil é identificar que servizo de confianza engadiu cada campo. O texto arbitrario anterior no bloque de cabeceiras non é unha proba fiable, e o nome dun produto non é unha promesa permanente de que a túa dirección da casa estea sempre presente ou sempre ausente.

Ler o correo máis tarde é unha conexión nova

Cando abres a resposta, o teu cliente conéctase ao teu servizo de caixa de correo pola rede na que esteas agora. É unha conexión nova coa súa propia dirección de orixe, non unha continuación do socket de envío de onte. Segue a política actual da rede que uses nese momento.

O contido remoto é aínda unha terceira cousa. Un cliente de correo que carga unha imaxe remota ou segue unha ligazón fai unha petición separada segundo a súa configuración actual, e esa petición pode levar calquera identificador que a mensaxe incrustase. Non é a resposta SMTP que chega a unha dirección antiga, e tratala como tal agocha a exposición real.

Desactiva o contido remoto se queres ler unha mensaxe sen anunciar que a abriches.

Que comprobar antes de chamalo fuga

Comeza pola vista da mensaxe orixinal e o campo Reply-To. Despois identifica que servizo engadiu as entradas Received que te preocupan, e compárao coa documentación actual do provedor en lugar dunha resposta antiga dun foro.

Por último, separa as preguntas: que observou o servidor de envío, que engadiu a cadea de entrega e que pediu o teu cliente cando abriches a mensaxe?

Responder esas tres por separado é máis traballo que mirar unha páxina de IP, e é a única versión que produce unha conclusión que podes defender. Responder a unha dirección de correo non revela a túa dirección da casa e non esixe que o túnel antigo siga activo.