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

JMAP – a better way to email

blog.fastmail.com

Post reply on HN
Print view View original

51–60 of 116 posts

Re: JMAP – a better way to email

#51

Post by groby_b »

iwantagrinder wrote: post #33

I' m interested in this from a security perspective. What does this new protocol offer in terms of better control around what makes it to the inbox? Would IMAP>JMAP translation before hitting the user give us better ability to filter out malicious items/spam?

So am I. From looking at http://jmap.io/spec.html#authentication, it looks like the password will be transmitted in plain text. (See the text below the 200 response)

That makes me extremely queasy. Yes, HTTPS theoretically provides transport layer security, but a single breach of transport layer security results in the attackers permanent access to your mail.

I.e. run a MITM attack in a coffee shop, snoop up JMAP passwords, make use of them at a latter point in time.

I really hope I'm missing something important, or misread the spec.

Re: JMAP – a better way to email

#52

Post by robn_fastmail »

groby_b wrote: post #51
iwantagrinder wrote: post #33

I' m interested in this from a security perspective. What does this new protocol offer in terms of better control around what makes it to the inbox? Would IMAP>JMAP translation before hitting the user give us better ability to filter out malicious items/spam?

So am I. From looking at http://jmap.io/spec.html#authentication , it looks like the password will be transmitted in plain text. (See the text below the 200 response) That makes me extremely queasy. Yes, HTTPS theoretically provides transport layer security, but a single breach of transport layer security results in the attackers permanent access to your mail. I.e. run a MITM attack in a coffee shop, snoop up JMAP pa…

If you read the spec closely, you'll note that it provides support for arbitrary challenge/response auth mechanisms. Its conceptually the same as SASL in that respect.

Yes, we're assuming a secure transport. Most of the internet currently does. Most of the passwords you send over encrypted channels right now are plaintext. This is not something we're trying to solve with JMAP (if it even needs solving, which is debatable).

Re: JMAP – a better way to email

#53

Post by grinich »

ebabchick wrote: post #29

For the well acquainted -- how does this relate to Inbox ( https://www.inboxapp.com/ )? I have not spent enough time with either to make a comparison

Michael from Inbox here— a few key differences, from the horse’s mouth. :)

First of all— I want to say that we’re huge fans of Fastmail and really admire their team and focus. Rob and Neil actually came by for lunch this summer and hacked in our office for the day. We’ve discussed JMAP back and forth with them for a while, and specifically had a long thread when we added calendar endpoints to the Inbox platform. [1]

The fundamental differences between the Inbox APIs and JMAP are the kinds of applications built with them, the open source code, and the email providers supported.

The Inbox APIs are really designed to let developers access email data in non-traditional ways. Our site reads “Say goodbye to IMAP” but we’re not so much replacing IMAP, as creating a new protocol which liberates email data to a higher form. We think about email as “the database of your life” which means unconventional “clients” and access/manipulation patterns.

That’s one of the reasons we have a more REST-inspired design, whereas JMAP is closer to RPC. The Inbox API endpoints strive to represent canonical objects that developers simply treat as resources. JMAP is tailored specifically for traditional email clients, so it excels at fast operations (like archive -> reload), but compromises in other areas of simplicity and clarity IMHO.

The other main difference is code. The Inbox sync engine is open source with about 15k lines of code on GitHub.[2] You can run it yourself right now, and it works on all providers, including Fastmail! That means your users don’t need to be on any specific provider or backend. If you don’t want to run it yourself, you can use our hosted version which also includes support for enterprise environments that use Microsoft Exchange. [3]

I’ve been lurking on the IETF mailing lists for several years now, and one thing I learned is that spec documents hardly move the world forward. Developers need code that is battle tested and they can depend on. What use is a API spec if you can’t build an app with it?

The JMAP system is a great spec for FastMail’s internal mail service, and it works to power their own clients, but unless they make some drastic changes to the code and business, it’s not a platform for building 3rd party mail apps.

As an aside, I totally wish I had more time to write. I envy how prolific the Fastmail blog is these days. :) Keep up the great work Bron, Rob, Neil, and the rest!

[0] https://www.inboxapp.com

[1] https://www.inboxapp.com/docs/api#calendar

[2] https://github.com/inboxapp/inbox

[3] https://www.inboxapp.com/features

Re: JMAP – a better way to email

#54

Post by mikhailt »

brongondwana wrote: post #9
driverdan wrote: post #7

Why would you create a new email protocol without an encryption requirement? I understand trying to fix the existing protocol problems but one of the biggest is plaintext.

Because SSL does the job of securing data between the server and the client just fine. There are a ton of interesting problems in the email world, including all the server to server communications. JMAP is lightning focused on solving ONE of those problems - the communication between end-user devices and their mail server - and doing it well.

You're assuming SSL is implemented without any security bugs. We saw what happened with Heartbleed and when SSL implementations are not properly reviewed and updated by a full funded team.

Re: JMAP – a better way to email

#55

Post by hsshah »

veb wrote: post #48
dannysu wrote: post #28

