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

[Bron Gondwana <[e-mail]>]

On Tue, 25 Apr 2017, at 10:54, Ted Lemon wrote:
> On Apr 24, 2017, at 8:39 PM, Chris Newman
> <[e-mail]> wrote:>> 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.)
All this is assuming that you have a writeback rather than writethrough
Outbox.  The implementation of Outbox in the perl JMAP proxy, for
example, is synchronous and emphemeral.  Nothing can ever actually exist
in the Outbox.  It's 79 lines of perl - currently here:
https://github.com/jmapio/jmap-perl/blob/master/JMAP/ImapDB.pm#L1116

It formulates the SMTP command, submits the content, then puts the
message in the Sent folder, all within a single DB transaction.
It's easy to create a JMAP server which doesn't hold messages in a queue
in the Outbox.  Though we also need event handling for Calendar Alerts
and other fun stuff in our server, so having those queues include
Outboxes isn't actually a huge additional management expense.  The
server will already have tooling for tracking events which are supposed
to fire for newly added messages, and will already have error reporting
for any errors.  The fact that there are a million mailboxes (FastMail's
infrastructure is also on this scale) doesn't materially affect the
amount of work once there's automation.  No matter how many mailboxes
you have, a good infrastructure will have retry ability and quite
reliable outbound queue injection.
You just don't get failures transferring from Outbox into the regular
SMTP queues.  And if you do, at least the messages are within your
system rather than in someone's client where you wind up getting reports
of failures through support channels and are sitting there on third line
support trying to debug SMTP issues on somebody's local computer with
software outside your control on some bogus network with bogus
antivirus.
I much prefer debugging message transfer between two systems that I have
full control over.
Bron.

--
  Bron Gondwana
  [e-mail]