خادم بريد إلكتروني خاص على VPS: المنفذ 25 وسجل PTR ولماذا يصل بريدك إلى المزعج

ما الذي يقرره المستقبِل فعليًا، وبأي ترتيب

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

يحدث القرار الأول عند اتصال TCP: من هذا، وهل يستحق الحديث معه أصلًا؟ في هذه اللحظة يملك المستقبِل عنوان IP الخاص بك، وسجل DNS العكسي له، وأي سمعة يُلصقها به هو أو مزودو قوائم الحظر التي يستخدمها. القرار الثاني يحدث عند مغلّف SMTP — HELO وMAIL FROM — حيث يُقيَّم SPF مقابل عنوان IP المتصل. أما الثالث فيصل مع بيانات الرسالة، حيث يُتحقق من توقيعات DKIM ويقرر DMARC ما إذا كانت نتيجة أي من التوثيقين متوافقة مع النطاق الظاهر في ترويسة From:. ولا يبدأ ما يشبه تصفية المحتوى إلا بعد كل ذلك، وعندها تكون معظم النتيجة قد حُسمت بالفعل.

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

المنفذ 25 هو أرخص جزء في المشكلة

تحجب كل سحابة كبيرة تقريبًا المنفذ 25 الصادر افتراضيًا، وفك الحجب يعني تقديم طلب. توفَّر AWS وGoogle Cloud وAzure وOracle Cloud ومعظم علامات VPS الكبرى بترشيح للمنفذ 25 الصادر، وطلب الإلغاء هو نموذج مرتبط بحساب يحمل أصلًا هويتك وبطاقتك ورقم هاتفك. هنا تموت خطة الاستضافة الذاتية بصمت في أغلب الأحيان، ولهذا فإن أكثر عبارات البحث التي تجلب الناس إلى صفحة كهذه هي نسخة من أي VPS يفتح المنفذ 25.

من المفيد أن تكون دقيقًا بشأن وظيفة كل منفذ، لأن الثلاثة يُخلط بينها باستمرار. المنفذ 25 هو اتصال خادم بخادم: هكذا يسلّم خادم MX رسالة إلى آخر، ولا يُوثَّق فيه المرسل أبدًا، وهو المنفذ الوحيد المهم لتسليم البريد إلى أشخاص ليسوا مستخدميك. المنفذ 587 هو منفذ الإرسال — حيث يُوثِّق عملاؤك أنفسهم لدى خادمك قبل أن يقوم بترحيل رسائلهم. المنفذ 465 هو الشيء نفسه مع TLS منذ البايت الأول؛ أُهمل في التسعينيات ثم أعاده رسميًا RFC 8314، وهو الخيار الافتراضي المعقول اليوم. فقدان المنفذ 25 الصادر يمنعك من الإرسال إلى العالم؛ وفقدان المنفذ 25 الوارد يمنع العالم من إرسال رسائل إليك، ومن الممكن تمامًا أن يتعطل أحدهما دون الآخر فتقضي بعد ظهر كامل تلوم فيه DNS.

على BitVPS، المنفذ 25 الصادر غير محجوب افتراضيًا في كل خطة وكل موقع. لا يوجد نموذج ولا إجراء استثناء لأنه لا يوجد ما يُرفع أصلًا. أما المنافذ 25 و465 و587 الواردة فتقع خلف تنقية واعية ببروتوكول البريد بدلًا من مرشّح عام على الطبقة الثالثة، وهذا هو الفرق المهم أثناء أي هجوم: المرشّح الذي يفهم SMTP يستطيع امتصاص الفيضان دون أن يُسقط معه محادثة MX المشروعة. تجد التفاصيل في صفحة خادم البريد، ويشرح دليل الحماية من DDoS ما تعنيه التنقية وما لا تعنيه بشكل عام.

فتح المنفذ 25 شرط ضروري لكنه أبعد ما يكون عن كونه شرطًا كافيًا — وهذا بالضبط سبب استمرار هذا الدليل لنحو ثلاثة آلاف كلمة أخرى.

العنوان الذي يُمنح لك يقرر أكثر مما تقرره إعداداتك

