Solicitudes de características: cuenta de correo separada para resúmenes

Contribuir Característica
1

Desde un novato: hoy tuvimos una experiencia en la que básicamente todo nuestro correo electrónico se detuvo y los usuarios no podían registrarse, recuperar contraseñas ni iniciar sesión con correo electrónico, porque el resumen semanal se activó después de una migración de un foro antiguo y había más de 300 mil correos en la cola de sidekiq. Por lo tanto, cualquier persona que intentara iniciar sesión por correo, registrarse o recuperar su contraseña, etc., no recibió ningún correo y quedó jodida (como se dice)..

El problema se debió al hecho de que usamos GMAIL como retransmisor de correo, y GMAIL (gratuito) establece límites para este tipo de retransmisión SMTP, por lo que GMAIL nos bloqueó por un día.

Me gustaría solicitar esta función en el futuro (a menos que exista otra forma de abordar esto).

Propuesta

Agregar otro conjunto de variables en app.yml que permitan a los administradores configurar un retransmisor de correo diferente para los resúmenes.

Durante el proceso de configuración, el diálogo podría incluir la pregunta: ¿Desea configurar un servidor SMTP diferente para los resúmenes?, y el usuario podría usar el mismo retransmisor SMTP si lo desea.

Fundamentación

Para foros grandes con mucha actividad de resúmenes, sería útil tener la opción de retransmitir estos correos de resumen a través de un retransmisor SMTP diferente al utilizado para tareas clave, como recuperación de contraseñas, inicio de sesión y registro.

Por ahora, hemos desactivado todos los resúmenes. Vimos una opción para limitar esto según el número de días X recientes. El valor predeterminado, cuando lo revisé hoy, era de 365 días. Por alguna razón, nuestro servidor migrado acumuló más de 300 mil mensajes en la cola.

Discusión

No es un problema enorme, pero creo que sería bueno separar los correos de resumen de los correos críticos, ya que incluso si la prioridad de la cola es mayor para los correos críticos, si el retransmisor SMTP se bloquea debido a un número excesivo de resúmenes, los correos críticos también quedarán bloqueados.

Además, algunos foros podrían estar experimentando una situación similar sin saber por qué su correo SMTP no funciona; cuando en realidad fue bloqueado por la razón mencionada.

Gracias por su atención y consideración.

TangentialDuck

2 Me gusta
2

Tenga en cuenta que no se admite el uso de Gmail gratuito para enviar correos electrónicos desde Discourse. Se trata nuevamente de los términos de servicio de Google. Usar Gmail de esta manera se acerca a una instalación #no-soportada.

Es difícil ver cómo tiene sentido implementar esta solicitud de función; si hubiera utilizado un mecanismo de correo electrónico compatible, el incidente no podría haber ocurrido.

3

Eso no es cierto.

Tenemos un dominio de Google y el correo gratuito ha sido soportado durante muchos años y sigue estándolo ahora.

Trata de ser un poco más comprensivo después de haber administrado un foro durante 20 años… No acabamos de salir del huevo ayer, @Stephen

1 me gusta
4

Absolutamente. Las comunidades que ignoran nuestra guía de correo electrónico se encuentran con esto constantemente.

Google no permite el envío de correos transaccionales desde cuentas de Gmail, y hemos visto comunidades perder sus cuentas de forma permanente al intentar hacerlo. Las cuentas de pago de GSuite también tienen límites estrictos en la cantidad de correos transaccionales que se pueden enviar por día. No eres la primera persona en esta situación y no podemos ayudarte a eludir los términos implementados por Google.

1 me gusta
5

Acabo de iniciar sesión en nuestra cuenta de GSuite y revisé los Términos de Servicio; lo que estás diciendo no es cierto:

@Stephen, eres demasiado rápido para sacar la pistola. No pedí una función para “eludir los Términos de Servicio de Google”, así que por favor evita poner palabras en mis publicaciones.

