sam:
もし sam.sam@somewhere.com が登録済みの場合、samsam+11@somewhere.com はもはや登録できません。
これは私の元の修正案でしたが、最終的に元に戻しました（ただし、Google に対しては特別扱いをしていました。振り返れば、それは厳しすぎませんでした）。
個人的には、新しいサイト設定を追加してこの件を終わらせるべきだと感じています。設定名は以下の通りです：
「OMG、私は巨大なスパムベクターだ、メタルのフォイルモードをオンにしてくれ」
バグについてですが、ブロックを遅らせることで、今では簡単にスパムが潜り込んでしまいます。現在のプロセスは 100% 反応型です。
元の修正が完璧に機能し、Gmail 関連のこの問題を解決したことを確認できます。このオプションモードが復活すれば、まさに命拾いになるでしょう。
スパマーたちは常に新しい技術を学び、Facebook、Instagram、Twitter といった巨大プレイヤーさえも依然として巧妙に欺いています。これにより、他の多くの場所は「イージーモード」になってしまいます。彼らにとってこれはフルタイムの仕事であり、実質的には以下のようになります：
もし脆弱性があり、かつ（必要なコスト < 得られる収益）であれば、それは悪用されます。
彼らは実際にはどのような対策も回避できます。唯一の望みは、そのコストを上げ、金銭的にメリットがなくなる点まで引き上げることです。
検出される前に、ほぼ無制限のメールアドレスやアカウントを使って大量スパムを行うこと（その後に管理者が元の Gmail アドレスをブロックし、手動で投稿を削除する）は、非常にコスト効率が良いです。24 時間体制のモデレーターチームがない場合、その効果はさらに高まります。
スパム対策を回避するコストは低下し続けています。一つの例として、4G/5G プロキシがあります。月額 30〜50 ドル程度で、主要 ISP/ASN から提供される、実在するモバイル IP に事実上無制限にアクセスできます。これらは自動的に、あるいは手動でローテーションされ、大都市や州全体の正当なユーザーたちと共有されています。4G/5G IP は多くのユーザーによって同時に 共有されています。
これらの ISP/ASN や IP をブロックすることは適切ではありません（Verizon や AT&T などのすべてのユーザーをブロックすることはできないため）。彼らは通常、IP を一度使用したら捨ててしまいます。この方法でブロックされた個々の IP は、その IP をランダムに共有している正当なユーザーもブロックしてしまいます。IP ブロックは、既知のホスティング企業の ASN を除いて、徐々に過去の遺物になりつつあります。これらのフォーラムで氷山の一角が見て取れます：
https://mpsocial.com/c/public-marketplace/61
https://www.blackhatworld.com/forums/proxies-for-sale.112/
スパマーたちは、完全または部分的に自作されたボットと手動スパムの混合だと考えています。Discourse が市場シェアをさらに獲得し、明らかに劇的に成長している以上、それが商用利用可能なボットのターゲットにならないはずはないでしょう。
Xrumer が最新の reCAPTCHA バージョンに対応し始めた頃、レガシーフォーラムの多くのウェブマスターは、スパムのコストが劇的に低下した（もはやキャプチャ解決 API を使用する必要がなくなり、これはすでに 1000 回あたりのコストが非常に安価です）ため、スパムが大幅に増加したことに気づくでしょう：
http://botmasterlabs.net/buy1/
人々はすでに Xrumer を使って、ほぼすべてのプラットフォームに対応する独自のプラグインやスクリプトを作成できます。しかし、もし彼らが将来 Discourse を最初からサポートすれば：
私はこの件において中立とは言えません。なぜなら、私は直接スパム対策を必要としているからです。Gmail のドットトリックに関する元の投稿 は 2014 年に別の誰かによって作成されましたが、別のユーザー が最初の X 件の投稿について承認を義務付けることでこれを解決したようです。少なくとも 3 人のユーザーからの報告があるかもしれませんね：
余談になりましたが、本題に戻ります。
メールに対する正規表現ブロックについて、おっしゃる通りです。これは部分的な解決策ですが、以下の理由から理想的ではありません：
@ の前に 1 つ以上のドットを含むすべての Gmail をブロックする場合：
1 つ以上のドットを含む実際の正当な Gmail ユーザー（これは非常に一般的です）を避けられずにブロックしてしまいます。
スパマーは 1 つのドットを使ってかなりのバリエーションを作成できます。例えば、Gmail の最大長は 30 文字です。例えば 12345678901234567890123456789.0@gmail.com には、単一のドットを含む 30 の使用可能な組み合わせがあります。
@ の前に 2 つ以上のドットを含むすべての Gmail をブロックする場合：
ブロックされる正当な Gmail は減りますが、依然として 1 つ以上のドットを含む正当な Gmail ユーザーをブロックしてしまいます。
スパマーは、30 文字の Gmail 1 つを使ってさらに多くのバリエーションを作成できます。おそらく約 842 通りの組み合わせです。
sam:
つまり、これは問題なく機能します（@markersocial さんはコンソールでテストしてみてください）：
./launcher enter app
rails c
ScreenedEmail.block('examplemailaddress@gmail.com')
ScreenedEmail.should_block?('e.x.a.m.pl.e.m.ai.lad.dre.ss@gmail.com')
# true
ブロックが有効になった後に新しいアカウントが作成されたことを確認しました。ブロック作成日は 2 月 1 日です。私は昨日、新しいアカウントが作成されるのを監視しており、ブロック規則の新しい最近の一致と、同じメールアドレス（ドットのみ）の組み合わせを使用した新しい登録の両方が確認できました。
私は一晩中登録を無効にし、今朝再度有効にしました。今日までに、その Gmail アドレスの順列を使って 104 の新しいアカウントが作成され、さらに登録が続いています。これらのアカウントのメールアドレスからドットを取り除くと、Screened Emails のブロック記録と完全に一致することを確認できます。
説明された通り rails c でブロックをテストしようとしましたが、ここから少し奇妙なことが起こります。
どうやら、一部のレコードは意図通り true を返し、一部のレコードはテストしたメールがブロックされた正規のメールと完全に一致しているにもかかわらず false を返しているようです。true を返したレコードについては、完全に意図通り機能し、私がテストしたすべてのバリエーションに対して true を返しました。しかし、false を返したメールについては、私がテストしたすべてのバリエーションも false を返しました。
相関関係を見つけようとしました。これらは相関していない（少なくとも一貫して相関していない）ことを確認できます：
メール長（@ の前）
メールに文字と数字が含まれているか
一致数（ブロックされた回数）
一致日
ただし、ブロック作成日との相関があるように見えます。古いものほど機能しにくい（false を返す）傾向があります。9 日前に作成されたレコードは true と false が混在しており、それより前に作成された（1 時間〜8 日前）すべてのテストしたレコードは true を返しています。
もしかすると「一致しないメールの最大保存期間（max age unmatched emails）」に関連しているかもしれません。このオプションは比較的新しいもので、私はデフォルト値の 365 日に設定しています。
結構なスペースを占有しそうですよね。ここで問題になっているのは Gmail アドレスだけなのでしょうか？
