mailcow أم Stalwart أم Mailu عند 10,000 صندوق بريد: ما الذي يصمد في الإنتاج

معظم مقارنات "mailcow مقابل Stalwart مقابل Mailu" مكتوبة من مختبر منزلي: نطاق واحد، وبضعة صناديق بريد، وقائمة ميزات. هذه طريقة معقولة لاختيار خادم لعائلتك، لكنها لا تخبرك إلا بالقليل عمّا يحدث عند 10,000 صندوق بريد، حيث تتغيّر الأسئلة من "هل فيه فلتر للبريد المزعج؟" إلى "ماذا يحدث إذا سقطت إحدى العقد؟" و"كيف أنشئ عشرة آلاف حساب دون عشرة آلاف نقرة؟".

نحن نشغّل Stalwart لجامعة فيها 10,000 صندوق بريد (الجانب المالي لتلك الهجرة موجود في مقالة منفصلة). إذن عمود واحد من الأعمدة الثلاثة أدناه يأتي من بيئة إنتاج فعلية، والعمودان الآخران لا. لم نشغّل mailcow ولا Mailu على هذا المستوى، وحيث تصفهما هذه المقالة فهي تصف توثيقهما الرسمي، والروابط موجودة في النص. اقرأ تلك الأجزاء على أنها قراءة للتوثيق، لا ملاحظات ميدانية.

الخلاصة السريعة

mailcow: الصندوق الأكثر اكتمالًا، لكنه صندوق واحد

عندما يقول الناس "بريد ذاتي الاستضافة يعمل وحسب"، فهم يقصدون mailcow غالبًا. وفق صفحة متطلبات النظام، يحتاج التثبيت الافتراضي إلى 6 GiB من الذاكرة على الأقل مع 1 GiB ذاكرة تبديل. والصفحة نفسها صريحة على نحو لافت في شرح السبب: عامل SOGo واحد قد يستهلك نحو 350 MiB، وشركة لديها 15 هاتفًا على ActiveSync ونحو 50 اتصال IMAP متزامنًا عليها أن تخطط لـ 16 GiB. أما ClamAV ومحرك البحث في النص الكامل فهما المستهلكان الكبيران الآخران، ويمكن إيقاف كليهما.

وما تحصل عليه مقابل هذه الذاكرة كثير. يمنح SOGo المستخدمين بريدًا عبر الويب وتقويمات وجهات اتصال وExchange ActiveSync جاهزة، وهذا مهم إذا كنت تستبدل Exchange لأشخاص يعيشون على Outlook في هواتفهم. ونقل صناديق البريد مدمج في لوحة الإدارة على شكل مهام مزامنة تشغّل imapsync في الخلفية. والمجتمع كبير، ومعظم المشكلات التي ستواجهها لها موضوع في المنتدى أصلًا.

القيد في النشر الكبير هو البنية نفسها. mailcow حزمة Compose مصمّمة لتعيش على خادم واحد. لم نجد في توثيقه وضعًا مدعومًا للعمل active-active أو على عدة عقد؛ وما يوثّقه للتكرار هو نسخة احتياطية باردة، أي نسخة rsync متّسقة على جهاز ثانٍ تنتقل إليها عندما يتعطّل الأول. هذا تصميم معقول لبضع مئات من المستخدمين. أما عند 10,000 مستخدم، فـ"الاستعادة إلى النسخة الاحتياطية" تعني انقطاعًا يجب أن تنظّم جداول الناس حوله. ويستبعد التوثيق أيضًا LXC وOpenVZ وVirtuozzo، فتحقّق من نوع الاستضافة قبل البدء.

Mailu: صغير ومرتّب ومناسب للتنسيق الآلي

على الورق، Mailu هو الأخف بين الثلاثة. تطلب صفحة متطلباته 1 GB من الذاكرة و1 GB ذاكرة تبديل دون مضاد فيروسات، و3 GB مع ClamAV. البريد عبر الويب إما Roundcube أو SnappyMail، وهناك واجهة REST لجانب الإدارة، والشيفرة مرخّصة بـ MIT، وهو الترخيص الأكثر تساهلًا بين الثلاثة.

وهو أيضًا الوحيد الذي يتعامل مع Kubernetes كهدف نشر جدّي، عبر مخطط Helm. اقرأ ملف README الخاص بهذا المخطط قبل أن تبني خطتك عليه. يمكن تشغيل الواجهة الأمامية بعدة نسخ أو كـ DaemonSet، لكن التشغيل عبر عدة عقد مع وحدة التخزين الافتراضية الواحدة يتطلب فئة تخزين تدعم ReadWriteMany. ويحيل توثيق Mailu نفسه إلى هذا المخطط ويذكر أنهم يبحثون عن مشرفين له. لا شيء من هذا سبب لتجنّبه، لكن كليهما يعني أن التوافر العالي مع Mailu يعتمد على طبقة التخزين لديك بقدر اعتماده على Mailu نفسه على الأقل.

Stalwart: ما واجهناه فعلًا

