A few years ago, returning to the hotel by car after one of the M3AAWG conferences, I remember having a conversation with atmail’s founder, Ben Duncan.  It went like a lot of those conversations do, trying to communicate with someone who is excited about a game changing technology, all the while they’re having the same conversation everyone else in the car, with no particular conclusions being reached. But there were a few things that stuck out to me: “JMAP”; “These guys are really switched on”; and “Ditch ActiveSync”.

As a company, atmail been playing with push technology for years with varying levels of success. Dealing with the same pitfalls many in this space deal with: integrating someone else’s technology into ours; or coming up with our own version of it.  Either way, we were paying a licence fee to Microsoft for the privilege. While we had played this game for a while, it really wasn’t the way we wanted to see it done, it wasn’t atmail.

Fast forward six months and internal discussions got serious when planning the next version of atmail’s web interface. Do we build on top of the same technology we’ve been using for the last five years? Or do we change it up and become pioneers once again?

Big decisions, the soul searching kind, led to the big commitment to completely redesign atmail’s flagship webmail product from the ground up. The deciding factor, in the face of the fast-paced messaging world, was that it would have been more difficult to solve the new problems being faced with the same old tools in the box. It was decided, that it was worth the time and effort to start with a new set of tools and all new materials, facing whatever new challenges would come. One of these new tools was JMAP.

 

But isn’t email dead?

Haha, no. We hear regularly about how there is no space for email anymore and every time something new and shiny comes out, you’ll see blog posts about how email is dead. Yet in reality, email is still one of the core methods of communication, nothing comes close in allowing interoperability between providers, nor the end senders and receivers. When in doubt, ask for an email address – it’s assumed everyone has a phone number and an email address.

Maybe you don’t use it as much. Maybe it might not be the first application you think about opening when you just need to say hi or check in on something. We know that usage of email has changed over time and we know that email is a choice among many options when you want to communicate with someone who isn’t in the same room. But when you’re looking to disseminate information that you need someone to take the time to read properly and understand as a complete thought, that’s when you’ll find yourself still leveraging the magic that email has been delivering since its invention by Ray Tomlinson in 1972.

Email is where we now store everything we consider ‘official’; it has become our electronic locker. It’s where I store the important receipts, or that official complaint I lodged with my electricity company, or where Gran sends me those pictures she took of me when I was a toddler.

So I say, email is not dead. Long live email!

 

Changes to how people consume email

One of the largest obstacles we were up against when deciding how to proceed at atmail was the change in how people consume email today. For example, I’m constantly sitting at my desk using my laptop and have both the web interface open for my email and another desktop client open at the same time and my mobile sitting next to my laptop, also running an email client (all connected to the same account). I hate delays and I want need my multiple devices to sync simultaneously.

 

JMAP, atmail JMAP proxy, atmail email

 

How does JMAP make email better?

JSON Meta Application Protocol (JMAP) helps make email better because it provides a way to make communication with email back ends consistent when using multiple devices. JMAP makes it possible for me to get my email on all of these systems updated nearly simultaneously.

How does it do this?

JMAP sits between the atmail user interfaces (both web and mobile devices) and the atmail server components (IMAP, DAV and admin) and decides when to push data from my mobile to the IMAP server on the back end, or when to tell the web client that there is an update on the server that needs to be viewed.

Why do we need JMAP for this? Doesn’t IMAP already handle this?

Well, yes and no. Technically IMAP does do these things, but it doesn’t do them as efficiently as it does with JMAP, with people using more than two devices at a time for email. Ask any service provider and they will tell you that whilst traffic rates are not growing as quickly anymore, the number of simultaneous connections is growing rapidly – soon, IMAP just won’t cut it.

JMAP is stateless. It doesn’t require a persistent connection to function. This is huge for mobile use or anytime you have an intermittent network connection, as well as anytime you want to turn your mobile off to conserve battery. IMAP on the other hand requires a continuously maintained TCP connection, using the IDLE extension, to receive IMAP events.  JMAP is perfect for today’s push notification technologies integrated with mobile devices.

JMAP communicates over HTTP(S), which is a plus, as the extensive nature of this standard web protocol makes it far less of a problem with networking and firewalls. This in turn makes it much easier to create applications for the general public to use and it also results in fewer support issues for email teams.

JMAP allows us to let the client control the amount of data the server sends and it does it in such a way that the server isn’t overloaded with error messages when the client’s limit has been exceeded.

As an example, say you’re on the train, moving through spotty coverage on your phone. JMAP can help us keep track of when the data cached on your client is complete (or not) and more efficiently make a decision on how to get the information moved between your device and the server. It is also backwards compatible with both IMAP folders and Gmail’s label system. This makes it extremely appealing to our clients who have invested so many resources into their existing infrastructure, but want to still take advantage of what JMAP has to offer.

Oh, and it’s a free open standard – goodbye ActiveSync!

 

Could JMAP replace IMAP?

This is really only scratching the surface of what JMAP brings to the table in the messaging world, where the existing technology just isn’t up to the task. The way IMAP communicates and the way it depends on a stateful connection, makes it inefficient in today’s world of more mobile devices and the intermittent connectivity inherent to their use – both in the amount of resources the IMAP server uses and in the wasted bandwidth required to re-sync all of the data on your mobile device that is invalidated with a simple name change of a folder.

IMAP is, and will continue to be, a useful protocol and I believe we’ll still be using it for messaging for some time to come. While JMAP could replace IMAP for a number of things in messaging world, I believe it’s real power is in where it can be used to make existing technology better. We can build clients that use JMAP when it’s appropriate and use IMAP where it might be a better solution. JMAP isn’t displacing IMAP (yet). Rather, it’s one more tool in the tool box that we have at our disposal to curate the best possible email experience for customers.

 

Want to learn more about JMAP?

For more details on JMAP and how you can get involved with this new set of tools to make the messaging world a better place, please visit the JMAP site here.

For more details on how you can tap into the power of our atmail JMAP proxy in our newest version of atmail (atmail suite/atmail webX), contact us here.

For open source enthusiasts, we’re considering making our atmail JMAP proxy open-source in the future to strengthen the JMAP community. Watch this space.

 

atmail_suite_updated_jmap_proxy

Written by Jason Brown and Dave Richards

 

 

27 March 2019 update on the progress of JMAP as a proposed official protocol:

JSON Meta Application Protocol

Memo for Internet Official Protocol Standards