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

31–40 of 120 posts

Re: JMAP: A modern, open email protocol

#31

Post by jolmg »

detaro wrote: post #23
jolmg wrote: post #19

Earlier quoted context omitted.

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"

By useless I meant that the use of HTTP doesn't contribute anything essential. Though maybe I could be wrong? But that's what I understood by "is not core to its operation". I understand it to just wrap the JSON in HTTP for the benefits that come from its ubiquity in use and not so much because of merits of the mechanisms described in the HTTP spec.

Re: JMAP: A modern, open email protocol

#32

Post by [deleted] »

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…

[deleted]

Re: JMAP: A modern, open email protocol

#34

Post by vbezhenar »

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…

1. Everyone does that, why should I do different thing?

2. I've heard about corporate firewalls which close everything and nobody has power to overcome that, so I'll tunnel everything via HTTP(S) and forget about those horrors.

3. HTTPS provide absolutely hassle-free encryption with reverse-proxies. I don't even need to think about it. Using TLS library sounds too complex and I must make some real effort to implement it. Rolling out my own encryption? Everyone will scream!

4. HTTP/1.1 protocol is really simple. There are some hidden gotchas in the corners, but basically it's headers, empty line and then either bytes or stream of chunks, that's all about it. So I can pass routing information (URL path), I can pass some metadata in headers and I can pass either a singular message or a streamed content. And with HTTP libraries in every language you'll get that functionality almost for free, both for server and client.

5. Theoretically you can leverage HTTP caching on various levels. Might be tricky, but certainly easier rather than implementing it from the scratch. And with things like Cloudflare you can't really build anything similar.

6. Browsers can only talk HTTP. So even if I don't need it know, if I would ever need to build web application, I'll have to provide HTTP bridge. And web applications are really common nowadays. You can't really make IMAP client in JavaScript running in browser. But you probably can do it with JMAP.

Re: JMAP: A modern, open email protocol

#35

Post by detaro »

jolmg wrote: post #31
detaro wrote: post #23

Earlier quoted context omitted.

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

By useless I meant that the use of HTTP doesn't contribute anything essential. Though maybe I could be wrong? But that's what I understood by "is not core to its operation". I understand it to just wrap the JSON in HTTP for the benefits that come from its ubiquity in use and not so much because of merits of the mechanisms described in the HTTP spec.

No, it's just the most widely supported protocol of that kind, so why not use it? Is there anything specific against it/how do you answer for another protocol the question of "why not HTTP, which is similar and has better support?"? (Caveat: I think you'd ideally want http/2, which isn't as widely supported)

EDIT: actually, one point: you can talk JMAP over HTTP(S) directly from a browser without a translating server.

Re: JMAP: A modern, open email protocol

#36

Post by tialaramex »

cvwright wrote: post #2

This is very exciting! It's been a long time coming. Should we take this IETF blog post as an indication that the standardization work is almost done?

The core work is done, yes, draft-ietf-jmap-core-17 and draft-ietf-jmap-mail-16 [edit: fixed draft name] are in the RFC editor's queue, how long it takes to get through that queue can depend on a lot of variables. At the end it goes to "AUTH48" which is notionally 48 hours long but a few weeks is more likely in practice, and then it gets cut a number and becomes an RFC.

The Working Group still has open items, including calendaring (because people never can build a mail system that doesn't involve calendaring for some reason), handling "read receipt" type features and because this is Current Year a mechanism to involve WebSockets. Either those will eventually also be polished into standards, or they'll be abandoned at some point and undelivered.

Re: JMAP: A modern, open email protocol

#37

Post by evilotto »

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.

The other part that is really lacking is security, in particular 2fa. The proposed standard says that obtaining credentials is out of scope, which means it will remain in the realm of vendor-specific implementations.

Re: JMAP: A modern, open email protocol

#38

Post by toomim »

butz wrote: post #3

Does it solve SPAM problem?

Nope, that needs to be solved in SMTP. Unfortunately, JMAP only replaces IMAP/POP.

I have personally been working on a new protocol that replaces both IMAP and SMTP. It's not ready yet, but the solution turns out to be quite elegant and I have great hope that it will work in the future.

Re: JMAP: A modern, open email protocol

#39

Post by wmf »

tialaramex wrote: post #30
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 wa…

JMAP is still young; just wait until a plethora of non-interoperable optional extensions get added.

Re: JMAP: A modern, open email protocol

#40

Post by jcranmer »

jolmg wrote: post #27
groovybits wrote: post #25

Earlier quoted context omitted.

> 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.

Opportunistic STARTTLS is vulnerable to encryption downgrade attacks. Good email clients don't implement opportunistic STARTTLS, they implement mandatory STARTTLS or TLS, with plaintext being either an option that's heavily discouraged by UX flow, enabled only for tests, or not available at all.
Post reply on HN