Re: [Jmap] Best vs Good enough - adoption of JMAP

[Ted Lemon <[e-mail]>]

On Apr 24, 2017, at 8:39 PM, Chris Newman <[e-mail]> wrote:
> I've never heard of a mail client author implementing a feature before the server exists. Server authors are the ones who have moved first in the email community. So the key to JMAP deployability is to make it not unnecessarily hostile to server developers (like myself) and server operators. But I agree we also want JMAP to provide significant benefits to client authors and their users. There are many design choices JMAP can make that meet all of these goals.

This seems like a problem, though.   If the whole thing is geared toward server vendors, then UX is out not at all visible: you don't get to find out about UX until you have an MUA.

> For example, if I'm operating a million-user deployment, it's critical to monitor the mail queues for problems. The proposed JMAP "outbox" model means I'm adding one million new mail queues to the monitoring system. That's a major deployment change; and thus a significant barrier to JMAP deployability.

This doesn't really follow.   It's perfectly possible that the way that the backend implements this is that when something is stuffed in outbox, it's put in the global mail queue, moved to sent, and the delivery status in sent is "pending."   Now the MUA can tell that the message has been queued, but no delivery attempt has been made.   Once the delivery attempt is completed, the MTA returns a status to the JMAP server indicating that the mail has been sent, or that it failed.   Or it doesn't; if it doesn't support this, then we just mark the message as "sent" as soon as it is queued.   But the facility for a richer status report is present.   In principle the JMAP server can use properly formatted and authenticated bounce messages to update delivery status if that is available.   (obviously, iterate across all the destination addresses on the message.)

> Well that's no problem from an infrastructure viewpoint as long as the JMAP server is permitted to perform the base64-encoding on binary message parts at submission/append time in order to remain compatible with IMAP mail stores (and non-BINARYMIME submission servers).

I'm probably revealing my naivete here, but _seriously_?   IMAP allows 8-bit messages, and even provides a way to require that clients support them.   Are you saying that these million-user IMAP servers are so ancient and clunky that they don't do that, or am I missing something?