جعلی ای میل کا header پڑھیں—نام نہیں، اصل راستہ بھی دیکھیں

مشکوک ای میل میں بھیجنے والے کا نام دیکھ کر فیصلہ نہ کریں۔ Gmail میں مکمل ہیڈر کھولیں اور From کے پتے کو Return-Path، Received اور Authentication-Results میں درج ڈومینوں سے ملائیں۔ خاص طور پر دیکھیں کہ SPF یا DKIM کی کامیاب تصدیق اسی ڈومین سے متعلق ہے جس کا دعویٰ From میں کیا گیا ہے۔

مکمل ہیڈر دیکھنے کے لیے Gmail میں پیغام کھولنا ہوتا ہے؛ اس کے اندر موجود لنک کھولنے، منسلکہ چلانے یا جواب دینے کی ضرورت نہیں۔ ہیڈر ترسیل اور ڈومین کی تصدیق کے اشارے دیتا ہے، لیکن کسی شخص کی شناخت یا پیغام میں کیے گئے مطالبے کی سچائی کا حتمی ثبوت نہیں بنتا۔

Gmail سے مکمل ہیڈر نکالیں

کمپیوٹر کے براؤزر میں Gmail کھولیں۔ Gmail کی ہدایت کے مطابق پیغام کے جواب والے تیر کے قریب مزید اختیارات کا مینو کھولنے سے Show original دستیاب ہوتا ہے؛ مکمل ہیڈر نئی ونڈو میں ظاہر ہوتا ہے۔ اگر ایک ہی گفتگو میں کئی پیغامات ہیں تو مینو اسی مشکوک پیغام کا کھولیں جسے جانچنا ہے۔

1. مشکوک پیغام کھولیں، مگر اس کے بٹن، لنک اور منسلک فائل کو نہ چھیڑیں۔
2. جواب والے تیر کے قریب تین نقطوں سے Show original منتخب کریں۔ نئی ونڈو میں نظر آنے والے مکمل ہیڈر کو Copy to clipboard سے نقل کیا جا سکتا ہے۔
3. نقل شدہ متن میں From، Return-Path، Received اور Authentication-Results تلاش کریں۔ ہر قدر کو پورے ای میل پتے یا ڈومین کے ساتھ پڑھیں؛ صرف نام یا pass کا لفظ الگ سے کافی نہیں۔

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

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

From میں دکھائی دینے والا نام اور اس کے ساتھ ای میل پتہ دو الگ چیزیں ہیں۔ مثال کے طور پر نام کسی ادارے کا تاثر دے سکتا ہے، جبکہ پتے میں @ کے بعد لکھا ڈومین کسی دوسری جگہ کا ہو۔ Reply-To بھی موجود ہو تو اسے پڑھیں: جواب کا مختلف پتے پر جانا توجہ طلب ہے، اگرچہ بعض جائز پیغامات میں جواب کے لیے الگ پتہ رکھا جاتا ہے۔

SMTP کا معیار RFC 5321 بتاتا ہے کہ ترسیلی سرور اپنی Received سطر موجودہ سطروں کے اوپر شامل کرتا ہے، جبکہ Return-Path وہ پتہ محفوظ کرتا ہے جہاں ترسیل ناکام ہونے کی اطلاع بھیجی جا سکتی ہے۔ اس لیے Received کی اوپری سطر عموماً وصولی کے حالیہ مرحلے کو دکھاتی ہے؛ نیچے کی سطروں سے پہلے کے مراحل دیکھے جاتے ہیں۔ ایک سطر میں from کے بعد پیغام دینے والے میزبان اور by کے بعد وصول کرنے والے سرور کا نام آ سکتا ہے۔

Return-Path کا From سے مختلف ہونا بذاتِ خود جعل سازی ثابت نہیں کرتا۔ ای میل بھیجنے والی خدمات اور میلنگ فہرستیں ترسیلی خرابیوں کے لیے الگ پتہ استعمال کر سکتی ہیں۔ اسی طرح Received میں متعدد سرور نظر آنا معمول کے راستے کا حصہ ہو سکتا ہے۔ مفید سوال یہ ہے کہ ظاہر کیے گئے بھیجنے والے، استعمال ہونے والے ترسیلی ڈومین اور پیغام کے متوقع سیاق میں کوئی واضح تضاد ہے یا نہیں۔

SPF، DKIM اور DMARC میں کیا ملائیں

Authentication-Results میں spf=pass اس ڈومین کے لیے بھیجنے والے سرور کی اجازت کی جانچ کا نتیجہ ہے جو smtp.mailfrom کے ساتھ درج ہوتا ہے۔ dkim=pass کا تعلق دستخط کی کامیاب تصدیق سے ہے؛ اس کا ڈومین عموماً header.d کے ساتھ نظر آتا ہے۔ دونوں نتائج پڑھتے وقت متعلقہ ڈومین ضرور دیکھیں۔ کسی دوسرے ڈومین کا pass، From میں دکھائے گئے ڈومین کی تصدیق نہیں کرتا۔

