Hinweise zum Stummschalten oder Löschen von Nutzern

[TonyG]

Diese Notiz soll meine Admin-Benutzererfahrung zusammenfassen, während ich einige Benutzer stummschalte. Ich fordere nicht unbedingt Änderungen, sondern nenne lediglich die Herausforderungen, die sich möglicherweise in Anfragen bei der Überprüfung niederschlagen.

1. Wenn ich einen Benutzer wegen zurückgesendeter E-Mails stummschalten muss, möchte ich nicht, dass eine E-Mail an ihn gesendet wird, um ihn über das Ereignis zu informieren.
2. Ich sehe keine Admin-Option, um einen benutzerdefinierten Grund für die Stummschaltung zur vorhandenen Liste hinzuzufügen. Ich möchte „Zurückgesendete E-Mails“ hinzufügen.
3. Ich möchte eine der verfügbaren Optionen für den Stummschaltungszeitraum als Standard festlegen. Ich möchte nicht für jedes Ereignis die Zeitspanne aus dem Dropdown-Menü auswählen müssen.
4. Ich möchte den Benutzer darüber informieren, warum er stummgeschaltet wurde, mit mehr Informationen als dem einzeiligen „Grund“. Die Box ist dafür da, dem Benutzer eine Notiz per E-Mail zu senden, aber auch das sendet eine E-Mail an den Benutzer. Ich möchte ihn nur benachrichtigen, weil ich weiß, dass E-Mails nicht funktionieren.
5. Werden nach der Sperrung oder Stummschaltung eines Benutzers weitere Discourse-E-Mails an ihn gesendet? Für dieses spezielle Szenario und möglicherweise andere möchte ich keine weiteren E-Mails an diesen Benutzer senden, insbesondere wenn er viele Benachrichtigungen abonniert hat.
6. Zum Löschen eines Benutzers in diesem gleichen Szenario: Wir können den Benutzer einfach löschen und wir können auch „die E-Mail-Adresse und die IP-Adresse löschen und sperren“. Warum sind diese verknüpft? Mir gefällt die Idee, eine E-Mail-Adresse zu sperren. Ich möchte vielleicht selten eine IP-Adresse sperren. Aber das Sperren einer IPv4 ist aus einer Reihe von Gründen umständlich – vielleicht ist es mit IPv6 in Ordnung, aber wir sind noch nicht so weit. Bis diese Konzepte getrennt sind, können wir nicht einfach eine E-Mail-Adresse sperren? Wenn ich mehr über die internen Abläufe von Discourse wüsste, würde ich gerne ein Verfahren skripten, das bestimmte Elemente aus den Sperrlisten löscht, aber ich weiß nicht, wo ich diese Daten finden kann.
7. Wir haben MaxMind für diese Website aktiviert und ich möchte die IP-Adresse verwenden, um einen Standort zu ermitteln, der mir hilft zu entscheiden, ob der Benutzer nur stummgeschaltet oder gelöscht werden soll. Wenn beispielsweise die zuletzt verwendete Adresse weit von der Registrierungsadresse entfernt ist (plus andere Metriken), würde ich das Konto löschen, weil es einfach schlecht riecht. Aber das Popup, das IP-Informationen anzeigt, zeigt keinen Standort an. Ist das ein Fehler oder sollte ich MaxMind noch einmal überprüfen?
8. Ich erhalte Bounce-Benachrichtigungen an meine Postmaster@-Adresse – so erfahre ich, dass E-Mails vom Forum zurückkommen. Jemand könnte vorschlagen, dass ich mir den Bounce Score für automatische Abschaltungen ansehe, um das E-Mailen von jemandem zu vermeiden, der bereits aufgezeichnete Bounces hat. Wir haben keine Bounce-Daten für die Bewertung, ich habe Discourse nicht so eingerichtet, dass es POP3 (IMAP??) für solche Daten abfragt. Alles, was ich in Meta sehe, sind Forum-Anekdoten über die Einrichtung. Gibt es eine echte dedizierte Dokumentation zu diesem Thema?

Nochmals, all dies dient nur dazu, die (nicht so tolle) Benutzererfahrung in diesem speziellen Bereich mitzuteilen, für wen auch immer es von Interesse sein mag.

Ich hoffe, das hilft – und danke!!!

[twofoursixeight]

@TonyG

Wenn ich einen Benutzer wegen zurückgesendeter E-Mails stumm schalten muss, möchte ich nicht, dass ihm eine E-Mail zur Benachrichtigung über das Ereignis gesendet wird [soweit ich glaube].

Ich vermute, wenn Sie den Grund für die Stummschaltung leer lassen, wird keine E-Mail an sie gesendet.

@TonyG

