بسیاری از علاقه‌مندان به دنیای خودمیزبانی (Self-Hosting) کار خود را با جایگزین کردن سرویس‌های ابری آغاز می‌کنند؛ از Google Drive و iCloud تا Bitwarden Premium و NextDNS. اما آخرین سنگر این مسیر، یعنی سرور ایمیل، داستان کاملاً متفاوتی دارد. یکی از کاربران که تجربه یک‌ساله خود را در این زمینه منتشر کرده، تأکید می‌کند که این پروژه نرم‌افزاری، تنها پروژه‌ای است که هرگز حاضر نیست دوباره آن را تکرار کند.
راه‌اندازی سرور ایمیل، خودش یک پروژه مستقل است
او ابتدا سراغ محبوب‌ترین گزینه‌های انجمن‌های فنی رفت و نام Mailcow بیش از همه تکرار می‌شد. اما با مطالعه مستندات این نرم‌افزار، حداقل منابع موردنیاز آن یعنی ۶ گیگابایت حافظه به‌همراه ۱ گیگابایت فضای Swap، او را از این انتخاب منصرف کرد؛ چرا که کل سرور خانگی‌اش ۱۲ گیگابایت حافظه داشت و بیش از ۲۰ سرویس روی آن در حال اجرا بود.
در نهایت انتخاب او روی Stalwart قرار گرفت؛ یک سرور ایمیل و همکاری (Collaboration Server) متن‌باز که با زبان برنامه‌نویسی Rust نوشته شده و از پروتکل‌های SMTP، IMAP، POP3 و JMAP به‌همراه CalDAV، CardDAV و WebDAV پشتیبانی می‌کند. بر اساس مستندات، برای ۵ تا ۱۰ کاربر، ۱ گیگابایت حافظه کافی است.
نخستین پیش‌نیاز شبکه‌ای برای کارکرد یک سرور ایمیل، برقراری اتصال‌های TCP ورودی و خروجی روی پورت ۲۵ است. او با ابزار netcat بررسی کرد و متوجه شد این پورت از سمت ارائه‌دهنده خدمات اینترنت (ISP) باز است. اما در مرحله تنظیم DNS و هویت ایمیل، به الزام رکورد PTR برخورد؛ رکوردی از نوع DNS معکوس (Reverse DNS) که نشانی IP را به یک نام میزبان متصل می‌کند تا سرویس‌هایی مانند جیمیل و اوت‌لوک بتوانند اصالت راه‌اندازی را تأیید کنند.
در اتصال اینترنت خانگی، مدیریت رکورد PTR بر عهده ISP است. بررسی با nslookup نشان داد هیچ رکورد DNS معکوسی وجود ندارد و ISP نیز از ثبت آن خودداری کرد. همین جا بود که نقشه میزبانی ایمیل در خانه رنگ باخت.
هتزنر سریع پاسخ داد؛ اما شرط و شروط داشت
او تصمیم گرفت سرور ایمیل را روی یک سرور مجازی ارزان (VPS) در حساب قدیمی خود در هتزنر راه‌اندازی کند. این بار پیش از هر اقدامی، همه پیش‌نیازها را بررسی کرد و متوجه شد هتزنر به‌صورت پیش‌فرض پورت‌های ۲۵ و ۴۶۵ را مسدود می‌کند تا از سوءاستفاده اسپمرها جلوگیری شود. باز کردن این پورت‌ها نیازمند درخواست دستی بود که به دلیل سابقه حساب و فاکتورهای پرداخت‌شده، در چند دقیقه تأیید شد.
سپس Stalwart را با Docker Compose روی VPS مستقر کرد و مراحل راه‌اندازی را تکمیل کرد:
- ثبت هفت رکورد DNS
- تعریف چهار قانون فایروال (Firewall)
- باز کردن پورت‌های ۲۵ و ۴۶۵
- دریافت گواهی Let's Encrypt با ابزار acme.sh و توکن محدودشده Cloudflare
- ساخت یک صندوق پستی (Mailbox) و یک نام مستعار postmaster
هزینه ماهانه این VPS تنها ۴.۹۹ دلار بود، در حالی که او پیش‌تر برای هر کاربر Google Workspace ماهانه ۸.۴۰ دلار پرداخت می‌کرد؛ بنابراین در ذهنش صرفه‌جویی قابل‌توجهی تصور می‌کرد. سپس نخستین ایمیل را ارسال کرد.
همه آزمون‌ها قبول شد، اما یک ارائه‌دهنده هنوز «نه» می‌گفت
او با آدرس ایمیل جدید در نرم‌افزار Thunderbird وارد شد و ایمیل‌های آزمایشی مشابهی به حساب‌های جیمیل، اوت‌لوک و پروتون‌میل فرستاد. اوت‌لوک و پروتون‌میل ایمیل را معتبر دانستند و به صندوق ورودی تحویل دادند، اما گوگل آن را اسپم علامت زد. تکرار آزمایش نیز همین نتیجه را داشت.
بررسی هدر پیام‌های دریافتی نشان داد جیمیل و پروتون‌میل امضای RSA DKIM را با موفقیت تأیید کرده‌اند، اما رفتارشان با امضای دوم Ed25519 متفاوت بود. اوت‌لوک علاوه بر همان بررسی‌ها، احراز هویت ترکیبی مایکروسافت (compauth=pass) را نیز پاس کرده و الگوریتم Ed25519 را به‌عنوان روشی پشتیبانی‌نشده نادیده گرفته بود. این یافته‌ها توضیح نمی‌داد چرا فقط جیمیل ایمیل را اسپم می‌داند، چون امضای RSA معتبر بود و DMARC نیز پاس شده بود.
بررسی نشانی IP سرور با MXToolbox نیز هیچ قرارگیری در فهرست‌های سیاه عمومی، از جمله Spamhaus ZEN، نشان نداد. با این حال، گوگل سیستم‌های اعتبارسنجی فرستنده اختصاصی خود را دارد و یک دامنه تازه یا IP کم‌ترافیک می‌تواند اعتبار ناچیزی داشته باشد. در نهایت او هرگز دلیل دقیق اسپم‌شدن ایمیل‌ها در جیمیل را کشف نکرد.
راه‌اندازی بخش آسان ماجراست؛ زنده نگه‌داشتن، خودِ کار است
مشکل تنها به تحویل ایمیل محدود نبود. در نسخه‌ای که او اجرا می‌کرد (0.16.24)، Stalwart نه اپلیکیشن اختصاصی داشت و نه وب‌میل (Webmail) داخلی. برای استفاده روزمره باید از نرم‌افزارهای شخص ثالث مانند Thunderbird استفاده می‌شد و ورود به حساب نیز نیازمند وارد کردن مشخصات سرور IMAP در کنار نام کاربری و گذرواژه بود. به این ترتیب، امکان ورود سریع از مرورگر روی یک رایانه دیگر وجود نداشت.
او آزمونی نیز برای پایداری سرویس انجام داد: کانتینر Docker را عمداً متوقف کرد و در همان بازه زمانی ایمیلی به آدرس خودمیزبان فرستاد. ایمیل دریافت شد، اما حدود ۲۰ تا ۲۵ دقیقه پس از بالا آمدن کانتینر و بر اساس سیاست تلاش مجدد (Retry Policy) فرستنده. همچنین در آزمون بازگردانی (Restore)، هرچند فرایند با موفقیت انجام شد، نسخه پشتیبان قدیمی‌تر بود و ایمیل‌های تازه را از سرور پاک کرد؛ در نتیجه کلاینت ایمیل نیز آن پیام‌ها را در همگام‌سازی بعدی حذف کرد.
صورتحسابی که ترجیح داد بپردازد
در پایان، او با موانعی چون تحویل‌پذیری نامطمئن ایمیل، نبود وب‌میل، مسئولیت نگهداری ۲۴ ساعته و هزینه ماهانه VPS روبه‌رو شد و تصمیم گرفت همان Google Workspace پولی را حفظ کند. به گفته او، Stalwart خودش مشکل نیست و یک سرور ایمیل ساده برای استقرار است؛ اما اگر کسی آماده پذیرش این مسئولیت سنگین باشد، می‌تواند گزینه‌ای قابل بررسی باشد.