Документация по SSO четко указывает, что валидация электронной почты должна выполняться заранее со стороны провайдера SSO, и что поступать иначе неразумно. Это логично.
Однако состояние этой валидации может измениться впоследствии. Например, провайдер SSO мог получить слишком много жестких отскоков (hard-bounces) от писем, отправленных этому пользователю, или жалобы на спам (FBL) и т. д. Какие существуют лучшие практики для обработки такой ситуации в контексте SSO, чтобы Discourse также временно прекратил отправку писем на адрес электронной почты конкретного пользователя?
Я видел предложения по остановке отправки писем для аккаунта путем настройки всех параметров, связанных с электронной почтой, на запрет отправки, но это было бы постоянным решением или, по крайней мере, сложным для отмены. Я ищу временное решение до тех пор, пока провайдер SSO не подтвердит валидность снова.
Поскольку в Discourse есть механизмы для остановки отправки писем, если количество отскоков превышает определенный порог, может ли манипулирование этими данными стать способом приостановки отправки? Я проверил API, но не нашел ничего, что позволяло бы изменить эти данные, хотя, возможно, я что-то упустил.
Короче говоря, как остановить отправку писем для конкретного аккаунта SSO?
Извините, если этот вопрос уже где-то обсуждался, но я не смог найти ответа.
У нас нет прямого API для установки показателя отказов (bounce score), хотя, полагаю, именно это вам нужно. Я открыт к PR, который добавит возможность для администраторов вручную задавать произвольное значение показателя отказов для пользователя.
Для остановки отправки писем на конкретный аккаунт могут существовать и другие причины, помимо возвратов писем: циклы обратной связи по электронной почте, юридические запросы в контексте GDPR о запрете использования этих персональных данных (временно); у провайдера SSO могут быть и другие юридические или бизнес-причины для необходимости этого.
Я упоминал о манипулировании баллом возврата писем, так как это может быть способом достижения данной цели, хотя это, возможно, немного обходной путь. Если ничего другого нет, я бы использовал именно этот вариант.
Но если такой функционал ещё не реализован, имеет ли смысл рассмотреть, например, добавление поля для пользователя, позволяющего глобально включать или отключать все письма для аккаунта, управляемое не только через API, но, возможно, и персоналом? Я не знаю, повлечёт ли это слишком большие изменения или существует ли центральное место в коде, где это можно проверять. Однако, я считаю, что это более универсальный подход, который может применяться в большем количестве сценариев, чем использование балла возврата писем для остановки отправки писем на аккаунт.