[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"content-a-frustrating-experience-with-imap":3,"$f2210dxdyggmbu":21},{"id":4,"type":5,"slug":6,"title":7,"date":8,"category":9,"tags":10,"body_markdown":13,"permalink":14,"excerpt_src":14,"media_type":14,"media_title":14,"media_author":14,"media_url":14,"rating":14,"layout":14,"pv":15,"admin_only":15,"created_at":16,"updated_at":16,"deleted_at":14,"status":17,"html":18,"excerpt":19,"cover":20},139,"article","a-frustrating-experience-with-imap","聊一聊与邮件协议IMAP的一段经历","2025-11-04 11:45:00","tech",[11,12],"IMAP","邮件协议","\n> 这不是一篇枯燥的技术文档，应该可以读得下去。\n\n## 引子\n\n很久没更新内容了，一直觉得自己没有资格写太多东西来“教育”大家，因此经常开天窗。\n\n最近见了一些朋友，也读了一些朋友的文字，也开始有了一些新的思考。也许我不需要像写技术文档一样来写文章，也许更随意的一些表达会更真诚，也许我只需要记录一些自己想法和感受就好。\n\n刚好最近花了两三个月的时候折腾完了IMAP协议，好像一块压在胸口几个月的石头终于被搬开了，确实也想写点东西，就当和朋友们聊聊天。\n\n\u003C!-- more -->\n\n## 一个非常古怪的工具：邮箱\n\n是的，之所以会涉及到IMAP协议，是因为我在做一个邮箱产品，如果从代码库中第一次提交算起的话，已经做了快5年了。对，我们要聊一个很重要的问题：为什么是邮箱？\n\n放在2025年来看，邮箱是一个非常古怪的工具。\n\n首先，它是为数不多还在使用分布式架构的应用之一。你可以选择任意一个邮箱服务商，来与全世界任意一个邮箱账号通信，而不必拘泥于某一个服务商。\n\n其次，邮件相关的通信协议非常古老，甚至可以看到远古互联网的影子。假设一下，你想要通过网络发送一封邮件给朋友，你会怎样来通信？\n\n- 你好，我是TooBug，我想给我的朋友发送一封邮件（ELHO TooBug）\n- 好的，TooBug，请告诉我你的邮箱地址（250 ok）\n- 我的邮箱地址是toobug@tinkmail.me（MAIL FROM：\\\u003Ctoobug@tinkmail.me\\>）\n- 好的，请继续（250 ok）\n- 我朋友的邮箱地址是support@tinkmail.me（RCPT TO：\\\u003Csupport@tinkmail.me\\>）\n- 好的，请告诉我邮件的内容（250 ok）\n- 邮件内容是“你好，朋友！”（DATA ......）\n- 好的，TooBug，我已经帮你把邮件发送出去了 （250 ok）\n- 谢谢，再见（QUIT）\n- 再见（221 bye）\n\n这就是发送邮件用的SMTP协议。它可以用人类语言来描述，几乎没有什么技术门槛，四十多年前，人们就是这样发送电子邮件的。\n\n一个如此古老且几乎没怎么升级过的应用层协议，即使有很多潜在的问题，但直到今天仍然在被广泛使用，这实在是令人惊讶。\n\n最后一点很古怪的是，过去二十年，几乎所有的互联网应用的形态都发生了巨大的变化，但唯独邮箱是个例外。\n\n我看到\n\n- 社交产品从BBS、Blog、微博、SNS网络一路演变到微信之类的超级应用\n- 内容消费产品从门户网站、RSS阅读器一路演变到今日的短视频、短剧平台\n- 协作办公产品也从单纯的即时通讯一路演变到今日的会议、文档一体化协作平台\n\n唯独邮箱应用的形态几乎没有什么变化。我们依然在使用Outlook、Thunderbird之类的邮箱客户端，而所有的Web邮箱也几乎都长得和这些客户端一模一样。\n\n你说说，是不是很古怪？\n## 邮箱产品的机会和挑战\n\n如果你读到了这里，应该会微微点头：确实，邮箱好多年没有变化了，那邮箱产品到底有什么机会呢？\n\n稍微思考一下就能发现很多普遍但不合理的事情：\n\n- 钓鱼和欺诈邮件如此普遍，但邮箱服务商却几乎没有为用户提供有价值的辅助判断工具，甚至有很多问题正是由于邮件展示的形态所导致的\n- 邮件几乎没有任何协作和任务管理功能，哪怕是标注稍后处理这样简单的功能也没有\n- 邮件的回复和转发链条如此混乱，阅读体验如此之差，但邮箱服务商却几乎没有提供任何工具来改善\n\n这里面能列出来的点还有非常多，每一项都意味着机会。\n\n但是，世上的事哪有这么容易的呢？几十年没有变化，有可能是有人忽略了一些事情，但也有可能是背后隐藏着很多死路。\n\n以我的能力，尚不足以靠推演来判断这些机会和陷阱到底在哪里。我只能说，看到了有人在尝试改进这些产品形态，也获得了一些成果。\n\n而最重要的是，我认为这里值得做出一些改变。先让改变发生，进而产生价值，最后收获成果，道阻且长。\n\n## 关于IMAP\n\n聊回IMAP。这是一个客户端用来收取邮件的协议，它也是一个基于文本的协议，但是复杂度却要高非常多。要完整实现所有的能力，需要先读58个RFC技术文档，然后一一用代码实现它们。\n\n我在2023年基于开源的wildduck模块实现了一版IMAP协议，只包含了最基本的能力。今年，我的邮箱产品有了一些来自海外的用户，并开始反馈IMAP的问题，于是我决定暂停一下，先把IMAP好好修一下，再继续其它特性的迭代。\n\n我从8月份开始啃IMAP协议的文档和实现，过程无比艰辛，几乎用上了我之前工作中所用到的全部的调试手段：\n\n- 打日志、打断点\n- 用WireShark抓包\n- 搭MITM代理抓包\n-  用Nginx搭建TCP代理来抓包\n- 自定义DNS服务器来调试移动端\n- 使用纯TCP协议来搭建mock服务器确认问题\n- 使用AI协助分析代码实现和数据包\n\n总之，过程非常艰辛，很多时候我认为完全没有问题的地方，客户端就会罢工。因此也时常会陷入自我怀疑的情绪中：是不是我不应该选择邮件这么难的一个领域？是不是我真的很不擅长协议调试？是不是我其实掌握不了这么复杂的协议？\n\n你知道，人一旦陷入自我怀疑的情绪中，就会带动方方面面的状态都变得很差：脾气不好，没有耐心，身体状态很差等等。\n\n这并不是我所期待的生活状态或者工作状态，因此一边被这种情绪所控制，一边又得不停安慰自己：没事的，多给自己一些时间，没有bug是修不好的。就像以前上班的时候，也经常碰到让人很绝望的bug，但最终每一次都会修好，这次也不例外。\n\n这个过程中也碰到过非常无语的事情，比如QQ邮箱的客户端，自己没有遵守规范，在请求时使用了小写的`uid`，却在碰到服务端返回的小写`uid`时直接罢工。大有一副“我这么做可以，但你这么做就是你的不对了”的面孔。以至于我一怒之下专门写了一个帖子罗列QQ邮箱在协议实现上的种种问题。\n\n好在，最终我找到了这些兼容问题，完善了这个协议的实现，最终让主流邮件客户端都能兼容。那天是10月29日，我发了一条推文：\n\n> 继续磕IMAP协议，又一个月过去了，终于可以告一段落了。 抓包和调试协议这个事情让我沮丧和自我怀疑了几个月，好在一点一点扒出来了。 现在请叫我IMAP协议专家，没有任何AI可以在IMAP协议实现上挑战我的地位！\n\n是的，这修的不是IMAP协议，而是生活呀。不急不躁，慢慢过，都会好的。\n",null,0,"2026-08-28 04:37:17","published","\u003Cblockquote>\n\u003Cp>这不是一篇枯燥的技术文档，应该可以读得下去。\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Ch2>引子\u003C\u002Fh2>\n\u003Cp>很久没更新内容了，一直觉得自己没有资格写太多东西来“教育”大家，因此经常开天窗。\u003C\u002Fp>\n\u003Cp>最近见了一些朋友，也读了一些朋友的文字，也开始有了一些新的思考。也许我不需要像写技术文档一样来写文章，也许更随意的一些表达会更真诚，也许我只需要记录一些自己想法和感受就好。\u003C\u002Fp>\n\u003Cp>刚好最近花了两三个月的时候折腾完了IMAP协议，好像一块压在胸口几个月的石头终于被搬开了，确实也想写点东西，就当和朋友们聊聊天。\u003C\u002Fp>\n\u003Ch2>一个非常古怪的工具：邮箱\u003C\u002Fh2>\n\u003Cp>是的，之所以会涉及到IMAP协议，是因为我在做一个邮箱产品，如果从代码库中第一次提交算起的话，已经做了快5年了。对，我们要聊一个很重要的问题：为什么是邮箱？\u003C\u002Fp>\n\u003Cp>放在2025年来看，邮箱是一个非常古怪的工具。\u003C\u002Fp>\n\u003Cp>首先，它是为数不多还在使用分布式架构的应用之一。你可以选择任意一个邮箱服务商，来与全世界任意一个邮箱账号通信，而不必拘泥于某一个服务商。\u003C\u002Fp>\n\u003Cp>其次，邮件相关的通信协议非常古老，甚至可以看到远古互联网的影子。假设一下，你想要通过网络发送一封邮件给朋友，你会怎样来通信？\u003C\u002Fp>\n\u003Cul>\n\u003Cli>你好，我是TooBug，我想给我的朋友发送一封邮件（ELHO TooBug）\u003C\u002Fli>\n\u003Cli>好的，TooBug，请告诉我你的邮箱地址（250 ok）\u003C\u002Fli>\n\u003Cli>我的邮箱地址是toobug@tinkmail.me（MAIL FROM：<toobug@tinkmail.me>）\u003C\u002Fli>\n\u003Cli>好的，请继续（250 ok）\u003C\u002Fli>\n\u003Cli>我朋友的邮箱地址是support@tinkmail.me（RCPT TO：<support@tinkmail.me>）\u003C\u002Fli>\n\u003Cli>好的，请告诉我邮件的内容（250 ok）\u003C\u002Fli>\n\u003Cli>邮件内容是“你好，朋友！”（DATA ......）\u003C\u002Fli>\n\u003Cli>好的，TooBug，我已经帮你把邮件发送出去了 （250 ok）\u003C\u002Fli>\n\u003Cli>谢谢，再见（QUIT）\u003C\u002Fli>\n\u003Cli>再见（221 bye）\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>这就是发送邮件用的SMTP协议。它可以用人类语言来描述，几乎没有什么技术门槛，四十多年前，人们就是这样发送电子邮件的。\u003C\u002Fp>\n\u003Cp>一个如此古老且几乎没怎么升级过的应用层协议，即使有很多潜在的问题，但直到今天仍然在被广泛使用，这实在是令人惊讶。\u003C\u002Fp>\n\u003Cp>最后一点很古怪的是，过去二十年，几乎所有的互联网应用的形态都发生了巨大的变化，但唯独邮箱是个例外。\u003C\u002Fp>\n\u003Cp>我看到\u003C\u002Fp>\n\u003Cul>\n\u003Cli>社交产品从BBS、Blog、微博、SNS网络一路演变到微信之类的超级应用\u003C\u002Fli>\n\u003Cli>内容消费产品从门户网站、RSS阅读器一路演变到今日的短视频、短剧平台\u003C\u002Fli>\n\u003Cli>协作办公产品也从单纯的即时通讯一路演变到今日的会议、文档一体化协作平台\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>唯独邮箱应用的形态几乎没有什么变化。我们依然在使用Outlook、Thunderbird之类的邮箱客户端，而所有的Web邮箱也几乎都长得和这些客户端一模一样。\u003C\u002Fp>\n\u003Cp>你说说，是不是很古怪？\u003C\u002Fp>\n\u003Ch2>邮箱产品的机会和挑战\u003C\u002Fh2>\n\u003Cp>如果你读到了这里，应该会微微点头：确实，邮箱好多年没有变化了，那邮箱产品到底有什么机会呢？\u003C\u002Fp>\n\u003Cp>稍微思考一下就能发现很多普遍但不合理的事情：\u003C\u002Fp>\n\u003Cul>\n\u003Cli>钓鱼和欺诈邮件如此普遍，但邮箱服务商却几乎没有为用户提供有价值的辅助判断工具，甚至有很多问题正是由于邮件展示的形态所导致的\u003C\u002Fli>\n\u003Cli>邮件几乎没有任何协作和任务管理功能，哪怕是标注稍后处理这样简单的功能也没有\u003C\u002Fli>\n\u003Cli>邮件的回复和转发链条如此混乱，阅读体验如此之差，但邮箱服务商却几乎没有提供任何工具来改善\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>这里面能列出来的点还有非常多，每一项都意味着机会。\u003C\u002Fp>\n\u003Cp>但是，世上的事哪有这么容易的呢？几十年没有变化，有可能是有人忽略了一些事情，但也有可能是背后隐藏着很多死路。\u003C\u002Fp>\n\u003Cp>以我的能力，尚不足以靠推演来判断这些机会和陷阱到底在哪里。我只能说，看到了有人在尝试改进这些产品形态，也获得了一些成果。\u003C\u002Fp>\n\u003Cp>而最重要的是，我认为这里值得做出一些改变。先让改变发生，进而产生价值，最后收获成果，道阻且长。\u003C\u002Fp>\n\u003Ch2>关于IMAP\u003C\u002Fh2>\n\u003Cp>聊回IMAP。这是一个客户端用来收取邮件的协议，它也是一个基于文本的协议，但是复杂度却要高非常多。要完整实现所有的能力，需要先读58个RFC技术文档，然后一一用代码实现它们。\u003C\u002Fp>\n\u003Cp>我在2023年基于开源的wildduck模块实现了一版IMAP协议，只包含了最基本的能力。今年，我的邮箱产品有了一些来自海外的用户，并开始反馈IMAP的问题，于是我决定暂停一下，先把IMAP好好修一下，再继续其它特性的迭代。\u003C\u002Fp>\n\u003Cp>我从8月份开始啃IMAP协议的文档和实现，过程无比艰辛，几乎用上了我之前工作中所用到的全部的调试手段：\u003C\u002Fp>\n\u003Cul>\n\u003Cli>打日志、打断点\u003C\u002Fli>\n\u003Cli>用WireShark抓包\u003C\u002Fli>\n\u003Cli>搭MITM代理抓包\u003C\u002Fli>\n\u003Cli>用Nginx搭建TCP代理来抓包\u003C\u002Fli>\n\u003Cli>自定义DNS服务器来调试移动端\u003C\u002Fli>\n\u003Cli>使用纯TCP协议来搭建mock服务器确认问题\u003C\u002Fli>\n\u003Cli>使用AI协助分析代码实现和数据包\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>总之，过程非常艰辛，很多时候我认为完全没有问题的地方，客户端就会罢工。因此也时常会陷入自我怀疑的情绪中：是不是我不应该选择邮件这么难的一个领域？是不是我真的很不擅长协议调试？是不是我其实掌握不了这么复杂的协议？\u003C\u002Fp>\n\u003Cp>你知道，人一旦陷入自我怀疑的情绪中，就会带动方方面面的状态都变得很差：脾气不好，没有耐心，身体状态很差等等。\u003C\u002Fp>\n\u003Cp>这并不是我所期待的生活状态或者工作状态，因此一边被这种情绪所控制，一边又得不停安慰自己：没事的，多给自己一些时间，没有bug是修不好的。就像以前上班的时候，也经常碰到让人很绝望的bug，但最终每一次都会修好，这次也不例外。\u003C\u002Fp>\n\u003Cp>这个过程中也碰到过非常无语的事情，比如QQ邮箱的客户端，自己没有遵守规范，在请求时使用了小写的\u003Ccode>uid\u003C\u002Fcode>，却在碰到服务端返回的小写\u003Ccode>uid\u003C\u002Fcode>时直接罢工。大有一副“我这么做可以，但你这么做就是你的不对了”的面孔。以至于我一怒之下专门写了一个帖子罗列QQ邮箱在协议实现上的种种问题。\u003C\u002Fp>\n\u003Cp>好在，最终我找到了这些兼容问题，完善了这个协议的实现，最终让主流邮件客户端都能兼容。那天是10月29日，我发了一条推文：\u003C\u002Fp>\n\u003Cblockquote>\n\u003Cp>继续磕IMAP协议，又一个月过去了，终于可以告一段落了。 抓包和调试协议这个事情让我沮丧和自我怀疑了几个月，好在一点一点扒出来了。 现在请叫我IMAP协议专家，没有任何AI可以在IMAP协议实现上挑战我的地位！\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Cp>是的，这修的不是IMAP协议，而是生活呀。不急不躁，慢慢过，都会好的。\u003C\u002Fp>\n","\u003Cblockquote>\n\u003Cp>这不是一篇枯燥的技术文档，应该可以读得下去。\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Ch2>引子\u003C\u002Fh2>\n\u003Cp>很久没更新内容了，一直觉得自己没有资格写太多东西来“教育”大家，因此经常开天窗。\u003C\u002Fp>\n\u003Cp>最近见了一些朋友，也读了一些朋友的文字，也开始有了一些新的思考。也许我不需要像写技术文档一样来写文章，也许更随意的一些表达会更真诚，也许我只需要记录一些自己想法和感受就好。\u003C\u002Fp>\n\u003Cp>刚好最近花了两三个月的时候折腾完了IMAP协议，好像一块压在胸口几个月的石头终于被搬开了，确实也想写点东西，就当和朋友们聊聊天。\u003C\u002Fp>\n","",{"total":15,"totalRoots":15,"comments":22,"pv":15},[]]