Come sospendere temporaneamente le email di un account specifico con SSO?

Supporto SSO
1

La documentazione per SSO chiarisce che la convalida dell’email dovrebbe essere effettuata in anticipo dal lato del provider SSO e che agire diversamente non è saggio. Questo ha senso.

Tuttavia, lo stato di tale convalida potrebbe cambiare successivamente. Ad esempio, il provider SSO potrebbe aver ricevuto troppi hard bounce delle email inviate a quell’utente, FBL, ecc. Qual è il modo migliore per gestire questa situazione in un contesto SSO, in modo che anche Discourse smetta (solo temporaneamente) di inviare email all’indirizzo email di un singolo utente?

Ho visto suggerimenti per bloccare le email per un account impostando tutte le impostazioni relative alle email dell’account su “non inviare email”, ma ciò sarebbe permanente o almeno complicato da annullare. Sto cercando una soluzione temporanea, fino a quando il provider SSO non effettua nuovamente la convalida.

Poiché Discourse dispone di metodi per bloccare l’invio di email se il numero di bounce supera una certa soglia, manipolare tali dati potrebbe essere un modo per interrompere l’invio? Ho controllato l’API ma non ho trovato nulla per modificare questo aspetto, anche se potrei averlo perso.

In sintesi, come si può impedire a un specifico account SSO di inviare email?

Mi scuso se questa domanda è già stata risposta altrove, ma non sono riuscito a trovare nulla.

3 Mi Piace
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.