既然一个简单的邮箱地址锁定模式既易于实现又便于理解，何必在此引入复杂的依赖呢？而且现在这还让我们面临新的漏洞风险？不必了！
考虑到此类投诉极为罕见，且情况特殊，我认为采用简单且更为严格的方案是更优选择。
采用简单方案（即禁止除 /a-zA-Z0-9/ 以外的任何字符）虽然可行，但会带来严重的可用性问题：大量用户将不知道如何注册，我们还需要新增错误提示。许多使用 Gmail 的用户并不知道 janedoe@gmail.com 可以作为他们的邮箱，因为他们一直以为 jane.doe@gmail.com 才是正确的邮箱。这种限制还会影响 OAuth，导致使用 Gmail 登录失败，无法正常工作。
邮箱地址：
sam.s@gmail.com
错误：邮箱地址中不允许使用.（新增错误提示）
进行规范化处理对用户更友好，且无需新增用户体验设计。
我们可以从一个更简单的可选规范化器开始（去除标签、为 Gmail 去除点号）。
不过，需要明确的是，我并不建议在此处引入依赖，email_address 存在缺陷，不适合我们当前的需求。
在此问题上仓促采取折中方案，只会导致出现一个“在我的网站上破坏邮箱功能”的站点设置选项，而我并不倾向于添加这样的设置。
1 个赞
没错，但他的网站正遭受围攻。每天都有成千上万个这样的重复账户注册。因此，为那些与摩萨德交战且处境艰难的网站提供一种简单的邮箱封锁模式，是合乎情理的。
战争需要牺牲，难免会有平民伤亡。他的网站已经彻底瘫痪。
1 个赞
理想情况下，你需要一个电子邮件提供商的表格，说明如何根据每个提供商“清理”（即你实际引用的内容）。正如 Bart 很好地解释的那样，问题不在于因为某些字符而禁止使用任何电子邮件地址，而在于能够检测哪些地址实际上是相同的。
当然，真正想这么做的垃圾邮件发送者总能做到。这就像警报/锁和窃贼一样：目的是增加难度。
创建多个 Gmail 地址本身就是对 Gmail 的垃圾邮件行为，这是他们自己需要解决的问题（即使这些地址之后可能被用来向你发送垃圾邮件）。
1 个赞
我不太明白。
如果我们将 bob.test+100@gmail.com 在内部视为 bobtest@gmail.com，并在开关开启时以这种方式存储，那么这里究竟做出了什么“牺牲”？
这个 bug 是专门针对 gmail 的，因此在我看来，因为 Google 决定制定规范并进行标准化，就禁止所有地方使用点号，这反应过度了。清理逻辑实际上非常直接，而且这个功能默认是关闭的，可选开启。
@Mevo，为了 100% 明确，Jeff 在这里的提议是：我们添加一种“灾难模式”。在该模式下，bob.test@gmail.com 将被视为无效邮箱，无法使用。
3 个赞
我建议与简化形式进行比较，但你需要小心，确保仍然存储并向用户最初指定的地址转发邮件。
你并未获得用户同意去联系任何其他变体地址，使用他们未指定的地址可能会导致他们无法收到邮件。
举个例子，我有一个 Gmail 地址，是在该服务开通的头几个月创建的。发往基础别名（base alias）的邮件实际上会被丢弃。只有发往特定“加号地址”（plus addresses）的邮件才会被看到。
也要小心假设——许多 Gmail 用户根本不知道点号（.）是可选的。绝大多数人甚至从未听说过“加号地址”功能。如果为了防止滥用后者而进行筛选，可能会误伤前者。
4 个赞
@sam 我完全理解 Jeff 的意思，和你一样，我反对他的提议（无意冒犯他，观点不同很正常）。
这可能有点吹毛求疵，但如果只存储“清理后”的邮箱地址，就会剥夺一些合法用户特意采用的做法。例如：用户（完全合法且仅一次）使用 bob+meta@example.com 或 bob+forums@example.com 注册时，会失去他原本想要实现的功能。问题在于，他最终只能在 bob@example.com 接收邮件，而这并非他所期望的（例如，他原本希望利用“标签”将收到的邮件归类到特定文件夹）。
我完全明白，考虑这一点会让实现变得稍微复杂一些。你需要同时存储用户输入的原始版本（用于发送邮件）和清理后的版本。你可以像现在使用邮箱地址那样使用清理后的版本（用于所有与用户相关的内部操作，以及检查该用户是否已注册）。此外，为了避免上述小问题，你还需要额外存储用户输入的原始地址（仅用于发送邮件）。这相当于电子邮件中的“回复地址”（Reply-To）。
希望这能表达清楚。
编辑：与 @Stephen 几乎同时撰写（整体思路相同）
2 个赞
这是一个非常好的观点，这确实让构建工作变得稍微复杂了一些。
我想你只需要在“创建新账户”时进行检查：
系统中是否已存在与该规范形式相同的电子邮件地址？如果是，很抱歉，无法为你创建新账户。
还有一个附带问题是 Google OAuth（它是否也会检查规范邮箱），以及从非规范邮箱到规范邮箱的过渡问题。
据我所知，OAuth 不支持加号地址（plus addressing），所以这是否属于范围之外？
我的意思是，我无法使用 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 我完全理解。
（顺便一提，我第一次看到这种情况。你的帖子被自动编辑了：“[系统] — 自动移除了整个前一条帖子的引用”。哇！这个功能太棒了！）
您需要格外小心，切勿存储规范版本。用户并未同意提供该信息，一旦您的用户表遭到泄露，他们将难以确定是哪家服务导致其数据泄露。
Facebook 因存储用户未提供且未同意与其账户关联的个人身份信息（PII）而多次陷入严重困境。
4 个赞
就我个人而言，我认为这个设置完全没问题。我只是因为“曾经有一个人遇到过一次问题”而不愿去做。
是的，建议将这种糟糕的功能添加到 Discourse 中是完全错误的。我会强烈反对添加它。此外，地址处理是一项功能，一直以来都是，并且对用户友好。
如果你正遭受摩萨德的攻击……那就启用“摩萨德攻击模式”吧。我想我们只需要摩萨德去攻击更多的人？
我坚决反对在 Discourse 中添加这个设置。如果有人想为此开发一个插件，我完全没问题，毕竟在插件里只需要几行代码。如果你一定要用这个功能，我可以暂停手头的工作，今天就去开发这个插件，请随时告诉我。
不过，开发这个功能其实有点多余，因为那个遇到问题的人已经明确表示不会使用它了。
设置一个“搞坏我的 Discourse”的选项从根本上来说就是不好的，依我看，它不应该出现在产品中。
我认为，如果有更多人遇到这个问题，实施邮件锁定模式会更有说服力。但目前只是那个网站上的那一个人遇到了问题。
所以我们还是静观其变吧…
1 个赞
更准确的说法是：
一个人，一个网站，且他并不会使用这个功能。