Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JMAP: A modern, open email protocol

ietf.org

Post reply on HN
Print view View original

21–30 of 120 posts

Re: JMAP: A modern, open email protocol

#21

Post by raimue »

jcranmer wrote: post #8
jwr wrote: post #5

I clicked on this with a lot of hope — alas, this only seems to address the "mailbox access" part of E-mail. I think that part actually works fairly well today (not optimally, but well enough in practice). The part that really needs fixing is SMTP.

IMAP is a really broken protocol; I'd characterize it as a database synchronization protocol that wasn't designed to be one. You need to rely on certain extensions to have a hope of being bug-free [1], and even those can be problematic (UIDVALIDITY changed, gotta clear your entire inbox!). [1] The IMAP protocol used to rely heavily on message sequence numbers, where each message in the folder was numbered sequentiall…

The UIDVALIDITY is actually a great design. IMAP servers will usually store the UID mapping in some kind of index that is used even across restarts. Therefore in normal operation this is not a problem. When did you encounter problems with this in every day use?

If the UIDs were not allowed to change, you would run into practical problems on edge cases. What if you switched your IMAP server implementation? What if the index files on server side got corrupt and you had to rebuild them? What if you had a fatal disk failure and had to restore an older backup? Mismatching UIDs would be even worse than a way to indicate to the client that the previously retrieved UIDs and associated messages are no longer valid. UIDVALIDITY is basically just a way for cache invalidation.

Re: JMAP: A modern, open email protocol

#22

Post by verisimilitudes »

satyanash wrote: post #12

If this takes off, it would remove one of the last few holdouts of non-HTTP application specific protocols. That just leaves us with SMTP really. While using HTTP is not necessarily a bad thing, it's certainly an interesting indication of how application developers prefer convention based protocol definitions (JSON over HTTP) instead of having a strictly defined protocol over a duplex stream (IMAP over TCP).

How disconcerting.

>If this takes off, it would remove one of the last few holdouts of non-HTTP application specific protocols.

IRC and FTP come to mind, but yes. It's as if email's being attacked at all angles, lately.

>While using HTTP is not necessarily a bad thing, it's certainly an interesting indication of how application developers prefer convention based protocol definitions (JSON over HTTP) instead of having a strictly defined protocol over a duplex stream (IMAP over TCP).

Using HTTP is a bad thing, I think, because it's a complex protocol and it's entirely unnecessary; JSON is a poor, ad-hoc format that isn't optimal for parsing. I don't believe developers ''prefer'' any of this so much as it's being forced on them.

You can really only define things rigidly if you want to make much in the way of guarantees. Any system held together by conventions can have those conventions violated and this is a harrowing sign of things to come.

Re: JMAP: A modern, open email protocol

#23

Post by detaro »

jolmg wrote: post #19
icebraining wrote: post #17

Earlier quoted context omitted.

https://jmap.io/#why-use-https/json ?

Everything mentioned there is because of its ubiquity, nothing about how the way HTTP operates makes it more suitable. What you link even says: > the encoding/transport part of JMAP [i.e. HTTP] is not core to its operation, so future specifications could easily add alternatives So HTTP is useless for this except for the fact that everyone uses it.

"possible to replace with alternatives" != "useless"

Re: JMAP: A modern, open email protocol

#24

Post by jolmg »

verisimilitudes wrote: post #22
satyanash wrote: post #12

If this takes off, it would remove one of the last few holdouts of non-HTTP application specific protocols. That just leaves us with SMTP really. While using HTTP is not necessarily a bad thing, it's certainly an interesting indication of how application developers prefer convention based protocol definitions (JSON over HTTP) instead of having a strictly defined protocol over a duplex stream (IMAP over TCP).

How disconcerting. >If this takes off, it would remove one of the last few holdouts of non-HTTP application specific protocols. IRC and FTP come to mind, but yes. It's as if email's being attacked at all angles, lately. >While using HTTP is not necessarily a bad thing, it's certainly an interesting indication of how application developers prefer convention based protocol definitions (JSON over HTTP) instead of having…

> IRC and FTP come to mind

They're niche now, though.

HTTP and email protocols are probably the only open protocols that almost everyone uses.

There's ssh, but it's also arguably niche in comparison.

Re: JMAP: A modern, open email protocol