Great job guys! Things like this together with CalDAV and CardDAV are reasons why I pay you guys for service. I just tried the following experiments with my Gmail and FastMail account. There's a reason why FastMail just feels faster! Try this: 1) While having the Gmail iOS app open, mark an email as read on the web 2) See how long it takes for Gmail to reflect the change 3) Now try with FastMail iOS app, see that it'…

Thank you for this comment. I do wonder why they simply didn't say this at the beginning of the article. I understood what they were up to purely because I'm a technical guy, but still I didn't want to actually have to watch the video -- namely because I'm deaf, and far too often there's no captions to explain what's going on so I prefer to read (and so do people at work, school, no sound etc), and it takes a lot les…

Every time I read about Fastmail, I want to make the jump from Google Apps. However, I don't do it because of Google Drive/Docs/Spreadsheet. Any recommendation for their replacement?!

Re: JMAP – a better way to email

#56

Post by veb »

hsshah wrote: post #55
veb wrote: post #48

Earlier quoted context omitted.

Thank you for this comment. I do wonder why they simply didn't say this at the beginning of the article. I understood what they were up to purely because I'm a technical guy, but still I didn't want to actually have to watch the video -- namely because I'm deaf, and far too often there's no captions to explain what's going on so I prefer to read (and so do people at work, school, no sound etc), and it takes a lot les…

Every time I read about Fastmail, I want to make the jump from Google Apps. However, I don't do it because of Google Drive/Docs/Spreadsheet. Any recommendation for their replacement?!

Ha. I'm the same, every time I read about them I want to make the jump - but I'm not reliant on any of those, except mail fortunately.

I just haven't quite done it yet. From people I've spoken to, everyone praises Fastmail... seems like we all need that extra push.

Re: JMAP – a better way to email

#57

Post by nmjenkins »

mikhailt wrote: post #54
brongondwana wrote: post #9

Earlier quoted context omitted.

Because SSL does the job of securing data between the server and the client just fine. There are a ton of interesting problems in the email world, including all the server to server communications. JMAP is lightning focused on solving ONE of those problems - the communication between end-user devices and their mail server - and doing it well.

You're assuming SSL is implemented without any security bugs. We saw what happened with Heartbleed and when SSL implementations are not properly reviewed and updated by a full funded team.

So you're assuming that an independent encryption layer that has to be reimplemented by every email client dev is going to be more secure than a widely studied protocol, implemented at the OS level. Right…

Re: JMAP – a better way to email

#58

Post by maxk42 »

devicenull wrote: post #34
maxk42 wrote: post #25

Earlier quoted context omitted.

There's nothing preventing an unapproved sender from requesting contact privileges, but once denied, their messages and further requests would be ignored by default. Each server and user would have their own identity management concerns. Basically someone can send a "friend request" and if approved by a human (the recipient) they may communicate freely from that point.

How do you deal with validating a sender? That is, how do you ensure that spammer's don't just create tons of fake new senders?

That's a great topic to have a conversation around.

My initial thoughts are that you'd have a blacklist for servers as well as individuals. So if people mistakenly approve senders at around the same rate they mistakenly open spam emails then you'd only get through one time in ten thousand. If your local messaging provider realizes that 9999 out of ten thousand friend requests from a particular domain are denied, then they'd block the entire domain.

Since a friend request conveys little to no information beyond the fact that someone wants to communicate, they'd be unable to get their message out effectively. If one in ten thousand spam friend requests gets through by mistake and after the initial spam message one in ten thousand isn't immediately blocked, then the spammers would need to set up ten thousand domains, each sending out ten thousand messages to get through to one schmuck who might fall for it, and then they'd need 9999 new domains since all but one have been blacklisted. It would likely be enough of a deterrent to prevent most spammers from continuing, although there will always be some amount of spam.

At least I don't think most people would be likely to accept a friend request from IncreaseYourDickSize6969@nigeriamail.com -- but there may be more effective strategies for handling burner identities. How would you do it?

Re: JMAP – a better way to email

#59

Post by maxk42 »

ricardobeat wrote: post #30
maxk42 wrote: post #25

Earlier quoted context omitted.

There's nothing preventing an unapproved sender from requesting contact privileges, but once denied, their messages and further requests would be ignored by default. Each server and user would have their own identity management concerns. Basically someone can send a "friend request" and if approved by a human (the recipient) they may communicate freely from that point.

How is this different from adding an address to your blacklist after the first message?

They can't deliver their spam message to begin with. You'd need to approve the contact then you could still block them if they spam you.

There's still friend-request spam on facebook, but not nearly as much as email because you can just ignore the people you don't know and block people you do know if they begin to spam you.

Re: JMAP – a better way to email

#60

Post by alfiedotwtf »

veb wrote: post #56
hsshah wrote: post #55

Earlier quoted context omitted.

Every time I read about Fastmail, I want to make the jump from Google Apps. However, I don't do it because of Google Drive/Docs/Spreadsheet. Any recommendation for their replacement?!

Ha. I'm the same, every time I read about them I want to make the jump - but I'm not reliant on any of those, except mail fortunately. I just haven't quite done it yet. From people I've spoken to, everyone praises Fastmail... seems like we all need that extra push.

Don't forget there's a 60 day free trial. How's that for a push :)
Post reply on HN