Email Trace چیست؟

Email Trace یا ردیابی ایمیل یعنی خواندن هدرهای یک پیام و لاگ سرور میل، تا بفهمید پیام از چه مسیری آمده، از کدام سرورها عبور کرده و دقیقاً در کدام مرحله رد شده یا معطل مانده است. در پنل‌های میزبانی هم ابزاری با همین نام (یا «Track Delivery») وجود دارد که همین کار را برای ایمیل‌های خروجی سرور شما انجام می‌دهد و علت شکست تحویل را نشان می‌دهد.

هدر ایمیل چه چیزی را نگه می‌دارد؟

متن ایمیل چیزی است که کاربر می‌بیند، اما تصمیم‌های واقعی سر و کارشان با هدر است؛ فیلترهایی مانند SpamAssassin هم امتیاز خود را در همین هدرها می‌نویسند. هدر شامل مسیر عبور پیام، شناسه یکتای آن، نتیجه بررسی‌های احراز هویت دامنه و نشانه‌هایی است که فیلترهای اسپم اضافه می‌کنند. برای دیدن هدر کامل، در Gmail از منوی پیام گزینه Show original، در Outlook Web گزینه View message details، در Roundcube گزینه View source و در Thunderbird کلید Ctrl+U (روی مک Cmd+U) را بزنید. اگر سایت و صندوق‌های ایمیل شما روی یک هاست اشتراکی قرار دارد، همین هدر خام تقریباً تنها چیزی است که برای شروع عیب‌یابی لازم دارید.

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

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

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

Message-ID و Return-Path

فیلد Message-ID شناسه یکتای پیام است و بهترین کلید برای جست‌وجو در لاگ سرور. هر وقت کاربری می‌گوید «ایمیلم نرسید»، اولین چیزی که باید از او بخواهید همین مقدار است.

فیلد From چیزی است که کاربر می‌بیند، اما Return-Path (همان Envelope Sender) آدرسی است که بازگشتی‌ها و خطاها به آن ارسال می‌شود و بررسی‌های احراز هویت هم روی آن انجام می‌گیرد. ناهماهنگی این دو، یکی از دلایل رایج افتادن ایمیل در پوشه اسپم است.

نتیجه SPF، DKIM و DMARC را کجا ببینیم

سرور گیرنده نتیجه بررسی‌ها را در فیلد Authentication-Results می‌نویسد؛ روش ساخت این رکوردها روی هاست در فعال‌سازی SPF و DKIM در سی پنل آمده است؛ چیزی شبیه spf=pass، dkim=pass و dmarc=pass. معنای ساده‌شان این است:

• SPF بررسی می‌کند IP سرور فرستنده در رکورد TXT دامنه مجاز شمرده شده باشد.
• DKIM امضای رمزنگاری‌شده پیام را با کلید عمومی منتشرشده روی سلکتور دامنه می‌سنجد؛ اگر متن پیام در مسیر تغییر کند، امضا می‌شکند.
• DMARC تعیین می‌کند اگر SPF یا DKIM رد شد و دامنه‌ها هم‌راستا نبودند، گیرنده چه کند.

هر سه مورد SPF، DKIM و DMARC رکورد TXT هستند و روی همان جایی مدیریت می‌شوند که DNS دامنه‌تان را نگه می‌دارد؛ اگر این بخش را از هاست جدا کرده باشید، سرویس هاست DNS افزودن و ویرایش و حذف رکوردهای TXT را از ناحیه کاربری و جدا از سرور وب در اختیارتان می‌گذارد.

برای بررسی مستقیم رکوردها از dig استفاده کنید:

• dig TXT example.com +short برای دیدن رکورد SPF
• dig TXT _dmarc.example.com +short برای سیاست DMARC
• dig TXT mail._domainkey.example.com +short برای کلید DKIM (نام سلکتور بسته به سرویس فرق می‌کند)
• dig -x 203.0.113.10 +short برای بررسی رکورد PTR یا همان Reverse DNS

