なぜ使わないのでしょうか？意味がわかりません。彼の攻撃の問題を解決します。
その場合、おそらく#marketplace が最適な場所でしょうか？
公式プラグインより、サードパーティが壊す方がマシですか？
公式プラグインにはなりません。Jeff が今日それを望むと判断すれば、私の GitHub アカウントにある 3 行のコードで済みます。
多くの正当なアカウントのメールログインを壊してしまいます。私の Gmail アカウントも含まれます。
はい、でもそのサイトを使っているとは思えません。
戦争中には一定数の民間人の犠牲は避けられないものです。毎日何千もの偽装されたプラスアドレス付きのメールに襲われている状況で、ユーザーの 2% がサインアップできないとしても、それは問題でしょうか？これは Cloudflare の「攻撃中」モードと同じです。正当なユーザーの一部が入れなくなることもあります。より厳格なセキュリティを導入する代償です。
あなたの主張は、Cloudflare の「攻撃中」モードが完璧ではないから存在すべきではない、ということでしょうか🤷♂️
いずれにせよ、これが大規模な問題であるという正当な報告をあと 2 つ見せてもらわない限り、対応を進めることはできません。
もし何か明らかな見落としがあったらお許しくださいが、登録画面に reCAPTCHA を追加する方が簡単ではありませんか？
これらは通常、人間によるスパマーです。2010 年に比べて、現在は非常に多く存在します。キャプチャは人間の敵対者に対しては何の役にも立ちません。
「いいね！」 1
なるほど…この「gmail のドットや＋を使った」登録は、主にボットが行うものだと思っていましたが…
「いいね！」 3
多くの本物の一般ユーザーが、sharklasers などのサービス（これを利用しています）を使って当サイトに登録するのは、自分のユーザー名を実生活の人物と結び付けたくないからです。状況によって異なります。
OP が投稿の信頼要件として「15 分間の読み取り時間」を設定し、最初の 5 件の投稿を staff（編集権限なし）が承認する必要があるようにすれば、その問題は即座に解消すると思います。
「いいね！」 1
ここで確実に確認したいのは、アカウント登録に対する適切なレート制限を設けていることです。
単一の IP アドレスからは、1 日に N 件のアカウント登録しか許可しないようにする必要があります。ただし、NAT の影響で多数のユーザーが同じ IP を共有するケースに対応するため、何らかの回避策やサイト設定が必要です。
Google 向けには . を正規化することを推奨しますが、+somthing はそのまま残すようにしてください。もしこれを行うのであれば、管理者が希望する設定を選べるようにするのがよいでしょう。
「いいね！」 1
それはすでに適用されています……ここで問題なのは、モサドが多数のIPアドレスを持っているということです。彼らには使い放題のIPが大量にあります。
「いいね！」 1
以下の項目でレートリミッターが機能しているのが確認できます：
- 1 時間あたりのメールログイン
- アクティベーションメールの更新
- アクティベーションメールの再送
- 2 要素認証方法のリスト表示
- TOTP の有効化
- 管理者ログイン
アカウント作成については、IP 単位で標準組み込みのレートリミットがある以外に、特定のレート制限は見当たりません。
@markersocial さんに、データエクスプローラーをインストールし、大量に登録されたユーザーの登録 IP アドレスをリストアップしていただけないでしょうか。これらの登録が 100 個の IP アドレスから行われているのか、それともたった 1 つの IP アドレスからなのか、確実に把握したいと考えています。
「いいね！」 2
私も同感ですが、Google にもこの問題があります。少なくとも私が勤務していた大学では、大学全体が単一の NAT からアクセスしているため、クラスの学生が Gmail に登録することができませんでした。
NAT のホワイトリストを設定すれば、現実的な問題の大半は解決するのではないかと考えます。正当なユーザーがどこから来ているかは、おそらく予測可能だからです。
1 日あたりの IP 数を小規模（または設定可能）な数にデフォルト設定するのは、私にとってはかなり安全な方法に思えます。
@sam - IP についてですが、登録およびログイン時の IP 制限を導入しており、大規模な IP 禁止リストも維持していることを確認いたします。複数のアカウントが同じ IP から作成されているわけではないと確信しています。もしそうであれば、ブロックも可能だったのですが。現状、これらをブロックする唯一の方法は、Gmail による登録をすべてブラックリスト化することです。
—
@codinghorror 合法なサービスの中には、月額 xxx ドルで xx,xxx,xxx 個の固有 IP にアクセスできるものがあります。つまり、Mossad だけでなく、誰でも簡単に大量の IP を入手できるのです 
。他にも大規模な IP プールを提供する合法サービスは多数ありますし、違法なボットネット貸出サービスも存在します。
「いいね！」 6
最新バージョンへのアップグレードを強くお勧めします。少なくとも、私の最新の挑戦/ハニーポットの変更を踏まえると、これを行うためのスクリプトを作成するのがはるかに面倒になります。
また、ここで定期的に更新情報を共有してください。そうすれば、より多くを学ぶことができます。
これは今も続いていますか？
「いいね！」 5
Great thanks @sam and sorry I didn’t follow up on this yet.
Yes it still seems quite viable to make a lot of accounts using this trick (2.5.0.beta1).
For example, using the username+{randomstring}@gmail.com trick, someone created 748 accounts in the last 10hrs. They already have thousands of accounts on this single gmail address.
Pretty much the only way for me to be able to remove them from the admin area is manually going to each account individually to suspend and/or delete them. It’s not very viable because the guy can pretty much just press a button and make a lot more accounts. 
They pretty much seem to have an unlimited supply of IPs, so IP bans/limits are pretty much futile in this case.
Also, still consistently getting quite a lot of registrations using the gmail dot and + tricks.
Cheers!
「いいね！」 3
重複する Gmail アカウントのサポートを無効にするサイト設定の追加を支持します。技術的には、その設定を追加する作業は 15〜30 分で完了します。
「いいね！」 4
@sam さん、ありがとうございます。追加で役立つ情報を含む PM を送りました。
長年の経験から言うと、ほとんどの自動スパムボット（すべてではありませんが、圧倒的多数）は同じ「HTTP_USER_AGENT」文字列を使用しています。IPアドレスを偽装できるスパムボットの一部でも、同じ「HTTP_USER_AGENT」を使用しているか、あまりに不自然で検出が容易なものを採用していることが多いです。
その理由は、多くのボマーやスパマーが単にボットスパムソフトウェアをダウンロードして実行するだけで、実際に何をしているのか理解していないからです。もちろん例外はありますが、99%以上のスパムボットは、それほど専門知識を持たないスパマーがダウンロードして実行するスクリプトやプログラムに過ぎません（一般的に、彼らはコーディングの巨匠ではありません）。
実際、これらの「HTTP_USER_AGENT」文字列は非常に明白な場合さえあります。理論上はあらゆる対策を回避できる可能性はありますが、実際には当フォーラムでは数十年にわたり、他のフォーラムに比べてスパム問題は極めて少なくなっています。これは、メールアドレスをさまざまな基準に基づいてスコアリングし、明らかなものを拒否しているためです（モデレーションは行わず、スコアが一定の閾値【信頼レベル】を超えた場合は登録を即座に拒否します。なぜなら、スパムの大量データベースをモデレーションしたい人はいないからです）。また、多くの理由から Akismet は使用していません（何年も前から）、しかしこの話題から脱線したくはありません 
一方、旧vBulletinフォーラムでは、これらはすべてPHPプラグインで容易に実装でき、リアルタイムで修正し（そして善戦し）ることができます。かつてはベイズ分類器を使用こともありましたが、長年の経験を通じてより良い方法を見つけました。さらに、クッキーを使用し、クッキーポリシーを受け入れ（当社のプライバシーポリシーに従ってクッキーを許可する）クライアントからの登録のみを許可する方法も採用しています。もちろん、ユーザーが登録した後にもクッキーを読み取り、複数のログインを検出するために使用することも可能です。正直なところ、これでほとんどのスパムボットを阻止できます。これはロケット科学ではなく、一般的に「IPアドレスベースのみ」というわけでもありません。
また、参考までに、ほとんどのスパムボットはクッキーを受け入れないため、クッキーを許可しないクライアントをブロックするだけでも効果が大きいです。
「賢そう」に聞こえるかもしれませんが、私は20年以上この分野に携わり、このテーマに関する学術論文も発表し、この分野でリアルタイムのサイバー戦争を戦い、リアルタイムのサイバー防御およびスパム対策技術において20年近い実務経験があります。したがって、私が何を話しているのか理解しています。もしこのような機能がDiscourseアプリに用意されていない、計画されていない、あるいは簡単に実装できない場合でも、私の返信を過度に厳しくブロックしないでください。よろしくお願いいたします。
すべての人、特にユーザーを支援しようとする専門家に対して、包括的でありましょう。
では、Cheers。
「いいね！」 2
…30 秒後…