ایمیل چگونه کار می کند

وقتی دکمه ارسال را می زنید، نامه از کجاها رد می شود؟

پنج ایستگاه، و هیچ کدامشان اتصال مستقیم بین شما و گیرنده نیست. اول برنامه ای که با آن می نویسید، چه وبمیل باشد چه یک اپ روی گوشی، نامه را به سرور پست خودتان تحویل می دهد. این تحویل با پروتکلی به نام SMTP انجام می شود و همین پروتکل بعدا بین سرورها هم به کار می رود؛ خواندن نامه کار دیگری است و با IMAP یا POP انجام می شود، که خیلی ها این دو را با هم اشتباه می گیرند.

ایستگاه دوم جالب ترینشان است. سرور فرستنده نمی داند نامه های example.ir کجا باید تحویل داده شوند، پس از DNS می پرسد و رکوردی به نام MX را می خواند. آن رکورد اسم سرور پست آن دامنه را می گوید. دامنه ما این را دارد: 10 mail.rgb.ir، یعنی نامه های rgb.ir به ماشینی به این نام تحویل داده می شوند.

و دامنه ای که اصلا نامه قبول نمی کند این را صریح اعلام می کند. example.com یک رکورد MX خالی منتشر کرده، چیزی که RFC 7505 اسمش را null MX گذاشته، و معنی اش این است که تلاش نکنید. در لاگ سرور خودمان همین را می بینید: نامه ای به یک نشانی روی آن دامنه، بدون هیچ تلاشی برای اتصال، همان جا برگشت خورد با دلیل Domain example.com does not accept mail (nullMX).

ایستگاه سوم و چهارم اتصال به آن سرور و تحویل نامه است. ایستگاه پنجم تصمیم سرور گیرنده است، و بقیه این درس درباره همین یک تصمیم است.

فرق «به اسپم رفت» با «اصلا نرسید» چیست؟

این دو یک اتفاق نیستند و علاجشان هم یکی نیست. نامه ای که به اسپم رفته، قبول شده است؛ سرور گیرنده آن را گرفته و بعد تصمیم گرفته کجا بگذاردش. نامه ای که رد شده اصلا قبول نشده و شما یک نامه برگشتی می گیرید که علتش را می گوید. حالت سومی هم هست که بیشتر مردم نمی شناسندش: نامه در صف مانده و سرور فرستنده هر چند دقیقه دوباره تلاش می کند.

لاگ سرور خودمان هر چهار حالت را در چند ساعت نشان می دهد. قبول شدن این شکلی است: status=sent (250 2.0.0 OK). صف این شکلی: status=deferred با پیام 452-4.2.2 The recipient's inbox is out of storage space، که برای یکی از نامه های ما دو روز و اندی تکرار شد. رد شدن این شکلی: status=bounced. و نرفتن اصلا، همان مورد null MX بخش قبل.

حالا مهم ترین خط. یکی از نامه های همین سرور را جیمیل با این جواب رد کرد: 550-5.7.26 Your email has been blocked because the sender is unauthenticated. Gmail requires all senders to authenticate with either SPF or DKIM. و بعد نتیجه را نوشت: DKIM = did not pass و SPF [] with ip: [65.109.218.65] = did not pass.

در همان چند دقیقه، از همان سرور و همان آی پی، نامه های عادی با 250 2.0.0 OK قبول شدند. پس مشکل نه سرور بود نه آی پی. آن یکی نامه یک اعلان برگشتی بود و فرستنده پاکتش خالی بود، همان from=<> که در لاگ دیده می شود؛ وقتی پاکت نامی ندارد، SPF چیزی برای بررسی ندارد و اگر امضای DKIM هم نباشد، از نظر جیمیل نامه بی هویت است. این دقیقا همان جایی است که بحث احراز هویت شروع می شود.

SPF و DKIM و DMARC هر کدام چه کاری می کنند؟

هر سه رکوردهای متنی در DNS دامنه شما هستند و هر سه به یک سوال جواب می دهند از سه زاویه: این نامه واقعا از طرف این دامنه است؟

SPF فهرست سرورهایی است که اجازه دارند از طرف دامنه شما نامه بفرستند. رکورد ما این است: v=spf1 +mx +a ~all، یعنی سرور پست دامنه و سرور خود سایت مجازند و بقیه مشکوک اند. آن ~all در انتها حالت میانی است، نه رد قاطع؛ سخت گیرانه ترش -all است و ما عمدا آن را انتخاب نکرده ایم، چون کافی است یک سرویس فرستنده را از قلم بیندازید تا نامه های واقعی رد شوند.

