なぜここで複雑な依存関係を採用するのでしょうか？単純なメールアドレスのロックダウンモードの方が、実装も、その挙動の理解もずっと簡単です。それに、これで新たな脆弱性に晒されることになります。お断りします。
この苦情は極めて稀で、その状況も特異であることを踏まえれば、シンプルかつ極めて厳格なアプローチを選ぶ方が望ましいと考えます。
/a-zA-Z0-9/ 以外の文字をすべて禁止するというシンプルな方法は機能しますが、重大な使い勝手の問題を引き起こします。多くの人がサインアップ方法がわからず、新しいエラーメッセージの作成も必要になります。多くの Gmail ユーザーは、janedoe@gmail.com が有効なメールアドレスであることを知りません。彼らは常に jane.doe@gmail.com が自分のメールアドレスだと信じているからです。この禁止措置は OAuth に影響し、Gmail でのログインが正常に機能しなくなる可能性があります。
メールアドレス:
sam.s@gmail.com
エラー: メールアドレスに.は許可されていません（新しいメッセージ）
正規化はユーザーを敵対視せず、新しい UX も不要です。
まずは、より単純なオプションの正規化から始めることができます（タグの除去、Gmail のドットの除去など）。
ただし、100% 明確に言っておきますが、ここでは依存関係の導入を提案しているわけではありません。email_address は破綻しており、ここで求められている用途には適していません。
ここで急いで中途半端な対策を講じれば、「私のサイトでメールを無効にする」というサイト設定が生まれるだけで、私はそれを追加することにあまり乗り気ではありません。
「いいね！」 1
その通りですが、彼のサイトは包囲状態にあります。毎日、何千もの偽アカウントが登録しています。そのため、モサドと戦って惨敗しているサイト向けに、メールアドレスを簡単にロックダウンするモードを用意するのは合理的です。
戦争には犠牲が伴います。民間人の犠牲も出ます。彼のサイトはすでに壊滅状態です。
「いいね！」 1
理想的には、各メールプロバイダーごとに「クリーンアップ」の方法を示す表が必要になります（まさにあなたが引用した内容のように）。Bart がよく説明してくれたように、特定の文字を使用するメールアドレスを禁止することではなく、実際には同一のアドレスを特定できるようにすることが重要です。
確かに、どうしてもやりたいスパマーは常に手段を見つけ出すでしょう。これは防犯アラームや施錠と泥棒の関係と同じで、目的は「より難しくすること」です。
Gmail アドレスを大量に作成することは Gmail に対するスパム行為であり、それは Gmail 側が対処すべき問題です（その後、それを使ってあなたにスパムを送られる可能性はありますが）。
「いいね！」 1
意味がわかりません。
もし bob.test+100@gmail.com を内部で bobtest@gmail.com として扱い（スイッチがオンの場合）、その形式で保存するとしたら、ここでいったいどのような犠牲が払われるというのでしょうか？
この不具合は gmail に特化したものです。Google が仕様を考案して正規化を決めたからといって、すべてのドットを禁止するのは反応が大きすぎるように思えます。クリーンアップのロジックは実際には非常にシンプルであり、この機能はデフォルトでオフのオプションとなるはずです。
@Mevo 念のため完全に明確にしておきますが、ここで Jeff が提案しているのは、「ディザスターモード」と呼ばれるモードを追加することです。このモードでは bob.test@gmail.com は無効なメールアドレスとして扱われ、使用することができません。
「いいね！」 3
簡略化された形式と比較することをお勧めしますが、元の指定されたアドレスを保存し、そこにメールを転送し続けるよう注意する必要があります。
ユーザーは他のバリエーションにメッセージを送信する同意を与えておらず、指定されたアドレス以外のものを使用すると、メッセージが届かない可能性があります。
例を挙げると、私はサービス開始から数ヶ月後に作成した Gmail アドレスを持っています。ベースのエイリアスへのメールは事実上破棄されます。特定のプラスアドレスに到達したメールのみが閲覧されます。
また、推測にも注意してください。多くの Gmail ユーザーはドットがオプションであることを知りません。プラスアドレスについても、大多数は聞いたことがありません。後者の乱用を防ぐための選別は、前者に被害をもたらすリスクがあります。
「いいね！」 4
@sam ジェフの意図はよく理解できましたし、あなたと同様に、彼の提案には反対です（彼に悪意はなく、意見の相違は当然あります）。
これは細かすぎるかもしれませんが、「クリーンアップされた」メールアドレスのみを保存すると、正当なユーザーが意図的に行っていることが失われてしまいます。例えば、bob+meta@example.com や bob+forums@example.com でユーザーが登録（完全に正当で、1 回限り）した場合、彼が達成しようとしていたことが失われてしまいます。問題は、彼が実際に受信するのは bob@example.com へのメールだけであり、それが彼の意図したものではありません（例えば、「タグ」を使って受信メールを特定のフォルダに分類できるなど）。
これを考慮するとシステムが少し複雑になることは完全に理解しています。ユーザーが入力したバージョン（メール送信用）と、クリーンアップされたバージョンの両方を保存する必要があります。クリーンアップされたバージョンは、現在メールアドレスに使っているように（ユーザーに関連する内部処理全体や、そのユーザーが既に登録済みかどうかの確認に）使用できます。さらに、上記の小さな問題を防ぐためには、ユーザーが入力したものを追加で保存する必要があります（これはメール送信にのみ使用します）。これは、メールの「返信先」アドレスに相当します。
ご理解いただけたら幸いです。
編集：@Stephen とほぼ同時に記載（全体的に同じ考え）
「いいね！」 2
これは非常に重要な指摘です。これにより、実装が少し複雑になります。
おそらく、このチェックは「新規アカウント作成」時のみ行うべきでしょう：
この正規形式のメールアドレスがすでにシステム内に存在しますか？存在する場合は、申し訳ありませんが、新しいアカウントは作成できません。
また、Google OAuth（これも正規化されたメールアドレスをチェックするかどうか）や、非正規形式から正規形式への移行に関する別の問題もあります。
Oauth はプラスアドレスングには対応していないと認識していますが、それでは対象外ということになりますか？
つまり、Google で新しいアカウントを作成し、別のエイリアスを指定して、これを繰り返すことができないということです。
同じ問題領域です。
sam+hi@gmail.com でサインアップし、その後「Google でログイン」ボタンをクリックするとどうなりますか？
-
現状：新しいアカウントが作成される
-
提案:
-
オプション A: エラー画面を表示し、このアカウントの作成を許可しない
-
オプション B:
sam+hi@gmail.comでユーザーがログインする
-
元の提案されたロックダウンモードでは、sam.test@gmail.com は「Google でログイン」ボタンでログインできません。
プラスアドレスや誤ったドットを除去するための堅牢な翻訳を考案できると仮定すれば、重複排除後のメールアドレスのハッシュ値を保持し、アカウント作成時にそれと比較するだけでよいでしょうか？
それはオプション B です。したがって、「Google OAuth にサイドプロブレムが存在する」ということです 
また、移行の問題は厄介ですが、おそらく回避できるでしょう。
とはいえ、この問題の実環境における範囲を考えると、今後数ヶ月で何らかの変更を行うことは想定していません。
前述の通り、内部的には「正規」バージョンのみを使用し、ユーザーが入力した内容（メール送信用）を別途保存するという方法では解決しないでしょうか？
これは十分に解決できます。このような新しいスイッチのテストとデバッグには、気にすべき細かい点が多数あるため、2〜6 日程度の作業が必要になると見積もっています。
ここで問題なのは、@codinghorror がこの機能に対してその程度の時間を予算化することができない点です。
大量のメールログインを破綻させる 機能を 1 日で実装することは可能ですが、Discourse にそのような設定を置くことは望んでいません。
したがって、@Mevo さんは少し困った状況に置かれています… この問題をより多くの人が体験し、報告することで、ようやくこの問題に時間を割く正当な理由が生まれます。
「いいね！」 3
@sam 理解しました。
（余談ですが、これは初めて目にする現象です。あなたの投稿は自動的に編集されました：「[system] — 直前の投稿全体の引用が自動的に削除されました」。すごい！とても便利な機能ですね！）
正規バージョンを保存しないよう、極めて注意を払う必要があります。ユーザーはそれを提供することに同意しておらず、ユーザーテーブルが侵害された場合、どのサービスがデータを侵害したのかを容易に特定できません。
Facebookは、ユーザーが提供しておらず、アカウントに関連付けることに同意もしていない個人情報（PII）を保存したことで、繰り返し深刻な問題に巻き込まれています。
「いいね！」 4
個人的にはこの設定に全く問題はないと思いますが、「あの人が一度困ったことがある」という理由だけでやりたくありません。
ええ、Discourse に追加すべきだと提案するのは本当に「ひどい」ことです。強く反対します。さらに、アドレス指定は機能であり、昔から機能であり、ユーザーフレンドリーです。
もしモサドに攻撃されているなら、「モサド攻撃モード」を有効にしてください。おそらく、モサドがもっと多くの人を攻撃する必要があるのでしょう？
Discourseにこの設定を追加することに、私は強く反対しています。プラグインとして実装するのは全く問題ありません。プラグイン内であれば数行のコードで済みます。どうしても必要であれば、今日は休憩してプラグインを作成します。お知らせください。
問題を抱えている本人が「もう使わない」と言っているのに、わざわざ実装するのは無意味でしょう。
「Discourseを壊す」という設定は根本的に問題があり、製品に含めるべきではないと思います。
もしより多くの人々が同じ問題に直面していれば、メールのロックダウンモードも正当化されただろうと思います。しかし現状では、あの一サイトの一利用者だけの話です。
だから、様子を見るしかありませんね…
「いいね！」 1
「その機能を使わない、たった一人の人物が、たった一つのサイトにいる」というのがより正確ですね。