Las notificaciones de rebot de SES/SNS ya no coinciden con EmailLog tras el endurecimiento de seguridad de TopicArn

Contribuir Error
2

Reproducido en una instalación autoalojada que ejecuta v2026.7.3 (release/2026.7), con SES SMTP en us-east-1 y PostgreSQL 18 embebido.

Configuración

  • aws_sns_topic_arn_allowlist contiene el ARN exacto del tema (verificado en la consola de SNS).
  • Suscripción HTTPS de SNS a /webhooks/aws confirmada; la misma suscripción procesó correctamente los rebotes desde marzo hasta junio de 2026 en release/2026.4 y 2026.5.0.

Observación
Dos mensajes de prueba enviados a bounce@simulator.amazonses.com. Cada uno generó un POST de SNS que llegó al contenedor:

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

Nada en /logs, nada bajo /admin/email-logs/bounced. Dado que WebhooksController#aws devuelve 406 ante un fallo en la lista de permisos o en la firma, el 200 confirma que ambas comprobaciones se superan y que Jobs::ProcessSnsNotification se encola; el trabajo luego termina en next if email_log.nil? porque mail.messageId (asignado por SES) nunca es igual a EmailLog.message_id (el propio Message-ID de Discourse, establecido en Email::Sender mediante email_log.message_id = @message.message_id).

El historial de git coincide con el análisis anterior: #7284 (2019) eliminó la coincidencia de ID por exactamente esta razón, y 61f12e1 (junio de 2026) la restableció utilizando el ID asignado por SES. En release/2026.7 el trabajo no ha cambiado desde ese commit.

Efecto neto para los usuarios autoalojados de SES en la ESR actual: el procesamiento de rebotes se desactiva silenciosamente, y el nuevo aviso del panel guía a los administradores hacia una configuración que luego no hace nada. Sería bienvenido un backport a release/2026.7 una vez que se implemente una corrección.

2 Me gusta