似乎有些 Gmail 邮箱被屏蔽的垃圾邮件发送者，尽管其邮箱的标准版本已被屏蔽，仍利用句号变体成功绕过限制。
例如：
examplemailaddress@gmail.com 已被屏蔽
e.x.a.m.pl.e.m.ai.lad.dre.ss@gmail.com 却能通过
看来屏蔽机制仍在运行，但并非完全有效。我在日志中仍能看到针对该记录的常规匹配记录（已筛查的电子邮件），但并非所有变体都被拦截。该用户今天已使用同一个被屏蔽的 Gmail 邮箱成功创建了数百个账户。
他们使用的 Gmail 句号变体中，句号数量介于 6 到 14 个之间，邮箱长度（@ 符号之前）为 19 个字符；他们未使用加号（+）变体（或者所有此类变体均已成功被屏蔽）。
可能相关的一点是：我将垃圾邮件邮箱的莱文斯坦距离阈值设置为 3（默认值为 2）。Discourse 最近已从 2.6.x 版本更新至 2.7.1 稳定版。
嗯，我忘了我们在这件事上达成了什么共识，@sam，但这可能是一个 bug，因为你说过：
这意味着，如果
evil.person+77@gmail.com被屏蔽，我们将转而屏蔽evilperson@gmail.com。那么当e.v.i.l.person@gmail.com试图溜进来时，由于规范匹配，它也会被屏蔽。
那么，当 sara.hanson@ 做了些恶劣的事情，而 sarah.anson@ 却无辜受牵连时，会发生什么呢？这就像我不确定 joe98@ 和 joe99@ 是否也能被视为同一个电子邮件地址一样。我想，这取决于社区的成员构成以及在匹配过程中所采用的人工判断程度。
“加号寻址”（Plus addressing）至少指的是属于同一邮箱地址的文件夹（前提是加号“+”之前的部分完全相同）。
或许可以通过 IP 段来阻止注册？这一切都取决于垃圾邮件发送者的技术 sophistication。从 Let’s Encrypt 社区过来，我们在那里有一个追踪线程，详细记录了一些相当广泛的垃圾邮件战术。我们甚至遇到过有人在几周后开始发送垃圾邮件之前，还曾提供过实际的技术帮助。
这是不可能的；从 Gmail 的角度来看，这两个地址属于同一个账户，因此它们代表的是同一个人。
有意思。我从未意识到 Gmail 实际上做了这种区分。今天学到了不少新知识。我想知道他们为什么要这么做？
感觉这会占用不少空间。这里只涉及 Gmail 地址吗？
我认为我们的结论是：“我对我们目前的处境感到不安，因为这会带来巨大的支持噩梦，而且这个问题永远不会消失 :)”。
我觉得，如果一个网站是垃圾邮件的源头，应该允许他们声明“将我所有的电子邮件设为规范地址”，即使存在负面影响也无所谓。
这意味着以下两封邮件都将 samsam@somewhere.com 设为规范地址：
sam.sam@somewhere.com
samsam+11@somewhere.com
如果 sam.sam@somewhere.com 已经注册，那么 samsam+11@somewhere.com 将不再允许注册。
这是我最初的修复方案，但我后来将其回退了（尽管当时针对 Google 做了特殊处理，现在回想起来，那还不够严厉）。
我觉得我们应该通过添加一个新的站点设置来彻底解决这个问题：
“天哪，我是巨大的垃圾邮件源头，请开启超级铝箔模式”
关于这个漏洞，如果你等到被屏蔽时才采取行动，垃圾邮件很容易趁虚而入。目前这完全是一个被动响应的过程。
这意味着以下操作可以正常工作（欢迎在控制台中测试，@markersocial）：
./launcher enter app
rails c
ScreenedEmail.block('examplemailaddress@gmail.com')
ScreenedEmail.should_block?('e.x.a.m.pl.e.m.ai.lad.dre.ss@gmail.com')
# true
问题在于：
# 创建了数百个账户
ScreenedEmail.block('examplemailaddress@gmail.com')
# 数百个账户依然存在
哦，对了，最初的请求是通过站点设置来屏蔽所有包含特殊字符的邮件。我以为我提出过这个方案，但你不喜欢？我记不清了。
我认为这归根结底是 @markersocial 想要一个功能（即我最初实现的强制规范链接），而我们数千名托管客户似乎都不需要这个功能。
我们可以继续完善“响应式功能”（在屏蔽时搜索规范链接，并提示管理员删除垃圾账号）。不过，我更希望先听到一些重复的投诉。
基于正则表达式的屏蔽肯定不适用于 @markersocial，但他可以自行确认这一点。
我无法复现原文中提到的问题，并强烈怀疑那些问题账号是在添加屏蔽规则之前创建的。
我可以确认，最初的修复方案效果完美，成功解决了 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 地址：
12345678901234567890123456789.0@gmail.com，仅使用单个点即可产生 30 种可用组合。如果封禁所有在 @ 之前包含 2 个或更多点的 Gmail 地址：
我可以确认，在封禁规则生效后，新账号仍然通过了。因为封禁创建日期是 2 月 1 日。昨天我一直在观察新账号的创建情况，看到封禁规则既有新的近期匹配项，也有使用相同邮箱（仅添加点号）组合的新注册进入。
我昨晚禁用了注册功能，今天早上重新启用。今天到目前为止，他们已经创建了 104 个新账号，使用的是该 Gmail 地址的排列组合，并且仍在继续注册。我可以确认，一旦从这些账号的邮箱中移除点号，它们就与 Screened Emails 封禁记录完全匹配。
我尝试按照描述在 rails c 中测试封禁，情况变得有点奇怪。
似乎有些记录按预期返回了 true，而有些记录即使测试的邮箱与被封禁的标准邮箱完全匹配，也返回了 false。对于返回 true 的记录，它们完全按预期工作，对我测试的所有变体都返回了 true。但对于返回 false 的邮箱，我测试的所有变体也都返回了 false。
我试图寻找任何相关性。我可以确认这些并不相关（或者至少不一致相关）：
不过，似乎与封禁创建日期存在相关性：较早创建的封禁不太可能生效（返回 false）。9 天前创建的记录返回了 true 和 false 的混合结果，而我测试的所有早于该时间（1 小时至 8 天前）创建的记录都返回了 true。
这是否与“未匹配邮箱的最大保留时间”有关？我想这个选项是最近才有的，我将其设置为默认的 365 天。
如果您能提供详细的复现步骤，我们肯定会修复该问题。
不过，“最大未匹配邮件保留时长”并非新设置——它与“最大未匹配 IP 保留时长”一样，是用于清理“受审查 IP 列表”和“受审查邮件列表”中那些在一年内未匹配到任何内容的陈旧条目的工具。
我需要具体的示例。如果存在漏洞，我当然希望修复它们。
我理解你的顾虑。我认为 @codinghorror 当初对原始实现的主要反对意见在于，其中包含了针对 Google 的特殊逻辑，这让 Jeff 感到相当不安。
我想，将规则细化为“无论域名如何，所有内容均统一为规范形式”，在一定程度上缓解了这种担忧。
例如：
sam+982@sam.com - 允许注册 … 但前提是 sam@sam.com 尚未注册。
s.a.m.@sam.com - 不允许注册 … 因为系统检测到 sam@sam.com 已被注册（规范形式已存在）。
未来某天我们可能会重新引入该功能，只需在别处找到应对滥用的方法。上次我调查时，在我们的托管服务中并未发现此类滥用行为。
今天只有少量时间发帖，但在更详细地回复之前，想先分享一些补充信息。
我发现，删除一条在“日志”→“已筛选的电子邮件（允许）”中返回 false 的记录，然后再次屏蔽该电子邮件（通过删除用户并在用户管理页面中对该用户执行屏蔽操作），可以使之前失败的规则现在对直接匹配及其变体持续返回 true。
这与“问题出在旧记录上”的观察结果一致。还需要进一步测试。
总有守桥人那种（随机）审核新人的方式……：grin:
