Riproduzione su un’installazione self-hosted che esegue la v2026.7.3 (release/2026.7), SES SMTP in us-east-1, PostgreSQL 18 incorporato.
Configurazione
aws_sns_topic_arn_allowlistcontiene l’ARN esatto del topic (verificato nella console SNS).- Confermata l’iscrizione HTTPS di SNS a
/webhooks/aws; la stessa iscrizione ha elaborato correttamente i bounce da marzo a giugno 2026 su release/2026.4 e 2026.5.0.
Osservazione
Due messaggi di test a bounce@simulator.amazonses.com. Ciascuno ha generato un POST SNS che ha raggiunto il container:
"POST /webhooks/aws HTTP/1.1" "Amazon Simple Notification Service Agent" 200 402
Niente in /logs, niente sotto /admin/email-logs/bounced. Dato che WebhooksController#aws restituisce 406 in caso di fallimento dell’allowlist o della firma, il 200 conferma che entrambi i controlli passano e che Jobs::ProcessSnsNotification viene messo in coda; il job termina poi con next if email_log.nil? perché mail.messageId (assegnato da SES) non corrisponde mai a EmailLog.message_id (il proprio Message-ID di Discourse, impostato in Email::Sender tramite email_log.message_id = @message.message_id).
La cronologia git conferma l’analisi sopra: #7284 (2019) ha rimosso il confronto degli ID per esattamente questo motivo, e 61f12e1 (giugno 2026) lo ha ripristinato utilizzando l’ID assegnato da SES. Su release/2026.7 il job non è stato modificato da quel commit.
Effetto netto per gli utenti self-hosted di SES sull’attuale ESR: l’elaborazione dei bounce è disabilitata silenziosamente, e la nuova notifica della dashboard orienta gli amministratori verso una configurazione che poi non ha alcun effetto. Sarebbe gradito un backport su release/2026.7 non appena verrà applicata una correzione.