د VPN ID په څېر ښکارېدونکی cid پسوند یوازې MIME Content-ID دی

تاسو د برېښنالیک په سرلیک کې د کونجونه قوسونو دننه د پېژندونکي په منځ کې openvpn ګورئ او ښکاره پایله دا ده چې پیغام د VPN غونډې سره اړیکه لري. مخکې لدې چې پرې ودرېږئ ټوله کرښه ولولئ: دا تار د یوه Content-ID په دننه کې دی، او Content-ID د یوه پیغام دننه د یوې برخې نوم دی. یوه cid: حواله په HTML کې هماغه نوم ته اشاره کوي، او دا جوړه د دې لپاره ده چې برېښنالیک یو انځور پرته لدې چې دوه ځله یې ولېږي، یوسي. په دې ترتیب کې هیڅ شی VPN سرور ته نه رسېږي، او په پسوند کې هیڅ شی نه وایي چې پېژندونکی چا جوړ کړی.

پېژندونکی په رښتیا څه ته اشاره کوي

HTML برېښنالیک کم د یوې ټیکې په توګه راځي. متن او هر دننه شوی انځور معمولاً د جلا MIME برخو په توګه سفر کوي، او کلاینټ د ښودلو لپاره بیا سره یوځای کوي. د دې لپاره ورته د انځور برخې لپاره نوم او د هغه نوم ته رسېدونکې حواله پکار ده.

لاندې جوړه د بېلګې لپاره جوړه شوې ده.

Content-ID: <[email protected]>

<img src="cid:[email protected]" alt="Company mark">

د سرلیک کرښه پر انځور برخه ده؛ img عنصر د HTML په برخه کې دی. کونجونه قوسونه د سرلیک نحو ته اړه لري، نو cid: حواله معمولاً پېژندونکی پرته لدې لیکي. هغه ارزښتونه چې د escape وړ توري لري باید کوډ شي، او له دې کبله دا جوړه د بدلون قاعده نه، بېلګه ده. مانا د دوو تارونو ورته والی لري، نه د دوی له یوه یوازې.

@openvpn پسوند د جوړېدو تفصیل دی

Content-ID د دې لپاره جوړېږي چې د یوه پیغام دننه ځانګړی وي، او برېښنالیک ساوتري ډېری وخت د @ او ډومېن په زیاتولو پته ته ورته ښکاره کوي. دا بڼه د جوړوونکي دود دی، نه لار: په سرلیک کې هیڅ شی کلاینټ نه شي کولای mailer.example سره اړیکه ونیسي، او کله چې پیغام ښودل کېږي هیڅ پوښتنه نه کېږي. دا ساحه هم د حساب نوم، VPN کارن یا د VPN کلاینټ پاتې نښه نه ده. چا چې پیغام جوړ کړی، د برخې په نومولو کې هماغه تار غوره کړی.

RFC 2392 cid سکیم تعریفوي او د پیغامونو او د هغوی برخو ته په حوالې پورې یې محدودوي. که دا حد په لغوي معنا ولولئ، پسوند له نومولو پرته د بل هر څه ثبوت نه وي. دا هم مانا لري چې جوړوونکی له پسوند نه پېژندل کېدای نه شي، او خلک هماغه ټوپ وهي کله چې په سرلیک کې یو آشنا کلمه راښکاره شي.

خام سرچینه وګورئ، بیا د خصوصیت پوښتنه پرېکړه کړئ

خام سرچینه پرانیزئ او د Content-ID بشپړ ارزښت ولولئ، ځکه RFC 2392 اجازه ورکوي چې ارزښت د لېږونکي هوسټ نوم یا حساب ته ورته تار ولېږدوي. بیا هر هغه ځای ومومئ چې هماغه نوم پکې ښکاره شوی: په HTML کې cid: حواله، بله سرلیک، د پخواني ځواب نه نقل شوې ټوټه. د دې ښکارېدنو ترمنځ ورته والی هغه دی چې د برخې هدف درته وایي.

همدا ځانګړتیا ده چې پېژندونکی د خصوصیت لپاره مهم کېدای شي. له هوسټ نوم یا د حساب نوم نه اخیستل شوی ارزښت د پیغام سره سفر کوي او کولای شي د هغه ماشین یا کس په اړه یو څه ښکاره کړي چې لېږلی یې دی. دا لا هم د VPN غونډه نه ده، او د هغې په توګه پرې کړه کول موندنه ضایع کوي.

لرې انځور یا دننه شوې برخه: جلا ترافیک

هغه img عنصر چې سرچینه یې https ده او هغه img عنصر چې سرچینه یې cid ده په HTML کې ورته ښکاري او په شبکه کې جلا چلند کوي. لومړی هغه سرچینه نوموي چې کلاینټ یې وروسته لدې چې پیغام پرانیستل شي راوړلای شي، او هغه راوړل لېږونکي ته وایي چې پیغام لوستل شوی او له کومې پتې. دویم د پیغام دننه د مخکې موجودې برخې پر وړاندې حل کېږي، نو ښودل یې له هیچا سره اړیکه نه لري.

یو پیغام کولای شي دواړه ګډ کړي، او د یوه کتل بل نه پاکوي. لرې حوالې له دننه شوو جلا وشمېرئ، او ولیکئ چې د کلاینټ ترتیبات څه اجازه ورکوي. د خصوصیت لپاره مهمه پرېکړه هماغه توپیر دی، نه د پېژندونکي دننه کلمه.

ثبوت پرته لدې چې پیغام ولېږئ شریک کړئ

کله چې بل څوک باید دا وګوري، لومړی تورپوش کړئ او په یو شان یې وکړئ. پتې او بې اړیکه سرلیکونه بدل کړئ، بیا Content-ID او د هغې cid: حواله په کاپي کې په یو شان لیکلې وساتئ، ځکه ناسمېدل یوازینی مهم ثبوت له منځه وړي. ووایاست چې سرلیک د کومې برخې و او کومه کرښه دې ته اشاره کړې وه. بیاکونکي ته اړیکه پکار ده، نه پیغام.

بیا دوه پایلې په لیکلي ډول جلا کړئ: پیغام څه لري، او څه ثبوت نه کوي. په دې ډول جوړ شوی ادعا کتل کېدای شي او پرې بحث کېدای شي، او ګټور راپور همدا ممکنوي.