Demandes de fonctionnalités : Compte e-mail séparé pour les résumés

Contribuer Fonctionnalité
1

De la part d’un novice : aujourd’hui, nous avons connu une expérience où tous nos e-mails ont été essentiellement bloqués et les utilisateurs ne pouvaient plus s’inscrire, récupérer leurs mots de passe ou se connecter par e-mail, car la diffusion hebdomadaire a été lancée après une migration d’un forum hérité, avec plus de 300 000 e-mails dans la file d’attente sidekiq. Ainsi, toute personne tentant de se connecter par e-mail, de s’inscrire ou de récupérer son mot de passe, etc., n’a reçu aucun e-mail et s’est retrouvée bloquée (comme on dit)…

Le problème provenait du fait que nous utilisons GMAIL comme relais de messagerie, et GMAIL (gratuit) impose des limites à ce type de relais SMTP, ce qui a entraîné le blocage de notre compte pour la journée.

Je souhaiterais demander l’ajout de cette fonctionnalité à l’avenir (sauf s’il existe une autre façon de résoudre ce problème).

Proposition

Ajouter un nouvel ensemble de variables app.yml permettant aux administrateurs de configurer un relais de messagerie différent pour les résumés.

Lors de la configuration, la fenêtre de dialogue pourrait afficher : Voulez-vous configurer un serveur SMTP différent pour les résumés ? et l’utilisateur pourrait utiliser le même relais SMTP s’il le souhaite.

Justification

Pour les grands forums avec une activité importante de résumés, il serait utile de pouvoir acheminer ces e-mails de résumé via un relais SMTP différent de celui utilisé pour les tâches essentielles, telles que la récupération de mot de passe, la connexion et l’inscription.

Pour l’instant, nous avons désactivé tous les résumés. Nous avons toutefois remarqué une option permettant de limiter cela aux X derniers jours. La valeur par défaut, lorsque je l’ai vérifiée aujourd’hui, était de 365 jours. Pour une raison quelconque, notre serveur migré a mis en file d’attente plus de 300 000 messages.

Discussion

Ce n’est pas un problème majeur, mais il serait bon, je pense, de séparer les e-mails de résumé des e-mails critiques ; car même si la priorité de la file d'attente est plus élevée pour les e-mails critiques, si le relais SMTP est bloqué en raison d’un nombre excessif de résumés, les e-mails critiques seront également bloqués.

De plus, certains forums pourraient rencontrer une situation similaire sans en connaître la raison exacte, alors que leur messagerie SMTP est en fait bloquée pour la raison mentionnée ci-dessus.

Merci pour votre attention réfléchie.

TangentialDuck

2 « J'aime »
2

Veuillez noter que l’utilisation de Gmail gratuit pour envoyer des e-mails depuis Discourse n’est pas prise en charge. Cela relève à nouveau des conditions d’utilisation de Google. Utiliser Gmail de cette manière s’apparente à une #installation-non-soutenue.

Il est difficile de comprendre en quoi cette demande de fonctionnalité aurait du sens à implémenter ; si vous aviez utilisé un mécanisme d’e-mail pris en charge, cet incident n’aurait pas pu se produire.

3

Ce n’est pas vrai.

Nous avons un domaine Google et la messagerie gratuite est prise en charge depuis de nombreuses années et l’est toujours.

Faites-moi une petite grâce après avoir géré un forum pendant 20 ans… Nous ne sommes pas sortis d’un œuf hier, @Stephen

1 « J'aime »
4

C’est tout à fait le cas. Les communautés qui ignorent notre guide sur les e-mails rencontrent ce problème constamment.

Google n’autorise aucun e-mail transactionnel à être envoyé depuis des comptes Gmail, et nous avons vu des communautés perdre leurs comptes de manière permanente en essayant de le faire. Les comptes GSuite payants ont également des limites strictes sur le nombre d’e-mails transactionnels autorisés par jour. Vous n’êtes pas la première personne à vous trouver dans cette situation, et nous ne pouvons pas vous aider à contourner les conditions imposées par Google.

1 « J'aime »
5

Je viens de me connecter à notre compte GSuite et j’ai consulté les CGU ; ce que vous dites n’est pas vrai :

