Eit cid-suffiks som ser ut som ein VPN-ID er berre ein MIME Content-ID
Ei cid-referanse peikar på ein innbygd MIME-del. Det domeneliknande suffikset er ein konstruksjonsdetalj, ikkje ei adresse eller ei VPN-økt.
Du ser openvpn inne i ein identifikator i vinkelparentesar i ein e-postheader, og den openberre konklusjonen er at meldinga har noko med ei VPN-økt å gjere. Les heile linja før du bind deg til det: strengen står i ein Content-ID, og ein Content-ID er eit namn på éin del av kroppen i éi melding. Ei cid: referanse i HTML-en peikar på det namnet, og paret finst for at e-posten skal kunne bere eit bilete utan å sende det to gonger. Ingenting i den ordninga når ein VPN-server, og ingenting i suffikset seier kven som bygde identifikatoren.
Kva identifikatoren eigentleg peikar på
HTML-e-post kjem sjeldan som éin blokk. Teksten og kvart innbygde bilete reiser vanlegvis som separate MIME-delar, og klienten set dei saman att for vising. For det treng han eit namn for bildedelen og ein referanse som løyser seg opp til det namnet.
Paret nedanfor er oppdikta som illustrasjon.
Content-ID: <[email protected]>
<img src="cid:[email protected]" alt="Company mark">Headerlinja står på bildedelen; img-elementet står i HTML-delen. Vinkelparentesar høyrer til header-syntaksen, så ein cid: referanse skriv vanlegvis identifikatoren utan dei. Verdiar med teikn som må escapeast, må kodast, og difor er dette paret ein illustrasjon og ikkje ein konverteringsregel. Det som ber meininga, er samsvaret mellom dei to strengane, ikkje nokon av dei åleine.
@openvpn-suffikset er ein konstruksjonsdetalj
Ein Content-ID vert bygd for å vere unik i éi melding, og e-postprogramvare får han ofte til å sjå ut som ei adresse ved å leggje til ein @ og eit domene. Den forma er ein konvensjon frå generatoren, ikkje ei rute: ingenting i headeren ber klienten kontakte mailer.example, og ingen oppslag skjer når meldinga vert vist. Feltet er heller ikkje eit kontonamn, ein VPN-brukar eller eit merke ein VPN-klient har lagt att. Den som sette saman meldinga, valde strengen då ein del vart namngjeven.
RFC 2392 definerer cid-skjemaet og avgrensar det til å referere til meldingar og delane deira. Les dette omfanget bokstaveleg, og suffikset sluttar å vere prov for noko ut over namngjeving. Det tyder òg at produsenten ikkje kan identifiserast frå suffikset, og det er nettopp det spranget folk tek når eit kjent ord dukkar opp i ein header.
Undersøk rådataa, og vurder så personvernspørsmålet
Opne rådataa og les heile Content-ID-verdien, fordi RFC 2392 tillèt at ein verdi ber vertsnamnet til avsendarane eller ein kontoliknande streng. Finn så kvar stad der det same namnet førekjem: ein cid: referanse i HTML-en, ein annan header, ein sitert blokk frå eit tidlegare svar. Samsvaret mellom desse førekomstane er det som fortel deg føremålet med delen.
Nettopp denne eigenskapen er grunnen til at ein identifikator kan bety noko for personvernet. Ein verdi avleidd frå eit vertsnamn eller eit kontonamn reiser med meldinga og kan avsløre noko om maskinen eller personen som sende henne. Det er framleis ikkje ei VPN-økt, og å handsame det som ei sløser bort funnet.
Fjernt bilete eller innbygd del: ulik trafikk
Eit img-element med ein https kjelde og eit img-element med ein cid kjelde ser like ut i HTML-en og oppfører seg ulikt på nettet. Det fyrste namngjev ein ressurs klienten kan hente når meldinga vert opna, og den hentinga fortel avsendaren at meldinga er lesen og frå kva adresse. Det andre løyser seg mot ein del som alt ligg i meldinga, så vising av det kontaktar ingen.
Éi melding kan blande båe, og kontroll av det eine reinskar ikkje det andre. Tel fjernreferansane skilt frå dei innbygde, og noter kva innstillingane til klienten tillèt. Den skilnaden er avgjerda som betyr noko for personvernet, ikkje ordet inne i identifikatoren.
Del provet utan å sende meldinga
Når nokon andre skal sjå på dette, rediger fyrst og rediger konsekvent. Bytt ut adresser og uvedkommande headere, og hald deretter Content-ID-en og cid: referansen hans stava likt i kopien, fordi eit avvik øydelegg det einaste provet som betyr noko. Sei kva del headeren høyrde til, og kva linje som refererte til han. Vurderaren treng relasjonen, ikkje meldinga.
Skil så dei to konklusjonane skriftleg: kva meldinga inneheld, og kva ho ikkje provar. Ein påstand formulert slik kan kontrollerast og diskuterast, og det er nettopp det ein nyttig rapport tillèt.