Reproduit sur une installation auto-hébergée exécutant la version v2026.7.3 (release/2026.7), avec SES SMTP dans us-east-1 et PostgreSQL 18 intégré.
Configuration
aws_sns_topic_arn_allowlistcontient l’ARN de sujet exact (vérifié dans la console SNS).- L’abonnement HTTPS SNS vers
/webhooks/awsa été confirmé ; la même souscription a correctement traité les rebonds de mars à juin 2026 sur les versions release/2026.4 et 2026.5.0.
Observation
Deux messages de test envoyés à bounce@simulator.amazonses.com. Chacun a généré un POST SNS qui a atteint le conteneur :
"POST /webhooks/aws HTTP/1.1" "Amazon Simple Notification Service Agent" 200 402
Rien dans /logs, rien sous /admin/email-logs/bounced. Étant donné que WebhooksController#aws renvoie 406 en cas d’échec de la liste blanche ou de la signature, le code 200 confirme que les deux vérifications sont passées et que Jobs::ProcessSnsNotification est mis en file d’attente ; le job se termine ensuite à next if email_log.nil? car mail.messageId (assigné par SES) n’est jamais égal à EmailLog.message_id (le Message-ID propre à Discourse, défini dans Email::Sender via email_log.message_id = @message.message_id).
L’historique git confirme l’analyse ci-dessus : #7284 (2019) a supprimé la correspondance d’ID pour exactement cette raison, et 61f12e1 (juin 2026) l’a rétablie en utilisant l’ID assigné par SES. Sur release/2026.7, le job n’a pas été modifié depuis cet engagement.
Effet net pour les auto-hébergeurs SES sur l’ESR actuel : le traitement des rebonds est silencieusement désactivé, et la nouvelle notification du tableau de bord oriente les administrateurs vers une configuration qui, ensuite, ne fait rien. Un backport vers release/2026.7 serait bienvenu dès qu’un correctif sera disponible.