如果能有一种方式添加通配符屏蔽的电子邮件地址就好了。例如，当垃圾邮件发送者使用 Gmail 的“点号技巧”时：
例如：
example@gmail.com
example+random12345@gmail.com
ex.a.mple+random12345@gmail.com
e.xamp.le@gmail.com
这些都是同一个电子邮件地址，垃圾邮件发送者可以轻松地利用一个 Gmail 地址创建无限多个账户。
我相信，像下面这样使用通配符屏蔽地址会是一个很好的解决方案：
e*x*a*m*p*l*e*@gmail.com
我并不认为所有使用这些 Gmail 地址变体的注册都应该被屏蔽，只是觉得如果某个 Gmail 地址被屏蔽，其所有变体也应一并被屏蔽；或者我们可以手动将一个带通配符的 Gmail 地址添加到电子邮件黑名单中，这样会很有用。
您遇到的是一个具体的实际问题，还是仅仅是一种推测？如果是具体问题，能否提供具体的垃圾邮件发件人邮箱？
是的，这确实是我正在经历的实际问题。垃圾邮件发送者经常利用 Gmail 的“点号法”（dot method），配合充足的 IP 地址池，通过单个 Gmail 账户批量注册数万个账户。
我目前只观察到“点号法”被使用，尚不完全确定“加号法”（+ method）是否同样有效。据我上次检查，使用包含“+”字符的邮箱地址进行注册是可行的，因此该技巧应该也适用。
例如，这个邮箱（并非真实邮箱）：
constantinehamilton1337x@gmail.com
仅通过“点号法”即可生成 16,777,216 个唯一的邮箱地址，而通过“加号法”则几乎可以生成无限多个。这使得垃圾邮件发送者能够极其高效地操作。由于涉及的是 Gmail 域名，直接列入域名黑名单并不现实。
你可以在此处查看一个生成器（超过 8000 种组合时会变得卡顿）：Redirecting...
如果这真的是通过通配符式的方法（而不是由 Discourse 自动处理）实现的，那么你可能需要比 e*x*a*m*p*l*e*@gmail.com 更加具体。采用这种方式可能会导致误封无辜用户，尤其是当垃圾邮件发送者的邮箱地址相对较短时。专门针对 . 和 + 进行匹配可能会安全得多。
你的 levenshtein_distance_spammer_emails 设置是多少？是默认值 2 还是最大值 3？
感谢提醒这个关于 levenshtein_distance_spammer_emails 的设置。我之前从未见过或修改过它——它默认值为 2。
我不理解你的数学逻辑。你只能在字符之间添加一个点，因此每个 N 字符的地址仅适用于 2n 个地址。你或许可以开发一个插件，在移除点后保存或比对地址，并禁止使用带加号的地址。
@pfaffman - 我刚才只是根据 Redirecting... 提供的数据得出的结论，该数据显示每增加一个字符（超过 2 个字符的部分），地址数量就会翻倍（不过大约在 8k 时会冻结）。
我认为如果是 2*n（如果我理解正确的话，意思是 26 个字符的地址会有 52 种组合？），这个数值太低了。因为用户可以在地址中插入多个点号。
例如：
constantinehamilton1337x@gmail.com
con.stantinehamilton1337.x@gmail.com
co.nst.antineh.amilton1.3.37x@gmail.com
constantineh.a.m.ilto.n13.37x@gmail.com
c.o.nsta.ntinehamil.ton1337x@gmail.com
不管怎样，无论确切数字是多少，数量都非常庞大。是的，你提出的解决方案很有道理！
是啊，我之前的计算有误，只允许了一个点。我本来记得这个数学规则的，但今天早上给忘了。
不过，如果一个插件能保存一次截图，并将免费版本的地址作为额外地址保存，就能满足你的需求，而且实现起来也不算太难。
注意……当您屏蔽 sam.sam@gmail.com 时，我们现在会自动屏蔽 sam.sam+1@gmail.com 等地址。
这个功能运行得非常顺利 @sam 
我认为你之前实现的 方案 仍然可以作为一个额外的反垃圾邮件功能发挥很大作用。在它短暂可用且启用（默认关闭）的期间，效果非常出色。
否则，垃圾邮件发送者仍然可以在版主或管理员发现之前，利用一个 Gmail 地址批量创建账户。例如，创建账户但不立即发布任何内容。
管理员/版主将需要手动查找并打开每个单独账户进行封禁或删除。这可能相当繁琐，尤其是当一名垃圾邮件发送者可以在被封禁之前用一个 Gmail 地址创建数百甚至数千个账户时。此外，搜索这些邮箱也很困难，例如 j.ohan.2.1@gmail 和 jo.ha.n21@gmail。
如果这些账户没有被手动排查出来，垃圾邮件发送者就能保留大量账户池来玩“打地鼠”游戏，而只需要消耗一个 Gmail 账户即可获得这些账户。
@sam 在进行了更多实地测试后，我认为之前被回退的实现方案对于应对有动机的垃圾信息发送者确实更为有效。我仍然收到大量利用这些 Gmail 变体技巧的注册请求。
我非常感激当前实施的防护机制，它非常有效。然而，我认为允许使用同一邮箱创建无限数量的账户（直到被特别发现并手动封禁）是一个漏洞。这给版主带来了更大的负担（据我所知，版主默认无法查看账户邮箱，除非启用该功能），尤其是在缺乏批量账户删除工具的情况下（例如：从账户/搜索列表中使用复选框选择多个账户并批量封禁/删除）。这意味着版主必须手动逐个访问每个账户进行删除或封禁操作。当需要搜索使用变体邮箱的账户时，这种情况尤为困难。
既然之前的实现方案是可选的（默认关闭），且已经开发完成并按预期运行，随后却被移除。对于希望利用它来增强针对有动机垃圾信息发送者的反垃圾保护社区来说，它不再可用，这实在令人遗憾。
这就是为什么我说某些字符必须（可选地）完全禁止出现在电子邮件地址中。具体来说，是那些允许子地址功能的字符，例如加号、点号、连字符等。使用正则表达式，你还可以按服务进行拦截，例如“不允许使用以 @gmail.com 结尾且包含加号的电子邮件”。cc @sam
之前的实现仍然允许使用 +addressing，同时保持每个账户仅保留一个规范地址（我认为这可能更安全）。
因此，你可以注册为 sam+discourse-meta@gmail.com，这对于你设置的 Gmail 内部规则非常方便。但随后系统会禁止从 sam@gmail.com 或 sam+1@gmail.com 注册新账户。
我并不反对添加白名单，但我觉得强制使用规范地址对于 Gmail 场景非常有用，而且作为一个默认设置也并无不妥。
安全并非这里的主要目标。由于该网站面临的问题范围较大，需要更极端的解决方案。只要它是可选的（即允许用户自定义“邮箱保护正则表达式”），那么在我看来，对于需要它的网站来说，这完全安全；这些网站可以选择启用“完全锁定模式”。
我们目前拥有：
被阻止的邮箱域名
我想我们可以添加：
被阻止的邮箱模式
不过，考虑到所需的各种转义，正确编写正则表达式有些令人烦恼。我担心提供此类选项，因为用户正确且按预期编写正则表达式的几率相当低。他们需要记得转义点号和加号。
.*\\+.*@gmail\\.com
我想我们也可以采用一种非基于正则表达式的简化模式，仅扩展 * 和 ?。
*+*@gmail.com
抱歉回复晚了！
如果将之前的实现作为选项重新添加，我相信这将彻底解决 Gmail 的问题。至少在我的情况下是这样。在我看来，这非常完美，并且为垃圾邮件发送者增加了足够的资源成本，使得应对工作变得可控。这确实是有需要全天候高强度审核与不需要之间的区别。
我已经封锁了几个允许类似操作并利用“允许邮箱域名列表”的域名。问题在于，人们可以在某个账户被禁止/封锁之前创建大量账户（这会激活对该 Gmail 地址变体的新账户封锁，但现有账户不受影响）。这使得审核工作变得相当繁重，并且事后逐个清理每个账户也很繁琐。
例如，我曾遇到一个帖子，其中有大约 200 条回复，每条回复来自一个不同的账户，但都使用同一个 Gmail 地址。类似的情况还有很多。这些是容易发现的例子，因为通过原始 Gmail 的变体来搜索它们非常困难。有些人会利用少量 Gmail 地址注册大量账户，并等到几个月后才开始发帖。
关于使用正则表达式作为解决方案：封锁加号（+）相对无害；而封锁点号（.）可能会阻止大量合法邮箱，例如 john.smith@gmail.com。封锁包含多个点号的地址可能造成的附带损害较小，但仍会允许 Gmail 地址的几种变体，不过比允许两个及以上点号的情况要少得多。
依我之见，之前的实现是理想的，并且作为可选保护措施实施起来并不过分。大多数主流社交网站都不允许使用多个 Gmail 变体进行注册，因为这些变体常被垃圾邮件发送者大量利用。
谢谢
@sam 我强烈认为，如果网站需要，应允许其实施这种可选的邮箱正则表达式锁定级别。否则，我们将违背 Discourse 的核心原则之一，即“默认安全”。
我们可以在下一个版本中完成这项工作，但我依然坚持最初的想法：规范化是对站点运营者最友好的解决方案，只需勾选一个复选框，问题便迎刃而解。而使用正则表达式，你不得不先花上五个小时学习正则表达式，最终得到的解决方案要么会让垃圾账户漏网，要么对用户不友好（不允许使用点号或加号），要么只能是一种折中方案。
不过话说回来，当然，我们可以在下一个版本中加入对正则表达式的支持。
嗯，其实很简单，就是“不允许使用包含加号或句点的电子邮件地址”，这确实相当严格，显然我们不会默认开启这个选项。但这就像“巴姆瓦”问题一样：总会有一些恶意行为者，因此你不得不准备“核按钮”，哪怕你并不想使用它。
这就像核战争。一旦核武器摆在桌面上，就不再有可能提供“用户友好”的选项了，你只能希望大多数时候永远不需要走到那一步。
