
JMAP is on the home straight - ac29
https://fastmail.blog/2018/12/27/jmap-is-on-the-home-straight/
======
stonogo
"The IETF likes separation of concerns" but they're letting Google et al. ram
through MTA-STS, which fails to define a standard port number for SMTP-over-
TLS and instead requires MTA implementations to _also_ be able to fetch port
numbers over https, a completely unrelated protocol.

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?

~~~
icebraining
You may disagree, but there are other reasons not to rely on DNSSEC besides
"mortal men not being capable of understanding it":
[https://sockpuppet.org/blog/2015/01/15/against-
dnssec/](https://sockpuppet.org/blog/2015/01/15/against-dnssec/)

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.

~~~
AndyMcConachie
The blog you quote is from 2015. Let's look at some recent numbers on
DNSSEC/DANE deployment.

[https://stats.dnssec-tools.org/#graphs](https://stats.dnssec-
tools.org/#graphs)

~~~
dullgiulio
These graphs don't address any of the points. Even worse, those numbers don't
say anything about how many DNS requests are actually verified... A good guess
is that those crypto keys sit idle.

------
tjoff
I have not tried it or looked at it too closely (since neither my server nor
client supports it). But I desperately hope that JMAP succeeds. It's exactly
what email needs. IMAP and POP are just so inadequate that locking yourself
into gmail/whatever is a reasonable choice.

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.

~~~
chrismorgan
I’ve roughly planned a talk entitled “building a fair dinkum email client in
half an hour with JMAP” (I’d take an hour if permitted; the result would be
much better). The talk is mostly live coding the thing from scratch, with
authentication being the only area where I cheat. I submitted it for Strange
Loop earlier this year, but it wasn’t accepted, so I haven’t actually written
it yet. Anyone got any suggestions of places to submit it to?

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.

~~~
lucb1e
36C3 (next year's chaos community congress)? I'd love to see that talk, either
in real life or online. Coding my own mail client is something I wanted to do
for a long time and if I can make decent headway in only 30-60 minutes, I'd
definitely watch that and code along.

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.

~~~
chrismorgan
For the base version of the talk I’m just using straight HTML and JavaScript
with no external libraries. Variants of the talk using other libraries (e.g.
React, Vue, whatever the flavour of the month is) would be reasonable. All it
needs is for the JMAP endpoint to be CORS-enabled (probably a bad idea in
general), or for a simple pass-through proxy to work around that (I’ve already
made a simple such tool for personal use at FastMail). Other than that, it’s
just running in the browser with no external dependencies; that’s one of the
great things about JMAP, compared to IMAP: it’s web-native.

------
saghul
As a Fastmail customer and standards enthusiast (been to a couple of IETFs
myself) this makes me extremely happy. Kudos for following the standards path
in this world of walled gardens.

~~~
lolc
I especially liked how they said the process improved the protocol.

------
shakna
> Clients that want to or need to (for example those doing PGP in the client)
> can still fetch the RFC5322 if needed. The message is represented by a
> blobId, and the raw bytes can be fetched using the same binary download
> mechanism as mentioned above.

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.

~~~
philipwhiuk
PGP/MIME / SMIME / Autocrypt and email is a chasm of insanity. You're
constantly making choices about security vs usability and the user needs to be
aware of them and yet the UX quickly becomes a maelstrom of icons and text and
options and ...

Mailing lists are a big problem you have to solve and none of the solutions
are very good.

~~~
shakna
That sounds like the perfect opportunity for a new email protocol like JMAP to
solve.

~~~
Mailtemi
Guess you're miss what JMAP protocol is trying to solve. It is not about
content of the emails, but how emails are synchronized.

~~~
shakna
I haven't missed that.

I just believe, in today's atmosphere, synchronisation where encryption is a
second-class citizen is a missed opportunity.

~~~
amdavidson
When the email has been generated by some far off server, you want JMAP to
apply a new layer of encryption on top of it while inside an HTTPS pipe?

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.

~~~
shakna
No. But encrypted blobs are somewhat expected to fall within MIMEFiles.

> 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.

~~~
Mailtemi
It is just a transport protocol. If email is SMIME/PGP encrypted the server
will return for the email that has only one attachment with mime type
"application/pkcs7-mime smime-type=enveloped-data". How this blob is processed
is managed by the client if support SMIME or PGP. Do not forget email is a
federated set of protocols, so the encryption cannot rely on servers, except
if they are a walled garden as Proton for example.

------
mrmondo
I’ve got to say I’ve been very impressed with JMAP using it with FastMail for
a few years now. Well done to the teams involved.

~~~
justusthane
Wait, you can use JMAP with Fastmail currently?

~~~
chrismorgan
As mentioned in the article, 30% of our customers have been switched to the
new JMAP-based interface. We’ll resume migrating the rest in the new year.

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.

~~~
justusthane
Got it, thanks! Looking forward to the transition (and even more so to 3rd-
party JMAP clients!)

------
buchanae
I just implemented an IMAP parser/server in Go. I found myself thinking
(wishing) a lot for HTTP, JSON, stateless connections, etc. I'm happy to see
someone has taken the lead in improving such an entrenched technology.

------
jchw
Hadn't heard of JMAP till just now and now I'm amazed it took this long for it
to exist. It seems so obvious, in many ways.

Though I'm sure MIME will always be a bit of a trash fire to deal with.

------
tmikaeld
Are there any other E-mail clients that support JMAP yet?

~~~
Mailtemi
Doesn't exist yet. Hopefully, once the standard is finalized and has a server
to offer public JMAP support will be adopted by email clients. I'm currently
working on adding support for JMAP, but to have reference server I need to
build and setup latest Cyrus from scratch which was a challenging experience.

------
Mailtemi
JMAP client and the protocol impresses a lot. Just 1 to few calls, you can re-
sync entire emails state in all folders. With IMAP need to select each folder
to inspect its state. Moreover, just a few IMAP servers support fast
synchronization extensions like QRESYNC or CONDSTORE.

------
PaulHoule
Where are the JMAP clients?

~~~
tree_of_item
Where are the JMAP servers? The protocol isn't finished yet.

~~~
ac29
The protocol isn't finished yet, but there are implementations - I believe the
primary one is Cyrus: [https://github.com/cyrusimap/cyrus-
imapd](https://github.com/cyrusimap/cyrus-imapd)

~~~
rsto
Yes, in Cyrus IMAP we take care to follow the latest spec. It's the version
that drives the JMAP backend at FastMail.

The JMAP website has a list of other clients and server:
[https://jmap.io/software.html](https://jmap.io/software.html)

------
nailer
Great but:

> 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."

~~~
joshka
I'm trying to understand your objection to this name a bit better, but I can't
quite agree with the things you've stated as problems. You seem to be arguing
for increasing the ambiguity where there really isn't any:

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?

~~~
nailer
You have, but I don't really know how I could explain it more simply. I'll try
though using your analogy.

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.

