മെയിൽ ഹെഡറിലെ കോൺ ബ്രാക്കറ്റിലുള്ള ഐഡന്റിഫയറിനുള്ളിൽ openvpn കാണുമ്പോൾ സന്ദേശത്തിന് VPN സെഷനുമായി ബന്ധമുണ്ടെന്ന് തോന്നും. അതിൽ ഉറച്ചുനിൽക്കുന്നതിന് മുൻപ് മുഴുവൻ വരിയും വായിക്കുക: ഈ സ്ട്രിംഗ് ഒരു Content-ID യിലാണ്, Content-ID എന്നത് ഒരു സന്ദേശത്തിനുള്ളിലെ ഒരു ബോഡി ഭാഗത്തിന്റെ പേരാണ്. HTML-ലെ ഒരു cid: റഫറൻസ് ആ പേരിലേക്ക് സൂചിപ്പിക്കുന്നു, ഈ ജോഡി ഉള്ളത് മെയിലിന് ഒരു ചിത്രം രണ്ടുതവണ അയക്കാതെ കൊണ്ടുപോകാൻ വേണ്ടിയാണ്. ആ ക്രമീകരണത്തിൽ ഒന്നും 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 ഒരു മൂല്യത്തിന് അയച്ചയാളുടെ ഹോസ്റ്റ്നാമോ അക്കൗണ്ട് പോലെയുള്ള സ്ട്രിംഗോ വഹിക്കാൻ അനുവദിക്കുന്നു. പിന്നീട് അതേ പേര് കാണുന്ന എല്ലാ സ്ഥലവും കണ്ടെത്തുക: HTML-ലെ cid: റഫറൻസ്, മറ്റൊരു ഹെഡർ, മുൻപത്തെ മറുപടിയിൽ നിന്നുള്ള ഉദ്ധരണി. ആ പ്രത്യക്ഷപ്പെടലുകൾ തമ്മിലുള്ള ഒത്തുചേരലാണ് ഭാഗത്തിന്റെ ഉദ്ദേശ്യം പറയുന്നത്.

ഈ സ്വഭാവം കൊണ്ടാണ് ഒരു ഐഡന്റിഫയർ സ്വകാര്യതയ്ക്ക് പ്രധാനമാകുന്നത്. ഹോസ്റ്റ്നാമിൽ നിന്നോ അക്കൗണ്ട് പേരിൽ നിന്നോ ഉരുത്തിരിഞ്ഞ മൂല്യം സന്ദേശത്തോടൊപ്പം സഞ്ചരിക്കുന്നു, അത് അയച്ച യന്ത്രത്തെയോ വ്യക്തിയെയോ കുറിച്ച് എന്തെങ്കിലും വെളിപ്പെടുത്തിയേക്കാം. അത് ഇപ്പോഴും VPN സെഷനല്ല, അതിനെ അങ്ങനെ കാണുന്നത് കണ്ടെത്തിയത് നഷ്ടപ്പെടുത്തുന്നു.

വിദൂര ചിത്രമോ ഉൾച്ചേർത്ത ഭാഗമോ: വ്യത്യസ്ത ട്രാഫിക്

ഉറവിടം https ഉള്ള img ഘടകവും ഉറവിടം cid ഉള്ള img ഘടകവും HTML-ൽ ഒരുപോലെ തോന്നുന്നു, നെറ്റ്വർക്കിൽ വ്യത്യസ്തമായി പെരുമാറുന്നു. ആദ്യത്തേത് സന്ദേശം തുറന്നതിന് ശേഷം ക്ലയന്റിന് എടുക്കാവുന്ന ഒരു വിഭവത്തെ പേരിടുന്നു, ആ എടുക്കൽ സന്ദേശം വായിച്ചു എന്നും ഏത് വിലാസത്തിൽ നിന്നാണെന്നും അയച്ചയാളെ അറിയിക്കുന്നു. രണ്ടാമത്തേത് സന്ദേശത്തിനുള്ളിൽ ഇതിനകം ഉള്ള ഭാഗത്തോട് പരിഹരിക്കുന്നു, അതിനാൽ അത് പ്രദർശിപ്പിക്കുന്നത് ആരെയും ബന്ധപ്പെടുന്നില്ല.

ഒരു സന്ദേശത്തിന് രണ്ടും കലർത്താം, ഒന്ന് പരിശോധിക്കുന്നത് മറ്റൊന്നിനെ വൃത്തിയാക്കുന്നില്ല. വിദൂര റഫറൻസുകൾ ഉൾച്ചേർത്തവയിൽ നിന്ന് വേർതിരിച്ച് എണ്ണുക, ക്ലയന്റ് ക്രമീകരണങ്ങൾ എന്ത് അനുവദിക്കുന്നു എന്ന് കുറിക്കുക. സ്വകാര്യതയ്ക്ക് പ്രധാനമായ തീരുമാനം ആ വ്യത്യാസമാണ്, ഐഡന്റിഫയറിലെ വാക്കല്ല.

സന്ദേശം അയക്കാതെ തെളിവ് പങ്കിടുക

മറ്റൊരാൾ ഇത് നോക്കേണ്ടിവരുമ്പോൾ ആദ്യം മറയ്ക്കുക, സ്ഥിരതയോടെ മറയ്ക്കുക. വിലാസങ്ങളും അസംബന്ധ ഹെഡറുകളും മാറ്റി, പിന്നീട് Content-ID ഉം അതിന്റെ cid: റഫറൻസും പകർപ്പിൽ ഒരേ വിധത്തിൽ എഴുതി നിർത്തുക, കാരണം പൊരുത്തക്കേട് പ്രധാനമായ ഏക തെളിവിനെ നശിപ്പിക്കുന്നു. ഹെഡർ ഏത് ഭാഗത്തിന്റേതായിരുന്നു, ഏത് വരി അതിനെ റഫറൻസ് ചെയ്തു എന്ന് പറയുക. അവലോകകന് ബന്ധം വേണം, സന്ദേശമല്ല.

പിന്നീട് രണ്ട് നിഗമനങ്ങൾ എഴുത്തിൽ വേർതിരിക്കുക: സന്ദേശത്തിൽ എന്തുണ്ട്, അത് എന്ത് തെളിയിക്കുന്നില്ല. അങ്ങനെ ചട്ടക്കൂട്ടിയ അവകാശവാദം പരിശോധിക്കാനും ചർച്ച ചെയ്യാനും കഴിയും, ഉപയോഗപ്രദമായ റിപ്പോർട്ട് അതു തന്നെ സാധ്യമാക്കുന്നു.

അനുബന്ധ ലേഖനങ്ങൾ