Ich sehe keine Admin-Option, um der bestehenden Liste einen benutzerdefinierten Grund für die Stummschaltung hinzuzufügen. Ich möchte „Zurückgesendete E-Mails“ hinzufügen.

Was das betrifft, siehe Custom Predefined Suspension Reasons

• Dies basiert auf dem, was ich über Discourse weiß (es wird nicht genau sein, aber ich versuche zu helfen!)

[TonyG]

2468 - wir wissen es zu schätzen!

[Moin]

@TonyG

Wenn ich einen Benutzer wegen zurückgesendeter E-Mails stumm schalten muss, möchte ich keine E-Mail an ihn senden, um ihn über das Ereignis zu informieren.

Wie haben Sie die Website-Einstellungen für den Bounce Score konfiguriert, insbesondere den Bounce Score Threshold?

[TonyG]

Ich habe den Schwellenwert für die Bounces-Punktzahl noch nicht konfiguriert, da ich Discourse nicht für die Überprüfung von E-Mails auf Bounce-Benachrichtigungen eingerichtet habe. Die Informationen in diesem Meta-Thread sind die besten, die ich zum Thema der Konfiguration zur Verarbeitung von Bounces gefunden habe. In den nächsten Tagen bin ich auf der Suche nach einer vollständigeren Dokumentation.

Aber ja, heute setze ich einen sehr niedrigen Bounce-Schwellenwert.

[Architect]

@twofoursixeight

Ich vermute, wenn Sie den Grund für die Stummschaltung leer lassen, wird keine E-Mail an sie gesendet.

Nein, das ist falsch.

Es muss ein Grund ausgewählt oder eingegeben werden, bevor das Konto überhaupt stummgeschaltet werden kann.

[TonyG]

{“translation”: “[quote="Architect, post:6, topic:323151"]Es muss einen Grund geben, der vorher ausgewählt oder geschrieben wird, bevor es überhaupt möglich ist, das Konto stummzuschalten.[/quote]\nDies ergibt Sinn, weil eine Systemmeldung an den Benutzer gesendet wird, um ihn über das Ereignis zu informieren. Diese Systemmeldung ist nicht klar darüber, was genau wir vom Benutzer wollen. Nachdem die Nachricht gesendet wurde, poste ich eine Antwort auf diese Nachricht an den Benutzer, um ihn zu bitten, zurückzuschreiben, wenn er die E-Mail-Situation korrigiert hat.\n\nDie Herausforderungen, denen ich jetzt gegenüberstehe, umfassen:\n\n- Ich möchte diese Nachricht an den Benutzer, aber ich würde es vorziehen, den Text zu ändern. Das Ändern von admin/customize/email_templates/system_messages.email_revoked auf Englisch ändert es nicht für alle anderen Sprachen. Gibt es eine Funktion, um eine automatische Übersetzung für eine oder alle system_messages durchzuführen?\n- Ohne eine Suche in admin/customize/email_templates/ ist es schwer, den richtigen Text für system_messages oder user_notifications zu finden, um sie zu bearbeiten, und um zu wissen, welche Prozesse sie auslösen.\n- Ich möchte keine E-Mail senden, wenn das Problem per Definition darin besteht, dass sie keine E-Mails erhalten.\n- Wenn ich diese Antwort auf die Systemmeldung in ihrem Benutzerprofil poste, geht eine weitere E-Mail heraus. Wenn wir das effektiv blockieren können, wird keine ausgehende Mail gesendet. Das heißt, senden alle ausgehenden Mail-Funktionen über einen zentralen Prozess, der zuerst prüft, ob die Bounce-Schwelle überschritten wurde? Oder vermisse ich eine Funktion im Zusammenhang mit Stille (Silence), die ausgehende Mails blockiert, ohne diese Entscheidung an die Bounce-Schwelle zu koppeln?\n- Idealerweise würde die Server-Software beim Ersetzen der E-Mail durch eine gültige Adresse oder beim Klicken auf “Meine Adresse ist jetzt okay” eine Testmail senden, und bei Erfolg die Bounce-Flagge/den Zähler zurücksetzen.\n- (Zufällig) Gibt es eine feste Anzahl von admin_js.admin.user.suspend_reasons, und sie sind “hart” codiert, um eine Anpassung für andere Zwecke zu verhindern. Das heißt, wir können den Text für admin_js.admin.user.suspend_reasons.combative ändern, und es gibt eine einzelne admin_js.admin.user.suspend_reasons.custom, aber es sieht nicht so aus, als könnten wir eine neue admin_js.admin.user.suspend_reasons.bouncing_email erstellen.\n\nDieses Szenario gilt nicht nur für Bounces. Mir fallen auch andere Szenarien ein, bei denen wir den Benutzer mit einer lokalen Nachricht informieren möchten, dass wir ihm keine Mail schicken können, und ihm eine gespeicherte benutzerdefinierte Nachricht geben, die erklärt, was er tun soll.\n\nIch vermute, dies beschreibt alles sehr fein abgestimmtes Verhalten, das wahrscheinlich keine Prioritätenliste nach oben bringt, aber ich weiß noch nicht, ob oder wie andere damit umgehen. Danke für die Geduld…”}

