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

त्यसपछि दुई निष्कर्ष लिखित रूपमा छुट्याउनुहोस्: सन्देशमा के छ, र यसले के प्रमाणित गर्दैन। यसरी बनाइएको दाबी जाँच्न र बहस गर्न सकिन्छ, र उपयोगी प्रतिवेदनले ठ्याक्कै त्यही सम्भव बनाउँछ।