كيف تستضيف بريد مؤسستك بنفسك: دليل عملي من القرار إلى التشغيل

لنفرض أنك مسؤول التقنية في شركة ناشئة تجاوز عدد موظفيها المئة، أو في جامعة أو مدرسة فيها آلاف الطلاب، أو في جهة حكومية تريد أن تبقى مراسلاتها على سيرفرات تعرف مكانها، وجاءك السؤال من الإدارة: «لماذا ندفع كل شهر اشتراكاً لكل صندوق بريد، وأين تحفظ رسائلنا أصلاً؟ ألا نستطيع أن نستضيف بريدنا بأنفسنا؟». والإجابة القصيرة نعم تستطيع، والأدوات مفتوحة المصدر Open Source الموجودة اليوم ناضجة وتعمل، ولكن البريد الإلكتروني Email ليس خدمة تثبتها ثم تنساها كما تفعل مع قاعدة معرفة داخلية، والسبب أن رسائلك تخرج إلى سيرفرات Gmail وOutlook التي لا تعرفك، وهي التي تقرر هل تصل رسالتك إلى صندوق الوارد Inbox أم إلى مجلد الرسائل المزعجة Spam، وبالتالي فنجاح المشروع يعتمد على القرار والتخطيط والمتابعة بقدر ما يعتمد على التثبيت نفسه.

وقد نشرنا على الموقع أدلة عملية لكل جزء من هذا الطريق، فشرحنا تثبيت ثلاثة خوادم بريد Mail Servers وقارنا بينها، وشرحنا ترحيل الصناديق Mailboxes بين السيرفرات، والنشرات البريدية Newsletters، واختيار السيرفر وتأمينه، ولكن من يبدأ يحتاج إلى خريطة تقول له من أين يبدأ وبأي ترتيب يقرأ، وما الذي يقرره قبل أن يكتب أول أمر. لذلك كتبنا هذا الدليل ليكون المرجع الذي ترسله إلى زملائك في الإدارة وفي فريق التقنية قبل أي قرار، وفي كل قسم منه رابط إلى الدليل الذي يشرح التفاصيل خطوة بخطوة.

وسوف نناقش في هذا المقال ما يلي:

• الخلاصة في دقيقة واحدة، ثم شكل منظومة البريد في مؤسستك من المستخدم إلى الإنترنت.
• هل تستضيف بريدك بنفسك أصلاً، ومتى يكون البريد المستضاف Hosted Email هو الأنسب، والحلول الوسط بينهما.
• ما تجهزه قبل أن تبدأ، وكم يحتاج السيرفر، وما الذي يختلف في الجامعات والمدارس.
• اختيار خادم البريد، وسجلات DNS التي تقرر وصول رسائلك.
• خطة نقل المؤسسة على مراحل، وإدارة الحسابات من أول يوم للموظف إلى آخر يوم له.
• التأمين، والنسخ الاحتياطي، ومراقبة وصول الرسائل، ولماذا لا ترسل النشرات من خادم البريد الأساسي.
• قائمة تحقق قبل التبديل، وخريطة المقالات التي تقرؤها بالترتيب.

الخلاصة في دقيقة واحدة

إذا لم يكن لديك وقت إلا لهذا القسم، فهذه أهم النقاط التي سوف نشرحها في بقية الدليل:

• استضف بريدك بنفسك عندما يكون لديك سبب واضح، مثل بقاء البيانات داخل الدولة، أو عدد كبير من الصناديق تصبح معه الاشتراكات بنداً كبيراً، ومعه شخص مسؤول عن السيرفر وله وقت مخصص لذلك، أما إذا لم يوجد هذا الشخص فالبريد المستضاف هو الأنسب لك.
• المزود Provider يحدد نجاحك قبل الأداة، فلا تشتر سيرفراً قبل أن تتأكد أن المنفذ Port 25 الصادر مفتوح أو يفتح بطلب، وأنك تستطيع ضبط سجل PTR، وأن عنوان IP غير مدرج في قوائم الحظر Blocklists.
• اختر بين mailcow وStalwart وPostfix مع Dovecot بحسب ما يحتاجه فريقك وبحسب الموارد، وتجد الفروق في مقارنة خوادم البريد.
• انشر سجلات MX وSPF وDKIM وDMARC وPTR كاملة قبل أول رسالة، وابدأ DMARC بالقيمة p=none ثم انتقل إلى p=quarantine ثم p=reject بعد مراجعة التقارير.
• انقل المؤسسة على مراحل: نطاق تجريبي ومجموعة صغيرة، ثم مزامنة الصناديق القديمة، ثم تبديل سجل MX بعد تخفيض قيمة TTL، مع إبقاء المزود القديم فترة بعد التبديل.
• لا ترسل النشرات والحملات الجماعية من خادم البريد الأساسي، وإنما من listmonk عبر خدمة إرسال مستقلة ونطاق فرعي Subdomain.
• النسخة الاحتياطية Backup التي لم تجرب استعادتها لا تعرف هل تعمل، لذلك اجعل تجربة الاستعادة Restore على سيرفر مؤقت جزءاً ثابتاً من عملك.

وهذه أدلة البريد الأساسية التي يحيل إليها هذا الدليل، من المقارنة بين الخوادم إلى التثبيت ثم الترحيل والإرسال والنشرات:

مقارنةmailcow أم Stalwart أم Postfix مع Dovecot؟ أي خادم بريد يناسبكهل تريد حزمة بريد كاملة ببريد عبر الويب، أم خادماً تبنيه بيدك وتفهم كل سطر فيه، أم برنامجاً واحداً خفيفاً؟ نقارن mailcow وPostfix مع Dovecot وStalwart لتعرف أيها يناسب فريقك وسيرفرك، ومتى يكون البريد المستضاف هو الأنسب.دليلتثبيت خادم البريد mailcow باستخدام Dockerأن تدير خادم بريدك بنفسك يعني أن تضمن وصول رسائلك إلى صندوق الوارد لا إلى الرسائل المزعجة. يشرح هذا الدليل تثبيت mailcow، وضبط سجلات DNS المطلوبة، وحل مشكلات التسليم الشائعة.دليلتثبيت خادم البريد Stalwart باستخدام Docker Composeخادم بريد كامل في برنامج واحد بدل عدة مكونات تضبط كلاً منها على حدة. يشرح هذا الدليل تثبيت Stalwart على Ubuntu، ونشر سجلات DNS التي يولدها لك، والشهادة والنسخ الاحتياطي والتحديث.دليلبناء خادم بريد بيدك مع Postfix وDovecot على Ubuntuنبني خادم بريد كاملاً من حزم Ubuntu دون Docker، ونضبط SPF وDKIM وDMARC بأنفسنا ونجرب انتحال النطاق لنرى الرفض بأعيننا، فتعرف دور كل مكون وأين تبحث عندما تتوقف رسالة.دليلترحيل صناديق البريد بين خادمي mailcow عبر الـ APIإذا كنت ستنقل بريد مؤسستك من سيرفر mailcow إلى آخر، فسوف تجد هنا سكربتاً واحداً ينقل كل الصناديق ورسائلها عبر الـ API دون أن تعرف كلمة مرور أي مستخدم، ثم ترتيب تبديل سجل MX بحيث لا تضيع أي رسالة.دليلإرسال بريد خادمك عبر Amazon SES مع mailcow وPostfix وStalwartإذا كان مزودك يحجب المنفذ 25 أو كانت رسائل سيرفرك الجديد تصل إلى Spam، فسوف نرسل البريد الصادر عبر Amazon SES ويبقى الاستقبال والصناديق على سيرفرك، مع DKIM وMAIL FROM وDMARC والارتدادات، والإعداد الدقيق لكل خادم بريد وأي تطبيق.دليلالبريد التفاعلي Transactional Email: كيف تصل رسائل تطبيقك في وقتهارابط استعادة كلمة المرور الذي لا يصل يعني مستخدماً لا يستطيع الدخول، لذلك نشرح ما هو البريد التفاعلي ولماذا تفصله عن النشرات بنطاق وسمعة مستقلين، وكيف ترسله من تطبيقك بطابور وإعادة محاولة، ومتى تختار Amazon SES أو منصة تستضيفها بنفسك مثل Postal.دليلتثبيت Postal لإرسال البريد التفاعلي من تطبيقاتكمنصة إرسال مفتوحة المصدر على سيرفرك تشبه Amazon SES، ترسل منها تطبيقاتك رسائل التسجيل واستعادة كلمة المرور عبر SMTP أو HTTP API. يشرح هذا الدليل تثبيت Postal بالأداة الرسمية، وسجلات DNS التي يطلبها، وWebhooks والنسخ الاحتياطي والتحديث.دليلتثبيت listmonk لإدارة النشرات البريدية على خادمكإذا كانت نشرتك البريدية تخرج اليوم من Gmail بخانة BCC أو من خدمة يرتفع سعرها مع كل مشترك، فسوف نثبت في هذا الدليل listmonk مع PostgreSQL على سيرفرك، ونربطه بمزود SMTP تختاره أنت، ثم نرسل أول حملة ونعالج الرسائل المرتدة، وتبقى قائمة المشتركين لديك.

كيف تبدو منظومة البريد في مؤسستك؟

قبل أن ندخل في القرار، لاحظ أن «خادم البريد» في المؤسسة ليس سيرفراً واحداً معزولاً، وإنما مجموعة أطراف يعتمد بعضها على بعض: المستخدمون يقرؤون بريدهم ويرسلونه من البرامج والهواتف والمتصفح، والسيرفر يستقبل الرسائل من الإنترنت على المنفذ 25 ويوقع الرسائل الصادرة بـ DKIM، وسجلات DNS تخبر سيرفرات العالم أين تسلم بريدك ومن يحق له أن يرسل باسمك، ثم تأتي أطراف لا يراها المستخدم ولكنها تحدد عمر المشروع، وهي النسخ الاحتياطي خارج السيرفر، ودخول الإدارة عبر شبكة خاصة، ومسار مستقل تماماً للنشرات البريدية. والشكل التالي يوضح ذلك:

في المخطط أعلاه لاحظ التالي:

• خادم البريد واحد من ثلاثة خيارات شرحناها، والقرار بينها يأتي بعد قرار أهم، وهو هل تستضيف البريد بنفسك أصلاً.
• الموظفون والطلاب على نطاقين مختلفين، example.com وstudents.example.com، وهذا الفصل يعطيك مرونة كبيرة كما سيأتي في قسم الحلول الوسط.
• سجل PTR يضبط عند مزود السيرفر وليس في لوحة DNS، وهو من أكثر أسباب رفض الرسائل شيوعاً.
• النشرات لا تمر بخادم البريد أبداً، وإنما تخرج من listmonk عبر خادم وسيط SMTP Relay له سمعته Reputation الخاصة ونطاقه الفرعي الخاص.

هل تستضيف بريد مؤسستك بنفسك أصلاً؟

هذا أهم سؤال في الدليل كله، وقد شرحنا في دليل لماذا الاستضافة الذاتية ومتى لا تناسبك أن البريد بالذات ليس الخدمة التي تبدأ بها الاستضافة الذاتية Self-hosting، والسبب أن خطأ في قاعدة معرفة داخلية يزعج فريقك ساعة، أما خطأ في البريد فيعني عقوداً لا تصل وطلاباً لا تصلهم رسائل القبول. لذلك إذا كانت هذه أول خدمة تستضيفها مؤسستك، فابدأ بخدمة أبسط حتى يتعود فريقك على التحديث والنسخ والمراقبة، ثم عد إلى البريد.

متى تكون الاستضافة الذاتية للبريد قراراً صحيحاً؟

• السيادة على البيانات Data Sovereignty والامتثال Compliance: البريد فيه العقود ومراسلات الإدارة وبيانات الطلاب والعملاء، وفي بعض القطاعات مثل الحكومة والتعليم والصحة والمال قد تفرض الأنظمة إبقاء البيانات داخل الدولة أو في بنية معتمدة، وهنا يصبح مكان السيرفر شرطاً وليس تفضيلاً. وفي المملكة تعطي قواعد البرمجيات الحكومية الحرة ومفتوحة المصدر الأفضلية للبرمجيات مفتوحة المصدر في قرار الشراء Procurement، وناقشنا ما يعنيه ذلك للجهات في مقال مستقبل المصادر المفتوحة في القطاع الحكومي، ولكن راجع النص الرسمي ومتطلبات جهتك قبل أي قرار.
• التكلفة لكل صندوق مع العدد الكبير: أغلب خدمات البريد المستضافة تحسب السعر لكل مستخدم في الشهر، وهذا مقبول مع عشرين موظفاً، ولكنه يتحول إلى بند كبير مع مئات الموظفين أو آلاف الطلاب، بينما تكلفة السيرفر لا ترتفع مع كل صندوق جديد بالطريقة نفسها. ولاحظ أن الحساب الصحيح يضم وقت من يدير السيرفر والتخزين والنسخ الاحتياطي، وقد شرحنا طريقة حساب التكلفة الحقيقية Total Cost of Ownership في دليل لماذا الاستضافة الذاتية.
• التحكم Control: أنت من يقرر مدة الاحتفاظ بالرسائل، وحصة Quota كل صندوق، وحدود الإرسال، ومن يدير كل نطاق، دون أن تنتظر خطة أغلى من المزود.
• الاستقلال عن قرارات المزود: كما شرحنا في مقال الاستضافة الذاتية خياراً استراتيجياً، قد يرفع المزود أسعاره أو يغير شروطه أو يوقف الخدمة في بلدك، والبريد هو آخر خدمة تريد أن تكون رهينة لقرار لا تملكه.

ما الذي تتحمله في المقابل؟

وقد يتساءل البعض: إذا كانت البرامج مجانية والسيرفر رخيصاً، فلماذا لا تستضيف كل مؤسسة بريدها بنفسها؟ والإجابة أن ما يدفعه المشترك للمزود هو في الحقيقة ثمن مسؤوليات سوف تنتقل إليك كاملة:

• وصول الرسائل Deliverability: سيرفر جديد ليس له تاريخ إرسال Sending History، فتتعامل معه Gmail وOutlook بحذر، وأي خطأ في PTR أو SPF أو DKIM يعني رسائل في مجلد الرسائل المزعجة أو مرفوضة، وإرشادات Google لمرسلي البريد تنص على هذه المتطلبات صراحة.
• المسؤولية على مدار الساعة: المنفذ 25 مفتوح للعالم كله دون كلمة مرور، فالتحديثات الأمنية Security Updates ليست اختيارية، وعندما يتوقف البريد ليلاً فأنت من يصلحه، وليس فريق دعم لدى مزود.
• الحسابات المسروقة: كلمة مرور موظف واحد تسربت تكفي لأن يرسل المخترق آلاف الرسائل المزعجة من سيرفرك، فيدخل عنوانك قوائم الحظر ويتوقف بريد المؤسسة كلها.
• النسخ والاستعادة: إذا تعطل القرص فلا يوجد مزود يعيد لك الرسائل، وإنما نسختك أنت، وهل جربت استعادتها أم لا.

وبالتالي فالسؤال الصحيح ليس «هل نستطيع التثبيت؟» فالتثبيت يأخذ ساعة، وإنما «هل لدينا شخص مسؤول عن هذا السيرفر، وله وقت كل أسبوع، ومن يحل محله في إجازته؟».

متى يكون البريد المستضاف هو الأنسب؟

• لا يوجد في فريقك من يتابع التحديثات وطابور الرسائل Queue وقوائم الحظر كل أسبوع، والسبب أن خادم بريد لا يتابعه أحد هو خادم سوف يستغله أحد.
• البريد حرج لعملك ولا تحتمل أن يتوقف يوماً بسبب ترقية فشلت أو عنوان دخل قائمة حظر، ولا تملك سيرفراً احتياطياً ومراقبة على مدار الساعة.
• مزودك يحجب المنفذ 25 ولا يسمح بضبط PTR، ولا تستطيع الانتقال إلى مزود آخر.
• كل ما تحتاجه رسائل آلية Transactional Emails من تطبيقاتك، فخدمة إرسال مثل Amazon SES أبسط بكثير من أي خادم بريد.
• في التعليم تحديداً احسب العرض المستضاف بدقة قبل أن تقرر، فمثلاً تقدم Google إصدار Google Workspace for Education Fundamentals دون تكلفة للمؤسسات التعليمية المؤهلة، وهنا لا تكون التكلفة سبباً للاستضافة الذاتية، ويبقى السبب السيادة على البيانات والتحكم إذا كانا يهمانك.

حلول وسط: لا يجب أن يكون القرار كل شيء أو لا شيء

كثير من المؤسسات تتعامل مع القرار كأنه خياران فقط، ولكن DNS يسمح بحلول وسط مفيدة جداً، والسبب أن سجل MX يحدد لكل نطاق أو نطاق فرعي سيرفره الخاص، وبالتالي تستطيع أن تقسم البريد بحسب الفئة أو بحسب نوع الرسائل:

• الموظفون على سيرفرك والطلاب على مزود مستضاف، أو العكس: عندما يكون للموظفين النطاق example.com وللطلاب students.example.com، فلكل منهما سجل MX مستقل، فتبقى مراسلات الإدارة الحساسة على سيرفرك، ويبقى بريد آلاف الطلاب لدى مزود يتحمل حجمه، أو تبدأ بالموظفين وحدهم وتؤجل الطلاب حتى تستقر التجربة.
• البريد اليومي لدى مزود مستضاف، والنشرات من خادمك: إذا كان دافعك الأساسي أن تبقى قوائم المشتركين لديك وألا تدفع لكل جهة اتصال، فاستضف listmonk وحده وأرسل عبر خدمة إرسال، واترك البريد اليومي كما هو.
• الاستقبال على سيرفرك والإرسال عبر خادم وسيط: إذا كان المنفذ 25 الصادر هو المشكلة الوحيدة، فالخيارات الثلاثة التي شرحناها تستطيع أن ترسل عبر خادم وسيط SMTP Relay، فتبقى الصناديق والرسائل على سيرفرك، وعندها اضبط سجلات DNS التي يطلبها الوسيط، وقد شرحنا ذلك خطوة بخطوة في دليل الإرسال عبر Amazon SES.

والصورة التالية تبين الخيارات الثلاثة جنباً إلى جنب، وكيف يقسم سجل MX البريد بين سيرفرك والمزود في الحل الوسط:

ما الذي تجهزه قبل أن تبدأ؟

أغلب مشاريع البريد المتعثرة تتعثر قبل التثبيت، فالمشكلة غالباً مزود يحجب المنفذ 25 أو عنوان IP بسمعة سيئة من مستخدم سابق، ولا يكتشفها أحد إلا بعد أيام من مراجعة الإعداد، لذلك جهز القائمة التالية أولاً:

• النطاق Domain ولوحة DNS: نطاق تملكه وتستطيع تعديل سجلاته، وإذا كانت مصطلحات DNS جديدة عليك فابدأ بـ دليل مصطلحات الاستضافة الذاتية ثم شرح DNS وسجلاته للمبتدئين.
• سيرفر افتراضي VPS عند مزود يسمح بالبريد: المنفذ 25 الصادر مفتوح أو يفتح بطلب، فمثلاً تحجب Hetzner المنفذين 25 و465 على سيرفرات Cloud حتى تطلب فتحهما، وتستطيع ضبط سجل PTR من لوحة المزود، والتقنية الافتراضية Virtualization كاملة مثل KVM لأن mailcow لا يعمل على OpenVZ وLXC، والأسئلة كلها في دليل اختيار خادم VPS.
• ليس من اتصال المنزل أو المكتب العادي: عناوين IP المنزلية مدرجة عادة في قوائم الحظر، وسجل PTR بيد مزود الإنترنت ISP، وقد شرحنا ذلك في دليل تشغيل خادمك من إنترنت المنزل.
• عنوان IP نظيف: افحصه في Spamhaus وMXToolbox قبل أن تبدأ، واطلب عنواناً آخر إذا كان مدرجاً.
• شخص مسؤول، ومن يحل محله: اسم واضح يتابع التحديثات والنسخ والتقارير كل أسبوع، وشخص ثان يعرف أين التوثيق وكلمات المرور في الطوارئ.
• تخزين خارجي Offsite Storage للنسخ الاحتياطي: عند مزود آخر أو في مكان آخر، والسبب أن النسخة على قرص السيرفر نفسه لا تحميك إذا تعطل السيرفر.
• نطاق تجريبي أو نطاق فرعي للتجربة: مثل lab.example.com، حتى تختبر الإرسال والاستقبال دون أن تلمس سجل MX الخاص ببريد المؤسسة.

كم يحتاج السيرفر، وماذا عن الجامعات؟

