تشغيل mailcow على VPS ليقبل Gmail بريدك

ما الذي ستبنيه

خادم بريد كامل على خادم تملكه: SMTP لإرسال البريد واستقباله، وIMAP للحفاظ على مزامنة هاتفك وحاسوبك المحمول، وعميل webmail، ومرشح spam يمنح كل رسالة تقييماً في الاتجاهين. يجمع mailcow-dockerized بين Postfix وDovecot وRspamd وSOGo webmail وMariaDB وRedis وعميل ACME في مكدس Docker Compose واحد، لذلك لا يمثل البرنامج الجزء الصعب. ستشغّله خلال نصف ساعة.

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

المتطلبات الأساسية هي المشروع

إذا أهملت أيّاً من هذه المتطلبات، فسترسل بريداً لا يصل أبداً. فيما يلي ترتيب تقريبي وفق مدى تسبّب كل متطلب في المشكلات:

يجب أن يكون المنفذ الصادر 25 مفتوحاً. يسلّم خادمك البريد إلى Gmail وMicrosoft عبر TCP على المنفذ 25. يحظر عدد كبير من موفري VPS والخدمات السحابية الاتصالات الصادرة على المنفذ 25 افتراضياً لمكافحة الرسائل المزعجة. يكون هذا الحظر صامتاً؛ فلا يظهر أي خطأ عند الإقلاع، وتبدو حالة كل شيء سليمة، لكن يبقى البريد مؤجلاً في قائمة الانتظار حتى يتوقف Postfix عن المحاولة ويرفضه، إذ يضبط mailcow الحد الأقصى لعمر قائمة الانتظار على خمسة أيام. اختبر ذلك قبل تثبيت أي شيء. إذا كان المنفذ محظوراً، فالحل الوحيد هو فتح تذكرة دعم تطلب فيها من موفر الخدمة فتحه. يفتح بعض الموفّرين المنفذ للحسابات القديمة، بينما لا يفتحه آخرون أبداً.

عنوان IP نظيف ذو سمعة قابلة للاستخدام. تكون عناوين IP المعاد استخدامها لدى VPS غالباً مدرجة مسبقاً في قوائم الحظر بسبب رسائل مزعجة أرسلها المستأجر السابق. افحص عنوانك عبر خدمة مثل Spamhaus lookup أو mxtoolbox قبل الالتزام به. يعني إدراج عنوان IP في قائمة الحظر وجود عمليات رفض لا يمكنك تجاوزها بتعديل الشيفرة.

التحكم في DNS مع سجل PTR صحيح. تحتاج إلى إضافة سجلات إلى منطقة نطاقك، وتحتاج إلى DNS عكسي (PTR) لعنوان IP الخاص بالخادم يشير إلى اسم مضيف البريد. لا يُضبط PTR تقريباً في لوحة DNS الخاصة بك، بل يكون لدى الجهة المالكة لعنوان IP. لذلك تضبطه من لوحة تحكم موفر VPS أو عبر تذكرة دعم.

تُعد سعة 6 GiB من RAM و2 vCPU حداً أدنى مريحاً. الحد الأدنى الذي يحدده mailcow لتثبيت خاص هو 6 GiB من RAM مع 1 GiB من swap، مع التوصية بـ8 GiB عندما يعتمد عليه عدد قليل من المستخدمين. عند النزول عن نحو 2.5 GiB، generate_config.sh يعرض تعطيل فاحص الفيروسات ClamAV حتى لا تبدأ النواة في إيقاف الحاويات. الحد الأدنى الموثق لمساحة القرص في mailcow هو 20 GiB قبل تخزين أي بريد، لذلك وفّر مساحة أكبر من ذلك عند البدء واترك مجالاً لنمو صناديق البريد.

