Estoy trabajando con un usuario para solucionar problemas relacionados con la no recepción de correos electrónicos y me he topado con la acción “revocar correo electrónico” registrada en su cuenta. ¿Cómo puedo cancelar o deshacer esta acción?
Además: si el correo electrónico de un usuario es revocado, ¿esto se refleja en los registros de Correos Enviados o Correos Omitidos? ¿O solo en la acción de Revocar Correo Electrónico?
La acción de revocar correo electrónico se activa cuando varios correos enviados a un usuario rebotan (no se entregan). Cada vez que un correo rebota, el “puntuación de rebote” del usuario se incrementa según el valor establecido en la configuración puntuación de rebote suave o puntuación de rebote duro de tu sitio. Una vez que la puntuación de rebote de un usuario alcanza el valor de la configuración umbral de puntuación de rebote de tu sitio (que por defecto es 4), se activa la acción de revocar correo electrónico.
Puedes deshacer esta acción yendo a la página de administración del usuario y haciendo clic en el botón “Restablecer” que se encuentra en la fila “Puntuación de rebote” cerca de la parte superior de la página.
Si no haces clic en el botón Restablecer, Discourse limpiará automáticamente la puntuación de rebote del usuario después del período de tiempo establecido en restablecer puntuación de rebote después de días. Esta configuración tiene un valor predeterminado de 30 días. Después de ese período, Discourse intentará enviar correos electrónicos al usuario nuevamente.
Si no se envía un correo electrónico a un usuario que ha superado el umbral de puntuación de rebote del sitio, se agregará una entrada en los registros de Omitidos. El motivo de omisión se establecerá en “Superado umbral_puntuación_rebote”.
Gracias. Entonces, si veo “Exceeded bounce_score_threshold” en el registro de omitidos para un mensaje de correo reciente enviado al Usuario X, ¿puedo asumir que hubo una acción de “revocar correo” para ese usuario anteriormente, y viceversa?
El contexto es que uno de mis usuarios no está recibiendo correos de nuestra instancia de Discourse. Es bastante competente, así que confío en sus informes de que revisó su carpeta de spam, etc. Le restablecí el puntaje de rebote hace un tiempo, pero solo me encontré con el registro de “Revocar correo” para él hoy.
Esto es interesante. Había asumido que la puntuación de rebote se restablecería para aquellos cuyos correos electrónicos aún no habían sido deshabilitados (como funciona en Mailman). Supongo que lo más cercano sería establecer esta configuración en unos 10 años.
Por lo que puedo ver, Discourse siempre restablece la puntuación de rebote de un usuario y luego intenta reenviar los correos electrónicos al usuario. La única diferencia entre cómo se manejan los rebotes temporales y permanentes es que los rebotes permanentes incrementan la puntuación de rebote en un valor predeterminado de 2 (establecido por la configuración del sitio hard bounce score) en lugar de en un valor predeterminado de 1 (establecido por la configuración del sitio soft bounce score).
Eso funcionaría, pero podría tener consecuencias no deseadas. Por ejemplo, los usuarios que superaron el umbral de puntuación de rebote debido a la reciente interrupción de Gmail tendrían que esperar 10 años para que su puntuación de rebote se restablezca automáticamente.
Mailman 2 tiene valores predeterminados más altos para la configuración y el umbral de rebotes, pero una vez que se alcanza, te dan de baja. Puedo ver el argumento a favor y en contra. Edición: No recuerdo los detalles, pero creo que en algún momento se te ofrece la oportunidad de responder a un correo electrónico administrativo, lo que restablecería tu puntuación de rebotes y te mantendría en la lista.
Muchas personas que alojan Discourse por su cuenta probablemente usan Mailgun, el cual mantiene la dirección de correo electrónico en su lista de supresión tras un único “fallo permanente” y, por lo tanto, ignorará el enfoque más flexible de Discourse.
Aparentemente, es posible obtener esa lista de supresión mediante la API de Mailgun, y supongo que también podría ser posible sincronizarla con la configuración de Discourse.
Hoy recibí un correo de Google que decía inequívocamente que alguien había obtenido mi contraseña: “Google ha tomado conocimiento de que otra persona conoce tu contraseña”, por lo que me pregunto si eso está relacionado con la “interrupción”…
Se trata de la eliminación de la configuración bounce_score_threshold_deactivate. Me pregunto si fue un error. Si la configuración predeterminada era difícil de alcanzar, la solución era bajarla.
Una consecuencia no deseada de esa eliminación para un foro grande sería intentar enviar correos electrónicos a un número creciente de direcciones inválidas de forma regular durante muchos años. Esto podría generar problemas con un servicio externo (como Mailgun, que suprime una dirección tras un único rebote de fallo permanente) o afectar la reputación de la IP.
En la situación actual, a menos que haya malinterpretado algo, Discourse cree que está enviando correos electrónicos que Mailgun simplemente se niega a enviar debido a su lista de supresión, y no es posible sincronizar el enfoque de Discourse con el de Mailgun.
Lo había olvidado. No estoy seguro de que la configuración bounce_score_threshold_deactivate funcionara para evitar que Discourse intentara enviar correos electrónicos a direcciones inválidas. El problema es que, una vez que un usuario alcanza el umbral de puntuación de rebote, Discourse dejará de enviarle correos electrónicos hasta que haya transcurrido el período de tiempo establecido por la configuración reset bounce score after days. En ese momento, la puntuación de rebote del usuario se restablecerá y el proceso comenzará de nuevo.
No estoy seguro de cuál sería la mejor solución para esto. Si he entendido correctamente las cosas, parece que, con el tiempo, un sitio de Discourse intentará enviar correos electrónicos a un número creciente de direcciones inválidas.
Esto tiene al menos dos facetas. Una es qué política es buena para Discourse, asumiendo que el remitente del correo (por ejemplo, localhost) se adhiere a esto. La otra es cómo sincronizar las cosas con un servicio de envío de correos que no lo hará (por ejemplo, Mailgun).
Creo que ya existe un mensaje en Discourse que dice algo como: “Por favor, verifica tu dirección de correo electrónico, ya que hemos tenido problemas al enviar a ella”. Quizás Discourse necesite un enfoque más agresivo para desactivar los correos que rebotan, combinado con un aviso del sitio no descargable sobre la falta de envío de correos.
La sincronización con remitentes externos sería más difícil. Mailgun indica que es posible obtener su lista de supresión a través de su API pero aún no sé si también es posible eliminar direcciones mediante la API. Si es posible hacer ambas cosas, entonces Discourse podría desactivar una dirección tan pronto como entre en la lista de supresión y eliminarla de dicha lista cuando se realice un paso manual dentro de Discourse por parte del administrador o el usuario (por ejemplo, respondiendo a un correo de confirmación). Otro problema relacionado con esto es que es probable que cada proveedor tenga reglas diferentes.