cid наставка што изгледа како VPN ID е само 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: референцата обично го пишува идентификаторот без нив. Вредностите со знаци што бараат escape мора да бидат кодирани, и затоа овој пар е илустрација, а не правило за преобразба. Значењето го носи совпаѓањето на двете низи, а не која било од нив сама.

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

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

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

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

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

Токму тоа својство го прави идентификаторот важен за приватноста. Вредност изведена од име на домаќин или име на сметка патува со пораката и може да открие нешто за машината или личноста што ја пратила. Таа сепак не е VPN сесија, и да се однесуваме со неа како со таква го троши наодот.

Далечна слика или вграден дел: различен сообраќај

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

Една порака може да ги измеша двете, и проверката на едното не го чисти другото. Бројте ги далечните референци одделно од вградените и запишете што дозволуваат поставките на клиентот. Токму таа разлика е одлуката важна за приватноста, а не зборот внатре во идентификаторот.

Споделете го доказот без да ја пратите пораката

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

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