O envio de e-mail falha quando a VPN se conecta: encontre a etapa

O e-mail que funcionava a manhã inteira para no momento em que o túnel sobe, e o primeiro instinto é digitar a senha de novo. Esse instinto pula a pergunta mais útil: o cliente chegou ao servidor e foi longe o bastante para oferecer credenciais? Um tempo limite, um erro de certificado e uma resposta de rejeição são três falhas diferentes, e só a terceira envolve a conta. Percorra as etapas em ordem e a VPN se torna uma variável que você pode testar, não um suspeito a quem culpar.

Etapa 1: classifique a falha antes de tocar nas credenciais

Leia o erro que a aplicação realmente produziu e coloque-o em um de três baldes. Um tempo limite ou um reset da conexão significa que o caminho TCP falhou; um erro TLS ou de certificado significa que o caminho funcionou e o aperto de mão não; uma resposta SMTP com código significa que um servidor de e-mail respondeu e tomou uma decisão. Cada balde aponta para um responsável diferente.

Vale a pena separar os baldes porque as correções se contradizem. Aumentar um tempo limite não ajuda quando o servidor rejeita o remetente, e trocar a senha não faz nada quando a rota está bloqueada. Um código de resposta é a evidência mais valiosa da lista, porque prova que toda a cadeia de transporte funcionou e que o problema é de política ou de identidade. Guarde o texto exato, incluindo qualquer código de status estendido, antes de tentar de novo.

Pare aqui se não conseguir reproduzir a falha fora da VPN. Um problema que aparece em uma aplicação em uma máquina ainda não é um problema de rede.

Etapa 2: confirme o endpoint e o modo TLS

O envio de mensagens é um serviço próprio, não a mesma coisa que retransmissão de servidor para servidor. Confirme o nome do host, a porta e o modo TLS na documentação do provedor para envio, porque uma porta conhecida emprestada de outra configuração de e-mail não é prova. A porta 587 espera uma saudação em texto simples seguida de STARTTLS, enquanto a porta 465 espera TLS desde o primeiro byte.

openssl s_client -connect smtp.example.com:465 -servername smtp.example.com -quiet
openssl s_client -starttls smtp -connect smtp.example.com:587 -servername smtp.example.com -quiet
nc -vz smtp.example.com 587

Executar a sonda errada das duas é exatamente o erro que o cliente comete quando está configurado para o outro modo. Se a sonda de TLS implícito travar na 587, ou a sonda STARTTLS falhar na 465, a porta e o modo não coincidem. Corrija o modo no cliente em vez de desativar a verificação do certificado, o que transforma um erro de configuração em uma conexão não verificada. A separação é antiga o bastante para ser padronizada: o TLS implícito na porta 465 é o arranjo descrito na RFC 8314.

Um erro de certificado aqui é informação e não obstáculo. Ele nomeia a identidade que o servidor apresentou e a identidade que o cliente esperava, e ambas podem ser corrigidas sem enfraquecer a conexão.

Etapa 3: compare caminhos sem mudar a conta

Mantenha o endpoint, a conta e as configurações do cliente constantes e mude apenas o caminho. Envie uma vez com o túnel abaixado e outra com ele levantado, e anote a rota e o endereço de origem que o servidor veria. Se a falha segue o caminho, você a isolou; se segue a máquina, não.

ip route get smtp.example.com
curl -v --ssl-reqd --url smtp://smtp.example.com:587 --user "$SMTP_USER" \
  --mail-from [email protected] --mail-rcpt [email protected] --upload-file msg.txt

Um túnel completo muda o endereço de origem que o provedor vê, e alguns provedores tratam uma fonte desconhecida com mais rigor do que uma senha desconhecida. É uma decisão de política do lado deles, e pode ser uma lista cinza, um limite de taxa ou um bloqueio. Não generalize de um provedor para todos, e não presuma que uma regra NAT ausente explica cada falha. O transcript do curl mostra qual etapa falhou mesmo quando o log da própria aplicação não mostra.

Se o túnel deve carregar tráfego de internet, tanto o roteamento quanto a política de saída devem permitir este destino. Um túnel que carrega apenas rotas privadas deixa a conexão de e-mail no caminho local, que é uma comparação diferente.

Etapa 4: envie uma mensagem inofensiva e anote a resposta

Corrija a etapa que falhou e depois envie uma mensagem inofensiva pela mesma aplicação e não por uma página de webmail. O que você testa é o caminho de envio da própria aplicação, incluindo suas configurações salvas e seu modo TLS. Uma sessão de webmail não prova nada sobre isso.

Anote a resposta, a porta, o modo TLS e o caminho que você usou, para que a próxima pessoa possa reproduzir o resultado. Um navegador que funciona e um ícone verde de VPN são observações sobre outras coisas. Se a mensagem chegar, o trabalho restante é tornar essa configuração o padrão para cada máquina que envia por esta conta.

A lista de verificação está completa quando você consegue nomear a etapa que falhou, a porta e o modo TLS que o cliente usa, o caminho que a mensagem percorreu e a resposta que o servidor devolveu. Esses quatro fatos transformam um problema vago de caixa de saída em uma mudança que alguém pode revisar.