[TonyG]

Ich halte diesen Thread mit den Fortschritten auf dem Laufenden…

Ich habe gerade diese Dokumentation zur Einrichtung der Bounce-Verarbeitung gefunden:

Configure direct-delivery incoming email for self-hosted sites with Mail-Receiver

Discourse is all about enabling civilized discussion. While plenty of people like a web interface, e-mail is still the “hub” of many people’s online lives. That’s why sending e-mail is so important, and when you’re sending e-mail, you really want to be able to receive it, too. There are several reasons why: If e-mails “bounce” (they can’t be delivered for some reason), you need to know about that. Repeatedly sending e-mails that bounce will get your e-mails flagged as spam. Receiving e-ma…

Configure VERP to handle bouncing e-mails

Setting up bounces handling Discourse uses the Variable envelope return path (VERP) technique to handle bouncing e-mails. To enable VERP, set the “reply by email address” site setting with an email address template that uses the + sign. The default of replies+%{reply_key}@discourse.example.com … works fine. If you are using your own or your company’s email server, then, that’s it Your discourse instance must be able to receive email sent to this address. This should work via POP, bu…

Die Bilder hier sind ebenfalls äußerst hilfreich:

Bounced emails not being detected

the reply_by_email_address is not used as the from address but the envelope-from, specifically so bounces work Here’s an image that demonstrates how each address is used. The addresses themselves are specific to our hosting, but should be sufficient for an example. notification_email: notifications@hs1.discoursemail.com reply_by_email_address: incoming+%{reply_key}@hs1.discoursemail.com A notification: [image] A replyable message: [image]

Die Implementierung dieser Funktionalität sollte genügend der hier genannten Herausforderungen bewältigen, um Bounces effektiv zu handhaben. Ich muss noch genau ausarbeiten, wie wir eine mehrsprachige Benutzerbasis effektiv benachrichtigen und sie schnell wieder auf Kurs bringen, wenn sie E-Mail-Probleme behoben haben. Das heißt, wenn sie eine effektive Änderung vorgenommen haben, müssen sie uns oder das System benachrichtigen, damit die Sperren für sie aufgehoben werden können.

[Architect]

@TonyG

Dieses Szenario gilt nicht nur für Bounces. Mir fallen andere Szenarien ein, in denen wir den Benutzer mit einer lokalen Nachricht benachrichtigen möchten, dass wir ihm keine E-Mail senden können, und ihm eine gespeicherte benutzerdefinierte Nachricht geben, die ihm sagt, was er tun soll.

Wenn eine E-Mail-Adresse zurückprallt, sendet der automatisierte Discourse-E-Mail-Versand, scheint es, als ob Sie ihr Konto dafür nicht unbedingt stumm schalten oder löschen müssten, es sei denn, Sie vermuten, dass es sich um ein Spoof-Konto oder etwas ohne gültige E-Mail handelt.

Ich schätze, das ist wahrscheinlich der Grund, warum Sie das Konto vorübergehend sperren möchten, um zu überprüfen, ob sie eine funktionierende E-Mail haben. Haben Sie viele solcher Fälle oder ist es praktikabel, diese einzeln manuell zu bearbeiten?

Es gibt einige andere Optionen, wie z. B. das manuelle Ändern der E-Mail-Benachrichtigungseinstellungen oder das vorübergehende Ändern der nicht funktionierenden E-Mail-Adresse in eine andere funktionierende Adresse, die vom Administrator kontrolliert wird, oder so etwas. Das ist vielleicht keine gute Idee, nur ein paar zufällige Ideen hier.

Wenn ein Konto gelöscht wird, sendet es meiner letzten Überprüfung zufolge keine E-Mail-Benachrichtigung darüber. Eine einfache, aber etwas brutale Richtlinie ist es, Konten zu löschen, wenn sie keine funktionierende E-Mail haben.

[TonyG]

Wir sind uns einig. Es gibt verschiedene Szenarien, die verschiedene Manager unterschiedlich handhaben möchten. Ich taste mich an diese Software heran, um zu verstehen, was sie tut, wie sie verwendet werden soll und wie andere sie verwenden.

