ユーザーを黙らせるまたは削除する方法についてのメモ

このメモは、一部のユーザーをミュートする際の管理者UXを要約することを目的としています。必ずしも変更を求めているわけではありませんが、レビューでのリクエストにつながる可能性のある課題を挙げています。

  1. メールがバウンスしたためにユーザーをミュートする必要がある場合、そのイベントを通知するメールを送信したくありません。:slight_smile:
  2. 既存のリストにカスタムミュート理由を追加する管理者オプションが見当たりません。「メールバウンス」を追加したいと思います。
  3. 利用可能なミュート期間オプションの1つをデフォルトに設定したいと思います。すべてのイベントでドロップダウンから期間を設定する必要はありません。
  4. ユーザーにミュートされた理由を、1行の「理由」以上の情報で通知したいと思います。ボックスはユーザーにメモをメールするためにありますが、これもユーザーにメールされます。メールが機能しないことを知っているので、メッセージを送りたいだけです。
  5. ブロックまたはミュートされたユーザーに、他のDiscourseメールが送信されますか?この特定のシナリオ、およびおそらく他のシナリオでは、特に多くの通知を購読しているユーザーには、これ以上メールを送信したくありません。
  6. この同じシナリオでユーザーを削除することについて:ユーザーを単純に削除することも、「メールアドレスとIPアドレスの両方を削除して禁止する」こともできます。これらはなぜリンクされているのですか?メールアドレスを禁止するという考えは気に入っています。IPアドレスを禁止することはめったにないかもしれません。しかし、IPv4を禁止することは、いくつかの理由で厄介です。IPv6では問題ないかもしれませんが、まだそこには到達していません。これらの概念が分離されるまで、メールアドレスを禁止することはできませんか?Discourseの内部についてもっと知っていれば、禁止リストから特定のアイテムをクリアするプロセスをスクリプト化喜んで行いますが、そのデータを見つけることができません。
  7. このサイトではMaxMindが有効になっており、IPアドレスを使用して場所を取得し、ユーザーをミュートまたは削除すべきかを判断したいと考えています。たとえば、最後に使用されたアドレスが登録アドレスから離れている場合(その他のメトリックに加えて)、アカウントが単に臭いだけで削除します。しかし、IP情報を表示するポップアップには場所が表示されません。これはバグですか、それともMaxMindを再度確認する必要がありますか?
  8. postmaster@アドレスにバウンス通知が届きます。これがフォーラムからのメールがバウンスしていることを知る方法です。記録されたバウンスがあるユーザーへのメール送信を回避するために、自動カットオフのためにバウンススコアを調べることを提案する人もいるかもしれません。スコアリングのためのバウンスデータはありません。POP3(IMAP??)をポーリングするようにDiscourseを設定していません。metaで見つけるのは、セットアップに関するフォーラムの逸話だけです。このトピックに関する実際の専用ドキュメントはありますか?

繰り返しますが、これらはすべて、関心のある人々のために、この特定の領域の(それほど良くない)UXを共有するためだけのものです。

お役に立てば幸いです。よろしくお願いします!!!

「いいね!」 2

ミュート理由を空のままにすれば、相手にメールが送信されないのではないでしょうか。

それについては、Custom Predefined Suspension Reasons を参照してください。

  • これは私がDiscourseについて知っていることに基づいています(正確ではないかもしれませんが、お手伝いしようとしています!)
「いいね!」 1

2468 - 感謝いたします! :slight_smile:

「いいね!」 2

bounce score のサイト設定、特に bounce score threshold をどのように設定しましたか?

「いいね!」 2

バウンススコアのしきい値はまだ設定していません。Discourse がバウンス通知のメールをチェックしていないためです。このトピックに関する設定方法については、こちらのメタスレッドの情報が最も役立ちました。今後数日間、より完全なドキュメントを見つけるための探求を行います。

しかし、はい、今日は非常に低いバウンスしきい値を設定します。

「いいね!」 1

いいえ、それは間違いです。
アカウントをサイレンスにするには、理由を選択するか、入力する必要があります。

これは理にかなっています。なぜなら、イベントについてユーザーに通知するサイトメッセージが送信されるからです。そのサイトメッセージは、ユーザーに具体的に何をしてほしいのかが不明確です。そのため、メッセージが送信された後、ユーザーに返信して、メールの問題が解決したら返信するように依頼します。

そのため、現在直面している初心者向けの課題は次のとおりです。

  • ユーザーへのメッセージは送信したいのですが、テキストを変更したいです。英語の admin/customize/email_templates/system_messages.email_revoked を変更しても、他のすべての言語には変更されません。または、1つまたはすべての system_messages に対して自動翻訳を実行する機能はありますか?
  • admin/customize/email_templates/ の検索機能がないと、編集する適切なテキストの system_messages または user_notifications を見つけるのが難しく、どのプロセスがそれらをトリガーするのかを知ることもできません。
  • 問題は定義上、メールを受信できないことなので、メールを送信したくありません。
  • システムメッセージへの返信をユーザープロファイルに投稿すると、別のメールが送信されます。効果的にメールをブロックできる場合、それは起こりません。つまり、すべての送信メール機能は、バウンスしきい値を超えたかどうかを確認する中央プロセスを経由しますか?それとも、バウンスしきい値にその決定をバインドせずに送信メールをブロックする、Silence に関する機能を見逃していますか?
  • 理想的には、ユーザーがメールアドレスを有効なものに置き換えるか、「メールアドレスは正常です」のチェックをクリックすると、サーバーがテストメールを送信し、成功時にバウンスフラグ/カウントをクリアできると素晴らしいでしょう。
  • (ランダム) admin_js.admin.user.suspend_reasons の管理者の数は固定されており、「ハード」に識別されているため、別の目的でカスタマイズすることはできません。つまり、admin_js.admin.user.suspend_reasons.combative のテキストを変更でき、単一の admin_js.admin.user.suspend_reasons.custom がありますが、新しい admin_js.admin.user.suspend_reasons.bouncing_email を作成することはできないようです。

