SES/SNS-Bounce-Benachrichtigungen stimmen nach Security-Hardening von TopicArn nicht mehr mit EmailLog überein

Beitragen Fehler
2

Reproduziert auf einer Self-Hosted-Installation mit v2026.7.3 (release/2026.7), SES SMTP in us-east-1 und eingebettetem PostgreSQL 18.

Setup

  • aws_sns_topic_arn_allowlist enthält die exakte Topic-ARN (im SNS-Konsolenscreen verifiziert).
  • Die HTTPS-Abonnierung von SNS für /webhooks/aws wurde bestätigt; dasselbe Abo verarbeitete Bounces korrekt von März bis Juni 2026 auf release/2026.4 und 2026.5.0.

Beobachtung
Zwei Testnachrichten an bounce@simulator.amazonses.com. Jede erzeugte einen einzelnen SNS-POST, der den Container erreichte:

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

Nichts unter /logs, nichts unter /admin/email-logs/bounced. Da WebhooksController#aws bei einem Allowlist- oder Signaturfehler 406 zurückgibt, bestätigt der 200-Status, dass beide Prüfungen bestanden werden und Jobs::ProcessSnsNotification in die Warteschlange gestellt wird; der Job bricht dann bei next if email_log.nil? ab, da mail.messageId (von SES zugewiesen) niemals mit EmailLog.message_id (die eigene Message-ID von Discourse, gesetzt in Email::Sender bei email_log.message_id = @message.message_id) übereinstimmt.

Die Git-Historie stimmt mit der obigen Analyse überein: #7284 (2019) entfernte die ID-Abgleichslogik aus genau diesem Grund, und 61f12e1 (Juni 2026) stellte sie unter Verwendung der von SES zugewiesenen ID wieder her. Auf release/2026.7 ist der Job seit diesem Commit unverändert.

Nettoeffekt für SES-Self-Hoster auf der aktuellen ESR: Die Bounce-Verarbeitung wird stillschweigend deaktiviert, und die neue Dashboard-Mitteilung lenkt Admins in eine Konfiguration, die dann nichts bewirkt. Ein Backport auf release/2026.7 wäre willkommen, sobald ein Fix vorliegt.

2 „Gefällt mir“