اسم DNS، وليس عنوان IP مجرداً. اختر اسم مضيف مثل mail.example.com. يصبح هذا الاسم نفسه MAILCOW_HOSTNAME، وموضوع شهادة TLS، والهدف لسجل PTR، وراية SMTP. حافظ على اتساقه في كل المواضع.

الخطوة 1، أثبت أن المنفذ الصادر 25 مفتوح

نفّذ ذلك أولاً. إذا فشل هذا الاختبار، فكل ما عداه جهد ضائع. من VPS جديد، حاول فتح جلسة SMTP مع خادم بريد فعلي:

sudo apt update && sudo apt install -y netcat-openbsd
nc -vz -w 5 gmail-smtp-in.l.google.com 25

تظهر النتيجة عند عمل الاتصال فوراً:

Connection to gmail-smtp-in.l.google.com (142.250.x.x) 25 port [tcp/smtp] succeeded!

يبقى المنفذ المحجوب معلقاً طوال الخمس ثواني، ثم يفشل:

nc: connect to gmail-smtp-in.l.google.com port 25 (tcp) timed out: Operation now in progress

في VPS جديد لا يحتوي على قواعد جدار ناري صادرة من إعدادك، يكون انتهاء المهلة هذا ناتجاً عن الحظر لدى مزود الخدمة. هذا مرشح شبكة لدى المزود، وليس جدارك الناري، لذلك لا يعالجه أي تغيير محلي. افتح تذكرة بالنص التالي: "Please enable outbound TCP port 25 for my VPS at <IP>; I am running a legitimate mail server." لا تثبّت mailcow قبل أن تعيد هذه المحاولة النتيجة "succeeded". لاحظ أن المنفذ الوارد 25، أي وصول الخوادم الأخرى إليك، مسار منفصل وعادةً ما يكون مفتوحاً. الذي يقيّده مزودو الخدمة عادةً هو الجانب الصادر.

الخطوة 2، اضبط سجلات DNS الآن

تستغرق تغييرات DNS وقتاً حتى تنتشر، لذلك انشر كل ما يمكنك نشره قبل التثبيت. افترض أن نطاقك هو example.com، وأن مضيف البريد هو mail.example.com، وأن عنوان IP هو 10.0.0.10. أنشئ السجلات التالية في منطقتك:

mail.example.com.        A      10.0.0.10
mail.example.com.        AAAA   2001:db8::10          ; only if you have IPv6
example.com.             MX  10 mail.example.com.
example.com.             TXT    "v=spf1 mx -all"
_dmarc.example.com.      TXT    "v=DMARC1; p=none; rua=mailto:postmaster@example.com"

يسمح سجل SPF بعبارة «لا يُسمح بالإرسال لهذا النطاق إلا إلى MX الخاص بي، وارفض الباقي». ابدأ DMARC بالقيمة p=none حتى تتمكن من مراقبة التقارير دون رفض رسائلك، ثم شدّد السياسة إلى p=quarantine وبعدها إلى p=reject عند التأكد من تطابق المحاذاة. يوجد سجلان غير مضافين عمداً: DKIM، الذي ينشئه mailcow لك في الخطوة 6، وPTR، الذي تضبطه الآن من لوحة مزود الخدمة.

اضبط PTR، أي DNS العكسي، للعنوان 10.0.0.10 على mail.example.com، وهي القيمة المطابقة تماماً لـ MAILCOW_HOSTNAME. هذا هو السجل الوحيد الذي ينساه معظم الأشخاص، وتعتمد عليه مزودات الخدمة الكبرى في الرفض. إذا لم تتضمن لوحتك حقلاً لـrDNS، فأرسل طلب دعم.

الخطوة 3، تثبيت Docker

يتطلب mailcow الإصدار 24.0 أو أحدث من Docker Engine، والإصدار 2.0 أو أحدث من Docker Compose. يُعد مكوّن Compose الإضافي (docker compose) المسار الأبسط، مع أن mailcow يدعم أيضاً الملف التنفيذي المستقل docker-compose. استخدم سكربت التثبيت الرسمي من Docker بدلاً من حزمة Ubuntu المسماة docker.io، إذ لا تتضمن هذه الحزمة مكوّن Compose الإضافي:

