Et cid-suffiks, der ligner et VPN-ID, er bare et MIME Content-ID

Du ser openvpn inde i en identifikator i vinkelparenteser i en mailheader, og den oplagte konklusion er, at meddelelsen har noget med en VPN-session at gøre. Læs hele linjen, før du binder dig til det: strengen står i et Content-ID, og et Content-ID er et navn på én del af kroppen i én meddelelse. En cid: reference i HTML'en peger på det navn, og parret findes, for at mailen kan bære et billede uden at sende det to gange. Intet i det arrangement når en VPN-server, og intet i suffikset siger, hvem der har bygget identifikatoren.

Hvad identifikatoren egentlig peger på

HTML-mail ankommer sjældent som én blok. Teksten og hvert indlejret billede rejser normalt som separate MIME-dele, og klienten samler dem igen for at vise dem. For at gøre det skal den have et navn til billeddelen og en reference, der opløses til det navn.

Parret nedenfor er opdigtet som illustration.

Content-ID: <[email protected]>

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

Headerlinjen står på billeddelen; img-elementet står i HTML-delen. Vinkelparenteser hører til header-syntaksen, så en cid: reference skriver normalt identifikatoren uden dem. Værdier med tegn, der skal escapes, skal kodes, og derfor er dette par en illustration og ikke en konverteringsregel. Det, der bærer betydningen, er match mellem de to strenge, ikke nogen af strengene alene.

@openvpn-suffikset er en konstruktionsdetalje

Et Content-ID bygges til at være unikt i én meddelelse, og mailsoftware får det ofte til at ligne en adresse ved at tilføje et @ og et domæne. Den form er generatorens konvention, ikke en rute: intet i headeren beder klienten om at kontakte mailer.example, og ingen opslag sker, når meddelelsen vises. Feltet er heller ikke et kontonavn, en VPN-bruger eller et mærke efterladt af en VPN-klient. Den, der samlede meddelelsen, valgte strengen, da en del blev navngivet.

RFC 2392 definerer cid-skemaet og begrænser det til at referere til meddelelser og deres dele. Læs det omfang bogstaveligt, og suffikset holder op med at være bevis for noget ud over navngivning. Det betyder også, at afsenderen ikke kan identificeres ud fra suffikset, og det er netop det spring, folk tager, når et velkendt ord dukker op i en header.

Undersøg den rå kilde, og vurder så privatlivsspørgsmålet

Åbn den rå kilde og læs hele Content-ID-værdien, fordi RFC 2392 tillader, at en værdi bærer afsenderens værtsnavn eller en kontoagtig streng. Find derefter hvert sted, hvor det samme navn optræder: en cid: reference i HTML'en, en anden header, en citeret blok fra et tidligere svar. Match mellem de forekomster er det, der fortæller dig delens formål.

Netop den egenskab er grunden til, at en identifikator kan betyde noget for privatlivet. En værdi, der er afledt af et værtsnavn eller et kontonavn, rejser med meddelelsen og kan afsløre noget om maskinen eller personen, der sendte den. Det er stadig ikke en VPN-session, og at behandle den som en ødsler fundet.

Fjernt billede eller indlejret del: forskellig trafik

Et img-element med en https kilde og et img-element med en cid kilde ser ens ud i HTML'en og opfører sig forskelligt på nettet. Det første navngiver en ressource, som klienten kan hente, når meddelelsen åbnes, og den hentning fortæller afsenderen, at meddelelsen er læst, og fra hvilken adresse. Det andet opløses mod en del, der allerede findes i meddelelsen, så visning af det kontakter ingen.

En enkelt meddelelse kan blande begge, og kontrol af det ene renser ikke det andet. Tæl fjernreferencerne adskilt fra de indlejrede, og noter, hvad klientens indstillinger tillader. Den forskel er den beslutning, der betyder noget for privatlivet, ikke ordet inde i identifikatoren.

Del beviset uden at sende meddelelsen

Når en anden skal se på dette, rediger først og rediger konsekvent. Erstat adresser og uvedkommende headere, og hold derefter Content-ID'et og dets cid: reference stavet ens i kopien, fordi en uoverensstemmelse ødelægger det eneste bevis, der betyder noget. Sig, hvilken del headeren hørte til, og hvilken linje der refererede til den. Revieweren har brug for relationen, ikke meddelelsen.

Adskil derefter de to konklusioner på skrift: hvad meddelelsen indeholder, og hvad den ikke beviser. En påstand formuleret sådan kan kontrolleres og diskuteres, og det er netop, hvad en brugbar rapport tillader.