VPN ఐడెంటిఫైయర్‌లా కనిపించే 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 ఒక విలువ పంపినవారి hostname లేదా ఖాతా పేరు లాంటి స్ట్రింగ్‌ను మోయడానికి అనుమతిస్తుంది. తర్వాత అదే పేరు కనిపించే ప్రతి చోటును కనుగొనండి: HTMLలో cid: సూచన, మరో హెడర్, మునుపటి ప్రత్యుత్తరం నుండి ఉదహరించిన బ్లాక్. ఆ సంభవాల మధ్య సరిపోలికే భాగం ఉద్దేశాన్ని మీకు చెబుతుంది.

అదే లక్షణం వల్లే ఐడెంటిఫైయర్ గోప్యతకు ముఖ్యమైనది కావచ్చు. hostname లేదా ఖాతా పేరు నుండి తీసుకున్న విలువ సందేశంతో ప్రయాణించి, దాన్ని పంపిన యంత్రం లేదా వ్యక్తి గురించి ఏదో వెల్లడించగలదు. అది ఇంకా VPN సెషన్ కాదు, దాన్ని సెషన్‌గా భావించడం ఆ ఆవిష్కరణను వృథా చేస్తుంది.

రిమోట్ చిత్రం లేదా పొందుపరిచిన భాగం: వేరే ట్రాఫిక్

మూలంగా https ఉన్న img మూలకం, మూలంగా cid ఉన్న img మూలకం HTMLలో ఒకేలా కనిపిస్తాయి, కానీ నెట్‌వర్క్‌లో భిన్నంగా ప్రవర్తిస్తాయి. మొదటిది సందేశం తెరిచాక క్లయింట్ పొందగల వనరును పేర్కొంటుంది, ఆ పొందిక సందేశం చదవబడిందని, ఏ చిరునామా నుండి అని పంపినవారికి చెబుతుంది. రెండవది ఇప్పటికే సందేశంలో ఉన్న భాగానికి తీరుతుంది, కాబట్టి దాన్ని ప్రదర్శించడం ఎవరినీ సంప్రదించదు.

ఒకే సందేశం రెండింటినీ కలపగలదు, ఒకదాన్ని తనిఖీ చేయడం మరొకదాన్ని తొలగించదు. రిమోట్ సూచనలను పొందుపరిచిన వాటి నుండి విడిగా లెక్కించండి, క్లయింట్ సెట్టింగ్‌లు ఏమి అనుమతిస్తాయో గమనించండి. గోప్యతకు ముఖ్యమైన నిర్ణయం ఆ భేదమే, ఐడెంటిఫైయర్‌లోని పదం కాదు.

సందేశాన్ని పంపకుండా సాక్ష్యాన్ని పంచుకోండి

మరొకరు దీన్ని చూడాల్సి వచ్చినప్పుడు, మొదట దాచండి, స్థిరంగా దాచండి. చిరునామాలు, సంబంధం లేని హెడర్‌లను భర్తీ చేయండి, తర్వాత కాపీలో Content-IDని, దాని cid: సూచనను ఒకేలా అక్షరక్రమంతో ఉంచండి, ఎందుకంటే సరిపోలకపోవడం ముఖ్యమైన ఏకైక సాక్ష్యాన్ని నాశనం చేస్తుంది. హెడర్ ఏ భాగానికి చెందింది, ఏ పంక్తి దాన్ని సూచించిందో చెప్పండి. సమీక్షకుడికి కావాల్సింది సంబంధం, సందేశం కాదు.

తర్వాత రెండు ముగింపులను వ్రాతపూర్వకంగా వేరు చేయండి: సందేశంలో ఏమి ఉంది, అది ఏమి నిరూపించదు. అలా రూపొందించిన వాదనను తనిఖీ చేయవచ్చు, దానితో వాదించవచ్చు; ఉపయోగకరమైన నివేదిక అనుమతించేది అదే.