الموارد Resources تختلف كثيراً بين الخيارات الثلاثة، فـ وثائق mailcow تطلب 6 GiB من الذاكرة RAM على الأقل مع 1 GiB من swap، وتقدر 8 GiB لفريق من 5 إلى 10 مستخدمين، و16 GiB لشركة فيها 15 هاتفاً على ActiveSync ونحو 50 اتصال IMAP متزامن، بينما تذكر صفحة متطلبات Stalwart نحو 1 GB لفريق من 5 إلى 10 مستخدمين، أما Postfix مع Dovecot فيعمل الإعداد الذي بنيناه في دليله على معالج واحد و1 GB لعدد صغير من الصناديق. ولاحظ أن هذه الأرقام كلها لفرق صغيرة، ولا توجد صفحة رسمية لأي من الثلاثة تقول لك كم تحتاج لخمسة آلاف طالب، لذلك لا تقدر الموارد من رقم تجده في منتدى، وإنما من تجربة فعلية كما يلي:

• الاتصالات المتزامنة أهم من عدد الحسابات: وثائق mailcow نفسها تقدر الذاكرة بعدد الهواتف والاتصالات المفتوحة وليس بعدد الصناديق، فجامعة فيها آلاف الحسابات قد لا يفتح بريده منها في الساعة نفسها إلا جزء صغير، وهذا ما تقيسه في المرحلة التجريبية بالأمرين free -h وdocker stats.
• القرص يحسب من الاستخدام الفعلي: الحصة سقف وليست استهلاكاً، فاضرب عدد الحسابات في متوسط ما يستخدمه الصندوق فعلاً، ثم أضف النمو السنوي ومساحة النسخ الاحتياطي، والحصة الافتراضية لكل صندوق في mailcow هي 3 GiB وحدها الأقصى 10 GiB في الإعداد الافتراضي، وتعدلها لكل نطاق ولكل صندوق.
• افصل الفئات بالنطاقات: نطاق للموظفين ونطاق فرعي للطلاب يعطيك لكل فئة حصة وحد إرسال Rate Limit وعدداً أقصى من الصناديق، وفي mailcow تستطيع أن تعين مديراً لكل نطاق Domain Administrator يدير صناديقه دون أن يصل إلى إعدادات السيرفر، وهذا مناسب لكلية أو إدارة تدير حساباتها بنفسها.
• خطط للنمو من البداية: يحفظ Stalwart كل شيء افتراضياً في قاعدة RocksDB المدمجة، ويسمح بنقل مخازن البيانات إلى PostgreSQL أو إلى تخزين متوافق مع S3 في الأنظمة الكبيرة، ولكن تغيير المخزن بعد التشغيل يحتاج إلى ترحيل والسيرفر متوقف، لذلك قرر ذلك قبل أن تنقل آلاف الصناديق.

أي خادم بريد تختار؟

شرحنا ثلاثة خيارات، والثلاثة تستقبل البريد وترسله وتوقعه بـ DKIM وتخدم برامج البريد Mail Clients عبر IMAP، والفرق في من يربط المكونات Components ببعضها وفي ما يراه المستخدم والمدير:

وبالتالي فأغلب الشركات والجامعات والجهات التي تنتقل من خدمة مستضافة سوف تجد أن mailcow هو الأقرب إلى ما اعتاده المستخدمون، وأن Stalwart مناسب عندما يقرأ الجميع من البرامج والهواتف ويقبل الفريق قراءة ملاحظات كل إصدار ثانوي، أما البناء اليدوي فقيمته الكبرى أنه يعلمك ما يحدث داخل الخيارين الآخرين. والتفاصيل كاملة بنقاط القوة ونقاط الضعف في مقارنة mailcow وStalwart وPostfix.

سجلات DNS التي تقرر وصول رسائلك

عندما تصل رسالتك إلى Gmail فإن سيرفرها يقرأ عدة سجلات DNS لنطاقك قبل أن يقرر، وقد شرحنا فكرة كل سجل منها ولماذا يوجد في شرح DNS وسجلاته للمبتدئين وشرح SPF وDKIM وDMARC للمبتدئين، والجدول التالي يلخصها مع مكان شرح كل سجل:

ومنذ فبراير 2024 أصبحت هذه السجلات شرطاً عند Gmail، وقواعد Yahoo مشابهة، وتفاصيل الشروط ولمن تنطبق في شرح SPF وDKIM وDMARC، والخيارات الثلاثة تحقق ذلك إذا نشرت سجلاتها كاملة.

DMARC على مراحل: من none إلى reject

قد يبدو الأسلم أن تبدأ مباشرة بالقيمة p=reject حتى لا ينتحل أحد نطاقك، وهذا ما يولده Stalwart افتراضياً وما يظهر في مثال توثيق mailcow، ولكن خدمات المؤسسة التي ترسل باسم نطاقك دون أن يتذكرها أحد، مثل نظام الرواتب وبوابة القبول، سوف تختفي رسائلها بصمت إذا بدأت بالرفض، وقد شرحنا السبب والمراحل بالتفصيل في شرح SPF وDKIM وDMARC، وباختصار:

1. انشر السجل بالقيمة p=none مع عنوان للتقارير مثل rua=mailto:[email protected]، وأنشئ هذا العنوان فعلاً.
2. اجمع التقارير نحو أسبوعين، وابحث فيها عن كل مصدر يرسل باسم نطاقك، فإذا كان مشروعاً فأضفه إلى سجل SPF ووقع رسائله بـ DKIM، وإذا لم تعرفه فهو غالباً محاولة انتحال.
3. انتقل إلى p=quarantine عندما تجتاز كل رسائلك المشروعة الفحص، ثم إلى p=reject بعد فترة أخرى من التقارير النظيفة.

خطة النقل على مراحل

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

والصورة التالية تبين المراحل الخمس على خط زمني واحد، ومتى يتغير كل سجل ومتى تتوقف المزامنة والمزود القديم:

المرحلة الأولى: تجهيز السيرفر

اختر المزود وتأكد من المنفذ 25 وPTR وسمعة العنوان، ثم أمن السيرفر، ثم ثبت الخيار الذي اخترته بحسب دليله، وتأكد قبل أي شيء أن المنفذ 25 الصادر مفتوح فعلاً بالأمر nc -vz -w 5 gmail-smtp-in.l.google.com 25 من السيرفر نفسه، فإذا انتهت المهلة دون اتصال فالمزود يحجبه، وهذا يوفر عليك ساعات من مراجعة الإعداد.

المرحلة الثانية: تجربة Pilot على نطاق تجريبي ومجموعة صغيرة

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

• أرسل رسائل إلى حسابات في Gmail وOutlook، وافتح الرسالة في Gmail ثم Show original، وتأكد أن نتيجة SPF وDKIM وDMARC هي PASS، وللتقييم الكامل أرسل رسالة إلى أداة مثل mail-tester.com.
• استقبل رسائل من الخارج، وجرب المرفقات الكبيرة، وجرب البرامج التي يستخدمها موظفوك فعلاً على الحاسوب والهاتف.
• جرب النسخ الاحتياطي والاستعادة على سيرفر مؤقت الآن، قبل أن تكون في السيرفر بيانات حقيقية.
• راقب الذاكرة والقرص، فهذه أرقامك أنت لتقدير السيرفر النهائي.

