cid piedēklis, kas izskatās kā VPN ID, ir tikai MIME Content-ID

Jūs redzat openvpn e-pasta galvenē identifikatorā starp leņķa iekavām, un acīmredzamais secinājums ir, ka ziņojumam ir saistība ar VPN sesiju. Izlasiet visu rindu, pirms tam pieķeraties: virkne atrodas Content-ID, un Content-ID ir vienas ziņojuma pamatteksta daļas nosaukums. cid: atsauce HTML norāda uz šo nosaukumu, un pāris pastāv tāpēc, lai pasts varētu nest attēlu, to nesūtot divreiz. Nekas šajā kārtojumā nesasniedz VPN serveri, un nekas piedēklī nepasaka, kas identifikatoru uzbūvēja.

Uz ko identifikators patiešām norāda

HTML pasts reti atnāk kā viens bloks. Teksts un katrs iegultais attēls parasti ceļo kā atsevišķas MIME daļas, un klients tās atkal saliek attēlošanai. Tam vajadzīgs attēla daļas nosaukums un atsauce, kas atrisinās uz šo nosaukumu.

Zemāk esošais pāris ir izdomāts ilustrācijai.

Content-ID: <[email protected]>

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

Galvenes rinda atrodas uz attēla daļas; img elements atrodas HTML daļā. Leņķa iekavas pieder galvenes sintaksei, tāpēc cid: atsauce parasti raksta identifikatoru bez tām. Vērtības ar rakstzīmēm, kurām vajag escape, ir jākodē, un tāpēc šis pāris ir ilustrācija, nevis pārveides noteikums. Nozīmi nes abu virkņu sakritība, nevis kāda no tām atsevišķi.

@openvpn piedēklis ir konstrukcijas detaļa

Content-ID tiek būvēts unikāls vienā ziņojumā, un pasta programmatūra to bieži padara līdzīgu adresei, pievienojot @ un domēnu. Šī forma ir ģeneratora konvencija, nevis maršruts: nekas galvenē nelūdz klientam sazināties ar mailer.example, un, ziņojumu attēlojot, nenotiek nekāda meklēšana. Laukums arī nav konta nosaukums, VPN lietotājs vai VPN klienta atstāta zīme. Kas ziņojumu salika, to virkni izvēlējās, daļai dodot nosaukumu.

RFC 2392 definē cid shēmu un ierobežo to ar atsaucēm uz ziņojumiem un to daļām. Izlasiet šo tvērumu burtiski, un piedēklis pārstāj būt pierādījums kaut kam ārpus nosaukšanas. Tas arī nozīmē, ka veidotāju nevar noteikt pēc piedēkļa, un tieši šo lēcienu cilvēki izdara, kad galvenē parādās pazīstams vārds.

Pārbaudiet neapstrādāto avotu, tad izvērtējiet privātuma jautājumu

Atveriet neapstrādāto avotu un izlasiet visu Content-ID vērtību, jo RFC 2392 pieļauj, ka vērtība nes sūtītāja resursdatora nosaukumu vai kontam līdzīgu virkni. Pēc tam atrodiet katru vietu, kur parādās tas pats nosaukums: cid: atsauce HTML, cita galvene, citāts no agrākas atbildes. Šo parādīšanās gadījumu sakritība ir tā, kas pasaka daļas mērķi.

Tieši šī īpašība padara identifikatoru nozīmīgu privātumam. Vērtība, kas atvasināta no resursdatora nosaukuma vai konta nosaukuma, ceļo kopā ar ziņojumu un var atklāt kaut ko par mašīnu vai cilvēku, kas to nosūtīja. Tā joprojām nav VPN sesija, un izturēties pret to kā pret tādu nozīmē izšķērdēt atradumu.

Attālināts attēls vai iegulta daļa: atšķirīga plūsma

img elements ar avotu https un img elements ar avotu cid HTML izskatās vienādi un tīklā uzvedas atšķirīgi. Pirmais nosauc resursu, ko klients var iegūt pēc ziņojuma atvēršanas, un šī iegūšana pasaka sūtītājam, ka ziņojums ir lasīts un no kādas adreses. Otrais atrisinās pret daļu, kas jau ir ziņojumā, tāpēc tā attēlošana ar nevienu nesazinās.

Viens ziņojums var sajaukt abus, un viena pārbaude neattīra otru. Skaitiet attālinātās atsauces atsevišķi no iegultajām un pierakstiet, ko pieļauj klienta iestatījumi. Tieši šī atšķirība ir privātumam svarīgais lēmums, nevis vārds identifikatorā.

Kopīgojiet pierādījumu, nesūtot ziņojumu

Kad kādam citam tas jāapskata, vispirms aizklājiet un dariet to konsekventi. Aizstājiet adreses un nesaistītās galvenes, pēc tam saglabājiet Content-ID un tā cid: atsauci kopijā uzrakstītas vienādi, jo neatbilstība iznīcina vienīgo svarīgo pierādījumu. Pasakiet, kurai daļai galvene piederēja un kura rinda uz to norādīja. Recenzentam vajadzīgas attiecības, nevis ziņojums.

Pēc tam atdaliet divus secinājumus rakstiski: ko ziņojums satur un ko tas nepierāda. Šādi formulēts apgalvojums ir pārbaudāms un apspriežams, un tieši to pieļauj lietderīgs ziņojums.