Eres demasiado rápido para sacar la pistola y acusar falsamente a las personas, @Steven, así que quizás deberías dejar que otros respondan a mis solicitudes, aquellos que no son tan precipitados.

6

Hay cierta inconsistencia en lo que estás diciendo aquí:

Gmail no es G-Suite. Las cuentas de pago de G-Suite tienen los siguientes límites:

Tipo de límite Límite
Mensajes por día
Límite de envío diario* 2.000 (500 para cuentas de prueba)

Las cuentas gratuitas de Gmail siempre tienen el límite de 500 correos.

Eso son los Términos de Servicio de Google, no tiene nada que ver con lo anterior. Definitivamente hay una diferencia entre «funcionó hasta ahora» y estar autorizado para hacerlo. Hemos visto que los usuarios intenten esto en los últimos siete años y nunca ha funcionado:

Más lectura sobre el tema

New setup - errors when trying to send emails through gmail - #2 by pfaffman
Office 365 SMTP settings - #2 by codinghorror
https://meta.discourse.org/t/setup-smtp-in-discourse/79173/2
Anyone using gmail for SMTP? - #8 by sam
Gmail SMTP Relay Setup not working - #2 by justin
Can I use gmail smtp? - #2 by fefrei
POP3 polling error - #4 by pfaffman
Sidekiq queue too large - Google email provider problems - #2 by codinghorror

Hay una guía de configuración de correo con una lista de proveedores recomendados. No estás obligado a seguirla, pero no podemos ayudarte a usar Gmail o GSuite de formas que no estaban previstas.

1 me gusta
7

Sí, ya sabía todo eso antes de publicar, @Steven.

Realmente deberías evitar subestimar el conocimiento de alguien que está en línea desde antes de que existiera el navegador Mosaic y tener cuidado con cómo respondes. No te quites la diversión de Discourse y de la tecnología en general haciendo declaraciones acusatorias hacia otros.

Primero me dijiste que “NO existe Gmail gratuito” (lo cual sabía que era incorrecto) y me acusaste de alguna actividad maliciosa; luego fuiste a investigar y descubriste que G Suite tiene un límite de 2.500 correos al día, algo que yo ya sabía desde hace mucho tiempo, ya que he gestionado esta cuenta de G Suite durante años.

Deberías disculparte cuando actúas con tanta precipitación, acusas a otros de cosas graves y te equivocas en los detalles.

No es divertido, en absoluto, publicar una solicitud de función sencilla y tener que responder a esta energía negativa.

8

Esto sugiere que estás usando Gmail y no G Suite, lo cual va en contra de las reglas. Muchas personas, especialmente aquellas que no saben qué es la administración de sistemas, intentan usar Gmail, y esto viola los términos de servicio. Decirles esto es una buena idea y no es maleducado ni grosero.

Pero estás usando G Suite, lo cual está perfectamente bien. Eso era imposible de saber por tu publicación original. Por eso parece que te están tratando de manera tan injusta.

Sin embargo, G Suite en realidad no funciona bien en un foro con mucho tráfico, como describes. Estás solicitando una nueva función para que Discourse funcione de alguna manera con un servicio de correo que te limita a 2500 mensajes por día.

Es posible, aunque no será muy fácil, crear un plugin para lograrlo. Sospecho que requeriría varios días de trabajo para alguien familiarizado con el desarrollo de Discourse.

La solución es utilizar un servicio de correo que pueda entregar la cantidad de correos que necesitas enviar.

2 Me gusta
9

Solo para hacer seguimiento, este tema es un duplicado. La solicitud de múltiples servicios SMTP ya fue planteada anteriormente:

El caso de uso aquí es un poco diferente, pero el problema surgió por una mala configuración del resumen. Unix.com tiene 138062 usuarios; un límite de 2000 correos electrónicos por día, incluso para cosas críticas como el restablecimiento de contraseñas, solo permitiría que el 1,8 % de esos usuarios interactúen diariamente.

