مرجع فیلدهای هدر ایمیل: کدام‌ها را می‌توان جعل کرد؟

ایمیل مشکوکی به دستتان رسیده و می‌خواهید بفهمید واقعاً از کجا آمده. هدر را باز می‌کنید و با دیوار به‌هم‌ریخته‌ای از Received و Authentication-Results و Return-Path روبه‌رو می‌شوید که هیچ‌کدام با From نمی‌خواند. سؤال واقعی این است: کدام فیلد را می‌توان باور کرد و کدام را هر فرستنده‌ای می‌تواند به دلخواه بنویسد؟

پاسخ کوتاه: از دید پروتکل SMTP، تقریباً هیچ فیلدی در هدر «امضا» ندارد. هر چیزی که خودِ فرستنده اضافه می‌کند قابل جعل است. تنها چیزی که ارزش اثباتی دارد، زنجیره‌ی Received است که سرورهای میانی به آن اضافه می‌کنند، به‌علاوه‌ی نتیجه‌ی احراز هویتی که سرور دریافت‌کننده‌ی شما نوشته است.

هدر ایمیل از دو خانواده‌ی کاملاً متفاوت تشکیل شده

فیلدهای هدر در RFC 5322 تعریف شده‌اند، اما از نظر کاربرد عملی به دو دسته تقسیم می‌شوند که هیچ‌وقت نباید قاطی‌شان کنید.

• فیلدهای مسیر (trace fields): Received، Return-Path، Authentication-Results. این‌ها را سرورها می‌نویسند و ترتیب‌شان معنادار است.
• فیلدهای پیام (message fields): From، To، Subject، Reply-To، Date، Message-ID. این‌ها را فرستنده می‌نویسد و هیچ تضمینی ندارند.

اشتباه رایجی که هر هفته می‌بینم: کسی From: support@bank-x.ir را می‌بیند و نتیجه می‌گیرد ایمیل از بانک آمده. این فیلد فقط یک رشته‌ی متنی است. حتی Reply-To هم می‌تواند به دامنه‌ای کاملاً بی‌ربط اشاره کند و پاسخ شما مستقیم به مهاجم برود.

زنجیره‌ی Received را از پایین به بالا بخوانید

هر سروری که پیام را تحویل می‌گیرد، یک خط Received به بالای هدر اضافه می‌کند. یعنی آخرین خط (پایین‌ترین) مربوط به مبدأ است و اولین خط (بالاترین) مربوط به سرور خودتان. اگر از بالا به پایین بخوانید، مسیر را برعکس طی می‌کنید و گم می‌شوید.

Received: from mail.example.com (mail.example.com [203.0.113.45])
    by mx.servernet.cloud (Postfix) with ESMTPS id 4A2B1C3D
    for <you@yourdomain.ir>; Tue, 14 Jan 2025 09:12:44 +0330

سه چیز را در هر خط بررسی کنید: نام هاست اعلام‌شده، IP داخل کروشه، و نتیجه‌ی تطبیق آن دو. اگر نام هاست با IP نخواند، سرور دریافت‌کننده معمولاً unknown یا helo= خالی ثبت می‌کند. این تنها جایی است که می‌توانید ادعای فرستنده را با واقعیت شبکه مقایسه کنید.

نکته‌ای که خیلی‌ها از دست می‌دهند: خطوط Received که بالاتر از آخرین سرور مورد اعتماد شما هستند، کاملاً قابل جعل‌اند. مهاجم می‌تواند چند خط ساختگی به هدر اضافه کند تا مسیر را طولانی‌تر و بی‌گناه‌تر نشان دهد. مرز اعتماد دقیقاً همان خطی است که سرور خودتان نوشته.

Authentication-Results تنها فیلدی است که باید باور کنید

این هدر را سرور دریافت‌کننده اضافه می‌کند، نه فرستنده. اگر پیام از Gmail آمده باشد، خطی شبیه این می‌بینید:

Authentication-Results: mx.google.com;
    spf=pass smtp.mailfrom=example.com;
    dkim=pass header.i=@example.com;
    dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.com

سه مقدار مهم است و ترتیب اهمیت‌شان دقیقاً همین است: dmarc، بعد dkim، بعد spf. دلیلش ساده است. SPF فقط IP فرستنده را بررسی می‌کند و به محتوای پیام کاری ندارد؛ اگر مهاجم از سرور مجاز شما بفرستد، SPF پاس می‌شود. DKIM امضای رمزنگاری‌شده روی هدر و بدنه است، پس دست‌کاری محتوا را می‌گیرد. DMARC این دو را به دامنه‌ی نمایش‌داده‌شده در From گره می‌زند و همان چیزی است که جلوی جعل نام دامنه را می‌گیرد.

اگر dmarc=fail دیدید ولی spf=pass، یعنی کسی از زیرساخت مجاز شما استفاده کرده اما با دامنه‌ای دیگر. این الگوی کلاسیک forward شدن پیام است، نه لزوماً حمله. تفاوت را با header.from بسنجید.

این‌جا اشتباه می‌کنند

