توقف الرد عبر البريد الإلكتروني المستضاف ذاتيًا عن العمل بعد آخر تحديث

[Paul_King]

لم يعد منتداي يستجيب للردود المرسلة عبر البريد الإلكتروني.

كانت ميزة الرد عبر البريد الإلكتروني تعمل بشكل جيد سابقًا، لكن يبدو أن هذه الوظيفة توقفت عن العمل حوالي 29 سبتمبر.

ليس لدي دليل قاطع على هذا التوقيت، حيث إن المنتدى ليس نشطًا جدًا، لكن من المؤكد أنه لم يعد يعمل الآن، ولا تظهر سجلات المنتدى أي رسائل مستقبَلة بعد 29 سبتمبر.

تحتوي سجلات الرسائل المرفوضة أيضًا على آخر إدخال في 29 سبتمبر. جميع الرسائل المرفوضة كانت تحتوي على عناوين مؤقتة ومحتوى يبدو كرسائل غير مرغوب فيها (سبام)، لذا يبدو أن النظام يعمل كما ينبغي.

سجل الرسائل المرتجعة فارغ أو يعرض “لم يتم العثور على سجلات”.

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

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

يُظهر سجل أخطاء المنتدى بضع تحذيرات (أيقونة تعجب صفراء) في 29 سبتمبر: “لا يمكن معالجة البريد الإلكتروني: Email::Receiver::BadDestinationAddress Received…”، والتي تبدو غير ضارة ولا تختلف عن أحداث مسجلة مشابهة سابقة. أفترض أنها مجرد رسائل سبام مرفوضة.

في 1 أكتوبر، تم تسجيل خطأ فعلي كما يلي:

رسالة

