我不确定，@sam，我觉得我们更需要一个用于用户注册的 CAPTCHA 插件？我认为“禁止使用点号和加号”并没有解决根本问题，只是在处理症状而已？
从历史趋势来看，垃圾邮件发送者越来越趋向于完全由真人操作。我的意思是，他们会填写用户资料、上传头像，一应俱全。除了 bamwar 之外，自动化垃圾邮件在 Discourse 中并未构成太大问题，因为作为一个完全基于 JavaScript 的应用程序，Discourse 很难被自动化脚本攻击。请注意，你大部分的评论 @neounix 都属于我上一句所描述的情况——与我们相比，1999 年时代的 HTML 1.0 网站要简单得多，因此对我们进行脚本化攻击非常困难。将难度门槛提得如此之高，根据我们观察到的客户案例以及 meta 社区的情况，已经消除了大部分问题。
总之，TL;DR：我并非完全反对设置一个简单的“禁止在邮箱中使用特定字符”的选项，但就我而言，我认为除了 CAPTCHA 之外，其他方法可能都难以在此情况下起到多大作用？我们是否可以两者兼用？
但是一些用户（包括我）在邮件客户端中使用 + 来实际排序邮件。
别担心，这默认不会开启，而是通过站点设置实现的“攻击锁定”模式。
@neounix 传奇人物。感谢你的建议，非常感激——你让我踏上了一场打击垃圾邮件的旅程。我暂时将 Cloudflare 设置为“我受到攻击”模式（这阻止了他们的注册——他们每隔 1-2 分钟就会创建一个新账户），并检查了 Cloudflare 防火墙日志中他们使用的一些 IP，发现该模式对每位访客都进行了挑战或记录。他们确实使用了完全相同的用户代理（useragent）。
我添加了一条防火墙规则，针对使用该用户代理的访客进行挑战，并在 Cloudflare 上禁用了“我受到攻击”模式。我相信因此受到挑战的无辜用户并不多，而且它完全阻止了他们的垃圾邮件注册。
随后，我发现了 Cloudflare 的 AS 编号（ASN）屏蔽功能，并参考用户代理屏蔽日志，设置了额外的防火墙规则以屏蔽大量相关 ASN。我知道这肯定有绕过方法，但这无疑增加了他们的资源成本和操作难度。
@codinghorror 我同意你的观点，验证码确实会有所帮助。我认为一个良好的垃圾邮件预防首要目标应该是提高垃圾邮件发送者的整体资源成本。
验证码有助于实现这一目标。使用验证码破解 API（例如 https://anti-captcha.com），每破解 1000 个 reCAPTCHA 大约需要花费 2 美元左右，此外他们的机器人还需要额外的复杂配置。
顺便提一下：Anti-captcha 提供了一款浏览器插件，可自动解决你的验证码，效果很好，用起来也很方便有趣。
电子邮件地址通常是批量创建账户的另一个资源成本。但情况并非总是如此，因为单个用户可以用一个 Gmail 地址创建 virtually 无限数量的账户。创建 1000 个 Gmail 账户的成本相当高，所以他们往往会转向其他限制较少的提供商或使用通配符域名。但这仍然会消耗他们的资源，并且更容易被识别为垃圾邮件。
我认为这确实是一个“越多越好”的情况。单一防御手段都不够强大，但增加垃圾邮件发送者所需的资源和努力，无疑是正确的方向。最好的情况是，垃圾邮件发送者攻击 Discourse 论坛所付出的努力，超过管理员进行屏蔽和批量删除已漏网垃圾邮件所需的工作量。
@itsbhanusharma 我真的很喜欢能够使用 + 号，但这就是为什么我们不能拥有美好的事物，哈哈。不过，如果为了对抗垃圾邮件需要的话，提供禁用它的选项会很不错。
经过思考，我倾向于同意你的看法……@sam，我们能否将这项邮件锁定设置优先安排在下一周处理？
这个问题在上述讨论中已经多次提及，就在这个帖子中。
“禁止”使用点和加号可能会引发一些问题（至少对某些用户而言）。原本的设想是存储电子邮件的“规范”版本（即“清理后”的版本），并禁止注册具有相同规范版本的新用户，以应对 Gmail 的“技巧”（实际上就是同一个邮箱地址）。
这可能就是 Sam 所说的内容：
也许这也是你所指的意思 @codinghorror，而不是真正“禁止”使用 . 和 +。
但我同意你的观点，这种方法只能“解决”Gmail 相关的问题（例如无法应对使用“通配邮箱”的域名等情况）。
当你自己都说：
那么，验证码真的能解决什么问题吗？
听起来我们似乎漏掉了一步。
强制使用规范邮箱确实存在问题，但默认情况下阻止一个规范邮箱关联多个账户则相当合理。
我们大多数人如果需要一个测试账户，都会有多个邮箱地址。如果这是默认设置，就不会在那里造成显著问题，而且我们也不必在滥用行为发生后再去教育用户开启该功能。
我认为，电子邮件中的加号（+）在所有电子邮件域名中基本上可以同样处理，不会有什么大问题。
对于像 sp.a.mmer.king@gmail.com 或 s.pa.mmerking@gmail.com 这样的邮箱，在 Gmail 的情况下，它们被视为同一个邮箱。但对于某些其他服务提供商，情况可能并非如此，这两个邮箱可能对应不同的用户。
–
我认为，从长远来看，一个良好的实现方式可以参考“电子邮件域名黑名单”功能。
允许添加自定义域名，以禁止利用重复注册的技巧。然后，可以单独启用或禁用对这两种重复注册方式的拦截。也就是说，分别提供“禁止使用加号（+）技巧的重复邮箱”和“禁止使用点号（.）技巧的重复邮箱”的选项。
系统应以原样存储注册的邮箱（包括用户的登录名和用于发送电子邮件的地址），但阻止被判定为相同邮箱的额外注册。
另一个能稍微提升效果的方案是，将多个域名归入同一个自定义域名记录中，使它们被视为同一域名。例如：gmail.com 和 googlemail.com。这样，如果有人尝试分别使用 example@gmail.com 和 example@googlemail.com 注册两次，系统可以将其拦截。还有一些其他服务提供商也拥有多个可互换的域名，我已将部分示例发送给 Sam。这可以进一步增强防护，但总体而言，主要可被利用的问题仍是加号和点号技巧导致的重复注册。
–
另一种可能更简单的实现方式是：如上所述，但针对每个自定义邮箱域名的两个选项改为：禁止所有包含加号（+）或点号（.）的注册。如果用户使用该域名并通过加号或点号进行注册，则返回错误提示，要求其移除邮箱中的点号和/或加号（甚至可以自动为其处理），然后重新尝试。这种方式虽不完美，但仍然非常有效。
没错，这就是为什么我们需要将其提炼为规范邮箱以确保唯一性。上文已对此进行了说明。不过，我们不能将规范邮箱存储为用户的邮箱地址，因为那并非他们实际提供的地址。
域名黑名单功能已经存在，但我们不能仅仅因为某个用户也可以通过 googlemail 或 gmail 地址联系到，就拒绝其中一个或另一个。因此，我们需要回溯到规范的“主”邮箱。
目前有些网站的用户确实合法地使用加号地址和点号地址。我们的目的并非给这些合法做法带来不便，而只是为了遏制不合理的副作用，例如一个规范邮箱对应两个用户的情况。
如果在注册过程中（在客户端获得同意后，类似于表单验证）要求提供已去除句号和加号字符串的邮箱，那么将其存储为账户邮箱是可以接受的。
这并非理想或完美的方案，但在某些情况下，如果选择是在让少数用户感到不便还是让整个论坛遭受垃圾邮件骚扰之间做权衡，这可能是一个更简单且值得的折衷方案。
有些 Gmail 账户的规范主邮箱本身就包含句号。这些用户会在注册期间因强制移除句号而感到最受影响和困惑。
我认为这也不是最佳的实现方式，并且绝对不适合作为默认选项。
没错，我的意思是提供一个选项菜单，类似于现有的邮箱域名黑名单，用于输入哪些邮箱域名应受影响，以及用于决定邮箱地址是否唯一/规范的参数（正如本线程中所讨论的）。可能还包括哪些域名应被视为同一主机，例如 gmail 和 googlemail。
关于 gmail 和 googlemail，我想我们已达成一致。关于句点和加号也是如此。
本质上，允许首次注册通过，但禁止用户使用同一邮箱创建多个账户。或者至少在合理范围内将其最小化。
john@googlemail.com 先注册 → 接受
john@gmail.com 后注册 → 拒绝
matthew+{randomstring}@gmail.com 先注册 → 接受
matthew@gmail.com 后注册 → 拒绝
matthew@googlemail.com 后注册 → 拒绝
m.att.he.w@gmail.com 后注册 → 拒绝
matthew+{randomstring}@gmail.com 后注册 → 拒绝
m.a.tt.ew+{randomstring}@googlemail.com 后注册 → 拒绝
googlemail 与 gmail（以及其他拥有多个备用域名的提供商）之间的差异，远不如句点和加号地址问题显著。不过，处理这些情况仍然是件好事。
这是一个非常不友好的用户变更，而且完全没必要。这些功能之所以存在，本意就是为了识别邮件来源。如果我使用 stephen+meta@gmail.com 注册，我可以配置一条规则，将所有发送至该地址的邮件打上标签。如果 Meta 被入侵，导致我的该别名邮箱收到垃圾邮件，我就能立刻知道泄露源头。破坏我使用邮件的方式并非解决方案；将我的邮箱地址提炼为规范版本进行比较，既能达到相同效果，又不会给用户带来任何不便。
没错，这与“规范地址”的概念紧密相关。如果该功能按最初讨论的方案实施，我们将能够受益于域名关联功能。所有的点号、加号排列以及域名变体都将被与那个邮箱的“唯一真实邮箱”进行比对，而不会造成任何摩擦。
只要我们不给用户带来任何困扰，就没有理由不默认启用此功能。
同意，不完美的方案就是不完美。我提出这一点，只是作为一种可能更易于实施的替代方案。这其实是我帖子最后部分的内容，作为对我主要建议的替代方案。我的主要建议赞同本线程中的许多讨论，即允许使用加号（+）和点号（.），但不允许重复注册账户。
话虽如此，根据我的观察，在非技术类论坛或网站上，合法用户使用加号（+）的情况通常属于边缘案例。
听起来非常棒。
我发帖的主要意图是探讨如何为不同的电子邮件域计算标准地址。因此，这并不局限于仅适用于 Gmail/Googlemail。我 essentially 想表达的是，长期来看，提供让用户按域名自定义标准地址计算方式的选项，将是一个很好的实施方案。
例如，有些其他服务提供商允许使用加号（+），但不允许使用点号排列组合，这意味着点号排列组合被视为不同的唯一邮件。
不过，仅针对 Gmail/Googlemail 的实现方案也非常棒，而且我也看不出有任何理由不能默认开启它。
您能举一个例子吗？我之所以这么问，是因为大多数 Gmail 用户根本不知道“点号技巧”。他们注册时使用的是带点号的邮箱地址，并将这个版本提供给所有人；如果被告知“他们的邮箱”无效，他们会感到非常困惑。
我很少遇到有人意识到去掉点号的别名仍然可以收到邮件。
好的，我现在会把一个例子私信发给你，这是我发给 Sam 的。我只是不确定是否适合在这样一个标题的帖子中公开发布，因为看起来幸运的是，还有不少垃圾信息发送者对此尚不知情。
是的，同意，对于普通用户来说，这个不完美的解决方案可能会引起主要的困惑。
我们绝不会采用如此复杂的方案。我们不会去“规范化”电子邮件地址。
要么你处于电子邮件锁定模式，该模式完全禁止电子邮件地址中的某些 problematic 字符（根据硬编码的电子邮件域名，也许），要么你就不是。
仅此而已。布尔开关：启用电子邮件锁定模式，是/否？
参考：
此修复现已完成。
使用站点设置 enforce_canonical_emails（默认为 false）来启用此保护。
启用后，我们将禁止利用 googlemail.com 和 gmail.com 中的 . 技巧以及全局范围内的 + 技巧进行重复注册。
该修复非常安全，在默认禁用的情况下，开箱即用且无任何影响。
实现的一个副作用是，一旦启用该设置，可能会有一个额外的重复账户被漏掉，因为除非启用该设置，否则我们不会在用户邮箱表中存储规范化格式的邮箱。在我看来这完全可以接受，因为在我们托管的众多站点中，我通常无法找到此类确切滥用案例。
无论如何存储规范形式都有问题。它们采用什么格式？
规范在此：
如果未启用站点设置，则不会发生任何操作……零，什么都没有。
感谢你的美言，@markersocial
抱歉没能早些回复，最近一直在忙于其他任务……刚刚才赶上处理元数据相关事务：
检测垃圾邮件、虚假注册、DDoS 攻击、入侵行为，以及整体的网络空间态势感知，以及其他各类以检测为导向、涉及多传感器数据融合的网络安全问题，一直是我最热衷的话题之一，看来你也有所了解 
由于我曾身处一线，实时参与过多次“实战”网络攻防，在此再给你两个建议，当你遭遇此类攻击时：
(1) 检测往往更像一门艺术，而非纯粹的科學。原因在于，攻击者对你检测和缓解算法及技术了解得越多，他们就越会变异和适应你的防御措施。
(2) 同时，永远不要忘记“OODA 循环”。观察 - 定向 - 决策 - 行动在网络战中，能够进入对手 OODA 循环的一方，通常会是胜利者。
很高兴看到你对网络防御充满热情，并着眼于更大的图景。听起来你已经掌控了全局（从我快速浏览的讨论摘要来看），而且 Meta 团队也为你做出了有益的调整。
如果你再次遭受攻击并需要帮助，请随时联系我。我已长期退休，不再追逐利润或充实金库（谢天谢地！），因此咨询我完全免费。帮助他人解决有趣的技术问题，尤其是在网络安全和网络战领域，对我来说比积累财富更为重要。
如果你需要有人交流想法，我随时在这里。从我最近读到的你的回复来看，听起来你已掌控了局面。
做得好！
@codinghorror 我的想法是，这个改动毫无意义，我应该直接撤销我的更改。
我们托管的所有站点都没有要求启用它，也没有要求极端的邮件拦截模式。实际上这根本不是问题，因为我们本身就会清理不活跃账户，并对用户资料进行垃圾邮件扫描。
垃圾邮件发送者完全可以搭建自己的 SMTP 服务器，这比自动化操作 Gmail 更容易，而且他们还能借此获得无限的邮箱地址。
此外，地址变体（addressing）在合法场景中也被广泛使用。
关于 Gmail 中点号（dots）引发问题的最常见情况并非垃圾邮件，而是邮件地址输入错误。
我想，我唯一支持在核心代码中进行的改动，是将被拦截的邮箱扩展为同时拦截其规范形式（canonical form）。至少这能改进“拦截邮箱”功能，并解决原帖（OP）提出的问题。
例如，如果你拦截了 Jane@gmail.com，那么 j.ane+1@gmail.com 也会被拦截。
其他任何改动都可以通过插件实现。
这样听起来可以吗？