E-mail enviado por uma VPN: para onde a resposta realmente vai

Envia uma mensagem pelo túnel, desliga-se e a resposta chega na manhã seguinte. Nada disso precisa do antigo endereço VPN e nada disso se estraga. O e-mail não encaminha as respostas para o endereço de onde a mensagem foi enviada; encaminha-as para uma caixa de correio. Aqui três caminhos fundem-se numa só pergunta, e separá-los responde à maior parte da preocupação.

Três caminhos que as pessoas fundem num só

Submissão, entrega e leitura são três ligações separadas, e apenas duas delas envolvem o seu 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 afetar a primeira e a terceira, porque são ligações que o seu dispositivo estabelece. Não pode afetar a segunda, porque esse caminho corre entre dois servidores de correio que não controla. Uma resposta não é um pacote que regressa ao endereço de onde enviou. É uma mensagem nova que o serviço de correio do outro lado entrega ao seu serviço de caixa de correio.

Quando mantém estes três separados, a pergunta sobre se a resposta o encontrará deixa de ser misteriosa.

Um campo Reply-To é um endereço, não uma rota

O RFC 5322 define Reply-To como a caixa ou as caixas de correio para as quais as respostas devem ser enviadas. Sem ele, o valor predefinido habitual é a caixa From, a menos que quem responde escreva outra coisa. Ambos são endereços de correio dentro de um cabeçalho. Nenhum deles é uma instrução para reabrir a ligação de rede que submeteu a mensagem original.

É por isso que um endereço de saída da VPN nunca aparece no caminho da resposta. Mesmo quando o servidor de submissão registou esse endereço de saída nalgum lugar, a resposta é endereçada a uma caixa de correio, e o servidor emissor procura o servidor de troca de correio do domínio em vez do seu antigo socket.

Se uma resposta for parar a um sítio inesperado, leia Reply-To e as próprias definições do cliente do remetente antes de suspeitar do túnel.

O que os cabeçalhos de rastreio realmente registam

Cada salto SMTP acrescenta à frente um cabeçalho Received que descreve a ligação tratada, e o mais alto é o último salto antes da entrega. Uma mensagem submetida pode, por isso, transportar detalhes de rede que vale a pena rever, e esses detalhes são escritos por servidores, não escolhidos por si. O que contêm depende da arquitetura de submissão do fornecedor e do modo como trata os cabeçalhos.

Leia-os em vez de adivinhar, a partir de uma mensagem guardada:

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

A disciplina útil é identificar que serviço de confiança acrescentou cada campo. Texto arbitrário mais acima no bloco de cabeçalhos não é prova fiável, e o nome de um produto não é uma promessa permanente de que o seu endereço de casa esteja sempre presente ou sempre ausente.

Ler o correio mais tarde é uma ligação nova

Quando abre a resposta, o seu cliente liga-se ao seu serviço de caixa de correio através da rede em que está agora. É uma ligação nova com o seu próprio endereço de origem, não uma continuação do socket de submissão de ontem. Segue a política atual da rede que estiver a usar naquele momento.

O conteúdo remoto é ainda uma terceira coisa. Um cliente de correio que carrega uma imagem remota ou segue uma ligação faz um pedido separado segundo as suas definições atuais, e esse pedido pode transportar quaisquer identificadores que a mensagem tenha incorporado. Não é a resposta SMTP que chega a um endereço antigo, e tratá-la como tal esconde a exposição real.

Desative o conteúdo remoto se quiser ler uma mensagem sem anunciar que a abriu.

O que verificar antes de lhe chamar fuga

Comece pela vista da mensagem original e pelo campo Reply-To. Depois identifique que serviço acrescentou as entradas Received que o preocupam, e compare isso com a documentação atual do fornecedor em vez de uma resposta antiga de um fórum.

Por fim, separe as perguntas: o que observou o servidor de submissão, o que acrescentou a cadeia de entrega, e o que pediu o seu cliente quando abriu a mensagem?

Responder a estas três em separado dá mais trabalho do que verificar uma página de IP, e é a única versão que produz uma conclusão que pode defender. Responder a um endereço de e-mail não revela o seu endereço de casa e não exige que o antigo túnel continue ativo.