curl -fsSL https://get.docker.com | sudo sh
sudo docker compose version

من المفترض أن ترى سطراً باسم Docker Compose version يعرض الإصدار v2.x أو v5.x. أُصدر Compose v5 في عام 2025، وهو مطابق وظيفياً للإصدار v2، ويستوفي أيٌّ منهما متطلبات mailcow. إذا أظهر docker compose version القيمة docker: 'compose' is not a docker command، فهذا يعني أن Docker Engine مثبّت، لكن مكوّن Compose الإضافي غير مثبّت. ثبّت المكوّن الإضافي من مستودع Docker، أو أعد تشغيل السكربت أعلاه، أو اتبع دليلنا التمهيدي لـDocker Compose، الذي يثبّت كلاً منهما من مستودع apt الخاص بـDocker.

الخطوة 4: استنسخ mailcow وأنشئ الإعدادات

cd /opt
sudo git clone https://github.com/mailcow/mailcow-dockerized
cd mailcow-dockerized
umask
sudo ./generate_config.sh

إن التحقق من أن umask يطبع 0022 يتبع خطوات تثبيت mailcow نفسها، التي تضبط umask 0022 قبل الاستنساخ. لا يختبر mailcow هذه القيمة في أي موضع، كما أن جلسة root جديدة على Ubuntu 24.04 تمنحك 0022 مسبقاً. يطلب البرنامج النصي بعد ذلك المعلومة المهمة الوحيدة: اسم المضيف المؤهل بالكامل. أدخل mail.example.com، ويجب أن تطابق القيمة سجل A وسجل PTR تماماً. يكتب البرنامج النصي mailcow.conf، وهو ملف البيئة الوحيد الذي يقرأه المكدس بأكمله. افتحه إذا احتجت إلى تغيير منافذ الويب (HTTP_PORT وHTTPS_PORT) أو تعطيل ClamAV على خادم محدود الموارد:

MAILCOW_HOSTNAME=mail.example.com
HTTP_PORT=80
HTTPS_PORT=443
SKIP_CLAMD=n          # set to y to drop the virus scanner on a <2.5 GiB box

يمثل SKIP_FTS=y خيار الضبط الآخر على خادم منخفض الذاكرة العشوائية: البحث في النص الكامل هو ثاني أكثر مكونات mailcow استهلاكاً للذاكرة وفقاً لوثائق mailcow، وتعطيله يحرمك فقط من البحث في نص الرسائل داخل webmail.

اترك HTTP_PORT=80 وHTTPS_PORT=443 كما هما، ما لم تكن خدمة أخرى على المضيف تستخدمهما مسبقاً. يستخدم عميل ACME المضمّن في mailcow تحدي HTTP-01 افتراضياً، ويتطلب ذلك إمكانية الوصول إلى المنفذ 80 من الإنترنت للحصول على الشهادة. (يمكن لإصدارات mailcow 2026-03 والإصدارات الأحدث استخدام تحدي DNS-01 بدلاً من ذلك عبر ACME_DNS_CHALLENGE=y، ولا يتطلب هذا التحدي المنفذ 80، لكنه يتطلب الوصول إلى API لدى مستضيف DNS.) لهذا السبب لا يشغّل التخطيط البسيط إعداداً منفصلاً لـ nginx وCertbot على الخادم نفسه؛ إذ يصدر mailcow شهادات TLS الخاصة به ويجددها داخلياً، كما أن وجود خدمة ثانية تستخدم المنفذين 80 و443 يؤدي إلى تعطيل ذلك. توثّق mailcow البديل أيضاً: اربط مستمعي الويب محلياً باستخدام HTTP_BIND=127.0.0.1 HTTP_PORT=8080 HTTPS_BIND=127.0.0.1 HTTPS_PORT=8443، وضع Reverse Proxy على المنفذين 80 و443، وإذا أردت أن يتولى Certbot المحلي إدارة الشهادات، وجّه mailcow إليها وأضف hook للتجديد. يتطلب ذلك مكونات تشغيلية أكثر على خادم البريد، وينطبق الحل الوسط نفسه على أي خدمة أخرى تريد واجهة ويب عامة: إذ يجب وضع بناء مثل إعادة تصميم Halcyon لمكتبة Jellyfin لتظهر كمتجر فيديو من حقبة التسعينيات على مضيف مختلف، ما لم تنقل mailcow خلف ذلك الـReverse Proxy، لأنه يتوقع Reverse Proxy خاصاً به على المنفذ 443. الاستثناء هو الخدمة التي لا تطلب منفذ ويب عاماً أصلاً: مرحل RustDesk مستضاف ذاتياً يستمع فقط ضمن نطاق المنافذ 21115 إلى 21119 الخاص به، ولذلك يمكنه مشاركة الخادم، بشرط توفر سعة إضافية كافية في النطاق الترددي.