@Stephen, vous êtes trop prompt à tirer. Je n’ai pas demandé une fonctionnalité pour « contourner les CGU de Google », alors veuillez éviter de mettre des mots dans mes messages.

Vous êtes trop prompt à tirer et accusez faussement les gens, @Steven. Alors, laissez peut-être d’autres personnes répondre à mes demandes, celles qui ne sont pas aussi promptes à tirer ?

6

Il y a une certaine incohérence dans ce que vous dites ici :

Gmail n’est pas G-Suite. Les comptes G-Suite payants ont les limites suivantes :

Type de limite Limite
Messages par jour
Limite d’envoi quotidienne* 2 000 (500 pour les comptes d’essai)

Les comptes Gmail gratuits ont toujours la limite de 500 e-mails.

Il s’agit des conditions d’utilisation de Google, cela n’a rien à voir avec ce qui précède. Il y a assurément une différence entre « cela fonctionnait jusqu’à présent » et être autorisé à le faire. Nous avons vu des utilisateurs tenter cela au cours des sept dernières années, et cela n’a jamais fonctionné :

Quelques lectures supplémentaires sur le sujet

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

Il existe un guide de configuration des e-mails avec une liste de fournisseurs recommandés. Vous n’êtes pas obligé de le suivre, mais nous ne pouvons pas vous aider à utiliser Gmail ou GSuite d’une manière qui n’était pas prévue.

1 « J'aime »
7

Oui, je savais tout cela avant de poster, @Steven.

Tu devrais vraiment t’abstenir de sous-estimer les connaissances de quelqu’un qui est en ligne depuis avant l’existence du navigateur Mosaic, à mon avis, et faire attention à la manière dont tu réponds. Ne gâche pas le plaisir de Discourse et de la technologie en général en faisant des accusations contre les autres.

D’abord, tu m’as dit qu’il n’y avait « AUCUN Gmail gratuit » (ce que je savais être faux) et tu m’as accusé d’une activité malveillante, puis tu as fait tes devoirs et découvert que GSuite a une limite de 2 500 par jour, ce que je savais depuis longtemps puisque je gère ce compte GSuite depuis des années.

Tu devrais présenter tes excuses quand tu tires trop vite, que tu accuses les gens de mauvaises choses et que tu te trompes sur les détails.

Ce n’est vraiment pas amusant de poster une simple demande de fonctionnalité et devoir répondre à cette énergie négative.

8

Cela suggère que vous utilisez Gmail et non G Suite, ce qui est contraire aux règles. Beaucoup de personnes, notamment celles qui ne connaissent pas l’administration système, tentent d’utiliser Gmail, ce qui constitue une violation des conditions d’utilisation. Le leur dire est une bonne idée, et ce n’est ni méchant ni grossier.

Mais vous utilisez G Suite, ce qui est tout à fait acceptable. Cela était impossible à déduire de votre message original. C’est pourquoi il semble que vous soyez traité de manière si injuste.

Sauf que G Suite ne fonctionne pas réellement sur un forum avec un trafic important, comme vous le décrivez. Vous demandez une nouvelle fonctionnalité pour que Discourse fonctionne d’une manière ou d’une autre avec un service de messagerie qui vous limite à 2 500 messages par jour.

Il est possible, mais pas très simple, de créer un plugin pour cela. Je soupçonne que cela prendrait plusieurs jours de travail à quelqu’un de familier avec le développement de Discourse.

La solution consiste à utiliser un service de messagerie capable de livrer le volume de courriers que vous devez envoyer.

2 « J'aime »
9

Juste pour faire suite, ce sujet est un doublon. La demande de plusieurs services SMTP a déjà été formulée précédemment :

Le cas d’usage ici est légèrement différent, mais le problème provient d’une mauvaise configuration des résumés. Unix.com compte 138 062 utilisateurs ; une limite de 2 000 e-mails par jour, même pour des éléments critiques comme les réinitialisations de mot de passe, ne permettrait que 1,8 % de ces utilisateurs d’interagir quotidiennement.

édit : corrigé de 2 500 à 2 000 pour refléter la limite réelle

1 « J'aime »
10

C’est la raison pour laquelle, @pfaffman, il est préférable pour tous les participants en ligne de ne pas être trop prompts à lancer des accusations contre les autres concernant la technologie et/ou leurs motivations. Normalement, nous devrions poser des questions avant de tirer le premier coup et de commencer à ouvrir le feu, LOL.