このシナリオは、バウンスに限定されません。メールを送信できないことをユーザーに通知し、何をすべきかを伝えるカスタムメッセージを保存したい他のシナリオも考えられます。

これらすべてが非常に細かく調整された動作を記述していると思われ、おそらく優先順位リストの上位には来ないでしょうが、他の人がどのようにこれに対処しているかはまだわかりません。忍耐強く聞いてくれてありがとう…

進捗状況をこのスレッドで更新していきます…

バウンス処理の設定に関するドキュメントを見つけました:

ここにある画像も非常に役立ちます:

この機能の実装により、バウンスメールを効果的に処理するための課題の多くが解決されるはずです。多言語ユーザーベースに効果的に通知し、メールの問題を修正した際に迅速に復帰してもらう方法を正確に把握する必要があります。つまり、効果的な変更を加えたら、ブロックを解除するために私たちまたはシステムに通知する必要があります。

Eメールアドレスが自動化されたDiscourseのEメールをバウンスバックする場合、なりすましアカウントや無効なEメールアカウントであると疑わない限り、そのアカウントをミュートまたは削除する必要はないように思われます。

それが、アカウントを一時的に保留して、有効なEメールを持っていることを確認したい理由かもしれません。そのようなケースは大量にありますか、それとも個別に手動で対応するのは現実的ですか?

Eメール通知設定を手動で変更したり、機能していないEメールアドレスを一時的に管理者が制御している別の機能しているアドレスに変更したりするなどの他のオプションもあります。それは最善のアイデアではないかもしれませんが、単なる思いつきです。

アカウントが削除された場合、最後に確認したときはそのことに関するEメール通知は送信されませんでした。機能していないEメールがあるアカウントを削除するという、シンプルですがやや過酷なポリシーです。

同じ認識です。様々なシナリオがあり、それぞれ異なるマネージャーが異なる対応を望むでしょう。私はこのソフトウェアが何をするのか、どのように使用されることを意図しているのか、そして他の人がどのように使用しているのかを理解するために、このソフトウェアを試しています。

このイニシアチブ/調査の根本的な目標は二つあります。第一に、積極的に悪用を回避すること。第二に、バウンスする可能性のあるメールの送信を回避し、当社のサイトが悪質なメールの送信元としてフラグを立てられることを防ぐことです。これはRBL(リアルタイムブラックホールリスト)に一時的に掲載される可能性があり、そのようなナンセンスは避けたいです。

このサイトのトラフィック量は多くありませんが、TL0-4とは似ているが異なるユーザーグループがあります。あるグループのユーザーは、メールに問題が発生した場合でも、ミュートされるべきではありません。最近のトピックに関する投稿がいくつかある別のグループのユーザーは、ミュートされるべきではありません。アクティビティがない、または最近の有効なアクティビティがないアカウントは、将来的に戻ってきた場合に注意を促すためにミュートされる可能性があります。

注意を促すために人々をミュートするという考え方は奇妙です。そして、私はメールアドレスにはあまり関心がありません。本当の意図は、偽のメールアドレスがある場合、そのアカウントが悪用の原因である可能性が高いと感じるということです。そのため、私は先回りしてミュートし、何らかの応答を求め、長期間応答がない場合はアカウントを削除します。参加しているユーザー(TL1?)で、長期間応答がない場合は、長期ミュート/レビューの対象となる可能性があります。

せっかくなので、これらすべては、有効なメールアドレスなしでアカウントが作成されている、またはアドレスが無効なものに変更されていることも意味します。私は#documentationを調べており、自動化を作成したいと考えています。新しいTL0ユーザーは、いくつかのスレッドを閲覧するまでミュートし、その後メールを送信します。これらの特定のメッセージからバウンスがあった場合は、レビュー状況に入れます。つまり、人間がサイト内を移動していることが確実になるまでウェルカムメールは送信されず、メールアドレスを確認したことが確実になるまで権限は付与されません。

参考までに、メールアドレスを確認せずにアカウントを有効にすることはできません(管理者が手動で有効化した場合、またはSSOを使用してIDPで確認しない場合を除く)。

「いいね!」 3

必ずしもそうとは限りません。メールが一時的に無効になっている、または送信者がブロックされている(これも一時的なアカウントの一時停止のようなものである可能性があります)など、他の理由もあります。

あなたが説明していることに対して私が推奨する最初のステップは、ユーザーのメールがメッセージを受信していない場合、それに気づいていない可能性を考慮して、通常のPMを送信することです。それを公式の警告PMにすることができます。チェックボックスをオンにすると、封筒のアラートアイコンが緑ではなく赤になります。これにより、アカウントに公式の警告PMが1つ以上送信されたというメモが残るため、文書化できます。

デフォルト設定で述べたように、新しいアカウントは、サイトを使用する前に、まず確認メール内のリンクをクリックして検証する必要があります。ただし、それをバイパスしていない場合。

これは、デフォルト設定で基本的にすでに有効になっているようです。TL0は公開の返信/トピックを投稿できますが、TL1の基本レベルに昇格するまで誰にもPMメッセージを送信できません。これには、ある程度の閲覧が必要であり、それ以前にメールを検証する必要があります。

「いいね!」 1