E-mail envoyé via un VPN : où va réellement la réponse

Vous envoyez un message par le tunnel, vous vous déconnectez, et la réponse arrive le lendemain matin. Rien de tout cela n'a besoin de l'ancienne adresse VPN, et rien de tout cela ne casse. Le courrier électronique n'achemine pas les réponses vers l'adresse depuis laquelle un message a été envoyé ; il les achemine vers une boîte aux lettres. Trois chemins se confondent ici en une seule question, et les séparer répond à l'essentiel de l'inquiétude.

Trois chemins que les gens confondent en un

La soumission, la livraison et la lecture sont trois connexions distinctes, et seules deux d'entre elles concernent votre appareil.

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

Le VPN peut affecter la première et la troisième, car ce sont des connexions que votre appareil établit. Il ne peut pas affecter la seconde, car ce chemin passe entre deux serveurs de messagerie que vous ne contrôlez pas. Une réponse n'est pas un paquet qui revient vers l'adresse depuis laquelle vous avez envoyé. C'est un nouveau message que le service de messagerie de l'autre côté dépose dans votre service de boîte aux lettres.

Dès que vous gardez ces trois séparés, la question de savoir si la réponse vous trouvera cesse d'être mystérieuse.

Un champ Reply-To est une adresse, pas une route

La RFC 5322 définit Reply-To comme la boîte aux lettres ou les boîtes aux lettres auxquelles les réponses doivent être envoyées. Sans ce champ, la valeur par défaut habituelle est la boîte From, sauf si la personne qui répond tape autre chose. Les deux sont des adresses de courrier dans un en-tête. Aucune des deux n'est une instruction de rouvrir la connexion réseau qui a soumis le message d'origine.

C'est pourquoi une adresse de sortie VPN n'apparaît jamais dans le chemin de la réponse. Même lorsque le serveur de soumission a enregistré quelque part cette adresse de sortie, la réponse est adressée à une boîte aux lettres, et le serveur d'envoi recherche le serveur de messagerie du domaine plutôt que votre ancien socket.

Si une réponse part quelque part d'inattendu, lisez Reply-To et les propres réglages du client de l'expéditeur avant de soupçonner le tunnel.

Ce que les en-têtes de trace enregistrent réellement

Chaque saut SMTP ajoute en tête un en-tête Received décrivant la connexion qu'il a traitée, et le plus haut est le dernier saut avant la livraison. Un message soumis peut donc porter des détails réseau qui méritent d'être examinés, et ces détails sont écrits par des serveurs, pas choisis par vous. Leur contenu dépend de l'architecture de soumission du fournisseur et de sa gestion des en-têtes.

Lisez-les au lieu de deviner, à partir d'un message enregistré :

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

La discipline utile consiste à identifier quel service de confiance a ajouté chaque champ. Un texte arbitraire plus haut dans le bloc d'en-têtes n'est pas une preuve fiable, et un nom de produit n'est pas une promesse permanente que votre adresse personnelle soit toujours présente ou toujours absente.

Lire le courrier plus tard est une nouvelle connexion

Lorsque vous ouvrez la réponse, votre client se connecte à votre service de boîte aux lettres par le réseau sur lequel vous êtes maintenant. C'est une connexion neuve avec sa propre adresse source, pas la continuation du socket de soumission d'hier. Elle suit la politique actuelle du réseau que vous utilisez à ce moment-là.

Le contenu distant est encore une troisième chose. Un client de messagerie qui charge une image distante ou suit un lien fait une requête séparée selon ses réglages actuels, et cette requête peut porter tous les identifiants que le message a intégrés. Ce n'est pas la réponse SMTP qui arrive à une ancienne adresse, et la traiter comme telle masque l'exposition réelle.

Désactivez le contenu distant si vous voulez lire un message sans annoncer que vous l'avez ouvert.

Ce qu'il faut vérifier avant de parler de fuite

Commencez par la vue du message d'origine et le champ Reply-To. Identifiez ensuite quel service a ajouté les entrées Received qui vous inquiètent, et comparez-le à la documentation actuelle du fournisseur plutôt qu'à une vieille réponse de forum.

Enfin, séparez les questions : qu'est-ce que le serveur de soumission a observé, qu'est-ce que la chaîne de livraison a ajouté, et qu'est-ce que votre client a demandé lorsque vous avez ouvert le message ?

Répondre à ces trois séparément demande plus de travail que consulter une page d'IP, et c'est la seule version qui produit une conclusion défendable. Répondre à une adresse électronique ne révèle pas votre adresse personnelle et n'exige pas que l'ancien tunnel reste actif.