31–40 of 116 posts
It's missing the one killer feature that would fix the spam problem: approved senders. If you had a "friends" list like Facebook where only people you've approved may send messages to you, we'd cut down on 90% of spam immediately. Between that and the lack of mandatory encryption this is just another tedious protocol to implement.
1. You recommend using a digest of the message to generate the message ID. Did you consider mandating that scheme or going farther and using a Merkle tree for the mailbox representation? It seems like this would allow for generating single requests that can fetch all new items.
2. Why SHA-1?
Edit: Also, thanks for keeping Fastmail running. As a customer of about ten years it's much appreciated.
Earlier quoted context omitted.
That's not a practical feature in the real world. Sometimes you need email from unapproved senders. Spam filtering is better accomplished before or after delivery, not during.
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.
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
Inbox is a separate layer on top of existing email servers. My impression is that the pain point they're addressing is, you want to build some awesome email integration app and sell it to companies, but you're looking at how complicated it would be to speak IMAP and IMAP-with-quirks and ActiveSync and the Gmail API and everything else (in order to build a high-quality integration) and that's scaring you. You can outsource that problem to Inbox, they'll make sure they get good-quality data from any email server reliably, and you just speak an HTTP API. This involves deploying a separate server which caches email. You talk to the "sync engine" over a reasonable protocol, and the sync engine takes care of talking an unreasonable protocol to wherever the data actually lives.
JMAP is an API to directly access an email store. It's something that an email provider (Fastmail, most obviously) will directly support, but it also only helps you for those providers that actually speak JMAP.
If you're an email server developer, an ISP, etc., then JMAP is cool and Inbox is not really useful -- there's not much of a point in having an email server that speaks IMAP and then also sticking a frontend to convert IMAP to something else. You might as well just make your email server speak a reasonable protocol directly.
If you're an app author, Inbox is useful today, and JMAP is only useful, maybe, if all your users are Fastmail users.
If you're an in-house developer at a large company that's running Exchange, and realistically you have no hope of getting the email admins to switch email servers (and you wouldn't want to run the email service yourself, even if they offered), JMAP is useless to you, and Inbox is super compelling.
(There is probably an argument that the Inbox "sync engine" should speak JMAP on the front end / those APIs should converge. Certainly the Inbox sync engine should speak JMAP on the back end, so Inbox can advertise support for Fastmail.)
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.
If you were designing a replacement for server-to-server SMTP, it'd be nice to require encryption, possibly end-to-end encryption.... although encryption can also be layered on top, at the RFC 822 level instead of the RFC 821 one (as S/MIME, PGP, etc. do). But this isn't an SMTP replacement, it's a replacement for IMAP (and ActiveSync, POP3, etc.).
http://xkcd.com/927/
The time is right for a better standard.
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?
There is a a protocol named Sieve ( http://www.ietf.org/rfc/rfc5228.txt ) which provides for delivery stage filtering rules. It is similar in capability and usage to procmail, but formalized and somewhat more modern (and not capable of running arbitrary system commands), and supported by some modern IMAP/POP servers, like Dovecot. Presumably if JMAP gets integrated into those servers, Sieve would also be available.
And, I would hope there wouldn't be an IMAP/JMAP translation layer, but instead servers would implement JMAP directly. Though I guess in the short term there might be some sort of proxy.
Modern, innovative, service-oriented products and a business model based on customers giving the company money in return for services.
I hope that this is a reminder to startups out there that you don't have to trick customers into handing over their personal information all the while pretending to offer your services "for free", in order to gain market share and be profitable.
The "traditional" business model can be quite successful.