Ett cid-suffix som ser ut som ett VPN-id är bara ett MIME Content-ID

Du ser openvpn inuti en identifierare inom vinkelparenteser i ett e-posthuvud och den uppenbara slutsatsen är att meddelandet har något med en VPN-session att göra. Läs hela raden innan du accepterar det: strängen sitter i ett Content-ID, och ett Content-ID är ett namn för en kroppsdel i ett meddelande. En cid: -referens i HTML pekar på det namnet, och paret finns för att mejlet ska kunna bära en bild utan att skicka den två gånger. Inget i den ordningen når en VPN-server, och inget i suffixet säger vem som byggde identifieraren.

Vad identifieraren faktiskt pekar på

HTML-mejl kommer sällan som ett enda block. Texten och varje inbäddad bild färdas vanligen som separata MIME-delar, och klienten sätter ihop dem för visning. För det behöver den ett namn för bilddelen och en referens som löser upp till det namnet.

Paret nedan är påhittat för att illustrera.

Content-ID: <[email protected]>

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

Huvudraden hör till bilddelen; img-elementet hör till HTML-delen. Vinkelparenteser tillhör huvudets syntax, så en cid: -referens skriver vanligen identifieraren utan dem. Värden med tecken som måste escapas måste kodas, och därför är paret en illustration snarare än en konverteringsregel. Det som bär betydelsen är matchningen mellan de två strängarna, inte någon av dem för sig.

Suffixet @openvpn är en konstruktionsdetalj

Ett Content-ID byggs för att vara unikt inom ett meddelande, och e-postprogram gör det ofta adresslikt genom att lägga till ett @ och en domän. Den formen är en konvention från generatorn, inte en väg: inget i huvudet ber klienten kontakta mailer.example, och ingen uppslagning sker när meddelandet visas. Fältet är inte heller ett kontonamn, en VPN-användare eller ett spår från en VPN-klient. Strängen valdes av den som satte ihop meddelandet när den namngav en del.

RFC 2392 definierar cid -schemat och begränsar det till att referera meddelanden och deras delar. Läs det omfånget bokstavligt och suffixet slutar vara bevis för något utöver namngivning. Det betyder också att avsändaren inte kan identifieras från suffixet, vilket är det språng folk tar när ett bekant ord dyker upp i ett huvud.

Granska råtexten och bedöm sedan integritetsfrågan

Öppna råtexten och läs hela Content-ID-värdet, eftersom RFC 2392 låter ett värde bära avsändarens hostname eller en kontoliknande sträng. Leta sedan upp varje ställe där samma namn förekommer: en cid: -referens i HTML, ett annat huvud, ett citerat block från ett tidigare svar. Matchningen mellan dessa förekomster är det som säger dig vad delen är till för.

Samma egenskap är skälet till att en identifierare kan spela roll för integriteten. Ett värde som härrör från ett hostname eller ett kontonamn följer med meddelandet och kan avslöja något om maskinen eller personen som skickade det. Det är fortfarande ingen VPN-session, och att behandla det som en slösar bort fyndet.

Fjärrbild eller inbäddad del: olika trafik

Ett img-element med en https -källa och ett img-element med en cid -källa ser likadana ut i HTML men beter sig olika på nätet. Det första namnger en resurs som klienten kan hämta när meddelandet öppnas, och den hämtningen talar om för avsändaren att meddelandet lästes och från vilken adress. Det andra löses mot en del som redan finns i meddelandet, så att visa det kontaktar ingen.

Ett enda meddelande kan blanda båda, och att kontrollera det ena rentvår inte det andra. Räkna fjärrreferenserna separat från de inbäddade och notera vad klientens inställningar tillåter. Den skillnaden är det beslut som spelar roll för integriteten, inte ordet inne i identifieraren.

Dela bevisen utan att skicka meddelandet

När någon annan måste titta på det här, redigera först och redigera konsekvent. Byt ut adresser och orelaterade huvuden och behåll sedan Content-ID:t och dess cid: -referens stavad likadant i kopian, eftersom en avvikelse förstör det enda bevis som spelar roll. Ange vilken del huvudet hörde till och vilken rad som refererade till det. Granskaren behöver sambandet, inte meddelandet.

Dela sedan upp de två slutsatserna skriftligt: vad meddelandet innehåller och vad det inte bevisar. Ett påstående formulerat så kan kontrolleras och bemötas, och det är vad en användbar rapport tillåter.