Google کی بھیجنے والوں کے لیے ہدایت کے مطابق DMARC میں From کے ڈومین کا SPF یا DKIM سے تصدیق پانے والے ڈومین کے ساتھ میل ہونا ضروری ہے۔ اس میل کو الائنمنٹ کہتے ہیں؛ متعلقہ ذیلی ڈومین بعض صورتوں میں قابلِ قبول ہو سکتا ہے، اس لیے ہر حرف کا مختلف ہونا لازماً ناکامی نہیں۔ dmarc=fail دکھائی دے تو اسے دوسرے نتائج اور پیغام کے دعوے کے ساتھ ملا کر پڑھیں۔

یہ نتائج ڈومین اور ترسیل کے طریقے کے بارے میں ہیں، پیغام کے متن میں دیے گئے وعدے یا لنک کے بارے میں نہیں۔ درست تصدیق کے ساتھ بھی کوئی پیغام غیر متوقع طور پر پاس ورڈ، ادائیگی یا ذاتی معلومات مانگ سکتا ہے۔ دوسری طرف، آگے بھیجی گئی یا میلنگ فہرست سے گزری جائز ای میل میں تصدیق متاثر ہو سکتی ہے۔ اس لیے pass کو اجازت نامہ اور fail کو اکیلا فیصلہ سمجھنے کے بجائے ڈومین، درخواست اور متوقع بھیجنے والے کو ایک ساتھ دیکھیں۔

فرضی ہیڈر کو سطر بہ سطر پڑھیں

یہ بے ضرر فرضی مثال ہے؛ example.org اور example.net کسی حقیقی پیغام یا ادارے کا دعویٰ نہیں کرتے۔ فرض کریں کسی ای میل کے مکمل ہیڈر میں درج ذیل سطریں دکھائی دیں۔ اصل پیغام میں ہر سطر کے ساتھ مزید تکنیکی معلومات ہو سکتی ہیں، اس لیے یہ صرف متعلقہ حصوں کو سمجھانے کے لیے مختصر کی گئی ہیں۔

• From: Accounts <[email protected]> — دکھائی دینے والا نام Accounts ہے، مگر پتے کا ڈومین example.org ہے۔ دعویٰ جانچنے کے لیے نام کے بجائے اس ڈومین کو بنیاد بنائیں۔
• Return-Path: <[email protected]> — ترسیل کی خرابی کا پتہ mailer.example.net پر ہے۔ یہ From کے ڈومین سے مختلف ہے، مگر صرف یہی فرق نتیجہ نکالنے کے لیے کافی نہیں۔
• Received: from mailer.example.net by mx.google.com — اس فرضی سطر میں mailer.example.net وہ میزبان ہے جس سے درج وصول کنندہ سرور کو پیغام ملا۔ یہ ایک مرحلے کا ریکارڈ ہے، پوری ترسیل کی کہانی نہیں۔
• Authentication-Results: spf=pass smtp.mailfrom=mailer.example.net؛ dkim=pass header.d=mailer.example.net؛ dmarc=fail header.from=example.org — کامیاب SPF اور DKIM نتائج example.net کی جانب اشارہ کرتے ہیں، جبکہ From میں example.org ہے۔

یہاں اصل اشارہ pass اور fail کا سادہ تقابل نہیں، بلکہ ان کے ساتھ درج ڈومین ہیں۔ فرضی پیغام میں دونوں کامیاب تصدیقیں mailer.example.net سے متعلق ہیں اور From کا ڈومین example.org ہے؛ dmarc=fail اسی عدم مطابقت کے مطابق ہے۔ اگر کسی حقیقی پیغام میں صرف SPF مختلف ہو لیکن DKIM، From کے ڈومین سے میل کھاتا ہو تو DMARC کا نتیجہ مختلف ہو سکتا ہے۔ اس لیے تمام متعلقہ قدروں کو ایک ہی سطر کے خلاصے میں گم نہ کریں۔

رپورٹ یا حذف کرنے سے پہلے ثبوت محفوظ کریں

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

• اصل ای میل برقرار رکھیں۔ گفتگو میں کئی پیغامات ہوں تو واضح کریں کہ کون سا پیغام مشکوک ہے۔
• مکمل ہیڈر کی نقل محفوظ کریں، خصوصاً From، موجود ہو تو Reply-To، Return-Path، Received اور Authentication-Results کی پوری سطریں۔ نقل کسی غیر متعلقہ عوامی جگہ پر شائع نہ کریں؛ اس میں پتے اور ترسیلی معلومات ہو سکتی ہیں۔
• مختصر لکھ لیں کہ شک کس بات سے پیدا ہوا: نام اور ڈومین کا فرق، غیر متوقع درخواست یا تصدیق کا نتیجہ۔ ثبوت جمع کرنے کے لیے مشکوک لنک کھولنے یا منسلکہ چلانے کی ضرورت نہیں۔
• دفتری اکاؤنٹ ہو تو محفوظ شدہ معلومات مقررہ حفاظتی ٹیم تک ادارے کے طریقے سے پہنچائیں۔ ذاتی Gmail میں پیغام کے مینو سے Report phishing منتخب کیا جا سکتا ہے؛ ثبوت کی ضرورت ہو تو حذف کرنے سے پہلے اسے محفوظ کر لیں۔

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

یہ بھی پڑھیں:

• جعلی software download اصل نام سے ملا—installer نے دفاع بھی کمزور کردیا
• پاکستان میں remote employee یا contractor؟ کم ٹیکس اکیلا فیصلہ نہیں
• Mutual fund factsheet پڑھیں—زیادہ return سے پہلے فیس اور خطرہ دیکھیں