Cómo detener temporalmente los correos electrónicos de una cuenta específica con SSO

La documentación para SSO deja claro que la validación del correo electrónico debe realizarse previamente por parte del proveedor de SSO y que hacerlo de otra manera no es recomendable. Esto tiene sentido.

Sin embargo, ese estado de validación puede cambiar posteriormente. Por ejemplo, el proveedor de SSO podría haber recibido demasiados rebounces duros de los correos que envía a ese usuario, FBLs, etc. ¿Cuál sería la mejor práctica para manejar esto en un contexto de SSO, de modo que Discourse también deje de enviar correos (solo temporalmente) a la dirección de correo de un solo usuario?

He visto sugerencias sobre detener los correos para una cuenta estableciendo todas las configuraciones relacionadas con el correo electrónico de la cuenta para que no envíen mensajes, pero eso sería permanente o al menos complicado de revertir. Busco algo temporal hasta que el proveedor de SSO lo valide nuevamente.

Dado que Discourse tiene formas de detener el envío de correos si el número de rebounces supera cierto umbral, ¿sería útil manipular esos datos para detener los correos? Revisé la API pero no encontré nada para cambiar eso, aunque podría haberlo pasado por alto.

En resumen, ¿cómo se puede detener el envío de correos de una cuenta específica de SSO?

Disculpas si esto ya ha sido respondido en otro lugar, pero no pude encontrar nada.

3 Me gusta

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.