通常の、Discourse を使用しない場合のフローの説明。
現在（Discourse とは完全に独立して）、公開されているメールアドレスをエイリアスとして使用し、問い合わせメールメッセージを複数のメールアドレスに送信しています。グループは、各メールプロバイダーのスパム検出に依存しています。そのほとんどが Gmail を使用しています。
担当者は個別に問い合わせに対応しており、重複した作業やその他の問題が発生することがあります。
Discourse を使用した場合の変更点。
私の Discourse インスタンスは完全にプライベートであり、メンバーはログインする必要があります。Mail-Receiver プラグインを使い始め、メンバーがメールでトピックに返信できるようになり、うまく機能しているようです。
関連するグループオプションについて読んだりテストしたりしており、カスタムアドレスへの受信メールを受け入れることができます。問い合わせ用メールアドレスにこれを検討しています。Mail-Receiver がスパムを適切に検出・防止できるかどうかはわかりません。
Discourse チーム自体も、サポート機能として受信メールを使用していると読んだので、スパムが彼らの邪魔をしていないのかもしれません。
こちらにガイドがあります:
mail-receiver アドレスに送信されるスパムメールで問題が発生したことはありませんが、アドレスが公開レジストリに記載されている場合、スパム/マーケティングメールを受信するリスクがあります。
はい、そのガイドは見ました。しかし、禁止ドメインのリストを維持することは選択肢ではありません。スパマーの一歩先を行くことは不可能です。ウェブサイトに公開されているアドレスには毎日スパムが届きますが、少なくともそれらのほとんどは、Gmailやmiabなど、私たちが管理していない検出サービスを通過します。
Discourseグループのメールアドレスを試す勇気が出るかもしれませんが、結果に耐えられないと予測できます。いつでも元のプロセスに戻ることができますが、コミュニケーションを維持しながら、自然な方法で作業を分散できるというアイデアは本当に気に入っていました。
それを避けるためには、可能であればウェブクローラーからアドレスを保護することが役立つかもしれません。それがどのように行われるかは定かではありませんが、クローラーによるアドレスのスクレイピングを防ぐために、キャプチャを使用したり、「アドレスを表示するにはクリック」オプションを設けたりするのを見たことがあります。
スパムが悪化しすぎた場合は、アドレスを簡単に変更できます。
メールが届いたら、ステージングされたユーザーを作成します。スパムの場合は、それらのメールアドレスとIPアドレスの両方をすぐにブロックできます。
mpalmer
(Matt Palmer)
5
ドメインブロッキングが汎用的なスパム対策として有効ではないという点には私も同意します。それは、時折現れる「ヘビーヒッター」に対処するためのものに過ぎません。
しかしながら、Postfixの全機能を利用できるため、mail-receiver をカスタマイズして、受信メッセージをSpamAssassinなどで処理するといった、必要な追加の配信前フィルタリングを実行することは十分に可能です。私は、これらの機能を標準で組み込んだ「mail receiver 9001」の構築を検討していましたが、現時点では個人的に必要としていないため、スポンサー付きの取り組みが必要になるでしょう。