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.
Non disponiamo di un’API diretta per impostare il punteggio di rimbalzo; immagino che sia ciò che vorresti fare in questo caso. Sono aperto a una PR che aggiunga il supporto affinché gli amministratori possano impostare manualmente il punteggio di rimbalzo per un utente su un valore arbitrario.
Potrebbero esserci altri motivi per interrompere l’invio di email per un account specifico, oltre ai rimbalzi: loop di feedback sulle email, richieste legali nel contesto del GDPR per non utilizzare tali dati personali (temporaneamente); potrebbero esserci altre ragioni legali o aziendali per cui il provider SSO ne abbia bisogno.
Ho menzionato la modifica del punteggio di rimbalzo perché potrebbe essere un modo per ottenere questo risultato, anche se forse è un po’ una soluzione alternativa. Se non altro, userei quella.
Tuttavia, se questa funzionalità non è già disponibile, avrebbe senso considerare, invece, l’aggiunta di un campo utente per abilitare o disabilitare globalmente tutte le email per un account, controllabile non solo tramite API ma forse anche dal personale? Non so se ciò implicherebbe un cambiamento troppo significativo o se esista un punto centrale nel codice dove questo potrebbe essere verificato; tuttavia, penso che questo potrebbe essere un approccio più generico, utilizzabile in più casi d’uso rispetto alla via del punteggio di rimbalzo per bloccare l’invio di email per un account.