الخطوة 5، تشغيل الحزمة وتسجيل الدخول

sudo docker compose pull
sudo docker compose up -d
sudo docker compose ps

تجلب عملية السحب نحو أربع وعشرين صورة؛ امنحها بضع دقائق. عندما يُظهر docker compose ps أنّ كل حاوية في حالة running (أو healthy)، افتح https://mail.example.com/admin في المتصفح. اسم المستخدم الافتراضي للدخول كمدير هو admin، وكلمة المرور هي moohoo. غيّر كلمة المرور هذه فوراً من واجهة الإدارة تحت System → Configuration، ثم Access → Administrators. إذا حذّر المتصفح من NET::ERR_CERT_AUTHORITY_INVALID، فهذا يعني أن شهادة ACME لم تصدر بعد؛ راجع قسم فشل ACME أدناه قبل افتراض وجود عطل، فظهور شهادة مؤقتة ذاتية التوقيع أمر طبيعي في الدقيقة أو الدقيقتين الأوليين.

الخطوة 6: إضافة نطاق وصندوق بريد ونشر DKIM

في واجهة الإدارة، افتح E-Mail → Configuration، ثم انقر Add domain ضمن علامة التبويب Domains وأدخل example.com. بعد ذلك، ضمن Mailboxes، انقر Add mailbox لإنشاء you@example.com مع كلمة مرور. يصبح لديك بذلك صندوق بريد يعمل ويمكن الوصول إليه عبر IMAP.

ننتقل الآن إلى مفتاح DKIM. انتقل إلى System → Configuration، ثم Options → ARC/DKIM keys. قد تكون mailcow قد أنشأت مفتاحاً عند إضافة النطاق. وإذا لم تكن قد فعلت، فأنشئ مفتاحاً من المكان نفسه، واختر النطاق، وأبقِ selector على dkim، واختر 2048-bit، ثم انقر Add. انسخ قيمة TXT الطويلة التي يعرضها البرنامج وانشرها كما يلي:

dkim._domainkey.example.com.  TXT  "v=DKIM1;k=rsa;t=s;s=email;p=MIIBIjANBgkqh...long-key...QAB"

تحتوي صفحة Domains في mailcow على زر DNS يسرد كل سجل تتوقعه، ويعرض علامة خضراء أو تقاطعاً أحمر مقابل القيمة المنشورة فعلياً. استخدمها كقائمة تحقق، واحصل على علامة خضراء لكل صف قبل اختبار قابلية تسليم البريد. يشير ظهور صف DKIM باللون الأحمر بعد النشر عادةً إلى تقسيم المفتاح بشكل غير صحيح بين أجزاء TXT؛ إذ إن مفتاح 2048-bit أطول من حد 255 حرفاً لسلسلة TXT واحدة، لذا الصقه كقيمة منطقية واحدة ودع مضيف DNS يقسمه إلى أجزاء نيابةً عنك.

