معرفی پروتکل‌های SMTP، IMAP و POP3 و تفاوت آن ها

مقدمه

در مقاله‌های قبلی با Mail Server و Webmail آشنا شدیم، اما ندیدیم دقیقاً چه پروتکل‌هایی پشت این ارتباطات کار می‌کنند. سه پروتکل اصلی — SMTP، IMAP و POP3 — هرکدام نقش متفاوتی در چرخه‌ی ارسال و دریافت ایمیل دارند، و اشتباه گرفتن آن‌ها یکی از رایج‌ترین منابع سردرگمی در تنظیم کلاینت‌های ایمیل است. در این نسخه‌ی گسترده‌تر، علاوه بر تعریف هر پروتکل، به مکانیزم داخلی، پورت‌ها و رمزنگاری، و سناریوهای واقعی پشتیبانی هم می‌پردازیم.

SMTP چیست؟

SMTP (Simple Mail Transfer Protocol) پروتکلی است که فقط برای ارسال ایمیل استفاده می‌شود — چه از MUA به سرور، چه بین دو سرور. یعنی هم وقتی شما روی Outlook دکمه‌ی Send را می‌زنید، هم وقتی MTA سرور شما ایمیل را به MTA سرور مقصد تحویل می‌دهد، در هر دو حالت SMTP در حال کار است.

مراحل داخلی یک ارتباط SMTP

وقتی دو MTA با هم صحبت می‌کنند (یا وقتی شما دستی با telnet متصل می‌شوید)، این دستورات به‌ترتیب رد و بدل می‌شوند:

HELO/EHLO mail.example.com   → معرفی سرور فرستنده
MAIL FROM:<sender@example.com>   → مشخص کردن Envelope فرستنده
RCPT TO:<receiver@example.com>   → مشخص کردن Envelope گیرنده
DATA   → شروع ارسال محتوای پیام (Headers + Body)
QUIT   → پایان ارتباط

EHLO یا Extended HELO نسخه‌ی جدیدتر HELO است و امکاناتی مثل SMTP AUTH و STARTTLS را هم به سرور اعلام می‌کند؛ تقریباً همه‌ی MTAهای امروزی (از جمله Exim) از EHLO پشتیبانی می‌کنند.

در این عکس نمایی جزئی‌تر از این فرآیند نمایش داده شده است.

پورت‌ها و رمزنگاری SMTP

تفاوت 587 و 465 در نحوه‌ی برقراری رمزنگاری است: در 587 ابتدا اتصال به‌صورت متن‌باز شروع و سپس با دستور STARTTLS رمزنگاری می‌شود؛ در 465 از همان ابتدای اتصال، رمزنگاری TLS برقرار است. جزئیات کامل هر پورت در مقاله‌ی پورت‌های پرکاربرد سرویس ایمیل بررسی شده است.

نکته حیاتی

طبق برخی منابع جدید استفاده از پورت 465 به علت تنظیم سرویس جدید از سمت IANA بر روی آن دیگر برای SMTP پیشنهاد نمی‌شود.

SMTP AUTH مکانیزمی است که با آن کلاینت (Outlook، Thunderbird، اپلیکیشن موبایل) با یوزرنیم/پسورد خودش را به سرور معرفی می‌کند تا اجازه‌ی ارسال از طریق آن سرور را داشته باشد؛ بدون این احراز هویت، سرور معمولاً درخواست را به‌عنوان Open Relay رد می‌کند (نکته‌ی مهم امنیتی که در مقاله‌ی آموزش تنظیم صحیح relay در cpanel بیشتر توضیح داده شده).

IMAP چیست؟

IMAP (Internet Message Access Protocol) برای دریافت و مدیریت ایمیل استفاده می‌شود(multi-device, synchronized mailbox access)، اما با یک ویژگی کلیدی: ایمیل‌ها روی سرور باقی می‌مانند و فقط نمایش داده می‌شوند. هر تغییری — خواندن، حذف، جابه‌جایی بین پوشه‌ها، Flag کردن به‌عنوان Important — مستقیماً روی سرور اعمال و بین همه‌ی دستگاه‌ها همگام‌سازی می‌شود.

چرا IMAP برای چند دستگاه بهتر است؟

فرض کنید یک ایمیل را روی گوشی می‌خوانید. چون IMAP وضعیت “خوانده‌شده” را روی خود سرور ثبت می‌کند، همان ایمیل وقتی از لپ‌تاپ هم چک شود، از قبل به‌عنوان خوانده‌شده نمایش داده می‌شود — چیزی که در POP3 اصلاً امکان‌پذیر نیست.

یکی از قابلیت‌های کمترشناخته‌شده‌ی IMAP، دستور IDLE است: کلاینت با استفاده از آن یک اتصال باز نگه می‌دارد و به‌محض رسیدن ایمیل جدید، بدون نیاز به Polling دوره‌ای، فوراً مطلع می‌شود — پایه‌ی Push Notification در اکثر اپلیکیشن‌های موبایل ایمیل.

پورت‌ها

