我可以确认，最初的修复方案效果完美，成功解决了 Gmail 地址的这个问题。如果能恢复这个可选模式，那将真正救急。
垃圾邮件发送者不断学习新技巧，依然能成功“利用”Facebook、Instagram 和 Twitter 等大型平台。这使得其他大多数地方变得像“简单模式”。对他们中的许多人来说，这是一份全职工作，因此本质上变成了：
如果存在可利用漏洞，且（所需成本 < 预期收益），那么该漏洞就会被利用。
他们几乎可以绕过任何措施，唯一的希望是将实施成本提高到使其不再具有经济回报的程度。
能够在被检测和版主/管理员事后封禁其标准 Gmail 地址并手动删除其帖子之前，利用近乎无限的邮箱/账号进行批量垃圾邮件发送，其成本效益非常高。如果没有一支 24/7 的版主团队，情况会更糟。
绕过反垃圾邮件措施的成本正在持续降低。一个例子是 4G/5G 代理：每月仅需 30-50 美元左右，人们就能获得近乎无限的真实移动 IP 地址，这些 IP 来自合法的 ISP/ASN，会自动或手动轮换，并被整个城市或州的合法用户共享。4G/5G IP 被许多用户同时共享。
直接封禁这些 ISP/ASN 或 IP 并不合适（不能直接封禁所有使用 Verizon、AT&T 等的用户）。他们通常只使用一次 IP 就丢弃。由此封禁的单个 IP 也会随机封禁共享该 IP 地址的合法用户。IP 封禁正逐渐成为一种过时的做法（已知托管公司的 ASN 除外）。你可以在这些论坛上看到冰山一角：
https://mpsocial.com/c/public-marketplace/61
https://www.blackhatworld.com/forums/proxies-for-sale.112/
我认为垃圾邮件发送者是全自动或部分手动编写的机器人与人工垃圾邮件的混合体。随着 Discourse 占据更多市场份额（其增长显然非常迅猛），如果它没有成为商业可用机器人的目标，那才令人惊讶。
一旦 Xrumer 开始支持最新的 reCAPTCHA 版本，我敢说大多数传统论坛的站长会注意到垃圾邮件量大幅上升，因为垃圾邮件的成本已降至谷底（不再需要使用验证码破解 API，而这类 API 每破解 1000 次的费用已经非常低廉）：
http://botmasterlabs.net/buy1/
人们已经可以自行编写插件/脚本来支持几乎所有平台，使用 Xrumer。但如果有一天它能原生支持 Discourse：
我无法声称自己是公正的，因为我确实急需反垃圾邮件措施。关于 Gmail 点号技巧的原始帖子是由他人于 2014 年创建的，似乎另一位用户通过要求前 x 篇帖子需经审核解决了此问题，所以也许至少有三次用户报告？
抱歉跑题了，回到正题。
关于针对邮箱的正则表达式封禁，你说得对。这只是部分解决方案，并不理想，原因如下：
如果封禁所有在 @ 之前包含 1 个或更多点的 Gmail 地址：
- 这将不可避免地封禁真实的合法 Gmail 用户，这些用户的邮箱中包含 1 个或多个点，这非常普遍。
- 垃圾邮件发送者仍然可以利用单个点创建大量变体。例如，Gmail 最长为 30 个字符，例如
12345678901234567890123456789.0@gmail.com，仅使用单个点即可产生 30 种可用组合。
如果封禁所有在 @ 之前包含 2 个或更多点的 Gmail 地址：
- 封禁的合法 Gmail 用户较少，但仍会封禁邮箱中包含超过 1 个点的合法用户。
- 垃圾邮件发送者可以利用单个 30 字符的 Gmail 创建更多变体。我认为大约有 842 种组合。
我可以确认，在封禁规则生效后，新账号仍然通过了。因为封禁创建日期是 2 月 1 日。昨天我一直在观察新账号的创建情况，看到封禁规则既有新的近期匹配项，也有使用相同邮箱（仅添加点号）组合的新注册进入。
我昨晚禁用了注册功能，今天早上重新启用。今天到目前为止，他们已经创建了 104 个新账号，使用的是该 Gmail 地址的排列组合，并且仍在继续注册。我可以确认，一旦从这些账号的邮箱中移除点号，它们就与 Screened Emails 封禁记录完全匹配。
我尝试按照描述在 rails c 中测试封禁，情况变得有点奇怪。
似乎有些记录按预期返回了 true，而有些记录即使测试的邮箱与被封禁的标准邮箱完全匹配，也返回了 false。对于返回 true 的记录，它们完全按预期工作，对我测试的所有变体都返回了 true。但对于返回 false 的邮箱，我测试的所有变体也都返回了 false。
我试图寻找任何相关性。我可以确认这些并不相关（或者至少不一致相关）：
- 邮箱长度（在 @ 之前）
- 邮箱包含字符和数字
- 匹配次数（被封禁的次数）
- 匹配日期
不过，似乎与封禁创建日期存在相关性：较早创建的封禁不太可能生效（返回 false）。9 天前创建的记录返回了 true 和 false 的混合结果，而我测试的所有早于该时间（1 小时至 8 天前）创建的记录都返回了 true。
这是否与“未匹配邮箱的最大保留时间”有关？我想这个选项是最近才有的，我将其设置为默认的 365 天。