الخطوة 7: اختبر قابلية التسليم واعمل للوصول إلى 10/10

انتقل إلى mail-tester.com، وانسخ العنوان العشوائي الذي يظهره الموقع، ثم أرسل إليه رسالة من صندوق بريدك الجديد. سجّل الدخول إلى بريد SOGo عبر الويب على https://mail.example.com/SOGo، وأرسل الرسالة من هناك. ثم انقر على "Then check your score".

استهدف الحصول على 10/10. فيما يلي أسباب الخصومات الشائعة:

• لم تتم محاذاة SPF: سجل MX/SPF مفقود، أو أن عنوان IP المرسل غير مشمول فيه. أعد التحقق من سجل SPF بصيغة TXT.
• تعذّر التحقق من توقيع DKIM: سجل dkim._domainkey بصيغة TXT مفقود، أو لم يكتمل نشره بعد، أو تعرض للتلف. هذا هو الخطأ الأكثر شيوعاً.
• لا يوجد PTR / عدم تطابق PTR: لا يحل DNS العكسي إلى mail.example.com. أصلح ذلك لدى مزود الخدمة.
• العنوان مدرج في قائمة حظر: يعود ذلك إلى سمعة عنوان IP السابقة. اطلب إزالة العنوان من القائمة، أو اطلب عنوان IP أنظف.

لا ترسل رسائل فعلية إلى Gmail أو Outlook قبل أن تظهر النتيجة 10/10. تؤدي النتيجة المنخفضة مع عنوان IP جديد إلى وضع نطاقك في قائمة المراقبة منذ اليوم الأول.

الخطوة 8، وصّل برنامج بريد حقيقياً

اضبط Thunderbird أو Apple Mail أو هاتفك للاتصال بالخادم باستخدام هذه الإعدادات. اسم مضيف الخادم هو mail.example.com في جميع الحالات:

• IMAP: المنفذ 993، مع SSL/TLS (أو المنفذ 143 مع STARTTLS)
• إرسال SMTP: المنفذ 465، مع SSL/TLS (أو المنفذ 587 مع STARTTLS)
• اسم المستخدم: العنوان الكامل، you@example.com
• كلمة المرور: كلمة مرور صندوق البريد التي عيّنتها

لا ترسل رسائل العميل عبر المنفذ 25 مطلقاً. فهذا المنفذ مخصّص للاتصال بين الخوادم فقط. ولا يوفّر mailcow إرسالاً موثّقاً عبره، لذلك سيرفض الخادم العميل الذي يتصل به. إذا أبلغ العميل عن Relay access denied، فهذا يعني أنه يحاول الإرسال عبر المنفذ 25 أو من دون مصادقة. غيّر الإعداد إلى المنفذ 465 أو 587، واستخدم بيانات اعتماد صندوق البريد.

الخطوة 9: انسخ احتياطياً ما يهم فعلياً

يتضمن mailcow برنامجاً نصياً للنسخ الاحتياطي ينشئ لقطة من كل volume يحتوي على بيانات دائمة. شغّله على قرص خارجي أو على وحدة تخزين remote موصولة:

sudo MAILCOW_BACKUP_LOCATION=/opt/mailcow-backups \
  ./helper-scripts/backup_and_restore.sh backup all