إعداداتك ليست سوى حفنة سجلات DNS ويوم عمل واحد. أما عنوان IP فهو تاريخ لم تكتبه أنت. نطاق /24 قضى عام 2019 يرسل بريد صيدليات مزعج يبقى في الذاكرة؛ وعنوان أُعيد تدويره من عميل أُنهي حسابه الشهر الماضي يصلك محكومًا عليه سلفًا؛ ونطاق جيرانه صاخبون يُحكم عليه بالتبعية عند مستقبِلين يقيّمون السمعة على مستوى /24 كاملًا. لا شيء من هذا مرئي من داخل الجهاز، ولا شيء منه يستجيب لملف main.cf أفضل.

لذا تحقق قبل الالتزام لا بعده. قوائم الحظر العامة تخبرك بجزء من القصة: Spamhaus هي التي تؤثر فعليًا في التسليم، حيث تسرد SBL وCSS مرسلين رُصدوا فعلًا، وتسرد PBL نطاقات أعلن مشغّلها أنها لا ينبغي أن ترسل بريدًا مباشرة، بينما تسرد DBL نطاقات لا عناوين. يستحق Barracuda وSpamCop نظرة، وسرعان ما يُزال الإدراج فيهما بمجرد إصلاح السبب. أما السمعتان اللتان تحسمان معظم نتيجتك فخاصتان: تحتفظ Google وMicrosoft كل منهما بتقييم لكل IP ولكل نطاق لا يمكنك الاستعلام عنه إطلاقًا إلا عبر Postmaster Tools وSNDS، وفقط بعد أن ترسل ما يكفي ليتكوّن لديهما رأي.

تحذيران بشأن قوائم التحقق التي ستجدها في أماكن أخرى. لا يزال نصفها ينصحك بفحص SORBS: أوقف مالك SORBS الخدمة في 5 يونيو 2024 وباتت نطاقاته لا تجيب بشيء الآن، فالاستعلام عنها ليس شهادة نظافة بل استعلامًا ميتًا. وتعامل مع المستويين 2 و3 من UCEPROTECT بحذر — فهما يسردان الجيران وأنظمة مستقلة كاملة بالتبعية ثم يدعوانك لدفع رسوم إزالة عاجلة، وهذا ما يجعل معظم المستقبِلين الجادين يتجاهلانهما. مطاردة إدراج في المستوى 3 طريقة لإضاعة عطلة أسبوع كاملة دون تحقيق شيء. أما بوابة السمعة الخاصة بـSpamhaus فهي التي يجب أخذها على محمل الجد.

هذا أيضًا هو الجزء الذي يُظهر فيه المضيف نفعه من عدمه. يفحص BitVPS كل عنوان مقابل القوائم الرئيسية عند التزويد ويستبدله قبل أن تسجّل الدخول أصلًا إذا ظهر في إحداها، ويخصّص لعملاء البريد نطاقات /29 لم يُعَد تدويرها من عميل بريد سابق خلال اثني عشر شهرًا، وينقل /29 بين أجهزة في مركز البيانات نفسه دون تغيير عنوانك — وهو أمر بالغ الأهمية بمجرد أن يكتسب العنوان سمعة أمضيت ستة أشهر تبنيها. لا شيء من هذا يجعل العنوان جيدًا؛ بل يجعله محايدًا، وهذا أقصى ما يمكن لأي مضيف أن يقدمه بصدق.

يجب أن يروي PTR وHELO وسجل A القصة نفسها

هذا هو السبب الأكثر شيوعًا على الإطلاق لرفض خادم بريد مثبّت بكفاءة، وهو أرخص شيء يمكن إصلاحه في هذه الصفحة. يجب أن تتفق ثلاثة أسماء. خادمك يعلن اسم مضيف في HELO؛ ولاسم المضيف هذا سجل A يشير إلى العنوان الذي يتصل منه؛ ولهذا العنوان سجل PTR يشير عودة إلى اسم المضيف. حلّله إلى الأمام فتصل إلى العنوان؛ وحلّله إلى الخلف فتصل إلى الاسم. تُسمى هذه الرحلة الدائرية DNS العكسي المؤكَّد أماميًا، ومنذ فبراير 2024 لم يعد سجل PTR الصحيح ترفًا لدى Gmail بل شرطًا معلنًا على كل مرسل، سواء كان مرسلًا جماعيًا أم لا.

