إرسال البريد من تطبيقاتك ذاتية الاستضافة عبر SMTP

ما تحتاج إليه التطبيقات ذاتية الاستضافة لإرسال البريد

لإرسال البريد من التطبيقات ذاتية الاستضافة، لا تحتاج إلى خادم بريد. تحتاج إلى relay: حساب SMTP واحد موثّق، تُعدّه مرة واحدة على المضيف، ثم تسلّم إليه كل التطبيقات الموجودة على الخادم رسائلها الصادرة. تشغيل mailbox هو المشكلة الأصعب، وهي مشكلة مختلفة.

يعني استقبال البريد قبول الاتصالات من كامل الإنترنت على المنفذ 25، وتصفية الرسائل المزعجة، وتخزين mailboxes ونسخها احتياطياً، والحفاظ على سمعة عنوان IP طوال فترة تشغيل الخادم. أصبحت هذه المهمة أصعب فعلاً. أما إرسال البريد فيعني رسائل إعادة تعيين كلمة المرور، وتأكيد التسجيل، وتنبيه "فشل النسخ الاحتياطي"، وإشعار الرد في المنتدى. هذه الرسائل قصيرة ومنخفضة الحجم، وتُرسل واحدة تلو الأخرى. يتولى relay التعامل معها، ويستغرق إعداده فترة بعد الظهر.

حدد أيّاً من المشكلتين تحاول حلّه فعلياً. ما إذا كان تشغيل mailbox خاص بك لا يزال يستحق ذلك سؤال حقيقي وله إجابة حقيقية، والإجابة بالنسبة إلى معظم الأشخاص هي لا. إذا كانت إجابتك نعم، فإن خادم Mailcow كامل للبريد على VPS هو المسار الصريح. أما النصف الآخر، أي الإرسال، فهو ما يحتاج إليه الجميع تقريباً ولا يخطط له أحد تقريباً.

لنبدأ بمصطلحين. SMTP (بروتوكول نقل البريد البسيط) هو البروتوكول الذي تستخدمه جميع أجزاء هذه العملية. أما relay، ويُسمى أيضاً smarthost، فهو خادم يقبل بريدك الموثّق ثم يسلّمه إلى وجهته باستخدام عناوينه وسمعته الخاصة.

لماذا لا يستطيع VPS لديك تسليم البريد عبر المنفذ 25

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

اختبر ذلك من الخادم:

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

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

الحظر ليس السبب الرئيسي لاستخدام relay. حتى عند فتح المنفذ 25، تصل الرسائل المرسلة مباشرة من عنوان VPS جديد إلى مجلد الرسائل المزعجة أو تُرفض بالكامل، لأن هذا العنوان لا يملك سجل إرسال، ولأنه يقع ضمن نطاق يتعامل معه مستلمو البريد على أنه نطاق استضافة. تتطلب إرشادات Google للمرسل وجود DNS أمامي وعكسي صالحين لعنوان IP المرسل، كما تستخدم عناوين VPS كثيرة سجل PTR عاماً لا يمكنك تغييره. يمنحك relay عناوين تملك سجلاً سابقاً.

منافذ الإرسال هي الحل. ينقل المنفذ 587 بروتوكول STARTTLS، حيث تبدأ الجلسة بنص واضح ثم تتم ترقيتها. وينقل المنفذ 465 بروتوكول TLS الضمني (أمان طبقة النقل)، حيث تُشفَّر الجلسة منذ البايت الأول. صُمّم كلا المنفذين للعمل مع العملاء الموثَّقين، وكلاهما مفتوح على شبكات VPS، ويدعم relay لديك واحداً منهما على الأقل.

اختر مرحّل البريد ونطاقاً فرعياً للإرسال

توجد العديد من موفّري البريد للرسائل المعاملاتية، وهم يؤدّون الوظيفة نفسها. قيّمهم وفق أربعة أمور:

• منفذ إرسال، 587 أو 465، مع SMTP AUTH
• توقيع DKIM باستخدام نطاقك ومحدّدك الخاصين، وليس باستخدام محدّد الموفّر وحده
• بيانات الارتداد والشكاوى التي يمكنك قراءتها، عبر لوحة المعلومات أو webhook
• فئة تناسب حجم الإرسال لديك. حتى أغسطس 2026، ما زال بعض الموفّرين يتيحون بضعة آلاف من الرسائل شهرياً مجاناً، لكن هذه الشروط تتغير كثيراً؛ لذلك راجع صفحة الأسعار الحالية بدلاً من الاعتماد على أي تدوينة

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

اضبط مرحِّل البريد مرة واحدة لكل تطبيق مستضاف ذاتياً

الطريقة السهلة ظاهرياً هي فتح صفحة إعدادات كل تطبيق ولصق مضيف SMTP واسم المستخدم وكلمة المرور فيها. يوفّر Nextcloud والمنتدى وGrafana وVaultwarden ومراقب التوافر هذه الخانات. إذا فعلت ذلك، ستصبح بيانات الاعتماد موجودة في ستة أماكن وبستة تنسيقات، ويكون بعضها داخل قاعدة بيانات تنسخها احتياطياً بوصفها بيانات لا إعدادات. وعندما تغيّر كلمة المرور، ستحدّث خمسة أماكن منها. أما السادس فسيتوقف عن الإرسال بصمت، لأن معظم التطبيقات تسجل خطأ SMTP على الخادم، لكنها تعرض للمستخدم صفحة نجاح.

اضبطه مرة واحدة على المضيف بدلاً من ذلك، ودع التطبيقات ترسل محلياً. توجد أداتان مناسبتان لهذا الغرض، والاختيار بينهما يعتمد على التخزين المؤقت للرسائل.

msmtp هو عميل متوافق مع sendmail ولا يعمل كخدمة daemon. يتصل ويرسل ثم ينهي عمله. لا يضع الرسائل في قائمة انتظار، لذلك إذا تعذر الوصول إلى المرحّل تضيع الرسالة، ويحصل التطبيق المستدعي على حالة خروج غير صفرية.

أما Postfix المضبوط بوصفه satellite فهو وكيل نقل بريد كامل مع قائمة انتظار فعلية. يقبل الرسالة فوراً، ويعيد المحاولة لأيام عند الفشل، ويحتفظ ببيانات اعتماد المرحّل في ملف لا يقرأه إلا root. استخدمه عندما يكون فقدان تنبيه أثناء تعطل المرحّل أمراً مهماً، أو عندما تعمل عدة تطبيقات باستخدام مستخدمين مختلفين للنظام.

msmtp، الخيار الصغير

sudo apt update
sudo apt install -y msmtp msmtp-mta ca-certificates

يثبّت msmtp-mta الرابط الرمزي /usr/sbin/sendmail، ولذلك فإن أي شيء يستدعي sendmail يصل إلى msmtp من دون أن يعرف بوجوده.

اكتب /etc/msmtprc:

defaults
auth            on
tls             on
tls_trust_file  /etc/ssl/certs/ca-certificates.crt
syslog          on

account         relay
host            smtp.relay.example
port            587
from            apps@notify.example.com
set_from_header on
user            <relay username>
password        <relay password>

account default : relay

يضبط set_from_header on دائماً ترويسة From ويتجاوز أي ترويسة موجودة، ولذلك يستبدل ما أنشأه التطبيق بالعنوان الموجود في from. من دونه، ترسل مهمة cron الرسالة باسم root@your-hostname، ويرفض المرحّل ذلك لأنه ليس عنواناً تحققت منه. يرسل syslog on السجل عبر syslog، ولذلك تقرأه باستخدام journalctl -t msmtp. والمسار المشترك logfile بديل، لكنه يحتاج إلى إذن كتابة لكل مستخدم يرسل البريد، وهذا مصدر مشكلة على خادم متعدد المستخدمين.

