Et cid-suffiks som ser ut som en VPN-ID er bare en MIME Content-ID

Du ser openvpn inne i en identifikator i vinkelparenteser i en e-postheader, og den åpenbare konklusjonen er at meldingen har noe med en VPN-økt å gjøre. Les hele linjen før du binder deg til det: strengen står i en Content-ID, og en Content-ID er et navn på én del av kroppen i én melding. En cid: referanse i HTML-en peker på det navnet, og paret finnes for at e-posten skal kunne bære et bilde uten å sende det to ganger. Ingenting i den ordningen når en VPN-server, og ingenting i suffikset sier hvem som bygde identifikatoren.

Hva identifikatoren egentlig peker på

HTML-e-post kommer sjelden som én blokk. Teksten og hvert innebygde bilde reiser vanligvis som separate MIME-deler, og klienten setter dem sammen igjen for visning. For det trenger den et navn for bildedelen og en referanse som løses opp til det navnet.

Paret nedenfor er oppdiktet som illustrasjon.

Content-ID: <[email protected]>

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

Headerlinjen står på bildedelen; img-elementet står i HTML-delen. Vinkelparenteser hører til header-syntaksen, så en cid: referanse skriver vanligvis identifikatoren uten dem. Verdier med tegn som må escapes, må kodes, og derfor er dette paret en illustrasjon og ikke en konverteringsregel. Det som bærer betydningen, er samsvaret mellom de to strengene, ikke noen av dem alene.

@openvpn-suffikset er en konstruksjonsdetalj

En Content-ID bygges for å være unik i én melding, og e-postprogramvare får den ofte til å se ut som en adresse ved å legge til en @ og et domene. Den formen er generatorens konvensjon, ikke en rute: ingenting i headeren ber klienten kontakte mailer.example, og ingen oppslag skjer når meldingen vises. Feltet er heller ikke et kontonavn, en VPN-bruker eller et merke en VPN-klient har lagt igjen. Den som satte sammen meldingen, valgte strengen da en del ble navngitt.

RFC 2392 definerer cid-skjemaet og begrenser det til å referere til meldinger og delene deres. Les dette omfanget bokstavelig, og suffikset slutter å være bevis for noe ut over navngiving. Det betyr også at produsenten ikke kan identifiseres fra suffikset, og det er nettopp det spranget folk tar når et kjent ord dukker opp i en header.

Undersøk rådataene, og vurder så personvernspørsmålet

Åpne rådataene og les hele Content-ID-verdien, fordi RFC 2392 tillater at en verdi bærer vertsnavnet til avsenderen eller en kontolignende streng. Finn så hvert sted hvor det samme navnet forekommer: en cid: referanse i HTML-en, en annen header, en sitert blokk fra et tidligere svar. Samsvaret mellom disse forekomstene er det som forteller deg delens formål.

Nettopp denne egenskapen er grunnen til at en identifikator kan bety noe for personvernet. En verdi avledet fra et vertsnavn eller et kontonavn reiser med meldingen og kan avsløre noe om maskinen eller personen som sendte den. Det er fortsatt ikke en VPN-økt, og å behandle det som en sløser bort funnet.

Fjernt bilde eller innebygd del: ulik trafikk

Et img-element med en https kilde og et img-element med en cid kilde ser like ut i HTML-en og oppfører seg ulikt på nettet. Det første navngir en ressurs klienten kan hente når meldingen åpnes, og den hentingen forteller avsenderen at meldingen er lest og fra hvilken adresse. Det andre løses mot en del som allerede ligger i meldingen, så visning av det kontakter ingen.

Én melding kan blande begge, og kontroll av det ene renser ikke det andre. Tell fjernreferansene atskilt fra de innebygde, og noter hva klientens innstillinger tillater. Den forskjellen er beslutningen som betyr noe for personvernet, ikke ordet inne i identifikatoren.

Del beviset uten å sende meldingen

Når noen andre skal se på dette, rediger først og rediger konsekvent. Erstatt adresser og uvedkommende headere, og hold deretter Content-ID-en og dens cid: referanse stavet likt i kopien, fordi en uoverensstemmelse ødelegger det eneste beviset som betyr noe. Si hvilken del headeren hørte til, og hvilken linje som refererte til den. Anmelderen trenger relasjonen, ikke meldingen.

Skil så de to konklusjonene skriftlig: hva meldingen inneholder, og hva den ikke beviser. En påstand formulert slik kan kontrolleres og diskuteres, og det er nettopp det en nyttig rapport tillater.