Sufix cid, který vypadá jako ID VPN, je jen MIME Content-ID
Odkaz cid ukazuje na vloženou část MIME. Jeho doméně podobný sufix je detail konstrukce, ne adresa ani relace VPN.
Uvidíte openvpn uvnitř identifikátoru v lomených závorkách v hlavičce e-mailu a zřejmý závěr je, že zpráva má něco společného s relací VPN. Přečtěte si celý řádek, než se na to upnete: řetězec leží v Content-ID a Content-ID je název jedné části těla uvnitř jedné zprávy. Odkaz cid: v HTML ukazuje na tento název a dvojice existuje proto, aby pošta mohla nést obrázek, aniž by ho posílala dvakrát. Nic v tomto uspořádání se nedostane na server VPN a nic v sufixu neříká, kdo identifikátor sestavil.
Na co identifikátor vlastně ukazuje
HTML pošta málokdy přichází jako jediný blok. Text a každý vložený obrázek obvykle cestují jako samostatné části MIME a klient je pro zobrazení znovu skládá. K tomu potřebuje název pro část s obrázkem a odkaz, který se na tento název vyřeší.
Dvojice níže je vymyšlená pro ilustraci.
Content-ID: <[email protected]>
<img src="cid:[email protected]" alt="Company mark">Řádek hlavičky leží na části s obrázkem; prvek img leží v části HTML. Lomené závorky patří k syntaxi hlavičky, takže odkaz cid: obvykle píše identifikátor bez nich. Hodnoty se znaky, které je třeba escapovat, musí být zakódované, a proto je tato dvojice ilustrace, nikoli pravidlo převodu. Význam nese shoda obou řetězců, ne kterýkoli z nich samotný.
Sufix @openvpn je detail konstrukce
Content-ID se staví tak, aby byl v rámci jedné zprávy jedinečný, a poštovní software mu často dává podobu adresy přidáním @ a domény. Tento tvar je konvence generátoru, ne trasa: nic v hlavičce nežádá klienta, aby kontaktoval mailer.example, a při zobrazení zprávy neproběhne žádné vyhledávání. Pole také není název účtu, uživatel VPN ani stopa zanechaná klientem VPN. Kdo zprávu sestavoval, vybral řetězec při pojmenování části.
RFC 2392 definuje schéma cid a omezuje ho na odkazování na zprávy a jejich části. Přečtěte tento rozsah doslova a sufix přestane být důkazem čehokoli mimo pojmenování. Znamená to také, že producenta nelze ze sufixu určit, a právě ten skok lidé dělají, když se v hlavičce objeví známé slovo.
Prohlédněte surový zdroj, pak posuďte otázku soukromí
Otevřete surový zdroj a přečtěte celou hodnotu Content-ID, protože RFC 2392 dovoluje, aby hodnota nesla název hostitele odesílatele nebo řetězec podobný názvu účtu. Pak najděte každé místo, kde se stejný název objevuje: odkaz cid: v HTML, jinou hlavičku, citovaný blok z dřívější odpovědi. Shoda mezi těmito výskyty je to, co vám řekne účel části.
Právě tato vlastnost je důvod, proč může být identifikátor důležitý pro soukromí. Hodnota odvozená z názvu hostitele nebo názvu účtu cestuje se zprávou a může prozradit něco o stroji nebo osobě, která ji poslala. Pořád to není relace VPN a zacházet s ní jako s relací znamená promarnit nález.
Vzdálený obrázek nebo vložená část: jiný provoz
Prvek img se zdrojem https a prvek img se zdrojem cid vypadají v HTML stejně a v síti se chovají odlišně. První pojmenuje zdroj, který klient může stáhnout, jakmile zprávu otevře, a toto stažení sdělí odesílateli, že zpráva byla přečtena a z jaké adresy. Druhý se vyřeší proti části, která už je uvnitř zprávy, takže jeho zobrazení s nikým nespojí.
Jedna zpráva může míchat obojí a ověření jednoho neočistí druhé. Počítejte vzdálené odkazy odděleně od vložených a poznamenejte, co nastavení klienta dovoluje. Právě toto rozlišení je rozhodnutí důležité pro soukromí, ne slovo uvnitř identifikátoru.
Sdílejte důkaz, aniž byste posílali zprávu
Když se na to má podívat někdo jiný, nejprve redigujte a redigujte důsledně. Nahraďte adresy a nesouvisející hlavičky, pak ponechte Content-ID a jeho odkaz cid: v kopii napsané stejně, protože neshoda ničí jediný důkaz, který má význam. Řekněte, ke které části hlavička patřila a který řádek na ni odkazoval. Recenzent potřebuje vztah, ne zprávu.
Pak oddělte dva závěry písemně: co zpráva obsahuje a co nedokazuje. Tvrzení takto zarámované lze ověřit a diskutovat o něm, a to je to, co užitečná zpráva umožňuje.