اوسینت جت · شواهد ایمیل
تحلیل هدر ایمیل در اوسینت؛ مسیر ارسال و احراز دامنه را درست بخوانید
هدر ایمیل شناسنامه قطعی فرستنده نیست؛ گزارشی لایهلایه از ادعاهای پیام، نتیجههای احراز دامنه و مسیر عبور آن است. اگر این لایهها را قاطی نکنیم، از یک متن شلوغ به چند سرنخ محدود اما قابل دفاع میرسیم.
از نسخه اصلی شروع کنید، نه اسکرینشات
اسکرینشات شاید نام نمایشی و موضوع را نشان دهد، اما بیشتر داده لازم برای بررسی را حذف میکند. پیام اصلی را در صندوق نگه دارید، زمان و محل دریافت را یادداشت کنید و هدر کامل را بدون ویرایش بردارید. در جیمیل مسیر More → Show original نسخه خام را نشان میدهد. راهنمای رسمی گوگل برای سرویسهای دیگر هم مسیر دریافت هدر را توضیح داده است: مشاهده هدر کامل ایمیل.
هدر ممکن است آدرس گیرنده، نام میزبان داخلی، شناسه پیام و گاهی IP داشته باشد. یک نسخه دستنخورده نگه دارید و تحلیل را روی کپی انجام دهید. برای نمونه آموزشی، داده شخصی غیرضروری را حذف کنید؛ ولی نسخه پاکشده را جای مدرک اصلی نگذارید. در پرونده حساس هم هدر را بیفکر داخل سایتهای ناشناس تحلیلگر کپی نکنید.
قبل از نتیجهگیری، چهار هویت را از هم جدا کنید
استاندارد RFC 5322 ساختار فیلدهایی مثل From، Reply-To و Message-ID را تعریف میکند؛ اما ساختار استاندارد به معنی درستبودن همه ادعاها نیست.
| لایه | کجا را ببینیم؟ | چه چیزی میفهمیم؟ | چه چیزی ثابت نمیشود؟ |
|---|---|---|---|
| هویت نمایشی | From، نام نمایشی و موضوع | پیام میخواهد خواننده فرستنده را چه کسی بداند. | کنترلکننده واقعی حساب یا نویسنده متن. |
| هویت پاسخ و پاکت | Reply-To، Return-Path و mail-from | پاسخ و خطای تحویل کجا میرود و SPF کدام دامنه را سنجیده است. | این دامنهها متعلق به همان سازماناند. |
| هویت احرازشده | Authentication-Results، دامنه DKIM و نتیجه DMARC | گیرنده چه نتیجهای برای مجوز میزبان، امضا و همراستایی دامنه ثبت کرده است. | صداقت فرستنده یا مجازبودن یک درخواست مالی. |
| مسیر انتقال | فیلدهای Received و زمانها | رلههایی که سامانههای درگیر ثبت کردهاند و تأخیرهای احتمالی. | مکان دقیق انسان یا صحت خطوط پیش از نخستین رله قابل اعتماد. |
به جای نوشتن «دامنه فرستنده»، دقیق بگویید کدام دامنه: دامنه نمایشی، دامنه برگشت، دامنه امضاکننده یا دامنه پاسخ. همین تفاوتها گاهی مهمترین سرنخ پروندهاند.
SPF، DKIM و DMARC سه سؤال متفاوت دارند
SPF بررسی میکند آیا سامانه متصلشونده اجازه داشته از دامنهای در گفتوگوی SMTP استفاده کند. طبق RFC 7208، این نتیجه به تنهایی نام نمایشی یا هویت فرد را تأیید نمیکند.
DKIM امضای رمزنگاریشده بخشهایی از سربرگ و بدنه را میسنجد. دامنه امضاکننده در مقدار d= دیده میشود. pass یعنی امضای آن دامنه برای قسمتهای امضاشده معتبر بوده؛ نه اینکه همه فیلدها درستاند یا دقیقاً میدانیم چه کسی دکمه ارسال را زده است. مرجع پایه RFC 6376 است.
DMARC میسنجد آیا یک شناسه احرازشده SPF یا DKIM با دامنه موجود در From همراستا است و بعد سیاست اعلامشده مالک دامنه را لحاظ میکند. مشخصات فعلی IETF، RFC 9989، در مه ۲۰۲۶ منتشر شده است. pass مدرک خوبی برای همراستایی دامنه است؛ ولی اجازه تغییر شماره حساب یا پرداخت را ثابت نمیکند.
SPF: pass — mail-from domain: ______
DKIM: pass — signing domain d=: ______
DMARC: pass — visible From domain: ______
Alignment: SPF | DKIM | both | unclear
Reply-To domain: ______
Unresolved mismatch: ______مسیر رله را از مرز قابل اعتماد به عقب بخوانید
هر سامانه پستی معمولاً یک خط Received بالای خطوط قبلی اضافه میکند. پس مسیر ادعایی را معمولاً از پایین به بالا دنبال میکنیم، اما «قدیمیتر» الزاماً «معتبرتر» نیست. فرستنده میتواند پیش از رسیدن پیام به اولین سامانه مورد اعتماد شما خطوط جعلی بسازد.
- بالاترین خطی را پیدا کنید که سرویس گیرنده شما نوشته است.
- یک رله یک رله به پایین بروید و hostname، IP، روش انتقال و زمان را مقایسه کنید.
- همه زمانها را به یک منطقه زمانی تبدیل کنید.
- مرزی را مشخص کنید که بعد از آن مالک زیرساخت را مستقل نمیشناسید.
- دادههای پایینتر از آن مرز را ادعا بدانید و با منبع دوم بسنجید.
فوروارد عادی، سامانه تیکت، خبرنامه یا سرویس ابری میتواند رله ناآشنا بسازد یا همراستایی را تغییر دهد. مغایرت، سؤال تحقیق است؛ حکم کلاهبرداری نیست.
نمونه عملی: احراز موفق است، اما درخواست هنوز تأیید نشده
این مثال کاملاً ساختگی است. همه دامنهها از پسوند رزروشده .example و IP از محدوده مستندسازی TEST-NET استفاده میکنند؛ بنابراین به شخص یا شرکت واقعی اشاره ندارند.
From: "Cedar Accounts" <accounts@cedar-supply.example>
Reply-To: billing@cedar-payments.example
Return-Path: <bounce@mailer.cedar-supply.example>
Authentication-Results: mx.receiver.example;
spf=pass smtp.mailfrom=mailer.cedar-supply.example;
dkim=pass header.d=cedar-supply.example;
dmarc=pass header.from=cedar-supply.example
Received: from mailer.cedar-supply.example (192.0.2.44)
by mx.receiver.example with ESMTPSعبارت دقیق این است: «سامانه گیرنده SPF و DKIM را موفق ثبت کرده و DMARC با دامنه From همراستا است.» مشاهده جداگانه هم این است که پاسخها به دامنه دیگری میروند. اگر متن خواهان تغییر حساب بانکی باشد، احراز دامنه هنوز اختیار تجاری آن تغییر را ثابت نکرده است.
| مشاهده | برداشت محدود | آزمایش بعدی |
|---|---|---|
| DKIM برای دامنه نمایشی موفق است. | امضای همان دامنه در گیرنده اعتبارسنجی شده است. | پیام را با کانال شناختهشده قبلی مقایسه کنید. |
| Reply-To دامنه دیگری دارد. | پاسخ از دامنه نمایشی خارج میشود. | مالکیت یا استفاده رسمی از دامنه دوم را با منبع عمومی و کانال مستقل بررسی کنید. |
| درخواست اثر مالی دارد. | هزینه اشتباه بالاست. | با شماره یا کانال از قبل معتبر تأیید کنید؛ به همان ایمیل پاسخ ندهید. |
نتیجه درست «واقعی است» یا «جعلی است» نیست. نتیجه قابل دفاع این است: «احراز فنی از کاربرد دامنه نمایشی پشتیبانی میکند، اما دامنه متفاوت پاسخ و اختیار تغییر مالی هنوز حل نشده است.»
هدر را به یافتهای قابل بازبینی تبدیل کنید
پیام، هدر، صفحات دامنه و تأیید مستقل را چهار مدرک جدا نگه دارید. برای هر کدام منبع، زمان برداشت، مشاهده دقیق و فرضیهای را که میآزمایید بنویسید. گزارش خوب خواننده را مجبور نمیکند یک بلوک هدر خام را از نو تحلیل کند.
وقتی پرونده شامل وبسایت، شرکت، شماره یا فاکتور قبلی است، اوسینت جت کمک میکند سرنخهای ورودی و یافتههای منابع عمومی در یک تحقیق قابل بازبینی کنار هم بمانند. ارزش اصلی در نظم شواهد است: دامنه احرازشده، تناقض Reply-To و مسیر تماس مستقل گم نمیشوند. این نظم، pass فنی را به اثبات هویت یک انسان تبدیل نمیکند.
برای ادامه، راهنمای اوسینت ایمیل، چکلیست تحقیق اوسینت و قالب گزارش تحقیق را ببینید.
پرسشهای رایج
SPF موفق یعنی From حتماً واقعی است؟
خیر. SPF مجوز میزبان و یک هویت SMTP را میسنجد. دامنه سنجیدهشده را بنویسید و همراستایی آن با From را جدا بررسی کنید.
DKIM موفق یعنی هیچچیز در ایمیل عوض نشده؟
فقط برای بدنه و فیلدهایی که امضای معتبر پوشش میدهد چنین پشتیبانیای ایجاد میکند. دامنه امضا و فهرست فیلدهای امضاشده را ببینید.
از هدر میشود مکان دقیق فرستنده را فهمید؟
اغلب نه. IP ممکن است برای سرویس ایمیل، درگاه یا رله باشد. بدون شناخت نقطه ثبت و رفتار سرویس، آن را مکان یک شخص ندانید.
هدر مشکوک را داخل ابزار آنلاین بگذارم؟
اول دادههای داخل آن و شرایط سرویس را بسنجید. در پرونده حساس، تحلیل محلی یا ابزار سازمانی مورد اعتماد بهتر است و فقط بخش ضروری باید به اشتراک گذاشته شود.
انتشار از اوسینت جت · انتشار نخست: ۲۹ سپتامبر ۲۰۲۶
ادامه مسیر اوسینت
سرنخهای خام را به یک تحقیق ساختارمند در اوسینت جت تبدیل کنید
برای نتیجه بهتر، فقط به یک سرنخ اکتفا نکنید. شماره تلفن، ایمیل، یوزرنیم، دامنه، نام شرکت، تصویر، شهر، لینک شبکه اجتماعی و توضیح زمینه پرونده را کنار هم قرار دهید تا موتور اطلاعاتی اوسینت جت تحلیل دقیقتری بسازد.