#25

Post by groovybits »

verisimilitudes wrote: post #22
satyanash wrote: post #12

If this takes off, it would remove one of the last few holdouts of non-HTTP application specific protocols. That just leaves us with SMTP really. While using HTTP is not necessarily a bad thing, it's certainly an interesting indication of how application developers prefer convention based protocol definitions (JSON over HTTP) instead of having a strictly defined protocol over a duplex stream (IMAP over TCP).

How disconcerting. >If this takes off, it would remove one of the last few holdouts of non-HTTP application specific protocols. IRC and FTP come to mind, but yes. It's as if email's being attacked at all angles, lately. >While using HTTP is not necessarily a bad thing, it's certainly an interesting indication of how application developers prefer convention based protocol definitions (JSON over HTTP) instead of having…

> IRC and FTP

IRC and FTP have widely used secure counterparts. Meanwhile, STARTTLS did not gain the traction that everyone hoped it would.

Edit: Additionally, we have secure working replacement protocols for IRC and FTP (such as Matrix and SSH/SCP).

Re: JMAP: A modern, open email protocol

#26

Post by satyanash »

verisimilitudes wrote: post #22
satyanash wrote: post #12

If this takes off, it would remove one of the last few holdouts of non-HTTP application specific protocols. That just leaves us with SMTP really. While using HTTP is not necessarily a bad thing, it's certainly an interesting indication of how application developers prefer convention based protocol definitions (JSON over HTTP) instead of having a strictly defined protocol over a duplex stream (IMAP over TCP).

How disconcerting. >If this takes off, it would remove one of the last few holdouts of non-HTTP application specific protocols. IRC and FTP come to mind, but yes. It's as if email's being attacked at all angles, lately. >While using HTTP is not necessarily a bad thing, it's certainly an interesting indication of how application developers prefer convention based protocol definitions (JSON over HTTP) instead of having…

> You can really only define things rigidly if you want to make much in the way of guarantees. Any system held together by conventions can have those conventions violated and this is a harrowing sign of things to come.

