Vous voyez openvpn dans un identifiant entre chevrons d’un en-tête de courriel et la conclusion évidente est que le message a un rapport avec une session VPN. Lisez la ligne entière avant de vous y engager : la chaîne se trouve dans un Content-ID, et un Content-ID est un nom pour une partie du corps à l’intérieur d’un seul message. Une cid: référence dans le HTML pointe vers ce nom, et la paire existe pour que le courriel puisse transporter une image sans l’envoyer deux fois. Rien dans cet agencement n’atteint un serveur VPN, et rien dans le suffixe ne dit qui a construit l’identifiant.

Ce que l’identifiant désigne réellement

Le courriel HTML arrive rarement en un seul bloc. Le texte et chaque image intégrée voyagent généralement en parties MIME distinctes, et le client les réassemble pour l’affichage. Pour cela, il lui faut un nom pour la partie image et une référence qui se résout vers ce nom.

La paire ci-dessous est inventée pour l’illustration.

Content-ID: <[email protected]>

<img src="cid:[email protected]" alt="Company mark">

La ligne d’en-tête se trouve sur la partie image ; l’élément img se trouve dans la partie HTML. Les chevrons appartiennent à la syntaxe de l’en-tête, donc une cid: référence écrit normalement l’identifiant sans eux. Les valeurs contenant des caractères à échapper doivent être encodées, et c’est pourquoi cette paire est une illustration et non une règle de conversion. Ce qui porte le sens, c’est la correspondance entre les deux chaînes, pas l’une d’elles isolément.

Le suffixe @openvpn est un détail de construction

Un Content-ID est construit pour être unique à l’intérieur d’un message, et les logiciels de messagerie le font souvent ressembler à une adresse en ajoutant un @ et un domaine. Cette forme est une convention du générateur, pas une route : rien dans l’en-tête ne demande au client de contacter mailer.example, et aucune résolution n’a lieu à l’affichage du message. Le champ n’est pas non plus un nom de compte, un utilisateur VPN ou une marque laissée par un client VPN. Celui qui a assemblé le message a choisi la chaîne en nommant une partie.

RFC 2392 définit le schéma cid et le limite à référencer des messages et leurs parties. Lisez cette portée au pied de la lettre et le suffixe cesse d’être la preuve d’autre chose que d’un nommage. Cela signifie aussi que le producteur ne peut pas être identifié à partir du suffixe, et c’est exactement le saut que font les gens quand un mot familier apparaît dans un en-tête.

Examinez la source brute, puis jugez la question de la vie privée

Ouvrez la source brute et lisez toute la valeur du Content-ID, car la RFC 2392 permet à une valeur de porter le nom d’hôte de l’émetteur ou une chaîne semblable à un compte. Cherchez ensuite chaque endroit où le même nom apparaît : une cid: référence dans le HTML, un autre en-tête, un bloc cité d’une réponse antérieure. La correspondance entre ces occurrences est ce qui vous dit la fonction de la partie.

C’est précisément cette propriété qui peut donner de l’importance à un identifiant pour la vie privée. Une valeur dérivée d’un nom d’hôte ou d’un nom de compte voyage avec le message et peut révéler quelque chose sur la machine ou la personne qui l’a envoyé. Ce n’est toujours pas une session VPN, et la traiter comme telle gaspille la trouvaille.

Image distante ou partie intégrée : un trafic différent

Un élément img dont la source est https et un élément img dont la source est cid se ressemblent dans le HTML et se comportent différemment sur le réseau. Le premier nomme une ressource que le client peut aller chercher une fois le message ouvert, et cette requête indique à l’expéditeur que le message a été lu et depuis quelle adresse. Le second se résout sur une partie déjà présente dans le message, donc l’afficher ne contacte personne.

Un seul message peut mêler les deux, et vérifier l’un ne blanchit pas l’autre. Comptez les références distantes séparément des intégrées et notez ce que les réglages du client autorisent. Cette distinction est la décision qui compte pour la vie privée, pas le mot à l’intérieur de l’identifiant.

Partagez la preuve sans expédier le message

Quand quelqu’un d’autre doit regarder cela, caviardez d’abord et caviardez de façon cohérente. Remplacez les adresses et les en-têtes sans rapport, puis gardez le Content-ID et sa cid: référence écrits à l’identique dans la copie, car une divergence détruit la seule preuve qui compte. Dites à quelle partie l’en-tête appartenait et quelle ligne y faisait référence. Le relecteur a besoin de la relation, pas du message.

Séparez ensuite les deux conclusions par écrit : ce que le message contient et ce qu’il ne prouve pas. Une affirmation formulée ainsi peut être vérifiée et discutée, et c’est ce qu’un rapport utile permet.

Articles similaires