يلتقط all ستة عناصر، وفقدان أيٍّ منها يعني فقدان البيانات: vmail (صناديق البريد الفعلية)، وcrypt (المفاتيح التي تفك تشفير vmail، ولا فائدة منها بدونه)، وmysql (قاعدة MariaDB التي تحتوي على النطاقات والمستخدمين والبدائل والإعدادات)، وredis (حالة قوائم الانتظار وذاكرة التخزين المؤقت)، وrspamd (بيانات spam/ham التي تعلّمها النظام)، وpostfix (قائمة انتظار البريد). يعمل البرنامج داخل حاوية مساعدة تكتب أرشيفات مضغوطة، لذلك تظل النسخ الاحتياطية متسقة حتى أثناء تشغيل الـstack. أتمت تشغيله باستخدام cron ليلاً، وأضف --delete-days 14 لحذف مجموعات النسخ القديمة. تتوقف مهمة cron أحياناً عن العمل من دون إصدار أي تنبيه، لذلك أرسل حالة الخروج من البرنامج إلى مكان ستلاحظها فيه فعلياً؛ إذ ينفّذ خادم ntfy مستضاف ذاتياً طلب curl في سطر واحد من إدخال cron نفسه، ويرسل الفشل إلى هاتفك في الليلة التي يحدث فيها. الاستعادة هي تشغيل البرنامج نفسه مع restore؛ إذ يعرض اللقطات ويسمح لك باختيار ما تريد استعادته. النسخة الاحتياطية التي لم تختبر استعادتها قط ليست نسخة احتياطية، بل مجرد أمل. نفّذ اختباراً تجريبياً عليها أولاً إلى VPS مخصص للاختبار.

الخطوة 10، التحديث وفق جدول زمني

يُحدِّث mailcow نفسه عبر البرنامج النصي الخاص به. يسحب البرنامج النصي الشيفرة الجديدة، ويُجري ترحيل mailcow.conf، ويحمّل الصور مسبقاً، ثم يعيد تشغيل الحاويات بالترتيب:

cd /opt/mailcow-dockerized
sudo ./update.sh --check   # reports whether an update exists, changes nothing
sudo ./update.sh           # applies it

أنشئ نسخة احتياطية أولاً (الخطوة 9)، لأن عكس ترحيل المخطط صعب. تصدر التحديثات باستمرار وتتضمن إصلاحات أمنية للخدمات التي يمكن الوصول إليها من الإنترنت، لذلك لا تترك خادم البريد دون تحديث لأشهر. إذا أدى أحد التحديثات إلى جعل حاوية غير سليمة، يحدد sudo docker compose logs --tail=50 <service>-mailcow الخدمة التي فشل تشغيلها مجدداً.

ملاحظة حول تعزيز الأمان

يشغّل mailcow خدمة netfilter الخاصة به (netfilter-mailcow)، وهي تحظر عناوين IP التي تكرر محاولات الاتصال بمنافذ البريد وwebmail، لذلك تكون جهة البريد محمية تلقائياً. لكن ذلك لا يشمل SSH على الخادم نفسه، إذ يظل مكشوفاً أمام الإنترنت ومعرّضاً لمحاولات التخمين القسري. اجمع هذا الإعداد مع Fail2ban لمراقبة سجل مصادقة SSH، واستخدم تسجيل الدخول بالمفاتيح فقط. احمِ واجهة إدارة mailcow بكلمة مرور قوية، ويفضل أن تمنع الوصول إليها من الإنترنت العام أو تضعها خلف VPN.

أنماط الفشل، مع السلاسل النصية الدقيقة

تتراكم رسائل البريد ولا تُسلَّم أبداً. شغّل sudo docker compose exec postfix-mailcow postqueue -p، أو اقرأ قائمة انتظار البريد في واجهة الإدارة؛ تبقى الإدخالات مؤجلة لمدة تصل إلى خمسة أيام قبل أن يعيد Postfix الرسائل إلى المرسل، مع:

status=deferred (connect to gmail-smtp-in.l.google.com[142.250.x.x]:25: Connection timed out)

