بیشتر مقایسههای «Mailcow در برابر Stalwart در برابر Mailu» در یک هوملب نوشته شدهاند: یک دامنه، چند صندوق پستی و یک چکلیست امکانات. برای انتخاب میل سرور خانگی کافی است، ولی دربارهٔ ۱۰ هزار صندوق پستی چیز زیادی نمیگوید. در این مقیاس سؤال دیگر این نیست که «فیلتر اسپم دارد یا نه». سؤال این است که اگر یک نود از کار بیفتد چه میشود، و چطور ده هزار حساب را بدون ده هزار بار کلیک بسازیم.
ما Stalwart را برای دانشگاهی با ۱۰ هزار صندوق پستی راه انداختهایم (بخش هزینهای این مهاجرت را در مقالهٔ جداگانه نوشتهایم). پس یکی از سه ستون جدول پایین از تجربهٔ عملیاتی واقعی میآید و دو ستون دیگر نه. ما Mailcow و Mailu را در این مقیاس اجرا نکردهایم. هر جا از آنها حرف میزنیم، خلاصهٔ مستندات رسمی خودشان است و لینکش را گذاشتهایم. آن بخشها را برداشت از مستندات بدانید، نه تجربهٔ میدانی.
خلاصه در یک جدول
| Mailcow | Mailu | Stalwart | |
|---|---|---|---|
| ساختار | استک Docker Compose شامل Postfix، Dovecot، SOGo، Rspamd، ClamAV، MariaDB، Redis و Nginx | مجموعهای از کانتینرها (Postfix، Dovecot، Rspamd، پنل مدیریت، وبمیل) | یک باینری Rust برای SMTP، IMAP، POP3، JMAP، CalDAV، CardDAV و WebDAV |
| حداقل RAM (طبق مستندات) | ۶ گیگ + ۱ گیگ swap | ۱ گیگ بدون آنتیویروس، ۳ گیگ با ClamAV (+۱ گیگ swap) | بسته به ذخیرهسازهایی که وصل میکنید |
| وبمیل | SOGo (با تقویم، مخاطبین و ActiveSync) | Roundcube یا SnappyMail | وبمیل کاربری همراهش نیست؛ JMAP برای ساختنش |
| ذخیرهسازی | دیسک محلی + MariaDB | ولوم محلی؛ دیتابیس خارجی ممکن است | قابل انتخاب: RocksDB، PostgreSQL، MySQL، SQLite، FoundationDB؛ فایلها روی S3/Azure |
| چندنودی | حالت active-active مستند نشده؛ cold standby با rsync | Helm chart جامعهمحور، چند replica برای front، نیازمند ذخیرهساز RWX | کلاستر در نسخهٔ Community؛ read replica و ذخیرهساز sharded در Enterprise |
| مجوز | GPL-3.0 | MIT | AGPL-3.0 بهعلاوهٔ مجوز تجاری Enterprise |
Mailcow: کاملترین جعبه، ولی فقط یک جعبه
وقتی کسی میگوید «ایمیل self-hosted که بیدردسر کار کند»، معمولاً منظورش Mailcow است. طبق صفحهٔ پیشنیازهایش، نصب پیشفرض دستکم ۶ گیگ RAM و ۱ گیگ swap میخواهد. همان صفحه دلیلش را هم صادقانه گفته است: یک worker از SOGo میتواند حدود ۳۵۰ مگابایت مصرف کند، و سازمانی با ۱۵ گوشی روی ActiveSync و حدود ۵۰ اتصال همزمان IMAP باید ۱۶ گیگ در نظر بگیرد. ClamAV و موتور جستوجوی متن کامل بقیهٔ حافظه را میبرند و هر دو را میشود خاموش کرد.
در عوض امکانات زیادی میگیرید. SOGo وبمیل، تقویم، مخاطبین و Exchange ActiveSync را آماده تحویل میدهد؛ اگر جایگزین Exchange برای کاربرانی هستید که با Outlook گوشی کار میکنند، این مهم است. مهاجرت صندوقها در پنل مدیریت به شکل sync job وجود دارد که پشتش imapsync است. جامعهٔ کاربری بزرگی دارد و برای بیشتر مشکلات از قبل یک تاپیک در انجمن پیدا میشود.
محدودیت اصلی در مقیاس بزرگ، خود ساختار است. Mailcow یک استک Compose است که روی یک میزبان زندگی میکند. ما در مستنداتش حالت پشتیبانیشدهٔ active-active یا چندنودی پیدا نکردیم. چیزی که مستند شده cold standby است: یک کپی سازگار با rsync روی ماشین دوم که وقتی اولی از کار افتاد به آن سوئیچ میکنید. برای چند صد کاربر طراحی معقولی است. برای ۱۰ هزار نفر، «سوئیچ به standby» یعنی قطعیای که باید برایش برنامهریزی کنید. مستندات LXC، OpenVZ و Virtuozzo را هم پشتیبانی نمیکند؛ قبل از شروع، نوع مجازیسازی سرورتان را چک کنید.
Mailu: کوچک، مرتب و سازگار با ارکستراسیون
روی کاغذ، Mailu سبکترین گزینه است. صفحهٔ پیشنیازهایش بدون آنتیویروس ۱ گیگ RAM و ۱ گیگ swap میخواهد و با ClamAV سه گیگ. وبمیلش Roundcube یا SnappyMail است، برای بخش مدیریت REST API دارد و کدش با مجوز MIT منتشر شده که آزادترین مجوز بین این سه است.
تنها گزینهای هم هست که Kubernetes را جدی گرفته، از طریق یک Helm chart. قبل از برنامهریزی README همان chart را بخوانید. بخش front میتواند چند replica یا DaemonSet داشته باشد، ولی اجرای چندنودی با ولوم پیشفرض به storage class با دسترسی ReadWriteMany نیاز دارد. مستندات خود Mailu هم نوشته که برای این chart دنبال نگهدارنده میگردند. هیچکدام دلیل کنار گذاشتن Mailu نیست، ولی یعنی دسترسپذیری بالا در Mailu دستکم به همان اندازه به لایهٔ ذخیرهسازی شما بستگی دارد که به خود Mailu.
Stalwart: آنچه واقعاً با آن روبهرو شدیم
Stalwart یک باینری تکفایلی به زبان Rust است که بهجای وصل کردن Postfix به Dovecot، همهٔ پروتکلهای ایمیل و groupware را خودش پیاده میکند. مجوزش دوگانه است: AGPL-3.0 برای نسخهٔ Community و مجوز تجاری برای Enterprise. دلیل انتخابش برای مهاجرت ۱۰ هزار صندوق از IceWarp عملی بود: JMAP (تا بتوانیم وبمیلی بسازیم که حس سال ۲۰۰۵ ندهد؛ جزئیاتش در مقالهٔ JMAP)، ذخیرهسازی خارجی، و مسیر کلاستر بدون قرارداد Enterprise.
تجربهٔ اجرایش اینطور بود، با قسمتهایی که وقتمان را گرفت.
ذخیرهسازی جداست و نکته همین است
متادیتا و تنظیمات را در PostgreSQL نگه میداریم و فایل پیامها را در ذخیرهساز شیء سازگار با S3 (MinIO). همین تفکیک Stalwart را در این مقیاس قابل مدیریت میکند: از PostgreSQL مثل هر دیتابیس دیگری بکاپ و replica میگیرید، ذخیرهساز فایل جداگانه بزرگ میشود و هیچ صندوقی به دیسک محلی یک ماشین وابسته نیست. از نسخهٔ 0.16 تنظیمات هم داخل دیتابیس است، پس بکاپ PostgreSQL یعنی بکاپ کل پیکربندی سرور.
راهنماهای قدیمی گمراهتان میکنند
نسخهٔ 0.16 مدل پیکربندی را عوض کرد. دیگر فایل بزرگ config.toml وجود ندارد. یک فایل JSON کوچک روی دیسک فقط میگوید به کدام دیتابیس وصل شود؛ بقیه (listenerها، دامنهها، DKIM، تنظیمات اسپم) به شکل آبجکت در دیتابیس ذخیره میشوند و از پنل وب یا API مدیریت تنظیم میشوند. بیشتر آموزشهای اینترنتی مال قبل از این تغییرند و خطاهایی که با دنبال کردنشان میگیرید، بهراحتی به علت اصلی اشاره نمیکنند. API مدیریت با OAuth محافظت میشود و password grant ندارد، پس اولین راهاندازی تعاملی است: با مرورگر یا جریان device code.
بعضی تنظیمات در Community در دسترس نبود
میخواستیم برای هر کاربر محدودیت نرخ ارسال سمت سرور بگذاریم تا اگر حسابی لو رفت، نتواند با SMTP خام انبوه ایمیل بفرستد. روی بیلد Community که اجرا کردیم (v0.16.8) راه کارآمدی برای اعمالش پیدا نکردیم: --config فقط JSON دیتابیس را قبول میکرد، endpointهای تنظیمات حتی با توکن معتبر 404 برمیگرداندند، و ویرایش مستقیم ردیفهای باینری پیکربندی در PostgreSQL روی سرور ایمیل زنده ریسکی نبود که بپذیریم. همهٔ این آزمایشها روی یک نمونهٔ ایزوله انجام شد، نه روی production. برداشت ما این است که این بخش از مدیریت تنظیمات در آن نسخه جزو Enterprise است، هرچند صفحهٔ مقایسهٔ نسخههای Stalwart آن را خط به خط ننوشته. در نهایت محدودیت نرخ را در لایهٔ وبمیل و روی reverse proxy جلوی JMAP گذاشتیم. اگر محدودیت ارسال برای هر کاربر برایتان الزامی است، قبل از تصمیم دقیقاً همین تنظیم را روی Community تست کنید.
صفحهٔ مقایسه فهرست امکانات مخصوص Enterprise را صریح آورده: چندمستأجری با سهمیهٔ هر مستأجر، طبقهبند اسپم مبتنی بر هوش مصنوعی/LLM، آرشیو حساب و بازگردانی حذفشدهها، SCIM، read replica و ذخیرهساز sharded، و داشبورد زنده و هشدار متریک. کلاستر پایه در Community هست. قیمت اعلامشدهٔ Enterprise به ازای هر صندوق در سال از ۲ یورو شروع میشود و در حجم بالاتر به ۰٫۸۹ یورو میرسد؛ برای ۱۰ هزار صندوق رقم قابلتوجهی است، ولی نه در حد IceWarp.
نکات کوچکی که در شبکهٔ محدود دردسر میشوند
- در اولین اجرا، پنل وب مدیریت از GitHub دانلود میشود. اگر سرورتان به GitHub دسترسی ندارد، آن فایل را از جایی در دسترس سرو کنید.
- پورت ارسال 587 در نصب ما بهصورت پیشفرض باز نبود. کلاینتهایی که روی 587 تنظیم شدهاند تا اضافه کردن این listener نمیتوانند ایمیل بفرستند.
- اگر برای ابزارهای خودتان فایل لاگ میخواهید، یک file tracer تنظیم کنید. در بیلد Community ما این کار برخلاف تنظیمات rate limit، از طریق آبجکتهای مدیریتی JMAP انجام شد.
ده هزار حساب و انتقال ایمیلها
ساختن حسابها یکییکی در این مقیاس واقعبینانه نیست. راه درست، وصل کردن Stalwart به دایرکتوری موجود (LDAP/AD) است تا حسابها از منبع اصلی بیایند. برای انتقال از IceWarp، ایمیلها و یادداشتها را با imapsync منتقل کردیم و تقویم، مخاطبین و فایلها را با یک اسکریپت کوچک خودمان DAV به DAV، چون هر دو طرف CalDAV/CardDAV/WebDAV میفهمند. بخش سخت اصلاً به Stalwart ربطی نداشت: IceWarp رمزها را هششده نگه میدارد و نمیشد همانها را دوباره استفاده کرد. راه عملی این بود که در طول انتقال برای هر حساب رمز موقت بگذاریم و بعد هش اصلی را برگردانیم. Stalwart حالا ابزار مهاجرت خودش به اسم Vandelay را هم دارد. ما از آن استفاده نکردیم، ولی قبل از نوشتن اسکریپت خودتان ارزش نگاه کردن دارد.
دسترسپذیری بالا، در طراحی
کلاستر Community در Stalwart چند نود مستقل را روی ذخیرهسازهای مشترک اجرا میکند که از طریق یک message bus هماهنگ میشوند. یادداشتهای ما در این مقیاس NATS را برای هماهنگی به Redis pub/sub ترجیح دادهاند، با HAProxy در جلو و ذخیرهسازهای مشترکی که خودشان افزونگی دارند: PostgreSQL با replica و failover، و MinIO در حالت توزیعشده. کار اصلی همین بخش آخر است. کلاستر Stalwart یک PostgreSQL تکی را از نقطهٔ شکست بودن نجات نمیدهد.
بالاخره کدام؟
اگر زیر چند صد کاربر دارید، تقویم و ActiveSync برای گوشی را بدون ساختن چیزی میخواهید و cold standby برایتان برنامهٔ بازیابی قابل قبولی است، Mailcow انتخاب ساده است. پخته و کامل است.
اگر کمترین مصرف منابع و مجوز MIT میخواهید، یا Kubernetes و ذخیرهساز ReadWriteMany قابل اعتماد دارید، Mailu خوب جا میافتد.
اگر هزاران صندوق دارید، سرویس باید از دست رفتن یک نود را تحمل کند، میخواهید ایمیلها در سیستمهایی باشند که بکاپشان را بلدید (PostgreSQL و S3)، یا JMAP را برای ساخت یک کلاینت وب درست لازم دارید، Stalwart همان است که دوباره انتخاب میکنیم. فقط بدانید مدل پیکربندی 0.16 جدید است، راهنماهای قدیمی دربارهاش اشتباه میگویند و بعضی امکانات مدیریتی در نسخهٔ پولی است. یادگیریاش را روی سرور تست و قبل از آخر هفتهٔ مهاجرت بگذارید، نه وسطش.
هر کدام را انتخاب کنید، در این مقیاس معمولاً خود سرور سختترین بخش نیست. تحویلپذیری، DNS، همگامسازی دایرکتوری و انتقال سالها ایمیل بدون گم شدن فلگها است که وقت میبرد. چرا هنوز ایمیل self-hosted در ۲۰۲۶ طرف دیگر این تصمیم را بررسی میکند.