问题是，强制使用规范邮箱实际上效果相同，但对用户的敌意要小得多。
不允许 Sam.sam@gmail.com，因为 Sa.msam+123@gmail.com 已经注册。
无论如何，我们可以在下一个版本中加入正则表达式处理。
2 个赞
是的，但在实际应用中这毫无用处，这也是我们之所以展开这场讨论的原因——一旦他们拥有了核武器，你也必须拥有核武器。
“用户不友好”这一概念，当你的受众拥有核武器并愿意使用时，便毫无意义。
我不同意这种说法，该解决方案对 @markersocial 完全有效。后来我回退了更改，是因为我被迫这么做。
我实施并随后回退的标准化方法不存在任何已知漏洞，它能 100% 解决上述 Gmail 问题。
3 个赞
好吧，我不同意，因为这将代码和精力的负担放在了我们要这一方，而不是对方。“规范化”电子邮件非常复杂，因邮件提供商而异，我不想涉足这个领域。
换句话说，让他们自己构建和处理核装置；我们不需要向每个国家、向每个 Discourse 安装实例都分发“原型核弹”，仅仅为了“以防万一”。
（此外，能够通过正则表达式屏蔽电子邮件列表功能非常强大，尤其是在 Discourse 中电子邮件即身份的情况下。）
1 个赞
我们可以让他们使用自己的正则表达式规则进行规范化，作为一种折中方案，这样我们就不必涉足规范化工作。
尽管如此，是的，下一个版本将实施正则表达式屏蔽，或者至少会实施通配符屏蔽。
6 个赞
我可以确认，之前的实现完美运行，彻底解决了 Gmail 问题。电子邮件域名白名单和黑名单都是非常有效的“核武器”。但直接屏蔽 Gmail 并不可行。
@codinghorror 我理解反对为不同邮件提供商进行标准化处理的观点。但我认为，至少以非破坏性的方式支持 Gmail（据称 2020 年占全球邮箱地址的约 43%，在美国这一比例为 53%）是合理的。这或许可以与开箱即用支持大型提供商的 OAuth 相提并论。
@sam ^ 这是一个很好的替代方案。
也许结合 Gmail/googlemail 匹配的示例，这种方式既用户友好又功能强大。
2 个赞
目前有一位用户利用单个 Gmail 地址（通过添加点号）注册了数千个账户，并 spam 推广其竞争网站以分流用户。我们计划在 2.8 版本发布后升级，并屏蔽所有包含点号或加号的邮箱地址。虽然希望能有之前的实现方案，但很高兴看到该问题正在被解决，并且即将提供解决方案。这将会带来巨大的改变，谢谢
1 个赞
我仔细思考了一下，想到了一个或许可行的解决方案。
可以添加一个管理员选项，用于处理和存储电子邮件的规范化版本（仅处理用户名部分，即 username@..）。
但此功能仅适用于由管理员指定的域名。
类似于电子邮件域名允许/阻止列表，每个域名可设置两个复选框：
- 移除加号及后续字符串
- 移除点号
然后，将这些记录作为参考，禁止使用同一邮箱的其他变体进行额外注册（但不影响主邮箱记录，主记录仍可包含加号和点号）。
这样一来，选择对哪些域名存储规范化记录以及如何规范化的工作将完全由管理员承担，使他们能够针对新出现的 problematic 邮箱域名及时做出响应。
总之，只是把这点想法提出来，供日后参考。
祝好。
我已合并 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 小时后自动关闭。不再允许回复。