cid наставак који личи на VPN идентификатор је само MIME Content-ID

У заглављу е-поште приметите openvpn унутар идентификатора у угластим заградама и очигледан закључак је да порука има везе са VPN сесијом. Прочитајте цео ред пре него што то прихватите: низ се налази у Content-ID, а Content-ID је назив једног дела тела у једној поруци. Референца cid: у HTML-у показује на тај назив, а пар постоји да би пошта могла да носи слику без двоструког слања. Ништа у том уређењу не стиже до VPN сервера и ништа у наставку не каже ко је идентификатор саставио.

На шта идентификатор заиста показује

HTML пошта ретко стиже као један блок. Текст и свака уграђена слика обично путују као одвојени делови тела MIME, а клијент их при приказу поново спаја. За то му је потребан назив дела са сликом и референца која се разрешава на тај назив.

Пар испод је измишљен ради илустрације.

Content-ID: <[email protected]>

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

Ред заглавља припада делу са сликом; елемент img припада делу HTML. Угласте заграде су део синтаксе заглавља, па референца cid: обично исписује идентификатор без њих. Вредности са знаковима које треба екранизовати морају да буду кодиране, и зато је овај пар илустрација, а не правило конверзије. Значење носи поклапање два низа, а не било који од њих сам.

Наставак @openvpn је детаљ конструкције

Content-ID се гради тако да буде јединствен унутар једне поруке, а поштански софтвер му често додаје @ и домен да би личио на адресу. Тај облик је конвенција генератора, а не путања: ништа у заглављу не тражи од клијента да контактира mailer.example, и никаква претрага се не дешава када се порука прикаже. Поље такође није назив налога, VPN корисник или траг који је оставио VPN клијент. Низ је изабрао онај ко је састављао поруку и именовао део.

RFC 2392 дефинише шему cid и ограничава је на референцирање порука и њихових делова. Ако тај обим прочитате дословно, наставак престаје да буде доказ било чега осим именовања. То такође значи да се произвођач не може препознати из наставка, а то је скок који људи направе када се у заглављу појави позната реч.

Прегледајте сирови извор, па процените питање приватности

Отворите сирови извор и прочитајте целу вредност Content-ID, јер RFC 2392 дозвољава да вредност носи hostname пошиљаоца или низ налик називу налога. Затим пронађите свако место где се исти назив појављује: референца cid: у HTML-у, друго заглавље, цитирани блок из ранијег одговора. Поклапање тих појава је оно што вам каже чему део служи.

Исто својство је разлог зашто идентификатор може бити важан за приватност. Вредност изведена из hostname-а или назива налога путује с поруком и може открити нешто о машини или особи која ју је послала. То и даље није VPN сесија, а третирање као сесију губи налаз.

Удаљена слика или уграђени део: различит саобраћај

Елемент img са извором https и елемент img са извором cid изгледају исто у HTML-у, а на мрежи се понашају другачије. Први именује ресурс који клијент може преузети када се порука отвори, и то преузимање каже пошиљаоцу да је порука прочитана и са које адресе. Други се разрешава према делу који је већ у поруци, па његов приказ никога не контактира.

Једна порука може да меша обоје, а провера једнога не чисти друго. Бројите удаљене референце одвојено од уграђених и забележите шта подешавања клијента дозвољавају. За приватност је пресудан тај разлика, а не реч унутар идентификатора.

Поделите доказе без слања поруке

Када то мора да погледа неко други, прво редигујте и редигујте доследно. Замените адресе и неповезана заглавља, затим у копији задржите Content-ID и његову референцу cid: написану исто, јер неслагање уништава једини доказ који је важан. Наведите ком делу је заглавље припадало и који ред се на њега позивао. Рецензенту је потребан однос, не порука.

Затим писано раздвојите два закључка: шта порука садржи и шта не доказује. Тако формулисана тврдња може да се провери и оспори, а то је управо оно што користан извештај омогућава.