[quote=“Simon Manning, post:476, topic:49487, username:Simon_Manning”]
أنا أشك في أن اقتباسك من الدليل قد أربكك وأن كل شيء يعمل بشكل صحيح في الواقع.
[/quote]لقد كنت على حق، فقد تم إعداد البريد الإلكتروني لفئة وإرسال البريد الإلكتروني إلى هناك كما هو متوقع، لذلك كنت أضرب رأسي في الحائط لأن عمليات الرفض كانت صامتة.
يسعدني أنني أعرف الآن، وآمل أن يتم تحديث الدليل، على الرغم من أنني شخصياً أفضل لو كان يعمل كما يصف الدليل. على سبيل المثال، إذا كان المستخدمون يحاولون إرسال بريد إلكتروني إلى عنوان ما ويفشل، فقد يساعدني ذلك في إخبارهم أو إدراك أن هناك طلبًا للتواصل مع فئة أو مجموعة عن طريق البريد الإلكتروني. يبدو أنه بدون ذلك، لا توجد طريقة سهلة لرؤية تلك رسائل البريد الإلكتروني.
[quote=“Matt Palmer, post:479, topic:49487, username:mpalmer”]
إنه كذلك. مع التسليم المباشر، لا يحتاج مزود البريد الصادر لديك إلى المشاركة على الإطلاق في البريد الوارد. يجب أن يذهب كل شيء، سواء كان موضوعًا جديدًا أو ردًا أو ارتدادًا، مباشرة إلى mail-receiver (ومن ثم إلى Discourse للمعالجة).
[/quote]لا يزال هذا لا يعمل كما هو متوقع. لقد نجحت في تشغيل خطافات الويب، لذا يمكنني رؤية العديد من الارتدادات، لكنني أعرف أنها من خطافات الويب الخاصة بـ Mailgun لأن لديها المشكلة الموصوفة هنا: “خطأ Discourse::NotFound” عند النقر على حقل “نوع البريد الإلكتروني” في admin/email/bounced
أنا لا أفهم حقًا كيف يحصل Mailgun على الارتدادات في المقام الأول، نظرًا لعدم وجود سجلات MX تشير إلى خوادمهم، أفترض أنهم يقومون بتعيين مسار إرجاع أثناء إرسال البريد الصادر؟
وأرى الارتدادات في سجلات mail-receiver، لكنها لا تصل إلى app. يبدو أنها تُرفض بصمت. إليك سطر في السجلات يمكنني ربطه بارتداد تم استلامه عبر خطافات الويب:
NOQUEUE: reject: RCPT from mail-[id1].outbound.protection.outlook.com[XX.XX.XX.XX]: 450 4.7.1 <bounce+[id2]-[email]=[address].com@www.[mydomain].com>: Recipient address rejected: Internal error, API request failed; from=<> to=<bounce+[id#]-[email]=[address].com@www.[mydomain].com> proto=ESMTP helo=<[id3].outbound.protection.outlook.com>
هل أحتاج إلى إضافة bounce+{%something}@www.mydomain.com كعنوان مدرج في القائمة البيضاء في مكان ما حتى يتم تمريرها؟