Ein cid-Suffix, das wie eine VPN-ID aussieht, ist nur eine MIME Content-ID

Sie sehen openvpn in einem Identifikator in spitzen Klammern in einem Mail-Header und der naheliegende Schluss ist, dass die Nachricht mit einer VPN-Sitzung zu tun hat. Lesen Sie die ganze Zeile, bevor Sie sich darauf festlegen: Die Zeichenkette steht in einer Content-ID, und eine Content-ID ist ein Name für einen Body-Teil innerhalb einer einzigen Nachricht. Eine cid: Referenz im HTML zeigt auf diesen Namen, und das Paar existiert, damit die Mail ein Bild tragen kann, ohne es zweimal zu senden. Nichts an dieser Anordnung erreicht einen VPN-Server, und nichts im Suffix sagt, wer den Identifikator gebaut hat.

Worauf der Identifikator tatsächlich zeigt

HTML-Mail kommt selten als ein einziger Block an. Der Text und jedes eingebettete Bild reisen meist als getrennte MIME-Teile, und der Client setzt sie zur Anzeige wieder zusammen. Dafür braucht er einen Namen für den Bildteil und eine Referenz, die zu diesem Namen auflöst.

Das folgende Paar ist zur Veranschaulichung erfunden.

Content-ID: <[email protected]>

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

Die Header-Zeile steht am Bildteil; das img-Element steht im HTML-Teil. Spitze Klammern gehören zur Syntax des Headers, deshalb schreibt eine cid: Referenz den Identifikator normalerweise ohne sie. Werte mit Zeichen, die maskiert werden müssen, müssen kodiert werden, und darum ist dieses Paar eine Veranschaulichung und keine Umwandlungsregel. Was die Bedeutung trägt, ist die Übereinstimmung der beiden Zeichenketten, nicht eine von ihnen allein.

Das @openvpn-Suffix ist ein Konstruktionsdetail

Eine Content-ID wird so gebaut, dass sie innerhalb einer Nachricht eindeutig ist, und Mail-Software lässt sie oft wie eine Adresse aussehen, indem sie ein @ und eine Domain anhängt. Diese Form ist eine Konvention des Generators, keine Route: Nichts im Header verlangt vom Client, mailer.example zu kontaktieren, und beim Anzeigen der Nachricht findet keine Abfrage statt. Das Feld ist auch kein Kontoname, kein VPN-Benutzer und keine Spur eines VPN-Clients. Wer die Nachricht zusammensetzte, wählte die Zeichenkette beim Benennen eines Teils.

RFC 2392 definiert das cid Schema und beschränkt es darauf, auf Nachrichten und ihre Teile zu verweisen. Liest man diesen Geltungsbereich wörtlich, ist das Suffix kein Beleg für irgendetwas jenseits der Benennung. Es heißt auch, dass der Ersteller aus dem Suffix nicht zu erkennen ist, und genau diesen Sprung machen Leute, wenn ein vertrautes Wort in einem Header auftaucht.

Prüfen Sie die Rohquelle und beurteilen Sie dann die Datenschutzfrage

Öffnen Sie die Rohquelle und lesen Sie den ganzen Content-ID-Wert, denn RFC 2392 erlaubt, dass ein Wert den Hostnamen des Urhebers oder eine kontonameähnliche Zeichenkette trägt. Suchen Sie dann jede Stelle, an der derselbe Name erscheint: eine cid: Referenz im HTML, ein anderer Header, ein zitierter Block aus einer früheren Antwort. Die Übereinstimmung dieser Vorkommen sagt Ihnen den Zweck des Teils.

Genau diese Eigenschaft macht einen Identifikator für den Datenschutz relevant. Ein Wert, der aus einem Hostnamen oder einem Kontonamen abgeleitet ist, reist mit der Nachricht und kann etwas über die Maschine oder die Person verraten, die sie gesendet hat. Es ist weiterhin keine VPN-Sitzung, und sie als eine zu behandeln verschwendet den Fund.

Entferntes Bild oder eingebetteter Teil: unterschiedlicher Verkehr

Ein img-Element mit einer https Quelle und ein img-Element mit einer cid Quelle sehen im HTML gleich aus und verhalten sich im Netz unterschiedlich. Das erste benennt eine Ressource, die der Client abrufen kann, sobald die Nachricht geöffnet wird, und dieser Abruf sagt dem Absender, dass die Nachricht gelesen wurde und von welcher Adresse. Das zweite löst gegen einen Teil auf, der schon in der Nachricht steckt, seine Anzeige kontaktiert also niemanden.

Eine einzelne Nachricht kann beides mischen, und die Prüfung des einen entlastet das andere nicht. Zählen Sie entfernte Referenzen getrennt von eingebetteten und notieren Sie, was die Einstellungen des Clients zulassen. Diese Unterscheidung ist die Entscheidung, die für den Datenschutz zählt, nicht das Wort im Identifikator.

Teilen Sie den Beleg, ohne die Nachricht zu versenden

Wenn jemand anderes das ansehen muss, redigieren Sie zuerst und redigieren Sie konsequent. Ersetzen Sie Adressen und unbeteiligte Header, und halten Sie dann die Content-ID und ihre cid: Referenz in der Kopie identisch geschrieben, denn eine Abweichung zerstört den einzigen Beleg, der zählt. Sagen Sie, zu welchem Teil der Header gehörte und welche Zeile darauf verwies. Die prüfende Person braucht die Beziehung, nicht die Nachricht.

Trennen Sie dann die beiden Schlüsse schriftlich: was die Nachricht enthält und was sie nicht beweist. Eine so gerahmte Behauptung lässt sich prüfen und diskutieren, und genau das ermöglicht ein nützlicher Bericht.