• 143 — بدون رمزنگاری (یا با STARTTLS اختیاری)
• 993 — IMAP روی SSL/TLS مستقیم (پیشنهادی و استاندارد امروزی)

POP3 چیست؟

POP3 (Post Office Protocol نسخه‌ی 3) هم برای دریافت ایمیل است، اما با منطقی متفاوت: ایمیل از سرور دانلود و معمولاً از روی سرور حذف می‌شود(simple download-first workflows) (مگر تنظیم “Leave a copy on server” فعال باشد). یعنی ایمیل عملاً به یک دستگاه مشخص منتقل می‌شود و آن دستگاه مالک اصلی نسخه‌ی نهایی پیام می‌شود.

POP3 از یک شناسه به نام UIDL (Unique ID Listing) برای هر پیام استفاده می‌کند تا کلاینت بتواند تشخیص دهد کدام پیام‌ها قبلاً دانلود شده‌اند و کدام‌ها جدیدند — حتی اگر “Leave a copy on server” فعال باشد.

این رفتار باعث می‌شود POP3 برای کاربری که فقط از یک دستگاه ثابت استفاده می‌کند و می‌خواهد فضای Mailbox روی سرور خالی بماند مناسب باشد، اما برای دسترسی چند-دستگاهی اصلاً گزینه‌ی خوبی نیست.

همچنین فرآیند عیب یابی و بک آپ گیری را نیز دشوارتر می‌کند.

پورت‌ها

• 110 — بدون رمزنگاری
• 995 — POP3 روی SSL/TLS (پیشنهادی)

جدول مقایسه

سناریوهای واقعی پشتیبانی

سناریو ۱: کاربر می‌گوید “ایمیل‌هایی که در گوشی حذف کردم هنوز روی سیستم دیگه‌ام هستن”
احتمالاً کلاینت با POP3 تنظیم شده، نه IMAP. راهنمایی: تغییر نوع اکانت به IMAP در تنظیمات کلاینت.

سناریو ۲: کاربر نمی‌تواند ایمیل ارسال کند ولی دریافت می‌کند
چون دریافت (IMAP/POP3) و ارسال (SMTP) دو مسیر کاملاً مجزا هستند، این خطا معمولاً به تنظیمات SMTP (پورت اشتباه، عدم فعال بودن SMTP AUTH، یا مسدود بودن پورت توسط ISP) یا تنظیمات recordهای ایمیل مثل SPF/DKIM/DMARC و وضعیت بلاک لیست‌ها برمی‌گردد، نه به Mailbox یا IMAP.

سناریو ۳: تست دستی یک اتصال IMAP یا SMTP با telnet
برای عیب‌یابی سطح پایین (بدون رمزنگاری، صرفاً برای بررسی در دسترس بودن پورت):

telnet mail.example.com 143
telnet mail.example.com 25

اگر اتصال برقرار نشود، معمولاً یعنی پورت توسط فایروال سرور یا شبکه‌ی کاربر مسدود شده — قبل از هر بررسی دیگری این را رد کنید.

اشتباهات رایج و عیب‌یابی

۱. تنظیم اشتباه IMAP به‌جای POP3 (یا برعکس) در کلاینت
اولین قدم عیب‌یابی، بررسی نوع اکانت در تنظیمات کلاینت است؛ این ساده‌ترین و رایج‌ترین منبع تیکت‌های مرتبط با “همگام‌سازی عجیب ایمیل‌ها” است.

۲. استفاده از پورت غیر-SSL در شبکه‌های عمومی
استفاده از پورت‌های رمزنگاری‌نشده (25، 143، 110) به‌جای معادل SSL آن‌ها، ریسک شنود اطلاعات ورود را بالا می‌برد؛ همیشه پورت SSL را به کاربر پیشنهاد دهید.

۳. تصور اینکه SMTP هم برای خواندن ایمیل استفاده می‌شود
SMTP هیچ نقشی در دریافت یا نمایش ایمیل ندارد؛ فقط مسیر ارسال است. اگر مشکل کاربر “ایمیل نمی‌بینم” باشد، مشکل احتمالا به IMAP/POP3 مربوط است، نه SMTP.

۴. فراموش کردن فعال‌سازی SMTP AUTH در کلاینت
بدون این تنظیم، سرور معمولاً درخواست ارسال را رد می‌کند، حتی اگر یوزرنیم/پسورد صحیح باشد؛ در اکثر کلاینت‌ها این گزینه با عنوان “My server requires authentication” یا مشابه آن ظاهر می‌شود.

جمع‌بندی

SMTP برای ارسال، IMAP برای مدیریت هم‌زمان‌شده‌ی (synchronized) ایمیل روی چند دستگاه، و POP3 برای دانلود و نگهداری محلی ایمیل استفاده می‌شود. تشخیص درست این‌که کاربر با کدام پروتکل و چه پورتی کار می‌کند، اولین و مهم‌ترین قدم در عیب‌یابی بسیاری از تیکت‌های مرتبط با کلاینت ایمیل است.