@sam 、正直に言うと、これはCAPTCHAユーザー作成プラグインが必要なのではないでしょうか？「ドットやプラス記号を禁止する」という対応は根本的な原因への対策ではなく、単に症状に対処しているだけだと感じます：thinking:
歴史的に見れば、スパマーは時間とともに100%人間によるものへと移行する傾向にあります。つまり、彼らはユーザープロフィールを記入し、プロフィール画像をアップロードし、あらゆることを行います。自動化されたスパマー（bamwarを除く）は、Discourseが完全なJavaScriptアプリケーションであり自動化が極めて困難なため、大きな問題にはなっておりません。@neounix さんのコメントの多くも、前述のカテゴリーに該当します。1999年頃のHTML 1.0のウェブサイトと比較して、Discourseはあまりに複雑であるため、スクリプト化するのは非常に困難です。このようにハードルを高く設定することで、顧客やメタでの観察に基づき、問題の大部分が解消されています。
結論を言えば（TL;DR）、特定の文字をメールアドレスで禁止する単純な設定には必ずしも反対ではありませんが、心の中では、このケースではCAPTCHA以外の対策では大きな効果は得られないと考えています。両方の対策を併用することも可能です。
「いいね！」 5
しかし、一部のユーザー（私自身も含む）は、メールクライアントでメールを並べ替えるために実際に「+」を使用しています。
「いいね！」 3
ご安心ください。これはデフォルトでは有効になりません。サイト設定による「攻撃時のロックダウン」モードです。
「いいね！」 7
@neounix 伝説的な存在ですね。アドバイスありがとうございます、とても感謝しています。スパム対策の旅に出かけました。一時的に Cloudflare を「攻撃中」モードに設定しました（これで彼らの登録が止まりました。1〜2 分ごとに新しいアカウントを作成していました）。Cloudflare のファイアウォールログを確認すると、彼らが使用していたいくつかの IP アドレスが見つかり、すべての訪問者がチャレンジまたはログ記録されていることがわかりました。彼らは確かに同一のユーザーエージェントを使用していました。
そのユーザーエージェントを持つユーザーにチャレンジを行うファイアウォールルールを追加し、CF の「攻撃中」モードを無効にしました。これによって無実のユーザーがチャレンジを受けることはほとんどなかったと思いますし、スパム登録は完全に止まりました。
その後、Cloudflare が提供する AS 番号（ASN）ブロック機能を見つけ、ユーザーエージェントブロックログを参照して、かなりの数の ASN をブロックする追加のファイアウォールルールを設定しました。これに対する回避策はあると思いますが、それらは彼らにとって追加のリソースコストと労力を意味します。
@codinghorror カプチャが役立つという点に同意します。スパム防止の主要な目標は、スパマー全体のリソースコストを上げることだと考えます。
カプチャはこれに貢献します。再カプチャの解決には API（例：https://anti-captcha.com ）を使用すると、1,000 回あたり約 2 ドル程度の費用がかかります。さらに、ボットにとっての複雑さが増します。
余談ですが、Anti-captcha には自動的にカプチャを解決するブラウザプラグインがあり、よく機能し、便利な機能として楽しんでいます。
メールアドレスは通常、大量のアカウント作成におけるもう一つのリソースコストです。ただし、1 つの Gmail アドレスから事実上無制限のアカウントを作成できる場合は例外です。1,000 個の Gmail アカウントを作成するには相当なコストがかかるため、彼らはしばしばより緩いプロバイダーやキャッチオールドメインに頼ります。それでもリソースコストはかかりますし、スパムとして特定しやすくなります。
これはまさに「多ければ多いほど良い」というケースだと思います。単一の防御策だけでは十分ではありません。スパマーに必要なリソースと労力を全体的に増やすことが、正しい方向への一歩です。最良のシナリオは、スパマーが Discourse フォーラムにスパムを送る労力が、管理者がそれをブロックし、通過したものを一括削除する労力よりも大きくなることです。
@itsbhanusharma 「+」記号を使えるのは本当に素晴らしいですが、これが私たちが良いものを手放さざるを得ない理由ですね（笑）。それでも、スパマー対策に必要な場合、これをブロックするオプションを有効にできるのは素敵だと思います。
「いいね！」 2
考えてみると、私もこれに賛成する傾向にあります。@sam 、来週このメールロックダウン設定を優先して対応することは可能でしょうか？
「いいね！」 5
Mevo
2020 年 4 月 11 日午後 3:14
66
この件については、このスレッド内ですでにかなり議論されています。
これが、サムが以下のように述べているときに言及していることかもしれません。
もしかすると、@codinghorror 氏も「禁止」ではなく、このような意味をおっしゃっていたのかもしれません。
あなたが以下のようにおっしゃっているように、CAPTCHA は本当に何かを解決するのでしょうか？
？
Stephen
2020 年 4 月 11 日午後 3:17
67
それは一歩飛ばしてしまったように聞こえますね。
正規のメールアドレスの使用を強制するのは問題がありますが、正規のメールアドレスごとにデフォルトで複数のアカウントを禁止するのは、かなり妥当な措置です。
テストアカウントが必要な場合、私たちの多くは複数のメールアドレスを持っています。デフォルトでこの設定を有効にしておけば、そこで大きな問題が生じることもありませんし、不正利用が発生してから有効にするよう人々に教育する必要もなくなります。
「いいね！」 1
メール内のプラス記号（+）は、ほぼすべてのメールドメインで問題なく同様に扱えると思います。
sp.a.mmer.king@gmail.com や s.pa.mmerking@gmail.com のようなメールの場合、Gmail ではこれらは同じメールアドレスとみなされます。しかし、他のプロバイダーによってはそうではなく、両方が異なるユーザーとして扱われる可能性があります。
–
長期的に見て良い実装としては、メールドメインのブラックリスト機能のようなものが考えられます。
重複登録のトリックを防ぎたいカスタムドメインを追加し、これらの 2 種類の重複登録ブロックを個別に有効/無効にできるようにします。つまり、「+」を使った重複登録と「ドット（.）」を使った重複登録を別々のオプションとして禁止する方式です。
登録されたメールアドレスはそのまま（ユーザーのログイン情報や送信先アドレスとして）保存しつつ、同一と判断される追加の登録をブロックします。
さらに効果を高める方法として、複数のドメインを 1 つのカスタムドメインレコードにまとめて、それらを同じドメインとして扱うことも考えられます。例えば gmail.com と googlemail.com のようにです。これにより、example@gmail.com と example@googlemail.com のように異なるドメインを使って 2 回登録しようとするユーザーをブロックできる可能性があります。他にも複数の相互交換可能なドメインを持つプロバイダーがありますが、その例は Sam にお送り済みです。これにより多少の保護が追加されますが、主に問題となるのは「+」や「ドット」を使った重複登録です。
–
あるいは、よりシンプルな実装として、上記と同様ですが、各カスタムドメインに対して「+」や「ドット」を含むすべての登録をブロックするオプションを用意する方法もあります。そのドメインで「+」や「ドット」を使ってユーザーが登録しようとした場合、ドットや「+」を削除して再度登録するようエラーメッセージを表示します（自動的に修正することも可能です）。完璧ではありませんが、非常に効果的でしょう。
Stephen
2020 年 4 月 11 日午後 5:12
69
その通りです。そのため、一意性を確保するために正規化されたメールアドレスに集約します。これは前述の通りです。ただし、正規化されたメールアドレスをユーザーのメールアドレスとして保存することはできません。なぜなら、それはユーザーが提供したアドレスではないからです。
ドメインのブラックリストは既に存在しますが、ユーザーが Googlemail または Gmail アドレスでも到達可能だからといって、一方を拒否すべきだとは限りません。そのため、正規化された「マスター」アドレスに戻って判断する必要があります。
現在でも、ユーザーが正当に「+」アドレスやドットを使用しているサイトがあります。目的は正当な運用を不便にすることではなく、1 つの正規化アドレスに対して2人のユーザーが存在するという不合理な副作用を抑制することにあります。
登録プロセス中に、ドットやプラス記号を除去した文字列のメールアドレスの提供がクライアント側で同意のもとに必要とされる場合（フォームバリデーションと同様）、それをアカウントのメールアドレスとして保存することは問題ありません。
理想的ではありませんが、一部のケースでは、いくつかのユーザーに不都合を強いるか、スパムによってフォーラム全体に不都合を強いるかという選択において、よりシンプルで価値のあるトレードオフとなり得ます。
Gmail のアカウントには、正規のメールアドレスにドットが含まれているものもあります。登録時に強制的にドットを削除すると、これらのユーザーが最も影響を受け、混乱するでしょう。
これも最適な実装だとは思いませんし、デフォルトのオプションとして親切なものでもありません。
Stephen:
ドメインブラックリストは既に存在しますが、ユーザーが googlemail または gmail アドレスの両方で連絡可能だからといって、どちらかを拒否すべきだと仮定することはできません。そのため、正規の「マスター」アドレスに戻って参照する必要があります。
現在、ユーザーが正当にプラスアドレスやドットを使用しているサイトもあります。目的は正当な慣行に不都合を強いることではなく、一つの正規アドレスに対して複数のユーザーが存在するといった不合理な副作用を抑制することです。
はい、私が言いたかったのは、既存のメールアドレスドメインブラックリストと同様のオプションメニューを用意し、どのメールアドレスドメインが影響を受けるか、また、メールアドレスが一意か正規かどうかを判断するために使用すべき/使用すべきでないパラメータを入力できるようにすることです（このスレッドで議論されている通り）。また、gmail と googlemail のように、同じホストと見なすべきドメインを指定できるようにすることも考えられます。
gmail と googlemail については、私たちが合意していると思います。ドットやプラス記号についても同様です。
本質的には、最初の登録を許可しつつ、同じメールアドレスを使って複数のアカウントを作成できないようにするか、少なくとも合理的な範囲内でそれを最小限に抑えることです。
john@googlemail.com が最初に登録 → 承認john@gmail.com が後に登録 → 拒否
matthew+{randomstring}@gmail.com が最初に登録 → 承認matthew@gmail.com が後に登録 → 拒否matthew@googlemail.com が後に登録 → 拒否m.att.he.w@gmail.com が後に登録 → 拒否matthew+{randomstring}@gmail.com が後に登録 → 拒否m.a.tt.ew+{randomstring}@googlemail.com が後に登録 → 拒否
googlemail と gmail の違い（および複数の代替ドメインを持つ他のプロバイダー）は、ドットやプラス記号の問題に比べてはるかに重要度が低いです。ただし、それらのケースを処理できれば素晴らしいでしょう。
Stephen
2020 年 4 月 11 日午後 6:31
71
それは非常にユーザーにとって不親切な変更であり、完全に不要です。これらの機能がそもそも存在する理由は、メールの送信元を特定するためです。私が stephen+meta@gmail.com というメールアドレスで登録する場合、そのアドレス宛てに送信されるすべてのメールにラベルを付けるルールを設定できます。もし meta が侵害され、そのエイリアス宛てにスパムが届くようになったら、どこで侵害が発生したかがわかります。メールの使い方を制限することは解決策ではなく、メールアドレスを比較のために正規形に単純化することで、ユーザーに不都合を生じさせることなく同じ結果が得られます。
はい、それは正規アドレスの概念と密接に関連しています。この機能が当初議論された通り実装されれば、ドメインを関連付ける機能から非常に恩恵を受けるでしょう。すべてのピリオドやプラス記号の組み合わせ、ドメインのバリエーションが、そのメールボックスの「唯一の正しいメールアドレス」と比較され、一切 の摩擦を生じさせることなく処理されます。
ユーザーに不利益をもたらさない限り、この機能をデフォルトでオンにしてリリースする理由はありません。
同意します。不完全な解決策は不完全です。私はこれを、実装がよりシンプルになる可能性のある代替案として述べただけです。私の投稿の最後の部分は、このスレッドでの議論の多くに賛同しつつ、‘+’ やドットを許可しつつも重複アカウントを認めないという、私が最初に提案した代替案として提示したものです。
とはいえ、技術系以外のフォーラムやサイトで ‘+’ を使ってメールを使用する正当なユーザーは、私の経験上、一般的には特殊なケースです。
Stephen:
その通りです。それは正規アドレスの概念と密接に関連しています。もしこの機能が当初議論された通りに進められたなら、ドメインを関連付ける機能によって本当に恩恵を受けることができました。すべてのドットやプラスの組み合わせ、ドメインのバリエーションが、そのメールボックスの「唯一の真のメールアドレス」と比較され、一切の摩擦 を生じさせることなく処理されます。
ユーザーに不利益をもたらさない限り、この機能をデフォルトでオンにしてリリースする理由はありません。
本当に素晴らしいですね。
私の投稿は主に、異なるメールドメインに対して正規アドレスがどのように計算されるかについて述べるものでした。つまり、Gmail/Googlemail のみに限定されるものではありません。本質的に言いたかったのは、ドメインごとに正規アドレスの計算方法をユーザーが選択できるようにすることは、長期的には良い実装になり得るということです。
例えば、一部の他のプロバイダーは ‘+’ は許可しますが、ドットの組み合わせは許可しません。つまり、ドットの組み合わせは固有のメールアドレスとなります。
ただし、Gmail/Googlemail 限定の実装でも素晴らしいですし、それがデフォルトでオンにできない理由も特に思い当たりません。
Stephen
2020 年 4 月 11 日午後 8:14
73
具体例を挙げていただけますか？私がこう聞くのは、Gmail ユーザーの大多数が「ドットトリック」に無関心だからです。彼らはドットを含んだアドレスで登録し、そのバージョンを全員に伝えていますが、「自分のメールアドレスが無効」と言われたら非常に混乱するでしょう。
ドットを除いたエイリアスでも受信できることに気づいている人に、めったに出会いません。
「いいね！」 1
もちろん、サムに送った例を今すぐプライベートメッセージで送ります。このスレッドのタイトルで公開するのは良いアイデアかどうか確信が持てないからです。幸いなことに、まだ多くのスパマーがそれについて知らないようです。
そうですね、同意します。その不完全な解決策では、一般ユーザーにとって主な混乱の原因になるでしょう。
そんな複雑なアプローチを採用するはずがありません。私たちはメールアドレスを「正規化」しません。
あなたはメールロックダウンモードにあるか、いないかのどちらかです。メールロックダウンモードでは、特定の厄介な文字をメールアドレスから完全に排除 します（ハードコードされたメールドメインに基づき、おそらく）。それだけです。
つまり、ブール値のトグルです。メールロックダウンモード：はい/いいえ？
「いいね！」 3
sam
2020 年 4 月 14 日午前 4:23
76
参照:
committed 04:16AM - 14 Apr 20 UTC
The new `enforce_canonical_emails` site setting ensures that emails in the
canon… ical form are unique.
This mean that if `s.a.m+1@gmail.com` is registered `sam@gmail.com` will
not be allowed.
The commit contains a blanket "tag strip" (stripping everything after +)
it also contains special handling of a "dot strip" for googlemail and gmail.
The setting only impacts new registrations after `enforce_canonical_emails`
The setting is default false so it will not impact any existing installs.
これで完了しました。
この保護を有効にするには、サイト設定 enforce_canonical_emails（デフォルトは false）を使用してください。
有効にすると、googlemail.com と gmail.com における . ハック、および + ハックを使用した重複登録をグローバルに禁止します。
この修正は非常に安全で、無効な状態ではデフォルトで何の影響も与えません。
実装の副作用として、設定を有効にした直後に 1 つの重複アカウントが回避される可能性があります。これは、設定を有効にしない限り、ユーザーのメールテーブルに正規化された形式のメールを保存しないためです。しかし、これは一般的に許容範囲だと考えます。なぜなら、私が運営する多くのサイトにおいて、この特定の悪用の事例を見つけることができなかったからです。
「いいね！」 8
Stephen
2020 年 4 月 14 日午前 4:57
77
正規形を保存すること自体が問題 です。どのような形式ですか？
sam
2020 年 4 月 14 日午前 4:58
78
仕様はここにあります：
context "canonical emails" do
it "correctly creates canonical emails" do
expect(UserEmail.canonical('s.a.m+1@gmail.com')).to eq('sam@gmail.com')
expect(UserEmail.canonical('sa.m+1@googlemail.com')).to eq('sam@googlemail.com')
expect(UserEmail.canonical('sa.m+1722@sam.com')).to eq('sa.m@sam.com')
expect(UserEmail.canonical('sa.m@sam.com')).to eq('sa.m@sam.com')
end
it "correctly bans non canonical emails" do
email = UserEmail.create!(email: 'sam@sam.com', user_id: user.id)
expect(email.canonical_email).to eq(nil)
email = UserEmail.create!(email: 'sam+1@sam.com', user_id: user.id)
expect(email.canonical_email).to eq(nil)
SiteSetting.enforce_canonical_emails = true
email = UserEmail.create!(email: 'Sam+5@sam.com', user_id: user.id)
expect(email.canonical_email).to eq('sam@sam.com')
show original
サイトの設定が有効になっていない場合は、何も起こりません。ゼロ、ナシです。
「いいね！」 5
neounix
2020 年 4 月 14 日午前 5:08
80
markersocial:
@neounix 伝説的な存在ですね。アドバイスいただきありがとうございます、大変感謝しています。スパム対策の旅に出かけました。Cloudflare を一時的に「攻撃中」モードに設定したところ、彼らの登録が止まりました（1〜2 分ごとに新しいアカウントを作成していました）。Cloudflare のファイアウォールログを確認し、彼らが使用していたいくつかの IP を調べたところ、すべての訪問者が検証またはログ記録の対象となっていました。彼らは確かに同一のユーザーエージェントを使用していました。
そのユーザーエージェントを持つユーザーに対して検証を行うファイアウォールルールを追加し、Cloudflare の「攻撃中」モードを無効にしました。多くの無実のユーザーが検証の対象になったとは思いませんが、スパム登録は完全に止まりました。
その後、Cloudflare が提供する AS 番号（ASN）ブロック機能を見つけ、ユーザーエージェントブロックログを参照して、さらに多くの IP ブロックを対象としたファイアウォールルールを設定しました。これに対する回避策は確かに存在すると思いますが、それには追加のリソースコストと努力が必要です。
温かいお言葉をありがとうございます、@markersocial
以前返信できず申し訳ありませんでした。他のタスクに忙殺されており、ようやくメタ情報の整理が整いました。
スパム、偽登録、DDoS 攻撃、侵入、そして全般的なサイバースペースの状況認識、その他同様の検出指向およびマルチセンサーデータ融合のサイバーセキュリティ問題の検出は、私の最も好きなテーマの一つです。あなたがそれを理解してくれているようですね
前線で多くの「実戦」サイバーバトルをリアルタイムで戦ってきた経験から、このような攻撃に直面した際に役立つヒントをもう二つ伝えましょう。
(1) 検出は純粋な科学というよりは、むしろ芸術に近いものです。その理由は、攻撃者があなたの検出・緩和アルゴリズムや技法について知っていることが多ければ多いほど、彼らはあなたの防御策に対して変異し、適応してくるからです。
(2) また、「OODA ループ」を決して忘れないでください。Observe-Orient-Decide-Act（観察・方向付け・決定・行動） サイバーバトルにおいて、相手の OODA ループの内側に入り込める者が、一般的に勝者となります。
サイバー防御を楽しみ、より大きな視点で捉えていると伺えて光栄です。この議論の概要をざっと拝見した限りでは、すべてがコントロール下にあるようですし、素晴らしいメタチームもあなたのために役立つ変更をコミットしてくれたそうですね。
もし攻撃に遭い、助けが必要であれば、遠慮なく私に連絡してください。私は利益追求や富の蓄積の世界から長く引退しています（本当に良かった！）、ので、私に相談する際に費用は一切かかりません。サイバーセキュリティやサイバー戦争の分野で興味深い技術的問題を抱える人々を支援することは、私にとって富を蓄積することよりも優先度の高いことです。
アイデアをぶつけ合う相手が必要であれば、私はいつでもあなたの味方です。最近のあなたの返信を読む限り、あなたは状況を十分にコントロールできているようです。
素晴らしい仕事ですね！
「いいね！」 5
sam
2020 年 4 月 16 日午後 8:46
81
@codinghorror 私の考えでは、この変更は無意味であり、変更を元に戻すべきです。
私たちのホストされているサイトのいずれも、これを求めておらず、極端なメールブロックモードを求めているわけではありません。実際には、これらの問題はすべて問題になりません。なぜなら、私たちは非アクティブなアカウントを削除し、スパムスキャンをプロファイルに対して行うからです。
スパマーは、Gmail の自動化よりも簡単な SMTP サーバーを運用でき、その方法で無限のメールにアクセスできます。
さらに、アドレス指定は正当な目的で広く使用されています。
Gmail のドットに関する問題で最も一般的なものは、スパムではなく、メールのタイプミスです。
私がコアで支持する唯一の変更は、ブロックされたメールを正規化されたメールにも拡張することです。少なくとも、これはメールブロック機能の改善であり、OP の問題を解決します。
例えば、Jane@gmail.com をブロックする場合、j.ane+1@gmail.com もブロックされます。
他の変更はプラグインで行うことができます。
これで問題ないでしょうか？
「いいね！」 7