اضبط الأذونات بنفسك. يفرض msmtp الأذونات على إعدادات المستخدم في ~/.msmtprc، حيث يرفض التشغيل باستخدام contains secrets and therefore must have no more than user read/write permissions. لكنه لا يفرض شيئاً على /etc/msmtprc، لأنه يحمّل ذلك الملف ببساطة إذا كان قابلاً للقراءة.

sudo chown root:root /etc/msmtprc
sudo chmod 600 /etc/msmtprc
printf 'Subject: relay test\n\nsent from the host\n' | sudo sendmail -v you@example.com

يطبع -v محادثة SMTP كاملة، ولذلك ترى كل رد من المرحّل. ينتهي الإرسال الناجح برد 250 الذي يقبل الرسالة. ويعني السطر authentication failed أن اسم المستخدم أو كلمة المرور غير صحيحين، أو أن المرحّل يتوقع مفتاح API بدلاً من كلمة مرور الحساب.

لكن هنا تكمن المشكلة، وهي سبب انتقال كثير من المستخدمين إلى Postfix. مع الوضع 600 والمالك root، لا يستطيع الإرسال إلا root. ولا يستطيع تطبيق يعمل باسم www-data قراءة الملف، فيتجاهله msmtp، ويفشل التطبيق بخطأ يفيد بعدم العثور على الحساب الافتراضي. الحل هو استخدام مجموعة:

sudo chgrp mail /etc/msmtprc
sudo chmod 640 /etc/msmtprc
sudo usermod -aG mail www-data

المعنى واضح: يستطيع كل عضو في مجموعة mail قراءة كلمة مرور المرحّل وإرسال البريد باسم نطاقك من ذلك الخادم. هذا مقبول على VPS تديره وحدك. لكنه غير مقبول عندما تعمل عدة تطبيقات لم تكتبها أنت باستخدام مستخدمين مختلفين، ويكون Postfix الخيار الأفضل لأن هذه التطبيقات لا ترى بيانات الاعتماد أبداً.

Postfix بوصفه satellite

sudo debconf-set-selections <<'EOF'
postfix postfix/main_mailer_type select Satellite system
postfix postfix/mailname string notify.example.com
postfix postfix/relayhost string [smtp.relay.example]:587
EOF
sudo DEBIAN_FRONTEND=noninteractive apt install -y postfix libsasl2-modules

إن libsasl2-modules ليس اختيارياً. من دونه يسجل Postfix warning: SASL authentication failure: No worthy mechs found، لأن مكتبات آليتي PLAIN وLOGIN غير مثبتة تحت /usr/lib/sasl2.

اضبط بقية الإعدادات باستخدام postconf -e، الذي يحرر /etc/postfix/main.cf مباشرة:

sudo postconf -e 'relayhost = [smtp.relay.example]:587'
sudo postconf -e 'smtp_sasl_auth_enable = yes'
sudo postconf -e 'smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd'
sudo postconf -e 'smtp_sasl_security_options = noanonymous'
sudo postconf -e 'smtp_tls_security_level = encrypt'
sudo postconf -e 'smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt'
sudo postconf -e 'inet_interfaces = loopback-only'

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

يجعل smtp_tls_security_level = encrypt استخدام TLS إلزامياً، ولذلك لا تُرسل الرسالة بنص واضح. لكنه لا يتحقق من الشهادة. توضح وثائق Postfix ذلك صراحة: يستمر التسليم في هذا المستوى حتى إذا كانت شهادة الخادم غير موثوقة أو تحمل اسماً خاطئاً. إذا أردت التحقق من الشهادة، فاستخدم verify أو secure، وأبقِ smtp_tls_CAfile مضبوطاً.

توضع بيانات الاعتماد في ملف واحد لا يقرأه إلا root:

echo '[smtp.relay.example]:587 relay-username:relay-password' | sudo tee /etc/postfix/sasl_passwd
sudo chmod 600 /etc/postfix/sasl_passwd
sudo postmap hash:/etc/postfix/sasl_passwd
sudo systemctl restart postfix

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

