# 我的邮件管理哲学

By: Murray
Published: July 4, 2026
Canonical: https://buxx.me/blog/email-philosophy
Updated: August 7, 2026
Tags: 技术向

步入大学后，电子邮件成倍地增多了。穿梭在个人与学校的不同 Inbox 之间，纷至沓来的各类邮件常让我感到不堪重负。在订阅 Fastmail 20 个月后，我决定记录下它是如何帮我理清混乱，重掌秩序的。

步入大学后，电子邮件成倍地增多了。穿梭在个人与学校的不同 Inbox 之间，纷至沓来的各类邮件常给我带来心智上的不堪重负。在订阅 Fastmail 20 个月后，我决定记录下它是如何帮我理清混乱，重掌秩序的。

整理下来，我的邮件管理体系体系服从三条原则：**无限的身份分层，与唯一的可信任邮件中枢入口。**能够为不同的身份创建唯一的邮箱，但决定权只能握在一个我完全信任、并有可靠的隐私保护、不靠邮件内容做生意的平台手里。**合理利用邮件规则分流注意力**。我可以接受海量的未读邮件堆成山，但不能挡住我该看的东西。**绝不可以被生态绑架**。无论多么喜欢一个服务商，也要留一条不被它绑架的退路。下面将会介绍我的邮件管理技巧。