edición: corregido de 2500 a 2000, para reflejar el límite real

1 me gusta
10

Por eso, @pfaffman, es mejor que todos en línea no sean tan rápidos para lanzar acusaciones hacia otros respecto a la tecnología y/o sus motivaciones. Normalmente, deberíamos hacer preguntas antes de apretar el gatillo y empezar a disparar, LOL.

Sí, dije GMAIL en lugar de GSUITE, pero cuando creé este dominio hace décadas, no existía GSUITE y simplemente se llamaba GMAIL. Además, la razón por la que no usé precisión es porque mi solicitud de característica NO TIENE NADA QUE VER CON GMAIL. Ese es un tema completamente tangencial.

Si yo quisiera (o si tú quisieras), podríamos ir a cualquier servidor, como muchos aquí pueden hacer, y escribir apt install postfix o apt install sendmail, y en 15 minutos o menos podríamos tener nuestro propio relay SMTP funcionando.

Por favor, no cambiemos el tema de mover el tráfico pesado de un proceso de resumen a una discusión sobre GMail vs. GSuite vs. Blah Blah. apt install postfix es trivial.

El problema es uno de confiabilidad. Es material básico de nivel 101.

Ejecutar correos críticos para la misión en el mismo relay SMTP que los resúmenes no es como me gustaría gestionar las cosas, por lo que hice esta solicitud de característica.

Por favor, mantengamos esto enfocado en lo que estoy solicitando, ya que sé de lo que hablo cuando se trata de construir aplicaciones críticas para la misión.

Aquí está de nuevo:

No quiero que mi correo crítico para la misión esté en el mismo relay SMTP que el correo de resúmenes, y creo que esta es una buena idea que hace al sistema más robusto.

Dejemos de lado la discusión muy tangencial sobre GMAIL, GSuite o MonkeyMail… blah blah. Lo siento incluso por mencionarlo, porque el servidor de correo no es relevante para mi solicitud de característica.

Disminuyamos la velocidad. Sé amable con los demás… Si alguien publica algo y no entiendes algo o te sientes confundido, pregunta; no disparar a las personas @Steven.

Puedo construir un relay SMTP en 10 minutos. Todos podemos. apt install postfix listo… Si quiero usar GSuite o postfix o donkey kong mail, eso depende de mí, no de otros. Como dije…

El punto principal … (de nuevo)

Es más confiable tener el correo crítico para la misión en un servidor diferente al de un canal de resúmenes. Esto es simplemente material básico para un servidor muy ocupado.

apt install postfix crea un relay SMTP. Estoy solicitando una característica que permita que el correo crítico para la misión (restablecimiento de contraseñas, correo de registro, inicio de sesión por correo) esté en un canal diferente al de los resúmenes por razones de confiabilidad y rendimiento.

11

@Steven

Ese no es el punto. Eso es tangencial.

Nota al margen: En realidad, solíamos tener más de 500.000 usuarios, pero los podé :slight_smile:

Me refiero a tener correo electrónico crítico en un canal diferente (retransmisión SMTP) que el tráfico de resúmenes.

Seguramente, este concepto simple y es muy fácil entender por qué dos canales son mejores.

Esta discusión se está desviando mucho de la idea original detrás de mi solicitud de función.

Lo siento por haber publicado y preguntado… :frowning:

Esta discusión posterior a mi publicación original se ha desviado mucho del objetivo, en mi opinión.

12

No deberías subestimar a ninguna de las personas que están tratando de ayudarte. Nadie está en tu contra.

3 Me gusta
13

Este es mi último mensaje sobre este tema.

En cuanto a GSuite (que no es el punto de mi solicitud de función en absoluto):

  • El número máximo de mensajes que un usuario puede enviar en un período de 24 horas es de 10,000. Sin embargo, esto puede variar según la cantidad de licencias de usuario en su cuenta de G Suite.
  • Un usuario registrado de G Suite no puede retransmitir mensajes a más de 10,000 destinatarios únicos en un período de 24 horas.