ابزار Email Trace در پنل میزبانی

در cPanel این ابزار امروز با نام Track Delivery در بخش Email در دسترس است (در نسخه‌های قدیمی‌تر Email Trace نامیده می‌شد). کافی است آدرس گیرنده یا فرستنده را وارد کنید تا فهرست تلاش‌های تحویل، وضعیت هر کدام و پیام خطای بازگشتی از سرور مقصد را ببینید. همین یک صفحه معمولاً جواب می‌دهد که پیام اصلاً از سرور خارج شده یا نه. سرویس هاست لینوکس ایران هم با کنترل‌پنل cPanel ارائه می‌شود، پس همین بخش Email را در ناحیه مدیریت هاست خواهید داشت. در DirectAdmin هم بخش گزارش‌های ایمیل نقش مشابهی دارد.

وقتی پنل کافی نیست: لاگ سرور میل

روی سرورهای اختصاصی و مجازی می‌توانید مستقیم سراغ لاگ بروید. مسیر لاگ به نرم‌افزار و پنل بستگی دارد: روی cPanel معمولاً /var/log/exim_mainlog، روی نصب‌های دیگر Exim مسیر /var/log/exim/mainlog و در Postfix معمولاً /var/log/maillog یا /var/log/mail.log.

نشانه‌های ابتدای هر خط در Exim را این‌طور بخوانید:

برای دنبال کردن سرگذشت یک پیام مشخص با شناسه صف، از exigrep '1r5xYz-0001aB-2C' /var/log/exim_mainlog استفاده کنید. برای دیدن حجم صف exim -bpc و برای فهرست کامل صف exim -bp کار را راه می‌اندازد. اگر شناسه صف را ندارید، جست‌وجوی ساده روی آدرس گیرنده هم کافی است: grep 'user@example.com' /var/log/exim_mainlog.

هشدار: دستور exim -Mrm پیام‌ها را بدون امکان بازیابی از صف حذف می‌کند و هیچ اعلانی هم برای فرستنده صادر نمی‌شود. قبل از پاک‌سازی صف، حتماً خروجی exim -bp را ذخیره کنید و مطمئن شوید پیام‌های سالم را همراه اسپم حذف نمی‌کنید.

خطاهای پرتکرار و معنی آن‌ها

کدهای پاسخ SMTP که در لاگ یا در بازگشتی می‌بینید، دو دسته‌اند. کدهای 4xx موقتی‌اند و سرور دوباره تلاش می‌کند؛ رایج‌ترین علتشان Greylisting یا محدودیت نرخ ارسال در سمت گیرنده است. اگر پیام رد شده به فهرست سیاه اشاره داشت، RBL چیست را بخوانید. کدهای 5xx دائمی‌اند: آدرس گیرنده وجود ندارد، دامنه یا IP شما در فهرست سیاه است، رکورد PTR تنظیم نشده، یا سیاست DMARC دامنه فرستنده پیام را رد کرده است. متن دقیق پیام خطا بین سرورهای گیرنده متفاوت است، پس همیشه عین همان متن را بخوانید و به کد اکتفا نکنید.

یک روال کوتاه برای عیب‌یابی

ابتدا هدر خام پیام را بگیرید و Message-ID و Return-Path را بردارید. سپس Authentication-Results را ببینید تا مشخص شود مشکل احراز هویت است یا مسیر. بعد زنجیره Received را از پایین به بالا بخوانید تا آخرین سرور سالم را پیدا کنید. در نهایت با ابزار پنل یا لاگ سرور، همان پیام را دنبال کنید. اگر بعد از این مراحل هم علت روشن نشد یا مشکل به تنظیمات سطح سرور و اعتبار IP برمی‌گردد، بهتر است از پشتیبانی و مدیریت سرور کمک بگیرید تا بررسی روی خود سرور انجام شود.