系统与基础设施unencumberedbyfacts.com
JMAP：像 IMAP 但又不完全是
JMAP: Like IMAP but Not Really
2019 — 2022，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇文章介绍 JMAP——由 FastMail 主导、已在 IETF 标准化的新邮件访问协议，用 HTTP/JSON 替代老旧的 IMAP。作者指出它虽常被拿来与 IMAP 类比，但实际设计理念并不相同。多年后回看，JMAP 虽已标准化，却主要停留在 FastMail 生态内，未被 Gmail、Outlook 等主流服务商采纳。
为什么经久不衰：它记录了邮件协议领域一次罕见的标准创新尝试，也折射出开放协议在巨头垄断下推广的困境，对关注邮件系统和协议设计的人仍有参考价值。
HN 评论精选
JMAP 源自 FastMail，正在 IETF 标准化，基于 HTTP 对移动端友好，令人期待。
FastMail 是这个协议背后的推手，据我所知 JMAP 是从他们的网页界面演化而来的。我是 FastMail 的满意用户。看到这个新协议令人兴奋，因为 JMAP 正在 IETF 标准化，看到新标准被开发出来真是令人耳目一新。据我了解 JMAP 对移动端很友好：它把通知排除在外，你应该用移动平台自带的机制实现通知；通过 JMAP 交互就是普通的 HTTP 请求，非常酷。我完全可以想象用它实现一个简单的邮件客户端来自动化在线服务，比如给网站做邮件回复系统。
bad_user查看英文原文
FastMail is behind this protocol and from what I've read JMAP has evolved out of their web interface. I've been a happy customer, even though lately I flirted with going back to GSuite for my personal email, but after a trial realized that Gmail does many things well, except for being a good email service. So I went back to FastMail and renewed for another 2 years. Seeing this new protocol is exciting, because JMAP is being standardized at IETF. A breath of fresh air to see a new standard being developed. Also from what I understand JMAP should be friendly for mobile usage. They kept notifications out of it, you're supposed to implement notifications using whatever the mobile platform provides. Interacting via JMAP is via plain HTTP requests, which is super cool. I can totally see myself implementing a simple email client for automating online services. For example if you implement a commenting system for a website, you might want to do replies by email. That would be a cool project for me to try out. I wonder if FastMail exposes JMAP publicly yet. Haven't seen any mentions in their admin or docs thus far.
JMAP 自定义 POST 操作更像 RPC/SOAP，称其为 REST 名不副实。
把 JMAP 描述成 REST 真的很奇怪。在 HTTP POST 上定义自己的操作，正是 SOAP 和其他 RPC 风格的 Web 服务做的事，恰恰不是 REST。大概因为 REST 缺乏正式标准，这个词最后被用在了所有东西上。
pedrocr查看英文原文
>JMAP is a REST API so it uses HTTP requests and responses to issue commands and get the results. Almost all requests in JMAP are to the same URL using an HTTP POST to submit a JSON body of “methods”. Describing this as REST is really strange. Defining your own operations over an HTTP POST is what SOAP and other RPC style web services do and specifically what REST isn't. But I guess that a lack of a standard behind REST ended up with the term being used for everything.
多年过去 JMAP 仍局限于 FastMail，缺乏主流服务商和客户端支持，前景黯淡。
JMAP 几年前听起来很有前景，作为标准发布也很棒，但它似乎只会停留在 FastMail 内部使用。我没看到 Outlook365、Gmail 甚至 Apple 宣布实现 JMAP，也没看到小型付费邮件服务商支持它。像 Thunderbird 这样流行的客户端也还没开始实现 JMAP，原因之一是 JMAP 的客户端和服务器文档已经好几年没更新了。所以是的，JMAP 像 IMAP，但又不真是。我们可能需要一个足够受欢迎的 JMAP 继任者。
newscracker查看英文原文
JMAP sounded promising several years ago, and it was great to hear it published as a standard. But it seems like it’ll just remain as what Fastmail (the email provider) uses. Maybe the JMAP team is very small and can’t get more people. Maybe Fastmail doesn’t have enough money and/or enough interest to make it easier to use and to evangelize it with major email providers and email client developers. I don’t see Outlook365 or Gmail (or even Apple for its iCloud email that has a relatively smaller user base) announcing any implementations of JMAP on their services. I don’t see smaller paid email service providers announce support for it. As it stands now, I don’t see a future for JMAP outside of Fastmail. A popular client like Mozilla Thunderbird still hasn’t started implementing JMAP [1] and one of the reasons is because…the client and server documentation for JMAP haven’t been updated for a few years. [2] So yeah, JMAP is like IMAP, but not really. We probably need a successor to JMAP that is liked enough to be implemented by email service providers and by email clients. [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1322991 [2]: https://github.com/jmapio/jmap/issues/323
JMAP 的 HTTP/JSON 思路可取，但协议本身是为 FastMail 临时拼凑的，设计糟糕。
作为分布式系统的爱好者，我很喜欢 SMTP 这种联邦式协议的简洁，但抱歉，JMAP 是垃圾。HTTP/JSON 部分很好，简化邮件访问的潜力也很好，但 JMAP 协议本身很糟糕——它是为 FastMail 增量构建的，这不是设计协议的方式。它把太多东西拼在一起，既随意又定制化，没有吸收 gRPC 等领域的进展。我们需要从零开始，把访问和通信协议重新设计成一个极其简洁的构建基块。
asim查看英文原文
Whoa I love SMTP and email, as a distributed systems nerd I'm a huge fan of the federated protocol and it's simplicity but JMAP I'm sorry is garbage. The http/json part is great, the potential to simplify email access and use is great, even using DNS SRV records is a potential good use of DNS and a compliment to MX records. But the actual JMAP protocol is horrible. This is something built incrementally for fastmail, it's not how you design a protocol. We need to go back to square one and redesign and access and communication protocol as one thing that's ultra simplistic as a building block and starts with very basic primitives. JMAP combines too many things while being very ad-hoc and custom not taking into account a lot of progress made in things like gRPC protos, etc. Tempted to build it from scratch just to prove a point.
历次讨论
同类还值得读
TTY 揭秘（2008）
The TTY demystified (2008)
经典文章深入剖析了 Unix/Linux 中 TTY 子系统的工作原理，包括线路规程、终端驱动、信号与控制字符等机制。
系统与基础设施上首页 11 次 · 2009–2025linusakesson.net编辑精选为什么 GNU grep 这么快
Why GNU grep is Fast
FreeBSD 邮件列表上一篇广为流传的帖子，解释 GNU grep 为什么快：核心在于 Boyer-Moore 字符串搜索算法配合精心优化的内部循环和 I/O，让程序在搜索时“…
系统与基础设施上首页 9 次 · 2010–2022lists.freebsd.orgXplain：为普通人讲解 X11
Xplain – Explaining X11 for the rest of us
《Xplain》是作者（HN 用户 Jasper_）写的一系列 X11 长文，用他在浏览器中重建的 X11 绘图模型做交互演示，讲解 X11 的绘图模型与窗口系统设计。
系统与基础设施上首页 6 次 · 2013–2020magcius.github.io编辑精选旋风教程：为 Linux 创建极小 ELF 可执行文件（1999）
A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux (1999)
breadbox 写于 1999 年的经典教程，主题是如何为 Linux 手工构造并裁剪出体积极小的 ELF 可执行文件。
系统与基础设施上首页 6 次 · 2007–2025muppetlabs.comPostgreSQL 内部原理
The internals of PostgreSQL
《The Internals of PostgreSQL》是一本免费在线书籍，系统讲解 PostgreSQL 的内部实现，包括查询处理、并发控制、WAL、缓冲区管理等核心机制。
系统与基础设施上首页 5 次 · 2017–2025interdb.jp编辑精选