‏ایمیل چطور کار می‌کنه؟ زیر پوست یه تکنولوژی ۵۰ ساله

وقتی Alice روی دکمه ارسال کلیک می‌کنه، اتفاق جالبی می‌افته: کلاینت ایمیل اون اصلاً ایمیل رو نمی‌فرسته، فقط اون رو به یه سرور واسط به اسم Mail Submission Agent تحویل می‌ده. این سرور روی پورت ۵۸۷ گوش می‌ده، احراز هویت رو چک می‌کنه و یه message-ID روش می‌زنه. از اون لحظه به بعد، یه موجودیت دیگه به اسم Mail Transfer Agent (MTA) یا همون پستچی دیجیتال، مسئولیت تحویل رو به عهده می‌گیره. MTA از DNS می‌پرسه «رکورد MX این دامنه چیه؟» تا بفهمه ایمیل باید کجا بره.

ایمیل یه سیستم real-time نیست؛ یه سیستم صف با منطق retry هست. اگه سرور مقصد در دسترس نباشه، پیام توی صف می‌مونه و با تأخیر نمایی دوباره تلاش می‌کنه — ۵ دقیقه، ۳۰ دقیقه، یه ساعت و الی‌آخر تا چند روز. سریع بودن ایمیل مدرن بیشتر به خاطر خالی شدن سریع صف‌هاست، نه معماری پروتکل.

یه مشکل اساسی در SMTP اینه که آدرس پاکت (MAIL FROM:) و هدر From: که کاربر می‌بینه می‌تونن کاملاً متفاوت باشن. پروتکل هیچ‌وقت چک نمی‌کنه که این دوتا با هم تطابق داشته باشن. SMTP در دهه ۷۰ برای شبکه‌های دانشگاهی مبتنی بر اعتماد طراحی شد و همین حفره‌ی بنیادی دلیل اصلی موفقیت فیشینگ و اسپامه.

برای جبران این ضعف، صنعت به جای اصلاح SMTP سه سیستم جداگانه روی آن سوار کرد. SPF لیست IP‌های مجاز برای ارسال از طرف یه دامنه رو در DNS منتشر می‌کنه، اما با forward کردن ایمیل دچار مشکل می‌شه. DKIM هر پیام خروجی رو با کلید خصوصی امضا می‌کنه و گیرنده می‌تونه با کلید عمومی موجود در DNS صحتش رو تأیید کنه — اما امضاهای DKIM هرگز منقضی نمی‌شن و یه ایمیل قدیمی رو می‌شه replay کرد. DMARC این دوتا رو به هم وصل می‌کنه و می‌گه هدر From: باید با دامنه‌ی تأییدشده توسط SPF یا DKIM همخوانی داشته باشه.

بعد از این سه لایه، یه فایروال محتوایی هم وجود داره که هیچ استانداردی نداره و هر ارائه‌دهنده‌ای نسخه خودش رو داره. این لایه شامل بررسی IP reputation (حتی اگه مستأجر قبلی سرور اسپم فرستاده باشه، شما هم امتیاز منفی می‌گیرید)، domain reputation، تحلیل محتوا با مدل‌های ML، اسکن ویروس و بررسی لینک‌ها در برابر بلاک‌لیست‌هاست.

رمزگذاری هم وضعش مشابهه. ایمیل از Opportunistic TLS استفاده می‌کنه؛ یعنی اگه سرور مقصد از STARTTLS پشتیبانی نکنه، اتصال به plain text برمی‌گرده. از همه مهم‌تر اینکه TLS فقط اتصال رو رمزگذاری می‌کنه، نه محتوا رو از سر تا ته. سرورهای ایمیل همیشه به محتوای پیام دسترسی دارن — و همینه که فایروال محتوایی می‌تونه کار کنه.

در نهایت، بعد از همه این لایه‌ها، سه اتفاق ممکنه: ایمیل به اینباکس برسه، بی‌صدا توی اسپم دفن بشه (نه فرستنده و نه گیرنده چیزی می‌فهمن)، یا با خطای 5xx رد بشه. گزینه دوم کابوس سرویس‌های transactional‌ه، چون RFC 5321 این رفتار رو کاملاً مجاز می‌دونه.

نکات کلیدی:

• کلاینت ایمیل فقط پیام رو submit می‌کنه؛ MTA مسئول تحویل واقعیه
• ایمیل یه سیستم صف با retry منطقیه، نه real-time
• SMTP هیچ تطابقی بین آدرس پاکت و هدر From: چک نمی‌کنه — ریشه اصلی فیشینگ
• SPF، DKIM و DMARC سه لایه جداگانه‌ان که بعداً اضافه شدن و هرکدام نقص‌های خودشون رو دارن
• TLS فقط کانال رو رمز می‌کنه؛ سرورهای ایمیل همیشه به محتوا دسترسی دارن
• رفتن ایمیل به اسپم بدون هیچ اطلاع‌رسانی‌ای کاملاً مطابق استانداردهاست