Уведомления SES/SNS о возвратах больше не совпадают с EmailLog после усиления безопасности TopicArn

Внести вклад Ошибка
2

Воспроизведено на self-hosted-инсталляции с версией v2026.7.3 (release/2026.7), SES SMTP в us-east-1, встроенный PostgreSQL 18.

Настройка

  • aws_sns_topic_arn_allowlist содержит точный ARN топика (проверено в консоли SNS).
  • Подписка SNS по HTTPS на /webhooks/aws подтверждена; та же подписка корректно обрабатывала отклонённые письма (bounces) с марта по июнь 2026 года на release/2026.4 и 2026.5.0.

Наблюдения
Два тестовых сообщения на bounce@simulator.amazonses.com. Каждое из них породило один POST-запрос SNS, дошедший до контейнера:

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

Ничего не появилось в /logs, ничего нет и в /admin/email-logs/bounced. Поскольку WebhooksController#aws возвращает 406 при сбое проверки allowlist или подписи, код 200 подтверждает, что обе проверки пройдены, и Jobs::ProcessSnsNotification добавлен в очередь; затем задача завершается на next if email_log.nil?, потому что mail.messageId (назначенный SES) никогда не совпадает с EmailLog.message_id (собственный Message-ID Discourse, устанавливаемый в Email::Sender через email_log.message_id = @message.message_id).

История git подтверждает вышеприведённый анализ: #7284 (2019) убрал проверку совпадения ID именно по этой причине, а 61f12e1 (июнь 2026) вернул её, используя ID, назначенный SES. В release/2026.7 задача не изменялась с момента этого коммита.

Итоговый эффект для self-hosted пользователей SES на текущем ESR: обработка отклонённых писем (bounces) молча отключена, а новое уведомление на дашборде направляет администраторов в конфигурацию, которая затем не выполняет никаких действий. Бэкпорт в release/2026.7 будет приветствован, как только появится исправление.

2 лайка