أقوم بتشغيل إعداد اختباري (الإصدار الحالي 2.4.0.beta4) في المنزل على جهاز كمبيوتر صغير محلي يعمل بنظام Ubuntu 16.04 LTS. قمت بتثبيته باستخدام دليل التثبيت في 30 دقيقة الممتاز. يحتوي النظام على اسم نطاق كامل (FQDN). وقد عمل إرسال البريد الإلكتروني عبر صندوق بريد لدى مزود خدمة الإنترنت الخاص بي باستخدام بروتوكول SMTP على المنفذ 587 مع المصادقة العادية بشكل جيد لأكثر من عام.
لقد أدركت للتو أنني لم أتلق أي إشعارات بريد إلكتروني منذ فترة، مثل إشعار “نسخة جديدة متاحة”. وعند التحقق من لوحة الإدارة > البريد الإلكتروني > الرسائل المتخطاة، يظهر أن جميع الرسائل تواجه الخطأ التالي:
550-Bad HELO: localhost.localdomain does not exist - Please see RFC 2821
عند الرجوع إلى صندوق البريد، قد يكون هذا قد بدأ مع الإصدار 2.4.0.beta2. لكنه قد يكون أيضًا نتيجة تغيير في سياسة مزود خدمة الإنترنت الخاص بي في نفس الفترة تقريبًا (نهاية يوليو 2019). غير متأكد من أين أبدأ. من أين يأتي localhost.localdomain؟ خلال التثبيت، كان علي فقط تعديل ملف app.yml، وهذا الملف يعرض اسم نطاقي الكامل (FQDN) بشكل صحيح في DISCOURSE_HOSTNAME:
لم أسمع من قبل عن Mailgun. هل تقصد mailgun.com، خدمة “واجهة برمجة التطبيقات للبريد الإلكتروني المعاملاتي”؟ ولتوضيح مستوى معرفتي: لدي فكرة عامة عن ماهية واجهة برمجة التطبيقات (API)، لكنني لا أعرف كيفية استخدامها. ومع ذلك، يمكنني محاولة استخدام بروتوكول SMTP لإرسال البريد إلى صندوق بريد آخر لدى مزود خدمة إنترنت مختلف. سأقوم بالإبلاغ هنا غدًا.
@itsbhanusharma، @jtbayly شكرًا! تمكنت للتو من إرسال رسالة اختبار عبر Mailgun. إذن كانت المشكلة في سياسة جديدة على خادم SMTP الخاص بمزود خدمة الإنترنت الخاص بي. قد أواصل استخدام Mailgun.
تقوم بعض خوادم SMTP، مثل Postfix، بتفعيل خيار للتحقق من ذلك مقابل عنوان IP للعميل. حيث يحل localhost.localdomain عنوان IP الخاص بخادم SMTP، وهو محتمل وجوده في ملف المضيفين (hosts file) الخاص به. يبدو أن مزودي خدمة الإنترنت (ISPs) يفعّلون هذا الإجراء في معركتهم ضد المرسلي البريد العشوائي (Spammers).
تعمل الأمور مع Mailgun لأن Mailgun لا تنفذ هذا الفحص. ومع ذلك، لا يزال ذلك يُعتبر “أمر HELO سيئًا”.
للمقارنة، أرسلت بريدًا إلكترونيًا باستخدام عميل بريد إلكتروني (Sylpheed) على نفس النظام. وهذا يعمل، حتى مع صندوق البريد الخاص بمزود خدمة الإنترنت، ويبدو أنه يستخدم:
HELO HL80L
HL80L هو اسم شبكتي المحلية. هذا لا يزال ليس اسم نطاق كامل (FQDN)، لكنه على الأقل لا يظهر كشيء مزيف واضح لخادم مزود خدمة الإنترنت.
لذلك، ربما يكون هذا شيئًا يحتاج إلى تحسين. لكن تنويه: لست خبيرًا في بروتوكول SMTP.
بالمناسبة، لقد نجحت في إعادته للعمل مرة أخرى عبر صندوق البريد الخاص بمزود خدمة الإنترنت الخاص بي عن طريق وضع خادم بريد (MTA) كوسيط لإعادة التوجيه. إنه تطبيق مبني على Postfix يعمل على جهاز NAS الخاص بي. يستخدم هذا الإجراء HELO mydomain.tld
سأقوم بفحص ما إذا كان قد حدث أي خلل أثناء الانتقال إلى Debian 10 أو الترقية إلى Rails 6. في غضون ذلك، يجب أن يعمل ضبط DISCOURSE_SMTP_DOMAIN في ملف app.yml. أعتقد أنه ينبغي أن نستخدم افتراضيًا قيمة DISCOURSE_HOSTNAME في حال لم يتم تحديد نطاق SMTP بشكل صريح.
شكرًا لك، @gerhard! لم يكن DISCOURSE_SMTP_DOMAIN موجودًا في ملف app.yml الخاص بي، لكنني أخذت نفسًا عميقًا وأضفته، ونعم، هذا هو الحل. أستطيع الآن استخدام صندوق بريد مزود خدمة الإنترنت الخاص بي مرة أخرى. في الطرف المستقبل، أجد في الرأس:
Received: from XXXXXXX.cable.dynamic.v4.ziggo.nl ([XX.XX.XX.X] helo=mydomain.tld)
by smtp7.mnd.mail.iss.as9143.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1)
في الوقت نفسه، تعلمت أن كلاً من RFC 2821 وخليفته RFC 5321، القسم 4.1.4 ينصان على ما يلي:
قد يتحقق خادم SMTP من أن اسم النطاق الموجود في حجة أمر EHLO يتوافق فعليًا مع عنوان IP للعميل. ومع ذلك، إذا فشلت عملية التحقق، يجب على الخادم ألا يرفض قبول الرسالة على هذا الأساس. المعلومات التي يتم التقاطها في محاولة التحقق مخصصة لأغراض التسجيل والتتبع. لاحظ أن هذا الحظر ينطبق فقط على مطابقة المعامل مع عنوان IP الخاص به؛ راجع القسم 7.9 لمناقشة أكثر تفصيلاً لرفض الاتصالات الواردة أو رسائل البريد الإلكتروني.
لكن العديد من وكلاء نقل البريد (MTAs) مثل Postfix و Exim لا تزال تبدو وكأنها تحتوي على إعداد اختياري للقيام بذلك. ربما يقوم المسؤولون بتفعيل ذلك في المعركة المستمرة ضد البريد العشوائي.
