我的临时邮箱黑名单屏蔽了我

# 我的临时邮箱黑名单把我自己拦住了 · Benjamin Piouffle 来源：https://benjamin.piouffle.com/blog/burner-email-blocklists/ 几天前，我尝试用 Proton Mail 别名注册一个公共开放数据服务（*如果你在意的话，是 ECMWF (https://www.ecmwf.int/)*），但表单把我的地址判定为“潜在垃圾邮件”而拒绝。我的挫败感中还夹杂着一点内疚：2018 年我发布了 Burnex (https://github.com/Betree/burnex)，一个 Elixir 包，它会将邮箱与一长串已知临时邮箱域名（比如 *yopmail.fr* 这种只用来收一次确认链接就消失的临时收件箱）进行比对。这个库本身依赖的是相当流行的 wesbos/burner-email-providers (https://github.com/wesbos/burner-email-providers) 列表。 当时，我在做一个协作式事实核查平台，账号的真实性很重要，我们需要一定把握确保用户不是伪造或批量生成的。域名黑名单在当时看来，是针对更广泛信任问题的一种廉价启发式手段。 我可能后知后觉，但让我明确说一句：**我不再建议在注册时系统性地屏蔽临时邮箱域名。** **TLDR;** > 如果你现在要制定注册策略，不要自动把使用隐私邮箱服务的用户拒之门外。区分公共共享收件箱和个人别名，只拦截前者。使用别名的用户更可能是在保护自己，而不是想骗你。而垃圾邮件发送者早已转向其他方法。如果你维护或使用一个黑名单，请考虑拆分类别，并在文档中鼓励良好实践。 ## 临时邮箱和别名不是一回事 我们在使用邮箱黑名单时常常忘记一个区别：经典的**临时邮箱**是一个**公开的**、短命的收件箱，谁都能访问，只用来点一次验证链接然后丢掉。而**邮箱别名**则相反：它是一个永久性的转发地址，绑定到*你的*账户，由你控制，可以禁用，当你的密码泄露时还能追溯到具体的注册来源。 如今，Firefox Relay (https://relay.firefox.com/) 和 Apple Hide My Email (https://support.apple.com/en-us/102648) 这类工具已经是主流产品，而不是边缘黑客工具。Mozilla 将 Relay 宣传为一种在注册新账号时保护身份隐私的方式，Apple 也将 Hide My Email 宣传为一种既能分享地址又不用透露真实地址的方式（*不过他们可能夸大了 (https://news.ycombinator.com/item?id=48744606) 这个承诺*）。 那些把别名提供商等同于一次性收件箱的黑名单，最终会拦截那些试图保护自己的人。这不仅仅是注册体验上的摩擦：别名能限制跨站追踪，减少泄露后的垃圾邮件，而且当垃圾邮件出现在你只给了某个服务的转发地址上时，你能确切知道是哪个服务泄露了你的地址。我们应该鼓励更多人使用别名，而不是减少。 ## 黑名单拦不住执意作恶的人 执意作恶的人从来不会被黑名单域名限制。Gmail 的 `+` 别名可以为一个收件箱创建无数种变体（`[email protected]`、`[email protected]`），像 Emailnator (https://www.emailnator.com/) 这样的服务可以帮你按需生成无限数量的 Gmail 一次性地址。自定义域名一年只要几美元，而且看起来和正经企业邮箱毫无区别。和你的用户不同，垃圾邮件发送者有手段也有时间去绕过域名黑名单。对他们来说，这只是个小障碍，不是一堵墙。 没错，黑名单确实能拦住一些低强度的自动注册。**但代价是不对等的：一个简单的机器人只是稍微慢了一点，而一个使用合法别名的真实用户却被直接拒绝，毫无办法。** 你是在优化那些轻易放弃的攻击者，却惩罚了认真对待隐私的用户。黑名单原本想阻止的那些人从没被真正阻止过，他们只是学会了使用你信任的域名。 除了黑名单，邮箱验证本身（包括确认链接）也不应该被视为账号真实、唯一或可信的证据。它只能证明有人能在那个地址收到一次邮件。 ## 仍有合理的用途 检查某个邮箱域名是否出现在已知的一次性邮箱列表中，仍然可以作为更广泛的信任或风险评分中的一个合理信号，用于发现一批注册中的可疑模式，或者在营销活动中忽略它们。 如果今天让我重写 Burnex，我会把范围缩小到真正公开、共享的收件箱（比如 *mailinator.com* 这种任何人都能收到你验证邮件的地址），而不是把它们和个人转发服务混为一谈——后者只是恰好使用了一个非主流域名而已： ```elixir # 公开的临时收件箱，屏蔽可能没问题 Burnex.is_burner?("[email protected]") # 个人别名，通常不应该屏蔽 Burnex.is_alias?("[email protected]") ``` 但问题不仅仅在于某个库如何分类域名：Burnex 所依赖的上游列表（wesbos/burner-email-providers (https://github.com/wesbos/burner-email-providers)）被全世界的注册验证器、第三方包和 API 直接使用。许多集成者不加筛选地屏蔽 `emails.txt` 中的每个域名，因此列表的分类选择会对下游产生实质影响。 ## *给后来者的话* 我已经开了一个 issue (https://github.com/wesbos/burner-email-providers/issues/538)，提议在 wesbos 的列表中做同样的拆分：保留一个文件用于公共共享收件箱（*yopmail.fr*、*mailinator.com* 等），再增加第二个文件用于个人别名和转发服务提供商（*passmail.net*、*anonaddy.me*、*mozmail.com* 等）。然后更新 README，加入良好实践的建议。 由于时间有限，而且我不再在我维护的产品中使用 Burnex，所以我在 2026 年初将这个项目弃用了。此后，Klemen Sever (https://github.com/achedeuzot) 提出接管该项目，我已经将所有权转让给了他。