Oui, j’ai écrit GMAIL au lieu de GSUITE, mais lorsque j’ai créé ce domaine il y a des décennies, il n’existait pas de GSUITE et c’était simplement appelé GMAIL. De plus, la raison pour laquelle je n’ai pas utilisé de précision est que ma demande de fonctionnalité n’a ABSOLUMENT RIEN À VOIR AVEC GMAIL. C’est une discussion complètement périphérique.

Si je voulais (ou si vous vouliez), nous pourrions aller sur n’importe quel serveur, comme beaucoup ici peuvent le faire, et taper apt install postfix ou apt install sendmail, et en 15 minutes ou moins, nous pourrions faire fonctionner notre propre relais SMTP.

Veuillez ne pas changer le sujet du déplacement du trafic important d’un processus de résumé vers une discussion GMail vs GSuite vs Blah Blah. apt install postfix est trivial.

Le problème est une question de fiabilité. C’est du niveau 101 de base.

Exécuter des emails critiques pour la mission sur le même relais SMTP que les résumés n’est pas la façon dont j’aimerais gérer les choses, c’est pourquoi j’ai demandé cette fonctionnalité.

Gardons, s’il vous plaît, le cap sur ce que je demande, car je sais de quoi je parle quand il s’agit de construire des applications critiques pour la mission.

Voici à nouveau :

Je ne veux pas que mes emails critiques pour la mission soient sur le même relais SMTP que les emails de résumé et je pense que c’est une bonne idée qui rend le système plus robuste.

Éloignons-nous de la discussion très périphérique sur GMAIL, GSuite ou MonkeyMail… bla bla. Je suis désolé de l’avoir même mentionné car le serveur de messagerie n’est pas pertinent pour ma demande de fonctionnalité.

Ralentissez. Soyez gentil avec les autres… Si quelqu’un publie quelque chose et que vous ne comprenez pas quelque chose ou vous sentez confus, alors posez des questions ; ne tirez pas sur les gens @Steven.

Je peux configurer un relais SMTP en 10 minutes. Nous pouvons tous le faire. apt install postfix terminé… Si je veux utiliser GSuite ou postfix ou donkey kong mail, cela me revient, pas aux autres. Comme je l’ai dit…

Le point principal … (encore une fois)

Il est plus fiable d’avoir des emails critiques pour la mission sur un serveur différent de celui d’un canal de résumé. C’est juste du basique pour un serveur très actif.

apt install postfix crée un relais SMTP. Je demande une fonctionnalité qui permet aux emails critiques pour la mission (réinitialisation de mot de passe, email d’inscription, connexion par email) d’être sur un canal différent des résumés pour des raisons de fiabilité et de performance.

11

@Steven

Ce n’est pas le sujet. Cela est accessoire.

Note complémentaire : en réalité, nous avions plus de 500 000 utilisateurs, mais je les ai élagués :slight_smile:

Je parle de mettre les e-mails critiques sur un canal différent (relais SMTP) que le trafic des résumés.

Évidemment, ce concept est simple et il est très facile de comprendre pourquoi deux canaux sont préférables.

Cette discussion s’éloigne complètement de l’idée originale derrière ma demande de fonctionnalité.

Désolé d’avoir même posté et demandé… :frowning:

À mon avis, cette discussion qui a suivi mon message initial est très loin du sujet.

12

Tu ne devrais sous-estimer aucune des personnes qui tentent de t’aider. Personne n’est contre toi.

3 « J'aime »
13

Ceci est mon dernier message sur ce sujet.

Concernant GSuite (ce qui n’est absolument pas l’objet de ma demande de fonctionnalité)

  • Le nombre maximum de messages qu’un utilisateur peut envoyer sur une période de 24 heures est de 10 000. Cependant, cela peut varier en fonction du nombre de licences utilisateur dans votre compte G Suite.
  • Un utilisateur G Suite enregistré ne peut pas relayer des messages à plus de 10 000 destinataires uniques sur une période de 24 heures.

Réf. : Route outgoing SMTP relay messages through Google  |  Set up & manage services  |  Google Workspace Help

