从「一站一密」到「一站一邮」

「不同的网站使用不同的密码」这一理念已经深入人心，「不同的网站使用不同的邮箱」却还没有那么普及。如何选择合适自己的域名邮箱？使用邮箱注册服务时是否透露了过多的信息给网站？本文试图推广一种新的邮箱管理理念。

一、前提：密码管理器

本文所讨论的内容的前提是读者你已经在使用密码管理器，并有为不同的网站使用唯一随机密码的习惯。我早在十年前就强调过密码管理器的重要性。如果你目前并未使用密码管理器，我在此推荐 1Password，我在《迁移至 1Password 密码管理器》一文中叙述了我从 KeePass 家族迁移至 1Password 的理由。

二、Canary Trap

「一站一密」的重要性在于一个网站被黑之后你的密码不会被用来尝试登录另一个网站（撞库）。那「一站一邮」有什么意义呢？有个老段子，大意是：

我在不同网站买东西用的名字不同：淘宝就用王淘宝，京东就用王京东。这样当我以后收到骚扰电话，开口就是「王淘宝先生/女士」，我就知道是淘宝把我的信息卖了。

虽然这只是个段子，实际可操作性方面有很多问题，但是它背后的核心思想其实是 canary trap，即将信息交给别人之前稍做变化，使每个人拿到的信息都略有不同，这样当信息被泄露的时候，根据泄露出来的信息版本，就可以判断是谁泄露了。

Canary trap 的关键是什么呢？首先是每个拿到你信息的人都要有唯一的信息版本。上述段子中，淘宝和京东上可能有成千上万的店家，只用两个名字无法确认是电商平台泄露了你的信息还是平台入驻的商家的问题。其次，如果你给出的信息一看就是一个 trap，那对方也会有所警觉，比如叫你「王先生/女士」而省略到后面的「识别码」。

幸运的是，虽然姓氏和名字很难做到千变万化，但邮箱可以。Gmail 在很多年前就允许用户用加号来创建自己邮箱的变体；Outlook 更是允许用户添加别名（alias）。因此，不少用户会用 [email protected] 或是 [email protected] 这样格式的邮箱来实现「一站一邮」。

这样做基本实现了「一站一邮」，但依然有两个问题，其中之一是：邮箱不是自己的。

三、域名邮箱

我一向对以手机号作为用户名的服务很反感，因为手机号资源是运营商的，不是自己的。邮箱也是如此，如果使用的是别人的域名（如 gmail.com 和 outlook.com 等），那始终存在着因为邮箱服务倒闭而导致所有用户被迫迁移的可能性。2013 年的时候，Yahoo! 邮箱就关停了所有 yahoo.cn 和 yahoo.com.cn 域名的邮箱。

更新：在查询上述新闻的时候看到一个帖子，说疑似因为政策原因，Yahoo! 要将中国大陆用户的 yahoo.com 邮箱也关停了。

如果你用别人的域名的邮箱注册了大量服务，当这个域名停止服务或是出现其他问题（比如不再提供别名功能？）的时候，等待你的将是迁移的噩梦。只有域名控制在自己手里，这个邮箱才完全属于你。域名背后实际的邮件提供商是谁并不重要——倒闭了换一家就是，但域名一定要是你自己的。为了长久考虑，个人建议只选择 .com / .org / .net 等老牌 ICANN 顶级域作为邮箱域名，而不要选择一些过于小众的 ccTLD 或 new gTLD，防止域名注册局倒闭或注册商不再支持这一顶级域。

如果你还记得 Google Apps 这个名字（后来改名叫 G Suite，最近又改名叫 Google Workspace 了）的话，你应该也记得 Google Apps 在 2012 年之前提供过免费的域名邮箱。当时拥有一个或多个以自己域名结尾的「Gmail 邮箱」是一件很酷的事情。现在免费的午餐早已结束，对很多人来说只是为了「一站一邮」而是去花 6 USD/mo 维护一个 Google Workspace 账户就显得不太值得了，更何况这一套面向企业的办公套件中的大部分功能其实个人用户根本用不到。