أربع طرق يحدث بها الخلل، بترتيب تنازلي حسب التكرار. لا يوجد سجل PTR إطلاقًا، لأن المضيف لا يوفر هذا الحقل أصلًا. أو يوجد سجل PTR لكنه العام التابع لمزود الخدمة — شيء ينتهي بنطاق شركة الاستضافة، وهو ما يعلن لكل مستقبِل أن هذا عنوان مؤجَّر في نطاق لا يرسل البريد غالبًا. أو يكون اسم HELO خاطئًا: الافتراضي من برنامج التثبيت، أو اسم مضيف قصير غير مؤهَّل، أو localhost، ولا شيء من هذه يُحلَّل. وأخيرًا ما يوقع حتى الحذرين: يملك الجهاز IPv6، ويفضّل عميل النقل استخدام IPv6 عندما ينشر المستقبِل سجل AAAA، ولا يوجد سجل PTR على عنوان v6 — فيعمل البريد إلى Gmail عبر IPv4 بشكل مثالي بينما تُرفض الرسالة نفسها عبر IPv6. إما أن تضبط PTR الخاص بـv6 بشكل صحيح، أو تُثبّت النقل على smtp_address_preference = ipv4 إلى حين ذلك.

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

SPF وDKIM وDMARC: ما الذي يثبته كل منها، وما معنى التوافق

تُنشر هذه الثلاثة كسجلات DNS، ويستغرق إعدادها ساعة واحدة، ويُساء وصفها في كل مكان تقريبًا — إذ تُقدَّم عادة كثلاث تعويذات متبادلة ضد البريد المزعج بدلًا من كونها ثلاثة تأكيدات مختلفة تمامًا. يحدد SPF (RFC 7208) أي العناوين يمكنها إرسال بريد يحمل مُرسِل مغلّف معيّن. أما DKIM (RFC 6376) فيرفق توقيعًا تشفيريًا على الترويسات والمتن، بحيث تستطيع الرسالة إثبات أي نطاق تحمّل مسؤوليتها. ولا يقول أي منهما شيئًا عن العنوان الذي يراه المستلِم فعليًا.

هذه هي مهمة DMARC (RFC 7489)، ولهذا فإن كلمة التوافق هي الكلمة المهمة. ينجح DMARC عندما ينجح SPF أو DKIM ويتطابق النطاق الذي وثّقه مع النطاق الظاهر في ترويسة From:. هنا يكمن الفشل الكلاسيكي: بريدك ينجح في SPF لأن عنوان الارتداد على نطاق يتحكم فيه خادم الإرسال، لكن هذا النطاق ليس هو نفسه الظاهر في From:، فلا يتحقق التوافق، وبلا توقيع DKIM يُعتمد عليه، يفشل DMARC في رسالة بدت موثّقة تمامًا في السجلات. أما الخطأ الكلاسيكي الآخر فهو نشر p=reject في اليوم الأول، قبل قراءة تقرير واحد، ثم اكتشاف بعد شهر أن نظام الفوترة كان يُرفض بصمت طوال الوقت. ابدأ بـp=none مع عنوان rua، واقرأ ما يصل، ثم شدّد لاحقًا.

ملاحظتان تشغيليتان أهم مما تبدوان عليه. أبقِ سجل SPF ضمن عشرة استعلامات DNS — فكل include: يكلّف استعلامًا واحدًا، وتضمين ثلاثة مزودي SaaS متداخلين يتجاوز الحد ويتحول إلى خطأ دائم بدلًا من فشل بسيط. ودوِّر محدِّدات DKIM بين حين وآخر بدلًا من عدم تدويرها إطلاقًا: إضافة محدِّد رخيصة، ووجود محدِّد ثانٍ منشور مسبقًا هو الفارق بين تدوير مفتاح يستغرق خمس دقائق وانقطاع كامل للخدمة.

تغيّر الحد الأدنى في 2024، ومرة أخرى في 2025

