One of our core company values is a commitment to interoperability through open source and open standards. FastMail believes very strongly in contributing to a healthy email ecosystem. We want people to become our customers, and to remain our customers, because they love our service and because we’re good at what we do – not because they have no choice.
When we started work on JMAP, “a better way to email”, we wanted to bring our advances in email protocol design to the rest of the world. We did this not only for altruistic reasons, but for the very selfish reason that too many new and popular email clients are tied to a specific email service (and not FastMail!), because the open protocols are too hard to use or lacking in features. With JMAP, we intend to make the easiest way to build the best experience be based on open standards.
After a couple of years of talking about JMAP at conferences and finding others who wanted to work with us it was time to bring JMAP to the Internet Engineering Task Force. The IETF is the body that produces what are whimsically known as RFC or “Request for Comments” documents, and if you want something to become an Internet standard, the RFC Standards track is the way to go.
There are various areas within the IETF, and JMAP naturally fell under the scope of the Applications and Real Time Area.
Since there was no active working group within ART which could take on JMAP, a new working group was proposed. JMAP-the-IETF-working-group was officially chartered just before the 98th IETF meeting in Chicago in March 2017. I was appointed as one of the chairs of the working group, with an experienced co-chair (Barry) to mentor me. We also found co-authors from outside FastMail for each of the standards track documents the working group plans to produce.
It’s important that the final JMAP be a community consensus and not dominated by our company. We are as keen as everyone else to see JMAP improved by input from the most experienced email people in the world.
It became clear upon joining the IETF that there were many people with experience running very different email infrastructures than we run, as well as people from other areas such as Security, HTTP, and Authentication who could bring their own expertise to the standard.
We have a very active issue tracker, with (at the time of writing) 81 closed issues and 19 still in progress, covering just the core and mail specifications. There are also in-progress documents for calendar and contacts which are awaiting work on the data representation. Robert already wrote about his work within the CalConnect group to standardise a representation for calendar events in a JMAP-compatible way, and I’ll be helping that work its way through the calext working group where it best fits.
The great thing about the IETF is that all the discussions happen in the open, so everybody is welcome to follow along on the mailing list.
JMAP has now had 3 working group sessions, one at each of the three IETF meetings in 2017, where the interested parties all get together to discuss the remaining issues face-to-face. We will be holding another session at IETF 101, London in March 2018 – hopefully with complete core and mail specifications, and starting to work on our next milestones.
While JMAP is working on a brand new protocol for the future, there’s another working group which chartered towards the end of 2017 to continue to improve the existing IMAP and Sieve standards – Email mailstore and eXtensions To Revise or Amend (EXTRA). If there’s one thing the IETF loves more than anything else, it’s a good acronym for a working group name. Bonus points if you can work a pun in. I sometimes suspect that the primary criterion for starting a new working group is whether the name is cool enough.
Anyway… I’m also a chair on the EXTRA working group, and EXTRA and JMAP authors are keeping an eye on each others’ work to ensure that it remains possible to support both protocols in the same server.
Over the past few years, the IETF has been hosting a hackathon immediately before the main conference. This gives an opportunity for developers and authors to work together to test ideas and interoperability throughout the standards process.
In Chicago (IETF98) we arrived too late to participate in the hackathon.
In Prague (IETF99) we had no specific plans for the hackathon, but we did arrive in time to join. Since most of the mail people were sitting on the ARC working group table, we joined them. While Neil worked on JMAP standards documents, I hacked an initial implementation of ARC into the perl Mail::DKIM module and Authentication Milter.
I handed my initial experiments over to Marc to be tidied up and made production grade, and it is now being used to authenticate and seal all incoming mail at FastMail, as well as being available as open source to everybody else. The OpenARC implementation from the Trusted Domain Project was just released today and we expect to continue working on ARC both at IETF and elsewhere over the coming year.
At the recent IETF100 in Singapore just last month, Neil and I updated both the client and proxy to the latest spec changes, and made good progress in testing the new submission object. My day job includes significantly less programming these days, so the hackathon was a nice opportunity to focus on code for a few uninterupted hours!
Fastmail’s open API makes creating new and exciting tools easy for email enthusiasts.
At the beginning of December, we announced the return of Fastmail Advent. Please enjoy this wrap-up of our staff members’ responses.