Суфікс cid, які выглядае як VPN ID, — гэта проста MIME Content-ID
Спасылка cid паказвае на ўбудаваную частку MIME. Яе падобны на дамен суфікс — дэталь пабудовы, а не адрас і не сесія VPN.
Вы бачыце 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 дазваляе значэнню несці імя хоста адпраўніка або радок, падобны на імя ўліковага запісу. Затым знайдзіце кожнае месца, дзе з’яўляецца тое ж імя: спасылка cid: у HTML, іншы загаловак, цытаваны блок з папярэдняга адказу. Супадзенне паміж гэтымі выпадкамі і кажа вам пра прызначэнне часткі.
Менавіта гэтая ўласцівасць робіць ідэнтыфікатар важным для прыватнасці. Значэнне, вытворнае ад імя хоста або імя ўліковага запісу, падарожнічае з паведамленнем і можа выкрыць нешта пра машыну або чалавека, які яго даслаў. Гэта ўсё яшчэ не сесія VPN, і ставіцца да яго як да сесіі — марнаваць здабытак.
Аддаленая выява ці ўбудаваная частка: розны трафік
Элемент img з крыніцай https і элемент img з крыніцай cid выглядаюць у HTML аднолькава, а ў сетцы паводзяць сябе па-рознаму. Першы называе рэсурс, які кліент можа загрузіць пасля адкрыцця паведамлення, і гэтая загрузка паведамляе адпраўніку, што паведамленне прачытана і з якога адрасу. Другі вырашаецца адносна часткі, ужо наяўнай у паведамленні, таму яго паказ ні з кім не звязваецца.
Адно паведамленне можа змяшаць абодва, і праверка аднаго не ачышчае другога. Лічыце аддаленыя спасылкі асобна ад убудаваных і адзначце, што дазваляюць налады кліента. Менавіта гэтае размежаванне — рашэнне, важнае для прыватнасці, а не слова ўнутры ідэнтыфікатара.
Падзяліцеся доказамі, не адпраўляючы паведамленне
Калі хтосьці іншы мусіць на гэта зірнуць, спачатку адрэдагуйце і рабіце гэта паслядоўна. Замяніце адрасы і недатычныя загалоўкі, затым пакіньце Content-ID і яго спасылку cid: напісанымі аднолькава ў копіі, бо разыходжанне знішчае адзіны доказ, які мае значэнне. Скажыце, да якой часткі належаў загаловак і які радок спасылаўся на яго. Рэцэнзенту патрэбна сувязь, а не паведамленне.
Затым раздзяліце дзве высновы пісьмова: што паведамленне змяшчае і чаго яно не даказвае. Сцвярджэнне, сфармуляванае так, можна праверыць і абмеркаваць, і менавіта гэта дазваляе карысная справаздача.