Como pausar temporariamente os e-mails de uma conta específica com SSO?

Suporte SSO
1

A documentação do SSO deixa claro que a validação de e-mail deve ser feita previamente pelo lado do provedor de SSO e que agir de outra forma não é aconselhável. Isso faz sentido.

No entanto, esse estado de validação pode mudar posteriormente. Por exemplo, o provedor de SSO pode ter registrado muitos hard-bounces dos e-mails enviados a esse usuário, FBLs, etc. Qual seria a melhor prática para lidar com isso em um contexto de SSO, de modo que o Discourse também pare (apenas temporariamente) de enviar e-mails para o endereço de e-mail de um único usuário?

Vi sugestões de parar os e-mails para uma conta definindo todas as configurações relacionadas ao e-mail da conta para não enviar e-mails, mas isso seria permanente ou, pelo menos, complicado de reverter. Estou procurando algo temporário, até que o provedor de SSO valide novamente.

Como o Discourse possui mecanismos para parar de enviar e-mails se o número de bounces ultrapassar um certo limite, seria possível manipular esses dados para interromper o envio de e-mails? Verifiquei a API, mas não encontrei nada para alterar isso; talvez eu tenha passado por cima de algo.

Em resumo, como impedir que uma conta específica de SSO envie e-mails?

Peço desculpas se isso já foi respondido em algum lugar, mas não consegui encontrar nada.

3 curtidas
2

We don’t have a direct API for setting bounce score, I guess that is what you would want to do here. I am open to a PR that adds support so admins can manually set bounce score for a user to an arbitrary value.

3

There may be other reasons to stop emails for a specific account other than email bounces: email feedback loops, legal requests in the context of GDPR to not use that private data (temporarily); there may be other legal/business reasons for the SSO provider to need this.

I mentioned fiddling with the bounce score because it could be way to achieve this, although it is maybe a bit of a workaround. If nothing else, I would use that.

But if that’s not already made available, would it make sense to consider, instead, having a user field to globally enable/disable all emails for an account, that could be controlled not just via the API but maybe by staff too? I don’t know if this would imply a too large change or if there’s a central place where this could be checked on the code, however, I think this could be a more generic approach that could be used in more use cases than the bounce score route to stop emails for an account.