يحدث ذلك تقريباً دائماً بسبب حظر مزود الخدمة للمنفذ الصادر 25 (الخطوة 1). وينتج عن وجود قاعدة صادرة في جدار الحماية الخاص بالخادم المهلة الزمنية نفسها، لذلك استبعد هذا الاحتمال أولاً؛ فإذا كان الخادم سليماً، فلن تصلح أي إعدادات المشكلة، وعليك فتح تذكرة دعم. المشكلة ليست في DNS ولا في TLS؛ والدليل هو ظهور الكلمة timed out مقابل MX بعيد على المنفذ 25.

يضع Gmail كل الرسائل في البريد العشوائي أو يعيدها إلى المرسل. افتح الرسالة في Gmail، واختر "عرض المصدر الأصلي"، ثم اقرأ نتائج المصادقة. تعني dkim=fail أو dkim=none أن سجل TXT الخاص بـdkim._domainkey مفقود أو تالف أو لم ينتشر بعد. أعد نشر القيمة نفسها تماماً كما تعرضها صفحة ARC/DKIM، ثم انتظر مدة TTL. وتعني spf=fail أن سجلات SPF/MX لا تشمل عنوان IP الخاص بك. التوافق بين النطاقات مهم جداً؛ إذ يكفي فشل فحص واحد لوضع الرسالة في البريد العشوائي.

يرفضها مزودو الخدمة الكبار عند الاتصال. تتضمن رسائل الإرجاع أو سجلات Postfix رفض Gmail الخاص بـPTR:

550-5.7.25 [10.0.0.10] The IP address sending this message does not have a PTR
550-5.7.25 record setup, or the corresponding forward DNS entry does not match
550 5.7.25 the sending IP. As a policy, Gmail does not accept messages from IPs
550 5.7.25 with missing PTR records.

يعني الرمز 550 5.7.25 أن DNS العكسي مفقود أو غير متطابق. اضبط PTR لعنوان IP الخاص بك على mail.example.com لدى مزود الخدمة (الخطوة 2). يجب أن يتطابق السجل الأمامي (A) مع السجل العكسي (PTR)، ويجب أن يشيرا كلاهما إلى اسم المضيف نفسه الذي يقدمه mailcow للخوادم الأخرى عند التحية.

يعرض المتصفح تحذيراً بشأن الشهادة ولا يختفي أبداً. فشلت الحاوية acme-mailcow في الحصول على شهادة فعلية. تحقّق من سجلها:

sudo docker compose logs acme-mailcow | tail -n 40

يعني ظهور سطر مثل Cannot validate any hostnames, skipping Let's Encrypt for 1 hour. أو فشل التحدي أن المنفذ 80 غير قابل للوصول من الإنترنت، أو أن سجل A لا يشير إلى هذا الخادم. إذا نشرت سجل AAAA، فتحقّق منه أيضاً: يتحقق mailcow أولاً باستخدام سجل AAAA ويتجاوز فحص A عند وجوده، لذلك يؤدي سجل AAAA خاطئ أو مسار IPv6 لا يستطيع الوصول إلى المنفذ 80 إلى فشل التحقق حتى مع صحة سجل A. تأكد من أن mail.example.com يُحل إلى هذا الخادم، وافتح المنفذين 80 و443 عبر أي جدار حماية على الخادم، وتأكد من عدم وجود خدمة أخرى تستمع على هذين المنفذين. بعد إصلاح السبب، أعد تشغيل العميل باستخدام sudo docker compose restart acme-mailcow بدلاً من انتظار انتهاء فترة التراجع التي تستغرق ساعة.

FAQ

هل يستحق تشغيل خدمة البريد الإلكتروني ذاتياً فعلاً؟

