SES/SNS bounce notifications no longer match EmailLog after TopicArn security hardening

Contribute Bug
2

Reproduced on a self-hosted install running v2026.7.3 (release/2026.7), SES SMTP in us-east-1, embedded PostgreSQL 18.

Setup

  • aws_sns_topic_arn_allowlist contains the exact topic ARN (verified against the SNS console).
  • SNS HTTPS subscription to /webhooks/aws confirmed; the same subscription processed bounces correctly from March to June 2026 on release/2026.4 and 2026.5.0.

Observation
Two test messages to bounce@simulator.amazonses.com. Each produced one SNS POST that reached the container:

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

Nothing at /logs, nothing under /admin/email-logs/bounced. Since WebhooksController#aws returns 406 on an allowlist or signature failure, the 200 confirms both checks pass and Jobs::ProcessSnsNotification is enqueued; the job then exits at next if email_log.nil? because mail.messageId (SES-assigned) never equals EmailLog.message_id (Discourse’s own Message-ID, set in Email::Sender at email_log.message_id = @message.message_id).

The git history agrees with the analysis above: #7284 (2019) dropped the ID match for exactly this reason, and 61f12e1 (June 2026) reinstated it using the SES-assigned ID. On release/2026.7 the job is unchanged since that commit.

Net effect for SES self-hosters on the current ESR: bounce processing is silently disabled, and the new dashboard notice steers admins into a configuration that then does nothing. A backport to release/2026.7 would be welcome once a fix lands.

2 Likes