TmpKit 幕后工作原理:运营一个临时邮箱服务的真实细节

2026年7月6日

更新于 2026年7月19日

#工程实现#临时邮箱#SMTP#幕后
TmpKit 幕后工作原理:运营一个临时邮箱服务的真实细节

大多数临时邮箱网站用营销话术介绍自己,然后就没有然后了。TmpKit 由一名开发者独立开发和运营,所以我可以做一件更有意思的事:带你走一遍从别人点击"发送"到邮件出现在你一次性收件箱之间真实发生的事情。如果你好奇过这类服务到底是魔法还是管道——答案是管道,图纸在这里。

发件方
  │  1. 查询 DNS MX

TmpKit SMTP 接收层(go-guerrilla)
  │  2. 接收并解析 RFC 5322 邮件
  ├──────────────► SQL:路由元数据与查询记录
  └──────────────► Redis:带 TTL 的压缩原始正文

浏览器 ── 会话 Cookie ──► API 校验会话 + 收件地址
  ▲                      │
  └──── 清理后的 HTML + 代理远程图片 ─────────────┘

实现快照:2026 年 7 月 19 日

下面是从代码直接核对的数值,不是营销估算:

| 控制项 | 当前实现 | | --- | --- | | 会话标识 | 16 个随机字节(32 位十六进制字符) | | 默认地址前缀 | 4 个随机字节(8 位十六进制字符) | | 会话 Cookie | HttpOnlySameSite=Strict,生产环境使用 Secure | | 默认有效窗口 | 3,600 秒;生产配置可以覆盖 | | 默认延长次数 | 一次;生产配置可以覆盖 | | 收件箱访问校验 | 有效会话 Cookie 收件地址匹配 | | HTML 隔离 | DOM 允许列表 + 空权限 sandbox iframe | | 一次性域名快照 | 7,892 条,来自 CC0 上游列表 | | 实时 DNS 超时 | 5 秒 |

产品与工具方法论会持续维护这些控制项及其局限的代码级说明。

一封邮件的旅程

假设你用 TmpKit 地址在某个网站注册,对方系统给你发了一封验证码邮件。接下来依次发生五件事。

1. DNS 指路。 发件方的邮件服务器查询你临时地址所属域名的 MX 记录,这些记录指向我们的邮件服务器。这是最标准的邮件基础设施——和任何人给你的 Gmail 发信时发生的查询一模一样,规则定义在 RFC 5321 中。

2. TmpKit 运营的 SMTP 接收层收下邮件。 接收层基于开源的 Go 语言 SMTP 服务器 go-guerrilla 构建。和任何生产网站一样,它依赖网络、DNS、托管、数据库和安全服务商,而不是声称“完全没有第三方”。域名配置为 catch-all(全收):发往 @ 前任何名字的邮件都会被接受。这正是临时邮箱服务无需预先创建邮箱就能发放无限地址的全部秘密——DNS 层面的细节我们在 catch-all 域名的工作原理里讲过。

3. 邮件被解析并短暂存储。 路由元数据写入 SQL,压缩后的原始邮件可放入带 TTL 的 Redis,供网页界面解析信头、正文和附件。API 只返回收件地址与有效会话匹配的邮件。这是一个中转区,不是档案库;实际有效窗口以界面显示为准。

4. 你的会话认领它。 你打开 TmpKit 时,服务器会生成一个与地址绑定的密码学随机会话。会话保存在 Redis 里并带硬性过期时间:代码默认值为一小时,默认配置允许延长一次。会话键和原始正文缓存由 Redis TTL 到期;另一个独立限频的清理过程删除超过有效窗口的 SQL 记录,删除按钮也能更早移除指定邮件。部署可以调整默认值,因此应用内倒计时才是当前会话的准确信息。

5. 你的浏览器取到邮件。 会话有效期间,收件箱页面每十秒轮询一次新邮件(会话失效后自动暂停——没必要为一个已经消失的收件箱空烧请求)。新邮件通常在送达后几秒内出现。

刻意的设计决策

这条管道里有几个选择值得展开说,因为隐私恰恰是在这些地方被决定的。

只收不发,是设计而非缺陷。 TmpKit 无法发送邮件。这不是没做完的功能——一个匿名的外发邮件服务一周之内就会沦为垃圾邮件大炮,负责任地运营它是不可能的。只收不发让滥用面尽可能小,也让使用场景保持诚实。

远程图片走代理加载。 营销邮件酷爱跟踪像素:一张 URL 里编码了邮件标识的一像素图片,浏览器直接请求就可能向发件方暴露阅读者的 IP 地址和阅读时间。TmpKit 在清理后的邮件进入 sandbox iframe 前,把远程图片 URL 改写为同源代理。这降低了浏览器直接连接发件方的追踪风险,但不构成匿名承诺。附件从 TmpKit 保存的副本通过会话校验接口下载,仍必须视为不可信文件。

没有收件箱账号,不等于“没有数据”。 这里无需注册收件箱,所以 TmpKit 不会要求常见的姓名、密码或找回手机号。但为了交付和保护服务,TmpKit 与基础设施仍需处理临时地址、邮件、会话 ID、IP 以及请求和安全数据。隐私政策说明了这些类别和保留边界。这也是为什么任何将来需要找回的东西都绝不该用临时地址注册;安全使用规则详细列出了一次性收件箱不适用的场景。

短保留期本身就是功能。 把邮件存一个月在技术上轻而易举。我们不这么做,因为每一封被存储的邮件对你和对我们都是一份负债。一小时默认时长(外加一次延长)恰好覆盖真实的使用场景——收一个验证码或下载链接——而不会让服务变成一座无意间建成的他人邮件档案馆。

没人告诉你的那部分:域名运营

运营临时邮箱服务真正难的部分不是软件,而是我们在网站为什么屏蔽一次性邮箱里描述的那整个检测产业,正日夜不停地识别你的域名并把它们加进黑名单。一个域名火起来几周之内,各家注册表单就会开始拒绝它。

这就是域名轮换背后的经济学,也塑造了每家服务商都要面对的取舍:新域名在更多网站上可用,但毫无历史记录;老域名稳定,但被拦截得越来越多。当任何服务商的地址被拒收时,你看到的就是这场军备竞赛——你甚至可以用一次性域名检测器查查某个域名当前的处境。

为什么要写这篇文章?

因为对隐私工具的信任不应该建立在盲信上。现在你知道了发往 TmpKit 地址的邮件会经历什么:由 TmpKit 运营的 SMTP 接收层收下,在短期存储和查询元数据之间拆分,只向匹配的有效会话开放,展示前进行清理,并通过 TTL 与清理流程删除。图片代理减少一种常见追踪路径,但不会假装整个服务是匿名的。没有魔法——只有边界写清楚、刻意设计得短命的管道。

对以上任何环节有疑问?关于页面介绍了服务由谁运营,联系表单的另一端是写下这些代码的人。