المرحلة الثالثة: مزامنة الصناديق القديمة

قبل الترحيل بيوم على الأقل اخفض قيمة TTL لسجل MX إلى 300 ثانية، والسبب أن السيرفرات الأخرى تحتفظ بالقيمة القديمة في ذاكرتها المؤقتة Cache حتى تنتهي مدتها كما شرحنا في شرح DNS وسجلاته، فإذا خفضتها يوم التبديل نفسه لم يستفد أحد من التخفيض. ثم انقل الرسائل بمزامنة IMAP، فالأداة imapsync تتحدث IMAP مع الطرفين ولا تهتم بما خلفهما، ويشغلها mailcow من الواجهة باسم مهام المزامنة Sync Jobs، ولـ Stalwart أداته Vandelay التي تسحب الحساب من IMAP أو Exchange أو Google Takeout مع التقويم وجهات الاتصال. وقد شرحنا في دليل ترحيل البريد بين خادمي mailcow كيف تنشئ الصناديق ومهام المزامنة لعشرات المستخدمين بسكربت عبر API، دون أن تطلب كلمة مرور أي موظف، وترتيب الخطوات فيه يصلح لأي ترحيل.

المرحلة الرابعة: تبديل سجل MX

عندما تكتمل المزامنة الأولى لكل الصناديق وتقارن عدد الرسائل على الطرفين، اختر وقتاً هادئاً مثل نهاية الأسبوع أو العطلة بين الفصلين الدراسيين، وغير سجل MX ليشير إلى السيرفر الجديد، وتأكد أن SPF وDKIM للسيرفر الجديد منشوران، ثم أبق المزامنة تعمل يوماً أو يومين على الأقل، والسبب أن بعض السيرفرات المرسلة تحتفظ بسجل MX القديم وتعيد المحاولة على المزود القديم. وبعد أن تتوقف الرسائل عن الوصول إلى المزود القديم نفذ مزامنة نهائية ثم أوقفها.

المرحلة الخامسة: ما بعد التبديل

لا تلغ المزود القديم فور التبديل، وإنما أبقه متاحاً للقراءة أسبوعاً على الأقل، وخذ منه نسخة كاملة قبل إلغائه، فإذا اكتشف موظف بعد أيام أن مجلداً ناقصاً فسوف تجده هناك. وبعد ذلك احذف مهام المزامنة وكلمات مرور التطبيقات ومفاتيح API التي أنشأتها للترحيل، فكل منها باب مفتوح إلى بريد المؤسسة، ثم انتقل في DMARC من p=none إلى المراحل التالية كما شرحنا.

ماذا تقول للمستخدمين؟

نجاح الترحيل في نظر الموظفين والطلاب يعني شيئاً واحداً، وهو أنهم لم يشعروا به، لذلك أرسل لهم قبل التبديل بأسبوع رسالة قصيرة واضحة فيها ما يلي:

• موعد التبديل، وأن الرسائل القديمة سوف تكون في الصندوق الجديد.
• طريقة الدخول الجديدة: العنوان الكامل اسماً للمستخدم، وكلمة مرور مؤقتة تصل عبر قناة آمنة ويغيرها عند أول دخول، ثم قيم الإعداد اليدوي إذا لم يعمل الإعداد التلقائي، وهي IMAP على المنفذ 993 وSMTP على 465 أو 587.
• أن لا يعيدوا ترتيب صناديقهم أو يحذفوا الرسائل القديمة حتى تنتهي المزامنة النهائية، والسبب أن المزامنة في اتجاه واحد، فالرسالة التي تحذف أو تنقل على السيرفر الجديد تعود إلى مكانها في الدورة التالية.
• من يتواصلون معه إذا لم يجدوا شيئاً، وأن المزود القديم ما زال متاحاً للقراءة فترة محددة.

إدارة الحسابات من أول يوم إلى آخر يوم

في شركة من عشرين موظفاً تستطيع أن تنشئ الصناديق يدوياً من اللوحة، ولكن في جامعة يدخلها آلاف الطلاب كل عام ويتخرج منها آلاف، تصبح إدارة دورة حياة الحساب Account Lifecycle هي العمل الحقيقي، والسؤال هنا: ما الذي تدعمه الأدوات فعلاً؟

والصورة التالية تبين دورة حياة الحساب من إنشائه إلى إغلاقه، وما تفعله في كل مرحلة:

إنشاء الحسابات بالجملة

• mailcow: تنشئ الصناديق من اللوحة، أو بالجملة عبر ال API كما فعلنا في دليل الترحيل، ومع كل صندوق تحدد الحصة وحد الإرسال، والخيار الذي يلزم المستخدم بتغيير كلمة المرور المؤقتة عند أول دخول، ومن التبويب نفسه تنشئ Aliases توجه الرسائل إلى صندوق أو أكثر، مثل [email protected] لفريق القبول كله.
• Stalwart: تنشئ الحسابات من Directory › Accounts مع العناوين البديلة والحصة والمجموعات Groups والأدوار Roles، وللدفعات الكبيرة يذكر التوثيق الأمر apply في أداة stalwart-cli أو ال API.
• Postfix مع Dovecot: كل صندوق سطر في ملفين نصيين، وهذا مقبول لعشرة صناديق وغير عملي لآلاف، إلا إذا ربطت Dovecot بقاعدة مستخدمين بنفسك.

الدخول الموحد SSO: ما الذي يدعمه كل خادم فعلاً؟

إذا كان لديك دليل مستخدمين User Directory مثل Active Directory أو OpenLDAP، أو نظام دخول موحد مثل authentik، فمن الطبيعي أن تريد ربط البريد به، ولكن الدعم يختلف بين الأدوات، لذلك اقرأ التفاصيل قبل أن تعد المستخدمين بشيء:

• mailcow: يدعم مزود الهوية Identity Provider من System › Configuration › Access › Identity Provider، بثلاثة أنواع: Keycloak وGeneric-OIDC وLDAP. ومع OIDC يدخل المستخدم إلى واجهة mailcow عبر مزود الهوية، وينشئ mailcow صندوقه تلقائياً عند أول دخول إذا طابق أحد قوالب الصناديق Mailbox Templates، ولكن برامج البريد على الحاسوب والهاتف لا تستخدم OIDC هنا، وإنما يحتاج المستخدم إلى أن ينشئ كلمة مرور تطبيق App Password من الواجهة. أما مع LDAP فيستطيع المستخدم الدخول بكلمة مرور الدليل من برامج البريد أيضاً، ويستطيع mailcow أن يستورد المستخدمين ويزامنهم دورياً. ولربط mailcow مع authentik تحديداً يوجد دليل تكامل في موقع authentik بمستوى دعم مجتمعي Community.
• Stalwart: يدعم LDAP وOpenID Connect في الإصدار المجاني، ولكن لاحظ أن OIDC هنا مختلف عن تطبيقات الويب، فبرنامج البريد هو الذي يحصل على التوكن Access Token من مزود الهوية ثم يقدمه لـ Stalwart عبر SASL بالآلية OAUTHBEARER، وبالتالي يحتاج إلى برنامج بريد يدعم ذلك مع مزود هويتك. ويوضح التوثيق أن الحساب لا يعرفه Stalwart مع OIDC حتى يسجل دخوله أول مرة، فالرسائل إليه ترفض قبل ذلك ما لم تنشئ الحسابات مسبقاً، أما مع LDAP فيستعلم من الدليل عند وصول رسالة فيقبلها.
• Postfix مع Dovecot: الإعداد الذي بنيناه يحفظ المستخدمين في ملف، وربط Dovecot بـ LDAP ممكن ولكنه خارج ما شرحناه.