Stalwart ملف تنفيذي واحد مكتوب بلغة Rust يتحدّث بنفسه كل بروتوكولات البريد والعمل الجماعي، بدل ربط Postfix بـ Dovecot. وهو بترخيص مزدوج: AGPL-3.0 لإصدار Community، وترخيص تجاري لإصدار Enterprise. أسباب اختيارنا له لهجرة 10,000 صندوق من IceWarp كانت عملية: JMAP (لنبني بريدًا عبر الويب لا يبدو وكأنه من 2005، والمزيد عن ذلك في مقالتنا عن JMAP)، والتخزين الخارجي، ومسار للتجميع لا يتطلب عقدًا مؤسسيًا.

هكذا بدا تشغيله، بما في ذلك الأجزاء التي كلّفتنا وقتًا.

التخزين مقسوم، وهذا هو المقصود

نحفظ البيانات الوصفية والإعدادات في PostgreSQL، وملفات الرسائل في تخزين كائنات متوافق مع S3 (MinIO). هذا التقسيم هو ما يجعل Stalwart قابلًا للعمل على هذا الحجم: يُنسخ PostgreSQL احتياطيًا ويُكرَّر مثل أي قاعدة بيانات أخرى، ومخزن الملفات يتوسّع وحده، ولا يوجد صندوق بريد يعيش على القرص المحلي لجهاز واحد. ويعني ذلك أيضًا أن النسخة الاحتياطية من PostgreSQL هي نسخة احتياطية من إعدادات الخادم كلها، لأن الإعدادات منذ الإصدار 0.16 موجودة في قاعدة البيانات أيضًا.

الأدلة القديمة ستضلّلك

غيّر الإصدار 0.16 نموذج الإعدادات. لم يعد هناك ملف config.toml كبير. ملف JSON صغير على القرص يصف فقط كيفية الوصول إلى مخزن البيانات، وكل ما عدا ذلك (المستمعون والنطاقات وDKIM وإعدادات البريد المزعج) محفوظ ككائنات في قاعدة البيانات ويُدار عبر لوحة الإدارة أو واجهة الإدارة البرمجية. معظم الشروحات التي ستجدها على الإنترنت أقدم من هذا التغيير، واتباعها ينتج أخطاء لا تدلّ بوضوح على سببها. وواجهة الإدارة البرمجية محمية بـ OAuth دون خيار password grant، لذا يكون الإعداد الأول تفاعليًا، عبر المتصفح أو عبر device-code flow.

بعض الإعدادات لم تكن متاحة في Community

أردنا حدًّا لمعدّل الإرسال لكل مستخدم على جانب الخادم، حتى لا يتمكّن حساب مخترق يتحدّث SMTP مباشرة من إغراق الإنترنت بالرسائل. على نسخة Community التي شغّلناها (v0.16.8)، لم نجد طريقة عاملة لتطبيقه: الخيار --config لم يقبل إلا ملف JSON الخاص بمخزن البيانات، ونقاط نهاية الإعدادات أعادت 404 حتى مع رمز صالح، وتعديل صفوف الإعدادات الثنائية في PostgreSQL مباشرة لم يكن مخاطرة تستحق على خادم بريد حيّ. اختبرنا كل هذا على نسخة معزولة، لا على الإنتاج. قراءتنا أن هذا الجزء من إدارة الإعدادات يقع ضمن Enterprise في ذلك الإصدار، مع أن صفحة مقارنة الإصدارات العامة لدى Stalwart لا تذكره بندًا بندًا. في النهاية طبّقنا تحديد المعدّل في طبقة البريد عبر الويب وفي الوكيل العكسي أمام JMAP. إذا كانت حدود الإرسال لكل مستخدم شرطًا لا تنازل عنه لديك، فاختبر هذا الإعداد بعينه على إصدار Community قبل الالتزام.

وللأمانة، صفحة المقارنة تذكر فعلًا ما هو حصري لـ Enterprise: تعدد المستأجرين مع حصص لكل مستأجر، ومصنّف البريد المزعج بالذكاء الاصطناعي/LLM، وأرشفة الحسابات واستعادة المحذوف، والتزويد عبر SCIM، ونسخ القراءة والتخزين المجزّأ، ولوحات المتابعة الحية وتنبيهات المقاييس. أما التجميع الأساسي فموجود في Community. والتسعير المنشور لـ Enterprise يكون لكل صندوق بريد سنويًا، يبدأ من 2.00 يورو وينخفض إلى 0.89 يورو مع الأحجام الأكبر، فعند 10,000 صندوق يصبح بندًا حقيقيًا في الميزانية، لكنه ليس بحجم فاتورة IceWarp.

تفاصيل صغيرة تؤلم على شبكة مقيّدة

• عند التشغيل الأول، تُنزَّل واجهة لوحة الإدارة من GitHub. إذا كان خادمك لا يصل إلى GitHub، فقدّم هذا الملف من مكان يستطيع الوصول إليه.
• منفذ الإرسال 587 لم يكن مفتوحًا افتراضيًا في تثبيتنا. عملاء البريد المضبوطون على 587 سيفشلون في الإرسال حتى تضيف ذلك المستمع.
• إذا أردت ملف سجلّ لأدواتك الخاصة، فاضبط file tracer. في نسخة Community لدينا نجح ذلك عبر كائنات إدارة JMAP، على عكس إعدادات تحديد المعدّل المذكورة أعلاه.

عشرة آلاف حساب، ونقل البريد

إنشاء الحسابات واحدًا واحدًا غير واقعي على هذا الحجم. الخيار المعقول هو ربط Stalwart بالدليل الموجود (LDAP/AD) لتأتي الحسابات من مصدرها الموثوق. ولنقل البريد من IceWarp استخدمنا imapsync للرسائل والملاحظات، وسكربتًا صغيرًا كتبناه لنسخ التقويمات وجهات الاتصال والملفات من DAV إلى DAV، لأن الطرفين يتحدّثان CalDAV/CardDAV/WebDAV. الجزء المزعج لم يكن Stalwart إطلاقًا: IceWarp يخزّن كلمات المرور مُجزّأة (hashed)، فلم يكن بإمكاننا ببساطة إعادة استخدامها. الحل العملي كان كلمة مرور مؤقتة لكل حساب طوال مدة النسخ، ثم استعادة الـ hash الأصلي بعد ذلك. ويأتي Stalwart الآن أيضًا بأداة هجرة خاصة به اسمها Vandelay، لم نستخدمها، لكنها تستحق نظرة قبل أن تكتب سكربتك الخاص.

التوافر العالي، كما هو مصمَّم

يشغّل التجميع في Stalwart Community عدة عقد مستقلة على المخازن المشتركة نفسها، بتنسيق عبر ناقل رسائل. ملاحظاتنا فضّلت NATS على Redis pub/sub للتنسيق على هذا الحجم، مع HAProxy في الأمام، ومع جعل المخازن المشتركة نفسها مكرّرة: PostgreSQL مع نسخة متماثلة وتحويل تلقائي عند الفشل، وMinIO في الوضع الموزّع. وهذا الجزء الأخير هو حيث يكمن العمل الفعلي. تجميع Stalwart لا يجعل نسخة PostgreSQL واحدة أقل من كونها نقطة فشل وحيدة.

إذن، أيها تختار؟

إذا كان عدد مستخدميك أقل من بضع مئات، وتريد تقويمات وActiveSync للهواتف دون بناء أي شيء، وكانت النسخة الاحتياطية الباردة خطة استعادة مقبولة لديك، فـ mailcow هو التوصية السهلة. إنه ناضج ومكتمل.

إذا أردت أصغر استهلاك للموارد، أو ترخيص MIT، أو كنت تشغّل Kubernetes أصلًا ولديك تخزين ReadWriteMany تثق به، فـ Mailu مناسب جدًا.

أما إذا كنت عند آلاف الصناديق، وتحتاج أن تصمد الخدمة عند فقدان عقدة، وتريد تخزين البريد في أنظمة تعرف أصلًا كيف تنسخها احتياطيًا (PostgreSQL وS3)، أو تريد JMAP لبناء عميل ويب حقيقي، فـ Stalwart هو ما سنختاره مرة أخرى. ادخل وأنت تعرف أن نموذج الإعدادات في 0.16 جديد، وأن الأدلة القديمة مخطئة بشأنه، وأن بعض ميزات الإدارة موجودة في الإصدار المدفوع. خصّص وقتًا لتعلّمه على نسخة اختبار قبل عطلة نهاية الأسبوع المخصّصة للانتقال، لا خلالها.

أيًّا كان اختيارك، الخادم في العادة ليس الجزء الصعب على هذا الحجم. وصول الرسائل إلى صناديق الوارد، وDNS، ومزامنة الدليل، ونقل سنوات من البريد دون فقدان العلامات، هي المواضع التي يذهب فيها الوقت. ومقالة لماذا الاستضافة الذاتية أصلًا في 2026 تغطي الجانب الآخر من هذا القرار.

والبريد ليس الخدمة الوحيدة التي يمكن استضافتها ذاتيًا. إن كان السؤال الأوسع عندك هو امتلاك البنية التحتية بدل استئجارها، فمقالة فان‌بينو CMS على Docker تشرح كيف يعمل نظام إدارة المحتوى لدينا بالكامل داخل حاويات.

قبل اختيار أي حزمة، من المفيد أن تعرف لماذا لا تسمح كثير من خدمات البريد باستخدام نطاقك الخاص، فهذه الفجوة غالباً ما تدفع الفرق نحو الاستضافة الذاتية.

وبما أن الحزم الثلاث تعمل داخل حاويات، فإن تتبّع أخطاء التسليم يصبح أسهل بكثير إذا اتبعت إرسال سجلات الحاويات إلى stdout بدلاً من الملفات.

الأسئلة الشائعة

قبل اختيار الحزمة، تحقق أولًا مما إذا كانت الاستضافة الذاتية مجدية عند حجمك: حاسبة تكلفة البريد الإلكتروني ذاتي الاستضافة المجانية تقارن خطة سحابية لكل مستخدم بتشغيل خادمك الخاص وتعرض عدد الصناديق عند نقطة التعادل.