لعشرين عامًا كان الحد الأدنى لإرسال البريد تقريبًا "امتلك سجل PTR ولا تكن مُدرَجًا على Spamhaus". تغيّر هذا في فبراير 2024، حين نشرت Google وYahoo متطلبات مرسلين شبه متطابقة وبدأتا في فرضها. كل مرسل — بما في ذلك أنت، حتى لو كنت ترسل أربع رسائل يوميًا فقط — يحتاج الآن إلى سجل PTR صحيح ومؤكَّد أماميًا، وTLS على الاتصال، وواحد على الأقل من SPF أو DKIM. أما المرسلون الذين يتجاوزون نحو خمسة آلاف رسالة يوميًا إلى مستقبِل واحد فيحتاجون SPF وDKIM وسجل DMARC، وترويسة إلغاء اشتراك بنقرة واحدة فعّالة وفق RFC 8058، ومعدل شكاوى بريد مزعج أقل من 0.3%.

لحقت بها Microsoft في 5 مايو 2025 بقاعدة من الشكل نفسه لـOutlook.com وHotmail وLive: النطاقات التي ترسل أكثر من خمسة آلاف رسالة يوميًا إلى صناديق المستهلكين هذه يجب أن تملك SPF وDKIM وDMARC، مع توجيه البريد غير الملتزم إلى المزعج أولًا ثم رفضه صراحة لاحقًا. يستحق كل من دعم مرسلي Microsoft وأفضل ممارسات Yahoo عشر دقائق من القراءة قبل أن ترسل أي شيء.

النتيجة العملية لخادم شخصي أو خادم فريق صغير ليست أن هذه الحدود ستطالك — فلن تطالك — بل أن الوضع الافتراضي غير الموثَّق أصبح الآن شاذًا فعلًا. بريد بلا سجل DMARC من عنوان بلا سجل تاريخي كان أمرًا عاديًا فيما مضى. في 2026 بات يشبه تمامًا الملف الذي صُممت المرشحات لإيقافه. اضبط إعداداتك كأنك مرسل جماعي حتى لو لم تكن كذلك، لأن التكلفة بعد ظهر واحد فقط والبديل أن تُقيَّم ضمن فئة لا تنتمي إليها.

تسخين عنوان لم يره أحد من قبل

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

قِس الأمر بالأدوات التي يوفرها المستقبِلون أنفسهم، لا بالنظر إلى صندوق واردك. تعرض Postmaster Tools من Google سمعة النطاق وIP ومعدلات شكاوى البريد المزعج ومعدلات نجاح التوثيق بمجرد التحقق من ملكية النطاق — رغم أنها تبقى فارغة إلى أن ترسل ما يكفي لتجميع أي بيانات، وهو ما قد يعني أبدًا بالنسبة لخادم شخصي، ولا بأس في ذلك. تقدم SNDS من Microsoft الشيء نفسه لـOutlook.com وتقترن ببرنامج الإبلاغ عن البريد المزعج الذي يحيل الشكاوى إليك مباشرة. أما خدمة التقييم السريع فمفيدة لاكتشاف سجل معطوب خلال عشر ثوانٍ، وعديمة الفائدة فيما عدا ذلك — فهي لا تخبرك بشيء عن السمعة، لأنها هي الأخرى لا تملك سجلًا تاريخيًا معك.

كن صريحًا مع نفسك بشأن أصعب مستقبِل. Outlook.com هو المكان الذي يعاني فيه العنوان الجديد أطول مدة: من الشائع أن يُصنَّف خادم مضبوط بشكل صحيح وموثَّق توثيقًا مثاليًا ضمن المزعج هناك لأسابيع بينما تقبله Gmail من أول رسالة. الحل هو الوقت والاستمرارية ومستلمون ينقلون الرسالة خارج المزعج — لا سجل DNS إضافي آخر. وإذا كانت قابلية التسليم إلى Outlook.com من اليوم الأول متطلبًا تجاريًا لا مجرد تفضيل، فهذه إحدى الإشارات إلى أنك تريد ترحيلًا (relay) لا مرسلًا ذاتي الاستضافة، وهو موضوع القسم الأخير.

ماذا تشغّل، وما حجم الجهاز الذي يحتاجه

