JMAP: A modern, open email protocol • Hacker News Board

Re: JMAP: A modern, open email protocol

#101

Post by tracker1 » Tue, May 07, 2019, 1:28 PM UTC

evilotto wrote: post #37

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.

I'd guess that you'd get a token that gets added as an `Authorization: bearer ` header in practice for most implementations. The specifics of the auth and token itself may vary though.

Edit:

Though having a dedicated /auth/login path that takes a JSON post with {username,passphrase,2facode,...} could be readily defined where any of the above parameters are optional. The response being a token that's used as the previously mentioned authorization header.

Re: JMAP: A modern, open email protocol

#102

Post by afiori » Tue, May 07, 2019, 1:34 PM UTC

upofadown wrote: post #93

afiori wrote: post #62

Earlier quoted context omitted.

What drawbacks do you see in JSON here? For machine to machine communication it is a pretty good serialization format I would say (It is not great for many other things, but this sound like its strong point)

It seemed to me that the article was only using the fact of JSON use as more evidence of modernness. It implied that JSON didn't map that well into their problem space but they overcame.

In a sense they are right. Modernness in the sense that it is a well understood format and not a DSL with non-trivial semantics and parsing.

Re: JMAP: A modern, open email protocol

#103

Post by tracker1 » Tue, May 07, 2019, 1:42 PM UTC

dcbadacd wrote: post #43

jolmg wrote: post #4

Earlier quoted context omitted.

I haven't read JMAP, but I don't think that's the problem it's tackling. Also, I think SPAM is as solved as it can be with blacklists, heuristics-based filtering software like spamassasin, and personal filtering with sieve scripts. What else would anyone suggest?

Spam could be half-fixed with forcing DKIM, SPF, DMARC and TLS. The very least there would be no impersonation of other domain names (filtering the rest into a spam box will become much easier after that) and insecure transportation then.

Simpler would be a callback mechanism that required at least a domain cert with TLS..

    Server A => Server B : 
        hey, I have a message 
        for X
        from Y
        MessageId: Z
        SingleUseKey: K
    Server B disconnect
    Server B => DNS Entry for Y's domain
    Server B : hey, I want message ID: Z, Key: K

Then you need not only DKIM, SPF, etc, but you need a server that responds to inbound requests to pick up an outbound mail configured and setup on the correct port.

Re: JMAP: A modern, open email protocol

#104

Post by dcbadacd » Tue, May 07, 2019, 2:05 PM UTC

ahje wrote: post #88

dcbadacd wrote: post #43

Earlier quoted context omitted.

Spam could be half-fixed with forcing DKIM, SPF, DMARC and TLS. The very least there would be no impersonation of other domain names (filtering the rest into a spam box will become much easier after that) and insecure transportation then.

How would sender authentication solve the problem? A large amount of spam is sent from throwaway domains with SPF and DKIM in place, and another large part of it is sent through hijacked web sites and email accounts.

As I have said, it would very least avoid spam looking real from real domains, which is half of the issue. The throwaway part could be fixed by making spam illegal and actually cracking down on it.

Re: JMAP: A modern, open email protocol

#105

Post by sneak » Tue, May 07, 2019, 2:07 PM UTC

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

Skype. SIP. Video Games. Bittorrent. Cryptocurrencies.

There’s lots of stuff that HTTP isn’t eating.

Re: JMAP: A modern, open email protocol

#106

Post by vbezhenar » Tue, May 07, 2019, 2:47 PM UTC

afiori wrote: post #58

vbezhenar wrote: post #34

Earlier quoted context omitted.

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…

Do you also have a list for why many people oppose HTTP (or better what is sometimes called "shoehorning everything in a HTTP shaped box")? I guess that the versioning and advanced features are a stark contrast with versionless TCP from the '80, but I am interested in hearing more opinions on the matter as I am ignorant of any dealbreaker regarding HTTP.

The hardest thing with HTTP is to send server-initiated messages to client. There are multiple approaches (websockets, SSE, client polling) but they are not simple.

Also HTTP carries some overhead. It's not significant, something like 50-100 bytes, but it might matter for a lot of tiny messages, I guess.

Another factor is: those intermediate proxies might break your app. They might cache your responses even if you don't want that, so your application will act wierdly. Of course any intermediate proxy might break any protocol...

Re: JMAP: A modern, open email protocol

#107

Post by afiori » Tue, May 07, 2019, 3:33 PM UTC

vbezhenar wrote: post #106

afiori wrote: post #58

Earlier quoted context omitted.

Do you also have a list for why many people oppose HTTP (or better what is sometimes called "shoehorning everything in a HTTP shaped box")? I guess that the versioning and advanced features are a stark contrast with versionless TCP from the '80, but I am interested in hearing more opinions on the matter as I am ignorant of any dealbreaker regarding HTTP.

The hardest thing with HTTP is to send server-initiated messages to client. There are multiple approaches (websockets, SSE, client polling) but they are not simple. Also HTTP carries some overhead. It's not significant, something like 50-100 bytes, but it might matter for a lot of tiny messages, I guess. Another factor is: those intermediate proxies might break your app. They might cache your responses even if you do…

> The hardest thing with HTTP is to send server-initiated messages to client.

My (weak) understanding here is that in most mobile cases this is intrinsically problematic and is the reason for the plethora of push notification standards. In this case HTTP is more battery friendly as a noisy server can't as easily spam your phone with traffic.

Re: JMAP: A modern, open email protocol

#108

Post by y4mi » Tue, May 07, 2019, 3:36 PM UTC

the8472 wrote: post #65

kitsunesoba wrote: post #57

Earlier quoted context omitted.

I’ll take JSON over text any day. Email parsing can break in so many subtle and/or obscure ways that I have trouble putting any confidence in the parsing code I’ve written… it’s quite frustrating, especially since there aren’t well tested mail parsing libraries for every language/platform to fall back on. On the other hand, JSON parsing errors are reasonably bounded and there’s well-tested highly optimized libraries…

If it has to be a loose bag of value data format you could at least CBOR instead of JSON.

>> there’s well-tested highly optimized libraries for it (JSON) for practically every supported platform and language.

> If it has to be a loose bag of value data format you could at least CBOR instead of JSON.

so you think there are well tested, good performing CBOR parsing libraries in basically all languages?

Re: JMAP: A modern, open email protocol

#109

Post by Nasreddin_Hodja » Tue, May 07, 2019, 3:52 PM UTC

https://jmap.io/#push-mechanism JMAP going to use rfc8030 push for mobile and EventSource (kind of http long polling) for desktop clients, as I understood. I don't like that idea, it's even worse than IMAP4 IDLE. Why not just WebSockets for mobile and desktop clients?

Re: JMAP: A modern, open email protocol

#110

Post by kahlonel » Tue, May 07, 2019, 5:47 PM UTC

y4mi wrote: post #108

the8472 wrote: post #65

Earlier quoted context omitted.

If it has to be a loose bag of value data format you could at least CBOR instead of JSON.

>> there’s well-tested highly optimized libraries for it (JSON) for practically every supported platform and language. > If it has to be a loose bag of value data format you could at least CBOR instead of JSON. so you think there are well tested, good performing CBOR parsing libraries in basically all languages?

Yes there are: https://cbor.io/impls.html