ActionDispatch::Http::MimeNegotiation::InvalidType (“%{#context[‘com.opensymphony.xwork2.dispatcher.httpservletresponse’].addheader(‘cbu0psig’” ليس نوع MIME صالحًا)
lib/middleware/omniauth_bypass_middleware.rb:71:in call' lib/content_security_policy/middleware.rb:12:in call’
lib/middleware/anonymous_cache.rb:353:in call' config/initializers/100-quiet_logger.rb:23:in call’
config/initializers/100-silence_logger.rb:31:in call' lib/middleware/enforce_hostname.rb:23:in call’
lib/middleware/request_tracker.rb:187:in `call’

المسار الخلفي

actionpack (6.1.4.1) lib/action_dispatch/http/mime_negotiation.rb:31:in rescue in block in content_mime_type' actionpack (6.1.4.1) lib/action_dispatch/http/mime_negotiation.rb:24:in block in content_mime_type’
rack (2.2.3) lib/rack/request.rb:69:in fetch' rack (2.2.3) lib/rack/request.rb:69:in fetch_header’
actionpack (6.1.4.1) lib/action_dispatch/http/mime_negotiation.rb:23:in content_mime_type' actionpack (6.1.4.1) lib/action_dispatch/http/request.rb:269:in media_type’
actionpack (6.1.4.1) lib/action_dispatch/http/request.rb:355:in form_data?' rack (2.2.3) lib/rack/request.rb:445:in POST’
actionpack (6.1.4.1) lib/action_dispatch/http/request.rb:400:in block (2 levels) in POST' actionpack (6.1.4.1) lib/action_dispatch/http/parameters.rb:88:in parse_formatted_parameters’

البيئة

HTTP HOSTS: nzarchitecture.net.nz

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

لا يبدو أن أيًا من عنواني البريديين مصنف كرسائل غير مرغوب فيها أو مدرج في قوائم الحظر عند الاختبار على www.mail-tester.com، ولم نواجه أي مشاكل في التواصل مع البشر من هذين العنوانين.

يستخدم المنتدى خدمة Mailgun، على الرغم من أنني أفترض أنها تُستخدم فقط لإرسال الرسائل البريدية الجماعية، وأن أي مشاكل في حساب Mailgun أو مفتاح الـ API لا ينبغي أن تؤثر على الرسائل الواردة؟ في الواقع، لم أجد أي مشاكل واضحة أو رسائل خطأ في حساب Mailgun الخاص بي عند تسجيل الدخول.

أفترض أن مفتاح API الخاص بـ Mailgun يجب أن يكون صحيحًا إذا كان المنتدى لا يزال يرسل البريد بشكل سليم.

لم يتم تغيير أي إعدادات للمنتدى منذ أن كانت ميزة الرد عبر البريد الإلكتروني تعمل، وأرى أن مربع اختيار “الرد عبر البريد الإلكتروني” لا يزال مُفعّلًا.

المنتدى مستضاف على Digital Ocean. لم يتم تغيير أي إعدادات DNS للنطاق في إعدادات Digital Ocean، ويبدو أن سجلات MX للمنتدى سليمة/غير متغيرة.

تم تحديث المنتدى إلى الإصدار 2.8.0 beta 7 منذ بدء المشكلة (على الأرجح مع إعادة البناء في العملية)، لكن لم يتحقق أي تحسن.

ما الذي أفتقده هنا؟
ما الذي على الأرجح حدث خطأ؟
كيف يمكنني إعادة تفعيل ميزة الرد عبر البريد الإلكتروني؟

[RGJ (Richard - Communiteq)]

يبدو أن هذا الخطأ غير ذي صلة.

بشكل عام، من الأسهل اختبار “البريد الوارد” مقارنة باختبار الرد عبر البريد الإلكتروني. قم بفحص إعدادات “تمكين الاستدعاء اليدوي” و"البريد الوارد"، وأضف عنوان بريد إلكتروني إلى فئة الموظفين، ثم راجع ما إذا كان بإمكانك إرسال بريد إلكتروني إلى ذلك العنوان باستخدام نفس عنوان البريد الإلكتروني الذي تستخدمه لحساب مسؤول المنتدى.

بعد ذلك، راجع القسم المسؤول - البريد الإلكتروني - المرتجعة / المستلمة / المرفوضة لمعرفة ما يحدث.

هل تم تكوين عنوان “الرد عبر البريد الإلكتروني” بشكل صحيح؟

[Paul_King]

مرحبًا، شكرًا لك ريتشارد

أؤكد لك أن إعدادات “التنبيه اليدوي مفعّل” و"البريد الإلكتروني الوارد" لا تزال مفعّلة.

لقد أضفت عنوان بريد Gmail الخاص بي كعنوان مخصص لفئة الموظفين، لكنني لا أرى طريقة لإرسال رسائل إلى الموظفين عبر المنتدى؟ فجميع روابط “اتصل بنا” مُعدّة في نصوص إعدادات المنتدى كروابط mailto: تؤدي فقط إلى عنوان بريدي الشخصي اليومي — عند النقر على أحد هذه الروابط، يفتح تطبيق البريد الإلكتروني الخاص بي مُعبّأ مسبقًا بعنوان بريدي المباشر الشخصي، مما يعني أن المنتدى لن يستقبل الرسالة أبدًا.

[RGJ (Richard - Communiteq)]

@Paul_King، المشاركة: 3، الموضوع: 206973

أضفت عنوان بريد Gmail الخاص بي كعنوان مخصص لفئة الموظفين

لا، يجب عليك إعداد شيء مثل staff@nzarchitecture.net.nz في إعدادات الفئة، ثم استخدم Gmail الخاص بك لإرسال رسالة إلى ذلك العنوان.

[Paul_King]

أهلاً، حسناً.

@RGJ

قم بإعداد شيء مثل staff@nzarchitecture.net.nz في إعدادات الفئة، ثم استخدم بريد Gmail لإرسال رسالة إلى هذا العنوان.

لقد جربت نفس الأمر تماماً، لكن لم يظهر أي شيء في سجلات الـ Bounced أو الـ Received أو الـ Rejected.

[IAmGav (Gavin Perch)]

يتم ضبط خادم البريد الخاص بك على Digital Ocean.

هل لديك خادم بريد معهم؟

[RGJ (Richard - Communiteq)]

هذه هي عنوان IP للقطرة التي تشغل مستلم البريد.

nzarchitecture.net.nz. 2727 IN A 159.65.140.176

[IAmGav (Gavin Perch)]

تم تغييره في الأشهر الخمسة الماضية

[RGJ (Richard - Communiteq)]

@Paul_King

كان الرد عبر البريد الإلكتروني يعمل بشكل جيد سابقًا، لكن يبدو أن هذه الوظيفة توقفت عن العمل حوالي 29 سبتمبر.

أعلم ما يحدث. إنها تلك المشكلة الملعونة مع Let’s Encrypt مرة أخرى التي تسببت في تعطيل نصف الإنترنت العديد من الأشياء في 30 سبتمبر.

Self-hosted mail-receiver update following Let's Encrypt root certificate change

This announcement only affects self-hosters who are running Configure direct-delivery incoming email for self-hosted sites with Mail-Receiver. Managed hosting customers, and self-hosters using POP3 for incoming mail are not affected. As you may be aware, Let’s Encrypt recently changed their root certificate. The old root certificate expired today, and has caused a number of issues for out-of-date clients across the web. All of our systems at CDCK are up-to-date, and were not affected by today’s…

ما عليك سوى إعادة بناء حاوية Docker لاستقبال البريد.

[IAmGav (Gavin Perch)]

@RGJ، منشور: 9، موضوع: 206973

إنه ذلك الشيء الملعون من Let’s Encrypt الذي تعطل مرة أخرى

هاهاهاها، نعم. نسيت ذلك. هههه

[IAmGav (Gavin Perch)]

يجب عليك متابعة الموضوع الذي نشره @RGJ.

هذا يجب أن يحل مشكلتك.

Self-hosted mail-receiver update following Let's Encrypt root certificate change

This announcement only affects self-hosters who are running Configure direct-delivery incoming email for self-hosted sites with Mail-Receiver. Managed hosting customers, and self-hosters using POP3 for incoming mail are not affected. As you may be aware, Let’s Encrypt recently changed their root certificate. The old root certificate expired today, and has caused a number of issues for out-of-date clients across the web. All of our systems at CDCK are up-to-date, and were not affected by today’s…

[Paul_King]

@RGJ، مشاركة: 9، موضوع: 206973

أعد بناء حاوية Docker لاستقبال البريد ببساطة.

آه، حسنًا. يبدو ذلك واعدًا!
كيف يمكنني إعادة بناء “حاوية استقبال البريد”؟ هل يختلف هذا عن إعادة بناء “مدير Docker” التي تحدث عند تحديث المنتدى عبر لوحة التحكم؟

هل أكتفي باتباع هذا الدليل؟ كيف أقوم بتحديث Discourse وصورة Docker يدويًا إلى الإصدار الأحدث؟ - كيف تفعل / المشرفون - Discourse Meta

[IAmGav (Gavin Perch)]

تحتاج إلى تسجيل الدخول إلى جانب سطر الأوامر في موقعك.

ليس عبر لوحة تحكم إداري المنتدى.

[Paul_King]

مرحبًا، تمكنت من إعادة بناء مستودع استقبال البريد باستخدام التعليمات الموجودة في هذا الرابط التسليم المباشر للبريد الوارد للمواقع المستضافة ذاتيًا - كيفية / مسؤول النظام - Discourse Meta

اضطررت إلى ترقية/توسيع حجم خادم Digital Ocean الخاص بي للقيام بذلك، حيث إنه حتى بعد حذف جميع النسخ الاحتياطية وما إلى ذلك المخزنة على المضيف، لم يكن هناك مساحة كافية على القرص لإعادة البناء.

بعد إعادة البناء، تمكنت من إرسال تلك الرسالة إلى staff@nzarchitecture.net.nz - وقد اعترف سجل المنتدى بهذه المرة.
ومع ذلك، عندما أحاول الرد عبر البريد الإلكتروني على موضوع موجود في المنتدى تم إشعاري به، في حين أن الرسائل الواردة الآن معترف بها، إلا أن لا شيء منها يظهر في المنتدى، وجميعها تحصل على تحذيرات “فشل تسليم البريد” في سجل البريد.

الرسائل الواردة لا تظهر في سجل البريد المرتجع، ولكنها تظهر جميعها في سجل البريد المرفوض مع تحذير [Email::Receiver::BadDestinationAddress] - بما في ذلك حساب البريد الإلكتروني الخاص بي كمسؤول، والذي أتمنى ألا يصبح فجأة عنوان وجهة سيئًا.

[pfaffman (Jay Pfaffman)]

هل قمت بإعادة بناء مستلم البريد الخاص بك مؤخرًا؟

[Paul_King]

نعم - قمت بذلك قبل حوالي نصف ساعة، مما أدى إلى ظهور المنشور أعلاه.
لقد قمت للتو بإعادة بناء كاملة أخرى، و (بإذن الله) يبدو أن الأمور تعمل مرة أخرى.

[pfaffman (Jay Pfaffman)]

@Paul_King

لقد قمت للتو بإعادة بناء كاملة، و (بحمد الله) يبدو أن الأمور تعمل مرة أخرى

قد يكون السبب هو أن فرض HTTPS لم يكن مُفعّلًا، وقد أصلحت إعادة البناء هذه المشكلة.

[Paul_King]

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

لم أكن أدرك أن فرض استخدام HTTPS إلزامي لاستقبال البريد الوارد.

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

[Paul_King]

@Paul_King

من الممكن أن يكون عدم فرض استخدام بروتوكول HTTPS سببًا في مشاكل تسجيل الدخول عبر فيسبوك.

يبدو أن تحديد خيار “فرض استخدام HTTPS” لم يُسهم بأي شكل في حل مشكلة تسجيل الدخول عبر فيسبوك. لا يزال الدعم الفني لفيسبوك يؤكد أن صفحة الهبوط للموقع تُظهر تحذيرًا أمنيًا يقول: “اتصالك غير آمن” (NET::ERR_CERT_COMMON_NAME_INVALID).

وفقًا لصفحة الخطأ، فإن الجهة المصدرة للشهادة هي “R3”، وتشير نتائج بحث جوجل إلى أنها مرتبطة بشركة Let’s Encrypt، وهي نفس الجهة التي تسببت في انتهاء صلاحية شهادتها في الحاجة إلى إعادة بناء تثبيت Discourse.

هل هذه مجرد مصادفة؟ هل يوحي هذا بأن أحدث إصدار من Discourse (الإصدار التجريبي 2.8.0 بيتا 7) لا يزال يعاني من مشكلة تتعلق بالشهادات؟ أم أن هذه مشكلة غير مرتبطة تتعلق بالاستضافة أو مزود الخدمة Digital Ocean؟

[Paul_King]

أبحاثي الخاصة غير المدروسة على جوجل قادتني إلى اختبار رابطي باستخدام https://www.whynopadlock.com/، وقد أدت النتائج إلى هذه المنشور من مستخدم لـ Let’s Encrypt

قامت Let’s Encrypt مؤخرًا بتحديث شهادة الوسيط الخاصة بها من “Let’s Encrypt Authority X3” إلى “R3”.

إذا كنت تستخدم عميل ACME يعمل بشكل صحيح، فسيكون قد بدأ تلقائيًا في استخدام الوسيط الجديد عند التجديد الأخير. ولا ينبغي أن تلاحظ أي فرق.

في حالتك، ربما تكون قد قمت بتضمين شهادة الوسيط بشكل ثابت (hardcoding). إذا كان الأمر كذلك، فستحتاج إلى استخدام الوسيط الجديد، والذي يمكنك العثور عليه على Chains of Trust - Let's Encrypt : https://letsencrypt.org/certs/lets-encrypt-r3-cross-signed.pem

هل النسخة الحالية من Discourse تقوم بشكل خاطئ بتضمين شهادة الوسيط بشكل ثابت؟

هل “شهادات الوسيط” شيء يُطلب الآن من مشرفي Discourse إدارته؟ وإذا كان الأمر كذلك، فكيف؟

أرجو إعلامي إذا كنت قد خرجت عن الموضوع - لست متأكدًا مما إذا كان هذا جزءًا من نفس المشكلة أم لا.