أعتقد أن النقر على حقل “نوع البريد الإلكتروني”، مثل user_watching_first_post، يُفترض أن يعرض تفاصيل رسالة الارتداد المستلمة من المستلم المقصود.
لكن في موقعي المستضاف ذاتيًا، تظهر رسالة الخطأ المذكورة أعلاه. هل هناك أي شيء يمكنني فعله لإصلاح ذلك؟
شكرًا لك.
هذا صحيح. لقد تحققت للتو من ذلك على موقع Discourse المستضاف لدي، وهو يعمل دون أي مشاكل. إذا كان موقعك يعمل على أحدث إصدار من Discourse، فإنني أتساءل عما إذا كانت المشكلة مرتبطة بكيفية تعامل خادم البريد الخاص بك مع إعادة توجيه رسالة الارتداد.
شكرًا لك. بالنسبة للبريد الصادر، أستخدم Mailgun. أعتقد أنني استخدمت الإعدادات الموصى بها من قبل Discourse.
أما بالنسبة للبريد الوارد، فأستخدم هذا الرابط: Configure direct-delivery incoming email for self-hosted sites with Mail-Receiver لكنني لم أقوم بتحديثه منذ التثبيت — هل قد يكون هذا هو المشكلة؟ وبما أن الأمر المستخدم في Discourse هو ./launcher rebuild app، فهل الأمر المقابل لاستقبال البريد هو ./launcher rebuild mail-receiver؟
نعم، هكذا يتم ترقية النظام. لقد مرّ وقت طويل منذ آخر تحديث، أعتقد، لكن خطوة أولى جيدة ستكون ترقية النظام وDiscourse.
لقد قمت بترقية كلاهما ولا يزال الخطأ نفسه يظهر، بما في ذلك (أعتقد) للرسائل الإلكترونية المستلمة منذ الترقية. هل لديك أي أفكار أخرى؟
نفس المشكلة هنا. استضافة ذاتية، محدثة. يتم التعامل مع الارتدادات بالطريقة الموصى بها. الروابط من قبل أن ننتقل إلى معالجة الارتدادات الصحيحة تعمل بشكل جيد.
نعم، من المرجح أن Discourse لا يتلقى الرسالة من Mailgun. لا أعرف كيف تعمل الويب هوك، لكنني أشك في أنها تُبلغ Discourse فقط بحدوث فشل مؤقت أو دائم دون إرسال رسالة الارتداد.
هل توجد طريقة لجعل ميزة Discourse هذه تعمل مع Mailgun؟
يجب أن يكون من الممكن عرض على الأقل رمز الخطأ والرسالة:
يتم الاحتفاظ بكل من رمز خطأ SMTP ورسالة خطأ SMTP
“code”: 550,
“address”: “'baz@example.com”,
“error”: “Message was not accepted – invalid mailbox. Local mailbox 'baz@example.com is unavailable: user not found”
https://documentation.mailgun.com/en/latest/api-bounces.html#examples
إذا لم يكن ذلك ممكنًا، فنحن بحاجة على الأقل إلى رسالة خطأ معقولة توضح سبب عدم عمل الرابط 
هل تم إنجاز أي عمل بشأن هذا الأمر. سأكون ممتنًا جدًا لو كان الأمر كذلك
أنا أستخدم Digital Ocean و Mailgun (أي التوصيات الرئيسية) لذا أتخيل أنه ليس أنا الوحيد الذي يعاني من المشكلة.
بعد اختباري الخاص، يبدو أنه في كثير من الحالات، لا يتلقى مستلم البريد الارتدادات على الإطلاق. (وجدت محاولة اتصال واحدة فقط، والتي فُقدت على الفور). لا أرى رأس Return-Path معينًا على الإطلاق (هل من المفترض أن يكون كذلك؟) مما يجعلني أعتقد أنها لا تُرسل في معظم الأوقات.
لا تزال هناك مشكلة هنا أيضًا. على الرغم من بياني السابق، يبدو الآن أن أياً من هذه الروابط لا تعمل، بالعودة إلى بدء تشغيل الموقع. في البداية، بدا أن هذا يؤثر فقط على الارتدادات قبل أن نبدأ في التعامل مع الارتدادات بشكل صحيح (Configure VERP to handle bouncing e-mails).
لقد لاحظت للتو أكوامًا من التحذيرات في سجل الأخطاء على هذا النحو:
لا يمكن معالجة البريد الإلكتروني: Email::Receiver::AutoGeneratedEmailError
تم الاستلام: من ...
لـ <bounce+f7e463.5f70e9-...@forum.example.com>; ...
الموضوع: لم يتم تسليم رسالتك
ربما لهذا السبب لا يحتوي Discourse على أي تفاصيل حول رسائل البريد الإلكتروني المرتدة.
لا أرى تلك الأخطاء في السجلات، لكن المشكلة مستمرة. عندما أنقر على قيمة نوع البريد الإلكتروني لإدخال في قائمة البريد المرتد، أحصل على “حدث خطأ: Discourse::NotFound”.
لقد تم تحديده بالفعل. عدت قليلاً إلى الوراء في السجل، وبينما أرى رسائل عرضية متعلقة بالبريد الإلكتروني، لا أرى الرسائل التي ذكرتها.
لدي نفس المشكلة مع Mailgun. مضيف مختلف، لذا ليس هذا هو السبب!
أتساءل عما إذا كانت هناك مشكلة في تعليمات تكوين Mailgun لإعداد VERP:
كان هذا موجودًا منذ فترة، ولكنه بدأ للتو في التسبب في مشاكل حيث أهدف إلى التحقيق في سبب حصولي على الكثير من الارتدادات في الوقت الحالي.
تبدو المشكلة في عدم وجود رابط في عمود نوع البريد الإلكتروني وعدم وجود شيء خلف أيقونة 
(الأسهم الحمراء):
عندما أنقر على هذه، أحصل على هذا:
بالنظر إلى كود الصفحة، تبدو علامات الربط في HTML مفقودة تمامًا:
لدي VERP مُعدّ لـ Mailgun، ويبدو أنه يعمل بشكل جيد بخلاف ذلك.
هذا هو السلوك المتوقع عندما لم تتم معالجة الرد المرتد بواسطة Discourse. الميزة تعمل بشكل جيد إذا استلمت Discourse الردود المرتدة، وإلا ستظهر هذا الرد لجميع الردود المرتدة.
هل يمكنك التحقق مرة أخرى وتشغيل الاختبار وفقًا لـ Configure VERP to handle bouncing e-mails
رسالة أفضل ستكون جيدة في هذه الحالة.
أعتقد أنك تقصد أنه إذا اكتشف Discourse الارتداد فقط من خلال خطاف ويب Mailgun، فلن يتم إرسال تفاصيل الارتداد أبدًا إلى Discourse. هل هذا صحيح؟
إذا كان الأمر كذلك - هل سيكون هناك أي طريقة لإرسال تلك التفاصيل إلى Discourse وتسجيلها وعرضها في نفس المكان الذي يتم فيه عرض الارتدادات التي يتلقاها Discourse؟ أعتقد أن واجهة برمجة تطبيقات Mailgun ستسمح بذلك ("Discourse::NotFound" error when click "Email Type" field on admin/email/bounced - #8 by Jonathan5).
في أي ظرف سيتعامل Discourse مع الارتدادات بدلاً من خدمة البريد الإلكتروني الخارجية؟ (أعلم أن Discourse يمكنه ارتداد/رفض رسائل البريد الإلكتروني، ولكني أعني التعامل مع رسائل الارتداد المستلمة من المستلمين المقصودين للبريد الإلكتروني.)
أتفق. إذا لم يكن هناك شيء معطل بالفعل، فلا ينبغي أن يبدو معطلاً. يمكن لـ Discourse بالتأكيد تقديم رسالة أكثر طمأنينة.