أربعة خيارات تغطي كل الحالات تقريبًا. الجمع بين Postfix وDovecot لـIMAP وrspamd للتصفية هو النشر المرجعي: ثلاث خدمات، وإعدادات نصية بسيطة، وكل رسالة خطأ ستراها لها إجابة منشورة في مكان ما بالفعل. يقوم OpenSMTPD بالمهمة نفسها بملف إعداد يمكنك قراءته في جلسة واحدة، وهذا يساوي أكثر مما يبدو عليه الساعة الثالثة فجرًا. أما Stalwart فهو ملف تنفيذي واحد يتحدث SMTP وIMAP وJMAP مع تصفية مدمجة، وهو الخيار الأمتع اليوم لمن يبدأ من الصفر. أما Mailcow أو Mail-in-a-Box فيجمّعان لك كل شيء، بما في ذلك بريد الويب، لكن بثمن حزمة لم تخترها أنت ولا يسهل تفكيكها.

تحديد الحجم لا يتعلق بعدد صناديق البريد بقدر ما يتعلق بما تضيفه أمامها. SMTP وIMAP نفسهما رخيصان؛ بضع عشرات من صناديق البريد لا تُذكر على أي جهاز حديث. الذاكرة تذهب إلى التصفية. rspamd متواضع، بضع مئات من الميغابايت مع تحميل خرائطه. أما ClamAV فلا: قاعدة بيانات التوقيعات وحدها تتجاوز به غيغابايتًا كاملًا من الذاكرة المقيمة، وهو المكوّن الأوحد الأكثر احتمالًا لدفع نسخة صغيرة إلى بدء المبادلة (swapping) — وهو ما يعني على خادم بريد أن الطابور يتراكم ويتباطأ التسليم إلى درجة أن المستقبِلين يبدؤون بتأجيل رسائلك. شغّله إن كانت لديك ذاكرة كافية، وتجاوزه إن لم تكن، ودع rspamd يتحمّل العبء.

بترجمة ذلك إلى خطط حقيقية: خطة Starter بسعر $8.50 بمعالج 2 vCPU وذاكرة 4 GB وتخزين NVMe سعة 60 GB تشغّل Postfix وDovecot وrspamd بارتياح لنطاق شخصي، شريطة استبعاد ClamAV. أما خطة Growth بسعر $13.50 بمعالج 4 vCPU وذاكرة 8 GB وتخزين 120 GB فهي الحجم الذي تتوقف عنده عن التفكير في الأمر — من عشرين إلى ثلاثين صندوق بريد مع تصفية كاملة، ومساحة فائضة تكفي مخزن بريد ينمو لسنوات. التخزين هو المحور الذي ينفد فعليًا أولًا، لأن البريد يُحفظ إلى الأبد لدى كل من استلم أيًا منه ولو مرة.

تشغيله بالترتيب الصحيح

1. وجّه النطاق وأنشئ النسخة. حدد اسم المضيف الذي سيعرّف الخادم نفسه به — العرف الشائع هو mail.example.com — وانشر سجل A الخاص به، وأضف AAAA فقط إذا كنت تنوي الإرسال عبر IPv6، وانشر سجل MX للنطاق يشير إلى هذا الاسم. اختر الموقع الأقرب إلى من تراسلهم؛ على BitVPS تصبح النسخة جاهزة خلال نحو ستين ثانية بعد تأكيد الدفع، والمنفذ 25 الصادر مفتوح مسبقًا.

2. اضبط DNS العكسي ليطابقه. اضبط PTR لعنوان IPv4 — ولعنوان IPv6 أيضًا إن نشرت سجل AAAA — ليكون تحديدًا اسم المضيف من الخطوة الأولى. يجب أن يتطابق الأمامي والعكسي في كلا الاتجاهين. هذا حقل واحد في لوحة التحكم، وهو الدقيقة الأعلى قيمة في الإجراء بأكمله.

3. افتح المنافذ الصحيحة في الاتجاهين. المنفذ 25 صادرًا للتسليم، و25 واردًا للاستقبال، و587 و465 لإرسال مستخدميك، و993 لـIMAP، وكل شيء آخر مغلق. جدار حماية يسمح بالمنفذ 25 صادرًا لكن لا يسمح به واردًا يبدو تمامًا كمشكلة DNS خلال الساعة الأولى من التشخيص، وهو ليس كذلك.