DKIM امضایی است که سرور فرستنده روی خود نامه می گذارد. کلید خصوصی روی سرور می ماند و کلید عمومی در DNS منتشر می شود، زیر نامی که به آن سلکتور می گویند. مال ما زیر default._domainkey.rgb.ir نشسته و کلید خصوصی اش روی همین ماشین است؛ همین حالا هم بررسی کردیم که کلید منتشرشده دقیقا همان کلید روی دیسک است. یک محدودیت را هم رک بگوییم: کلید ما ۱۰۲۴ بیتی است، که RFC 8301 آن را کف تعیین کرده و ۲۰۴۸ بیت را توصیه می کند. یعنی جای بهتر شدن دارد.

DMARC هیچ چیزی را خودش بررسی نمی کند. به سرور گیرنده می گوید اگر دو تای قبلی نگرفت چه کند، و گزارش ها را کجا بفرستد. رکورد ما v=DMARC1;p=quarantine;rua=mailto:admin@rgb.ir است، یعنی نامه مشکوک را قرنطینه کن و گزارشش را بفرست.

ظرافتی که معمولا گفته نمی شود: SPF نشانی روی پاکت را می بیند و DKIM امضای روی خود نامه را، و این دو می توانند با هم فرق کنند. کاری که DMARC اضافه می کند این است که می خواهد یکی از آن دو با نام فرستنده ای که کاربر می بیند هم خانواده باشد. برای همین است که سرویس های خبرنامه ای که از دامنه خودشان می فرستند ولی نام شما را نشان می دهند، بدون تنظیم درست، از نظر DMARC رد می شوند.

کدام یک از این سه را دارید؟ روش بررسی

سه استعلام DNS جواب دو تای اول را می دهند و سومی چیز دیگری لازم دارد. برای SPF رکوردهای متنی خود دامنه را بخوانید، برای DMARC رکورد متنی زیرشاخه _dmarc را:

dig +short example.ir TXT
dig +short _dmarc.example.ir TXT

برای DKIM اما نمی شود کورکورانه پرسید، چون اسم سلکتور را باید بدانید و هر سرویس ایمیل سلکتور خودش را دارد. آن را از پنل سرویس ایمیلتان بردارید و بعد dig +short SELECTOR._domainkey.example.ir TXT بگیرید. اگر نمی خواهید با دستور کار کنید، ابزار رایگان بررسی رکوردهای DNS و سلامت ایمیل همین سه را یکجا نشان می دهد و صادقانه می گوید که DKIM را بدون دانستن سلکتور چک نمی کند.

ولی هیچ کدام از این ها ثابت نمی کند نامه شما در عمل قبول می شود. تنها مدرک واقعی نظر گیرنده است. یک نامه به نشانی ای بفرستید که خودتان به آن دسترسی دارید و در آن سرویس دنبال گزینه ای بگردید که هدرهای اصلی نامه را نشان می دهد؛ در جیمیل اسمش «Show original» است. سطری به نام Authentication-Results پیدا کنید و ببینید کنار هر سه چه نوشته.

یک اشتباه رایج را هم اینجا بگیریم: نتیجه را با فرستادن به نشانی روی همان دامنه آزمایش نکنید. سرور با نامه ای که از خودش آمده مثل غریبه رفتار نمی کند و نتیجه گمراه کننده می شود.

چرا وضعیت «ارسال شد» هیچ چیزی را ثابت نمی کند؟

وقتی یک فرم تماس یا یک افزونه می گوید ایمیل ارسال شد، منظورش این است که نامه را به سرور پست محلی تحویل داده. این آغاز مسیر است، نه پایانش. در وردپرس تابع wp_mail() وقتی true برمی گرداند دقیقا همین را می گوید و نه بیشتر؛ ما این را روی سایت های خودمان بارها دیده ایم و قاعده ثابتمان شده که تا لاگ سرور پست را ندیده ایم، درباره تحویل چیزی نگوییم.

جایی که جواب واقعی نوشته می شود لاگ سرور پست است، و آنجا هر نامه یک خط دارد که با status= تمام می شود و جواب عین به عین سرور گیرنده را نقل می کند. تفاوت این دو نگاه در آمار همین سرور دیده می شود: در بازه ای که لاگ فعلی نگه داشته، ۴۴ نامه status=sent گرفتند و ۲۴ نامه status=bounced. برنامه ای که فرستاده بود، برای بخشی از آن ۲۴ تا هم گفته بود ارسال شد.

اگر ایمیل برایتان مهم است، یک عادت بیشتر لازم نیست: بعد از هر تغییری در تنظیمات ایمیل، یک نامه واقعی بفرستید و لاگ را نگاه کنید. اگر به لاگ سرور دسترسی ندارید، از میزبان سایتتان بخواهید خط مربوط به آن نامه را برایتان بفرستد. یک خط لاگ از ده ساعت حدس زدن باارزش تر است.