استضف بريدك الإلكتروني عبر Mailcow على VPS

ما الذي تبنيه

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

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

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

تجاهل واحدًا منها فقط وسترسل بريدًا لن يصل أبدًا. مرتّبة تقريبًا حسب مدى تسببها في تعثر الناس:

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

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

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

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

اسم DNS، لا عنوان IP عاريًا. اختر اسم مضيف مثل mail.example.com. هذا الاسم الوحيد يصبح MAILCOW_HOSTNAME الخاص بك، وموضوع شهادة TLS، وهدف PTR، ورسالة ترحيب (banner) 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

انتهاء المهلة هذا هو الحظر. إنه مرشِّح شبكة على مستوى المزوّد، لا جدار الحماية لديك، ولذلك لا يصلحه أي تغيير محلي. افتح تذكرة دعم: «الرجاء تفعيل المنفذ TCP 25 الصادر لخادم VPS الخاص بي على العنوان <IP>؛ أنا أُشغّل خادم بريد مشروعًا.» لا تثبّت mailcow حتى يعيد هذا الاختبار «succeeded». لاحظ أن المنفذ 25 الوارد (خوادم أخرى تصل إليك) مسار منفصل، وهو مفتوح عادة؛ فالجانب الصادر هو ما يُقيّده المزوّدون.

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

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

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 بمجرد إثبات التوافق (alignment). سجلّان ما زالا مفقودين عن قصد: DKIM، الذي يولّده mailcow لك في الخطوة 6، وPTR، الذي تضبطه الآن في لوحة مزوّدك.

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

الخطوة 3: ثبّت Docker

يحتاج mailcow إلى Docker Engine مع إضافة Compose v2. استخدم سكربت Docker الرسمي المريح بدلًا من حزمة docker.io الخاصة بـ Ubuntu، التي لا تأتي بإضافة Compose على الإطلاق:

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

يجب أن ترى سطر Docker Compose version v2.x. إذا طبع أمر 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 يرفض البناء بقناع ملفات (file mask) غير معتاد، وجلسة root جديدة على Ubuntu 24.04 تمنحك 0022 بالفعل. يسأل السكربت بعدها السؤال الوحيد المهم: اسم المضيف المؤهَّل بالكامل (FQDN). أدخل 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، وتخطّيه لا يكلّفك سوى البحث في نص الرسائل داخل webmail.

اترك HTTP_PORT=80 وHTTPS_PORT=443 كما هما ما لم يكن شيء آخر على المضيف يشغلهما بالفعل؛ فعميل ACME المدمج في mailcow يحتاج إلى أن يكون المنفذ 80 قابلًا للوصول من الإنترنت للحصول على الشهادة. لهذا السبب لا تُشغّل إعداد nginx مع Certbot منفصلًا على الجهاز نفسه؛ فـ mailcow يُصدر ويجدّد شهادة TLS الخاصة به داخليًا، وأي خدمة ثانية تستولي على المنفذين 80/443 تكسر ذلك.

الخطوة 5: شغّل الحزمة وسجّل الدخول

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

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

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

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

والآن مفتاح DKIM. اذهب إلى Configuration → ARC/DKIM keys؛ ربما يكون mailcow قد ولّد مفتاحًا بالفعل عند إضافة النطاق، وإن لم يفعل، فولّد واحدًا هناك: اختر النطاق، أبقِ المُحدِّد (selector) على dkim، اختر 2048 بت، وانقر 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 بت أطول من حد الـ 255 حرفًا لسلسلة TXT الواحدة، فألصقه كقيمة منطقية واحدة ودع مزوّد DNS لديك يقسّمه إلى أجزاء نيابة عنك.

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

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

اسعَ إلى 10/10. الخصومات الشائعة وأسبابها:

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

لا ترسل بريدًا حقيقيًا إلى Gmail أو Outlook حتى تحصل على 10/10. نتيجة منخفضة إضافة إلى عنوان IP جديد هي بالضبط الطريقة التي يُوسَم بها نطاقك منذ اليوم الأول.

الخطوة 8: اربط عميل بريد حقيقيًا

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

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

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

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

يأتي mailcow بسكربت نسخ احتياطي يأخذ لقطة (snapshot) لكل وحدة تخزين ذات حالة (stateful volume). شغّله إلى قرص خارجي أو تخزين بعيد مثبَّت (mounted):

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

الخيار all يلتقط ستة أشياء، وفقدان أي واحد منها يعني فقدان بيانات: vmail (صناديق البريد الفعلية)، وcrypt (المفاتيح التي تفك تشفير vmail؛ عديمة الفائدة من دونها)، وmysql (قاعدة MariaDB التي تحوي النطاقات والمستخدمين والأسماء المستعارة (aliases) والإعدادات)، وredis (حالة الطابور والذاكرة المؤقتة)، وrspamd (بيانات البريد المزعج/غير المزعج المتعلَّمة)، وpostfix (طابور البريد). يعمل السكربت داخل حاوية مساعدة تكتب أرشيفات مضغوطة، فتبقى النسخ الاحتياطية متسقة حتى أثناء عمل الحزمة. أتمِتْه بمهمة cron ليلية، وأضف --delete-days 14 لتقليم المجموعات القديمة. الاستعادة هي السكربت نفسه مع 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، أو اقرأ طابور البريد في واجهة الإدارة؛ الإدخالات تبقى مؤجلة (deferred) بالرسالة:

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، اختر «Show original»، واقرأ نتائج المصادقة. dkim=fail أو dkim=none يعني أن TXT الخاص بـ dkim._domainkey مفقود أو مشوَّه أو لم ينتشر بعد؛ أعد نشر ما تعرضه صفحة ARC/DKIM بالضبط وانتظر انقضاء TTL. spf=fail يعني أن سجلّات SPF/MX لا تغطي عنوان IP لديك. التوافق (alignment) هو كل شيء؛ فحص واحد فاشل يكفي للهبوط في البريد المزعج.

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

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. أو فشل تحدٍّ (challenge) يعني أن المنفذ 80 غير قابل للوصول من الإنترنت، أو أن سجل A لا يشير إلى هذا الخادم. تأكد أن mail.example.com يُحلَّل إلى هذا الجهاز، وافتح المنفذين 80 و443 عبر أي جدار حماية على المضيف، وتأكد ألا شيء آخر يستخدم هذين المنفذين. بعد إصلاح السبب، أعد تشغيل العميل بالأمر sudo docker compose restart acme-mailcow بدلًا من انتظار فترة التراجع (back-off) الممتدة ساعة كاملة.

FAQ

هل الاستضافة الذاتية للبريد الإلكتروني تستحق العناء فعلًا؟

إذا كنت تريد ملكية بياناتك، وأسماء مستعارة (aliases) غير محدودة، وتحكمًا كاملًا، فالجواب نعم؛ mailcow يمنحك حزمة احترافية بسعر خادم VPS. لكن قابلية التسليم مهمة دائمة: سمعة IP، وتوافق DNS، ومراقبة قوائم الحظر لا تنتهي أبدًا فعليًا. أما لعنوان بريد تجاري بالغ الأهمية حيث يكلفك يوم واحد في مجلد البريد المزعج لدى أحدهم، فمزوّد مُدار هو الخيار العملي. استضف ذاتيًا حين تقدّر التحكم أكثر من الراحة، وستهتم به فعلًا.

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

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

لماذا ما زال بريدي يهبط في مجلد البريد المزعج في Gmail؟

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

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

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

هل يمكنني تشغيل mailcow على خادم VPS بـ 2 GB؟

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