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: संदर्भ को प्रति में एक जैसी वर्तनी में रखें, क्योंकि असंगति एकमात्र महत्वपूर्ण प्रमाण को नष्ट कर देती है। कहें कि हेडर किस भाग का था और किस पंक्ति ने उसका संदर्भ दिया। समीक्षक को संबंध चाहिए, संदेश नहीं।

फिर दोनों निष्कर्षों को लिखित रूप में अलग करें: संदेश में क्या है, और वह क्या सिद्ध नहीं करता। इस तरह रखा गया दावा जाँचा और चर्चा किया जा सकता है, और उपयोगी रिपोर्ट ठीक यही संभव बनाती है।