الموظف المغادر والطالب المتخرج

هنا يقع أكثر الأخطاء شيوعاً، فالحساب الذي لا يغلقه أحد يبقى يستقبل الرسائل، وقد تبقى كلمة مروره بيد شخص لم يعد في المؤسسة، ولاحظ أن ربط البريد بدليل المستخدمين لا يحل ذلك وحده، فـ توثيق Stalwart ينص صراحة على أن الإنشاء التلقائي عند الدخول Just-in-time Provisioning لا يحذف شيئاً، فالحساب الذي حذف من الدليل يبقى صندوقه ويستقبل البريد حتى يحذفه المدير، والحل الآلي عنده هو SCIM وهو في الإصدار التجاري. لذلك اكتب إجراء واضحاً للمغادرة يتضمن ما يلي:

• عطل الحساب فوراً، ففي mailcow تستطيع أن تجعل الصندوق غير نشط Inactive من اللوحة دون حذفه، ثم ألغ كلمات مرور التطبيقات الخاصة به.
• قرر مع الإدارة مصير الرسائل: نسخة تحفظ بحسب سياسة الاحتفاظ Retention Policy لديكم، ثم حذف الصندوق، ثم اسم مستعار بالعنوان نفسه يوجه الرسائل إلى زميله أو مديره فترة محددة.
• للطلاب حدد سياسة مكتوبة قبل أن تنشئ أول حساب: هل يبقى البريد بعد التخرج مدة معينة، ومتى يعطل، وكيف ينقل الطالب رسائله قبل ذلك، والسبب أن آلاف الحسابات المتروكة تعني آلاف كلمات المرور التي قد تسرق ومساحة قرص تدفع ثمنها كل شهر.
• العناوين المشتركة مثل info@ وadmissions@ اجعلها أسماء مستعارة أو صناديق تملكها الإدارة وليس شخص بعينه، حتى لا تغادر مع موظف.

تأمين السيرفر والحسابات

خادم البريد هدف دائم، فبعد أيام من تشغيله سوف ترى في السجلات Logs محاولات دخول فاشلة من عناوين في كل مكان، فهذه برامج تجرب كلمات المرور الشائعة على كل خادم بريد تجده، لذلك ابن الحماية في طبقات:

• السيرفر نفسه: مفاتيح SSH بدل كلمات المرور، وجدار حماية Firewall لا يفتح إلا منافذ البريد، والتحديثات الأمنية التلقائية، كما في دليل تأمين خادم VPS.
• التحقق الثنائي Two-Factor Authentication وكلمات مرور التطبيقات: فعل التحقق الثنائي لحساب المدير دون استثناء، ويدعمه mailcow للمستخدمين أيضاً، وعندها يستخدم المستخدم كلمة مرور تطبيق لكل برنامج بريد، وفي Stalwart يدير المستخدم التحقق الثنائي وكلمات مرور التطبيقات من صفحة /account.
• حدود الإرسال Rate Limits وfail2ban: حد إرسال لكل نطاق ولكل صندوق يحمي سمعة سيرفرك إذا سرقت كلمة مرور، وfail2ban يحظر من يخمن كلمات المرور، وقد شرحنا إعداده وحدوده في دليل Postfix وDovecot.
• دخول الإدارة: لا تكشف ال SSH ولا لوحات الإدارة الأخرى على السيرفر للإنترنت، وإنما ضعها خلف شبكة خاصة مع WireGuard، أما واجهة البريد عبر الويب فيصل إليها المستخدمون من الإنترنت بطبيعتها، فاحمها بالتحقق الثنائي.
• التحديث دون تأجيل: اقرأ ملاحظات كل إصدار، وطبق الإصلاحات الأمنية فور صدورها، وراجع إعدادات تأتي معطلة افتراضياً، مثل الإعداد الذي يغلق هجوم تهريب SMTP (SMTP Smuggling) في Postfix 3.8 على Ubuntu 24.04.

النسخ الاحتياطي وتجربة الاستعادة

طبق قاعدة 3-2-1 التي ذكرناها في مقال الاستضافة الذاتية خياراً استراتيجياً: ثلاث نسخ على وسيطين مختلفين، منها نسخة خارج الموقع Off-site، ولكل خيار طريقته:

• mailcow: سكربت النسخ الرسمي ينسخ الرسائل وقاعدة البيانات ومفاتيح التشفير ومفاتيح DKIM والخدمات تعمل، ولا تفصل نسخة vmail عن نسخة crypt لأن الرسائل مشفرة على القرص بمفاتيحها.
• Stalwart: أوقف ال Container ثواني ثم انسخ ال Volumes، واستعد دائماً إلى Volumes فارغة، والسبب أن RocksDB تفسد إذا فككت النسخة فوق بيانات موجودة.
• Postfix مع Dovecot: نسخ /var/vmail و/etc ومفاتيح DKIM بالأمر tar والخدمات تعمل.

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

مراقبة وصول الرسائل

وصول الرسائل ليس أمراً تضبطه مرة ثم تنساه، فعنوانك قد يدخل قائمة حظر بسبب حساب واحد مسروق، وخدمة جديدة في المؤسسة قد تبدأ بالإرسال باسم نطاقك دون أن يخبرك أحد، لذلك خصص وقتاً كل أسبوع لما يلي:

• تقارير DMARC: تصلك يومياً من السيرفرات الكبيرة على العنوان الذي وضعته في rua، وفيها كل مصدر أرسل باسم نطاقك ونتيجة فحصه، وهي التي تخبرك متى تنتقل إلى p=reject.
• تقارير TLS-RPT: إذا فعلت MTA-STS فهذه التقارير تخبرك أن سيرفراً فشل في التسليم إليك عبر TLS، وهذا غالباً شهادة انتهت أو ملف سياسة لم يحدث، حيث يشرح المعياران RFC 8461 وRFC 8460 التفاصيل.
• أدوات المستقبلين الكبار: سجل نطاقك في Postmaster Tools من Google لترى سمعة نطاقك ونسبة الشكاوى في Gmail، وسجل عنوان سيرفرك في Microsoft SNDS لترى كيف يراه Outlook.
• قوائم الحظر وطابور الرسائل: افحص عنوانك في Spamhaus وMXToolbox، وراقب طابور الرسائل الصادرة، فالطابور الذي يكبر فجأة يعني غالباً حساباً مسروقاً يرسل الرسائل المزعجة أو سيرفراً يرفض رسائلك.