Ref: Route outgoing SMTP relay messages through Google  |  Set up & manage services  |  Google Workspace Help

Sin embargo, esto está totalmente fuera de tema para mí; porque incluso si GSuite permitiera más de 1000 millones de correos electrónicos al día a través de retransmisión SMTP, todavía desearía un canal de retransmisión SMTP diferente para el correo electrónico crítico en comparación con el correo electrónico de resumen.

Este es el punto.

Gracias. Por favor, considere esto en una futura actualización. Creo que es relativamente fácil agregar esto.

Esta solicitud de función no se trata de personalidad ni de los méritos o detalles de los proveedores de correo electrónico.

Mi solicitud de función se trata de la fiabilidad y de mantener el correo electrónico crítico fuera del canal de resumen.

Fin de la transmisión… :slight_smile:

14

Las personas que desarrollan Discourse tienen sistemas de correo que funcionan. No van a añadir una función para quienes quieran usar múltiples sistemas de correo poco fiables. Puedes desarrollar un plugin si lo deseas. Será difícil de desarrollar y problemático de mantener.

Puede ser fácil instalar Postfix, pero es mucho más difícil ejecutar un servidor de correo funcional ahora que cuando porté Sendmail y UUCP a Linux. Si ejecutar un servidor de correo fuera fácil, tendrías un servidor de correo funcional y no querrías dos.

Eso no es lo que pienso, pero es posible que sepas mucho más sobre el desarrollo de plugins de Discourse que yo.

3 Me gusta
15

Una solución sencilla es simplemente “desactivar” los correos electrónicos de resumen a nivel global si causan tantos problemas. Es posible que las mejores sugerencias ya se hayan hecho; solo puedo recomendar usar un proveedor de correo que no imponga límites, por ejemplo, Mailgun. De esta manera, todos estarán contentos (a menos que tengas restricciones que te obliguen a usar un proveedor de correo específico por alguna razón).

4 Me gusta
16

Estoy de acuerdo, hay mucha inconsistencia en lo que @neounix publicó inicialmente, y muchos detalles cambian en las respuestas posteriores.

He puesto énfasis en lo anterior; las restricciones de las cuentas gratuitas ya están documentadas en otro lugar de este tema. Las cuentas de G Suite ‘gratuitas’ que fueron abuelizadas también tienen estos límites. Si se trata de una cuenta de G Suite de pago, el comentario anterior es engañoso y explica mi respuesta.

De nuevo, no quedas claro sobre qué servicio estás utilizando. Si se trata de Google Apps heredadas en el nivel gratuito, entonces estás limitado a 500 destinatarios por día por usuario, igual que el producto gratuito de Gmail. Si estás usando una cuenta de G Suite de pago, deberías estar utilizando el servicio de relay SMTP de Google; los límites son de 10 000 por día por usuario, mejor pero aún no es ideal, especialmente con más de 130 000 usuarios que necesitan solicitar un restablecimiento de contraseña. Es genial saber que eliminaste algunos usuarios durante la migración, aunque no estoy seguro de cuán relevante sea eso realmente.

Puedo entender que estés frustrado; tu prueba no detectó los resúmenes que se pondrían en cola. Esto causó un período de indisponibilidad efectiva para cualquier persona que intentara restablecer su contraseña y recuperar el acceso a sus cuentas.

En varias ocasiones has sugerido que estoy poniendo palabras en tu boca, pero, por lo que puedo ver, las respuestas están en línea con la información que proporcionaste. Disculpas si no estás de acuerdo, pero al releer los mensajes sigue sin quedar claro exactamente qué producto estás utilizando.

Por cierto, soy @Stephen, no @Steven; estás etiquetando y notificando a un usuario totalmente diferente.

3 Me gusta
17

