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: संदर्भ प्रतिमध्ये एकाच शुद्धलीपीत ठेवा, कारण विसंगती महत्त्वाचा एकमेव पुरावा नष्ट करते. हेडर कोणत्या भागाचा होता आणि कोणत्या ओळीने त्याचा संदर्भ दिला ते सांगा. पुनरावलोककाला संबंध हवा, संदेश नाही.

मग दोन निष्कर्ष लिखित स्वरूपात वेगळे करा: संदेशात काय आहे, आणि तो काय सिद्ध करत नाही. अशा रीतीने मांडलेला दावा तपासता येतो आणि त्यावर चर्चा करता येते, आणि उपयुक्त अहवाल तेच शक्य करतो.