Cependant, cela est totalement hors sujet pour moi ; car même si GSuite autorisait plus de 1 milliard d’e-mails par jour via le relais SMTP, je souhaiterais toujours un canal de relais SMTP différent pour les e-mails critiques par rapport aux e-mails de résumé.

C’est là le point essentiel.

Merci. Veuillez en tenir compte lors d’une prochaine mise à niveau. Je pense qu’il est relativement simple d’ajouter cette fonctionnalité.

Cette demande de fonctionnalité ne concerne pas la personnalité ni les mérites ou les détails des fournisseurs de messagerie.

Ma demande de fonctionnalité porte sur la fiabilité et sur le fait de maintenir les e-mails critiques hors du canal de résumé.

Fin de transmission… :slight_smile:

14

Les personnes qui développent Discourse ont des systèmes de messagerie qui fonctionnent. Ils ne vont pas ajouter une fonctionnalité pour les utilisateurs qui souhaitent utiliser plusieurs systèmes de messagerie peu fiables. Vous pouvez développer un plugin si vous le souhaitez. Cela sera difficile à développer et fastidieux à maintenir.

Il est peut-être facile d’installer Postfix, mais il est beaucoup plus difficile d’exécuter un serveur de messagerie fonctionnel aujourd’hui qu’à l’époque où j’ai porté Sendmail et UUCP vers Linux. Si l’exécution d’un serveur de messagerie était facile, vous auriez déjà un serveur de messagerie fonctionnel et vous ne voudriez pas en avoir deux.

Ce n’est pas mon avis, mais vous en savez peut-être beaucoup plus que moi sur le développement de plugins pour Discourse.

3 « J'aime »
15

Une solution de contournement simple consiste à simplement « désactiver » les e-mails de résumé au niveau global si cela pose autant de problèmes. Les meilleures suggestions ont peut-être déjà été faites ; je ne peux que suggérer d’utiliser un fournisseur de messagerie qui n’impose aucune limite, par exemple Mailgun.
De cette façon, tout le monde sera satisfait (sauf si vous avez des contraintes qui vous obligent à utiliser un fournisseur de messagerie particulier pour une raison quelconque).

4 « J'aime »
16

Je suis d’accord, il y a beaucoup d’incohérences dans ce que @neounix a initialement publié, et de nombreux détails changent dans les réponses suivantes.

Mise en évidence de ma part dans le texte ci-dessus : les restrictions des comptes gratuits ont déjà été documentées ailleurs dans ce sujet. Les comptes G Suite « gratuits » hérités sont également soumis à ces limites. Si cela concerne un compte G Suite payant, le commentaire ci-dessus est trompeur et explique ma réponse.

Encore une fois, vous n’êtes pas clair quant au service que vous utilisez ici. S’il s’agit de l’ancienne version Google Apps au niveau gratuit, alors vous êtes limité à 500 destinataires par jour et par utilisateur, comme avec le produit Gmail gratuit. Si vous utilisez un compte G Suite payant, vous devriez utiliser le service de relais SMTP de Google ; les limites sont de 10 000 par jour et par utilisateur, ce qui est mieux mais toujours insuffisant, surtout avec plus de 130 000 utilisateurs ayant besoin de demander une réinitialisation de mot de passe. C’est une bonne nouvelle que vous ayez éliminé certains utilisateurs lors de la migration, bien que je ne sois pas certain que cela ait vraiment un impact concret.

Je comprends que vous soyez frustré ici ; vos tests n’ont pas détecté les résumés qui auraient été mis en file d’attente. Cela a entraîné une période d’indisponibilité effective pour toute personne tentant de réinitialiser son mot de passe et de retrouver l’accès à son compte.

À plusieurs reprises ci-dessus, vous avez suggéré que je mettais des mots dans votre bouche, mais d’après ce que je vois, vos réponses sont cohérentes avec les informations que vous avez fournies. Je m’excuse si vous n’êtes pas d’accord, mais en relisant les messages, il reste encore flou quel produit exact vous utilisez.

Au passage, je suis @Stephen, pas @Steven - vous taggez et notifiez un utilisateur totalement différent.

3 « J'aime »
17

Si c’est le cas, n’hésitez pas à le financer en publiant dans Marketplace avec un budget. Il y a aussi d’excellentes suggestions ci-dessus :index_pointing_up: pour réduire le volume des e-mails ; je vous conseille d’en profiter.

