VPN کے ذریعے بھیجی گئی ای میل: جواب دراصل کہاں جاتا ہے

آپ سرنگ کے ذریعے پیغام بھیجتے ہیں، رابطہ منقطع کرتے ہیں اور اگلی صبح جواب آ جاتا ہے۔ اِس میں کچھ بھی پرانے VPN پتے کا محتاج نہیں، اور کچھ بھی خراب نہیں ہوتا۔ ای میل جوابات کو اُس پتے پر نہیں بھیجتی جہاں سے پیغام بھیجا گیا تھا؛ وہ اُنہیں میل باکس میں بھیجتی ہے۔ یہاں تین راستے ایک ہی سوال میں سمٹ جاتے ہیں، اور اُنہیں الگ کرنا بیشتر بے چینی کا جواب دیتا ہے۔

تین راستے جنہیں لوگ ایک میں سمو دیتے ہیں

جمع کرنا، ترسیل اور پڑھنا تین الگ رابطے ہیں، اور اِن میں سے صرف دو آپ کے آلے کو شامل کرتے ہیں۔

Submission: your mail app  -> your mail service
Delivery:   other mail service -> your mailbox service
Reading:    your app now -> your mailbox service

VPN پہلے اور تیسرے پر اثر ڈال سکتا ہے، کیونکہ یہ وہ رابطے ہیں جو آپ کا آلہ بناتا ہے۔ یہ دوسرے پر اثر نہیں ڈال سکتا، کیونکہ وہ راستہ اُن دو میل سروروں کے درمیان جاتا ہے جنہیں آپ کنٹرول نہیں کرتے۔ جواب کوئی پیکٹ نہیں جو اُس پتے پر واپس آئے جہاں سے آپ نے بھیجا تھا۔ یہ ایک نیا پیغام ہے جو دوسری طرف کی میل سروس آپ کی میل باکس سروس تک پہنچاتی ہے۔

جب آپ اِن تینوں کو الگ رکھتے ہیں تو یہ سوال کہ جواب آپ کو ملے گا یا نہیں، پراسرار نہیں رہتا۔

Reply-To فیلڈ ایک پتہ ہے، راستہ نہیں

RFC 5322 Reply-To کو اُس میل باکس یا میل باکسز کے طور پر بیان کرتا ہے جنہیں جوابات بھیجے جائیں۔ اِس کے بغیر معمول کا طے شدہ From باکس ہوتا ہے، الا یہ کہ جواب دینے والا کچھ اور لکھے۔ دونوں ہیڈر میں بیٹھے میل پتے ہیں۔ کوئی بھی اُس نیٹ ورک رابطے کو دوبارہ کھولنے کی ہدایت نہیں جو اصل پیغام جمع کرتا تھا۔

یہی وجہ ہے کہ VPN کا خارجی پتہ جواب کے راستے میں کبھی ظاہر نہیں ہوتا۔ اگرچہ جمع کرنے والے سرور نے وہ خارجی پتہ کہیں درج کیا ہو، جواب کسی میل باکس کو لکھا جاتا ہے، اور بھیجنے والا سرور آپ کے پرانے ساکٹ کی بجائے ڈومین کے میل تبادلہ گر کو تلاش کرتا ہے۔

اگر جواب کہیں غیر متوقع جگہ جائے تو سرنگ پر شک کرنے سے پہلے Reply-To اور بھیجنے والے کی اپنی کلائنٹ ترتیبات پڑھیں۔

ٹریس ہیڈر دراصل کیا درج کرتے ہیں

ہر SMTP چھلانگ آگے ایک Received ہیڈر لگاتی ہے جو اُس رابطے کی وضاحت کرتا ہے جسے اُس نے سنبھالا، اور سب سے اوپر والا ترسیل سے پہلے آخری چھلانگ ہے۔ اِس لیے جمع کیا گیا پیغام ایسی نیٹ ورک تفصیلات رکھ سکتا ہے جو جائزے کے قابل ہوں، اور یہ تفصیلات سرور لکھتے ہیں، آپ منتخب نہیں کرتے۔ اِن میں کیا ہوگا یہ فراہم کنندہ کی جمع کرنے کی ساخت اور ہیڈرز سے اُس کے برتاؤ پر منحصر ہے۔

اندازہ لگانے کی بجائے محفوظ پیغام سے اِنہیں پڑھیں:

grep -E '^(Received|Return-Path|Reply-To|From):' message.eml

مفید ضابطہ یہ ہے کہ پہچانیں کون سی قابلِ اعتماد سروس نے ہر فیلڈ شامل کی۔ ہیڈر بلاک میں پہلے کا من مانی متن قابلِ اعتماد ثبوت نہیں، اور کسی مصنوع کا نام یہ دائمی وعدہ نہیں کہ آپ کا گھر کا پتہ ہمیشہ موجود ہے یا ہمیشہ غیر موجود۔

بعد میں میل پڑھنا ایک نیا رابطہ ہے

جب آپ جواب کھولتے ہیں تو آپ کا کلائنٹ اب جس نیٹ ورک پر ہے اُس کے ذریعے آپ کی میل باکس سروس سے جڑتا ہے۔ یہ اپنے ماخذ پتے والا تازہ رابطہ ہے، کل کے جمع کرنے والے ساکٹ کا تسلسل نہیں۔ یہ اُس نیٹ ورک کی موجودہ پالیسی کی پیروی کرتا ہے جو آپ اُس لمحے استعمال کر رہے ہیں۔

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

اگر آپ پیغام کھولنے کا اعلان کیے بغیر پڑھنا چاہتے ہیں تو دور کا مواد بند کر دیں۔

اِسے رساؤ کہنے سے پہلے کیا جانچیں

اصل پیغام کے منظر اور Reply-To فیلڈ سے شروع کریں۔ پھر پہچانیں کہ آپ کو بے چین کرنے والی Received اندراجات کس سروس نے شامل کیں، اور اِسے پرانے فورم کے جواب کی بجائے فراہم کنندہ کی موجودہ دستاویزات سے موازنہ کریں۔

آخر میں، سوالات الگ کریں: جمع کرنے والے سرور نے کیا دیکھا، ترسیل کی زنجیر نے کیا شامل کیا، اور جب آپ نے پیغام کھولا تو آپ کے کلائنٹ نے کیا مانگا؟

اِن تینوں کا الگ الگ جواب دینا IP صفحہ جانچنے سے زیادہ کام ہے، اور یہی واحد صورت ہے جو ایسا نتیجہ دیتی ہے جس کا آپ دفاع کر سکیں۔ ای میل پتے کو جواب دینے سے آپ کا گھر کا پتہ ظاہر نہیں ہوتا، اور اِس کے لیے پرانی سرنگ کا کھلا رہنا ضروری نہیں۔