VPN-ID moodi näiv cid-järelliide on vaid MIME Content-ID

Näete openvpn nurksulgudes identifikaatori sees meili päises ja ilmne järeldus on, et sõnumil on midagi tegemist VPN-sessiooniga. Lugege kogu rida enne, kui sellega nõustute: string asub Content-ID-s ja Content-ID on ühe sõnumi ühe kehaosa nimi. Viide cid: HTML-is osutab sellele nimele ja paar on olemas selleks, et meil saaks pilti kanda ilma seda kaks korda saatmata. Miski selles korralduses ei jõua VPN-serverini ja miski järelliites ei ütle, kes identifikaatori ehitas.

Millele identifikaator tegelikult osutab

HTML-meil saabub harva ühe plokina. Tekst ja iga manustatud pilt liiguvad tavaliselt eraldi MIME-osadena ning klient paneb need kuvamiseks uuesti kokku. Selleks vajab ta pildiosa nime ja viidet, mis sellele nimele laheneb.

Allolev paar on illustreerimiseks välja mõeldud.

Content-ID: <[email protected]>

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

Päise rida asub pildi osal; img-element asub HTML-osa sees. Nurkjooned kuuluvad päise süntaksisse, seega viide cid: kirjutab identifikaatori tavaliselt ilma nendeta. Väärtused, mis sisaldavad escapemist vajavaid märke, tuleb kodeerida, ja seetõttu on see paar illustratsioon, mitte teisendusreegel. Tähendust kannab kahe stringi kattuvus, mitte kumbki string üksi.

@openvpn järelliide on konstruktsiooni detail

Content-ID ehitatakse ühe sõnumi sees unikaalseks ja meilitarkvara teeb selle sageli aadressi moodi, lisades @ ja domeeni. See kuju on generaatori konventsioon, mitte marsruut: miski päises ei palu kliendil mailer.example-iga ühendust võtta ja sõnumi kuvamisel ei toimu ühtegi päringut. Väli ei ole ka konto nimi, VPN-kasutaja ega VPN-kliendi jäetud jälg. See, kes sõnumi kokku pani, valis stringi osa nimetades.

RFC 2392 määratleb skeemi cid ja piirab selle sõnumitele ja nende osadele viitamisega. Lugege seda ulatust sõna-sõnalt ja järelliide lakkab olemast tõend millestki peale nimetamise. See tähendab ka, et tootjat ei saa järelliitest tuvastada, ja just selle hüppe teevad inimesed, kui päises ilmub tuttav sõna.

Uurige töötlemata allikat, seejärel hinnake privaatsusküsimust

Avage töötlemata allikas ja lugege kogu Content-ID väärtust, sest RFC 2392 lubab väärtusel kanda saatja hostinime või kontosarnast stringi. Seejärel leidke iga koht, kus sama nimi esineb: viide cid: HTML-is, teine päis, varasemast vastusest tsiteeritud plokk. Nende esinemiste kattuvus ütleb teile osa otstarbe.

Just see omadus teeb identifikaatori privaatsuse jaoks oluliseks. Hostinimest või konto nimest tuletatud väärtus rändab sõnumiga kaasa ja võib paljastada midagi masina või selle saatnud inimese kohta. See ei ole ikkagi VPN-sessioon ja selle nii kohtlemine raiskab leiu.

Kaugpilt või manustatud osa: erinev liiklus

img-element allikaga https ja img-element allikaga cid näevad HTML-is sarnased välja ja käituvad võrgus erinevalt. Esimene nimetab ressursi, mille klient võib pärast sõnumi avamist tuua, ja see toomine ütleb saatjale, et sõnumit loeti ja milliselt aadressilt. Teine laheneb osa vastu, mis on juba sõnumi sees, seega selle kuvamine ei võta kellegagi ühendust.

Üks sõnum võib segada mõlemat ja ühe kontrollimine ei puhasta teist. Loendage kaugviited manustatutest eraldi ja märkige, mida kliendi seaded lubavad. Just see eristus on privaatsuse jaoks oluline otsus, mitte identifikaatori sees olev sõna.

Jagage tõendit sõnumit saatmata

Kui keegi teine peab seda vaatama, redigeerige kõigepealt ja redigeerige järjekindlalt. Asendage aadressid ja mitteseotud päised, seejärel hoidke Content-ID ja selle viide cid: koopias ühtemoodi kirjutatud, sest lahknevus hävitab ainsa tõendi, mis loeb. Öelge, millisele osale päis kuulus ja milline rida sellele viitas. Ülevaataja vajab seost, mitte sõnumit.

Seejärel eraldage kaks järeldust kirjalikult: mida sõnum sisaldab ja mida see ei tõesta. Nii sõnastatud väidet saab kontrollida ja vaidlustada, ja just seda võimaldab kasulik aruanne.