تستمر التطبيقات في عنونة بريدها باستخدام root@hostname. أعد كتابة المرسل:

echo '/.+/    apps@notify.example.com' | sudo tee /etc/postfix/sender_canonical
sudo postconf -e 'sender_canonical_classes = envelope_sender, header_sender'
sudo postconf -e 'sender_canonical_maps = regexp:/etc/postfix/sender_canonical'
sudo systemctl reload postfix

تُقرأ خريطة regexp: مباشرة، ولذلك لا تحتاج إلى postmap. تخرج كل رسالة الآن باستخدام مرسل غلاف واحد وترويسة From واحدة، وهذا ما يريده المرحّل. لكن المقابل هو أن الردود ستصل كلها إلى مكان واحد، لذلك اضبط ترويسة Reply-To داخل كل تطبيق على العنوان الذي ينبغي أن تصل إليه الردود.

أرسل رسالة اختبار واقرأ السجل:

printf 'Subject: postfix relay test\n\nsent through the queue\n' | sendmail you@example.com
sudo tail -n 20 /var/log/mail.log

يسجل البريد الذي تم تسليمه status=sent متبوعاً برد المرحّل نفسه بين قوسين. وأي شيء آخر يذكر السبب. ويعني status=deferred مع Connection timed out أن شيئاً ما لا يزال موجهاً إلى المنفذ 25. ويعني Host or domain name not found. Name service error for name=smtp.relay.example type=A أن اسم مضيف المرحّل خاطئ أو أن DNS معطل على الخادم. يعرض mailq الرسائل العالقة، ويعيد sudo postqueue -f محاولة إرسالها الآن.

الوصول إلى مرحِّل المضيف من حاويات Docker

لا تستطيع الحاوية استدعاء sendmail الخاص بالمضيف، لأن الملف الثنائي غير موجود في الصورة، ولأن قائمة الانتظار غير مشتركة. امنح الحاويات هدفاً شبكياً بدلاً من ذلك. يمكن لـ Postfix الاستماع على عنوان جسر Docker.

ip -4 addr show docker0
sudo postconf -e 'inet_interfaces = 127.0.0.1, 172.17.0.1'
sudo postconf -e 'mynetworks = 127.0.0.0/8 172.17.0.0/16'
sudo systemctl restart postfix

اقرأ عنوان الجسر الخاص بك من ذلك الأمر الأول بدلاً من نسخ هذا العنوان، لأن مشروع Compose ينشئ شبكته الخاصة ضمن شبكة فرعية مختلفة، وdocker network inspect <name> يطبعها. استخدم restart هنا، وليس reload: توثّق Postfix ضرورة إيقاف الخدمة ثم تشغيلها بعد تغيير inet_interfaces، ولن يلتقط الأمر reload التغيير. يحصل كل تطبيق بعد ذلك على مضيف SMTP هو 172.17.0.1، والمنفذ 25، ومن دون مصادقة أو TLS، لأن حركة المرور هذه لا تغادر المضيف. إذا كانت خدماتك موجودة على شبكة Compose، يشرح تشغيل Docker Compose على VPS مصدر تلك الشبكة الفرعية.

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

ss -tlnp | grep ':25'

يجب أن يُظهر الناتج عنوان loopback وعنوان الجسر فقط. ومن جهاز آخر، يجب أن يفشل nc -vz your.server.ip 25.

SPF وDKIM وDMARC لنطاق الإرسال

انشر السجلات الثلاثة قبل أول إرسال فعلي. فهي مجانية، وهي سجلات DNS، وهي أول ما يتحقق منه خادم الاستقبال.

يسرد SPF ‏(إطار سياسة المرسل) الجهات التي يُسمح لها بوضع نطاقك في مرسل المغلف. انشره على النطاق الفرعي المخصّص للإرسال:

notify.example.com.  IN  TXT  "v=spf1 include:_spf.relay.example -all"

