Notificações de rejeição SES/SNS não correspondem mais ao EmailLog após o endurecimento de segurança do TopicArn

Contribuir Bug
2

Reproduzido em uma instalação auto-hospedada executando a v2026.7.3 (release/2026.7), com SES SMTP em us-east-1 e PostgreSQL 18 embutido.

Configuração

  • aws_sns_topic_arn_allowlist contém o ARN exato do tópico (verificado no console do SNS).
  • Assinatura HTTPS do SNS para /webhooks/aws confirmada; a mesma assinatura processou corretamente os rejeitos (bounces) de março a junho de 2026 nas versões release/2026.4 e 2026.5.0.

Observação
Duas mensagens de teste enviadas para bounce@simulator.amazonses.com. Cada uma gerou um único POST do SNS que alcançou o contêiner:

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

Nada em /logs, nada em /admin/email-logs/bounced. Como WebhooksController#aws retorna 406 em caso de falha na lista de permissões ou na assinatura, o código 200 confirma que ambas as verificações foram aprovadas e que Jobs::ProcessSnsNotification foi enfileirado; o job então termina em next if email_log.nil? porque mail.messageId (atribuído pelo SES) nunca é igual a EmailLog.message_id (o próprio Message-ID do Discourse, definido em Email::Sender em email_log.message_id = @message.message_id).

O histórico do git corrobora a análise acima: #7284 (2019) removeu a correspondência de IDs exatamente por esse motivo, e 61f12e1 (junho de 2026) a reinstaurou usando o ID atribuído pelo SES. Na release/2026.7, o job permanece inalterado desde esse commit.

Efeito líquido para auto-hospedeiros do SES na ESR atual: o processamento de rejeitos é desativado silenciosamente, e o novo aviso no painel direciona os administradores para uma configuração que, em seguida, não faz nada. Um backport para a release/2026.7 seria bem-vindo assim que uma correção for implementada.

1 Curtiu