لماذا لا ترسل النشرات من خادم البريد الأساسي؟

لنفرض أن الجامعة أرسلت نشرة إلى عشرين ألف خريج من خادم البريد الأساسي، وصنف بعضهم الرسالة رسالة مزعجة، فالنتيجة أن سمعة عنوان IP ونطاق الجامعة تنخفض، وتبدأ رسائل الموظفين اليومية بالوصول إلى مجلد الرسائل المزعجة لدى Gmail، وبالتالي فشكاوى حملة واحدة دفع ثمنها البريد اليومي للمؤسسة كلها. لذلك افصل المسارين تماماً كما في دليل listmonk:

• listmonk يدير القوائم والحملات، وليس خادم بريد، فالإرسال الفعلي يمر عبر خادم وسيط SMTP Relay تختاره، مثل Amazon SES.
• خصص للنشرات نطاقاً فرعياً مثل news.example.com بسجلات SPF وDKIM وDMARC خاصة به، حتى تبقى سمعة النشرات منفصلة عن سمعة البريد الأساسي.
• فعل التأكيد المزدوج Double opt-in للقوائم العامة، ومعالجة الرسائل المرتدة Bounces والشكاوى، ولا تحذف رابط إلغاء الاشتراك، فـ listmonk يضيف ترويسة إلغاء الاشتراك بنقرة واحدة وفق RFC 8058 التي تشترطها Gmail وYahoo على المرسل الكبير.
• أما الرسائل الآلية من تطبيقاتك، مثل استعادة كلمة المرور في authentik أو إشعارات نظام التذاكر، فإما عبر خدمة الإرسال نفسها، وإما من صندوق مخصص مثل [email protected] بكلمة مرور تطبيق وحد إرسال مناسب، كما شرحنا في دليل mailcow.

قائمة التحقق قبل تبديل سجل MX

اطبع هذا الجدول أو انسخه إلى نظام المهام لديكم، ولا تبدل سجل MX حتى تكون كل بنوده منجزة:

خريطة المقالات: ماذا تقرأ وبأي ترتيب؟

إذا كنت تشارك هذا الدليل مع فريقك، فهذا هو الترتيب الذي ننصح به، من القرار إلى التشغيل، مقسماً على خمس خطوات:

القرار: هل تستضيف بريدك بنفسك؟

ابدأ بالأسباب والحالات التي لا تناسبك فيها الاستضافة الذاتية، وطريقة حساب التكلفة الحقيقية، وما يعنيه تقديم المصادر المفتوحة في قرار الشراء للجهات الحكومية:

دليللماذا الاستضافة الذاتية؟ ومتى لا تناسبكهل تستحق الاستضافة الذاتية الجهد الذي تتطلبه؟ يساعدك هذا الدليل على الحكم: متى تمنحك التحكم في بياناتك وتكاليفك، ومتى تصبح عبئاً، وكيف تحسب تكلفتها الحقيقية قبل أن تبدأ.دليلالاستضافة الذاتية (Self-Hosting): متى تصبح خياراً استراتيجياً لأعمالك؟ماذا لو ارتفعت أسعار خدمة تعتمد عليها فجأة، أو توقفت، أو فقدت بياناتك فيها؟ يشرح المقال متى تصبح الاستضافة الذاتية خياراً استراتيجياً لمؤسستك، وكيف تبدأ بها بخطوات صغيرة.دليلقواعد البرمجيات الحكومية مفتوحة المصدر في المملكة: ماذا تعني للجهات والموردين؟قراءة في قرار مجلس الوزراء رقم 14 وقواعد تنظيم البرمجيات الحكومية الحرة ومفتوحة المصدر واستراتيجيتها: ترتيب جديد لقرار الشراء، وعقود تضمن تسليم الشفرة وحقوق إعادة استخدامها، وما يعنيه ذلك للجهات والموردين والمهندسين.دليلمستقبل المصادر المفتوحة في القطاع الحكومي السعودي: من الامتثال إلى بناء القدرةالإطار التنظيمي قائم، والسؤال الأهم: هل تصبح المصادر المفتوحة ثقافة عمل وصناعة وطنية؟ رؤية لثلاثة تحولات متوقعة، والتحديات التي ستحدد النجاح، وما تحتاجه المنظومة من معرفة ومعايير ومجتمعات.

قبل أن تبدأ: المصطلحات والسيرفر

بعد القرار جهز الأساس، من مصطلحات DNS والمنافذ وسجلات DNS وتوثيق البريد، إلى اختيار مزود يفتح المنفذ 25 ويسمح بسجل PTR، ثم تأمين السيرفر وتثبيت Docker:

دليلمصطلحات الاستضافة الذاتية: دليل المبتدئين من الشبكة إلى ال Containersمرجع مبسط لأهم المصطلحات التي ستقابلها في أدلة الاستضافة الذاتية، مثل Reverse Proxy وVolume وCGNAT، بأسمائها الإنجليزية كما تظهر في لوحات التحكم، مع شرح قصير لكل منها.دليلشرح DNS وسجلاته للمبتدئين: A وCNAME وMX وTXT وCAA وPTR بمثال حقيقيكيف يتحول اسم نطاقك إلى عنوان سيرفرك خطوة خطوة، وما وظيفة كل سجل من A وCNAME وMX وTXT وCAA وPTR على سيرفر تستضيفه بنفسك، مع مخرجات حقيقية لأمر dig والأخطاء التي تضيع فيها الساعات عادة.دليلشرح SPF وDKIM وDMARC للمبتدئين: كيف تثبت أن رسائلك منك فعلاًلماذا يستطيع أي شخص أن يرسل باسم نطاقك، وكيف جاء كل من SPF وDKIM وDMARC ليسد ثغرة تركها الذي قبله، مع قراءة السجلات جزءاً جزءاً وطرق اختبار بريدك بالخدمات المجانية.دليلكيف تختار خادماً افتراضياً VPSكم تحتاج من المعالج والذاكرة والقرص؟ وما الذي يميز مزوداً عن آخر غير السعر؟ يساعدك هذا الدليل على اختيار خادم VPS يناسب احتياجك، مع مقارنة بأبرز المزودين القريبين من المنطقة.دليلتشغيل خادمك من إنترنت المنزل: CGNAT وDDNS وCloudflare Tunnelهل يمكنك تشغيل خدماتك من اتصال الإنترنت في منزلك؟ يشرح هذا الدليل كيف تعرف ما يسمح به اتصالك، ومتى يكفي توجيه المنافذ، ولماذا يكون Cloudflare Tunnel غالباً الحل الأسهل والأكثر أماناً.دليلتأمين خادم VPS من أول دخول على Ubuntu 24.04استلمت خادمك للتو؟ قبل أن تثبت عليه أي تطبيق، اتبع هذه الخطوات لإغلاق أبرز الثغرات: الدخول بمفتاح SSH بدلاً من كلمة المرور، وجدار حماية، وتحديثات أمنية تلقائية.دليلتثبيت Docker Engine وDocker Compose على Ubuntu 24.04Docker هو الأساس الذي تعمل عليه معظم التطبيقات التي تستضيفها بنفسك. يشرح هذا الدليل تثبيته على Ubuntu 24.04 من المستودع الرسمي، وضبطه من البداية حتى لا يمتلئ القرص أو تنكشف منافذك للإنترنت.

