Cette note vise à résumer mon expérience d’administrateur lors du bannissement de certains utilisateurs. Je ne demande pas nécessairement de changements, mais je cite les défis qui pourraient se traduire par des demandes lors de la révision.
Lorsque je dois bannir un utilisateur en raison de retours d’e-mails, je ne souhaite pas qu’un e-mail leur soit envoyé pour les informer de l’événement.
Je ne vois pas d’option d’administration pour ajouter une raison de bannissement personnalisée à la liste existante. J’aimerais ajouter « Retours d’e-mails ».
J’aimerais définir l’une des options de période de bannissement disponibles comme option par défaut. Je ne veux pas avoir à sélectionner la période dans la liste déroulante pour chaque événement.
Je souhaite informer l’utilisateur de la raison de son bannissement, avec plus d’informations que la raison d’une ligne. La case est là pour envoyer un e-mail à l’utilisateur avec une note, mais encore une fois, cela envoie un e-mail à l’utilisateur. Je veux juste lui envoyer un message car je sais que l’e-mail ne fonctionne pas.
D’autres e-mails Discourse sont-ils envoyés à un utilisateur après qu’il ait été bloqué ou banni ? Pour ce scénario spécifique et potentiellement d’autres, je ne veux plus qu’aucun e-mail ne soit envoyé à cet utilisateur, surtout s’il s’est abonné à de nombreuses notifications.
Concernant la suppression d’un utilisateur dans ce même scénario : nous pouvons simplement supprimer l’utilisateur, et nous pouvons également « supprimer et bannir à la fois l’adresse e-mail et l’adresse IP ». Pourquoi ces deux actions sont-elles liées ? J’aime l’idée de bannir une adresse e-mail. Je pourrais rarement vouloir bannir une adresse IP. Mais bannir une IPv4 est gênant pour un certain nombre de raisons - c’est peut-être acceptable avec IPv6, mais nous n’en sommes pas encore là. Tant que ces concepts ne seront pas séparés, ne pouvons-nous pas simplement bannir une adresse e-mail ? Si j’en savais plus sur le fonctionnement interne de Discourse, je serais heureux de créer un script pour effacer des éléments spécifiques des listes de bannissement, mais je ne sais pas où trouver ces données.
Nous avons MaxMind actif pour ce site et j’aimerais utiliser l’adresse IP pour obtenir un emplacement afin de déterminer si l’utilisateur doit simplement être banni ou supprimé. Par exemple, si l’adresse utilisée en dernier est éloignée de l’adresse d’enregistrement (plus d’autres métriques), alors je supprimerais le compte pour une simple suspicion. Mais la fenêtre contextuelle qui affiche les informations IP n’affiche pas d’emplacement. Est-ce un bug ou dois-je vérifier à nouveau MaxMind ?
Je reçois des notifications de retour à mon adresse postmaster@ - c’est ainsi que je sais que les e-mails du forum ne parviennent pas. Quelqu’un pourrait suggérer de regarder le score de retour pour les coupures automatiques afin d’éviter d’envoyer un e-mail à quelqu’un qui a déjà des retours enregistrés. Nous n’avons pas de données de retour pour le scoring, je n’ai pas configuré Discourse pour interroger POP3 (IMAP??) pour de telles données. Tout ce que je vois dans meta, ce sont des anecdotes du forum sur la façon de le configurer. Existe-t-il une documentation dédiée et réelle sur ce sujet ?
Encore une fois, tout cela vise simplement à partager l’expérience utilisateur (pas très bonne) dans ce domaine spécifique, pour quiconque pourrait être intéressé.
Je n’ai pas encore configuré le seuil de score de rebond car je n’ai pas Discourse qui vérifie les e-mails pour les notifications de rebond. Les informations contenues dans ce fil de discussion meta sont les meilleures que j’ai trouvées sur le sujet de la configuration pour traiter les rebonds. Au cours des prochains jours, je pars à la recherche d’une documentation plus complète.
Mais oui, aujourd’hui, je fixe un seuil de rebond très bas.
Cela a du sens car un message du site est envoyé à l’utilisateur pour l’informer de l’événement. Ce message du site n’est pas clair sur ce que nous voulons que l’utilisateur fasse exactement. Donc, après l’envoi du message, je publie une réponse à ce message à l’utilisateur, pour lui demander de répondre lorsqu’il aura résolu le problème de l’e-mail.
Les défis de noob auxquels je suis confronté maintenant incluent :
Je veux ce message à l’utilisateur, mais je préférerais en modifier le texte. Changer admin/customize/email_templates/system_messages.email_revoked pour l’anglais ne le change pas pour toutes les autres langues. Existe-t-il une fonctionnalité pour effectuer une traduction automatique sur un ou tous les system_messages ?
Sans recherche sur admin/customize/email_templates/, il est difficile de trouver le bon texte system_messages ou user_notifications à modifier, et de savoir quels processus les déclenchent.
Je ne veux pas envoyer d’e-mail alors que le problème, par définition, est qu’ils ne reçoivent pas d’e-mails.
Lorsque je publie cette réponse au message système sur son profil utilisateur, un autre e-mail est envoyé. Si nous pouvons bloquer efficacement les e-mails sortants vers cette adresse, cela ne se produira pas. C’est-à-dire que toutes les fonctions d’e-mail sortant passent par un processus central qui vérifie d’abord si le seuil de rebond a été dépassé ? Ou est-ce que je manque une fonctionnalité autour du Silence qui bloque les e-mails sortants sans avoir à lier cette décision au seuil de rebond ?
Idéalement, lorsque l’utilisateur remplace l’adresse e-mail par une adresse valide, ou clique sur une case “mon adresse est maintenant OK”, ce serait bien que le serveur envoie un e-mail de test et, en cas de succès, efface le drapeau/compteur de rebond.
(Aléatoire) Il y a un nombre fixe de admin_js.admin.user.suspend_reasons et ils sont identifiés “en dur” pour exclure la personnalisation à d’autres fins. C’est-à-dire que nous pouvons changer le texte pour admin_js.admin.user.suspend_reasons.combative et il y a un seul admin_js.admin.user.suspend_reasons.custom mais il ne semble pas que nous puissions créer un nouveau admin_js.admin.user.suspend_reasons.bouncing_email.
Ce scénario ne s’applique pas seulement aux rebonds. Je peux penser à d’autres scénarios où nous voudrions informer l’utilisateur avec un message local que nous ne pouvons pas lui envoyer d’e-mail et lui donner un message personnalisé stocké qui lui dit quoi faire.
Je soupçonne que tout cela décrit un comportement très précis qui ne remonte probablement pas dans la liste des priorités, mais je ne sais pas encore si ou comment d’autres personnes gèrent cela. Merci de votre patience…
Je garde ce fil de discussion à jour avec les progrès…
Je viens de trouver cette documentation pour configurer la gestion des rebonds :
Les images ici sont également extrêmement utiles :
La mise en œuvre de cette fonctionnalité devrait résoudre suffisamment de problèmes ici pour gérer efficacement les e-mails rebondis. Je dois encore déterminer exactement comment nous informerons une base d’utilisateurs multilingue efficacement et les remettrons rapidement sur la bonne voie lorsqu’ils auront résolu des problèmes d’e-mail. C’est-à-dire, lorsqu’ils auront apporté une modification efficace, ils devront nous en informer ou informer le système afin que les blocages à leur encontre puissent être levés.
Lorsqu’une adresse e-mail renvoie les e-mails automatisés de Discourse, cela semble être une raison pour laquelle vous n’auriez pas nécessairement besoin/vouloir faire taire ou supprimer leur compte pour cela, à moins que vous ne suspectiez qu’il s’agit d’un compte de spoofing ou quelque chose sans e-mail valide.
Je suppose que c’est probablement la raison pour laquelle vous voudriez suspendre temporairement le compte pour valider qu’ils ont un e-mail fonctionnel, avez-vous un volume élevé de cas comme celui-ci ou est-il pratique de traiter ces cas un par un manuellement ?
Il existe d’autres options comme modifier manuellement les paramètres de notification par e-mail, ou changer temporairement l’adresse e-mail non fonctionnelle en une autre adresse fonctionnelle contrôlée par l’administrateur ou quelque chose de similaire. Ce n’est peut-être pas la meilleure idée, juste quelques idées aléatoires ici.
Lorsqu’un compte est supprimé, il n’envoie pas de notification par e-mail à ce sujet, d’après ce que j’ai vérifié la dernière fois. Une politique simple mais un peu brutale consiste à supprimer les comptes s’ils n’ont pas d’e-mail fonctionnel.
Nous sommes sur la même longueur d’onde. Il existe différents scénarios que différents gestionnaires voudront gérer différemment. J’explore ce logiciel pour comprendre ce qu’il fait, comment il est censé être utilisé et comment les autres l’utilisent.
L’objectif sous-jacent de cette initiative/enquête est double : Premièrement, éviter proactivement les abus. Deuxièmement, éviter d’envoyer des e-mails qui échoueront, ce qui pourrait entraîner le signalement de notre site comme source d’e-mails non livrables. Cela peut entraîner des listages temporaires dans les RBL et je veux éviter de telles absurdités.
Nous n’avons pas un volume élevé pour ce site, mais il existe des groupes d’utilisateurs, similaires à TL0-4 mais différents. Les utilisateurs d’un groupe ne devraient pas être réduits au silence si quelque chose ne va pas avec leur e-mail. Les utilisateurs d’un autre groupe avec quelques publications récentes sur le sujet ne devraient pas être réduits au silence. Les comptes sans activité ou sans activité valide récente pourraient être réduits au silence pour attirer leur attention s’ils reviennent un jour.
Le concept de réduire les gens au silence pour attirer leur attention est gênant. Et je ne me soucie pas vraiment des adresses e-mail. L’intention réelle est que si nous avons une adresse e-mail bidon, je pense qu’un compte est plus susceptible d’être une source d’abus qu’autrement. Je les réduirai donc préventivement au silence, chercherai une réponse, et si nous n’avons pas de nouvelles d’eux pendant une longue période, je supprimerai simplement le compte. Un utilisateur participant (TL1 ?) dont nous n’avons pas eu de nouvelles depuis longtemps pourrait simplement être mis en silence/révision à long terme.
Puisque nous sommes là, tout cela implique également que des personnes créent des comptes sans e-mail valide, ou modifient leurs adresses pour quelque chose d’invalide. Je parcours la Documentation et je souhaite créer une automatisation pour : Réduire au silence les nouveaux utilisateurs TL0 jusqu’à ce qu’ils aient consulté quelques fils de discussion, puis leur envoyer un e-mail. Si nous recevons un rejet de ces messages spécifiques, mettez-les en statut de révision. Donc, pas d’e-mail de bienvenue avant d’être sûrs qu’il s’agit d’un humain se déplaçant sur le site, et aucune permission tant que nous ne sommes pas sûrs qu’ils vérifient leur e-mail.
Pour information, il n’est pas possible d’activer votre compte sans vérifier d’abord votre e-mail (sauf si l’activation est effectuée manuellement par un administrateur, ou si vous utilisez l’authentification unique (SSO) et ne vérifiez pas auprès de votre fournisseur d’identité (IdP)).
Ce n’est pas nécessairement vrai, il y a d’autres raisons comme le fait que l’e-mail peut être temporairement désactivé, ou qu’ils ont banni votre expéditeur (ce qui peut aussi être temporaire, comme un silence de compte temporaire).
La première étape que je recommanderais pour ce que vous décrivez serait d’envoyer un message privé ordinaire à un utilisateur si son e-mail ne reçoit pas de messages comme alerte au cas où il ne serait pas au courant, vous pouvez en faire un message privé d’avertissement officiel avec la case à cocher pour rendre l’icône d’alerte d’enveloppe rouge au lieu de verte. Cela met également une note sur leur compte qu’ils ont reçu un ou plusieurs messages privés d’avertissement officiels, vous aurez donc cela documenté.
Comme mentionné avec les paramètres par défaut, les nouveaux comptes doivent être validés en cliquant sur le lien dans l’e-mail de vérification avant de pouvoir utiliser votre site, à moins que vous n’ayez contourné cela.
Cela semble être fondamentalement déjà activé avec les paramètres par défaut, bien que les TL0 puissent publier des réponses/sujets publics, ils ne peuvent envoyer de messages privés à personne avant d’être promus au niveau de base TL1, ce qui nécessite une lecture et une validation de l’e-mail avant cela.