Das übergeordnete Ziel dieser Initiative/Anfrage ist zweigeteilt: Erstens, proaktiv Missbrauch zu vermeiden. Zweitens, das Versenden von E-Mails zu vermeiden, die zurückkommen und dazu führen könnten, dass unsere Website als Quelle für nicht zustellbare E-Mails markiert wird. Dies kann zu temporären Einträgen in RBLs führen, und ich möchte solchen Unsinn vermeiden.

Wir haben kein hohes Volumen für diese Website, aber es gibt Benutzergruppen, die TL0-4 ähneln, aber anders sind. Benutzer in einer Gruppe sollten nicht stummgeschaltet werden, wenn mit ihrer E-Mail etwas schief geht. Benutzer in einer anderen Gruppe mit einigen kürzlichen themenbezogenen Beiträgen sollten nicht stummgeschaltet werden. Konten ohne Aktivität oder ohne aktuelle gültige Aktivität könnten stummgeschaltet werden, um ihre Aufmerksamkeit zu erregen, falls sie jemals zurückkehren.

Das Konzept, Leute stummzuschalten, um ihre Aufmerksamkeit zu erregen, ist umständlich. Und E-Mail-Adressen sind mir eigentlich egal. Die eigentliche Absicht ist, dass, wenn wir eine gefälschte E-Mail-Adresse haben, ich der Meinung bin, dass ein Konto eher eine Quelle für Missbrauch ist als nicht. Also werde ich sie präventiv stummschalten, eine Antwort suchen und, wenn wir lange nichts von ihnen hören, das Konto löschen. Ein teilnehmender Benutzer (TL1?), von dem wir lange nichts gehört haben, könnte einfach auf eine langfristige Stummschaltung/Überprüfung gesetzt werden.

Da wir schon dabei sind, impliziert all dies auch, dass Leute Konten ohne gültige E-Mail-Adresse erstellen oder ihre Adressen in etwas Ungültiges ändern. Ich gehe die Documentation durch und möchte eine Automatisierung erstellen, um: Neue TL0-Benutzer stummzuschalten, bis sie ein paar Threads angesehen haben, und sie dann per E-Mail zu kontaktieren. Wenn wir von diesen spezifischen Nachrichten eine Fehlermeldung erhalten, werden sie in den Überprüfungsstatus versetzt. Also keine Willkommens-E-Mail, bis wir sicher sind, dass sie ein Mensch sind, der sich auf der Website bewegt, und keine Berechtigungen, bis wir sicher sind, dass sie ihre E-Mail verifizieren.

[JammyDodger]

FWIW Es ist nicht möglich, Ihr Konto zu aktivieren, ohne zuerst Ihre E-Mail-Adresse zu verifizieren (es sei denn, sie wird manuell von einem Administrator aktiviert, oder Sie verwenden SSO und verifizieren nicht mit Ihrem IdP).

[Architect]

@TonyG

all of this also implies that people are creating accounts without a valid email, or changing their addresses to something invalid.

Das ist nicht unbedingt wahr, es gibt andere Gründe, wie z. B. dass E-Mails vorübergehend deaktiviert werden oder dass sie Ihren Absender gesperrt haben (was ebenfalls vorübergehend sein kann, wie z. B. eine vorübergehende Stummschaltung des Kontos).

Der erste Schritt, den ich für das, was Sie beschreiben, empfehlen würde, wäre, eine normale PM an einen Benutzer zu senden, wenn seine E-Mail keine Nachrichten als Benachrichtigung darüber erhält, falls er sich dessen nicht bewusst ist. Sie können dies zu einer offiziellen Warn-PM machen, indem Sie das Kontrollkästchen aktivieren, um das Briefumschlag-Warnsymbol anstelle von Grün rot zu machen. Dies vermerkt auch in ihrem Konto, dass sie eine oder mehrere offizielle Warn-PMs erhalten haben, sodass Sie dies dokumentiert haben.

Wie bereits erwähnt, müssen bei den Standardeinstellungen neue Konten validiert werden, indem sie zuerst auf den Link in der Bestätigungs-E-Mail klicken, bevor sie Ihre Website nutzen können, es sei denn, Sie haben dies umgangen.

@TonyG

want to create an automation to: Silence new TL0 users until after they have viewed a couple threads, then email them. If we get a bounce from these specific messages, put them into review status. So no welcome email until after we’re sure they’re a human moving around the site, and no permissons until we’re sure they verify their email.

Das scheint mit den Standardeinstellungen im Grunde bereits aktiviert zu sein, obwohl TL0 öffentliche Antworten/Themen posten kann, aber niemand PM-Nachrichten senden kann, bis sie auf das grundlegende Level TL1 befördert werden, was einige Lektüre erfordert und die E-Mail vorab validiert werden müsste.