إشعارات الارتداد لـ SES/SNS لم تعد تتطابق مع EmailLog بعد تعزيز الأمان لـ TopicArn

تمت إعادة إنتاج المشكلة على تثبيت ذاتي التشغيل يعمل بالإصدار v2026.7.3 (إصدار/2026.7)، مع استخدام SES SMTP في us-east-1، وقاعدة بيانات PostgreSQL مدمجة من الإصدار 18.

الإعداد

  • يحتوي aws_sns_topic_arn_allowlist على معرّف الموضوع (Topic ARN) الدقيق (تم التحقق منه من وحدة تحكم SNS).
  • تم تأكيد اشتراك HTTPS الخاص بـ SNS إلى /webhooks/aws؛ وقد قام نفس الاشتراك بمعالجة الرسائل المرتدة بشكل صحيح من مارس إلى يونيو 2026 على الإصدارات release/2026.4 و 2026.5.0.

الملاحظة
أُرسلت رسالتان تجريبيتان إلى bounce@simulator.amazonses.com. أنتجت كل منهما طلب POST واحد عبر SNS وصل إلى الحاوية:

"POST /webhooks/aws HTTP/1.1" "Amazon Simple Notification Service Agent" 200 402

لم يظهر شيء في /logs ولا في /admin/email-logs/bounced. بما أن WebhooksController#aws يعيد 406 في حالة فشل قائمة السماح أو التحقق من التوقيع، فإن الاستجابة 200 تؤكد نجاح كلا الفحصين، وأن Jobs::ProcessSnsNotification قد تم وضعه في قائمة الانتظار. ثم ينهي المهمة next if email_log.nil? لأن mail.messageId (المُسند من SES) لا يساوي أبدًا EmailLog.message_id (معرّف الرسالة الخاص بـ Discourse، والذي يُعيَّن في Email::Sender عبر email_log.message_id = @message.message_id).

يتوافق سجل Git مع التحليل أعلاه: فقد ألغى التغيير #7284 (2019) مطابقة المعرّف لهذا السبب بالذات، وأعاد التعديل 61f12e1 (يونيو 2026) تفعيله باستخدام المعرّف المُسند من SES. في إصدار release/2026.7، لم تتغير المهمة منذ ذلك التعديل.

النتيجة الصافية لمستخدمي SES ذاتي التشغيل على الإصدار المستقر الحالي (ESR): معالجة الرسائل المرتدة معطلة بصمت، والإشعار الجديد في لوحة التحكم يوجه المشرفين إلى إعداد لا يؤدي إلى أي شيء. سيكون من المستحسن ترحيل التصحيح إلى إصدار release/2026.7 بمجرد توفر إصلاح.

إعجابَين (2)