I think it's pretty clear what's going on here.
By the way, FastMail's work at the protocol level - http://jmap.io/ - is open source, and being standardized by the IETF.
I think it's pretty clear what's going on here.
By the way, FastMail's work at the protocol level - http://jmap.io/ - is open source, and being standardized by the IETF.
FastMail itself is using something non-standard, and saying it is open source and "being standardized" means nothing. See https://xkcd.com/927.
The spec is now nearly complete and we expect standards-track RFCs to be published later this year. Adoption will then happen slowly over time, as it did with IMAP. Smaller, more nimble companies are likely to move first and then larger companies following later. IMAP took many years to get widespread adoption; I hope we can make the move to JMAP a bit faster, but these things always take time (often measured in years!) to develop, test and release.
I love XKCD as much as the next guy, and of course it's kind-of right, but also too cynical: the only other alternative is to not make an effort at all, and accept the status quo is the best you can hope for. We'd like to do better than that. If we fail, at least we know we tried.
While Fastmail at this moment look much better than other mail services, nobody know what Fastmail (or any other service) could do with your correspondence tomorrow.
There is cool sample flowchart[0] created using Dia[1]: "Should I encrypt my email?"[2]
[0] http://dia-installer.de/shapes/Flowchart/index.html.en
[1] https://en.wikipedia.org/wiki/Dia_(software)
[2] http://dia-installer.de/shapes/Flowchart/images/Flowchart.pn...
Given the surfeit of standards compliant email available, switching to another provider is trivial
What are you talking about ? The IDLE command is completely supported and I'm using it in my mail client with no issues at all.