Re: [Jmap] Submission

Alexey Melnikov <alexey.melnikov@isode.com> Wed, 19 April 2017 20:17 UTC

Return-Path: <alexey.melnikov@isode.com>
X-Original-To: jmap@ietfa.amsl.com
Delivered-To: jmap@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 977D7129C47 for <jmap@ietfa.amsl.com>; Wed, 19 Apr 2017 13:17:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NszZeTy6Y4Wj for <jmap@ietfa.amsl.com>; Wed, 19 Apr 2017 13:17:41 -0700 (PDT)
Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id EE5CC1293E1 for <jmap@ietf.org>; Wed, 19 Apr 2017 13:17:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1492633060; d=isode.com; s=june2016; i=@isode.com; bh=0dySK/TC60wbL+IuvsqtIYCjdygzSbVmHYg1ou5+Xe8=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=ShqNNp8817WoviXFQQ35+ZzHU12fpbufEYFUhg4FsnJ/3hOChSGzo7wYtGV02TzKL4qbWc c2sQT5Mo99//KEP8MnE0Lm2vIsCPQ8br1iPFtBCMCXl2ae1t7VxJY3yrYyerRT+GKzc2nV ZtgH2M2bi7Kw0tQvMCikO760FrKSjok=;
Received: from [192.168.0.6] (cpc121086-nmal24-2-0-cust54.19-2.cable.virginm.net [77.97.145.55]) by statler.isode.com (submission channel) via TCP with ESMTPSA id <WPfF4wB5Y033@statler.isode.com>; Wed, 19 Apr 2017 21:17:39 +0100
X-SMTP-Protocol-Errors: PIPELINING
From: Alexey Melnikov <alexey.melnikov@isode.com>
X-Mailer: iPad Mail (14A456)
In-Reply-To: <89E217B2-A700-498C-BA72-3FD9939F34C7@fugue.com>
Date: Wed, 19 Apr 2017 21:38:47 +0100
Cc: Chris Newman <chris.newman@oracle.com>, "jmap@ietf.org" <jmap@ietf.org>
Message-Id: <B1563B04-AA25-47CA-9D63-D8B6CD4B3257@isode.com>
References: <em27fa7b29-5584-44f3-aa88-086ce734ab59@bodybag> <096E2D4B-D7ED-4439-BB6F-7944892D2ACA@oracle.com> <89E217B2-A700-498C-BA72-3FD9939F34C7@fugue.com>
To: Ted Lemon <mellon@fugue.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="Apple-Mail-7C9965E6-CECE-4A97-88AC-131CACE67A42"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/jmap/SxPoKqLwOoxwMdjVt6B3rGO9NNk>
Subject: Re: [Jmap] Submission
X-BeenThere: jmap@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: JSON Message Access Protocol <jmap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jmap>, <mailto:jmap-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jmap/>
List-Post: <mailto:jmap@ietf.org>
List-Help: <mailto:jmap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jmap>, <mailto:jmap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Apr 2017 20:17:43 -0000

> On 19 Apr 2017, at 20:36, Ted Lemon <mellon@fugue.com> wrote:
> 
>> On Apr 19, 2017, at 3:29 PM, Chris Newman <chris.newman@oracle.com> wrote:
>> When deploying a large mail service it's important to keep the submission mail queues (which have management/monitoring issues) functionally separate from the mail store (which has very different management/monitoring issues). If the JMAP design requires a mail queue to be present on the JMAP server or present in the mail store, that is an unacceptable protocol design error as it hinders the manageability of large deployments.
> 
> Isn't this just an implementation detail?   IOW, how is it different to have a different protocol for queuing messages, versus having different handling for a mailbox with a specific name?

It is not clear to me why a queue can't be also a mailbox. Interfaces seem to be pretty similar for both.

But anyway, Outbox doesn't really have to be a part of the mailstore, it can be just exposed as a mailbox in JMAP.

> Your three requirements, which make sense to me, could be added as attributes to the message once it's been sent.

Right (or they can be a part of the message when it is created. But this is not important right now.)
> 
> I'm not convinced that this is the right way to handle it—it means that the MUA has to be specifically watching for changes in the submit mailbox, or else that there has to be a submit and a sent mailbox,

There are both.

> and the MUA has to watch the sent mailbox.

Can you elaborate on why you think MUA has to watch the Sent mailbox? In order to report to the user that a message was sent? I suspect we can use JMAP notifications for that.

>   But ISTM that we have to provide ways of doing all these things anyway, so having an additional protocol may not actually be worth the complexity.