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 个赞
太棒了，我认为这100%解决了@markersocial的问题，并且如果你最终成为此次特定攻击的目标，这是一个很好的设置。
请让我们知道你的进展@markersocial
4 个赞
非常感谢您实施此功能，这是一个巨大的胜利——我很高兴它已被添加。我昨天已上线并正在监控。
到目前为止，它似乎 100% 按预期工作，并完全解决了这个问题。人们仍然可以使用包含句点的电子邮件进行注册（并且可能还有加号，我最近没有看到这些注册）。但无法再创建同一 Gmail 变体的账户。从阅读 GitHub 上的讨论来看，将原始电子邮件保持原样绝对是最佳选择。
因此，话虽如此，我将在此留下我认为可以改进此功能但又不会过于复杂的建议：
与其使用复选框来启用/禁用 normalize emails，不如使用两个列表，类似于电子邮件域名阻止列表样式。
- 应用句点规范化的域名列表
- 应用加号规范化的域名列表
例如：
管理员将 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 个赞
此主题在 16 小时后自动关闭。不再允许回复。