انسخ قيمة include: من صفحة الإعداد الخاصة بـrelay لديك، لأن include الذي لا يمكن حله يؤدي إلى خطأ دائم بدلاً من نتيجة pass. يتوقف تقييم SPF بعد عشرة آليات تجري استعلامات DNS، ويُرجع permerror، وهو ما تتعامل معه خوادم الاستقبال على أنه فشل؛ لذلك اجعل عدد include محدوداً. انشر سجل v=spf1 واحداً فقط لكل اسم؛ فنشر سجلين منه يُعد أيضاً permerror.

يوقّع DKIM ‏(البريد المحدد بمفاتيح النطاق) كل رسالة باستخدام مفتاح خاص يحتفظ به relay، وتسترد خوادم الاستقبال المفتاح العام المطابق من DNS. يزوّدك relay بقيمة selector وسجل TXT أو CNAME لنشره:

sel1._domainkey.notify.example.com.  IN  CNAME  sel1.dkim.relay.example.

يهم DKIM أكثر من SPF لأن DKIM يظل صالحاً عند إعادة التوجيه. عندما تمرر قائمة بريدية أو قاعدة .forward رسالتك، تصل الرسالة من عنوان IP الخاص بالجهة التي أعادت توجيهها؛ لذلك يفشل SPF بينما يظل التوقيع قابلاً للتحقق.

يحدد DMARC ‏(مصادقة الرسائل المستندة إلى النطاق وإعداد التقارير والتوافق) الإجراء الذي ينبغي لخوادم الاستقبال اتخاذه عندما لا تتوافق أي من عمليتي التحقق، ويطلب منها إرسال تقارير إليك. انشره على النطاق التنظيمي:

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=r; aspf=r"

ابدأ بـp=none واقرأ التقارير لمدة أسبوعين. لا يغيّر p=none شيئاً في التسليم؛ فهو يفعّل التقارير فقط، وبذلك تكتشف الأنظمة التي نسيت أنها ترسل باستخدام نطاقك. ثم انتقل إلى p=quarantine، وبعد ذلك إلى p=reject. إن نشر p=reject في اليوم الأول هو الطريقة التي يكتشف بها الأشخاص أن نظام الفوترة لديهم كان يرسل باستخدام النطاق، وذلك بعد أن لا يتلقى أحد العملاء فاتورة.

تحقق مما يراه العالم، لا مما تعرضه لوحة DNS لديك:

dig +short TXT notify.example.com
dig +short TXT sel1._domainkey.notify.example.com
dig +short TXT _dmarc.example.com

يعني الناتج الفارغ أن السجل لم ينتشر بعد أو أن الاسم غير صحيح. قد يظل سجل أصلحته قبل خمس دقائق غير صحيح في ذاكرات التخزين المؤقت طوال مدة TTL السابقة له (مدة البقاء)، لذلك تحقق من TTL قبل استخلاص أي نتيجة.

حافظ على تطابق From وReturn-Path

تحمل كل رسالة عنوانَي مرسل، ويجري التحقق منهما بطرائق مختلفة. يُحدَّد مرسل الغلاف في أمر SMTP MAIL FROM، ويظهر في الرسالة المسلَّمة باسم Return-Path. أما الرأس From فهو العنوان الذي يراه القارئ.

يتحقق SPF من نطاق مرسل الغلاف مقابل عنوان IP المتصل. ويعرض DKIM النطاق الذي وقّع الرسالة، باسم d=. ينجح DMARC فقط عندما يتطابق نطاق واحد على الأقل من هذين النطاقين مع النطاق الموجود في الرأس From. في حالة التطابق المرن (adkim=r، aspf=r، وهي الإعدادات الافتراضية)، يُعتدّ بالنطاق الفرعي؛ لذلك يتطابق مرسل غلاف على notify.example.com مع رأس From على example.com. أما في حالة التطابق الصارم فلا يحدث ذلك.

