Comment suspendre temporairement les e-mails d'un compte spécifique avec SSO ?

Soutien SSO
1

La documentation pour SSO indique clairement que la validation des e-mails doit être effectuée au préalable par le fournisseur SSO et que faire autrement n’est pas judicieux. Cela semble logique.

Cependant, cet état de validation peut changer par la suite. Par exemple, le fournisseur SSO a peut-être constaté trop de rebonds définitifs (hard-bounces) pour les e-mails qu’il envoie à cet utilisateur, des FBL, etc. Quelle serait la meilleure pratique pour gérer cela dans un contexte SSO afin que Discourse cesse également (de manière temporaire uniquement) d’envoyer des e-mails à l’adresse e-mail d’un utilisateur unique ?

J’ai vu des suggestions consistant à arrêter l’envoi d’e-mails pour un compte en définissant tous les paramètres liés aux e-mails du compte sur « ne pas envoyer d’e-mails », mais cela serait permanent ou du moins difficile à annuler. Je cherche une solution temporaire jusqu’à ce que le fournisseur SSO le revalide.

Comme Discourse dispose de moyens pour arrêter l’envoi d’e-mails si le nombre de rebonds dépasse un certain seuil, manipuler ces données serait-il un moyen d’interrompre l’envoi d’e-mails ? J’ai consulté l’API mais je n’ai rien trouvé pour modifier cela, bien que j’aie peut-être manqué quelque chose.

En bref, comment empêcher un compte SSO spécifique d’envoyer des e-mails ?

Veuillez m’excuser si cela a déjà été répondu ailleurs, mais je n’ai rien trouvé.

3 « J'aime »
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.