Est-il possible d’optimiser la période de résumé par tranche de milliers de membres de la communauté ? Chaque lundi, Discourse envoie plusieurs milliers d’e-mails en 1 à 2 secondes, ce qui provoque des problèmes de SPAM avec notre serveur de messagerie personnalisé.
Comment réinitialiser le champ “last_digest_time” pour chaque compte et le normaliser pour les autres milliers de comptes ?
L’objectif est d’avoir 100 à 200 résumés par jour au lieu de 5 000 le lundi. Nous utilisons Discourse depuis quatre ans ; peut-être y a-t-il un problème lié à une mise à jour que nous effectuons très fréquemment vers la dernière version.
Par ailleurs, auriez-vous un indice sur la façon d’accéder à PostgreSQL de l’image Docker et sur l’endroit où “mettre à jour” les enregistrements dans la base de données ?
Quelles sont vos idées ? Le serveur envoie simplement des lettres aux destinations où elles sont placées dans les SPAMS. Je ferais de même si quelqu’un m’envoyait 2 000 lettres en 1 seconde.
Si vous hébergez votre propre serveur SMTP, vous tomberez dans les écueils habituels associés. Les entreprises de livraison de courrier comme Mailgun et SendGrid utilisent diverses techniques pour s’assurer que leurs serveurs sont fiables et considérés comme dignes de confiance par les réseaux de destination. C’est pourquoi la documentation recommande d’utiliser l’un de ces services plutôt que de procéder à un auto-hébergement.
Exactement — même si vous n’envoyez ces messages que par pics, des services de messagerie tiers réputés peuvent livrer de manière fiable des centaines de milliers d’e-mails dans des boîtes aux lettres tierces chaque heure.
Malheureusement, nous ne pouvons offrir aucune assistance si vous insistez pour gérer votre propre serveur de messagerie. Si vous décidez de ne pas suivre les recommandations, vous acceptez la complexité supplémentaire que cela engendre.
Tout fonctionne correctement avec SMTP, y compris DMARC, SPF et DKIM. J’utilise mon propre serveur SMTP depuis 2005. À cette époque, nous n’avions pas ces services inutiles de « machine à faire de l’argent ». Imaginons un instant que quelqu’un essaie demain de facturer l’air…
Revenons donc au problème. Je sais que la solution la plus simple pour un testeur senior serait de m’orienter vers une solution payante ou un service tiers. Quelqu’un pourrait-il m’aider à corriger un bug critique dans Discourse ? Je ne suis toujours pas d’accord avec le fait que Discourse doive envoyer 10 000 courriels en une seconde. Il faudrait un service de rotation ou quelque chose de similaire qui normalise le « last_digest_timestamp » entre les comptes.
Je ne suis pas employé par CDCK, et je n’ai aucun intérêt financier à vous orienter vers des services tiers.
Si vous ne souhaitez pas suivre les recommandations et la documentation, c’est votre choix. Dans ce cas, cela vous éloigne de la voie du soutien gratuit que nous fournissons ici à la communauté. Votre seule autre option est donc de faire appel à un consultant via le Marketplace.
Ce n’est pas un problème de Discourse ; ce problème est dû au fait que l’adresse IP de votre serveur de messagerie n’est pas considérée comme fiable. Nous ne pouvons pas vous aider à résoudre cela, et vous refusez d’envisager les options existantes à cette fin.
Oui, je travaille avec des communautés qui envoient dix fois ce volume ; beaucoup de personnes qui gèrent de grandes communautés opèrent à cette échelle ou plus.
Il semble que vos besoins en matière d’e-mail dépassent désormais votre maîtrise du protocole pour assurer une livraison fiable d’e-mails en grand volume. C’est pourquoi ces entreprises d’e-mail transactionnel existent. Personne ici ne fait la promotion de « l’e-mail massif » — il s’agit simplement du défi lié à l’envoi d’e-mails en grand volume.
Vous pouvez configurer votre serveur de messagerie pour qu’il conserve les courriels et étale leur livraison. C’est vraiment un problème lié à votre serveur de messagerie plutôt qu’à Discourse. J’ai géré des serveurs de messagerie depuis le début des années 1990 jusqu’en 2005 environ, époque où les spams ont rendu la tâche trop difficile. C’est beaucoup plus difficile aujourd’hui.
J’ai certaines limites de débit. Si vous ne faites même pas cela, les serveurs SMTP typiques ont des paramètres préconfigurés pour vous. Les serveurs de messagerie sont plus intelligents aujourd’hui et peuvent facilement détecter votre délai entre les messages.
Oui, car ils utilisent le service que vous avez mentionné précédemment. Vous ne comprenez toujours pas la différence entre ces services et le service SMTP personnel. Ils utilisent un immense pool d’adresses IP et simulent différents expéditeurs. C’est une bonne technique pour les entreprises qui font du « vrai » SPAM. Bien sûr, ils paient pour ce service.
Je ne vois pas de raison pour que les gens utilisent ces « machines à argent » pour Discourse si Discourse n’envoie pas de SPAM. Ops… désolé… en raison d’un bug, il peut envoyer 100 000 messages en une seconde le lundi parce que @Stephensays affirme que c’est un comportement VRAI.
Bon, je ne vois pas l’intérêt de discuter avec des gens qui ont une couronne au-dessus de la tête. Oui, Discourse est génial et merci beaucoup pour votre contribution.
J’espère que des gens simples sans auront quelques idées ici.
Selon les réponses ci-dessus de l’équipe Discourse, ils ne constatent aucun problème avec Discourse. J’ai résolu ce problème de manière peu élégante en accédant directement à la base de données. Voici ma solution
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)")
Veuillez mettre à jour la plage last_emailed_at dans la requête SQL. J’avais 4 000 entrées last_emailed_at en une seule journée le 16 mars. Ainsi, tous les utilisateurs ont maintenant été optimisés sur une période de 3 jours avec un intervalle de 30 secondes.
Discourse n’est pas conçu pour être utilisé avec un service SMTP personnel. Désolé que cela n’ait pas été expliqué clairement ; cela peut certainement fonctionner, mais pour une communauté avec une activité e-mail régulière, ce n’est pas une bonne idée. C’est une limitation de l’état actuel de l’e-mail, et nous réagissons tous comme nous le pouvons.
au-dessus de la tête. Oui, Discourse est génial et merci beaucoup pour votre contribution.