القاعدة العملية بسيطة: استخدم النطاق نفسه في الرأس From ومرسل الغلاف، ولن تثار هذه المسألة. وهذا تحديداً ما يفعله set_from_header on في msmtp، وما يفعله sender_canonical_maps في Postfix.

اقرأ نتيجة التحقق في رسالة مسلَّمة. في Gmail، يعرض الخيار "Show original" الرأس الذي سجّله المستلم:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@notify.example.com;
       spf=pass (google.com: domain of apps@notify.example.com designates 198.51.100.25 as permitted sender) smtp.mailfrom=apps@notify.example.com;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=example.com

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

الارتدادات والشكاوى قبل وصول حجم الإرسال

الارتداد هو رفض المستلم لرسالتك. الارتداد الدائم نهائي، ويصفه Gmail بالصيغة 550 5.1.1 The email account that you tried to reach does not exist. أما الارتداد المؤقت فهو مؤقت، ويكون رمز 4xx عند امتلاء صندوق البريد أو عند استخدام greylisting، ثم يعيد relay المحاولة تلقائياً.

تقيس relays معدل الارتداد الدائم لديك، وتعلّق الحسابات التي تواصل الإرسال إلى عناوين غير موجودة، لأن هذا النمط يشبه قائمة عناوين مشتراة. الشكاوى أهم. الشكوى هي أن يضغط شخص على زر الرسائل غير المرغوب فيها. وتطلب إرشادات Google للمرسلين، التي تم التحقق منها في August 2026، من المرسلين إبقاء معدل الرسائل غير المرغوب فيها أقل من 0.30% وفقاً لما يظهر في Postmaster Tools، وتوصي بالبقاء دون 0.10%.

أربع نقاط يجب تجهيزها قبل وصول حجم الإرسال:

• webhook، أو مراجعة أسبوعية لقائمة suppression في relay، حتى ترى الارتدادات فعلياً
• عنوان From يمثل صندوق بريد حقيقياً يقرأه شخص ما، مع ضبط Reply-To على المكان الذي يجب أن تصل إليه الردود
• تأكيد قبل إضافة أي عنوان إلى أي قائمة، حتى لا ترسل أبداً إلى عنوان لم يُدخله صاحبه
• تحديد معدل الإرسال لأي نموذج يتسبب في إرسال البريد

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

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

للمرجع، تنطبق قواعد Gmail للمرسلين ذوي الإرسال الجماعي عند تجاوز 5,000 رسالة يومياً إلى عناوين Gmail، وتتطلب SPF وDKIM وDMARC وإلغاء الاشتراك بنقرة واحدة في البريد التسويقي. لا تصل معظم التطبيقات المستضافة ذاتياً إلى هذا الحد. أما مصادقة البريد فأصبحت متوقعة من كل مرسل الآن على أي حال.

اختبره قبل أن تثق به

swaks هي الأداة المناسبة لذلك. فهي تتحدث عبر SMTP وتطبع المحادثة كاملة، حتى ترى الخطوة التي فشلت.

sudo apt install -y swaks
swaks --to you@example.com --from apps@notify.example.com --server smtp.relay.example --port 587 --tls --auth-user '<relay username>' --auth-password '<relay password>'

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

swaks --to you@example.com --from apps@notify.example.com --server 127.0.0.1

بعد ذلك، تحقّق من النتيجة من البداية إلى النهاية، بدءاً من الخادم، باستخدام بريد حقيقي. لا يمكن إثبات أي من ذلك من ملفات الإعداد، لذلك نفّذ الاختبار بنفسك:

• أرسل إلى خدمة تقييم مثل mail-tester.com، التي تقرأ إعدادات SPF وDKIM وDMARC ومحتوى الرسالة، وتوضح أسباب النتيجة
• أرسل إلى صندوق بريد لدى كل مزوّد من المزوّدين اللذين يستخدمهما المستخدمون فعلياً، واقرأ Authentication-Results في الرسالة الخام
• مرّر رسالة واحدة عبر learndmarc.com عندما لا تكون نتيجة المحاذاة واضحة
• شغّل عملية إرسال من التطبيق نفسه، وليس من سطر الأوامر فقط، لأن التطبيق هو الذي يضبط رأس From

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

