The documentation for SSO makes clear that email validation should be made beforehand on the side of the SSO provider and that doing otherwise is not wise. That makes sense.
However, that validation state may change afterwards. For example, the SSO provider may had seen too many hard-bounces of the emails it sends to that user, FBLs, etc. What would be the best practices way to handle this in a SSO context so that Discourse also stops (only temporarily), from sending emails to the email address of a single user?
I have seen suggestions of stopping emails for an account by setting all the email related settings of the account to not send emails, but that would be permanent or at least tricky to revert. I’m looking for something temporary until the SSO provider validates it again.
As Discourse has ways of stop sending emails if the number of email bounces go above some threshold, would playing with that data be a way to halt emails? I checked the API but haven’t found anything to change that, but I might have missed it.
In short, how to stop a specific SSO account from sending emails?
Apologies if this is already answered somewhere, but I couldn’t find anything.
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.
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.