Een cid-suffix dat op een VPN-ID lijkt is gewoon een MIME Content-ID

U ziet openvpn in een identificatie tussen punthaken in een mailheader en de voor de hand liggende conclusie is dat het bericht iets met een VPN-sessie te maken heeft. Lees de hele regel voordat u zich daaraan vastlegt: de tekenreeks staat in een Content-ID, en een Content-ID is een naam voor één lichaamsdeel binnen één bericht. Een cid: verwijzing in de HTML wijst naar die naam, en het paar bestaat zodat de mail een afbeelding kan dragen zonder die twee keer te versturen. Niets in die opzet bereikt een VPN-server, en niets in het suffix zegt wie de identificatie heeft gebouwd.

Waar de identificatie werkelijk naar wijst

HTML-mail komt zelden als één blok binnen. De tekst en elke ingebedde afbeelding reizen meestal als afzonderlijke MIME-onderdelen, en de client zet ze voor weergave weer in elkaar. Daarvoor heeft hij een naam voor het afbeeldingsonderdeel nodig en een verwijzing die naar die naam verwijst.

Het paar hieronder is verzonnen als illustratie.

Content-ID: <[email protected]>

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

De headerregel staat op het afbeeldingsonderdeel; het img-element staat in het HTML-onderdeel. Punthaken horen bij de syntax van de header, dus een cid: verwijzing schrijft de identificatie meestal zonder. Waarden met tekens die moeten worden geëscaleerd, moeten worden gecodeerd, en daarom is dit paar een illustratie en geen conversieregel. Wat de betekenis draagt, is de overeenkomst tussen de twee tekenreeksen, niet een van beide op zichzelf.

Het @openvpn-suffix is een constructiedetail

Een Content-ID wordt gebouwd om uniek te zijn binnen één bericht, en mailsoftware laat hem vaak op een adres lijken door een @ en een domein toe te voegen. Die vorm is een conventie van de generator, geen route: niets in de header vraagt de client om mailer.example te benaderen, en er gebeurt geen opzoeking wanneer het bericht wordt weergegeven. Het veld is ook geen accountnaam, VPN-gebruiker of een spoor dat een VPN-client heeft achtergelaten. Wie het bericht samenstelde, koos de tekenreeks bij het benoemen van een onderdeel.

RFC 2392 definieert het cid schema en beperkt het tot verwijzen naar berichten en hun onderdelen. Lees dat bereik letterlijk en het suffix houdt op bewijs te zijn voor iets buiten het benoemen. Het betekent ook dat de producent niet uit het suffix te herkennen is, en dat is precies de sprong die mensen maken wanneer een bekend woord in een header opduikt.

Onderzoek de onbewerkte bron en beoordeel dan de privacyvraag

Open de onbewerkte bron en lees de hele Content-ID-waarde, want RFC 2392 staat toe dat een waarde de hostnaam van de afzender of een accountachtige tekenreeks draagt. Zoek daarna elke plaats waar dezelfde naam voorkomt: een cid: verwijzing in de HTML, een andere header, een geciteerd blok uit een eerder antwoord. De overeenkomst tussen die voorkomens is wat u het doel van het onderdeel vertelt.

Juist die eigenschap maakt een identificatie van belang voor privacy. Een waarde die van een hostnaam of accountnaam is afgeleid, reist met het bericht mee en kan iets onthullen over de machine of de persoon die het heeft verzonden. Het is nog steeds geen VPN-sessie, en het als zodanig behandelen verspilt de vondst.

Externe afbeelding of ingebed onderdeel: ander verkeer

Een img-element met een https bron en een img-element met een cid bron zien er in de HTML hetzelfde uit en gedragen zich op het net anders. Het eerste noemt een bron die de client kan ophalen zodra het bericht is geopend, en dat ophalen vertelt de afzender dat het bericht is gelezen en vanaf welk adres. Het tweede lost op tegen een onderdeel dat al in het bericht zit, dus het weergeven ervan neemt met niemand contact op.

Eén bericht kan beide mengen, en het controleren van het ene zuivert het andere niet. Tel de externe verwijzingen apart van de ingebedde, en noteer wat de instellingen van de client toestaan. Dat onderscheid is de beslissing die voor privacy telt, niet het woord in de identificatie.

Deel het bewijs zonder het bericht te versturen

Wanneer iemand anders dit moet bekijken, redigeer dan eerst en redigeer consistent. Vervang adressen en niet-gerelateerde headers, en houd daarna de Content-ID en zijn cid: verwijzing in de kopie identiek gespeld, want een afwijking vernietigt het enige bewijs dat telt. Zeg bij welk onderdeel de header hoorde en welke regel ernaar verwees. De beoordelaar heeft de relatie nodig, niet het bericht.

Scheid daarna de twee conclusies schriftelijk: wat het bericht bevat, en wat het niet bewijst. Een bewering die zo is geformuleerd, is te controleren en te betwisten, en dat is wat een bruikbaar rapport mogelijk maakt.