JMAP is on the home straight
fastmail.blog
fastmail.blog
All because the authors believe mortal men are not capable of understanding DNSSEC. Leaving aside the unholy alliance of Google + Microsoft + Verizon + Comcast, the fact that the IETF made Fastmail ditch authentication from a mail protocol while letting Google subsume DNS and web-based port knocking into another mail protocol definitely tells me there's nobody behind the wheel any more.
I'm happy that the Fastmail team is doing work that excites them, but does anyone know if the IETF has any plans to use ports other than 443 ever again?
HTTPS does seem like overkill, but on the other hand, it's likely already running (even I, who host my own mail, have an HTTP daemon on the same server), so in the common case, it doesn't increase the attack surface.
This is a fundamental misunderstanding of how the IETF works. The IETF codifies industry standards but, as with the W3C, it doesn't have some sort of veto authority over what companies actually implement. If major vendors are using MTA-STS, it's in everyone else's interest that it be described in a public standard. The IETF does get high-quality feedback and I see no reason to question the sincerity of Fastmail's stated reasoning and expressed appreciation.
Similarly, “the authors believe mortal men are not capable of understanding DNSSEC” might be an amusing rhetorical flourish but it's not as convincing as the actual numbers showing that DNSSEC is not reliable on the internet now whereas HTTPS has near-universal deployment _and_ doesn't have the various design flaws which the DNSSEC community is slowly fixing. If you want to protect users, it's usually better to pick something which doesn't require hundreds of parties around the world to make significant changes — and that certainly fits with the “rough consensus and running code” ethos.
With JMAP maybe we will actually see some interest in decent desktop and mobile clients for once. And also maybe we will have decent alternatives to the big players for non-techie people too.
That JMAP makes it straightforward to build a rudimentary but fully functional email client gives me hope that people may experiment more than they have been. I believe that a large part of the reason that there are few email clients now is because getting a basically-functioning email client going is a surprisingly large investment of effort, and doing it well is an enormous investment.
FOSDEM? Probably too late for this year, though.
The only thing I'm afraid of is the programming language, please don't pick some hipster language (e.g. invented in the past five years) or some bloated platform like Electron.
Though that makes it sound like it would work with any email provider. It's not clear that JMAP is a protocol. "Building a JMAP email client in half an hour"?
Maybe there's not enough interest in JMAP yet, and a talk that promotes JMAP over IMAP/SMTP would be better first. Maybe the client could be prebuilt and simply presented as part of the talk as FOSS, showing the small LoC that it took and simply mentioning how little time it took. Maybe having it in multiple programming languages would help, too, to show that its simplicity is not a matter of language of choice.
Just throwing ideas out there.
Totally agree that email protocols need improvement, but there are other benefits to gmail. I'm always going to want reliable service and storage, good spam filtering (and gmail's scale allows them to do that potentially better than anybody), and the interface is pretty good. I can even use my own domain.
I'd hope most decent providers let you use your own domain...
It's easy to think gmail spam filtering is good if you never check the spam folder. It has filtered out some very important mails for me and others so I do my very best to disable it. Create a filter for "is:spam" and "Never send it to Spam" is the best solution I know. But despite this google might remove mails anyway.
I haven't looked into backing up gmail.
Another big advantage is that their spam data aggregation is optional, unlike Gmail's, and solely uses the content of confirmed spam (aka, you permanently deleted it) to refine their data, so no personal data is getting hoovered up with it.
I did actually shut off offering up my spam data to the masses on FastMail, because I realized I had an edge case where the filters defining my spam as spam for everyone could be harmful.
As far as backup, I have a local Microsoft Outlook which I open every so often which pulls down all the email. I wouldn't mind a Google Takeout-esque download feature from FastMail at some point too though.
I don't doubt there was a time Gmail was the absolute best at spam filtering, but I would contend that time is over.
I have one address hosted via outlook.com (relic from when they had a free tier for personal domains), and the bulk of email is via gmail. I have mail forwards in google domains for a few really old email addresses (just used it the other day to recover an old account). But for the most part, I would love to see some better personal mail options.
I've roughly looked at some of the mail in a box stuff, but I don't want all of DNS and the world for the domain controlled under my mail server.
This bit of JMAP has irked me - encryption is a second-class citizen, in a world rapidly evolving to need it every step of the way.
Mailing lists are a big problem you have to solve and none of the solutions are very good.
I just believe, in today's atmosphere, synchronisation where encryption is a second-class citizen is a missed opportunity.
Fortunately, Fastmail has a blog post that goes more in depth on the subject: https://fastmail.blog/2016/12/10/why-we-dont-offer-pgp/
What you want is something on top of emails, like autocrypt (https://autocrypt.org/)
That doesn't begin to solve the real issue of how to reliably encrypt from sender to sender across two servers it just makes the process even more needlessly complex.
> Clients that want to or need to (for example those doing PGP in the client) can still fetch the RFC5322 if needed.
Not a case of JMAP saying to the client, "Hey, here's this blob. It might be encrypted." But a case of asking the client to use a message standard they've replaced where possible.
That's what I mean by second-class citizen.
For clarity, we’ve only had beta users (other than ourselves) on the JMAP-based interface for a few months. The previous interface (which has been in use since the start of 2012) was built on the precursor to JMAP, which works in a broadly similar fashion.
Though I'm sure MIME will always be a bit of a trash fire to deal with.
The JMAP website has a list of other clients and server: https://jmap.io/software.html
> The fact that “Message” meant too many things led to it being renamed as “Email”
No. No no no no no. 'Email' means even more things than 'message'.
1. Address: "What's your email?"
2. Synonym for 'send': "I can email you there. "
3. Message body: "Let me know when you've got the email."
1. That's an email address, not an email. 2. That's a noun-ed verb - context generally makes it obvious when verbs are used rather than nouns. "I can email you" is a shorthand for "I can send an email to you". 3. That's fine - a mail client / server would never confuse these as the body is very obviously a property of most any representation.
In the same way that I'm not concerned that my postman has never delivered a fence to me, or written on a bulletin board system, I think we can cope with this name being the appropriately sensible one.
Have I misconstrued your argument?
Your postman doesn't deliver fences to you, he posts post to you. In a similar way, instead of using the word 'post' all the time, a sensible design for an API would want to have a person deliver a message.