¿Es posible optimizar el período de resumen por cada mil comunidades? Cada lunes, Discourse envía varios miles de correos electrónicos en 1-2 segundos, lo que genera problemas de SPAM con nuestro servidor de correo personalizado.
¿Cómo se puede restablecer “last_digest_time” por cuenta y normalizarlo para las otras mil cuentas?
El objetivo es tener entre 100 y 200 resúmenes al día en lugar de 5.000 el lunes. Hemos estado usando Discourse durante los últimos 4 años; quizás haya un problema con una actualización, la cual realizamos con mucha frecuencia a la última versión.
Además, ¿hay alguna indicación sobre cómo acceder a PostgreSQL de la imagen de Docker y dónde “actualizar” los registros en la base de datos?
¿Tienes alguna idea? El servidor solo envía correos a los destinos donde ponen nuestras cartas en SPAM. Yo haría lo mismo si alguien me enviara 2 mil correos en 1 segundo.
Si estás alojando tu propio servidor SMTP, estás incurriendo en los problemas habituales asociados. Las empresas de entrega de correo, como Mailgun y SendGrid, emplean diversas técnicas para garantizar que sus servidores sean confiables y considerados reputados por las redes de destino. Por esa razón, la documentación recomienda que utilices uno de esos servicios en lugar de alojarlo tú mismo.
Exacto: aunque solo envíes esos mensajes en ráfagas, los servicios de correo de terceros reputados pueden entregar de manera fiable cientos de miles de correos electrónicos a bandejas de entrada de terceros cada hora.
Lamentablemente, no podemos ofrecer ninguna asistencia si insistes en ejecutar tu propio servidor de correo. Si decides no seguir las recomendaciones, aceptas la complejidad adicional que esto genera.
Todo está correcto con SMTP, incluyendo DMARC, SPF y DKIM. He estado utilizando mi propio servidor SMTP desde el año 2005. En aquella época no existían esos servicios innecesarios de “máquinas de hacer dinero”. Imaginemos que mañana alguien intente cobrar por el aire…
Así que, volvamos al problema. Sé que la forma más fácil para un Tester Senior es derivarme a algún lugar o a algún servicio de pago. ¿Podría alguien ayudarme a solucionar un error crítico en Discourse? Todavía no estoy de acuerdo en que Discourse deba enviar 10.000 correos en 1 segundo. Debería ser un servicio de rotación o algo similar que normalice “last_digest_timestamp” entre las cuentas.
No estoy empleado por CDCK, ni tengo ningún interés financiero en dirigirte a servicios de terceros.
Si no deseas seguir la recomendación y la documentación, esa es tu decisión. En este caso, te aleja del camino del soporte gratuito que ofrecemos aquí a la comunidad, por lo que tu única otra opción es contactar con un consultor a través de Marketplace.
Esto no es un problema de Discourse; el problema se debe a que la IP de tu servidor de correo no se considera confiable. No podemos ayudarte a solucionar eso y tú te niegas a considerar las opciones que existen para ese propósito.
Sí, trabajo con comunidades que envían diez veces ese volumen; muchas de las personas que gestionan comunidades grandes operan a esa escala o incluso mayor.
Parece que tus necesidades de correo electrónico están superando ahora tu experiencia con el protocolo para entregar correo de forma fiable a gran volumen; por eso existen estas empresas de correo transaccional. Nadie aquí está haciendo publicidad de ‘correo masivo’; simplemente se trata del desafío de entregar correo electrónico a alto volumen.
Puedes configurar tu servidor de correo para que retenga los mensajes y distribuya su entrega. Esto es realmente un problema de tu servidor de correo y no de Discourse. Yo gestioné servidores de correo desde principios de los años 90 hasta alrededor de 2005, cuando el spam lo hizo demasiado difícil. Ahora es mucho más difícil.
Tengo ciertos límites de velocidad. Si ni siquiera haces esto, los servidores SMTP típicos ya tienen configuraciones predefinidas para ti. Los servidores de correo son más inteligentes hoy en día y pueden detectar fácilmente el retraso entre tus mensajes.
Sí, porque utilizan el servicio que mencionaste antes. Aún no entiendes la diferencia entre esos servicios y el servicio SMTP personal. Ellos utilizan un enorme grupo de direcciones IP y simulan diferentes remitentes. Esta es una buena técnica para empresas que realizan SPAM “agresivo”. Por supuesto, pagan por este servicio.
No veo razón por la que las personas deban usar estas “máquinas de dinero” para Discourse si Discourse no envía SPAM. Ops… perdón… debido a un error, podría enviar 100 mil mensajes en un segundo el lunes porque @Stephen dice que este es un comportamiento REAL.
Bueno, no veo sentido en charlar con personas que llevan una corona en la cabeza. Sí, Discourse es genial y muchas gracias por tu contribución.
Espero que las personas sencillas, sin , puedan aportar algunas ideas aquí.
Según las respuestas anteriores del equipo de Discourse, no ven ningún problema con Discourse. Resolví este problema de manera poco ortodoxa mediante la manipulación directa de la base de datos. Aquí está mi solución:
cd /var/discourse
./launcher enter app
rails c
Topic.exec_sql("UPDATE users SET last_emailed_at = now() + interval '30' second * id WHERE last_emailed_at > ('2020-03-14'::date) AND last_emailed_at < ('2020-03-17'::date)")
Actualiza el rango de last_emailed_at en la consulta SQL. Yo tenía 4K valores de last_emailed_at en un día, el 16 de marzo. Por lo tanto, ahora todos los usuarios se han optimizado para un intervalo de 3 días con un intervalo de 30 segundos.
Discourse no está diseñado para usarse con un servicio SMTP personal. Lo siento si no se explicó con claridad; definitivamente puede funcionar, pero para una comunidad con actividad regular de correo electrónico no es una buena idea. Esta es una limitación derivada del estado actual del correo electrónico, y todos estamos reaccionando a ello según nuestras posibilidades.
en la cabeza. Sí, Discourse es genial y muchas gracias por tu contribución.