Si es así, siéntete libre de financiarlo publicando en Marketplace con un presupuesto. También hay algunas sugerencias realmente buenas arriba :index_pointing_up: para reducir el volumen de correos electrónicos; te sugiero aprovecharlas.

3 Me gusta
18

Por ahora, terminamos simplemente desactivando los resúmenes por completo; y aquí está la historia actualizada:

También tenemos un servidor de staging, y como Discourse habilita los resúmenes semanales (con una ventana de 365 días) de forma predeterminada, out-of-the-box al instalarse, ese servidor de staging también inició un resumen el fin de semana pasado (lo cual no esperábamos), LOL

Así que, antes de saber que esto sucedería (o podría suceder)… intenté hacer una copia de seguridad en el servidor de staging y el sistema se negó a hacerlo… dando un error. Olvidé el mensaje de error exacto en la consola de administración, pero recuerdo que había una pista que apuntaba a la cola de correo.

Con esa pista, ahora mirando sidekiq - y efectivamente había más de 300 mil mensajes de resumen en la cola debido a la configuración predeterminada de resúmenes en ‘activado’ y ‘últimos 365 días’.

Así que, limpié la cola de correo desde la línea de comandos, volví al panel de administración de copias de seguridad y la copia de seguridad funcionó perfectamente.

Dado que el sistema de correo de Discourse está construido sobre sidekiq, esta debe ser la razón por la que configurar canales diferentes (servidores de correo diferentes) para crítico para la misión y resúmenes podría ser complicado. Veo que no es tan simple como pensé originalmente (simplemente configurar dos servidores de correo en los entornos).

Aquí está la parte divertida… LOL

Al principio pensé que sería buena idea desactivar los resúmenes por defecto OOTB en lugar de tenerlos habilitados con una ventana de inicio de sesión de 365 días; pero luego recordé que el error fue todo mío; y esa no fue una buena sugerencia para publicar en meta, LOL.

Cuando se instaló Discourse, estableció a todos los usuarios migrados (de nuestro antiguo foro vB3), por defecto, en last_seen_at hace unos 50 años.

Entré a la base de datos y cambié manualmente a todos los usuarios a “última vez visto hace 10 días”! LOL. En ese momento no tenía idea de la configuración de resúmenes; y pensé que era un error de migración tener a todos los usuarios vistos por última vez hace 50 años después de la migración. Jaja… estaba equivocado. Hay una buena razón para esto.

Discourse inició un proceso masivo de resúmenes semanales que saturó sidekiq tanto en nuestros servidores de producción como de staging; porque hice el “hack” de cambiar en la base de datos “última vez visto hace 10 días” en el servidor de staging, y lo exporté a producción. Este fue el error que causó este problema.

Como la mayoría de las personas no entran a postgres y hacen cosas como:

UPDATE users SET last_seen_at "hoy menos 10 días"

… en una migración heredada con muchos usuarios…

no tendrán este tipo de problema masivo de resúmenes.

LOL

Me disculpo por crear toda esta tensión debido a mi hack UPDATE en la tabla users.

Aún así, creo que es razonable tener el correo electrónico crítico para la misión y el correo electrónico de resúmenes en dos servidores de correo diferentes, pero al mirar sidekiq aún no está claro para mí si hay una forma sencilla de hacerlo, ya que no tengo experiencia (aún) con sidekiq.

Sin embargo, puedo aconsejar a los migradores: si están migrando un foro a Discourse (lo cual es una gran idea), dejen el valor predeterminado de last_seen_at en users como está predeterminado :slight_smile:

1 me gusta
19

Por lo general, recomendaría colocar Mailhog entre una instancia de staging y el mundo exterior. Es excelente en este tipo de escenarios.

4 Me gusta
20

Voy a agregar DISCOURSE_DISABLE _DIGEST _EMAILS a mis instancias de staging. Pero con los correos electrónicos deshabilitados para usuarios que no son del personal, esto no es un gran problema.

2 Me gusta