VPN ID જેવો દેખાતો cid પ્રત્યય માત્ર MIME Content-ID છે

તમે મેઇલ હેડરમાં કોણ-કૌંસવાળા ઓળખકર્તાની અંદર 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: સંદર્ભ નકલમાં એકસરખી જોડણીએ રાખો, કારણ કે અસંગતિ એકમાત્ર મહત્ત્વનો પુરાવો નષ્ટ કરે છે. કહો કે હેડર કયા ભાગનું હતું અને કઈ લાઇને તેનો સંદર્ભ આપ્યો. સમીક્ષકને સંબંધ જોઈએ, સંદેશ નહીં.

પછી બે તારણને લખાણમાં અલગ કરો: સંદેશમાં શું છે, અને તે શું સાબિત કરતું નથી. આ રીતે ઘડાયેલો દાવો ચકાસી શકાય છે અને તેની ચર્ચા થઈ શકે છે, અને ઉપયોગી અહેવાલ એ જ શક્ય બનાવે છે.