إذا كنت تريد امتلاك بياناتك، وإنشاء aliases غير محدودة، والتحكم الكامل، فنعم. يوفّر لك mailcow حزمة احترافية بتكلفة VPS. لكن ضمان وصول الرسائل مهمة مستمرة: سمعة IP، وتوافق DNS، ومراقبة blocklists لا تنتهي تماماً. إذا كان العنوان التجاري بالغ الأهمية، وكان وصول رسالة واحدة إلى مجلد spam لدى شخص ما ليوم واحد يسبب لك خسارة، فالمزوّد المُدار هو الخيار العملي. شغّل الخدمة ذاتياً عندما تكون قيمة التحكم لديك أكبر من قيمة الراحة، وعندما تكون مستعداً لإدارتها فعلياً. وإذا كان هدفك الحقيقي هو إبقاء بياناتك خارج خوادم الآخرين، وليس تشغيل البريد تحديداً، فابدأ بخدمة لا يملك الآخرون حق التصويت على تشغيلها: لا تواجه مكتبة الصور مشكلة في وصول الرسائل أصلاً، وتغطي مقارنتنا بين PhotoPrism وImmich الحد الأدنى من RAM وأوامر النسخ الاحتياطي لهذا الإعداد على النوع نفسه من VPS.

كيف أعرف ما إذا كان المنفذ الصادر 25 محجوباً؟

نفّذ nc -vz -w 5 gmail-smtp-in.l.google.com 25 من الخادم. تعني الرسالة "succeeded!" أن المنفذ مفتوح. أما ظهور timed out بعد الانتظار، فيعني أن المنفذ محجوب. إذا لم تكن لديك قواعد جدار ناري صادرة خاصة بك على الخادم، فالمزوّد هو من يحجبه. هذا هو السبب الأكثر شيوعاً لتمكّن خادم مستضاف ذاتياً من استقبال البريد دون إرساله مطلقاً. والحل الوحيد لحجب المزوّد هو أن يفتح المزوّد المنفذ؛ فلا يغيّر أي إعداد محلي ذلك.

لماذا تصل رسائلي إلى مجلد spam في Gmail رغم ذلك؟

السبب في معظم الحالات هو تعطل سلسلة المصادقة. استخدم "Show original" في Gmail وابحث عن spf=pass وdkim=pass وdmarc=pass. يشير ظهور dkim=fail إلى غياب سجل TXT من نوع dkim._domainkey أو إلى تلفه. كما يضر عدم تطابق PTR أو استخدام IP جديد بلا سجل إرسال سابق بقدرة الرسائل على الوصول. ارفع نتيجة mail-tester.com إلى 10/10 أولاً، ثم حسّن سمعة IP تدريجياً بإرسال بضع رسائل يومياً وزيادة العدد تدريجياً، بدلاً من إرسال حجم كبير في اليوم الأول.

ما الذي أحتاج إلى نسخه احتياطياً تحديداً؟

نفّذ backup_and_restore.sh backup all واحتفظ بالمجموعة كاملة خارج الخادم. يشمل ذلك vmail، أي صناديق البريد، وcrypt، أي المفاتيح التي تفك تشفيرها، وقاعدة بيانات MariaDB، بما فيها النطاقات والمستخدمون وaliases والإعدادات، وRedis، والبيانات التي تعلّمها Rspamd، وقائمة انتظار Postfix. وحدة crypt هي الجزء الذي يغفل عنه كثيرون. فمن دونها تكون نسخة vmail الاحتياطية عبارة عن نص مشفّر غير قابل للقراءة. اختبر استعادة النسخة على خادم تجريبي مرة واحدة على الأقل.

هل يمكنني تشغيل mailcow على VPS بسعة 2 GB؟

ليس بصورة مريحة. يعرض generate_config.sh تعطيل ClamAV عندما تقل الذاكرة عن نحو 2.5 GiB. وحتى عند تعطيل ClamAV، تتنافس Rspamd وDovecot وMariaDB وبقية الحزمة على الذاكرة، لذلك ستصل إلى استخدام swap وإيقاف العمليات بسبب OOM تحت أي حمل فعلي. اعتبر 6 GiB مع 1 GiB من swap الحد الأدنى لتثبيت مستقر لمستخدم واحد، وانتقل إلى 8 GiB فور اعتماد أكثر من شخصين عليه.