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: حوالہ عام طور پر شناخت ان کے بغیر لکھتا ہے۔ ایسی قدریں جن میں ایسے حروف ہوں جنہیں escape کرنا ضروری ہے، انہیں انکوڈ کرنا پڑتا ہے، اسی لیے یہ جوڑا تبدیلی کا قاعدہ نہیں بلکہ مثال ہے۔ معنی دو رشتوں کے میل سے بنتا ہے، ان میں سے کسی ایک سے تنہا نہیں۔

@openvpn لاحقہ تعمیر کی ایک تفصیل ہے

Content-ID اس طرح بنایا جاتا ہے کہ ایک پیغام کے اندر منفرد رہے، اور میل سافٹ ویئر اس میں @ اور ایک ڈومین شامل کر کے اسے پتے جیسا بنا دیتا ہے۔ یہ شکل بنانے والے کی روایت ہے، راستہ نہیں: ہیڈر میں کچھ بھی کلائنٹ سے یہ نہیں کہتا کہ mailer.example سے رابطہ کرے، اور پیغام دکھاتے وقت کوئی تلاش نہیں ہوتی۔ یہ فیلڈ کسی اکاؤنٹ کا نام، VPN صارف، یا VPN کلائنٹ کا چھوڑا ہوا نشان بھی نہیں ہے۔ یہ رشته اسی نے چنا جس نے پیغام جوڑا اور حصے کو نام دیا۔

RFC 2392 cid اسکیم کی تعریف کرتا ہے اور اسے صرف پیغامات اور ان کے حصوں کے حوالے تک محدود کرتا ہے۔ اس دائرے کو لفظی طور پر پڑھیں تو لاحقہ نام دینے کے سوا کسی چیز کا ثبوت نہیں رہتا۔ اس کا مطلب یہ بھی ہے کہ لاحقے سے بنانے والے کی شناخت نہیں ہو سکتی، اور ہیڈر میں کوئی مانوس لفظ دکھنے پر لوگ یہی چھلانگ لگاتے ہیں۔

خام ماخذ دیکھیں، پھر رازداری کا سوال تولیں

خام ماخذ کھولیں اور پوری Content-ID قدر پڑھیں، کیونکہ RFC 2392 کسی قدر کو بھیجنے والے کا hostname یا اکاؤنٹ کے نام جیسی رشته رکھنے کی اجازت دیتا ہے۔ پھر ہر وہ جگہ تلاش کریں جہاں وہی نام آتا ہے: HTML میں cid: حوالہ، کوئی دوسرا ہیڈر، پچھلے جواب سے نقل کیا گیا بلاک۔ ان واقعات کے درمیان میل ہی آپ کو بتاتا ہے کہ اس حصے کا مقصد کیا ہے۔

یہی خصوصیت وجہ ہے کہ شناخت رازداری کے لیے اہم ہو سکتی ہے۔ hostname یا اکاؤنٹ کے نام سے ماخوذ قدر پیغام کے ساتھ سفر کرتی ہے اور اس مشین یا شخص کے بارے میں کچھ ظاہر کر سکتی ہے جس نے اسے بھیجا۔ یہ پھر بھی VPN سیشن نہیں ہے، اور اسے سیشن سمجھنا دریافت کو ضائع کر دیتا ہے۔

دور کی تصویر یا ایمبیڈڈ حصہ: مختلف ٹریفک

img عنصر جس کا ماخذ https ہے اور img عنصر جس کا ماخذ cid HTML میں ایک جیسے لگتے ہیں مگر نیٹ ورک پر مختلف برتاؤ کرتے ہیں۔ پہلا ایسے وسیلے کا نام بتاتا ہے جو کلائنٹ پیغام کھلنے پر لا سکتا ہے، اور یہ حصول بھیجنے والے کو بتاتا ہے کہ پیغام پڑھا گیا اور کس پتے سے۔ دوسرا پیغام کے اندر پہلے سے موجود حصے پر حل ہوتا ہے، اس لیے اسے دکھانا کسی سے رابطہ نہیں کرتا۔

ایک پیغام دونوں کو ملا سکتا ہے، اور ایک کی جانچ دوسرے کو صاف نہیں کرتی۔ دور کے حوالوں کو ایمبیڈڈ والوں سے الگ گنیں، اور دیکھیں کہ کلائنٹ کی ترتیبات کیا اجازت دیتی ہیں۔ رازداری کے لیے فیصلہ کن بات یہی فرق ہے، شناخت کے اندر کا لفظ نہیں۔

پیغام بھیجے بغیر ثبوت شیئر کریں

جب کسی اور کو یہ دیکھنا پڑے تو پہلے حذف کریں اور یکساں طور پر حذف کریں۔ پتے اور غیر متعلق ہیڈر بدلیں، پھر نقل میں Content-ID اور اس کا cid: حوالہ بالکل ویسا ہی ہجے کے ساتھ رکھیں، کیونکہ عدم مطابقت واحد اہم ثبوت کو تباہ کر دیتی ہے۔ بتائیں کہ ہیڈر کس حصے کا تھا اور کس سطر نے اس کا حوالہ دیا۔ جائزہ لینے والے کو رشتہ چاہیے، پیغام نہیں۔

پھر دو نتائج کو تحریری طور پر الگ کریں: پیغام میں کیا ہے، اور یہ کیا ثابت نہیں کرتا۔ اس طرح رکھا گیا دعویٰ جانچا اور چیلنج کیا جا سکتا ہے، اور مفید رپورٹ یہی اجازت دیتی ہے۔