要は、正規のメールアドレスを強制することは実質的に同じですが、ユーザーに極めて親切ではありません。
Sam.sam@gmail.com は許可されず、Sa.msam+123@gmail.com はすでに登録されています。
いずれにせよ、次のリリースで正規表現を実装します。
「いいね！」 2
でも、実際には役に立たないからこそ、こんな議論になっているんです。相手が核を持てば、こちらも核を持つ必要があります。
「ユーザーに敵対的」という概念は、相手側に核があり、それを使う意思がある以上、無意味です。
これには同意できません。この解決策は @markersocial さんには完璧に機能しました。その後、私の手は縛られていたため、変更を元に戻しました。
私が実装し、その後元に戻した正規化アプローチには既知の欠陥はありません。上記の Gmail の問題を 100% 解決します。
「いいね！」 3
ええと、私はそれに反対です。なぜなら、それではコードや労力の負担が相手側ではなく、私たちの側に来てしまうからです。メールの「正規化」は非常に複雑で、メールプロバイダーによって異なり、私はそのような事業には入りたくないのです。
つまり、核兵器の構築と管理は彼ら自身に任せるべきです。Discourse のあらゆるインストールにおいて、「もしものために」プロト核兵器を各国に配送する必要はありません。
（さらに、正規表現を通じてメールをブロックリスト化できる機能は非常に強力です。特に、Discourse においてメールはアイデンティティであるという点から重要です。）
「いいね！」 1
独自の正規表現ルールで正規化させることも、ある種の妥協案として可能ですが、そうすれば当社は正規化の業務には関与しなくなります。
とはいえ、次回のリリースでは正規表現によるブロック、あるいは少なくともワイルドカードによるブロックは実施されます。
「いいね！」 6
以前の実装は完璧に機能し、Gmail の問題を完全に解決したことを確認できます。ドメインの許可リストと拒否リストは非常に効果的な対策ですが、Gmail をブロックするのは現実的ではありません。
@codinghorror 異なるメールプロバイダーの正規化に反対するご意見は理解できます。しかし、少なくとも Gmail（2020 年の全世界で約 43%、米国では 53% を占める）を破壊的な方法ではなく対応できるようにすることは理にかなっていると思います。これは、主要プロバイダーからの OAuth サポートを標準で提供するのと同様の考え方かもしれません。
@sam ^ これは素晴らしい代替案ですね。
特に、Gmail/Googlemail の一致例を添えれば、ユーザーにとって非常に親しみやすく、強力な機能になるかもしれません。
「いいね！」 2
現在、1 つの Gmail アドレス（ドットを利用して）で数千のアカウントを作成し、競合サイトを宣伝してユーザーを奪おうとするスパム行為を行っているユーザーがいます。バージョン 2.8 にアップグレードし、リリース直後にドットやプラス記号を含むすべてのメールアドレスをブロックする予定です。以前の機能の実装が利用できればよかったのですが、この問題が対応され、解決策が提供されることに感謝しています。これは大きな違いになるでしょう。ありがとうございます
「いいね！」 1
少し考えてみたところ、理にかなった解決策が思いつきました。
管理者オプションとして、メールアドレスの正規化されたバージョンを処理・保存する機能を実装するのはどうでしょうか（ただし、ドメイン部分ではなく、ユーザー名部分のみを処理します。例：username@..）。
ただし、これは管理者が指定したドメインに対してのみ適用します。
具体的には、メールドメインの許可/ブロックリストに似た形式で、各ドメインに対して以下の2つのチェックボックスを設けます：
- プラス記号（+）と文字列の除去
- ピリオドの除去
そして、これらのレコードを参照し、そのメールアドレスの別バージョン（正規化されたもの）による追加登録を禁止します（ただし、元のメールアドレスレコードには影響を与えず、プラス記号やピリオドを含むまま登録可能です）。
こうすることで、どのドメインに対して正規化レコードを保存し、どのように正規化するかという負担を管理者のみに委ねることができます。これにより、問題となるメールドメインが発生した際に、管理者がそれに対応できるようになります。
とりあえず、このアイデアを共有しておきます。将来的に検討していただけると幸いです。
よろしくお願いいたします。
PR をマージしました。
これにより、新しいサイト設定 normalize emails が追加され、メールからドットと +… 部分を削除してから一意性をチェックします。たとえば、test+1@gmail.com ユーザーがいて、test+2@gmail.com がサインアップしようとした場合、サイト設定が有効になっていると許可されません。
「いいね！」 7
素晴らしい、これで @markersocial さんの問題は100%解決すると思います。この特定の攻撃の標的になった場合に有効にするのに最適な設定です。
@markersocial さん、結果を教えてください。
「いいね！」 4
実装していただき、本当にありがとうございます。これは大きな成果であり、追加されて大変嬉しいです。昨日から本番環境に適用し、監視しています。
今のところ、意図したとおりに100%機能しており、この問題を完全に解決しているようです。ピリオドを含むメールアドレス（おそらくプラス記号もですが、最近は見ていません）でも登録は可能ですが、同じGmailのバリエーションでアカウントを作成し続けることはできなくなりました。GitHubでの議論を読むと、元のメールアドレスをそのまま保持するのが最善の選択だったことは間違いありません。
それを踏まえて、複雑になりすぎずにこの機能を改善できると思われる提案を以下に示します。
normalize emails を有効/無効にするチェックボックスの代わりに、メールドメインブロックリストのような2つのリストを用意します。
- ピリオド正規化を適用するドメインリスト
- プラス記号正規化を適用するドメインリスト
例：
管理者が両方のドメイン正規化リストに gmail.com を追加します。
e.mai.l+123@gmail → email@gmail.com
ユーザーがプラス記号正規化リスト（のみ）に outlook.com を追加します。
us.er+123@outlook.com → us.er@outlook.com
us.er@email.com と user@email.com が同じアドレス/アカウントであることは、一部のプロバイダーに特有であり、実際には標準ではありません。一方、プラス記号は（それを許可するプロバイダーであれば）標準のようです。
これにより、管理者はこれらの正規化（両方のタイプ）をすべてのメールドメインに適用するのではなく、問題が発生したメールドメインに個別に選択的にルールを適用できるようになります。
上記の提案については特に期待していませんが、役立つようであれば提案として残しておきます。
いずれにしても、重ねて感謝いたします。この機能が実装されたことに本当に感謝しています。これはゲームチェンジャーです。
「いいね！」 2
しかし、これが理論上の問題なのか、現実世界の問題なのか疑問に思います。忠実性への欲求は理解できますが、これが問題を引き起こしている具体的な事例をいくつか聞きたいです。
このような設定を導入する際の難点は、サイトの許可リストを変更した際に正規化ルールを再適用することになり、非常に複雑な変更になることです。
現在、条件なしで正規化を行っています（サイトの設定に関係なく）。そのため、オンにするのは瞬時で、すべての履歴に適用されます。
素晴らしいです 
すべては@nbiancaのおかげです。
「いいね！」 4
素晴らしい！それが遡及的に適用されるとは知りませんでした。正規化された住所は新しい登録に対してのみ保存されると思っていました。
はい、問題が発生する主な可能性は、+エイリアスを許可するものの、異なる配置のピリオドを同じとは見なさないメールアドレスの場合です。
知る限り、+エイリアスは許可するすべてのプロバイダーで同じように処理されるため、メール内の+のすべてのインスタンスは問題なく同じように処理できます。ピリオドは、プロバイダー間でいくつかの違いがある唯一のものです。
記憶が正しければ、Googleの仕事用メール（カスタムドメインを使用）、Yandex、Outlookは、異なるピリオド配置を異なるアドレスと見なしますが、+エイリアスは引き続き使用できると思います。
したがって、唯一のケースは、「theirs@email.com」が存在する場合、「the.irs@email.com」が登録できなくなる（実際には、そのメールドメイン/プロバイダーによると、これらは2つのユニークなアカウント/アドレスである）ということになります。これは現実世界では非常にまれに発生する可能性があります。
「いいね！」 2
このトピックは16時間後に自動的に閉じられました。返信はもうできません。