3 « J'aime »
18

Pour l’instant, nous avons fini par désactiver complètement les résumés ; voici la version mise à jour de l’histoire :

Nous avons également un serveur de préproduction, et comme Discourse active par défaut les résumés hebdomadaires (avec une fenêtre de 365 jours) dès l’installation, ce serveur de préproduction a également lancé un résumé le week-end dernier (ce que nous n’attendions pas), LOL

Donc, avant de savoir que cela arriverait (ou pourrait arriver)… j’ai essayé de faire une sauvegarde sur le serveur de préproduction et le système a refusé de le faire… en affichant une erreur. J’ai oublié le message d’erreur exact dans la console d’administration, mais je me souviens qu’il y avait un indice pointant vers la file d’attente des courriels.

Avec cet indice, en regardant maintenant sidekiq - et effectivement, il y avait plus de 300 000 messages de résumé dans la file d’attente, provenant de la configuration par défaut des résumés activés et couvrant les 365 derniers jours.

J’ai donc vidé la file d’attente des courriels depuis la ligne de commande, suis retourné au panneau d’administration des sauvegardes, et la sauvegarde a fonctionné sans problème.

Comme le système de messagerie de Discourse est basé sur sidekiq, cela doit être la raison pour laquelle la configuration de canaux différents (serveurs de messagerie différents) pour les courriels critiques et les résumés pourrait être délicate. Je vois que ce n’est pas aussi simple que je le pensais au départ (simplement configurer deux serveurs de messagerie dans les environnements).

Voici la partie amusante… LOL

Au début, je pensais qu’il serait bon de désactiver les résumés par défaut OOTB au lieu de les avoir activés avec une fenêtre de connexion de 365 jours ; mais ensuite j’ai réalisé que l’erreur venait entièrement de moi ; et ce n’était pas une bonne suggestion à poster sur meta, LOL.

Lors de l’installation de Discourse, il a défini par défaut tous les utilisateurs migrés (de notre ancien forum vB3) avec une valeur last_seen_at d’il y a environ 50 ans.

Je suis allé dans la base de données et j’ai manuellement changé tous les utilisateurs pour indiquer qu’ils avaient été vus il y a 10 jours ! LOL. À l’époque, je ne savais rien de la configuration des résumés ; et je pensais qu’il s’agissait d’une erreur de migration que tous les utilisateurs apparaissent comme vus pour la dernière fois il y a 50 ans après la migration. Haha… j’avais tort. Il y a une bonne raison pour cela.

Discourse a lancé un processus massif de résumé hebdomadaire qui a saturé sidekiq sur nos serveurs de production et de préproduction ; parce que j’avais appliqué le “hack” de modification de la base de données “vu pour la dernière fois il y a 10 jours” sur le serveur de préproduction, puis l’avais exporté vers la production. C’était l’erreur qui a causé ce problème.

Puisque la plupart des gens n’entrent pas dans postgres pour bidouiller comme moi et faire des choses comme :

UPDATE users SET last_seen_at "today minus 10 days"

… lors d’une migration d’un ancien système avec de nombreux utilisateurs…

ils n’auront pas ce genre de problème massif de résumés.

LOL

Je m’excuse d’avoir créé toute cette tension à cause de mon hack UPDATE sur la table users.

Néanmoins, je pense qu’il est raisonnable de placer les courriels critiques et les courriels de résumé sur deux serveurs de messagerie différents, mais en regardant sidekiq, il n’est pas encore clair pour moi s’il existe un moyen simple de le faire, car je n’ai pas encore d’expérience avec sidekiq.

Cependant, je peux conseiller les personnes effectuant des migrations : si vous migrez un forum vers Discourse (ce qui est une excellente idée), laissez la valeur par défaut de last_seen_at dans users telle quelle :slight_smile:

1 « J'aime »
19

Je recommanderais habituellement de placer Mailhog entre une instance de préproduction et le monde extérieur. Il est excellent dans ce type de scénario.

4 « J'aime »
20

Je vais ajouter DISCOURSE_DISABLE _DIGEST _EMAILS à mes instances de préproduction. Mais avec l’option de désactivation des e-mails définie sur « non personnel », ce n’est pas un gros problème.

2 « J'aime »