[Create your Fastmail account](https://join.fastmail.com/b564c1b3?ref=blog.buxx.me)

## 前言：邮件管理只有三条路。吗？

要么忍：把现有的一堆邮箱服务（Gmail, Outlook) 用 Spark 之类的第三方客户端聚合在一起，这样也可以做到在所有设备上同步，能够接收由 Spark 代理的推送通知（Push Notification），但需忍受越来越臃肿的收件箱、防不胜防的垃圾邮件，以及 —— 假装不知道 Spark 能读到我每一封邮件的内容 [[1]](#fn1)。

要么躲：用 Proton Mail 那样坚固的隐私堡垒把自己封起来。代价是被迫使用它自己的客户端 [[2]](#fn2)，放弃和其他生态平台的兼容性，即便他提供了 Bridge，心智代价仍然不小。相当于以麻烦换隐私。

还有一条大多数人直接走的路，干脆用 Outlook 或者 Gmail 自己的原生客户端。但本质上这只是把「忍」中的「要不要信任第三方客户端」这个问题换成了「要不要信任邮箱服务商自己」，Google 和 Microsoft 会在你的邮箱中学习内容，并在客户端里定向投放广告恶心用户，这是我最不能忍受的一点。而且多个邮箱身份要在多个原生 App 之间来回切换, 这也恰恰是我最想解决的问题。

我只想要一个中立的、不靠邮件内容做生意的中枢，能用标准协议（IMAP）接进我喜欢的纯粹的客户端，同时不用为了这份自由去装一个随时可能掉线的本地代理。后来发现 Fastmail 基本满足了上述要求，而且用下去之后，它解决的问题比我最初想的多得多。

## 收信：所有邮件的统一入口

我把 Fastmail 当作所有邮件的最终目标。不论邮件最初发到哪个地址，最后都汇进一个平台处理，我只需要打开这一个邮箱阅读就够了。

学校邮箱依赖 Google Workspace，我在 Gmail 侧设了转发规则，所有进站的邮件保留副本并自动转发到 Fastmail。[[3]](#fn3)这解决了一个具体的老问题：以前使用 Gmail 客户端时，多个邮箱需要切换账号分别查看 Inbox，很容易漏看重要通知。学校系统的邮件密度不低，优先级也很高。个人 Gmail 同理转发过来，现在基本只作为历史遗产地址保留，收收验证码，不再用它新注册任何网站了。

## 发信：仍能使用原地址

邮件全都汇进来了，回信也要能从原来的地址发出去。Fastmail 支持通过 OAuth 绑定 Gmail / Outlook 等账号 （[Settings -> Addresses](https://app.fastmail.com/settings/addresses/create/existing?ref=blog.buxx.me))，这样就可以直接在 app 内使用原有地址发送邮件，十分便捷。我绑定了个人 Gmail 和学校邮箱，在 Fastmail 里写邮件的时候直接切换发送地址即可。

## 身份：域名邮箱与 Masked Email

之前折腾过 Cloudflare Email Routing、Microsoft 365、Google Workspace，以及 iCloud+，各花入各眼。但是也踩了许多坑，用着都不是很满意。最后还是落在了 Fastmail 上。 我自己持有多个域名，Fastmail 可以直接托管域名邮箱的收发。除了一般的对顶级域名的 catch-all 收信， Fastmail 在最基础的 plan 就支持子域名的配置。 例如：我可以将 `anything.buxx.me` 单独加成一个域名，这样就可以拓展另一片无限的邮箱空间，同时使用 `anyname@buxx.me`、`anyname@anything.buxx.me`等等随意收发邮件了。

Fastmail 提供两种别名机制。一种是别名（alias），可以手动创建固定的额外的 Fastmail 地址，我喜欢他提供的 `@sent.com` 地址，还拿到了两个字母的靓号。另一种是掩码邮箱（masked email），在注册之时即时生成的一次性地址。服务商拿到的地址和我的真实身份没有任何关联，一旦某个服务开始滥发邮件或者泄露数据，唯一要做的就是把受影响的那个地址 ban 掉就行。掩码邮箱默认用随机前缀加 `@fastmail.com`，「权重」很高。当然也可以换成自己的域名，生成的地址看起来就和普通邮箱没什么区别。

我会把这套机制和 [iCloud - Hide My Email](https://support.apple.com/en-au/guide/icloud/mme38e1602db/1.0/icloud/1.0?ref=blog.buxx.me) 进行类比。在自动生成和填充方面，Fastmail 与 1Password 原生集成。注册新账号时，由 1Password 自动生成一个掩码邮箱地址填进去，免于手动创建填写的困扰，并且在两个平台管理都很方便。

值得注意的是，自 2026 年夏天晚些时候，Apple 将不再允许创建域名为 `@icloud.com` 的匿名邮箱，转而使用 `@private.icloud.com`。[[4]](#fn4)这会让开发者拦截 iCloud 掩码邮箱注册变得轻而易举。[[5]](#fn5)

## 客户端

桌面端我交替使用 Fastmail 的网页版和 Apple Mail App。移动端固定用 Apple Mail。Fastmail 也在多个平台提供客户端，不过是网页套壳，用起来总没有原生的顺畅。

值得一提的是，Fastmail 在 Apple Mail App 里原生支持 IMAP Push 推送通知[[6]](#fn6)，基于 [APNs](https://en.wikipedia.org/wiki/Apple_Push_Notification_service?ref=blog.buxx.me) 的神力，邮件通知几乎实时到达。第三方 mail 支持 Push 的很少见。Gmail 在 Apple Mail 里只能靠定时拉取，延迟明显。这个差异在收验证码的场景感知明显，Fastmail 的验证码基本秒到，如 SMS 一般。

## 邮件规则

我从不搞收件箱清零。我的收件箱常常躺着几千封未读邮件。但如果它们全混在一起，我就没办法选择性地忽略某一类，也没办法在赶 due 的那几天只看学校相关的通信。 所以我设置规则的意义不在于清空，而是分流注意力。

下面介绍一下我在 Fastmail 上设置的规则。

### `Inbox/Uni`

这里分类了所有来自学校邮箱的邮件。 规则设置为自动 pin，这是最重要的信息，必须让我第一时间看到。然后全部归进 Inbox/Uni ，便于按照标签过滤查找。

### `Inbox/Dev`

GitHub 、Cloudflare 和 Betterstack 的通知，归进 `Inbox/Dev`。这类邮件量大、重复度高，但偶尔会有需要立刻处理的 issue mention 或者 actions 告警，或者服务器宕机通知，不能直接丢掉，挪出主视野并方便归档。

### `Inbox/Transactions`

这里只包括了信用卡的通知邮件，全都是重复信息。

### `Inbox/Files`

Receipt 和 Statement 分别归进 `Inbox/Files/Receipt` 和 `Inbox/Files/Statement`。包含购物小票和银行/Paypal/券商的账单，留着有用但不需要天天看。

### `Inbox/Newsletter`

Newsletter 占了收件箱的绝大部分体积，却是最不重要的一类。参照 [Jason Becker](https://json.blog/2025/04/13/mail-rules-on-fastmail-that.html?ref=blog.buxx.me) 的思路，用邮件 header 的字段来自动识别 newsletter 类邮件。两条规则的伪代码如下：

```pseudocode
Rule 1:

IF ALL of:
  header:List-Id exists
  anywhere CONTAINS "unsubscribe"
  sender IS NOT a contact
THEN move to Inbox/Newsletter

---

Rule 2:

IF header:List-Unsubscribe exists
THEN move to Inbox/Newsletter
```

### Netflix 验证码

还有一条比较有意思的规则：Netflix 的登录验证码自动转发给和我拼车的朋友。这种小需求用邮件规则实现最为优雅。

```pseudocode
IF ALL of:
  to/cc/bcc IS EXACTLY "接收 Netflix 验证码的邮箱"
  subject MATCHES REGULAR EXPRESSION /Your Netflix temporary access code|Netflix: Your sign-in code|您的 Netflix 临时访问代码|Netflix：您的登录代码/
THEN forward to [车友邮箱1, 车友邮箱2]
```

### 垃圾邮件

对于垃圾邮件，我的态度很简单：不想再看的邮件立刻退订，马上点击 Unsubscribe 或者 Block 掉。Block 行为也是基于规则，被规则拦截的发件人会被分流到 Blocked 文件夹。

收件箱不是 To Do List，所以搞 100 个文件夹配上复杂如[梅田駅](https://subway.osakametro.co.jp/station_guide/m/m16/map.php?ref=blog.buxx.me)的规则，没有更多意义。搜索栏能高效地处理你的查找需求，只要确保打了合适的、你记得住的标签。自动化分流能帮你把低优先级的垃圾挪出视野，该退订的就退订，该设规则的设规则。我目前的文件夹结构偏克制，加上语义化的搜索以及 AI Agent 的加持就十分高效。

## MCP 与 AI Agent

[Fastmail 提供了 MCP 集成](https://www.fastmail.com/blog/an-mcp-server-for-fastmail/?ref=blog.buxx.me)，提供了丰富的工具让 AI agents 直接操作邮箱。我给 Claude 接了这个 MCP，目前用得最多的几个场景：**用自然语言搜索邮件**，不用自己拼搜索语法。让 agent **帮忙起草正式邮件**，出完内容再讨论修改，最后直接把草稿放进 Drafts。**给重要邮件做 memo 标注**，让 agent 把这封邮件现在的状态和下一步动作写下来，附在邮件本身上，管理工作流很高效。

在 MCP 之前，我用的是 Fastmail 的 API token，给我的 OpenClaw 调用。这套 API 是 JMAP 协议，文档写得清楚，接起来不复杂。

但这里就要说到 Fastmail 不完美的地方了。

## 封号事故

三月份的某一天，我登录 Fastmail，页面只显示一句话：「Login disabled, contact support.」额，我被封号了。但我依然不相信一个付费邮箱服务还tm封号的。

联系客服之后得知（客服居然是活人），Fastmail 因为近期大量诈骗账号注册，收紧了自动检测机制，我的账号被误判为违反 ToS。客服推测触发原因可能和我频繁使用 API 以及创建大量 Masked Email 有关。讽刺的是，这两个都是 Fastmail 自己提供的卖点以及鼓励使用的功能。

整个申诉过程折腾了将近一周，这一周期间我的主邮箱完全不可用。一周后终于解锁，客服道歉了事。

Email 就像生活的基础设施。把这样重要的工具托管给第三方服务，最担心的就是这种事。Reddit 上也有用户反映过类似情况[[7]](#fn7)，有的甚至没有得到申诉机会。Fastmail 的产品我依然喜欢，但这次经历让我知道，再好的产品和服务也会随意地把你锁在门外。

## 写在最后

Fastmail 让我开始用实用性的眼光看问题。以前我总觉得要么找到一个什么都满足的完美工具，要么折腾一番还是回到原点。Fastmail 满足了我大部分需求，同时也有一些小瑕疵。但这套围绕它搭建的邮箱管理体系：All in One，域名邮箱、多 alias、规则分流、MCP agent，已经让我的收件箱从一个看着都烦的💩山变成了一个基本不需要操心的成熟系统。打开收件箱的时候，我所看到的基本都是值得看的东西。这就够了。

**没收一分钱** lol

---

1. Spark (Readdle 开发) 的隐私文档承认，为了支持推送通知和跨设备同步，Spark 会同步邮件主题和部分正文内容，加密后存储在其服务器上，并在发送通知后 4 小时内删除这部分数据。AI 功能方面,官方说明是只有与查询直接相关的少数邮件会被发送给第三方 AI 提供商处理，而不是整个收件箱，但这些邮件仍会在 AI 提供商的服务器上保留一段时间用于滥用监测。我用 Surge 抓包后实测，Spark 的隐私架构与纯本地客户端有本质区别，它会把元数据和推送通知负载同步到 Readdle 的服务器以支持跨设备功能，包括主题行、部分正文和发件人信息。换句话说，即便内容是加密的，数据本身确实离开了设备，这是很多注重隐私的用户在社区讨论中反复提到的顾虑。 [↩︎](#fnref1)
2. Proton Mail 免费版不支持标准的 IMAP、POP3、SMTP，无法直接接入 Apple Mail 等第三方客户端，只能用官方网页版和手机 App。接入第三方客户端需升级付费版，使用 [Proton Mail Bridge](https://github.com/ProtonMail/proton-bridge?ref=blog.buxx.me) 本地程序，在后台将 Proton 的加密邮箱转译成标准 IMAP/SMTP 给客户端调用，原理上是本地解密再转发，官方称密码本身不离开本机。且Bridge 只支持桌面，手机端完全用不了，只能使用 Proton 自己的 App。在桌面使用必须让它一直挂在后台，Bridge 出问题，客户端就会直接断连。社区长期反馈里也提到过文件夹同步的 bug、UID 处理问题,以及新版本重写 IMAP 库之后才逐步稳定下来这些细节。 [↩︎](#fnref2)
3. [Gmail 帮助中心：自动向其他账号转发 Gmail 邮件](https://support.google.com/mail/answer/10957?ref=blog.buxx.me) [↩︎](#fnref3)
4. [Apple 官方开发者公告](https://developer.apple.com/news/?id=sus6t6ab&ref=blog.buxx.me)称，从 2026 年夏天晚些时候开始，"用 Apple 登录"和 iCloud+ Hide My Email 生成的新地址会统一使用 private.icloud.com 新域名，此前分别用的 privaterelay.appleid.com 和 icloud.com 上的旧地址不受影响。 [↩︎](#fnref4)
5. 是本文做出的技术性推断。开发者只需要屏蔽 `@private.icloud.com` 的注册即可屏蔽全部 iCloud 掩码邮箱。 [↩︎](#fnref5)
6. [Fastmail Blog: Push email now available in iOS Mail](https://www.fastmail.com/blog/push-email-now-available-in-ios-mail/?ref=blog.buxx.me) [↩︎](#fnref6)
7. [Reddit: fastmail close my account no response](https://www.reddit.com/r/fastmail/comments/1fhtssi/fastmail_close_my_account_no_response/?ref=blog.buxx.me) [↩︎](#fnref7)