聊一聊与邮件协议IMAP的一段经历

2025年11月4日

这不是一篇枯燥的技术文档，应该可以读得下去。

引子

很久没更新内容了，一直觉得自己没有资格写太多东西来“教育”大家，因此经常开天窗。

最近见了一些朋友，也读了一些朋友的文字，也开始有了一些新的思考。也许我不需要像写技术文档一样来写文章，也许更随意的一些表达会更真诚，也许我只需要记录一些自己想法和感受就好。

刚好最近花了两三个月的时候折腾完了IMAP协议，好像一块压在胸口几个月的石头终于被搬开了，确实也想写点东西，就当和朋友们聊聊天。

是的，之所以会涉及到IMAP协议，是因为我在做一个邮箱产品，如果从代码库中第一次提交算起的话，已经做了快5年了。对，我们要聊一个很重要的问题：为什么是邮箱？

放在2025年来看，邮箱是一个非常古怪的工具。

首先，它是为数不多还在使用分布式架构的应用之一。你可以选择任意一个邮箱服务商，来与全世界任意一个邮箱账号通信，而不必拘泥于某一个服务商。

其次，邮件相关的通信协议非常古老，甚至可以看到远古互联网的影子。假设一下，你想要通过网络发送一封邮件给朋友，你会怎样来通信？

这就是发送邮件用的SMTP协议。它可以用人类语言来描述，几乎没有什么技术门槛，四十多年前，人们就是这样发送电子邮件的。

一个如此古老且几乎没怎么升级过的应用层协议，即使有很多潜在的问题，但直到今天仍然在被广泛使用，这实在是令人惊讶。

最后一点很古怪的是，过去二十年，几乎所有的互联网应用的形态都发生了巨大的变化，但唯独邮箱是个例外。

我看到

唯独邮箱应用的形态几乎没有什么变化。我们依然在使用Outlook、Thunderbird之类的邮箱客户端，而所有的Web邮箱也几乎都长得和这些客户端一模一样。

你说说，是不是很古怪？

如果你读到了这里，应该会微微点头：确实，邮箱好多年没有变化了，那邮箱产品到底有什么机会呢？

稍微思考一下就能发现很多普遍但不合理的事情：

这里面能列出来的点还有非常多，每一项都意味着机会。

但是，世上的事哪有这么容易的呢？几十年没有变化，有可能是有人忽略了一些事情，但也有可能是背后隐藏着很多死路。

以我的能力，尚不足以靠推演来判断这些机会和陷阱到底在哪里。我只能说，看到了有人在尝试改进这些产品形态，也获得了一些成果。

而最重要的是，我认为这里值得做出一些改变。先让改变发生，进而产生价值，最后收获成果，道阻且长。

聊回IMAP。这是一个客户端用来收取邮件的协议，它也是一个基于文本的协议，但是复杂度却要高非常多。要完整实现所有的能力，需要先读58个RFC技术文档，然后一一用代码实现它们。

我在2023年基于开源的wildduck模块实现了一版IMAP协议，只包含了最基本的能力。今年，我的邮箱产品有了一些来自海外的用户，并开始反馈IMAP的问题，于是我决定暂停一下，先把IMAP好好修一下，再继续其它特性的迭代。

我从8月份开始啃IMAP协议的文档和实现，过程无比艰辛，几乎用上了我之前工作中所用到的全部的调试手段：

总之，过程非常艰辛，很多时候我认为完全没有问题的地方，客户端就会罢工。因此也时常会陷入自我怀疑的情绪中：是不是我不应该选择邮件这么难的一个领域？是不是我真的很不擅长协议调试？是不是我其实掌握不了这么复杂的协议？

你知道，人一旦陷入自我怀疑的情绪中，就会带动方方面面的状态都变得很差：脾气不好，没有耐心，身体状态很差等等。

这并不是我所期待的生活状态或者工作状态，因此一边被这种情绪所控制，一边又得不停安慰自己：没事的，多给自己一些时间，没有bug是修不好的。就像以前上班的时候，也经常碰到让人很绝望的bug，但最终每一次都会修好，这次也不例外。

这个过程中也碰到过非常无语的事情，比如QQ邮箱的客户端，自己没有遵守规范，在请求时使用了小写的uid，却在碰到服务端返回的小写uid时直接罢工。大有一副“我这么做可以，但你这么做就是你的不对了”的面孔。以至于我一怒之下专门写了一个帖子罗列QQ邮箱在协议实现上的种种问题。

好在，最终我找到了这些兼容问题，完善了这个协议的实现，最终让主流邮件客户端都能兼容。那天是10月29日，我发了一条推文：

继续磕IMAP协议，又一个月过去了，终于可以告一段落了。抓包和调试协议这个事情让我沮丧和自我怀疑了几个月，好在一点一点扒出来了。现在请叫我IMAP协议专家，没有任何AI可以在IMAP协议实现上挑战我的地位！

是的，这修的不是IMAP协议，而是生活呀。不急不躁，慢慢过，都会好的。