The thing is forcing canonical emails is effectively the same except that it is far less user hostile.
No Sam.sam@gmail.com is allowed Sa.msam+123@gmail.com is already registered
Anyway we can do regex next release
「いいね！」 2
Yeah, but it’s useless in actual practice, which is why we’re having this discussion… once they have nukes, you need nukes too.
“User hostile” is a meaningless concept once your audience has nukes and is willing to use them.
I disagree with this, the solution worked perfectly for @markersocial, and then I reverted the change cause my hand was forced
There are no known gaps with the canonicalization approach I implemented and reverted, it solves the above gmail problem 100%
「いいね！」 3
Well, I disagree, because that put the code and effort burden on our side, rather than their side. “Normalizing” emails is quite complicated, varies per email provider, and I don’t want to be in that business.
In other words, let them build and handle the nuclear devices on their own; we don’t need to ship proto-nukes to every country and in every installation of Discourse “just in case”.
(Plus being able to blocklist emails via regex is quite powerful, especially since email = identity in Discourse.)
「いいね！」 1
We could let them normalise with their own regex rules as some sort of middle ground, then we are not in the business of normalisation
That said yes regex blocking or at least wildcard blocking will happen for the next release
「いいね！」 6
I can confirm that the previous implementation worked perfectly and entirely solved the gmail issue. The email domain allow list and disallow list both are quite effective nukes. But it’s just not viable to block gmail.
@codinghorror I can see the point of view against normalising for different email providers. But I think it would make sense to be able to cover at least gmail (~43% of all email addresses apparently in 2020, 53% for the US) in a non-destructive way. It might be comparable to supporting oauth from large providers out of the box.
@sam ^ This is a great idea for an alternative. 
Maybe this, with an example for the gmail/googlemail match could be quite user friendly and powerful.
「いいね！」 2
Have a user right now that has made several thousand accounts with a single gmail address (using periods) and spamming promoting their competing site to siphon off users. Will be upgrading to 2.8 and blocking all emails that contain a period or plus symbol as soon as it’s released. I do wish the previous implementation was available, but appreciate that this is being addressed and a solution will be available. It’s going to make a massive difference, thank you 
「いいね！」 1
So have thought about this a bit and thought of a solution that could maybe make sense.
There could be an admin option to process and store a normalised version of the email (only processing the username part i.e. username@…)
But only apply this for domains that are specified by the admin.
So a list somewhat like the email domain allow/block lists, with two checkboxes per domain:
- Strip + string
- Strip periods
Then use these records as a reference for disallowing additional registrations using alternative versions of that email (without affecting the primary email record, which can still have + and periods).
This way, the burden of selecting which domains to store a normalise record for and how to normalise them can be on the admin only, allowing them to respond to problematic email domains as they emerge.
Anyhow, just dropping this here so it can perhaps be considered at some point.
Cheers.
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時間後に自動的に閉じられました。返信はもうできません。