اختر خادمك وثبته

اقرأ المقارنة أولاً حتى تعرف نقاط القوة ونقاط الضعف في كل خيار، ثم دليل الخادم الذي اخترته:

مقارنةmailcow أم Stalwart أم Postfix مع Dovecot؟ أي خادم بريد يناسبكهل تريد حزمة بريد كاملة ببريد عبر الويب، أم خادماً تبنيه بيدك وتفهم كل سطر فيه، أم برنامجاً واحداً خفيفاً؟ نقارن mailcow وPostfix مع Dovecot وStalwart لتعرف أيها يناسب فريقك وسيرفرك، ومتى يكون البريد المستضاف هو الأنسب.دليلتثبيت خادم البريد mailcow باستخدام Dockerأن تدير خادم بريدك بنفسك يعني أن تضمن وصول رسائلك إلى صندوق الوارد لا إلى الرسائل المزعجة. يشرح هذا الدليل تثبيت mailcow، وضبط سجلات DNS المطلوبة، وحل مشكلات التسليم الشائعة.دليلتثبيت خادم البريد Stalwart باستخدام Docker Composeخادم بريد كامل في برنامج واحد بدل عدة مكونات تضبط كلاً منها على حدة. يشرح هذا الدليل تثبيت Stalwart على Ubuntu، ونشر سجلات DNS التي يولدها لك، والشهادة والنسخ الاحتياطي والتحديث.دليلبناء خادم بريد بيدك مع Postfix وDovecot على Ubuntuنبني خادم بريد كاملاً من حزم Ubuntu دون Docker، ونضبط SPF وDKIM وDMARC بأنفسنا ونجرب انتحال النطاق لنرى الرفض بأعيننا، فتعرف دور كل مكون وأين تبحث عندما تتوقف رسالة.

النقل والتشغيل

عندما يعمل السيرفر انقل الصناديق دون توقف، واجعل دخول الإدارة عبر شبكة خاصة، واربط الحسابات بالدخول الموحد إذا احتجت إليه:

دليلترحيل صناديق البريد بين خادمي mailcow عبر الـ APIإذا كنت ستنقل بريد مؤسستك من سيرفر mailcow إلى آخر، فسوف تجد هنا سكربتاً واحداً ينقل كل الصناديق ورسائلها عبر الـ API دون أن تعرف كلمة مرور أي مستخدم، ثم ترتيب تبديل سجل MX بحيث لا تضيع أي رسالة.دليلشبكة خاصة مع WireGuard وواجهة wg-easyلا تحتاج لوحات الإدارة إلى أن تكون مكشوفة للإنترنت. ننشئ شبكة VPN خاصة باستخدام WireGuard وواجهة wg-easy، ونضيف إليها الأجهزة برمز QR، فلا يصل إلى أدواتك إلا أجهزة فريقك.دليلدخول موحد لجميع تطبيقاتك: تثبيت authentik باستخدام Docker Composeحساب واحد لكل موظف يدخل به إلى جميع تطبيقات الفريق، بدلاً من حساب مستقل في كل خدمة. يشرح هذا الدليل تثبيت authentik وإعداده، وفرض المصادقة الثنائية على المستخدمين.

الإرسال والنشرات

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

دليلإرسال بريد خادمك عبر Amazon SES مع mailcow وPostfix وStalwartإذا كان مزودك يحجب المنفذ 25 أو كانت رسائل سيرفرك الجديد تصل إلى Spam، فسوف نرسل البريد الصادر عبر Amazon SES ويبقى الاستقبال والصناديق على سيرفرك، مع DKIM وMAIL FROM وDMARC والارتدادات، والإعداد الدقيق لكل خادم بريد وأي تطبيق.دليلالبريد التفاعلي Transactional Email: كيف تصل رسائل تطبيقك في وقتهارابط استعادة كلمة المرور الذي لا يصل يعني مستخدماً لا يستطيع الدخول، لذلك نشرح ما هو البريد التفاعلي ولماذا تفصله عن النشرات بنطاق وسمعة مستقلين، وكيف ترسله من تطبيقك بطابور وإعادة محاولة، ومتى تختار Amazon SES أو منصة تستضيفها بنفسك مثل Postal.دليلتثبيت Postal لإرسال البريد التفاعلي من تطبيقاتكمنصة إرسال مفتوحة المصدر على سيرفرك تشبه Amazon SES، ترسل منها تطبيقاتك رسائل التسجيل واستعادة كلمة المرور عبر SMTP أو HTTP API. يشرح هذا الدليل تثبيت Postal بالأداة الرسمية، وسجلات DNS التي يطلبها، وWebhooks والنسخ الاحتياطي والتحديث.دليلتثبيت listmonk لإدارة النشرات البريدية على خادمكإذا كانت نشرتك البريدية تخرج اليوم من Gmail بخانة BCC أو من خدمة يرتفع سعرها مع كل مشترك، فسوف نثبت في هذا الدليل listmonk مع PostgreSQL على سيرفرك، ونربطه بمزود SMTP تختاره أنت، ثم نرسل أول حملة ونعالج الرسائل المرتدة، وتبقى قائمة المشتركين لديك.

الخلاصة

• استضافة البريد بنفسك قرار صحيح عندما يكون السبب واضحاً، سيادة على البيانات أو عدد كبير من الصناديق أو تحكم تحتاجه فعلاً، ومعه شخص مسؤول له وقت أسبوعي، وإلا فالبريد المستضاف هو الأنسب، والحلول الوسط بالنطاقات الفرعية متاحة دائماً.
• تحقق من المزود قبل الأداة: المنفذ 25 الصادر، وسجل PTR، وسمعة العنوان، ثم اختر بين mailcow وStalwart وPostfix مع Dovecot بحسب فريقك ومواردك.
• انشر سجلات DNS كاملة، وابدأ DMARC بالقيمة p=none ثم انتقل بالتدريج، وأبق المزود القديم في SPF حتى ينتهي الانتقال.
• انقل المؤسسة على مراحل: تجربة، ثم مزامنة، ثم تبديل MX بعد تخفيض TTL، ثم فترة يبقى فيها المزود القديم متاحاً، وأخبر المستخدمين بكل خطوة.
• اكتب إجراء دخول الحسابات وخروجها قبل أن تنشئ أول حساب، واعرف ما تدعمه أداتك من LDAP وOIDC وما لا تدعمه، وجرب الاستعادة دورياً، ولا ترسل النشرات من خادم البريد الأساسي.

سجل التحديثات (Changelog)

• أكتوبر 2026: كتابة الدليل اعتماداً على أدلتنا المختبرة لـ mailcow-dockerized 2026-09 وStalwart 0.16.24 وPostfix 3.8.6 مع Dovecot 2.3.21 على Ubuntu 24.04 وlistmonk 6.2.0، مع مراجعة دعم LDAP وOIDC في توثيق mailcow وStalwart.