此外，你真的需要 Google Workspace / Microsoft 365 等提供的全功能邮箱吗？如果只是为了「一站一邮」，许多域名注册商提供的邮件转发功能就足够了，这一功能往往是免费的。

Google Domains 就提供了免费的邮件转发功能。你可以配置通配符，将整个域名下所有可能的邮件地址收到的邮件全部转发到你的主邮箱。这个功能对于只收不发的场景来说是足够用了，如果真的偶尔要发送邮件的话（比如开了个工单，要求用注册邮箱回复），用邮件客户端改一下 From 大概率也能糊弄过去（考虑到工单系统很可能不查 SPF/DKIM/DMARC）。

上文已经提到，只要域名是你自己的，背后实际邮件提供商是谁并不重要。所以你完全可以用一个（不公开的）@gmail.com 或 @outlook.com 结尾的邮箱作为自己的域名邮箱的转发目标，毕竟这个目标是可以随时换的。

当然，如果你愿意投入更多，最好还是选择一个全功能的邮箱而不是使用转发服务，以获取更好的 SPF/DKIM/DMARC 兼容性。相较于 Google Workspace 和 Microsoft 365 这样的全功能办公套件，我个人推荐专做邮箱服务的 FastMail。使用我的注册链接可享受第一年 10% 的优惠。

当你配置好自己的域名邮箱之后——恭喜你，你离完美的「一站一邮」更进一步了，但还有一个问题：你是否在域名邮箱里透露了过多的信息？

四、域名邮箱之困境

故事的主角叫 Alice，她拥有了 alice.tld 这个域名并配置了域名邮箱。Alice 注册 Twitter 时使用了 [email protected] 这个邮箱，注册 Facebook 时使用了 [email protected] 这个邮箱。当哪天 Alice 从 [email protected] 这个邮箱收到了垃圾邮件，她就知道 Mark Zuckerberg 又不干好事了。这一切看起来很美好。

有一天 Alice 想注册 Pornhub，但是她又不想让别人知道她注册了 Pornhub，这时候再用 [email protected] 作为注册邮箱就不合适了，因为 alice.tld 恰好也是 Alice 的个人主页域名，如果 Pornhub 被黑了，那别人只要在数据库里查一下 alice.tld 就知道她注册了 Pornhub。

又有一天 Alice 想在 Reddit 上爆个料而注册一个小号，但是 [email protected] 已经被大号占用了，难道用 [email protected] 吗？

可能你会说：注册这些不想和 Alice 这个身份产生联系的网站的时候，用那种一次性邮箱不就行了？的确，如果只是注册一个临时使用的 Reddit 小号的话，这样的方法或许可行。但如果 Alice 想要注册一个隐秘的 OnlyFans 账号卖电风扇赚外快呢？如果用临时的一次性邮箱就会有资金安全的问题了。

你可能又会说：那用 Fake Name Generator 生成一个假身份注册一个比如 [email protected] 的邮箱不就行了？然而，如果你多个网站都用同一个邮箱，那就不再是「一站一邮」了；如果你愿意为每个网站都注册一个不同的 [email protected]，那你大概也就不需要自己的域名邮箱了。

除了 @alice.tld 部分泄露了「这个邮箱属于 Alice」这一信息，@ 之前的部分也向网站泄露了不必要的信息。Alice 用 [email protected] 注册 Facebook 是为了提醒自己这个邮箱在 Facebook 使用过，但 Facebook 没有必要知道这一层关联，这属于额外的信息泄露。在 canary trap 的使用场景里，被分发信息的人是不应该/没有必要知道自己拿到的信息是个 canary trap 的。

上述困境也曾困扰我许久，直到 FastMail 和 1Password 联合推出了 Masked Email 功能，我才受到启发，想到了破局之法。

五、唯一随机邮箱

「Canary trap 不应被看出来这是一个 canary trap」的问题本质上是 facebook@... 这样的邮箱满足了「唯一性」，但没有满足「随机性」。密码都是随机生成的了，不如把邮箱也随机生成一下？反正都是密码管理器去记忆而不是人脑去记忆。

FastMail 的 Masked Email 功能就能随机生成一个邮箱。它其实就是把别名（alias）功能包装一下。别名功能本身并不新鲜，但包装之后的 Masked Email 的想法很新颖，和 1Password 合作之后更是非常方便。

如图，在 FastMail 设置里可以方便地对 Masked Email 进行增删改查的操作；新建的 Masked Email 会自动以类似 foo.bar1234@ 这样两个随机单词加四个随机数字的形式开头：

如果从 Masked Email 收到邮件，则在 Web UI 上有特别的标记（一个面具），并且会显示你给这个 Masked Email 填写的描述（比如网站名）；如果你使用客户端的话，则可以高亮 Fastmail-MaskedEmail 这个邮件头：

如果点击回复的话，会自动以 Masked Email 的邮件地址作为发件人地址，并不会不小心泄露你的主邮箱：

至此 Masked Email 已经实现了「一站一邮」，并且就像唯一随机密码一样，邮箱也做到唯一 + 随机。Alice 的困境得到了解决，因为每个网站的邮箱地址都不再与 Alice 这个身份有关联，无论是 Facebook 还是 Pornhub。

锦上添花的是，Masked Email 这个功能与 1Password 有深度整合。当用户将 FastMail 与 1Password 关联起来之后，可以在注册新服务的时候，让 1Password 帮你在 FastMail 里生成一个 Masked Email 并自动填表。而且这一 Masked Email 在 1Password 里也可以一键 block / search：

这真是太方便了！

六、服务依赖性

我在使用一个服务之前会慎重考虑这个服务数据是否可导出、是否容易地被替换等要素。上文强调邮箱要使用自己的域名即是因为这个原因，之前写文推广 PhotoPrism 等自建服务也是如此。Masked Email 功能刚推出的时候，我想当然地以为它只能生成 @fastmail.com 结尾的地址。我虽然喜欢 FastMail 且用了很多年，但是我时刻警惕着 FastMail 突然倒闭，所以并不想用它的域名。后来我欣喜地发现原来这个功能是可以使用自己的域名的（FastMail 支持添加至多 100 个域名，并指定其中一个作为 Masked Email 所用域名，这一域名可以随时更换），于是便试用了一下，发现真是方便啊。

此外，Masked Email 自动保存到 1Password 还意味着即使 FastMail 倒闭或者我换到别的提供商，这份随机邮箱地址与网站的对应关系表还在我的手里，我在别的提供商依然可以利用这份对应表重建收件规则（当然我也可以偷懒直接搞个通配符）。

至此，Alice 的「一站一邮」方案已经成型：她注册了一个与 Alice 身份无关的域名 bob.tld，添加到 FastMail 里设置成 Masked Email 所用的域名。她用 1Password 自动填表注册所有的网站，每个网站都拥有一个唯一的、随机的形如 [email protected] 的邮箱，以及一个唯一的、随机的、强壮的密码。

如果你也想搞这么一套「一站一邮」方案，那快去购买域名、注册 FastMail 和 1Password 吧！

当然，你也可以根据上述方案的思路稍加改变，比如开启 Google Domains 的免费通配符邮件转发功能，然后自己写个浏览器扩展之类，在填表的时候生成一个随机邮箱，写入自己的密码管理器（不一定是 1Password）。

开启通配符转发有个小问题就是经常会收到一些发往一些从未使用过的随机地址的邮件，比较烦人。Jimmy Xu 提供了一个思路是生成邮箱的时候使用特定的正则甚至 HMAC，然后在接收邮件的时候时候再做验证，不符合规则的直接拒收。当然这需要你跑一个自己的 MTA。

如果你有其他想法，也欢迎在下面留言或是给我发邮件。

本文地址： https://wzyboy.im/post/1447.html 。转载请注明出处。