لماذا تستضيف بريدك الإلكتروني بنفسك في 2026
كان رفع أسعار Microsoft 365 بنسبة تصل إلى 43% بحسب الباقة، اعتباراً من 1 يوليو 2026، بمثابة صدمة حقيقية لكثير من الشركات الصغيرة والمتوسطة. المؤسسة التي كانت تدفع نحو 200 يورو شهرياً لعشرين موظفاً باتت تواجه فاتورة تتجاوز 285 يورو دون أي تحسين ملموس في الخدمة. وهذا ليس كل شيء؛ إذ أعلنت مايكروسوفت عن إيقاف Exchange Web Services (EWS) في أكتوبر 2026، مما يُلغي عشرات التكاملات التي كانت تعتمد على هذا البروتوكول من تقاويم مشتركة وأدوات CRM وأتمتة داخلية.
أمام هذه الاضطرابات السعرية والتقنية، عادت فكرة الاستضافة الذاتية للبريد الإلكتروني إلى الواجهة بشرعية متجددة. استضافة خادم البريد على VPS خاص بك توفر ثلاث مزايا رئيسية: تحكم كامل في التكاليف (VPS مناسب يتكلف بين 15 و40 يورو شهرياً لـ20 إلى 50 صندوق بريد)، وسيادة البيانات (رسائلك لا تمر عبر مراكز بيانات شركات التكنولوجيا الكبرى)، وتبسيط الامتثال للائحة GDPR (تعرف بالضبط أين تُخزَّن بياناتك وكيف تُعالَج). بالنسبة لمكاتب المحامين والمهنيين الصحيين ووكالات الاتصال وأي جهة تتعامل مع بيانات حساسة، غالباً ما تكون هذه الحجة هي الفاصلة.
ما يتضمنه Mailcow من مكوّنات
- Postfix + Dovecot: الثنائي الكلاسيكي المُختبَر للبريد مفتوح المصدر — يتولى Postfix الإرسال والاستقبال عبر SMTP، بينما يوفر Dovecot الوصول عبر IMAP وPOP3 لعملاء البريد.
- Rspamd: محرك فلترة للرسائل غير المرغوب فيها من الجيل التالي، يتفوق بدقته على SpamAssassin، مع تعلم بايزي تكيفي وقوائم رمادية وDKIM وARC وتسجيل متعدد العوامل.
- SOGo: عميل بريد ويب متكامل (تقاويم وجهات اتصال ومهام) مع مزامنة ActiveSync لـOutlook والأجهزة المحمولة دون الحاجة إلى Exchange.
- لوحة إدارة ويب: لوحة تحكم حديثة لإدارة النطاقات وصناديق البريد والأسماء المستعارة والحصص وقوائم التوزيع وسياسات DKIM بنقرات قليلة.
- WebAuthn والمصادقة الثنائية: أمان معزز عبر مفاتيح مادية (YubiKey وما شابهها) أو TOTP لحماية وصول المسؤول وصناديق بريد المستخدمين.
- واجهة REST API كاملة: جميع إجراءات الإدارة متاحة عبر API موثقة تتيح أتمتة إنشاء صناديق البريد والأسماء المستعارة أو دمج Mailcow في بوابة العملاء الخاصة بك.
- مزامنة IMAP مدمجة: مهام المزامنة في الواجهة (*E-Mail Configuration → Synchronizations*) تنسخ الرسائل من خادم المصدر (Gmail أو Microsoft 365 أو cPanel…) إلى صندوق بريد في Mailcow دون الحاجة إلى سطر الأوامر.
- شهادات TLS تلقائية: Let's Encrypt مدمج بشكل أصلي — يجدد Mailcow شهادات نطاق البريد الخاص بك دون أي تدخل يدوي.
المتطلبات التقنية ومتطلبات الشبكة
قبل بدء التثبيت، تأكد من أن خادم VPS وإعداد شبكتك يستوفيان الشروط التالية. على صعيد الأجهزة، يطلب توثيق Mailcow ما لا يقل عن 6 جيجابايت من ذاكرة الوصول العشوائي إضافة إلى 1 جيجابايت من ذاكرة التبادل (swap) في الإعداد الافتراضي: دون ذلك تخرج عن الإعداد الذي يقصده مطوّروه، وتكون الحاويات الأكثر استهلاكاً (مضاد البريد العشوائي ومضاد الفيروسات وقاعدة البيانات) أول من يتضرر. خطط لتوفير معالجَين افتراضيَّين وما لا يقل عن 20 جيجابايت من مساحة القرص للحاويات والرسائل — و50 جيجابايت نقطة انطلاق معقولة لمؤسسة صغيرة.
على صعيد الشبكة، ثمة نقاط غير قابلة للتفاوض. أولاً، يجب أن يكون المنفذ 25 مفتوحاً للخروج: كثير من مزودي الاستضافة يحجبونه افتراضياً لمكافحة البريد العشوائي. تحقق من ذلك قبل الطلب. ثانياً، يجب أن تتمكن من تهيئة rDNS (سجل PTR) لعنوان IP الخاص بك: هذا ما يتيح لخوادم المستلمين التحقق من أن IP الخاص بك يتوافق فعلاً مع اسم مضيف البريد — بدون PTR صحيح ستصل رسائلك إلى مجلد البريد العشوائي لدى معظم مزودي الخدمة الكبار. ثالثاً، تحتاج إلى اسم نطاق تتحكم في DNS الخاص به (إضافة سجلات MX وA وTXT). أخيراً، يُنصح باستخدام خادم يعمل بـDebian 12 أو Ubuntu 24.04 LTS لتحقيق أفضل توافق مع Docker وسكريبتات Mailcow. ويعلن توثيق Mailcow توافقه مع Debian من 11 إلى 13 وUbuntu 22.04 وما بعده وAlmaLinux 8 و9 وRocky Linux 9، أما Alpine فبتوافق محدود وتعديلات يدوية.
تثبيت Mailcow في 8 خطوات
تهيئة الخادم VPS وضبط rDNS
اطلب خادم VPS بذاكرة وصول عشوائي لا تقل عن 6 جيجابايت ومعالجَين افتراضيَّين وعنوان IP مخصص. في لوحة تحكم مزود الاستضافة، انتقل إلى قسم rDNS (أو سجل PTR) واربط عنوان IP الخاص بك بـmail.yourdomain.com. هذا الإعداد حاسم: بدون PTR صحيح، ستُرفض رسائلك أو تُصنَّف كبريد عشوائي لدى Gmail وOutlook. قد يستغرق انتشار سجل PTR ما يصل إلى 24 ساعة.
ضبط سجلات DNS للنطاق
في مدير DNS الخاص بك، أنشئ سجل A (أو AAAA) لـmail.yourdomain.com يشير إلى عنوان IP الخادم. أضف سجل MX على yourdomain.com بقيمة mail.yourdomain.com وأولوية 10. جهّز أيضاً سجل SPF (v=spf1 mx ~all) وسجل DMARC على _dmarc.yourdomain.com — سيُولَّد DKIM تلقائياً بواسطة Mailcow عند أول تشغيل.
تثبيت Docker وDocker Compose
اتصل بخادم VPS عبر SSH بصلاحيات root. ثبّت Docker باستخدام السكريبت الرسمي:
curl -fsSL https://get.docker.com | sh. يُضمَّن Docker Compose v2 في حزم Docker الحديثة. تحقق من الإصدارات باستخدامdocker --versionوdocker compose version. تأكد من بدء تشغيل Docker تلقائياً عبرsystemctl enable --now docker.استنساخ المستودع وتوليد الإعداد
استنسخ المستودع الرسمي في /opt/mailcow-dockerized:
git clone https://github.com/mailcow/mailcow-dockerized /opt/mailcow-dockerized. ادخل إلى المجلد ونفّذ./generate_config.sh. سيطلب السكريبت اسم مضيف البريد (مثل mail.yourdomain.com) والمنطقة الزمنية، ويُنشئ ملف mailcow.conf بمفاتيح عشوائية آمنة — لا تعدّل هذه المفاتيح يدوياً لاحقاً.تشغيل Mailcow
من مجلد /opt/mailcow-dockerized، نفّذ
docker compose pullلتنزيل جميع الصور (حوالي 2 إلى 4 جيجابايت)، ثمdocker compose up -dلتشغيل جميع الحاويات في الخلفية. يستغرق أول تشغيل من 2 إلى 5 دقائق. تحقق من حالة الحاويات بـdocker compose ps— يجب أن تُظهر جميعها الحالة Up أو Up (healthy).الدخول إلى الواجهة وإنشاء أول نطاق
افتح المتصفح على https://mail.yourdomain.com. بيانات الاعتماد الافتراضية هي admin / moohoo. غيّر كلمة مرور المسؤول فوراً. في قائمة *Configuration → Domains*، أضف نطاقك. ثم أنشئ أول صندوق بريد في *Configuration → Mailboxes*. الواجهة بديهية ومنظمة بشكل جيد.
تفعيل DKIM واختبار قابلية التسليم
في *Configuration → ARC/DKIM Keys*، اختر نطاقك وانقر على *Generate new key* (يُنصح بطول 2048 بت). انسخ سجل TXT المُولَّد وأضفه في مدير DNS الخاص بك (سجل TXT على dkim._domainkey.yourdomain.com). ثم أرسل بريداً تجريبياً من صندوقك الجديد إلى [email protected] أو استخدم mail-tester.com للحصول على تقرير شامل لقابلية التسليم.
إعداد النسخ الاحتياطي التلقائي
يوفر Mailcow سكريبت نسخ احتياطي رسمي في helper-scripts/backup_and_restore.sh. جدوله يومياً عبر cron:
0 3 * * * MAILCOW_BACKUP_LOCATION=/opt/backup /opt/mailcow-dockerized/helper-scripts/backup_and_restore.sh backup all. يتجنب المتغير MAILCOW_BACKUP_LOCATION السؤال التفاعلي عن مكان الحفظ؛ ثم انقل هذا المجلد إلى تخزين خارجي (تحميل NFS أو حاوية S3 أو مجلد بعيد عبر rsync). أضف--delete-days 3إلى الأمر لحذف النسخ القديمة. يطلب التوثيق ألا تنسخ السكريبت إلى مكان آخر: استدعِه من مجلده الأصلي. اختبر الاستعادة قبل اعتبار النسخ الاحتياطي فعّالاً.
قابلية التسليم: الأخطاء التي يجب تجنبها
قد يرسل خادم بريد صحيح تقنياً رسائله إلى مجلد البريد العشوائي إذا لم تُستوفَ شروط شبكية وDNS معينة. إليك الأخطاء الأكثر شيوعاً.
القوائم السوداء: قد يكون عنوان IP لخادم VPS مدرجاً في قوائم سوداء مثل Spamhaus أو Barracuda إذا استُخدم سابقاً لإرسال البريد العشوائي. تحقق من IP الخاص بك على mxtoolbox.com/blacklists.aspx قبل التثبيت.
حجب المنفذ 25: بعض مزودي الاستضافة يحجبون المنفذ 25 الصادر على جميع عناوين IP الجديدة لفترة تجريبية. تواصل مع الدعم قبل البدء.
غياب DKIM أو ضعف إعداده: البريد الإلكتروني بدون توقيع DKIM صالح يُعامَل بريبة من قِبَل Gmail وOutlook. تحقق بـdig TXT dkim._domainkey.yourdomain.com من أن السجل مرئي.
DMARC متساهل للغاية: ابدأ بـp=none لجمع التقارير دون حجب، ثم انتقل إلى p=quarantine فـp=reject بمجرد التأكد من أن جميع تدفقات البريد الشرعية مشمولة بـSPF وDKIM.
غياب سجل PTR: الخطأ الأكثر نسياناً. بدون سجل PTR يحل إلى اسم مضيف البريد، سترفض Microsoft Outlook رسائلك بخطأ 550.
Mailcow خلف Nginx Proxy Manager: إذا كان خادم VPS يستضيف خدمات ويب أخرى (موقع إلكتروني، تطبيق)، يمكنك تشغيل Mailcow جنباً إلى جنب مع Nginx Proxy Manager على نفس عنوان IP. المفتاح هو السماح لـNPM بإدارة المنفذَين 80 و443 فقط كبروكسي عكسي، بينما يحتفظ Mailcow بالتحكم المباشر في منافذ SMTP (25 و465 و587) وIMAP/POP3 (993 و995). في mailcow.conf، اضبط HTTP_PORT=8080 وHTTP_BIND=127.0.0.1 وHTTPS_PORT=8443 وHTTPS_BIND=127.0.0.1، ثم طبّق التغيير بالأمر docker compose up -d، وهيّئ NPM للتوجيه إلى http://127.0.0.1:8080 (وهو المنفذ المستخدم في مثال Nginx بتوثيق Mailcow). لا تحاول أبداً توجيه المنفذ 25 عبر بروكسي HTTP عكسي — SMTP لا يعمل بهذه الطريقة.
الترحيل من Google Workspace أو Microsoft 365 إلى Mailcow
غالباً ما يكون ترحيل رسائل البريد الموجودة هو ما يُعيق المؤسسات. يتضمن Mailcow مهام مزامنة IMAP مباشرة في واجهته، مما يجعل العملية في متناول غير المتخصصين.
الإجراء الأساسي هو: (1) إنشاء صناديق البريد الوجهة في Mailcow، (2) فتح *E-Mail Configuration → Synchronizations* من واجهة المسؤول (ويجد المستخدم الأداة نفسها في *User Settings → Sync Jobs*)، (3) إدخال المضيف والمنفذ واسم المستخدم وكلمة المرور للخادم المصدر، واختيار التشفير — يناسب TLS عادةً المنفذ 143 ويناسب SSL المنفذ 993 ويُنصح بشدة بتجنب وضع PLAIN — ثم تفعيل المهمة. تنسخ المهمة الرسائل مجلداً تلو الآخر. يمكن إعادة تشغيل الترحيل عدة مرات قبل القطع النهائي (الرسائل المنسوخة مسبقاً تُتجاهَل في المرات التالية)، مما يتيح إجراء قطع تدريجي: تواصل استقبال البريد على العنوان القديم أثناء نقل البيانات، ثم تبدّل سجل MX في عملية واحدة. وبعد القطع عطّل المهمة أو احذفها.
بالنسبة لـMicrosoft 365، لا تعتمد على EWS: بحسب توثيق مايكروسوفت يبدأ تعطيله لجميع المؤسسات في أكتوبر 2026 ويُعطَّل كلياً في أبريل 2027، فتتوقف أدوات الترحيل التي تعتمد عليه عن العمل. يستخدم Mailcow بروتوكول IMAP لا EWS، وبالتالي لن يتأثر — وهذا سبب إضافي للترحيل المبكر.
أما عملاء البريد الإلكتروني، فإن Thunderbird وApple Mail والتطبيقات المحمولة (iOS وAndroid) تُهيَّأ عبر IMAP/SMTP القياسي. كما يعمل Outlook بما في ذلك مزامنة التقويم وجهات الاتصال عبر ActiveSync (SOGo).
مقارنة: Mailcow مقابل Mailu مقابل iRedMail
Mailcow ليس الحل الوحيد للبريد الإلكتروني المستضاف ذاتياً والمبني على Docker. إليك كيفية مقارنته بمنافسيه الرئيسيين.
Mailu أخف في استهلاك الموارد (يعمل بجيجابايت واحد من ذاكرة الوصول العشوائي) ويناسب الاستخدام الشخصي أو المؤسسات الصغيرة جداً. واجهته بسيطة، لا يتضمن SOGo، وميزاته أكثر محدودية. خيار ممتاز عندما تكون البساطة أولوية.
iRedMail حل ناضج متاح بنسخة مجتمعية ونسخة مدفوعة (iRedMail Pro). يدعم عدة خلفيات قواعد بيانات (MySQL وPostgreSQL وLDAP) ويثبَّت مباشرة على النظام المضيف دون Docker. منحنى الإعداد أشد انحداراً والتحديثات أقل أتمتة.
Mailcow يتميز بثراء مزاياه وجودة واجهة إدارته وتواتر تحديثاته (إصدارات شهرية) وحجم مجتمعه (أكثر من 13,200 نجمة على GitHub). إنه الخيار الطبيعي للشركات الصغيرة والمتوسطة التي تريد حلاً متكاملاً مُصانَاً بنشاط مع توثيق وفير. المقابل هو استهلاك ذاكرة الوصول العشوائي: 6 جيجابايت كحد أدنى شرط غير قابل للتفاوض.
الصيانة وترقيات الإصدارات
ينشر Mailcow إصداراً واحداً كل شهر، ويحمل وسمه السنة والشهر (2026-10 للإصدار الصادر في 21 أكتوبر 2026). تُصلح هذه الإصدارات ثغرات أمنية وتحسن فلاتر البريد العشوائي وتضيف ميزات. إجراء التحديث الرسمي بسيط وموثق جيداً.
من مجلد /opt/mailcow-dockerized، نفّذ ./update.sh. يسحب هذا السكريبت صور Docker الجديدة ويطبق أي ترحيل في الإعداد ويعيد تشغيل الحاويات المتأثرة. تستغرق العملية عادة 5 إلى 15 دقيقة مع انقطاع للخدمة أقل من دقيقة للحاويات المُعاد تشغيلها.
لا تستخدم Watchtower مع Mailcow. تتضمن تحديثات Mailcow أحياناً ترحيل قواعد بيانات أو تعديلات في الإعداد تستلزم تنفيذ update.sh بالترتيب الصحيح. السماح لـWatchtower بسحب الصور وإعادة تشغيل الحاويات تلقائياً قد يُتلف تثبيتك.
جدوِل تحديثاتك خلال نافذة صيانة معروفة (مثلاً صباح السبت)، واقرأ ملاحظة الإصدار في صفحة الإصدارات بمستودع Mailcow قبل التطبيق، وتحقق من حالة الحاويات بالأمر docker compose ps بعد كل تحديث. خذ نسخة احتياطية كاملة قبل كل تحديث مباشرة. وإذا كان الإصدار تحديثاً أمنياً فلا تنتظر: القسم التالي يعرض إجراء الطوارئ.
تحديث Mailcow على وجه السرعة: حالة PHP2Shell
Mailcow ليس تطبيق PHP موضوعاً فوق نظامك: إنه يحمل PHP الخاص به داخل الحاوية php-fpm-mailcow التي تشغّل واجهة الإدارة. لذلك لا تشمله إصلاحات PHP في توزيعتك، ولا يغيّر الأمر apt upgrade على الخادم شيئاً في النسخة التي يستخدمها Mailcow. وهذا ما دفع إلى فتح النقاش #7533</a> في 21 أكتوبر 2026 بعنوان «[UPDATE NOW] PHP RCE Vulnerability (CVE-2026-109618 and CVE-2026-109619)»: يطلب فيه مديرو الأنظمة إصلاحاً من Mailcow نفسه. نشرح الثغرتين في مقالنا [PHP2Shell: إصلاح CVE-2026-109618 وCVE-2026-109619](/blog/php2shell-cve-2026-109618-109619-mettre-a-jour-php).
من جهة الإصدار، يحمل الإصدار 2026-10 الصادر في 21 أكتوبر 2026 العنوان «Security Update: PHP 8.2.35, SOGo 5.12.12 & Nginx 1.30.6». لا تذكر ملاحظاته أرقام CVE: يتم الربط عبر نسخة PHP، لأن 8.2.35 هي النسخة المصححة من الفرع 8.2 في إشعار مشروع PHP</a> الصادر في اليوم نفسه، ولأن صورة phpfpm المرفقة بهذا الإصدار تحمل الوسم 8.2.35-1. اقرأ ملاحظة الإصدار</a> قبل التنفيذ: فقد يغيّر إصدار أحدث هذه الأرقام.
إجراء الطوارئ في ست خطوات
خذ النسخة الاحتياطية أولاً
من أي مجلد، نفّذ
MAILCOW_BACKUP_LOCATION=/opt/backup /opt/mailcow-dockerized/helper-scripts/backup_and_restore.sh backup all. تأكد من أن مجلد الوجهة يحتوي ملفات فعلاً قبل المتابعة، واحتفظ بنسخة خارج الخادم: نسخة تعيش على الجهاز الذي توشك على تعديله لا تحمي من شيء.اقرأ ما سيغيّره التحديث
داخل
/opt/mailcow-dockerizedيبيّن الأمر./update.sh --checkهل يوجد تحديث وما الذي يغيّره دون تطبيق أي شيء. افتح ملاحظة الإصدار بالتوازي وابحث عن قسم «Security»: إن لم تظهر فيه أرقام PHP فعليك مقارنتها بإشعار مشروع PHP بنفسك.طبّق التحديث
نفّذ
./update.shمن المجلد نفسه وأجب عن أسئلة السكريبت. لا تستخدم--forceالذي يصفه التوثيق بأنه غير مدعوم، ولا--oursالذي ينصح بتجنبه: فهما يخفيان تعارضات الملفات بدل حلها. توقع انقطاعاً لبضع دقائق.تحقق من نسخة PHP داخل الحاوية
يجب أن يُظهر الأمر
docker compose exec php-fpm-mailcow php -vالنسخة 8.2.35 أو أحدث. ويعطيك الأمرdocker compose images php-fpm-mailcowالصورة ووسمها (8.2.35-1للإصدار2026-10). أماphp -vعلى الخادم نفسه خارج الحاوية فلا يقول شيئاً عن Mailcow: المهم هو الفحص داخل الحاوية.افحص حالة الحزمة
يجب أن يعرض
docker compose psكل الحاويات بحالةUpأوUp (healthy). ثم نفّذdocker compose logs --tail 50 php-fpm-mailcowبحثاً عن خطأ عند الإقلاع، وافتح واجهة الويب وأرسل رسالة اختبار من صندوق بريد إلى عنوان خارجي.إن تعذّر التحديث فوراً
أحصى النقاش #7533 تدابير مؤقتة قبل صدور الإصلاح:
session.upload_progress.enabled = Off(رآها صاحب النقاش غير كافية)، وقاعدة nginx تردّ بالرمز 403 على طلباتmultipart، وجعل الواجهة تستمع على 127.0.0.1 عبرHTTP_BINDوHTTPS_BIND، وهو ما يقطع أيضاً الوصول المباشر إلى الواجهة ويجعل MTA-STS غير متاح كما نبّه أحد المشاركين. هذه تمنحك ساعات قليلة وليست إصلاحاً. وإن ساء التحديث فالتوثيق يتيح التراجع:docker compose downثمgit checkout <معرّف الـcommit>ثمdocker compose pullثمdocker compose up -d؛ ويتركupdate.shالتزاماً باسم «Before update» تجده بالأمرgit log.
استكشاف الأخطاء: حاوية netfilter تعيد التشغيل في حلقة
على خادم VPS يستضيف أصلاً حاويات Docker أخرى، قد تبدأ الحاوية netfilter-mailcow بإعادة التشغيل بلا نهاية. العَرَض الظاهر: لا تستجيب واجهة الويب، وتُعلن الحاوية unbound-mailcow معطلة («dependency failed to start: container mailcowdockerized-unbound-mailcow-1 is unhealthy»)، وتكرر سجلات netfilter العبارة «MAILCOW target not found in ip forward table, restarting container to fix it...».
السبب المُبلَّغ عنه: عند الإقلاع يتحقق netfilter من موضع سلسلته MAILCOW في جدول FORWARD. بحسب النقاش #6795</a>، تفترض الشيفرة في NFTables.py أن السلسلة في الموضع الأول وتضعها بالإدراج؛ فإذا كان Docker قد أنشأ سلاسله من قبل فشل التحقق وتوقفت الحاوية، ويضيف كل إعادة تشغيل قفزة MAILCOW أخرى. وفي #6995</a> يعدّ أحد المشاركين أكثر من 9000 قفزة، ويصف آخر الأثر نفسه بعد تحديث Docker على Debian.
ما نعرفه عن الحالة: أُغلق #6795 المفتوح في سبتمبر 2025 بوصف «not planned» في ديسمبر 2025 بعد وسم «stale»؛ وأُغلق #6995 المفتوح في يناير 2026 بالطريقة نفسها في أكتوبر 2026. لا يؤكد أي مشرف هناك وجود إصلاح، ويرى أحد المشاركين أن السبب الجذري يتطلب إعادة تصميم. لذا فما يلي حل التفافي من المجتمع وليس إجراءً رسمياً.
شخّص ثم التفّ، من الأكثر أماناً إلى الأكثر خطورة
تأكد من وجود التكرارات
يعرض
docker compose logs --tail 50 netfilter-mailcowالرسائل أعلاه. ويحسبiptables -S FORWARD | grep -c MAILCOWالقفزات نحو السلسلةMAILCOW: المتوقع قفزة واحدة، وأكثر من ذلك يؤكد التشخيص. كرر الاختبار بالأمرip6tablesإن كان IPv6 مفعّلاً.تجنب المشكلة من أصلها
الأكثر أماناً ألا يتعايش Mailcow مع حزم Docker أخرى: جهاز مخصص للبريد يتفادى التصادم. كما يشير توثيق Mailcow إلى مشكلات عدة مع جدار حماية ufw أو firewalld المفعّل، وينصح بتعطيله ونقل قواعدك إلى السلسلة
DOCKER-USER، ويوضح أن قواعدINPUTلا أثر لها على Mailcow.نظّف التكرارات
اعرض القواعد بالأمر
iptables -t filter -L FORWARD --line-numbers، وحدد الأسطر التي تقفز إلىMAILCOW، ثم احذفها بالأمرiptables -t filter -D FORWARD <الرقم>مع إعادة العدّ بعد كل حذف لأن الأرقام تتزحزح. أعد تشغيل الحزمة بالأمرdocker compose down && docker compose up -d. لا تمس قواعدDOCKERالخاصة بحاوياتك الأخرى. هذا التنظيف مؤقت: إن بقي السبب عادت التكرارات.علّق MAILCOW في DOCKER-USER
في #6995 يذكر أحد المشاركين أنه أبقى الحظر عاملاً بتعليق السلسلة في
DOCKER-USER:iptables -I DOCKER-USER 1 -m comment --comment "mailcow bans" -j MAILCOW، مع أمرip6tablesالمكافئ. ويقترح آخر صورة اختبار غير رسمية لـnetfilter جُرّبت مع nftables فقط. لا يعتمد المشروع الأصلي أياً من الطريقتين: جرّبهما على آلة افتراضية للتجربة مع لقطة قبل أن تلمس بيئة الإنتاج.أزل قاعدة العزل كحل أخير
إذا كانت قاعدة العزل في netfilter تحجب تدفقات مشروعة، فإن
DISABLE_NETFILTER_ISOLATION_RULE=yفي mailcow.conf متبوعاً بـdocker compose up -dيزيلها. يحذّر تعليق الملف من أن ذلك قد يعرّض منافذ الحاويات للجيران على الشبكة الفرعية نفسها حتى لو كانت مربوطة بـlocalhost: خصص هذا الإعداد لجهاز مخصص لـMailcow.
خادم VPS للبريد وحده: يفترض تحجيم 6 جيجابايت مع ذاكرة التبادل أن Mailcow يملك الجهاز لنفسه. على خادم مشترك مع موقع تعريفي أو تطبيق في حاويات تجمع ذاكرة كل حزمة، وخطر تصادم قواعد جدار الحماية المذكور أعلاه، وPHP إضافياً يجب مراقبته عند كل إشعار أمني. فصل البريد عن الباقي يكلّف خادم VPS إضافياً، لكنه يزيل هذه الأمور الثلاثة دفعة واحدة.
متى لا يُنصح بالاستضافة الذاتية للبريد الإلكتروني
الاستضافة الذاتية للبريد الإلكتروني ليست إجابة شاملة. ثمة حالات تظل فيها Google Workspace أو Microsoft 365 الخيار الأكثر منطقية حتى بعد الزيادة في الأسعار.
إذا كانت لديك كفاءات تقنية داخلية محدودة: إدارة خادم بريد تتطلب مراقبة أمنية منتظمة وتحديثات استباقية والقدرة على تشخيص مشكلات قابلية التسليم. بدون هذه الكفاءات، قد تجد نفسك بلا بريد إلكتروني في حادثة حرجة.
إذا كانت قابلية التسليم بالغة الأهمية: العمليات الكبيرة للبريد الإلكتروني التحويلي (بنوك، شركات تأمين، منصات تجارة إلكترونية عالية الحجم) تستفيد من سمعة IP المشتركة المُدارة مهنياً من قِبَل مزودي خدمة البريد (Mailgun وPostmark وBrevo).
إذا حجب مزود الاستضافة المنفذ 25: بعض مشغلي الحوسبة السحابية يحجبون هذا المنفذ بصورة نهائية لمكافحة البريد العشوائي. تحقق قبل الالتزام.
إذا كنت في صناعة شديدة التنظيم: بعض القطاعات (المالية والرعاية الصحية) تفرض متطلبات شهادات أو تدقيق لبنية الاتصال البريدي يصعب استيفاؤها بالاستضافة الذاتية دون دعم متخصص.
الخاتمة: خادم بريد إلكتروني يخصك أنت
استضافة خادم البريد الإلكتروني الخاص بك باستخدام Mailcow على خادم VPS أصبحت في متناول أي مؤسسة تمتلك الحد الأدنى من النضج التقني. الحل ناضج ومُصان بنشاط ويوفر مستوى وظيفياً يُنافس بصدق العروض التجارية — بجزء بسيط من التكلفة.
زيادة أسعار Microsoft 365 وتوقف EWS في 2026 حوّلا الاستضافة الذاتية من خيار هامشي إلى بديل استراتيجي لآلاف الشركات الصغيرة والمتوسطة والوكالات. مع خادم VPS مُهيَّأ بشكل صحيح (6 جيجابايت من ذاكرة الوصول العشوائي وعنوان IP مخصص مع rDNS مُعدَّل)، يستغرق تثبيت Mailcow أقل من ساعة، ويمكن إجراء ترحيل صناديق البريد الموجودة بصورة تدريجية دون انقطاع في الخدمة.
ثلاث نقاط تذكّرها قبل البدء: تحقق من أن المنفذ 25 مفتوح لدى مزود الاستضافة، وهيّئ سجل PTR لعنوان IP قبل إرسال أول بريد إلكتروني، وأعدّ نسخاً احتياطية خارجية منذ اليوم الأول. بهذه الأسس، سيكون خادم بريدك الإلكتروني بالغ الموثوقية — وأقل تكلفة بكثير — مقارنة بأي اشتراك سحابي.
أضف ردّ فعل رابعاً إلى هذه الثلاثة: يحمل Mailcow PHP الخاص به، لذا يُعالَج كل إشعار أمني لـPHP بالأمر ./update.sh ثم فحص داخل الحاوية، كما في PHP2Shell في أكتوبر 2026.