4. ثبّت خادم البريد (MTA) وامنحه هوية حقيقية. Postfix أو OpenSMTPD أو Stalwart؛ اضبط اسم HELO على اسم المضيف من الخطوة الأولى؛ فعّل TLS بشهادة لهذا الاسم. Let's Encrypt مجاني وهو ما يقدمه معظم الإنترنت. أرسل رسالة إلى نفسك واقرأ الترويسات قبل المتابعة — كل خطوة لاحقة تفترض أن هذه الخطوة نجحت.

5. انشر SPF وDKIM وDMARC. سجل SPF يسرد عنوان الإرسال، ينتهي بـ~all أثناء الاختبار. مفتاح DKIM بطول 2048-bit مع نشر محدِّده وتفعيل التوقيع. سجل DMARC عند p=none مع عنوان rua كي تبدأ التقارير بالوصول. ثلاثة سجلات DNS، بلا تكلفة، وساعة واحدة على الأكثر.

6. اقرأ نتائج التوثيق، لا صندوق الوارد. أرسل إلى Gmail وإلى Outlook.com وإلى مستقبِل مؤسسي واحد، ثم افتح Authentication-Results في كل منها. تريد أن ترى spf=pass وdkim=pass وdmarc=pass، وأن يكون التوافق مع النطاق الظاهر في From:. الوقوع في المزعج مع ثلاثة نجاحات مشكلة سمعة؛ والوقوع في المزعج مع فشل واحد مشكلة إعداد. تُصلَحان بطريقتين مختلفتين تمامًا، والخلط بينهما يهدر أسابيع.

7. شدّد السياسة بمجرد أن تصبح التقارير نظيفة. بعد أسبوع أو أسبوعين من تقارير DMARC التي لا يفشل فيها أي مصدر شرعي، انتقل إلى p=quarantine، ثم لاحقًا إلى p=reject، وغيّر SPF من ~all إلى -all. التشديد قبل قراءة التقارير هو الطريقة التي يحجب بها الناس فواتيرهم الخاصة لشهر كامل دون أن يلاحظوا.

8. أضف الأجزاء التي ينساها الجميع. انشر MTA-STS وTLS-RPT كي يعرف المرسلون الآخرون أن عليهم الإصرار على TLS معك، وأضف DANE إذا كان نطاقك موقَّعًا، وضع rspamd أمام صندوق الوارد، وانسخ مخزن البريد احتياطيًا إلى مكان غير هذا الجهاز، وشفّره أثناء التخزين — يغطي دليل تشفير القرص الكامل ما يحميه ذلك وما لا يحميه. ثم راقب طابور الصادر: طابور ينمو بصمت هو أول عرض لمشكلة سمعة، ويظهر قبل أيام من ملاحظتك غياب الردود.

متى تكون الاستضافة الذاتية الأداة الخاطئة

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

توجد أيضًا مقايضة تتعلق بإخفاء الهوية يتجاهلها معظم من يكتب عن الموضوع. خادم البريد هو أقل شيء يمكنك تشغيله من حيث إخفاء الهوية. فهو ينشر نطاقًا، وعنوانًا ثابتًا، وسجل PTR يسمّي ذلك النطاق، وسجل MX يربطهما معًا، ويسلّم كل مستلِم مجموعة كاملة من الترويسات التي تصف المسار. إخفاء الهوية وMX عام يشدّان في اتجاهين متعاكسين، وإذا كان سبب وجودك هنا هو الخصوصية لا التحكم، فاقرأ إلى أي مدى يمكن تعقب استضافة العملات المشفرة فعليًا قبل أن تبني أي شيء. الاستضافة الذاتية تزيل فعلًا طرفًا ثالثًا من بريدك المخزَّن وبياناته الوصفية، وهذا مكسب حقيقي يستحق العناء — لكنها لا تجعل البريد نفسه مجهول الهوية، ولا يمكنها ذلك، لأن نصف كل محادثة يعيش في صندوق بريد شخص آخر.

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