Esta nota tiene como objetivo resumir mi experiencia de administración mientras silencio a algunos usuarios. No estoy pidiendo cambios necesariamente, solo cito los desafíos que pueden traducirse en solicitudes de revisión.
Cuando necesito silenciar a un usuario debido a correos electrónicos rebotados, no quiero que se le envíe un correo electrónico para notificarle del evento.
No veo una opción de administración para agregar una razón de silencio personalizada a la lista existente. Me gustaría agregar “Correos electrónicos rebotados”.
Me gustaría establecer una de las opciones de período de silencio disponibles como predeterminada. No quiero tener que establecer el período de tiempo en el menú desplegable para cada evento.
Quiero informar al usuario sobre por qué ha sido silenciado, con más información que la “razón” de una línea. El cuadro está ahí para enviar un correo electrónico al usuario con una nota, pero de nuevo, eso envía un correo electrónico al usuario. Solo quiero enviarle un mensaje porque sé que el correo electrónico no funciona.
¿Se envían otros correos electrónicos de Discourse a un usuario después de que ha sido bloqueado o silenciado? Para este escenario específico y posiblemente otros, no quiero que se envíe más correo a este usuario, especialmente si se ha suscrito a muchas notificaciones.
Sobre la eliminación de un usuario en este mismo escenario: podemos simplemente eliminar al usuario, y también podemos “eliminar y prohibir tanto la dirección de correo electrónico como la dirección IP”. ¿Por qué están vinculados? Me gusta la idea de prohibir una dirección de correo electrónico. Raramente podría querer prohibir una dirección IP. Pero prohibir una IPv4 es incómodo por varias razones; tal vez esté bien con IPv6, pero aún no hemos llegado allí. Hasta que estos conceptos se separen, ¿no podemos simplemente prohibir una dirección de correo electrónico? Si supiera más sobre los internos de Discourse, estaría feliz de programar un proceso que limpie elementos específicos de las listas de prohibición, pero no sé dónde encontrar esos datos.
Tenemos MaxMind activo para este sitio y me gustaría usar la dirección IP para obtener una ubicación que ayude a determinar si el usuario solo debe ser silenciado o eliminado. Por ejemplo, si la dirección utilizada por última vez está distante de la dirección de registro (más otras métricas), entonces eliminaría la cuenta por simplemente oler mal. Pero la ventana emergente que muestra información de IP no muestra una ubicación. ¿Es un error o debería revisar MaxMind nuevamente?
Recibo avisos de rebote en mi dirección postmaster@; así es como sé que los correos electrónicos del foro están rebotando. Alguien podría sugerir que mire la Puntuación de Rebote para cortes automáticos para evitar enviar correos electrónicos a alguien que ya tiene rebotes registrados. No tenemos datos de rebote para la puntuación, no he configurado Discourse para consultar POP3 (IMAP??) para tales datos. Todo lo que veo en meta son anécdotas del foro sobre su configuración. ¿Hay una documentación dedicada real sobre este tema?
Nuevamente, todo esto es solo para compartir la experiencia de usuario (no tan buena) en esta área específica, para quien pueda estar interesado.
Aún no he configurado el umbral de puntuación de rebote porque no tengo Discourse revisando el correo electrónico en busca de notificaciones de rebote. La información en este hilo de meta es la mejor que he encontrado sobre el tema de la configuración para procesar rebotes. Durante los próximos días, me embarcaré en la búsqueda de documentación más completa.
Pero sí, hoy estoy estableciendo un umbral de rebote muy bajo.
[citar=“Arquitecto, post:6, tema:323151”]Tiene que haber una razón elegida o escrita antes de que sea posible silenciar la cuenta.[/citar]
Esto tiene sentido porque se envía un mensaje al usuario para informarle sobre el evento. Ese mensaje del sitio no es claro acerca de lo que exactamente queremos que el usuario haga. Entonces, después de que se envía el mensaje, respondo a ese mensaje para pedirles que respondan cuando hayan corregido la situación del correo electrónico.
Entonces, los desafíos de novato que enfrento ahora incluyen:
Quiero ese mensaje para el usuario, pero preferiría modificar el texto. Cambiar admin/customize/email_templates/system_messages.email_revoked para inglés no lo cambia para todos los demás idiomas. ¿O hay una función para hacer una traducción automática en uno o todos los system_messages?
Sin una búsqueda en admin/customize/email_templates/ es difícil encontrar el texto correcto para editar en system_messages o user_notifications, y saber qué procesos los activan.
No quiero enviar un correo cuando el problema, por definición, es que no están recibiendo correos.
Cuando publico esa respuesta en el perfil del usuario en el mensaje del sistema, se envía otro correo. Si podemos bloquear eficazmente los correos salientes a esa dirección, eso no ocurrirá. Es decir, ¿todos los funciones de correo saliente pasan por un proceso central que primero verifica si el umbral de rebotes ha sido excedido? ¿O me falta alguna función en torno a Silenciar que bloquee el correo saliente sin tener que vincular esa decisión al umbral de rebotes?
Idealmente, cuando el usuario reemplaza la dirección de correo por algo válido, o hace clic en una opción de “mi dirección está bien ahora”, sería genial que el servidor enviara un correo de prueba y, si tiene éxito, borre la bandera o contador de rebote.
(Aleatorio) Hay un número fijo de admin_js.admin.user.suspend_reasons y están “duro” identificados para impedir la personalización para otro propósito. Es decir, podemos cambiar el texto para admin_js.admin.user.suspend_reasons.combative y hay un único admin_js.admin.user.suspend_reasons.custom, pero no parece que podamos crear un nuevo admin_js.admin.user.suspend_reasons.bouncing_email.
Este escenario no solo se aplica a los rebotes. Puedo pensar en otros escenarios donde querríamos notificar al usuario con un mensaje local que no podemos enviarle correo y darle un mensaje personalizado almacenado que le diga qué hacer.
Sospecho que todo esto describe un comportamiento muy afinado que probablemente no sube en la lista de prioridades, pero todavía no sé si o cómo otros manejan esto. Gracias por la paciencia…
Solo mantendré este hilo actualizado con el progreso…
Acabo de encontrar esta documentación para configurar el manejo de rebotes:
Las imágenes aquí también son extremadamente útiles:
La implementación de esta funcionalidad debería abordar suficientes desafíos aquí para manejar el correo devuelto de manera efectiva. Todavía necesito averiguar exactamente cómo notificaremos a una base de usuarios multilingüe de manera efectiva y los pondremos de nuevo en marcha rápidamente cuando hayan solucionado problemas de correo electrónico. Es decir, cuando hayan realizado un cambio efectivo, necesitan notificarnos a nosotros o al sistema para que se puedan levantar los bloqueos sobre ellos.
Cuando una dirección de correo electrónico devuelve los correos electrónicos automatizados de Discourse, parece que no necesariamente necesitarías/querrías silenciar o eliminar su cuenta por eso, a menos que sospeches que es una cuenta falsa o algo sin un correo electrónico válido.
Supongo que esa es probablemente la razón por la que querrías poner la cuenta en espera temporalmente para validar que tienen un correo electrónico que funciona, ¿tienen un gran volumen de casos como ese o es práctico lidiar con ellos uno a uno manualmente?
Existen algunas otras opciones, como cambiar manualmente la configuración de notificación por correo electrónico, o cambiar temporalmente la dirección de correo electrónico que no funciona por otra dirección que funcione y que esté controlada por el administrador o algo similar. Esa podría no ser la mejor idea, solo algunas ideas aleatorias aquí.
Cuando se elimina una cuenta, esta no envía una notificación por correo electrónico sobre eso la última vez que lo comprobé. Una política simple pero algo brutal es eliminar las cuentas si no tienen un correo electrónico que funcione.
Estamos en la misma página. Hay diferentes escenarios que diferentes gerentes querrán manejar de manera diferente. Estoy explorando este software para entender qué hace, cómo se pretende usar y cómo lo usan otros.
El objetivo subyacente de esta iniciativa/consulta es doble: Primero, evitar proactivamente el abuso. Segundo, evitar enviar correos electrónicos que reboten, lo que podría resultar en que nuestro sitio sea marcado como fuente de correo no entregable. Esto puede resultar en listados temporales en RBLs y quiero evitar tales tonterías.
No tenemos un alto volumen para este sitio, pero hay grupos de usuarios, similares pero diferentes a TL0-4. Los usuarios de un grupo no deben ser silenciados si algo sale mal con su correo electrónico. Los usuarios de otro grupo con algunas publicaciones recientes sobre el tema no deben ser silenciados. Las cuentas sin actividad o sin actividad válida reciente podrían ser silenciadas para llamar su atención si alguna vez regresan.
El concepto de silenciar a las personas para llamar su atención es incómodo. Y realmente no me importan las direcciones de correo electrónico. La intención real es que si tenemos una dirección de correo electrónico falsa, siento que es más probable que una cuenta sea una fuente de abuso. Así que los silenciaré preventivamente, buscaré alguna respuesta y, si no sabemos nada de ellos durante un largo período, simplemente eliminaré la cuenta. Un usuario participante (TL1?) del que simplemente no hemos tenido noticias durante mucho tiempo podría ser puesto en silencio/revisión a largo plazo.
Ya que estamos aquí, todo esto también implica que las personas están creando cuentas sin un correo electrónico válido, o cambiando sus direcciones a algo inválido. Estoy revisando la Documentation y querré crear una automatización para: Silenciar a los nuevos usuarios TL0 hasta después de que hayan visto un par de hilos, luego enviarles un correo electrónico. Si obtenemos un rebote de estos mensajes específicos, los pondremos en estado de revisión. Así que ningún correo de bienvenida hasta después de que estemos seguros de que son humanos moviéndose por el sitio, y ningún permiso hasta que estemos seguros de que verifican su correo electrónico.
Para que conste, no es posible activar tu cuenta sin verificar primero tu correo electrónico (a menos que sea activada manualmente por un administrador, o estés usando SSO y no verificando con tu IdP).
Eso no es necesariamente cierto, hay otras razones como que el correo electrónico puede estar temporalmente desactivado, o han prohibido tu remitente (lo que también puede ser temporal, como un silencio temporal de cuenta).
El primer paso que recomendaría para lo que estás describiendo sería enviar un mensaje privado normal a un usuario si su correo electrónico no recibe mensajes como una alerta sobre eso en caso de que no lo sepan, puedes hacer de eso un mensaje privado de advertencia oficial con la casilla para hacer que el icono de alerta del sobre sea rojo en lugar de verde. Esto también pone una nota en su cuenta de que se les ha enviado uno o varios mensajes privados de advertencia oficiales, por lo que tendrás eso documentado.
Como se mencionó con la configuración predeterminada, las nuevas cuentas deben ser validadas haciendo clic en el enlace en el correo electrónico de verificación primero antes de que puedan usar tu sitio, a menos que hayas omitido eso.
Eso parece estar básicamente ya habilitado con la configuración predeterminada, aunque TL0 puede publicar respuestas/temas públicos, no pueden enviar mensajes privados a nadie hasta que sean promovidos al nivel básico TL1, lo que requiere algo de lectura y el correo electrónico debería ser validado antes de eso.
