I think clicking on an “Email Type” field, e.g. user_watching_first_post is meant to display details of the bounce message received from the intended recipient.
But on my self-hosted site I get the error message stated above. Is there anything I can do to fix this?
Thanks.
That is correct. I’ve just checked this on my hosted Discourse site and it’s working without any problems. If your site is on the latest version of Discourse, I’m wondering is the issue is related to how your mail server handles forwarding the bounce message.
Thanks. For outgoing mail I’m using Mailgun. I think I used Discourse’s recommended settings.
For incoming mail I’m using this Straightforward direct-delivery incoming mail But I’ve never updated it since installation - might that be the problem? As it’s ./launcher rebuild app for Discourse, is it ./launcher rebuild mail-receiver?
Yes, that’s how to upgrade it. It’s been a while since the last update, I think, but a good first stop) step would be to upgrade it and discourse.
I have upgraded both and still get the same error, including (I think) for emails received since the upgrade. Any further ideas?
Same problem here. Self-hosted, up to date. Bounces being handled the recommended way. Links from before we changed to proper bounce handling work fine.
Yes likely Discourse isn’t getting it from Mailgun. I don’t know how the webhooks work but suspect it just tells Discourse there has been a temporary/permanent failure without sending the bounce message.
Is there any way to make this Discourse feature work with Mailgun?
It should be possible to show at least the error code and message:
Both SMTP error code and SMTP error message are preserved
“code”: 550,
“address”: “'baz@example.com”,
“error”: “Message was not accepted – invalid mailbox. Local mailbox 'baz@example.com is unavailable: user not found”
If not then at least we need a sensible error message to explain why the link doesn’t work 
هل تم إنجاز أي عمل بشأن هذا الأمر. سأكون ممتنًا جدًا لو كان الأمر كذلك 
أنا أستخدم 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 بالتأكيد تقديم رسالة أكثر طمأنينة.