The problem with this is that most new protocols (or APIs as they're popularly known now) are built by startups aiming for rapid growth. Writing an RFC for the underlying protocol of the newfangled dating app you're building is counterproductive if you don't know the company will exist six months later.

Re: JMAP: A modern, open email protocol

#27

Post by jolmg »

groovybits wrote: post #25
verisimilitudes wrote: post #22

Earlier quoted context omitted.

How disconcerting. >If this takes off, it would remove one of the last few holdouts of non-HTTP application specific protocols. IRC and FTP come to mind, but yes. It's as if email's being attacked at all angles, lately. >While using HTTP is not necessarily a bad thing, it's certainly an interesting indication of how application developers prefer convention based protocol definitions (JSON over HTTP) instead of having…

> IRC and FTP IRC and FTP have widely used secure counterparts. Meanwhile, STARTTLS did not gain the traction that everyone hoped it would. Edit: Additionally, we have secure working replacement protocols for IRC and FTP (such as Matrix and SSH/SCP).

STARTTLS is vulnerable to man-in-the-middle and encryption downgrade attacks. Using a distinct port that only allows these application protocols over SSL/TLS (e.g. SMTPS and IMAPS) is better. It's also widely accepted. I don't think there's many that are still running unencrypted SMTP or IMAP connections.

Re: JMAP: A modern, open email protocol

#28

Post by westurner »

What are the optimizations in JMAP that make it faster than, say, Solid? Solid is built on a bunch of W3C Web, Security, and Linked Data Standards; LDP: Linked Data Protocol, JSON-LD: JSON Linked Data, WebID-TLS, REST, WebSockets, LDN: Linked Data Notifications. [1][2] Different worlds, I suppose.

There's no reason you couldn't represent RFC5322 data with RDF as JSONLD. There's now a way to do streaming JSON-LD.

LDP does paging and querying.

Solid supports pubsub with WebSockets and LDN. It may or may not (yet?) be as efficient for synchronization as JMAP, but it's definitely designed for all types of objects with linked data web standards; and client APIs can just parse JSON-LD.

[1] https://github.com/solid/information#solid-specifications

[2] https://github.com/solid/solid-spec/issues/123 "WebSockets and HTTP/2" SSE (Server-Side Events)

https://jmap.io/

JMAP: JSON Meta Application Protocol https://en.wikipedia.org/wiki/JSON_Meta_Application_Protocol

Is there a OpenAPI Specification for JMAP? There are a bunch of tools for Swagger / OpenAPIs: DRY interactive API docs, server implementations, code generators: https://swagger.io/tools/open-source/ https://openapi.tools/

Does JMAP support labels; such that I don't need to download a message and an attachment and mark it as read twice like labels over IMAP?

How does this integrate with webauthn; is that a different layer?

(edit) Other email things: openpgpjs; Web Key Directory /.well-known/openpgpkey/*; if there's no webserver on the MX domain, you can use the ACME DNS challenge to get free 3-month certs from LetsEncrypt.

https://wiki.gnupg.org/WKD

Re: JMAP: A modern, open email protocol

#29

Post by zeroxfe »

jolmg wrote: post #14
satyanash wrote: post #12

If this takes off, it would remove one of the last few holdouts of non-HTTP application specific protocols. That just leaves us with SMTP really. While using HTTP is not necessarily a bad thing, it's certainly an interesting indication of how application developers prefer convention based protocol definitions (JSON over HTTP) instead of having a strictly defined protocol over a duplex stream (IMAP over TCP).

Why is this happening? Forgetting ubiquity of tooling, is there something technical about HTTP that makes it so attractive? I get JSON. People don't want to write text-parsers. But what's attractive about this abuse of HTTP? This isn't hypertext. Is it so complicated to work with a duplex-stream? Could a library alleviate the complications? Could it be that developers are more familiar with HTTP than with TCP and so…

> This isn't hypertext.

That ship has long sailed. HTTP is no longer just hypertext -- it's a ubiquitous and well-understood transport for RPCs, with lots of tooling and infrastructure support across the Internet.

I think at its core, HTTP abstracts away some of what you would want in a request-response protocol, but not really all of it. But _simply because of the ubiquity of tooling_, you get a whole lot of other stuff for free (load balancing, DDoS detection, in-browser debugging, etc.)

> Is it so complicated to work with a duplex-stream? Could a library alleviate the complications?

Yes, TCP streams are very complicated to work with (in my experience) -- there are way too many failure modes and corner cases to consider. IMO, your language's go-to HTTP library is that library that alleviates the complications.

All this said, I personally think gRPC is the right approach for RPCs, and I hope to see broader adoption of it over the coming years.

Re: JMAP: A modern, open email protocol

#30

Post by tialaramex »

ocdtrekkie wrote: post #13

One of the things I particularly recall reading is FastMail devs explaining that the standardization process led to changes and improvements. (Even their about page says that "JMAP was built by the community, and continues to improve via the IETF standardization process.") Really thrilled the FastMail team is working on this, and doing it in the way that changes to mail should be handled: Going through proper Interne…

The IETF's standardisation process almost can't help but improve whatever it is you're trying to standardize. Not only are you being shepherded by peers with expertise in whatever corner of networking you're excited about (the Area Directors for whichever Area your Working Group was assigned to) but you're obliged to put up with anyone who cares to offer an opinion mailing it in. Looking for consensus isn't a good way to run a restaurant kitchen, but it may be the best possible way to agree network standards. Even when contributors say something you believe to be completely stupid figuring out how to put into words exactly why they're wrong is likely to be instructive, and as often as not they're not /quite/ as wrong as you first thought.

For example the TLS Working Group is polishing up a document telling people to cut it out with the TLS 1.0 after all these years and get to something at least vaguely modern like ten year old TLS 1.2 instead, (once upon a time named the diediedie draft, these days it has a more respectable name). Martin Rex offered the opinion that TLS 1.2 is _worse_ than TLS 1.0 and 1.1 because it doesn't smash SHA1 and MD5 together to produce a single hash. He reasons that if, somehow, SHA1 is broken enough to allow a preimage attack, TLS 1.0 is fine, whereas TLS 1.2 with SHA1 is now broken.

Of course people said Martin is barking up the wrong tree. But much more importantly they took another look at their document, it didn't actually _say_ you should implement SHA-256 when you upgrade to TLS 1.2, but they all agreed you should do that, so probably the document wants to spell that out...

Post reply on HN