FAQ

لماذا يكون المنفذ الصادر 25 محظوراً على VPS الخاص بي؟

يحظر كل موفّر تقريباً منفذ TCP الصادر 25 افتراضياً، لأن الخادم المخترق الذي يكون هذا المنفذ مفتوحاً عليه يستطيع تسليم الرسائل المزعجة مباشرةً إلى خوادم البريد المستلمة. تُسقَط الحزم بدلاً من رفضها، لذلك تتمثل الأعراض في اتصال يظل معلّقاً ثم تنتهي مهلته، لا في ظهور رسالة خطأ. أكّد ذلك بتشغيل nc -vz -w 5 gmail-smtp-in.l.google.com 25 بجانب nc -vz -w 5 smtp.relay.example 587: يبقى الأمر الأول معلّقاً، بينما يستجيب الثاني فوراً. الحل ليس طلب رفع الحظر. أرسل البريد عبر relay على منفذ الإرسال 587 أو 465، فهما مفتوحان ومخصّصان للعملاء الذين يستخدمون المصادقة.

هل أحتاج إلى SPF وDKIM وDMARC لمجرد إرسال بعض إشعارات التطبيق؟

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

هل ينبغي أن أستخدم msmtp أم Postfix كعميل relay؟

استخدم msmtp عندما يدير الخادم شخص واحد، ويكون فقدان رسالة أثناء تعطل relay أمراً مقبولاً. فهو يعتمد على ملف إعداد واحد ولا يشغّل daemon، ولأنه لا يضع الرسائل في قائمة انتظار، فإن عدم الوصول إلى relay يعني فقدان الرسالة. استخدم Postfix بوصفه satellite عندما تريد قائمة انتظار تعيد المحاولة لأيام، أو عندما تعمل عدة تطبيقات كمستخدمين مختلفين في النظام. يحتفظ Postfix بكلمة مرور relay في ملف لا يستطيع قراءته إلا root، ولا تقرأه التطبيقات، بينما يحتاج msmtp إلى أن يكون ملف إعداده قابلاً للقراءة من كل مستخدم يرسل رسائل.

لماذا يُرفض بريد تطبيقي لأنه يأتي من root؟

تنشئ مهام Cron والعديد من التطبيقات المرسل اعتماداً على المستخدم المحلي واسم المضيف، فتنتج قيمة مثل root@srv1.localdomain. هذا ليس عنواناً تحققت منه لدى relay، لذلك يرفض relay الرسالة برد 553 أو 554 يذكر عنوان المرسل. أصلح ذلك على مستوى المضيف بدلاً من إصلاحه في كل تطبيق: set_from_header on مع عنوان from في /etc/msmtprc، أو sender_canonical_maps مع sender_canonical_classes = envelope_sender, header_sender في Postfix. اضبط Reply-To داخل كل تطبيق إذا كان يجب أن تصل الردود إلى شخص.

هل يحمي النطاق الفرعي المنفصل لبريد التطبيقات نطاقي الرئيسي فعلاً؟

جزئياً، ولا يزال استخدامه مفيداً. يتتبع المستلمون السمعة لكل نطاق، لذلك تبقى الشكاوى المتعلقة بـnotify.example.com إلى حد كبير ضمن notify.example.com، بينما يواصل نطاقك الرئيسي تسليم الرسائل. لكن هذا الحل له حدود فعلية: يرفع بعض المستلمين مؤشرات النطاق الفرعي إلى النطاق التنظيمي، كما تنطبق سياسة DMARC المنشورة على مستوى النطاق التنظيمي على النطاقات الفرعية ما لم تضبط sp= بشكل منفصل. تعامل مع النطاق الفرعي على أنه وسيلة للحد من الأضرار، لا ضماناً.