رایج‌ترین خطا: تکیه بر Return-Path برای تشخیص فرستنده‌ی واقعی. Return-Path همان MAIL FROM در پاکت SMTP است و کاملاً مستقل از From قابل تنظیم است. علامتش هم این است که در گزارش‌های اسپم می‌بینید Return-Path روی یک دامنه‌ی بی‌ربط است ولی From نام برند شما را نشان می‌دهد و کاربر فکر می‌کند ایمیل از شماست. Return-Path فقط برای bounce و گزارش DMARC کاربرد دارد، نه برای هویت.

خطای دوم که گران تمام می‌شود: خواندن هدر با کلاینت‌هایی که خطوط تاشده (folded) را درست باز نمی‌کنند. هدرهای بلند با فاصله یا tab به خط بعد شکسته می‌شوند. اگر ابزارتان این را نادیده بگیرد، امضای DKIM را ناقص می‌خواند و به نتیجه‌ی غلط می‌رسد.

کدام فیلدها را هرگز باور نکنید

یک استثنای مهم: Authentication-Results هم اگر بالاتر از مرز اعتماد شما باشد قابل جعل است. مهاجم می‌تواند خط dkim=pass ساختگی اضافه کند. همیشه بررسی کنید که این هدر توسط همان سروری نوشته شده که آخرین Received را ثبت کرده است.

برای بررسی عملی چه کاری انجام دهیم

هدر خام را از کلاینت بگیرید، نه از پیش‌نمایش. در Gmail از منوی سه‌نقطه گزینه‌ی «Show original» و در Thunderbird کلید Ctrl+U. سپس مسیر را از پایین به بالا دنبال کنید تا به اولین سروری برسید که خارج از کنترل شماست.

اگر می‌خواهید بفهمید دامنه‌ی فرستنده اصلاً زیرساخت ایمیل درستی دارد یا نه، اول رکوردهای MX آن را چک کنید؛ بررسی رکورد MX سریع‌ترین راه برای دیدن این است که پشت دامنه سرور واقعی هست یا فقط یک رکورد تشریفاتی. برای پیام‌هایی که به اسپم می‌روند و علتش را در هدر نمی‌بینید، راهنمای رفع مشکل اسپم الگوهای رایج را با مثال هدر توضیح داده است.

اگر خودتان سرور ایمیل دارید و می‌خواهید هدرهای خروجی‌تان تمیز باشد، راه‌اندازی ایمیل تراکنشی توضیح می‌دهد چرا ارسال انبوه از هاست اشتراکی به بن‌بست می‌خورد و چه جایگزینی درست است. برای سرورهایی که روی هاست لینوکس بالا می‌آیند، همین تنظیمات Postfix و OpenDKIM مستقیماً قابل اعمال است.

و اگر حجم پیام‌ها زیاد است و می‌خواهید تحلیل هدر را خودکار کنید، مستندات و پایگاه دانش نمونه‌های parse کردن هدر با ابزارهای خط فرمان را دارد.

پرسش‌های پرتکرار

آیا فیلد From در هدر ایمیل قابل جعل است؟

بله، به‌طور کامل. From فقط یک رشته‌ی متنی است که فرستنده در پیام می‌نویسد و SMTP هیچ مکانیزمی برای تأیید آن ندارد. تنها چیزی که جلوی این جعل را می‌گیرد، سیاست DMARC روی دامنه‌ی مقصد است. اگر دامنه‌ای DMARC با p=reject نداشته باشد، هر کسی می‌تواند با نام آن ایمیل بفرستد و سرور شما هم تحویلش می‌دهد.

تفاوت Return-Path و From چیست؟

Return-Path از دستور MAIL FROM در پاکت SMTP ساخته می‌شود و آدرس بازگشت bounceهاست. From چیزی است که کاربر در کلاینت می‌بیند. این دو می‌توانند به دو دامنه‌ی کاملاً متفاوت اشاره کنند و در ارسال‌های قانونی هم اغلب همین‌طور است. برای تشخیص هویت فرستنده، From را با نتیجه‌ی DMARC بسنجید، نه با Return-Path.

چرا هدر Received چندین بار تکرار شده است؟

هر سروری که پیام از آن عبور می‌کند یک خط Received به بالای هدر اضافه می‌کند. تعداد این خطوط برابر تعداد پرش‌های پیام است. اگر تعدادشان غیرعادی زیاد باشد یا زمان‌هایشان با هم نخواند، احتمال دست‌کاری وجود دارد. مرز اعتماد شما آخرین خطی است که سرور خودتان نوشته.

از کجا بفهمم ایمیل واقعاً از دامنه‌ی ادعاشده آمده؟

خط Authentication-Results را ببینید و مقدار dmarc را چک کنید. اگر dmarc=pass بود و header.from همان دامنه‌ای بود که انتظار دارید، پیام از زیرساخت مجاز آن دامنه آمده است. اگر dmarc=fail یا none بود، هیچ تضمینی وجود ندارد و باید با کانال دیگری صحت پیام را تأیید کنید.