From nobody Mon Apr 3 02:13:41 2017 Return-Path: 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 9EC71129590 for ; Mon, 3 Apr 2017 02:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.108 X-Spam-Level: X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 W8AgF1I_SKwv for ; Mon, 3 Apr 2017 02:13:37 -0700 (PDT) Received: from alderaan.linagora.com (unknown [109.197.180.137]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 935B91295EA for ; Mon, 3 Apr 2017 02:13:36 -0700 (PDT) Received: from [10.11.114.151] (unknown [1.55.245.97]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by alderaan.linagora.com (Postfix) with ESMTPSA id 592773EEA for ; Mon, 3 Apr 2017 11:13:32 +0200 (CEST) To: jmap@ietf.org References: <148716911729.17277.15371202023742081890.idtracker@ietfa.amsl.com> From: Benoit Tellier Message-ID: Date: Mon, 3 Apr 2017 16:13:24 +0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: [Jmap] Adding the Message::isForwarded property X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 09:13:40 -0000 Hello, At Linagora, we tend to consider **forward** information as important for the email we care about. Today, it is not part of the RFC-3501 spec, and many IMAP implementations handle it with the de-facto standard $Forwarded flag. This implicit standard is a bad thing, and we truly would like the JMAP mail protocol to do this right. To be right, it should be explicit. We then propose this pull request: It reproduces the behavior of **answered** feature: - Adds a **isForwarded** message property - Adds a mechanism for automatically marking messages as forwarded upon sending emails - Clarifies interactions between isForwarded and threads - Makes isForwarded searchable Does this proposal make sense to you? Best regards, Benoit Tellier ----------------------------- Software engineer at Linagora PMC on Apache JAMES Le 01/04/2017 à 06:23, Dave Crocker a écrit : > G'day, > > The working group meeting discussion about a static message, dynamic > annotation, etc., resonated with a variety of similar discussions I've > been around over the years (dating back to the mid-1970.) > > A simpler version equates the constructs of message and document, as > two views of the same thing. (Ie, Document with attributes; Message > with a body.) > > The essence is to consider the nature and relationship of the objects, > possibly permitting different semantics for the same set of objects, > according to different applications or roles. > > That is, there can be a variety of constituent objects that are > associated and can be viewed according to different semantics (or > views)... So a message, a document, a calendar entry, a series of > comments, etc. Each object has associated processing rules (eg, > static vs. editable vs. executable; constrained choice of values; > organization into folders or other schemas...) > > An environment like this can be powerful and very appealing. The > challenge tends to be staying practical: With no effort at all it > devolves into an abstract computer science exercise. Some of that is > an efficiency issue(*) but I think it's mostly about the human > manageability for design and operations. > > Based on both the years of commercial use and the public commentary > about the performance, I've no doubt the fastmail system does not > suffer these downsides. But it's a potential that this re-casting > through the IETF could easily suffer. > > I'm posting this note partly because I think it would exciting to > produce specs that permit a degree of flexibility that such an > approach permits, but also wanted to cite the dangers. > > At the moment, I'm guessing there needs to be a small number of basic > object types and a small number of 'relationship' types that define > the association between objects. These could then be combined into > higher-order, formal organizations/semantics the define an application > semantic (mail, calendar, whatever.) > > > d/ > > (*) A system I did in 1977 has a little bit of this and the extremely > pure design produced impressively horrible performance. > From nobody Mon Apr 3 02:23:55 2017 Return-Path: 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 1C90312960D for ; Mon, 3 Apr 2017 02:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.108 X-Spam-Level: X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 Sk9KqpPE-_rc for ; Mon, 3 Apr 2017 02:23:44 -0700 (PDT) Received: from alderaan.linagora.com (unknown [109.197.180.137]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EDBE1295EA for ; Mon, 3 Apr 2017 02:16:00 -0700 (PDT) Received: from [10.11.114.151] (unknown [1.55.245.97]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by alderaan.linagora.com (Postfix) with ESMTPSA id 1E55A356A for ; Mon, 3 Apr 2017 11:15:57 +0200 (CEST) To: jmap@ietf.org References: <148716911729.17277.15371202023742081890.idtracker@ietfa.amsl.com> From: Benoit Tellier Message-ID: Date: Mon, 3 Apr 2017 16:15:50 +0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Jmap] Adding the Message::isForwarded property X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 09:23:54 -0000 Link to the pull request: https://github.com/jmapio/jmap/pull/58 Le 03/04/2017 à 16:13, Benoit Tellier a écrit : > Hello, > > At Linagora, we tend to consider **forward** information as important > for the email we care about. > > Today, it is not part of the RFC-3501 spec, and many IMAP > implementations handle it with the de-facto standard $Forwarded flag. > > This implicit standard is a bad thing, and we truly would like the JMAP > mail protocol to do this right. To be right, it should be explicit. > > We then propose this pull request: > > It reproduces the behavior of **answered** feature: > > - Adds a **isForwarded** message property > - Adds a mechanism for automatically marking messages as forwarded upon > sending emails > - Clarifies interactions between isForwarded and threads > - Makes isForwarded searchable > > Does this proposal make sense to you? > > Best regards, > > Benoit Tellier > ----------------------------- > Software engineer at Linagora > PMC on Apache JAMES > > > Le 01/04/2017 à 06:23, Dave Crocker a écrit : >> G'day, >> >> The working group meeting discussion about a static message, dynamic >> annotation, etc., resonated with a variety of similar discussions I've >> been around over the years (dating back to the mid-1970.) >> >> A simpler version equates the constructs of message and document, as >> two views of the same thing. (Ie, Document with attributes; Message >> with a body.) >> >> The essence is to consider the nature and relationship of the objects, >> possibly permitting different semantics for the same set of objects, >> according to different applications or roles. >> >> That is, there can be a variety of constituent objects that are >> associated and can be viewed according to different semantics (or >> views)... So a message, a document, a calendar entry, a series of >> comments, etc. Each object has associated processing rules (eg, >> static vs. editable vs. executable; constrained choice of values; >> organization into folders or other schemas...) >> >> An environment like this can be powerful and very appealing. The >> challenge tends to be staying practical: With no effort at all it >> devolves into an abstract computer science exercise. Some of that is >> an efficiency issue(*) but I think it's mostly about the human >> manageability for design and operations. >> >> Based on both the years of commercial use and the public commentary >> about the performance, I've no doubt the fastmail system does not >> suffer these downsides. But it's a potential that this re-casting >> through the IETF could easily suffer. >> >> I'm posting this note partly because I think it would exciting to >> produce specs that permit a degree of flexibility that such an >> approach permits, but also wanted to cite the dangers. >> >> At the moment, I'm guessing there needs to be a small number of basic >> object types and a small number of 'relationship' types that define >> the association between objects. These could then be combined into >> higher-order, formal organizations/semantics the define an application >> semantic (mail, calendar, whatever.) >> >> >> d/ >> >> (*) A system I did in 1977 has a little bit of this and the extremely >> pure design produced impressively horrible performance. >> > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap From nobody Mon Apr 3 10:10:49 2017 Return-Path: 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 4F22F120046 for ; Mon, 3 Apr 2017 10:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.998 X-Spam-Level: X-Spam-Status: No, score=-6.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.796, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 orua9eDBOENR for ; Mon, 3 Apr 2017 10:10:46 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE01A128D69 for ; Mon, 3 Apr 2017 10:10:46 -0700 (PDT) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v33HAjHc003049 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 3 Apr 2017 17:10:45 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v33HAint003641 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 3 Apr 2017 17:10:45 GMT Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v33HAhEe026878; Mon, 3 Apr 2017 17:10:43 GMT Received: from [10.145.239.159] (/10.145.239.159) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 03 Apr 2017 10:10:43 -0700 From: "Chris Newman" To: "Benoit Tellier" Cc: jmap@ietf.org Date: Mon, 03 Apr 2017 10:10:21 -0700 Message-ID: In-Reply-To: References: <148716911729.17277.15371202023742081890.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: MailMate (1.9.6r5347) X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Subject: Re: [Jmap] Adding the Message::isForwarded property X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 17:10:48 -0000 IMAP $Forwarded is a registered keyword and thus a fully supported part = of IMAP: https://www.iana.org/assignments/imap-keywords/imap-keywords.xhtml#ima= p-keywords-1 There's no need for JMAP to define all these registered keywords; it = only needs to reference the registry. =3D Chris On 3 Apr 2017, at 2:13, Benoit Tellier wrote: > Hello, > > At Linagora, we tend to consider **forward** information as important > for the email we care about. > > Today, it is not part of the RFC-3501 spec, and many IMAP > implementations handle it with the de-facto standard $Forwarded flag. > > This implicit standard is a bad thing, and we truly would like the = > JMAP > mail protocol to do this right. To be right, it should be explicit. > > We then propose this pull request: > > It reproduces the behavior of **answered** feature: > > - Adds a **isForwarded** message property > - Adds a mechanism for automatically marking messages as forwarded = > upon > sending emails > - Clarifies interactions between isForwarded and threads > - Makes isForwarded searchable > > Does this proposal make sense to you? > > Best regards, > > Benoit Tellier > ----------------------------- > Software engineer at Linagora > PMC on Apache JAMES > > > Le 01/04/2017 =C3=A0 06:23, Dave Crocker a =C3=A9crit : >> G'day, >> >> The working group meeting discussion about a static message, dynamic >> annotation, etc., resonated with a variety of similar discussions = >> I've >> been around over the years (dating back to the mid-1970.) >> >> A simpler version equates the constructs of message and document, as >> two views of the same thing. (Ie, Document with attributes; Message >> with a body.) >> >> The essence is to consider the nature and relationship of the = >> objects, >> possibly permitting different semantics for the same set of objects, >> according to different applications or roles. >> >> That is, there can be a variety of constituent objects that are >> associated and can be viewed according to different semantics (or >> views)... So a message, a document, a calendar entry, a series of >> comments, etc. Each object has associated processing rules (eg, >> static vs. editable vs. executable; constrained choice of values; >> organization into folders or other schemas...) >> >> An environment like this can be powerful and very appealing. The >> challenge tends to be staying practical: With no effort at all it >> devolves into an abstract computer science exercise. Some of that is >> an efficiency issue(*) but I think it's mostly about the human >> manageability for design and operations. >> >> Based on both the years of commercial use and the public commentary >> about the performance, I've no doubt the fastmail system does not >> suffer these downsides. But it's a potential that this re-casting >> through the IETF could easily suffer. >> >> I'm posting this note partly because I think it would exciting to >> produce specs that permit a degree of flexibility that such an >> approach permits, but also wanted to cite the dangers. >> >> At the moment, I'm guessing there needs to be a small number of basic >> object types and a small number of 'relationship' types that define >> the association between objects. These could then be combined into >> higher-order, formal organizations/semantics the define an = >> application >> semantic (mail, calendar, whatever.) >> >> >> d/ >> >> (*) A system I did in 1977 has a little bit of this and the extremely >> pure design produced impressively horrible performance. >> > > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap From nobody Mon Apr 3 10:43:18 2017 Return-Path: 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 DA80D1294BE for ; Mon, 3 Apr 2017 10:43:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 UF6FqPzUV8jR for ; Mon, 3 Apr 2017 10:43:14 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id C40B01294B3 for ; Mon, 3 Apr 2017 10:43:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1491241393; d=isode.com; s=june2016; i=@isode.com; bh=ZTHazCsbk/44eDak14HInPMy7Ab2xcFAtMO/sbOaAeU=; 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=BQ9j2zwkGijUUDcvd4wuSKK/oxTIG0bzH8QdfUpO2iHu2Xr80UHgVUgBa8kBcRxCHQlFcN 4BqK3FGmeuoLx/zkV02iOqOd9GxMCmB+Drx6Pq8b1ZnvAL3toxcKXH7dU7aAzE7gTIZ1gi YTG6eC+x9T5mbvq90qJvGmJimOqwA+M=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 3 Apr 2017 18:43:13 +0100 To: Chris Newman , Benoit Tellier References: <148716911729.17277.15371202023742081890.idtracker@ietfa.amsl.com> Cc: jmap@ietf.org From: Alexey Melnikov Message-ID: <9eb1fd3c-8868-9d24-6c30-46d333b69fef@isode.com> Date: Mon, 3 Apr 2017 18:43:09 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [Jmap] Adding the Message::isForwarded property X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 17:43:17 -0000 On 03/04/2017 18:10, Chris Newman wrote: > IMAP $Forwarded is a registered keyword and thus a fully supported=20 > part of IMAP: > > https://www.iana.org/assignments/imap-keywords/imap-keywords.xhtml#imap-ke= ywords-1 > > There's no need for JMAP to define all these registered keywords; it=20 > only needs to reference the registry. Agreed. And at the Chicago face-to-face meeting I've raised the issue of=20 lack of generic access to IMAP keywords in JMAP. I believe there was=20 room agreement to fix it in a generic way. > > =3D Chris > > On 3 Apr 2017, at 2:13, Benoit Tellier wrote: > >> Hello, >> >> At Linagora, we tend to consider **forward** information as important >> for the email we care about. >> >> Today, it is not part of the RFC-3501 spec, and many IMAP >> implementations handle it with the de-facto standard $Forwarded flag. >> >> This implicit standard is a bad thing, and we truly would like the JMAP >> mail protocol to do this right. To be right, it should be explicit. >> >> We then propose this pull request: >> >> It reproduces the behavior of **answered** feature: >> >> - Adds a **isForwarded** message property >> - Adds a mechanism for automatically marking messages as forwarded upon >> sending emails >> - Clarifies interactions between isForwarded and threads >> - Makes isForwarded searchable >> >> Does this proposal make sense to you? >> >> Best regards, >> >> Benoit Tellier >> ----------------------------- >> Software engineer at Linagora >> PMC on Apache JAMES >> >> >> Le 01/04/2017 =C3=A0 06:23, Dave Crocker a =C3=A9crit : >>> G'day, >>> >>> The working group meeting discussion about a static message, dynamic >>> annotation, etc., resonated with a variety of similar discussions I've >>> been around over the years (dating back to the mid-1970.) >>> >>> A simpler version equates the constructs of message and document, as >>> two views of the same thing. (Ie, Document with attributes; Message >>> with a body.) >>> >>> The essence is to consider the nature and relationship of the objects, >>> possibly permitting different semantics for the same set of objects, >>> according to different applications or roles. >>> >>> That is, there can be a variety of constituent objects that are >>> associated and can be viewed according to different semantics (or >>> views)... So a message, a document, a calendar entry, a series of >>> comments, etc. Each object has associated processing rules (eg, >>> static vs. editable vs. executable; constrained choice of values; >>> organization into folders or other schemas...) >>> >>> An environment like this can be powerful and very appealing. The >>> challenge tends to be staying practical: With no effort at all it >>> devolves into an abstract computer science exercise. Some of that is >>> an efficiency issue(*) but I think it's mostly about the human >>> manageability for design and operations. >>> >>> Based on both the years of commercial use and the public commentary >>> about the performance, I've no doubt the fastmail system does not >>> suffer these downsides. But it's a potential that this re-casting >>> through the IETF could easily suffer. >>> >>> I'm posting this note partly because I think it would exciting to >>> produce specs that permit a degree of flexibility that such an >>> approach permits, but also wanted to cite the dangers. >>> >>> At the moment, I'm guessing there needs to be a small number of basic >>> object types and a small number of 'relationship' types that define >>> the association between objects. These could then be combined into >>> higher-order, formal organizations/semantics the define an application >>> semantic (mail, calendar, whatever.) >>> >>> >>> d/ >>> >>> (*) A system I did in 1977 has a little bit of this and the extremely >>> pure design produced impressively horrible performance. >>> >> >> _______________________________________________ >> Jmap mailing list >> Jmap@ietf.org >> https://www.ietf.org/mailman/listinfo/jmap > > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap From nobody Tue Apr 4 03:08:46 2017 Return-Path: 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 31043129415 for ; Tue, 4 Apr 2017 03:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.106 X-Spam-Level: X-Spam-Status: No, score=-1.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RDNS_NONE=0.793, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 0l-HlS0LPS4i for ; Tue, 4 Apr 2017 03:08:42 -0700 (PDT) Received: from alderaan.linagora.com (unknown [109.197.180.137]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD1C1129452 for ; Tue, 4 Apr 2017 03:08:41 -0700 (PDT) Received: from [10.11.114.151] (unknown [1.55.245.97]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by alderaan.linagora.com (Postfix) with ESMTPSA id 2A9A07A8; Tue, 4 Apr 2017 12:08:36 +0200 (CEST) To: Alexey Melnikov , Chris Newman References: <148716911729.17277.15371202023742081890.idtracker@ietfa.amsl.com> <9eb1fd3c-8868-9d24-6c30-46d333b69fef@isode.com> Cc: jmap@ietf.org From: Benoit Tellier Message-ID: <3c1711a2-46dd-db1c-506e-5e1ad89ce56d@linagora.com> Date: Tue, 4 Apr 2017 17:08:31 +0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <9eb1fd3c-8868-9d24-6c30-46d333b69fef@isode.com> Content-Type: multipart/alternative; boundary="------------21DC8916990A47A0DA4ECA9D" Archived-At: Subject: Re: [Jmap] Adding the Message::isForwarded property X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 10:08:45 -0000 This is a multi-part message in MIME format. --------------21DC8916990A47A0DA4ECA9D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit |Hi, | |Thanks for your answers. How do you plan to access such registered keyword, if it is not made somehow a message property?| |As a JMAP user I would like this to be very easily accessible from the Message object, and also it to be searchable. | |In the case of $Forwarded I think it needs to be consistent with the reply feature, for automatically marked as forwarded, and for threads.| |Cheers, | |Benoit Tellier| Le 04/04/2017 à 00:43, Alexey Melnikov a écrit : > On 03/04/2017 18:10, Chris Newman wrote: > >> IMAP $Forwarded is a registered keyword and thus a fully supported >> part of IMAP: >> >> https://www.iana.org/assignments/imap-keywords/imap-keywords.xhtml#imap-keywords-1 >> >> >> There's no need for JMAP to define all these registered keywords; it >> only needs to reference the registry. > Agreed. And at the Chicago face-to-face meeting I've raised the issue > of lack of generic access to IMAP keywords in JMAP. I believe there > was room agreement to fix it in a generic way. > >> >> = Chris >> >> On 3 Apr 2017, at 2:13, Benoit Tellier wrote: >> >>> Hello, >>> >>> At Linagora, we tend to consider **forward** information as important >>> for the email we care about. >>> >>> Today, it is not part of the RFC-3501 spec, and many IMAP >>> implementations handle it with the de-facto standard $Forwarded flag. >>> >>> This implicit standard is a bad thing, and we truly would like the JMAP >>> mail protocol to do this right. To be right, it should be explicit. >>> >>> We then propose this pull request: >>> >>> It reproduces the behavior of **answered** feature: >>> >>> - Adds a **isForwarded** message property >>> - Adds a mechanism for automatically marking messages as forwarded >>> upon >>> sending emails >>> - Clarifies interactions between isForwarded and threads >>> - Makes isForwarded searchable >>> >>> Does this proposal make sense to you? >>> >>> Best regards, >>> >>> Benoit Tellier >>> ----------------------------- >>> Software engineer at Linagora >>> PMC on Apache JAMES >>> >>> >>> Le 01/04/2017 à 06:23, Dave Crocker a écrit : >>>> G'day, >>>> >>>> The working group meeting discussion about a static message, dynamic >>>> annotation, etc., resonated with a variety of similar discussions I've >>>> been around over the years (dating back to the mid-1970.) >>>> >>>> A simpler version equates the constructs of message and document, as >>>> two views of the same thing. (Ie, Document with attributes; Message >>>> with a body.) >>>> >>>> The essence is to consider the nature and relationship of the objects, >>>> possibly permitting different semantics for the same set of objects, >>>> according to different applications or roles. >>>> >>>> That is, there can be a variety of constituent objects that are >>>> associated and can be viewed according to different semantics (or >>>> views)... So a message, a document, a calendar entry, a series of >>>> comments, etc. Each object has associated processing rules (eg, >>>> static vs. editable vs. executable; constrained choice of values; >>>> organization into folders or other schemas...) >>>> >>>> An environment like this can be powerful and very appealing. The >>>> challenge tends to be staying practical: With no effort at all it >>>> devolves into an abstract computer science exercise. Some of that is >>>> an efficiency issue(*) but I think it's mostly about the human >>>> manageability for design and operations. >>>> >>>> Based on both the years of commercial use and the public commentary >>>> about the performance, I've no doubt the fastmail system does not >>>> suffer these downsides. But it's a potential that this re-casting >>>> through the IETF could easily suffer. >>>> >>>> I'm posting this note partly because I think it would exciting to >>>> produce specs that permit a degree of flexibility that such an >>>> approach permits, but also wanted to cite the dangers. >>>> >>>> At the moment, I'm guessing there needs to be a small number of basic >>>> object types and a small number of 'relationship' types that define >>>> the association between objects. These could then be combined into >>>> higher-order, formal organizations/semantics the define an application >>>> semantic (mail, calendar, whatever.) >>>> >>>> >>>> d/ >>>> >>>> (*) A system I did in 1977 has a little bit of this and the extremely >>>> pure design produced impressively horrible performance. >>>> >>> >>> _______________________________________________ >>> Jmap mailing list >>> Jmap@ietf.org >>> https://www.ietf.org/mailman/listinfo/jmap >> >> _______________________________________________ >> Jmap mailing list >> Jmap@ietf.org >> https://www.ietf.org/mailman/listinfo/jmap > --------------21DC8916990A47A0DA4ECA9D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi,

Thanks for your answers. How do you plan to access such registered keyword, if it is not made somehow a message property?

As a JMAP user I would like this to be very easily accessible from the Message object, and also it to be searchable.

In the case of $Forwarded I think it needs to be consistent with the reply feature, for automatically marked as forwarded, and for threads.

Cheers,

Benoit Tellier


Le 04/04/2017 à 00:43, Alexey Melnikov a écrit :
On 03/04/2017 18:10, Chris Newman wrote:

IMAP $Forwarded is a registered keyword and thus a fully supported part of IMAP:

https://www.iana.org/assignments/imap-keywords/imap-keywords.xhtml#imap-keywords-1

There's no need for JMAP to define all these registered keywords; it only needs to reference the registry.
Agreed. And at the Chicago face-to-face meeting I've raised the issue of lack of generic access to IMAP keywords in JMAP. I believe there was room agreement to fix it in a generic way.


        = Chris

On 3 Apr 2017, at 2:13, Benoit Tellier wrote:

Hello,

At Linagora, we tend to consider **forward** information as important
for the email we care about.

Today, it is not part of the RFC-3501 spec, and many IMAP
implementations handle it with the de-facto standard $Forwarded flag.

This implicit standard is a bad thing, and we truly would like the JMAP
mail protocol to do this right. To be right, it should be explicit.

We then propose this pull request:

It reproduces the behavior of **answered** feature:

 - Adds a **isForwarded** message property
 - Adds a mechanism for automatically marking messages as forwarded upon
sending emails
 - Clarifies interactions between isForwarded and threads
 - Makes isForwarded searchable

Does this proposal make sense to you?

Best regards,

Benoit Tellier
-----------------------------
Software engineer at Linagora
PMC on Apache JAMES


Le 01/04/2017 à 06:23, Dave Crocker a écrit :
G'day,

The working group meeting discussion about a static message, dynamic
annotation, etc., resonated with a variety of similar discussions I've
been around over the years (dating back to the mid-1970.)

A simpler version equates the constructs of message and document, as
two views of the same thing.  (Ie, Document with attributes; Message
with a body.)

The essence is to consider the nature and relationship of the objects,
possibly permitting different semantics for the same set of objects,
according to different applications or roles.

That is, there can be a variety of constituent objects that are
associated and can be viewed according to different semantics (or
views)...  So a message, a document, a calendar entry, a series of
comments, etc.  Each object has associated processing rules (eg,
static vs. editable vs. executable; constrained choice of values;
organization into folders or other schemas...)

An environment like this can  be powerful and very appealing. The
challenge tends to be staying practical:  With no effort at all it
devolves into an abstract computer science exercise.  Some of that is
an efficiency issue(*) but I think it's mostly about the human
manageability for design and operations.

Based on both the years of commercial use and the public commentary
about the performance, I've no doubt the fastmail system does not
suffer these downsides.  But it's a potential that this re-casting
through the IETF could easily suffer.

I'm posting this note partly because I think it would exciting to
produce specs that permit a degree of flexibility that such an
approach permits, but also wanted to cite the dangers.

At the moment, I'm guessing there needs to be a small number of basic
object types and a small number of 'relationship' types that define
the association between objects.  These could then be combined into
higher-order, formal organizations/semantics the define an application
semantic (mail, calendar, whatever.)


d/

(*) A system I did in 1977 has a little bit of this and the extremely
pure design produced impressively horrible performance.


_______________________________________________
Jmap mailing list
Jmap@ietf.org
https://www.ietf.org/mailman/listinfo/jmap

_______________________________________________
Jmap mailing list
Jmap@ietf.org
https://www.ietf.org/mailman/listinfo/jmap


--------------21DC8916990A47A0DA4ECA9D-- From nobody Tue Apr 4 07:00:51 2017 Return-Path: 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 DE1131204DA for ; Tue, 4 Apr 2017 07:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 7e6O4ngGccqM for ; Tue, 4 Apr 2017 07:00:44 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id EA009127071 for ; Tue, 4 Apr 2017 07:00:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1491314442; d=isode.com; s=june2016; i=@isode.com; bh=j468KOHMo9hlhxC74awtn+J9W6/QR2AHzaszhUzO0ME=; 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=asYjPcAG/Wezq7lqHk9oQy0l+lujHcAatRMZl0633g2G+xGpRJujPSPW/2Tj4YyUeOxMiO H6ISOwKPIFfFdbFIVCfuy7J6dmOFbhUJEoS+9aaXg9yWDJHoygIeEOsK+m9jxIxAtVisPx JAyb7MrC0RHwB5DcngOcPYExo7qMFMc=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 4 Apr 2017 15:00:42 +0100 To: Benoit Tellier , Chris Newman References: <148716911729.17277.15371202023742081890.idtracker@ietfa.amsl.com> <9eb1fd3c-8868-9d24-6c30-46d333b69fef@isode.com> <3c1711a2-46dd-db1c-506e-5e1ad89ce56d@linagora.com> Cc: jmap@ietf.org From: Alexey Melnikov Message-ID: <92769755-62c6-7257-ce3d-7d0b5699735d@isode.com> Date: Tue, 4 Apr 2017 15:00:28 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 In-Reply-To: <3c1711a2-46dd-db1c-506e-5e1ad89ce56d@linagora.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------7CC7DBFF6E1F90CB0BD7B70A" Archived-At: Subject: Re: [Jmap] Adding the Message::isForwarded property X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 14:00:47 -0000 --------------7CC7DBFF6E1F90CB0BD7B70A Content-Type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: quoted-printable Hi Benoit, On 04/04/2017 11:08, Benoit Tellier wrote: > |Hi, > | > > |Thanks for your answers. How do you plan to access such registered=20 > keyword, if it is not made somehow a message property?| > | It has to be a message properly. For example "keywords" which contains=20 an array of other IMAP keywords as strings. I have other applications=20 that need to access to other keywords, some of which are listed on=20 | > > |As a JMAP user I would like this to be very easily accessible from=20 > the Message object, and also it to be searchable. > | > | Agreed. | > > || > > |In the case of $Forwarded I think it needs to be consistent with the=20 > reply feature, for automatically marked as forwarded, and for threads.| > | I wouldn't mind having some extra logic for forwarded messages, if the=20 group can agree on that. Best Regards, Alexey | > > |Cheers, > | > > |Benoit Tellier| > > > Le 04/04/2017 =C3=A0 00:43, Alexey Melnikov a =C3=A9crit : >> On 03/04/2017 18:10, Chris Newman wrote: >> >>> IMAP $Forwarded is a registered keyword and thus a fully supported=20 >>> part of IMAP: >>> >>> https://www.iana.org/assignments/imap-keywords/imap-keywords.xhtml#imap-= keywords-1=20 >>> >>> >>> There's no need for JMAP to define all these registered keywords; it=20 >>> only needs to reference the registry. >> Agreed. And at the Chicago face-to-face meeting I've raised the issue=20 >> of lack of generic access to IMAP keywords in JMAP. I believe there=20 >> was room agreement to fix it in a generic way. >> >>> >>> =3D Chris >>> >>> On 3 Apr 2017, at 2:13, Benoit Tellier wrote: >>> >>>> Hello, >>>> >>>> At Linagora, we tend to consider **forward** information as important >>>> for the email we care about. >>>> >>>> Today, it is not part of the RFC-3501 spec, and many IMAP >>>> implementations handle it with the de-facto standard $Forwarded flag. >>>> >>>> This implicit standard is a bad thing, and we truly would like the=20 >>>> JMAP >>>> mail protocol to do this right. To be right, it should be explicit. >>>> >>>> We then propose this pull request: >>>> >>>> It reproduces the behavior of **answered** feature: >>>> >>>> - Adds a **isForwarded** message property >>>> - Adds a mechanism for automatically marking messages as forwarded=20 >>>> upon >>>> sending emails >>>> - Clarifies interactions between isForwarded and threads >>>> - Makes isForwarded searchable >>>> >>>> Does this proposal make sense to you? >>>> >>>> Best regards, >>>> >>>> Benoit Tellier >>>> ----------------------------- >>>> Software engineer at Linagora >>>> PMC on Apache JAMES >>>> >>>> >>>> Le 01/04/2017 =C3=A0 06:23, Dave Crocker a =C3=A9crit : >>>>> G'day, >>>>> >>>>> The working group meeting discussion about a static message, dynamic >>>>> annotation, etc., resonated with a variety of similar discussions=20 >>>>> I've >>>>> been around over the years (dating back to the mid-1970.) >>>>> >>>>> A simpler version equates the constructs of message and document, as >>>>> two views of the same thing. (Ie, Document with attributes; Message >>>>> with a body.) >>>>> >>>>> The essence is to consider the nature and relationship of the=20 >>>>> objects, >>>>> possibly permitting different semantics for the same set of objects, >>>>> according to different applications or roles. >>>>> >>>>> That is, there can be a variety of constituent objects that are >>>>> associated and can be viewed according to different semantics (or >>>>> views)... So a message, a document, a calendar entry, a series of >>>>> comments, etc. Each object has associated processing rules (eg, >>>>> static vs. editable vs. executable; constrained choice of values; >>>>> organization into folders or other schemas...) >>>>> >>>>> An environment like this can be powerful and very appealing. The >>>>> challenge tends to be staying practical: With no effort at all it >>>>> devolves into an abstract computer science exercise. Some of that is >>>>> an efficiency issue(*) but I think it's mostly about the human >>>>> manageability for design and operations. >>>>> >>>>> Based on both the years of commercial use and the public commentary >>>>> about the performance, I've no doubt the fastmail system does not >>>>> suffer these downsides. But it's a potential that this re-casting >>>>> through the IETF could easily suffer. >>>>> >>>>> I'm posting this note partly because I think it would exciting to >>>>> produce specs that permit a degree of flexibility that such an >>>>> approach permits, but also wanted to cite the dangers. >>>>> >>>>> At the moment, I'm guessing there needs to be a small number of basic >>>>> object types and a small number of 'relationship' types that define >>>>> the association between objects. These could then be combined into >>>>> higher-order, formal organizations/semantics the define an=20 >>>>> application >>>>> semantic (mail, calendar, whatever.) >>>>> >>>>> >>>>> d/ >>>>> >>>>> (*) A system I did in 1977 has a little bit of this and the extremely >>>>> pure design produced impressively horrible performance. >>>>> >>>> >>>> _______________________________________________ >>>> Jmap mailing list >>>> Jmap@ietf.org >>>> https://www.ietf.org/mailman/listinfo/jmap >>> >>> _______________________________________________ >>> Jmap mailing list >>> Jmap@ietf.org >>> https://www.ietf.org/mailman/listinfo/jmap >> > --------------7CC7DBFF6E1F90CB0BD7B70A Content-Type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

Hi Benoit,

On 04/04/2017 11:08, Benoit Tellier wrote:

Hi,

Thanks for your answers. How do you plan to access such registered keyword, if it is not made somehow a message property?<= /span>


It has to be a message properly. For example "keywords" which contains an array of other IMAP keywords as strings. I have other applications that need to access to other keywords, some of which are listed on <https://www.iana.org/assignments/imap= -keywords/imap-keywords.xhtml>

As a JMAP user I would like this to be very easily accessible from the Message object, and also it to be searchable.


Agreed.

=

In the case of $Forwarded I think it needs to be consistent with the reply feature, for automatically marked as forwarded, and for threads.


I wouldn't mind having some extra logic for forwarded messages, if the group can agree on that.

Best Regards,
Alexey

Cheers,

Benoit Tellier<= /span>


Le 04/04/2017 =C3=A0 00:43, Alexey Melnikov a =C3=A9crit=C2=A0:
On 03/04/2017 18:10, Chris Newman wrote:

IMAP $Forwarded is a registered keyword and thus a fully supported part of IMAP:

https://www.iana.org/assignments/imap-keywords/imap-keywords= .xhtml#imap-keywords-1

There's no need for JMAP to define all these registered keywords; it only needs to reference the registry.
Agreed. And at the Chicago face-to-face meeting I've raised the issue of lack of generic access to IMAP keywords in JMAP. I believe there was room agreement to fix it in a generic way.


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D Chris

On 3 Apr 2017, at 2:13, Benoit Tellier wrote:

Hello,

At Linagora, we tend to consider **forward** information as important
for the email we care about.

Today, it is not part of the RFC-3501 spec, and many IMAP
implementations handle it with the de-facto standard $Forwarded flag.

This implicit standard is a bad thing, and we truly would like the JMAP
mail protocol to do this right. To be right, it should be explicit.

We then propose this pull request:

It reproduces the behavior of **answered** feature:

=C2=A0- Adds a **isForwarded** message property
=C2=A0- Adds a mechanism for automatically marking messages as forwarded upon
sending emails
=C2=A0- Clarifies interactions between isForwarded and threads <= br> =C2=A0- Makes isForwarded searchable

Does this proposal make sense to you?

Best regards,

Benoit Tellier
-----------------------------
Software engineer at Linagora
PMC on Apache JAMES


Le 01/04/2017 =C3=A0 06:23, Dave Crocker a =C3=A9crit :
G'day,

The working group meeting discussion about a static message, dynamic
annotation, etc., resonated with a variety of similar discussions I've
been around over the years (dating back to the mid-1970.)

A simpler version equates the constructs of message and document, as
two views of the same thing.=C2=A0 (Ie, Document with attributes; Message
with a body.)

The essence is to consider the nature and relationship of the objects,
possibly permitting different semantics for the same set of objects,
according to different applications or roles.

That is, there can be a variety of constituent objects that are
associated and can be viewed according to different semantics (or
views)...=C2=A0 So a message, a document, a calendar entry, a series of
comments, etc.=C2=A0 Each object has associated processing rules (eg,
static vs. editable vs. executable; constrained choice of values;
organization into folders or other schemas...)

An environment like this can=C2=A0 be powerful and very appealing. The
challenge tends to be staying practical:=C2=A0 With no effort at all it
devolves into an abstract computer science exercise.=C2=A0 Som= e of that is
an efficiency issue(*) but I think it's mostly about the human
manageability for design and operations.

Based on both the years of commercial use and the public commentary
about the performance, I've no doubt the fastmail system does not
suffer these downsides.=C2=A0 But it's a potential that this re-casting
through the IETF could easily suffer.

I'm posting this note partly because I think it would exciting to
produce specs that permit a degree of flexibility that such an
approach permits, but also wanted to cite the dangers.

At the moment, I'm guessing there needs to be a small number of basic
object types and a small number of 'relationship' types that define
the association between objects.=C2=A0 These could then be combined into
higher-order, formal organizations/semantics the define an application
semantic (mail, calendar, whatever.)


d/

(*) A system I did in 1977 has a little bit of this and the extremely
pure design produced impressively horrible performance.


_______________________________________________
Jmap mailing list
Jmap@ietf.org
https://ww= w.ietf.org/mailman/listinfo/jmap

_______________________________________________
Jmap mailing list
Jmap@ietf.org
https://www.= ietf.org/mailman/listinfo/jmap



--------------7CC7DBFF6E1F90CB0BD7B70A-- From nobody Tue Apr 4 07:33:00 2017 Return-Path: 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 D904112950C for ; Tue, 4 Apr 2017 07:32:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.106 X-Spam-Level: X-Spam-Status: No, score=-1.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RDNS_NONE=0.793, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 GLKvj5mhQvPH for ; Tue, 4 Apr 2017 07:32:55 -0700 (PDT) Received: from alderaan.linagora.com (unknown [109.197.180.137]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1E541296D2 for ; Tue, 4 Apr 2017 07:32:45 -0700 (PDT) Received: from [192.168.113.104] (unknown [183.80.6.77]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by alderaan.linagora.com (Postfix) with ESMTPSA id 4D20A7F7; Tue, 4 Apr 2017 16:32:39 +0200 (CEST) To: Alexey Melnikov , Chris Newman References: <148716911729.17277.15371202023742081890.idtracker@ietfa.amsl.com> <9eb1fd3c-8868-9d24-6c30-46d333b69fef@isode.com> <3c1711a2-46dd-db1c-506e-5e1ad89ce56d@linagora.com> <92769755-62c6-7257-ce3d-7d0b5699735d@isode.com> Cc: jmap@ietf.org From: Benoit Tellier Message-ID: <27c62cc8-68e0-49b5-4900-34c26d7b4c6a@linagora.com> Date: Tue, 4 Apr 2017 21:32:28 +0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <92769755-62c6-7257-ce3d-7d0b5699735d@isode.com> Content-Type: multipart/alternative; boundary="------------F2E9D56AEDC007D60D889516" Archived-At: Subject: Re: [Jmap] Adding the Message::isForwarded property X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 14:32:58 -0000 This is a multi-part message in MIME format. --------------F2E9D56AEDC007D60D889516 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Alexey, Thanks for your answer. Le 04/04/2017 à 21:00, Alexey Melnikov a écrit : > > Hi Benoit, > > On 04/04/2017 11:08, Benoit Tellier wrote: > >> |Hi, >> | >> >> |Thanks for your answers. How do you plan to access such registered >> keyword, if it is not made somehow a message property?| >> > | > It has to be a message properly. For example "keywords" which contains > an array of other IMAP keywords as strings. I have other applications > that need to access to other keywords, some of which are listed on > | |I agree that a **keyword** property is cool. However, I would go a bit further. Rather than creating a message property having a special meaning for the Forwarded feature, I would make it a top-level message property. That is why I proposed to add a **isForwarded** message property. | >> >> |As a JMAP user I would like this to be very easily accessible from >> the Message object, and also it to be searchable. >> | >> > | > Agreed. > > | >> >> || >> >> |In the case of $Forwarded I think it needs to be consistent with the >> reply feature, for automatically marked as forwarded, and for threads.| >> > | > I wouldn't mind having some extra logic for forwarded messages, if the > group can agree on that. > > Best Regards, > Alexey > > | >> >> |Cheers, >> | >> >> |Benoit Tellier| >> >> >> Le 04/04/2017 à 00:43, Alexey Melnikov a écrit : >>> On 03/04/2017 18:10, Chris Newman wrote: >>> >>>> IMAP $Forwarded is a registered keyword and thus a fully supported >>>> part of IMAP: >>>> >>>> https://www.iana.org/assignments/imap-keywords/imap-keywords.xhtml#imap-keywords-1 >>>> >>>> >>>> There's no need for JMAP to define all these registered keywords; >>>> it only needs to reference the registry. >>> Agreed. And at the Chicago face-to-face meeting I've raised the >>> issue of lack of generic access to IMAP keywords in JMAP. I believe >>> there was room agreement to fix it in a generic way. >>> >>>> >>>> = Chris >>>> >>>> On 3 Apr 2017, at 2:13, Benoit Tellier wrote: >>>> >>>>> Hello, >>>>> >>>>> At Linagora, we tend to consider **forward** information as important >>>>> for the email we care about. >>>>> >>>>> Today, it is not part of the RFC-3501 spec, and many IMAP >>>>> implementations handle it with the de-facto standard $Forwarded flag. >>>>> >>>>> This implicit standard is a bad thing, and we truly would like the >>>>> JMAP >>>>> mail protocol to do this right. To be right, it should be explicit. >>>>> >>>>> We then propose this pull request: >>>>> >>>>> It reproduces the behavior of **answered** feature: >>>>> >>>>> - Adds a **isForwarded** message property >>>>> - Adds a mechanism for automatically marking messages as >>>>> forwarded upon >>>>> sending emails >>>>> - Clarifies interactions between isForwarded and threads >>>>> - Makes isForwarded searchable >>>>> >>>>> Does this proposal make sense to you? >>>>> >>>>> Best regards, >>>>> >>>>> Benoit Tellier >>>>> ----------------------------- >>>>> Software engineer at Linagora >>>>> PMC on Apache JAMES >>>>> >>>>> >>>>> Le 01/04/2017 à 06:23, Dave Crocker a écrit : >>>>>> G'day, >>>>>> >>>>>> The working group meeting discussion about a static message, dynamic >>>>>> annotation, etc., resonated with a variety of similar discussions >>>>>> I've >>>>>> been around over the years (dating back to the mid-1970.) >>>>>> >>>>>> A simpler version equates the constructs of message and document, as >>>>>> two views of the same thing. (Ie, Document with attributes; Message >>>>>> with a body.) >>>>>> >>>>>> The essence is to consider the nature and relationship of the >>>>>> objects, >>>>>> possibly permitting different semantics for the same set of objects, >>>>>> according to different applications or roles. >>>>>> >>>>>> That is, there can be a variety of constituent objects that are >>>>>> associated and can be viewed according to different semantics (or >>>>>> views)... So a message, a document, a calendar entry, a series of >>>>>> comments, etc. Each object has associated processing rules (eg, >>>>>> static vs. editable vs. executable; constrained choice of values; >>>>>> organization into folders or other schemas...) >>>>>> >>>>>> An environment like this can be powerful and very appealing. The >>>>>> challenge tends to be staying practical: With no effort at all it >>>>>> devolves into an abstract computer science exercise. Some of >>>>>> that is >>>>>> an efficiency issue(*) but I think it's mostly about the human >>>>>> manageability for design and operations. >>>>>> >>>>>> Based on both the years of commercial use and the public commentary >>>>>> about the performance, I've no doubt the fastmail system does not >>>>>> suffer these downsides. But it's a potential that this re-casting >>>>>> through the IETF could easily suffer. >>>>>> >>>>>> I'm posting this note partly because I think it would exciting to >>>>>> produce specs that permit a degree of flexibility that such an >>>>>> approach permits, but also wanted to cite the dangers. >>>>>> >>>>>> At the moment, I'm guessing there needs to be a small number of >>>>>> basic >>>>>> object types and a small number of 'relationship' types that define >>>>>> the association between objects. These could then be combined into >>>>>> higher-order, formal organizations/semantics the define an >>>>>> application >>>>>> semantic (mail, calendar, whatever.) >>>>>> >>>>>> >>>>>> d/ >>>>>> >>>>>> (*) A system I did in 1977 has a little bit of this and the >>>>>> extremely >>>>>> pure design produced impressively horrible performance. >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Jmap mailing list >>>>> Jmap@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/jmap >>>> >>>> _______________________________________________ >>>> Jmap mailing list >>>> Jmap@ietf.org >>>> https://www.ietf.org/mailman/listinfo/jmap >>> >> > --------------F2E9D56AEDC007D60D889516 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Alexey,

Thanks for your answer.


Le 04/04/2017 à 21:00, Alexey Melnikov a écrit :

Hi Benoit,

On 04/04/2017 11:08, Benoit Tellier wrote:

Hi,

Thanks for your answers. How do you plan to access such registered keyword, if it is not made somehow a message property?


It has to be a message properly. For example "keywords" which contains an array of other IMAP keywords as strings. I have other applications that need to access to other keywords, some of which are listed on <https://www.iana.org/assignments/imap-keywords/imap-keywords.xhtml>
I agree that a **keyword** property is cool.

However, I would go a bit further. Rather than creating a message property having a special meaning for the Forwarded feature, I would make it a top-level message property. That is why I proposed to add a **isForwarded** message property.

As a JMAP user I would like this to be very easily accessible from the Message object, and also it to be searchable.


Agreed.

In the case of $Forwarded I think it needs to be consistent with the reply feature, for automatically marked as forwarded, and for threads.


I wouldn't mind having some extra logic for forwarded messages, if the group can agree on that.

Best Regards,
Alexey

Cheers,

Benoit Tellier


Le 04/04/2017 à 00:43, Alexey Melnikov a écrit :
On 03/04/2017 18:10, Chris Newman wrote:

IMAP $Forwarded is a registered keyword and thus a fully supported part of IMAP:

https://www.iana.org/assignments/imap-keywords/imap-keywords.xhtml#imap-keywords-1

There's no need for JMAP to define all these registered keywords; it only needs to reference the registry.
Agreed. And at the Chicago face-to-face meeting I've raised the issue of lack of generic access to IMAP keywords in JMAP. I believe there was room agreement to fix it in a generic way.


        = Chris

On 3 Apr 2017, at 2:13, Benoit Tellier wrote:

Hello,

At Linagora, we tend to consider **forward** information as important
for the email we care about.

Today, it is not part of the RFC-3501 spec, and many IMAP
implementations handle it with the de-facto standard $Forwarded flag.

This implicit standard is a bad thing, and we truly would like the JMAP
mail protocol to do this right. To be right, it should be explicit.

We then propose this pull request:

It reproduces the behavior of **answered** feature:

 - Adds a **isForwarded** message property
 - Adds a mechanism for automatically marking messages as forwarded upon
sending emails
 - Clarifies interactions between isForwarded and threads
 - Makes isForwarded searchable

Does this proposal make sense to you?

Best regards,

Benoit Tellier
-----------------------------
Software engineer at Linagora
PMC on Apache JAMES


Le 01/04/2017 à 06:23, Dave Crocker a écrit :
G'day,

The working group meeting discussion about a static message, dynamic
annotation, etc., resonated with a variety of similar discussions I've
been around over the years (dating back to the mid-1970.)

A simpler version equates the constructs of message and document, as
two views of the same thing.  (Ie, Document with attributes; Message
with a body.)

The essence is to consider the nature and relationship of the objects,
possibly permitting different semantics for the same set of objects,
according to different applications or roles.

That is, there can be a variety of constituent objects that are
associated and can be viewed according to different semantics (or
views)...  So a message, a document, a calendar entry, a series of
comments, etc.  Each object has associated processing rules (eg,
static vs. editable vs. executable; constrained choice of values;
organization into folders or other schemas...)

An environment like this can  be powerful and very appealing. The
challenge tends to be staying practical:  With no effort at all it
devolves into an abstract computer science exercise.  Some of that is
an efficiency issue(*) but I think it's mostly about the human
manageability for design and operations.

Based on both the years of commercial use and the public commentary
about the performance, I've no doubt the fastmail system does not
suffer these downsides.  But it's a potential that this re-casting
through the IETF could easily suffer.

I'm posting this note partly because I think it would exciting to
produce specs that permit a degree of flexibility that such an
approach permits, but also wanted to cite the dangers.

At the moment, I'm guessing there needs to be a small number of basic
object types and a small number of 'relationship' types that define
the association between objects.  These could then be combined into
higher-order, formal organizations/semantics the define an application
semantic (mail, calendar, whatever.)


d/

(*) A system I did in 1977 has a little bit of this and the extremely
pure design produced impressively horrible performance.


_______________________________________________
Jmap mailing list
Jmap@ietf.org
https://www.ietf.org/mailman/listinfo/jmap

_______________________________________________
Jmap mailing list
Jmap@ietf.org
https://www.ietf.org/mailman/listinfo/jmap




--------------F2E9D56AEDC007D60D889516-- From nobody Tue Apr 4 12:25:26 2017 Return-Path: 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 98AFE1205D3 for ; Tue, 4 Apr 2017 12:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.997 X-Spam-Level: X-Spam-Status: No, score=-6.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.796, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 9CKnZs83H2kx for ; Tue, 4 Apr 2017 12:25:22 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18B4112932A for ; Tue, 4 Apr 2017 12:25:21 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v34JPHYv009588 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 4 Apr 2017 19:25:18 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v34JPHDm020997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 4 Apr 2017 19:25:17 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v34JPGgs025404; Tue, 4 Apr 2017 19:25:16 GMT Received: from [10.145.239.160] (/10.145.239.160) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 04 Apr 2017 12:25:16 -0700 From: "Chris Newman" To: "Alexey Melnikov" Cc: "Benoit Tellier" , jmap@ietf.org Date: Tue, 04 Apr 2017 12:25:14 -0700 Message-ID: <59771DE7-35FB-49E3-BFC9-9EBD1268E88A@oracle.com> In-Reply-To: <92769755-62c6-7257-ce3d-7d0b5699735d@isode.com> References: <148716911729.17277.15371202023742081890.idtracker@ietfa.amsl.com> <9eb1fd3c-8868-9d24-6c30-46d333b69fef@isode.com> <3c1711a2-46dd-db1c-506e-5e1ad89ce56d@linagora.com> <92769755-62c6-7257-ce3d-7d0b5699735d@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: MailMate (1.9.6r5347) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Subject: Re: [Jmap] Adding the Message::isForwarded property X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 19:25:24 -0000 On 4 Apr 2017, at 7:00, Alexey Melnikov wrote: > Hi Benoit, > > On 04/04/2017 11:08, Benoit Tellier wrote: > >> |Hi, >> | >> >> |Thanks for your answers. How do you plan to access such registered = >> keyword, if it is not made somehow a message property?| >> > | > It has to be a message properly. For example "keywords" which contains = > an array of other IMAP keywords as strings. I have other applications = > that need to access to other keywords, some of which are listed on = > | As a general principle, I'm opposed to gratuitous changes between IMAP = and JMAP (or Submit and JMAP). So a message has to have flags/keywords = as a property and $Forwarded is a keyword no different from other = keywords in how it is accessed. >> |As a JMAP user I would like this to be very easily accessible from = >> the Message object, and also it to be searchable. >> | >> > Agreed. +1. IMAP flags/keywords are easy to access and searchable via IMAP. Same = should be true via JMAP. >> |In the case of $Forwarded I think it needs to be consistent with the = >> reply feature, for automatically marked as forwarded, and for = >> threads.| >> > | > I wouldn't mind having some extra logic for forwarded messages, if the = > group can agree on that. I'm supportive of including flag setting logic for $Forwarded, $MDNSent = and \Answered in JMAP to the extent JMAP provides forward, MDN and reply = functionality. Our JMAP-equivalent IMAP/Submit proxy has flag setting = logic for $MDNSent and \Answered. The omission of support for $Forwarded = is likely because it was defined later than the other two. - Chris > Best Regards, > Alexey > > | >> >> |Cheers, >> | >> >> |Benoit Tellier| >> >> >> Le 04/04/2017 =C3=A0 00:43, Alexey Melnikov a =C3=A9crit : >>> On 03/04/2017 18:10, Chris Newman wrote: >>> >>>> IMAP $Forwarded is a registered keyword and thus a fully supported = >>>> part of IMAP: >>>> >>>> https://www.iana.org/assignments/imap-keywords/imap-keywords.xhtml#i= map-keywords-1 >>>> >>>> There's no need for JMAP to define all these registered keywords; = >>>> it only needs to reference the registry. >>> Agreed. And at the Chicago face-to-face meeting I've raised the = >>> issue of lack of generic access to IMAP keywords in JMAP. I believe = >>> there was room agreement to fix it in a generic way. >>> >>>> >>>> =3D Chris >>>> >>>> On 3 Apr 2017, at 2:13, Benoit Tellier wrote: >>>> >>>>> Hello, >>>>> >>>>> At Linagora, we tend to consider **forward** information as = >>>>> important >>>>> for the email we care about. >>>>> >>>>> Today, it is not part of the RFC-3501 spec, and many IMAP >>>>> implementations handle it with the de-facto standard $Forwarded = >>>>> flag. >>>>> >>>>> This implicit standard is a bad thing, and we truly would like the = >>>>> JMAP >>>>> mail protocol to do this right. To be right, it should be = >>>>> explicit. >>>>> >>>>> We then propose this pull request: >>>>> >>>>> It reproduces the behavior of **answered** feature: >>>>> >>>>> - Adds a **isForwarded** message property >>>>> - Adds a mechanism for automatically marking messages as = >>>>> forwarded upon >>>>> sending emails >>>>> - Clarifies interactions between isForwarded and threads >>>>> - Makes isForwarded searchable >>>>> >>>>> Does this proposal make sense to you? >>>>> >>>>> Best regards, >>>>> >>>>> Benoit Tellier >>>>> ----------------------------- >>>>> Software engineer at Linagora >>>>> PMC on Apache JAMES >>>>> >>>>> >>>>> Le 01/04/2017 =C3=A0 06:23, Dave Crocker a =C3=A9crit : >>>>>> G'day, >>>>>> >>>>>> The working group meeting discussion about a static message, = >>>>>> dynamic >>>>>> annotation, etc., resonated with a variety of similar discussions = >>>>>> I've >>>>>> been around over the years (dating back to the mid-1970.) >>>>>> >>>>>> A simpler version equates the constructs of message and document, = >>>>>> as >>>>>> two views of the same thing. (Ie, Document with attributes; = >>>>>> Message >>>>>> with a body.) >>>>>> >>>>>> The essence is to consider the nature and relationship of the = >>>>>> objects, >>>>>> possibly permitting different semantics for the same set of = >>>>>> objects, >>>>>> according to different applications or roles. >>>>>> >>>>>> That is, there can be a variety of constituent objects that are >>>>>> associated and can be viewed according to different semantics (or >>>>>> views)... So a message, a document, a calendar entry, a series = >>>>>> of >>>>>> comments, etc. Each object has associated processing rules (eg, >>>>>> static vs. editable vs. executable; constrained choice of values; >>>>>> organization into folders or other schemas...) >>>>>> >>>>>> An environment like this can be powerful and very appealing. The >>>>>> challenge tends to be staying practical: With no effort at all = >>>>>> it >>>>>> devolves into an abstract computer science exercise. Some of = >>>>>> that is >>>>>> an efficiency issue(*) but I think it's mostly about the human >>>>>> manageability for design and operations. >>>>>> >>>>>> Based on both the years of commercial use and the public = >>>>>> commentary >>>>>> about the performance, I've no doubt the fastmail system does not >>>>>> suffer these downsides. But it's a potential that this = >>>>>> re-casting >>>>>> through the IETF could easily suffer. >>>>>> >>>>>> I'm posting this note partly because I think it would exciting to >>>>>> produce specs that permit a degree of flexibility that such an >>>>>> approach permits, but also wanted to cite the dangers. >>>>>> >>>>>> At the moment, I'm guessing there needs to be a small number of = >>>>>> basic >>>>>> object types and a small number of 'relationship' types that = >>>>>> define >>>>>> the association between objects. These could then be combined = >>>>>> into >>>>>> higher-order, formal organizations/semantics the define an = >>>>>> application >>>>>> semantic (mail, calendar, whatever.) >>>>>> >>>>>> >>>>>> d/ >>>>>> >>>>>> (*) A system I did in 1977 has a little bit of this and the = >>>>>> extremely >>>>>> pure design produced impressively horrible performance. >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Jmap mailing list >>>>> Jmap@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/jmap >>>> >>>> _______________________________________________ >>>> Jmap mailing list >>>> Jmap@ietf.org >>>> https://www.ietf.org/mailman/listinfo/jmap >>> >> > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap From nobody Tue Apr 4 22:36:53 2017 Return-Path: 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 80664129412 for ; Tue, 4 Apr 2017 22:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=jfmNWZY+; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=awCJ0zM7 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 Zq2T4heszmqt for ; Tue, 4 Apr 2017 22:36:46 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43F6C12940C for ; Tue, 4 Apr 2017 22:36:46 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id B17DE2094E for ; Wed, 5 Apr 2017 01:36:45 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Wed, 05 Apr 2017 01:36:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=5WyZAYdcX8YrGVjp1Dwwgh7z/Ehtu ReBKgfgVj2pWek=; b=jfmNWZY+lKUxH0lVMpDRg0MCiqYfSOsdJ1JABcUv8sLsZ jO22+yaLDqmQz8+EM22Bn8ci+NFXws+F2S4GSWh6Gs6d5ICJsqRc+gMDH2glwR0w RiTCMEvMJ18h314C9ePbqIUBhhQa7//2I3lqpVwhxX/K2Xk/g2c8zqKG5OzI1XMo 5+n5E2YLLDcFIZh6w24N/pL4bbUAYWDK4bjocmPgTCJhgTcyG8wF10Qcezefvluf JDqsVffqSuh9DIcIH8ifa6V/6E5whP8u86wMRFoO6wtFhArz3gTCFSs4yvxd9ANR OTyOxQNFkNcAQj+3drjmyo+9KUrQA/soJccsrnJmw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=5WyZAY dcX8YrGVjp1Dwwgh7z/EhtuReBKgfgVj2pWek=; b=awCJ0zM7aplZDx01q9YONP QJiR+JfFZiGrlmba4gFlbzKj9BI6CeLJwyivo62f3g8IudeOBX8HoraPaTJuB4OC Yn26ebGwZohSIsTUDRennsDqf6XjLdBOT4DBHXPo3w+35R9Q4YGQEB/8rtpVFuZq /CbFn0SvAjZqnVFJkthzx0IZcCtVhBJlmL/uihgcqa5dc2S2I/aek1cI78JEA81K tUiMzPhMBm1rK7CQb/xdAvj1QLzrI/AnRE3QCNhl46/5Xe/BRA/fZydV3sBKvm/r E7o0iqldsZPAt9ubAXlXw7kzIwmY2Bmr8BIFmyer76Uv4mJy+V+mlCzZPb/WTeTQ == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 64F26E2561; Wed, 5 Apr 2017 01:36:45 -0400 (EDT) Message-Id: <1491370605.1381724.934621536.30B3055A@webmail.messagingengine.com> From: Neil Jenkins To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_149137060513817241" X-Mailer: MessagingEngine.com Webmail Interface - ajax-c4fccc2b Date: Wed, 05 Apr 2017 00:36:45 -0500 In-Reply-To: <59771DE7-35FB-49E3-BFC9-9EBD1268E88A@oracle.com> References: <148716911729.17277.15371202023742081890.idtracker@ietfa.amsl.com> <9eb1fd3c-8868-9d24-6c30-46d333b69fef@isode.com> <3c1711a2-46dd-db1c-506e-5e1ad89ce56d@linagora.com> <92769755-62c6-7257-ce3d-7d0b5699735d@isode.com> <59771DE7-35FB-49E3-BFC9-9EBD1268E88A@oracle.com> Archived-At: Subject: Re: [Jmap] Adding the Message::isForwarded property X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 05:36:48 -0000 This is a multi-part message in MIME format. --_----------=_149137060513817241 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" The existing *isFoo* properties on the Message object correspond to IMAP system flags, so I think they are OK to be special, but since we know we need generic access to IMAP user flags I agree we should just do that and use the IANA registry rather than adding a special *isForwarded* flag. My suggestion would be to add a *keywords* property to the Message object, which corresponds to the list of IMAP user flags. There is a question of what type this should be. An array is one option, but this has two downsides: 1. The server must sort it to ensure a consistent representation is returned (probably just by ASCII code point, and for compatibility with IMAP the flags *will* have to be ASCII). This then leads to the question of whether the server accepts an unsorted array from the client when updating it (probably yes, but then it's returning something that's semantically different at the JSON layer to what was set, to represent something semantically the same at the application layer). 2. It's much harder to define patch semantics for an array. In CalConnect[1], we've been working on a new JSON representation for event data, and there are often many "complex" properties on the event (e.g. set of alarms). Over time we've moved to having everything as a map with an id as the key, rather than an array, so that we can more easily patch event objects. So I would advocate for making the *keywords* property type Object, with the keywords as the keys, each mapping to a Boolean true as the value. This avoids the above two issues, although at the expense of having an irrelevant "value" in the map for each keyword. To enable searching I would add the following properties to the MessageList FilterCondition: * hasKeyword: `String|null` * notKeyword: `String|null` With regards to the special server behaviour for the $Forwarded keyword, I think we can define this without adding a *forwardingMessageId* property. We can just define that the server should look for the X-Forwarded-Message- Id header on the message, and then search for message(s) with this RFC5322 message id, and add the $Forwarded keyword to any it finds. The current *inReplyToMessageId* property on the Message object is actually problematic, because it's meant to be the JMAP message id, which can change if the original message is delivered and/or deleted after the reply is fetched, but the property is *meant* to be immutable. I think we can actually just drop the *inReplyToMessageId* property altogether. Instead, clients can simply set the In-Reply-To and References headers directly, and the server can use the In-Reply-To header to search for the message(s) to set as replied, just like with $Forwarded. Neil. Links: 1. https://www.calconnect.org/ --_----------=_149137060513817241 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
The existing isFoo properties on the Message object corre= spond to IMAP system flags, so I think they are OK to be special, but since= we know we need generic access to IMAP user flags I agree we should just d= o that and use the IANA registry rather than adding a special isForwarde= d flag.

My suggestion would be to add a keywords property to the M= essage object, which corresponds to the list of IMAP user flags. There is a= question of what type this should be. An array is one option, but this has= two downsides:
  1. The server must sort it to ensure a consistent representation is r= eturned (probably just by ASCII code point, and for compatibility with IMAP= the flags will have to be ASCII). This then leads to the question o= f whether the server accepts an unsorted array from the client when updatin= g it (probably yes, but then it's returning something that's semantically d= ifferent at the JSON layer to what was set, to represent something semantic= ally the same at the application layer).
  2. It's much harder to de= fine patch semantics for an array. In CalConnect, we've been working on a new JSON representation for even= t data, and there are often many "complex" properties on the event (e.g. se= t of alarms). Over time we've moved to having everything as a map with an i= d as the key, rather than an array, so that we can more easily patch event = objects.
So I would advocate for making the keywords property type Object, with the keywords as the keys, eac= h mapping to a Boolean true as the value. This avoids = the above two issues, although at the expense of having an irrelevant "valu= e" in the map for each keyword.

To enable searching I would add the following properties to the Messag= eList FilterCondition:
  • hasKeyword: `String|null`
  • notKeyword: `String|null`
    =

With regards to the special server behaviour for the $Forward= ed keyword, I think we can define this without adding a forwardin= gMessageId property. We can just define that the server should look for= the X-Forwarded-Message-Id header on the message, and then= search for message(s) with this RFC5322 message id, and add the $= Forwarded keyword to any it finds.

The current inReplyToMessageId property on the Message object i= s actually problematic, because it's meant to be the JMAP message id, which= can change if the original message is delivered and/or deleted after the r= eply is fetched, but the property is meant to be immutable.
=

I think we can actually just drop the inReplyToMessageId p= roperty altogether. Instead, clients can simply set the In-Reply-T= o and References headers directly, and the server ca= n use the In-Reply-To header to search for the message(s) t= o set as replied, just like with $Forwarded.

Neil.
--_----------=_149137060513817241-- From nobody Tue Apr 4 22:43:38 2017 Return-Path: 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 A4288126C26 for ; Tue, 4 Apr 2017 22:43:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=jFVfDgBy; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=VMran4w4 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 hiKPo7zyyRqT for ; Tue, 4 Apr 2017 22:43:36 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD008126C22 for ; Tue, 4 Apr 2017 22:43:34 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id 323F420BAA for ; Wed, 5 Apr 2017 01:43:34 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Wed, 05 Apr 2017 01:43:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=8abaL88VQ7sXqhKq3bPDoSizQqe8V d5FxU+gNVBrpoI=; b=jFVfDgByJ6mEV5YVAxWsnBkq0dl7C3vtQhpolDb+fm5ex Wowk/soXnwiUfj9m4KUTz3r0hRtNMJKw1PqFLvkBJCadrYlKBx9Of9//FXaJUDpx SJhgB2g7QgKqjE0OOyWbWIoRPiJ9D51kH+vDD4VBQFO6tAQGiAkhdwaGevB4FE2Z Grzmnu/uDTXkXLebGUqDn7C3EgwelNgjkNJzhJTOEKmXBAYkjNH27K8T2Hh5Jaca Extvot8pW2nC1rQWA3i9pfH6eCdS6+h3nOpZQZm14DXADAZYRVqLWmoqlWfj596o YclnblQeHC5rqfuNMyxPqVrnWt58IlSp+VDVVBZ2Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=8abaL8 8VQ7sXqhKq3bPDoSizQqe8Vd5FxU+gNVBrpoI=; b=VMran4w4LqeydsO/GmhvwR 6+sbWO9HQomYyJfKj6+YmWOb6hh7PbXK7HWOYJ0ykxdkUyTIJ+SzSF+zsU/UqMjx 1+1gfS7jfXd918UU8oLyrASdtHRq4UmT2zQhna4M0H9tF5Fa95uxx9WtjArVGHbd P60mgcUXKYhfW6B60EW+ot61t+CAdLFGEI56YWn575l4gmZyQW8N8eNUrTPSrmY0 jLdjSBxtlVikAvdjTOTPbPdsunX8n9G4zF+36TdHH7vtW2clRcmHRx6YLAqZCOtN P7+i9jSbtp/Arqns79Mt0XlgrguAX28QzeFC6g4xLFmWfLqG5T9ea9bg2gBaC0Ew == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id F2472E2561; Wed, 5 Apr 2017 01:43:33 -0400 (EDT) Message-Id: <1491371013.1386002.934634464.79C9C1F7@webmail.messagingengine.com> From: Neil Jenkins To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_149137101313860020" X-Mailer: MessagingEngine.com Webmail Interface - ajax-c4fccc2b References: <148716911729.17277.15371202023742081890.idtracker@ietfa.amsl.com> In-Reply-To: Date: Wed, 05 Apr 2017 00:43:33 -0500 Archived-At: Subject: Re: [Jmap] message vs. annotation X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 05:43:37 -0000 This is a multi-part message in MIME format. --_----------=_149137101313860020 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Fri, 31 Mar 2017, at 06:23 PM, Dave Crocker wrote: > An environment like this can be powerful and very appealing. The > challenge tends to be staying practical: With no effort at all it > devolves into an abstract computer science exercise. This is the key here. While mailboxes, keywords and annotations could be viewed as conceptually the same thing and so combined into one perfectly abstract construct, I strongly believe that to do so would be a mistake. It would make it harder for client authors to understand and use, harder to implement efficiently on the server, and harder to map backwards compatibility to IMAP. Neil. --_----------=_149137101313860020 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Fri, 31 Mar 2017, at 06:23 PM, Dave Crocker wrote:
An environment like this can  be powerful and very appealing.  The
challenge tends to be staying practical:  With no effort at all it
devolves into an abstract computer science exercise.

This is the key here. While mailboxes, keywords and annotations could be viewed as conceptually the same thing and so combined into one perfectly abstract construct, I strongly believe that to do so would be a mistake. It would make it harder for client authors to understand and use, harder to implement efficiently on the server, and harder to map backwards compatibility to IMAP.

Neil.
--_----------=_149137101313860020-- From nobody Wed Apr 5 05:21:43 2017 Return-Path: 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 C28C21273B1 for ; Wed, 5 Apr 2017 05:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 KScS_xKhxZxB for ; Wed, 5 Apr 2017 05:21:36 -0700 (PDT) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 111E4127863 for ; Wed, 5 Apr 2017 05:21:31 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id 81so7284480pgh.2 for ; Wed, 05 Apr 2017 05:21:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=2jADYLL5Xhwdw9k1iv71FsR9uNCTAHctLutC/HDowE8=; b=WaAeXzMDJPEs0zevZr7y3P0f0OsYxZ+tMOJIhCa6O43vtvKNj/G2x6YcOIn5gG4jtv TwywrljSgw8X5j3YrdCuNPmHJP19kp/FvXA8cIsQv2+n4PXd5xU8yPl1COHlGaydEgII /BKYX3HbFZS7BhYogNmIfcq0Cs847ZURHHkPwxR2u4iyOhVl32eJO1g3IJchG5KH55Yq u7zX5H8TvA9dMsfR9S/jkQ5ut4Zv9j1UKylAYwi7engzi7683l4KM792qkS0xMtmyXUI wNrvxNDYO6zVkeu7KiQrvdZ5IrnnrxxFUZEFxYF1MWU6GW3+k1g9GoStjevaZd7P4IB4 POQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=2jADYLL5Xhwdw9k1iv71FsR9uNCTAHctLutC/HDowE8=; b=sZMFX2LJCGcBTuBYT8ZdyOxHNVtvxT0fvs3qcOW//nEeAZzz6njfSJusLROGIri9Y7 RZYhPC5yV0M34m0D2ggq4mqmEQ/kmcbjGGJnH7q5k9oxvh+oNLzAWbUeB5zFNuTLh805 0qlM/eKwPLcV81Fdve7OFxYTNwi7al0evTBavB6Ad3fM8jIOzWyHr95kaEj5PLbP+d14 jBnGuWS5o5TawvCFxDnoLmpwaSMiYAmjscK0LuFzsG7x88RpE273INR7CX2OKBLK0n5Q 7oqeyYSO6G55igWj6wXdrIbebXnCV9t6KoU8GP1WsQe8rZZMcMDwnCKE8+tFT8U+IpBV ndhA== X-Gm-Message-State: AFeK/H2tG8GjvMAdKaTcLhWByBNa6V/HowEcRxer/pubo/DB7RISNBI6aahjDkfBYedyOQ== X-Received: by 10.99.113.18 with SMTP id m18mr30090026pgc.235.1491394890593; Wed, 05 Apr 2017 05:21:30 -0700 (PDT) Received: from [192.168.6.83] (ip-64-134-223-134.public.wayport.net. [64.134.223.134]) by smtp.gmail.com with ESMTPSA id s17sm37540701pgo.27.2017.04.05.05.21.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Apr 2017 05:21:29 -0700 (PDT) From: Ted Lemon Message-Id: <84395E74-9B7F-43A7-8EE0-62EFC5F9807D@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_8DDF6708-88D2-428A-BD42-7115D7B765A5" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 5 Apr 2017 05:21:27 -0700 In-Reply-To: <1491371013.1386002.934634464.79C9C1F7@webmail.messagingengine.com> Cc: jmap@ietf.org To: Neil Jenkins References: <148716911729.17277.15371202023742081890.idtracker@ietfa.amsl.com> <1491371013.1386002.934634464.79C9C1F7@webmail.messagingengine.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Jmap] message vs. annotation X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 12:21:40 -0000 --Apple-Mail=_8DDF6708-88D2-428A-BD42-7115D7B765A5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 4, 2017, at 10:43 PM, Neil Jenkins wrote: > This is the key here. While mailboxes, keywords and annotations could = be viewed as conceptually the same thing and so combined into one = perfectly abstract construct, I strongly believe that to do so would be = a mistake. It would make it harder for client authors to understand and = use, harder to implement efficiently on the server, and harder to map = backwards compatibility to IMAP. I think that the reason to have keywords as a special type of thing is = so that you can define standard keywords. Otherwise they don't seem = any different than labels/mailboxes. I think both types of object have = essentially the same desired set of semantics: "give me all the things = that match this label, quickly." "tell me what things with this label = have changed/appeared/disappeared." The reason I pushed back on annotations in the meeting is that I think = that annotations are actually likely to be more structured objects than = simply "things I need to get done by Friday." "Things I need to get = done by friday" is not a static object: it's a verb with modifiers. If = you treat it as if it's just an annotation, I think that you have an = overly limited solution to that problem. The reason I reacted to that = specific example at the microphone the way I did is that this sort of ad = hoc label that mail programs currently offer is actually a great example = of a missed opportunity: something that could really be a kick-ass = feature instead winds up being just another way for me to do = bookkeeping, and just another thing for me to remember. If a thing is a "thing I should get done by Friday," there should be = some code running that's helping me to arrange to actually get it done = by Friday, not just a notice for me to read on Saturday and feel guilty = about. And an annotation at least as described during the conversation in the = meeting last week would not be sufficient for this. Sure, you could = hang more stuff off it to make it work, or have something that cleverly = parses these annotations and does something smart with them, but it's = all way too sloppy and ad hoc to be useful. So while I agree that everything isn't the same object, and there may be = some value to having mailbox tags be different than annotation tags, I = think that an annotation really ought to be a first-class object that = can be linked to a message. The link probably has to be two-way: give = me all the messages with this annotation, and give me all the = annotations on this message. Of course, the response at the mic was that a message could have = multiple annotations, each one with its own name, and not all downloaded = to the client all the time. I don't disagree with this. And if = indeed each annotation has a name, maybe that's enough structure. But = it doesn't feel right to me. If there are two objects marked "get done = by Friday," I think the question "list objects marked get done by = Friday" is a really obvious one. --Apple-Mail=_8DDF6708-88D2-428A-BD42-7115D7B765A5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Apr 4, 2017, at 10:43 PM, Neil Jenkins <neilj@fastmail.com> = wrote:
This is the key here. While mailboxes, keywords and = annotations could be viewed as conceptually the same thing and so = combined into one perfectly abstract construct, I strongly believe that = to do so would be a mistake. It would make it harder for client authors = to understand and use, harder to implement efficiently on the server, = and harder to map backwards compatibility to = IMAP.

I think that the = reason to have keywords as a special type of thing is so that you can = define standard keywords.   Otherwise they don't seem any different = than labels/mailboxes.   I think both types of object have = essentially the same desired set of semantics: "give me all the things = that match this label, quickly."  "tell me what things with this = label have changed/appeared/disappeared."

The reason I pushed back on annotations in the = meeting is that I think that annotations are actually likely to be more = structured objects than simply "things I need to get done by Friday." =   "Things I need to get done by friday" is not a static object: = it's a verb with modifiers.   If you treat it as if it's just an = annotation, I think that you have an overly limited solution to that = problem.   The reason I reacted to that specific example at the = microphone the way I did is that this sort of ad hoc label that mail = programs currently offer is actually a great example of a missed = opportunity: something that could really be a kick-ass feature instead = winds up being just another way for me to do bookkeeping, and just = another thing for me to remember.

If = a thing is a "thing I should get done by Friday," there should be some = code running that's helping me to arrange to actually get it done by Friday, not just a = notice for me to read on Saturday and feel guilty about.

And an annotation at least as described during the = conversation in the meeting last week would not be sufficient for this. =   Sure, you could hang more stuff off it to make it work, or have = something that cleverly parses these annotations and does something = smart with them, but it's all way too sloppy and ad hoc to be = useful.

So while I agree that = everything isn't the same object, and there may be some value to having = mailbox tags be different than annotation tags, I think that an = annotation really ought to be a first-class object that can be linked to = a message.   The link probably has to be two-way: give me all the = messages with this annotation, and give me all the annotations on this = message.

Of course, the response at = the mic was that a message could have multiple annotations, each one = with its own name, and not all downloaded to the client all the time. =   I don't disagree with this.   And if indeed each annotation = has a name, maybe that's enough structure.   But it doesn't feel = right to me.   If there are two objects marked "get done by = Friday," I think the question "list objects marked get done by Friday" = is a really obvious one.

= --Apple-Mail=_8DDF6708-88D2-428A-BD42-7115D7B765A5-- From nobody Wed Apr 5 08:16:50 2017 Return-Path: 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 721E012949A for ; Wed, 5 Apr 2017 08:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 Cw3i-T_wULWu for ; Wed, 5 Apr 2017 08:16:47 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id E627E12945C for ; Wed, 5 Apr 2017 08:16:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1491405404; d=isode.com; s=june2016; i=@isode.com; bh=FurI2WiZegH7PGuHjyJJYAov6LIvJGIdx2cCd/f3m4c=; 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=J8wZGVrf1a2r12mubKf35Gq0Ebqv/rffL/gzDft0Hv8GPIw9TtPJediaxH2BbeWyWZpug5 713pfgzflA/k+FOLQeUSC9jPBUi3P5uzAY7BfftGmyyCZc3MuozMdLptqpkvuZR4b8vHuf /QyJqYGAF81jCGELB1piMUKmL48BHsM=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 5 Apr 2017 16:16:44 +0100 To: Neil Jenkins , jmap@ietf.org References: <148716911729.17277.15371202023742081890.idtracker@ietfa.amsl.com> <9eb1fd3c-8868-9d24-6c30-46d333b69fef@isode.com> <3c1711a2-46dd-db1c-506e-5e1ad89ce56d@linagora.com> <92769755-62c6-7257-ce3d-7d0b5699735d@isode.com> <59771DE7-35FB-49E3-BFC9-9EBD1268E88A@oracle.com> <1491370605.1381724.934621536.30B3055A@webmail.messagingengine.com> From: Alexey Melnikov Message-ID: <1d07de41-b115-ccdc-1f12-0eb339c4be0e@isode.com> Date: Wed, 5 Apr 2017 16:16:27 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 In-Reply-To: <1491370605.1381724.934621536.30B3055A@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------9C270B214CB2526CDC424F6F" Archived-At: Subject: Re: [Jmap] Adding the Message::isForwarded property X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 15:16:49 -0000 --------------9C270B214CB2526CDC424F6F Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Neil, On 05/04/2017 06:36, Neil Jenkins wrote: > The existing /isFoo/ properties on the Message object correspond to > IMAP system flags, so I think they are OK to be special, but since we > know we need generic access to IMAP user flags I agree we should just > do that and use the IANA registry rather than adding a special > /isForwarded/ flag. > > My suggestion would be to add a /keywords/ property to the Message > object, which corresponds to the list of IMAP user flags. There is a > question of what type this should be. An array is one option, but this > has two downsides: > > 1. The server must sort it to ensure a consistent representation is > returned (probably just by ASCII code point, and for compatibility > with IMAP the flags /will/ have to be ASCII). This then leads to > the question of whether the server accepts an unsorted array from > the client when updating it (probably yes, but then it's returning > something that's semantically different at the JSON layer to what > was set, to represent something semantically the same at the > application layer). > 2. It's much harder to define patch semantics for an array. In > CalConnect , we've been working on a > new JSON representation for event data, and there are often many > "complex" properties on the event (e.g. set of alarms). Over time > we've moved to having everything as a map with an id as the key, > rather than an array, so that we can more easily patch event objects. > Sorting seems sensible to me. > So I would advocate for making the /keywords/ property type Object, > with the keywords as the keys, each mapping to a Boolean true as the > value. This avoids the above two issues, although at the expense of > having an irrelevant "value" in the map for each keyword. That would be fine. > To enable searching I would add the following properties to the > MessageList FilterCondition: > > * hasKeyword: `String|null` > * notKeyword: `String|null` > Ok. > With regards to the special server behaviour for the $Forwarded > keyword, I think we can define this without adding a > /forwardingMessageId/ property. We can just define that the server > should look for the X-Forwarded-Message-Id header on the message, and > then search for message(s) with this RFC5322 message id, and add the > $Forwarded keyword to any it finds. Is X-Forwarded-Message-Id registered and which implementations are known to add it? > The current /inReplyToMessageId/ property on the Message object is > actually problematic, because it's meant to be the JMAP message id, > which can change if the original message is delivered and/or deleted > after the reply is fetched, but the property is /meant/ to be immutable. > > I think we can actually just drop the /inReplyToMessageId/ property > altogether. Instead, clients can simply set the In-Reply-To and > References headers directly, and the server can use the In-Reply-To > header to search for the message(s) to set as replied, just like with > $Forwarded. > > Neil. > > > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap --------------9C270B214CB2526CDC424F6F Content-Type: text/html; charset=windows-1252 Content-transfer-encoding: quoted-printable

Hi Neil,


On 05/04/2017 06:36, Neil Jenkins wrote:
The existing isFoo properties on the Message object correspond to IMAP system flags, so I think they are OK to be special, but since we know we need generic access to IMAP user flags I agree we should just do that and use the IANA registry rather than adding a special isForwarded flag.

My suggestion would be to add a keywords=A0property to the Message object, which corresponds to the list of IMAP user flags. There is a question of what type this should be. An array is one option, but this has two downsides:
  1. The server must sort it to ensure a consistent representation is returned (probably just by ASCII code point, and for compatibility with IMAP the flags will have to be ASCII). This then leads to the question of whether the server accepts an unsorted array from the client when updating it (probably yes, but then it's returning something that's semantically different at the JSON layer to what was set, to represent something semantically the same at the application layer).
  2. It's much harder to define patch semantics for an array. In C= alConnect, we've been working on a new JSON representation for event data, and there are often many "complex" properties on the event (e.g. set of alarms). Over time we've moved to having everything as a map with an id as the key, rather than an array, so that we can more easily patch event objects.

Sorting seems sensible to me.
So I would advocate for making the keywords property type Object, with the keywords as the keys, each mapping to a Boolean tru= e=A0as the value. This avoids the above two issues, although at the expense of having an irrelevant "value" in the map for each keyword.
That would be fine.

To enable searching I would add the following properties to the MessageList FilterCondition:
  • hasKeyword: `String|null`
  • notKeyword: `String|null`
Ok.

With regards to the special server behaviour for the $Forwarded keyword, I think we can define this without adding a forwardingMessageId property. We can just define that the server should look for the X-Forwarded-Message-Id header on the message, and then search for message(s) with this RFC5322 message id, and add the $Forwarded keyword to any it finds.
Is X-Forwarded-Message-Id registered and which implementations are known to add it?

The current inReplyToMessageId property on the Message object is actually problematic, because it's meant to be the JMAP message id, which can change if the original message is delivered and/or deleted after the reply is fetched, but the property is=A0meant to be immutable.

I think we can actually just drop the inReplyToMessageId= =A0property altogether. Instead, clients can simply set the In-Reply-To and Ref= erences headers directly, and the server can use the In-= Reply-To header to search for the message(s) to set as replied, just like with $Forwarded.

Neil.


_______________________________________________
Jmap mailing list
Jmap@iet=
f.org
https://www.ietf.org/mailman/listinfo/jmap

--------------9C270B214CB2526CDC424F6F-- From nobody Wed Apr 5 13:51:55 2017 Return-Path: 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 A86DD129490 for ; Wed, 5 Apr 2017 13:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 yVaXk0ij91co for ; Wed, 5 Apr 2017 13:51:50 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [122.56.26.1]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D93541270A0 for ; Wed, 5 Apr 2017 13:51:38 -0700 (PDT) Received: From [192.168.1.146] (unverified [192.168.1.146]) by SMTP Server [192.168.1.3] (WinGate SMTP Receiver v9.0.5 (Build 5926)) with SMTP id <0001009857@smtp.qbik.com>; Thu, 06 Apr 2017 08:51:35 +1200 From: "Adrien de Croy" To: "Neil Jenkins" , "jmap@ietf.org" Date: Wed, 05 Apr 2017 20:51:35 +0000 Message-Id: In-Reply-To: <1491370605.1381724.934621536.30B3055A@webmail.messagingengine.com> References: <148716911729.17277.15371202023742081890.idtracker@ietfa.amsl.com> <9eb1fd3c-8868-9d24-6c30-46d333b69fef@isode.com> <3c1711a2-46dd-db1c-506e-5e1ad89ce56d@linagora.com> <92769755-62c6-7257-ce3d-7d0b5699735d@isode.com> <59771DE7-35FB-49E3-BFC9-9EBD1268E88A@oracle.com> <1491370605.1381724.934621536.30B3055A@webmail.messagingengine.com> Reply-To: "Adrien de Croy" User-Agent: eM_Client/7.0.27943.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MBE1E99019-8CCC-4DC4-BBBE-51D5DCC18EFF" Archived-At: Subject: Re: [Jmap] Adding the Message::isForwarded property X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 20:51:54 -0000 --------=_MBE1E99019-8CCC-4DC4-BBBE-51D5DCC18EFF Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Is there no equivalent to set? E.g. a sorted container whose keys are=20 also the values? Saves the meaningless value issue. Adrien ------ Original Message ------ From: "Neil Jenkins" To: "jmap@ietf.org" Sent: 5/04/2017 5:36:45 PM Subject: Re: [Jmap] Adding the Message::isForwarded property >The existing isFoo properties on the Message object correspond to IMAP=20 >system flags, so I think they are OK to be special, but since we know=20 >we need generic access to IMAP user flags I agree we should just do=20 >that and use the IANA registry rather than adding a special isForwarded= =20 >flag. > >My suggestion would be to add a keywords property to the Message=20 >object, which corresponds to the list of IMAP user flags. There is a=20 >question of what type this should be. An array is one option, but this=20 >has two downsides: >The server must sort it to ensure a consistent representation is=20 >returned (probably just by ASCII code point, and for compatibility with= =20 >IMAP the flags will have to be ASCII). This then leads to the question=20 >of whether the server accepts an unsorted array from the client when=20 >updating it (probably yes, but then it's returning something that's=20 >semantically different at the JSON layer to what was set, to represent=20 >something semantically the same at the application layer). >It's much harder to define patch semantics for an array. In CalConnect=20 >, we've been working on a new JSON=20 >representation for event data, and there are often many "complex"=20 >properties on the event (e.g. set of alarms). Over time we've moved to=20 >having everything as a map with an id as the key, rather than an array,= =20 >so that we can more easily patch event objects. >So I would advocate for making the keywords property type Object, with=20 >the keywords as the keys, each mapping to a Boolean true as the value.=20 >This avoids the above two issues, although at the expense of having an=20 >irrelevant "value" in the map for each keyword. > >To enable searching I would add the following properties to the=20 >MessageList FilterCondition: >hasKeyword: `String|null` >notKeyword: `String|null` > >With regards to the special server behaviour for the $Forwarded=20 >keyword, I think we can define this without adding a=20 >forwardingMessageId property. We can just define that the server should= =20 >look for the X-Forwarded-Message-Id header on the message, and then=20 >search for message(s) with this RFC5322 message id, and add the=20 >$Forwarded keyword to any it finds. > >The current inReplyToMessageId property on the Message object is=20 >actually problematic, because it's meant to be the JMAP message id,=20 >which can change if the original message is delivered and/or deleted=20 >after the reply is fetched, but the property is meant to be immutable. > >I think we can actually just drop the inReplyToMessageId property=20 >altogether. Instead, clients can simply set the In-Reply-To and=20 >References headers directly, and the server can use the In-Reply-To=20 >header to search for the message(s) to set as replied, just like with=20 >$Forwarded. > >Neil. --------=_MBE1E99019-8CCC-4DC4-BBBE-51D5DCC18EFF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Is there no equivalent to set? =C2=A0E.g. a = sorted container whose keys are also the values?

Saves the meaningless value issue.

Adrien
=

------ Original Message ------
From: "Neil Jenkins" <neilj@f= astmail.com>
To: "jmap@ietf.org" <jmap@ietf.org= >
Sent: 5/04/2017 5:36:45 PM
Subject: Re: [Jmap] Adding the Message::isForwarded property

The existing isFoo properties on the Message object correspond= to IMAP system flags, so I think they are OK to be special, but since we= know we need generic access to IMAP user flags I agree we should just do= that and use the IANA registry rather than adding a special isForwarded= flag.

My suggestion would be to add a keywords=C2=A0property to the= Message object, which corresponds to the list of IMAP user flags. There= is a question of what type this should be. An array is one option, but = this has two downsides:
  1. The server must sort it to ensure a consistent representation is= returned (probably just by ASCII code point, and for compatibility with= IMAP the flags will have to be ASCII). This then leads to the quest= ion of whether the server accepts an unsorted array from the client when= updating it (probably yes, but then it's returning something that's semant= ically different at the JSON layer to what was set, to represent something= semantically the same at the application layer).
  2. It's much= harder to define patch semantics for an array. In CalConnect, we've been working on a new JSON representa= tion for event data, and there are often many "complex" properties on the= event (e.g. set of alarms). Over time we've moved to having everything = as a map with an id as the key, rather than an array, so that we can more= easily patch event objects.
So I would advocate for= making the keywords property type Object, with the= keywords as the keys, each mapping to a Boolean true=C2= =A0as the value. This avoids the above two issues, although at the expense= of having an irrelevant "value" in the map for each keyword.

To enable searching I would add the following properties to the Messag= eList FilterCondition:
  • hasKeyword: `String|null`
  • notKeyword: `String|null`

With regards to the special server behaviour for the $Forw= arded keyword, I think we can define this without adding a forwar= dingMessageId property. We can just define that the server should look= for the X-Forwarded-Message-Id header on the message, and= then search for message(s) with this RFC5322 message id, and add the $Forwarded keyword to any it finds.

The current inReplyToMessageId property on the Message object= is actually problematic, because it's meant to be the JMAP message id, = which can change if the original message is delivered and/or deleted after= the reply is fetched, but the property is=C2=A0meant to be immutabl= e.

I think we can actually just drop the inReplyToMessageId=C2=A0= property altogether. Instead, clients can simply set the In-Reply-= To and References headers directly, and the server= can use the In-Reply-To header to search for the messag= e(s) to set as replied, just like with $Forwarded.

Neil.
--------=_MBE1E99019-8CCC-4DC4-BBBE-51D5DCC18EFF-- From nobody Wed Apr 5 16:13:53 2017 Return-Path: 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 3D3E6126E01 for ; Wed, 5 Apr 2017 16:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=vcMRQZmq; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=OuxCqUvn 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 2h9RCuxq19dW for ; Wed, 5 Apr 2017 16:13:49 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1520F1293F9 for ; Wed, 5 Apr 2017 16:13:49 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id 8186420BB0; Wed, 5 Apr 2017 19:13:48 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Wed, 05 Apr 2017 19:13:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=oMdEigF9MjX4GrnAqWrdoL1f9yq7Q ZwMWiBjCZNcl7g=; b=vcMRQZmqrTH2kDkiLl/UKXB3w7Y6drIYhaWVBAOwl1sbe F96Y3fnIqHfGUFQVCon3/b/N/Rd1m+mbq4FH/N0xVtrd/KtxAQIPJBudgG36ghHi ynKhhUCMnv+3mssVcX/pv3MVnG+lmP/4WNqRNLiUBb61epfo6QzelLAeKguMtygO 07BeJD6ki3hh6MhCaL3rNEIMBlADbJG7AM10cp7FsnEHoAqpr2+pgqqMlM/wmJ6s yzb8Oy0UD08JcFW5+TZ3pfwtopqsiSBkS5jMp6/GOUQawtjzZRAkgbcD3jrgE9CR TAqgy7uq9T1qv6EF/5VGo33x3A+HwUuv1yYPOYOZw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=oMdEig F9MjX4GrnAqWrdoL1f9yq7QZwMWiBjCZNcl7g=; b=OuxCqUvn0kVzVlI4lkdvVT utl7w9MOl+EdPzYIxXjmlEeiktP58uQZHcLF5Kf+ShENWJIbXvF8GcMi3urHJWz+ Tt7yROahLYkfVxHO48WC4d2dax4+gDqrBA/uGZISpCPUeB7AKzIh87Qdmomt4ync MzvONPqaW9uT9OsNZvAAqosdtwsHiUOBK+uPTQXEc1viOHl/SLBALmqC3ZhpLFfF EPW3fePTGfathoqZrjp2u5m3jQN8BOrifIJkdIUVX2GNypuE+9BCrhOvNtcYvjsM YYBmitKdS1dYC0coDskQchlwfnD5O6cCNby2i2YwGib+7x2Ty95lUHNePRmlciog == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 3E955E2636; Wed, 5 Apr 2017 19:13:48 -0400 (EDT) Message-Id: <1491434028.2437286.935656552.3735299C@webmail.messagingengine.com> From: Neil Jenkins To: Alexey Melnikov , jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_149143402824372861" X-Mailer: MessagingEngine.com Webmail Interface - ajax-affd76ca In-Reply-To: <1d07de41-b115-ccdc-1f12-0eb339c4be0e@isode.com> Date: Wed, 05 Apr 2017 18:13:48 -0500 References: <148716911729.17277.15371202023742081890.idtracker@ietfa.amsl.com> <9eb1fd3c-8868-9d24-6c30-46d333b69fef@isode.com> <3c1711a2-46dd-db1c-506e-5e1ad89ce56d@linagora.com> <92769755-62c6-7257-ce3d-7d0b5699735d@isode.com> <59771DE7-35FB-49E3-BFC9-9EBD1268E88A@oracle.com> <1491370605.1381724.934621536.30B3055A@webmail.messagingengine.com> <1d07de41-b115-ccdc-1f12-0eb339c4be0e@isode.com> Archived-At: Subject: Re: [Jmap] Adding the Message::isForwarded property X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 23:13:51 -0000 This is a multi-part message in MIME format. --_----------=_149143402824372861 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Wed, 5 Apr 2017, at 10:16 AM, Alexey Melnikov wrote: > Is X-Forwarded-Message-Id registered and which implementations are > known to add it? Good question. I took this from Benoit's proposed changes, since we would need *some* header for the server to be able to automatically set the $Forwarded flag. Googling suggests this was introduced by Thunderbird[1] and I don't see any evidence that it is registered anywhere or implemented in other clients. Anyone have further information on this, or know of a more standardised alternative? The concept does seem useful to me. On Wed, 5 Apr 2017, at 03:51 PM, Adrien de Croy wrote: > Is there no equivalent to set? E.g. a sorted container whose keys are > also the values? No, JSON does not have a built-in "set" representation, hence the choice between array or object representation. Neil. Links: 1. https://bugzilla.mozilla.org/show_bug.cgi?id=583587 --_----------=_149143402824372861 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Wed, 5 Apr 2017, at 10:16 AM, Alexey Melnikov wrote:
Is X-Forwarded-Message-Id registered and which implementations are known to add it?

Good question. I took this from Benoit's proposed changes, since we would need some header for the server to be able to automatically set the $Forwarded flag. Googling suggests this was introduced by Thunderbird and I don't see any evidence that it is registered anywhere or implemented in other clients.

Anyone have further information on this, or know of a more standardised alternative? The concept does seem useful to me.

On Wed, 5 Apr 2017, at 03:51 PM, Adrien de Croy wrote:
Is there no equivalent to set?  E.g. a sorted container whose keys are also the values?

No, JSON does not have a built-in "set" representation, hence the choice between array or object representation.

Neil.
--_----------=_149143402824372861-- From nobody Fri Apr 7 02:56:58 2017 Return-Path: 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 A0B35128BB7 for ; Fri, 7 Apr 2017 02:56:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.106 X-Spam-Level: X-Spam-Status: No, score=-1.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RDNS_NONE=0.793, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 yWlaSnDSCwvd for ; Fri, 7 Apr 2017 02:56:53 -0700 (PDT) Received: from smtp.linagora.com (unknown [109.197.180.137]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 418E812783A for ; Fri, 7 Apr 2017 02:56:52 -0700 (PDT) Received: from [10.11.114.151] (unknown [1.55.245.97]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.linagora.com (Postfix) with ESMTPSA id CAFC82673 for ; Fri, 7 Apr 2017 11:56:49 +0200 (CEST) To: jmap@ietf.org References: <148716911729.17277.15371202023742081890.idtracker@ietfa.amsl.com> <9eb1fd3c-8868-9d24-6c30-46d333b69fef@isode.com> <3c1711a2-46dd-db1c-506e-5e1ad89ce56d@linagora.com> <92769755-62c6-7257-ce3d-7d0b5699735d@isode.com> <59771DE7-35FB-49E3-BFC9-9EBD1268E88A@oracle.com> <1491370605.1381724.934621536.30B3055A@webmail.messagingengine.com> <1d07de41-b115-ccdc-1f12-0eb339c4be0e@isode.com> <1491434028.2437286.935656552.3735299C@webmail.messagingengine.com> From: Benoit Tellier Message-ID: Date: Fri, 7 Apr 2017 16:56:44 +0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <1491434028.2437286.935656552.3735299C@webmail.messagingengine.com> Content-Type: multipart/alternative; boundary="------------BF6322B42A365001C16AB711" Archived-At: Subject: Re: [Jmap] Adding the Message::isForwarded property X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 09:56:56 -0000 This is a multi-part message in MIME format. --------------BF6322B42A365001C16AB711 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Neil, I took the X-Forwarded-Message-Id from Thunderbird. I did not find more generic way to convey this information in the headers of the mail. However I still found this header useful. Hence my proposal. Otherwise, I definitely agree with having keywords as part of JMAP spec. I believe we can add mentions about the different keywords defined by https://www.iana.org/assignments/imap-keywords/imap-keywords.xhtml as part of JMAP spec. Would you like me to update my proposal during the following week, to match the discussion status? I will include: - Keyword field on Messages (Map of keyword to true) - GetMessageList logic for keywords - The logic about marking messages as $Forwarded when sending them. I will also include changes about dropping */inReplyToMessageId*./ / - /The//changes that this implies on Threads (algorithm and order in display) Cheers, Benoit Le 06/04/2017 à 06:13, Neil Jenkins a écrit : > On Wed, 5 Apr 2017, at 10:16 AM, Alexey Melnikov wrote: > > Is X-Forwarded-Message-Id registered and which implementations are > known to add it? > > > Good question. I took this from Benoit's proposed changes, since we > would need /some/ header for the server to be able to automatically > set the $Forwarded flag. Googling suggests this was introduced by > Thunderbird and > I don't see any evidence that it is registered anywhere or implemented > in other clients. > > Anyone have further information on this, or know of a more > standardised alternative? The concept does seem useful to me. > > On Wed, 5 Apr 2017, at 03:51 PM, Adrien de Croy wrote: > > Is there no equivalent to set? E.g. a sorted container whose keys > are also the values? > > > No, JSON does not have a built-in "set" representation, hence the > choice between array or object representation. > > Neil. > > > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap --------------BF6322B42A365001C16AB711 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Hi Neil,

I took the X-Forwarded-Message-Id from Thunderbird. I did not find more generic way to convey this information in the headers of the mail. However I still found this header useful. Hence my proposal.


Otherwise, I definitely agree with having keywords as part of JMAP spec. I believe we can add mentions about the different keywords defined by https://www.iana.org/assignments/imap-keywords/imap-keywords.xhtml as part of JMAP spec.


Would you like me to update my proposal during the following week, to match the discussion status?


I will include:

 - Keyword field on Messages (Map of keyword to true)

 - GetMessageList logic for keywords

 - The logic about marking messages as $Forwarded when sending them. I will also include changes about dropping *inReplyToMessageId*.

  - The changes that this implies on Threads (algorithm and order in display)



Cheers,

Benoit

Le 06/04/2017 à 06:13, Neil Jenkins a écrit :
On Wed, 5 Apr 2017, at 10:16 AM, Alexey Melnikov wrote:
Is X-Forwarded-Message-Id registered and which implementations are known to add it?

Good question. I took this from Benoit's proposed changes, since we would need some header for the server to be able to automatically set the $Forwarded flag. Googling suggests this was introduced by Thunderbird and I don't see any evidence that it is registered anywhere or implemented in other clients.

Anyone have further information on this, or know of a more standardised alternative? The concept does seem useful to me.

On Wed, 5 Apr 2017, at 03:51 PM, Adrien de Croy wrote:
Is there no equivalent to set?  E.g. a sorted container whose keys are also the values?

No, JSON does not have a built-in "set" representation, hence the choice between array or object representation.

Neil.


_______________________________________________
Jmap mailing list
Jmap@ietf.org
https://www.ietf.org/mailman/listinfo/jmap

--------------BF6322B42A365001C16AB711-- From nobody Sun Apr 9 17:09:06 2017 Return-Path: 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 B79A312751F for ; Sun, 9 Apr 2017 17:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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, RCVD_IN_DNSWL_MED=-2.3, 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 (2048-bit key) header.d=apple.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 X_M4XuSy_q4W for ; Sun, 9 Apr 2017 17:09:03 -0700 (PDT) Received: from mail-in6.apple.com (mail-out6.apple.com [17.151.62.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A516127866 for ; Sun, 9 Apr 2017 17:09:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1491782940; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=EyW2sl08/upzqS/CvvsvWZAyBkS5Hrl31nFkBv83l+I=; b=rymFx9J3CfJbzjPpwCQTmZN+4TVB7wbziPLB4qhOH1y3ocdGcj3ZIGJTbHnjwD0H AJ4uglEcm2B+7zWtRSo6D2wD+y0swkyX1hn34kJFYlrLKcrwkKYdVliWqp0IvgsZ hUwiGujiR3e+jWEKdsNJPiRvK95qGHMwsPCO+voVlCDWjXNh/bSBMIlrxBboNzDC BKKQfG+Jz//AZu/6hVuU8w4B8MxgCoxhN76gN+QQzi4cYNb0ymnr8ryIrDp9NqUl X3qNG3JzFSpBWP0A4hajxooY6qJJMMLa+GFasZ2aJhvTJ/FJOjOSxQzxY+x00T+O 7L1wv5302me03TJBGB8/zA==; Received: from relay8.apple.com (relay8.apple.com [17.128.113.102]) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id FB.D9.29635.C1DCAE85; Sun, 9 Apr 2017 17:09:00 -0700 (PDT) X-AuditID: 11973e15-3419d9a0000073c3-7e-58eacd1c727b Received: from mailex13.apple.com (nwk-mbx16p-w02.pex.exch.apple.com [17.146.17.21]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by relay8.apple.com (Apple SCV relay) with SMTP id 53.AA.07296.C1DCAE85; Sun, 9 Apr 2017 17:09:00 -0700 (PDT) Received: from nwk-mbx16p-w01.pex.exch.apple.com (17.146.17.20) by nwk-mbx16p-w02.pex.exch.apple.com (17.146.17.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32; Sun, 9 Apr 2017 17:08:59 -0700 Received: from nwk-mbx16p-w01.pex.exch.apple.com ([17.146.17.20]) by nwk-mbx16p-w01.pex.exch.apple.com ([17.146.17.20]) with mapi id 15.01.0669.032; Sun, 9 Apr 2017 17:08:59 -0700 From: Neil Jhaveri To: Benoit Tellier CC: Alexey Melnikov , Chris Newman , "jmap@ietf.org" Thread-Topic: [Jmap] Adding the Message::isForwarded property Thread-Index: AQHSrFqZUamWuQglA0y5SBdM0Bf22qG0Vv2AgAAJKoCAARNPgIAAQM4AgAAI8QCACHy7AA== Date: Mon, 10 Apr 2017 00:08:59 +0000 Message-ID: References: <148716911729.17277.15371202023742081890.idtracker@ietfa.amsl.com> <9eb1fd3c-8868-9d24-6c30-46d333b69fef@isode.com> <3c1711a2-46dd-db1c-506e-5e1ad89ce56d@linagora.com> <92769755-62c6-7257-ce3d-7d0b5699735d@isode.com> <27c62cc8-68e0-49b5-4900-34c26d7b4c6a@linagora.com> In-Reply-To: <27c62cc8-68e0-49b5-4900-34c26d7b4c6a@linagora.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [17.153.40.233] Content-Type: multipart/alternative; boundary="_000_C88A669A21434FC281EF3C9A2CD5963Bapplecom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrIIsWRmVeSWpSXmKPExsUi2FCYpitz9lWEwe+ZRhYzVhdZzFi3it3i ePMrJove+zPYHFg8liz5yeRxqtnQ49//7YweH5/eYglgieKySUnNySxLLdK3S+DKOLSEpeDM BcaKRQ9nsjcwtp9m7GLk5JAQMJE4vf4/O4gtJLCPUaLpthhMfNeav0A1XEDx9UwSmzZ9ZYZw 2pkk9r9vZYFwtjNK/L7whK2LkYODTUBdYvO5NJBuEQEtiS+/+1lBbGaBKomrE4+xgdjCAjYS L+9/YYGosZXY9rWVEcIOk+ifcIsZxGYRUJW4s2Uq2EW8QPWXDz1khdh1gFlixb6ZYEWcAg4S B1/vBlvAKCAm8f3UGiaIZeISt57MZ4J4QUBiyZ7zzBC2qMTLx/9YIWwdibPXn0C9ryjxa8NM JpD7mQUSJLa9VoDYKyhxcuYTsB8lBHaxS3RMfMwygVFyFpIVsxBaZiFpgQhrSqzfpQ9RrSgx pfshO4StIdE6Zy6U7Shx6Nd2RmQ1Cxg5VjEK5SZm5uhm5pnpJRYU5KTqJefnbmIEpYHpdqI7 GM+ssjrEKMDBqMTDG1D9KkKINbGsuDL3EKM0B4uSOK/6kucRQgLpiSWp2ampBalF8UWlOanF hxiZODilGhjNa3m69FenmbanCNixHyxQeqFd6SyjUHZxPvOugBT2x+bNUireB8PkJht+u7U5 nzFjSfAxy+57ywQ3R3xtO/+go8ZQy36pYZvcCdP0JLabV9KqTc6erOhiyK1lNj359MWEjR+0 bwW0Vd1vmWd5JGXOrnWNEYnM8YeZS1fFrD70/+EvbmUjRyWW4oxEQy3mouJEAHIgmHPkAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDKsWRmVeSWpSXmKPExsUiOElQVFfm7KsIg3cv5CxmrC6ymLFuFbvF 8eZXTBa992ewObB4LFnyk8njVLOhx7//2xk9Pj69xRLAEsVlk5Kak1mWWqRvl8CVcWgJS8GZ C4wVix7OZG9gbD/N2MXIySEhYCKxa81fIJuLQ0hgPZPEpk1fmSGcdiaJ/e9bWSCc7YwSvy88 Yeti5OBgE1CX2HwuDaRbREBL4svvflYQm1mgSuLqxGNsILawgI3Ey/tfWCBqbCW2fW1lhLDD JPon3GIGsVkEVCXubJnKDmLzAtVfPvSQFWLXAWaJFftmghVxCjhIHHy9G2wBo4CYxPdTa5gg lolL3HoynwniBQGJJXvOM0PYohIvH/9jhbB1JM5efwL1pqLErw0zmUDuZxZIkNj2WgFir6DE yZlPWCYwis1CMnUWQtUsJFUQYU2J9bv0IaoVJaZ0P2SHsDUkWufMhbIdJQ792s6IrGYBI8cq RoGi1JzESgu9xIKCnFS95PzcTYygyG0oTNvB2LTc6hCjAAejEg9vQPWrCCHWxLLiytxDjBIc zEoivG4ngUK8KYmVValF+fFFpTmpxYcYJzICw3Ais5Rocj4wreSVxBuamBiYGBubGRubm5jT UlhJnPf64ucRQgLpiSWp2ampBalFMEcxcXBKNTDuCsvas/m9rLUcp/+1awa5TE+iTp+c8+T8 1jZJtzcN9W5VYgf8We90Om5kc/p6d6pVS0Dm68wY6yUhnMo3/pumXZi2doaK3f7eZby1body Xt2OX/Kx+Py2ujdZl9kyF7/1krRZrlGYfq6oRqlK9dvNn9ov9Q5OFYk1/bB1a+/TJXGhZbtK 765XYinOSDTUYi4qTgQAp0kB6U8DAAA= Archived-At: Subject: Re: [Jmap] Adding the Message::isForwarded property X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 00:09:06 -0000 --_000_C88A669A21434FC281EF3C9A2CD5963Bapplecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiBBcHIgNCwgMjAxNywgYXQgNzozMiBBTSwgQmVub2l0IFRlbGxpZXIgPGJ0ZWxsaWVyQGxp bmFnb3JhLmNvbTxtYWlsdG86YnRlbGxpZXJAbGluYWdvcmEuY29tPj4gd3JvdGU6DQoNCg0KSGkg QWxleGV5LA0KDQpUaGFua3MgZm9yIHlvdXIgYW5zd2VyLg0KDQpMZSAwNC8wNC8yMDE3IMOgIDIx OjAwLCBBbGV4ZXkgTWVsbmlrb3YgYSDDqWNyaXQgOg0KDQpIaSBCZW5vaXQsDQoNCk9uIDA0LzA0 LzIwMTcgMTE6MDgsIEJlbm9pdCBUZWxsaWVyIHdyb3RlOg0KDQpIaSwNCg0KVGhhbmtzIGZvciB5 b3VyIGFuc3dlcnMuIEhvdyBkbyB5b3UgcGxhbiB0byBhY2Nlc3Mgc3VjaCByZWdpc3RlcmVkIGtl eXdvcmQsIGlmIGl0IGlzIG5vdCBtYWRlIHNvbWVob3cgYSBtZXNzYWdlIHByb3BlcnR5Pw0KDQpJ dCBoYXMgdG8gYmUgYSBtZXNzYWdlIHByb3Blcmx5LiBGb3IgZXhhbXBsZSAia2V5d29yZHMiIHdo aWNoIGNvbnRhaW5zIGFuIGFycmF5IG9mIG90aGVyIElNQVAga2V5d29yZHMgYXMgc3RyaW5ncy4g SSBoYXZlIG90aGVyIGFwcGxpY2F0aW9ucyB0aGF0IG5lZWQgdG8gYWNjZXNzIHRvIG90aGVyIGtl eXdvcmRzLCBzb21lIG9mIHdoaWNoIGFyZSBsaXN0ZWQgb24gPGh0dHBzOi8vd3d3LmlhbmEub3Jn L2Fzc2lnbm1lbnRzL2ltYXAta2V5d29yZHMvaW1hcC1rZXl3b3Jkcy54aHRtbD48aHR0cHM6Ly93 d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvaW1hcC1rZXl3b3Jkcy9pbWFwLWtleXdvcmRzLnhodG1s Pg0KSSBhZ3JlZSB0aGF0IGEgKiprZXl3b3JkKiogcHJvcGVydHkgaXMgY29vbC4NCg0KSG93ZXZl ciwgSSB3b3VsZCBnbyBhIGJpdCBmdXJ0aGVyLiBSYXRoZXIgdGhhbiBjcmVhdGluZyBhIG1lc3Nh Z2UgcHJvcGVydHkgaGF2aW5nIGEgc3BlY2lhbCBtZWFuaW5nIGZvciB0aGUgRm9yd2FyZGVkIGZl YXR1cmUsIEkgd291bGQgbWFrZSBpdCBhIHRvcC1sZXZlbCBtZXNzYWdlIHByb3BlcnR5LiBUaGF0 IGlzIHdoeSBJIHByb3Bvc2VkIHRvIGFkZCBhICoqaXNGb3J3YXJkZWQqKiBtZXNzYWdlIHByb3Bl cnR5Lg0KDQpJIHNlZW0gdG8gYmUgb24gdGhlIG1pbm9yaXR5IHNpZGUgaGVyZSwgYnV0IEkgcGVy c29uYWxseSBkbyBzZWUgdGhlIGFwcGVhbCBpbiAqKmlzRm9yd2FyZGVkKiogYmVpbmcgYSBmaXJz dC1jbGFzcyBwcm9wZXJ0eS4gVGhpcyBpcyBhIGNvcmUgcGFydCBvZiBtYW55IG1vZGVybiBjbGll bnQgVUkncyBzaG93aW5nIGEgbGlzdCBvZiBtZXNzYWdlcy4gSWYgSSBoYWQgbmV2ZXIgdXNlZCBJ TUFQIGJlZm9yZSwgaXQgd291bGQgZGVmaW5pdGVseSBzZWVtIHdlaXJkIGFuZCBpbmNvbmdydWVu dCB0byBtZSB0aGF0IGFuc3dlcmVkIGlzIGEgcHJvcGVydHksIGJ1dCBmb3J3YXJkZWQgaXMgYSBr ZXl3b3JkLCBhbmQgaXQgd291bGQgcHJvYmFibHkgY2F1c2Ugc29tZSBtb21lbnRhcnkgY29uZnVz aW9uIHRyeWluZyB0byBmaWd1cmUgb3V0IGhvdyB0byBrbm93IGlmIGEgbWVzc2FnZSB3YXMgZm9y d2FyZGVkIG9yIG5vdC4NCg0KSSBhbHNvIHNlZSB0aGUgZGlsZW1tYSBvZiBoYXZpbmcgdG8gcGxh eSBjYXRjaC11cCB3aXRoIGV2ZXJ5IG5ldyByZWdpc3RlcmVkIGtleXdvcmQgYmVjb21pbmcgYSBz dXBwbGVtZW50YWwgcHJvcGVydHkuDQoNCklmIHRoZXJlIGRvZXMgZW5kIHVwIGJlaW5nIG1vcmUg c3VwcG9ydCBmb3IgdGhpcywgSSBjb3VsZCBzZWUgYW4gYXJndW1lbnQgZm9yIGRyYXdpbmcgYSBs aW5lIGluIHRoZSBzYW5kIG9uIHRoZSBtb3N0IGltcG9ydGFudCBrZXl3b3JkcywgYW5kIG1heWJl IHVwZ3JhZGluZyAkSnVuay8kTm90SnVuayBhbmQgJFBoaXNoaW5nIGludG8gZmlyc3QtY2xhc3Mg cHJvcGVydGllcyB0b28uIE90aGVyIGtleXdvcmRzIGxpa2UgJFN1Ym1pdFBlbmRpbmcgYW5kICRT dWJtaXR0ZWQgc2VlbSB0byBoYXZlIHRoZWlyIHVzZSBjYXNlcyBoYW5kbGVkIHF1aXRlIGRpZmZl cmVudGx5IGluIEpNQVAgd2l0aCB0aGUgT3V0Ym94IGNvbmNlcHQsIHNvIGNvdWxkIGJlIGxlZnQg YWxvbmUgaW4gYSByYXcga2V5d29yZHMgcHJvcGVydHkuDQoNCkkgdGhpbmsgaXTigJlzIGEgc3R5 bGlzdGljIHF1ZXN0aW9uLCB0aG91Z2gsIGFuZCBub3QgYSBmdW5jdGlvbmFsIG9uZS4gQ29uc2Vu c3VzIHNvIGZhciBzZWVtcyB0byBiZSBhZ2FpbnN0IHRoaXMsIGFuZCBJIHRoaW5rIGVpdGhlciB3 YXkgaXMgcHJvYmFibHkgZmluZSwgYnV0IEkgZG8gcGVyc29uYWxseSBzdXBwb3J0IHRoZSBtb3Jl IE9PUC1saWtlIGZpcnN0LWNsYXNzIHByb3BlcnR5LCB3aGVyZSBpdCBtYWtlcyBzZW5zZSBhbmQg aXMgY2xlYW5lciB0byB0aGUgbmV3Y29tZXIuDQoNCkFzIGEgSk1BUCB1c2VyIEkgd291bGQgbGlr ZSB0aGlzIHRvIGJlIHZlcnkgZWFzaWx5IGFjY2Vzc2libGUgZnJvbSB0aGUgTWVzc2FnZSBvYmpl Y3QsIGFuZCBhbHNvIGl0IHRvIGJlIHNlYXJjaGFibGUuDQoNCkFncmVlZC4NCg0KDQpJbiB0aGUg Y2FzZSBvZiAkRm9yd2FyZGVkIEkgdGhpbmsgaXQgbmVlZHMgdG8gYmUgY29uc2lzdGVudCB3aXRo IHRoZSByZXBseSBmZWF0dXJlLCBmb3IgYXV0b21hdGljYWxseSBtYXJrZWQgYXMgZm9yd2FyZGVk LCBhbmQgZm9yIHRocmVhZHMuDQoNCkkgd291bGRuJ3QgbWluZCBoYXZpbmcgc29tZSBleHRyYSBs b2dpYyBmb3IgZm9yd2FyZGVkIG1lc3NhZ2VzLCBpZiB0aGUgZ3JvdXAgY2FuIGFncmVlIG9uIHRo YXQuDQoNCkJlc3QgUmVnYXJkcywNCkFsZXhleQ0KDQoNCkNoZWVycywNCg0KQmVub2l0IFRlbGxp ZXINCg0KTGUgMDQvMDQvMjAxNyDDoCAwMDo0MywgQWxleGV5IE1lbG5pa292IGEgw6ljcml0IDoN Ck9uIDAzLzA0LzIwMTcgMTg6MTAsIENocmlzIE5ld21hbiB3cm90ZToNCg0KSU1BUCAkRm9yd2Fy ZGVkIGlzIGEgcmVnaXN0ZXJlZCBrZXl3b3JkIGFuZCB0aHVzIGEgZnVsbHkgc3VwcG9ydGVkIHBh cnQgb2YgSU1BUDoNCg0KaHR0cHM6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvaW1hcC1rZXl3 b3Jkcy9pbWFwLWtleXdvcmRzLnhodG1sI2ltYXAta2V5d29yZHMtMQ0KDQpUaGVyZSdzIG5vIG5l ZWQgZm9yIEpNQVAgdG8gZGVmaW5lIGFsbCB0aGVzZSByZWdpc3RlcmVkIGtleXdvcmRzOyBpdCBv bmx5IG5lZWRzIHRvIHJlZmVyZW5jZSB0aGUgcmVnaXN0cnkuDQpBZ3JlZWQuIEFuZCBhdCB0aGUg Q2hpY2FnbyBmYWNlLXRvLWZhY2UgbWVldGluZyBJJ3ZlIHJhaXNlZCB0aGUgaXNzdWUgb2YgbGFj ayBvZiBnZW5lcmljIGFjY2VzcyB0byBJTUFQIGtleXdvcmRzIGluIEpNQVAuIEkgYmVsaWV2ZSB0 aGVyZSB3YXMgcm9vbSBhZ3JlZW1lbnQgdG8gZml4IGl0IGluIGEgZ2VuZXJpYyB3YXkuDQoNCg0K ICAgICAgICA9IENocmlzDQoNCk9uIDMgQXByIDIwMTcsIGF0IDI6MTMsIEJlbm9pdCBUZWxsaWVy IHdyb3RlOg0KDQpIZWxsbywNCg0KQXQgTGluYWdvcmEsIHdlIHRlbmQgdG8gY29uc2lkZXIgKipm b3J3YXJkKiogaW5mb3JtYXRpb24gYXMgaW1wb3J0YW50DQpmb3IgdGhlIGVtYWlsIHdlIGNhcmUg YWJvdXQuDQoNClRvZGF5LCBpdCBpcyBub3QgcGFydCBvZiB0aGUgUkZDLTM1MDEgc3BlYywgYW5k IG1hbnkgSU1BUA0KaW1wbGVtZW50YXRpb25zIGhhbmRsZSBpdCB3aXRoIHRoZSBkZS1mYWN0byBz dGFuZGFyZCAkRm9yd2FyZGVkIGZsYWcuDQoNClRoaXMgaW1wbGljaXQgc3RhbmRhcmQgaXMgYSBi YWQgdGhpbmcsIGFuZCB3ZSB0cnVseSB3b3VsZCBsaWtlIHRoZSBKTUFQDQptYWlsIHByb3RvY29s IHRvIGRvIHRoaXMgcmlnaHQuIFRvIGJlIHJpZ2h0LCBpdCBzaG91bGQgYmUgZXhwbGljaXQuDQoN CldlIHRoZW4gcHJvcG9zZSB0aGlzIHB1bGwgcmVxdWVzdDoNCg0KSXQgcmVwcm9kdWNlcyB0aGUg YmVoYXZpb3Igb2YgKiphbnN3ZXJlZCoqIGZlYXR1cmU6DQoNCiAtIEFkZHMgYSAqKmlzRm9yd2Fy ZGVkKiogbWVzc2FnZSBwcm9wZXJ0eQ0KIC0gQWRkcyBhIG1lY2hhbmlzbSBmb3IgYXV0b21hdGlj YWxseSBtYXJraW5nIG1lc3NhZ2VzIGFzIGZvcndhcmRlZCB1cG9uDQpzZW5kaW5nIGVtYWlscw0K IC0gQ2xhcmlmaWVzIGludGVyYWN0aW9ucyBiZXR3ZWVuIGlzRm9yd2FyZGVkIGFuZCB0aHJlYWRz DQogLSBNYWtlcyBpc0ZvcndhcmRlZCBzZWFyY2hhYmxlDQoNCkRvZXMgdGhpcyBwcm9wb3NhbCBt YWtlIHNlbnNlIHRvIHlvdT8NCg0KQmVzdCByZWdhcmRzLA0KDQpCZW5vaXQgVGVsbGllcg0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClNvZnR3YXJlIGVuZ2luZWVyIGF0IExpbmFnb3Jh DQpQTUMgb24gQXBhY2hlIEpBTUVTDQoNCg0KTGUgMDEvMDQvMjAxNyDDoCAwNjoyMywgRGF2ZSBD cm9ja2VyIGEgw6ljcml0IDoNCkcnZGF5LA0KDQpUaGUgd29ya2luZyBncm91cCBtZWV0aW5nIGRp c2N1c3Npb24gYWJvdXQgYSBzdGF0aWMgbWVzc2FnZSwgZHluYW1pYw0KYW5ub3RhdGlvbiwgZXRj LiwgcmVzb25hdGVkIHdpdGggYSB2YXJpZXR5IG9mIHNpbWlsYXIgZGlzY3Vzc2lvbnMgSSd2ZQ0K YmVlbiBhcm91bmQgb3ZlciB0aGUgeWVhcnMgKGRhdGluZyBiYWNrIHRvIHRoZSBtaWQtMTk3MC4p DQoNCkEgc2ltcGxlciB2ZXJzaW9uIGVxdWF0ZXMgdGhlIGNvbnN0cnVjdHMgb2YgbWVzc2FnZSBh bmQgZG9jdW1lbnQsIGFzDQp0d28gdmlld3Mgb2YgdGhlIHNhbWUgdGhpbmcuICAoSWUsIERvY3Vt ZW50IHdpdGggYXR0cmlidXRlczsgTWVzc2FnZQ0Kd2l0aCBhIGJvZHkuKQ0KDQpUaGUgZXNzZW5j ZSBpcyB0byBjb25zaWRlciB0aGUgbmF0dXJlIGFuZCByZWxhdGlvbnNoaXAgb2YgdGhlIG9iamVj dHMsDQpwb3NzaWJseSBwZXJtaXR0aW5nIGRpZmZlcmVudCBzZW1hbnRpY3MgZm9yIHRoZSBzYW1l IHNldCBvZiBvYmplY3RzLA0KYWNjb3JkaW5nIHRvIGRpZmZlcmVudCBhcHBsaWNhdGlvbnMgb3Ig cm9sZXMuDQoNClRoYXQgaXMsIHRoZXJlIGNhbiBiZSBhIHZhcmlldHkgb2YgY29uc3RpdHVlbnQg b2JqZWN0cyB0aGF0IGFyZQ0KYXNzb2NpYXRlZCBhbmQgY2FuIGJlIHZpZXdlZCBhY2NvcmRpbmcg dG8gZGlmZmVyZW50IHNlbWFudGljcyAob3INCnZpZXdzKS4uLiAgU28gYSBtZXNzYWdlLCBhIGRv Y3VtZW50LCBhIGNhbGVuZGFyIGVudHJ5LCBhIHNlcmllcyBvZg0KY29tbWVudHMsIGV0Yy4gIEVh Y2ggb2JqZWN0IGhhcyBhc3NvY2lhdGVkIHByb2Nlc3NpbmcgcnVsZXMgKGVnLA0Kc3RhdGljIHZz LiBlZGl0YWJsZSB2cy4gZXhlY3V0YWJsZTsgY29uc3RyYWluZWQgY2hvaWNlIG9mIHZhbHVlczsN Cm9yZ2FuaXphdGlvbiBpbnRvIGZvbGRlcnMgb3Igb3RoZXIgc2NoZW1hcy4uLikNCg0KQW4gZW52 aXJvbm1lbnQgbGlrZSB0aGlzIGNhbiAgYmUgcG93ZXJmdWwgYW5kIHZlcnkgYXBwZWFsaW5nLiBU aGUNCmNoYWxsZW5nZSB0ZW5kcyB0byBiZSBzdGF5aW5nIHByYWN0aWNhbDogIFdpdGggbm8gZWZm b3J0IGF0IGFsbCBpdA0KZGV2b2x2ZXMgaW50byBhbiBhYnN0cmFjdCBjb21wdXRlciBzY2llbmNl IGV4ZXJjaXNlLiAgU29tZSBvZiB0aGF0IGlzDQphbiBlZmZpY2llbmN5IGlzc3VlKCopIGJ1dCBJ IHRoaW5rIGl0J3MgbW9zdGx5IGFib3V0IHRoZSBodW1hbg0KbWFuYWdlYWJpbGl0eSBmb3IgZGVz aWduIGFuZCBvcGVyYXRpb25zLg0KDQpCYXNlZCBvbiBib3RoIHRoZSB5ZWFycyBvZiBjb21tZXJj aWFsIHVzZSBhbmQgdGhlIHB1YmxpYyBjb21tZW50YXJ5DQphYm91dCB0aGUgcGVyZm9ybWFuY2Us IEkndmUgbm8gZG91YnQgdGhlIGZhc3RtYWlsIHN5c3RlbSBkb2VzIG5vdA0Kc3VmZmVyIHRoZXNl IGRvd25zaWRlcy4gIEJ1dCBpdCdzIGEgcG90ZW50aWFsIHRoYXQgdGhpcyByZS1jYXN0aW5nDQp0 aHJvdWdoIHRoZSBJRVRGIGNvdWxkIGVhc2lseSBzdWZmZXIuDQoNCkknbSBwb3N0aW5nIHRoaXMg bm90ZSBwYXJ0bHkgYmVjYXVzZSBJIHRoaW5rIGl0IHdvdWxkIGV4Y2l0aW5nIHRvDQpwcm9kdWNl IHNwZWNzIHRoYXQgcGVybWl0IGEgZGVncmVlIG9mIGZsZXhpYmlsaXR5IHRoYXQgc3VjaCBhbg0K YXBwcm9hY2ggcGVybWl0cywgYnV0IGFsc28gd2FudGVkIHRvIGNpdGUgdGhlIGRhbmdlcnMuDQoN CkF0IHRoZSBtb21lbnQsIEknbSBndWVzc2luZyB0aGVyZSBuZWVkcyB0byBiZSBhIHNtYWxsIG51 bWJlciBvZiBiYXNpYw0Kb2JqZWN0IHR5cGVzIGFuZCBhIHNtYWxsIG51bWJlciBvZiAncmVsYXRp b25zaGlwJyB0eXBlcyB0aGF0IGRlZmluZQ0KdGhlIGFzc29jaWF0aW9uIGJldHdlZW4gb2JqZWN0 cy4gIFRoZXNlIGNvdWxkIHRoZW4gYmUgY29tYmluZWQgaW50bw0KaGlnaGVyLW9yZGVyLCBmb3Jt YWwgb3JnYW5pemF0aW9ucy9zZW1hbnRpY3MgdGhlIGRlZmluZSBhbiBhcHBsaWNhdGlvbg0Kc2Vt YW50aWMgKG1haWwsIGNhbGVuZGFyLCB3aGF0ZXZlci4pDQoNCg0KZC8NCg0KKCopIEEgc3lzdGVt IEkgZGlkIGluIDE5NzcgaGFzIGEgbGl0dGxlIGJpdCBvZiB0aGlzIGFuZCB0aGUgZXh0cmVtZWx5 DQpwdXJlIGRlc2lnbiBwcm9kdWNlZCBpbXByZXNzaXZlbHkgaG9ycmlibGUgcGVyZm9ybWFuY2Uu DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkpt YXAgbWFpbGluZyBsaXN0DQpKbWFwQGlldGYub3JnPG1haWx0bzpKbWFwQGlldGYub3JnPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9qbWFwDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpKbWFwIG1haWxpbmcgbGlzdA0KSm1h cEBpZXRmLm9yZzxtYWlsdG86Sm1hcEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vam1hcA0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KSm1hcCBtYWlsaW5nIGxpc3QNCkptYXBAaWV0Zi5vcmc8bWFp bHRvOkptYXBAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2ptYXANCg0K --_000_C88A669A21434FC281EF3C9A2CD5963Bapplecom_ Content-Type: text/html; charset="utf-8" Content-ID: <2A4AB79C91B5E845824EC01E6B4D3C4B@pex.exch.apple.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBBcHIg NCwgMjAxNywgYXQgNzozMiBBTSwgQmVub2l0IFRlbGxpZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpi dGVsbGllckBsaW5hZ29yYS5jb20iIGNsYXNzPSIiPmJ0ZWxsaWVyQGxpbmFnb3JhLmNvbTwvYT4m Z3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4N CjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGJnY29sb3I9IiNGRkZGRkYiIHRleHQ9IiMwMDAwMDAiIGNs YXNzPSIiPg0KPHAgY2xhc3M9IiI+SGkgQWxleGV5LDwvcD4NCjxwIGNsYXNzPSIiPlRoYW5rcyBm b3IgeW91ciBhbnN3ZXIuPGJyIGNsYXNzPSIiPg0KPC9wPg0KPGJyIGNsYXNzPSIiPg0KPGRpdiBj bGFzcz0ibW96LWNpdGUtcHJlZml4Ij5MZSAwNC8wNC8yMDE3IMOgIDIxOjAwLCBBbGV4ZXkgTWVs bmlrb3YgYSDDqWNyaXQmbmJzcDs6PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBj aXRlPSJtaWQ6OTI3Njk3NTUtNjJjNi03MjU3LWNlM2QtN2QwYjU2OTk3MzVkQGlzb2RlLmNvbSIg dHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8cCBjbGFzcz0iIj5IaSBCZW5vaXQsPGJyIGNsYXNzPSIi Pg0KPC9wPg0KPHAgY2xhc3M9IiI+T24gMDQvMDQvMjAxNyAxMTowOCwgQmVub2l0IFRlbGxpZXIg d3JvdGU6PGJyIGNsYXNzPSIiPg0KPC9wPg0KPGJsb2NrcXVvdGUgY2l0ZT0ibWlkOjNjMTcxMWEy LTQ2ZGQtZGIxYy01MDZlLTVlMWFkODljZTU2ZEBsaW5hZ29yYS5jb20iIHR5cGU9ImNpdGUiIGNs YXNzPSIiPg0KPGZvbnQgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IiI+PGNvZGUgY2xhc3M9ImhsanMi PkhpLCA8YnIgY2xhc3M9IiI+DQo8L2NvZGU+PC9zcGFuPjwvZm9udD4NCjxwIGNsYXNzPSIiPjxm b250IGNsYXNzPSIiPjxzcGFuIGNsYXNzPSIiPjxjb2RlIGNsYXNzPSJobGpzIj5UaGFua3MgZm9y IHlvdXIgYW5zd2Vycy4gSG93IGRvIHlvdSBwbGFuIHRvIGFjY2VzcyBzdWNoIHJlZ2lzdGVyZWQg a2V5d29yZCwgaWYgaXQgaXMgbm90IG1hZGUgc29tZWhvdyBhIG1lc3NhZ2UgcHJvcGVydHk/PC9j b2RlPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGZvbnQgZmFjZT0iSGVsdmV0 aWNhIiBjbGFzcz0iIj48Y29kZSBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIj48YnIgY2xhc3M9IiI+ DQpJdCBoYXMgdG8gYmUgYSBtZXNzYWdlIHByb3Blcmx5LiBGb3IgZXhhbXBsZSAmcXVvdDtrZXl3 b3JkcyZxdW90OyB3aGljaCBjb250YWlucyBhbiBhcnJheSBvZiBvdGhlciBJTUFQIGtleXdvcmRz IGFzIHN0cmluZ3MuIEkgaGF2ZSBvdGhlciBhcHBsaWNhdGlvbnMgdGhhdCBuZWVkIHRvIGFjY2Vz cyB0byBvdGhlciBrZXl3b3Jkcywgc29tZSBvZiB3aGljaCBhcmUgbGlzdGVkIG9uDQo8YSBtb3ot ZG8tbm90LXNlbmQ9InRydWUiIGNsYXNzPSJtb3otdHh0LWxpbmstcmZjMjM5NkUiIGhyZWY9Imh0 dHBzOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL2ltYXAta2V5d29yZHMvaW1hcC1rZXl3b3Jk cy54aHRtbCI+DQombHQ7aHR0cHM6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvaW1hcC1rZXl3 b3Jkcy9pbWFwLWtleXdvcmRzLnhodG1sJmd0OzwvYT48L2ZvbnQ+PC9jb2RlPjxiciBjbGFzcz0i Ij4NCjwvZm9udD48L2Jsb2NrcXVvdGU+DQo8Y29kZSBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBm YWNlPSJIZWx2ZXRpY2EiPkkgYWdyZWUgdGhhdCBhICoqa2V5d29yZCoqIHByb3BlcnR5IGlzIGNv b2wuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSG93ZXZlciwgSSB3b3VsZCBnbyBhIGJp dCBmdXJ0aGVyLiBSYXRoZXIgdGhhbiBjcmVhdGluZyBhIG1lc3NhZ2UgcHJvcGVydHkgaGF2aW5n IGEgc3BlY2lhbCBtZWFuaW5nIGZvciB0aGUgRm9yd2FyZGVkIGZlYXR1cmUsIEkgd291bGQgbWFr ZSBpdCBhIHRvcC1sZXZlbCBtZXNzYWdlIHByb3BlcnR5LiBUaGF0IGlzIHdoeSBJIHByb3Bvc2Vk IHRvIGFkZCBhICoqaXNGb3J3YXJkZWQqKiBtZXNzYWdlIHByb3BlcnR5LjxiciBjbGFzcz0iIj4N CjwvZm9udD48L2NvZGU+PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQpJIHNlZW0gdG8gYmUgb24gdGhlIG1pbm9yaXR5IHNpZGUgaGVyZSwg YnV0IEkgcGVyc29uYWxseSBkbyBzZWUgdGhlIGFwcGVhbCBpbiAqKmlzRm9yd2FyZGVkKiogYmVp bmcgYSBmaXJzdC1jbGFzcyBwcm9wZXJ0eS4gVGhpcyBpcyBhIGNvcmUgcGFydCBvZiBtYW55IG1v ZGVybiBjbGllbnQgVUkncyBzaG93aW5nIGEgbGlzdCBvZiBtZXNzYWdlcy4gSWYgSSBoYWQgbmV2 ZXIgdXNlZCBJTUFQIGJlZm9yZSwgaXQgd291bGQgZGVmaW5pdGVseSBzZWVtDQogd2VpcmQgYW5k IGluY29uZ3J1ZW50IHRvIG1lIHRoYXQgYW5zd2VyZWQgaXMgYSBwcm9wZXJ0eSwgYnV0IGZvcndh cmRlZCBpcyBhIGtleXdvcmQsIGFuZCBpdCB3b3VsZCBwcm9iYWJseSBjYXVzZSBzb21lIG1vbWVu dGFyeSBjb25mdXNpb24gdHJ5aW5nIHRvIGZpZ3VyZSBvdXQgaG93IHRvIGtub3cgaWYgYSBtZXNz YWdlIHdhcyBmb3J3YXJkZWQgb3Igbm90LjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjxkaXY+SSBhbHNvIHNlZSB0aGUgZGlsZW1tYSBvZiBoYXZpbmcgdG8gcGxheSBjYXRjaC11 cCB3aXRoIGV2ZXJ5IG5ldyByZWdpc3RlcmVkIGtleXdvcmQgYmVjb21pbmcgYSBzdXBwbGVtZW50 YWwgcHJvcGVydHkuPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5JZiB0 aGVyZSBkb2VzIGVuZCB1cCBiZWluZyBtb3JlIHN1cHBvcnQgZm9yIHRoaXMsIEkgY291bGQgc2Vl IGFuIGFyZ3VtZW50IGZvciBkcmF3aW5nIGEgbGluZSBpbiB0aGUgc2FuZCBvbiB0aGUgbW9zdCBp bXBvcnRhbnQga2V5d29yZHMsIGFuZCBtYXliZSB1cGdyYWRpbmcgJEp1bmsvJE5vdEp1bmsgYW5k ICRQaGlzaGluZyBpbnRvIGZpcnN0LWNsYXNzIHByb3BlcnRpZXMgdG9vLiBPdGhlciBrZXl3b3Jk cyBsaWtlICRTdWJtaXRQZW5kaW5nDQogYW5kICRTdWJtaXR0ZWQgc2VlbSB0byBoYXZlIHRoZWly IHVzZSBjYXNlcyBoYW5kbGVkIHF1aXRlIGRpZmZlcmVudGx5IGluIEpNQVAgd2l0aCB0aGUgT3V0 Ym94IGNvbmNlcHQsIHNvIGNvdWxkIGJlIGxlZnQgYWxvbmUgaW4gYSByYXcga2V5d29yZHMgcHJv cGVydHkuPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5JIHRoaW5rIGl0 4oCZcyBhIHN0eWxpc3RpYyBxdWVzdGlvbiwgdGhvdWdoLCBhbmQgbm90IGEgZnVuY3Rpb25hbCBv bmUuIENvbnNlbnN1cyBzbyBmYXIgc2VlbXMgdG8gYmUgYWdhaW5zdCB0aGlzLCBhbmQgSSB0aGlu ayBlaXRoZXIgd2F5IGlzIHByb2JhYmx5IGZpbmUsIGJ1dCBJIGRvIHBlcnNvbmFsbHkgc3VwcG9y dCB0aGUgbW9yZSBPT1AtbGlrZSBmaXJzdC1jbGFzcyBwcm9wZXJ0eSwgd2hlcmUgaXQgbWFrZXMg c2Vuc2UgYW5kIGlzIGNsZWFuZXINCiB0byB0aGUgbmV3Y29tZXIuPC9kaXY+DQo8ZGl2Pg0KPGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBiZ2Nv bG9yPSIjRkZGRkZGIiB0ZXh0PSIjMDAwMDAwIiBjbGFzcz0iIj48Zm9udCBmYWNlPSJIZWx2ZXRp Y2EiIGNsYXNzPSIiPjxjb2RlIGNsYXNzPSIiPjxmb250IGNsYXNzPSIiPjwvZm9udD48L2NvZGU+ PC9mb250Pg0KPGJsb2NrcXVvdGUgY2l0ZT0ibWlkOjkyNzY5NzU1LTYyYzYtNzI1Ny1jZTNkLTdk MGI1Njk5NzM1ZEBpc29kZS5jb20iIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUg Y2l0ZT0ibWlkOjNjMTcxMWEyLTQ2ZGQtZGIxYy01MDZlLTVlMWFkODljZTU2ZEBsaW5hZ29yYS5j b20iIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPHAgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiI+PHNw YW4gY2xhc3M9IiI+PGNvZGUgY2xhc3M9ImhsanMiPkFzIGEgSk1BUCB1c2VyIEkgd291bGQgbGlr ZSB0aGlzIHRvIGJlIHZlcnkgZWFzaWx5IGFjY2Vzc2libGUgZnJvbSB0aGUgTWVzc2FnZSBvYmpl Y3QsIGFuZCBhbHNvIGl0IHRvIGJlIHNlYXJjaGFibGUuDQo8YnIgY2xhc3M9IiI+DQo8L2NvZGU+ PC9zcGFuPjwvZm9udD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8Zm9udCBmYWNlPSJIZWx2ZXRpY2Ei IGNsYXNzPSIiPjxjb2RlIGNsYXNzPSIiPjxmb250IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCkFn cmVlZC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2ZvbnQ+PC9jb2RlPjwvZm9udD4N CjxibG9ja3F1b3RlIGNpdGU9Im1pZDozYzE3MTFhMi00NmRkLWRiMWMtNTA2ZS01ZTFhZDg5Y2U1 NmRAbGluYWdvcmEuY29tIiB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxwIGNsYXNzPSIiPjxmb250 IGNsYXNzPSIiPjxzcGFuIGNsYXNzPSIiPjxjb2RlIGNsYXNzPSJobGpzIj48L2NvZGU+PC9zcGFu PjwvZm9udD48L3A+DQo8cCBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIj48c3BhbiBjbGFzcz0iIj48 Y29kZSBjbGFzcz0iaGxqcyI+SW4gdGhlIGNhc2Ugb2YgJEZvcndhcmRlZCBJIHRoaW5rIGl0IG5l ZWRzIHRvIGJlIGNvbnNpc3RlbnQgd2l0aCB0aGUgcmVwbHkgZmVhdHVyZSwgZm9yIGF1dG9tYXRp Y2FsbHkgbWFya2VkIGFzIGZvcndhcmRlZCwgYW5kIGZvciB0aHJlYWRzLjwvY29kZT48L3NwYW4+ PC9mb250PjwvcD4NCjwvYmxvY2txdW90ZT4NCjxmb250IGZhY2U9IkhlbHZldGljYSIgY2xhc3M9 IiI+PGNvZGUgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KSSB3b3VsZG4n dCBtaW5kIGhhdmluZyBzb21lIGV4dHJhIGxvZ2ljIGZvciBmb3J3YXJkZWQgbWVzc2FnZXMsIGlm IHRoZSBncm91cCBjYW4gYWdyZWUgb24gdGhhdC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+ DQpCZXN0IFJlZ2FyZHMsPGJyIGNsYXNzPSIiPg0KQWxleGV5PGJyIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KPC9mb250PjwvY29kZT48L2ZvbnQ+DQo8YmxvY2txdW90ZSBjaXRlPSJtaWQ6M2Mx NzExYTItNDZkZC1kYjFjLTUwNmUtNWUxYWQ4OWNlNTZkQGxpbmFnb3JhLmNvbSIgdHlwZT0iY2l0 ZSIgY2xhc3M9IiI+DQo8cCBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIj48c3BhbiBjbGFzcz0iIj48 Y29kZSBjbGFzcz0iaGxqcyI+Q2hlZXJzLCA8YnIgY2xhc3M9IiI+DQo8L2NvZGU+PC9zcGFuPjwv Zm9udD48L3A+DQo8cCBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIj48c3BhbiBjbGFzcz0iIj48Y29k ZSBjbGFzcz0iaGxqcyI+QmVub2l0IFRlbGxpZXI8L2NvZGU+PC9zcGFuPjwvZm9udD48L3A+DQo8 YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJtb3otY2l0ZS1wcmVmaXgiPkxlIDA0LzA0LzIwMTcg w6AgMDA6NDMsIEFsZXhleSBNZWxuaWtvdiBhIMOpY3JpdCZuYnNwOzo8YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIGNpdGU9Im1pZDo5ZWIxZmQzYy04ODY4LTlkMjQtNmMzMC00NmQz MzNiNjlmZWZAaXNvZGUuY29tIiB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCk9uIDAzLzA0LzIwMTcg MTg6MTAsIENocmlzIE5ld21hbiB3cm90ZTogPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+SU1BUCAkRm9yd2FyZGVkIGlzIGEgcmVn aXN0ZXJlZCBrZXl3b3JkIGFuZCB0aHVzIGEgZnVsbHkgc3VwcG9ydGVkIHBhcnQgb2YgSU1BUDoN CjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIg Y2xhc3M9Im1vei10eHQtbGluay1mcmVldGV4dCIgaHJlZj0iaHR0cHM6Ly93d3cuaWFuYS5vcmcv YXNzaWdubWVudHMvaW1hcC1rZXl3b3Jkcy9pbWFwLWtleXdvcmRzLnhodG1sI2ltYXAta2V5d29y ZHMtMSI+aHR0cHM6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvaW1hcC1rZXl3b3Jkcy9pbWFw LWtleXdvcmRzLnhodG1sI2ltYXAta2V5d29yZHMtMTwvYT4NCjxiciBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NClRoZXJlJ3Mgbm8gbmVlZCBmb3IgSk1BUCB0byBkZWZpbmUgYWxsIHRoZXNlIHJl Z2lzdGVyZWQga2V5d29yZHM7IGl0IG9ubHkgbmVlZHMgdG8gcmVmZXJlbmNlIHRoZSByZWdpc3Ry eS4NCjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCkFncmVlZC4gQW5kIGF0IHRoZSBDaGlj YWdvIGZhY2UtdG8tZmFjZSBtZWV0aW5nIEkndmUgcmFpc2VkIHRoZSBpc3N1ZSBvZiBsYWNrIG9m IGdlbmVyaWMgYWNjZXNzIHRvIElNQVAga2V5d29yZHMgaW4gSk1BUC4gSSBiZWxpZXZlIHRoZXJl IHdhcyByb29tIGFncmVlbWVudCB0byBmaXggaXQgaW4gYSBnZW5lcmljIHdheS4NCjxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA9 IENocmlzIDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCk9uIDMgQXByIDIwMTcsIGF0IDI6 MTMsIEJlbm9pdCBUZWxsaWVyIHdyb3RlOiA8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8 YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5IZWxsbywgPGJyIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KQXQgTGluYWdvcmEsIHdlIHRlbmQgdG8gY29uc2lkZXIgKipmb3J3YXJkKiog aW5mb3JtYXRpb24gYXMgaW1wb3J0YW50IDxiciBjbGFzcz0iIj4NCmZvciB0aGUgZW1haWwgd2Ug Y2FyZSBhYm91dC4gPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVG9kYXksIGl0IGlzIG5v dCBwYXJ0IG9mIHRoZSBSRkMtMzUwMSBzcGVjLCBhbmQgbWFueSBJTUFQIDxiciBjbGFzcz0iIj4N CmltcGxlbWVudGF0aW9ucyBoYW5kbGUgaXQgd2l0aCB0aGUgZGUtZmFjdG8gc3RhbmRhcmQgJEZv cndhcmRlZCBmbGFnLiA8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGlzIGltcGxpY2l0 IHN0YW5kYXJkIGlzIGEgYmFkIHRoaW5nLCBhbmQgd2UgdHJ1bHkgd291bGQgbGlrZSB0aGUgSk1B UCA8YnIgY2xhc3M9IiI+DQptYWlsIHByb3RvY29sIHRvIGRvIHRoaXMgcmlnaHQuIFRvIGJlIHJp Z2h0LCBpdCBzaG91bGQgYmUgZXhwbGljaXQuIDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N CldlIHRoZW4gcHJvcG9zZSB0aGlzIHB1bGwgcmVxdWVzdDogPGJyIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KSXQgcmVwcm9kdWNlcyB0aGUgYmVoYXZpb3Igb2YgKiphbnN3ZXJlZCoqIGZlYXR1 cmU6IDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZuYnNwOy0gQWRkcyBhICoqaXNGb3J3 YXJkZWQqKiBtZXNzYWdlIHByb3BlcnR5IDxiciBjbGFzcz0iIj4NCiZuYnNwOy0gQWRkcyBhIG1l Y2hhbmlzbSBmb3IgYXV0b21hdGljYWxseSBtYXJraW5nIG1lc3NhZ2VzIGFzIGZvcndhcmRlZCB1 cG9uIDxiciBjbGFzcz0iIj4NCnNlbmRpbmcgZW1haWxzIDxiciBjbGFzcz0iIj4NCiZuYnNwOy0g Q2xhcmlmaWVzIGludGVyYWN0aW9ucyBiZXR3ZWVuIGlzRm9yd2FyZGVkIGFuZCB0aHJlYWRzIDxi ciBjbGFzcz0iIj4NCiZuYnNwOy0gTWFrZXMgaXNGb3J3YXJkZWQgc2VhcmNoYWJsZSA8YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpEb2VzIHRoaXMgcHJvcG9zYWwgbWFrZSBzZW5zZSB0byB5 b3U/IDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkJlc3QgcmVnYXJkcywgPGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KQmVub2l0IFRlbGxpZXIgPGJyIGNsYXNzPSIiPg0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gPGJyIGNsYXNzPSIiPg0KU29mdHdhcmUgZW5naW5lZXIg YXQgTGluYWdvcmEgPGJyIGNsYXNzPSIiPg0KUE1DIG9uIEFwYWNoZSBKQU1FUyA8YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpMZSAwMS8wNC8yMDE3IMOgIDA2OjIz LCBEYXZlIENyb2NrZXIgYSDDqWNyaXQgOiA8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBl PSJjaXRlIiBjbGFzcz0iIj5HJ2RheSwgPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhl IHdvcmtpbmcgZ3JvdXAgbWVldGluZyBkaXNjdXNzaW9uIGFib3V0IGEgc3RhdGljIG1lc3NhZ2Us IGR5bmFtaWMgPGJyIGNsYXNzPSIiPg0KYW5ub3RhdGlvbiwgZXRjLiwgcmVzb25hdGVkIHdpdGgg YSB2YXJpZXR5IG9mIHNpbWlsYXIgZGlzY3Vzc2lvbnMgSSd2ZSA8YnIgY2xhc3M9IiI+DQpiZWVu IGFyb3VuZCBvdmVyIHRoZSB5ZWFycyAoZGF0aW5nIGJhY2sgdG8gdGhlIG1pZC0xOTcwLikgPGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQSBzaW1wbGVyIHZlcnNpb24gZXF1YXRlcyB0aGUg Y29uc3RydWN0cyBvZiBtZXNzYWdlIGFuZCBkb2N1bWVudCwgYXMgPGJyIGNsYXNzPSIiPg0KdHdv IHZpZXdzIG9mIHRoZSBzYW1lIHRoaW5nLiZuYnNwOyAoSWUsIERvY3VtZW50IHdpdGggYXR0cmli dXRlczsgTWVzc2FnZSA8YnIgY2xhc3M9IiI+DQp3aXRoIGEgYm9keS4pIDxiciBjbGFzcz0iIj4N CjxiciBjbGFzcz0iIj4NClRoZSBlc3NlbmNlIGlzIHRvIGNvbnNpZGVyIHRoZSBuYXR1cmUgYW5k IHJlbGF0aW9uc2hpcCBvZiB0aGUgb2JqZWN0cywgPGJyIGNsYXNzPSIiPg0KcG9zc2libHkgcGVy bWl0dGluZyBkaWZmZXJlbnQgc2VtYW50aWNzIGZvciB0aGUgc2FtZSBzZXQgb2Ygb2JqZWN0cywg PGJyIGNsYXNzPSIiPg0KYWNjb3JkaW5nIHRvIGRpZmZlcmVudCBhcHBsaWNhdGlvbnMgb3Igcm9s ZXMuIDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClRoYXQgaXMsIHRoZXJlIGNhbiBiZSBh IHZhcmlldHkgb2YgY29uc3RpdHVlbnQgb2JqZWN0cyB0aGF0IGFyZSA8YnIgY2xhc3M9IiI+DQph c3NvY2lhdGVkIGFuZCBjYW4gYmUgdmlld2VkIGFjY29yZGluZyB0byBkaWZmZXJlbnQgc2VtYW50 aWNzIChvciA8YnIgY2xhc3M9IiI+DQp2aWV3cykuLi4mbmJzcDsgU28gYSBtZXNzYWdlLCBhIGRv Y3VtZW50LCBhIGNhbGVuZGFyIGVudHJ5LCBhIHNlcmllcyBvZiA8YnIgY2xhc3M9IiI+DQpjb21t ZW50cywgZXRjLiZuYnNwOyBFYWNoIG9iamVjdCBoYXMgYXNzb2NpYXRlZCBwcm9jZXNzaW5nIHJ1 bGVzIChlZywgPGJyIGNsYXNzPSIiPg0Kc3RhdGljIHZzLiBlZGl0YWJsZSB2cy4gZXhlY3V0YWJs ZTsgY29uc3RyYWluZWQgY2hvaWNlIG9mIHZhbHVlczsgPGJyIGNsYXNzPSIiPg0Kb3JnYW5pemF0 aW9uIGludG8gZm9sZGVycyBvciBvdGhlciBzY2hlbWFzLi4uKSA8YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQpBbiBlbnZpcm9ubWVudCBsaWtlIHRoaXMgY2FuJm5ic3A7IGJlIHBvd2VyZnVs IGFuZCB2ZXJ5IGFwcGVhbGluZy4gVGhlIDxiciBjbGFzcz0iIj4NCmNoYWxsZW5nZSB0ZW5kcyB0 byBiZSBzdGF5aW5nIHByYWN0aWNhbDombmJzcDsgV2l0aCBubyBlZmZvcnQgYXQgYWxsIGl0IDxi ciBjbGFzcz0iIj4NCmRldm9sdmVzIGludG8gYW4gYWJzdHJhY3QgY29tcHV0ZXIgc2NpZW5jZSBl eGVyY2lzZS4mbmJzcDsgU29tZSBvZiB0aGF0IGlzIDxiciBjbGFzcz0iIj4NCmFuIGVmZmljaWVu Y3kgaXNzdWUoKikgYnV0IEkgdGhpbmsgaXQncyBtb3N0bHkgYWJvdXQgdGhlIGh1bWFuIDxiciBj bGFzcz0iIj4NCm1hbmFnZWFiaWxpdHkgZm9yIGRlc2lnbiBhbmQgb3BlcmF0aW9ucy4gPGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQmFzZWQgb24gYm90aCB0aGUgeWVhcnMgb2YgY29tbWVy Y2lhbCB1c2UgYW5kIHRoZSBwdWJsaWMgY29tbWVudGFyeSA8YnIgY2xhc3M9IiI+DQphYm91dCB0 aGUgcGVyZm9ybWFuY2UsIEkndmUgbm8gZG91YnQgdGhlIGZhc3RtYWlsIHN5c3RlbSBkb2VzIG5v dCA8YnIgY2xhc3M9IiI+DQpzdWZmZXIgdGhlc2UgZG93bnNpZGVzLiZuYnNwOyBCdXQgaXQncyBh IHBvdGVudGlhbCB0aGF0IHRoaXMgcmUtY2FzdGluZyA8YnIgY2xhc3M9IiI+DQp0aHJvdWdoIHRo ZSBJRVRGIGNvdWxkIGVhc2lseSBzdWZmZXIuIDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N CkknbSBwb3N0aW5nIHRoaXMgbm90ZSBwYXJ0bHkgYmVjYXVzZSBJIHRoaW5rIGl0IHdvdWxkIGV4 Y2l0aW5nIHRvIDxiciBjbGFzcz0iIj4NCnByb2R1Y2Ugc3BlY3MgdGhhdCBwZXJtaXQgYSBkZWdy ZWUgb2YgZmxleGliaWxpdHkgdGhhdCBzdWNoIGFuIDxiciBjbGFzcz0iIj4NCmFwcHJvYWNoIHBl cm1pdHMsIGJ1dCBhbHNvIHdhbnRlZCB0byBjaXRlIHRoZSBkYW5nZXJzLiA8YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQpBdCB0aGUgbW9tZW50LCBJJ20gZ3Vlc3NpbmcgdGhlcmUgbmVlZHMg dG8gYmUgYSBzbWFsbCBudW1iZXIgb2YgYmFzaWMgPGJyIGNsYXNzPSIiPg0Kb2JqZWN0IHR5cGVz IGFuZCBhIHNtYWxsIG51bWJlciBvZiAncmVsYXRpb25zaGlwJyB0eXBlcyB0aGF0IGRlZmluZSA8 YnIgY2xhc3M9IiI+DQp0aGUgYXNzb2NpYXRpb24gYmV0d2VlbiBvYmplY3RzLiZuYnNwOyBUaGVz ZSBjb3VsZCB0aGVuIGJlIGNvbWJpbmVkIGludG8gPGJyIGNsYXNzPSIiPg0KaGlnaGVyLW9yZGVy LCBmb3JtYWwgb3JnYW5pemF0aW9ucy9zZW1hbnRpY3MgdGhlIGRlZmluZSBhbiBhcHBsaWNhdGlv biA8YnIgY2xhc3M9IiI+DQpzZW1hbnRpYyAobWFpbCwgY2FsZW5kYXIsIHdoYXRldmVyLikgPGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KZC8gPGJyIGNsYXNzPSIi Pg0KPGJyIGNsYXNzPSIiPg0KKCopIEEgc3lzdGVtIEkgZGlkIGluIDE5NzcgaGFzIGEgbGl0dGxl IGJpdCBvZiB0aGlzIGFuZCB0aGUgZXh0cmVtZWx5IDxiciBjbGFzcz0iIj4NCnB1cmUgZGVzaWdu IHByb2R1Y2VkIGltcHJlc3NpdmVseSBob3JyaWJsZSBwZXJmb3JtYW5jZS4gPGJyIGNsYXNzPSIi Pg0KPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gPGJyIGNsYXNzPSIiPg0KSm1h cCBtYWlsaW5nIGxpc3QgPGJyIGNsYXNzPSIiPg0KPGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBj bGFzcz0ibW96LXR4dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86Sm1hcEBpZXRmLm9y ZyI+Sm1hcEBpZXRmLm9yZzwvYT4NCjxiciBjbGFzcz0iIj4NCjxhIG1vei1kby1ub3Qtc2VuZD0i dHJ1ZSIgY2xhc3M9Im1vei10eHQtbGluay1mcmVldGV4dCIgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9qbWFwIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2ptYXA8L2E+DQo8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xh c3M9IiI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyA8 YnIgY2xhc3M9IiI+DQpKbWFwIG1haWxpbmcgbGlzdCA8YnIgY2xhc3M9IiI+DQo8YSBtb3otZG8t bm90LXNlbmQ9InRydWUiIGNsYXNzPSJtb3otdHh0LWxpbmstYWJicmV2aWF0ZWQiIGhyZWY9Im1h aWx0bzpKbWFwQGlldGYub3JnIj5KbWFwQGlldGYub3JnPC9hPg0KPGJyIGNsYXNzPSIiPg0KPGEg bW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ptYXAiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vam1hcDwvYT4NCjxiciBjbGFzcz0iIj4NCjwvYmxv Y2txdW90ZT4NCjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NCjwv YmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnIgY2xhc3M9IiI+DQpKbWFwIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1h aWx0bzpKbWFwQGlldGYub3JnIiBjbGFzcz0iIj5KbWFwQGlldGYub3JnPC9hPjxiciBjbGFzcz0i Ij4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vam1hcDxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_C88A669A21434FC281EF3C9A2CD5963Bapplecom_-- From nobody Mon Apr 10 00:44:05 2017 Return-Path: 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 958B612945D for ; Mon, 10 Apr 2017 00:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=WHRx9gEx; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=mcOLmMpw 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 Jz3QTeSFtrdA for ; Mon, 10 Apr 2017 00:44:02 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F97912945F for ; Mon, 10 Apr 2017 00:44:02 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id A4211208EE for ; Mon, 10 Apr 2017 03:44:01 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Mon, 10 Apr 2017 03:44:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=mK91LClBAcmnCJmdtCfrp3KSjyrgk zrEC+VWKWqE3L8=; b=WHRx9gExxbyQZWcjzqoSWh+n5okwQCXpVQfCHuGKKcRam SlKRG1gC0E1bT25V6m6eadGUw3ahSdlCxSPRfiTLoXXiEj686gVvhOopSbXR9bQH Soa2LHv3HFqrWvXYPG2wgMJBFmkj9S4dT9tDQoPLRzaVIY4F/uocPlhvryiac4ud KMf+XSQlpyQ9YVcFF2RO4+aa+wLUsAY0ZFSrB4sFIWe5mlXRJ25eGLALI2lMK3sU AY443FI/FT/FCZfa8C5jAKrFkoRkpO/nBA817bpInjUYS1yJ0Isx4Yb8VRahHh2u ua5JCflUwpnvVtVfXF1qqFexWaJvEM04i7VzZrsPw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=mK91LC lBAcmnCJmdtCfrp3KSjyrgkzrEC+VWKWqE3L8=; b=mcOLmMpwMAYvyjj8JCIR1p HFMV6FP7hrCC/auwIToUGpGn4p6MN32owtwpV+IC0YLgOSOujoaT9CNAyuTke+ey uS6LXe5Q4t23tvtnoJ+EdzWkeTMjEatuCW0xgfbSWHBhhf1oscgx4pnYm0+f1WeG rPP0J8Nbg13axlEL2BHuFmyBd8/j0CF4DD+EueLyGsC8+Dhx7DRuxM2ZGYGGiVox 5/x6HSSjME7l4RzhNzxQlTtv974DIYbG17ErtkhMO/ia/N37//7uWa9jVC9XT/Mu fM9aaUNbHCAelXgV5HYQfgqWYMG5ZJI/sQeyCHTBogGAPmqL+UWirK4Vfa6O5K8A == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 61956E23C7; Mon, 10 Apr 2017 03:44:01 -0400 (EDT) Message-Id: <1491810241.3519699.939632432.32581C91@webmail.messagingengine.com> From: Neil Jenkins To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_149181024135196991" X-Mailer: MessagingEngine.com Webmail Interface - ajax-c42a28aa References: <148716911729.17277.15371202023742081890.idtracker@ietfa.amsl.com> <9eb1fd3c-8868-9d24-6c30-46d333b69fef@isode.com> <3c1711a2-46dd-db1c-506e-5e1ad89ce56d@linagora.com> <92769755-62c6-7257-ce3d-7d0b5699735d@isode.com> <27c62cc8-68e0-49b5-4900-34c26d7b4c6a@linagora.com> In-Reply-To: Date: Mon, 10 Apr 2017 17:44:01 +1000 Archived-At: Subject: Re: [Jmap] Adding the Message::isForwarded property X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 07:44:04 -0000 This is a multi-part message in MIME format. --_----------=_149181024135196991 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Mon, 10 Apr 2017, at 10:08 AM, Neil Jhaveri wrote: > I seem to be on the minority side here, but I personally do see the > appeal in **isForwarded** being a first-class property. This is a core > part of many modern client UI's showing a list of messages. If I had > never used IMAP before, it would definitely seem weird and incongruent > to me that answered is a property, but forwarded is a keyword, This is a good point. From a pure conceptual view it *is* weird and inconsistent. > If there does end up being more support for this, I could see an > argument for drawing a line in the sand on the most important > keywords, and maybe upgrading $Junk/$NotJunk and $Phishing into first- > class properties too. Other keywords like $SubmitPending and > $Submitted seem to have their use cases handled quite differently in > JMAP with the Outbox concept, so could be left alone in a raw keywords > property. Yes, I think this is worth considering. It provides a better interface to this functionality. The main downside is when a new IANA keyword is registered, at first it would just appear in the keywords property. Then in the next JMAP spec version you would probably have it added as a message property (and therefore disappear from the keywords array), and so you would potentially need client code to handle both paths. Although, maybe not if the JMAP spec revision could happen reasonably quickly (and arguably it's a way of knowing the server does something with this flag, which is the whole point of them, so you never need to handle the keywords option). Neil. --_----------=_149181024135196991 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Mon, 10 Apr 2017, at 10:08 AM, Neil Jhaveri wrote:
I seem to be on the minority side here, but I personally do see the appeal in **isForwarded** being a first-class property. This is a core part of many modern client UI's showing a list of messages. If I had never used IMAP before, it would definitely seem weird and incongruent to me that answered is a property, but forwarded is a keyword,

This is a good point. From a pure conceptual view it is weird and inconsistent.

If there does end up being more support for this, I could see an argument for drawing a line in the sand on the most important keywords, and maybe upgrading $Junk/$NotJunk and $Phishing into first-class properties too. Other keywords like $SubmitPending and $Submitted seem to have their use cases handled quite differently in JMAP with the Outbox concept, so could be left alone in a raw keywords property.

Yes, I think this is worth considering. It provides a better interface to this functionality. The main downside is when a new IANA keyword is registered, at first it would just appear in the keywords property. Then in the next JMAP spec version you would probably have it added as a message property (and therefore disappear from the keywords array), and so you would potentially need client code to handle both paths. Although, maybe not if the JMAP spec revision could happen reasonably quickly (and arguably it's a way of knowing the server does something with this flag, which is the whole point of them, so you never need to handle the keywords option).

Neil.
--_----------=_149181024135196991-- From nobody Mon Apr 10 16:38:12 2017 Return-Path: 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 93847124C27 for ; Mon, 10 Apr 2017 16:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 98TQpETNL0Nj for ; Mon, 10 Apr 2017 16:38:09 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CA55128B93 for ; Mon, 10 Apr 2017 16:38:09 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v3ANc66c027560 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 10 Apr 2017 23:38:06 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v3ANc5XN015761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 10 Apr 2017 23:38:06 GMT Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v3ANc4X7018776; Mon, 10 Apr 2017 23:38:05 GMT Received: from [10.145.239.165] (/10.145.239.165) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 10 Apr 2017 16:38:04 -0700 From: "Chris Newman" To: "Neil Jhaveri" Cc: "Benoit Tellier" , "Alexey Melnikov" , "jmap@ietf.org" Date: Mon, 10 Apr 2017 16:38:02 -0700 Message-ID: In-Reply-To: References: <148716911729.17277.15371202023742081890.idtracker@ietfa.amsl.com> <9eb1fd3c-8868-9d24-6c30-46d333b69fef@isode.com> <3c1711a2-46dd-db1c-506e-5e1ad89ce56d@linagora.com> <92769755-62c6-7257-ce3d-7d0b5699735d@isode.com> <27c62cc8-68e0-49b5-4900-34c26d7b4c6a@linagora.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5347) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Subject: Re: [Jmap] Adding the Message::isForwarded property X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 23:38:11 -0000 On 9 Apr 2017, at 17:08, Neil Jhaveri wrote: > I seem to be on the minority side here, but I personally do see the > appeal in **isForwarded** being a first-class property. This is a core > part of many modern client UI's showing a list of messages. If I had > never used IMAP before, it would definitely seem weird and incongruent > to me that answered is a property, but forwarded is a keyword, and it > would probably cause some momentary confusion trying to figure out how > to know if a message was forwarded or not. System flags and keywords have largely identical syntax and behavior in the IMAP data model and are all searchable. So the fact that JMAP is introducing a special data model for system flags that's different from the syntax for keywords seems odd to me. Why can't JMAP treat all flags/keywords as peers in the data model; the way IMAP does? The only significant difference between flags and keywords in the IMAP base spec is that servers are not required to support keywords. One of the design flaws in IMAP is it's too permissive of server variations that make it harder to write clients. When the majority of deployed IMAP servers support a feature (providing support for a minimum number of extensible keywords being an example), I'm supportive of making JMAP require that feature. So adding a clause that requires JMAP servers to support at least X extensible keywords (maybe X=32 or X=64) is a change I would support. > If there does end up being more support for this, I could see an > argument for drawing a line in the sand on the most important > keywords, and maybe upgrading $Junk/$NotJunk and $Phishing into > first-class properties too. Other keywords like $SubmitPending and > $Submitted seem to have their use cases handled quite differently in > JMAP with the Outbox concept, so could be left alone in a raw keywords > property. From my viewpoint, differences between the IMAP data model and JMAP data model are added complexity to the email infrastructure unless there's a justification for making a change. So I'd prefer to leave the line between system flags and registered keywords where it is unless there's a compelling reason to change it. Otherwise we have to modify the keyword registry to distinguish ones that are treated differently in JMAP from IMAP. > I think it’s a stylistic question, though, and not a functional one. > Consensus so far seems to be against this, and I think either way is > probably fine, but I do personally support the more OOP-like > first-class property, where it makes sense and is cleaner to the > newcomer. The extensibility of a data model is one of the most important parts of a protocol's design. I consider JMAP severely deficient if its extensibility model for flags/keywords is inferior to the one in IMAP. I also consider JMAP deficient if it can't largely share the extension registries for IMAP keywords/metadata/annotations and the extension registry for the SMTP Submission protocol. - Chris From nobody Mon Apr 10 21:53:03 2017 Return-Path: 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 910F6127F0E for ; Mon, 10 Apr 2017 21:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.718 X-Spam-Level: X-Spam-Status: No, score=-2.718 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=yD90YnRT; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=EGgNLv6J 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 rMtrkC7v-J4h for ; Mon, 10 Apr 2017 21:53:00 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 020AE126B72 for ; Mon, 10 Apr 2017 21:52:59 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id 6878720B87 for ; Tue, 11 Apr 2017 00:52:59 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Tue, 11 Apr 2017 00:52:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=OW+8iY8I2v6H5dip5+wcg8GrHNW8T857sNgl0ab4Too=; b=yD90YnRT nnIwkw8WGEx493C3vsrVLQwi4x7A9ge5OPr9MvSvaj3sMDtiYYZ1dXvOmileIhyv yY3HkFXK2mtuHYQHtSm+2KD1mnzqL0lwFaWPSsIY6rAbz5lj9uePZA9/Q6l0H+u+ +v5omdVk04U/jOKa/TXJ7TTVE/hsy/9A4K6pHbo/pkpcCSQBUm0KcsKiUiGxX53f I/ondvBCE0BSS9xt+hv7IXWCKMfg5lZsMIPVZql8hasPVnQN/jb+xk5/ebsSuruz 75cXxltYfy56PcYj1rcarIvdypxxSBXROn15VM/4fVE+XJ+WgXTQuy/IBONTLDW5 3H1bHVcXy7CpIg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=OW+8iY8I2v6H5dip5+wcg8GrHNW8T 857sNgl0ab4Too=; b=EGgNLv6JUGB6AOgT/jMG7EvMgswbIZLot3nOLilVGaMkt 5yZPSl8mMW2Shb4FdG+1z3D4qKBHegcy2xlZAd+ChAufIDgxyPOXuODIfpOev0BJ vExzcVYLOI2pfBKWYE1tZ04HRdnybDeJIVoYEJBdlQUqvSt1Q5Rakad/c1mijLdQ juHSEY48+Iud2VFNeTsbaTiSsYe2X705jOSDr8RaG57bPFlwTMKe5vs5RnPs2pw9 OAyz4OcGmgmi7wYBcuq14NKCCiRvklEPrmaivYiuXUecrwa6c1I8MmEAICyp0uOa nXbkZZMrrt4/iETU2vHMrF0WIDvy8rVzSRU0SUA2Q== X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 21EFDE2597; Tue, 11 Apr 2017 00:52:59 -0400 (EDT) Message-Id: <1491886379.444171.940831720.06C71198@webmail.messagingengine.com> From: Neil Jenkins To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_14918863794441711" X-Mailer: MessagingEngine.com Webmail Interface - ajax-0492b2e2 Date: Tue, 11 Apr 2017 14:52:59 +1000 Archived-At: Subject: [Jmap] Push mechanism X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 04:53:01 -0000 This is a multi-part message in MIME format. --_----------=_14918863794441711 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" We talked a bit in Chicago about RFC 8030[1] and what mechanisms we should support for push. Having looked at RFC8030 in a bit more detail, the JMAP server is just the "Application Server" in this model (the other two participants are the "UA" and the "Push Server"). We should specify the behaviour such that it is compatible in this role, but not constrain it further. The Web Hook[2] part of the current draft of the JMAP spec basically already does this. I think we just need to add a few headers to the calls to the push server to make it compliant: TTL, Topic and Urgency. This is a very flexible mechanism then, as the Push Server is up to the UA. For example, the Apple iOS Mail.app would register the web hook with their push server which would then trigger an APNS notification (not RFC8030). Similarly an Android app would route the push via GCM. A webmail client might have a push server that uses the rest of RFC8030 to deliver the push messages. Does this sound reasonable to everyone? Neil. Links: 1. https://tools.ietf.org/html/rfc8030 2. http://jmap.io/spec-core.html#web-hook --_----------=_14918863794441711 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
We talked a bit in Chicago about RFC 8030 and what mechanisms we should support for push. Having looked at RFC8030 in a bit more detail, the JMAP server is just the "Application Server" in this model (the other two participants are the "UA" and the "Push Server"). We should specify the behaviour such that it is compatible in this role, but not constrain it further. The Web Hook part of the current draft of the JMAP spec basically already does this. I think we just need to add a few headers to the calls to the push server to make it compliant: TTL, Topic and Urgency.

This is a very flexible mechanism then, as the Push Server is up to the UA. For example, the Apple iOS Mail.app would register the web hook with their push server which would then trigger an APNS notification (not RFC8030). Similarly an Android app would route the push via GCM. A webmail client might have a push server that uses the rest of RFC8030 to deliver the push messages.

Does this sound reasonable to everyone?

Neil.
--_----------=_14918863794441711-- From nobody Tue Apr 11 11:10:24 2017 Return-Path: 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 D678C12EB78 for ; Tue, 11 Apr 2017 11:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.379 X-Spam-Level: X-Spam-Status: No, score=-4.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 rs_frK_pw3K1 for ; Tue, 11 Apr 2017 11:10:21 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F257129A92 for ; Tue, 11 Apr 2017 11:10:21 -0700 (PDT) Received: from pps.filterd (m0049458.ppops.net [127.0.0.1]) by m0049458.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v3BI9ZWi012971 for ; Tue, 11 Apr 2017 14:10:18 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049458.ppops.net-00191d01. with ESMTP id 29s45x01vk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 11 Apr 2017 14:09:55 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v3BI9rSP016534 for ; Tue, 11 Apr 2017 14:09:53 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v3BI9ldh016398 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 11 Apr 2017 14:09:51 -0400 Received: from MISOUT7MSGHUBAD.ITServices.sbc.com (MISOUT7MSGHUBAD.itservices.sbc.com [130.9.129.148]) by mlpi408.sfdc.sbc.com (RSA Interceptor) for ; Tue, 11 Apr 2017 18:09:35 GMT Received: from MISOUT7MSGUSRCG.ITServices.sbc.com ([169.254.7.103]) by MISOUT7MSGHUBAD.ITServices.sbc.com ([130.9.129.148]) with mapi id 14.03.0319.002; Tue, 11 Apr 2017 14:09:35 -0400 From: "HANSEN, TONY L" CC: "jmap@ietf.org" Thread-Topic: [Jmap] Adding the Message::isForwarded property Thread-Index: AQHSslOJ8Z+O7mXmikS/Qp3qOj/VGKHAeOQA Date: Tue, 11 Apr 2017 18:09:34 +0000 Message-ID: References: <148716911729.17277.15371202023742081890.idtracker@ietfa.amsl.com> <9eb1fd3c-8868-9d24-6c30-46d333b69fef@isode.com> <3c1711a2-46dd-db1c-506e-5e1ad89ce56d@linagora.com> <92769755-62c6-7257-ce3d-7d0b5699735d@isode.com> <27c62cc8-68e0-49b5-4900-34c26d7b4c6a@linagora.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.110.240.32] Content-Type: text/plain; charset="utf-8" Content-ID: <25E4B3238151E54EA2393D27779D61B2@LOCAL> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-11_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 lowpriorityscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1704110139 Archived-At: Subject: Re: [Jmap] Adding the Message::isForwarded property X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 18:10:23 -0000 SSBzdXBwb3J0IGV2ZXJ5dGhpbmcgdGhhdCBDaHJpcyBzYXlzIGhlcmUuDQoNCglUb255IEhhbnNl bg0KDQpPbiA0LzEwLzE3LCA3OjM4IFBNLCAiSm1hcCBvbiBiZWhhbGYgb2YgQ2hyaXMgTmV3bWFu IiA8am1hcC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBjaHJpcy5uZXdtYW5Ab3JhY2xl LmNvbT4gd3JvdGU6DQoNCiAgICBPbiA5IEFwciAyMDE3LCBhdCAxNzowOCwgTmVpbCBKaGF2ZXJp IHdyb3RlOg0KICAgID4gSSBzZWVtIHRvIGJlIG9uIHRoZSBtaW5vcml0eSBzaWRlIGhlcmUsIGJ1 dCBJIHBlcnNvbmFsbHkgZG8gc2VlIHRoZSANCiAgICA+IGFwcGVhbCBpbiAqKmlzRm9yd2FyZGVk KiogYmVpbmcgYSBmaXJzdC1jbGFzcyBwcm9wZXJ0eS4gVGhpcyBpcyBhIGNvcmUgDQogICAgPiBw YXJ0IG9mIG1hbnkgbW9kZXJuIGNsaWVudCBVSSdzIHNob3dpbmcgYSBsaXN0IG9mIG1lc3NhZ2Vz LiBJZiBJIGhhZCANCiAgICA+IG5ldmVyIHVzZWQgSU1BUCBiZWZvcmUsIGl0IHdvdWxkIGRlZmlu aXRlbHkgc2VlbSB3ZWlyZCBhbmQgaW5jb25ncnVlbnQgDQogICAgPiB0byBtZSB0aGF0IGFuc3dl cmVkIGlzIGEgcHJvcGVydHksIGJ1dCBmb3J3YXJkZWQgaXMgYSBrZXl3b3JkLCBhbmQgaXQgDQog ICAgPiB3b3VsZCBwcm9iYWJseSBjYXVzZSBzb21lIG1vbWVudGFyeSBjb25mdXNpb24gdHJ5aW5n IHRvIGZpZ3VyZSBvdXQgaG93IA0KICAgID4gdG8ga25vdyBpZiBhIG1lc3NhZ2Ugd2FzIGZvcndh cmRlZCBvciBub3QuDQogICAgDQogICAgU3lzdGVtIGZsYWdzIGFuZCBrZXl3b3JkcyBoYXZlIGxh cmdlbHkgaWRlbnRpY2FsIHN5bnRheCBhbmQgYmVoYXZpb3IgaW4gDQogICAgdGhlIElNQVAgZGF0 YSBtb2RlbCBhbmQgYXJlIGFsbCBzZWFyY2hhYmxlLg0KICAgIA0KICAgIFNvIHRoZSBmYWN0IHRo YXQgSk1BUCBpcyBpbnRyb2R1Y2luZyBhIHNwZWNpYWwgZGF0YSBtb2RlbCBmb3Igc3lzdGVtIA0K ICAgIGZsYWdzIHRoYXQncyBkaWZmZXJlbnQgZnJvbSB0aGUgc3ludGF4IGZvciBrZXl3b3JkcyBz ZWVtcyBvZGQgdG8gbWUuIFdoeSANCiAgICBjYW4ndCBKTUFQIHRyZWF0IGFsbCBmbGFncy9rZXl3 b3JkcyBhcyBwZWVycyBpbiB0aGUgZGF0YSBtb2RlbDsgdGhlIHdheSANCiAgICBJTUFQIGRvZXM/ DQogICAgDQogICAgVGhlIG9ubHkgc2lnbmlmaWNhbnQgZGlmZmVyZW5jZSBiZXR3ZWVuIGZsYWdz IGFuZCBrZXl3b3JkcyBpbiB0aGUgSU1BUCANCiAgICBiYXNlIHNwZWMgaXMgdGhhdCBzZXJ2ZXJz IGFyZSBub3QgcmVxdWlyZWQgdG8gc3VwcG9ydCBrZXl3b3Jkcy4gT25lIG9mIA0KICAgIHRoZSBk ZXNpZ24gZmxhd3MgaW4gSU1BUCBpcyBpdCdzIHRvbyBwZXJtaXNzaXZlIG9mIHNlcnZlciB2YXJp YXRpb25zIA0KICAgIHRoYXQgbWFrZSBpdCBoYXJkZXIgdG8gd3JpdGUgY2xpZW50cy4gV2hlbiB0 aGUgbWFqb3JpdHkgb2YgZGVwbG95ZWQgSU1BUCANCiAgICBzZXJ2ZXJzIHN1cHBvcnQgYSBmZWF0 dXJlIChwcm92aWRpbmcgc3VwcG9ydCBmb3IgYSBtaW5pbXVtIG51bWJlciBvZiANCiAgICBleHRl bnNpYmxlIGtleXdvcmRzIGJlaW5nIGFuIGV4YW1wbGUpLCBJJ20gc3VwcG9ydGl2ZSBvZiBtYWtp bmcgSk1BUCANCiAgICByZXF1aXJlIHRoYXQgZmVhdHVyZS4gU28gYWRkaW5nIGEgY2xhdXNlIHRo YXQgcmVxdWlyZXMgSk1BUCBzZXJ2ZXJzIHRvIA0KICAgIHN1cHBvcnQgYXQgbGVhc3QgWCBleHRl bnNpYmxlIGtleXdvcmRzIChtYXliZSBYPTMyIG9yIFg9NjQpIGlzIGEgY2hhbmdlIA0KICAgIEkg d291bGQgc3VwcG9ydC4NCiAgICANCiAgICA+IElmIHRoZXJlIGRvZXMgZW5kIHVwIGJlaW5nIG1v cmUgc3VwcG9ydCBmb3IgdGhpcywgSSBjb3VsZCBzZWUgYW4gDQogICAgPiBhcmd1bWVudCBmb3Ig ZHJhd2luZyBhIGxpbmUgaW4gdGhlIHNhbmQgb24gdGhlIG1vc3QgaW1wb3J0YW50IA0KICAgID4g a2V5d29yZHMsIGFuZCBtYXliZSB1cGdyYWRpbmcgJEp1bmsvJE5vdEp1bmsgYW5kICRQaGlzaGlu ZyBpbnRvIA0KICAgID4gZmlyc3QtY2xhc3MgcHJvcGVydGllcyB0b28uIE90aGVyIGtleXdvcmRz IGxpa2UgJFN1Ym1pdFBlbmRpbmcgYW5kIA0KICAgID4gJFN1Ym1pdHRlZCBzZWVtIHRvIGhhdmUg dGhlaXIgdXNlIGNhc2VzIGhhbmRsZWQgcXVpdGUgZGlmZmVyZW50bHkgaW4gDQogICAgPiBKTUFQ IHdpdGggdGhlIE91dGJveCBjb25jZXB0LCBzbyBjb3VsZCBiZSBsZWZ0IGFsb25lIGluIGEgcmF3 IGtleXdvcmRzIA0KICAgID4gcHJvcGVydHkuDQogICAgDQogICAgIEZyb20gbXkgdmlld3BvaW50 LCBkaWZmZXJlbmNlcyBiZXR3ZWVuIHRoZSBJTUFQIGRhdGEgbW9kZWwgYW5kIEpNQVAgDQogICAg ZGF0YSBtb2RlbCBhcmUgYWRkZWQgY29tcGxleGl0eSB0byB0aGUgZW1haWwgaW5mcmFzdHJ1Y3R1 cmUgdW5sZXNzIA0KICAgIHRoZXJlJ3MgYSBqdXN0aWZpY2F0aW9uIGZvciBtYWtpbmcgYSBjaGFu Z2UuIFNvIEknZCBwcmVmZXIgdG8gbGVhdmUgdGhlIA0KICAgIGxpbmUgYmV0d2VlbiBzeXN0ZW0g ZmxhZ3MgYW5kIHJlZ2lzdGVyZWQga2V5d29yZHMgd2hlcmUgaXQgaXMgdW5sZXNzIA0KICAgIHRo ZXJlJ3MgYSBjb21wZWxsaW5nIHJlYXNvbiB0byBjaGFuZ2UgaXQuIE90aGVyd2lzZSB3ZSBoYXZl IHRvIG1vZGlmeSANCiAgICB0aGUga2V5d29yZCByZWdpc3RyeSB0byBkaXN0aW5ndWlzaCBvbmVz IHRoYXQgYXJlIHRyZWF0ZWQgZGlmZmVyZW50bHkgaW4gDQogICAgSk1BUCBmcm9tIElNQVAuDQog ICAgDQogICAgPiBJIHRoaW5rIGl04oCZcyBhIHN0eWxpc3RpYyBxdWVzdGlvbiwgdGhvdWdoLCBh bmQgbm90IGEgZnVuY3Rpb25hbCBvbmUuIA0KICAgID4gQ29uc2Vuc3VzIHNvIGZhciBzZWVtcyB0 byBiZSBhZ2FpbnN0IHRoaXMsIGFuZCBJIHRoaW5rIGVpdGhlciB3YXkgaXMgDQogICAgPiBwcm9i YWJseSBmaW5lLCBidXQgSSBkbyBwZXJzb25hbGx5IHN1cHBvcnQgdGhlIG1vcmUgT09QLWxpa2Ug DQogICAgPiBmaXJzdC1jbGFzcyBwcm9wZXJ0eSwgd2hlcmUgaXQgbWFrZXMgc2Vuc2UgYW5kIGlz IGNsZWFuZXIgdG8gdGhlIA0KICAgID4gbmV3Y29tZXIuDQogICAgDQogICAgVGhlIGV4dGVuc2li aWxpdHkgb2YgYSBkYXRhIG1vZGVsIGlzIG9uZSBvZiB0aGUgbW9zdCBpbXBvcnRhbnQgcGFydHMg b2YgDQogICAgYSBwcm90b2NvbCdzIGRlc2lnbi4gSSBjb25zaWRlciBKTUFQIHNldmVyZWx5IGRl ZmljaWVudCBpZiBpdHMgDQogICAgZXh0ZW5zaWJpbGl0eSBtb2RlbCBmb3IgZmxhZ3Mva2V5d29y ZHMgaXMgaW5mZXJpb3IgdG8gdGhlIG9uZSBpbiBJTUFQLiBJIA0KICAgIGFsc28gY29uc2lkZXIg Sk1BUCBkZWZpY2llbnQgaWYgaXQgY2FuJ3QgbGFyZ2VseSBzaGFyZSB0aGUgZXh0ZW5zaW9uIA0K ICAgIHJlZ2lzdHJpZXMgZm9yIElNQVAga2V5d29yZHMvbWV0YWRhdGEvYW5ub3RhdGlvbnMgYW5k IHRoZSBleHRlbnNpb24gDQogICAgcmVnaXN0cnkgZm9yIHRoZSBTTVRQIFN1Ym1pc3Npb24gcHJv dG9jb2wuDQogICAgDQogICAgCQktIENocmlzDQoNCg== From andris.reinman@gmail.com Tue Apr 18 14:32:28 2017 Return-Path: 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 81C66127A97 for ; Tue, 18 Apr 2017 14:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 2dVTWNJcAcQX for ; Tue, 18 Apr 2017 14:32:27 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCE681293EE for ; Tue, 18 Apr 2017 14:32:26 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id t144so2918448lff.1 for ; Tue, 18 Apr 2017 14:32:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:date:subject:message-id :to; bh=eLbJJ1HrLhAsA6wiaegRx+vZ0y04HdyE1eA8dV+zOp0=; b=p1MC0nnqEekw2zZgtoKdIEquQECi+xK745BviKcdjzl2AeYFbv8lsFxsMRZO7YFi/u ZurHAbbJVx93K53XwBq/5HNAerzhKgilxYO0Xe9/InsI2SGrwMKU3Z2QqZxVB8Odiedy MlP0PdZZ2MDMf6jI+TUuymPuohKLbT1/6zMYp94uDwJIhZJEm6fLBmTCtF5WSBFQpee2 GGj8ObfAkR63b6ZVil3RZP3ydxN8PEaIShUl4fwrK6AeRih7uKLUFxBJC12jN/kZS/kp IsE64i08SSccW0li8DEeEvU0tRZhp27VSJDLTk/7WUQbK4lWIa33NK3Up86UyHfVKrbN J2Ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version:date :subject:message-id:to; bh=eLbJJ1HrLhAsA6wiaegRx+vZ0y04HdyE1eA8dV+zOp0=; b=iTeeFTzwjJEWA6fhTmRCAU+5LfrsmABQ7/NPU5qQt9xuvPDq+8LJazVpNZpbuIH2MA QllUtUDu1ihFXrQPea2Nut3iEyvJzU/bW16jWcCtzCZgt2VO8ZJxem3cXoOpzGypOMUK daCp9QviBc3UNHuePfPlQTBxInQy5pcbWg5aHuNUYrHKguAd3+okrpQDI4/3FqC4U3SM n4J4AlHgr4TT8abaKKFKmIbvgboDEWUQYFjS+MsmVId004q7nSiTPWWNHOSIQq4i0NRr 1rzVcGtPYKSzQ2xQjPJX4hcGCuXNcj/UiIDbWX/AP0rv3QLssc+JFqNOWMt7PmI3mugN jnNA== X-Gm-Message-State: AN3rC/5H5mf8AZHfK0eHc1aThM5IfSkL3EmBRQlNCwA7UOhV5MRaSYVM Iezq6n9LkIisITtlQEo= X-Received: by 10.46.7.17 with SMTP id 17mr5087842ljh.43.1492551144635; Tue, 18 Apr 2017 14:32:24 -0700 (PDT) Received: from ?IPv6:2001:7d0:83a0:7d80:1137:fa19:c188:7bc? (07bc-c188-fa19-1137-7d80-83a0-07d0-2001.dyn.estpak.ee. [2001:7d0:83a0:7d80:1137:fa19:c188:7bc]) by smtp.gmail.com with ESMTPSA id e30sm58542ljb.68.2017.04.18.14.32.23 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Apr 2017 14:32:23 -0700 (PDT) From: andris.reinman@gmail.com Content-Type: multipart/alternative; boundary=Apple-Mail-5269ADF3-45BB-4AE7-9213-32B85A7A2821 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Date: Wed, 19 Apr 2017 00:32:22 +0300 Message-Id: To: jmap@ietf.org X-Mailer: iPhone Mail (14E304) Archived-At: Subject: [Jmap] Prerequisites for implementing JMAP X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 21:35:08 -0000 --Apple-Mail-5269ADF3-45BB-4AE7-9213-32B85A7A2821 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi, I'm interested in adding JMAP support for my IMAP server called Wild Duck (h= ttps://github.com/wildduck-email/wildduck). Is there a list of prerequisites= that such a server should/must already support to implement JMAP? I mean so= mething like "you need CONDSTORE for modseq values, X for Y and Z for Q". So= far it is not so clear and I've had several surprises when going through th= e spec "oh, I need this thing too" Best regards, Andris Reinman= --Apple-Mail-5269ADF3-45BB-4AE7-9213-32B85A7A2821 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Hi,

I'm interested in adding JMAP support for my IMAP server called Wild Duck (https://github.com/wildduck-email/wildduck). Is there a list of prerequisites that such a server should/must already support to implement JMAP? I mean something like "you need CONDSTORE for modseq values, X for Y and Z for Q". So far it is not so clear and I've had several surprises when going through the spec "oh, I need this thing too"

Best regards,
Andris Reinman
--Apple-Mail-5269ADF3-45BB-4AE7-9213-32B85A7A2821-- From nobody Tue Apr 18 22:12:53 2017 Return-Path: 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 7B6A8126C83 for ; Tue, 18 Apr 2017 22:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=c8UZIM25; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=BrdkuwKC 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 iOF2GVAdfJ_d for ; Tue, 18 Apr 2017 22:12:51 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4CBF120724 for ; Tue, 18 Apr 2017 22:12:50 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id 4072E207A2 for ; Wed, 19 Apr 2017 01:12:50 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Wed, 19 Apr 2017 01:12:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=bgV53gUNCHFHCzXbcOdjcucbUPNam ihvRJi51B0yJqQ=; b=c8UZIM254sTz2Kqnj5SEyjum5Oi+ZajcnvjBlGlbFuHWx anSzHSiu2rwBPjva4IDnFdreE+Dn+OgW5TgYU8CdRg1JReUgnz+5nhoANTlYLh3Q B0kFJ1fPXtjMQRfhDCxTtVnRCOYSFEqNSjnqqmetOrBxm8x2lT9Tk5CS1acILjpf TDT3m0Rtg3fKh0eNT3oReFkZry6iybxFwRZOYgc7Brbrr6GYmXyhug9kEYn0CLaw j11UvzdkbFYrBQtBVOgNLbWTjF9b4TswC8DD2K6iVCjQDhIWp6JolZc4fU3hfw3r u9LNHy8Q5CoA5GJgAzIOKPK5BBN0TsrDvPNDqbNUg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=bgV53g UNCHFHCzXbcOdjcucbUPNamihvRJi51B0yJqQ=; b=BrdkuwKC4G7OPWwDvrodf+ Rz0VohqW9mnqAmHZTDkn7tCIgjsB4FppzTt+FA5Xcfxag5ou+t/2irDBkK/bZi3m pjoalwHK9H3zNRAoLg2Gutl4Dj+01Fb0MtylAotQQswvLOKB0122g3tDjfbdIxdK oAj4yXPiIJTgIlDLu1OSW+awHSo7RJSsUnSYplER7zDBSGhK+CRpqs8N2yoLwzqD AUBgQwty9GU3s9qzf9FhJ07sJLst/maR+wEI/khvZTrU4YhXy7gylWr9hxVAwjJK seq54wPrBR2+CrX0vz/Jwpxh3Xm+tWLHQyHoSOyz3plukZxdJe1rF3x7Lv5CgoIg == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id F2ADCE2597; Wed, 19 Apr 2017 01:12:49 -0400 (EDT) Message-Id: <1492578769.2998463.948881496.303A9C8D@webmail.messagingengine.com> From: Neil Jenkins To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_149257876929984631" X-Mailer: MessagingEngine.com Webmail Interface - ajax-aa3edb73 References: In-Reply-To: Date: Wed, 19 Apr 2017 15:12:49 +1000 Archived-At: Subject: Re: [Jmap] Prerequisites for implementing JMAP X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 05:12:52 -0000 This is a multi-part message in MIME format. --_----------=_149257876929984631 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Hi Andris, The JMAP spec is designed to be compatible with an IMAP backend (in that you can serve IMAP and JMAP interfaces to the same data), but is not defined in terms of IMAP so there's no exact set of IMAP extensions you *have* to support necessarily to support JMAP. For example, if you support CONDSTORE you will probably reuse the modseqs for doing getMessageListUpdates etc., but you don't *have* to. You could implement it with a transaction log instead for example, if you are not doing IMAP as well. As part of the charter, the JMAP WG intends to produce a document =E2=80=9Cdescribing how a dual IMAP and JMAP server implementation can be d= one=E2=80=9D, but work on this has not yet started. Neil. --_----------=_149257876929984631 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
Hi Andris,

The JMAP spec is designed to be compatible with an IMAP backend (in th= at you can serve IMAP and JMAP interfaces to the same data), but is not def= ined in terms of IMAP so there's no exact set of IMAP extensions you <= i>have to support necessarily to support JMAP. For example, if you supp= ort CONDSTORE you will probably reuse the modseqs for doing getMessageListU= pdates etc., but you don't have to. You could implement it with= a transaction log instead for example, if you are not doing IMAP as well.<= br>

As part of the charter, the JMAP WG intends to produce a document =E2= =80=9Cdescribing how a dual IMAP and JMAP server implementation can be done= =E2=80=9D, but work on this has not yet started.

Neil.
--_----------=_149257876929984631-- From nobody Tue Apr 18 22:21:21 2017 Return-Path: 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 18EF3131516 for ; Tue, 18 Apr 2017 22:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.718 X-Spam-Level: X-Spam-Status: No, score=-2.718 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=kadLM9PT; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=GEdsn44a 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 YTQ7Rghh10QF for ; Tue, 18 Apr 2017 22:21:18 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A33C131515 for ; Tue, 18 Apr 2017 22:21:18 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id DC02F2071A for ; Wed, 19 Apr 2017 01:21:17 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Wed, 19 Apr 2017 01:21:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=cIJt4RE4n0BcxcIepW5Re8jbYw+dz f3Ozj+fORP5ivg=; b=kadLM9PTwzhssXYEKOh8+WmhO5jJKlfHvmfeCWl9KLV56 +jZF/B5UVl91EUBr+a+UEfj7N9II6XRAHDQEoU5NC3B8t2BGqts3sx1Bv8EViGjn cjyxQl7jlsiDyR5/STTBeFyVVN6OLRverr7naJi8xp3zSFnqUlNV2a8H5leXi9jG R0/vUjMOI4YZyGG25cay8PZVfKkYUuv0f2LMjIMcnGJLDnnDvNE7tvqmrvXDWgrG OAEAD2eRUITAgabOXyaP9MrztJzaSD3gMEaAlO+U4e4v1CQex7493g4Nrv30ca25 VUVRkTL98khqL5znpJ1hPlTL1NBMGkiJWrxf2lEUw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=cIJt4R E4n0BcxcIepW5Re8jbYw+dzf3Ozj+fORP5ivg=; b=GEdsn44aNtslrDZkHUT4y3 kYkX7A1O5+TJPGGyKw5QumzqTBw05FCdm0aCToK6k63uQq+QGaQbUX+242k6TBlo +CljtHwtHBu73lN+1sr18gRevYipCYcualkU73Tloolc+fYYrxXbYGE0szvpYctv 4ZZZYU8JWrIWEzM2AZNpl21666t5eORCzBHaHOWIn5l3pCELtwIenuWsS1aLBGL0 WQ793aJV+aJ0jqpULQ7aH/4+vRF95ZjfZfnf7Z2h1i55jh1SbRcM/M8EJ8OH3weJ lFiCnqnL3iZk7qtRthVoo9EHiinM7E6zgPFwIaUYs0+xH9y3/RZSQBly6ZXWLeng == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id A10FCE2597; Wed, 19 Apr 2017 01:21:17 -0400 (EDT) Message-Id: <1492579277.2998458.948887296.01406185@webmail.messagingengine.com> From: Neil Jenkins To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_149257927729984580" X-Mailer: MessagingEngine.com Webmail Interface - ajax-aa3edb73 References: <1491886379.444171.940831720.06C71198@webmail.messagingengine.com> In-Reply-To: <1491886379.444171.940831720.06C71198@webmail.messagingengine.com> Date: Wed, 19 Apr 2017 15:21:17 +1000 Archived-At: Subject: Re: [Jmap] Push mechanism X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 05:21:20 -0000 This is a multi-part message in MIME format. --_----------=_149257927729984580 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Tue, 11 Apr 2017, at 02:52 PM, Neil Jenkins wrote: > We talked a bit in Chicago about RFC 8030[1] and what mechanisms we > should support for push. Having looked at RFC8030 in a bit more > detail, the JMAP server is just the "Application Server" in this model > (the other two participants are the "UA" and the "Push Server"). We > should specify the behaviour such that it is compatible in this role, > but not constrain it further. The Web Hook[2] part of the current > draft of the JMAP spec basically already does this. I think we just > need to add a few headers to the calls to the push server to make it > compliant: TTL, Topic and Urgency. Can I take the lack of argument about this as consensus that this is the right way forward? :) Neil. Links: 1. https://tools.ietf.org/html/rfc8030 2. http://jmap.io/spec-core.html#web-hook --_----------=_149257927729984580 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Tue, 11 Apr 2017, at 02:52 PM, Neil Jenkins wrote:
We talked a bit in Chicago about RFC 8030 and what mechanisms we should support for push. Having looked at RFC8030 in a bit more detail, the JMAP server is just the "Application Server" in this model (the other two participants are the "UA" and the "Push Server"). We should specify the behaviour such that it is compatible in this role, but not constrain it further. The Web Hook part of the current draft of the JMAP spec basically already does this. I think we just need to add a few headers to the calls to the push server to make it compliant: TTL, Topic and Urgency.

Can I take the lack of argument about this as consensus that this is the right way forward? :)

Neil.
--_----------=_149257927729984580-- From nobody Tue Apr 18 22:40:12 2017 Return-Path: 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 9C7061292D0 for ; Tue, 18 Apr 2017 22:40:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.178 X-Spam-Level: X-Spam-Status: No, score=-1.178 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 UfByA3PKf2y3 for ; Tue, 18 Apr 2017 22:40:09 -0700 (PDT) Received: from smtp.dovecot.fi (smtp.dovecot.fi [193.209.119.8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EE16120724 for ; Tue, 18 Apr 2017 22:40:09 -0700 (PDT) Received: from null (unknown [87.191.39.187]) by smtp.dovecot.fi (Halon) with ESMTPSA id a0b00443-24c2-11e7-8799-3d447e05304f; Wed, 19 Apr 2017 08:40:00 +0300 (EEST) Date: Wed, 19 Apr 2017 08:39:57 +0300 (EEST) From: Aki Tuomi To: jmap@ietf.org, Neil Jenkins Message-ID: <1594590924.2859.1492580398931@appsuite-dev.open-xchange.com> In-Reply-To: <1492579277.2998458.948887296.01406185@webmail.messagingengine.com> References: <1491886379.444171.940831720.06C71198@webmail.messagingengine.com> <1492579277.2998458.948887296.01406185@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v7.8.4-Rev1 X-Originating-Client: open-xchange-appsuite Archived-At: Subject: Re: [Jmap] Push mechanism X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 05:40:11 -0000


On April 19, 2017 at 8:21= AM Neil Jenkins wrote:


On Tue, 11 Apr 2017, at 02:52 PM, Neil J= enkins wrote:
We talked a bit in Chicago about RFC= 8030[1] and what mechanisms we
should support for push. Having looked a= t RFC8030 in a bit more
detail, the JMAP server is just the "Applica= tion Server" in this model
(the other two participants are the "= UA" and the "Push Server"). We
should specify the behaviour = such that it is compatible in this role,
but not constrain it further. T= he Web Hook[2] part of the current
draft of the JMAP spec basically alre= ady does this. I think we just
need to add a few headers to the calls to= the push server to make it
compliant: TTL, Topic and Urgency.Can I take the lack of argument about this as consensus that this is the=
right way forward? :)
Neil.

Fwiw, using existing stan= dard is a good idea. Had a quick look and it looked ok.

Aki

=20 From nobody Tue Apr 18 22:57:36 2017 Return-Path: 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 8034E13151E for ; Tue, 18 Apr 2017 22:57:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=lHoniWTX; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=bdUspQht 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 2i_oSFFTMH7G for ; Tue, 18 Apr 2017 22:57:33 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EA8F13151B for ; Tue, 18 Apr 2017 22:57:33 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id C8F2B20D3A for ; Wed, 19 Apr 2017 01:57:32 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Wed, 19 Apr 2017 01:57:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=Caa80RHfatnCqHivP/mltgeHuc8HQ YE9QOTaCFQDdQY=; b=lHoniWTXlIW4+365FzLlyrBeucm7bLc07HjBj1Lh+Kexr hKtseu8sg91J5dVBJ00ZOHNWe3/LdNF+K+/v0AdZGJV7h7fTwMxhBWLjdxdcNuQq l2xEBTeXObkOW4pWl7SbEdtbye8GeBau2JDY/51US8/JKFt564a3M+zlDdVcP0++ k9x77fzx1VR6WQKP1ZfhfyhN7wQ/31r+V6uwM9KljF8S4ujv4tOdJHt0SPlooWOc KzEVz9zugJ1f1XGItwHqH9SjvmdULhsrzRkOD/UUus2BJruWswosM7XiFpNGJtXQ EYjguVXdjK4l7vN+yCcfIDgTd1spA1zAkTA6N28ZQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=Caa80R HfatnCqHivP/mltgeHuc8HQYE9QOTaCFQDdQY=; b=bdUspQhtAMcZyiZr5kqHIK qfAAeMua8RI9gbYRsaIbmDCqCOC3Hbh5UhX37sbCMiwxkKOVM8GhS1eNoLFtVDey /qVYvSIqQjSho+8hwkKKHUN8p8GxyGZ057qkHJdSZBQa/8lOGoKgB0xim8V15rm4 ioGJbmGcoOFe7C3Eo4k7FDRgscnIM36GrIZILQTjcpyRIeq909GVZPl/oKKKPp+o 0T0d4WiYC4gmYNNQ4oGOlumm+pIwV47qGGlOtxn2rg1bpr8VHO0I0UXxAQhoSW1P b44g/KQxe5iY0xDCVaLV1s2Aff74D0lXXR18bJAhLWU5WmcXK5uJdE/t3soOHakA == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 8211CE2597; Wed, 19 Apr 2017 01:57:32 -0400 (EDT) Message-Id: <1492581452.3025596.948906456.71780673@webmail.messagingengine.com> From: Neil Jenkins To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_149258145230255960" X-Mailer: MessagingEngine.com Webmail Interface - ajax-aa3edb73 References: <148716911729.17277.15371202023742081890.idtracker@ietfa.amsl.com> <9eb1fd3c-8868-9d24-6c30-46d333b69fef@isode.com> <3c1711a2-46dd-db1c-506e-5e1ad89ce56d@linagora.com> <92769755-62c6-7257-ce3d-7d0b5699735d@isode.com> <27c62cc8-68e0-49b5-4900-34c26d7b4c6a@linagora.com> In-Reply-To: Date: Wed, 19 Apr 2017 15:57:32 +1000 Archived-At: Subject: Re: [Jmap] Adding the Message::isForwarded property X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 05:57:34 -0000 This is a multi-part message in MIME format. --_----------=_149258145230255960 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" The initial JMAP design was only interested in the system flags, so having the separate properties made sense. But given we want to add full support for custom IMAP flags (and reuse the IANA registry), I think having the system ones in a different format is going to end up causing pain down the line. We could make properties for the keywords currently in the IANA registry, but this would clearly cause headaches as more are standardised down the line. So I agree we should change to just a single "keywords" property, and reuse the keyword names from IMAP. This means we would remove the "isUnread", "isFlagged", "isAnswered" and "isDraft" properties from the Message object and introduce a single "keywords" property (with respectively "\Seen" (flipped meaning), "\Flagged", "\Answered" and "\Draft" keywords, as per IMAP). The main downside is I think is this is slightly less accessible for newcomers who haven't been exposed to IMAP, but this is probably outweighed by the benefits already discussed. Do we have consensus on this? The last few messages all seem to be in favour of making this change. If so, I'm happy to update the spec and call this issue closed. In terms of representation, do we agree on an Object type, with the keywords as the keys (and a boolean `true` as the value (as discussed in a previous email in this thread)? Neil. --_----------=_149258145230255960 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
The initial JMAP design was only interested in the system flags, so having the separate properties made sense. But given we want to add full support for custom IMAP flags (and reuse the IANA registry), I think having the system ones in a different format is going to end up causing pain down the line. We could make properties for the keywords currently in the IANA registry, but this would clearly cause headaches as more are standardised down the line. So I agree we should change to just a single "keywords" property, and reuse the keyword names from IMAP.

This means we would remove the "isUnread", "isFlagged", "isAnswered" and "isDraft" properties from the Message object and introduce a single "keywords" property (with respectively "\Seen" (flipped meaning), "\Flagged", "\Answered" and "\Draft" keywords, as per IMAP).

The main downside is I think is this is slightly less accessible for newcomers who haven't been exposed to IMAP, but this is probably outweighed by the benefits already discussed.

Do we have consensus on this? The last few messages all seem to be in favour of making this change. If so, I'm happy to update the spec and call this issue closed.

In terms of representation, do we agree on an Object type, with the keywords as the keys (and a boolean `true` as the value (as discussed in a previous email in this thread)?

Neil.
--_----------=_149258145230255960-- From nobody Tue Apr 18 23:20:29 2017 Return-Path: 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 709D8131508 for ; Tue, 18 Apr 2017 23:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 apnTp2FiObrR for ; Tue, 18 Apr 2017 23:20:21 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [122.56.26.1]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F94C129B16 for ; Tue, 18 Apr 2017 23:20:20 -0700 (PDT) Received: From [192.168.1.146] (unverified [192.168.1.146]) by SMTP Server [192.168.1.3] (WinGate SMTP Receiver v9.0.5 (Build 5926)) with SMTP id <0001022992@smtp.qbik.com>; Wed, 19 Apr 2017 18:20:16 +1200 From: "Adrien de Croy" To: "Neil Jenkins" , "jmap@ietf.org" Date: Wed, 19 Apr 2017 06:20:17 +0000 Message-Id: In-Reply-To: <1492581452.3025596.948906456.71780673@webmail.messagingengine.com> References: <148716911729.17277.15371202023742081890.idtracker@ietfa.amsl.com> <9eb1fd3c-8868-9d24-6c30-46d333b69fef@isode.com> <3c1711a2-46dd-db1c-506e-5e1ad89ce56d@linagora.com> <92769755-62c6-7257-ce3d-7d0b5699735d@isode.com> <27c62cc8-68e0-49b5-4900-34c26d7b4c6a@linagora.com> <1492581452.3025596.948906456.71780673@webmail.messagingengine.com> Reply-To: "Adrien de Croy" User-Agent: eM_Client/7.0.27943.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MB0104ADDE-63A1-42AE-9B90-9778AC670801" Archived-At: Subject: Re: [Jmap] Adding the Message::isForwarded property X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 06:20:26 -0000 --------=_MB0104ADDE-63A1-42AE-9B90-9778AC670801 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi one thing that has bugged me for a long time about IMAP is its basic=20 verbosity. We protocol log IMAP here, and the IMAP logs are a lot bigger than any=20 others even though a lot less work is done. Even trimming the completely redundant \ from the start of a flag=20 keyword would save a bunch of space and transfer bandwidth. Are we going to make any effort to make the JMAP more efficient or will=20 it be equally or even more bloated? Will there be a requirement for compression support? I don't know why we would stick with the same keywords for the flags as=20 IMAP uses. I wonder if any IMAP implementors are storing these flags in= =20 textual format anyway. We certainly aren't. Regards Adrien ------ Original Message ------ From: "Neil Jenkins" To: "jmap@ietf.org" Sent: 19/04/2017 5:57:32 PM Subject: Re: [Jmap] Adding the Message::isForwarded property >The initial JMAP design was only interested in the system flags, so=20 >having the separate properties made sense. But given we want to add=20 >full support for custom IMAP flags (and reuse the IANA registry), I=20 >think having the system ones in a different format is going to end up=20 >causing pain down the line. We could make properties for the keywords=20 >currently in the IANA registry, but this would clearly cause headaches=20 >as more are standardised down the line. So I agree we should change to=20 >just a single "keywords" property, and reuse the keyword names from=20 >IMAP. > >This means we would remove the "isUnread", "isFlagged", "isAnswered"=20 >and "isDraft" properties from the Message object and introduce a single= =20 >"keywords" property (with respectively "\Seen" (flipped meaning),=20 >"\Flagged", "\Answered" and "\Draft" keywords, as per IMAP). > >The main downside is I think is this is slightly less accessible for=20 >newcomers who haven't been exposed to IMAP, but this is probably=20 >outweighed by the benefits already discussed. > >Do we have consensus on this? The last few messages all seem to be in=20 >favour of making this change. If so, I'm happy to update the spec and=20 >call this issue closed. > >In terms of representation, do we agree on an Object type, with the=20 >keywords as the keys (and a boolean `true` as the value (as discussed=20 >in a previous email in this thread)? > >Neil. --------=_MB0104ADDE-63A1-42AE-9B90-9778AC670801 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi

one thing that= has bugged me for a long time about IMAP is its basic verbosity.

We protocol log IMAP here, and the IMAP logs are a lot= bigger than any others even though a lot less work is done.
Even trimming the completely redundant \ from the start of= a flag keyword would save a bunch of space and transfer bandwidth.

Are we going to make any effort to make the JMAP more= efficient or will it be equally or even more bloated?

Will there be a requirement for compression support?
I don't know why we would stick with the same keywords for= the flags as IMAP uses. =C2=A0I wonder if any IMAP implementors are storin= g these flags in textual format anyway. =C2=A0We certainly aren't.

Regards

Adrien

------ Original Message ------
From: "Neil Jenkins" <neilj@f= astmail.com>
To: "jmap@ietf.org" <jmap@ietf.org= >
Sent: 19/04/2017 5:57:32 PM
Subject: Re: [Jmap] Adding the Message::isForwarded property

The initial JMAP design was only interested in the system flags, so= having the separate properties made sense. But given we want to add full= support for custom IMAP flags (and reuse the IANA registry), I think havin= g the system ones in a different format is going to end up causing pain = down the line. We could make properties for the keywords currently in the= IANA registry, but this would clearly cause headaches as more are standard= ised down the line. So I agree we should change to just a single "keywords"= property, and reuse the keyword names from IMAP.

This means we would remove the "isUnread", "isFlagged", "isAnswered"= and "isDraft" properties from the Message object and introduce a single= "keywords" property (with respectively "\Seen" (flipped meaning), "\Flagge= d", "\Answered" and "\Draft" keywords, as per IMAP).

The main downside is I think is this is slightly less accessible for= newcomers who haven't been exposed to IMAP, but this is probably outweighe= d by the benefits already discussed.

Do we have consensus on this? The last few messages all seem to be = in favour of making this change. If so, I'm happy to update the spec and= call this issue closed.

In terms of representation, do we agree on an Object type, with the= keywords as the keys (and a boolean `true` as the value (as discussed in= a previous email in this thread)?

Neil.
--------=_MB0104ADDE-63A1-42AE-9B90-9778AC670801-- From nobody Tue Apr 18 23:40:16 2017 Return-Path: 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 3B10E13151E for ; Tue, 18 Apr 2017 23:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 t20lzCooSuUZ for ; Tue, 18 Apr 2017 23:40:11 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [122.56.26.1]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BA4013150E for ; Tue, 18 Apr 2017 23:40:10 -0700 (PDT) Received: From [192.168.1.146] (unverified [192.168.1.146]) by SMTP Server [192.168.1.3] (WinGate SMTP Receiver v9.0.5 (Build 5926)) with SMTP id <0001023000@smtp.qbik.com>; Wed, 19 Apr 2017 18:40:08 +1200 From: "Adrien de Croy" To: "jmap@ietf.org" Date: Wed, 19 Apr 2017 06:40:08 +0000 Message-Id: Reply-To: "Adrien de Croy" User-Agent: eM_Client/7.0.27943.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MBA61F7815-0D45-41E4-BEC7-8E477C306CA0" Archived-At: Subject: [Jmap] Submission X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 06:40:14 -0000 --------=_MBA61F7815-0D45-41E4-BEC7-8E477C306CA0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi I just looked through the specs for mail submission and couldn't find=20 where it's covered. In the "Message Submission" section in the jmap.io site it talks about=20 submission being merely a copy (move?) of a message (presumably from=20 drafts) to an outbox. Presumably after that it gets moved or copied to=20 the sent folder? Does this mean the server must parse the message to get SMTP envelope=20 information? There are all kinds of problems with that. As for the justifying discussion on the site about this also then=20 allowing support for "delayed sending" by way of the client setting the=20 date in the message (bad idea IMO, server should set message date,=20 client often has wrong date, or mis-matched to server date) in the=20 future which the client can then cancel, I think this is also several=20 bad ideas. * It gives the server the job of maintaining when to send the message * It requires the client and server clocks to be in synch * it delays the message (who ever wants to do this?) * opening a window to cancel the message before it's sent seems a bit=20 nonsensical / contrived to me sorry. A UA using this is just mainly=20 going to make itself useless for mail conversations by unnecessarily=20 delaying mail. So I think using "delayed send" as a justification for "copy to outbox"=20 submission falls over under scrutiny. I think submission should be a separate command so that the client can=20 specify needed envelope information independently of the message=20 content. Even if this were an additional option. E.g. just move it to=20 outbox if you want the server to try to obtain an envelope from the=20 message content, or specifically provide that data from the client. Otherwise list processors won't be able to use this, server will need to= =20 strip BCC etc etc. Adrien --------=_MBA61F7815-0D45-41E4-BEC7-8E477C306CA0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi

I just looked through the specs for mail subm= ission and couldn't find where it's covered.

In= the "Message Submission" section in the jmap.io site it talks about submis= sion being merely a copy (move?) of a message (presumably from drafts) to= an outbox. =C2=A0Presumably after that it gets moved or copied to the sent= folder?

Does this mean the server must parse= the message to get SMTP envelope information? =C2=A0There are all kinds= of problems with that.

As for the justifying= discussion on the site about this also then allowing support for "delayed= sending" by way of the client setting the date in the message (bad idea= IMO, server should set message date, client often has wrong date, or mis-m= atched to server date) in the future which the client can then cancel, I= think this is also several bad ideas.

* It give= s the server the job of maintaining when to send the message
*=C2=A0It requires the client and serve= r clocks to be in synch
*=C2=A0= it delays the message (who ever wants to do this?)
*=C2=A0opening a window to cancel the= message before it's sent seems a bit nonsensical / contrived to me sorry.= =C2=A0A UA using this is just mainly going to make itself useless for mail= conversations by unnecessarily delaying mail.

S= o I think using "delayed send" as a justification for "copy to outbox" subm= ission falls over under scrutiny.

I think submis= sion should be a separate command so that the client can specify needed = envelope information independently of the message content. =C2=A0Even if= this were an additional option. =C2=A0E.g. just move it to outbox if you= want the server to try to obtain an envelope from the message content, = or specifically provide that data from the client.

Otherwise list processors won't be able to use this, server will need= to strip BCC etc etc.

Adrien


--------=_MBA61F7815-0D45-41E4-BEC7-8E477C306CA0-- From nobody Tue Apr 18 23:51:17 2017 Return-Path: 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 0316D129474 for ; Tue, 18 Apr 2017 23:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=LnMYUEOW; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=f3zFMwYd 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 kvM6GRLhaX_I for ; Tue, 18 Apr 2017 23:51:14 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC840129438 for ; Tue, 18 Apr 2017 23:51:14 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id 2834E20A74; Wed, 19 Apr 2017 02:51:14 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Wed, 19 Apr 2017 02:51:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=5YasQh2UGEEOSoHuNFhT3yU1TMBlh gqvP9T881v3d6E=; b=LnMYUEOWBm3lwLBsmfq9HS5SXH5tDsXr0+JGbp9QH+p1N q5BlKaIK+T4wVVUAL71cVUs/8VCGQljKNELcKBF0ngb7zgyl54+XKEuNv9MS6g+a yaWCFuwMFNdrPuGH0qfqlKNO5mP7bQrwrSEJm+KUbAD5OXxg/3LCeZ69Q819agUp O2QCGnm3E2IIyh+tgrEKMAxHBoJcw7BKClYtou8uhwxkaGFDRPEn5DMVTOlCK1cP Ja2OP6YdFOrk+Eg+m26rp7+RG4IR/vbxC4s6FSQAumuFtwV+UKvwHsINfKfvkze1 KRZq1+4shkl56ANhuqg3ikVifG913pqZowb8wXWnQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=5YasQh 2UGEEOSoHuNFhT3yU1TMBlhgqvP9T881v3d6E=; b=f3zFMwYdfEnASOUYYrLNl4 nTVV06StdhQguGJjbztIz4dt/+C4wHxdO1jFtbXKaYHJ+EJymB+HpopvRJeWdc/M d7Mtwbnre1erG7RF3UG7ICAPyJOygWK04xHcLoGh7tVs3Et+w/oeF0tYdZP7aDDt QGiloD893tYUpHw71QyUlkiuzOwoRiicb95zmxq6nQcysTbAFQu9dKqJHdEqMX+a JqdBR7ar7EM61xcXKN/WrdGrQIL96woF5kkz0mhvvvsJTkJU1UxE2kkLvlc4w60m LW5va+vqFhjTupaN2RcAX1YUUa4qdOaOJfQMZZ4YcEwcezyODOCvrJ9UqT1VfmIw == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id D90A4E2796; Wed, 19 Apr 2017 02:51:13 -0400 (EDT) Message-Id: <1492584673.3068477.948935352.527C33EE@webmail.messagingengine.com> From: Neil Jenkins To: Adrien de Croy , jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_149258467330684775" X-Mailer: MessagingEngine.com Webmail Interface - ajax-aa3edb73 References: <148716911729.17277.15371202023742081890.idtracker@ietfa.amsl.com> <9eb1fd3c-8868-9d24-6c30-46d333b69fef@isode.com> <3c1711a2-46dd-db1c-506e-5e1ad89ce56d@linagora.com> <92769755-62c6-7257-ce3d-7d0b5699735d@isode.com> <27c62cc8-68e0-49b5-4900-34c26d7b4c6a@linagora.com> <1492581452.3025596.948906456.71780673@webmail.messagingengine.com> In-Reply-To: Date: Wed, 19 Apr 2017 16:51:13 +1000 Archived-At: Subject: Re: [Jmap] Adding the Message::isForwarded property X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 06:51:17 -0000 This is a multi-part message in MIME format. --_----------=_149258467330684775 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Wed, 19 Apr 2017, at 04:20 PM, Adrien de Croy wrote: > Even trimming the completely redundant \ from the start of a flag > keyword would save a bunch of space and transfer bandwidth. The main issue would be namespace conflicts. While it would be a very odd and confusing thing to do, someone may have defined an IMAP keyword called "Flagged" for example, so if you drop the \ from the beginning of system flags you could end up with a conflict between the system and user keyword names. > Will there be a requirement for compression support? Since it goes over HTTP, any standard compression supported by the HTTP server can be negotiated. I would expect all servers to support gzip at a minimum. This reduces the data size in responses from the server considerably, and effectively negates any difference between "\Flagged" and "Flagged". Neil. --_----------=_149258467330684775 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Wed, 19 Apr 2017, at 04:20 PM, Adrien de Croy wrote:
Even trimming the completely redundant \ from the start of a flag keyword would save a bunch of space and transfer bandwidth.

The main issue would be namespace conflicts. While it would be a very odd and confusing thing to do, someone may have defined an IMAP keyword called "Flagged" for example, so if you drop the \ from the beginning of system flags you could end up with a conflict between the system and user keyword names.

Will there be a requirement for compression support?

Since it goes over HTTP, any standard compression supported by the HTTP server can be negotiated. I would expect all servers to support gzip at a minimum. This reduces the data size in responses from the server considerably, and effectively negates any difference between "\Flagged" and "Flagged".

Neil.
--_----------=_149258467330684775-- From nobody Wed Apr 19 00:11:20 2017 Return-Path: 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 15F85131529 for ; Wed, 19 Apr 2017 00:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=PuCXBKvb; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=N+ZhxGQN 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 bKXNiNXKJKIz for ; Wed, 19 Apr 2017 00:11:17 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F832129438 for ; Wed, 19 Apr 2017 00:11:17 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id 68E6120D69 for ; Wed, 19 Apr 2017 03:11:16 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Wed, 19 Apr 2017 03:11:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=gYcR4ocldKn9jjg79qsmxxb1SGt3h na70eHBdcHU8oQ=; b=PuCXBKvbzCYbzLG5lfh3dyicJSAwwaf4DyU3xGmtzN/1v U/wib6rA/Xlt4c4Q+M+2pKNLHwGoVhYOT40egdeFlComRkoxyC5wd2THGpLXslf1 jZRNlaQdQndA7jsxAxkcNiIuLaUnU36WY9tk8Y5L3TpXC3uFqzXwSggiJOWdPf8/ OPmS4XNixRjdIk/KwYLJQvZxCbkTPGYdQJHJo/LmrHBzgGAzTkne/ji6PhxmYqWO VCpvJKz3RxTe6rhLV8ByRa5m1ZdKx9pas/eFQBWrTncAJhCQdrpPHFm320HVU6qj 3XhlY5S2oBny3/7W4rEraoGBd047+h7DGhnrijPZA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=gYcR4o cldKn9jjg79qsmxxb1SGt3hna70eHBdcHU8oQ=; b=N+ZhxGQNWB8QgRg1ePjUde EMhPgVFdxcHX9l6V+ztLBlo2kHJQQHU5fuo9/dp7Lz4f1HaXqUUl0z5RgnM6uVN9 qXU2tx2nku0OcDX8LIj6bnycXMQRtx6nmFgpotWrD6CX2LjVVCDUPlYN95K6PUh9 NCClerFqhh1JGc7yKPhGq1bHkXp7ewzern3QWs83IAPw4agVNXaJynK4PnX2j5aN i5Z3Cvyg5qDyPygcbg0NZT6X9ykElJqzZuIcEYUE6vbE06SrcGWzD7Y8jpE0tbqi tlsJ0pidJe0ZJJy53vKP/b2ewpEMSbjbXEYqkkjEkMv3FyGTk/VrRu1JpmLlCB3g == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 1C7EEE2796; Wed, 19 Apr 2017 03:11:16 -0400 (EDT) Message-Id: <1492585876.3100717.948941576.3168BAAE@webmail.messagingengine.com> From: Neil Jenkins To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_149258587631007170" X-Mailer: MessagingEngine.com Webmail Interface - ajax-aa3edb73 In-Reply-To: Date: Wed, 19 Apr 2017 17:11:16 +1000 References: Archived-At: Subject: Re: [Jmap] Submission X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 07:11:19 -0000 This is a multi-part message in MIME format. --_----------=_149258587631007170 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" Yes, the intention is the server will build the RFC5322 message, add and strip headers as appropriate and set the SMTP envelope information. After sending, the server moves the message from the Outbox to Sent, or deletes it and writes a new one if it adds in extra information (since the message is immutable with the same id). This covers everything normal email clients need to do. There are other niche use cases, but JMAP doesn't have to deal with everything. SMTP Submission will still exist, but this simplifies things in the overwhelmingly common case. > * It requires the client and server clocks to be in synch Almost every device these days uses NTP or equivalent to set their system clock. We have not observed significant clock skew issues with our client for years. > * it delays the message (who ever wants to do this?) You're joking, right? The ability to "undo send" is *enormously* popular. Being able to do this in a standardised way for desktop clients would be a huge win over the current situation. Normally you would use a window of something like 30 seconds in the future. Scheduled send is also moderately popular in a certain niche. > * opening a window to cancel the message before it's sent seems a bit > nonsensical / contrived to me sorry. A UA using this is just mainly > going to make itself useless for mail conversations by unnecessarily > delaying mail. The UA does not *have* to delay the send. It can omit setting an explicit date on the message, in which case the server will set the date to now(), and immediately send the message. But the ability to do so for clients that want to make use of this is very important. > I think submission should be a separate command so that the client can > specify needed envelope information independently of the message > content. Even if this were an additional option. The trouble is options increase complexity and testing requirements. The current spec does not *require* servers to support delayed send. The canDelaySend capability property lets clients know if it does. Servers that don't support it could even not have a real "outbox" folder but just a synthetic one as anything moved to it is sent immediately (or the move is rejected if the message is invalid). Neil. --_----------=_149258587631007170 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
Yes, the intention is the server will build the RFC5322 message, add and strip headers as appropriate and set the SMTP envelope information. After sending, the server moves the message from the Outbox to Sent, or deletes it and writes a new one if it adds in extra information (since the message is immutable with the same id). This covers everything normal email clients need to do. There are other niche use cases, but JMAP doesn't have to deal with everything. SMTP Submission will still exist, but this simplifies things in the overwhelmingly common case.

* It requires the client and server clocks to be in synch

Almost every device these days uses NTP or equivalent to set their system clock. We have not observed significant clock skew issues with our client for years.

* it delays the message (who ever wants to do this?)

You're joking, right? The ability to "undo send" is enormously popular. Being able to do this in a standardised way for desktop clients would be a huge win over the current situation. Normally you would use a window of something like 30 seconds in the future. Scheduled send is also moderately popular in a certain niche.

* opening a window to cancel the message before it's sent seems a bit nonsensical / contrived to me sorry.  A UA using this is just mainly going to make itself useless for mail conversations by unnecessarily delaying mail.

The UA does not have to delay the send. It can omit setting an explicit date on the message, in which case the server will set the date to now(), and immediately send the message. But the ability to do so for clients that want to make use of this is very important.

I think submission should be a separate command so that the client can specify needed envelope information independently of the message content.  Even if this were an additional option.

The trouble is options increase complexity and testing requirements. The current spec does not require servers to support delayed send. The canDelaySend capability property lets clients know if it does. Servers that don't support it could even not have a real "outbox" folder but just a synthetic one as anything moved to it is sent immediately (or the move is rejected if the message is invalid).

Neil.
--_----------=_149258587631007170-- From nobody Wed Apr 19 00:27:28 2017 Return-Path: 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 E4AAD131537 for ; Wed, 19 Apr 2017 00:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 oDNdfGoO__i2 for ; Wed, 19 Apr 2017 00:27:27 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id CA3B2131532 for ; Wed, 19 Apr 2017 00:27:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1492586844; d=isode.com; s=june2016; i=@isode.com; bh=UTK44ZGPCKn4qv92oROh1lTTFRm1UeGRjOQYQj0SBQM=; 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=wfkQAc9SpAolADDA01eYbm1GgWo+PmPCuhrtO5hQCD1++Ds5fHornRws9QoMD5flrQ4jj1 2lankncNhoruz45SVQ8171/sq6LRZjwpD0xX0mWxobcJ52dlNI3EVbIlaad6oO0m+QtT0w 7FbE7MOj2OX7XIIrlzRoWyMhcKr/sn8=; Received: from [10.1.127.18] ((unknown) [85.255.234.109]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 19 Apr 2017 08:27:24 +0100 X-SMTP-Protocol-Errors: NORDNS PIPELINING From: Alexey Melnikov X-Mailer: iPhone Mail (13G35) In-Reply-To: Date: Wed, 19 Apr 2017 08:42:35 +0100 Cc: "jmap@ietf.org" Message-Id: <6799E58E-E92D-45F3-A475-FBBD01CC8DED@isode.com> References: <148716911729.17277.15371202023742081890.idtracker@ietfa.amsl.com> <9eb1fd3c-8868-9d24-6c30-46d333b69fef@isode.com> <3c1711a2-46dd-db1c-506e-5e1ad89ce56d@linagora.com> <92769755-62c6-7257-ce3d-7d0b5699735d@isode.com> <27c62cc8-68e0-49b5-4900-34c26d7b4c6a@linagora.com> <1492581452.3025596.948906456.71780673@webmail.messagingengine.com> To: Adrien de Croy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Jmap] Adding the Message::isForwarded property X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 07:27:28 -0000 Hi, > On 19 Apr 2017, at 07:20, Adrien de Croy wrote: >=20 > I don't know why we would stick with the same keywords for the flags as IM= AP uses. I wonder if any IMAP implementors are storing these flags in textu= al format anyway. =20 If a server supports arbitrary IMAP keywords, it has to. Multiple implementa= tions do. > We certainly aren't. From nobody Wed Apr 19 01:31:36 2017 Return-Path: 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 1746E131572 for ; Wed, 19 Apr 2017 01:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 eXyQddvqggkn for ; Wed, 19 Apr 2017 01:31:32 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [122.56.26.1]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09685131574 for ; Wed, 19 Apr 2017 01:31:30 -0700 (PDT) Received: From [192.168.1.146] (unverified [192.168.1.146]) by SMTP Server [192.168.1.3] (WinGate SMTP Receiver v9.0.5 (Build 5926)) with SMTP id <0001023066@smtp.qbik.com>; Wed, 19 Apr 2017 20:31:27 +1200 From: "Adrien de Croy" To: "Neil Jenkins" , "jmap@ietf.org" Date: Wed, 19 Apr 2017 08:31:27 +0000 Message-Id: In-Reply-To: <1492585876.3100717.948941576.3168BAAE@webmail.messagingengine.com> References: <1492585876.3100717.948941576.3168BAAE@webmail.messagingengine.com> Reply-To: "Adrien de Croy" User-Agent: eM_Client/7.0.27943.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MB483AE999-08AB-4859-85CE-4B6D1552FCAC" Archived-At: Subject: Re: [Jmap] Submission X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 08:31:35 -0000 --------=_MB483AE999-08AB-4859-85CE-4B6D1552FCAC Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable OK on delayed send. NTP I wouldn't rely on. I still often see clock divergence. but frankly the server parsing the envelope out of the message seems=20 like a hack, which also limits options to a subset of what a sender can=20 do with SMTP. Surely it's simple to have a submit command which takes envelope=20 attributes. That way is deterministic. I agree about option hell, that's one thing I'd like to leave behind=20 with IMAP. But parsing messages, scraping an envelope, and stripping unwanted=20 headers seems fragile. A server failing to strip BCC headers leaks=20 private information. It's also a lot more work for the server, and no=20 real difference either way for the client. Adrien ------ Original Message ------ From: "Neil Jenkins" To: "jmap@ietf.org" Sent: 19/04/2017 7:11:16 PM Subject: Re: [Jmap] Submission >Yes, the intention is the server will build the RFC5322 message, add=20 >and strip headers as appropriate and set the SMTP envelope information.= =20 >After sending, the server moves the message from the Outbox to Sent, or= =20 >deletes it and writes a new one if it adds in extra information (since=20 >the message is immutable with the same id). This covers everything=20 >normal email clients need to do. There are other niche use cases, but=20 >JMAP doesn't have to deal with everything. SMTP Submission will still=20 >exist, but this simplifies things in the overwhelmingly common case. > >>* It requires the client and server clocks to be in synch > >Almost every device these days uses NTP or equivalent to set their=20 >system clock. We have not observed significant clock skew issues with=20 >our client for years. > >>* it delays the message (who ever wants to do this?) > >You're joking, right? The ability to "undo send" is enormously popular.= =20 >Being able to do this in a standardised way for desktop clients would=20 >be a huge win over the current situation. Normally you would use a=20 >window of something like 30 seconds in the future. Scheduled send is=20 >also moderately popular in a certain niche. > >>* opening a window to cancel the message before it's sent seems a bit=20 >>nonsensical / contrived to me sorry. A UA using this is just mainly=20 >>going to make itself useless for mail conversations by unnecessarily=20 >>delaying mail. > >The UA does not have to delay the send. It can omit setting an explicit= =20 >date on the message, in which case the server will set the date to=20 >now(), and immediately send the message. But the ability to do so for=20 >clients that want to make use of this is very important. > >>I think submission should be a separate command so that the client can= =20 >>specify needed envelope information independently of the message=20 >>content. Even if this were an additional option. > >The trouble is options increase complexity and testing requirements.=20 >The current spec does not require servers to support delayed send. The=20 >canDelaySend capability property lets clients know if it does. Servers=20 >that don't support it could even not have a real "outbox" folder but=20 >just a synthetic one as anything moved to it is sent immediately (or=20 >the move is rejected if the message is invalid). > >Neil. --------=_MB483AE999-08AB-4859-85CE-4B6D1552FCAC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

OK on delayed send.

= NTP I wouldn't rely on. =C2=A0I still often see clock divergence.

but frankly the server= parsing the envelope out of the message seems like a hack, which also limi= ts options to a subset of what a sender can do with SMTP.
=
Surely it's simple to have a submit command which takes= envelope attributes. =C2=A0That way is deterministic.

I agree about option hell, that's one thing I'd like to leave behind= with IMAP.

But parsing messages, scraping an= envelope, and stripping unwanted headers seems fragile. =C2=A0A server = failing to strip BCC headers leaks private information. =C2=A0It's also = a lot more work for the server, and no real difference either way for the= client.

Adrien



------ Original Message ------
From: "Neil Jenkins" <neilj@f= astmail.com>
To: "jmap@ietf.org" <jmap@ietf.org= >
Sent: 19/04/2017 7:11:16 PM
Subject: Re: [Jmap] Submission

Yes, the intention is the server will build the RFC5322 message, add= and strip headers as appropriate and set the SMTP envelope information.= After sending, the server moves the message=C2=A0from the Outbox to Sent,= or deletes it and writes a new one if it adds in extra information (since= the message is immutable with the same id). This covers everything normal= email clients need to do. There are other niche use cases, but JMAP doesn'= t have to deal with everything. SMTP Submission will still exist, but this= simplifies things in the overwhelmingly common case.

*=C2=A0It requires the client and server clocks= to be in synch

Almost every device these days uses NTP or equivalent to set their = system clock. We have not observed significant clock skew issues with our= client for years.

*=C2=A0it delays the message (who ever wants = to do this?)

You're joking, right? The ability to "undo send" is enormously= popular. Being able to do this in a standardised way for desktop clients= would be a huge win over the current situation. Normally you would use = a window of something like 30 seconds in the future. Scheduled send is also= moderately popular in a certain niche.

*=C2=A0opening a window to cancel the message= before it's sent seems a bit nonsensical / contrived to me sorry. =C2=A0= A UA using this is just mainly going to make itself useless for mail conver= sations by unnecessarily delaying mail.

The UA does not have to delay the send. It can omit setting = an explicit date on the message, in which case the server will set the date= to now(), and immediately send the message. But the ability to do so for= clients that want to make use of this is very important.

I think submission should = be a separate command so that the client can specify needed envelope inform= ation independently of the message content. =C2=A0Even if this were an addi= tional option.

The trouble is options increase complexity and testing requirements.= The current spec does not require servers to support delayed send.= The=C2=A0canDelaySend capability property lets clients know if it does.= Servers that don't support it could even not have a real "outbox" folder= but just a synthetic one as anything moved to it is sent immediately (or= the move is rejected if the message is invalid).

Neil.
--------=_MB483AE999-08AB-4859-85CE-4B6D1552FCAC-- From nobody Wed Apr 19 01:56:36 2017 Return-Path: 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 DDBD8131594 for ; Wed, 19 Apr 2017 01:56:33 -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 RVrPTA0-q11Y for ; Wed, 19 Apr 2017 01:56:31 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id A9516131585 for ; Wed, 19 Apr 2017 01:56:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1492592190; d=isode.com; s=june2016; i=@isode.com; bh=dE9vgbduREbT+ADyKWnzXQPi1pT4PdHfEkS1ku1olNI=; 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=KI+VRpt4Eb2AKAe4XOv91mPppBON16M/d4YB0BNGudzhYem0/kxHO2HU4c0E7Ra6y3EJE8 HuzVtYz7GiECZB8E0TNdOSLA8nJZ8iG8scWeV3GRRshzFtcEA5qiVQZyZNqBxrdbRxKaJd HV2iOy6t9RfxxrcOfQgpf1e4uel0C5s=; Received: from [10.1.127.18] ((unknown) [85.255.234.109]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 19 Apr 2017 09:56:30 +0100 X-SMTP-Protocol-Errors: NORDNS PIPELINING From: Alexey Melnikov X-Mailer: iPhone Mail (13G35) In-Reply-To: Date: Wed, 19 Apr 2017 10:11:42 +0100 Cc: Neil Jenkins , "jmap@ietf.org" Message-Id: <0D1582C6-5843-44EC-BDD0-DB484306B066@isode.com> References: <1492585876.3100717.948941576.3168BAAE@webmail.messagingengine.com> To: Adrien de Croy MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=Apple-Mail-661BB246-FF5B-4EA1-83FE-272D8FA55D18 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Jmap] Submission X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 08:56:34 -0000 --Apple-Mail-661BB246-FF5B-4EA1-83FE-272D8FA55D18 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi, > On 19 Apr 2017, at 09:31, Adrien de Croy wrote: >=20 >=20 > OK on delayed send. >=20 > NTP I wouldn't rely on. I still often see clock divergence. >=20 > but frankly the server parsing the envelope out of the message seems like a= hack, which also limits options to a subset of what a sender can do with SM= TP. >=20 > Surely it's simple to have a submit command which takes envelope attribute= s. That way is deterministic. Personally I don't care whether it is a separate command versa extra (possib= ly optional) parameters for envelope on an existing one. I think having parameters for envelope would be a good idea (and it would be= consistent with earlier discussions on Submit in IMAP.) But I am wondering i= f we can make common cases simple for clients by not requiring the parameter= s. > I agree about option hell, that's one thing I'd like to leave behind with I= MAP. >=20 > But parsing messages, scraping an envelope, and stripping unwanted headers= seems fragile. A server failing to strip BCC headers leaks private informa= tion. It's also a lot more work for the server, and no real difference eith= er way for the client. >=20 > Adrien >=20 >=20 >=20 >=20 > ------ Original Message ------ > From: "Neil Jenkins" > To: "jmap@ietf.org" > Sent: 19/04/2017 7:11:16 PM > Subject: Re: [Jmap] Submission >=20 >> Yes, the intention is the server will build the RFC5322 message, add and s= trip headers as appropriate and set the SMTP envelope information. After sen= ding, the server moves the message from the Outbox to Sent, or deletes it an= d writes a new one if it adds in extra information (since the message is imm= utable with the same id). This covers everything normal email clients need t= o do. There are other niche use cases, but JMAP doesn't have to deal with ev= erything. SMTP Submission will still exist, but this simplifies things in th= e overwhelmingly common case. >>=20 >>> * It requires the client and server clocks to be in synch >>=20 >> Almost every device these days uses NTP or equivalent to set their system= clock. We have not observed significant clock skew issues with our client f= or years. >>=20 >>> * it delays the message (who ever wants to do this?) >>=20 >> You're joking, right? The ability to "undo send" is enormously popular. B= eing able to do this in a standardised way for desktop clients would be a hu= ge win over the current situation. Normally you would use a window of someth= ing like 30 seconds in the future. Scheduled send is also moderately popular= in a certain niche. >>=20 >>> * opening a window to cancel the message before it's sent seems a bit no= nsensical / contrived to me sorry. A UA using this is just mainly going to m= ake itself useless for mail conversations by unnecessarily delaying mail. >>=20 >> The UA does not have to delay the send. It can omit setting an explicit d= ate on the message, in which case the server will set the date to now(), and= immediately send the message. But the ability to do so for clients that wan= t to make use of this is very important. >>=20 >>> I think submission should be a separate command so that the client can s= pecify needed envelope information independently of the message content. Ev= en if this were an additional option. >>=20 >> The trouble is options increase complexity and testing requirements. The c= urrent spec does not require servers to support delayed send. The canDelaySe= nd capability property lets clients know if it does. Servers that don't supp= ort it could even not have a real "outbox" folder but just a synthetic one a= s anything moved to it is sent immediately (or the move is rejected if the m= essage is invalid). >>=20 >> Neil. > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap --Apple-Mail-661BB246-FF5B-4EA1-83FE-272D8FA55D18 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi,

On 19 Apr 2017, at 0= 9:31, Adrien de Croy <adrien@qbik.com<= /a>> wrote:



Persona= lly I don't care whether it is a separate command versa extra (possibly opti= onal) parameters for envelope on an existing one.

I think having parameters= for envelope would be a good idea (and it would be consistent with earlier d= iscussions on Submit in IMAP.) But I am wondering if we can make common case= s simple for clients by not requiring the parameters.

<= blockquote type=3D"cite">
I agree about option hell, that's one thi= ng I'd like to leave behind with IMAP.

But parsing m= essages, scraping an envelope, and stripping unwanted headers seems fragile.=  A server failing to strip BCC headers leaks private information. &nbs= p;It's also a lot more work for the server, and no real difference either wa= y for the client.

Adrien




------ Original Message ------
Sent: 19/04/2017 7:11:16 PM
Subject: Re: [Jmap] Submission

Yes, the intention is the server will build the RFC5322 message, add an= d strip headers as appropriate and set the SMTP envelope information. After s= ending, the server moves the message from the Outbox to Sent, or delete= s it and writes a new one if it adds in extra information (since the message= is immutable with the same id). This covers everything normal email clients= need to do. There are other niche use cases, but JMAP doesn't have to deal w= ith everything. SMTP Submission will still exist, but this simplifies things= in the overwhelmingly common case.

* It requires the client and server clocks to be= in synch

Almost every device these days uses NTP or equivalent to set their syst= em clock. We have not observed significant clock skew issues with our client= for years.

* it delays the message (who ever wants to do th= is?)

You're joking, right? The ability to "undo send" is enormously p= opular. Being able to do this in a standardised way for desktop clients woul= d be a huge win over the current situation. Normally you would use a window o= f something like 30 seconds in the future. Scheduled send is also moderately= popular in a certain niche.

* opening a window to cancel the message before i= t's sent seems a bit nonsensical / contrived to me sorry.  A UA using t= his is just mainly going to make itself useless for mail conversations by un= necessarily delaying mail.

The UA does not have to delay the send. It can omit setting an e= xplicit date on the message, in which case the server will set the date to n= ow(), and immediately send the message. But the ability to do so for clients= that want to make use of this is very important.

I think submission should be a= separate command so that the client can specify needed envelope information= independently of the message content.  Even if this were an additional= option.

The trouble is options increase complexity and testing requirements. Th= e current spec does not require servers to support delayed send. The&= nbsp;canDelaySend capability property lets clients know if it does. Servers t= hat don't support it could even not have a real "outbox" folder but just a s= ynthetic one as anything moved to it is sent immediately (or the move is rej= ected if the message is invalid).

Neil.
____________________= ___________________________
Jmap mailing list
Jmap@ietf.org
https://www.ietf.org/mailman= /listinfo/jmap
= --Apple-Mail-661BB246-FF5B-4EA1-83FE-272D8FA55D18-- From nobody Wed Apr 19 04:14:31 2017 Return-Path: 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 A4D141294A6 for ; Wed, 19 Apr 2017 04:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gulbrandsen.priv.no 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 aNqHP5KxG7gX for ; Wed, 19 Apr 2017 04:14:29 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 332A1129489 for ; Wed, 19 Apr 2017 04:14:28 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 0160DFA0075; Wed, 19 Apr 2017 11:14:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1492600465; bh=ZBKe4plCQQWWJ2WDZGQfX6Z8u9u2V1Gcg6cXcEgzfRk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=GgnGpG57uNWfr+dUIaiU9XnJs0ACrDxiBOKgrxZJ6qO+jCBw1pDNJ2ZlER1ZxvhZU LT2cobKnwRxzCXa43gQDA3od4td16eBUV7vphfySIx/ah9zKhXUzuyV8l9zLgDyd5l kVXWx3bCYdw9sgRo19aI+cxQ6ncen9qQtq7bAQPc= Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1492600462-4383-4380/11/6; Wed, 19 Apr 2017 11:14:22 +0000 From: Arnt Gulbrandsen To: jmap@ietf.org Date: Wed, 19 Apr 2017 12:14:20 +0100 User-Agent: Trojita/v0.5-9-g8961725; Qt/4.8.6; X11; Linux; Devuan GNU/Linux 1.0 (jessie) Mime-Version: 1.0 Message-Id: <53a13457-c65a-43fc-8690-fb63c2624e26@gulbrandsen.priv.no> In-Reply-To: <1492585876.3100717.948941576.3168BAAE@webmail.messagingengine.com> References: <1492585876.3100717.948941576.3168BAAE@webmail.messagingengine.com> Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: Subject: Re: [Jmap] Submission X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 11:14:31 -0000 Neil Jenkins writes: > Scheduled send is also moderately popular in a certain > niche. Oh? That's very interesting. What niche? Arnt From nobody Wed Apr 19 04:28:40 2017 Return-Path: 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 394241294B7 for ; Wed, 19 Apr 2017 04:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gulbrandsen.priv.no 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 KolDE2fvsVet for ; Wed, 19 Apr 2017 04:28:37 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 286BD1294BE for ; Wed, 19 Apr 2017 04:28:36 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 0BBD9FA0075; Wed, 19 Apr 2017 11:28:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1492601314; bh=HshSav/bC+ziTobHedILIsFiSvCN2ZWEozihpE+MbiI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Z1K3HSl6frfGblJ0Zb8JZ6rs+ZJmJ/MBLIl2eAx0pCLNP+4mtGfVFTGRooieGltB/ zy4/Dww9Up1oJAev2qR6NayTr26VOprm9tn8NQ0qwFU9mKBPav6oCA3YiFD5unucZK DQK9BHqbzUx1xSoHH0br21VAiKSmqoyjE9r9guJQ= Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1492601312-4382-4380/11/1; Wed, 19 Apr 2017 11:28:32 +0000 From: Arnt Gulbrandsen To: jmap@ietf.org Date: Wed, 19 Apr 2017 12:28:31 +0100 User-Agent: Trojita/v0.5-9-g8961725; Qt/4.8.6; X11; Linux; Devuan GNU/Linux 1.0 (jessie) Mime-Version: 1.0 Message-Id: <7bf6ed88-9277-47fd-8059-1119987522bd@gulbrandsen.priv.no> In-Reply-To: References: <1492585876.3100717.948941576.3168BAAE@webmail.messagingengine.com> Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: Subject: Re: [Jmap] Submission X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 11:28:38 -0000 Adrien de Croy writes: > NTP I wouldn't rely on. I still often see clock divergence. A lot of phones get their time from the telco, whose base stations are very well synchronised with each other but not always with that place in Greenwich. But perhaps it's still reasonable to rely on correctness. If E-Plus is off (IIRC it was off by ~90 seconds when I was a customer) its customers either cannot undo send and/or can undo for 120 seconds rather than 30. Having that happen to a few people may be an acceptable price to pay for API simplicity. There are fewer than 1000 network operators, most of those <1000 clocks are correct to within a second or two, and the consequences of the errors seem minor. Arnt From nobody Wed Apr 19 04:38:52 2017 Return-Path: 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 C3AAC1294CE for ; Wed, 19 Apr 2017 04:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gulbrandsen.priv.no 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 dyzHshAhbWXy for ; Wed, 19 Apr 2017 04:38:49 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2D4B1294C7 for ; Wed, 19 Apr 2017 04:38:49 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id A8321FA0075; Wed, 19 Apr 2017 11:38:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1492601928; bh=ZgS6q2+1+iqF0DEDR/dZuYbo7kyjqxA5arrTMHcZP8c=; h=From:To:Subject:Date:In-Reply-To:References:From; b=NDrNUeIVerlxLa334l7aHt5vWKBocsZG0dyawL2eO1V6u2TRLQpZk5GDpAjwHyyPJ aUvaM/XVPNpstdVTnim6CJDBPnbAoKoMDrPwuceGZMvtgBBpLxXRiVcNtUZLTPwrPh Ha3uifYrXQ0v2moaNH4LKgHAvlTuGein4TL6g6/U= Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1492601925-4383-4380/11/7; Wed, 19 Apr 2017 11:38:45 +0000 From: Arnt Gulbrandsen To: jmap@ietf.org Date: Wed, 19 Apr 2017 12:38:41 +0100 User-Agent: Trojita/v0.5-9-g8961725; Qt/4.8.6; X11; Linux; Devuan GNU/Linux 1.0 (jessie) Mime-Version: 1.0 Message-Id: <55c3a20e-d813-4e73-a796-0e24dd7ec08f@gulbrandsen.priv.no> In-Reply-To: <7bf6ed88-9277-47fd-8059-1119987522bd@gulbrandsen.priv.no> References: <1492585876.3100717.948941576.3168BAAE@webmail.messagingengine.com> <7bf6ed88-9277-47fd-8059-1119987522bd@gulbrandsen.priv.no> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Jmap] Submission X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 11:38:51 -0000 I'd add a sentence saying that servers and clients are assumed to have=20 correct clocks within =C2=B13s, and that the authors have not paid = attention to=20 what might fail when a clock is off by more than that. Arnt From nobody Wed Apr 19 05:28:51 2017 Return-Path: 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 BAE6212951B for ; Wed, 19 Apr 2017 05:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com header.b=TMjxUPqb; dkim=neutral reason="invalid (public key: not available)" header.d=rjbs.manxome.org header.b=R0r91Rzq 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 RrZry4HY7jLL for ; Wed, 19 Apr 2017 05:28:49 -0700 (PDT) Received: from sasl.smtp.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E6BA127444 for ; Wed, 19 Apr 2017 05:28:48 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id EF39E88816; Wed, 19 Apr 2017 08:28:47 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=date:from:to :cc:subject:message-id:references:mime-version:content-type :in-reply-to; s=sasl; bh=YEeSk7rPgs1v3UI+Cjko2dQWQ5s=; b=TMjxUPq bxcNFUMlTBcyy4v/B74oPrKvhibx/ai/U/v/bErlRPDvuxFyDGyAWayHxwCEu3WV ioPVLlwUMMqOcsZ/+CqclOwLUEhVNH0B503O7GMb0gYhy5tKXK/WvBIi7z7o0+xE J/0eUqzhwh+aIkBnHFIgyvM1ZYjujvqN08J0= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id E5C9488815; Wed, 19 Apr 2017 08:28:47 -0400 (EDT) Received: from carpenter.manxome.org (unknown [45.33.15.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id 4552388814; Wed, 19 Apr 2017 08:28:47 -0400 (EDT) Received: by carpenter.manxome.org (Postfix, from userid 1000) id 445CF7DB20; Wed, 19 Apr 2017 08:28:46 -0400 (EDT) Date: Wed, 19 Apr 2017 08:28:46 -0400 From: Ricardo Signes To: Alexey Melnikov Cc: Adrien de Croy , "jmap@ietf.org" , Neil Jenkins Message-ID: <20170419122846.GA9764@debian> References: <1492585876.3100717.948941576.3168BAAE@webmail.messagingengine.com> <0D1582C6-5843-44EC-BDD0-DB484306B066@isode.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EeQfGwPcQSOJBaQU" Content-Disposition: inline In-Reply-To: <0D1582C6-5843-44EC-BDD0-DB484306B066@isode.com> X-Message-Flag: Warning: Your computer is current broadcasting an IP address. X-Planet: Planet of the Apes User-Agent: Mutt/1.5.23 (2014-03-12) X-Pobox-Relay-ID: BC52097A-24FB-11E7-9240-C260AE2156B6-07314517!pb-smtp2.pobox.com DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=rjbs.manxome.org; h=date:from:to:cc:subject:message-id:references:mime-version:content-type:in-reply-to; s=mesmtp; bh=YEeSk7rPgs1v3UI+Cjko2dQWQ5s=; b=R0r91Rzq/IpFNUVWGIR7JE7WuQOmzBcU1mtSxlrYoyQBEsnNeafD0JJl+/U7V7aInK8/Y8m4i0/LOkd5JHJM7MoIS12h9HJ0L/+7NoqTsECAu0Bri5f+tK8jgwscqhgU6YPY/dyQapRn6uapXDliaC38e6DcOmcVAGg082sGn8I= Archived-At: Subject: Re: [Jmap] Submission X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 12:28:51 -0000 --EeQfGwPcQSOJBaQU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Alexey Melnikov [2017-04-19T05:11:42] > I think having parameters for envelope would be a good idea (and it would= be > consistent with earlier discussions on Submit in IMAP.) But I am wonderin= g if > we can make common cases simple for clients by not requiring the paramete= rs. We discussed envelope parameters at IETF 98, and I hope that we do continue forward by making them both possible and optional. --=20 rjbs --EeQfGwPcQSOJBaQU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJY91f+AAoJEOYby6cMccU5bHsIAMO/msowwzq71pt6iYZopvj7 lXvYrt43XqA/O4FDHXk6Y9Q1b9ppYnF92tZrygiXFp599NyBEKnK4OFcF3+RONgr 32I4nbT/hlErXL+dEY6XlBSlqRskxa+jugz70aujO9DK2rfLklS53eaXG+bdnCXD VEOfnc1eg8Uxjs5YuVOP/tmxNINW+l5aB0dMYhLEBStQIB2qdc6Rkj5beEe116dz Cyx2BpEqoebn1damjQZOv0SCB6LXprLliZmvmAw4FiT8c/ATD8C3mj6RStbW55Mt mygXjvwt3A/oxS5JK3hDXrUmmJG3B4b9wJjxlCkIM0DQhWrw5T7VoMOjFw8E3+8= =x0/6 -----END PGP SIGNATURE----- --EeQfGwPcQSOJBaQU-- From nobody Wed Apr 19 06:45:11 2017 Return-Path: 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 3CF61129687 for ; Wed, 19 Apr 2017 06:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=0irndoeQ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=B4Su4dXM 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 2bKpXD8mJWue for ; Wed, 19 Apr 2017 06:45:08 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEDF5129543 for ; Wed, 19 Apr 2017 06:45:08 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 3809620C57 for ; Wed, 19 Apr 2017 09:45:08 -0400 (EDT) Received: from web4 ([10.202.2.214]) by compute6.internal (MEProxy); Wed, 19 Apr 2017 09:45:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=ZcdK3CzxTPZac1Ws+o2B7gIrF8/25f0Ka1B8xgWjyU8=; b=0irndoeQ KBUZVAlMvGDSofAp4nYNwj9G1c5rb9S6uGdxPWLJQ75LJoFDN4Y1BZuACN9TBd7B XlTEZG3QChb7rAoPooiXtIftjDb8t6xQF9YvnxBy7K+tjwJsCRXYIZZAc0jEqb1S hJqwbzmMj5BSG8juVS9DxROstGiZZ0bXRJcmEisqzvAGTliX+sRPut+aedFNWd+i DJjfcEqGSpBT1/rfvwykV5sCHkAQIDCaUY0CGRTipNad96Ul6gbUjvrBxFTsT+Nx GhVUrYkTnTKvDpg5OkNmuhOmVbHxdLrkaatN/eQyXKpPtaWDhZrQwuoV8oQE0BW7 W60hnaDLkI6frw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=ZcdK3CzxTPZac1Ws+o2B7gIrF8/25 f0Ka1B8xgWjyU8=; b=B4Su4dXMUVDuH2pBZ9IT8BmJ2hOglkmdVTW7dK9cGAEGD ERJEgDxgiD9zcIBHC43eO+s3/HLgbZOJ4rYZQXZJbvmDSw3KzdsQa3sbth6rJGGo yiincZP0DbsYDu/hYOH8E0ZHesHzHdWp9J1p4dQYy7toPZEbZXE5HEdfvKNdVJUJ DbR1rqk/DujJ5HwMoAOWH/GsyKxZNw9y1PKgh8sRqTdWGYBAtTsGFnaa665akoFJ QxQ3NjNtdPn2ozDwwTF/cSmfIbt3ZJb6/dA8USw2fDpBX2F2wqkaf0u46C5PlmGC Tlvu88c3KgneWyOrSgwUfqzxnqV/a3sJepC8LF8VQ== X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 158DFBAB6E; Wed, 19 Apr 2017 09:45:08 -0400 (EDT) Message-Id: <1492609508.3506279.949306664.3C8FB3E5@webmail.messagingengine.com> From: Bron Gondwana To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-ca85a2ec Date: Wed, 19 Apr 2017 23:45:08 +1000 Archived-At: Subject: [Jmap] Meeting minutes uploaded X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 13:45:10 -0000 Sorry for the delay on these! I got busy doing other things. I appear to have managed to work datatracker, but here's a copy for those of you who prefer to just read email. --- # JMAP 2017-03-30 ## notes from Joe Hildebrand, minute taker Actions * Neil Jenkins and Dave Crocker offered to co-edit * Alexey will edit the mapping to IMAP later * Create wiki page on github for implementation experience * Do not preclude e2e encryption * Consider protocol suite approach (cf. https://xmpp.org/extensions/xep-0387.html and http://caniuse.com/) * Discuss EAI * Make sure to check HTTP semantics, particularly after finishing the HTTP/2 decision Notes: * There is no adequate description of the IMAP data model ## notes from Bron Gondwana, co-chair * Neil Jhaveri also offered to co-edit one of the documents * discussion to happen on the mailing list, with issues also tracked in github --- Neil Jh is still waiting on legal clearance to work on this (yay big companies) but Neil Je and Dave Crocker are already working on the Core document, and Neil Je has started work on ways to map IANA and non-standard IMAP keywords into the mail data model. Once we have rough consensus on each change, I'll be either adding support to my couple of servers (JMAP Proxy and Cyrus IMAPd) or getting someone else to do it (my job consists more of talking to people and less of coding these days) so we can make sure it works in practice. Running code! Cheers, Bron. -- Bron Gondwana brong@fastmail.fm From nobody Wed Apr 19 06:51:37 2017 Return-Path: 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 1F80E129553 for ; Wed, 19 Apr 2017 06:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 lpa-ZlWWPAN5 for ; Wed, 19 Apr 2017 06:51:34 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id 979921274D0 for ; Wed, 19 Apr 2017 06:51:34 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id B60FCF997; Wed, 19 Apr 2017 09:51:33 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 1D6CE206AF; Wed, 19 Apr 2017 09:49:58 -0400 (EDT) From: Daniel Kahn Gillmor To: Ricardo Signes , Alexey Melnikov Cc: Adrien de Croy , "jmap\@ietf.org" , Neil Jenkins In-Reply-To: <20170419122846.GA9764@debian> References: <1492585876.3100717.948941576.3168BAAE@webmail.messagingengine.com> <0D1582C6-5843-44EC-BDD0-DB484306B066@isode.com> <20170419122846.GA9764@debian> Date: Wed, 19 Apr 2017 09:49:54 -0400 Message-ID: <87wpag7bi5.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [Jmap] Submission X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 13:51:36 -0000 --=-=-= Content-Type: text/plain On Wed 2017-04-19 08:28:46 -0400, Ricardo Signes wrote: > * Alexey Melnikov [2017-04-19T05:11:42] >> I think having parameters for envelope would be a good idea (and it would be >> consistent with earlier discussions on Submit in IMAP.) But I am wondering if >> we can make common cases simple for clients by not requiring the parameters. > > We discussed envelope parameters at IETF 98, and I hope that we do continue > forward by making them both possible and optional. I somehow missed that discussion at IETF 98, but i want to say that i think that envelope parameters during submission is an important feature. MUAs that want their RFC5322 message to go out exactly as they composed it, but using an arbitrary SMTP envelope should be able to exercise that level of control via JMAP, without worrying that the server side is going to parse, interpret, rearrange, or mangle the standard in-message headers. Regarding one common mismatch between SMTP envelope and RFC5322 mail headers: I think that encouraging an MUA to include an explicit, in-band Bcc: header in a message that it hands off to a server for delivery is asking for trouble. Making the SMTP envelope parameters "optional" needs more specification. For who are they optional? how? optional for JMAP servers to implement? optional for JMAP servers to accept? optional for JMAP clients to include? optional for JMAP clients to implement? My preference (for simplicity, omitting the explicit mechanism and just calling it "submission"): * JMAP servers MUST accept SMTP envelope parameters via the submission mechanism * JMAP clients MAY decline to provide SMTP envelope parameters when invoking the submission mechanism, in which case the JMAP server will synthesize SMTP envelope parameters from the submitted message. * synthesis of SMTP envelope headers at submission time by the JMAP server should leave the message otherwise unchanged. * delayed send should be implemented as an explicit envelope parameter, not as a parsing of the in-band Date: header. There are a range of reasons why an MUA might want to submit a message with a in-band Date: that the server finds objectionable (including server-side clock failure). Regards, --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEOCdgUepHf6PklTkyFJitxsGSMjcFAlj3awIACgkQFJitxsGS Mjc45Q//RY6GZUfK5JRtfxF3pw9kxd4YEeuNvkfPwv6W3XI85ISHqMaUC19YJNwb PLekpu7OV7shYm5aR+JtowB3iRIBt/puNOq4sptHkGGVxUxpeZFG22VShPACqcj2 aTARW757ctztzHZqMXwlPDJZeHoB8/75j8PJTb3bxhDOAn/y9JPc7aVH17Azo7QE +luZCUF2J0p7E/a6k4vRGOWTB3sXQ9QluV1EnRGqNP0o++tPRhrTHQ444ed/P3Z0 mALfxxeDg03US333WOarq4idHRKtd4V/T/92NLo6KAO/HpUFN8hcqNIs2bSFOCHR CtNjLKlZYRQFepd5zh8ozi29Sl0kca1uPaN6mOpCag0GZIlWSHFIhzNnLPxanZRl bRBnG9/EEhyzfXYi11/r+HxMGEqe+5u81agp5krAqiwue+VnzhEDPc9Ww3yfmuu2 2NqUAxZ6WSCdFaeoFXxVkB6VALrIwJH8nPlY8z4VzN9dm8oxVzxGhV8a3dEFglcn KtXA5iL2SGMBnJLANJ+qSG8nAufCPoMKUPvwGw5xmiu72QY3QKaGZI7unorK0Tjd h8q03XO5RrB8dfnUdTqgTSBtj7wbihkyaJClkBzJoYH8pJFn7x5VQve8w8wfYo8R x5rvYrYfEwSKEe2zonP1iOyKLm4UtwCyfD6Z3WagmdvQuUIzOlw= =VDaY -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Apr 19 08:39:22 2017 Return-Path: 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 CC164129B13 for ; Wed, 19 Apr 2017 08:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 AiDN30s3tmz5 for ; Wed, 19 Apr 2017 08:39:19 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 75E0C129B0F for ; Wed, 19 Apr 2017 08:39:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1492616358; d=isode.com; s=june2016; i=@isode.com; bh=jBmMEgwGIYujwyoFp1Jm8VxOWYBXA3ZIY/K8vGfjEH0=; 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=bKhUdhFdGI8crByz5Mis8kNnZs1Yec9zTSmtNYWutYqVvPbNkx1Pr2f4jupFkCj+mldHK2 sHeTmfHR+wunR9pd4gllMVaodMIfOCY9nNoEF3AJp7waxA8PzLumoNqbZgkFJ5ipHaGBkS 0KZWRSRvOBQPlJj8faGRAeS1cFYiw0g=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 19 Apr 2017 16:39:18 +0100 To: Daniel Kahn Gillmor References: <1492585876.3100717.948941576.3168BAAE@webmail.messagingengine.com> <0D1582C6-5843-44EC-BDD0-DB484306B066@isode.com> <20170419122846.GA9764@debian> <87wpag7bi5.fsf@fifthhorseman.net> Cc: "jmap@ietf.org" From: Alexey Melnikov Message-ID: Date: Wed, 19 Apr 2017 16:39:02 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 In-Reply-To: <87wpag7bi5.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Jmap] Submission X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 15:39:21 -0000 Hi, On 19/04/2017 14:49, Daniel Kahn Gillmor wrote: > On Wed 2017-04-19 08:28:46 -0400, Ricardo Signes wrote: >> * Alexey Melnikov [2017-04-19T05:11:42] >>> I think having parameters for envelope would be a good idea (and it would be >>> consistent with earlier discussions on Submit in IMAP.) But I am wondering if >>> we can make common cases simple for clients by not requiring the parameters. >> We discussed envelope parameters at IETF 98, and I hope that we do continue >> forward by making them both possible and optional. > I somehow missed that discussion at IETF 98, but i want to say that i > think that envelope parameters during submission is an important > feature. MUAs that want their RFC5322 message to go out exactly as they > composed it, but using an arbitrary SMTP envelope should be able to > exercise that level of control via JMAP, without worrying that the > server side is going to parse, interpret, rearrange, or mangle the > standard in-message headers. > > Regarding one common mismatch between SMTP envelope and RFC5322 mail > headers: > > I think that encouraging an MUA to include an explicit, in-band > Bcc: header in a message that it hands off to a server for delivery is > asking for trouble. > > > > Making the SMTP envelope parameters "optional" needs more specification. > For who are they optional? how? optional for JMAP servers to > implement? optional for JMAP servers to accept? optional for JMAP > clients to include? optional for JMAP clients to implement? I meant the last two. > My preference (for simplicity, omitting the explicit mechanism and just > calling it "submission"): > > * JMAP servers MUST accept SMTP envelope parameters via the submission > mechanism > > * JMAP clients MAY decline to provide SMTP envelope parameters when > invoking the submission mechanism, in which case the JMAP server will > synthesize SMTP envelope parameters from the submitted message. > > * synthesis of SMTP envelope headers at submission time by the JMAP > server should leave the message otherwise unchanged. > > * delayed send should be implemented as an explicit envelope parameter, > not as a parsing of the in-band Date: header. There are a range of > reasons why an MUA might want to submit a message with a in-band > Date: that the server finds objectionable (including server-side > clock failure). +1. From nobody Wed Apr 19 09:37:47 2017 Return-Path: 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 19A61129B2E for ; Wed, 19 Apr 2017 09:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.227 X-Spam-Level: X-Spam-Status: No, score=0.227 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 00roYbvyB1pv for ; Wed, 19 Apr 2017 09:34:53 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB4D1129B2A for ; Wed, 19 Apr 2017 09:34:52 -0700 (PDT) Received: (qmail 53265 invoked from network); 19 Apr 2017 16:34:51 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 19 Apr 2017 16:34:51 -0000 Date: 19 Apr 2017 16:34:29 -0000 Message-ID: <20170419163429.8556.qmail@ary.lan> From: "John Levine" To: jmap@ietf.org Cc: dkg@fifthhorseman.net In-Reply-To: <87wpag7bi5.fsf@fifthhorseman.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: X-Mailman-Approved-At: Wed, 19 Apr 2017 09:37:46 -0700 Subject: Re: [Jmap] Submission X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 16:34:54 -0000 In article <87wpag7bi5.fsf@fifthhorseman.net> you write: >Making the SMTP envelope parameters "optional" needs more specification. Urrgh. There is a long history of doing submission by moving messages to a special folder, and one thing they have in common is that they all failed to get much use. I think there are two reasons they failed: a lack of feature negotiation, and the overoptimistic belief that you can construct the envelope from the message headers. Feature negotiation should not be a big problem. In RFC 6409 submission, you get a list of features back from EHLO. Some of them can affect the way a client formats an outgoing message, e.g. 8BITMIME or BURL or SMTPUTF8. Some like DELIVERBY and DSN let the client put annotations on the message or individual addresses. Hence we need a way to get the submission features from the server, and a way to put submission annotations on the envelope addresses when sending a message. This leads to the second issue, where do the envelope addresses come from. While it is certainly true that in many simple cases you can guess the envelope addresses from the message headers, guessing robustly is hard, and in many cases it is not evident to me what the correct guess would be. With a message possibly having Sender, From, To, Cc, Bcc, and Resent-* versions of all of those, there's over a thousand possible header combinations to screw up and test. Beyond that, what do you do with a From: with two addresses or a group address with no actual addresses? If there's a Resent-To but no Resent-From (a 5322 violation but not a surprising one) do you reject it or do you invent an envelope address and if so, what address do you use? My strong preference would be that if you do submission, there should be no envelope defaults and the entire envelope must be specified by the client. (This is separate from whether the submission agent cleans up the submitted message on the way out.) This shouldn't be a burden on client writers, since the client presumably knows who it's sending the mail to, and it provides a straightforward way to add annotations to the envelope addresses, e.g., by sending a list of [ address, annotation, ... ] in place of a plain address. Also, if the envelope is explicit, this lets people use jmap for some interesting other applications, e.g., make a service like mailman a daemon talking to a jmap server rather than having to configure it in system specific ways. R's, John From nobody Wed Apr 19 09:50:28 2017 Return-Path: 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 707D0129B36 for ; Wed, 19 Apr 2017 09:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 QQqGeNZgczuy for ; Wed, 19 Apr 2017 09:50:26 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD0B0129B2A for ; Wed, 19 Apr 2017 09:50:25 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id y33so24254614qta.2 for ; Wed, 19 Apr 2017 09:50:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6Kg+1wBRTvcOkyn4Dm8rdIcbjJm2Ru6kxONfM/1k5vo=; b=0Qc/AElV3njRIf2ZiOf0vXTNyPPNS1u68J2AHgkv1Fmk2N9K6i+RQMiLgBDY97rpJh MIP3S71t1EKjupJ7anio2Mf69eAkQECU33rmQKQfIpo8d6em12kbfBiqnzm6CTwK7tyY N1Sbsl3DQXs1oKrqXc0cbUWWP9p/CjC+F/R9zvRg6t4s1VS4tyoOBuuDzn43UP+Oqt4i nuk6iOSbr8ru3kKIWkDnWvJThOU7DfIEWOxi84bQeuawWmzDv1JafcP/HNXk3T+ozrFq t7lVyGfO6MH/UlFMg8IgLywa5upnidEPCGgDtLreuVi4r1P1HALPjNtZqXdnk6RC9Pj9 TlKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6Kg+1wBRTvcOkyn4Dm8rdIcbjJm2Ru6kxONfM/1k5vo=; b=eE8aUHGX/Ag7Nu3Iqx0BI8nuEoC8kzwpxVHD+l+hinOOI7bWNohHj2VRaDUsqUlDyb bxRd+PWCKfFg+gV6ewd0+L0OahT/TZE+WN8TR8na/bstFY9z39bkZDBkPHq+6W9pwB90 NckjVmRBw68RSDaMCEXffWjrJMdp9SDCePvraINlD9zXPXEkiH+U/6XnC3sqLvmoGrT4 b4Fh/k2jNytQtYXo3VQ5lIEFCOT7e9n8+IjVsOGTNCzhML8xzvQ/utbwISOZ8Dz5dJ1m 4lIorqcQ/Ib6x0OgyMrfccDFKPcWZdykuOSBKD8wY986u0F592OSS+t++yXKQ7HhKsp4 NUJg== X-Gm-Message-State: AN3rC/5o6p4wJvInsouh+ZEOkROSKcsQrzMRJE9wsyKxEnfgmwIIue2Q e+QStmAy+JH0vA== X-Received: by 10.200.36.240 with SMTP id t45mr3361327qtt.230.1492620625080; Wed, 19 Apr 2017 09:50:25 -0700 (PDT) Received: from [10.0.20.202] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id h16sm2245104qta.34.2017.04.19.09.50.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Apr 2017 09:50:24 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ted Lemon In-Reply-To: <20170419163429.8556.qmail@ary.lan> Date: Wed, 19 Apr 2017 12:50:23 -0400 Cc: jmap@ietf.org, dkg@fifthhorseman.net Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170419163429.8556.qmail@ary.lan> To: John Levine X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Jmap] Submission X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 16:50:27 -0000 Of course you could do the envelope as attached attributes to the = message that's stuffed in the special folder. I'm not saying it has to = happen that way, but it can be made to work. From nobody Wed Apr 19 10:30:48 2017 Return-Path: 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 E54CF129B52 for ; Wed, 19 Apr 2017 10:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no 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 f7mVTbmJPrkK for ; Wed, 19 Apr 2017 10:30:44 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id AE2EF128BB6 for ; Wed, 19 Apr 2017 10:30:44 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id D7633F999; Wed, 19 Apr 2017 13:30:44 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id B9565206F1; Wed, 19 Apr 2017 12:46:11 -0400 (EDT) From: Daniel Kahn Gillmor To: John Levine , jmap@ietf.org In-Reply-To: <20170419163429.8556.qmail@ary.lan> References: <20170419163429.8556.qmail@ary.lan> Date: Wed, 19 Apr 2017 12:46:08 -0400 Message-ID: <87d1c873cf.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [Jmap] Submission X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 17:30:46 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed 2017-04-19 16:34:29 +0000, John Levine wrote: > My strong preference would be that if you do submission, there should > be no envelope defaults and the entire envelope must be specified by > the client. (This is separate from whether the submission agent > cleans up the submitted message on the way out.) This shouldn't be a > burden on client writers, since the client presumably knows who it's > sending the mail to, and it provides a straightforward way to add > annotations to the envelope addresses, e.g., by sending a list of=20 > [ address, annotation, ... ] in place of a plain address. I think you've convinced me that while it is surely easy to write a server-side envelope synthesizer, it looks hard to write a high-quality and robust server-side envelope sythesizer. You've also convinced me that even if submitting envelope parameters ends up being nominally optional, any client i work on would always explicitly send them anyway because i'd be afraid of whatever bugs lurk inside whatever server-side synthesizer i happen to be talking to. So from an implementer's perspective, i don't really care about making the submission envelope parameters optional, and would happy if JMAP ends up requiring the client to provide them during submission. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEOCdgUepHf6PklTkyFJitxsGSMjcFAlj3lFAACgkQFJitxsGS MjeO2hAAgGnhftJG/E6hk7fH1YU4ue5nFEGShJYbVokNlWPt1TkL0HHhiMGmtBbo 1Edxw6hyqA50bJKnM0zJSFFjQ1yTVCu9Q6q5FolxtFF+enFWsrn3z9OULEGI3c/C izGh4xH3mz8kDShE3AWSMMlmSE6EHlYIkIeR0rODSGYoCzw6mDegoYsYn97GYjjO ISzO8tykj5CCgtFEjnWwUytZUbTYY5BSM6ts7SE1p3EuU6Qc7kGM/YWAA62M5aDF e6Ey+tMEEA8DSOjmm+XPlq5pljnyNOR0RPpQPZ7ngd5O3xt8mhVBakJbq/XIJfmj nr/KOEdTekCLxilJrkp2Rw6X94wqNSJdh0pkEbNG/7qvCoVyhwlXKryM0iRn0iry soijhaJ3EuOtY8i1JUZj8IvN+0ZmTokO3qB8EknzQl3xzQudBSXX/7U73k5AFBP0 JOIcEmzOoeGqtCyICOS5x3lNcwopKefw5wfDbWXXIHQFVdw+Y+kc+t4/YQaauFSz aIJmr4hLDFbLX3cwKqtT8x6Cv47IjrbMSGrur3m6kEtaUn2gPTfMBzuZWJYcT+MX IIgWt4xV75Ug7uuqXEwrE/yt4IaUuCLVeTme54U/5/4bnn17HPEUvrhotqxfI7Ti +Nc89SUFLs/rj6blPrQYFhbOA7DunkQ9cYDitgNtUrjEEHuecMc= =ocbY -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Apr 19 10:42:12 2017 Return-Path: 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 53830129B66 for ; Wed, 19 Apr 2017 10:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.22 X-Spam-Level: X-Spam-Status: No, score=-1.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=HIqdDJdu; dkim=pass (1536-bit key) header.d=taugh.com header.b=clrYnuNq 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 nzPdADu8B8sk for ; Wed, 19 Apr 2017 10:33:11 -0700 (PDT) Received: from miucha.iecc.com (w6.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 679A8129B63 for ; Wed, 19 Apr 2017 10:33:11 -0700 (PDT) Received: (qmail 63230 invoked from network); 19 Apr 2017 17:33:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=f6fc.58f79f56.k1704; bh=7O9NixHpGwsftOZ+mawHCfvY5swwYxUq4CTeyTUEzWQ=; b=HIqdDJduIxyKuSoXr+Lf91PWAcQSuV8+U2kCXh32WIFcctmIKjAfQ42GhEiqt/0JjXDqLp8SQeFk1eq/IVPODfJp5uWf5zQE+tojCOC/S/25NFYAqUz+SturxQYQhGFr4JpYDpfoUfwTHCLlfGtjeLvFvqh/L9RgMmyHh3n68PF31Xre19uPpRILYxAIkn1FaaSQBvOCUyMlMqk6qRARYGmlj/el7m7JRV3r3bn69DmAnyRPjI/DNXys2sAwHeQ8 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=f6fc.58f79f56.k1704; bh=7O9NixHpGwsftOZ+mawHCfvY5swwYxUq4CTeyTUEzWQ=; b=clrYnuNqp6WilpklBWdDtjbd7ObkskCMB+GhyL2FtEcz030GqTGkLAc7dS/86XPhPRM3zNS2GViy+7MsfdAVFmlP73gEwhEtOwOuxxS8NdWomWfV391ijhNzu1xGQiKVmfE6JO8TjQtwlhyrCZOcOsOxr5NLyWjPkeQ+4ZX+euiVHANyLbW1QA/wuZzpoaJ0U3bEqqOaR55z5mMQAz/hjdcsqRtrI84PjpgjHfnn/wrmUSZL1JvL4EXLkDF52+Fa Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 19 Apr 2017 17:33:10 -0000 Date: 19 Apr 2017 13:33:09 -0400 Message-ID: From: "John R Levine" To: "Ted Lemon" Cc: jmap@ietf.org In-Reply-To: References: <20170419163429.8556.qmail@ary.lan> User-Agent: Alpine 2.20 (OSX 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: X-Mailman-Approved-At: Wed, 19 Apr 2017 10:42:06 -0700 Subject: Re: [Jmap] Submission X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 17:33:17 -0000 > Of course you could do the envelope as attached attributes to the message that's stuffed in the special folder. I'm not saying it has to happen that way, but it can be made to work. Sure. I don't see this as being hard to implement. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Wed Apr 19 11:04:45 2017 Return-Path: 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 721E2129BA9 for ; Wed, 19 Apr 2017 11:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.221 X-Spam-Level: X-Spam-Status: No, score=-1.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=CTZCxk9J; dkim=pass (1536-bit key) header.d=taugh.com header.b=jRJ4X2/N 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 U5LPXNGPjaWM for ; Wed, 19 Apr 2017 11:04:42 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46758129B82 for ; Wed, 19 Apr 2017 11:04:42 -0700 (PDT) Received: (qmail 68607 invoked from network); 19 Apr 2017 18:04:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=10bfc.58f7a6b9.k1704; bh=0mmDxiCVmfKm7wo9QGfOiT7zqERo0URLXDxI5lkiWCU=; b=CTZCxk9J8aeEenFY/KcvE61cKnIi6mlYIUo8i5A0aKO0GaVlhHUl7QvsntCxpFEtA/aUcUY7doMMD4SIoi6Ax2Sp6u40uT+bxlGZOJiTNE7F+XV/bthOoTmhixMUgXeRgqGvKuvEk8C12wshSvUiVBJZIS1hHc1L9ciObjRVW17UF6jZfr+WnIAk94sMK+Oftw+2BfivRKMu+d3t6ijlLQdKqZLdIIKnnjmmc+oR7+SqrOs6mycwjqfIfZyk1myM DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=10bfc.58f7a6b9.k1704; bh=0mmDxiCVmfKm7wo9QGfOiT7zqERo0URLXDxI5lkiWCU=; b=jRJ4X2/Nap2Yj1yoYeoco+6sWYaJYkc8t5eWj3yxx6X2ArVP2L0WmQnwZbQsOrbmJFan42CpxPWgZfmeKH5yDNVywU8xnDUGfsq4yrnN9FV2ZxSScWeS3rJpVPmX9+D2isZ5EDulh4hpKAG74oMFFl7LbCpZjbljqzenEUrUUCpmaYCF85EWGd/vZjVJDIQnna8j+sZ8FU3jiFHXjTYj/WysA19nSxPF7Qq3WIgaFtegShOmScZW19vZTXOHLdIU Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 19 Apr 2017 18:04:41 -0000 Date: 19 Apr 2017 14:04:40 -0400 Message-ID: From: "John R Levine" To: "Daniel Kahn Gillmor" Cc: jmap@ietf.org In-Reply-To: <87d1c873cf.fsf@fifthhorseman.net> References: <20170419163429.8556.qmail@ary.lan> <87d1c873cf.fsf@fifthhorseman.net> User-Agent: Alpine 2.20 (OSX 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Jmap] Submission X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 18:04:43 -0000 > I think you've convinced me that while it is surely easy to write a > server-side envelope synthesizer, it looks hard to write a high-quality > and robust server-side envelope sythesizer. Right, and even then, if a client can't put parameters on the envelope, it's not going to be very satisfactory. On the other hand, if you do have an explicit envelope with parameters, a lot of other stuff falls out naturally. For example, the marinate* option that people were arguing about is the FUTURERELEASE extension defined in RFC 4865. with the HOLDFOR and HOLDUNTIL parameters. No need to invent anything, it's already there. I hope Ned Freed weighs in here, since he's done more hand to hand combat with this stuff than anyone. R's, John * - as in, allow a message to marinate for a while before sending it From nobody Wed Apr 19 12:29:34 2017 Return-Path: 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 21792128C83 for ; Wed, 19 Apr 2017 12:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.002 X-Spam-Level: X-Spam-Status: No, score=-7.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 SRbcNL1hFZdO for ; Wed, 19 Apr 2017 12:29:32 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 165C71270B4 for ; Wed, 19 Apr 2017 12:29:32 -0700 (PDT) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v3JJTVAs032479 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 19 Apr 2017 19:29:31 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.13.8/8.14.4) with ESMTP id v3JJTVXg026572 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 19 Apr 2017 19:29:31 GMT Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v3JJTU5t019310 for ; Wed, 19 Apr 2017 19:29:30 GMT Received: from [10.154.116.81] (/10.154.116.81) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 19 Apr 2017 12:29:30 -0700 From: "Chris Newman" To: "jmap@ietf.org" Date: Wed, 19 Apr 2017 12:29:29 -0700 Message-ID: <096E2D4B-D7ED-4439-BB6F-7944892D2ACA@oracle.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Subject: Re: [Jmap] Submission X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 19:29:33 -0000 The original IMAP designer always opposed adding submission to IMAP as a matter of functional separation. While I strongly agree with the need for functional specification, it is possible to design a protocol in such a way that multiple separable functions are provided in the same protocol. As a result I support adding submission to JMAP in a way that preserves functional separation. 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. Furthermore, SMTP submission is a full standard IETF protocol that continues to be extended. JMAP should leverage the semantics of the existing standard in such a way that it's not necessary to change the JMAP specification when a new submission extension that's useful to JMAP is added. In addition to giving JMAP clients access to all the useful submission extensions like FUTURERELASE, UTF8SMTP, DELIVERBY, etc. This will ultimately make the JMAP specification simpler (as it won't have to deal with submission extensions directly) and more flexible to deploy. Finally, if JMAP supports submission then I expect a client author will want to use the JMAP submission mechanism for all submissions. If JMAP has a rigid design where each submission extension requires an additional JMAP extension then a high-end client will eventually be forced to implement SMTP submission in addition to JMAP submission. And it will be stuck doing both (the former for functionality, the latter for ease-of-setup). I don't want JMAP clients to be forced down that path. What this means is that for JMAP to support submission correctly, it must be able to function as an SMTP submission proxy from a semantic viewpoint. This creates a number of requirements. The basic requirements are: 1. It must be possible to query the JMAP server for the set of Submission ESMTP extensions semantically equivalent to the SMTP submission EHLO response. The JMAP server needs to omit the extensions that aren't relevant (e.g., AUTH, STARTTLS, PIPELINING). 2. It must be possible to provide an SMTP envelope for submission that is semantically identical to the submission protocol. This needs to support MAIL FROM, one or more RCPT TO, and ESMTP parameters to those envelope components. There needs to be an algorithmic way to convert from JMAP envelope syntax to SMTP Submission envelope syntax. 3. It must be possible to get submission errors that are semantically identical to those provided by a submission server. Including at least 3-digit SMTP code, optionally enhanced SMTP code and human readable text of error and potentially one response for mail from, one for each rcpt to and one for data/bdat final response. So that's the submission functionality JMAP needs to provide if it provides submission at all. If you want to also provide a simpler model for submission in JMAP, I won't object as long as the full model is mandatory. - Chris From nobody Wed Apr 19 12:37:04 2017 Return-Path: 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 A4636129B4B for ; Wed, 19 Apr 2017 12:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 xjJGsY5WkFGO for ; Wed, 19 Apr 2017 12:37:02 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C3311277BB for ; Wed, 19 Apr 2017 12:37:02 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id p68so29199596qke.1 for ; Wed, 19 Apr 2017 12:37:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ZC4kdeun2CrgEpsgZJIx7VksqQ94g1XGqA4KM9QLs0A=; b=s/cE8AXGCxlw6quO8nGuSc9gpBYvIn9ealxTRbwKNlnkS7ZFZXDSBPm6tC/cYgoxGh zdM+hgytibhbjxxW4bETuYyCd2YOrrwh3cMlLqfNhE0nfkCONPvUI38JxhNjLX7GDmhB Zdnp8y7sQnqWxyVdbtRdMrJMW7+muQpHS6RdOlocHVOtkPhrnNeZNYhK1mfWu5GMeWp1 Iiyi2tdc+KRfpK/E3JjEKSJfoA9HwarHvMEYy3f4JUBy2ebV2BF74r4AjSuN3nB/MC2Y ADC9tsTkGgRJ/iDzHLQy+U3kZycVJTx6Ux4uhLbi6i3Hkjar8ZzwlZF4PkHxqzN1nfbS kOOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=ZC4kdeun2CrgEpsgZJIx7VksqQ94g1XGqA4KM9QLs0A=; b=jHE8qqOkhbZSLJ+S/Gk2diN6BQLECa69/vGweQCKjPxT1jL+TXFjtFWOn0LlZaQT8V ctv3EmC3unCTS+Z9c5coWtEWvE2gHpLJ/wb6Fy1U2kCctH2YeFksPZ+rBGASEqbsgPhJ L0iAgePRbeN3FGSyeCVRc86Jz2O9vh2UA/gl9HngoXZ1AayhornZj5S27w319ZbJd1iW LanvGW3qTVcTm9l/J4qPT9kf4s2hYrU1cZ5x5oPJdb0JUA3eHSpfkJP5vvVWSjl1AtfG fCdFRpM/0sdLaOxvsh/HlDDzVPu731/3KmluyQkUDkq5eYEo3teCZdptIyUyFqIE4dbE OJrg== X-Gm-Message-State: AN3rC/6XjmCzEG1U36DtSZUbKIRnRWlisA3xlQR36TxouppJWVcXFa4N bn9Kv5RJ8zzT8A== X-Received: by 10.55.77.209 with SMTP id a200mr4422361qkb.11.1492630621237; Wed, 19 Apr 2017 12:37:01 -0700 (PDT) Received: from [10.0.20.202] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id r129sm668797qkb.16.2017.04.19.12.36.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Apr 2017 12:37:00 -0700 (PDT) From: Ted Lemon Message-Id: <89E217B2-A700-498C-BA72-3FD9939F34C7@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_06195D68-23D7-4179-9D01-EF453E03C9FB" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 19 Apr 2017 15:36:59 -0400 In-Reply-To: <096E2D4B-D7ED-4439-BB6F-7944892D2ACA@oracle.com> Cc: "jmap@ietf.org" To: Chris Newman References: <096E2D4B-D7ED-4439-BB6F-7944892D2ACA@oracle.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Jmap] Submission X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 19:37:04 -0000 --Apple-Mail=_06195D68-23D7-4179-9D01-EF453E03C9FB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Apr 19, 2017, at 3:29 PM, Chris Newman = 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? Your three requirements, which make sense to me, could be added as = attributes to the message once it's been sent. I'm not convinced that this is the right way to handle it=E2=80=94it = 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, and the MUA has to watch the sent mailbox. 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. --Apple-Mail=_06195D68-23D7-4179-9D01-EF453E03C9FB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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?

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

I'm not = convinced that this is the right way to handle it=E2=80=94it 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, and = the MUA has to watch the sent mailbox.   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.

= --Apple-Mail=_06195D68-23D7-4179-9D01-EF453E03C9FB-- From nobody Wed Apr 19 13:17:44 2017 Return-Path: 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 ; 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 ; 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 ; 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 ; Wed, 19 Apr 2017 21:17:39 +0100 X-SMTP-Protocol-Errors: PIPELINING From: Alexey Melnikov 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 , "jmap@ietf.org" Message-Id: References: <096E2D4B-D7ED-4439-BB6F-7944892D2ACA@oracle.com> <89E217B2-A700-498C-BA72-3FD9939F34C7@fugue.com> To: Ted Lemon MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=Apple-Mail-7C9965E6-CECE-4A97-88AC-131CACE67A42 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Jmap] Submission X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 20:17:43 -0000 --Apple-Mail-7C9965E6-CECE-4A97-88AC-131CACE67A42 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable > On 19 Apr 2017, at 20:36, Ted Lemon wrote: >=20 >> On Apr 19, 2017, at 3:29 PM, Chris Newman 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 o= r present in the mail store, that is an unacceptable protocol design error a= s it hinders the manageability of large deployments. >=20 > Isn't this just an implementation detail? IOW, how is it different to ha= ve a different protocol for queuing messages, versus having different handli= ng for a mailbox with a specific name? It is not clear to me why a queue can't be also a mailbox. Interfaces seem t= o 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 attribu= tes 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 n= ot important right now.) >=20 > I'm not convinced that this is the right way to handle it=97it means that t= he 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 ord= er to report to the user that a message was sent? I suspect we can use JMAP n= otifications for that. > But ISTM that we have to provide ways of doing all these things anyway, s= o having an additional protocol may not actually be worth the complexity. --Apple-Mail-7C9965E6-CECE-4A97-88AC-131CACE67A42 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On 19 Apr 20= 17, 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 stor= e (which has very different management/monitoring issues). If the JMAP desig= n requires a mail queue to be present on the JMAP server or present in the m= ail store, that is an unacceptable protocol design error as it hinders the m= anageability of large deployments.

Isn't this just an implementation detail?   IOW, how is it dif= ferent to have a different protocol for queuing messages, versus having diff= erent handling for a mailbox with a specific name?
<= div>
It is not clear to me why a queue can't be also a mailbox. Int= erfaces seem to be pretty similar for both.

But anyway, O= utbox doesn't really have to be a part of the mailstore, it can be just expo= sed as a mailbox in JMAP.

Your three requirements, which make sense to me, could be added as a= ttributes to the message once it's been sent.
<= br>
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=E2=80=94it means that the MUA has to be specific= ally watching for changes in the submit mailbox, or else that there has to b= e a submit and a sent mailbox,

There= are both.

and the MU= A has to watch the sent mailbox.

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

  But ISTM that we have to provide ways of doing all these things an= yway, so having an additional protocol may not actually be worth the complex= ity.
= --Apple-Mail-7C9965E6-CECE-4A97-88AC-131CACE67A42-- From nobody Wed Apr 19 13:49:34 2017 Return-Path: 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 944CA129BCC for ; Wed, 19 Apr 2017 13:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 FVOUdccSLk7T for ; Wed, 19 Apr 2017 13:49:29 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CB2A12D0C3 for ; Wed, 19 Apr 2017 13:49:29 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id y63so554384qkd.1 for ; Wed, 19 Apr 2017 13:49:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=lHW9TMhr5S1Zq6HoDTjQc1RBjyGpTpUcnjkxezjv8WA=; b=o04I2RAoxmVJXY+9S1PrRFAPpN6sFXsyITWRmF739n8VYibITY4XlbfzQsxoiF6mQH FZv7sU4R9lrKgU9DxsbJasutF13UfexGIuk2haIdAO5xNBmFTaPtBtKqAyH/5qh+ZhzC h/gc/JOYiKjWR/JPsCV6kgAjlIyLcFMRoKqv12Of7Sn0yxnMoNrhjSBr1teil5FRMsMh mkL31ARZJ2BblDBAcbNSvfVLMYOI5nPdCo79xCA2BvOozJpcY9Uv+Yz4dY/CijXE09gp MXiAaEWvr3CFCXTxC70afyRzlKEoP5Nnv1Foc8nRrMv5JgBAWBjGSs88E1MzrWKBH8tI jZWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=lHW9TMhr5S1Zq6HoDTjQc1RBjyGpTpUcnjkxezjv8WA=; b=s6Wrb0Eyavi+QBSsSsRYngwPdlFHYLzuqqqUDPyg7lyunx/oTq4ohaICVxF0Ror9qd yE3Ma0OB9h8FH9fAlhbWh79VXE5MPaBQEQIp4MdEdvO9Z9ryfX+G9iGoDCQPHm9/2rWD +Xaxr7QeA2VfJSfqapfRhUGtORqWYWupySjXTLLaCSEaABY3P24vg0ohHh6d7zdLpb9f BEPWIaTilSqSlwjG0Lv5i9+RO0dvd0YmoJNxEnwC2jBkiz1aZssSg9I6GPC7UdrUeWzX /KVsKWC4hS5+hBZMZveGT3tSs7JMSfJWLUI2kpPg4MPC8fZEwq4OsosdzO5sdhVXIVrx GWDQ== X-Gm-Message-State: AN3rC/7q+zfvfugehYJNdm+uqzIYKTKqbSdQFu+pWz1cDclmG2yVG9ep Qb3zj/cnA/PiyYU515k= X-Received: by 10.55.129.134 with SMTP id c128mr4217080qkd.310.1492634968549; Wed, 19 Apr 2017 13:49:28 -0700 (PDT) Received: from [10.0.20.202] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id h6sm2679164qkd.56.2017.04.19.13.49.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Apr 2017 13:49:27 -0700 (PDT) From: Ted Lemon Message-Id: <58623A09-E856-46D7-92A3-E960E20245F0@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_051165E9-A9B5-42F6-838A-E60D771F404B" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 19 Apr 2017 16:49:26 -0400 In-Reply-To: Cc: Chris Newman , "jmap@ietf.org" To: Alexey Melnikov References: <096E2D4B-D7ED-4439-BB6F-7944892D2ACA@oracle.com> <89E217B2-A700-498C-BA72-3FD9939F34C7@fugue.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Jmap] Submission X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 20:49:33 -0000 --Apple-Mail=_051165E9-A9B5-42F6-838A-E60D771F404B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 19, 2017, at 4:38 PM, Alexey Melnikov = wrote: > 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. Possibly, but reliable delivery of notifications would potentially be an = issue, for cases where the message is queued rather than being delivered = as soon as it lands, or even in that case if the MUA disconnects = immediately after submitting. But my mental model of how notifications = work is really thin, so if that's not an issue, then sure, notifications = would work. I would have assumed that watching the sent mailbox would = be how the notification would be generated, no? --Apple-Mail=_051165E9-A9B5-42F6-838A-E60D771F404B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Apr 19, 2017, at 4:38 PM, Alexey Melnikov <alexey.melnikov@isode.com> wrote:
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.

Possibly, but reliable delivery of notifications = would potentially be an issue, for cases where the message is queued = rather than being delivered as soon as it lands, or even in that case if = the MUA disconnects immediately after submitting.   But my mental = model of how notifications work is really thin, so if that's not an = issue, then sure, notifications would work.   I would have assumed = that watching the sent mailbox would be how the notification would be = generated, no?

= --Apple-Mail=_051165E9-A9B5-42F6-838A-E60D771F404B-- From nobody Wed Apr 19 18:28:46 2017 Return-Path: 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 E2A3912E852 for ; Wed, 19 Apr 2017 18:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 oUXkBAF2b44f for ; Wed, 19 Apr 2017 18:28:42 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93357129C2B for ; Wed, 19 Apr 2017 18:28:42 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v3K1SfEP006870 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Thu, 20 Apr 2017 01:28:41 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v3K1SfKj007349 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Thu, 20 Apr 2017 01:28:41 GMT Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v3K1Sesd013883 for ; Thu, 20 Apr 2017 01:28:40 GMT Received: from [10.154.116.81] (/10.154.116.81) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 19 Apr 2017 18:28:40 -0700 From: "Chris Newman" To: "jmap@ietf.org" Date: Wed, 19 Apr 2017 18:28:39 -0700 Message-ID: In-Reply-To: <89E217B2-A700-498C-BA72-3FD9939F34C7@fugue.com> References: <096E2D4B-D7ED-4439-BB6F-7944892D2ACA@oracle.com> <89E217B2-A700-498C-BA72-3FD9939F34C7@fugue.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Subject: Re: [Jmap] Submission X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 01:28:44 -0000 On 19 Apr 2017, at 12:36, Ted Lemon wrote: > On Apr 19, 2017, at 3:29 PM, Chris Newman > 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? Not at all. Protocols can either be architecture neutral or impose an architecture on the system. An example where IMAP imposed an architecture on the system is the \Deleted flag and EXPUNGE command. This requires a server mail store to have a concept of deleted messages within a folder; something that doesn't fit well if the mail store had a "trash folder" model. And while it's possible to implement a virtual trash folder in a mail client using the \Deleted+EXPUNGE model so this wasn't a UI-constraining protocol design error, it turns out that clients didn't do that and decided to ignore the IMAP base spec semantics and impose the trash folder model on IMAP servers. That interoperates badly without correct implementation of RFC 6154 on all clients. So that's an example of a protocol design error imposing architectural constraints that resulted in real world problems. To clarify my point, I think having an "outbox" with combined mail store and mail queue semantics as a mandatory architectural element of JMAP is a protocol design error because it breaks functional separation. And that violation of functional separation is particularly problematic in larger deployments where mail stores and mail queues each add management and monitoring complexity and require different designs and storage models to scale effectively. JMAP needs to have a submission action that has semantics matching the IETF Submission standard. It's fine for that command to pull data from the mail store as part of the submission action (as RFC 4468 does). But the JMAP protocol needs to allow implementations where mail queue and mail store semantics are separate. - Chris From nobody Wed Apr 19 18:55:47 2017 Return-Path: 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 0FDD212EAE0 for ; Wed, 19 Apr 2017 18:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 4EiB6wixnUOt for ; Wed, 19 Apr 2017 18:55:43 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00FAB12778E for ; Wed, 19 Apr 2017 18:55:42 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id m36so34520757qtb.0 for ; Wed, 19 Apr 2017 18:55:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ctebnSRnOZxvL3fFx4nTk/+wr3HoPWUhPWAMlM+JJwU=; b=bVekXfKRWHAWQtlzK4BB/lON8cJSN0yXS8TtWtuJ8/tNvp1cPeKaOgh9ACZaIWwef7 f5hDaurN3u7qNi6VDyScGY+3rNbysqFWg6xmhLlBLgK3BDnnGIGLJ5QuctII2aV/+NCq 90ZJgXub+HIdxvCAfs5aCIXsw/Sj8IA2FoKxZOcL6hW2QHdgwOKEoO+5CMS18r545FDA r/blvixLv63MGfTc9gpa2XS1K6EnfodTs++HqIg/zTxmNyhg7Os0vcTCb9NqE6Azx+M2 fUdinAOSh7sLnygl/53MYljr8pytGdLPviD7jAf9alAROLts9PwO2QIrsdi2VYOIqa98 L89w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=ctebnSRnOZxvL3fFx4nTk/+wr3HoPWUhPWAMlM+JJwU=; b=ohJ+j4kLH3X10PBDFMkGDodIrRFhpSOpfq18EcNS2b424h5ODo3ezvHsp9kMxV9BeB H/J3kZ7bNuEeE2v9uDfy9ibTqMJuLESoJoXOfoxQv4+8iEXA/PmN9YWr1zHuXigDegNu EwCkCv7i6ZKSdaWpk8jYlpqZ3ulNoIe9aOKI8vPZvnlsGwB+xfpfh16RITKsUIeShBKB Buy7ZiW/m1RWHJ+6V7OL6hi0aRbIjopCR1z+RDHXKoO3AtCyvpYtvZKvw7RTs/7DoIK3 40CeJmlR0wFCio9qAD+o9FlI/SwMrKqCkpHWMGXcmj9Tv8duEPg2IeTxXpumy7h4gmNu DO6Q== X-Gm-Message-State: AN3rC/7iQ89taWfzANQUpz+bYD3N/FKPa93eFPkV00JvCoq4pmXPFHh1 vLzrsUb75FkgfiGknXU= X-Received: by 10.200.44.130 with SMTP id 2mr5972507qtw.59.1492653342122; Wed, 19 Apr 2017 18:55:42 -0700 (PDT) Received: from [10.0.20.202] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id i16sm3192305qta.61.2017.04.19.18.55.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Apr 2017 18:55:41 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_6625C96C-EBD3-4E56-8216-238A38BF12C2" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 19 Apr 2017 21:55:39 -0400 In-Reply-To: Cc: "jmap@ietf.org" To: Chris Newman References: <096E2D4B-D7ED-4439-BB6F-7944892D2ACA@oracle.com> <89E217B2-A700-498C-BA72-3FD9939F34C7@fugue.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Jmap] Submission X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 01:55:45 -0000 --Apple-Mail=_6625C96C-EBD3-4E56-8216-238A38BF12C2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 19, 2017, at 9:28 PM, Chris Newman = wrote: > To clarify my point, I think having an "outbox" with combined mail = store and mail queue semantics as a mandatory architectural element of = JMAP is a protocol design error because it breaks functional separation. = And that violation of functional separation is particularly problematic = in larger deployments where mail stores and mail queues each add = management and monitoring complexity and require different designs and = storage models to scale effectively. >=20 > JMAP needs to have a submission action that has semantics matching the = IETF Submission standard. It's fine for that command to pull data from = the mail store as part of the submission action (as RFC 4468 does). But = the JMAP protocol needs to allow implementations where mail queue and = mail store semantics are separate. Perhaps so. However, the semantics of submission protocols aren't = really right either. What I think we want is to tell the MUA that = delivery failed if it did, and to allow the MUA to know the current = status of delivery at least at the first hop, if delivery is not yet = complete. But the SMTP submit protocol doesn't do this. It's fire = and forget: all you get is confirmation that the message has been = queued. Granting that the point of this working group is not to fix SMTP, the = semantics of the JMAP submit protocol ought to allow for delivery of = failure status without generating a needless bounce message just as a = place to put information from the site MTA's delivery attempt. If the = failure happens farther down the line in a forwarding chain, we can't do = anything about it, but from a usability perspective bounce messages are = worse than useless, so anything that can reduce the number of such = messages that users see is a net win. The point that I am arguing is that sent messages really do have a place = in something that is notionally a mail store, and those messages serve = as a place where delivery status can be found. Message submission = should not be a transaction: it should be a process. Notification = should work even if the MUA isn't present at the time of failure, and = should be available in all MUAs, not just the sending MUA. It should be = presentable to the user in a way that makes sense. A "sent" folder = makes sense. A separate queue construct does not. Forcing the MUA to = fake this isn't going to produce a good user experience. --Apple-Mail=_6625C96C-EBD3-4E56-8216-238A38BF12C2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Apr 19, 2017, at 9:28 PM, Chris Newman <Chris.Newman@oracle.com> wrote:
To clarify my point, I think having an = "outbox" with combined mail store and mail queue semantics as a = mandatory architectural element of JMAP is a protocol design error = because it breaks functional separation. And that violation of = functional separation is particularly problematic in larger deployments = where mail stores and mail queues each add management and monitoring = complexity and require different designs and storage models to scale = effectively.

JMAP needs to have = a submission action that has semantics matching the IETF Submission = standard. It's fine for that command to pull data from the mail store as = part of the submission action (as RFC 4468 does). But the JMAP protocol = needs to allow implementations where mail queue and mail store semantics = are separate.

Perhaps so.   However, the semantics of submission = protocols aren't really right either.   What I think we want is to = tell the MUA that delivery failed if it did, and to allow the MUA to = know the current status of delivery at least at the first hop, if = delivery is not yet complete.   But the SMTP submit protocol = doesn't do this.   It's fire and forget: all you get is = confirmation that the message has been queued.

Granting that the point of this working = group is not to fix SMTP, the semantics of the JMAP submit protocol = ought to allow for delivery of failure status without generating a = needless bounce message just as a place to put information from the site = MTA's delivery attempt.   If the failure happens farther down the = line in a forwarding chain, we can't do anything about it, but from a = usability perspective bounce messages are worse than useless, so = anything that can reduce the number of such messages that users see is a = net win.

The = point that I am arguing is that sent messages really do have a place in = something that is notionally a mail store, and those messages serve as a = place where delivery status can be found.   Message submission = should not be a transaction: it should be a process.   Notification = should work even if the MUA isn't present at the time of failure, and = should be available in all MUAs, not just the sending MUA. It should be = presentable to the user in a way that makes sense.   A "sent" = folder makes sense.   A separate queue construct does not.   = Forcing the MUA to fake this isn't going to produce a good user = experience.

= --Apple-Mail=_6625C96C-EBD3-4E56-8216-238A38BF12C2-- From nobody Wed Apr 19 19:06:01 2017 Return-Path: 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 CF89512EAAA for ; Wed, 19 Apr 2017 19:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.002 X-Spam-Level: X-Spam-Status: No, score=-7.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 iqj6lVuJ1bG5 for ; Wed, 19 Apr 2017 19:05:58 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE16B124D68 for ; Wed, 19 Apr 2017 19:05:58 -0700 (PDT) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v3K25upF031250 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 20 Apr 2017 02:05:57 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v3K25sBS027296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 20 Apr 2017 02:05:56 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v3K25q11030328; Thu, 20 Apr 2017 02:05:53 GMT Received: from [10.154.116.81] (/10.154.116.81) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 19 Apr 2017 19:05:52 -0700 From: "Chris Newman" To: "Alexey Melnikov" Cc: "Ted Lemon" , "jmap@ietf.org" Date: Wed, 19 Apr 2017 19:05:51 -0700 Message-ID: In-Reply-To: References: <096E2D4B-D7ED-4439-BB6F-7944892D2ACA@oracle.com> <89E217B2-A700-498C-BA72-3FD9939F34C7@fugue.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Subject: Re: [Jmap] Submission X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 02:06:00 -0000 On 19 Apr 2017, at 13:38, Alexey Melnikov wrote: > > On 19 Apr 2017, at 20:36, Ted Lemon wrote: >> >>> On Apr 19, 2017, at 3:29 PM, Chris Newman >>> 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. The architectural requirements of a mail store and mail queue are very different. For comparison: Mail store * data is "owned" by the end-user * long-lived small & large objects * write-once, read-multiple, important dynamic metadata (flags & annotations) * quota-based administrative limits * over quota is flagged for statistics but not an operational problem * for security, read can be restricted to only work when the end-user authenticates * final delivery agent can be limited to append-only access * data for different users must be kept separate with ACL restrictions * random access is important; message metadata must be cached for efficiency Mail queue * data is "owned" by the delivery system * short-lived small & large objects * write-once, normally read+delete once, largely static metadata (envelope) * generally no administrative limits (or limits are imposed at submission time) * large queue indicates operational problems, needs to flag a monitoring system alert * for security, all read/write access can be restricted to delivery agent; no need for ACL complexity * data for different users can be combined for efficient queuing. * sending messages for different users over the same SMTP relay channel improves privacy by making traffic analysis harder * access follows queue pattern; many need to cache envelope metadata for efficiency but message metadata is not cached It possible to implement something that provides the union of the required semantics. But combining the semantics creates security and privacy constraints, adds monitoring complexity to the deployment, and removes a bunch of potential optimizations. So I object to JMAP if it requires me to implement something combining mail store and mail queue semantics. The protocol design needs to allow implementations with clean functional separation between mail queue and mail store. - Chris From nobody Wed Apr 19 19:30:22 2017 Return-Path: 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 169B6129B5F for ; Wed, 19 Apr 2017 19:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 GpsZYxf05PDR for ; Wed, 19 Apr 2017 19:30:19 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 781B4129470 for ; Wed, 19 Apr 2017 19:30:19 -0700 (PDT) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v3K2UG9L020524 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 Apr 2017 02:30:16 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0021.oracle.com (8.13.8/8.14.4) with ESMTP id v3K2UFEs001807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 Apr 2017 02:30:16 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id v3K2UD7v019427; Thu, 20 Apr 2017 02:30:14 GMT Received: from [10.154.116.81] (/10.154.116.81) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 19 Apr 2017 19:30:13 -0700 From: "Chris Newman" To: "Ted Lemon" Cc: "jmap@ietf.org" Date: Wed, 19 Apr 2017 19:30:12 -0700 Message-ID: In-Reply-To: References: <096E2D4B-D7ED-4439-BB6F-7944892D2ACA@oracle.com> <89E217B2-A700-498C-BA72-3FD9939F34C7@fugue.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Subject: Re: [Jmap] Submission X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 02:30:21 -0000 On 19 Apr 2017, at 18:55, Ted Lemon wrote: > On Apr 19, 2017, at 9:28 PM, Chris Newman > wrote: >> To clarify my point, I think having an "outbox" with combined mail >> store and mail queue semantics as a mandatory architectural element >> of JMAP is a protocol design error because it breaks functional >> separation. And that violation of functional separation is >> particularly problematic in larger deployments where mail stores and >> mail queues each add management and monitoring complexity and require >> different designs and storage models to scale effectively. >> >> JMAP needs to have a submission action that has semantics matching >> the IETF Submission standard. It's fine for that command to pull data >> from the mail store as part of the submission action (as RFC 4468 >> does). But the JMAP protocol needs to allow implementations where >> mail queue and mail store semantics are separate. > > Perhaps so. However, the semantics of submission protocols aren't > really right either. What I think we want is to tell the MUA that > delivery failed if it did, and to allow the MUA to know the current > status of delivery at least at the first hop, if delivery is not yet > complete. But the SMTP submit protocol doesn't do this. It's fire > and forget: all you get is confirmation that the message has been > queued. There's RFC 3887 (Message Tracking Query Protocol). The product I work on has implemented that. > Granting that the point of this working group is not to fix SMTP, the > semantics of the JMAP submit protocol ought to allow for delivery of > failure status without generating a needless bounce message just as a > place to put information from the site MTA's delivery attempt. Agreed. > If the failure happens farther down the line in a forwarding chain, we > can't do anything about it, but from a usability perspective bounce > messages are worse than useless, so anything that can reduce the > number of such messages that users see is a net win. Bounce messages that are standards compliant are useful (and are frequently used to implement automatic un-subscription for mailing lists). But what I would say is that a mail client UI that shows bounce messages as "just another message in the INBOX" is not a good UI. > The point that I am arguing is that sent messages really do have a > place in something that is notionally a mail store, Draft Messages and Sent Messages belong in a mail store; the \Sent and \Draft RFC 6154 folders are well-within scope for JMAP. > and those messages serve as a place where delivery status can be > found. I'm generally supportive of this goal. However, I want the JMAP base spec to deploy quickly so I'd like to keep the amount of additional mandatory system complexity JMAP requires over-and-above Submission+IMAP to a minimum. I'm supportive of some additional complexity in exchange for ease-of-client development. But I don't think improved bounce handling is the right place to make that tradeoff in the base JMAP spec. Improved bounce handling could make a good JMAP extension. - Chris From nobody Wed Apr 19 20:31:13 2017 Return-Path: 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 1DE82129C0C for ; Wed, 19 Apr 2017 20:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 JmcYBrZ1MOVy for ; Wed, 19 Apr 2017 20:31:10 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8321012940C for ; Wed, 19 Apr 2017 20:31:10 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id c45so35572321qtb.1 for ; Wed, 19 Apr 2017 20:31:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=DQ5WmHm4uCTSg72BkKdme5dDWxylYu2exMcVNQW+2Hk=; b=Ka2HYpI09aAoCIWb30GAqiKHqAUFPvFTY6izvu12DJ6yce4fallZZZiogsCkLzrWhY gL+6zFvIJi8nKhJ/gqMWUVAs79W2l+yahloKsGl14GeQQG0DeT1ed2A21JJz8VR5PeAl SMts8jPFiY5RNLgd+7nmtZcQnrx2D884UrJ9Gga+xK7RrPdqjeXWn/ZtADn0b+JxbRXD IN1PWW4Mx97KnwwmaNFPKux17+EhII8uTeGOfGv7Vlg8YI2nl74sWXcnpOE++ZpBtfv9 kCGjmbFqyrPbDT1wkWsH6cInWr5guaGp6lm1Ja5bpmHhLQai6UYlAF/C8w+mEs6bi1I1 q2ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=DQ5WmHm4uCTSg72BkKdme5dDWxylYu2exMcVNQW+2Hk=; b=Hs15cujL1KJe4iwVILQRnh0UHIYabsxUVrARUk95fCdTv4xsNezuUO/xF82o6LMZEd CFcmsCT5DvTpoyPl8RBgFQ9qUDIdgZEae7C4PNq6JYWc3FZz9aVqcKsj21vwWpaa35b2 RavuKTtMCuY1GKgTUklAWHAgQALcXMkTjK4s2unsloOsNs5BQoUhCvGt5xu3B3JPqdh8 KW92LNf01kp2rD/qNB+wkZyGfNYlE9oOxEW0uhT/sEp2NX73kAvkrm3UmoOVLgbk+qlN RDqaOa2Y1r7PJvCnFWKX5zhQR+uKcuNCJcUr7u8JlRReYSvbQJzrAP839ODfpWuPitNZ Ix1w== X-Gm-Message-State: AN3rC/4okDtjd9xLIqf0PRKhMAAntY0nD1ZFdXkbvechEtpHO6B4N8g4 7ldfEIMu0P9yRa4b5V4= X-Received: by 10.200.34.39 with SMTP id o36mr6419535qto.189.1492659069650; Wed, 19 Apr 2017 20:31:09 -0700 (PDT) Received: from [10.0.20.202] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id x10sm3352817qtb.25.2017.04.19.20.31.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Apr 2017 20:31:08 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_043E5C4E-E427-42D8-A6EC-FD2B8F14A209" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 19 Apr 2017 23:31:07 -0400 In-Reply-To: Cc: "jmap@ietf.org" To: Chris Newman References: <096E2D4B-D7ED-4439-BB6F-7944892D2ACA@oracle.com> <89E217B2-A700-498C-BA72-3FD9939F34C7@fugue.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Jmap] Submission X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 03:31:12 -0000 --Apple-Mail=_043E5C4E-E427-42D8-A6EC-FD2B8F14A209 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Apr 19, 2017, at 10:30 PM, Chris Newman = wrote: > Improved bounce handling could make a good JMAP extension. That is the rathole IMAP went down. The reason I'm advocating for = doing this in the base spec is that then we don't have to tolerate = clients that don't do the extension. But the complexities that you = mention are worth consideration=E2=80=94I'm saying this not to entirely = disagree with you, but to advocate that we at least consider doing this = in the base spec. --Apple-Mail=_043E5C4E-E427-42D8-A6EC-FD2B8F14A209 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Apr 19, 2017, at 10:30 PM, Chris Newman <chris.newman@oracle.com> wrote:
Improved bounce handling could make a = good JMAP extension.

That is the rathole IMAP went down.   The reason I'm = advocating for doing this in the base spec is that then we don't have to = tolerate clients that don't do the extension.   But the = complexities that you mention are worth consideration=E2=80=94I'm saying = this not to entirely disagree with you, but to advocate that we at least = consider doing this in the base spec.

= --Apple-Mail=_043E5C4E-E427-42D8-A6EC-FD2B8F14A209-- From nobody Wed Apr 19 21:14:39 2017 Return-Path: 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 8D28E129458 for ; Wed, 19 Apr 2017 21:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.226 X-Spam-Level: X-Spam-Status: No, score=0.226 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no 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 SvYL0fbVa1Jc for ; Wed, 19 Apr 2017 21:14:36 -0700 (PDT) Received: from miucha.iecc.com (w6.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AB181286B2 for ; Wed, 19 Apr 2017 21:14:36 -0700 (PDT) Received: (qmail 4340 invoked from network); 20 Apr 2017 04:14:34 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 20 Apr 2017 04:14:34 -0000 Date: 20 Apr 2017 04:14:12 -0000 Message-ID: <20170420041412.12322.qmail@ary.lan> From: "John Levine" To: jmap@ietf.org Cc: mellon@fugue.com In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Jmap] Submission X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 04:14:37 -0000 In article you write: >-=-=-=-=-=- >-=-=-=-=-=- > >On Apr 19, 2017, at 10:30 PM, Chris Newman wrote: >> Improved bounce handling could make a good JMAP extension. > >That is the rathole IMAP went down. The reason I'm advocating for doing this in the base spec is that then we don't have to tolerate clients that >don't do the extension. But the complexities that you mention are worth consideration—I'm saying this not to entirely disagree with you, but to >advocate that we at least consider doing this in the base spec. Having written some bounce processors for mailing list software, I can assure you that improved bounce handling is a rathole all of its own. You can handle all of the RFC compliant DSNs and such, and you're about 1/3 of the way there. It has been my impression that we want jmap to do what imap and submit do, but not that we want to try and fix SMTP's problems. R's, John From nobody Wed Apr 19 21:37:04 2017 Return-Path: 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 DA87012940E for ; Wed, 19 Apr 2017 21:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 nykS3A14ho8B for ; Wed, 19 Apr 2017 21:37:00 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9E5E127B52 for ; Wed, 19 Apr 2017 21:37:00 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id y11so1592401oie.0 for ; Wed, 19 Apr 2017 21:37:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GAssqmoVnVL8aBJ2ALRjw2OWymXaEBVnZ4ycjjyEfUI=; b=Uu8SyIikwIkuCKwdy3gRD9GmdX0lkb53/bwUagETzRfDZ5eIQYBsEz9tbWD/J2Sa2r MoT8sgo9GKKuxUniDgPGw9mH4tsvZ8cS1+aDy5rK1Oh6J8SL+Md+5l3C6zEklZoBHAgN jmeev+exPDge+8BJxFEk+T5wUmQr1zepuyrBWRB4tjtLa2OMJjTZO2cLe4h2k9nNzUf2 8slPqysjB6vmZRpUwac+O1xqQmWHo7jL5E8USGRTg1Ee09GaLX0NPhfESvHghsUTfrsa 9MR0OlP91iYIVbur85UJ/Y7ad1m15+9TN6Gjj9u3zTAGlXZO7eNq5pNJYAYx4CDZy+Qn Q3Lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GAssqmoVnVL8aBJ2ALRjw2OWymXaEBVnZ4ycjjyEfUI=; b=bErVd2w+lwWhNXl3WoNrXI7pjdFREdz22ZVkft3VlJ6BTVvsVG2iyOLWhdMhXONdvG efN0u61RhZDvpuV5cu3LP0bN1XU7tuii6Z/k7kyz2KEXq0nR3DFuVvStPczF9TVADD26 bl75lZHXf+0K49Nax56sStLQuuBn/bkUck2L/cWD2egDhFPuF8OWGxzjWyRprX8Ds612 1N2yKyYQm5R/rkQkRNi39K2qcNvvQ9Qhr7SfrzgRpKrTSuyuzk5E9MECbJ/JR7+iJlcP QWxecfS/01mC3EKkv5KYEORnWm56WPMiXTGkrswgxny2lFBUye4igKqeDH2qyOstCYYp Hdvw== X-Gm-Message-State: AN3rC/5HgIcMqezWCLU/0qbcBmHsO/GgSFOq7EFNDFLDe0bOeaxqFvej cCJ+mCTsbBeFYAoODwYXvFa0Eqvzr+nJ X-Received: by 10.202.216.84 with SMTP id p81mr3003692oig.193.1492663019760; Wed, 19 Apr 2017 21:36:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.120.72 with HTTP; Wed, 19 Apr 2017 21:36:58 -0700 (PDT) In-Reply-To: References: <096E2D4B-D7ED-4439-BB6F-7944892D2ACA@oracle.com> <89E217B2-A700-498C-BA72-3FD9939F34C7@fugue.com> From: Brandon Long Date: Wed, 19 Apr 2017 21:36:58 -0700 Message-ID: To: Chris Newman Cc: Alexey Melnikov , "jmap@ietf.org" , Ted Lemon Content-Type: multipart/alternative; boundary=001a113d28301069d0054d91b1f4 Archived-At: Subject: Re: [Jmap] Submission X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 04:37:03 -0000 --001a113d28301069d0054d91b1f4 Content-Type: text/plain; charset=UTF-8 On Wed, Apr 19, 2017 at 7:05 PM, Chris Newman wrote: > On 19 Apr 2017, at 13:38, Alexey Melnikov wrote: > >> > On 19 Apr 2017, at 20:36, Ted Lemon wrote: >> >>> >>> On Apr 19, 2017, at 3:29 PM, Chris Newman >>>> 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. >> > > The architectural requirements of a mail store and mail queue are very > different. For comparison: > > Mail store > * data is "owned" by the end-user > * long-lived small & large objects > * write-once, read-multiple, important dynamic metadata (flags & > annotations) > * quota-based administrative limits > * over quota is flagged for statistics but not an operational problem > * for security, read can be restricted to only work when the end-user > authenticates > * final delivery agent can be limited to append-only access > * data for different users must be kept separate with ACL restrictions > * random access is important; message metadata must be cached for > efficiency > > Mail queue > * data is "owned" by the delivery system > * short-lived small & large objects > * write-once, normally read+delete once, largely static metadata > (envelope) > * generally no administrative limits (or limits are imposed at submission > time) > * large queue indicates operational problems, needs to flag a monitoring > system alert > * for security, all read/write access can be restricted to delivery > agent; no need for ACL complexity > * data for different users can be combined for efficient queuing. > * sending messages for different users over the same SMTP relay channel > improves privacy by making traffic analysis harder > * access follows queue pattern; many need to cache envelope metadata for > efficiency but message metadata is not cached > > It possible to implement something that provides the union of the required > semantics. But combining the semantics creates security and privacy > constraints, adds monitoring complexity to the deployment, and removes a > bunch of potential optimizations. > > So I object to JMAP if it requires me to implement something combining > mail store and mail queue semantics. The protocol design needs to allow > implementations with clean functional separation between mail queue and > mail store. My understanding of an "outbox" is typically "the message is here when I want it submitted to the mail queue, and removed when that submission has been accomplished". Ie, on disconnected clients, this is often where messages are stored locally before they can be submitted via MSA. So, the outbox / jmap wouldn't require mail queue semantics, it's not the mail queue, it's the precursor to the mail queue. A more advanced solution might be for the message to be in the outbox for the entire time it's in the mail queue. I wouldn't implement them as one and the same, but move a message from the outbox to the sent folder (on success) or back to drafts or something (on failure) when the message has exited the mail queue. Ie, you could use DSN from the mall queue back to the mail store to cause the messages to move folders. I don't think anyone is suggesting this is required for jmap, though. I often considered something like that for Gmail, as it eliminates the confusion people often have that a message may be pending in our mail queues for days. It does require a fairly integrated system, however. Brandon --001a113d28301069d0054d91b1f4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Apr 19, 2017 at 7:05 PM, Chris Newman <chris.newman@orac= le.com> wrote:
On 19 Apr 2017, at 13:38, Alexey Melnikov wrote:
> 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 submissi= on mail queues (which have management/monitoring issues) functionally separ= ate from the mail store (which has very different management/monitoring iss= ues). If the JMAP design requires a mail queue to be present on the JMAP se= rver 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?=C2=A0 =C2=A0IOW, how is it di= fferent to have a different protocol for queuing messages, versus having di= fferent handling for a mailbox with a specific name?

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

 The architectural requirements of a mail store and mail queue are very diff= erent. For comparison:

Mail store
=C2=A0* data is "owned" by the end-user
=C2=A0* long-lived small & large objects
=C2=A0* write-once, read-multiple, important dynamic metadata (flags & = annotations)
=C2=A0* quota-based administrative limits
=C2=A0* over quota is flagged for statistics but not an operational problem=
=C2=A0* for security, read can be restricted to only work when the end-user= authenticates
=C2=A0* final delivery agent can be limited to append-only access
=C2=A0* data for different users must be kept separate with ACL restriction= s
=C2=A0* random access is important; message metadata must be cached for eff= iciency

Mail queue
=C2=A0* data is "owned" by the delivery system
=C2=A0* short-lived small & large objects
=C2=A0* write-once, normally read+delete once, largely static metadata (env= elope)
=C2=A0* generally no administrative limits (or limits are imposed at submis= sion time)
=C2=A0* large queue indicates operational problems, needs to flag a monitor= ing system alert
=C2=A0* for security, all read/write access can be restricted to delivery a= gent; no need for ACL complexity
=C2=A0* data for different users can be combined for efficient queuing.
=C2=A0* sending messages for different users over the same SMTP relay chann= el improves privacy by making traffic analysis harder
=C2=A0* access follows queue pattern; many need to cache envelope metadata = for efficiency but message metadata is not cached

It possible to implement something that provides the union of the required = semantics. But combining the semantics creates security and privacy constra= ints, adds monitoring complexity to the deployment, and removes a bunch of = potential optimizations.

So I object to JMAP if it requires me to implement something combining mail= store and mail queue semantics. The protocol design needs to allow impleme= ntations with clean functional separation between mail queue and mail store= .

My understanding of an "outbox"= is typically "the message is here when I want it submitted to the mai= l queue, and removed when that submission has been accomplished".

Ie, on disconnected clients, this is often where messa= ges are stored locally before they can be submitted via MSA.

=
So, the outbox / jmap wouldn't require mail queue semantics,= it's not the mail queue, it's the precursor to the mail queue.

A more advanced solution might be for the message to = be in the outbox for the entire time it's in the mail queue.=C2=A0 I wo= uldn't implement them as one and the same, but move a message from the = outbox to the sent folder (on success) or back to drafts or something (on f= ailure) when the message has exited the mail queue.=C2=A0 Ie, you could use= DSN from the mall queue back to the mail store to cause the messages to mo= ve folders.=C2=A0 I don't think anyone is suggesting this is required f= or jmap, though.

I often considered something like= that for Gmail, as it eliminates the confusion people often have that a me= ssage may be pending in our mail queues for days.=C2=A0 It does require a f= airly integrated system, however.

Brandon
--001a113d28301069d0054d91b1f4-- From nobody Wed Apr 19 21:46:34 2017 Return-Path: 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 CB165127B52 for ; Wed, 19 Apr 2017 21:46:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 WPGu6PCM_1Xp for ; Wed, 19 Apr 2017 21:46:31 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C8B212EAF6 for ; Wed, 19 Apr 2017 21:46:30 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id r203so33518887oib.3 for ; Wed, 19 Apr 2017 21:46:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=G1yW3LYmlTvy18CSeOnYR041IxelEa/SC8q6mQAL11I=; b=gVHzwzEEIE8CC2t8lRr+Aedyvdqqa9SV81BIOZq6eyunDa1rRpkpxqiWuyaVX9kSZ9 rysc8sDTezb+RZL839HEh74u4QXs2V8Nu1yO3yumcuzW55LMmK4uJ5FRmGtdgL5fe58m Fupdp53mWotBSJTAN3t+a9fQ+mj7Y+aiKvOsXU6pO3ECfB+szG2BDyvjR+0BeSLL6Oew 6ymM2UNPjFR/WQV0J6/dtdbaKUHjcKdHWJ6YCTM9EZpiZ9HBwqUBeJrnZQXJW2Npgw7Q P/XJgaezUO9Z2x0lRdiz9UO7t1KAF6ZJSICamBTGqV/GKe5FiUeQ34c3cv2QYgL2fXG/ DwmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=G1yW3LYmlTvy18CSeOnYR041IxelEa/SC8q6mQAL11I=; b=dULh/tfGb1ucVVJKE4IqtIHNI3c9tRhzkclmZq9LE8rOdKPr3vyuo2cQtgqaL9B6A+ elmBhmZguLMKvcxQRhgCjBhijypTqYKmjDICZj3UAjknlvT0DI8W/NyxFcoE59BNbioV fsA0wj+5DB/ZbBDA24BP76nSpyXVlvJtXBqqXDgt9/EDg0CvIT7fiDzKtukon6d9dKlO B/ztdo+s0ccq3vXD6i1UeaDO2HNbxVSq95ji91kkS/3IrWO1kho5RMJL7Z+oO+fpVQKy /ifonLTisp/7mvYh/Au+AiV2fGOx9c/KDW//cbopoFGTa4m/D8ud647EJ1AEO73tkbg9 apAQ== X-Gm-Message-State: AN3rC/6aUb15NllJw74f9iJxrK6U2znKxts58OYFdJR8Ekc2YI6olWWM HziL/CxCR1K+KYF/eDOEL8MqLgfo/OTZ X-Received: by 10.157.43.56 with SMTP id o53mr896267otb.97.1492663589330; Wed, 19 Apr 2017 21:46:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.120.72 with HTTP; Wed, 19 Apr 2017 21:46:28 -0700 (PDT) In-Reply-To: <096E2D4B-D7ED-4439-BB6F-7944892D2ACA@oracle.com> References: <096E2D4B-D7ED-4439-BB6F-7944892D2ACA@oracle.com> From: Brandon Long Date: Wed, 19 Apr 2017 21:46:28 -0700 Message-ID: To: Chris Newman Cc: "jmap@ietf.org" Content-Type: multipart/alternative; boundary=001a11c0c15e03494c054d91d390 Archived-At: Subject: Re: [Jmap] Submission X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 04:46:33 -0000 --001a11c0c15e03494c054d91d390 Content-Type: text/plain; charset=UTF-8 On Wed, Apr 19, 2017 at 12:29 PM, Chris Newman wrote: > The original IMAP designer always opposed adding submission to IMAP as a > matter of functional separation. While I strongly agree with the need for > functional specification, it is possible to design a protocol in such a way > that multiple separable functions are provided in the same protocol. As a > result I support adding submission to JMAP in a way that preserves > functional separation. > > 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. > > Furthermore, SMTP submission is a full standard IETF protocol that > continues to be extended. JMAP should leverage the semantics of the > existing standard in such a way that it's not necessary to change the JMAP > specification when a new submission extension that's useful to JMAP is > added. In addition to giving JMAP clients access to all the useful > submission extensions like FUTURERELASE, UTF8SMTP, DELIVERBY, etc. This > will ultimately make the JMAP specification simpler (as it won't have to > deal with submission extensions directly) and more flexible to deploy. > SMTPUTF8 I presume. > Finally, if JMAP supports submission then I expect a client author will > want to use the JMAP submission mechanism for all submissions. If JMAP has > a rigid design where each submission extension requires an additional JMAP > extension then a high-end client will eventually be forced to implement > SMTP submission in addition to JMAP submission. And it will be stuck doing > both (the former for functionality, the latter for ease-of-setup). I don't > want JMAP clients to be forced down that path. > Is there any proof that the majority of clients would bother? I realize that's the argument that's always been made about including submission in IMAP, but is there proof that the majority of clients used by people implement these? I mean, SMTPUTF8, sure, should be a requirement for jmap. What this means is that for JMAP to support submission correctly, it must > be able to function as an SMTP submission proxy from a semantic viewpoint. > This creates a number of requirements. The basic requirements are: > > 1. It must be possible to query the JMAP server for the set of Submission > ESMTP extensions semantically equivalent to the SMTP submission EHLO > response. The JMAP server needs to omit the extensions that aren't relevant > (e.g., AUTH, STARTTLS, PIPELINING). 2. It must be possible to provide an SMTP envelope for submission that is > semantically identical to the submission protocol. This needs to support > MAIL FROM, one or more RCPT TO, and ESMTP parameters to those envelope > components. There needs to be an algorithmic way to convert from JMAP > envelope syntax to SMTP Submission envelope syntax. > 3. It must be possible to get submission errors that are semantically > identical to those provided by a submission server. Including at least > 3-digit SMTP code, optionally enhanced SMTP code and human readable text of > error and potentially one response for mail from, one for each rcpt to and > one for data/bdat final response. > Why? > So that's the submission functionality JMAP needs to provide if it > provides submission at all. If you want to also provide a simpler model for > submission in JMAP, I won't object as long as the full model is mandatory. Maybe that's the simplest way to avoid the argument. Brandon --001a11c0c15e03494c054d91d390 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Apr 19, 2017 at 12:29 PM, Chris Newman <chris.newman@ora= cle.com> wrote:
The original IMAP designer always opposed adding submission to IMAP= as a matter of functional separation. While I strongly agree with the need= for functional specification, it is possible to design a protocol in such = a way that multiple separable functions are provided in the same protocol. = As a result I support adding submission to JMAP in a way that preserves fun= ctional separation.

When deploying a large mail service it's important to keep the submissi= on mail queues (which have management/monitoring issues) functionally separ= ate from the mail store (which has very different management/monitoring iss= ues). If the JMAP design requires a mail queue to be present on the JMAP se= rver or present in the mail store, that is an unacceptable protocol design = error as it hinders the manageability of large deployments.

Furthermore, SMTP submission is a full standard IETF protocol that continue= s to be extended. JMAP should leverage the semantics of the existing standa= rd in such a way that it's not necessary to change the JMAP specificati= on when a new submission extension that's useful to JMAP is added. In a= ddition to giving JMAP clients access to all the useful submission extensio= ns like FUTURERELASE, UTF8SMTP, DELIVERBY, etc. This will ultimately make t= he JMAP specification simpler (as it won't have to deal with submission= extensions directly) and more flexible to deploy.
SMTPUTF8 I presume.
=C2=A0
Finally, if JMAP supports submission then I expect a client author will wan= t to use the JMAP submission mechanism for all submissions. If JMAP has a r= igid design where each submission extension requires an additional JMAP ext= ension then a high-end client will eventually be forced to implement SMTP s= ubmission in addition to JMAP submission. And it will be stuck doing both (= the former for functionality, the latter for ease-of-setup). I don't wa= nt JMAP clients to be forced down that path.

Is there any proof that the majority of clients would bother?=C2=A0 I= realize that's the argument that's always been made about includin= g submission in IMAP, but is there proof that the majority of clients used = by people implement these?=C2=A0 I mean, SMTPUTF8, sure, should be a requir= ement for jmap.

What this means is that for JMAP to support submission correctly, it must b= e able to function as an SMTP submission proxy from a semantic viewpoint. T= his creates a number of requirements. The basic requirements are:

1. It must be possible to query the JMAP server for the set of Submission E= SMTP extensions semantically equivalent to the SMTP submission EHLO respons= e. The JMAP server needs to omit the extensions that aren't relevant (e= .g., AUTH, STARTTLS, PIPELINING).=C2=A0
2. It must be possible to provide an SMTP envelope for submission that is s= emantically identical to the submission protocol. This needs to support MAI= L FROM, one or more RCPT TO, and ESMTP parameters to those envelope compone= nts. There needs to be an algorithmic way to convert from JMAP envelope syn= tax to SMTP Submission envelope syntax.
3. It must be possible to get submission errors that are semantically ident= ical to those provided by a submission server. Including at least 3-digit S= MTP code, optionally enhanced SMTP code and human readable text of error an= d potentially one response for mail from, one for each rcpt to and one for = data/bdat final response.

Why?
=C2=A0
So that's the submission functionality JMAP needs to provide if it prov= ides submission at all. If you want to also provide a simpler model for sub= mission in JMAP, I won't object as long as the full model is mandatory.=

Maybe that's the simplest way to avoid= the argument.

Brandon
--001a11c0c15e03494c054d91d390-- From nobody Thu Apr 20 01:25:02 2017 Return-Path: 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 535CE12EB6D for ; Thu, 20 Apr 2017 01:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 8XPab9t-2cvO for ; Thu, 20 Apr 2017 01:24:58 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [122.56.26.1]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A46C12EB6B for ; Thu, 20 Apr 2017 01:24:56 -0700 (PDT) Received: From [192.168.1.146] (unverified [192.168.1.146]) by SMTP Server [192.168.1.3] (WinGate SMTP Receiver v9.0.5 (Build 5926)) with SMTP id <0001024507@smtp.qbik.com>; Thu, 20 Apr 2017 20:24:52 +1200 From: "Adrien de Croy" To: "Ted Lemon" , "Chris Newman" Cc: "jmap@ietf.org" Date: Thu, 20 Apr 2017 08:24:52 +0000 Message-Id: In-Reply-To: References: <096E2D4B-D7ED-4439-BB6F-7944892D2ACA@oracle.com> <89E217B2-A700-498C-BA72-3FD9939F34C7@fugue.com> Reply-To: "Adrien de Croy" User-Agent: eM_Client/7.0.27943.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MB53AEAAC2-A4A1-40FB-863B-2C02968509DA" Archived-At: Subject: Re: [Jmap] Submission X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 08:25:01 -0000 --------=_MB53AEAAC2-A4A1-40FB-863B-2C02968509DA Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable ------ Original Message ------ From: "Ted Lemon" To: "Chris Newman" Cc: "jmap@ietf.org" Sent: 20/04/2017 1:55:39 PM Subject: Re: [Jmap] Submission >On Apr 19, 2017, at 9:28 PM, Chris Newman =20 >wrote: >>To clarify my point, I think having an "outbox" with combined mail=20 >>store and mail queue semantics as a mandatory architectural element of= =20 >>JMAP is a protocol design error because it breaks functional=20 >>separation. And that violation of functional separation is=20 >>particularly problematic in larger deployments where mail stores and=20 >>mail queues each add management and monitoring complexity and require=20 >>different designs and storage models to scale effectively. >> >>JMAP needs to have a submission action that has semantics matching the= =20 >>IETF Submission standard. It's fine for that command to pull data from= =20 >>the mail store as part of the submission action (as RFC 4468 does).=20 >>But the JMAP protocol needs to allow implementations where mail queue=20 >>and mail store semantics are separate. > >Perhaps so. However, the semantics of submission protocols aren't=20 >really right either. What I think we want is to tell the MUA that=20 >delivery failed if it did, and to allow the MUA to know the current=20 >status of delivery at least at the first hop, if delivery is not yet=20 >complete. But the SMTP submit protocol doesn't do this. It's fire=20 >and forget: all you get is confirmation that the message has been=20 >queued. > >Granting that the point of this working group is not to fix SMTP, the=20 >semantics of the JMAP submit protocol ought to allow for delivery of=20 >failure status without generating a needless bounce message just as a=20 >place to put information from the site MTA's delivery attempt. If the= =20 >failure happens farther down the line in a forwarding chain, we can't=20 >do anything about it, but from a usability perspective bounce messages=20 >are worse than useless, so anything that can reduce the number of such=20 >messages that users see is a net win. I agree I'd love to see a mail client that does at least initial validation on=20 destination email addresses as they are added to the message, so that=20 errors in the addresses which can be resolved at that stage (e.g.=20 NXDOMAIN) can be raised with the email author before the mail is even=20 submitted. Due to DNS issues, this may need to be handled on the server, but could=20 be something as simple as an MX lookup, or something. Late bounce=20 messages relating to bad domain parts of an email address are=20 ridiculously user-unfriendly and we could do so much better. If we're doing a new mail protocol, we should be targeting the user=20 experience we want, rather than just whatever it takes to replicate what= =20 we have maybe with fewer configuration points. It should be possible in many cases to even give realtime updates about=20 the delivery status of the message whilst it's sitting in some folder=20 (whether that's outbox or sent) in the case where the JMAP server is=20 also the SMTP client for delivery upstream. I can imagine sitting at my desk after sending a mail, watching the=20 status icon on the message go from submitted to connecting to delivered=20 to destination mailbox. Why not consider something like some way to=20 give status updates back to the client for this kind of thing. People are moving away from SMTP to things like Facebook messaging due=20 to these sorts of reasons. They focused on user experience. If we=20 don't then we are wasting our time. Adrien > > >The point that I am arguing is that sent messages really do have a=20 >place in something that is notionally a mail store, and those messages=20 >serve as a place where delivery status can be found. Message=20 >submission should not be a transaction: it should be a process. =20 >Notification should work even if the MUA isn't present at the time of=20 >failure, and should be available in all MUAs, not just the sending MUA.= =20 >It should be presentable to the user in a way that makes sense. A=20 >"sent" folder makes sense. A separate queue construct does not. =20 >Forcing the MUA to fake this isn't going to produce a good user=20 >experience. > --------=_MB53AEAAC2-A4A1-40FB-863B-2C02968509DA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


------ Original Message ------
From: "Ted Lemon" <mellon@fugue= .com>
To: "Chris Newman" <Chri= s.Newman@oracle.com>
Cc: "jmap@ietf.org" <jmap@ietf.org= >
Sent: 20/04/2017 1:55:39 PM
Subject: Re: [Jmap] Submission

On Apr 19, 2017, at 9:28 PM, Chris Newman <Chris.Newman@oracle.com> wrote:
To clarify my point, I think having an "outbox" with combin= ed mail store and mail queue semantics as a mandatory architectural element= of JMAP is a protocol design error because it breaks functional separation= . And that violation of functional separation is particularly problematic= in larger deployments where mail stores and mail queues each add managemen= t and monitoring complexity and require different designs and storage model= s to scale effectively.

JMAP needs to= have a submission action that has semantics matching the IETF Submission= standard. It's fine for that command to pull data from the mail store as= part of the submission action (as RFC 4468 does). But the JMAP protocol= needs to allow implementations where mail queue and mail store semantics= are separate.

Perhaps so. =C2=A0 However, the semantics of submission protocols = aren't really right either. =C2=A0 What I think we want is to tell the MUA= that delivery failed if it did, and to allow the MUA to know the current= status of delivery at least at the first hop, if delivery is not yet compl= ete. =C2=A0 But the SMTP submit protocol doesn't do this. =C2=A0 It's fire= and forget: all you get is confirmation that the message has been queued.<= /div>

Granting that= the point of this working group is not to fix SMTP, the semantics of the= JMAP submit protocol ought to allow for delivery of failure status without= generating a needless bounce message just as a place to put information= from the site MTA's delivery attempt. =C2=A0 If the failure happens farthe= r down the line in a forwarding chain, we can't do anything about it, but= from a usability perspective bounce messages are worse than useless, so= anything that can reduce the number of such messages that users see is = a net win.
I agree
I'd love to= see a mail client that does at least initial validation on destination = email addresses as they are added to the message, so that errors in the = addresses which can be resolved at that stage (e.g. NXDOMAIN) can be raised= with the email author before the mail is even submitted.

Due to DNS issues, this may need to be handl= ed on the server, but could be something as simple as an MX lookup, or some= thing. =C2=A0Late bounce messages relating to bad domain parts of an email= address are ridiculously user-unfriendly and we could do so much better.

If we're doing a new mail= protocol, we should be targeting the user experience we want, rather than= just whatever it takes to replicate what we have maybe with fewer configur= ation points.
It should be= possible in many cases to even give realtime updates about the delivery= status of the message whilst it's sitting in some folder (whether that's= outbox or sent) in the case where the JMAP server is also the SMTP client= for delivery upstream.

I = can imagine sitting at my desk after sending a mail, watching the status= icon on the message go from submitted to connecting to delivered to destin= ation mailbox. =C2=A0Why not consider something like some way to give statu= s updates back to the client for this kind of thing.=C2=A0

People are moving away from SMTP to things= like Facebook messaging due to these sorts of reasons. =C2=A0They focused= on user experience. =C2=A0If we don't then we are wasting our time.
<= div id=3D"x806040390875452" style=3D"word-wrap: break-word; -webkit-nbsp-mo= de: space; -webkit-line-break: after-white-space;">
Adrien



The point that I am arguing is that sent messages really= do have a place in something that is notionally a mail store, and those= messages serve as a place where delivery status can be found. =C2=A0 Messa= ge submission should not be a transaction: it should be a process. =C2=A0= Notification should work even if the MUA isn't present at the time of fail= ure, and should be available in all MUAs, not just the sending MUA. It shou= ld be presentable to the user in a way that makes sense. =C2=A0 A "sent"= folder makes sense. =C2=A0 A separate queue construct does not. =C2=A0 = Forcing the MUA to fake this isn't going to produce a good user experience.=

--------=_MB53AEAAC2-A4A1-40FB-863B-2C02968509DA-- From nobody Thu Apr 20 07:18:17 2017 Return-Path: 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 C27E2129537 for ; Thu, 20 Apr 2017 07:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 Ia-GeMM585wC for ; Thu, 20 Apr 2017 07:18:14 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D3D7129548 for ; Thu, 20 Apr 2017 07:18:14 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id y63so17105661qkd.1 for ; Thu, 20 Apr 2017 07:18:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=9acegeZMADAdSNREniKURgt23rHYd5rNAfJMbujWCmU=; b=b4dVGGxEnDiz/UvRzGOfBqEKWMT+XZtOhFUBI86YT5+/Vn+chVt0YP/rAOSaFKD9x+ E48U3d7t7M/AvQ4f+M4OEByXIscFlBARHv5ZFJYERD4M7ZFcy4ApHPXHx9rCmFfLHHWJ vU9tj/Xx7HXKf+DspgoUqujprTQbXUdirV2WNPSVOnTJCL/tCq8Vs9A9U3Bya5SUH5Qa tn/FenWlvYMU00RcHsfZLK9w4YFnyhQ7SAMIiUQGGZ+kEDpAiLAhmkyjdjSUr1PWHUi7 0ALkx4b/i9YIU1I2UqvtQkkRIMImDuIDkSzPAYv/U1O50tLTE5srnABQeyj+4dZRmv5u dcuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=9acegeZMADAdSNREniKURgt23rHYd5rNAfJMbujWCmU=; b=Rj1aEwWoMCukMWkTRhVCuwVTxT6G9fv1WTry8g5EZRGkV+DjMzMTibCdDJTaYGdZrg +u6I2w+vd6RynqByUod2Bjt6VWhXMNwLVSPwds0MPRXqdWvie0KNjq03zgS236+GcpJ9 fCu6b59gquCEyeRmguBJAKJJjjufUEelG6mDanzUlC8mTrvniCPJKTzfQ4rMaFSj6X3s xePzbkKdyeFEaL92q8QdIbVcXsRf6VEYUORKRS1JBomCCO7qGt9gpkKnbNjHkmrL1qw9 0JhS/UKIoDgaILWPDkPQO38q3spSRTAoclmXKK6InVGNg7Gv31Um78RXBe7jc8uFzdiY D7Rw== X-Gm-Message-State: AN3rC/41HjCkES02zd8b4v+PQycKJ/QXAUZPSUYKvvQASeecuuuHc6lo B4ELt/9jyOV1bQ== X-Received: by 10.55.20.161 with SMTP id 33mr5164585qku.321.1492697893169; Thu, 20 Apr 2017 07:18:13 -0700 (PDT) Received: from [10.0.20.228] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id t45sm2605235qtt.9.2017.04.20.07.18.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Apr 2017 07:18:12 -0700 (PDT) From: Ted Lemon Message-Id: <38570AF7-DC45-4F12-AB78-F2E6C41ECC53@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_1FCE6475-E461-4402-8D51-3D34ACC11B18" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 20 Apr 2017 10:18:10 -0400 In-Reply-To: Cc: Chris Newman , Alexey Melnikov , "jmap@ietf.org" To: Brandon Long References: <096E2D4B-D7ED-4439-BB6F-7944892D2ACA@oracle.com> <89E217B2-A700-498C-BA72-3FD9939F34C7@fugue.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Jmap] Submission X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 14:18:16 -0000 --Apple-Mail=_1FCE6475-E461-4402-8D51-3D34ACC11B18 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 20, 2017, at 12:36 AM, Brandon Long wrote: > I often considered something like that for Gmail, as it eliminates the = confusion people often have that a message may be pending in our mail = queues for days. It does require a fairly integrated system, however. That seems like a good thing. In any case, if the facility is present = in the spec and is the standard way that MUAs communicate about = messages, then whether or not this integration happens really comes down = to quality of implementation. If integration is possible, the UX will = be better; if it is not, it will still be perfectly adequate. --Apple-Mail=_1FCE6475-E461-4402-8D51-3D34ACC11B18 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Apr 20, 2017, at 12:36 AM, Brandon Long <blong@google.com> = wrote:
I = often considered something like that for Gmail, as it eliminates the = confusion people often have that a message may be pending in our mail = queues for days.  It does require a fairly integrated system, = however.

That seems = like a good thing.   In any case, if the facility is present in the = spec and is the standard way that MUAs communicate about messages, then = whether or not this integration happens really comes down to quality of = implementation.   If integration is possible, the UX will be = better; if it is not, it will still be perfectly adequate.


= --Apple-Mail=_1FCE6475-E461-4402-8D51-3D34ACC11B18-- From nobody Thu Apr 20 13:56:57 2017 Return-Path: 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 03883126C22 for ; Thu, 20 Apr 2017 13:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 XoUM6YB9eQkC for ; Thu, 20 Apr 2017 13:56:54 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1943D131687 for ; Thu, 20 Apr 2017 13:56:52 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v3KKunju016003 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 20 Apr 2017 20:56:50 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v3KKunAM003266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 20 Apr 2017 20:56:49 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v3KKunfa021608; Thu, 20 Apr 2017 20:56:49 GMT Received: from [192.168.15.59] (/66.214.236.56) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 20 Apr 2017 13:56:49 -0700 From: "Chris Newman" To: "Brandon Long" Cc: "jmap@ietf.org" Date: Thu, 20 Apr 2017 13:56:48 -0700 Message-ID: <63880E85-93FF-4ADD-8E03-E9CBD6DE5F5B@oracle.com> In-Reply-To: References: <096E2D4B-D7ED-4439-BB6F-7944892D2ACA@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Subject: Re: [Jmap] Submission X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 20:56:56 -0000 On 19 Apr 2017, at 21:46, Brandon Long wrote: > On Wed, Apr 19, 2017 at 12:29 PM, Chris Newman > > wrote: >> Finally, if JMAP supports submission then I expect a client author >> will >> want to use the JMAP submission mechanism for all submissions. If >> JMAP has >> a rigid design where each submission extension requires an additional >> JMAP >> extension then a high-end client will eventually be forced to >> implement >> SMTP submission in addition to JMAP submission. And it will be stuck >> doing >> both (the former for functionality, the latter for ease-of-setup). I >> don't >> want JMAP clients to be forced down that path. > > Is there any proof that the majority of clients would bother? I > realize > that's the argument that's always been made about including submission > in > IMAP, but is there proof that the majority of clients used by people > implement these? Of course there is no proof related to future actions of third parties. But semantic equivalent guarantees the problem won't happen. > I mean, SMTPUTF8, sure, should be a requirement for jmap. I'm unsure we should require all JMAP servers to support SMTPUTF8. I presently don't have strong feelings one way or the other, but I think there are a number of important tradeoffs that should be understood to inform the decision. >> What this means is that for JMAP to support submission correctly, it >> must >> be able to function as an SMTP submission proxy from a semantic >> viewpoint. >> This creates a number of requirements. The basic requirements are: >> >> 1. It must be possible to query the JMAP server for the set of >> Submission >> ESMTP extensions semantically equivalent to the SMTP submission EHLO >> response. The JMAP server needs to omit the extensions that aren't >> relevant >> (e.g., AUTH, STARTTLS, PIPELINING). >> 2. It must be possible to provide an SMTP envelope for submission >> that is >> semantically identical to the submission protocol. This needs to >> support >> MAIL FROM, one or more RCPT TO, and ESMTP parameters to those >> envelope >> components. There needs to be an algorithmic way to convert from JMAP >> envelope syntax to SMTP Submission envelope syntax. >> 3. It must be possible to get submission errors that are semantically >> identical to those provided by a submission server. Including at >> least >> 3-digit SMTP code, optionally enhanced SMTP code and human readable >> text of >> error and potentially one response for mail from, one for each rcpt >> to and >> one for data/bdat final response. > > Why? These three requirements would give JMAP semantic equivalence to standard IETF Submission, which preserves functional separation (improving scalability and security/privacy models), and simplifies deployment in sites with existing submit servers (which is presently all sites). I don't think 1 or 2 should be controversial. Some debate about item 3 may be appropriate. >> So that's the submission functionality JMAP needs to provide if it >> provides submission at all. If you want to also provide a simpler >> model for >> submission in JMAP, I won't object as long as the full model is >> mandatory. > > Maybe that's the simplest way to avoid the argument. Debating the technical tradeoffs between different proposals is an important part of getting a good standard. If you think I'm wrong, it'd be good to explain the alternate viewpoint and technical reasoning behind that viewpoint. As I work on server software products, I tend to have some server bias in designs but I recognize there are tradeoffs between ease-of-development/ease-of-deployment for server vs. client software. As a long time IETF participant, I also view IMAP+Submission+standard-extensions as the starting point for JMAP design. That's a different viewpoint from people who view the problem entirely from the client viewpoint and ignore the constraints of presently deployed infrastructure. A good JMAP standard should probably end up somewhere in the middle. - Chris From nobody Thu Apr 20 14:56:05 2017 Return-Path: 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 57E701316D4 for ; Thu, 20 Apr 2017 14:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 zPrsBs-Gp1OZ for ; Thu, 20 Apr 2017 14:56:00 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [122.56.26.1]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BA3B1316CE for ; Thu, 20 Apr 2017 14:55:59 -0700 (PDT) Received: From [192.168.1.146] (unverified [192.168.1.146]) by SMTP Server [192.168.1.3] (WinGate SMTP Receiver v9.0.5 (Build 5926)) with SMTP id <0001025297@smtp.qbik.com>; Fri, 21 Apr 2017 09:55:56 +1200 From: "Adrien de Croy" To: "Chris Newman" , "Brandon Long" Cc: "jmap@ietf.org" Date: Thu, 20 Apr 2017 21:55:56 +0000 Message-Id: In-Reply-To: <63880E85-93FF-4ADD-8E03-E9CBD6DE5F5B@oracle.com> References: <096E2D4B-D7ED-4439-BB6F-7944892D2ACA@oracle.com> <63880E85-93FF-4ADD-8E03-E9CBD6DE5F5B@oracle.com> Reply-To: "Adrien de Croy" User-Agent: eM_Client/7.0.27943.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Jmap] Submission X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 21:56:03 -0000 My first impression is that if we considered the entire gamut of ESMTP=20 submission extensions, most would not be relevant for the client, and=20 therefore most would not need to be reflected in JMAP. The client should not care if the payload is sent chunked, whether the=20 next hop server supports pipelining. The only extensions would relate=20 to the things the client needs to know in order to emit a properly=20 formed message and envelope. If we make delivery status updates a core=20 (and mandatory) part of JMAP, whether the upstream SMTP infrastructure=20 can support it or not is not particularly important. The JMAP server=20 can provide something regardless, and in a tightly-integrated system=20 (e.g. one JMAP client sending mail to another on the same server) then=20 the user experience can be excellent. Even things like 8BITMIME should=20 be the default, mandatory in the client<->JMAP server and if the=20 upstream SMTP system needs to redo the message then that's what it needs= =20 to do. It's ridiculous we are still bound to a 7-bit-compatible mail=20 transport where the only machines now that are 7 bit are in museums. I think it would be a shame to get hung up on non-necessary SMTP=20 extensions and use that as a justification to not progress on=20 improvements. We need to be sure that we have a realistic but useful=20 set of minimum requirements which safeguard an excellent user=20 experience, because we need to do better than what is currently there or= =20 this will not be adopted. Adrien ------ Original Message ------ From: "Chris Newman" To: "Brandon Long" Cc: "jmap@ietf.org" Sent: 21/04/2017 8:56:48 AM Subject: Re: [Jmap] Submission >On 19 Apr 2017, at 21:46, Brandon Long wrote: >>On Wed, Apr 19, 2017 at 12:29 PM, Chris Newman=20 >> >>wrote: >>>Finally, if JMAP supports submission then I expect a client author=20 >>>will >>>want to use the JMAP submission mechanism for all submissions. If=20 >>>JMAP has >>>a rigid design where each submission extension requires an additional= =20 >>>JMAP >>>extension then a high-end client will eventually be forced to=20 >>>implement >>>SMTP submission in addition to JMAP submission. And it will be stuck=20 >>>doing >>>both (the former for functionality, the latter for ease-of-setup). I=20 >>>don't >>>want JMAP clients to be forced down that path. >> >>Is there any proof that the majority of clients would bother? I=20 >>realize >>that's the argument that's always been made about including submission= =20 >>in >>IMAP, but is there proof that the majority of clients used by people >>implement these? > >Of course there is no proof related to future actions of third parties.= =20 >But semantic equivalent guarantees the problem won't happen. > >>I mean, SMTPUTF8, sure, should be a requirement for jmap. > >I'm unsure we should require all JMAP servers to support SMTPUTF8. I=20 >presently don't have strong feelings one way or the other, but I think=20 >there are a number of important tradeoffs that should be understood to=20 >inform the decision. > >>>What this means is that for JMAP to support submission correctly, it=20 >>>must >>>be able to function as an SMTP submission proxy from a semantic=20 >>>viewpoint. >>>This creates a number of requirements. The basic requirements are: >>> >>>1. It must be possible to query the JMAP server for the set of=20 >>>Submission >>>ESMTP extensions semantically equivalent to the SMTP submission EHLO >>>response. The JMAP server needs to omit the extensions that aren't=20 >>>relevant >>>(e.g., AUTH, STARTTLS, PIPELINING). >>>2. It must be possible to provide an SMTP envelope for submission=20 >>>that is >>>semantically identical to the submission protocol. This needs to=20 >>>support >>>MAIL FROM, one or more RCPT TO, and ESMTP parameters to those=20 >>>envelope >>>components. There needs to be an algorithmic way to convert from JMAP >>>envelope syntax to SMTP Submission envelope syntax. >>>3. It must be possible to get submission errors that are semantically >>>identical to those provided by a submission server. Including at=20 >>>least >>>3-digit SMTP code, optionally enhanced SMTP code and human readable=20 >>>text of >>>error and potentially one response for mail from, one for each rcpt=20 >>>to and >>>one for data/bdat final response. >> >>Why? > >These three requirements would give JMAP semantic equivalence to=20 >standard IETF Submission, which preserves functional separation=20 >(improving scalability and security/privacy models), and simplifies=20 >deployment in sites with existing submit servers (which is presently=20 >all sites). I don't think 1 or 2 should be controversial. Some debate=20 >about item 3 may be appropriate. > >>>So that's the submission functionality JMAP needs to provide if it >>>provides submission at all. If you want to also provide a simpler=20 >>>model for >>>submission in JMAP, I won't object as long as the full model is=20 >>>mandatory. >> >>Maybe that's the simplest way to avoid the argument. > >Debating the technical tradeoffs between different proposals is an=20 >important part of getting a good standard. If you think I'm wrong, it'd= =20 >be good to explain the alternate viewpoint and technical reasoning=20 >behind that viewpoint. As I work on server software products, I tend to= =20 >have some server bias in designs but I recognize there are tradeoffs=20 >between ease-of-development/ease-of-deployment for server vs. client=20 >software. As a long time IETF participant, I also view=20 >IMAP+Submission+standard-extensions as the starting point for JMAP=20 >design. That's a different viewpoint from people who view the problem=20 >entirely from the client viewpoint and ignore the constraints of=20 >presently deployed infrastructure. A good JMAP standard should probably= =20 >end up somewhere in the middle. > > - Chris > >_______________________________________________ >Jmap mailing list >Jmap@ietf.org >https://www.ietf.org/mailman/listinfo/jmap From nobody Thu Apr 20 17:13:56 2017 Return-Path: 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 7AECB129B75 for ; Thu, 20 Apr 2017 17:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no 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 ULJDxZN4Tf80 for ; Thu, 20 Apr 2017 17:13:53 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 644E2120326 for ; Thu, 20 Apr 2017 17:13:53 -0700 (PDT) Received: (qmail 70057 invoked from network); 21 Apr 2017 00:13:51 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 21 Apr 2017 00:13:51 -0000 Date: 21 Apr 2017 00:13:29 -0000 Message-ID: <20170421001329.24963.qmail@ary.lan> From: "John Levine" To: jmap@ietf.org Cc: adrien@qbik.com In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Jmap] Submission X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 00:13:54 -0000 In article you write: > >My first impression is that if we considered the entire gamut of ESMTP >submission extensions, most would not be relevant for the client, and >therefore most would not need to be reflected in JMAP. I haven't heard anyone demand that JMAP support every SMTP extension. That would be ridiculous -- no SMTP or submission server supports them all, either. But what we do need is an architecture that can pass through whatever extensions the server wants to support, without needing to revise JMAP each time there's a new extension. > Even things like 8BITMIME should be the default, mandatory in the > client<->JMAP server and if the upstream SMTP system needs to redo > the message then that's what it needs to do. Those of us who apply DKIM signatures would be very unhappy with that misdesign. Sure, an MUA on a phone isn't likely to do that, but consider my example of list management software running through JMAP, they do it all the time. R's, John From nobody Thu Apr 20 17:17:28 2017 Return-Path: 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 5A191129B75 for ; Thu, 20 Apr 2017 17:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no 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 qwR0pPPPKhCi for ; Thu, 20 Apr 2017 17:17:25 -0700 (PDT) Received: from miucha.iecc.com (w6.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DD1D12946E for ; Thu, 20 Apr 2017 17:17:25 -0700 (PDT) Received: (qmail 70599 invoked from network); 21 Apr 2017 00:17:24 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 21 Apr 2017 00:17:24 -0000 Date: 21 Apr 2017 00:17:02 -0000 Message-ID: <20170421001702.24991.qmail@ary.lan> From: "John Levine" To: jmap@ietf.org Cc: adrien@qbik.com In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Jmap] Submission X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 00:17:26 -0000 In article you write: >I'd love to see a mail client that does at least initial validation on >destination email addresses as they are added to the message, so that >errors in the addresses which can be resolved at that stage (e.g. >NXDOMAIN) can be raised with the email author before the mail is even >submitted. This is quite the can of worms. It's easy enough to look up a domain and see if it has an A or an MX, but whatever you were planning to do to validate mailboxes will get you blacklisted as a listwashing spammer. Once again, I really do not think this is the time or place to try and fix all of SMTP's faults. R's, John From nobody Thu Apr 20 20:28:11 2017 Return-Path: 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 04DB61293FF for ; Thu, 20 Apr 2017 20:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.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 LgxJJoNzy_xH for ; Thu, 20 Apr 2017 20:28:09 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA7F31205F1 for ; Thu, 20 Apr 2017 20:28:08 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QDEV2TF1PS000VZ5@mauve.mrochek.com> for jmap@ietf.org; Thu, 20 Apr 2017 20:23:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1492744982; bh=bH7ExEkqQT3FOSobx5KF58cTyHoneb0F8k98gen//a8=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=hZYF5DcIHy8TKs4Rq1YL6EckG/cdSAUw2w1R+w68ofKj4Xpag080AXfEjGD+BDAVw oTCKmBFIUKb/RPqDBzE8qe2wbQtjQkvLjOiAnGQWaXPGRjCnS1ie2kswOw6FcHzhrW bGs60A7PGFs5S7hBRz4LXykHddhWnLiK6Z8Qo1Lk= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QDELNEAKJK00005O@mauve.mrochek.com>; Thu, 20 Apr 2017 20:22:58 -0700 (PDT) Cc: Daniel Kahn Gillmor , jmap@ietf.org Message-id: <01QDEV2QM6XC00005O@mauve.mrochek.com> Date: Thu, 20 Apr 2017 20:06:57 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 19 Apr 2017 14:04:40 -0400" References: <20170419163429.8556.qmail@ary.lan> <87d1c873cf.fsf@fifthhorseman.net> To: John R Levine Archived-At: Subject: Re: [Jmap] Submission X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 03:28:10 -0000 > > I think you've convinced me that while it is surely easy to write a > > server-side envelope synthesizer, it looks hard to write a high-quality > > and robust server-side envelope sythesizer. > Right, and even then, if a client can't put parameters on the envelope, > it's not going to be very satisfactory. On the other hand, if you do have > an explicit envelope with parameters, a lot of other stuff falls out > naturally. > For example, the marinate* option that people were arguing about is the > FUTURERELEASE extension defined in RFC 4865. with the HOLDFOR and > HOLDUNTIL parameters. No need to invent anything, it's already there. > I hope Ned Freed weighs in here, since he's done more hand to hand combat > with this stuff than anyone. I'm following the discussion, but I really have had nothing substantive to add to what you and Chris Newman have already said. In regards to envelope synthesizers, I guess I should note that we find we have to tweak ours fairly regularly to keep up with interesting new ways various pieces of software manage to implement someting other than RFC 5322. So not only is writing a good one difficult, it's something you never really finish. And since you've brought up the FUTURERELEASE SUBMIT extension, it's worth pointing out the fundamental incompatibility between, on the one hand, people saying that the "marinate until", aka FUTURERELEASE, capability is highly desireable and widely used and other people saying that there are no SUBMIT extensions worth considering. More generally, the only difference between a JMAP capability tied to, say, a magic header and a SUBMIT extension is syntax. But if you specify things in a way that makes it difficult to map from one to the other, you'll pay the price for that as long as either protocols continue to evolve - and that's going to be a long time. Ned From nobody Thu Apr 20 23:16:50 2017 Return-Path: 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 E0352127B52 for ; Thu, 20 Apr 2017 23:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 bUNEWBAogCui for ; Thu, 20 Apr 2017 23:16:46 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [122.56.26.1]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E81B127599 for ; Thu, 20 Apr 2017 23:16:45 -0700 (PDT) Received: From [192.168.1.146] (unverified [192.168.1.146]) by SMTP Server [192.168.1.3] (WinGate SMTP Receiver v9.0.5 (Build 5926)) with SMTP id <0001025720@smtp.qbik.com>; Fri, 21 Apr 2017 18:16:42 +1200 From: "Adrien de Croy" To: "John Levine" , "jmap@ietf.org" Date: Fri, 21 Apr 2017 06:16:42 +0000 Message-Id: In-Reply-To: <20170421001702.24991.qmail@ary.lan> References: <20170421001702.24991.qmail@ary.lan> Reply-To: "Adrien de Croy" User-Agent: eM_Client/7.0.27943.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Jmap] Submission X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 06:16:49 -0000 ------ Original Message ------ From: "John Levine" To: "jmap@ietf.org" Cc: "adrien@qbik.com" Sent: 21/04/2017 12:17:02 PM Subject: Re: [Jmap] Submission >In article you write: >>I'd love to see a mail client that does at least initial validation on >>destination email addresses as they are added to the message, so that >>errors in the addresses which can be resolved at that stage (e.g. >>NXDOMAIN) can be raised with the email author before the mail is even >>submitted. > >This is quite the can of worms. It's easy enough to look up a domain >and see if it has an A or an MX, but whatever you were planning to do >to validate mailboxes will get you blacklisted as a listwashing >spammer. sure, I think there are fundamental issues with trying to go further=20 than an A/MX for now, but if we built in a mechanism to verify=20 addresses, it could be extended later, rather than being blocked off for= =20 all of eternity. Even A/MX would have some value. Who knows what kind of trusted mail=20 delivery infrastructure may come out in the future, at some stage we=20 have to fix SMTP. Forever is a long time. Adrien > > >Once again, I really do not think this is the time or place to try and >fix all of SMTP's faults. > >R's, >John > >_______________________________________________ >Jmap mailing list >Jmap@ietf.org >https://www.ietf.org/mailman/listinfo/jmap From nobody Thu Apr 20 23:25:54 2017 Return-Path: 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 C710A12941C for ; Thu, 20 Apr 2017 23:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 AOlGi70huNNA for ; Thu, 20 Apr 2017 23:25:51 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [122.56.26.1]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25B0E12869B for ; Thu, 20 Apr 2017 23:25:50 -0700 (PDT) Received: From [192.168.1.146] (unverified [192.168.1.146]) by SMTP Server [192.168.1.3] (WinGate SMTP Receiver v9.0.5 (Build 5926)) with SMTP id <0001025725@smtp.qbik.com>; Fri, 21 Apr 2017 18:25:48 +1200 From: "Adrien de Croy" To: "John Levine" , "jmap@ietf.org" Date: Fri, 21 Apr 2017 06:25:48 +0000 Message-Id: In-Reply-To: <20170421001329.24963.qmail@ary.lan> References: <20170421001329.24963.qmail@ary.lan> Reply-To: "Adrien de Croy" User-Agent: eM_Client/7.0.27943.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Jmap] Submission X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 06:25:54 -0000 ------ Original Message ------ From: "John Levine" To: "jmap@ietf.org" Cc: "adrien@qbik.com" Sent: 21/04/2017 12:13:29 PM Subject: Re: [Jmap] Submission >In article you write: >> >>My first impression is that if we considered the entire gamut of ESMTP >>submission extensions, most would not be relevant for the client, and >>therefore most would not need to be reflected in JMAP. > >I haven't heard anyone demand that JMAP support every SMTP extension. >That would be ridiculous -- no SMTP or submission server supports them >all, either. > >But what we do need is an architecture that can pass through whatever >extensions the server wants to support, without needing to revise JMAP >each time there's a new extension. which server? The upstream SMTP one? I think trying to pass through SMTP extensions when there may not even=20 be an upstream SMTP server is going to be problematic let alone ugly. Which extensions do we think are even in scope for this? > > >> Even things like 8BITMIME should be the default, mandatory in the >> client<->JMAP server and if the upstream SMTP system needs to redo >> the message then that's what it needs to do. > >Those of us who apply DKIM signatures would be very unhappy with that >misdesign. Sure, an MUA on a phone isn't likely to do that, but >consider my example of list management software running through JMAP, >they do it all the time. So in 100 years we will still be using the 7-bit limbo pole everyone has= =20 to go under We need to move past the 1960s. When will we abandon 7-bit? Sounds like DKIM didn't think through the need to transform mail. What=20 does a server do right now when an SMTP server needs to send 8bit mail=20 to a server that doesn't advertise 8BITMIME? Bounce it? There should be= =20 a lossless transform that DKIM could cope with. I suspect many MTAs will happily accept binary mail, but just don't=20 advertise 8BITMIME because all the other requirements were far too=20 onerous. Adrien > > >R's, >John > >_______________________________________________ >Jmap mailing list >Jmap@ietf.org >https://www.ietf.org/mailman/listinfo/jmap From nobody Fri Apr 21 00:09:19 2017 Return-Path: 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 F0935129450 for ; Fri, 21 Apr 2017 00:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.52 X-Spam-Level: X-Spam-Status: No, score=-0.52 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 ubYJ8LHwKcrI for ; Fri, 21 Apr 2017 00:09:15 -0700 (PDT) Received: from mx2.sitnet.dk (mx2.sitnet.dk [188.64.157.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C46C6126C83 for ; Fri, 21 Apr 2017 00:09:15 -0700 (PDT) From: Mads Hjorth To: "jmap@ietf.org" CC: =?utf-8?B?QW5kZXJzIEZhdXNiw7hsbA==?= Thread-Topic: Is the group address syntax from RFC5322 really not supported in JMAP? Thread-Index: AQHSum4u3LxJGk1GVkyRIh+MrvZ48g== Date: Fri, 21 Apr 2017 07:09:13 +0000 Message-ID: Reply-To: Mads Hjorth Accept-Language: da-DK, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Received-SPF: none Archived-At: Subject: [Jmap] Is the group address syntax from RFC5322 really not supported in JMAP? X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 07:09:18 -0000 SEksIA0KDQpJIGhhdmUgYW4gZXllIG9uIEpNQVAgZm9yIHRoZSB1c2UgaW4gYSByYXRoZXIgbGFy Z2Ugc2NhbGUgbWVzc2FnaW5nIHN5c3RlbSAoKzUgbWlsbGlvbiBtYWlsYm94ZXMpLg0KDQpJbiBv bmUgb2Ygb3VyIHVzZSBjYXNlcywgd2Ugd2FudCB0byBzZW5kIG1lc3NhZ2VzIHRvIGFuIG5hbWVk IGdyb3VwLCBhbGxvd2luZyB0aGUgcmVjaXBpZW50IHRvIHNlZSB0aGUgbmFtZSBvZiB0aGUgZ3Jv dXAsIGJ1dCBub3QgdGhlIGlkZW50aXR5IG9mIHRoZSBtZW1iZXJzLiBXZSBjb25zaWRlciB1c2lu ZyB0aGUgUkZDNTMyMiBzeW50YXggZm9yIHRoaXMgZS5nLiANCg0KVG86IFRlZW5hZ2UgTXV0YW50 IE5pbmphIFR1cnRsZXM6Ow0KQmNjOiDigJxMZW9uYXJkb+KAnSA8bGVvQGV4YW1wbGUuY29tPiwg 4oCcRG9uYXRlbGxv4oCdIDxkb25AZXhhbXBsZS5jb20+DQoNCkJ1dCB0aGUgY3VycmVudCBKTUFQ IHN0YXRlcyANCg0KPiBHcm91cCBpbmZvcm1hdGlvbiBhbmQgY29tbWVudHMgZnJvbSB0aGUgUkZD IDUzMjIgaGVhZGVyIE1VU1QgYmUgZGlzY2FyZGVkIHdoZW4gY29udmVydGluZyBpbnRvIGFuIEVt YWlsZXIgb2JqZWN0Lg0KDQpBbmQgSSBkb27igJl0IHNlZSBhIG1vdGl2YXRpb24gZm9yIHRoZSBk aXZlcnNpb24gZnJvbSB0aGUgUkZDLiANCg0KSXMgaXQgaGFyZCB0byBpbXBsZW1lbnQ/IE5ldmVy IHVzZWQ/IG9yIGlzIHRoZXJlIGFub3RoZXIgZ29vZCBleHBsYW5hdGlvbj8NCg0KDQogICAgICAg ICAgIOKAoA0KICAgICAgICBbWyBvIF1dDQogICAgICAgICAqKioqKg0KRElHSVRBTElTRVJJTkdT U1RZUkVMU0VODQoNCk1hZHMgSGpvcnRoDQpDaGVma29uc3VsZW50DQoNCnRlbDorNDU0MTc4MjM1 MQ0KbWFpbHRvOm1hZHNoQGRpZ3N0LmRrDQpodHRwOi8vd3d3LmRpZ3N0LmRrDQoNCiJJIHdvdWxk IGhhdmUgZ290IHJpZCBvZiB0aGUgc2xhc2ggc2xhc2ggDQogYWZ0ZXIgdGhlIGNvbG9uLiBZb3Ug ZG9uJ3QgcmVhbGx5IG5lZWQgaXQuIA0KIEl0IGp1c3Qgc2VlbWVkIGxpa2UgYSBnb29kIGlkZWEg YXQgdGhlIHRpbWUuIiANCg0KLSBUaW0gQmVybmVycy1MZWUNCg0KDQoNCg== From nobody Fri Apr 21 01:31:41 2017 Return-Path: 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 4B1C3129438 for ; Fri, 21 Apr 2017 01:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 loEYyKcP7y0a for ; Fri, 21 Apr 2017 01:31:38 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id AE9B4126CC7 for ; Fri, 21 Apr 2017 01:31:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1492763497; d=isode.com; s=june2016; i=@isode.com; bh=eWapbGkgt8w/+YFhymrMbf45a33l9GbFrVPUkKx1KME=; 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=BBBOVjOL70u7VrHyXz4kxykYba0OBgU+D8YDGKoJGpRyHhAOhuX3UJRTNsVVSfzxPFigVo Ue+4rLCh8GIMCfQKHXpU0Rt+tW3Kgj5twcjjWOdOpAEY7aNYcoKhXXf8WU+xgISBtKFS59 T+JqbgqeuhucgA1xOlvS5SHn43lBeRo=; Received: from [10.1.0.228] ((unknown) [85.255.237.155]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 21 Apr 2017 09:31:37 +0100 X-SMTP-Protocol-Errors: NORDNS PIPELINING From: Alexey Melnikov X-Mailer: iPhone Mail (13G35) In-Reply-To: Date: Fri, 21 Apr 2017 09:46:56 +0100 Cc: "jmap@ietf.org" , =?utf-8?Q?Anders_Fausb=C3=B8ll?= Message-Id: <66B256FE-E331-4319-A11A-570D0AF6E618@isode.com> References: To: Mads Hjorth MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Jmap] Is the group address syntax from RFC5322 really not supported in JMAP? X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 08:31:40 -0000 > On 21 Apr 2017, at 08:09, Mads Hjorth wrote: >=20 > HI,=20 >=20 > I have an eye on JMAP for the use in a rather large scale messaging system= (+5 million mailboxes). >=20 > In one of our use cases, we want to send messages to an named group, allow= ing the recipient to see the name of the group, but not the identity of the m= embers. We consider using the RFC5322 syntax for this e.g.=20 >=20 > To: Teenage Mutant Ninja Turtles:; > Bcc: =93Leonardo=94 , =93Donatello=94 >=20 > But the current JMAP states=20 >=20 >> Group information and comments from the RFC 5322 header MUST be discarded= when converting into an Emailer object. >=20 > And I don=92t see a motivation for the diversion from the RFC.=20 I noticed lack of this in my review as well and I would like to see this sup= ported. > Is it hard to implement? Never used? or is there another good explanation?= >=20 >=20 > =86 > [[ o ]] > ***** > DIGITALISERINGSSTYRELSEN >=20 > Mads Hjorth > Chefkonsulent >=20 > tel:+4541782351 > mailto:madsh@digst.dk > http://www.digst.dk >=20 > "I would have got rid of the slash slash=20 > after the colon. You don't really need it.=20 > It just seemed like a good idea at the time."=20 >=20 > - Tim Berners-Lee >=20 >=20 >=20 > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap From nobody Fri Apr 21 06:44:02 2017 Return-Path: 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 3B3A1127077 for ; Fri, 21 Apr 2017 06:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 Y1eWZIon4onM for ; Fri, 21 Apr 2017 06:43:59 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C5B71205F1 for ; Fri, 21 Apr 2017 06:43:59 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id d80so7201410qke.3 for ; Fri, 21 Apr 2017 06:43:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=y5jUCrwkFpnHODxuP87YQi+Hp70YGm5TI7UEzLThx+c=; b=rFD5PGhukLijqy1lk8AAP4DZ7ewTMGQA78LBLi65Uh8ylUphHGf52gRZUAonYOxfx1 ju6PWMnftl+Lt+yXaVWUBY+mH7uVvg+/I79sHSDYQOG89C1GxbxvjfvrBkbZK7vYdhZT sTiazZD31TJNOeBWkSlnFw6VrUw6Kdi5Q3D1q1ePkXFqrBH4HdepJ0BiJApu+2CbuN1b ozEfyZOSuIaZtYsA/PZpHCRR1q6r0yf7Z4SdAJz05mVOmANjzE80jZ//QKWbkzL5u0YT kfldBnFVW6hcNE+Wf8kDsN8lWAARVYSSWxXte8V9l4Iy2AE8OgFyAb5rfRDD/OdGQB+G nbYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=y5jUCrwkFpnHODxuP87YQi+Hp70YGm5TI7UEzLThx+c=; b=fVhSwRyQ3z5egD1i9mq5QSK6cW+7py6X2DpLiAt9fEGEPVE09rScWBTGRSgqiq+XZN Y23bR15mLYvPRabGXnDHmOW+Nte17S6QsjLDR/c7VrcO1rS9oGA9bxXn4Z1c7dJq+oP6 J+YczO8vt/MewVGak9QlyWjii45QVK8T4ySUh2hU1jSasCAn9yLxJDyFjEbkG9/Q8DR3 uel5tE/BAnp3PEdiL+SUsfigYNEVBxUYD8xyMOSdFTRfjWw8UVcRGCzFkzyYLU+a3bUL JrTGRtTt7ymmxOc1/ch7DIwForpm/gj288v0cooNhoibWjMOxvz3Z2Ua3OOZ79CLaUkj XSWQ== X-Gm-Message-State: AN3rC/54vR+2t/rpDcsdNaUdrt7hsr20MIqqYYCDgfejcYOeFAmZxJG7 15llDyBqH01LGQ== X-Received: by 10.55.77.209 with SMTP id a200mr13613892qkb.11.1492782238460; Fri, 21 Apr 2017 06:43:58 -0700 (PDT) Received: from [10.0.30.228] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id 36sm247459qtz.16.2017.04.21.06.43.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Apr 2017 06:43:57 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_3130D1D1-FA0E-4271-9430-149EBD674FDD" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 21 Apr 2017 09:43:56 -0400 In-Reply-To: <01QDEV2QM6XC00005O@mauve.mrochek.com> Cc: John R Levine , jmap@ietf.org, Daniel Kahn Gillmor To: Ned Freed References: <20170419163429.8556.qmail@ary.lan> <87d1c873cf.fsf@fifthhorseman.net> <01QDEV2QM6XC00005O@mauve.mrochek.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Jmap] Submission X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 13:44:01 -0000 --Apple-Mail=_3130D1D1-FA0E-4271-9430-149EBD674FDD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 20, 2017, at 11:06 PM, Ned Freed wrote: > More generally, the only difference between a JMAP capability tied to, = say, > a magic header and a SUBMIT extension is syntax. But if you specify = things > in a way that makes it difficult to map from one to the other, you'll = pay > the price for that as long as either protocols continue to evolve - = and that's > going to be a long time. I think the distinction comes from whether you actually think that the = SMTP submission protocol is always going to be what's behind a message = submitted via JMAP. If you think that, then it's going to look really = weird to not just replicate that exact paradigm with the JMAP submission = process. However, it's not at all clear to me that that makes any general sense. = I'm sure it makes sense in some implementations, but if we were to go = that route, we would essentially be nailing JMAP to SMTP submission. = There's some value to doing this in that it avoids reinventing the = wheel, but there is also damage, in that the SMTP submission paradigm = really isn't particularly congruent to the general paradigm of JMAP. The point is that whichever choice we make, we are going to pay a price = for it. It's worth asking what that price is, and also asking what the = advantages are to the choices we have, and then deciding on that basis. = The fact that we would pay a price for not replicating SMTP submission = can definitely be taken as a given. --Apple-Mail=_3130D1D1-FA0E-4271-9430-149EBD674FDD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Apr 20, 2017, at 11:06 PM, Ned Freed <ned.freed@mrochek.com> wrote:
More generally, the only difference = between a JMAP capability tied to, say,
a magic header and = a SUBMIT extension is syntax. But if you specify things
in a way that makes it difficult to map from one = to the other, you'll pay
the price for that = as long as either protocols continue to evolve - and that's
going to be a long = time.

I = think the distinction comes from whether you actually think that the = SMTP submission protocol is always going to be what's behind a message = submitted via JMAP.   If you think that, then it's going to look = really weird to not just replicate that exact paradigm with the JMAP = submission process.

However, it's not at all clear to me that that makes any = general sense.   I'm sure it makes sense in some implementations, = but if we were to go that route, we would essentially be nailing JMAP to = SMTP submission.   There's some value to doing this in that it = avoids reinventing the wheel, but there is also damage, in that the SMTP = submission paradigm really isn't particularly congruent to the general = paradigm of JMAP.

The point is that whichever choice we make, we are going to = pay a price for it.   It's worth asking what that price is, and = also asking what the advantages are to the choices we have, and then = deciding on that basis.   The fact that we would pay a price for = not replicating SMTP submission can definitely be taken as a = given.

= --Apple-Mail=_3130D1D1-FA0E-4271-9430-149EBD674FDD-- From nobody Fri Apr 21 07:34:52 2017 Return-Path: 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 8F0751294E0 for ; Fri, 21 Apr 2017 07:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gulbrandsen.priv.no 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 zozgQlsB8huF for ; Fri, 21 Apr 2017 07:34:49 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 042F012944C for ; Fri, 21 Apr 2017 07:34:48 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 4AAA7FA0075; Fri, 21 Apr 2017 14:34:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1492785287; bh=LiwWyOVrbdn5VKvFIoJgVAJSImImPSh+cU1N990LTcc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=ZcQcbXFG+pRJuTSKaVCokdRJOfrUtHbUZfEl4ipRgUGFzE3GjKT1cQz5uHrGTjBXZ L7Xyy9M8lDWPYCN8lmcbiebs9Pz4q2DGE/MrD0pWkspro1qg5EFMKef92PENwvdQFH dMcEKfvfaNcapLi/Zf4Z13axgg/ig8xpjVv0qZSg= Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1492785286-26128-4380/11/8; Fri, 21 Apr 2017 14:34:46 +0000 From: Arnt Gulbrandsen To: jmap@ietf.org Date: Fri, 21 Apr 2017 15:34:44 +0100 User-Agent: Trojita/v0.5-9-g8961725; Qt/4.8.6; X11; Linux; Devuan GNU/Linux 1.0 (jessie) Mime-Version: 1.0 Message-Id: <4471fa93-2321-4a7e-87b0-fbb00927d584@gulbrandsen.priv.no> In-Reply-To: References: <20170419163429.8556.qmail@ary.lan> <87d1c873cf.fsf@fifthhorseman.net> <01QDEV2QM6XC00005O@mauve.mrochek.com> Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: Subject: Re: [Jmap] Submission X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 14:34:51 -0000 Ted Lemon writes: > I think the distinction comes from whether you actually think > that the SMTP submission protocol is always going to be what's > behind a message submitted via JMAP. If you think that, then > it's going to look really weird to not just replicate that exact > paradigm with the JMAP submission process. Hm? Won't the nexthop generally be the thing that the port-587 server forwards to? After all, JMAP already handles authentication, and it's not clear to me that a typical JMAP server is easily able to authenticate on behalf of the end user in a way that a port-587 server accepts. Assuming that JMAP forwards to the filter or smarthost, then requiring that JMAP servers be able to forward SMTP extensions looks really odd. A submission server on port 587 cannot forward SMTP extensions from its nexthop, why should one on port 443 have to? The usual answer is "so as to not need a corresponding JMAP RFC whenever there's a new SMTP RFC". That strikes me as poor. A new extension requires an RFC and three kinds of implementations (SMTP client, submission server, filter server). The RFC publication bit isn't usually the bottleneck among those four. > The point is that whichever choice we make, we are going to pay > a price for it. It's worth asking what that price is, and also > asking what the advantages are to the choices we have, and then > deciding on that basis. The fact that we would pay a price for > not replicating SMTP submission can definitely be taken as a > given. +1 Arnt From nobody Fri Apr 21 08:02:33 2017 Return-Path: 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 432671294D3 for ; Fri, 21 Apr 2017 08:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 GDl20R2Nwwt1 for ; Fri, 21 Apr 2017 08:02:27 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 902D4124D37 for ; Fri, 21 Apr 2017 08:02:27 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id c45so71607008qtb.1 for ; Fri, 21 Apr 2017 08:02:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=lcagNObZW9A9eg/F/iBMvmLkL3hPOdPirzbHc9OgxT0=; b=vwblRFZ/ZqfuFcyR0dYRbopQSFBgzQXvXpFjJtuLPIbUbnYkegvtlaRxodFt+i5HOH r9nNoYAv1m1T915cdKR2w1k7GUdofrxv5uJl0Lq7iFn9o6pqdhr0CqtyJQtvR8Bc24pA fioWp46rc4IP+sQUAK2z1DgDI6zAiM20TbU7PLOiulc/UZbIeyC6VHhj0XfJ5ky6T+FE Nee99JQ0/XJ1hWpwaz1DkidYm+9EuoARbNH3bk8OROfj94VSRumeFvO2H2vCEVM41fQ5 4DRo2rpZd1O4a/cfdIJ+vCu6PDqlokVTd3fAPfXgkp13s/DO0OGD5aOAk1AGzUVTqo8z P7jA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=lcagNObZW9A9eg/F/iBMvmLkL3hPOdPirzbHc9OgxT0=; b=FD47izYSiQQ4QIfZbN9WFfZeKn+GS86EeNFlCuJYvnUas11tWiv35ZsZAd5xKyi6fi tkVysAs8sdU2v1tXPvlDTANyCuK59OLGmqY71GwMZh2NkZno8l5zZtBTDD79cfqjyrOe 4IsFHi/VnewZ2QmI5YC1dWKXKebYTFzRLWLqDPiWPa9T9nQQYTFE/GKwUi7o6x8P5JsO u4C/0DTtOjyDWZUN9kbHGHRnwSIHJZskUsYlg46YMbzr036hyJfYiM9qkVXFsKL00ggj TcuMnBe/NwyVVaWKAJod1nxyY+ofrBW01DXg70opKW0XTpgZvAO7dc6tQg4FBEftA0LZ Wwqw== X-Gm-Message-State: AN3rC/5G+3OnE3PISvfmuouhVXrAkd/BJAM8Nya91yyCoc6Hq+fhYOm0 6A4Y0F1xj9CTP8xrdFU= X-Received: by 10.200.53.156 with SMTP id k28mr14014918qtb.202.1492786946659; Fri, 21 Apr 2017 08:02:26 -0700 (PDT) Received: from [10.0.30.228] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id m30sm6467839qtg.57.2017.04.21.08.02.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Apr 2017 08:02:25 -0700 (PDT) From: Ted Lemon Message-Id: <7ED5BB51-F552-4E2E-A152-55D4DE5CF917@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_0C901AE7-CA6E-49C1-95CD-6584F0BD29C5" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 21 Apr 2017 11:02:24 -0400 In-Reply-To: <4471fa93-2321-4a7e-87b0-fbb00927d584@gulbrandsen.priv.no> Cc: jmap@ietf.org To: Arnt Gulbrandsen References: <20170419163429.8556.qmail@ary.lan> <87d1c873cf.fsf@fifthhorseman.net> <01QDEV2QM6XC00005O@mauve.mrochek.com> <4471fa93-2321-4a7e-87b0-fbb00927d584@gulbrandsen.priv.no> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Jmap] Submission X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 15:02:29 -0000 --Apple-Mail=_0C901AE7-CA6E-49C1-95CD-6584F0BD29C5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 21, 2017, at 10:34 AM, Arnt Gulbrandsen = wrote: > Won't the nexthop generally be the thing that the port-587 server = forwards to? After all, JMAP already handles authentication, and it's = not clear to me that a typical JMAP server is easily able to = authenticate on behalf of the end user in a way that a port-587 server = accepts. This would have been my assumption, but we seem to be hearing different = things from some folks who are operating large installations, so I think = it's worth discussing. --Apple-Mail=_0C901AE7-CA6E-49C1-95CD-6584F0BD29C5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Apr 21, 2017, at 10:34 AM, Arnt Gulbrandsen <arnt@gulbrandsen.priv.no> wrote:
Won't the nexthop generally be the thing = that the port-587 server forwards to? After all, JMAP already handles = authentication, and it's not clear to me that a typical JMAP server is = easily able to authenticate on behalf of the end user in a way that a = port-587 server accepts.

This would have been my assumption, but we = seem to be hearing different things from some folks who are operating = large installations, so I think it's worth discussing.

= --Apple-Mail=_0C901AE7-CA6E-49C1-95CD-6584F0BD29C5-- From nobody Fri Apr 21 08:17:01 2017 Return-Path: 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 C4990129516 for ; Fri, 21 Apr 2017 08:17:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 P1W4OZlxLYxw for ; Fri, 21 Apr 2017 08:17:00 -0700 (PDT) Received: from miucha.iecc.com (w6.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E60DF129505 for ; Fri, 21 Apr 2017 08:16:59 -0700 (PDT) Received: (qmail 16780 invoked from network); 21 Apr 2017 15:16:58 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 21 Apr 2017 15:16:58 -0000 Date: 21 Apr 2017 15:16:36 -0000 Message-ID: <20170421151636.28173.qmail@ary.lan> From: "John Levine" To: jmap@ietf.org Cc: mellon@fugue.com In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Jmap] Submission is not hard X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 15:17:01 -0000 In article you write: >I think the distinction comes from whether you actually think that the SMTP submission protocol is always going to be what's behind a message >submitted via JMAP. If you think that, then it's going to look really weird to not just replicate that exact paradigm with the JMAP submission process. Um, this is the IETF. If you want to invent a new, different, and incompatible mail system, JMAP is definitely not the place to do so. I am scratching my head about why people are having such trouble with the submission model. It's not complicated. The message goes into a queue, the envelope and message are separate, the envelope addresses can have annotations, and the server tells the client what optional features it supports. That's it. The options are, you know, optional, but many of them are useful. Before someone suggests that we should use some better scheme, I would point out that a lot of mail transport designs have come and gone over the past 40 years, and all of the others are dead. You're going to need a really good story about why this time is different. There's also a lot of issues that are really quality of implementation. For example, I agree that a server that doesn't support 8BITMIME would be pretty lame, and I would not blame a client that refused to work with it (and unsurprised to find that the MUA on my phone already does that.) But the place to deprecate not-8BITMIME is in 5321bis, not here. Finally, if people want to try whizbang ways to show animations of mail zipping through the aether, that sounds like a swell optional add-on to try and implement and test and perhaps bring back later as an extension, but it'd be nuts to try to invent it now. R's, John From nobody Fri Apr 21 08:18:21 2017 Return-Path: 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 C7128129510 for ; Fri, 21 Apr 2017 08:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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=mrochek.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 phjIM_UepFmW for ; Fri, 21 Apr 2017 08:18:18 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 832A0127868 for ; Fri, 21 Apr 2017 08:18:18 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QDFJVC928G006BAP@mauve.mrochek.com> for jmap@ietf.org; Fri, 21 Apr 2017 08:13:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1492787593; bh=joX1n6KE7JTLNoSR9tDT/Agy5nOZDgeXFFAvm4r7zOQ=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=X/AF//7J9/gE+7Y5i0GWYTopnG3RqPl2jqASFPtQJNUZQrNlKQCnJ8dUUogkMpxVL Z0m0XdKBb0G656+/tf3VSJQdDF82L9c9GvuK11+XgHc2fihAiMP0YWotynAaBRZqHP MW5T2et0tCkr8avg3YtfMGIZC/I5DfAzpnimLx6M= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QDELNEAKJK00005O@mauve.mrochek.com>; Fri, 21 Apr 2017 08:13:09 -0700 (PDT) Cc: Ned Freed , John R Levine , jmap@ietf.org, Daniel Kahn Gillmor Message-id: <01QDFJV9BBBS00005O@mauve.mrochek.com> Date: Fri, 21 Apr 2017 08:02:32 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 21 Apr 2017 09:43:56 -0400" References: <20170419163429.8556.qmail@ary.lan> <87d1c873cf.fsf@fifthhorseman.net> <01QDEV2QM6XC00005O@mauve.mrochek.com> To: Ted Lemon Archived-At: Subject: Re: [Jmap] Submission X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 15:18:20 -0000 > On Apr 20, 2017, at 11:06 PM, Ned Freed wrote: > > More generally, the only difference between a JMAP capability tied to, say, > > a magic header and a SUBMIT extension is syntax. But if you specify things > > in a way that makes it difficult to map from one to the other, you'll pay > > the price for that as long as either protocols continue to evolve - and that's > > going to be a long time. > I think the distinction comes from whether you actually think that the SMTP > submission protocol is always going to be what's behind a message submitted via > JMAP. If you think that, then it's going to look really weird to not just > replicate that exact paradigm with the JMAP submission process. I don't think that at all and I doubt anyone else does either, so this distinction seems completely irrelevant to me. The issue is semantics, not syntax. If your design locks you in to a particular set of semantics that cannot be extended - which is what any design that fails to allow for capability discovery and attachment of arbitrary parameters - you've put yourself in a position where you need to continually revise things in order to keep them synchronized as the capabilities of the transport infrasture continue to evolve. None of this is in any way specific to SUBMIT or SMTP. > However, it's not at all clear to me that that makes any general sense. I'm > sure it makes sense in some implementations, but if we were to go that route, > we would essentially be nailing JMAP to SMTP submission. There's some value > to doing this in that it avoids reinventing the wheel, but there is also > damage, in that the SMTP submission paradigm really isn't particularly > congruent to the general paradigm of JMAP. The message transport process is precisely defined as a series of steps that begin with submission and end with delivery. Nothing in that process says that SUBMIT has to be used for submission - and it frequently isn't in practice - but in order to be compatible with the current transport infrastructure submission does have to occur and where it occurs has to be well defined. > The point is that whichever choice we make, we are going to pay a price for > it. It's worth asking what that price is, and also asking what the advantages > are to the choices we have, and then deciding on that basis. The fact that we > would pay a price for not replicating SMTP submission can definitely be taken > as a given. I'm afraid that's really not the point at all. There are always costs on both sides of a decision; my point is that the costs on one side of this decision are significant and ongong, whereas on the other, not so much. Ned From nobody Fri Apr 21 08:28:04 2017 Return-Path: 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 05E36127B60 for ; Fri, 21 Apr 2017 08:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 XWhlTIZMhk3J for ; Fri, 21 Apr 2017 08:28:01 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4157312953E for ; Fri, 21 Apr 2017 08:28:01 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id g60so72379927qtd.3 for ; Fri, 21 Apr 2017 08:28:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=eu4GdT/CGmhKlbNv3il8IM6nZ60AzJJ0kT+GQfwf+y4=; b=lxGrDBStPteaYCMYcRjnZW2VHGc6W+9/+fAaiu0Ph26yGQwBXjw5F3e6/J5A+yBOvL ww3GRqwvPSBEBUhKWvt6XMd7Ag0gD+zLeQSx5hN9nC+Z2rmoG77YDVdi0yClD5wanTUo Mv/YTYS+oI25wS0d2SnNuezRJl45hM+2tBratC0cK70khP9c5CO1ThmgFu+melZRbwqo WDP5WdW3WfIYa6NV4zXC/E/v2YR8KXGSFBOj5hNGY3+o/TR37RN003B5DZkekVnILyWJ XjF5dOfsqxSZZIbLkNCq17fw+nrjbf6dpxQoE6X02ACbMLV1kH8WTtfT9hB1UlNzWx9m RotA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=eu4GdT/CGmhKlbNv3il8IM6nZ60AzJJ0kT+GQfwf+y4=; b=BjvMrBC554ThmkUrUSb0SMB+cTs4SBJTtijfYcw+lRiJNCSpdVUYNbR2AGjgk+J1HT uKUqAsX+//jMJJs0j4f5Rx9MHC7DJBG1oJjQnWiFYLoxj078IEoan2I9Oa1AJtmAjt1E q6xnNjPZIg2NJUj/yTfPuaK1nkhO9+EwclSSkhSUCj0u1lWygh4tMKBPopYQ7WI2clIv gkUU9brEO1x1FShgD3JXPoFVXnfgEnESpEndcHp6HbsXdc1a6mMGNFCCYghEmp2xYPmc 1IlawUKvcg3zxAt3fhu6BhrkWbETKHNwWFpOV24kuUR36LkI89A/O5833Y5nLnIh2muc HGSA== X-Gm-Message-State: AN3rC/5gg0Wu29PHe5AWuojYfaaynmZoCiSYkKF2dNxzMQVgtUcBdM+a eNgcxlkgC9J+Sj1wRxk= X-Received: by 10.237.53.141 with SMTP id c13mr13275849qte.21.1492788480413; Fri, 21 Apr 2017 08:28:00 -0700 (PDT) Received: from [10.0.30.228] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id x33sm6512222qtc.22.2017.04.21.08.27.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Apr 2017 08:27:58 -0700 (PDT) From: Ted Lemon Message-Id: <65CA1C64-ACD9-4AF5-8ED4-59D4285B5A8D@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E762F0AB-5E93-4837-8851-5342F1391873" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 21 Apr 2017 11:27:57 -0400 In-Reply-To: <01QDFJV9BBBS00005O@mauve.mrochek.com> Cc: jmap@ietf.org To: Ned Freed References: <20170419163429.8556.qmail@ary.lan> <87d1c873cf.fsf@fifthhorseman.net> <01QDEV2QM6XC00005O@mauve.mrochek.com> <01QDFJV9BBBS00005O@mauve.mrochek.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Jmap] Submission X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 15:28:03 -0000 --Apple-Mail=_E762F0AB-5E93-4837-8851-5342F1391873 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 21, 2017, at 11:02 AM, Ned Freed wrote: > The issue is semantics, not syntax. If your design locks you in to a > particular set of semantics that cannot be extended - which is what = any > design that fails to allow for capability discovery and attachment of > arbitrary parameters - you've put yourself in a position where you = need > to continually revise things in order to keep them synchronized as the > capabilities of the transport infrasture continue to evolve. Yes, I hear this concern. I'm saying that it's to be weighed against = the benefits of making the JMAP submission protocol primary, rather than = nailing it to SMTP submission. If you nail JMAP submission to SMTP = submission, you are excluding any functionality that can't be provided = by SMTP submission. =20 And as a practical matter, as Arnt said, if SMTP submission continues to = be the place where innovation occurs, then this means implementations = will have to follow that. I don't think it's fair to assume that = preserving the semantics of SMTP submission in JMAP submission is going = to get you to a place of win. Any JMAP implementation that doesn't use SMTP submission as a backend = is still going to have to track SMTP submission RFCs, or else there will = be interop problems. For such implementations, the need for a JMAP RFC = to track relevant new functionality added to SMTP submit is good, not = bad. For the use case you are concerned about, I think it doesn't matter; the = point I am making here is just that that is not the only use case we = ought to consider. --Apple-Mail=_E762F0AB-5E93-4837-8851-5342F1391873 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Apr 21, 2017, at 11:02 AM, Ned Freed <ned.freed@mrochek.com> wrote:
The issue is semantics, not syntax. If = your design locks you in to a
particular set of = semantics that cannot be extended - which is what any
design that fails to allow for capability = discovery and attachment of
arbitrary = parameters - you've put yourself in a position where you need
to continually revise things in order to keep = them synchronized as the
capabilities of the = transport infrasture continue to = evolve.

Yes,= I hear this concern.   I'm saying that it's to be weighed against = the benefits of making the JMAP submission protocol primary, rather than = nailing it to SMTP submission.   If you nail JMAP submission to = SMTP submission, you are excluding any functionality that can't be = provided by SMTP submission.   

And as a practical matter, as Arnt = said, if SMTP submission continues to be the place where innovation = occurs, then this means implementations will have to follow that.   = I don't think it's fair to assume that preserving the semantics of SMTP = submission in JMAP submission is going to get you to a place of = win.

Any JMAP = implementation that doesn't use SMTP submission as a backend  is = still going to have to track SMTP submission RFCs, or else there will be = interop problems.   For such implementations, the need for a JMAP = RFC to track relevant new functionality added to SMTP submit is good, = not bad.

For = the use case you are concerned about, I think it doesn't matter; the = point I am making here is just that that is not the only use case we = ought to consider.

= --Apple-Mail=_E762F0AB-5E93-4837-8851-5342F1391873-- From nobody Fri Apr 21 08:30:39 2017 Return-Path: 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 0AA3312954A for ; Fri, 21 Apr 2017 08:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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=mrochek.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 jgsDBXZVvrtd for ; Fri, 21 Apr 2017 08:30:36 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E842712956D for ; Fri, 21 Apr 2017 08:30:35 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QDFKD23L40006Q8V@mauve.mrochek.com> for jmap@ietf.org; Fri, 21 Apr 2017 08:26:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1492788403; bh=VlXRyKLAEm2av/L/b8VGPawvTrlx46ggIueWyQFp/iA=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=fHdAVcwSWSuLvLKYe8A8hujNVj0jH14eIo5Zp2F6HCy/Adh5r8+zeknW9Qs+wDo1L 6L3HyA6obpS/A/xSsnD0TL2I7huW395gpYakpT5N11ga8QXR6DGXA1MSn6vrJP/AUE WX2XPVWPfwnameng7Jc/Bq2Cg2y3r+TUKxdZdDYM= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QDELNEAKJK00005O@mauve.mrochek.com>; Fri, 21 Apr 2017 08:26:40 -0700 (PDT) Cc: jmap@ietf.org, mellon@fugue.com Message-id: <01QDFKCZZ52I00005O@mauve.mrochek.com> Date: Fri, 21 Apr 2017 08:18:37 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 21 Apr 2017 15:16:36 +0000" <20170421151636.28173.qmail@ary.lan> References: <20170421151636.28173.qmail@ary.lan> To: John Levine Archived-At: Subject: Re: [Jmap] Submission is not hard X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 15:30:38 -0000 > In article you write: > >I think the distinction comes from whether you actually think that the SMTP submission protocol is always going to be what's behind a message > >submitted via JMAP. If you think that, then it's going to look really weird to not just replicate that exact paradigm with the JMAP submission process. > Um, this is the IETF. If you want to invent a new, different, and > incompatible mail system, JMAP is definitely not the place to do so. > I am scratching my head about why people are having such trouble with > the submission model. It's not complicated. The message goes into a > queue, the envelope and message are separate, the envelope addresses > can have annotations, and the server tells the client what optional > features it supports. That's it. The options are, you know, > optional, but many of them are useful. Exactly right. And the envelope format can and should be dead easy to generate - dare I suggest using JSON? - making this quite easy for clients to do. > Before someone suggests that we should use some better scheme, I would > point out that a lot of mail transport designs have come and gone over > the past 40 years, and all of the others are dead. You're going to > need a really good story about why this time is different. Having spent considerable time implementing most of the other designs that have come and gone over the years, one of the conclusions I've reached is that full envelope separation is a key design principle along the same lines as the end-to-end principle. It's a shame it isn't recognized as such. Ned From nobody Fri Apr 21 08:33:14 2017 Return-Path: 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 D87DB129543 for ; Fri, 21 Apr 2017 08:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no 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 FtTZBd5cCXsz for ; Fri, 21 Apr 2017 08:33:10 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B08C8129510 for ; Fri, 21 Apr 2017 08:33:09 -0700 (PDT) Received: (qmail 19102 invoked from network); 21 Apr 2017 15:33:08 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 21 Apr 2017 15:33:08 -0000 Date: 21 Apr 2017 15:32:46 -0000 Message-ID: <20170421153246.28229.qmail@ary.lan> From: "John Levine" To: jmap@ietf.org Cc: adrien@qbik.com In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Jmap] Submission X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 15:33:11 -0000 In article you write: >I think trying to pass through SMTP extensions when there may not even >be an upstream SMTP server is going to be problematic let alone ugly. It seems very likely that there will be a submission server, if there is any hope of sending mail to the billion people who use SMTP mail now. >Which extensions do we think are even in scope for this? All of them. A more interesting question is which ones are likely to be useful in this context. A quick look suggests 8BITMIME, SUBMITTER, DSN, DELIVERBY, FUTURERELEASE, SMTPUTF8, CONPERM, MT-PRIORITY, RRVS, and maybe BURL. R's, John PS: >Sounds like DKIM didn't think through the need to transform mail. ... How about if you read the dkim list archives and get back to us on that? From nobody Fri Apr 21 09:01:13 2017 Return-Path: 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 DC84E128B8D for ; Fri, 21 Apr 2017 09:01:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 krns5m6stum3 for ; Fri, 21 Apr 2017 09:01:11 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7DEF12878D for ; Fri, 21 Apr 2017 09:01:10 -0700 (PDT) Received: (qmail 22847 invoked from network); 21 Apr 2017 16:01:09 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 21 Apr 2017 16:01:09 -0000 Date: 21 Apr 2017 16:00:47 -0000 Message-ID: <20170421160047.28310.qmail@ary.lan> From: "John Levine" To: jmap@ietf.org Cc: arnt@gulbrandsen.priv.no In-Reply-To: <4471fa93-2321-4a7e-87b0-fbb00927d584@gulbrandsen.priv.no> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Jmap] Submission X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 16:01:12 -0000 In article <4471fa93-2321-4a7e-87b0-fbb00927d584@gulbrandsen.priv.no> you write: >Assuming that JMAP forwards to the filter or smarthost, then requiring that >JMAP servers be able to forward SMTP extensions looks really odd. A >submission server on port 587 cannot forward SMTP extensions from its >nexthop, why should one on port 443 have to? Nobody's asking for that. What we need are the extensions that the submission server supports. Perhaps some people here (not you) are unaware that submission and SMTP are different protocols but share the same set of extensions. R's, John From nobody Fri Apr 21 15:22:46 2017 Return-Path: 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 9EB31129437 for ; Fri, 21 Apr 2017 15:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 QF_-mERKWLt0 for ; Fri, 21 Apr 2017 15:22:42 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [122.56.26.1]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0AD7129B0D for ; Fri, 21 Apr 2017 15:22:41 -0700 (PDT) Received: From [192.168.1.146] (unverified [192.168.1.146]) by SMTP Server [192.168.1.3] (WinGate SMTP Receiver v9.0.5 (Build 5926)) with SMTP id <0001026394@smtp.qbik.com>; Sat, 22 Apr 2017 10:22:39 +1200 From: "Adrien de Croy" To: "John Levine" , "jmap@ietf.org" Date: Fri, 21 Apr 2017 22:22:39 +0000 Message-Id: In-Reply-To: <20170421153246.28229.qmail@ary.lan> References: <20170421153246.28229.qmail@ary.lan> Reply-To: "Adrien de Croy" User-Agent: eM_Client/7.0.27943.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Jmap] Submission X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 22:22:45 -0000 ------ Original Message ------ From: "John Levine" To: "jmap@ietf.org" Cc: "adrien@qbik.com" Sent: 22/04/2017 3:32:46 AM Subject: Re: [Jmap] Submission >In article you write: >>I think trying to pass through SMTP extensions when there may not even >>be an upstream SMTP server is going to be problematic let alone ugly. > >It seems very likely that there will be a submission server, if there >is any hope of sending mail to the billion people who use SMTP mail >now. sure, but conversely there very often will not be. Intra-organizational= =20 mail for example is often not forwarded with SMTP. Also if we don't prevent it, inter-organizational mail could use this as= =20 well. The key is to not make that impossible or worthless. SMTP is just not being fixed. Until the IETF decides enough is enough,=20 and agents acting on behalf of humans must no longer do things=20 anonymously (and this means using certificates at any point mail is=20 injected into the system so that these can be revoked on abuse), we will= =20 continue to be inundated with spam, with all the down-stream impact that= =20 has on the usefulness of electronic mail. Just because there is a cost to doing something, doesn't necessarily=20 mean that cost would not be well-spent. There's an ongoing cost of=20 leaving things the same as well. All costs are very difficult to quantify, and therefore it's very=20 difficult to determine which path we should take on a purely cost-basis. But we could also consider maybe that if we actually came up with a=20 design which was compelling enough, then adoption could make it=20 worth-while. People are sick of the problems with SMTP, and sick of the= =20 lack of progress addressing them. We should be learning from things=20 like Facebook messaging. Good anti-spam is masking the issue, which is still growing, but the=20 situation is actually insane. How many legitimate mails are you missing= =20 out on because of the constant deluge of spam? > > >>Which extensions do we think are even in scope for this? > >All of them. A more interesting question is which ones are likely to >be useful in this context. A quick look suggests 8BITMIME, SUBMITTER, >DSN, DELIVERBY, FUTURERELEASE, SMTPUTF8, CONPERM, MT-PRIORITY, RRVS, >and maybe BURL. > >R's, >John > >PS: > >>Sounds like DKIM didn't think through the need to transform mail. ... > >How about if you read the dkim list archives and get back to us on=20 >that? I'm sure it was contentious. Just saying it seems a bit silly to define= =20 a system that requires mail to not be transformed, and then layer it=20 over a transport that may need to transform mail. Just sayin' Adrien > > >_______________________________________________ >Jmap mailing list >Jmap@ietf.org >https://www.ietf.org/mailman/listinfo/jmap From nobody Fri Apr 21 15:34:20 2017 Return-Path: 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 CC39A128A32 for ; Fri, 21 Apr 2017 15:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 l412tfU92ZCE for ; Fri, 21 Apr 2017 15:34:16 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [122.56.26.1]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AC6A1243FE for ; Fri, 21 Apr 2017 15:34:15 -0700 (PDT) Received: From [192.168.1.146] (unverified [192.168.1.146]) by SMTP Server [192.168.1.3] (WinGate SMTP Receiver v9.0.5 (Build 5926)) with SMTP id <0001026402@smtp.qbik.com>; Sat, 22 Apr 2017 10:34:12 +1200 From: "Adrien de Croy" To: "John Levine" , "jmap@ietf.org" Cc: "mellon@fugue.com" Date: Fri, 21 Apr 2017 22:34:13 +0000 Message-Id: In-Reply-To: <20170421151636.28173.qmail@ary.lan> References: <20170421151636.28173.qmail@ary.lan> Reply-To: "Adrien de Croy" User-Agent: eM_Client/7.0.27943.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Jmap] Submission is not hard X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 22:34:19 -0000 ------ Original Message ------ From: "John Levine" To: "jmap@ietf.org" Cc: "mellon@fugue.com" Sent: 22/04/2017 3:16:36 AM Subject: Re: [Jmap] Submission is not hard > >Finally, if people want to try whizbang ways to show animations of >mail zipping through the aether, that sounds like a swell optional >add-on to try and implement and test and perhaps bring back later as >an extension, but it'd be nuts to try to invent it now. > IME, if we don't design it now, it will never happen. Surely it's=20 important enough to do the work up front? ll I'm suggesting here is that in the new MUA to JMAP protocol, we allow= =20 for notifications about delivery, and not use the MDNs for this (between= =20 client and JMAP server). When a JMAP server needs to forward a message via SMTP, then it can use=20 existing SMTP extensions for this if supported, or tell the client that=20 it won't be getting any more delivery status updates for that message. For internal mail that doesn't go anywhere near SMTP, it could be a very= =20 rich experience. Eventually when organisations using this build enough web of trust to=20 use it for inter-organizational messaging, the rich experience will come= =20 for free. This is one way to provide a compelling reason to make a=20 change. Because sorry, but bounce messages are out of the dark ages. We need an= =20 attitude change here, we're competing against systems that aren't bound=20 by the need for consensus, and are just able to provide service and=20 function which is enticing users away from our systems. This is making=20 existing systems weaker and gradually obsolete. Cheers Adrien > >R's, >John > >_______________________________________________ >Jmap mailing list >Jmap@ietf.org >https://www.ietf.org/mailman/listinfo/jmap From nobody Fri Apr 21 15:46:51 2017 Return-Path: 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 5B824129B15 for ; Fri, 21 Apr 2017 15:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.221 X-Spam-Level: X-Spam-Status: No, score=-1.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=IJ2Q1+ia; dkim=pass (1536-bit key) header.d=taugh.com header.b=eeAapSAs 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 KuZoKhjrRfoI for ; Fri, 21 Apr 2017 15:46:39 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46293129AE8 for ; Fri, 21 Apr 2017 15:46:39 -0700 (PDT) Received: (qmail 71682 invoked from network); 21 Apr 2017 22:46:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=11800.58fa8bcd.k1704; bh=FQ2Kg+DMusjGca+YjDX6wTsyFuPv3O/OrCGSp3AnKtw=; b=IJ2Q1+iaCNtXJVqW/6w5PwCjI61E54HEpbtu5xp0N4Bk9aB4QvrhiXIf8fw3gSbMN+1/hzQk8wixtAkeumlZCrCAtOXAEi7HEeJ6Fjbn+uBpHDWybHxWmzeEReqEuUGSstdSjRucVZX9Q3Vm47HcbsZwrkqFAD36BznKyhU81k/tsZ9qhFUHg3Vt71TUwbIfXYgDAeRDMLFgL3u5b0407QK6KrkCP9Xu6zcLY5ztDfDxEVfRg8tKajwPif/ftuIs DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=11800.58fa8bcd.k1704; bh=FQ2Kg+DMusjGca+YjDX6wTsyFuPv3O/OrCGSp3AnKtw=; b=eeAapSAsU2cK05qmFhIvH9toJuTwp9UUTZYxyqEyfzl8K+i07jo+i3yhI43dRgwgFk8itA835jxPn3my4+NjKlRrcmAPtt7tFF/3cntwi9DSDXnrGH3t63a6dxQygxjsg98w+xSAIlxq3kkrY62oL3qLEtzJVniCgzo/SxHYpUnj5OPFrZzS6y3B+RbPm/Alcm/r/7HFGGRgV+tyygZiCvZpRsjo1bVMVZ8IOV8v4BA4q/fHSpHr0lEID6a06w6B Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 21 Apr 2017 22:46:37 -0000 Date: 21 Apr 2017 18:46:36 -0400 Message-ID: From: "John R Levine" To: "Adrien de Croy" Cc: "jmap@ietf.org" In-Reply-To: References: <20170421151636.28173.qmail@ary.lan> User-Agent: Alpine 2.20 (OSX 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Jmap] Submission is not hard X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 22:46:40 -0000 >> Finally, if people want to try whizbang ways to show animations of >> mail zipping through the aether, that sounds like a swell optional >> add-on to try and implement and test and perhaps bring back later as >> an extension, but it'd be nuts to try to invent it now. >> > IME, if we don't design it now, it will never happen. Surely it's important > enough to do the work up front? If our goal is to drag JMAP down in an endless swamp of vaporware design, I'd entirely agree. Otherwise, no. R's, John From nobody Fri Apr 21 15:52:37 2017 Return-Path: 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 D9DAE1293E8 for ; Fri, 21 Apr 2017 15:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 w8C_NsYgFvJy for ; Fri, 21 Apr 2017 15:52:33 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [122.56.26.1]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A438129407 for ; Fri, 21 Apr 2017 15:52:32 -0700 (PDT) Received: From [192.168.1.146] (unverified [192.168.1.146]) by SMTP Server [192.168.1.3] (WinGate SMTP Receiver v9.0.5 (Build 5926)) with SMTP id <0001026425@smtp.qbik.com>; Sat, 22 Apr 2017 10:52:29 +1200 From: "Adrien de Croy" To: "John R Levine" Cc: "jmap@ietf.org" Date: Fri, 21 Apr 2017 22:52:30 +0000 Message-Id: In-Reply-To: References: <20170421151636.28173.qmail@ary.lan> Reply-To: "Adrien de Croy" User-Agent: eM_Client/7.0.27943.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Jmap] Submission is not hard X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 22:52:36 -0000 It's only vapourware if nobody implements it. MUA designers tend to be interested in things like usability. Adrien ------ Original Message ------ From: "John R Levine" To: "Adrien de Croy" Cc: "jmap@ietf.org" Sent: 22/04/2017 10:46:36 AM Subject: Re: [Jmap] Submission is not hard >>>Finally, if people want to try whizbang ways to show animations of >>>mail zipping through the aether, that sounds like a swell optional >>>add-on to try and implement and test and perhaps bring back later as >>>an extension, but it'd be nuts to try to invent it now. >>> >>IME, if we don't design it now, it will never happen. Surely it's=20 >>important enough to do the work up front? > >If our goal is to drag JMAP down in an endless swamp of vaporware=20 >design, I'd entirely agree. Otherwise, no. > >R's, >John > >_______________________________________________ >Jmap mailing list >Jmap@ietf.org >https://www.ietf.org/mailman/listinfo/jmap From nobody Fri Apr 21 15:54:44 2017 Return-Path: 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 2BE96129BB7 for ; Fri, 21 Apr 2017 15:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.221 X-Spam-Level: X-Spam-Status: No, score=-1.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=2jXV+FQ7; dkim=pass (1536-bit key) header.d=taugh.com header.b=XKHNxP2V 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 7eT7cHKhmxNG for ; Fri, 21 Apr 2017 15:54:42 -0700 (PDT) Received: from miucha.iecc.com (w6.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31041129AE8 for ; Fri, 21 Apr 2017 15:54:42 -0700 (PDT) Received: (qmail 72206 invoked from network); 21 Apr 2017 22:54:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=11a0c.58fa8db0.k1704; bh=tNWWaVwhpIuAroBuJNPwhKZ4QnzZI4BwSezV9MY+E+Y=; b=2jXV+FQ7PFGlfNheF47bexo6xcOQ5ALzCnRlPehVFIR0kYz/d7HI/jG5C7237fp6xNsTrDHVt77BX0l429nJF5HvU+WmWAf6BT35juZIvhMPYxdZbXI9SrNg2PAtuVStPnY3cEBFnYcxTEWaXvZK/42LpvFmkm7JZN0Qr5am5QRCF8ReHQ4+ECRiaobSZNNTy6C2JhAJyMeDyOYMRgWSZgRd5Gtv5z22b0zNYAi1DdJYCDuE/tuqRf3x5vVtY/8n DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=11a0c.58fa8db0.k1704; bh=tNWWaVwhpIuAroBuJNPwhKZ4QnzZI4BwSezV9MY+E+Y=; b=XKHNxP2Vihq5i2oiFxH3Y/VyLfhlybZXaNqn7FRBcAnSHt6Cb9Ghnmm0JTxbz7w6kZeqfCYBpI8bTL2p2vCXKa7NEFG3wwqebj+cG8c8j8gPcopDZxJu6VnnRJorhGw6+hEFA7Ho73j8FJI2dnXaK3Kpzm+1jzh6jzDk0ADloOZiWvjuCG1dJgI6Y4+EF9FRL7ljdo5gEKxw1HJDSaSg8FZJQ2KPZhgMl2JwH2QKraNLsue2UMbjcNwcECo7bSXS Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 21 Apr 2017 22:54:40 -0000 Date: 21 Apr 2017 18:54:40 -0400 Message-ID: From: "John R Levine" To: "Adrien de Croy" Cc: "jmap@ietf.org" In-Reply-To: References: <20170421153246.28229.qmail@ary.lan> User-Agent: Alpine 2.20 (OSX 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Jmap] Submission X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 22:54:43 -0000 > Also if we don't prevent it, inter-organizational mail could use this as > well. The key is to not make that impossible or worthless. Hmmn. I have written submission servers. They are not particularly complicated or difficult, particularly if they don't have to handle the crypto goop in STARTTLS and AUTH, both of which JMAP does other ways. Assuming you mean intra-organizational mail, it would be a big help if you could explain concretely what about the standard submission model would make such mail impossible or worthless. Please be specific. R's, John From nobody Fri Apr 21 15:55:24 2017 Return-Path: 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 7D6E6129BB7 for ; Fri, 21 Apr 2017 15:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.22 X-Spam-Level: X-Spam-Status: No, score=-1.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=vAsAkSKh; dkim=pass (1536-bit key) header.d=taugh.com header.b=wZkQWRBf 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 FByQ2XJqs0on for ; Fri, 21 Apr 2017 15:55:22 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19029129AE8 for ; Fri, 21 Apr 2017 15:55:22 -0700 (PDT) Received: (qmail 72302 invoked from network); 21 Apr 2017 22:55:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=11a6c.58fa8dd7.k1704; bh=vl3jLKWod5UqHzrvAoeWOCjIgcRkER5gpBSEHemqN2k=; b=vAsAkSKhdfYfzg0bxKaZkE+vDc8z5yUAmwMUohUy9KgHjM6+PjsaMY/nXMmaXpihHaGkBnDAPLiCijYTCz+aRlnqnseh7Xt2GyW+nkgqPdB6GwmDBJVPRVjE9YEPUGJLt70i10OSeD50HtRWCLbqno2DmBVeFD5pmCOAsExJWtilPfW+VATJR36N03NMRG4Y7pup6VJKcw437CTqNgCL+TbvWHlKNGlGDxaMk3VwCfjzDLhYuh6gl/l01kEnr7pE DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=11a6c.58fa8dd7.k1704; bh=vl3jLKWod5UqHzrvAoeWOCjIgcRkER5gpBSEHemqN2k=; b=wZkQWRBfUrZ1Z+YIR9pLL3EVEbes/lRLx6L4jJP0wuFK3FZVVCpAxM8ddLyY9z8EUyuNz73+qTnW7tv1vWc/ONxDB07J4OBaJXHmkZbIC9wCe+sngaYIRj/000LJmvYMdTrjnyDZlrVyXLRQixCIs6Mn91q+S/WQg0hAPV0RqKJ9+zJyALjNQdanVG/g5/5zIXb4GhDND+qF/zBnGB+o2VaLG7j2UgD3bFmCZ05ot+XnHT5cD/GXjMsyPwZUJyRE Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 21 Apr 2017 22:55:18 -0000 Date: 21 Apr 2017 18:55:18 -0400 Message-ID: From: "John R Levine" To: "Adrien de Croy" Cc: "jmap@ietf.org" In-Reply-To: References: <20170421151636.28173.qmail@ary.lan> User-Agent: Alpine 2.20 (OSX 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Jmap] Submission is not hard X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 22:55:23 -0000 > It's only vapourware if nobody implements it. > MUA designers tend to be interested in things like usability. Well, sure. We eargerly await your prototypes. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Fri Apr 21 16:09:33 2017 Return-Path: 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 3294F128896 for ; Fri, 21 Apr 2017 16:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 iHXxU3F8T_Qe for ; Fri, 21 Apr 2017 16:09:28 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [122.56.26.1]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6B5612785F for ; Fri, 21 Apr 2017 16:09:27 -0700 (PDT) Received: From [192.168.1.146] (unverified [192.168.1.146]) by SMTP Server [192.168.1.3] (WinGate SMTP Receiver v9.0.5 (Build 5926)) with SMTP id <0001026433@smtp.qbik.com>; Sat, 22 Apr 2017 11:09:24 +1200 From: "Adrien de Croy" To: "John R Levine" Cc: "jmap@ietf.org" Date: Fri, 21 Apr 2017 23:09:25 +0000 Message-Id: In-Reply-To: References: <20170421153246.28229.qmail@ary.lan> Reply-To: "Adrien de Croy" User-Agent: eM_Client/7.0.27943.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Jmap] Submission X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 23:09:30 -0000 I did mean inter-organizational. E.g. external messaging. ------ Original Message ------ From: "John R Levine" To: "Adrien de Croy" Cc: "jmap@ietf.org" Sent: 22/04/2017 10:54:40 AM Subject: Re: [Jmap] Submission >>Also if we don't prevent it, inter-organizational mail could use this=20 >>as well. The key is to not make that impossible or worthless. > >Hmmn. I have written submission servers. They are not particularly=20 >complicated or difficult, particularly if they don't have to handle the= =20 >crypto goop in STARTTLS and AUTH, both of which JMAP does other ways. > >Assuming you mean intra-organizational mail, it would be a big help if=20 >you could explain concretely what about the standard submission model=20 >would make such mail impossible or worthless. Please be specific. > >R's, >John > >_______________________________________________ >Jmap mailing list >Jmap@ietf.org >https://www.ietf.org/mailman/listinfo/jmap From nobody Fri Apr 21 16:14:31 2017 Return-Path: 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 39B14128896 for ; Fri, 21 Apr 2017 16:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 Mn9a8N0ceHaI for ; Fri, 21 Apr 2017 16:14:27 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [122.56.26.1]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1032127071 for ; Fri, 21 Apr 2017 16:14:26 -0700 (PDT) Received: From [192.168.1.146] (unverified [192.168.1.146]) by SMTP Server [192.168.1.3] (WinGate SMTP Receiver v9.0.5 (Build 5926)) with SMTP id <0001026438@smtp.qbik.com>; Sat, 22 Apr 2017 11:14:23 +1200 From: "Adrien de Croy" To: "John R Levine" Cc: "jmap@ietf.org" Date: Fri, 21 Apr 2017 23:14:23 +0000 Message-Id: In-Reply-To: References: <20170421151636.28173.qmail@ary.lan> Reply-To: "Adrien de Croy" User-Agent: eM_Client/7.0.27943.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Jmap] Submission is not hard X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 23:14:29 -0000 If I had a mail client I would do it already. I can only commit to=20 doing it for the server side. In general, I think any system which involves humans, where things=20 happen which cause the system to require the human to wait for something= =20 should be designed in a way that allows for status updates to be given=20 to the human in a timely fashion. This is why I wrote the draft for status updates in http. This is why I suggest we allow for status notifications in mail. because when you send a message, you have to wait to find out what=20 happened. And sometimes it's important. When people are forced to wait for things for too long without any=20 feedback, they start doing things (like getting on the phone to see if=20 the message got through). Often these things are unnecessary and=20 wasteful of resources. More wasteful than a system that provided=20 adequate feedback in the first place. Designing protocols with this in mind allows implementors of these=20 systems to treat the humans (their customers) politely. Leaving=20 feedback / notifications out of the protocols puts the implementers in a= =20 position where they are forced to treat their users badly / rudely. Adrien ------ Original Message ------ From: "John R Levine" To: "Adrien de Croy" Cc: "jmap@ietf.org" Sent: 22/04/2017 10:55:18 AM Subject: Re: [Jmap] Submission is not hard >>It's only vapourware if nobody implements it. >>MUA designers tend to be interested in things like usability. > >Well, sure. We eargerly await your prototypes. > >Regards, >John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY >Please consider the environment before reading this e-mail.=20 >https://jl.ly > >_______________________________________________ >Jmap mailing list >Jmap@ietf.org >https://www.ietf.org/mailman/listinfo/jmap From nobody Fri Apr 21 16:19:48 2017 Return-Path: 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 D9A5A129AE8 for ; Fri, 21 Apr 2017 16:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no 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 uHCkeI8tFc4y for ; Fri, 21 Apr 2017 16:19:45 -0700 (PDT) Received: from miucha.iecc.com (w6.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3726128896 for ; Fri, 21 Apr 2017 16:19:45 -0700 (PDT) Received: (qmail 75485 invoked from network); 21 Apr 2017 23:19:44 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 21 Apr 2017 23:19:44 -0000 Date: 21 Apr 2017 23:19:22 -0000 Message-ID: <20170421231922.29225.qmail@ary.lan> From: "John Levine" To: jmap@ietf.org Cc: adrien@qbik.com In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Jmap] Submission X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 23:19:48 -0000 In article you write: > >I did mean inter-organizational. E.g. external messaging. In that case, I don't understand your point at all. Existing mail software uses the IETF submission protocols to send billions of inter-organizational messages every day, frequently from rather limited clients like a 2G flip phone or the laser printer on my desk or the NAS in the server room. Given the multi-decade track record here, what makes this so daunting if you wrap some JSON around it? R's, John From nobody Fri Apr 21 16:30:53 2017 Return-Path: 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 7F9F7129BC8 for ; Fri, 21 Apr 2017 16:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 N2CQ58Nolj9V for ; Fri, 21 Apr 2017 16:30:50 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [122.56.26.1]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9FF5128B93 for ; Fri, 21 Apr 2017 16:30:49 -0700 (PDT) Received: From [192.168.1.146] (unverified [192.168.1.146]) by SMTP Server [192.168.1.3] (WinGate SMTP Receiver v9.0.5 (Build 5926)) with SMTP id <0001026443@smtp.qbik.com>; Sat, 22 Apr 2017 11:30:46 +1200 From: "Adrien de Croy" To: "John Levine" , "jmap@ietf.org" Date: Fri, 21 Apr 2017 23:30:46 +0000 Message-Id: In-Reply-To: <20170421231922.29225.qmail@ary.lan> References: <20170421231922.29225.qmail@ary.lan> Reply-To: "Adrien de Croy" User-Agent: eM_Client/7.0.27943.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Jmap] Submission X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 23:30:52 -0000 ------ Original Message ------ From: "John Levine" To: "jmap@ietf.org" Cc: "adrien@qbik.com" Sent: 22/04/2017 11:19:22 AM Subject: Re: [Jmap] Submission >In article you write: >> >>I did mean inter-organizational. E.g. external messaging. > >In that case, I don't understand your point at all. Existing mail >software uses the IETF submission protocols to send billions of >inter-organizational messages every day, frequently from rather >limited clients like a 2G flip phone or the laser printer on my desk >or the NAS in the server room. > >Given the multi-decade track record here, what makes this so daunting >if you wrap some JSON around it? because in that case we're not looking to improve anything. My point is that (wrt submision) if we design a system for MUA->"the=20 system" which allows for a rich experience for the MUA, then if we don't= =20 make it impossible for this protocol to be used to extend the system=20 outside of the organisation, then we can get the rich experience for all= =20 mail, not just mail to your colleagues on the same server. I'm imagining a system where the JMAP server uses JMAP to send it the=20 next hop as well if required, and so on, thereby avoiding the=20 limitations of SMTP. > > >R's, >John > > >_______________________________________________ >Jmap mailing list >Jmap@ietf.org >https://www.ietf.org/mailman/listinfo/jmap From nobody Fri Apr 21 17:09:53 2017 Return-Path: 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 24A46129BAA for ; Fri, 21 Apr 2017 17:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.22 X-Spam-Level: X-Spam-Status: No, score=-1.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=Jpsnhctk; dkim=pass (1536-bit key) header.d=taugh.com header.b=wokGSnKo 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 ixVx8gRR9Qwr for ; Fri, 21 Apr 2017 17:09:51 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B32F11293FD for ; Fri, 21 Apr 2017 17:09:50 -0700 (PDT) Received: (qmail 79909 invoked from network); 22 Apr 2017 00:09:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=13823.58fa9f4c.k1704; bh=8LCEvs5trVrltbGfF2f53EONnsNTeZAY03zQKSngsOk=; b=JpsnhctkACCkB5tUd0QM6SdDIz6bM3nfNoWSvjn7xR1PDdTrDTw8yH4cKq3ufQ1oU0YWEA78uBKeo44+basP2UnHnQQtM7CTA0tRw6VtwbnHVi8zqQFTZ0WHJiDDFvGWmik1+N6b+iXe0ilnnXrhp5G78BaQ90uBSGv+DtbLmhjkCDs+RTH6XHHagxKszPOe4d7n5ie4wj6JVJj7l4RYtpAtKPEFb0s4e6KxgnrDmH2CnoS02PYSBKcb/YwGdmVB DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=13823.58fa9f4c.k1704; bh=8LCEvs5trVrltbGfF2f53EONnsNTeZAY03zQKSngsOk=; b=wokGSnKoYriUfR7qitrze2H8LVzfq/eH4/LG6zpYSYtzPfBwDA3CxKpwh9TIIFvlRfSrC05doxNPrlWXPF0p6ZN28bIjuWSJXG/cHDWUk+bppZN2YJRljzlraa3pEc6z3a0f43OXndeywmd6uRZcKL/FRKq06+vC/slqFsXiDpDiGdi0CbvauoAAUQb3O6NoFpRgBfTyPhOh48sR7osGHtK2JXKYfT2/0PIFhNtwo7DXlxarZXI9Bq9+YCGaEjeF Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 22 Apr 2017 00:09:47 -0000 Date: 21 Apr 2017 20:09:47 -0400 Message-ID: From: "John R Levine" To: "Adrien de Croy" Cc: "jmap@ietf.org" In-Reply-To: References: <20170421231922.29225.qmail@ary.lan> User-Agent: Alpine 2.20 (OSX 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Jmap] Submission X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Apr 2017 00:09:52 -0000 > I'm imagining a system where the JMAP server uses JMAP to send it the next > hop as well if required, and so on, thereby avoiding the limitations of SMTP. Well, then, have fun in your walled garden. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Fri Apr 21 17:28:21 2017 Return-Path: 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 1042E129484 for ; Fri, 21 Apr 2017 17:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 j5Bsj6WlpMdY for ; Fri, 21 Apr 2017 17:28:18 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [122.56.26.1]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E277128708 for ; Fri, 21 Apr 2017 17:28:17 -0700 (PDT) Received: From [192.168.1.146] (unverified [192.168.1.146]) by SMTP Server [192.168.1.3] (WinGate SMTP Receiver v9.0.5 (Build 5926)) with SMTP id <0001026463@smtp.qbik.com>; Sat, 22 Apr 2017 12:28:13 +1200 From: "Adrien de Croy" To: "John R Levine" Cc: "jmap@ietf.org" Date: Sat, 22 Apr 2017 00:28:14 +0000 Message-Id: In-Reply-To: References: <20170421231922.29225.qmail@ary.lan> Reply-To: "Adrien de Croy" User-Agent: eM_Client/7.0.27943.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Jmap] Submission X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Apr 2017 00:28:20 -0000 I'm not suggesting a walled garden. I'm suggesting that eventually SMTP can become the true relic it is. We've had decades to fix SMTP. It's not happening. Especially when=20 protocol designers don't seem to care about user experience beyond basic= =20 interop. we can add extensions to SMTP until the cows come home. We could build=20 all these things into SMTP (and maybe we should attempt to). But the=20 legacy issues will continue to hamper it, until we decide to make a=20 clean break from them (e.g. like deprecating non binary transport in=20 SMTP). We're moving too slowly, and the users are already voting with=20 their feet. ------ Original Message ------ From: "John R Levine" To: "Adrien de Croy" Cc: "jmap@ietf.org" Sent: 22/04/2017 12:09:47 PM Subject: Re: [Jmap] Submission >>I'm imagining a system where the JMAP server uses JMAP to send it the=20 >>next hop as well if required, and so on, thereby avoiding the=20 >>limitations of SMTP. > >Well, then, have fun in your walled garden. > >Regards, >John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY >Please consider the environment before reading this e-mail.=20 >https://jl.ly > >_______________________________________________ >Jmap mailing list >Jmap@ietf.org >https://www.ietf.org/mailman/listinfo/jmap From nobody Fri Apr 21 18:00:37 2017 Return-Path: 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 58740129BBD for ; Fri, 21 Apr 2017 18:00:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 koH6YBUq2E5H for ; Fri, 21 Apr 2017 18:00:34 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7939F127698 for ; Fri, 21 Apr 2017 18:00:34 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id y33so81511611qta.2 for ; Fri, 21 Apr 2017 18:00:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=OrUya+v1dvOGO7o7AZSkgykCeRcXCJlykJHgidF83eQ=; b=pREunxBxYvSw1XffReQyNydG6u3a+BBdt9R9ldCBURq8YECwIEMvj6S1aLzzNrLyhC 6AzusLSsnnh1e+pNJUwCL/h5OybFtxjBDYcz7SVHNpRsvEkYasaV4ClL0HfnfxKRmpiu XwsojxOAoThO+AQbw7DA7HISABd/li2kd/2MFVXvX+08cJLfBvv4zbmo/jmXJVSmIS7y EaubEn7+kvy/IY3oPqY3+4QcgYQ3Z67pFMAN3VPl6KOy782vD0IFKnbvH2a6g2qTJs42 5B6OIQ/W9Ag5VBgJIYx8UCkAnQfgFqhwUbwFmCt+vvMpM79TVe5ytmKqKLBZS4dz3WpD oiOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=OrUya+v1dvOGO7o7AZSkgykCeRcXCJlykJHgidF83eQ=; b=dmhMV79TvznKznr1LozYGsEs25avI5nugo0pdHQewbGQxtZ8af4dxB313in312LV9S HH6DnwVN9KUcsTH1tMbmERvSJ2Z7G13fFleD/yVIaoC0ds+NR5OBklwGK2LJs33p4jsq irNk/AqK4HG06ogdMpCy/DOvgah3MPIaMj/ICw3jj3QP9bjAX4nKRRrKRiwmuL0yD78k 7kEcL8VfM4wPqI4Jgxf3TJ1kTmz6Ayu8kd2344Udie4/RCClnx3Rsza+X4LvYj0cuBp8 MJ2WkDQYTDknKLaaNJHA1XK6Zr/pTGkdYtnsU45SjXiMfGox09hEJ4E1tTrRBa/7WuTh bXlw== X-Gm-Message-State: AN3rC/7udP1aIfk+gUN+1J9jB52EEhW2zQRMQQOmbY0LVHT2pq+gZWEk fdvVamgEdFnSe3pMbGs= X-Received: by 10.200.4.44 with SMTP id v44mr17921495qtg.135.1492822833666; Fri, 21 Apr 2017 18:00:33 -0700 (PDT) Received: from [10.0.30.228] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id c26sm7556692qte.19.2017.04.21.18.00.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Apr 2017 18:00:32 -0700 (PDT) From: Ted Lemon Message-Id: <915BE3FC-354F-4A2D-B33C-AC2DF40ADC21@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_16CB7953-2AAD-450E-8CFA-0DBFA72B06B7" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 21 Apr 2017 21:00:30 -0400 In-Reply-To: Cc: John Levine , "jmap@ietf.org" To: Adrien de Croy References: <20170421231922.29225.qmail@ary.lan> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Jmap] Submission X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Apr 2017 01:00:36 -0000 --Apple-Mail=_16CB7953-2AAD-450E-8CFA-0DBFA72B06B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 21, 2017, at 7:30 PM, Adrien de Croy wrote: > I'm imagining a system where the JMAP server uses JMAP to send it the = next hop as well if required, and so on, thereby avoiding the = limitations of SMTP. I really don't think this is likely. However, that doesn't mean that = fixing the first hop is a bad idea. I suspect that what will happen is = that when we are done with this work, if there is demand to improve the = experience for subsequent hops, the pressure will probably arrive the = same way the pressure for JMAP did: from large sites, where large wins = can be had by implementing something like this, even if it is not = universal. IOW, we should do the JMAP part right, in hopes that things will improve = in the rest of the system, not tune the JMAP solution to the lowest = common denominator. --Apple-Mail=_16CB7953-2AAD-450E-8CFA-0DBFA72B06B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Apr 21, 2017, at 7:30 PM, Adrien de Croy <adrien@qbik.com> = wrote:
I'm imagining a = system where the JMAP server uses JMAP to send it the next hop as well = if required, and so on, thereby avoiding the limitations of = SMTP.

I = really don't think this is likely.   However, that doesn't mean = that fixing the first hop is a bad idea.   I suspect that what will = happen is that when we are done with this work, if there is demand to = improve the experience for subsequent hops, the pressure will probably = arrive the same way the pressure for JMAP did: from large sites, where = large wins can be had by implementing something like this, even if it is = not universal.

IOW, we should do the JMAP part right, in hopes that things = will improve in the rest of the system, not tune the JMAP solution to = the lowest common denominator.

= --Apple-Mail=_16CB7953-2AAD-450E-8CFA-0DBFA72B06B7-- From nobody Fri Apr 21 18:03:04 2017 Return-Path: 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 1180A129BCD for ; Fri, 21 Apr 2017 18:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.002 X-Spam-Level: X-Spam-Status: No, score=-7.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 ZMUaVaXEzKYZ for ; Fri, 21 Apr 2017 18:03:01 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B81FC129BBD for ; Fri, 21 Apr 2017 18:03:01 -0700 (PDT) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v3M12xIc029039 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 22 Apr 2017 01:03:00 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v3M12x0B028764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 22 Apr 2017 01:02:59 GMT Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id v3M12uIj013104; Sat, 22 Apr 2017 01:02:57 GMT Received: from [192.168.15.59] (/66.214.236.56) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 21 Apr 2017 18:02:56 -0700 From: "Chris Newman" To: "Adrien de Croy" Cc: "jmap@ietf.org" Date: Fri, 21 Apr 2017 18:02:55 -0700 Message-ID: <00616B85-F365-4B1F-82EA-2FF2623CED77@oracle.com> In-Reply-To: References: <20170421001702.24991.qmail@ary.lan> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Subject: [Jmap] Address Validation (was Re: Submission) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Apr 2017 01:03:03 -0000 On 20 Apr 2017, at 23:16, Adrien de Croy wrote: >> In article someone >> write: >>> I'd love to see a mail client that does at least initial validation >>> on >>> destination email addresses as they are added to the message, so >>> that >>> errors in the addresses which can be resolved at that stage (e.g. >>> NXDOMAIN) can be raised with the email author before the mail is >>> even >>> submitted. >> >> This is quite the can of worms. It's easy enough to look up a domain >> and see if it has an A or an MX, but whatever you were planning to do >> to validate mailboxes will get you blacklisted as a listwashing >> spammer. > sure, I think there are fundamental issues with trying to go further > than an A/MX for now, but if we built in a mechanism to verify > addresses, it could be extended later, rather than being blocked off > for all of eternity. > > Even A/MX would have some value. Who knows what kind of trusted mail > delivery infrastructure may come out in the future, at some stage we > have to fix SMTP. Forever is a long time. The present model for MUA mail address validation is to authenticate to an IETF standard submission server, issue a MAIL FROM + RCPT TO + RSET. Anyway, I support adding a feature in JMAP that does the equivalent of performing this sequence of commands on the Submission server and returns a 3-digit SMTP status code, optionally SMTP enhanced status codes (see RFC 3463 section 3.2) and text string. This is quite extensible and I believe this specific functionality is in-scope of the JMAP charter as Submission (RFC 6409) is explicitly in-scope. Doing address validation this way is already quite powerful. For example, if the submission server chooses to implement the SMTP 251/551 response codes for local users, the mail client gains the ability to prompt the user to correct the address book entry for that recipient. How much validation the submission server does then becomes a quality-of-implementation issue (and there are, of course, security/privacy issues). Future work would be to define additional SMTP/Submit enhanced status codes for additional address validation, but that's presently out-of-scope for the JMAP charter. The JMAP charter does not permit development of a new address validation mechanism and I object to development of a new incompatible validation mechanism on the grounds that having two mechanisms to perform the same function is poor design, when a full-standard mechanism to do address validation already exists. I support mapping the existing Submission validation mechanism to JMAP in a way that preserves all the semantics of the existing mechanism. - Chris From nobody Fri Apr 21 18:34:12 2017 Return-Path: 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 B90D5128B4E for ; Fri, 21 Apr 2017 18:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 q0fRhIDKZVKc for ; Fri, 21 Apr 2017 18:34:08 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [122.56.26.1]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00E4F127698 for ; Fri, 21 Apr 2017 18:34:07 -0700 (PDT) Received: From [192.168.1.146] (unverified [192.168.1.146]) by SMTP Server [192.168.1.3] (WinGate SMTP Receiver v9.0.5 (Build 5926)) with SMTP id <0001026507@smtp.qbik.com>; Sat, 22 Apr 2017 13:34:04 +1200 From: "Adrien de Croy" To: "Chris Newman" Cc: "jmap@ietf.org" Date: Sat, 22 Apr 2017 01:34:04 +0000 Message-Id: In-Reply-To: <00616B85-F365-4B1F-82EA-2FF2623CED77@oracle.com> References: <20170421001702.24991.qmail@ary.lan> <00616B85-F365-4B1F-82EA-2FF2623CED77@oracle.com> Reply-To: "Adrien de Croy" User-Agent: eM_Client/7.0.27943.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Jmap] Address Validation (was Re: Submission) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Apr 2017 01:34:11 -0000 "two mechanisms to perform the same function is poor design" Sorry I missed this one on the Mt Sinai tablets. We are now and have throughout history been completely inundated with=20 multiple designs and implementations of things for the same function.=20 History has proven this to be a vital part of evolution. Stating this is therefore by definition somehow "poor design" seems like= =20 an argument for never improving anything. It could just as well be argued that if the first incarnation were not=20 poor design there would be no need for the existence of (let alone=20 proposals for) the second and subsequent. So maybe with that=20 interpretation you're right. In any case validation upon submission of only local addresses is a long= =20 way short of validation prior to submission (during composition) of=20 local and remote addresses, or at least even just allowing for the=20 possibility of this. It's too little too late. Adrien ------ Original Message ------ From: "Chris Newman" To: "Adrien de Croy" Cc: "jmap@ietf.org" Sent: 22/04/2017 1:02:55 PM Subject: [Jmap] Address Validation (was Re: Submission) >On 20 Apr 2017, at 23:16, Adrien de Croy wrote: >>>In article someone=20 >>>write: >>>>I'd love to see a mail client that does at least initial validation=20 >>>>on >>>>destination email addresses as they are added to the message, so=20 >>>>that >>>>errors in the addresses which can be resolved at that stage (e.g. >>>>NXDOMAIN) can be raised with the email author before the mail is=20 >>>>even >>>>submitted. >>> >>>This is quite the can of worms. It's easy enough to look up a domain >>>and see if it has an A or an MX, but whatever you were planning to do >>>to validate mailboxes will get you blacklisted as a listwashing >>>spammer. >>sure, I think there are fundamental issues with trying to go further=20 >>than an A/MX for now, but if we built in a mechanism to verify=20 >>addresses, it could be extended later, rather than being blocked off=20 >>for all of eternity. >> >>Even A/MX would have some value. Who knows what kind of trusted mail=20 >>delivery infrastructure may come out in the future, at some stage we=20 >>have to fix SMTP. Forever is a long time. > >The present model for MUA mail address validation is to authenticate to= =20 >an IETF standard submission server, issue a MAIL FROM + RCPT TO + RSET.= =20 >Anyway, I support adding a feature in JMAP that does the equivalent of=20 >performing this sequence of commands on the Submission server and=20 >returns a 3-digit SMTP status code, optionally SMTP enhanced status=20 >codes (see RFC 3463 section 3.2) and text string. > >This is quite extensible and I believe this specific functionality is=20 >in-scope of the JMAP charter as Submission (RFC 6409) is explicitly=20 >in-scope. Doing address validation this way is already quite powerful.=20 >For example, if the submission server chooses to implement the SMTP=20 >251/551 response codes for local users, the mail client gains the=20 >ability to prompt the user to correct the address book entry for that=20 >recipient. > >How much validation the submission server does then becomes a=20 >quality-of-implementation issue (and there are, of course,=20 >security/privacy issues). Future work would be to define additional=20 >SMTP/Submit enhanced status codes for additional address validation,=20 >but that's presently out-of-scope for the JMAP charter. > >The JMAP charter does not permit development of a new address=20 >validation mechanism and I object to development of a new incompatible=20 >validation mechanism on the grounds that having two mechanisms to=20 >perform the same function is poor design, when a full-standard=20 >mechanism to do address validation already exists. I support mapping=20 >the existing Submission validation mechanism to JMAP in a way that=20 >preserves all the semantics of the existing mechanism. > > - Chris > >_______________________________________________ >Jmap mailing list >Jmap@ietf.org >https://www.ietf.org/mailman/listinfo/jmap From nobody Fri Apr 21 18:48:19 2017 Return-Path: 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 BA484129A9C for ; Fri, 21 Apr 2017 18:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.002 X-Spam-Level: X-Spam-Status: No, score=-7.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 MGYtU0P3owFT for ; Fri, 21 Apr 2017 18:48:16 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C12981296C6 for ; Fri, 21 Apr 2017 18:48:16 -0700 (PDT) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v3M1mBdi025197 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 22 Apr 2017 01:48:12 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v3M1mB0S009545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 22 Apr 2017 01:48:11 GMT Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v3M1mAVM002988; Sat, 22 Apr 2017 01:48:10 GMT Received: from [192.168.15.59] (/66.214.236.56) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 21 Apr 2017 18:48:10 -0700 From: "Chris Newman" To: "Arnt Gulbrandsen" Cc: jmap@ietf.org Date: Fri, 21 Apr 2017 18:48:09 -0700 Message-ID: <77D58FD6-0D09-424E-8EEF-5C6738BAD6A4@oracle.com> In-Reply-To: <4471fa93-2321-4a7e-87b0-fbb00927d584@gulbrandsen.priv.no> References: <20170419163429.8556.qmail@ary.lan> <87d1c873cf.fsf@fifthhorseman.net> <01QDEV2QM6XC00005O@mauve.mrochek.com> <4471fa93-2321-4a7e-87b0-fbb00927d584@gulbrandsen.priv.no> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Subject: Re: [Jmap] Submission X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Apr 2017 01:48:17 -0000 On 21 Apr 2017, at 7:34, Arnt Gulbrandsen wrote: > Ted Lemon writes: >> I think the distinction comes from whether you actually think that >> the SMTP submission protocol is always going to be what's behind a >> message submitted via JMAP. If you think that, then it's going to >> look really weird to not just replicate that exact paradigm with the >> JMAP submission process. > > Hm? > > Won't the nexthop generally be the thing that the port-587 server > forwards to? After all, JMAP already handles authentication, and it's > not clear to me that a typical JMAP server is easily able to > authenticate on behalf of the end user in a way that a port-587 server > accepts. There are lots of standard ways for a proxy to authenticate on behalf of another user to another server. SASL PLAIN over TLS is the most obvious, but a TLS client certificate plus SASL EXTERNAL also works. The OAuth SASL mechanism could also be useful if it was designed correctly (sorry, I haven't reviewed it in detail with respect to that use case). My product's existing JMAP-like proxy is a JSON/HTTP to submission/IMAP proxy. One of the design errors that was made (back in the 1990s) was to not support submission extensions. This is one of the largest remaining design errors in our proxy and has caused significant problems. I do not want the JMAP standard to repeat the mistake we made. > Assuming that JMAP forwards to the filter or smarthost, then requiring > that JMAP servers be able to forward SMTP extensions looks really odd. > A submission server on port 587 cannot forward SMTP extensions from > its nexthop, why should one on port 443 have to? Submission servers do forward hop-to-hop extensions to the next hop. It's how they have to work. SMTP extensions like DELIVERBY, RRVS, SMTPUTF8, MTRK require hop-to-hop forwarding of SMTP parameters. > The usual answer is "so as to not need a corresponding JMAP RFC > whenever there's a new SMTP RFC". That strikes me as poor. A new > extension requires an RFC and three kinds of implementations (SMTP > client, submission server, filter server). The RFC publication bit > isn't usually the bottleneck among those four. We're going to need submission servers until all useful software is updated to use JMAP submission. I'd guess that at many sites that will never happen. So if we must have SMTP submission, then it's desirable to keep JMAP submission as close in semantics to SMTP submission as possible in order to minimize the attack surface and code complexity of the system. Yes, there are some specific tradeoffs where there might be a good reason to deviate from full submission semantics; for example, I'm unsure per-recipient status is useful to most clients so an option where any failed recipient results in failed submission would make sense to me in JMAP. And, of course, JMAP submission should be one round-trip and may have helpful side-effects like moving a message from the \Drafts folder to \Sent folder on success. >> The point is that whichever choice we make, we are going to pay a >> price for it. It's worth asking what that price is, and also asking >> what the advantages are to the choices we have, and then deciding on >> that basis. The fact that we would pay a price for not replicating >> SMTP submission can definitely be taken as a given. > > +1 > > Arnt - Chris From nobody Fri Apr 21 19:16:55 2017 Return-Path: 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 64AF4126DD9 for ; Fri, 21 Apr 2017 19:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 j7WBnXbzRMIx for ; Fri, 21 Apr 2017 19:16:52 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B64B612025C for ; Fri, 21 Apr 2017 19:16:52 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id f76so3945028qke.2 for ; Fri, 21 Apr 2017 19:16:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=iZQkAMzeLJyQHCVGni2pp6MPX7iIX/9LnF40WYII2SA=; b=a8a8LlhtirsLysOolS1wjXZcyVArlCE8VNd7Axu03GLf2If/qGuTneCVQCtjFNaW5u /UqBBX2NJuw89jGsSLaOHqMuO6EEVPQkMhqrJwgfIFHBa28Bil34QWJlmezNNk6AY3pi P9MLnIZcw/6+TthN3Guca3kh12J6z1ZwOqBw9o6FQ+UCUFxN/X0rLhq1lY2p2my6WxNd 9HYDrMPzJtHhAiDKLBeSMvRxM6/9fZJqMUH9ee7aECGRI1PDvooa+LHgHfKMHN0VjwGb V4nz4t8GkNl5YgpS4F9GSay/k0WGaK54C/g/b8q7hvdPA8xh0QvupB9xXltIoIW8R+j1 uHhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=iZQkAMzeLJyQHCVGni2pp6MPX7iIX/9LnF40WYII2SA=; b=uFdvaCvB6m/j3Y8fCDVMICSf0D4e8oN+lTKQgDxW529iisW/3JmaRFHHlNvbOInHDo OlDzTG7Ld/+6+5ybhkCaK7akfd2zzfvGzaX6aA109i5gIZGOPPpV3a2slMiVSh/Km+Ua uDsxB5ut0deTOtn5Ogd0t7gKQ5gKkZAfbh/QOo8Ejl6GvRkbY7Fa3iNZ8Rx4HL9DNmac HlkkE/MXS5k9WrAaAhRVF7j5pCLccuK/E8aHHKhZlxDw13X/y5MBbIpYCYIbJSPHDGPs RBsnNA0aOUiNPl96rDisOJnbjoheWd9cEpMw0x0oBA6mR8Nq9MH8gudT2JIPxeizA7pC glRQ== X-Gm-Message-State: AN3rC/5YaUv8vt8d5OfUif5EDQ+YCCZ/OuhrRwZGhBPeoujy9mi37NeF GXzByQRdYisgGyEaBew= X-Received: by 10.55.65.133 with SMTP id o127mr15513040qka.71.1492827411683; Fri, 21 Apr 2017 19:16:51 -0700 (PDT) Received: from [10.0.30.228] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id t129sm7660123qkf.36.2017.04.21.19.16.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Apr 2017 19:16:50 -0700 (PDT) From: Ted Lemon Message-Id: <2409CB86-1C1B-417B-9934-B969180C714F@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_F60CF2BA-7003-4F38-B63F-35635729AE4D" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 21 Apr 2017 22:16:49 -0400 In-Reply-To: <77D58FD6-0D09-424E-8EEF-5C6738BAD6A4@oracle.com> Cc: Arnt Gulbrandsen , jmap@ietf.org To: Chris Newman References: <20170419163429.8556.qmail@ary.lan> <87d1c873cf.fsf@fifthhorseman.net> <01QDEV2QM6XC00005O@mauve.mrochek.com> <4471fa93-2321-4a7e-87b0-fbb00927d584@gulbrandsen.priv.no> <77D58FD6-0D09-424E-8EEF-5C6738BAD6A4@oracle.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Jmap] Submission X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Apr 2017 02:16:54 -0000 --Apple-Mail=_F60CF2BA-7003-4F38-B63F-35635729AE4D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 21, 2017, at 9:48 PM, Chris Newman = wrote: > My product's existing JMAP-like proxy is a JSON/HTTP to = submission/IMAP proxy. One of the design errors that was made (back in = the 1990s) was to not support submission extensions. This is one of the = largest remaining design errors in our proxy and has caused significant = problems. I do not want the JMAP standard to repeat the mistake we made. Can you give an example of a failure mode that resulted from this = omission? (Not doubting you, just curious what the specific problem = was). --Apple-Mail=_F60CF2BA-7003-4F38-B63F-35635729AE4D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Apr 21, 2017, at 9:48 PM, Chris Newman <chris.newman@oracle.com> wrote:
My product's existing JMAP-like proxy is = a JSON/HTTP to submission/IMAP proxy. One of the design errors that was = made (back in the 1990s) was to not support submission extensions. This = is one of the largest remaining design errors in our proxy and has = caused significant problems. I do not want the JMAP standard to repeat = the mistake we made.

Can you give an example of a failure mode that resulted from = this omission?  (Not doubting you, just curious what the specific = problem was).

= --Apple-Mail=_F60CF2BA-7003-4F38-B63F-35635729AE4D-- From nobody Fri Apr 21 19:26:43 2017 Return-Path: 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 5633D12708C for ; Fri, 21 Apr 2017 19:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 EJN2kTkWI7nj for ; Fri, 21 Apr 2017 19:26:40 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB2AB12025C for ; Fri, 21 Apr 2017 19:26:39 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v3M2QcDY004852 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 22 Apr 2017 02:26:39 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v3M2QcWs015009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 22 Apr 2017 02:26:38 GMT Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v3M2QbwN013759; Sat, 22 Apr 2017 02:26:37 GMT Received: from [192.168.15.59] (/66.214.236.56) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 21 Apr 2017 19:26:37 -0700 From: "Chris Newman" To: "Adrien de Croy" Cc: "jmap@ietf.org" Date: Fri, 21 Apr 2017 19:26:36 -0700 Message-ID: <63C94A82-4399-41C3-A30C-4A9780D4E6F8@oracle.com> In-Reply-To: References: <20170421151636.28173.qmail@ary.lan> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Subject: [Jmap] Message Tracking and JMAP extensibility (was Re: Submission is not hard) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Apr 2017 02:26:41 -0000 On 21 Apr 2017, at 15:34, Adrien de Croy wrote: > ------ Original Message ------ > From: "John Levine" > To: "jmap@ietf.org" > Cc: "mellon@fugue.com" > Sent: 22/04/2017 3:16:36 AM > Subject: Re: [Jmap] Submission is not hard >> >> Finally, if people want to try whizbang ways to show animations of >> mail zipping through the aether, that sounds like a swell optional >> add-on to try and implement and test and perhaps bring back later as >> an extension, but it'd be nuts to try to invent it now. > > IME, if we don't design it now, it will never happen. Surely it's > important enough to do the work up front? I believe that client-convenient message tracking status is a desirable feature of a mail system. But the real world shows that tracking status and automated DSN/MDN handling is not sufficiently important for clients to have used existing facilities to provide that functionality; even though it's completely possible to do so. So no, I do not think this feature should be included in the base JMAP specification and believe the client developer community has spoken through their actions that it is not high priority. Furthermore, Message Tracking functionality is presently out of scope for the JMAP charter. The WG Chair can shut down any significant discussion on the topic to keep us on track to deliver the base JMAP specification. What I'd consider appropriate to discuss on this list is if JMAP is extensible in such a way that we can add client-convenient tracking status to JMAP in a future extension. Extensibility is critical for a base specification to get right. Here's an example client-convenient tracking model: have a server-mutable object attached to messages in the \Sent folder that can convey tracking status along the lines of RFC 3887 + DSN + MDN. I believe that's a completely workable model for message tracking that can be added in the future as a JMAP extension. Such an extension could go further and allow the JMAP view of the mailstore to convert DSN and MDN to status on the message in the \Sent folder (if such a message can be found) for clients that want the convenient delivery/tracking/MDN-status feature. So the question that's in-scope for the working group is if there's anything in the present design of JMAP that would prevent an extension along those lines? - Chris From nobody Fri Apr 21 19:34:12 2017 Return-Path: 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 B6466128B90 for ; Fri, 21 Apr 2017 19:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 3MKEEKTk0usb for ; Fri, 21 Apr 2017 19:34:09 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [122.56.26.1]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 587BC127286 for ; Fri, 21 Apr 2017 19:34:08 -0700 (PDT) Received: From [192.168.1.146] (unverified [192.168.1.146]) by SMTP Server [192.168.1.3] (WinGate SMTP Receiver v9.0.5 (Build 5926)) with SMTP id <0001026525@smtp.qbik.com>; Sat, 22 Apr 2017 14:34:06 +1200 From: "Adrien de Croy" To: "Ted Lemon" , "Chris Newman" Cc: "jmap@ietf.org" , "Arnt Gulbrandsen" Date: Sat, 22 Apr 2017 02:34:06 +0000 Message-Id: In-Reply-To: <2409CB86-1C1B-417B-9934-B969180C714F@fugue.com> References: <20170419163429.8556.qmail@ary.lan> <87d1c873cf.fsf@fifthhorseman.net> <01QDEV2QM6XC00005O@mauve.mrochek.com> <4471fa93-2321-4a7e-87b0-fbb00927d584@gulbrandsen.priv.no> <77D58FD6-0D09-424E-8EEF-5C6738BAD6A4@oracle.com> <2409CB86-1C1B-417B-9934-B969180C714F@fugue.com> Reply-To: "Adrien de Croy" User-Agent: eM_Client/7.0.27943.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MBD88CE545-D595-4FA7-B6CD-AB9C6BFBAEDF" Archived-At: Subject: Re: [Jmap] Submission X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Apr 2017 02:34:11 -0000 --------=_MBD88CE545-D595-4FA7-B6CD-AB9C6BFBAEDF Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable yes, also curious about this. Real world experience is always good to=20 learn. ------ Original Message ------ From: "Ted Lemon" To: "Chris Newman" Cc: "jmap@ietf.org" ; "Arnt Gulbrandsen"=20 Sent: 22/04/2017 2:16:49 PM Subject: Re: [Jmap] Submission >On Apr 21, 2017, at 9:48 PM, Chris Newman =20 >wrote: >>My product's existing JMAP-like proxy is a JSON/HTTP to=20 >>submission/IMAP proxy. One of the design errors that was made (back in= =20 >>the 1990s) was to not support submission extensions. This is one of=20 >>the largest remaining design errors in our proxy and has caused=20 >>significant problems. I do not want the JMAP standard to repeat the=20 >>mistake we made. > >Can you give an example of a failure mode that resulted from this=20 >omission? (Not doubting you, just curious what the specific problem=20 >was). > --------=_MBD88CE545-D595-4FA7-B6CD-AB9C6BFBAEDF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

yes, also curious about this.= =C2=A0Real world experience is always good to learn.


------ Original Message ------
From: "Ted Lemon" <mellon@fugue= .com>
To: "Chris Newman" <chri= s.newman@oracle.com>
Cc: "jmap@ietf.org" <jmap@ietf.org= >; "Arnt Gulbrandsen" <arnt@gulbrandsen.priv.no>
Sent: 22/04/2017 2:16:49 PM
Subject: Re: [Jmap] Submission

On Apr 21, 2017, at 9:48 PM, Chris Newman <chris.newman@oracle.com> wrote:
My product's existing JMAP-like proxy is a JSON/HTTP to = submission/IMAP proxy. One of the design errors that was made (back in the= 1990s) was to not support submission extensions. This is one of the larges= t remaining design errors in our proxy and has caused significant problems.= I do not want the JMAP standard to repeat the mistake we made.

Can you give an exampl= e of a failure mode that resulted from this omission? =C2=A0(Not doubting= you, just curious what the specific problem was).
--------=_MBD88CE545-D595-4FA7-B6CD-AB9C6BFBAEDF-- From nobody Fri Apr 21 19:42:39 2017 Return-Path: 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 EE3371293E9 for ; Fri, 21 Apr 2017 19:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 Ed4NhudC_R2b for ; Fri, 21 Apr 2017 19:42:34 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [122.56.26.1]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E07AB127286 for ; Fri, 21 Apr 2017 19:42:33 -0700 (PDT) Received: From [192.168.1.146] (unverified [192.168.1.146]) by SMTP Server [192.168.1.3] (WinGate SMTP Receiver v9.0.5 (Build 5926)) with SMTP id <0001026528@smtp.qbik.com>; Sat, 22 Apr 2017 14:42:30 +1200 From: "Adrien de Croy" To: "Chris Newman" Cc: "jmap@ietf.org" Date: Sat, 22 Apr 2017 02:42:31 +0000 Message-Id: In-Reply-To: <63C94A82-4399-41C3-A30C-4A9780D4E6F8@oracle.com> References: <20170421151636.28173.qmail@ary.lan> <63C94A82-4399-41C3-A30C-4A9780D4E6F8@oracle.com> Reply-To: "Adrien de Croy" User-Agent: eM_Client/7.0.27943.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Jmap] Message Tracking and JMAP extensibility (was Re: Submission is not hard) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Apr 2017 02:42:37 -0000 I think this is just another facet of the problem around implementation=20 uptake of optional features. There's still enough uncertainty about whether the entire end-to-end=20 path of a message will support the envelope options to cast doubt onto=20 any decision to implement it. A lot of the specs for these options have= =20 quite onerous requirements for dealing with non-compliant systems (those= =20 that do not advertise the extension). So I think this becomes a circular argument. We don't make new things=20 because history has shown new things don't get implemented. New things=20 don't get implemented because other existing things don't get upgraded=20 to add them. So I believe that's an argument to put things in from the start, rather=20 than deferring things. So much pain goes into trying to figure out how to deal with legacy=20 non-compliant systems. So I agree with Ted, we should do JMAP right from the start, and that=20 can then provide some real benefit on the first hop, and real incentive=20 for subsequent hops rather than a lowest-common-denominator approach. =20 So IMO the starting point should be what can be the best possible first=20 hop, in terms of best possible user experience. Because for=20 intra-server messaging, we can get (and then demonstrate/prove the value= =20 of) the benefit of this from the outset. Adrien ------ Original Message ------ From: "Chris Newman" To: "Adrien de Croy" Cc: "jmap@ietf.org" Sent: 22/04/2017 2:26:36 PM Subject: [Jmap] Message Tracking and JMAP extensibility (was Re:=20 Submission is not hard) >On 21 Apr 2017, at 15:34, Adrien de Croy wrote: >>------ Original Message ------ >>From: "John Levine" >>To: "jmap@ietf.org" >>Cc: "mellon@fugue.com" >>Sent: 22/04/2017 3:16:36 AM >>Subject: Re: [Jmap] Submission is not hard >>> >>>Finally, if people want to try whizbang ways to show animations of >>>mail zipping through the aether, that sounds like a swell optional >>>add-on to try and implement and test and perhaps bring back later as >>>an extension, but it'd be nuts to try to invent it now. >> >>IME, if we don't design it now, it will never happen. Surely it's=20 >>important enough to do the work up front? > >I believe that client-convenient message tracking status is a desirable= =20 >feature of a mail system. But the real world shows that tracking status= =20 >and automated DSN/MDN handling is not sufficiently important for=20 >clients to have used existing facilities to provide that functionality;= =20 >even though it's completely possible to do so. So no, I do not think=20 >this feature should be included in the base JMAP specification and=20 >believe the client developer community has spoken through their actions= =20 >that it is not high priority. Furthermore, Message Tracking=20 >functionality is presently out of scope for the JMAP charter. The WG=20 >Chair can shut down any significant discussion on the topic to keep us=20 >on track to deliver the base JMAP specification. > >What I'd consider appropriate to discuss on this list is if JMAP is=20 >extensible in such a way that we can add client-convenient tracking=20 >status to JMAP in a future extension. Extensibility is critical for a=20 >base specification to get right. > >Here's an example client-convenient tracking model: have a=20 >server-mutable object attached to messages in the \Sent folder that can= =20 >convey tracking status along the lines of RFC 3887 + DSN + MDN. I=20 >believe that's a completely workable model for message tracking that=20 >can be added in the future as a JMAP extension. Such an extension could= =20 >go further and allow the JMAP view of the mailstore to convert DSN and=20 >MDN to status on the message in the \Sent folder (if such a message can= =20 >be found) for clients that want the convenient=20 >delivery/tracking/MDN-status feature. > >So the question that's in-scope for the working group is if there's=20 >anything in the present design of JMAP that would prevent an extension=20 >along those lines? > > - Chris > >_______________________________________________ >Jmap mailing list >Jmap@ietf.org >https://www.ietf.org/mailman/listinfo/jmap From nobody Fri Apr 21 20:08:35 2017 Return-Path: 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 E28CA127876 for ; Fri, 21 Apr 2017 20:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 v0AcAXKwZ0-R for ; Fri, 21 Apr 2017 20:08:32 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC0411250B8 for ; Fri, 21 Apr 2017 20:08:32 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v3M38R4I028023 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 22 Apr 2017 03:08:27 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v3M38RTJ014233 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 22 Apr 2017 03:08:27 GMT Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v3M38Qu0024369; Sat, 22 Apr 2017 03:08:26 GMT Received: from [192.168.15.59] (/66.214.236.56) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 21 Apr 2017 20:08:25 -0700 From: "Chris Newman" To: "Ted Lemon" Cc: jmap@ietf.org, "Arnt Gulbrandsen" Date: Fri, 21 Apr 2017 20:08:23 -0700 Message-ID: <0B3ACACC-7FF2-4A65-9DE9-2238DEB70818@oracle.com> In-Reply-To: <2409CB86-1C1B-417B-9934-B969180C714F@fugue.com> References: <20170419163429.8556.qmail@ary.lan> <87d1c873cf.fsf@fifthhorseman.net> <01QDEV2QM6XC00005O@mauve.mrochek.com> <4471fa93-2321-4a7e-87b0-fbb00927d584@gulbrandsen.priv.no> <77D58FD6-0D09-424E-8EEF-5C6738BAD6A4@oracle.com> <2409CB86-1C1B-417B-9934-B969180C714F@fugue.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Subject: Re: [Jmap] Submission X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Apr 2017 03:08:34 -0000 On 21 Apr 2017, at 19:16, Ted Lemon wrote: > On Apr 21, 2017, at 9:48 PM, Chris Newman > wrote: >> My product's existing JMAP-like proxy is a JSON/HTTP to >> submission/IMAP proxy. One of the design errors that was made (back >> in the 1990s) was to not support submission extensions. This is one >> of the largest remaining design errors in our proxy and has caused >> significant problems. I do not want the JMAP standard to repeat the >> mistake we made. > > Can you give an example of a failure mode that resulted from this > omission? (Not doubting you, just curious what the specific problem > was). A rigid proxy design means complexity-increasing changes have to be made to three pieces of software instead of just two pieces of software. That means the entire system is more complex and less agile. With a proxy design that's well-aligned to the submission protocol, most submission extensions can be supported with just a configuration change (to pass through the new extension). So an extension increases system complexity in only two components with the better design. For our product, we have different developers on each component (Submission vs. HTTP proxy vs. Client UI) and some of the developers have a significant timezone shift. I leave the problems that causes to the imagination of the reader. - Chris From nobody Fri Apr 21 20:20:28 2017 Return-Path: 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 494F11250B8 for ; Fri, 21 Apr 2017 20:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.002 X-Spam-Level: X-Spam-Status: No, score=-7.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 Z0nsf4zW6F0y for ; Fri, 21 Apr 2017 20:20:24 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FFDD127876 for ; Fri, 21 Apr 2017 20:20:24 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v3M3KM8U013507 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 22 Apr 2017 03:20:22 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v3M3KMNu029593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 22 Apr 2017 03:20:22 GMT Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v3M3KKW3030026; Sat, 22 Apr 2017 03:20:21 GMT Received: from [192.168.15.59] (/66.214.236.56) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 21 Apr 2017 20:20:19 -0700 From: "Chris Newman" To: "Adrien de Croy" Cc: "jmap@ietf.org" Date: Fri, 21 Apr 2017 20:20:18 -0700 Message-ID: <84B51656-4D9A-47E2-BCEA-6B678E27930C@oracle.com> In-Reply-To: References: <20170421151636.28173.qmail@ary.lan> <63C94A82-4399-41C3-A30C-4A9780D4E6F8@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: MailMate (1.9.6r5347) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Subject: Re: [Jmap] Message Tracking and JMAP extensibility (was Re: Submission is not hard) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Apr 2017 03:20:26 -0000 On 21 Apr 2017, at 19:42, Adrien de Croy wrote: > I think this is just another facet of the problem around = > implementation uptake of optional features. > > There's still enough uncertainty about whether the entire end-to-end = > path of a message will support the envelope options to cast doubt onto = > any decision to implement it. A lot of the specs for these options = > have quite onerous requirements for dealing with non-compliant systems = > (those that do not advertise the extension). > > So I think this becomes a circular argument. We don't make new things = > because history has shown new things don't get implemented. New = > things don't get implemented because other existing things don't get = > upgraded to add them. If JMAP is well aligned with submission, that's one less barrier to = deployment of extensions. If it's not well aligned, then we have to = change another spec and another piece of software to get something new = deployed. I agree we should not make the extension uptake problem worse = by having JMAP out of semantic alignment with Submission for extensions. > So I believe that's an argument to put things in from the start, = > rather than deferring things. I made this exact argument many times while developing the ACAP base = specification. It resulted in a 44-page specification that was unwieldy = to implement and thus failed to deploy. I am opposed to changing the = JMAP working charter to allow us to go down that path for message = tracking/status functionality. I take this position because I want JMAP = to deploy and I try to learn from my past mistakes. At this point, I don't think I have anything more to add on the message = tracking/status issue. - Chris > So much pain goes into trying to figure out how to deal with legacy = > non-compliant systems. > > So I agree with Ted, we should do JMAP right from the start, and that = > can then provide some real benefit on the first hop, and real = > incentive for subsequent hops rather than a lowest-common-denominator = > approach. So IMO the starting point should be what can be the best = > possible first hop, in terms of best possible user experience. = > Because for intra-server messaging, we can get (and then = > demonstrate/prove the value of) the benefit of this from the outset. > > Adrien > > > ------ Original Message ------ > From: "Chris Newman" > To: "Adrien de Croy" > Cc: "jmap@ietf.org" > Sent: 22/04/2017 2:26:36 PM > Subject: [Jmap] Message Tracking and JMAP extensibility (was Re: = > Submission is not hard) > >> On 21 Apr 2017, at 15:34, Adrien de Croy wrote: >>> ------ Original Message ------ >>> From: "John Levine" >>> To: "jmap@ietf.org" >>> Cc: "mellon@fugue.com" >>> Sent: 22/04/2017 3:16:36 AM >>> Subject: Re: [Jmap] Submission is not hard >>>> >>>> Finally, if people want to try whizbang ways to show animations of >>>> mail zipping through the aether, that sounds like a swell optional >>>> add-on to try and implement and test and perhaps bring back later = >>>> as >>>> an extension, but it'd be nuts to try to invent it now. >>> >>> IME, if we don't design it now, it will never happen. Surely it's = >>> important enough to do the work up front? >> >> I believe that client-convenient message tracking status is a = >> desirable feature of a mail system. But the real world shows that = >> tracking status and automated DSN/MDN handling is not sufficiently = >> important for clients to have used existing facilities to provide = >> that functionality; even though it's completely possible to do so. So = >> no, I do not think this feature should be included in the base JMAP = >> specification and believe the client developer community has spoken = >> through their actions that it is not high priority. Furthermore, = >> Message Tracking functionality is presently out of scope for the JMAP = >> charter. The WG Chair can shut down any significant discussion on the = >> topic to keep us on track to deliver the base JMAP specification. >> >> What I'd consider appropriate to discuss on this list is if JMAP is = >> extensible in such a way that we can add client-convenient tracking = >> status to JMAP in a future extension. Extensibility is critical for a = >> base specification to get right. >> >> Here's an example client-convenient tracking model: have a = >> server-mutable object attached to messages in the \Sent folder that = >> can convey tracking status along the lines of RFC 3887 + DSN + MDN. I = >> believe that's a completely workable model for message tracking that = >> can be added in the future as a JMAP extension. Such an extension = >> could go further and allow the JMAP view of the mailstore to convert = >> DSN and MDN to status on the message in the \Sent folder (if such a = >> message can be found) for clients that want the convenient = >> delivery/tracking/MDN-status feature. >> >> So the question that's in-scope for the working group is if there's = >> anything in the present design of JMAP that would prevent an = >> extension along those lines? >> >> - Chris >> >> _______________________________________________ >> Jmap mailing list >> Jmap@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_ma= ilman_listinfo_jmap&d=3DDwIFaQ&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057= SbK10&r=3DQBZgPENFbjFadxqU4HJ3ZDpRz3X1JlDY-keqMt52FFo&m=3D3-MZtEL_JnGA64b= IHNq8ZGszP3FJT07irtG2_lYIYrk&s=3DyXtYh6_dIHPe2bohL8G5YBE_9y5bxVWBqwJgKr_P= vzs&e=3D From nobody Sun Apr 23 16:37:25 2017 Return-Path: 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 B4153127078 for ; Sun, 23 Apr 2017 16:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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=mrochek.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 wAsSVN_7DsFp for ; Sun, 23 Apr 2017 16:37:22 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AFB7127076 for ; Sun, 23 Apr 2017 16:37:22 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QDITVTCROW0083TI@mauve.mrochek.com> for jmap@ietf.org; Sun, 23 Apr 2017 16:32:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1492990338; bh=7ZAW2Mg4biMgQNxEqcNQI6l+iygDOT8n1LK6YjwC+Io=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=HjmmN4OiCqYWLv9b7va5s+eBvJDQAKTwX8TL69nlEtHjkNz7W2ahAw4mDtOxw7m7l URK4cVUFswYgLdEJlhIArKjuN3Ffcm2ux6KbYAuGmUBLHbOAHQR3opXSfyOZhaFgu4 Yompbsrujl701Xf2odx9PdFQiHV7P6MSaUQQ76ew= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QD64433M0W00005B@mauve.mrochek.com>; Sun, 23 Apr 2017 16:32:16 -0700 (PDT) Cc: Ned Freed , jmap@ietf.org Message-id: <01QDITVRJT3O00005B@mauve.mrochek.com> Date: Sun, 23 Apr 2017 16:13:36 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 21 Apr 2017 11:27:57 -0400" <65CA1C64-ACD9-4AF5-8ED4-59D4285B5A8D@fugue.com> References: <20170419163429.8556.qmail@ary.lan> <87d1c873cf.fsf@fifthhorseman.net> <01QDEV2QM6XC00005O@mauve.mrochek.com> <01QDFJV9BBBS00005O@mauve.mrochek.com> <65CA1C64-ACD9-4AF5-8ED4-59D4285B5A8D@fugue.com> To: Ted Lemon Archived-At: Subject: Re: [Jmap] Submission X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Apr 2017 23:37:24 -0000 > On Apr 21, 2017, at 11:02 AM, Ned Freed wrote: > > The issue is semantics, not syntax. If your design locks you in to a > > particular set of semantics that cannot be extended - which is what any > > design that fails to allow for capability discovery and attachment of > > arbitrary parameters - you've put yourself in a position where you need > > to continually revise things in order to keep them synchronized as the > > capabilities of the transport infrasture continue to evolve. > Yes, I hear this concern. I'm saying that it's to be weighed against the > benefits of making the JMAP submission protocol primary, rather than nailing it > to SMTP submission. This is a entirely false dichotomy of choices you have going here. Nobody is proposing "nailing it to SUBMIT". All anyone is saying is that you need to have a means of specifying the envelope separate from the message and its headers, and that the envelope needs to be extensible. Aside from the fact that SUBMIT happens to be a protocol that implements these semantics (actually with some limitations that probably should be removed in JMAP), this has nothing to do with using SUBMIT. If, given this framework or a superset of it, you want you implement mechanisms that cannot be implemented in SUBMIT, that's an entirely separate discussion, and I look forward to the specification describing such a mechanism. The long and short of it is I really don't understand why you persist in worrying about SUBMIT, but since neither of these fundamental concepts we're concerned with having in JMAP originated in SUBMIT or even SMTP, maybe it would help to name them after where they did (AFAIK) originate. So if I say "IFIP style envelope/message separation" and "X.400-1988 style extensible envelope parameters", does it help? > And as a practical matter, as Arnt said, if SMTP submission continues to be > the place where innovation occurs, then this means implementations will have to > follow that. Indeed it does. And without having the right semantics they will do so slowly and painfully. > I don't think it's fair to assume that preserving the semantics of SMTP > submission in JMAP submission is going to get you to a place of win. Again with characterizing this as all about SUBMIT. It isn't. > Any JMAP implementation that doesn't use SMTP submission as a backend is > still going to have to track SMTP submission RFCs, or else there will be > interop problems. Actually, no, it won't. We've been down this path before with nonextensible submission APIs of various sorts. It has not gone well. > For such implementations, the need for a JMAP RFC to track relevant new > functionality added to SMTP submit is good, not bad. So rather than having a clean extensible architecture with minimal costs to use, you're arguing that we should start with a much more limited architecture that requires unnnecessary specifications to extend? This strikes me as fundamentally wrongminded. > For the use case you are concerned about, I think it doesn't matter; the > point I am making here is just that that is not the only use case we ought to > consider. If you can name a possible use case that is hindered by having an extensible separate envelope, I'd love to hear what it is and why this is the case. Ned From nobody Sun Apr 23 16:49:22 2017 Return-Path: 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 C8E1A1270AC for ; Sun, 23 Apr 2017 16:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 xw9sOSs750Bb for ; Sun, 23 Apr 2017 16:49:18 -0700 (PDT) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC72D127076 for ; Sun, 23 Apr 2017 16:49:17 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id y33so101964875qta.2 for ; Sun, 23 Apr 2017 16:49:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=P6AOSBqJ8yE7ielPkIQxEccFkPmCfIFN4dbyrjQ11CU=; b=pJtMzNxPoqA6g2yrZyPPo6WBx4Li+6XFQ2Iaut5iPGzZdTcyCJxGTjYZhOtfn86Oft ftDnPWS0YSTgKKSfYY+4AIToqo2JlgCVRAnSCFTsWVFcP3teR6CkSVam4niSujgZuj// 8OtDIdZ6CVwrTUGsTi+7TMmLDtDAiSje/4A4/6kc9bxUSJXxqSOei7uc8Z9PWTNroqjg liCWrnmytLUER0Tgir33Y+uDGcdMat1nE/iY6fw3qTr15z9Elqu09xFQa3cVl1Ya7D9Y hcFH2H8NvWrbXuDyQWPWy4fLuHwO+5xsi8io+ctkcW58atiFtnzEPh/RNWr6pJjrREFO UEAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=P6AOSBqJ8yE7ielPkIQxEccFkPmCfIFN4dbyrjQ11CU=; b=l4iqM3upAGAKy6MyIbfRTQv53jsY1Qp2EAEPlvfkgzL1Ze8unKCWQ7LijJnUkHn2sd FibB272v8gijmFEaRoC81RTab4B5w6wkNHhe5+RZ61CKD32uPwHz6l44+QgkmrnNuLTW u9wPzwQY/XH4Hv5JaSGnSZMNVpfAUekgd/4FrwbADmxreq0G+lJ1zP3SnKwgC/u2INJ2 ZZ0ykpDStRt01ADV62VS6EiW9agwyuGXfmXC5Z1WrveArW1PNZjkemA6/3d5RExpkTFw xwW3XHPvtS8EROe/4y6l3AD0cfKcsQUjcazeb4Kbx0FksnsfgQuXaJX7sflzkvPM1DvL m71w== X-Gm-Message-State: AN3rC/7SOBFiJ840CQ1MyQAvuYuiQpU7BxqYGgmLJxoxiPwxR+zv5Urx o/EDgpMpJ+ZVMg== X-Received: by 10.200.42.29 with SMTP id k29mr13228914qtk.186.1492991356892; Sun, 23 Apr 2017 16:49:16 -0700 (PDT) Received: from macbook-pro-6.home (pool-108-31-94-75.washdc.fios.verizon.net. [108.31.94.75]) by smtp.gmail.com with ESMTPSA id h37sm3213379qtc.47.2017.04.23.16.49.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 23 Apr 2017 16:49:15 -0700 (PDT) From: Ted Lemon Message-Id: <87F9079E-AAC7-49C7-99FC-79F19AA3C5D6@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_827043B8-DAE1-44D7-BFFF-84C3F66B5DC3" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sun, 23 Apr 2017 19:49:15 -0400 In-Reply-To: <01QDITVRJT3O00005B@mauve.mrochek.com> Cc: jmap@ietf.org To: Ned Freed References: <20170419163429.8556.qmail@ary.lan> <87d1c873cf.fsf@fifthhorseman.net> <01QDEV2QM6XC00005O@mauve.mrochek.com> <01QDFJV9BBBS00005O@mauve.mrochek.com> <65CA1C64-ACD9-4AF5-8ED4-59D4285B5A8D@fugue.com> <01QDITVRJT3O00005B@mauve.mrochek.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Jmap] Submission X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Apr 2017 23:49:20 -0000 --Apple-Mail=_827043B8-DAE1-44D7-BFFF-84C3F66B5DC3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 23, 2017, at 7:13 PM, Ned Freed wrote: > This is a entirely false dichotomy of choices you have going here. = Nobody is > proposing "nailing it to SUBMIT". All anyone is saying is that you = need to > have a means of specifying the envelope separate from the message and = its > headers, and that the envelope needs to be extensible. If that's the case, then I don't think there's anything to argue about. = But I've been getting the impression that that's not the case. I am = fully in agreement with the assertion, with which I don't recall anyone = disagreeing, that the envelope has to be separate from the message and = has to be extensible. My concern is with avoiding a requirement that JMAP submit have the same = _flow_ as SMTP submit. So I want it to be the case that status can be = delivered asynchronously, essentially. I don't mind if it's also = possible to deliver it synchronously, since that's just a degenerate = case of asynchronous. --Apple-Mail=_827043B8-DAE1-44D7-BFFF-84C3F66B5DC3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Apr 23, 2017, at 7:13 PM, Ned Freed <ned.freed@mrochek.com> wrote:
This is a entirely false dichotomy of = choices you have going here. Nobody is
proposing "nailing = it to SUBMIT". All anyone is saying is that you need to
have a means of specifying the envelope separate = from the message and its
headers, and that = the envelope needs to be extensible.

If that's the case, then I don't think = there's anything to argue about.   But I've been getting the = impression that that's not the case.   I am fully in agreement with = the assertion, with which I don't recall anyone disagreeing, that the = envelope has to be separate from the message and has to be = extensible.

My = concern is with avoiding a requirement that JMAP submit have the same = _flow_ as SMTP submit.   So I want it to be the case that status = can be delivered asynchronously, essentially.   I don't mind if = it's also possible to deliver it synchronously, since that's just a = degenerate case of asynchronous.

= --Apple-Mail=_827043B8-DAE1-44D7-BFFF-84C3F66B5DC3-- From nobody Sun Apr 23 16:54:47 2017 Return-Path: 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 6AE4412751F for ; Sun, 23 Apr 2017 16:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.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 ZEWqlAm5WT0o for ; Sun, 23 Apr 2017 16:54:43 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E49D91270B4 for ; Sun, 23 Apr 2017 16:54:42 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QDIUI8MI4W006AFI@mauve.mrochek.com> for jmap@ietf.org; Sun, 23 Apr 2017 16:49:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1492991376; bh=ajPMJ9RmEgUpa8dAW1wJRS822kPoFatIFIH/17+AR/A=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=MGbm3QtIzPTx2VGLqhNUMzfkftr3WjVqv7sOOsz1APK3XQueeBQkjE9TbswJdKRw7 bsIt90G2DYqEhVc74O7vpfs0ObQwXeP0kOijy646Q7B7jzXMR8KM15GMgAC6juH3OY AYhGTXgOIL9109hRmCIth9XyHVMUZ3pjK/HngZOQ= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QD64433M0W00005B@mauve.mrochek.com>; Sun, 23 Apr 2017 16:49:34 -0700 (PDT) Cc: jmap@ietf.org Message-id: <01QDIUI7C57800005B@mauve.mrochek.com> Date: Sun, 23 Apr 2017 16:37:29 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 21 Apr 2017 15:34:44 +0100" <4471fa93-2321-4a7e-87b0-fbb00927d584@gulbrandsen.priv.no> References: <20170419163429.8556.qmail@ary.lan> <87d1c873cf.fsf@fifthhorseman.net> <01QDEV2QM6XC00005O@mauve.mrochek.com> <4471fa93-2321-4a7e-87b0-fbb00927d584@gulbrandsen.priv.no> To: Arnt Gulbrandsen Archived-At: Subject: Re: [Jmap] Submission X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Apr 2017 23:54:44 -0000 > Won't the nexthop generally be the thing that the port-587 server forwards > to? That's highly unlikely. There's quite a lot of activity associated with message submission: Access control, auditing, spam/virus checks, content filtering, etc. JMAP doesn't make any of that magically vanish. Of course this doesn't mean that messages are going to be submitted using the SUBMIT protocol. But there has to be some kind of agent that performs these functions, irrespective of how you talk to it. > After all, JMAP already handles authentication, and it's not clear to > me that a typical JMAP server is easily able to authenticate on behalf of > the end user in a way that a port-587 server accepts. Proxy authentication is widely if not universally supported using any number of techniques. And again, you don't get rid of the need to perform any number of actions based on the submitters identity just because the user already authenticated to JMAP. > Assuming that JMAP forwards to the filter or smarthost, then requiring that > JMAP servers be able to forward SMTP extensions looks really odd. I have no idea what this "filter or smarthost" thing is that you're talking about, but I can assure you that if it isn't directly integrated into the SUBMIT server so it has direct access to credentials and can return immediate failures rather than delayed DSNs, you have a serious implementation problem. > A submission server on port 587 cannot forward SMTP extensions from its > nexthop, why should one on port 443 have to? Of course it can. Ours does this routinely. > The usual answer is "so as to not need a corresponding JMAP RFC whenever > there's a new SMTP RFC". That strikes me as poor. A new extension requires > an RFC and three kinds of implementations (SMTP client, submission server, > filter server). The RFC publication bit isn't usually the bottleneck among > those four. I guess you missed the recent discussion about the incredibly high cost of RFCs. (Not that I agree, but one of the reasons I disagree is that we've worked hard to eliminate the need to generate gratuitous material from the process.) Ned From nobody Sun Apr 23 17:29:47 2017 Return-Path: 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 528EE120726 for ; Sun, 23 Apr 2017 17:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 Uu9k_I8zZfzz for ; Sun, 23 Apr 2017 17:29:44 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [122.56.26.1]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32A6E1204DA for ; Sun, 23 Apr 2017 17:29:43 -0700 (PDT) Received: From [192.168.1.146] (unverified [192.168.1.146]) by SMTP Server [192.168.1.3] (WinGate SMTP Receiver v9.0.5 (Build 5926)) with SMTP id <0001027835@smtp.qbik.com>; Mon, 24 Apr 2017 12:29:39 +1200 From: "Adrien de Croy" To: "Ned Freed" , "Arnt Gulbrandsen" Cc: "jmap@ietf.org" Date: Mon, 24 Apr 2017 00:29:40 +0000 Message-Id: In-Reply-To: <01QDIUI7C57800005B@mauve.mrochek.com> References: <20170419163429.8556.qmail@ary.lan> <87d1c873cf.fsf@fifthhorseman.net> <01QDEV2QM6XC00005O@mauve.mrochek.com> <4471fa93-2321-4a7e-87b0-fbb00927d584@gulbrandsen.priv.no> <01QDIUI7C57800005B@mauve.mrochek.com> Reply-To: "Adrien de Croy" User-Agent: eM_Client/7.0.27943.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Jmap] Submission X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 00:29:46 -0000 ------ Original Message ------ From: "Ned Freed" > >Proxy authentication is widely if not universally supported using any >number of techniques. And again, you don't get rid of the need to >perform any number of actions based on the submitters identity just=20 >because >the user already authenticated to JMAP. I can think of one major platform (Windows) where this approach will be=20 highly problematic. Are we talking about a JMAP proxy (e.g. the client talks real-time via=20 the JMAP server to the SUBMIT server), or are we talking about a system=20 where the JMAP server accepts the message, and MAYBE forwards it via=20 SMTP or SUBMIT depending on the destination. If the latter, I would suggest that building a system that requires=20 individual user credentials to be presented to the next hop will be=20 highly problematic. Adrien > From nobody Sun Apr 23 17:33:03 2017 Return-Path: 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 5B9CD127871 for ; Sun, 23 Apr 2017 17:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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=mrochek.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 51sndu3Gnn_a for ; Sun, 23 Apr 2017 17:32:52 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBFC01204DA for ; Sun, 23 Apr 2017 17:32:52 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QDIVTM7TI80081MB@mauve.mrochek.com> for jmap@ietf.org; Sun, 23 Apr 2017 17:27:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1492993668; bh=WHRqQfB6mWcrVNCpYwSixzsoJKCXX4xQMBLUzjImJVE=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=Ih3IGCWdcByTWatzknWrf+OZxpGU9u3BXrp6Ui7SA9ezO1ZG7qk9xqc4UplsSuPsU OXPDP6SOuU3Wq/+GaB+GpY7QQIBrhTZBYIhquBP+R3/uTeRee4eesbqxhrWx6S4XWA Kla2fYbHcu79dTlfCnCS8ccTIGQNhZjX7Tbf52tY= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QD64433M0W00005B@mauve.mrochek.com>; Sun, 23 Apr 2017 17:27:45 -0700 (PDT) Cc: Ned Freed , jmap@ietf.org Message-id: <01QDIVTKAWPK00005B@mauve.mrochek.com> Date: Sun, 23 Apr 2017 16:50:54 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sun, 23 Apr 2017 19:49:15 -0400" <87F9079E-AAC7-49C7-99FC-79F19AA3C5D6@fugue.com> References: <20170419163429.8556.qmail@ary.lan> <87d1c873cf.fsf@fifthhorseman.net> <01QDEV2QM6XC00005O@mauve.mrochek.com> <01QDFJV9BBBS00005O@mauve.mrochek.com> <65CA1C64-ACD9-4AF5-8ED4-59D4285B5A8D@fugue.com> <01QDITVRJT3O00005B@mauve.mrochek.com> <87F9079E-AAC7-49C7-99FC-79F19AA3C5D6@fugue.com> To: Ted Lemon Archived-At: Subject: Re: [Jmap] Submission X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 00:32:56 -0000 > On Apr 23, 2017, at 7:13 PM, Ned Freed wrote: > > This is a entirely false dichotomy of choices you have going here. Nobody is > > proposing "nailing it to SUBMIT". All anyone is saying is that you need to > > have a means of specifying the envelope separate from the message and its > > headers, and that the envelope needs to be extensible. > If that's the case, then I don't think there's anything to argue about. But I've been getting the impression that that's not the case. I am fully in agreement with the assertion, with which I don't recall anyone disagreeing, that the envelope has to be separate from the message and has to be extensible. > My concern is with avoiding a requirement that JMAP submit have the same > _flow_ as SMTP submit. Huh? Nobody has said that. AFAIK nobody has even hinted at that. > So I want it to be the case that status can be delivered asynchronously, > essentially. I don't mind if it's also possible to deliver it synchronously, > since that's just a degenerate case of asynchronous. That's a completely different matter, and in that regard, I'll just make a few observations: (0) Synchronous delivery of status is, with the exception of a handful of egregiously broken clients, always going to provide the better user experience. This has everything to do with how people are wired and nothing to do with the technology. (1) SUBMIT and SMTP both have the ability to deliver status both synchronously and asynchronously. We call the latter "DSNs". They have not worked out well. (2) Asynchronous delivery of status information is NOT a degenerate case of synchronous delivery. For example, it's entirely possible for a SUBMIT server to always return success status codes and issue a DSN later. (In fact our SUBMIT server can be set to do exactly this, in order to deal with the aforementioned egregiously broken clients.) (3) The argument that DSNs being in-band rather than an out-of-band mechanism is the root cause of all the problems in this area doesn't fly. Out-of-band mechanisms for message status reporting have been tried - the obvious example is X.400 - and if anything they've worked less well than the in-band approach taken in SMTP. So nobody should assume that the definition of such a mechanism will magically lead to glory. (4) There seems to be an assumption that an alternative asynchronous notification mechanism is something that SUBMIT could not do. If so, that's incorrect. In fact I can easily imagine a SUBMIT extension that would specify an alternative mechanism for reporting delivery success/failures, which the server would then employ instead of generating one or more DSNs. In fact this would be so trivially easy to implement modulo whatever the backwards-pointing notification mechanism is I bet I could do it in only and hour or two of coding. (5) Implementing proper error handling is hard, getting everyone to implement it correctly is probably impossible. (6) There are a host of problems associated with the Outbox/Sent magic folder proposal that have nothing to do with anything being discussed here. In fact I believe I'm going to coin a new term at this point - the FUSMEHP. I bet you can geuss what it means. Ned From nobody Sun Apr 23 17:54:44 2017 Return-Path: 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 66A161270B4 for ; Sun, 23 Apr 2017 17:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 2QM4Zk1L3eZV for ; Sun, 23 Apr 2017 17:54:40 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [122.56.26.1]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0BB4124217 for ; Sun, 23 Apr 2017 17:54:39 -0700 (PDT) Received: From [192.168.1.146] (unverified [192.168.1.146]) by SMTP Server [192.168.1.3] (WinGate SMTP Receiver v9.0.5 (Build 5926)) with SMTP id <0001027847@smtp.qbik.com>; Mon, 24 Apr 2017 12:54:36 +1200 From: "Adrien de Croy" To: "Ned Freed" , "Ted Lemon" Cc: "jmap@ietf.org" , "Ned Freed" Date: Mon, 24 Apr 2017 00:54:36 +0000 Message-Id: In-Reply-To: <01QDIVTKAWPK00005B@mauve.mrochek.com> References: <20170419163429.8556.qmail@ary.lan> <87d1c873cf.fsf@fifthhorseman.net> <01QDEV2QM6XC00005O@mauve.mrochek.com> <01QDFJV9BBBS00005O@mauve.mrochek.com> <65CA1C64-ACD9-4AF5-8ED4-59D4285B5A8D@fugue.com> <01QDITVRJT3O00005B@mauve.mrochek.com> <87F9079E-AAC7-49C7-99FC-79F19AA3C5D6@fugue.com> <01QDIVTKAWPK00005B@mauve.mrochek.com> Reply-To: "Adrien de Croy" User-Agent: eM_Client/7.0.27943.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Jmap] Submission X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 00:54:42 -0000 Just to clarify about what I was thinking when I raised the spectre of=20 notifications. Quite often the person would like to see more than one. The key=20 attribute about notifications intended for humans is timeliness. We=20 have a system where you may get something that looks like a bounce=20 message 4hrs after sending your message. You may get a bounce message=20 10 minutes later (or worse) if you entered the destination address=20 incorrectly. You may have already gone home, and now missed the=20 deadline to submit your tender for the project. There are real=20 consequences to the delays that are created by mail systems. As for DSNs the person generally doesn't want to see them in their inbox= =20 as messages. Whether underneath these are multilpe DSNs or whatever I don't think=20 many people really care, although we have questions about what should a=20 client do to a server-stored message (e.g. as per IMAP) when it's a=20 control message like this (should it be processed and then deleted?). The problem with DSNs also is that they are not protocol. they are just= =20 other messages that a MUA has to retrieve and process, based on whatever= =20 retrieval schedule. This works against timeliness. In any case, there will still be a lot of mail that is not delivered by=20 SMTP or SUBMIT - and that's mail where the destination is to another=20 user of the JMAP server. This is a considerable amount of mail. In=20 this case also, the notifications could be in the protocol, since the=20 time overall is probably very short. All we need for mail that takes=20 longer to change state (e.g. because it's going off-site via=20 SMTP/SUBMIT) is a way to send a status message back. This could be an=20 email, or it could be some other kind of message. The JMAP server=20 submitting mail via SMTP/SUBMIT could then choose to request DSNs on=20 behalf of the client, and the client will always get some kind of=20 notification, whether that is * Your message was delivered to another local mailbox * your message was submitted for delivery and there will be further=20 notifications - incoming DSN from SMTP etc * your message was submitted for delivery, but there will be no more=20 status notifications This should help provide incentive for MTA vendors to implement DSNs as=20 well. As for other envelope extensions, I agree the SMTP/SUBMIT system needs=20 to know certain envelope-related things, such as whether the content is=20 binary or 7-bit safe or not. This is where the discussion about=20 shackling JMAP to SUBMIT/SMTP comes in. It's a shame that we still have= =20 to support a transport that needs to care about the payload. Seems like= =20 a basic layering violation to me. If we aren't going to do anything about that, like set a minimum level=20 of required support for the systems the JMAP will interface to, we won't= =20 improve this, nor provide any incentive for it to be improved, and so it= =20 won't be. We will still be Base64 or quoted-printable encoding=20 everything. also we may find there is more interest in this protocol if we DO look=20 at fixing something (anything) about SMTP. Adrien ------ Original Message ------ From: "Ned Freed" To: "Ted Lemon" Cc: "jmap@ietf.org" ; "Ned Freed" Sent: 24/04/2017 11:50:54 AM Subject: Re: [Jmap] Submission >> On Apr 23, 2017, at 7:13 PM, Ned Freed wrote: >> > This is a entirely false dichotomy of choices you have going here.= =20 >>Nobody is >> > proposing "nailing it to SUBMIT". All anyone is saying is that you= =20 >>need to >> > have a means of specifying the envelope separate from the message=20 >>and its >> > headers, and that the envelope needs to be extensible. > >> If that's the case, then I don't think there's anything to argue=20 >>about. But I've been getting the impression that that's not the=20 >>case. I am fully in agreement with the assertion, with which I don't= =20 >>recall anyone disagreeing, that the envelope has to be separate from=20 >>the message and has to be extensible. > >> My concern is with avoiding a requirement that JMAP submit have the=20 >>same >> _flow_ as SMTP submit. > >Huh? Nobody has said that. AFAIK nobody has even hinted at that. > >> So I want it to be the case that status can be delivered=20 >>asynchronously, >> essentially. I don't mind if it's also possible to deliver it=20 >>synchronously, >> since that's just a degenerate case of asynchronous. > >That's a completely different matter, and in that regard, I'll just=20 >make >a few observations: > >(0) Synchronous delivery of status is, with the exception of a handful=20 >of > egregiously broken clients, always going to provide the better user > experience. This has everything to do with how people are wired and > nothing to do with the technology. > >(1) SUBMIT and SMTP both have the ability to deliver status both=20 >synchronously > and asynchronously. We call the latter "DSNs". They have not worked= =20 >out > well. > >(2) Asynchronous delivery of status information is NOT a degenerate=20 >case > of synchronous delivery. For example, it's entirely possible for a= =20 >SUBMIT > server to always return success status codes and issue a DSN later.= =20 >(In > fact our SUBMIT server can be set to do exactly this, in order to > deal with the aforementioned egregiously broken clients.) > >(3) The argument that DSNs being in-band rather than an out-of-band=20 >mechanism > is the root cause of all the problems in this area doesn't fly.=20 >Out-of-band > mechanisms for message status reporting have been tried - the=20 >obvious > example is X.400 - and if anything they've worked less well than > the in-band approach taken in SMTP. So nobody should assume that=20 >the > definition of such a mechanism will magically lead to glory. > >(4) There seems to be an assumption that an alternative asynchronous > notification mechanism is something that SUBMIT could not do. If=20 >so, > that's incorrect. In fact I can easily imagine a SUBMIT extension=20 >that > would specify an alternative mechanism for reporting delivery > success/failures, which the server would then employ instead of > generating one or more DSNs. > > In fact this would be so trivially easy to implement modulo=20 >whatever > the backwards-pointing notification mechanism is I bet I could do=20 >it > in only and hour or two of coding. > >(5) Implementing proper error handling is hard, getting everyone to=20 >implement > it correctly is probably impossible. > >(6) There are a host of problems associated with the Outbox/Sent magic=20 >folder > proposal that have nothing to do with anything being discussed=20 >here. > >In fact I believe I'm going to coin a new term at this point - the=20 >FUSMEHP. I >bet you can geuss what it means. > > Ned > >_______________________________________________ >Jmap mailing list >Jmap@ietf.org >https://www.ietf.org/mailman/listinfo/jmap From nobody Sun Apr 23 17:58:35 2017 Return-Path: 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 99879124217 for ; Sun, 23 Apr 2017 17:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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=mrochek.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 uMQcwXXCDnCB for ; Sun, 23 Apr 2017 17:58:32 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32A5B1204DA for ; Sun, 23 Apr 2017 17:58:32 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QDIWQDJNC0008AMC@mauve.mrochek.com> for jmap@ietf.org; Sun, 23 Apr 2017 17:53:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1492995206; bh=hd6lzE1wthVcJ50S4su7q2Gl1AJa6zhobdmZQ3MworA=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=e5cAeCY6tUnJ1gwcNfRJjtIPVlJ3b7Tqk/dFYjEKbO1huK70jjRLPtj424FAWKEq6 embtTzP1c+vZfeDpYX2to95n1jWAPwdR5TxRDJiCkgtWWdcFhTuzNti/nyKr0r3k+U bgMnIU1cCBHHJwwQo3i3L0vatHIrfRd64PgXk9Zc= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QD64433M0W00005B@mauve.mrochek.com>; Sun, 23 Apr 2017 17:53:23 -0700 (PDT) Cc: Ned Freed , Arnt Gulbrandsen , "jmap@ietf.org" Message-id: <01QDIWQBJR5K00005B@mauve.mrochek.com> Date: Sun, 23 Apr 2017 17:42:24 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Mon, 24 Apr 2017 00:29:40 +0000" References: <20170419163429.8556.qmail@ary.lan> <87d1c873cf.fsf@fifthhorseman.net> <01QDEV2QM6XC00005O@mauve.mrochek.com> <4471fa93-2321-4a7e-87b0-fbb00927d584@gulbrandsen.priv.no> <01QDIUI7C57800005B@mauve.mrochek.com> To: Adrien de Croy Archived-At: Subject: Re: [Jmap] Submission X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 00:58:34 -0000 > ------ Original Message ------ > From: "Ned Freed" > > > >Proxy authentication is widely if not universally supported using any > >number of techniques. And again, you don't get rid of the need to > >perform any number of actions based on the submitters identity just > >because > >the user already authenticated to JMAP. > I can think of one major platform (Windows) where this approach will be > highly problematic. We used to have a Windows implementation. Curiously, I don't recall it having any problems with proxy authentication. > Are we talking about a JMAP proxy (e.g. the client talks real-time via > the JMAP server to the SUBMIT server), or are we talking about a system > where the JMAP server accepts the message, and MAYBE forwards it via > SMTP or SUBMIT depending on the destination. In answer to your question, we are not talking about any particular architecture. That's a point I've been trying to make, I guess unsuccessfully, since I first starting posting in this thread. > If the latter, I would suggest that building a system that requires > individual user credentials to be presented to the next hop will be > highly problematic. Then I guess I should be thankful I never suggested it do such a thing. Ned From nobody Sun Apr 23 18:16:59 2017 Return-Path: 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 51154127071 for ; Sun, 23 Apr 2017 18:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=sdqE6xIO; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ov2q8jQw 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 8d0ePlYn13NB for ; Sun, 23 Apr 2017 18:16:56 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5D1D12783A for ; Sun, 23 Apr 2017 18:16:55 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 3946F209F5 for ; Sun, 23 Apr 2017 21:16:54 -0400 (EDT) Received: from web2 ([10.202.2.212]) by compute6.internal (MEProxy); Sun, 23 Apr 2017 21:16:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=dyUU2RCcXkDQJKFWjwAXogmgNM3bl bnc0jV/DUvF89g=; b=sdqE6xIOGfQ5h6+HiS9toSQusQ+d1n2MRftN7AJKh+1T7 K1imSHd3AHW4WGBH1noBbW0hgHqw3VN6BAaRG5XX17xQVv+sz2nBWOVhFftdldpl /308nXZkxls827l+eeC7qXTcSznEmHU0w5KvVnvvO9L86UkziGgUK1iZ4ZNbDUJz ZRVgDrHBeh2LYhF4YYQKVUn7j8WP1XLXLxGCNFheAqc8Gu+vaJOX8x5Uc/0La/rr IC4J0TldMlf+abrfewgBYvLZH5lBcLgdnr9VRhEJmel20aJN3jqo+tz27vkHSTF9 BE0W/kvlTXNLX9uHZmw8zK6Oh5+3qWT7EVvkJ7Tmw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=dyUU2R CcXkDQJKFWjwAXogmgNM3blbnc0jV/DUvF89g=; b=ov2q8jQwm1GlKx/0mYzCCW VP/c2IsgcmKYdk8wbMpnSfH+S/NKQWtwSFoMLM/87ZhTJRWfqH6zR1vbR4BqtUol LXAkbmn2qp9C5VzJ/9ygDGIiKZR2T1+xzNi4+ZYjhoxaSbFOADhfLaLvm5BkuPjl l1uTyIOJHNNa4486L5PU9a7mRRpBwLrFc2HVAneB/P9GSnQ0SRVr3Y34oy/VpEm7 0YO/eWnkdkXFysie/Bu+S9cLWv9m56BoTnRx+USfKs3c8NdmakcHhd+u4wE3txHi MVskY3CMua6RBLdhwgEcUS1gnitYUENngaveGm4zkw8AD1nL9oGG1gpc0sHYjiQQ == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id A63EB62737; Sun, 23 Apr 2017 21:16:54 -0400 (EDT) Message-Id: <1492996614.3309017.953748384.4E2D15C7@webmail.messagingengine.com> From: Bron Gondwana To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-75775c69 References: <66B256FE-E331-4319-A11A-570D0AF6E618@isode.com> Date: Mon, 24 Apr 2017 11:16:54 +1000 In-Reply-To: <66B256FE-E331-4319-A11A-570D0AF6E618@isode.com> Archived-At: Subject: Re: [Jmap] Is the group address syntax from RFC5322 really not supported in JMAP? X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 01:16:57 -0000 https://github.com/jmapio/jmap/issues/59 On Fri, 21 Apr 2017, at 18:46, Alexey Melnikov wrote: >=20 > > On 21 Apr 2017, at 08:09, Mads Hjorth wrote: > >=20 > > HI,=20 > >=20 > > I have an eye on JMAP for the use in a rather large scale messaging sys= tem (+5 million mailboxes). > >=20 > > In one of our use cases, we want to send messages to an named group, al= lowing the recipient to see the name of the group, but not the identity of = the members. We consider using the RFC5322 syntax for this e.g.=20 > >=20 > > To: Teenage Mutant Ninja Turtles:; > > Bcc: =E2=80=9CLeonardo=E2=80=9D , =E2=80=9CDonatello= =E2=80=9D > >=20 > > But the current JMAP states=20 > >=20 > >> Group information and comments from the RFC 5322 header MUST be discar= ded when converting into an Emailer object. > >=20 > > And I don=E2=80=99t see a motivation for the diversion from the RFC.=20 >=20 > I noticed lack of this in my review as well and I would like to see this = supported. >=20 > > Is it hard to implement? Never used? or is there another good explanati= on? > >=20 > >=20 > > =E2=80=A0 > > [[ o ]] > > ***** > > DIGITALISERINGSSTYRELSEN > >=20 > > Mads Hjorth > > Chefkonsulent > >=20 > > tel:+4541782351 > > mailto:madsh@digst.dk > > http://www.digst.dk > >=20 > > "I would have got rid of the slash slash=20 > > after the colon. You don't really need it.=20 > > It just seemed like a good idea at the time."=20 > >=20 > > - Tim Berners-Lee > >=20 > >=20 > >=20 > > _______________________________________________ > > Jmap mailing list > > Jmap@ietf.org > > https://www.ietf.org/mailman/listinfo/jmap >=20 > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap --=20 Bron Gondwana brong@fastmail.fm From nobody Sun Apr 23 18:21:59 2017 Return-Path: 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 64054127735 for ; Sun, 23 Apr 2017 18:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=Hgh/LsKC; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=XAD7Iz+c 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 uRdy2-l2NvdL for ; Sun, 23 Apr 2017 18:21:56 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65BCF124217 for ; Sun, 23 Apr 2017 18:21:56 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id C01FC209BE for ; Sun, 23 Apr 2017 21:21:55 -0400 (EDT) Received: from web2 ([10.202.2.212]) by compute6.internal (MEProxy); Sun, 23 Apr 2017 21:21:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=XAX8aWWMzKm79bHFW20AzU0AYLCHz n0qOoy5f/oX86c=; b=Hgh/LsKC4OLT7SxKJBdqbaPyAvQ35faJIi/dFilrnaqm9 YS3If/M+Sen0FHJ87q57KbtMUwhJAqsQGW04DNkdXGFjPU1hrjEG7rwB5+/6k1JK 6GPIbTaynSs9meSKmDtpnJ+8GuFuAAxv7qEEsxL5FlD01pJvZzVOkM+dpSh2p8pP kG0F8wINqFhybN97kd8yGu/Zl+3UNAiTQRKLrvE9aIFAwIdigbNqmJictD+pYH40 CFH81G5wHR16XleMOSvWumdVVdOAohrSsLa4UPonRREOr7BkmLFUrVjhJZpTyuWZ R8c/zVWcbeAHKDhl4q9qD1BNWxuim4ohUIhnGwgpg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=XAX8aW WMzKm79bHFW20AzU0AYLCHzn0qOoy5f/oX86c=; b=XAD7Iz+cyEPRtojTkMwuKb lVJnFVka4YEjPmaxZd5wUel6m/pYYF8xaPXEzSh7abQyJP+3aWClOO7r4uWO3pQC PhY5xO55OqfOxbEWlOWY8Tsf0c6VXGfOmtd9ojWKC4Ud/f+kP9qhsYgFqaZrzmOc xOFWTAfDwSFdiBDGN1iBLcblvXQy6ugzmH3zulPsyOcW48jluJ3D2+CsBz1l/7a3 Uj4V2zwfxQfZRMj5q6u3CiR+epggGGHN+wY+xldNpAbnJNO6xryzczXxRfshx7+Q VLHQY4REuYDMugN78Ae/Dwn/MV1d26j0Nkci4L0nEX/gjGhNhP1D/vDSx3cLZ4Ig == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 9504062737; Sun, 23 Apr 2017 21:21:55 -0400 (EDT) Message-Id: <1492996915.3310412.953749536.0F1C8B46@webmail.messagingengine.com> From: Bron Gondwana To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-75775c69 In-Reply-To: References: <20170421001702.24991.qmail@ary.lan> <00616B85-F365-4B1F-82EA-2FF2623CED77@oracle.com> Date: Mon, 24 Apr 2017 11:21:55 +1000 Archived-At: Subject: Re: [Jmap] Address Validation (was Re: Submission) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 01:21:57 -0000 On Sat, 22 Apr 2017, at 11:34, Adrien de Croy wrote: > > "two mechanisms to perform the same function is poor design" > > Sorry I missed this one on the Mt Sinai tablets. There's no need to be nasty. Chill it please. We're a professional working group. Chris Newman wrote: > This is quite extensible and I believe this specific functionality is > in-scope of the JMAP charter as Submission (RFC 6409) is explicitly > in-scope. Doing address validation this way is already quite powerful. > For example, if the submission server chooses to implement the SMTP > 251/551 response codes for local users, the mail client gains the > ability to prompt the user to correct the address book entry for that > recipient. Without getting bogged down in exact details just yet, we should address this question: Do we want JMAP-Mail to include a facility to check whether an address would be accepted for mail delivery by the server - presumably the result is a tristate of [definite YES, Unknown, definite NO] via whatever response method is used. Cheers, Bron. -- Bron Gondwana brong@fastmail.fm From nobody Sun Apr 23 18:32:31 2017 Return-Path: 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 896041277BB for ; Sun, 23 Apr 2017 18:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 dbJgfGOjouLP for ; Sun, 23 Apr 2017 18:32:27 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [122.56.26.1]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 120A312426E for ; Sun, 23 Apr 2017 18:32:26 -0700 (PDT) Received: From [192.168.1.146] (unverified [192.168.1.146]) by SMTP Server [192.168.1.3] (WinGate SMTP Receiver v9.0.5 (Build 5926)) with SMTP id <0001027868@smtp.qbik.com>; Mon, 24 Apr 2017 13:32:24 +1200 From: "Adrien de Croy" To: "Ned Freed" Cc: "Ned Freed" , "Arnt Gulbrandsen" , "jmap@ietf.org" Date: Mon, 24 Apr 2017 01:32:24 +0000 Message-Id: In-Reply-To: <01QDIWQBJR5K00005B@mauve.mrochek.com> References: <20170419163429.8556.qmail@ary.lan> <87d1c873cf.fsf@fifthhorseman.net> <01QDEV2QM6XC00005O@mauve.mrochek.com> <4471fa93-2321-4a7e-87b0-fbb00927d584@gulbrandsen.priv.no> <01QDIUI7C57800005B@mauve.mrochek.com> <01QDIWQBJR5K00005B@mauve.mrochek.com> Reply-To: "Adrien de Croy" User-Agent: eM_Client/7.0.27943.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Jmap] Submission X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 01:32:29 -0000 ------ Original Message ------ From: "Ned Freed" To: "Adrien de Croy" Cc: "Ned Freed" ; "Arnt Gulbrandsen"=20 ; "jmap@ietf.org" Sent: 24/04/2017 12:42:24 PM Subject: Re: [Jmap] Submission > > >>------ Original Message ------ >>From: "Ned Freed" >> > >> >Proxy authentication is widely if not universally supported using any >> >number of techniques. And again, you don't get rid of the need to >> >perform any number of actions based on the submitters identity just >> >because >> >the user already authenticated to JMAP. > >>I can think of one major platform (Windows) where this approach will=20 >>be >>highly problematic. > >We used to have a Windows implementation. Curiously, I don't recall it=20 >having >any problems with proxy authentication. Maybe we have different things in mind when we think about proxy=20 authentication, or even proxy. In JMAPs case, I would suggest it's probably not a proxy, not in the way= =20 an HTTP proxy is. > > >>Are we talking about a JMAP proxy (e.g. the client talks real-time via >>the JMAP server to the SUBMIT server), or are we talking about a=20 >>system >>where the JMAP server accepts the message, and MAYBE forwards it via >>SMTP or SUBMIT depending on the destination. > >In answer to your question, we are not talking about any particular >architecture. That's a point I've been trying to make, I guess=20 >unsuccessfully, >since I first starting posting in this thread. Ok, except when working with existing systems such as challenge response= =20 auth protocols that take opaque blobs, then the architecture can be=20 impinged upon. > > >>If the latter, I would suggest that building a system that requires >>individual user credentials to be presented to the next hop will be >>highly problematic. > >Then I guess I should be thankful I never suggested it do such a thing. OK, does this mean you intended that the auth was of the JMAP server to=20 the SUBMIT server not on behalf of (using creds of) a JMAP user? In that case, it's a fairly trivial issue. Adrien > > > Ned From nobody Sun Apr 23 18:35:41 2017 Return-Path: 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 C4F551277BB for ; Sun, 23 Apr 2017 18:35:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=rsAox8Xb; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=DmHpaiQX 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 gefmSsEK_3_g for ; Sun, 23 Apr 2017 18:35:38 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2383E12426E for ; Sun, 23 Apr 2017 18:35:38 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 8C79A20AEF for ; Sun, 23 Apr 2017 21:35:37 -0400 (EDT) Received: from web2 ([10.202.2.212]) by compute6.internal (MEProxy); Sun, 23 Apr 2017 21:35:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=q+2HqNlaWJJLkxOkKVcvcLfAN+B8VZsPJKfvynaZayc=; b=rsAox8Xb 3xMlPXNoRTpMEYIm9ZnGD3wEWixNyGifLz7bedj+VJZi+v3BLma2RE2skEkWTGjk 0FSv50BL8/w2gfsp64yD0KBnvB/j66mwPi9zOx50MwOE9xFn7KrpIY8i8mGZwyKp ReUuemgr5COEfrIDCntpON9w+5MQu/Upy7M7a0KkjjZAtoPOjxk9SjNZ3jTajYz8 y+lcHaTcQrsd4WFr4axMtFEepxHTZH7hw8lnY6l7KWKEG+yYMapKxPFM7x/+m/ti QA1VC+NmXU/fD43agJIb/LFjVycoBcMW4WeEKb1llzECr07gHTKASfspxu0JPs6X wNHjiM5L7Bce/g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=q+2HqNlaWJJLkxOkKVcvcLfAN+B8V ZsPJKfvynaZayc=; b=DmHpaiQXfKgPFsy2XMt3mZdRPj94tTzvyexwejihKimSU psaV+uWMNMUd86cOKmM2n+jck37y1rDNjnF2rxpInPf4YHo+qoOgNHLSqrYDT63S BE01wsShEHfNd8UR+8yWvgTDtODMNz16tdsyUdEc9hdZ6fflgEfL13VmcBEAMg61 62ZwC+5UVPVBhBYV2BIEFbOpIucdR1PMOrGTL8GbiZNq36lWNRDla5cUW6A3K0wd VEFYwC0bKdg9EwkLWXS/0G6CACDB7ZsUYf25cbCcUW16BxlPzW7nIahGbaEvCS+/ E97tSb3yy6gczGaLqx+v8hoRph1WMKv5PJC1yeLLA== X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 5FC0762737; Sun, 23 Apr 2017 21:35:37 -0400 (EDT) Message-Id: <1492997737.3312553.953738776.7D27901C@webmail.messagingengine.com> From: Bron Gondwana To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-75775c69 Date: Mon, 24 Apr 2017 11:35:37 +1000 Archived-At: Subject: [Jmap] Submission: options for github issue X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 01:35:40 -0000 Hi All, I've been following the discussion with interest, and am trying to distill it down into a github issue for the authors to work from. As I see it there are roughtly the following options being thrown around. 0) degenerate case: don't support submission at all via JMAP 1) current proposal: extract all envelope information in-band from headers in RFC5322 message content 2) new proposal: store structure envelope information separate from RFC5322 message content There are some sub-categories as well: 1a) extract envelope data out of From/To/CC/BCC headers only. 1b) add new headers to RFC5322 message content which are kept in the "Sent" copy, but stripped from the copy sent via SMTP. I'd like to note here that regardless of what method is used, we need to generate two distinct copies of the message, one that goes down the wire without the BCC field, and one that is stored locally and has BCC included. Sites may have their own magic headers as well, for example FastMail keeps an X-ME-Personality-Id header in drafts which is used to identify which set of signatures to apply to a message, and also whether the email needs to be sent with SMTP-Auth to a smarthost rather than placed into our own outbound queues. Then we look at the new proposal, from which there are a few options: 2a) add support for arbitrary key/value annotations to all messages, allowing envelope data to be stored and edited along with a draft and retained as it moves to Outbox. 2b) add envelope data as special properties which can only be set when moving a message to Outbox, and must be set when moving to Outbox. 2c) add envelope data as special properties which can only be set when moving a message to Outbox (like 2b), but if not set are inferred from the content of the message (like 1a). 2d) do away with the Outbox concept entirely, either losing delayed send capability from the protocol, or having another way to manage delayed messages - and submit messages using a different technique than "move to Outbox". Do you think I have adequately captured all the possible ways to do submission here? Bron. P.S. There is another question being raised by this discussion, which is whether Draft messages should be editable while retaining the same ID. One of the best bits of IMAP is that messages are immutable, but it does create frustrations around Draft message handling. I'll start a separate email thread for that. -- Bron Gondwana brong@fastmail.fm From nobody Sun Apr 23 18:49:16 2017 Return-Path: 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 7AD16127A91 for ; Sun, 23 Apr 2017 18:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=zrUmBihu; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=DgsQqAGT 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 erYJmKJPswzy for ; Sun, 23 Apr 2017 18:49:13 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88959120046 for ; Sun, 23 Apr 2017 18:49:13 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id D556B209B1 for ; Sun, 23 Apr 2017 21:49:12 -0400 (EDT) Received: from web2 ([10.202.2.212]) by compute6.internal (MEProxy); Sun, 23 Apr 2017 21:49:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=UcW3UyJcHTWjtJ7GJdTJ1QU+ZQJY2 Zjlr1DjcJiYxJI=; b=zrUmBihuRGFkCFI7NOt0tkh1H2Ght9M0q4ziYIzs1voOI dSa/S+BXLUHcDG40sp7arV5l0qa0MVumwkrCVf++GGLAYQekTsxVXEKT9ZoGvvA+ HidUh9BUvPNYa08BM4kKhZjKpM4Zkazjuk9Ys6gw1R/e/lEjOOdXOB1gyFmuCVjy o4husU6Eqj1R/MHJSYBYOkW+V5Tc7Z++91JNx1BHRXVEk8MKlf3FanL12yNMk4Mc Wlz70qO3H1Vik1Wb/bgXEfNniI7V/SNrZyNKeNmfAOUrFHfrlMbUu3PseNR40bSg WbbFpXDNoIqK6lZFm9fHeFFlLs21HdN+URoZFX/ww== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=UcW3Uy JcHTWjtJ7GJdTJ1QU+ZQJY2Zjlr1DjcJiYxJI=; b=DgsQqAGT2PBQHUi7oGCIfV wXiwsuIHBqxvplrnH5b5yDtknbjlr9sG5izpvmLaX6SO2qI1yHhW4M60hTS2ZuZo B6FHD8yHPIFZg3PLvHx6gUfSRpuMSzXmfrPZ52Ks4/YRHLRmygVZF6TbM891Vg8p JlWK7gk/aL6DRZCOQIdhAbW5ZFpQli8a3EktfClz6IUNBxBMDwrKTBmuip7UDADd KLTSKUdaJdlvZYNz6zg9v3JmKeDFywC1gUrfIehkb0pLUKOpaZ9WRyzOsf0+o3Lo +CcH2s24wRjz9I9H/Y4ruTt7Z5R1oxgyg5/hvlhLpTSIzH81zdH7t0pSMEjSNtoQ == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id B2CA262737; Sun, 23 Apr 2017 21:49:12 -0400 (EDT) Message-Id: <1492998552.3315117.953767768.5225D039@webmail.messagingengine.com> From: Bron Gondwana To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-75775c69 References: <1492997737.3312553.953738776.7D27901C@webmail.messagingengine.com> Date: Mon, 24 Apr 2017 11:49:12 +1000 In-Reply-To: <1492997737.3312553.953738776.7D27901C@webmail.messagingengine.com> Archived-At: Subject: Re: [Jmap] Submission: options for github issue X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 01:49:14 -0000 On Mon, 24 Apr 2017, at 11:35, Bron Gondwana wrote: > Do you think I have adequately captured all the possible ways to do submission here? Noting also that regardless of what method we use, it could be possible to derive default envelope information from a create which didn't explicitly override it, based on server settings. A very contrived example: (pseudo-jmap-code) ["setMessages", { "create" : { "newid" : { "to" : "brong@fastmail.fm", "bcc" : "secretaccount@example.com", "from" : "brong@fastmail.fm", "subject" : "test", "inMailboxes" : [ "draftfolderid" ], "isDraft" : true, "textBody" : "some text" }, }, "#1"] ["messagesSet", { created: { "newid" : { "id" : "84130d20-9b6f-4059-8895-a15c638a5bfa", "envelopeFrom" : ["brong@fastmail.fm", "BODY=8BITMIME"], "envelopeTo" : { "brong@fastmail.fm": ["NOTIFY=SUCCESS"], "secretaccount@example.fm": ["NOTIFY=FAILURE"], }, }, }, }, "#1"] Obviously the ability to edit those fields later depends how immutable we make the Draft message, and whether it's being stored in the RFC5322 or as annotations. Bron. -- Bron Gondwana brong@fastmail.fm From nobody Sun Apr 23 18:50:23 2017 Return-Path: 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 2C0BB126C2F for ; Sun, 23 Apr 2017 18:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no 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 vfWHKqfw-mub for ; Sun, 23 Apr 2017 18:50:21 -0700 (PDT) Received: from miucha.iecc.com (w6.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B13B4120046 for ; Sun, 23 Apr 2017 18:50:20 -0700 (PDT) Received: (qmail 42494 invoked from network); 24 Apr 2017 01:50:19 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 24 Apr 2017 01:50:19 -0000 Date: 24 Apr 2017 01:49:57 -0000 Message-ID: <20170424014957.39235.qmail@ary.lan> From: "John Levine" To: jmap@ietf.org Cc: brong@fastmail.fm In-Reply-To: <1492996915.3310412.953749536.0F1C8B46@webmail.messagingengine.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Jmap] Address Validation (was Re: Submission) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 01:50:22 -0000 In article <1492996915.3310412.953749536.0F1C8B46@webmail.messagingengine.com> you write: >Do we want JMAP-Mail to include a facility to check whether an address would be accepted for mail delivery by the server - presumably the result is a >tristate of [definite YES, Unknown, definite NO] via whatever response method is used. I'm trying to think of a plausible use case for separate checks rather than at submission time, and also trying to think of a plausible way to do useful checks on non-local addresses. The use cases I think of are pretty contrived, like someone just uploaded an address book and wants to prune out the bogus addresses. For the latter, since nobody supports VRFY and EXPN any more (for good reasons,) and RCPT TO probes tend to get you blacklisted, the answer for remote addreses is always going to be "maybe" unless you mistype a nonexistent domain. So I wouldn't bother. The addresses will get checked when people send the message, just like now. R's, John From nobody Sun Apr 23 18:55:03 2017 Return-Path: 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 1BCE4124217 for ; Sun, 23 Apr 2017 18:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=YYvNRKIx; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=d5gnZ8Sv 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 RWBBw8nmtVcD for ; Sun, 23 Apr 2017 18:55:00 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14B1C120046 for ; Sun, 23 Apr 2017 18:55:00 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 6EAAB20BBC for ; Sun, 23 Apr 2017 21:54:59 -0400 (EDT) Received: from web2 ([10.202.2.212]) by compute6.internal (MEProxy); Sun, 23 Apr 2017 21:54:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=WIu9hWUqmS8wyjniStJVVTM6Z1nuFWah6sN2zfegnH8=; b=YYvNRKIx 1WFN28EMcuT39K5mczJgpam+GSBk6NdDj8TEsb3vw0g7ZNcu19Mm++ALVCkAS32a OBJEHwiaiQ98mW2WDILXc/qqapZ7oRo/cFg4rZkLLlu9g7MoRWTQYMYqv/z7jTDT RoynxMeAWaamJyul7RwWEPWN1EILpC2H+TwNnjGUkvJDA1ApB5bGVGmG59xISpXO pn4spYqvGB/JucLQOh/8xWIJJwUI5iBw8up7AWXd/W8dRrw3pDOuhV14DiQ6SkrB yPYj7i0H/e3+xqxfOnRi6OO/g4tGBEcjZB9TWkuVoPYxnJkQUIv095/s22NdVP2z NF33DZeONHmOYA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=WIu9hWUqmS8wyjniStJVVTM6Z1nuF Wah6sN2zfegnH8=; b=d5gnZ8SvK0gOP2O6f5zYIUd9sW4gdimYWTBr68kLahnjC I0Cmw6FSI042xRZyiWeCOc5eDT623Rk1OhhgRl+jRtGDGRIZvrT2B47haCB6wClZ 3XfWZR3HBf0U1mSrAuXF+ikQS/ifs9UcKG7IWN88ljwjqYEkEUVHrEiFNVPURvrE gzNngLRrAybot1I6RhWqTF+zc6pedbif/AgFzyLRGmNSvmhL2a2mzwp/3QOlBMz0 Bog4jZyJmR4QA51jgCeCAS7Y6CAtk5MBUEeGLG2sUuxNi4pFwxfDLFMqMMPXODgn MMk8FyOIp/VGgKEIeZcBwq0omIZdfIITjuT8Dh9iA== X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 443FD62737; Sun, 23 Apr 2017 21:54:59 -0400 (EDT) Message-Id: <1492998899.3316920.953769616.254C9CBD@webmail.messagingengine.com> From: Bron Gondwana To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-75775c69 Date: Mon, 24 Apr 2017 11:54:59 +1000 Archived-At: Subject: [Jmap] Draft messages - mutability X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 01:55:01 -0000 I'm starting this thread to discuss the mutability of fields in isDraft: true messages. In Cyrus IMAPd right now, we create the "MSGID" field as the sha1 of the "RFC822" raw message content as would be delivered over IMAP. That's lovely for non-draft messages (except that we'll probably switch to using blake2 for new messages soon). But it sucks for drafts, because it means that every time you edit a draft, you get a new MSGID. Futhermore, you can't edit a draft via JMAP with ['setMessages', {update:{}}] because the fields that you want to edit are immutable, so instead you are doing ['setMessages', {create:{all the fields}, destroy: ["the old id"]}] which is a horrible way to edit drafts. A somewhat similar discussion is happening over in CalConnect around the idea of saving draft ICALENDAR items on a server without sending out scheduling messages about them until they have finished being edited. So the question for JMAP becomes: is a "draft message" the same datatype as a "message", or do you handle them completely differently? Clearly you want to show them in-thread with the message they are in reply to in an interface, but how does that look over the protocol? Bron. -- Bron Gondwana brong@fastmail.fm From nobody Sun Apr 23 19:04:01 2017 Return-Path: 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 2DC47126C2F for ; Sun, 23 Apr 2017 19:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=CIAtm5rY; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=QyBRr3ey 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 qr_1f2wy3DU7 for ; Sun, 23 Apr 2017 19:03:59 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE83A120046 for ; Sun, 23 Apr 2017 19:03:58 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 56FA620B1A for ; Sun, 23 Apr 2017 22:03:58 -0400 (EDT) Received: from web2 ([10.202.2.212]) by compute6.internal (MEProxy); Sun, 23 Apr 2017 22:03:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=+vnEtO+jKAq6D/IA085Z31KE9aOVW QDZGtb5+gOmImg=; b=CIAtm5rYwhpgysAEoDcpBn7eH1HUfqgbZ/Cp5Nx2c2a+Q 2blzarm1PvVPuhVMFPqaX7E4Fqt6xky1mai/QHM6pvOBcbv6YuOOn41nZ49YbCxg lil+h+5zcEfaDGaBolMt8QQt9/LmJlwYujaQKn8vR8/sS5S9ny11C9IkEDTQe+aO HAd0Yy3aXzjYlvhmVgmA3BvqOq8wS8SZKI+nRP5fyDKfOlIhbRTGo2NMG2yJSjOM x2mm4X0V33XUi6yEqXxq0/EnWI+v1pDT4/8GRsF/H9aVryxvDWfGouyG3Zan3vFf Y/wZCUUxx3uCEyh8OXb8IvQebw7Pjo1PPEu3LFX0Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=+vnEtO +jKAq6D/IA085Z31KE9aOVWQDZGtb5+gOmImg=; b=QyBRr3ey0me4Hi3cMoH09v Rd+aQXzofcUpqtMqEDiw1LGTPGmqjGGBm0Kp+o8tPQgkTK4vNzh9wi01Ygi/llgX Q6zvgnMqqNul/SoYpujz8IzYsYVfxLds5O197f/pB7F9vMV78MEIHkRShJgJXcUm uD9uqog9589P8qc5S+BTGA0CcMZLh+OdhvvTvDVUgcJlp2+uMqAXWBGOSf+NuLG1 GEhLBmFakLQCN2Knz6q6/1IlGgrgZQ4Zj+/giWRlXgY0KiIPtNFKe9ycy4PDw1Bm tZ9UYYwG0F/BmBqsH9xLCOMXMpZnn/VjdcLqyG9/k8shF9Fp49/hzBUMRPbipELQ == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 2DC0F62737; Sun, 23 Apr 2017 22:03:58 -0400 (EDT) Message-Id: <1492999438.3318688.953774952.11A8EA9B@webmail.messagingengine.com> From: Bron Gondwana To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-75775c69 In-Reply-To: <20170424014957.39235.qmail@ary.lan> Date: Mon, 24 Apr 2017 12:03:58 +1000 References: <20170424014957.39235.qmail@ary.lan> Archived-At: Subject: Re: [Jmap] Address Validation (was Re: Submission) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 02:04:00 -0000 On Mon, 24 Apr 2017, at 11:49, John Levine wrote: > In article <1492996915.3310412.953749536.0F1C8B46@webmail.messagingengine.com> you write: > >Do we want JMAP-Mail to include a facility to check whether an address would be accepted for mail delivery by the server - presumably the result is a > >tristate of [definite YES, Unknown, definite NO] via whatever response method is used. > > I'm trying to think of a plausible use case for separate checks rather > than at submission time, and also trying to think of a plausible way > to do useful checks on non-local addresses. > > The use cases I think of are pretty contrived, like someone just > uploaded an address book and wants to prune out the bogus addresses. I'm inclined to agree with you here that this is something best addressed as part of Addressbook handling (jmap-addressbook, when we get to that) allowing you to pre-fill known user addresses without typing them by hand! Obviously the answer for non-local addresses would be "Unknown". The interesting bit is having the information available to the client about whether an address is local, and hence they can get a clear indication of correctness before trying to send. There's definitely value in that from a usability perspective, particularly in a large company or university or something where valid address lookup is available. Bron. -- Bron Gondwana brong@fastmail.fm From nobody Sun Apr 23 19:07:40 2017 Return-Path: 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 7DD75126C2F for ; Sun, 23 Apr 2017 19:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 P7Kdrf_bp5nv for ; Sun, 23 Apr 2017 19:07:35 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [122.56.26.1]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA405120046 for ; Sun, 23 Apr 2017 19:07:34 -0700 (PDT) Received: From [192.168.1.146] (unverified [192.168.1.146]) by SMTP Server [192.168.1.3] (WinGate SMTP Receiver v9.0.5 (Build 5926)) with SMTP id <0001027887@smtp.qbik.com>; Mon, 24 Apr 2017 14:07:31 +1200 From: "Adrien de Croy" To: "John Levine" , "jmap@ietf.org" Cc: "brong@fastmail.fm" Date: Mon, 24 Apr 2017 02:07:31 +0000 Message-Id: In-Reply-To: <20170424014957.39235.qmail@ary.lan> References: <1492996915.3310412.953749536.0F1C8B46@webmail.messagingengine.com> <20170424014957.39235.qmail@ary.lan> Reply-To: "Adrien de Croy" User-Agent: eM_Client/7.0.27943.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Jmap] Address Validation (was Re: Submission) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 02:07:37 -0000 when I made the suggestion, I was imagining that although you can't do=20 VRFY or EXPN or probe emails and yes this is for good reason, the number= =20 of times I've had bounce messages a long time after submission for=20 problems such as NXDOMAIN, means the current system isn't very good at=20 even this. Also if we put a system into JMAP to allow it, it can then be extended. = =20 If we don't, we are stuck with the current functionality. I believe there is certainly some value in pre-checking an address. The problem tends to happen in more cases than you'd think (e.g. not=20 just importing / checking an address book). I've seen many messages=20 stuck in retry queues which are just replies to an email from someone=20 who made a mistake setting their own email address in their mail client.= =20 Presumably these people have a frustrating life wondering why they=20 never get replies until they sort it out. Also if you take someone's=20 address down from some other medium (phone) and get it wrong. People=20 often write what they want to hear rather than what is spoken to them. So you can't even rely on people to get their own email correct, and you= =20 can't rely on an address being correctly transcribed. It's on first use= =20 that you find out whether the address is any good. Also it's fairly=20 common for addresses to get cancelled, even domains expire. Checking (whatever form of checking is possible) early is better than=20 later, as it can provide more options. If you hit send and bolt for the= =20 door, even a submission bounce will be too late. At the moment yes I believe all the checking that's really possible is=20 just at the domain level. that's not to say that's all the checking=20 there will ever be, once (if) it's proven to have sufficient value. Adrien ------ Original Message ------ From: "John Levine" To: "jmap@ietf.org" Cc: "brong@fastmail.fm" Sent: 24/04/2017 1:49:57 PM Subject: Re: [Jmap] Address Validation (was Re: Submission) >In article=20 ><1492996915.3310412.953749536.0F1C8B46@webmail.messagingengine.com> you= =20 >write: >>Do we want JMAP-Mail to include a facility to check whether an address= =20 >>would be accepted for mail delivery by the server - presumably the=20 >>result is a >>tristate of [definite YES, Unknown, definite NO] via whatever response= =20 >>method is used. > >I'm trying to think of a plausible use case for separate checks rather >than at submission time, and also trying to think of a plausible way >to do useful checks on non-local addresses. > >The use cases I think of are pretty contrived, like someone just >uploaded an address book and wants to prune out the bogus addresses. > >For the latter, since nobody supports VRFY and EXPN any more (for good >reasons,) and RCPT TO probes tend to get you blacklisted, the answer >for remote addreses is always going to be "maybe" unless you mistype >a nonexistent domain. > >So I wouldn't bother. The addresses will get checked when people send >the message, just like now. > >R's, >John > > >_______________________________________________ >Jmap mailing list >Jmap@ietf.org >https://www.ietf.org/mailman/listinfo/jmap From nobody Sun Apr 23 19:22:44 2017 Return-Path: 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 CB126120326 for ; Sun, 23 Apr 2017 19:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.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 WwfoG5WI2vPi for ; Sun, 23 Apr 2017 19:22:42 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16E24120046 for ; Sun, 23 Apr 2017 19:22:42 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QDIZNS0LCG0081Z8@mauve.mrochek.com> for jmap@ietf.org; Sun, 23 Apr 2017 19:17:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1493000257; bh=36QcHFdSpoef3Jtj314c0bavkOh4IMYanWeB+Sth3ZA=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=KTSmjzKr1rv8KG3tDQJfVupQXXvsGmVvXtckWscb5o+7y/ZCJM7ksaXPojtBiXKzT jqPdXaEqcXllCQXCslrPXrXx6HZ15du96ruH3r3TDSnTjD35hq3wurowdF/FOo3U1E MYn21pkJDBGcn17l0nNkN8GJfLqQAWlK5MGAg65c= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QD64433M0W00005B@mauve.mrochek.com>; Sun, 23 Apr 2017 19:17:35 -0700 (PDT) Cc: Ned Freed , Arnt Gulbrandsen , "jmap@ietf.org" Message-id: <01QDIZNPSIDI00005B@mauve.mrochek.com> Date: Sun, 23 Apr 2017 19:09:01 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Mon, 24 Apr 2017 01:32:24 +0000" References: <20170419163429.8556.qmail@ary.lan> <87d1c873cf.fsf@fifthhorseman.net> <01QDEV2QM6XC00005O@mauve.mrochek.com> <4471fa93-2321-4a7e-87b0-fbb00927d584@gulbrandsen.priv.no> <01QDIUI7C57800005B@mauve.mrochek.com> <01QDIWQBJR5K00005B@mauve.mrochek.com> To: Adrien de Croy Archived-At: Subject: Re: [Jmap] Submission X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 02:22:43 -0000 > > > If the latter, I would suggest that building a system that requires > > > individual user credentials to be presented to the next hop will be > > > highly problematic. > >Then I guess I should be thankful I never suggested it do such a thing. > OK, does this mean you intended that the auth was of the JMAP server to > the SUBMIT server not on behalf of (using creds of) a JMAP user? On behalf of, but not using the user's credentials. That's the functionality proxy authentication provides. Of course there are many ways to do it, including but not limited to good old SASL PLAIN's authzid parameter. Ned From nobody Sun Apr 23 19:38:59 2017 Return-Path: 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 E57301243F6 for ; Sun, 23 Apr 2017 19:38:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 LaJsmnC2bn06 for ; Sun, 23 Apr 2017 19:38:56 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [122.56.26.1]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 773E3120326 for ; Sun, 23 Apr 2017 19:38:55 -0700 (PDT) Received: From [192.168.1.146] (unverified [192.168.1.146]) by SMTP Server [192.168.1.3] (WinGate SMTP Receiver v9.0.5 (Build 5926)) with SMTP id <0001027910@smtp.qbik.com>; Mon, 24 Apr 2017 14:38:53 +1200 From: "Adrien de Croy" To: "Bron Gondwana" , "jmap@ietf.org" Date: Mon, 24 Apr 2017 02:38:53 +0000 Message-Id: In-Reply-To: <1492997737.3312553.953738776.7D27901C@webmail.messagingengine.com> References: <1492997737.3312553.953738776.7D27901C@webmail.messagingengine.com> Reply-To: "Adrien de Croy" User-Agent: eM_Client/7.0.27943.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Jmap] Submission: options for github issue X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 02:38:59 -0000 Hi Bron I'm in favour of keeping the envelope separate from the message content. I have less concern about exactly how the envelope is treated. in the=20 end, it's meta-data associated with the message. There could be some value in keeping the envelope after a message is=20 submitted. There are some pathological cases relating to sending messages to=20 multiple recipients that could perhaps be simplified if the envelope=20 were kept. for example per-recipient status. It may be possible to avoid having to= =20 include the BCC field and have 2 copies of the message as well if the=20 BCCed addresses are kept in the envelope instead of the message. Adrien ------ Original Message ------ From: "Bron Gondwana" To: "jmap@ietf.org" Sent: 24/04/2017 1:35:37 PM Subject: [Jmap] Submission: options for github issue >Hi All, > >I've been following the discussion with interest, and am trying to=20 >distill it down into a github issue for the authors to work from. As I= =20 >see it there are roughtly the following options being thrown around. > >0) degenerate case: don't support submission at all via JMAP >1) current proposal: extract all envelope information in-band from=20 >headers in RFC5322 message content >2) new proposal: store structure envelope information separate from=20 >RFC5322 message content > >There are some sub-categories as well: > >1a) extract envelope data out of From/To/CC/BCC headers only. >1b) add new headers to RFC5322 message content which are kept in the=20 >"Sent" copy, but stripped from the copy sent via SMTP. > >I'd like to note here that regardless of what method is used, we need=20 >to generate two distinct copies of the message, one that goes down the=20 >wire without the BCC field, and one that is stored locally and has BCC=20 >included. Sites may have their own magic headers as well, for example=20 >FastMail keeps an X-ME-Personality-Id header in drafts which is used to= =20 >identify which set of signatures to apply to a message, and also=20 >whether the email needs to be sent with SMTP-Auth to a smarthost rather= =20 >than placed into our own outbound queues. > >Then we look at the new proposal, from which there are a few options: > >2a) add support for arbitrary key/value annotations to all messages,=20 >allowing envelope data to be stored and edited along with a draft and=20 >retained as it moves to Outbox. >2b) add envelope data as special properties which can only be set when=20 >moving a message to Outbox, and must be set when moving to Outbox. >2c) add envelope data as special properties which can only be set when=20 >moving a message to Outbox (like 2b), but if not set are inferred from=20 >the content of the message (like 1a). >2d) do away with the Outbox concept entirely, either losing delayed=20 >send capability from the protocol, or having another way to manage=20 >delayed messages - and submit messages using a different technique than= =20 >"move to Outbox". > >Do you think I have adequately captured all the possible ways to do=20 >submission here? > >Bron. > >P.S. There is another question being raised by this discussion, which=20 >is whether Draft messages should be editable while retaining the same=20 >ID. One of the best bits of IMAP is that messages are immutable, but=20 >it does create frustrations around Draft message handling. I'll start=20 >a separate email thread for that. > > >-- > Bron Gondwana > brong@fastmail.fm > >_______________________________________________ >Jmap mailing list >Jmap@ietf.org >https://www.ietf.org/mailman/listinfo/jmap From nobody Mon Apr 24 02:44:22 2017 Return-Path: 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 C157012EB88 for ; Mon, 24 Apr 2017 02:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 Js-RHm_Kfpk8 for ; Mon, 24 Apr 2017 02:44:20 -0700 (PDT) Received: from wizmail.org (wizmail.org [IPv6:2a00:1940:107::2:0:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3B7312EB81 for ; Mon, 24 Apr 2017 02:44:19 -0700 (PDT) Received: from [2a00:b900:109e:0:c5d6:c61b:f5e0:b51f] (helo=lap.dom.ain) by wizmail.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_RC100) id 1d2aXX-00086i-Fm for jmap@ietf.org (return-path ); Mon, 24 Apr 2017 09:44:15 +0000 To: jmap@ietf.org References: <20170419163429.8556.qmail@ary.lan> <87d1c873cf.fsf@fifthhorseman.net> <01QDEV2QM6XC00005O@mauve.mrochek.com> <01QDFJV9BBBS00005O@mauve.mrochek.com> <65CA1C64-ACD9-4AF5-8ED4-59D4285B5A8D@fugue.com> <01QDITVRJT3O00005B@mauve.mrochek.com> <87F9079E-AAC7-49C7-99FC-79F19AA3C5D6@fugue.com> <01QDIVTKAWPK00005B@mauve.mrochek.com> From: Jeremy Harris Message-ID: <20f29006-4ebb-6676-5ac3-31bd559b553f@wizmail.org> Date: Mon, 24 Apr 2017 10:44:11 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Pcms-Received-Sender: [2a00:b900:109e:0:c5d6:c61b:f5e0:b51f] (helo=lap.dom.ain) with esmtpsa Archived-At: Subject: Re: [Jmap] Submission X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 09:44:22 -0000 On 24/04/17 01:54, Adrien de Croy wrote: > As for other envelope extensions, I agree the SMTP/SUBMIT system needs > to know certain envelope-related things, such as whether the content is > binary or 7-bit safe or not. This is where the discussion about > shackling JMAP to SUBMIT/SMTP comes in. It's a shame that we still have > to support a transport that needs to care about the payload. Seems like > a basic layering violation to me. Specifically on the 8-bit-cleanliness issue: http://cr.yp.to/smtp/8bitmime.html -- Cheers, Jeremy From nobody Mon Apr 24 06:43:29 2017 Return-Path: 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 455B2131531 for ; Mon, 24 Apr 2017 06:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.221 X-Spam-Level: X-Spam-Status: No, score=-1.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=gP15HwFy; dkim=pass (1536-bit key) header.d=taugh.com header.b=wkUQJO6k 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 C0ybKBczdtBA for ; Mon, 24 Apr 2017 06:43:25 -0700 (PDT) Received: from miucha.iecc.com (w6.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FCE913152E for ; Mon, 24 Apr 2017 06:43:25 -0700 (PDT) Received: (qmail 32625 invoked from network); 24 Apr 2017 13:43:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=7f6e.58fe00fc.k1704; bh=6l5Pcf2KLPkhQlNUMFagfuZgXv5RxssFTWnVleyu6Ac=; b=gP15HwFyd2Js2oZvTQAKXkkLRv0ruAG+u6Xoad1KdEhGH1PS1Pe5X/c7CtwwIpaBQejNKCxRYJXB4BpItIcbduHh/Ujbo5be796kBMaVChnzcz36fldF8v3+HXZST0av7Lvudk81SSbAKuI+zbAC42gjfNBGK1xK5kUrGQj7XWNmu3DmzENg0v4VF5iwDS6Xexu/iwyYIq4kGEb2U96xv2PQq+QXtKPGY/YwRGuRhfU2W8eFl7yrUHnFGnyNDKR+ DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=7f6e.58fe00fc.k1704; bh=6l5Pcf2KLPkhQlNUMFagfuZgXv5RxssFTWnVleyu6Ac=; b=wkUQJO6kLFbeFy5gLxqJmB+ZgiGmwoaeNIzqWbAqcKp2kI7wH9ZBabj3fsE0zKqZDWMsWBrOi7+vglwAILw2qgf5Fi2tRDEIEJ6SNzm7aIzfWGwYf5T+/7c2y6RFgpYVRKC3fRftnULTLEliQuxYaL6YpxZ67Vb2S4cCw6Cs28YOnu1J6lsuAOFHBtjQkpJGtirWCPEQ8/fqaE+u3kjT/1a7c2PZrKlHGiJt8TIVwokM4Yd0PDh0J8ZlNuO8PyBC Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 24 Apr 2017 13:43:23 -0000 Date: 24 Apr 2017 09:43:23 -0400 Message-ID: From: "John R Levine" To: "Adrien de Croy" Cc: "jmap@ietf.org" In-Reply-To: References: <1492996915.3310412.953749536.0F1C8B46@webmail.messagingengine.com> <20170424014957.39235.qmail@ary.lan> User-Agent: Alpine 2.20 (OSX 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [Jmap] Address Validation (was Re: Submission) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 13:43:27 -0000 > when I made the suggestion, I was imagining that although you can't do VRFY > or EXPN or probe emails and yes this is for good reason, the number of times > I've had bounce messages a long time after submission for problems such as > NXDOMAIN, means the current system isn't very good at even this. Once again, that's a change to SMTP and in this case a fairly large and incompatible one. On all the mail systems I know, if you try to send mail at a domain that doesn't exist, it fails instantly. The problem is when you send mail to a domain that has an A record but no mail server. There's no way for a client system to tell a nonexistent mail server from one that crashed and will be back shortly. Maybe the retry timeout should be less than the 4-5 days that RFC 5321 suggests, but that's a quality of implementation issue that has nothing whatsoever to do with JMAP. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Mon Apr 24 06:52:13 2017 Return-Path: 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 AC04612945F for ; Mon, 24 Apr 2017 06:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 beCo2_PFxIII for ; Mon, 24 Apr 2017 06:52:08 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76622126DEE for ; Mon, 24 Apr 2017 06:52:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id A985B6AD4140; Mon, 24 Apr 2017 09:52:07 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mk5gF4fG8zVa; Mon, 24 Apr 2017 09:52:06 -0400 (EDT) Received: from [17.44.178.123] (unknown [17.44.178.123]) by daboo.name (Postfix) with ESMTPSA id 7436D6AD4134; Mon, 24 Apr 2017 09:52:06 -0400 (EDT) Date: Mon, 24 Apr 2017 09:52:05 -0400 From: Cyrus Daboo To: Adrien de Croy , Bron Gondwana , jmap@ietf.org Message-ID: In-Reply-To: References: <1492997737.3312553.953738776.7D27901C@webmail.messagingengine.com> X-Mailer: Mulberry/4.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=709 Archived-At: Subject: Re: [Jmap] Submission: options for github issue X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 13:52:12 -0000 Hi Adrien, --On April 24, 2017 at 2:38:53 AM +0000 Adrien de Croy wrote: > There could be some value in keeping the envelope after a message is > submitted. One key value: the ability to re-send the message in case of a failure that can easily be corrected. Also, users expect to see Bcc information in their sent-mail copies, so if that detail was only in the envelope then it would need to be preserved. However, clients have traditionally used the Bcc header for maintaining that information, so we may need to special Bcc headers even if the envelope is preserved - but then it because a little awkward because of the duplication of information in two places. -- Cyrus Daboo From nobody Mon Apr 24 07:13:03 2017 Return-Path: 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 5AF9B129492 for ; Mon, 24 Apr 2017 07:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 EVU4_u5QrBwy for ; Mon, 24 Apr 2017 07:12:59 -0700 (PDT) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B679612948E for ; Mon, 24 Apr 2017 07:12:59 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id g60so114602843qtd.3 for ; Mon, 24 Apr 2017 07:12:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=LMis5p7ILVCggGw97GUzThFac8w9MAdRN3UvuB4Ej00=; b=GLBYiRTgp5SHX2xrhULrZrF9N2HtT4kRQOrsp8IwgVLhzqea5XTVwFMGLBpMHRaoVH +BHlL6czJQxqWGkU2zWkuy7pkkilM5/jgwoiSPYKhOQ3CCC242ob7ezzmn8SZjRayMbK IYlXOHfzgd59sj4/tN2hMyY3BWoO9sbC3kuzYjc4g/3AoikwO19nP7DPGR8x75Y2qUmY zHFbeFeEcVE0vEfvDZiW7PvEhjQD8nu+dhicIf+7CYSOJNdrmrwtea1jy2KWu22iyHXL BjuRVkszNLO0t2f7pPgUnwufxUHpgDirYlwkWN8MD72/PfMnJE+N3f6dGPqO4ZvZqjsp a7tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=LMis5p7ILVCggGw97GUzThFac8w9MAdRN3UvuB4Ej00=; b=kfqnyTOier9HUbBE92IM7shSfXz3vGkZiELH/DOGTAos3+qwsLYemSGF35JVtmU0wQ 3vz08YcxfBdEGAaeNG8lWGLb6dfA85y0RD1BoJUgZorAO1DRd43i6ECtUP2lCXpW60li YiMzQJCnQFQW3MlLlCirKddtDyVsYvBcm2viDar5Wzel9XQqII/348QKtv7OYJAVKWbl WsZ/WpeF3Guy6/iyJ7XuQhJfu20bmu8ytN+4JZF8L+u5zwFgHlNMqmRynOjUG/Val8zV y9Omgtzc2VMfGJQF6pvEsRC0FqrY1AjKImayaa2BYp9SW2LjqsBRvcdYr+59rKKtwZuc 49EA== X-Gm-Message-State: AN3rC/7p+J8fAP3MwFU/xFR69kFn/zqJd3VaLF6s5MP+Dtiw6/E9LzH5 43o27JsGDFvPEpeH7Ts= X-Received: by 10.237.38.135 with SMTP id q7mr1584260qtd.115.1493043178923; Mon, 24 Apr 2017 07:12:58 -0700 (PDT) Received: from macbook-pro-6.home (pool-108-31-94-75.washdc.fios.verizon.net. [108.31.94.75]) by smtp.gmail.com with ESMTPSA id y201sm7282599qky.41.2017.04.24.07.12.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Apr 2017 07:12:58 -0700 (PDT) From: Ted Lemon Message-Id: <43747FEE-5EBE-4F89-BE13-94701F88A5BA@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_D95CE3FB-9439-4311-99F6-06F4A3EC4094" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 24 Apr 2017 10:12:56 -0400 In-Reply-To: Cc: Adrien de Croy , Bron Gondwana , jmap@ietf.org To: Cyrus Daboo References: <1492997737.3312553.953738776.7D27901C@webmail.messagingengine.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Jmap] Submission: options for github issue X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 14:13:01 -0000 --Apple-Mail=_D95CE3FB-9439-4311-99F6-06F4A3EC4094 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 24, 2017, at 9:52 AM, Cyrus Daboo wrote: > we may need to special Bcc headers even if the envelope is preserved - = but then it because a little awkward because of the duplication of = information in two places. Except that the bcc header shouldn't be in the message in the first = place, for privacy reasons. So either the message in the JMAP store is = different than what was actually sent, or the Bcc info should _only_ be = on the envelope. Of course, this requires the MUA to do some creative gymnastics to make = it all look good, but such is life. --Apple-Mail=_D95CE3FB-9439-4311-99F6-06F4A3EC4094 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Apr 24, 2017, at 9:52 AM, Cyrus Daboo <cyrus@daboo.name> = wrote:
we may need to = special Bcc headers even if the envelope is preserved - but then it = because a little awkward because of the duplication of information in = two places.

Except that the bcc header shouldn't be in = the message in the first place, for privacy reasons.   So either = the message in the JMAP store is different than what was actually sent, = or the Bcc info should _only_ be on the envelope.
Of course, this requires the MUA to do = some creative gymnastics to make it all look good, but such is = life.

= --Apple-Mail=_D95CE3FB-9439-4311-99F6-06F4A3EC4094-- From nobody Mon Apr 24 07:16:19 2017 Return-Path: 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 3536C129496 for ; Mon, 24 Apr 2017 07:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gulbrandsen.priv.no 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 5Ug1ag44Bo7V for ; Mon, 24 Apr 2017 07:16:16 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B2221294B3 for ; Mon, 24 Apr 2017 07:16:16 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 51489FA005C; Mon, 24 Apr 2017 14:16:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1493043374; bh=eTWYixX6yDeOo6tMnUD7rQU+8HSyZl99Tb6ykDPVs24=; h=From:To:Subject:Date:In-Reply-To:References:From; b=YIoZtrqb271hlpFW9KuIxQK49kwfTZUJ9IIh7zP7dQ9Mmvb6jag1BqFrVIbeUPFk/ Vpv2Hennki/7Dq9Jd35vwa+DFm7evoouesP3+dhc5thFc3XC1CkOXmQYYLENT4wwzG y4pCCPEOyHGfbYIfwhV/eLiVknxPfbrMNMMBQc/Y= Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1493043373-4383-4380/11/21; Mon, 24 Apr 2017 14:16:13 +0000 From: Arnt Gulbrandsen To: jmap@ietf.org Date: Mon, 24 Apr 2017 15:16:13 +0100 User-Agent: Trojita/v0.5-9-g8961725; Qt/4.8.6; X11; Linux; Devuan GNU/Linux 1.0 (jessie) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <1492996915.3310412.953749536.0F1C8B46@webmail.messagingengine.com> <20170424014957.39235.qmail@ary.lan> Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: Subject: Re: [Jmap] Address Validation (was Re: Submission) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 14:16:18 -0000 John R Levine writes: > Once again, that's a change to SMTP and in this case a fairly > large and incompatible one. 3885/7, isn't it? Would be nice if etc., but twelve years of nonimplementation is a strong sign that it isn't going to be implemented. IMO JMAP draft editors ought to pretend that 3885-8 never were written and nothing of the sort will be deployed. Arnt From nobody Mon Apr 24 07:26:33 2017 Return-Path: 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 534551314F6 for ; Mon, 24 Apr 2017 07:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 P6eFUZt0xxsz for ; Mon, 24 Apr 2017 07:26:30 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2873130134 for ; Mon, 24 Apr 2017 07:26:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 0BBA46AD4D3F; Mon, 24 Apr 2017 10:26:28 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qMeMdKCBsrdg; Mon, 24 Apr 2017 10:26:27 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.44.178.52]) by daboo.name (Postfix) with ESMTPSA id 69A506AD4D34; Mon, 24 Apr 2017 10:26:27 -0400 (EDT) Date: Mon, 24 Apr 2017 10:26:20 -0400 From: Cyrus Daboo To: Ted Lemon cc: Adrien de Croy , Bron Gondwana , jmap@ietf.org Message-ID: <4A4B1A7AC839999470A6D83C@caldav.corp.apple.com> In-Reply-To: <43747FEE-5EBE-4F89-BE13-94701F88A5BA@fugue.com> References: <1492997737.3312553.953738776.7D27901C@webmail.messagingengine.com> <43747FEE-5EBE-4F89-BE13-94701F88A5BA@fugue.com> X-Mailer: Mulberry/4.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=1142 Archived-At: Subject: Re: [Jmap] Submission: options for github issue X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 14:26:31 -0000 Hi Ted, --On April 24, 2017 at 10:12:56 AM -0400 Ted Lemon wrote: >> we may need to special Bcc headers even if the envelope is preserved - >> but then it because a little awkward because of the duplication of >> information in two places. > > Except that the bcc header shouldn't be in the message in the first > place, for privacy reasons. So either the message in the JMAP store is > different than what was actually sent, or the Bcc info should _only_ be > on the envelope. > > Of course, this requires the MUA to do some creative gymnastics to make > it all look good, but such is life. > Most MUAs today store Bcc information in the sent-mail copy of a message - of course they never include the Bcc header in the message that was actually sent However it is worth noting that RFC 5322 () does define 3 different ways that the Bcc header can be used and in two of those the Bcc header is included in some fashion in a message being sent. I don't think those two modes are common enough to warrant support in JMAP, but I could be wrong. -- Cyrus Daboo From nobody Mon Apr 24 07:43:08 2017 Return-Path: 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 7DB53131591 for ; Mon, 24 Apr 2017 07:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 eq3As372vPW9 for ; Mon, 24 Apr 2017 07:43:04 -0700 (PDT) Received: from mail-yb0-x242.google.com (mail-yb0-x242.google.com [IPv6:2607:f8b0:4002:c09::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17C1C13158A for ; Mon, 24 Apr 2017 07:43:03 -0700 (PDT) Received: by mail-yb0-x242.google.com with SMTP id 19so8990423ybl.2 for ; Mon, 24 Apr 2017 07:43:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=asor5dQKCQODX5ny4NsrLgkIbaFQOSnBWb4HmQvDhkw=; b=Lmh2C2rrLYHLybzteQNKt03HVHe2t8FovW54nTXq/dAHuh6WUkGPktbXPPMx7MMF99 AI0LZPzTiZaH3A562gsTJXD0TckUlgjYHzkPWDBIwA6UuCdOCdDhcu+/w2yne7Sr9Z2p 9T2P9l1ZdkESmsziZCtSLumXe2QNxSnztWiI1yTHEDFpaVZPQZbzaBpk3vN52hPymZfm I1wtQjgQab8CsTDSqtHfCf/ovxFxlvcFsTXVw3JWgdwJBBjFRpBPg5UrOvuBNRNIfF5I pJB8ddpnZdG43QPl9dqCyshaQQYUj/uQ8VKQt4khB+1ayOQ1/1hyIoextLQXZpHx5FsF M7/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=asor5dQKCQODX5ny4NsrLgkIbaFQOSnBWb4HmQvDhkw=; b=YoweSFnfCz3FQJgCTA2OAgCD9RYtPh5gXlTdHTUmMSWAI6yvXifC+DSqeUTj0518Ec 5BPp/FgBRUNW9CmErKx1PuPzlX8sHOtny4NTXrdVuwXwdjfqLX/dYvH2a5i5IrIViiUm M/VUgXGa/c1VPxAslW1QAqwg0TrqC8Fr6jWlUwpeOtUv/Pv4cApRZTR2LU64AGtb/2es ZZvOu2FcnDdo0iyslGvoRK0qm8b5zY4uNDCwmLkotl6BGjeP7H4jlwDxSg5euaHkficQ sXB8Pgh48/PROY7NXYxi3+IjTjkxliYv4+mkZ5Np13uRECaX8UICx9M3QY/FGLckQ7pE CFSg== X-Gm-Message-State: AN3rC/7CiGQCDJlWP9jEfn6RuwidgHcXldv38XwZYNZakw1nXsjHYHHw v9l1D2xzLy7MPXOnPyhVNCZEfFWArA== X-Received: by 10.37.173.90 with SMTP id l26mr5265819ybe.73.1493044982269; Mon, 24 Apr 2017 07:43:02 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 24 Apr 2017 07:43:01 -0700 From: Gren Elliot In-Reply-To: <4A4B1A7AC839999470A6D83C@caldav.corp.apple.com> References: <1492997737.3312553.953738776.7D27901C@webmail.messagingengine.com> <43747FEE-5EBE-4F89-BE13-94701F88A5BA@fugue.com> <4A4B1A7AC839999470A6D83C@caldav.corp.apple.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Mon, 24 Apr 2017 07:43:01 -0700 Message-ID: To: Ted Lemon , Cyrus Daboo , jmap@ietf.org Cc: Adrien de Croy , Bron Gondwana Content-Type: multipart/alternative; boundary=f403045ec944cd4eeb054dea9f94 Archived-At: Subject: Re: [Jmap] Submission: options for github issue X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 14:43:06 -0000 --f403045ec944cd4eeb054dea9f94 Content-Type: text/plain; charset=UTF-8 I have worked on a server that did BCC splitting - i.e. A separate message was sent to each BCC user including their address in the BCC header and a message sent to all the rest excluding the BCC header. Regards, Gren Elliot From: Cyrus Daboo Reply: Cyrus Daboo Date: 24 April 2017 at 15:26:35 To: Ted Lemon Cc: Adrien de Croy , jmap@ietf.org , Bron Gondwana Subject: Re: [Jmap] Submission: options for github issue Hi Ted, --On April 24, 2017 at 10:12:56 AM -0400 Ted Lemon wrote: >> we may need to special Bcc headers even if the envelope is preserved - >> but then it because a little awkward because of the duplication of >> information in two places. > > Except that the bcc header shouldn't be in the message in the first > place, for privacy reasons. So either the message in the JMAP store is > different than what was actually sent, or the Bcc info should _only_ be > on the envelope. > > Of course, this requires the MUA to do some creative gymnastics to make > it all look good, but such is life. > Most MUAs today store Bcc information in the sent-mail copy of a message - of course they never include the Bcc header in the message that was actually sent However it is worth noting that RFC 5322 () does define 3 different ways that the Bcc header can be used and in two of those the Bcc header is included in some fashion in a message being sent. I don't think those two modes are common enough to warrant support in JMAP, but I could be wrong. -- Cyrus Daboo _______________________________________________ Jmap mailing list Jmap@ietf.org https://www.ietf.org/mailman/listinfo/jmap --f403045ec944cd4eeb054dea9f94 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =
I have worked on a server that did BCC splitting = - i.e. A separate message was sent to each BCC user including their address= in the BCC header and a message sent to all the rest excluding the BCC hea= der.

Regards,
Gren Elliot
=

From:= =C2=A0Cyrus Daboo <cyrus@daboo.name>
Reply:=C2=A0Cyrus Daboo <cyrus= @daboo.name>
Date:=C2=A024 April 2017= at 15:26:35
To:=C2=A0Ted Lemon <mellon@fugue.com>
Cc:= =C2=A0Adrien de Croy <adrien@qbik.com>, jmap@ietf.org <jmap@ietf.org>, Bron G= ondwana <brong@fastmail.fm&g= t;
Subject:=C2=A0 Re: [Jmap] Submission:= options for github issue

Hi Ted,

--On April 24, 2017 at 10:12:56 AM -0400 Ted Lemon <mellon@fugue.com> wrote:

>> we may need to special Bcc headers even if the envelope is pre= served -
>> but then it because a little awkward because of the duplicatio= n of
>> information in two places.
>
> Except that the bcc header shouldn't be in the message in the = first
> place, for privacy reasons. So either the message in the JMAP st= ore is
> different than what was actually sent, or the Bcc info should _onl= y_ be
> on the envelope.
>
> Of course, this requires the MUA to do some creative gymnastics to= make
> it all look good, but such is life.
>

Most MUAs today store Bcc information in the sent-mail copy of a messag= e - =20
of course they never include the Bcc header in the message that was =20
actually sent

However it is worth noting that RFC 5322 =20
(<http= s://tools.ietf.org/html/rfc5322#section-3.6.3>) does define 3 =20
different ways that the Bcc header can be used and in two of those the = Bcc =20
header is included in some fashion in a message being sent. I don't= think =20
those two modes are common enough to warrant support in JMAP, but I cou= ld =20
be wrong.

-- =20
Cyrus Daboo

_______________________________________________
Jmap mailing list
Jmap@ietf.org
https://www.ietf= .org/mailman/listinfo/jmap
--f403045ec944cd4eeb054dea9f94-- From nobody Mon Apr 24 07:49:09 2017 Return-Path: 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 EAEDF1315DA for ; Mon, 24 Apr 2017 07:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no 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 qwQxVOcUFWTj for ; Mon, 24 Apr 2017 07:49:07 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 605E31315A6 for ; Mon, 24 Apr 2017 07:48:11 -0700 (PDT) Received: (qmail 63976 invoked from network); 24 Apr 2017 14:48:10 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 24 Apr 2017 14:48:10 -0000 Date: 24 Apr 2017 14:47:48 -0000 Message-ID: <20170424144748.42105.qmail@ary.lan> From: "John Levine" To: jmap@ietf.org Cc: brong@fastmail.fm In-Reply-To: <1492999438.3318688.953774952.11A8EA9B@webmail.messagingengine.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Jmap] Address Validation (was Re: Submission) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 14:49:08 -0000 In article <1492999438.3318688.953774952.11A8EA9B@webmail.messagingengine.com> you write: > There's definitely value in that from a >usability perspective, particularly in a large company or university or something where valid address lookup is available. If it's just address validation, I still don't see a lot of value in doing that separately before you send the message. On the other hand, if the address is local there's likely to be an LDAP server that can populate other parts of the address book than just the address. R's, John From nobody Mon Apr 24 07:53:32 2017 Return-Path: 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 B67271315AE for ; Mon, 24 Apr 2017 07:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no 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 mnv66jNBICgr for ; Mon, 24 Apr 2017 07:53:31 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C14F81315DC for ; Mon, 24 Apr 2017 07:51:39 -0700 (PDT) Received: (qmail 64601 invoked from network); 24 Apr 2017 14:51:38 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 24 Apr 2017 14:51:38 -0000 Date: 24 Apr 2017 14:51:16 -0000 Message-ID: <20170424145116.42134.qmail@ary.lan> From: "John Levine" To: jmap@ietf.org Cc: arnt@gulbrandsen.priv.no In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Jmap] Address Validation (was Re: Submission) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 14:53:32 -0000 In article you write: >John R Levine writes: >> Once again, that's a change to SMTP and in this case a fairly >> large and incompatible one. > >3885/7, isn't it? Would be nice if etc., but twelve years of >nonimplementation is a strong sign that it isn't going to be implemented. That, and the relief we all felt when default configs of sendmail stopped sending those messages saying I've been trying for N hours and will keep trying for a long, long, time. R's, John From nobody Mon Apr 24 07:54:46 2017 Return-Path: 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 3E7C2131656 for ; Mon, 24 Apr 2017 07:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no 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 rhEUotRCOXga for ; Mon, 24 Apr 2017 07:54:44 -0700 (PDT) Received: from miucha.iecc.com (w6.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E18813162A for ; Mon, 24 Apr 2017 07:52:46 -0700 (PDT) Received: (qmail 64738 invoked from network); 24 Apr 2017 14:52:45 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 24 Apr 2017 14:52:45 -0000 Date: 24 Apr 2017 14:52:23 -0000 Message-ID: <20170424145223.42155.qmail@ary.lan> From: "John Levine" To: jmap@ietf.org Cc: brong@fastmail.fm In-Reply-To: <1492996614.3309017.953748384.4E2D15C7@webmail.messagingengine.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Jmap] Is the group address syntax from RFC5322 really not supported in JMAP? X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 14:54:45 -0000 In article <1492996614.3309017.953748384.4E2D15C7@webmail.messagingengine.com> you write: >https://github.com/jmapio/jmap/issues/59 Seems to me that this is one of the many problems that a separate submission envelope solves. R's, John > >On Fri, 21 Apr 2017, at 18:46, Alexey Melnikov wrote: >> >> > On 21 Apr 2017, at 08:09, Mads Hjorth wrote: >> > >> > HI, >> > >> > I have an eye on JMAP for the use in a rather large scale messaging system (+5 million mailboxes). >> > >> > In one of our use cases, we want to send messages to an named group, allowing the recipient to see the name of the group, but not the identity of >the members. We consider using the RFC5322 syntax for this e.g. >> > >> > To: Teenage Mutant Ninja Turtles:; >> > Bcc: “Leonardo†, “Donatello†>> > >> > But the current JMAP states >> > >> >> Group information and comments from the RFC 5322 header MUST be discarded when converting into an Emailer object. From nobody Mon Apr 24 08:01:22 2017 Return-Path: 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 A49DC1315E7 for ; Mon, 24 Apr 2017 08:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.602 X-Spam-Level: X-Spam-Status: No, score=-0.602 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 0b1VNnOUvGS9 for ; Mon, 24 Apr 2017 08:01:19 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 417AD1315AF for ; Mon, 24 Apr 2017 07:59:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1493045962; d=isode.com; s=june2016; i=@isode.com; bh=KlSvcjUhFNFIG75+FFMRUV67vAJNhSOqyq3FeyFcsjk=; 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=PvoRaqUppgYIlTbJizJ+ujKeLdFYKcQCZr6NesjmQEZVFRass0tgM+fLgRQH6EQhm914nE 6cbMl4pAJjP6PoyXuAvzurLujJVSZg4U5zG1rVCcAE7QAeaQfqDOobEiKcjis7C7qgFGwn pi9Yz2CHegdOZMSADcm51QIkD8iwuG4=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 24 Apr 2017 15:59:22 +0100 To: John Levine , jmap@ietf.org References: <20170424145223.42155.qmail@ary.lan> Cc: brong@fastmail.fm From: Alexey Melnikov Message-ID: Date: Mon, 24 Apr 2017 15:59:14 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 In-Reply-To: <20170424145223.42155.qmail@ary.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Jmap] Is the group address syntax from RFC5322 really not supported in JMAP? X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 15:01:21 -0000 On 24/04/2017 15:52, John Levine wrote: > In article <1492996614.3309017.953748384.4E2D15C7@webmail.messagingengine.com> you write: >> https://github.com/jmapio/jmap/issues/59 > Seems to me that this is one of the many problems that a separate submission > envelope solves. Possibly, but currently group names can't be expressed in syntax. So the above ticket is about that. From nobody Mon Apr 24 08:02:16 2017 Return-Path: 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 7450A13166C for ; Mon, 24 Apr 2017 08:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gulbrandsen.priv.no 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 M46o8oDxyoeG for ; Mon, 24 Apr 2017 08:02:11 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1196C1315F2 for ; Mon, 24 Apr 2017 08:00:22 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 42634FA005C; Mon, 24 Apr 2017 15:00:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1493046021; bh=qyOMwkR0G2f0bI0lVWlQ0DF2cv2o+ypqvDkO58QPpE0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=UFQC/l7Qoc+63gvw+PiTAWUgZaaTy5ukqzDshX6argwwQjHXDT/tyTKodskrNzPBv gdYCzwilEv1UArU1jaJArwb/S8VNwn2A3f6Qa68Vi96StNjFp9JQgMaCokohc1bBUa pZ5SNJ0knponN+QSZ2N6k/g0/0jP/lZS4hld5D3g= Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1493046020-8170-4380/11/5; Mon, 24 Apr 2017 15:00:20 +0000 From: Arnt Gulbrandsen To: jmap@ietf.org Date: Mon, 24 Apr 2017 16:00:20 +0100 User-Agent: Trojita/v0.5-9-g8961725; Qt/4.8.6; X11; Linux; Devuan GNU/Linux 1.0 (jessie) Mime-Version: 1.0 Message-Id: In-Reply-To: <20170424145116.42134.qmail@ary.lan> References: <1492996915.3310412.953749536.0F1C8B46@webmail.messagingengine.com> <20170424014957.39235.qmail@ary.lan> <20170424145116.42134.qmail@ary.lan> Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: Subject: Re: [Jmap] Address Validation (was Re: Submission) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 15:02:15 -0000 John Levine writes: > That, and the relief we all felt when default configs of sendmail > stopped sending those messages saying I've been trying for N hours and > will keep trying for a long, long, time. I shudder at the memory ;) An excellent example of good intention ruined by annoying execution. Arnt From nobody Mon Apr 24 08:24:15 2017 Return-Path: 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 A926C131674 for ; Mon, 24 Apr 2017 08:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 uop6awipWA30 for ; Mon, 24 Apr 2017 08:24:12 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05A9C131675 for ; Mon, 24 Apr 2017 08:24:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 91FDA6AD61C7; Mon, 24 Apr 2017 11:24:05 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dj53zBvzrX2E; Mon, 24 Apr 2017 11:24:05 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.44.178.52]) by daboo.name (Postfix) with ESMTPSA id D899B6AD61BC; Mon, 24 Apr 2017 11:24:04 -0400 (EDT) Date: Mon, 24 Apr 2017 11:24:02 -0400 From: Cyrus Daboo To: Bron Gondwana , jmap@ietf.org Message-ID: In-Reply-To: <1492997737.3312553.953738776.7D27901C@webmail.messagingengine.com> References: <1492997737.3312553.953738776.7D27901C@webmail.messagingengine.com> X-Mailer: Mulberry/4.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=411 Archived-At: Subject: Re: [Jmap] Submission: options for github issue X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 15:24:14 -0000 Hi Bron, --On April 24, 2017 at 11:35:37 AM +1000 Bron Gondwana wrote: > Do you think I have adequately captured all the possible ways to do > submission here? Well for completeness there is the BURL(RFC4468)/URLAUTH(RFC4467) extension that works today in conjunction with IMAP. Whilst I am not proposing JMAP support that, it is another mechanism that could be used. -- Cyrus Daboo From nobody Mon Apr 24 08:25:48 2017 Return-Path: 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 419D312943B for ; Mon, 24 Apr 2017 08:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 hfQRv3HD8jeW for ; Mon, 24 Apr 2017 08:25:40 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCB39131675 for ; Mon, 24 Apr 2017 08:25:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 1F40B6AD623C; Mon, 24 Apr 2017 11:25:39 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5XDHbpmXfvvM; Mon, 24 Apr 2017 11:25:38 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.44.178.52]) by daboo.name (Postfix) with ESMTPSA id 6169F6AD6231; Mon, 24 Apr 2017 11:25:38 -0400 (EDT) Date: Mon, 24 Apr 2017 11:25:36 -0400 From: Cyrus Daboo To: Arnt Gulbrandsen , jmap@ietf.org Message-ID: In-Reply-To: References: <1492996915.3310412.953749536.0F1C8B46@webmail.messagingengine.com> <20170424014957.39235.qmail@ary.lan> X-Mailer: Mulberry/4.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=835 Archived-At: Subject: Re: [Jmap] Address Validation (was Re: Submission) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 15:25:41 -0000 Hi Arnt, --On April 24, 2017 at 3:16:13 PM +0100 Arnt Gulbrandsen wrote: > 3885/7, isn't it? Would be nice if etc., but twelve years of > nonimplementation is a strong sign that it isn't going to be implemented. > IMO JMAP draft editors ought to pretend that 3885-8 never were written > and nothing of the sort will be deployed. At least one person has commented on this list that they have implemented the extension. Just because an extension is not implemented by every SMTP server, it doesn't mean that the extension is not useful and being used in some smaller market. Clearly we don't need to build message tracking into JMAP from the outset, but equally we should not design JMAP in a way that would prevent it from easily being added as an extension for those that want it. -- Cyrus Daboo From nobody Mon Apr 24 08:26:05 2017 Return-Path: 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 D8D571316A2 for ; Mon, 24 Apr 2017 08:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.221 X-Spam-Level: X-Spam-Status: No, score=-1.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=fYQ7GjWE; dkim=pass (1536-bit key) header.d=taugh.com header.b=ifOJla7V 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 GQTqAGaS1pXv for ; Mon, 24 Apr 2017 08:26:02 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 010B21316B6 for ; Mon, 24 Apr 2017 08:25:56 -0700 (PDT) Received: (qmail 69792 invoked from network); 24 Apr 2017 15:25:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=1109e.58fe1903.k1704; bh=rL768DUxnLAs5OqRiC7+M1LgzdwKvBGyqAbBsvxgohE=; b=fYQ7GjWEOYYc+nida0jJBHgN3jn+w52JQsVf6fPhH6zwd/aYvx+jnBTnw1nCvKJOB9JQAteK9CMqyo4XZ/TdjkbwHVdC5PeFcvPa6MBOzqwJkBBylPsdhW5tu2uR2ZMOs8kBEURIlxH2hOXJmIrq76hdXaRneqkG4AF/evam7Ba4/XZPIUBwqoBRLFik4a/sbgCf68tCpP3oCAN931Y0ItKD1qNNrWATKchiSS0bXShCqP3IQ9PZ5UQqbW5RxKvK DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=1109e.58fe1903.k1704; bh=rL768DUxnLAs5OqRiC7+M1LgzdwKvBGyqAbBsvxgohE=; b=ifOJla7VgESq4jZfqZo8tvvm3xTmxAbdaj0zZLf0oyN/wWHMiMmfu1FJsg55xvX3BN4SvS4bz7A0lMRGglAmPkkfK72x+cO7f7IRu2jNzpOdaXQiVaKrHawmpAEjgigF1M3qaEBgdDalB5dEq/nl7Lw42by0j2ewUjJdOpcw60dp6IHndoJSWOzY+DrF7jEssEzKdnpVaglZg4NJl9FT3egdUtVBadp6RxR1VIFAtIqT4XBYalEYKtS2UXQIuM/w Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 24 Apr 2017 15:25:55 -0000 Date: 24 Apr 2017 11:25:55 -0400 Message-ID: From: "John R Levine" To: "Alexey Melnikov" Cc: "John Levine" , jmap@ietf.org, brong@fastmail.fm In-Reply-To: References: <20170424145223.42155.qmail@ary.lan> User-Agent: Alpine 2.20 (OSX 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Jmap] Is the group address syntax from RFC5322 really not supported in JMAP? X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 15:26:04 -0000 >>> https://github.com/jmapio/jmap/issues/59 >> Seems to me that this is one of the many problems that a separate >> submission envelope solves. > Possibly, but currently group names can't be expressed in syntax. So the > above ticket is about that. They aren't expressed in SMTP either, they're just a convention for 5322 headers. It's always been up to the MUA to pick out the actual addresses at submission time. In practice there have always been ways to store distribution lists on one's mail server, but I don't think any of those have ever made it into an RFC. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Mon Apr 24 08:47:05 2017 Return-Path: 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 91F0E131755 for ; Mon, 24 Apr 2017 08:47:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no 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 C546ysuWRVEo for ; Mon, 24 Apr 2017 08:47:02 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9065F131754 for ; Mon, 24 Apr 2017 08:47:02 -0700 (PDT) Received: (qmail 74021 invoked from network); 24 Apr 2017 15:46:59 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 24 Apr 2017 15:46:59 -0000 Date: 24 Apr 2017 15:46:37 -0000 Message-ID: <20170424154637.42294.qmail@ary.lan> From: "John Levine" To: jmap@ietf.org Cc: brong@fastmail.fm In-Reply-To: <1492997737.3312553.953738776.7D27901C@webmail.messagingengine.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Jmap] sent vs. really sent, was Submission: options for github issue X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 15:47:04 -0000 In article <1492997737.3312553.953738776.7D27901C@webmail.messagingengine.com> you write: >2c) add envelope data as special properties which can only be set when moving a message to Outbox (like 2b), but if not set are inferred from the content of the message (like 1a). Most submission servers clean up the message on the way out. RFC 4409 describes some of the things they do, making all addresses FQDNs rather than local abbreviations (joe@sales -> joe@sales.bigcorp.cam), They can also invent missing To:, From: and Sender: lines from the envelope, add Date: and Message-ID: if they're missing or invalid, fix common address syntax errors like no comma between addresses, and delete Bcc. Modern MUAs tend to send mail with fewer defects than the old unix Mail program, but my MSA still does this stuff, and I've found that when I've misconfigured my MSA to skip the cleanup step, I can tell. This means that if the MUA directly stores copies of the message in the Sent folder, the stored copies are not the same as what really got sent. This is not new, and it's probably why a lot of MUAs give you the option of adding an implicit BCC so you can send copies to yourself or perhaps to an address filtered into your Sent folder. So anyway, I have no objection to inferring the envelope so long as it's all or nothing, if you specify any of the envelope you specify all of it, but I wouldn't worry too much about whether the message then gets cleaned up by BCC deletion since that's nothing new. R's, John From nobody Mon Apr 24 09:14:12 2017 Return-Path: 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 93889131799 for ; Mon, 24 Apr 2017 09:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gulbrandsen.priv.no 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 YYQQB9C8m5WA for ; Mon, 24 Apr 2017 09:14:09 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53B31127201 for ; Mon, 24 Apr 2017 09:14:08 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 4C074FA005C; Mon, 24 Apr 2017 16:14:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1493050447; bh=Frq225x6kfqL3xZ14gb74Slc1BVZs5iVGC1T6lVE5a0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=gnqZ7ksNj9R0mI+UUcSSUFVIXQWNbyk9NyTVxgtBTrBKwQOjfS2Kxq/ukfJytQNkq M32rR47ERjEIYKQqHaCj7JTOLipsmiOp262GHyQvtqTA3xaZhI4huZjNydfjrg0pxI aYvi/KhuXuud5RkHZ8d/2ed8ruhOCBDStaDRXI6E= Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1493050446-4383-4380/11/23; Mon, 24 Apr 2017 16:14:06 +0000 From: Arnt Gulbrandsen To: Cyrus Daboo Cc: jmap@ietf.org Date: Mon, 24 Apr 2017 17:14:01 +0100 User-Agent: Trojita/v0.5-9-g8961725; Qt/4.8.6; X11; Linux; Devuan GNU/Linux 1.0 (jessie) Mime-Version: 1.0 Message-Id: <6319482c-e53f-4483-870b-844e23030f8c@gulbrandsen.priv.no> In-Reply-To: References: <1492996915.3310412.953749536.0F1C8B46@webmail.messagingengine.com> <20170424014957.39235.qmail@ary.lan> Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: Subject: Re: [Jmap] Address Validation (was Re: Submission) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 16:14:11 -0000 Cyrus Daboo writes: > At least one person has commented on this list that they have > implemented the extension. Yes. > Just because an extension is not > implemented by every SMTP server, it doesn't mean that the > extension is not useful and being used in some smaller market. > Clearly we don't need to build message tracking into JMAP from > the outset, but equally we should not design JMAP in a way that > would prevent it from easily being added as an extension for > those that want it. I agree that 3885 (et al) have some utility even if only a few people implement them. However, the question that I understood was asked upthread is roughly "to which recipients has x been delivered already?", and for that particular question an unbroken implementation chain is needed from sender to recipient. Arnt From nobody Mon Apr 24 09:31:47 2017 Return-Path: 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 7D75B1317F7 for ; Mon, 24 Apr 2017 09:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.4 X-Spam-Level: X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 ntXzr2IaqzRO for ; Mon, 24 Apr 2017 09:31:45 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9325131823 for ; Mon, 24 Apr 2017 09:31:44 -0700 (PDT) Received: from pps.filterd (m0049462.ppops.net [127.0.0.1]) by m0049462.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v3OGTvLH012302 for ; Mon, 24 Apr 2017 12:31:42 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049462.ppops.net-00191d01. with ESMTP id 2a1k7gwrp5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 24 Apr 2017 12:31:41 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v3OGVdZ4030563 for ; Mon, 24 Apr 2017 12:31:40 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v3OGVUUI030159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 24 Apr 2017 12:31:35 -0400 Received: from MISOUT7MSGHUBAH.ITServices.sbc.com (MISOUT7MSGHUBAH.itservices.sbc.com [130.9.129.152]) by mlpi408.sfdc.sbc.com (RSA Interceptor) for ; Mon, 24 Apr 2017 16:31:09 GMT Received: from MISOUT7MSGUSRCG.ITServices.sbc.com ([169.254.7.29]) by MISOUT7MSGHUBAH.ITServices.sbc.com ([130.9.129.152]) with mapi id 14.03.0319.002; Mon, 24 Apr 2017 12:31:09 -0400 From: "HANSEN, TONY L" To: "jmap@ietf.org" Thread-Topic: [Jmap] Submission: options for github issue Thread-Index: AQHSvQbMhkECnRTPeECyUCEQUCF1gaHU2yWA///bJwA= Date: Mon, 24 Apr 2017 16:31:08 +0000 Message-ID: <14DCEF5C-CB51-442B-9A35-B64F37ECD1B4@att.com> References: <1492997737.3312553.953738776.7D27901C@webmail.messagingengine.com> <43747FEE-5EBE-4F89-BE13-94701F88A5BA@fugue.com> <4A4B1A7AC839999470A6D83C@caldav.corp.apple.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.110.241.72] Content-Type: multipart/alternative; boundary="_000_14DCEF5CCB51442B9A35B64F37ECD1B4attcom_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-24_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1704240282 Archived-At: Subject: Re: [Jmap] Submission: options for github issue X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 16:31:46 -0000 --_000_14DCEF5CCB51442B9A35B64F37ECD1B4attcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhdCBoYXMgY2VydGFpbmx5IGFsd2F5cyBiZWVuIG15IHByZWZlcnJlZCB3YXkgb2Ygc2VlaW5n IEJDQ3MgaGFuZGxlZC4NCg0KICAgICAgICAgICAgICAgIFRvbnkgSGFuc2VuDQoNCkZyb206IEpt YXAgPGptYXAtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIEdyZW4gRWxsaW90IDxmYXRr dWR1QGdtYWlsLmNvbT4NCkRhdGU6IE1vbmRheSwgQXByaWwgMjQsIDIwMTcgYXQgMTA6NDMgQU0N ClRvOiBUZWQgTGVtb24gPG1lbGxvbkBmdWd1ZS5jb20+LCBDeXJ1cyBEYWJvbyA8Y3lydXNAZGFi b28ubmFtZT4sICJqbWFwQGlldGYub3JnIiA8am1hcEBpZXRmLm9yZz4NCkNjOiBBZHJpZW4gZGUg Q3JveSA8YWRyaWVuQHFiaWsuY29tPiwgQnJvbiBHb25kd2FuYSA8YnJvbmdAZmFzdG1haWwuZm0+ DQpTdWJqZWN0OiBSZTogW0ptYXBdIFN1Ym1pc3Npb246IG9wdGlvbnMgZm9yIGdpdGh1YiBpc3N1 ZQ0KDQpJIGhhdmUgd29ya2VkIG9uIGEgc2VydmVyIHRoYXQgZGlkIEJDQyBzcGxpdHRpbmcgLSBp LmUuIEEgc2VwYXJhdGUgbWVzc2FnZSB3YXMgc2VudCB0byBlYWNoIEJDQyB1c2VyIGluY2x1ZGlu ZyB0aGVpciBhZGRyZXNzIGluIHRoZSBCQ0MgaGVhZGVyIGFuZCBhIG1lc3NhZ2Ugc2VudCB0byBh bGwgdGhlIHJlc3QgZXhjbHVkaW5nIHRoZSBCQ0MgaGVhZGVyLg0K --_000_14DCEF5CCB51442B9A35B64F37ECD1B4attcom_ Content-Type: text/html; charset="utf-8" Content-ID: <0E9989F058CEAA4A9273EF60A721BDB9@LOCAL> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5tc29JbnMNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OkNhbGlicmkiPlRoYXQgaGFzIGNlcnRhaW5seSBhbHdheXMgYmVlbiBteSBwcmVmZXJyZWQgd2F5 IG9mIHNlZWluZyBCQ0NzIGhhbmRsZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2Fs aWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRvbnkgSGFuc2VuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj4NCjwvYj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+Sm1hcCAmbHQ7am1hcC1i b3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2YgR3JlbiBFbGxpb3QgJmx0O2ZhdGt1ZHVA Z21haWwuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5Nb25kYXksIEFwcmlsIDI0LCAyMDE3IGF0 IDEwOjQzIEFNPGJyPg0KPGI+VG86IDwvYj5UZWQgTGVtb24gJmx0O21lbGxvbkBmdWd1ZS5jb20m Z3Q7LCBDeXJ1cyBEYWJvbyAmbHQ7Y3lydXNAZGFib28ubmFtZSZndDssICZxdW90O2ptYXBAaWV0 Zi5vcmcmcXVvdDsgJmx0O2ptYXBAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5BZHJpZW4g ZGUgQ3JveSAmbHQ7YWRyaWVuQHFiaWsuY29tJmd0OywgQnJvbiBHb25kd2FuYSAmbHQ7YnJvbmdA ZmFzdG1haWwuZm0mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbSm1hcF0gU3VibWlzc2lv bjogb3B0aW9ucyBmb3IgZ2l0aHViIGlzc3VlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5JIGhhdmUg d29ya2VkIG9uIGEgc2VydmVyIHRoYXQgZGlkIEJDQyBzcGxpdHRpbmcgLSBpLmUuIEEgc2VwYXJh dGUgbWVzc2FnZSB3YXMgc2VudCB0byBlYWNoIEJDQyB1c2VyIGluY2x1ZGluZyB0aGVpciBhZGRy ZXNzIGluIHRoZSBCQ0MgaGVhZGVyIGFuZCBhIG1lc3NhZ2Ugc2VudCB0byBhbGwgdGhlIHJlc3Qg ZXhjbHVkaW5nDQogdGhlIEJDQyBoZWFkZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_14DCEF5CCB51442B9A35B64F37ECD1B4attcom_-- From nobody Mon Apr 24 09:59:10 2017 Return-Path: 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 094D8131879 for ; Mon, 24 Apr 2017 09:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 1y6hK3Ut1ouy for ; Mon, 24 Apr 2017 09:59:06 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFC3D131878 for ; Mon, 24 Apr 2017 09:59:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id DBE296AD8062; Mon, 24 Apr 2017 12:59:03 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H9raRwnmM6Yu; Mon, 24 Apr 2017 12:59:03 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.44.178.52]) by daboo.name (Postfix) with ESMTPSA id 3ADC66AD8057; Mon, 24 Apr 2017 12:59:03 -0400 (EDT) Date: Mon, 24 Apr 2017 12:59:01 -0400 From: Cyrus Daboo To: "HANSEN, TONY L" , jmap@ietf.org Message-ID: In-Reply-To: <14DCEF5C-CB51-442B-9A35-B64F37ECD1B4@att.com> References: <1492997737.3312553.953738776.7D27901C@webmail.messagingengine.com> <43747FEE-5EBE-4F89-BE13-94701F88A5BA@fugue.com> <4A4B1A7AC839999470A6D83C@caldav.corp.apple.com> <14DCEF5C-CB51-442B-9A35-B64F37ECD1B4@att.com> X-Mailer: Mulberry/4.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=765 Archived-At: Subject: Re: [Jmap] Submission: options for github issue X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 16:59:08 -0000 Hi TONY, --On April 24, 2017 at 4:31:08 PM +0000 "HANSEN, TONY L" wrote: > That has certainly always been my preferred way of seeing BCCs handled. Actually what we ended up doing in Mulberry is add an option where a separate message could be sent to just the bcc recipients, but with additional text added to the top of the message. The text could be customized, but the default was a warning message: IMPORTANT! This message has been blind-carbon-copied to you. Please do not reply-to-all or forward this without permission of the author. This was deemed to reduce the chance of accidental reply-all by bcc recipients (in the absence of those recipients' email clients providing their own warning mechanism). -- Cyrus Daboo From nobody Mon Apr 24 12:25:46 2017 Return-Path: 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 5E3ED1294BD for ; Mon, 24 Apr 2017 12:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 2_N5rRjmbIC5 for ; Mon, 24 Apr 2017 12:25:42 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE350128B88 for ; Mon, 24 Apr 2017 12:25:42 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id y33so122789306qta.2 for ; Mon, 24 Apr 2017 12:25:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Yp8gsH0YI03UvRvyH3Gwy+ORxHrj2b6X1l+WnOREzYs=; b=KuRNqHNnVElEbXphzc0whAwEB8SzZMKEKQHAs+5UEduLyapBu+7VYtGjrAcDVGAyQF JK0exmJeKvQJb/nU0MkgnpN0+paYJWBw4wyVurdDAlVF0+cY3bbwIMKoRyVjH+9IWM2u EN+TVycsJqpTUr+MetbQwtTfc4QxCunHYIv7epLBlXDn5tMtpl+wEf4wf9ojjZMw/hes Jdb4xoxKto9xmo/KYr/qVtKp/sdzqybYLt2cDmhQEPgPwuSla0aV9it4anRwmuHn1ZTK o5cvKuk8MJlZHqw1ZHb1PLc1W2Y82izqrv6Ud78BqNfu+pd3dmcD0ONRbSCEfkaNcgCi PT9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Yp8gsH0YI03UvRvyH3Gwy+ORxHrj2b6X1l+WnOREzYs=; b=FZhINfaHCQnxUIaQrCTYbVh83t2T2rI4cYD8tTsDMfiRU6cLx8rvvgSAnN1kTeIakM DYvL4j4EUnWs63Un+3SsjdBho/MNu/RAwLftvO26Tz2jXIYYjggoDD6XQP5rFLLxbQbn RmbWZRQVUNtzSO0fn2fur1IvuciS8mUWTtj3VU3Qz7RU7N6vTe0oma4ReC/4iL4+WQMC Cd/BUJ+q/E4S5X57YNmrhvXde0ORogbymhZ1FofudKRUN/6FtShCx7Fg8yerEYW4ImZu r2v1a9aFbDtBjtcr3gZxKVRQrqc0Ssd+9583kJK2EskJ/MKsw2w0pMbdsmsZ4urC9Uly 0p/Q== X-Gm-Message-State: AN3rC/6BkwmDsOJ60mwx4LwF9BQKuO6l8JEeQ9X47xLXYBKUf7wDqiy8 0nVgRkkF7nXA8xtMQ3Y= X-Received: by 10.200.53.66 with SMTP id z2mr26860526qtb.184.1493061941745; Mon, 24 Apr 2017 12:25:41 -0700 (PDT) Received: from macbook-pro-6.home.arpa (pool-108-31-94-75.washdc.fios.verizon.net. [108.31.94.75]) by smtp.gmail.com with ESMTPSA id n22sm2665399qkn.8.2017.04.24.12.25.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Apr 2017 12:25:40 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_F998A8B4-45DC-4036-89C6-63B12C032346" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 24 Apr 2017 15:25:40 -0400 In-Reply-To: <6319482c-e53f-4483-870b-844e23030f8c@gulbrandsen.priv.no> Cc: Cyrus Daboo , jmap@ietf.org To: Arnt Gulbrandsen References: <1492996915.3310412.953749536.0F1C8B46@webmail.messagingengine.com> <20170424014957.39235.qmail@ary.lan> <6319482c-e53f-4483-870b-844e23030f8c@gulbrandsen.priv.no> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Jmap] Address Validation (was Re: Submission) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 19:25:44 -0000 --Apple-Mail=_F998A8B4-45DC-4036-89C6-63B12C032346 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 24, 2017, at 12:14 PM, Arnt Gulbrandsen = wrote: > However, the question that I understood was asked upthread is roughly = "to which recipients has x been delivered already?", and for that = particular question an unbroken implementation chain is needed from = sender to recipient. I think even knowing that the MTA for the admin domain of the JMAP = server has successfully forwarded the message would be sufficient to be = equivalent in most cases. If someone does more, that's great, but best = is the enemy of good enough. --Apple-Mail=_F998A8B4-45DC-4036-89C6-63B12C032346 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Apr 24, 2017, at 12:14 PM, Arnt Gulbrandsen <arnt@gulbrandsen.priv.no> wrote:
However, the question that I understood = was asked upthread is roughly "to which recipients has x been delivered = already?", and for that particular question an unbroken implementation = chain is needed from sender to recipient.

I = think even knowing that the MTA for the admin domain of the JMAP server = has successfully forwarded the message would be sufficient to be = equivalent in most cases.   If someone does more, that's great, but = best is the enemy of good enough.

= --Apple-Mail=_F998A8B4-45DC-4036-89C6-63B12C032346-- From nobody Mon Apr 24 14:37:10 2017 Return-Path: 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 E920C1317F3 for ; Mon, 24 Apr 2017 14:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 eKkohb7HpqRi for ; Mon, 24 Apr 2017 14:37:05 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [122.56.26.1]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C6A0120227 for ; Mon, 24 Apr 2017 14:37:04 -0700 (PDT) Received: From [192.168.1.146] (unverified [192.168.1.146]) by SMTP Server [192.168.1.3] (WinGate SMTP Receiver v9.0.5 (Build 5926)) with SMTP id <0001028908@smtp.qbik.com>; Tue, 25 Apr 2017 09:37:01 +1200 From: "Adrien de Croy" To: "John R Levine" Cc: "jmap@ietf.org" Date: Mon, 24 Apr 2017 21:37:01 +0000 Message-Id: In-Reply-To: References: <1492996915.3310412.953749536.0F1C8B46@webmail.messagingengine.com> <20170424014957.39235.qmail@ary.lan> Reply-To: "Adrien de Croy" User-Agent: eM_Client/7.0.27943.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Jmap] Address Validation (was Re: Submission) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 21:37:08 -0000 ------ Original Message ------ From: "John R Levine" To: "Adrien de Croy" Cc: "jmap@ietf.org" Sent: 25/04/2017 1:43:23 AM Subject: Re: [Jmap] Address Validation (was Re: Submission) >>when I made the suggestion, I was imagining that although you can't do= =20 >>VRFY or EXPN or probe emails and yes this is for good reason, the=20 >>number of times I've had bounce messages a long time after submission=20 >>for problems such as NXDOMAIN, means the current system isn't very=20 >>good at even this. > >Once again, that's a change to SMTP and in this case a fairly large and= =20 >incompatible one. actually I didn't envisage this one going anywhere near SMTP in the=20 first instance. The JMAP server can easily do domain-part validation,=20 or any other validation available to it (address book lookup, security=20 policy whatever) and deny the recipient validation. > > >On all the mail systems I know, if you try to send mail at a domain=20 >that doesn't exist, it fails instantly. I've seen a lot delayed, especially when the initial submission server=20 forwards to another pre-configured "smarthost" which then delays it=20 further. Adrien >The problem is when you send mail to a domain that has an A record but=20 >no mail server. There's no way for a client system to tell a=20 >nonexistent mail server from one that crashed and will be back shortly.= =20 > Maybe the retry timeout should be less than the 4-5 days that RFC 5321= =20 >suggests, but that's a quality of implementation issue that has nothing= =20 >whatsoever to do with JMAP. > >Regards, >John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY >Please consider the environment before reading this e-mail.=20 >https://jl.ly > >_______________________________________________ >Jmap mailing list >Jmap@ietf.org >https://www.ietf.org/mailman/listinfo/jmap From nobody Mon Apr 24 14:38:16 2017 Return-Path: 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 B2C5013150C for ; Mon, 24 Apr 2017 14:38:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 jAeLgnkAtkfH for ; Mon, 24 Apr 2017 14:38:12 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [122.56.26.1]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27E44120227 for ; Mon, 24 Apr 2017 14:38:11 -0700 (PDT) Received: From [192.168.1.146] (unverified [192.168.1.146]) by SMTP Server [192.168.1.3] (WinGate SMTP Receiver v9.0.5 (Build 5926)) with SMTP id <0001028910@smtp.qbik.com>; Tue, 25 Apr 2017 09:38:08 +1200 From: "Adrien de Croy" To: "Ted Lemon" , "Cyrus Daboo" Cc: "jmap@ietf.org" , "Bron Gondwana" Date: Mon, 24 Apr 2017 21:38:09 +0000 Message-Id: In-Reply-To: <43747FEE-5EBE-4F89-BE13-94701F88A5BA@fugue.com> References: <1492997737.3312553.953738776.7D27901C@webmail.messagingengine.com> <43747FEE-5EBE-4F89-BE13-94701F88A5BA@fugue.com> Reply-To: "Adrien de Croy" User-Agent: eM_Client/7.0.27943.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MB1C548D5E-34AD-4B91-A100-99619BAFD6DF" Archived-At: Subject: Re: [Jmap] Submission: options for github issue X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 21:38:15 -0000 --------=_MB1C548D5E-34AD-4B91-A100-99619BAFD6DF Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable yes, the MUA could feasibly fairly easily fake up the BCC field for the=20 user interface based on envelope information. It could even do better, such as show status per recipient if it had=20 that information. ------ Original Message ------ From: "Ted Lemon" To: "Cyrus Daboo" Cc: "Adrien de Croy" ; "jmap@ietf.org" ;= =20 "Bron Gondwana" Sent: 25/04/2017 2:12:56 AM Subject: Re: [Jmap] Submission: options for github issue >On Apr 24, 2017, at 9:52 AM, Cyrus Daboo wrote: >>we may need to special Bcc headers even if the envelope is preserved -= =20 >>but then it because a little awkward because of the duplication of=20 >>information in two places. > >Except that the bcc header shouldn't be in the message in the first=20 >place, for privacy reasons. So either the message in the JMAP store=20 >is different than what was actually sent, or the Bcc info should _only_= =20 >be on the envelope. > >Of course, this requires the MUA to do some creative gymnastics to make= =20 >it all look good, but such is life. > --------=_MB1C548D5E-34AD-4B91-A100-99619BAFD6DF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

yes, the MUA could feasibly= fairly easily fake up the BCC field for the user interface based on envelo= pe information.

It could even do better, such= as show status per recipient if it had that information.


------ Original Message ------
From: "Ted Lemon" <mellon@fugue= .com>
To: "Cyrus Daboo" <cyrus@daboo.= name>
Cc: "Adrien de Croy" <adrien@qbi= k.com>; "jmap@ietf.org" <jmap@ie= tf.org>; "Bron Gondwana" <br= ong@fastmail.fm>
Sent: 25/04/2017 2:12:56 AM
Subject: Re: [Jmap] Submission: options for github issue
On Apr 24, 2017, at 9:52 AM, Cyrus Daboo <cyrus@daboo.name> wrote:
we= may need to special Bcc headers even if the envelope is preserved - but= then it because a little awkward because of the duplication of information= in two places.

Except that the bcc header shouldn't be in the message in the first= place, for privacy reasons. =C2=A0 So either the message in the JMAP store= is different than what was actually sent, or the Bcc info should _only_= be on the envelope.

Of course, this requires the MUA to do some creative gymnastics to= make it all look good, but such is life.

--------=_MB1C548D5E-34AD-4B91-A100-99619BAFD6DF-- From nobody Mon Apr 24 15:43:30 2017 Return-Path: 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 72DF2131953 for ; Mon, 24 Apr 2017 15:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 47Ra0iSzvvfc for ; Mon, 24 Apr 2017 15:43:27 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [122.56.26.1]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 141FB131954 for ; Mon, 24 Apr 2017 15:43:26 -0700 (PDT) Received: From [192.168.1.146] (unverified [192.168.1.146]) by SMTP Server [192.168.1.3] (WinGate SMTP Receiver v9.0.5 (Build 5926)) with SMTP id <0001028965@smtp.qbik.com>; Tue, 25 Apr 2017 10:43:24 +1200 From: "Adrien de Croy" To: "jmap@ietf.org" Date: Mon, 24 Apr 2017 22:43:24 +0000 Message-Id: Reply-To: "Adrien de Croy" User-Agent: eM_Client/7.0.27943.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MB798A9939-F3B3-442A-8A1E-927D711702DC" Archived-At: Subject: [Jmap] Best vs Good enough - adoption of JMAP X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 22:43:29 -0000 --------=_MB798A9939-F3B3-442A-8A1E-927D711702DC Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable On the topic of best vs good enough. I agree they are perhaps opposed,=20 you could say that good enough is the enemy of best however, since once=20 you have something that is good enough, your incentive to do any better=20 is greatly diminished. However, we are up against several obstacles when it comes to adoption=20 of JMAP. 1. Server authors won't want to add support unless there are clients 2. Client authors won't want to add support unless there are servers 3. Client or server authors won't want to add support unless they can=20 make things significantly better for mail users. 4. We are losing customers to alternate messaging systems. If our target is just going to end up providing no benefits to users=20 over what we already have with IMAP+SMTP, then nobody will bother. Where it gets interesting for me personally at least is if we can push=20 the boundary of mail experience. In many cases this can be done in the=20 MUA but in some cases it requires support from the protocols. I hear the arguments that the more complex we make the spec, the less=20 likely it will be implemented, at least correctly. I'm not a fan of=20 complexity either, and neither of my suggestions do I consider to be=20 particularly complex. My argument is that if the design doesn't hold out a carrot for better=20 mail experience for users, then nobody will bother, and we're wasting=20 our time here, which would be a shame because we have the potential to=20 achieve a lot here. At the moment, there is a benefit on the table, mostly being the ability= =20 to only require configuration of access to 1 service (that's if JMAP=20 does submission). I believe we should be looking for opportunities to make mail the best=20 experience possible, come up with ideas, and we may decided to defer=20 some or not implement others, but we should keep them in mind so that=20 perhaps we don't close off the path to some of them. We don't need=20 another protocol that is hamstrung by lack of foresight. there are plenty of ideas around, look at the competition. Cheers Adrien --------=_MB798A9939-F3B3-442A-8A1E-927D711702DC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On the topic of best vs good enough. =C2=A0I= agree they are perhaps opposed, you could say that good enough is the enem= y of best however, since once you have something that is good enough, your= incentive to do any better is greatly diminished.

However, we are up against several obstacles when it comes to adoption= of JMAP.

1. Server authors won't want to add= support unless there are clients
2. Client authors won't want= to add support unless there are servers
3. Client or server auth= ors won't want to add support unless they can make things significantly = better for mail users.
4. We are losing customers to alternate= messaging systems.

If our target is just going= to end up providing no benefits to users over what we already have with= IMAP+SMTP, then nobody will bother.

Where it= gets interesting for me personally at least is if we can push the boundary= of mail experience. =C2=A0In many cases this can be done in the MUA but= in some cases it requires support from the protocols.

I hear the arguments that the more complex we make the spec, the = less likely it will be implemented, at least correctly. I'm not a fan of= complexity either, and neither of my suggestions do I consider to be parti= cularly complex.

My argument is that if the desi= gn doesn't hold out a carrot for better mail experience for users, then = nobody will bother, and we're wasting our time here, which would be a shame= because we have the potential to achieve a lot here.

At the moment, there is a benefit on the table, mostly being the abil= ity to only require configuration of access to 1 service (that's if JMAP= does submission).

I believe we should be lookin= g for opportunities to make mail the best experience possible, come up with= ideas, and we may decided to defer some or not implement others, but we= should keep them in mind so that perhaps we don't close off the path to= some of them. =C2=A0We don't need another protocol that is hamstrung by= lack of foresight.

there are plenty of ideas= around, look at the competition.

Cheers

Adrien
--------=_MB798A9939-F3B3-442A-8A1E-927D711702DC-- From nobody Mon Apr 24 17:39:23 2017 Return-Path: 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 C15A013197B for ; Mon, 24 Apr 2017 17:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 MlTtBD4MOr4X for ; Mon, 24 Apr 2017 17:39:20 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27EC3126B72 for ; Mon, 24 Apr 2017 17:39:19 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v3P0dIVj029161 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 25 Apr 2017 00:39:19 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v3P0dHLe024889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 25 Apr 2017 00:39:18 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id v3P0dF0w001421; Tue, 25 Apr 2017 00:39:16 GMT Received: from [10.145.239.181] (/10.145.239.181) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 24 Apr 2017 17:39:15 -0700 From: "Chris Newman" To: "Adrien de Croy" Cc: "jmap@ietf.org" Date: Mon, 24 Apr 2017 17:39:12 -0700 Message-ID: <46F700A6-C2B1-488B-A8B4-6ACD45B03C31@oracle.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Subject: Re: [Jmap] Best vs Good enough - adoption of JMAP X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 00:39:22 -0000 On 24 Apr 2017, at 15:43, Adrien de Croy wrote: > On the topic of best vs good enough. This is a misleading dichotomy for an engineering discussion. My immediate response when you say "best" is "best for whom?" If you design the best possible protocol for end-user experience, it will place unreasonable requirements on servers and won't deploy. Good engineering involves tradeoffs, cost/benefit analysis, deployability analysis, extensibility design, etc. > I agree they are perhaps opposed, you could say that good enough is > the enemy of best however, since once you have something that is good > enough, your incentive to do any better is greatly diminished. > > However, we are up against several obstacles when it comes to adoption > of JMAP. > > 1. Server authors won't want to add support unless there are clients > 2. Client authors won't want to add support unless there are servers > 3. Client or server authors won't want to add support unless they can > make things significantly better for mail users. 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. > 4. We are losing customers to alternate messaging systems. > > If our target is just going to end up providing no benefits to users > over what we already have with IMAP+SMTP, then nobody will bother. > > Where it gets interesting for me personally at least is if we can push > the boundary of mail experience. In many cases this can be done in > the MUA but in some cases it requires support from the protocols. > > I hear the arguments that the more complex we make the spec, the less > likely it will be implemented, at least correctly. I'm not a fan of > complexity either, and neither of my suggestions do I consider to be > particularly complex. > > My argument is that if the design doesn't hold out a carrot for better > mail experience for users, then nobody will bother, and we're wasting > our time here, which would be a shame because we have the potential to > achieve a lot here. > > At the moment, there is a benefit on the table, mostly being the > ability to only require configuration of access to 1 service (that's > if JMAP does submission). > > I believe we should be looking for opportunities to make mail the best > experience possible, come up with ideas, and we may decided to defer > some or not implement others, but we should keep them in mind so that > perhaps we don't close off the path to some of them. We don't need > another protocol that is hamstrung by lack of foresight. > > there are plenty of ideas around, look at the competition. Email is the most widely deployed multi-vendor messaging system on the Internet. The major value of doing JMAP as a standard is to get multi-vendor deployment. A walled garden will always have features that an open multi-vendor system can't achieve (simply for privacy reasons). Yes, we should look at the features that are popular in walled garden messaging systems and do a cost/benefit analysis. If the cost is low and benefit is high, let's consider it. But if the cost is high or the feature will involve a lot of careful design work and is outside the charter scope, then you'll get opposition to adding that feature to the JMAP base spec. A multi-vendor standard needs to support both small and large deployments and support both cloud and on-premises deployments. There are hundreds of deployed IMAP and Submission server implementations on the Internet and JMAP will deploy a lot faster if it "plays well" with those implementations. And by "play well", I mean it can be added to an existing deployment without major infrastructure changes. 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. Suppose we remove the "outbox" model from JMAP and replace it with a submission command with envelope extensions. Now suppose we want to require JMAP servers to support BINARYMIME submission (and/or append) as a boon to JMAP submission client authors? 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). Want to have the JMAP submission command handle both the \Sent folder copy and the Submission without duplicate data transmission? I think we need to do that. Want to have the base JMAP submission or append command include IMAP CATENATE functionality (assemble a message including server-stored attachments in order to "forward without download")? I have no problem with that. There's quite a bit of room to improve the JMAP client author's experience without forcing major infrastructure changes. The WG exists to discuss the cost/benefit of various features and make an engineering judgment call. The proposals that are most likely to succeed are ones that can be implemented in a JMAP proxy without significant changes to IMAP/Submission. And proposals that would require reasonably straightforward or well-understood IMAP/Submission extensions are worth considering (e.g., if I need a per-user unique/persistent message identifier for IMAP, I understand the implications of that). So the opposition you're seeing is to making fundamental architecture changes to the Internet email infrastructure or adding complex new mandatory features that have a poor cost/benefit. If you want to do that, go design your own walled-garden protocol. But if you want to make the client author experience better in a way that can deploy across email systems from multiple vendors, then this is the place to make and refine proposals that strike a deployable balance. Sorry for the meta-discussion, but I got the impression you had misinterpreted opposition to infrastructure disruption as opposition to improving the client experience. - Chris From nobody Mon Apr 24 17:54:19 2017 Return-Path: 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 9992F131982 for ; Mon, 24 Apr 2017 17:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 ASCfpZf79Cwv for ; Mon, 24 Apr 2017 17:54:16 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84DC213197E for ; Mon, 24 Apr 2017 17:54:16 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id y63so103110659qkd.1 for ; Mon, 24 Apr 2017 17:54:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=YAd+6AkcfNy0cV7fSsg8vlVWZccRMwrw9n2ua+6Qf8I=; b=v2CADQE6H52ys5Wlc+cmfHLMLHPTXyL0EmsxUR/N0tT77YJHurlN7R0pDvg19ESmoj pyqUCMI1oh4kEJFr5Glk4ch/6AUh/azmzmgxjdPfWYBO8KBk+BXMt5gnTbmOCZDUjkI5 QiPCpIYSDkoIlL9F8AqoeAtPS0tpYXCOl7aw8wKilOlFokkDHSXrxuYUHUy/TodbcPXy vtLD065i3hnLJzSnYFvK+muQt82X84CH7N/6Tjkzn66dsVNLi5nZFzD20J6pvma8Nx/r DhzY2VNscWPt3mxf8lwxo06dLo4VbECBAeP196E0IrY+GifpVuqkzP5pG3IgwrwgoBRo AiNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=YAd+6AkcfNy0cV7fSsg8vlVWZccRMwrw9n2ua+6Qf8I=; b=j1xZxJs/fv6Ljfc96Tjd8YO3mDQoH8/GyUpBftQujvcNzoQluG9nn+Ijz0vmm4O1M1 7SLs3BgF63eljtzpjSG/HFI8WrnvK8H46xsrZMjf860cs3OCixMtuQXbAvFMC4uwzdlP +XHVsQOj9A9lquQuP2/6+PaFQ4iuhhMAZ8XBVic5AlH9TNxMqzqHtwX3KkwtIixPSAnF cSxKaBZqejE8CiGxMToHOYPvNM0wGYzogWduWgDBKWmAvCVBQ95ZlkT9vsmlQePyUghU UXPMSTzao1evDPgWmnteDm167ZeHDERhhb+3Lh3jU+pg9iZTAaQuDADyiiVFWjEMsWwQ wyPg== X-Gm-Message-State: AN3rC/6F7mP7YOzOId8NyuIThoR6/q72i5lZc19fsV1swSukNYWqUlNI DRE5KFqd7y1GrqOzmUw= X-Received: by 10.55.54.202 with SMTP id d193mr6138005qka.160.1493081655678; Mon, 24 Apr 2017 17:54:15 -0700 (PDT) Received: from macbook-pro-6.home.arpa (pool-108-31-94-75.washdc.fios.verizon.net. [108.31.94.75]) by smtp.gmail.com with ESMTPSA id s71sm14083205qkl.58.2017.04.24.17.54.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Apr 2017 17:54:14 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_E20CA368-0D87-4286-AA07-3517579F5EAB" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 24 Apr 2017 20:54:13 -0400 In-Reply-To: <46F700A6-C2B1-488B-A8B4-6ACD45B03C31@oracle.com> Cc: Adrien de Croy , "jmap@ietf.org" To: Chris Newman References: <46F700A6-C2B1-488B-A8B4-6ACD45B03C31@oracle.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Jmap] Best vs Good enough - adoption of JMAP X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 00:54:19 -0000 --Apple-Mail=_E20CA368-0D87-4286-AA07-3517579F5EAB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 24, 2017, at 8:39 PM, Chris Newman = 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? --Apple-Mail=_E20CA368-0D87-4286-AA07-3517579F5EAB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Apr 24, 2017, at 8:39 PM, Chris Newman <chris.newman@oracle.com> 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?

= --Apple-Mail=_E20CA368-0D87-4286-AA07-3517579F5EAB-- From nobody Mon Apr 24 18:02:33 2017 Return-Path: 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 31E34131987 for ; Mon, 24 Apr 2017 18:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 s3PkYmgzrDZI for ; Mon, 24 Apr 2017 18:02:30 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2010713197B for ; Mon, 24 Apr 2017 18:02:30 -0700 (PDT) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v3P12QIo014359 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 25 Apr 2017 01:02:26 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v3P12QA9012463 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 25 Apr 2017 01:02:26 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v3P12Q3B015081; Tue, 25 Apr 2017 01:02:26 GMT Received: from [10.145.239.181] (/10.145.239.181) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 24 Apr 2017 18:02:25 -0700 From: "Chris Newman" To: "Bron Gondwana" Cc: jmap@ietf.org Date: Mon, 24 Apr 2017 18:02:24 -0700 Message-ID: In-Reply-To: <1492998899.3316920.953769616.254C9CBD@webmail.messagingengine.com> References: <1492998899.3316920.953769616.254C9CBD@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Subject: Re: [Jmap] Draft messages - mutability X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 01:02:31 -0000 On 23 Apr 2017, at 18:54, Bron Gondwana wrote: > I'm starting this thread to discuss the mutability of fields in > isDraft: true messages. > > In Cyrus IMAPd right now, we create the "MSGID" field as the sha1 of > the "RFC822" raw message content as would be delivered over IMAP. > That's lovely for non-draft messages (except that we'll probably > switch to using blake2 for new messages soon). > > But it sucks for drafts, because it means that every time you edit a > draft, you get a new MSGID. Futhermore, you can't edit a draft via > JMAP with ['setMessages', {update:{}}] because the fields that you > want to edit are immutable, so instead you are doing ['setMessages', > {create:{all the fields}, destroy: ["the old id"]}] which is a > horrible way to edit drafts. > > A somewhat similar discussion is happening over in CalConnect around > the idea of saving draft ICALENDAR items on a server without sending > out scheduling messages about them until they have finished being > edited. > > So the question for JMAP becomes: is a "draft message" the same > datatype as a "message", or do you handle them completely differently? > Clearly you want to show them in-thread with the message they are in > reply to in an interface, but how does that look over the protocol? I see a lot of cost and no benefit to making a draft a different datatype from a message. Now adding a command with semantics like draft-brandt-imap-replace to JMAP may be quite reasonable. - Chris From nobody Mon Apr 24 18:05:41 2017 Return-Path: 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 40FB6131988 for ; Mon, 24 Apr 2017 18:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 TiYH7OBzjxwW for ; Mon, 24 Apr 2017 18:05:37 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [122.56.26.1]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B876131987 for ; Mon, 24 Apr 2017 18:05:36 -0700 (PDT) Received: From [192.168.1.146] (unverified [192.168.1.146]) by SMTP Server [192.168.1.3] (WinGate SMTP Receiver v9.0.5 (Build 5926)) with SMTP id <0001029025@smtp.qbik.com>; Tue, 25 Apr 2017 13:05:35 +1200 From: "Adrien de Croy" To: "Chris Newman" Cc: "jmap@ietf.org" Date: Tue, 25 Apr 2017 01:05:35 +0000 Message-Id: In-Reply-To: <46F700A6-C2B1-488B-A8B4-6ACD45B03C31@oracle.com> References: <46F700A6-C2B1-488B-A8B4-6ACD45B03C31@oracle.com> Reply-To: "Adrien de Croy" User-Agent: eM_Client/7.0.27943.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Jmap] Best vs Good enough - adoption of JMAP X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 01:05:40 -0000 ------ Original Message ------ From: "Chris Newman" To: "Adrien de Croy" Cc: "jmap@ietf.org" Sent: 25/04/2017 12:39:12 PM Subject: Re: [Jmap] Best vs Good enough - adoption of JMAP >On 24 Apr 2017, at 15:43, Adrien de Croy wrote: >>On the topic of best vs good enough. > >This is a misleading dichotomy for an engineering discussion. My=20 >immediate response when you say "best" is "best for whom?" If you=20 >design the best possible protocol for end-user experience, it will=20 >place unreasonable requirements on servers and won't deploy. Good=20 >engineering involves tradeoffs, cost/benefit analysis, deployability=20 >analysis, extensibility design, etc. > >>I agree they are perhaps opposed, you could say that good enough is=20 >>the enemy of best however, since once you have something that is good=20 >>enough, your incentive to do any better is greatly diminished. >> >>However, we are up against several obstacles when it comes to adoption= =20 >>of JMAP. >> >>1. Server authors won't want to add support unless there are clients >>2. Client authors won't want to add support unless there are servers >>3. Client or server authors won't want to add support unless they can=20 >>make things significantly better for mail users. > >I've never heard of a mail client author implementing a feature before=20 >the server exists. Server authors are the ones who have moved first in=20 >the email community. there are a few vendors who provide both, and they are in a special=20 situation where they can really push the envelope on features because=20 they have control of both sides of the conversation. This is why Google was able to push SPDY, and why HTTP/2 is like it is. >So the key to JMAP deployability is to make it not unnecessarily=20 >hostile to server developers (like myself) and server operators. But I=20 >agree we also want JMAP to provide significant benefits to client=20 >authors and their users. There are many design choices JMAP can make=20 >that meet all of these goals. > >>4. We are losing customers to alternate messaging systems. >> >>If our target is just going to end up providing no benefits to users=20 >>over what we already have with IMAP+SMTP, then nobody will bother. >> >>Where it gets interesting for me personally at least is if we can push= =20 >>the boundary of mail experience. In many cases this can be done in=20 >>the MUA but in some cases it requires support from the protocols. >> >>I hear the arguments that the more complex we make the spec, the less=20 >>likely it will be implemented, at least correctly. I'm not a fan of=20 >>complexity either, and neither of my suggestions do I consider to be=20 >>particularly complex. >> >>My argument is that if the design doesn't hold out a carrot for better= =20 >>mail experience for users, then nobody will bother, and we're wasting=20 >>our time here, which would be a shame because we have the potential to= =20 >>achieve a lot here. >> >>At the moment, there is a benefit on the table, mostly being the=20 >>ability to only require configuration of access to 1 service (that's=20 >>if JMAP does submission). >> >>I believe we should be looking for opportunities to make mail the best= =20 >>experience possible, come up with ideas, and we may decided to defer=20 >>some or not implement others, but we should keep them in mind so that=20 >>perhaps we don't close off the path to some of them. We don't need=20 >>another protocol that is hamstrung by lack of foresight. >> >>there are plenty of ideas around, look at the competition. > >Email is the most widely deployed multi-vendor messaging system on the=20 >Internet. This one is rapidly moving. I'd agree it's most widely deployed, but I=20 don't know if it's most widely used. Since mobiles have overtaken=20 desktops as internet endpoints, I'd imagine Facebook messaging is=20 getting close in terms of number of people using it, if it hasn't=20 surpassed mail already. >The major value of doing JMAP as a standard is to get multi-vendor=20 >deployment. A walled garden will always have features that an open=20 >multi-vendor system can't achieve (simply for privacy reasons). Yes, we= =20 >should look at the features that are popular in walled garden messaging= =20 >systems and do a cost/benefit analysis. If the cost is low and benefit=20 >is high, let's consider it. But if the cost is high or the feature will= =20 >involve a lot of careful design work and is outside the charter scope,=20 >then you'll get opposition to adding that feature to the JMAP base=20 >spec. understood. I'm not proposing creating any more walled gardens. =20 However walled gardens with open protocols, and which avoid privacy=20 issues are fair game. >A multi-vendor standard needs to support both small and large=20 >deployments and support both cloud and on-premises deployments. There=20 >are hundreds of deployed IMAP and Submission server implementations on=20 >the Internet and JMAP will deploy a lot faster if it "plays well" with=20 >those implementations. And by "play well", I mean it can be added to an= =20 >existing deployment without major infrastructure changes. yes. It has to be deployable on all levels (e.g. meet policy and=20 commercial requirements as well as technical). > >For example, if I'm operating a million-user deployment, it's critical=20 >to monitor the mail queues for problems. The proposed JMAP "outbox"=20 >model means I'm adding one million new mail queues to the monitoring=20 >system. That's a major deployment change; and thus a significant=20 >barrier to JMAP deployability. > >Suppose we remove the "outbox" model from JMAP and replace it with a=20 >submission command with envelope extensions. Now suppose we want to=20 >require JMAP servers to support BINARYMIME submission (and/or append)=20 >as a boon to JMAP submission client authors? Well that's no problem=20 >from an infrastructure viewpoint as long as the JMAP server is=20 >permitted to perform the base64-encoding on binary message parts at=20 >submission/append time in order to remain compatible with IMAP mail=20 >stores (and non-BINARYMIME submission servers). Want to have the JMAP=20 >submission command handle both the \Sent folder copy and the Submission= =20 >without duplicate data transmission? I think we need to do that. Want=20 >to have the base JMAP submission or append command include IMAP=20 >CATENATE functionality (assemble a message including server-stored=20 >attachments in order to "forward without download")? I have no problem=20 >with that. Yes, I think clients need to be able to build the message on the server,= =20 in binary. > >There's quite a bit of room to improve the JMAP client author's=20 >experience without forcing major infrastructure changes. I guess my point here is that I don't believe we can force major=20 infrastructure changes even if we decided we wanted to. I didn't think=20 I was proposing anything that would do that. >The WG exists to discuss the cost/benefit of various features and make=20 >an engineering judgment call. The proposals that are most likely to=20 >succeed are ones that can be implemented in a JMAP proxy without=20 >significant changes to IMAP/Submission. And proposals that would=20 >require reasonably straightforward or well-understood IMAP/Submission=20 >extensions are worth considering (e.g., if I need a per-user=20 >unique/persistent message identifier for IMAP, I understand the=20 >implications of that). OK, so we have an IMAP server and SMTP server. I'm intending (if it=20 works out) to implement JMAP, but I would be making whatever changes=20 needed to the IMAP and SMTP servers required to provide whatever added=20 benefit I can give to a user by way of JMAP. I don't really think of JMAP as a proxy. I think of it on an even par=20 with IMAP + SUBMIT servers. I'm not intending to proxy JMAP back via=20 IMAP, we abstracted the store from IMAP in any case (so it could be=20 shared with POP3), so the JMAP server would be another user of that mail= =20 store. > >So the opposition you're seeing is to making fundamental architecture=20 >changes to the Internet email infrastructure or adding complex new=20 >mandatory features that have a poor cost/benefit. If you want to do=20 >that, go design your own walled-garden protocol. But if you want to=20 >make the client author experience better in a way that can deploy=20 >across email systems from multiple vendors, then this is the place to=20 >make and refine proposals that strike a deployable balance. > >Sorry for the meta-discussion, but I got the impression you had=20 >misinterpreted opposition to infrastructure disruption as opposition to= =20 >improving the client experience. No problem, I appreciate your response. Maybe I haven't been clear in my suggestions, but I'm not proposing=20 making all these suggestions mandatory, but I am keen that they remain=20 possible, and not get prohibited by some design decisions now. Being able to do something prior to submission relating to submission as= =20 a general concept I think has some interesting possibilities, and early=20 mail verification I think has a lot more value than some are seeing. =20 When you've had your umpteenth mail bounced that took you hours to=20 write, you end up wishing something told you the mail address was bad at= =20 the beginning. I still think as a general principle, that failing fast and early is=20 preferable to slow and late. that's where the email address=20 pre-validation idea came from. As for the other one of message notification. I also think keeping the=20 human in the loop has all manner of benefits. With HTTP it may be=20 easier to see, since people hit the refresh button over and over if the=20 page doesn't load. We built a variant of Chrome that worked with our=20 HTTP status response codes during AV scanning, and the usability was=20 greatly improved. I think as a general principle, keeping people informed of what's going=20 on, at a much greater level than we currently do, can save people a lot=20 of wasted effort and worry. Cheers Adrien > > > - Chris From nobody Mon Apr 24 18:35:39 2017 Return-Path: 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 D021D131998 for ; Mon, 24 Apr 2017 18:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=DhbOk7uU; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=J0CrDNZt 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 jkhfG50BNTVL for ; Mon, 24 Apr 2017 18:35:35 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 589BE120726 for ; Mon, 24 Apr 2017 18:35:35 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id B0D5520F41; Mon, 24 Apr 2017 21:35:34 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Mon, 24 Apr 2017 21:35:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=X+t6Brws9wWymBzwlHiBI0IOLTXfh oYU3og0nZJRY70=; b=DhbOk7uU4hcQyiX8tbY/nk2S0AdCZb68uX+r1zjEI2D1X KLneiS3jkDBdhIBxgs7LrZ8XfD7dQ4P+kwDdKLmKz5fHWXBc59fsspI7+V2jmuf1 J8IUJvFYapH7wQf8K87H0xDa3YouHjCN2W1ME1Hs5PXiv8J81XziZPK2+OnTNFkk vAG0a0MZp+XQgyQXKaL49gSs52ynYNOFPvU74iJ9G1HoJoQm2doarRT5zxjvJwjs UYDgDr9NgB9SEdjEXHfzbUUh/MpUzJSSsDDZ/GnAUwvqUfCqFYSev+DXg1W4r6Jg Qx1binVw4hli9rLIjMruqIiw4JufYym0+Z5epICgw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=X+t6Br ws9wWymBzwlHiBI0IOLTXfhoYU3og0nZJRY70=; b=J0CrDNZt4aV84kCH7axeW0 dB2Lp0FYy5jjwBMQuO3F48V+BMlaDCQZg33ST0vp04NdAauisGHISrxB5nU5xXVU 5PVBJjf1T80afW92F8QgjKQ3nIeUTjB5lsha0dzX34x6+tnr0jwC56EYkuImJd5l 0IbYZk4TJrzgwoP/kiuO93dJ2iHwa5iRWBZysa8Sqilt7DnWc6frpXBKlfiEZXbL 9gJOgjclkAFBmviN1LjAvzQ0dzbPk8puuswm9JnH7IkUlygxCkXZrXTZLpw19muT GnY1TbL2Iq8+pEbEFs5E2oj30Dc8OPf0ZKs47w+0Ke06L7bV7gc2C5dOhh5OOP3g == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 6BC3AE2342; Mon, 24 Apr 2017 21:35:34 -0400 (EDT) Message-Id: <1493084134.2830550.955039432.5403CAFB@webmail.messagingengine.com> From: Neil Jenkins To: Chris Newman , Bron Gondwana Cc: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_149308413428305501" X-Mailer: MessagingEngine.com Webmail Interface - ajax-77cb7ee4 References: <1492998899.3316920.953769616.254C9CBD@webmail.messagingengine.com> In-Reply-To: Date: Tue, 25 Apr 2017 11:35:34 +1000 Archived-At: Subject: Re: [Jmap] Draft messages - mutability X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 01:35:37 -0000 This is a multi-part message in MIME format. --_----------=_149308413428305501 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Tue, 25 Apr 2017, at 11:02 AM, Chris Newman wrote: > I see a lot of cost and no benefit to making a draft a different > datatype from a message. I don't see any benefit to making it a different data type. However, what we currently have is that, like IMAP, a message is immutable except for flags/mailboxes. This is a pain for client authors trying to keep track of a single draft as it is saved through multiple revisions (especially when the user has multiple clients). One possible solution to this is to simply say any message with the \Draft flag set is fully mutable (while keeping the same id). I think we would also want the server to enforce that a message cannot be changed from/to draft state after creation. If it starts a draft it stays a draft, or vice versa. >From a protocol perspective, since most messages won't be drafts (with a normal user) you still get the efficiency of immutable messages (you only have to refetch flags/mailboxes, not the whole message) for most of the messages in the mail store. But it will be easier for MUAs to handle drafts, and particularly allow for a much better experience when editing the same draft message across multiple devices. Neil. --_----------=_149308413428305501 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Tue, 25 Apr 2017, at 11:02 AM, Chris Newman wrote:
I see a lot of cost and no benefit to making a draft a different
datatype from a message.

I don't see any benefit to making it a different data type. However, what we currently have is that, like IMAP, a message is immutable except for flags/mailboxes. This is a pain for client authors trying to keep track of a single draft as it is saved through multiple revisions (especially when the user has multiple clients). One possible solution to this is to simply say any message with the \Draft flag set is fully mutable (while keeping the same id). I think we would also want the server to enforce that a message cannot be changed from/to draft state after creation. If it starts a draft it stays a draft, or vice versa.

From a protocol perspective, since most messages won't be drafts (with a normal user) you still get the efficiency of immutable messages (you only have to refetch flags/mailboxes, not the whole message) for most of the messages in the mail store. But it will be easier for MUAs to handle drafts, and particularly allow for a much better experience when editing the same draft message across multiple devices.

Neil.
--_----------=_149308413428305501-- From nobody Mon Apr 24 18:41:59 2017 Return-Path: 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 F39C41277BB for ; Mon, 24 Apr 2017 18:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 peeGrXLDYZ4m for ; Mon, 24 Apr 2017 18:41:56 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACD45131998 for ; Mon, 24 Apr 2017 18:41:56 -0700 (PDT) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v3P1fsQI006784 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 25 Apr 2017 01:41:55 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.13.8/8.14.4) with ESMTP id v3P1fsvM023026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 25 Apr 2017 01:41:54 GMT Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v3P1fpso030857; Tue, 25 Apr 2017 01:41:51 GMT Received: from [10.145.239.181] (/10.145.239.181) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 24 Apr 2017 18:41:51 -0700 From: "Chris Newman" To: "Ted Lemon" Cc: "Adrien de Croy" , "jmap@ietf.org" Date: Mon, 24 Apr 2017 18:41:49 -0700 Message-ID: In-Reply-To: References: <46F700A6-C2B1-488B-A8B4-6ACD45B03C31@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Subject: Re: [Jmap] Best vs Good enough - adoption of JMAP X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 01:41:58 -0000 On 24 Apr 2017, at 17:54, Ted Lemon wrote: > On Apr 24, 2017, at 8:39 PM, Chris Newman > 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. Yes, this has been a common problem in design of mail protocols. If you have any ideas on how to keep the mail client authors who think more about UX issues engaged in the JMAP standardization debate, I'd love to hear them. >> 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.) True, if the WG finds rough consensus around the outbox model despite my objections, then my implementation will have an always-empty outbox as that's the only way to implement it without infrastructure disruption. I'd prefer a JMAP design that allows me to provide delivery status UX without infrastructure disruption. >> 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? Pretty much everything deployed is 8-bit clean in message bodies (UTF-8 does not need to be encoded for IMAP). But a lot of the email infrastructure is not binary clean (e.g., a lot of mail stores will not store binary MIME with NUL octets). Now we do have BINARYMIME/CHUNKING extensions for SMTP as well as binary append and fetch extensions for IMAP. So I have no problem with JMAP requiring support for binary MIME on the wire; but it shouldn't say anything that prevents the server from converting to 8-bit MIME (using base64 to encode parts with NUL octets) for storage purposes. - Chris From nobody Mon Apr 24 18:47:11 2017 Return-Path: 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 6CA171319A4 for ; Mon, 24 Apr 2017 18:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=Sdgu2tMK; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=FI1FiDWG 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 G-J0EL-wIqvP for ; Mon, 24 Apr 2017 18:47:08 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B1B81319A2 for ; Mon, 24 Apr 2017 18:47:08 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id A705820B5B for ; Mon, 24 Apr 2017 21:47:07 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Mon, 24 Apr 2017 21:47:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=YVZRBvtwOXz2itL+nwgtKoHLmGqE7 X7r+uhIn5TiEiA=; b=Sdgu2tMKujyRIyX60BnPYPbj0NnkIG4zN5F0M85tuOEva DeFBCCMNN4H2/Cvue85NglXFqH2USVpoO9ZI5KAGeGriQEysBmbWYzUfb4stE2J0 6bPwQuHbAQwp1ZTCRAWD/QwnisDuFws1UOmdvLEBTY3KSfoJQv0aTDSH3BaLfGeQ Yzfrq9BZBANXJcrzPWew5XZxL34AOSklC4v7q+i47qJ59eAbinDk7OF1em0NVNoK qJLD/OeoC9HxTvdbVkMVyahTDxvpDNd91YUEgRSR62eKdu0kYVeQFva7aW4Sq/DT XojTPcA7gij39MTs7QYNkHdVdNg/9GpCQPNFTcXPg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=YVZRBv twOXz2itL+nwgtKoHLmGqE7X7r+uhIn5TiEiA=; b=FI1FiDWGAduR2s9etMOh9O 7QbsdmsCu3irpWxSlsaB2pANVBGs12H6V2qef1uSXTus5LUixirxLOnBVECs8ZeS zMwqhWTt1/E4nuHuV42z8b/lc1XclMiWDuzFr8dJ6fhLsMNGVsyA6fMlD9z4wSsX gbSTI9AyYPJl2vLsW/YErtvpNoI2LZkjMmb4KGN83TqsRtdOw9Cy+lnM+KR04giV f8yLEziF5vZoG9aUCEpsidWZsIu1WrIzXB1xvOUo5syKf2bnH3RHYAAAsE594MH1 fKkz5lxtBp2wFeLLPXCxwAcs6x0BGr9v2otNOH8lYE9o1cuk3X8kxO2rJWjABVvg == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 726D0E2342; Mon, 24 Apr 2017 21:47:07 -0400 (EDT) Message-Id: <1493084827.2833415.955057496.1E8325CA@webmail.messagingengine.com> From: Neil Jenkins To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_149308482728334154" X-Mailer: MessagingEngine.com Webmail Interface - ajax-77cb7ee4 In-Reply-To: References: <46F700A6-C2B1-488B-A8B4-6ACD45B03C31@oracle.com> Date: Tue, 25 Apr 2017 11:47:07 +1000 Archived-At: Subject: Re: [Jmap] Best vs Good enough - adoption of JMAP X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 01:47:09 -0000 This is a multi-part message in MIME format. --_----------=_149308482728334154 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Tue, 25 Apr 2017, at 11:41 AM, Chris Newman wrote: > Yes, this has been a common problem in design of mail > protocols. If you> have any ideas on how to keep the mail client authors who think more > about UX issues engaged in the JMAP standardization debate, I'd love > to> hear them. As it happens I lead UX for FastMail, and the other proposed co-editor of the JMAP Mail spec is also a client author. So I'm hopeful that JMAP may do slightly better in this regards than some previous protocol design work. Neil. --_----------=_149308482728334154 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Tue, 25 Apr 2017, at 11:41 AM, Chris Newman wrote:
Yes, this has been a common problem in design of mail protocols. If you
have any ideas on how to keep the mail client authors who think more
about UX issues engaged in the JMAP standardization debate, I'd love to
hear them.

As it happens I lead UX for FastMail, and the other proposed co-editor of the JMAP Mail spec is also a client author. So I'm hopeful that JMAP may do slightly better in this regards than some previous protocol design work.

Neil.
--_----------=_149308482728334154-- From nobody Mon Apr 24 19:00:10 2017 Return-Path: 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 B581F1319A7 for ; Mon, 24 Apr 2017 19:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 YRCGsYvEvqZP for ; Mon, 24 Apr 2017 19:00:06 -0700 (PDT) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C949127977 for ; Mon, 24 Apr 2017 19:00:06 -0700 (PDT) Received: by mail-pg0-x22b.google.com with SMTP id v1so9238643pgv.1 for ; Mon, 24 Apr 2017 19:00:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yX13gmjDBb3X9xbv3rBRZSeSrnaV7ELbokPpPnnBcwE=; b=HNCwOjRdxR6qCc7N5BiQxFwkiDkiFPrS8r/uDGmM62ZabKZHnCPbJHoKmKZIH09PzM qfFi7ltKAKPX4dI/tZ7RJnSLVZyB5i8e0Tly9O7C3LVV8ezExzhJSujROaWl0l+92t2m RKooqT6R1hx/lMh9H0NcKJj/Q6LEl/HyLqKiTEwBZRZHt6aRXYEmc+h+e4TOh0y4htAT qwLx64bjdPB+lc+JeWSa3yDdMD8Z3pKoI9yBmDCdT3KJTEN4Fjw+gsOeEuiks1I6mF5B XQ+tlEd2Rziyy2OILhK1nwc53ZDCoK5pI9ikrd6D1FviAAYCpFUVkGhRkXGivRgsKrv3 Knzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=yX13gmjDBb3X9xbv3rBRZSeSrnaV7ELbokPpPnnBcwE=; b=Mgeeapw47+vRP7jjB1iTZd9dQvUQgoRw+1HjIJFvUFiLm4PTXQGbweQFZqabg3/3+N +/fNN/mjPOxdcEYRhPPeaDzonSM/g0tPYO/ROx1gKkexM6Ij5CIfDZPdv9OZcuXhTeTf OatVQzKX3/Ed4GW9fFTAFSUqMcmx/KXNI3cCa3iOZr7s2rnNld6SC9F9ROmRlslVN7Ob sX9zL8RYyiB4TQ5dwPXLRmv+uiueQoKNQv0iYwS7t7vVsigHtuxLEcXwM5/nL5uueMCe cwcoYBGx+q+7MzvPwv2ADenqH8F/gpgNnDSFXUotocQc142+YhEgJNFD6MemM3Eh5vq7 aI+w== X-Gm-Message-State: AN3rC/4kwqqnpyn4D8KeAoiikQXWcYbQt8ueTv38P7YCaUg3wWsy0dRt 4LW92okBL5LI7NmSS3AQCoHHL/JtFw== X-Received: by 10.98.210.2 with SMTP id c2mr27692470pfg.83.1493085606119; Mon, 24 Apr 2017 19:00:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.187.66 with HTTP; Mon, 24 Apr 2017 19:00:05 -0700 (PDT) Received: by 10.100.187.66 with HTTP; Mon, 24 Apr 2017 19:00:05 -0700 (PDT) In-Reply-To: <1493084134.2830550.955039432.5403CAFB@webmail.messagingengine.com> References: <1492998899.3316920.953769616.254C9CBD@webmail.messagingengine.com> <1493084134.2830550.955039432.5403CAFB@webmail.messagingengine.com> From: Ted Lemon Date: Mon, 24 Apr 2017 22:00:05 -0400 Message-ID: To: Neil Jenkins Cc: jmap@ietf.org, Bron Gondwana , Chris Newman Content-Type: multipart/alternative; boundary=001a114676b22c1aa9054df415e5 Archived-At: Subject: Re: [Jmap] Draft messages - mutability X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 02:00:09 -0000 --001a114676b22c1aa9054df415e5 Content-Type: text/plain; charset=UTF-8 If drafts are mutable, the implication is that synchronization based on message ID can't happen without something like a version modifier. At which point why not make every message versioned? On Apr 24, 2017 9:35 PM, "Neil Jenkins" wrote: > On Tue, 25 Apr 2017, at 11:02 AM, Chris Newman wrote: > > I see a lot of cost and no benefit to making a draft a different > datatype from a message. > > > I don't see any benefit to making it a different data type. However, what > we currently have is that, like IMAP, a message is immutable except for > flags/mailboxes. This is a pain for client authors trying to keep track of > a single draft as it is saved through multiple revisions (especially when > the user has multiple clients). One possible solution to this is to simply > say any message with the \Draft flag set is fully mutable (while keeping > the same id). I think we would also want the server to enforce that a > message cannot be changed from/to draft state after creation. If it starts > a draft it stays a draft, or vice versa. > > From a protocol perspective, since most messages won't be drafts (with a > normal user) you still get the efficiency of immutable messages (you only > have to refetch flags/mailboxes, not the whole message) for most of the > messages in the mail store. But it will be easier for MUAs to handle > drafts, and particularly allow for a much better experience when editing > the same draft message across multiple devices. > > Neil. > > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap > > --001a114676b22c1aa9054df415e5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If drafts are mutable, the implication is that synchroniz= ation based on message ID can't happen without something like a version= modifier. At which point why not make every message versioned?

On Apr 24, 2017 9:35 PM= , "Neil Jenkins" <neilj@= fastmail.com> wrote:
On Tue, 25 Apr 2017, at 11:02 AM, Chris Newman wrote:
I see a lot of cost and no benefit to making= a draft a different
datatype from a message.

I don't see any benefit to making it a different data type. Howeve= r, what we currently have is that, like IMAP, a message is immutable except= for flags/mailboxes. This is a pain for client authors trying to keep trac= k of a single draft as it is saved through multiple revisions (especially w= hen the user has multiple clients). One possible solution to this is to sim= ply say any message with the \Draft flag set is fully mutable (while keepin= g the same id). I think we would also want the server to enforce that a mes= sage cannot be changed from/to draft state after creation. If it starts a d= raft it stays a draft, or vice versa.

From a protocol perspective, since most messages won't be drafts (= with a normal user) you still get the efficiency of immutable messages (you= only have to refetch flags/mailboxes, not the whole message) for most of t= he messages in the mail store. But it will be easier for MUAs to handle dra= fts, and particularly allow for a much better experience when editing the s= ame draft message across multiple devices.

Neil.

_______________________________________________
Jmap mailing list
Jmap@ietf.org
https://www.ietf.org/mailman/listinfo/jmap

--001a114676b22c1aa9054df415e5-- From nobody Mon Apr 24 19:07:25 2017 Return-Path: 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 E1283131991 for ; Mon, 24 Apr 2017 19:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 ls96Y6kQX73k for ; Mon, 24 Apr 2017 19:07:22 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCD2D1204DA for ; Mon, 24 Apr 2017 19:07:21 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v3P27K2h026102 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 25 Apr 2017 02:07:20 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v3P27KtR016769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 25 Apr 2017 02:07:20 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v3P27JMu012556; Tue, 25 Apr 2017 02:07:19 GMT Received: from [10.145.239.181] (/10.145.239.181) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 24 Apr 2017 19:07:19 -0700 From: "Chris Newman" To: "Adrien de Croy" Cc: "jmap@ietf.org" Date: Mon, 24 Apr 2017 19:07:17 -0700 Message-ID: <364FFD2E-57D2-4C0D-A2BF-53363147D9B9@oracle.com> In-Reply-To: References: <46F700A6-C2B1-488B-A8B4-6ACD45B03C31@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Subject: Re: [Jmap] Best vs Good enough - adoption of JMAP X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 02:07:24 -0000 On 24 Apr 2017, at 18:05, Adrien de Croy wrote: > I don't really think of JMAP as a proxy. I think of it on an even par > with IMAP + SUBMIT servers. I'm not intending to proxy JMAP back via > IMAP, we abstracted the store from IMAP in any case (so it could be > shared with POP3), so the JMAP server would be another user of that > mail store. Our JMAP-like component was initially implemented as a peer access protocol to our IMAP & POP servers using our internal store API. At one point we deliberately converted it to be an IMAP proxy. That turned out to be a very good architecture decision for our product. It improved our mail store reliability and scalability by providing greater functional separation and a better deployment model. So I view JMAP as an IMAP/Submit proxy based on that experience. POP3 is such a simple protocol that it's not worth the effort to convert it from an internal API consumer to a proxy, but if I started a design from scratch, I'd implement POP3 as a proxy to an IMAP backend. - Chris From nobody Mon Apr 24 19:18:19 2017 Return-Path: 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 BF6A6131991 for ; Mon, 24 Apr 2017 19:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 ASeH53IHFH-7 for ; Mon, 24 Apr 2017 19:18:16 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91BAE12785F for ; Mon, 24 Apr 2017 19:18:16 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v3P2ID8h001566 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 25 Apr 2017 02:18:13 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v3P2ICAn000911 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 25 Apr 2017 02:18:13 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v3P2IC9b014105; Tue, 25 Apr 2017 02:18:12 GMT Received: from [10.145.239.181] (/10.145.239.181) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 24 Apr 2017 19:18:12 -0700 From: "Chris Newman" To: "Neil Jenkins" Cc: "Bron Gondwana" , jmap@ietf.org Date: Mon, 24 Apr 2017 19:18:10 -0700 Message-ID: In-Reply-To: <1493084134.2830550.955039432.5403CAFB@webmail.messagingengine.com> References: <1492998899.3316920.953769616.254C9CBD@webmail.messagingengine.com> <1493084134.2830550.955039432.5403CAFB@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Subject: Re: [Jmap] Draft messages - mutability X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 02:18:18 -0000 On 24 Apr 2017, at 18:35, Neil Jenkins wrote: > On Tue, 25 Apr 2017, at 11:02 AM, Chris Newman wrote: >> I see a lot of cost and no benefit to making a draft a different >> datatype from a message. > > I don't see any benefit to making it a different data type. However, > what we currently have is that, like IMAP, a message is immutable > except > for flags/mailboxes. This is a pain for client authors trying to keep > track of a single draft as it is saved through multiple revisions > (especially when the user has multiple clients). One possible solution > to this is to simply say any message with the \Draft flag set is fully > mutable (while keeping the same id). I think we would also want the > server to enforce that a message cannot be changed from/to draft state > after creation. If it starts a draft it stays a draft, or vice versa. Why is it important to keep the same ID when modifying a draft? The approach draft-brandt-imap-replace uses is to include the new ID in the response to the modification operation. The replace model seems a good way to preserve the immutable property (which is very helpful for quick synchronization) while providing the client an interface that looks just like editing an existing message. - Chris From nobody Mon Apr 24 19:18:30 2017 Return-Path: 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 88066131991 for ; Mon, 24 Apr 2017 19:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=He3x3RXl; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=jJVolFBj 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 KkBYSTrRMgTn for ; Mon, 24 Apr 2017 19:18:26 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C545C12785F for ; Mon, 24 Apr 2017 19:18:25 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id 3AEA220C85; Mon, 24 Apr 2017 22:18:25 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Mon, 24 Apr 2017 22:18:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=msGldNA3cD0UD/zizg4MSy5/GpWUD d4948c8kIJ9QZM=; b=He3x3RXlO+0UjCB5EIbTKPow0TsGPhxo/eAnI4dJtb7BZ NCCUCnQew36VOntUnPmUe1P3lFCW6Gpv4+QvUNP47WKXr0BjqDF2uzNAoaNbL8b0 cdnXhpIG7AORl2PrmT3oiaPZZ9vzfjipCQbgmdruUvImk4ATpnqL7TemB+k2XUFV faDASz+ecr4JkhHWsv055pMtBPqz6nGJZl9NvAXGAY3Zg4FGsBYeFIrIddaZr2PU ffDCW12NwgvzOTh+G43N53KWumYUXc2GCnHEN8D2tj4ZSx9834kvbsLgtkzmeI17 7tw2CsnBq0lEfxe1PhzxHZmogo7wAt1iwRk8n6DZw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=msGldN A3cD0UD/zizg4MSy5/GpWUDd4948c8kIJ9QZM=; b=jJVolFBj5aF4xKxxCarj3b snms/9MBcEO9SpWlgY7v4XxGmOPlpk58mqCxygmokQ0IJqHEDIxP2pFm9egqp9Ab xsvSdyHehrI8Wmq2fFXFvmU1tRsdJJgJfxuvMvBnk8pz2xk1DBgR7ZyT1g/vyL+H q5Xl38T1AB9+8MMRV22m5a+mdVkR5+nDkYLiDwVwexbu2DdYf3oI/Gtq01R/86kR 4Qvv7L3ovjqyiMkIfzktjzIfAM+K04Vmvyo9IwSZLJdeGbS8jXkfpn4MSnnLTxrJ XUlzuuA/PI/yANyTfWEWHBCyAy1viY8T1jTTDLA+SL0WmUNtKVfGHwaHDW0/tcCA == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id EC0BBE23C7; Mon, 24 Apr 2017 22:18:24 -0400 (EDT) Message-Id: <1493086704.2870249.955076016.66A059E7@webmail.messagingengine.com> From: Neil Jenkins To: Ted Lemon Cc: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_149308670428702491" X-Mailer: MessagingEngine.com Webmail Interface - ajax-71880675 Date: Tue, 25 Apr 2017 12:18:24 +1000 In-Reply-To: References: <1492998899.3316920.953769616.254C9CBD@webmail.messagingengine.com> <1493084134.2830550.955039432.5403CAFB@webmail.messagingengine.com> Archived-At: Subject: Re: [Jmap] Draft messages - mutability X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 02:18:29 -0000 This is a multi-part message in MIME format. --_----------=_149308670428702491 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Tue, 25 Apr 2017, at 12:00 PM, Ted Lemon wrote: > If drafts are mutable, the implication is that synchronization based > on message ID can't happen without something like a version modifier. > At which point why not make every message versioned? I'm not sure I fully understand your question; every message is already versioned (like the IMAP CONDSTORE modseq) so that you can efficiently synchronise changes. There is a well-defined model of data synchronisation which is used across all data types in JMAP. A client can request the list of ids of a type (let's say Messages) which have changed since the client's current state. It can then decide which of those messages it wants to fetch, and what information it needs to fetch for each one. In the case of non-drafts, it only needs to fetch flags/mailboxes. If drafts are mutable, then for any draft message it has it would need to redownload the entire message. This is the trade-off I was talking about in my previous post. Neil. --_----------=_149308670428702491 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Tue, 25 Apr 2017, at 12:00 PM, Ted Lemon wrote:
If drafts are mutable, the implication is that synchronization based on message ID can't happen without something like a version modifier. At which point why not make every message versioned?

I'm not sure I fully understand your question; every message is already versioned (like the IMAP CONDSTORE modseq) so that you can efficiently synchronise changes.

There is a well-defined model of data synchronisation which is used across all data types in JMAP. A client can request the list of ids of a type (let's say Messages) which have changed since the client's current state. It can then decide which of those messages it wants to fetch, and what information it needs to fetch for each one. In the case of non-drafts, it only needs to fetch flags/mailboxes. If drafts are mutable, then for any draft message it has it would need to redownload the entire message. This is the trade-off I was talking about in my previous post.

Neil.
--_----------=_149308670428702491-- From nobody Mon Apr 24 19:21:20 2017 Return-Path: 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 531C51319B1 for ; Mon, 24 Apr 2017 19:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 WWGWYXI4Aszh for ; Mon, 24 Apr 2017 19:21:17 -0700 (PDT) Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4FC51319B2 for ; Mon, 24 Apr 2017 19:21:17 -0700 (PDT) Received: by mail-pg0-x236.google.com with SMTP id 63so21142539pgh.0 for ; Mon, 24 Apr 2017 19:21:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=a/sDMcEK0ysbX93y9IvJsEX173CL2MHidGB3Wu5/a9c=; b=1TReka2KhYGO180VC30+bImKnk0W4FHJlhx2aEoii/8wjKSiq5m7b+toQYHQW3j9gE PR33mg8XYiq+GgUlHiQdUv33cBYD6IQC+8q8Y9jBi2nCkA/irdWf/iFCtmzpNJZDoTLc aMbOD0Von4Q2KpgIAV8K7tOG77acifMHZ/xMFLwNQ/hBAk8VGXWJttJLIQXGjvmGJOKz 4Z4cdaw+c1ujfjVp8s2FRAVp+PfS5VuVx7pqnesxERJAIQXnck7ezWBgDwn8UeDDK5VI A7/AsjRUeLmfH31aSdPanNjFttq7hIt2PzKtzJ+tzAac4lPjyJxyJYx74mFKDK7ML0rt CJmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=a/sDMcEK0ysbX93y9IvJsEX173CL2MHidGB3Wu5/a9c=; b=L5qjSeYGL59raojndwfm/vx1PtYVVCidQ7VdqZaPbTYSYPAFYmFZPgK1WLkqSp+gK2 bPIRcXdDEPjxhmg2BJKsZJW53Kfv1EnCAEacejVlvNi7U9kshIdxU+UisqdrmE++dzb1 BTfmpdNoDcaRoGzVZOAjg6x7Wg34xQwiCU9KdqLxP2+loA78qh8T92H+W4jzXdKme0cI HOgstU1pniC6i3vMJ+AMx8WlSnWXiavIF2Ta1V7nCCz/9mt5OcuaxmA2m5eBuZ+x9Rmg F9z9mB4S3VyO6jBXPHmKSXGzeSYitu23sGCV1qODx/A3xaJvliDtNAl+sbTw4OpLPKU+ kx6g== X-Gm-Message-State: AN3rC/5SDw2YzuiN0kR9PkSHiUFEDt+3IbEAmgtzEr+2Qz/b6DS/bZng JiqJz80c5U7M0hIrueGTbRFG4EYLEQ== X-Received: by 10.98.210.2 with SMTP id c2mr27727732pfg.83.1493086877404; Mon, 24 Apr 2017 19:21:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.187.66 with HTTP; Mon, 24 Apr 2017 19:21:16 -0700 (PDT) Received: by 10.100.187.66 with HTTP; Mon, 24 Apr 2017 19:21:16 -0700 (PDT) In-Reply-To: <1493086704.2870249.955076016.66A059E7@webmail.messagingengine.com> References: <1492998899.3316920.953769616.254C9CBD@webmail.messagingengine.com> <1493084134.2830550.955039432.5403CAFB@webmail.messagingengine.com> <1493086704.2870249.955076016.66A059E7@webmail.messagingengine.com> From: Ted Lemon Date: Mon, 24 Apr 2017 22:21:16 -0400 Message-ID: To: Neil Jenkins Cc: jmap@ietf.org Content-Type: multipart/alternative; boundary=001a114676b2f25f6b054df46060 Archived-At: Subject: Re: [Jmap] Draft messages - mutability X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 02:21:19 -0000 --001a114676b2f25f6b054df46060 Content-Type: text/plain; charset=UTF-8 That seems okay as long as there isn't a ton of churn in the drafts folder. On Apr 24, 2017 10:18 PM, "Neil Jenkins" wrote: > On Tue, 25 Apr 2017, at 12:00 PM, Ted Lemon wrote: > > If drafts are mutable, the implication is that synchronization based on > message ID can't happen without something like a version modifier. At which > point why not make every message versioned? > > > I'm not sure I fully understand your question; every message is already > versioned (like the IMAP CONDSTORE modseq) so that you can efficiently > synchronise changes. > > There is a well-defined model of data synchronisation which is used across > all data types in JMAP. A client can request the list of ids of a type > (let's say Messages) which have changed since the client's current state. > It can then decide which of those messages it wants to fetch, and what > information it needs to fetch for each one. In the case of non-drafts, it > only needs to fetch flags/mailboxes. If drafts are mutable, then for any > draft message it has it would need to redownload the entire message. This > is the trade-off I was talking about in my previous post. > > Neil. > --001a114676b2f25f6b054df46060 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
That seems okay as long as there isn't a ton of churn= in the drafts folder.=C2=A0

On Apr 24, 2017 10:18 PM, "Neil Jenkins" <neilj@fastmail.com> wrote:
On Tue, 25 Apr 2017, at 12:00 PM, Ted Lemon wrote:
If drafts are mutable, the implication is th= at synchronization based on message ID can't happen without something l= ike a version modifier. At which point why not make every message versioned= ?

I'm not sure I fully understand your question; every message is al= ready versioned (like the IMAP CONDSTORE modseq) so that you can efficientl= y synchronise changes.

There is a well-defined model of data synchronisation which is used ac= ross all data types in JMAP. A client can request the list of ids of a typ= e (let's say Messages) which have changed since the client's curren= t state. It can then decide which of those messages it wants to fetch, and = what information it needs to fetch for each one. In the case of non-drafts,= it only needs to fetch flags/mailboxes. If drafts are mutable, then for an= y draft message it has it would need to redownload the entire message. This= is the trade-off I was talking about in my previous post.

Neil.
--001a114676b2f25f6b054df46060-- From nobody Mon Apr 24 19:24:47 2017 Return-Path: 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 41810131991 for ; Mon, 24 Apr 2017 19:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=rbToARNm; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=OxO7WNQ+ 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 9mYaIGe9Xxs8 for ; Mon, 24 Apr 2017 19:24:44 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D43361319AC for ; Mon, 24 Apr 2017 19:24:43 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id 4ADB120CC1; Mon, 24 Apr 2017 22:24:43 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Mon, 24 Apr 2017 22:24:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=g6fgFt0yZlcn2S13BjQIOISGq4ZlJ cDfKvQjRJ7Mvvo=; b=rbToARNmRQezoIrV3ojfL4f2J+Sd8G7PPoTmD4heq10k+ 9xjH4gvx3nCjaVWQD304vb32roQbDEFswh2+5tfuYsQ5xycSN3q1l/4k/tsR34mi r3I6H/Qp4vO5ngSUWIxN6G//ZU3kgLF5QuYHein+NQZJjqfLRV+XbyJE0C/ERbO8 hzfrV7uOOoyXE3HbiDw+65/79y54x/X9Ab+JiHtGMPXqU1rhfEOZ0T50aAib+nbC au+obEhxn0d8Mk8ZLWRKQ4s18+9Nk0DC7XOsZX2lRdJCxCqbgVDClY5MxTKJV19v vdJSlug61d608nOtC59Cpus0bA/L8ilzbRXy6fLdQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=g6fgFt 0yZlcn2S13BjQIOISGq4ZlJcDfKvQjRJ7Mvvo=; b=OxO7WNQ+AYXefZeGWMMk7M He/wCOpOYN110FaY9BjxWnB/XCON5UcFtl6DyJy1BLQT2AGIzGl+huMpponPU9+p zIwTdzOhI9ZZtvL8xbAJYgj1pfJvU5/TYAunUjN5Mv+Bgpiv7LC72MLNLFAf8mwN /nHhMBqMGvyTzv3XxmYbikExqqYhZn8rtF3l1+v5n+BS8UD+c4VyV9wFltFW1gap p8AK7DwKMSHLgD61WruLwvLZhVXxl166jJunpZg06go47rv2j054vcJDB2K2sJiU FDq3lYnH8MxdwrNwSRc4l2hZozk0158e0z6gx8nOtofJvB9MbgnXKIuXiD8qweNA == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 0B6A4E23C7; Mon, 24 Apr 2017 22:24:43 -0400 (EDT) Message-Id: <1493087082.2882732.955078288.61343C16@webmail.messagingengine.com> From: Neil Jenkins To: Chris Newman Cc: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_149308708228827320" X-Mailer: MessagingEngine.com Webmail Interface - ajax-71880675 In-Reply-To: References: <1492998899.3316920.953769616.254C9CBD@webmail.messagingengine.com> <1493084134.2830550.955039432.5403CAFB@webmail.messagingengine.com> Date: Tue, 25 Apr 2017 12:24:42 +1000 Archived-At: Subject: Re: [Jmap] Draft messages - mutability X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 02:24:45 -0000 This is a multi-part message in MIME format. --_----------=_149308708228827320 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Tue, 25 Apr 2017, at 12:18 PM, Chris Newman wrote: > Why is it important to keep the same ID when modifying a draft? > The approach draft-brandt-imap-replace uses is to include the new > ID in the> response to the modification operation. That's great if you're only using one client to edit the draft. But consider the following scenario: 1. I start a draft on my laptop. I'm not finished, it's still open on the screen and I just put the laptop to sleep.2. I continue editing on my phone. Maybe I finish and send it or maybe I don't.3. I go back to my laptop, which immediately resyncs with the server to find out what's changed. Now with immutable messages, all my laptop MUA can see is that the draft has been deleted from the server, but this might just mean there's a newer version of the draft. I can see the newer draft but can't know for sure it's an update to the one I have open or not. So I can either resave the draft that's open (which could cause a duplicate old draft to "reappear" in the Drafts mailbox), or I can just delete it and hope for the best (and the user can reopen the new draft if they still hadn't finished sending). With mutable messages, I would see there's an update to the current message I have open. If I know the user's last changes were saved to the server I would just fetch the update and immediately show this instead. If the user has made other changes then I know we have a split and I can prompt the user what they want to do. It's a much better user experience. Neil. --_----------=_149308708228827320 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Tue, 25 Apr 2017, at 12:18 PM, Chris Newman wrote:
Why is it important to keep the same ID when modifying a draft?
The approach draft-brandt-imap-replace uses is to include the new ID in the
response to the modification operation.

That's great if you're only using one client to edit the draft. But consider the following scenario:

1. I start a draft on my laptop. I'm not finished, it's still open on the screen and I just put the laptop to sleep.
2. I continue editing on my phone. Maybe I finish and send it or maybe I don't.
3. I go back to my laptop, which immediately resyncs with the server to find out what's changed.

Now with immutable messages, all my laptop MUA can see is that the draft has been deleted from the server, but this might just mean there's a newer version of the draft. I can see the newer draft but can't know for sure it's an update to the one I have open or not. So I can either resave the draft that's open (which could cause a duplicate old draft to "reappear" in the Drafts mailbox), or I can just delete it and hope for the best (and the user can reopen the new draft if they still hadn't finished sending).

With mutable messages, I would see there's an update to the current message I have open. If I know the user's last changes were saved to the server I would just fetch the update and immediately show this instead. If the user has made other changes then I know we have a split and I can prompt the user what they want to do. It's a much better user experience.

Neil.
--_----------=_149308708228827320-- From nobody Mon Apr 24 22:37:27 2017 Return-Path: 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 AD1F81319B7 for ; Mon, 24 Apr 2017 22:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.718 X-Spam-Level: X-Spam-Status: No, score=-2.718 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=dWb7n7TV; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Aio6+QhK 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 feSYhP2SokZC for ; Mon, 24 Apr 2017 22:37:24 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 700421318F4 for ; Mon, 24 Apr 2017 22:37:24 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id E3A9B20A69 for ; Tue, 25 Apr 2017 01:37:23 -0400 (EDT) Received: from web4 ([10.202.2.214]) by compute6.internal (MEProxy); Tue, 25 Apr 2017 01:37:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=qD7wcZ7hTkeyqTtwq92K8WOQy65dQ WrjStRgNyNhNkc=; b=dWb7n7TV4e5xrdoRQBz6cXfw6iNjpmKZAx8YkOkTLrlcn Dw45v6903gwwPmyAA2gM/sCT979pTcXOlZiuLeYrnr6M8XXP1dRl+WI7k6VyoVWX f0G/Vwvj/CEgJkRnPnYwLut1hepq7ZluZaAmyYloukDcrhObfyRpEowogwSCPblh IHpOlNuvfhbIy4hc+dk9/f+ArADumHuWHLC86Eg0I3HXn36X6xPBW10napT2+J2p HEvK7QDsBXzPZtKPZhDOVcfNHam61Nk9UVswsSNSFaYu43YN+T2SIZFlGTrMd2/W DZfcXGywhWhO9O9DEjVYqwIdGViLj9cITvf+JJDhA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=qD7wcZ 7hTkeyqTtwq92K8WOQy65dQWrjStRgNyNhNkc=; b=Aio6+QhKWvELHIq+2E2RF/ zDgDB6p4duoJYROsBVUijMqHMLcrexi65aa3Yg8vbgO5f5ZtVHJyBOmMcN2i0DyW Jn/Kg37Dp2yaxtaLnGKE0gfodoxr/NpfHIgtHeesyM7dNHqubKVbZcrdH5TqMzb4 7S5qBUWCOMwm9qeoHXST2GZwaKR2PkO+VqCc3LoXnEkw318CyOPRkNPCD+rgHV5p Oy6Q663eCNVcUk41LpslSpfr7Lvy1ryiU+iKxXtV3tJNomtxkZUpmxBbLK/QjqY5 HjHg3RdH96tW/e7EcQJY+cd9vAW7WdnfWtIXaCndyLJBkiuGEJEmJewTEy3fVqMA == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id BD713BAB6F; Tue, 25 Apr 2017 01:37:23 -0400 (EDT) Message-Id: <1493098643.3019530.955182168.23368BB4@webmail.messagingengine.com> From: Bron Gondwana To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_149309864330195300" X-Mailer: MessagingEngine.com Webmail Interface - ajax-29d47332 Date: Tue, 25 Apr 2017 15:37:23 +1000 References: <1492996915.3310412.953749536.0F1C8B46@webmail.messagingengine.com> <20170424014957.39235.qmail@ary.lan> <6319482c-e53f-4483-870b-844e23030f8c@gulbrandsen.priv.no> In-Reply-To: Archived-At: Subject: Re: [Jmap] Address Validation (was Re: Submission) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 05:37:27 -0000 This is a multi-part message in MIME format. --_----------=_149309864330195300 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Tue, 25 Apr 2017, at 05:25, Ted Lemon wrote: > On Apr 24, 2017, at 12:14 PM, Arnt Gulbrandsen > wrote:>> However, the question that I understood was asked upthread is roughly >> "to which recipients has x been delivered already?", and for that >> particular question an unbroken implementation chain is needed from >> sender to recipient.> > I think even knowing that the MTA for the admin domain of the JMAP > server has successfully forwarded the message would be sufficient to > be equivalent in most cases. If someone does more, that's great, but > best is the enemy of good enough. Our eventual plan for FastMail is to annotate every sent message with the delivery log lines that were generated for each recipient at the edge of our infrastructure as the messages get sent. Self service facilities are nice to have. Bron. -- Bron Gondwana brong@fastmail.fm --_----------=_149309864330195300 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Tue, 25 Apr 2017, at 05:25, Ted Lemon wrote:
On Apr 24, 2017, at 12:14 PM, Arnt Gulbrandsen <arnt@gulbrandsen.priv.no> wrote:
However, the question that I understood was asked upthread is roughly "to which recipients has x been delivered already?", and for that particular question an unbroken implementation chain is needed from sender to recipient.

I think even knowing that the MTA for the admin domain of the JMAP server has successfully forwarded the message would be sufficient to be equivalent in most cases.   If someone does more, that's great, but best is the enemy of good enough.

Our eventual plan for FastMail is to annotate every sent message with the delivery log lines that were generated for each recipient at the edge of our infrastructure as the messages get sent.  Self service facilities are nice to have.

Bron.

--
  Bron Gondwana
  brong@fastmail.fm


--_----------=_149309864330195300-- From nobody Mon Apr 24 22:51:40 2017 Return-Path: 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 1E32D1319C4 for ; Mon, 24 Apr 2017 22:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.718 X-Spam-Level: X-Spam-Status: No, score=-2.718 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=o+6mDA/J; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=eZoyzgl8 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 qJkLIOjsKL8Z for ; Mon, 24 Apr 2017 22:51:35 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58A08127011 for ; Mon, 24 Apr 2017 22:51:35 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 9EC3C209D7 for ; Tue, 25 Apr 2017 01:51:34 -0400 (EDT) Received: from web4 ([10.202.2.214]) by compute6.internal (MEProxy); Tue, 25 Apr 2017 01:51:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=It6Au3/NGSaZI15kSyv1BuLcSD/+d fmsRP5QUnZ/TWY=; b=o+6mDA/J+uAh8M9SWTHelcnHP57V5ofs/3vUshRkZdMDU 0wXjkl9uzAy4vfi/lk2UqgiwJEynbdOMQRR9huQV4ipntZbztTALcchPpnVkG2Cs QLnHiedliPyhDaLEf/Zs54c+JZLhV02JI/c6NSKwgrl6X1Es3QqWUPUHTV5GeW3P SVYoIpAp0EMLCYpWczQtl7+KXMD/HcoU4cVz/3lZTLK16Fv1r/sQ50s0m/Ysf2XU BMC66n+wSTPTs/bQtqTS2fj7JZmd8UkuJ2i9y95mhMDnXvIBkmG8EvxGENCftjl3 2mGiDq3fTzojCby/4Qcv0N9sXoNqzkp4bynG082XQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=It6Au3 /NGSaZI15kSyv1BuLcSD/+dfmsRP5QUnZ/TWY=; b=eZoyzgl8k3rnebQoInH/tB O5E7+koNC3nsWwyc+tigYzATtAzFrCiB3AgzSUXutbAzX/FWcWPL4cbckHvvKvrh slqKbj/JYerQZtZ9urXXhh282i0bYw32bKN2hxp038P+iu3gRF3UWIN7JORdM/dG ix1yh9cY2FH9lTKaZNVoyM7yPhBahnACE+zdjp3HhG9omd48sGjnqKcx4c4jYJHg 242l/id1dP3XQh3zU6zk8t53+XaL0YfEEKlT9mCdfCbeH0kirzJtwio28xnvmCLw qKMY20rcfDHgl9ZLknktY2SAtnBZfYvmI+mX7AdOZFnBNUrTcdqxR2mHH2KGEmSw == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 7F3A8BAB6F; Tue, 25 Apr 2017 01:51:34 -0400 (EDT) Message-Id: <1493099494.3022600.955184792.68A53782@webmail.messagingengine.com> From: Bron Gondwana To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_149309949430226001" X-Mailer: MessagingEngine.com Webmail Interface - ajax-29d47332 In-Reply-To: References: <46F700A6-C2B1-488B-A8B4-6ACD45B03C31@oracle.com> Date: Tue, 25 Apr 2017 15:51:34 +1000 Archived-At: Subject: Re: [Jmap] Best vs Good enough - adoption of JMAP X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 05:51:38 -0000 This is a multi-part message in MIME format. --_----------=_149309949430226001 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Tue, 25 Apr 2017, at 10:54, Ted Lemon wrote: > On Apr 24, 2017, at 8:39 PM, Chris Newman > 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 brong@fastmail.fm --_----------=_149309949430226001 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Tue, 25 Apr 2017, at 10:54, Ted Lemon wrote:
On Apr 24, 2017, at 8:39 PM, Chris Newman <chris.newman@oracle.com> 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:


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
  brong@fastmail.fm


--_----------=_149309949430226001-- From nobody Mon Apr 24 22:56:13 2017 Return-Path: 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 965971319CA for ; Mon, 24 Apr 2017 22:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=g7PwOW2/; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Y5l5bxYU 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 9BI0kH8TpgE8 for ; Mon, 24 Apr 2017 22:56:10 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 071411319BD for ; Mon, 24 Apr 2017 22:56:10 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 715A620A1F for ; Tue, 25 Apr 2017 01:56:09 -0400 (EDT) Received: from web4 ([10.202.2.214]) by compute6.internal (MEProxy); Tue, 25 Apr 2017 01:56:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=RRtFzSJaan1trxIEJIKMs4fOYCAwQ Ww2U4aCXuHiLEk=; b=g7PwOW2/ZHwQP0AvE3hi/0NX1q+ht0nlj/e22dWn6jLss P5qhkQqU6PKfWPTQauoKujjpqc62RBDmRynK+wusCLepT/CIjcSIYlj6nFFpRYnp KsLSZyQ7r6lmA0RCxZP7JXqRTlrYls1fB4pA3Ihjld2PjxScY9V0ITDjBP1SAgMF I+PVZjq41krK/cvs6gPvdqMESbasKi4EpmulvFqZmPmm5mftq/SE7p+q9LUyTsSJ 6fsl/zE1LNXd+oIvtibIA+PtGFpB8fFt5KDAsK9c+o0d0pRZXdnafqDH/7W9Z6N1 3LQCJrwVTtp+3bXzOz7F/8IuP0m/bLpWyoaQr5ZSA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=RRtFzS Jaan1trxIEJIKMs4fOYCAwQWw2U4aCXuHiLEk=; b=Y5l5bxYUWnsa04EClQw1pY f508/lETYLLYLbNGrWy0aOHBpmb8AWM6ZgxY6AafRPUOfsTA858X5MJSB8DMm0Yk lYJUb+R4NmW2gF5BZyfE9ptsSARfosKhs97VOoN9MLtXtgqO7z5/YSjwlbp3Q8sb Hqr0XsX1YhWlZb4NcE7tXrPtfjLbGoLMMnwKd7n7PWHQBVYGBKILGfKZpPsKloar 2enRA7POaYSS9DV+0IMLb3XHm5fdj1fibGDMlPQFyvFJnf8C8Bq4E1Aeabz+z4QC LyBiFGBRJJkcbVvq0c9jXnP6JTWzVLZXito3QbaqKHt/FJ5e3WzMy+sed38HNrQQ == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 4F66FBAB6F; Tue, 25 Apr 2017 01:56:09 -0400 (EDT) Message-Id: <1493099769.3023399.955193288.6D0312CC@webmail.messagingengine.com> From: Bron Gondwana To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-29d47332 Date: Tue, 25 Apr 2017 15:56:09 +1000 References: <46F700A6-C2B1-488B-A8B4-6ACD45B03C31@oracle.com> In-Reply-To: Archived-At: Subject: Re: [Jmap] Best vs Good enough - adoption of JMAP X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 05:56:12 -0000 On Tue, 25 Apr 2017, at 11:41, Chris Newman wrote: > True, if the WG finds rough consensus around the outbox model despite my > objections, then my implementation will have an always-empty outbox as > that's the only way to implement it without infrastructure disruption. > I'd prefer a JMAP design that allows me to provide delivery status UX > without infrastructure disruption. Ahh, I see you already replied with this. Yeah, always-empty outbox is my first plan too as a server implementer. It's what I did for the proxy, since it doesn't have reliable storage. The reason to hold email in the outbox temporarily is to implement both undo-send and delayed send, both of which are popular features in new mail clients. We'll definitely do outbox-as-queue at FastMail eventually. Bron. -- Bron Gondwana brong@fastmail.fm From nobody Tue Apr 25 00:15:36 2017 Return-Path: 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 6C755124D6C for ; Tue, 25 Apr 2017 00:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 aj1I546uWTkb for ; Tue, 25 Apr 2017 00:15:31 -0700 (PDT) Received: from mx2.sitnet.dk (mx2.sitnet.dk [188.64.157.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CD7A12708C for ; Tue, 25 Apr 2017 00:15:30 -0700 (PDT) From: Mads Hjorth To: Adrien de Croy CC: Ted Lemon , Cyrus Daboo , "jmap@ietf.org" , Bron Gondwana Thread-Topic: [Jmap] Submission: options for github issue Thread-Index: AQHSvJsY4luEIe89AEeVXvyXtk3ur6HTrRWAgAC8F4CAAAXUAIAAfGSAgAChTQA= Date: Tue, 25 Apr 2017 07:15:28 +0000 Message-ID: <3C2D4AD4-7C06-47C9-818F-124619F225AE@digst.dk> References: <1492997737.3312553.953738776.7D27901C@webmail.messagingengine.com> <43747FEE-5EBE-4F89-BE13-94701F88A5BA@fugue.com> In-Reply-To: Accept-Language: da-DK, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_3C2D4AD47C0647C9818F124619F225AEdigstdk_" MIME-Version: 1.0 Received-SPF: none Archived-At: Subject: Re: [Jmap] Submission: options for github issue X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 07:15:35 -0000 --_000_3C2D4AD47C0647C9818F124619F225AEdigstdk_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpGaXJzdCBvZiBhbGwsIHRoYW5rIHlvdSBmb3IgdGhlIGdyZWF0IHdvcmsgeW91 IGFyZSBkb2luZyBvbiBmaWd1cmluZyBvdXQgaG93IHRvIGNyYWNrIHRoaXMgbnV0IQ0KDQpJIGRv bnQga25vdyB0b28gbXVjaCBhYm91dCB0aGUgc3BlY2lmaWMgaW1wbGVtZW50YXRpb24gb2YgdGhl IGlzc3VlcyBiZWluZyBkaXNjdXNzZWQsIGJ1dCBJIHdpbGwgbGlrZSB0byB0aHJvdyBpbiBhIGZl dyBvYnNlcnZhdGlvbnMuDQoNCi0gU2VsZi1jb250YWluZWQgbWVzc2FnZXMgKG5vdCBrZWVwaW5n IG1ldGFkYXRhIHNlcGFyYXRlKSBtYWtlcyBhcmNoaXZpbmcsIHRyYW5zZm9ybWF0aW9uIGFuZCBh IGxvdCBvZiBvdGhlciBoYW5kbGluZyBlYWlzZXIuIFJlbWVtYmVyIHRoYXQgbWFpbHMgaGF2ZSBh IHdob2xlIGxpZmUgb3V0c2lkZSB0aGUgY29udGV4dCBvZiB3ZWJtYWlsLiBJdCBhbHNvIGF2b2lk IHRoZSBuZXZlciBlbmRpbmcgZGlzY3Vzc2lvbiBhYm91dCB3aGF0IGlzIGRhdGEgYW5kIHdoYXQg aXMgbWV0YSBkYXRhLiBNYXliZSBpdCBpcyBtb3JlIGEgcXVlc3Rpb24gYWJvdXQgd2hhdCBwYXJ0 cyBvZiBhIG1lc3NhZ2UgdGhhdCBhcmUgdmlzaWJsZS9lbmNyeXB0ZWQuDQoNCi0gU2VuZGluZyB0 byBuYW1lZCBncm91cHMgYW5kIEJjYy4gVGhlIGxpdHRsZSBhd2t3YXJkLW5lc3MgaXMgY2VudHJh bCB0byBzb21lIG9mIHRoZSBpc3N1ZXMgSSBhbSBjdXJyZW50bHkgbG9va2luZyBhZGQuIEkgYW0g dHJ5aW5nIHRvIGZpZ3VyZSBvdXQgdGhlIGJlc3Qgd2F5IHRvIGFsbG93IHJlY2lwaWVudHMgdG8g c2VlIHdoeSB0aGV5IHJlY2VpdmUgYSBncm91cCBtZXNzYWdlIChiZXNpZGUgbWFuYWdlZCBkaXN0 cmlidXRpb24gbGlzdHMpLiBUaGUgd2hvbGUgc2VtYW50aWNzIGFuZCBwcmFjdGljZSBhcm91bmQg dGhpcyBpcyByYXRoZXIgdW5jbGVhciB0byBtZS4gQ3VycmVudGx5IG15IGJlc3QgYmV0IGlzIGFu IGVtcHR5IGdyb3VwIGFkZHJlc3MgaW4gVG86IGFuZCBhZGRyZXNzZXMgb2YgdGhlIG1lbWJlcnMg aW4gQmNjOg0KDQpUaGUgaW50ZW50aW9uIG9mIHNpbXBsaWZ5aW5nIHRoZSBlY28tc3lzdGVtIGJ5 IGluY2x1ZGluZyBzdWJtaXNzaW9uIGluIEpNQVAgaXMgZ3JlYXQsIGJ1dCBJIGhhdmUgYSBmZWVs aW5nIHRoYXQgaWYgaXQgd2FzIHBvc3NpYmxlL2ZlYXNpYmxlL2Vhc3kgaXQgd291bGQgaGF2ZSBi ZWVuIGRvbmUgYnkgSU1BUCBhbGwgcmVhZHkuDQoNCkFzIGEgZnV0dXJlIHVzZXIgb2YgdGhpcyBz cGVjaWZpY2F0aW9uIEkgd291bGQgcmF0aGVyIHNlZSBmdWxsIFJGQyBjb21wbGlhbmNlIChlLmcu IGdyb3VwcyBhbmQgY29tbWVudHMgaW4gYWRkcmVzcyksIHRoYW4gZm9jdXNpbmcgb24gZnV0dXJl cyB0aGF0IGFyZSByZWFzb25hYmx5IHdlbGwgc3VwcG9ydGVkIGJ5IG90aGVyIHByb3RvY29scy4N Cg0KVGhhbmtzIGFnYWluIGZvciBzb21lIGdyZWF0IGFuZCBpbXBvcnRhbnQgd29yayENCg0KDQoN CiAgICAgICAgICAg4oCgDQogICAgICAgIFtbIG8gXV0NCiAgICAgICAgICoqKioqDQpESUdJVEFM SVNFUklOR1NTVFlSRUxTRU4NCg0KTWFkcyBIam9ydGgNCkNoZWZrb25zdWxlbnQNCg0KdGVsOis0 NTQxNzgyMzUxDQptYWlsdG86bWFkc2hAZGlnc3QuZGsNCmh0dHA6Ly93d3cuZGlnc3QuZGsNCg0K Ikkgd291bGQgaGF2ZSBnb3QgcmlkIG9mIHRoZSBzbGFzaCBzbGFzaA0KIGFmdGVyIHRoZSBjb2xv bi4gWW91IGRvbid0IHJlYWxseSBuZWVkIGl0Lg0KIEl0IGp1c3Qgc2VlbWVkIGxpa2UgYSBnb29k IGlkZWEgYXQgdGhlIHRpbWUuIg0KDQotIFRpbSBCZXJuZXJzLUxlZQ0KDQoNCkRlbiAyNC4gYXBy LiAyMDE3IGtsLiAyMy4zOCBza3JldiBBZHJpZW4gZGUgQ3JveSA8YWRyaWVuQHFiaWsuY29tPG1h aWx0bzphZHJpZW5AcWJpay5jb20+PjoNCg0KDQp5ZXMsIHRoZSBNVUEgY291bGQgZmVhc2libHkg ZmFpcmx5IGVhc2lseSBmYWtlIHVwIHRoZSBCQ0MgZmllbGQgZm9yIHRoZSB1c2VyIGludGVyZmFj ZSBiYXNlZCBvbiBlbnZlbG9wZSBpbmZvcm1hdGlvbi4NCg0KSXQgY291bGQgZXZlbiBkbyBiZXR0 ZXIsIHN1Y2ggYXMgc2hvdyBzdGF0dXMgcGVyIHJlY2lwaWVudCBpZiBpdCBoYWQgdGhhdCBpbmZv cm1hdGlvbi4NCg0KDQotLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLS0NCkZyb206ICJUZWQg TGVtb24iIDxtZWxsb25AZnVndWUuY29tPG1haWx0bzptZWxsb25AZnVndWUuY29tPj4NClRvOiAi Q3lydXMgRGFib28iIDxjeXJ1c0BkYWJvby5uYW1lPG1haWx0bzpjeXJ1c0BkYWJvby5uYW1lPj4N CkNjOiAiQWRyaWVuIGRlIENyb3kiIDxhZHJpZW5AcWJpay5jb208bWFpbHRvOmFkcmllbkBxYmlr LmNvbT4+OyAiam1hcEBpZXRmLm9yZzxtYWlsdG86am1hcEBpZXRmLm9yZz4iIDxqbWFwQGlldGYu b3JnPG1haWx0bzpqbWFwQGlldGYub3JnPj47ICJCcm9uIEdvbmR3YW5hIiA8YnJvbmdAZmFzdG1h aWwuZm08bWFpbHRvOmJyb25nQGZhc3RtYWlsLmZtPj4NClNlbnQ6IDI1LzA0LzIwMTcgMjoxMjo1 NiBBTQ0KU3ViamVjdDogUmU6IFtKbWFwXSBTdWJtaXNzaW9uOiBvcHRpb25zIGZvciBnaXRodWIg aXNzdWUNCg0KT24gQXByIDI0LCAyMDE3LCBhdCA5OjUyIEFNLCBDeXJ1cyBEYWJvbyA8Y3lydXNA ZGFib28ubmFtZTxtYWlsdG86Y3lydXNAZGFib28ubmFtZT4+IHdyb3RlOg0Kd2UgbWF5IG5lZWQg dG8gc3BlY2lhbCBCY2MgaGVhZGVycyBldmVuIGlmIHRoZSBlbnZlbG9wZSBpcyBwcmVzZXJ2ZWQg LSBidXQgdGhlbiBpdCBiZWNhdXNlIGEgbGl0dGxlIGF3a3dhcmQgYmVjYXVzZSBvZiB0aGUgZHVw bGljYXRpb24gb2YgaW5mb3JtYXRpb24gaW4gdHdvIHBsYWNlcy4NCg0KRXhjZXB0IHRoYXQgdGhl IGJjYyBoZWFkZXIgc2hvdWxkbid0IGJlIGluIHRoZSBtZXNzYWdlIGluIHRoZSBmaXJzdCBwbGFj ZSwgZm9yIHByaXZhY3kgcmVhc29ucy4gICBTbyBlaXRoZXIgdGhlIG1lc3NhZ2UgaW4gdGhlIEpN QVAgc3RvcmUgaXMgZGlmZmVyZW50IHRoYW4gd2hhdCB3YXMgYWN0dWFsbHkgc2VudCwgb3IgdGhl IEJjYyBpbmZvIHNob3VsZCBfb25seV8gYmUgb24gdGhlIGVudmVsb3BlLg0KDQpPZiBjb3Vyc2Us IHRoaXMgcmVxdWlyZXMgdGhlIE1VQSB0byBkbyBzb21lIGNyZWF0aXZlIGd5bW5hc3RpY3MgdG8g bWFrZSBpdCBhbGwgbG9vayBnb29kLCBidXQgc3VjaCBpcyBsaWZlLg0KDQoNCg== --_000_3C2D4AD47C0647C9818F124619F225AEdigstdk_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg c3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBBcmlhbDsgZm9udC1zaXpl OiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZv bnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87 IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9u ZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsg LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo OiAwcHg7Ij4NCjxmb250IGZhY2U9IkNvdXJpZXIgTmV3IiBjbGFzcz0iIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOiAxMHB0OyIgY2xhc3M9IiI+SGkgYWxsLCZuYnNwOzwvc3Bhbj48L2ZvbnQ+PC9k aXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQXJpYWw7 IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczog bm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBo YW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFu c2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFj aW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0 cm9rZS13aWR0aDogMHB4OyI+DQo8Zm9udCBmYWNlPSJDb3VyaWVyIE5ldyIgY2xhc3M9IiI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvc3Bh bj48L2ZvbnQ+PC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZh bWlseTogQXJpYWw7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZh cmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzog bm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBw eDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0 bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdl YmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+DQo8Zm9udCBmYWNlPSJDb3VyaWVyIE5ldyIg Y2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsiIGNsYXNzPSIiPkZpcnN0IG9m IGFsbCwgdGhhbmsgeW91IGZvciB0aGUgZ3JlYXQgd29yayB5b3UgYXJlIGRvaW5nIG9uIGZpZ3Vy aW5nIG91dCBob3cgdG8gY3JhY2sgdGhpcyBudXQhPC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXYg c3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBBcmlhbDsgZm9udC1zaXpl OiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZv bnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87 IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9u ZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsg LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo OiAwcHg7Ij4NCjxmb250IGZhY2U9IkNvdXJpZXIgTmV3IiBjbGFzcz0iIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOiAxMHB0OyIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9zcGFuPjwvZm9udD48 L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBBcmlh bDsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBz OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9y cGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRy YW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNw YWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQt c3Ryb2tlLXdpZHRoOiAwcHg7Ij4NCjxmb250IGZhY2U9IkNvdXJpZXIgTmV3IiBjbGFzcz0iIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyIgY2xhc3M9IiI+SSBkb250IGtub3cgdG9vIG11 Y2ggYWJvdXQgdGhlIHNwZWNpZmljIGltcGxlbWVudGF0aW9uIG9mIHRoZSBpc3N1ZXMgYmVpbmcg ZGlzY3Vzc2VkLCBidXQgSSB3aWxsIGxpa2UgdG8gdGhyb3cgaW4gYSBmZXcgb2JzZXJ2YXRpb25z LiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAs IDApOyBmb250LWZhbWlseTogQXJpYWw7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9y bWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0 ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4 dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7 IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zaXplLWFkanVz dDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+DQo8Zm9udCBmYWNlPSJD b3VyaWVyIE5ldyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsiIGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xv cjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQXJpYWw7IGZvbnQtc2l6ZTogMTJweDsgZm9u dC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDog bm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWdu OiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNw YWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4 dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+DQo8 Zm9udCBmYWNlPSJDb3VyaWVyIE5ldyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTog MTBwdDsiIGNsYXNzPSIiPi0gU2VsZi1jb250YWluZWQgbWVzc2FnZXMgKG5vdCBrZWVwaW5nIG1l dGFkYXRhIHNlcGFyYXRlKSBtYWtlcyBhcmNoaXZpbmcsIHRyYW5zZm9ybWF0aW9uIGFuZCBhIGxv dCBvZiBvdGhlciBoYW5kbGluZyBlYWlzZXIuIFJlbWVtYmVyIHRoYXQgbWFpbHMgaGF2ZSBhIHdo b2xlIGxpZmUgb3V0c2lkZSB0aGUgY29udGV4dA0KIG9mIHdlYm1haWwuIEl0IGFsc28gYXZvaWQg dGhlIG5ldmVyIGVuZGluZyBkaXNjdXNzaW9uIGFib3V0IHdoYXQgaXMgZGF0YSBhbmQgd2hhdCBp cyBtZXRhIGRhdGEuIE1heWJlIGl0IGlzIG1vcmUgYSBxdWVzdGlvbiBhYm91dCB3aGF0IHBhcnRz IG9mIGEgbWVzc2FnZSB0aGF0IGFyZSB2aXNpYmxlL2VuY3J5cHRlZC48YnIgY2xhc3M9IiI+DQo8 L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9u dC1mYW1pbHk6IEFyaWFsOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9u dC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNp bmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50 OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6 IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87 IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPg0KPGZvbnQgZmFjZT0iQ291cmllciBO ZXciIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigw LCAwLCAwKTsgZm9udC1mYW1pbHk6IEFyaWFsOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6 IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsg bGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7 IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9y bWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc2l6ZS1h ZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPg0KPGZvbnQgZmFj ZT0iQ291cmllciBOZXciIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IiBj bGFzcz0iIj4tIFNlbmRpbmcgdG8gbmFtZWQgZ3JvdXBzIGFuZCBCY2MuIFRoZSBsaXR0bGUgYXdr d2FyZC1uZXNzIGlzIGNlbnRyYWwgdG8gc29tZSBvZiB0aGUgaXNzdWVzIEkgYW0gY3VycmVudGx5 IGxvb2tpbmcgYWRkLiBJIGFtIHRyeWluZyB0byBmaWd1cmUgb3V0IHRoZSBiZXN0IHdheSB0byBh bGxvdyByZWNpcGllbnRzIHRvIHNlZQ0KIHdoeSB0aGV5IHJlY2VpdmUgYSBncm91cCBtZXNzYWdl IChiZXNpZGUgbWFuYWdlZCBkaXN0cmlidXRpb24gbGlzdHMpLiBUaGUgd2hvbGUgc2VtYW50aWNz IGFuZCBwcmFjdGljZSBhcm91bmQgdGhpcyBpcyByYXRoZXIgdW5jbGVhciB0byBtZS4gQ3VycmVu dGx5IG15IGJlc3QgYmV0IGlzIGFuIGVtcHR5IGdyb3VwIGFkZHJlc3MgaW4gVG86IGFuZCBhZGRy ZXNzZXMgb2YgdGhlIG1lbWJlcnMgaW4gQmNjOjwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2IHN0 eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQXJpYWw7IGZvbnQtc2l6ZTog MTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250 LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0 ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7 IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13 ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDog MHB4OyI+DQo8Zm9udCBmYWNlPSJDb3VyaWVyIE5ldyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTogMTBwdDsiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvc3Bhbj48L2ZvbnQ+PC9k aXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQXJpYWw7 IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczog bm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBo YW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFu c2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFj aW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0 cm9rZS13aWR0aDogMHB4OyI+DQo8Zm9udCBmYWNlPSJDb3VyaWVyIE5ldyIgY2xhc3M9IiI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsiIGNsYXNzPSIiPlRoZSBpbnRlbnRpb24gb2Ygc2lt cGxpZnlpbmcgdGhlIGVjby1zeXN0ZW0gYnkgaW5jbHVkaW5nIHN1Ym1pc3Npb24gaW4gSk1BUCBp cyBncmVhdCwgYnV0IEkgaGF2ZSBhIGZlZWxpbmcgdGhhdCBpZiBpdCB3YXMgcG9zc2libGUvZmVh c2libGUvZWFzeSBpdCB3b3VsZCBoYXZlIGJlZW4gZG9uZSBieSBJTUFQIGFsbCByZWFkeS4mbmJz cDs8L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsg Zm9udC1mYW1pbHk6IEFyaWFsOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsg Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNw YWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5k ZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRv d3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1 dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPg0KPGZvbnQgZmFjZT0iQ291cmll ciBOZXciIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJn YigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEFyaWFsOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5 bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1h bDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3Rh cnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTog bm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc2l6 ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPg0KPGZvbnQg ZmFjZT0iQ291cmllciBOZXciIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7 IiBjbGFzcz0iIj5BcyBhIGZ1dHVyZSB1c2VyIG9mIHRoaXMgc3BlY2lmaWNhdGlvbiBJIHdvdWxk IHJhdGhlciBzZWUgZnVsbCBSRkMgY29tcGxpYW5jZSAoZS5nLiBncm91cHMgYW5kIGNvbW1lbnRz IGluIGFkZHJlc3MpLCB0aGFuIGZvY3VzaW5nIG9uIGZ1dHVyZXMgdGhhdCBhcmUgcmVhc29uYWJs eSB3ZWxsIHN1cHBvcnRlZCBieSBvdGhlcg0KIHByb3RvY29scy48L3NwYW4+PC9mb250PjwvZGl2 Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEFyaWFsOyBm b250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5v cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFu czogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNm b3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2lu ZzogMHB4OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDsiPg0KPGZvbnQgZmFjZT0iQ291cmllciBOZXciIGNsYXNzPSIiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L3NwYW4+ PC9mb250PjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1p bHk6IEFyaWFsOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJp YW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5v cm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7 IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87 IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJr aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPg0KPGZvbnQgZmFjZT0iQ291cmllciBOZXciIGNs YXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IiBjbGFzcz0iIj5UaGFua3MgYWdh aW4gZm9yIHNvbWUgZ3JlYXQgYW5kIGltcG9ydGFudCB3b3JrITwvc3Bhbj48L2ZvbnQ+PC9kaXY+ DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQXJpYWw7IGZv bnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9y bWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5z OiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zv cm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5n OiAwcHg7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4OyI+DQo8Zm9udCBmYWNlPSJDb3VyaWVyIE5ldyIgY2xhc3M9IiI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvc3Bhbj48 L2ZvbnQ+PC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWls eTogQXJpYWw7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlh bnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9y bWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsg dGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsg d29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtp dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYg c3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBBcmlhbDsgZm9udC1zaXpl OiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZv bnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87 IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9u ZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsg LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo OiAwcHg7Ij4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigw LCAwLCAwKTsgZm9udC1mYW1pbHk6IEFyaWFsOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6 IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsg bGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7 IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9y bWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc2l6ZS1h ZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPg0KPGRpdj48Zm9u dCBmYWNlPSJDb3VyaWVyIE5ldyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBw dDsiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IiBjbGFzcz0iIj7igKA8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IFtbPC9zcGFuPjwvZm9udD48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0 OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsiIGNsYXNzPSIiPiZuYnNwO28gXV08L3NwYW4+ PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNvdXJpZXIgTmV3IiBjbGFzcz0iIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOiAxMHB0OyIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyoqKioqPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IiBjbGFzcz0i Ij48YnIgY2xhc3M9IiI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsiIGNs YXNzPSIiPkRJR0lUQUxJU0VSSU5HU1NUWVJFTFNFTjwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2 Pjxmb250IGZhY2U9IkNvdXJpZXIgTmV3IiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2ZvbnQ+ PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNvdXJpZXIgTmV3IiBjbGFzcz0iIj5NYWRzIEhqb3J0 aDwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ291cmllciBOZXciIGNsYXNzPSIiPkNo ZWZrb25zdWxlbnQ8L2ZvbnQ+PC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRp dj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7IiBjbGFzcz0iIj48YSBo cmVmPSJ0ZWw6JiM0Mzs0NTQxNzgyMzUxIiBjbGFzcz0iIj50ZWw6JiM0Mzs0NTQxNzgyMzUxPC9h Pjwvc3Bhbj48L2Rpdj4NCjxkaXY+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAnQ291cmllciBO ZXcnOyIgY2xhc3M9IiI+PGEgaHJlZj0ibWFpbHRvOm1hZHNoQGRpZ3N0LmRrIiBjbGFzcz0iIj5t YWlsdG86bWFkc2hAZGlnc3QuZGs8L2E+PC9zcGFuPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48c3Bh biBjbGFzcz0iIiBzdHlsZT0iZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7Ij48YSBocmVmPSJo dHRwOi8vd3d3LmRpZ3N0LmRrIiBjbGFzcz0iIj5odHRwOi8vd3d3LmRpZ3N0LmRrPC9hPjwvc3Bh bj48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IiIgc3R5bGU9ImZvbnQtZmFtaWx5 OiAnQ291cmllciBOZXcnOyI+PGJyIGNsYXNzPSIiPg0KPC9zcGFuPjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj48Zm9udCBmYWNlPSJDb3VyaWVyIE5ldyIgY2xhc3M9IiI+JnF1b3Q7SSB3b3VsZCBoYXZl IGdvdCByaWQgb2YgdGhlIHNsYXNoIHNsYXNoJm5ic3A7PC9mb250PjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj48Zm9udCBmYWNlPSJDb3VyaWVyIE5ldyIgY2xhc3M9IiI+Jm5ic3A7YWZ0ZXIgdGhlIGNv bG9uLiBZb3UgZG9uJ3QgcmVhbGx5IG5lZWQgaXQuJm5ic3A7PC9mb250PjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj48Zm9udCBmYWNlPSJDb3VyaWVyIE5ldyIgY2xhc3M9IiI+Jm5ic3A7SXQganVzdCBz ZWVtZWQgbGlrZSBhIGdvb2QgaWRlYSBhdCB0aGUgdGltZS4mcXVvdDsmbmJzcDs8L2ZvbnQ+PC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGZhY2U9IkNvdXJpZXIgTmV3IiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGZhY2U9IkNvdXJp ZXIgTmV3IiBjbGFzcz0iIj4tIFRpbSBCZXJuZXJzLUxlZTwvZm9udD48L2Rpdj4NCjwvZGl2Pg0K PGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjwvZGl2Pg0KPGJyIGNsYXNz PSIiPg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFz cz0iIj5EZW4gMjQuIGFwci4gMjAxNyBrbC4gMjMuMzggc2tyZXYgQWRyaWVuIGRlIENyb3kgJmx0 OzxhIGhyZWY9Im1haWx0bzphZHJpZW5AcWJpay5jb20iIGNsYXNzPSIiPmFkcmllbkBxYmlrLmNv bTwvYT4mZ3Q7OjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4N CjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogVGFob21hOyBmb250LXNp emU6IDE2cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsg Zm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjog c3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFj ZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDog MHB4OyIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0K eWVzLCB0aGUgTVVBIGNvdWxkIGZlYXNpYmx5IGZhaXJseSBlYXNpbHkgZmFrZSB1cCB0aGUgQkND IGZpZWxkIGZvciB0aGUgdXNlciBpbnRlcmZhY2UgYmFzZWQgb24gZW52ZWxvcGUgaW5mb3JtYXRp b24uPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogVGFob21hOyBmb250LXNpemU6IDE2 cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13 ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7 IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9y bWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIg Y2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5 OiBUYWhvbWE7IGZvbnQtc2l6ZTogMTZweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlh bnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9y bWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06 IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRl eHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCkl0IGNvdWxkIGV2ZW4gZG8gYmV0dGVy LCBzdWNoIGFzIHNob3cgc3RhdHVzIHBlciByZWNpcGllbnQgaWYgaXQgaGFkIHRoYXQgaW5mb3Jt YXRpb24uPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogVGFob21hOyBmb250LXNpemU6 IDE2cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9u dC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3Rh cnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTog bm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4 OyIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFt aWx5OiBUYWhvbWE7IGZvbnQtc2l6ZTogMTZweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZh cmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzog bm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zv cm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0 LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IFRhaG9tYTsgZm9udC1zaXplOiAxNnB4OyBmb250 LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBu b3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWlu ZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29y ZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIi Pg0KLS0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0tPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250 LWZhbWlseTogVGFob21hOyBmb250LXNpemU6IDE2cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9u dC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNp bmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJh bnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdl YmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQpGcm9tOiAmcXVvdDtUZWQg TGVtb24mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzptZWxsb25AZnVndWUuY29tIiBjbGFzcz0i Ij5tZWxsb25AZnVndWUuY29tPC9hPiZndDs8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5 OiBUYWhvbWE7IGZvbnQtc2l6ZTogMTZweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlh bnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9y bWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06 IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRl eHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NClRvOiAmcXVvdDtDeXJ1cyBEYWJvbyZx dW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmN5cnVzQGRhYm9vLm5hbWUiIGNsYXNzPSIiPmN5cnVz QGRhYm9vLm5hbWU8L2E+Jmd0OzwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IFRhaG9t YTsgZm9udC1zaXplOiAxNnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBz OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRl eHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsg d2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KQ2M6ICZxdW90O0FkcmllbiBkZSBDcm95JnF1b3Q7 ICZsdDs8YSBocmVmPSJtYWlsdG86YWRyaWVuQHFiaWsuY29tIiBjbGFzcz0iIj5hZHJpZW5AcWJp ay5jb208L2E+Jmd0OzsgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmptYXBAaWV0Zi5vcmciIGNsYXNz PSIiPmptYXBAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86am1hcEBpZXRm Lm9yZyIgY2xhc3M9IiI+am1hcEBpZXRmLm9yZzwvYT4mZ3Q7OyAmcXVvdDtCcm9uIEdvbmR3YW5h JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86YnJvbmdAZmFzdG1haWwuZm0iIGNsYXNzPSIiPmJy b25nQGZhc3RtYWlsLmZtPC9hPiZndDs8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBU YWhvbWE7IGZvbnQtc2l6ZTogMTZweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQt Y2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFs OyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5v bmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQt c3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NClNlbnQ6IDI1LzA0LzIwMTcgMjoxMjo1NiBB TTwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IFRhaG9tYTsgZm9udC1zaXplOiAxNnB4 OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2Vp Z2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0 ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1h bDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNs YXNzPSIiPg0KU3ViamVjdDogUmU6IFtKbWFwXSBTdWJtaXNzaW9uOiBvcHRpb25zIGZvciBnaXRo dWIgaXNzdWU8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBUYWhvbWE7IGZvbnQtc2l6 ZTogMTZweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBm b250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBz dGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNl OiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAw cHg7IiBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBpZD0ieDFmYWE5NTlm MGZkZTQ4NyIgc3R5bGU9ImZvbnQtZmFtaWx5OiBUYWhvbWE7IGZvbnQtc2l6ZTogMTZweDsgZm9u dC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDog bm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1p bmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdv cmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHdvcmQtd3Jh cDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJl YWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSBjaXRlPSJ4LW1z ZzovLzQvNDM3NDdGRUUtNUVCRS00Rjg5LUJFMTMtOTQ3MDFGODhBNUJBQGZ1Z3VlLmNvbSIgdHlw ZT0iY2l0ZSIgY2xhc3M9ImNpdGUyIiBzdHlsZT0ibWFyZ2luLWxlZnQ6IDVweDsgbWFyZ2luLXJp Z2h0OiAwcHg7IHBhZGRpbmctbGVmdDogMTBweDsgcGFkZGluZy1yaWdodDogMHB4OyBib3JkZXIt bGVmdC13aWR0aDogMXB4OyBib3JkZXItbGVmdC1zdHlsZTogc29saWQ7IGJvcmRlci1sZWZ0LWNv bG9yOiByZ2IoMjA0LCAyMDQsIDIwNCk7IG1hcmdpbi10b3A6IDNweDsgcGFkZGluZy10b3A6IDBw eDsiPg0KT24gQXByIDI0LCAyMDE3LCBhdCA5OjUyIEFNLCBDeXJ1cyBEYWJvbyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmN5cnVzQGRhYm9vLm5hbWUiIGNsYXNzPSIiPmN5cnVzQGRhYm9vLm5hbWU8L2E+ Jmd0OyB3cm90ZToNCjxkaXYgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFz cz0iIj4NCjxkaXYgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IiIgc3R5bGU9ImZvbnQtZmFtaWx5OiBN ZW5sby1SZWd1bGFyOyBmb250LXNpemU6IDE4cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12 YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6 IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNm b3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtp dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFp bXBvcnRhbnQ7Ij53ZQ0KIG1heSBuZWVkIHRvIHNwZWNpYWwgQmNjIGhlYWRlcnMgZXZlbiBpZiB0 aGUgZW52ZWxvcGUgaXMgcHJlc2VydmVkIC0gYnV0IHRoZW4gaXQgYmVjYXVzZSBhIGxpdHRsZSBh d2t3YXJkIGJlY2F1c2Ugb2YgdGhlIGR1cGxpY2F0aW9uIG9mIGluZm9ybWF0aW9uIGluIHR3byBw bGFjZXMuPC9zcGFuPjxiciBjbGFzcz0iIiBzdHlsZT0iZm9udC1mYW1pbHk6IE1lbmxvLVJlZ3Vs YXI7IGZvbnQtc2l6ZTogMThweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fw czogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0 ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7 IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ry b2tlLXdpZHRoOiAwcHg7Ij4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSIiPkV4Y2VwdCB0aGF0IHRoZSBiY2MgaGVhZGVyIHNob3VsZG4n dCBiZSBpbiB0aGUgbWVzc2FnZSBpbiB0aGUgZmlyc3QgcGxhY2UsIGZvciBwcml2YWN5IHJlYXNv bnMuICZuYnNwOyBTbyBlaXRoZXIgdGhlIG1lc3NhZ2UgaW4gdGhlIEpNQVAgc3RvcmUgaXMgZGlm ZmVyZW50IHRoYW4gd2hhdCB3YXMgYWN0dWFsbHkgc2VudCwgb3IgdGhlIEJjYyBpbmZvIHNob3Vs ZCBfb25seV8gYmUgb24gdGhlIGVudmVsb3BlLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+T2YgY291cnNlLCB0aGlzIHJlcXVpcmVzIHRo ZSBNVUEgdG8gZG8gc29tZSBjcmVhdGl2ZSBneW1uYXN0aWNzIHRvIG1ha2UgaXQgYWxsIGxvb2sg Z29vZCwgYnV0IHN1Y2ggaXMgbGlmZS48L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_3C2D4AD47C0647C9818F124619F225AEdigstdk_-- From nobody Tue Apr 25 00:36:27 2017 Return-Path: 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 B52C7128B4E for ; Tue, 25 Apr 2017 00:36:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 t1ekATZDn6-0 for ; Tue, 25 Apr 2017 00:36:24 -0700 (PDT) Received: from mx2.sitnet.dk (mx2.sitnet.dk [188.64.157.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA26B128AB0 for ; Tue, 25 Apr 2017 00:36:23 -0700 (PDT) From: Mads Hjorth To: Adrien de Croy CC: John Levine , "jmap@ietf.org" Thread-Topic: [Jmap] Submission Thread-Index: AQHSuXVw+QDyL8wL60auOI5xl9FmGaHNXfmAgABsvwCAAQoIAIAAZH0AgAZflYA= Date: Tue, 25 Apr 2017 07:36:21 +0000 Message-ID: <438DDABF-163A-421E-9A6A-84D3B53D5ADB@digst.dk> References: <20170421001702.24991.qmail@ary.lan> In-Reply-To: Accept-Language: da-DK, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-ID: <8224246CCA2BC5419E26D39E9744973B@SITAD.DK> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Received-SPF: none Archived-At: Subject: Re: [Jmap] Submission X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 07:36:26 -0000 SSBhZ3JlZSBpbiB0aGUgYW1iaXRpb24gdG8gbWFrZSBhIGJldHRlciBtYWlsIGV4cGVyaWVuY2Ug Oi0pIGFuZCBpbiB0aGUgcHJpbmNpcGxlIG9mIGtlZXBpbmcgcHJvdG9jb2xzIG9wZW4gYW5kIG1v ZHVsYXIuIA0KDQpTb21lIG9mIHRoZSBtYWluIGlzc3VlcyB3aXRoIHRoZSBjdXJyZW50IG1haWwg ZXhwZXJpZW5jZSBpcyBpdHMgbGFjayBvZiBldmlkZW5jZSBvZiBzZW5kZXJzIElEIGFuZCBkZWxp dmVyeS4gDQoNCkEgbG90IG9mIG9yZ2FuaXphdGlvbnMgYXJlIGxvb2tpbmcgaW50byB0aGlzLiAN Cg0KRXVyb3BlYW4gVGVsZWNvbW11bmljYXRpb25zIFN0YW5kYXJkcyBJbnN0aXR1dGUgaGFzIHB1 Ymxpc2hlZCBhIHN0YW5kYXJkIG9uIFJlZ2lzdGVyZWQgRWxlY3Ryb25pYyBNYWlsIChFVFNJIFRT IDEwMiA2NDAtMSkuIA0KDQpNYXliZSB0aGlzIGZyYW1ld29yayBjb3VsZCBiZSB1c2VkIHRvIGNs YXJpZnkgdGhlIGZ1dHVyZSByb2xlIG9mIEpNQVAgZS5nLiBkb2VzIGl0IGNvdmVyIHRoZSByZXF1 aXJlbWVudCBvZiBib3RoIGEgU2VuZGVyLU1lc3NhZ2UgU3VibWlzc2lvbiBJbnRlcmZhY2UgYW5k IFNlbmRlci1NZXNzYWdlIFN0b3JlIFJldHJpZXZhbCBJbnRlcmZhY2UuIA0KDQpTb+KApiBtYXli ZSBwcmVwYXJlIEpNQVAgdG8gaGVscCBvcmdhbml6YXRpb25zIGdvIGZyb20gZW1haWwgdG8gcmVn aXN0ZXJlZCBlbWFpbD8NCg0KL21hZHNoDQoNCg0KPiBEZW4gMjEuIGFwci4gMjAxNyBrbC4gMDgu MTYgc2tyZXYgQWRyaWVuIGRlIENyb3kgPGFkcmllbkBxYmlrLmNvbT46DQo+IA0KPiANCj4gDQo+ IC0tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tLQ0KPiBGcm9tOiAiSm9obiBMZXZpbmUiIDxq b2hubEB0YXVnaC5jb20+DQo+IFRvOiAiam1hcEBpZXRmLm9yZyIgPGptYXBAaWV0Zi5vcmc+DQo+ IENjOiAiYWRyaWVuQHFiaWsuY29tIiA8YWRyaWVuQHFiaWsuY29tPg0KPiBTZW50OiAyMS8wNC8y MDE3IDEyOjE3OjAyIFBNDQo+IFN1YmplY3Q6IFJlOiBbSm1hcF0gU3VibWlzc2lvbg0KPiANCj4+ IEluIGFydGljbGUgPGVtZDM1MzNjMGQtZGMwOC00NWMzLTgwMWMtMDc5NzI4NThhZDY0QGJvZHli YWc+IHlvdSB3cml0ZToNCj4+PiBJJ2QgbG92ZSB0byBzZWUgYSBtYWlsIGNsaWVudCB0aGF0IGRv ZXMgYXQgbGVhc3QgaW5pdGlhbCB2YWxpZGF0aW9uIG9uDQo+Pj4gZGVzdGluYXRpb24gZW1haWwg YWRkcmVzc2VzIGFzIHRoZXkgYXJlIGFkZGVkIHRvIHRoZSBtZXNzYWdlLCBzbyB0aGF0DQo+Pj4g ZXJyb3JzIGluIHRoZSBhZGRyZXNzZXMgd2hpY2ggY2FuIGJlIHJlc29sdmVkIGF0IHRoYXQgc3Rh Z2UgKGUuZy4NCj4+PiBOWERPTUFJTikgY2FuIGJlIHJhaXNlZCB3aXRoIHRoZSBlbWFpbCBhdXRo b3IgYmVmb3JlIHRoZSBtYWlsIGlzIGV2ZW4NCj4+PiBzdWJtaXR0ZWQuDQo+PiANCj4+IFRoaXMg aXMgcXVpdGUgdGhlIGNhbiBvZiB3b3Jtcy4gIEl0J3MgZWFzeSBlbm91Z2ggdG8gbG9vayB1cCBh IGRvbWFpbg0KPj4gYW5kIHNlZSBpZiBpdCBoYXMgYW4gQSBvciBhbiBNWCwgYnV0IHdoYXRldmVy IHlvdSB3ZXJlIHBsYW5uaW5nIHRvIGRvDQo+PiB0byB2YWxpZGF0ZSBtYWlsYm94ZXMgd2lsbCBn ZXQgeW91IGJsYWNrbGlzdGVkIGFzIGEgbGlzdHdhc2hpbmcNCj4+IHNwYW1tZXIuDQo+IHN1cmUs IEkgdGhpbmsgdGhlcmUgYXJlIGZ1bmRhbWVudGFsIGlzc3VlcyB3aXRoIHRyeWluZyB0byBnbyBm dXJ0aGVyIHRoYW4gYW4gQS9NWCBmb3Igbm93LCBidXQgaWYgd2UgYnVpbHQgaW4gYSBtZWNoYW5p c20gdG8gdmVyaWZ5IGFkZHJlc3NlcywgaXQgY291bGQgYmUgZXh0ZW5kZWQgbGF0ZXIsIHJhdGhl ciB0aGFuIGJlaW5nIGJsb2NrZWQgb2ZmIGZvciBhbGwgb2YgZXRlcm5pdHkuDQo+IA0KPiBFdmVu IEEvTVggd291bGQgaGF2ZSBzb21lIHZhbHVlLiAgV2hvIGtub3dzIHdoYXQga2luZCBvZiB0cnVz dGVkIG1haWwgZGVsaXZlcnkgaW5mcmFzdHJ1Y3R1cmUgbWF5IGNvbWUgb3V0IGluIHRoZSBmdXR1 cmUsIGF0IHNvbWUgc3RhZ2Ugd2UgaGF2ZSB0byBmaXggU01UUC4gIEZvcmV2ZXIgaXMgYSBsb25n IHRpbWUuDQo+IA0KPiBBZHJpZW4NCj4gDQo+IA0KPj4gDQo+PiANCj4+IE9uY2UgYWdhaW4sIEkg cmVhbGx5IGRvIG5vdCB0aGluayB0aGlzIGlzIHRoZSB0aW1lIG9yIHBsYWNlIHRvIHRyeSBhbmQN Cj4+IGZpeCBhbGwgb2YgU01UUCdzIGZhdWx0cy4NCj4+IA0KPj4gUidzLA0KPj4gSm9obg0KPj4g DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4g Sm1hcCBtYWlsaW5nIGxpc3QNCj4+IEptYXBAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vam1hcA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gSm1hcCBtYWlsaW5nIGxpc3QNCj4gSm1hcEBpZXRm Lm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ptYXANCg0K From nobody Tue Apr 25 01:32:59 2017 Return-Path: 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 171FE1293D9 for ; Tue, 25 Apr 2017 01:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.622 X-Spam-Level: X-Spam-Status: No, score=-2.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 NKSF8rHQWcOb for ; Tue, 25 Apr 2017 01:32:55 -0700 (PDT) Received: from mail.pscs.co.uk (mail.pscs.co.uk [188.65.177.237]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F1271293DF for ; Tue, 25 Apr 2017 01:32:53 -0700 (PDT) Authentication-Results: mail.pscs.co.uk; spf=none; auth=pass (cram-md5) smtp.auth=paul Received: from lmail.pscs.co.uk ([82.68.5.206]) by mail.pscs.co.uk ([188.65.177.237] running VPOP3) with ESMTP for ; Tue, 25 Apr 2017 09:32:37 +0100 Authentication-Results: lmail.pscs.co.uk; spf=none; auth=pass (cram-md5) smtp.auth=paul Received: from [192.168.66.101] ([192.168.66.101]) by lmail.pscs.co.uk ([192.168.66.70] running VPOP3) with ESMTPSA for ; Tue, 25 Apr 2017 09:26:47 +0100 To: jmap@ietf.org References: <1492996915.3310412.953749536.0F1C8B46@webmail.messagingengine.com> <20170424014957.39235.qmail@ary.lan> From: Paul Smith Message-ID: <6ccd8a82-5132-a38f-d7eb-cc3eeeb922b1@pscs.co.uk> Date: Tue, 25 Apr 2017 09:26:46 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V7.2 - Registered X-Organisation: Paul Smith Computer Services X-VPOP3Tester: 12 345 X-Authenticated-Sender: paul Archived-At: Subject: Re: [Jmap] Address Validation (was Re: Submission) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 08:32:58 -0000 On 24/04/2017 22:37, Adrien de Croy wrote: > >> >> On all the mail systems I know, if you try to send mail at a domain >> that doesn't exist, it fails instantly. > I've seen a lot delayed, especially when the initial submission server > forwards to another pre-configured "smarthost" which then delays it > further. I've seen delays as well. Often related to badly behaved DNS servers which do strange things with non-existent domains (eg not returning anything, rather than returning an NX error). The mail server then should play safe and retry for a while. Remember that a lot of mail servers are deployed on small networks with badly behaving infrastructure. Eg - how is a mail server supposed to indicate whether a recipient address is valid if the Internet connection is down and the DNS server has crashed? I know it seems unpopular here, but there are good reasons for a lot (not all) of the ways things happen with SMTP/IMAP4. From nobody Tue Apr 25 01:38:55 2017 Return-Path: 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 EC29A131B32 for ; Tue, 25 Apr 2017 01:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 NtonxNJMT7PK for ; Tue, 25 Apr 2017 01:38:52 -0700 (PDT) Received: from mail.pscs.co.uk (mail.pscs.co.uk [188.65.177.237]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60BFC131B15 for ; Tue, 25 Apr 2017 01:38:49 -0700 (PDT) Authentication-Results: mail.pscs.co.uk; spf=none; auth=pass (cram-md5) smtp.auth=paul Received: from lmail.pscs.co.uk ([82.68.5.206]) by mail.pscs.co.uk ([188.65.177.237] running VPOP3) with ESMTP for ; Tue, 25 Apr 2017 09:38:32 +0100 Authentication-Results: lmail.pscs.co.uk; spf=none; auth=pass (cram-md5) smtp.auth=paul Received: from [192.168.66.101] ([192.168.66.101]) by lmail.pscs.co.uk ([192.168.66.70] running VPOP3) with ESMTPSA for ; Tue, 25 Apr 2017 09:33:25 +0100 To: jmap@ietf.org References: <1492996915.3310412.953749536.0F1C8B46@webmail.messagingengine.com> <20170424014957.39235.qmail@ary.lan> <6319482c-e53f-4483-870b-844e23030f8c@gulbrandsen.priv.no> From: Paul Smith Message-ID: Date: Tue, 25 Apr 2017 09:33:24 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------4861E3CF32ACADD9460C53E2" X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V7.2 - Registered X-Organisation: Paul Smith Computer Services X-VPOP3Tester: 12 345 X-Authenticated-Sender: paul Archived-At: Subject: Re: [Jmap] Address Validation (was Re: Submission) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 08:38:54 -0000 This is a multi-part message in MIME format. --------------4861E3CF32ACADD9460C53E2 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 24/04/2017 20:25, Ted Lemon wrote: > On Apr 24, 2017, at 12:14 PM, Arnt Gulbrandsen > > wrote: >> However, the question that I understood was asked upthread is roughly >> "to which recipients has x been delivered already?", and for that >> particular question an unbroken implementation chain is needed from >> sender to recipient. > > I think even knowing that the MTA for the admin domain of the JMAP > server has successfully forwarded the message would be sufficient to > be equivalent in most cases. If someone does more, that's great, but > best is the enemy of good enough. I may be wrong, but I believe you can already do that with DSN/MDNs. However, I have yet to see an MUA which does it even though it doesn't seem like it'd be that hard to do with the MUA requesting success DSNs and parsing the responses. Maybe the JMAP server could handle the responses and somehow link the status to the sent message? --------------4861E3CF32ACADD9460C53E2 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 24/04/2017 20:25, Ted Lemon wrote:
On Apr 24, 2017, at 12:14 PM, Arnt Gulbrandsen <arnt@gulbrandsen.priv.no> wrote:
However, the question that I understood was asked upthread is roughly "to which recipients has x been delivered already?", and for that particular question an unbroken implementation chain is needed from sender to recipient.

I think even knowing that the MTA for the admin domain of the JMAP server has successfully forwarded the message would be sufficient to be equivalent in most cases.   If someone does more, that's great, but best is the enemy of good enough.

I may be wrong, but I believe you can already do that with DSN/MDNs. However, I have yet to see an MUA which does it even though it doesn't seem like it'd be that hard to do with the MUA requesting success DSNs and parsing the responses.

Maybe the JMAP server could handle the responses and somehow link the status to the sent message?


 
--------------4861E3CF32ACADD9460C53E2-- From nobody Tue Apr 25 02:26:28 2017 Return-Path: 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 EAF65127599 for ; Tue, 25 Apr 2017 02:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 snfT2kKfw3l4 for ; Tue, 25 Apr 2017 02:26:24 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [122.56.26.1]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4743C1289B5 for ; Tue, 25 Apr 2017 02:26:23 -0700 (PDT) Received: From [192.168.1.146] (unverified [192.168.1.146]) by SMTP Server [192.168.1.3] (WinGate SMTP Receiver v9.0.5 (Build 5926)) with SMTP id <0001029337@smtp.qbik.com>; Tue, 25 Apr 2017 21:26:20 +1200 From: "Adrien de Croy" To: "Paul Smith" , "jmap@ietf.org" Date: Tue, 25 Apr 2017 09:26:20 +0000 Message-Id: In-Reply-To: References: <1492996915.3310412.953749536.0F1C8B46@webmail.messagingengine.com> <20170424014957.39235.qmail@ary.lan> <6319482c-e53f-4483-870b-844e23030f8c@gulbrandsen.priv.no> Reply-To: "Adrien de Croy" User-Agent: eM_Client/7.0.27943.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MB37C6EF3D-5B7C-44B8-9DC3-9326C4E5C0F0" Archived-At: Subject: Re: [Jmap] Address Validation (was Re: Submission) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 09:26:27 -0000 --------=_MB37C6EF3D-5B7C-44B8-9DC3-9326C4E5C0F0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable I think the problem with lack of support for MDN / DSN in clients may be= =20 due to lack of implementation in the network of support for it. If there's still a significant number of deployed systems that don't=20 support it, then clients have increased doubts about its worth. Chicken= =20 and egg issue again. I wouldn't presume that the reason that it doesn't appear so much in the= =20 wild in clients is due to lack of interest. Maybe some MUA authors=20 could be approached for comment. We looked several times at supporting DSN etc in our mail system, and=20 balked at some of the more onerous requirements. A lot of the extension RFCs have onerous requirements for interfacing=20 with non-supporting systems. 8BITMIME springs to mind here. So we are=20 binary safe (even embedded NULLs), but don't advertise 8BITMIME due to=20 not wanting to take on the responsibility of what to do when forwarding=20 to another server that doesn't advertise it. Maybe that just makes us=20 lame. Probably should revisit both these. But we probably aren't the only ones either. Adrien ------ Original Message ------ From: "Paul Smith" To: "jmap@ietf.org" Sent: 25/04/2017 8:33:24 PM Subject: Re: [Jmap] Address Validation (was Re: Submission) >On 24/04/2017 20:25, Ted Lemon wrote: >>On Apr 24, 2017, at 12:14 PM, Arnt Gulbrandsen=20 >> wrote: >>>However, the question that I understood was asked upthread is roughly= =20 >>>"to which recipients has x been delivered already?", and for that=20 >>>particular question an unbroken implementation chain is needed from=20 >>>sender to recipient. >> >>I think even knowing that the MTA for the admin domain of the JMAP=20 >>server has successfully forwarded the message would be sufficient to=20 >>be equivalent in most cases. If someone does more, that's great, but= =20 >>best is the enemy of good enough. > >I may be wrong, but I believe you can already do that with DSN/MDNs.=20 >However, I have yet to see an MUA which does it even though it doesn't=20 >seem like it'd be that hard to do with the MUA requesting success DSNs=20 >and parsing the responses. > >Maybe the JMAP server could handle the responses and somehow link the=20 >status to the sent message? > > > =20=09 --------=_MB37C6EF3D-5B7C-44B8-9DC3-9326C4E5C0F0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable =20

I think the problem with lack of support for= MDN / DSN in clients may be due to lack of implementation in the network= of support for it.

If there's still a significa= nt number of deployed systems that don't support it, then clients have incr= eased doubts about its worth. =C2=A0Chicken and egg issue again.
=
I wouldn't presume that the reason that it doesn't appear= so much in the wild in clients is due to lack of interest. =C2=A0Maybe = some MUA authors could be approached for comment.

We looked several times at supporting DSN etc in our mail system, and = balked at some of the more onerous requirements.

A lot of the extension RFCs have onerous requirements for interfacing with= non-supporting systems. =C2=A08BITMIME springs to mind here. =C2=A0So we= are binary safe (even embedded NULLs), but don't advertise 8BITMIME due= to not wanting to take on the responsibility of what to do when forwarding= to another server that doesn't advertise it. =C2=A0Maybe that just makes= us lame. =C2=A0Probably should revisit both these.

<= div>But we probably aren't the only ones either.

Adrien


------ Original Message ------
From: "Paul Smith" <paul@pscs.co= .uk>
To: "jmap@ietf.org" <jmap@ietf.org= >
Sent: 25/04/2017 8:33:24 PM
Subject: Re: [Jmap] Address Validation (was Re: Submission)
=
On 24/04/2017 20:25, Ted Lemon wrote:
=20 On Apr 24, 2017, at 12:14 PM, Arnt Gulbrandsen <arnt@gulbrand= sen.priv.no> wrote:
However, the question= that I understood was asked upthread is roughly "to which recipients has x been delivered already?", and for that particular question an unbroken implementation chain is needed from sender to recipient.

I think even knowing that the MTA for the admin domain of the JMAP server has successfully forwarded the message would be sufficient to be equivalent in most cases. =C2=A0 If someo= ne does more, that's great, but best is the enemy of good enough.

I may be wrong, but I believe you can already do that with DSN/MDNs. However, I have yet to see an MUA which does it even though it doesn't seem like it'd be that hard to do with the MUA requesting success DSNs and parsing the responses.

Maybe the JMAP server could handle the responses and somehow link the status to the sent message?


=C2=A0 =09
--------=_MB37C6EF3D-5B7C-44B8-9DC3-9326C4E5C0F0-- From nobody Tue Apr 25 02:56:21 2017 Return-Path: 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 C5721129C2F for ; Tue, 25 Apr 2017 02:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 oKAa-yRO-CD0 for ; Tue, 25 Apr 2017 02:56:17 -0700 (PDT) Received: from mail.pscs.co.uk (mail.pscs.co.uk [188.65.177.237]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE6BE129BF3 for ; Tue, 25 Apr 2017 02:56:16 -0700 (PDT) Authentication-Results: mail.pscs.co.uk; spf=none; auth=pass (cram-md5) smtp.auth=paul Received: from lmail.pscs.co.uk ([82.68.5.206]) by mail.pscs.co.uk ([188.65.177.237] running VPOP3) with ESMTP; Tue, 25 Apr 2017 10:55:51 +0100 Authentication-Results: lmail.pscs.co.uk; spf=none; auth=pass (cram-md5) smtp.auth=paul Received: from [192.168.66.101] ([192.168.66.101]) by lmail.pscs.co.uk ([192.168.66.70] running VPOP3) with ESMTPSA; Tue, 25 Apr 2017 10:50:44 +0100 To: Adrien de Croy ,"jmap@ietf.org" References: <1492996915.3310412.953749536.0F1C8B46@webmail.messagingengine.com> <20170424014957.39235.qmail@ary.lan> <6319482c-e53f-4483-870b-844e23030f8c@gulbrandsen.priv.no> From: Paul Smith Message-ID: <1702cc09-1d91-b9e8-0fbc-027981f8cb40@pscs.co.uk> Date: Tue, 25 Apr 2017 10:50:43 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------9EFAA5EF96ACDBF04482B318" X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V7.2 - Registered X-Organisation: Paul Smith Computer Services X-VPOP3Tester: 12 345 X-Authenticated-Sender: paul Archived-At: Subject: Re: [Jmap] Address Validation (was Re: Submission) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 09:56:20 -0000 This is a multi-part message in MIME format. --------------9EFAA5EF96ACDBF04482B318 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 25/04/2017 10:26, Adrien de Croy wrote: > > I think the problem with lack of support for MDN / DSN in clients may > be due to lack of implementation in the network of support for it. > > If there's still a significant number of deployed systems that don't > support it, then clients have increased doubts about its worth. > Chicken and egg issue again. > > I wouldn't presume that the reason that it doesn't appear so much in > the wild in clients is due to lack of interest. Maybe some MUA > authors could be approached for comment. > > We looked several times at supporting DSN etc in our mail system, and > balked at some of the more onerous requirements. DSN wasn't that hard when we implemented it (many years ago so I've forgotten details). It wasn't trivial either (we had to change the way envelope data was stored), but there are some things which have been far more onerous (it's a 'separate' thing, so potential breaking effects in other code are limited - unlike full 8 bit support which affects pretty much everything). But - if DSN is hard to implement, then any 'delivery status' type thing could be similarly hard so may affect JMAP implementation if delivery status is a mandatory part of that standard. > A lot of the extension RFCs have onerous requirements for interfacing > with non-supporting systems. 8BITMIME springs to mind here. So we > are binary safe (even embedded NULLs), but don't advertise 8BITMIME > due to not wanting to take on the responsibility of what to do when > forwarding to another server that doesn't advertise it. Maybe that > just makes us lame. Probably should revisit both these. We support 8 bit, but not embedded NULLs. Changing that would be a big thing (probably not to implement in the message store, but to just to test (and write new tests for) EVERYTHING that looks at the data). We've thought about it, but since we probably wouldn't advertise 8BITMIME anyway, for the reasons you say, it's easier just not to potentially break things by supporting NULL characters ;-) To me, having to rewrite messages is a really bad idea (DKIM etc), so 8BITMIME just isn't worth doing now. If we were designing SMTP nowadays, obviously full 8 bit support would be mandatory, but we're not. --------------9EFAA5EF96ACDBF04482B318 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 25/04/2017 10:26, Adrien de Croy wrote:

I think the problem with lack of support for MDN / DSN in clients may be due to lack of implementation in the network of support for it.

If there's still a significant number of deployed systems that don't support it, then clients have increased doubts about its worth.  Chicken and egg issue again.

I wouldn't presume that the reason that it doesn't appear so much in the wild in clients is due to lack of interest.  Maybe some MUA authors could be approached for comment.

We looked several times at supporting DSN etc in our mail system, and balked at some of the more onerous requirements.

DSN wasn't that hard when we implemented it (many years ago so I've forgotten details). It wasn't trivial either (we had to change the way envelope data was stored), but there are some things which have been far more onerous (it's a 'separate' thing, so potential breaking effects in other code are limited - unlike full 8 bit support which affects pretty much everything).

But - if DSN is hard to implement, then any 'delivery status' type thing could be similarly hard so may affect JMAP implementation if delivery status is a mandatory part of that standard.


A lot of the extension RFCs have onerous requirements for interfacing with non-supporting systems.  8BITMIME springs to mind here.  So we are binary safe (even embedded NULLs), but don't advertise 8BITMIME due to not wanting to take on the responsibility of what to do when forwarding to another server that doesn't advertise it.  Maybe that just makes us lame.  Probably should revisit both these.

We support 8 bit, but not embedded NULLs. Changing that would be a big thing (probably not to implement in the message store, but to just to test (and write new tests for) EVERYTHING that looks at the data). We've thought about it, but since we probably wouldn't advertise 8BITMIME anyway, for the reasons you say, it's easier just not to potentially break things by supporting NULL characters ;-)

To me, having to rewrite messages is a really bad idea (DKIM etc), so 8BITMIME just isn't worth doing now. If we were designing SMTP nowadays, obviously full 8 bit support would be mandatory, but we're not.


 
--------------9EFAA5EF96ACDBF04482B318-- From nobody Tue Apr 25 04:50:22 2017 Return-Path: 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 06FDD12EC33 for ; Tue, 25 Apr 2017 04:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.22 X-Spam-Level: X-Spam-Status: No, score=-1.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=WrM9rEnT; dkim=pass (1536-bit key) header.d=taugh.com header.b=W9ukaM58 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 S0AP6yqVIYO1 for ; Tue, 25 Apr 2017 04:50:19 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 852BC12EC2C for ; Tue, 25 Apr 2017 04:50:19 -0700 (PDT) Received: (qmail 48004 invoked from network); 25 Apr 2017 11:50:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=bb82.58ff37fa.k1704; bh=1LMB99LW9GIPy5+c1rf38HA94okZf7EQPFZe7OSKF8o=; b=WrM9rEnTkZQgis+ZkoHOA6K8blJNplTS21yBb5NTDdtdSJMQLUYpsyZuqk0n+5DmuXD08jB8lG7VGfAGRYTzwrqy/4LIdKydqs0gOaYCS8d27hLNXhXXAT+LerqVoE5CvjEhtu9577oNIoCGRge+pgZfD0wygGmqG0Z/FP4bMeeY/iLRrdDm2uLI/RFcV32oiQthls90E1j8Ltwh6TRhycTjuOBIYyLRIE1xOUdb8Twtzz69rjR3Iekf7eOUPkCB DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=bb82.58ff37fa.k1704; bh=1LMB99LW9GIPy5+c1rf38HA94okZf7EQPFZe7OSKF8o=; b=W9ukaM58I4Buac70BXTojaum7ohygPFNnavUkIgDMOpjaFLkVemeeuMkFUUHUNWsemq4Dvr+IAf++uDdninTj3u0AuVjehHVAzIp2SGn+yvxG74tXGuIg//lNDpCo9rePgEwXerksxHXZCt7D3IxKjj3WPdlydD1edTrwd2KG2GdfL5tjaZzLXg8KZdOP5dxeD3UNYHk7wyZ2ALOXn+8YFStRZp4faOhrFtBpuMPu9OsWlLyycBe5xSH4KlC+0Bx Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 25 Apr 2017 11:50:17 -0000 Date: 25 Apr 2017 07:51:29 -0400 Message-ID: From: "John R Levine" To: "Mads Hjorth" Cc: "jmap@ietf.org" In-Reply-To: <438DDABF-163A-421E-9A6A-84D3B53D5ADB@digst.dk> References: <20170421001702.24991.qmail@ary.lan> <438DDABF-163A-421E-9A6A-84D3B53D5ADB@digst.dk> User-Agent: Alpine 2.20 (OSX 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="0-1269714660-1493121089=:72072" Archived-At: Subject: Re: [Jmap] Submission X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 11:50:21 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1269714660-1493121089=:72072 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT > So… maybe prepare JMAP to help organizations go from email to registered email? In the US there are patents on registered electronic mail and at least one patent holder with a history of aggressive litigation. I would suggest staying away from it. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly --0-1269714660-1493121089=:72072-- From nobody Tue Apr 25 06:41:15 2017 Return-Path: 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 5C5E912944A for ; Tue, 25 Apr 2017 06:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 qDS08s1MLNQ4 for ; Tue, 25 Apr 2017 06:41:11 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 869A21270A7 for ; Tue, 25 Apr 2017 06:41:11 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id f76so64547166qke.2 for ; Tue, 25 Apr 2017 06:41:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=EgRrK4wL8NEE1FCnJ8njYOzFhpIjOiB+PlmZ9Z/t6Qs=; b=1dxPjujB2bY0IK6dL9D/y58nSKAnf7jiIyGHZYT4dLHHp86wLSBTh4oa3Fh84gBKG3 wxDUAz7ZCWRO4CqXJbDW69QJH45VvFkf/YmuW1C8PaFS+i2NgVM54yVsmqd+ZAyl6cIp fjEucqDFUu9EgqL33NZhmQLxfv6w6xJH9KC9WBZHB3PMHiuKjAdLDYek97JmlOemPGM8 KqyVtphw0U+PiaugViEszj9mxo37fosFOwH8cQkVSidbcjNBCOhind7//4RYURA4k85J QGVSjxOhRinVmzkGWL02VdTyAqaaZHewlnlcoReD3n64IVyW5C4uO2oDdjzwN6gAkDXA qvZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=EgRrK4wL8NEE1FCnJ8njYOzFhpIjOiB+PlmZ9Z/t6Qs=; b=C0Rw8N63M1Bu68AH2r6+B9+8bJrp8LBKtwPrv9mVnVBXpZs1pijmgqj1J4EwGcxJMu W9ikIzutPqe7mOYEh3JtFox0GNp2dl6WJLeHYKQoEXi+q0uSiZwXVd+QVSgYd8v1EtkF NIvnnHx4BVs1GuippN5idb8QoAKtAv4mcPfGtz+oGGP9a4yjuj91FEttVpp2TLONDrkG JP68Ans6ZpQ+9eTP/VbGFzZh1EK+9QVeHV9kAUPpvMdKrmqNiAtdlYdZrStTstNRm1u7 FMmin5M2qTrhmKBqUsNBAFtr+7mxZN7JyY+AHzqW1gJWikb1E01zISzTZouBgAnfuVOA f3hw== X-Gm-Message-State: AN3rC/4Z5ghaEYY4V2eHGY7JC0NbfrAEU3gXtgGKTT/7HItFbPmw9Zkt jB8Z6JrZTLwNH1GLFKQ= X-Received: by 10.55.165.132 with SMTP id o126mr10833285qke.95.1493127670667; Tue, 25 Apr 2017 06:41:10 -0700 (PDT) Received: from macbook-pro-6.home.arpa (pool-108-31-94-75.washdc.fios.verizon.net. [108.31.94.75]) by smtp.gmail.com with ESMTPSA id u8sm15135794qtb.55.2017.04.25.06.41.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Apr 2017 06:41:09 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_4F0B8B3D-D6DD-4672-B28D-D6164F8DB51A" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 25 Apr 2017 09:41:08 -0400 In-Reply-To: Cc: jmap@ietf.org To: Paul Smith References: <1492996915.3310412.953749536.0F1C8B46@webmail.messagingengine.com> <20170424014957.39235.qmail@ary.lan> <6319482c-e53f-4483-870b-844e23030f8c@gulbrandsen.priv.no> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Jmap] Address Validation (was Re: Submission) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 13:41:13 -0000 --Apple-Mail=_4F0B8B3D-D6DD-4672-B28D-D6164F8DB51A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 25, 2017, at 4:33 AM, Paul Smith wrote: > I may be wrong, but I believe you can already do that with DSN/MDNs. = However, I have yet to see an MUA which does it even though it doesn't = seem like it'd be that hard to do with the MUA requesting success DSNs = and parsing the responses. One of the stated goals of the JMAP work is to remove one of the major = pain points in writing MUAs: IMAP (specifically the lack of consistent = implementation, which causes interop issues). So perhaps we will see = more MUA innovation. --Apple-Mail=_4F0B8B3D-D6DD-4672-B28D-D6164F8DB51A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Apr 25, 2017, at 4:33 AM, Paul Smith <paul@pscs.co.uk> = wrote:
I may be wrong, but I believe you can already do = that with DSN/MDNs. However, I have yet to see an MUA which does it even = though it doesn't seem like it'd be that hard to do with the MUA = requesting success DSNs and parsing the responses.

One = of the stated goals of the JMAP work is to remove one of the major pain = points in writing MUAs: IMAP (specifically the lack of consistent = implementation, which causes interop issues).   So perhaps we will = see more MUA innovation.

= --Apple-Mail=_4F0B8B3D-D6DD-4672-B28D-D6164F8DB51A-- From nobody Tue Apr 25 06:53:42 2017 Return-Path: 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 004CA12F3D6 for ; Tue, 25 Apr 2017 06:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 bVpQaphlQrrA for ; Tue, 25 Apr 2017 06:53:37 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73528129BEC for ; Tue, 25 Apr 2017 06:53:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id BA17B6AEF7D6; Tue, 25 Apr 2017 09:53:36 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-nOln0QSSvp; Tue, 25 Apr 2017 09:53:36 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.44.178.52]) by daboo.name (Postfix) with ESMTPSA id 58A106AEF7CB; Tue, 25 Apr 2017 09:53:35 -0400 (EDT) Date: Tue, 25 Apr 2017 09:53:33 -0400 From: Cyrus Daboo To: Adrien de Croy , Paul Smith , jmap@ietf.org Message-ID: In-Reply-To: References: <1492996915.3310412.953749536.0F1C8B46@webmail.messagingengine.com> <20170424014957.39235.qmail@ary.lan> <6319482c-e53f-4483-870b-844e23030f8c@gulbrandsen.priv.no> X-Mailer: Mulberry/4.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=1197 Archived-At: Subject: Re: [Jmap] Address Validation (was Re: Submission) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 13:53:41 -0000 Hi Adrien, --On April 25, 2017 at 9:26:20 AM +0000 Adrien de Croy wrote: > I think the problem with lack of support for MDN / DSN in clients may be > due to lack of implementation in the network of support for it. > > If there's still a significant number of deployed systems that don't > support it, then clients have increased doubts about its worth. Chicken > and egg issue again. > > I wouldn't presume that the reason that it doesn't appear so much in the > wild in clients is due to lack of interest. Maybe some MUA authors could > be approached for comment. Yup, I implemented DSN and MDM in Mulberry - but as you say, due to the fact that there is no guarantee that status will be returned, it is not very useful in the general case. I can't remember the last time I used DSN - but I'll try it out on this message just to see what happens! However, there some environments where it may be useful - e.g. an enterprise which has a required policy to enforce MDM read receipt or DSN success (something that could be controlled via device management restrictions). I doubt it is something that would ever be useful for a non-enterprise system. -- Cyrus Daboo From nobody Tue Apr 25 07:07:42 2017 Return-Path: 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 0248212946F for ; Tue, 25 Apr 2017 07:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.622 X-Spam-Level: X-Spam-Status: No, score=-2.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 gdqeb42fAntq for ; Tue, 25 Apr 2017 07:07:38 -0700 (PDT) Received: from mail.pscs.co.uk (mail.pscs.co.uk [188.65.177.237]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBA9712F3D3 for ; Tue, 25 Apr 2017 07:07:35 -0700 (PDT) Authentication-Results: mail.pscs.co.uk; spf=none; auth=pass (cram-md5) smtp.auth=paul Received: from lmail.pscs.co.uk ([82.68.5.206]) by mail.pscs.co.uk ([188.65.177.237] running VPOP3) with ESMTP; Tue, 25 Apr 2017 15:07:23 +0100 Authentication-Results: lmail.pscs.co.uk; spf=none; auth=pass (cram-md5) smtp.auth=paul Received: from [192.168.66.101] ([192.168.66.101]) by lmail.pscs.co.uk ([192.168.66.70] running VPOP3) with ESMTPSA; Tue, 25 Apr 2017 15:01:32 +0100 To: Cyrus Daboo , Adrien de Croy , jmap@ietf.org References: <1492996915.3310412.953749536.0F1C8B46@webmail.messagingengine.com> <20170424014957.39235.qmail@ary.lan> <6319482c-e53f-4483-870b-844e23030f8c@gulbrandsen.priv.no> From: Paul Smith Message-ID: Date: Tue, 25 Apr 2017 15:01:31 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V7.2 - Registered X-Organisation: Paul Smith Computer Services X-VPOP3Tester: 12 345 X-Authenticated-Sender: paul Archived-At: Subject: Re: [Jmap] Address Validation (was Re: Submission) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 14:07:41 -0000 On 25/04/2017 14:53, Cyrus Daboo wrote: > > Yup, I implemented DSN and MDM in Mulberry - but as you say, due to > the fact that there is no guarantee that status will be returned, it > is not very useful in the general case. I can't remember the last time > I used DSN - but I'll try it out on this message just to see what > happens! > > However, there some environments where it may be useful - e.g. an > enterprise which has a required policy to enforce MDM read receipt or > DSN success (something that could be controlled via device management > restrictions). I doubt it is something that would ever be useful for a > non-enterprise system. The original statement was something like "it would be useful to know that the submission server has sent the message out". It seems to me that DSN would meet that requirement, especially if the MUA or JMAP server parsed the MDN and flagged the message appropriately. Of course, if the server doesn't support DSN, then it won't help - but you'd need some support from the server to handle delivery notifications of any type, so why not DSN? (BTW, did you receive the "delivered" MDN from our server from the DSN request? It looks like it left here OK) From nobody Tue Apr 25 07:12:43 2017 Return-Path: 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 BA44012ECA6 for ; Tue, 25 Apr 2017 07:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 ugMc2rh4Gwwo for ; Tue, 25 Apr 2017 07:12:41 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0692130889 for ; Tue, 25 Apr 2017 07:12:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 681166AEFEC1; Tue, 25 Apr 2017 10:12:35 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lnCs8RbfLAg3; Tue, 25 Apr 2017 10:12:32 -0400 (EDT) Received: from [17.44.178.123] (unknown [17.44.178.123]) by daboo.name (Postfix) with ESMTPSA id A5D6D6AEFEB5; Tue, 25 Apr 2017 10:12:31 -0400 (EDT) Date: Tue, 25 Apr 2017 10:12:30 -0400 From: Cyrus Daboo To: Paul Smith , Adrien de Croy , jmap@ietf.org Message-ID: <129D134A09971EC26CEF9853@cyrus.local> In-Reply-To: References: <1492996915.3310412.953749536.0F1C8B46@webmail.messagingengine.com> <20170424014957.39235.qmail@ary.lan> <6319482c-e53f-4483-870b-844e23030f8c@gulbrandsen.priv.no> X-Mailer: Mulberry/4.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=549 Archived-At: Subject: Re: [Jmap] Address Validation (was Re: Submission) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 14:12:43 -0000 Hi Paul, --On April 25, 2017 at 3:01:31 PM +0100 Paul Smith wrote: > (BTW, did you receive the "delivered" MDN from our server from the DSN > request? It looks like it left here OK) Your server gave me a "delivered" status. For Adrien and ietf.org I only got a "relayed" status from my own server. I think the later is not very useful as I expect my own server to be reliable, and if not expect to know about problems pretty quickly. Note, I only used DSN on the last message - I'll try an MDM on this one. -- Cyrus Daboo From nobody Tue Apr 25 07:40:47 2017 Return-Path: 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 DE37C131BA0 for ; Tue, 25 Apr 2017 07:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 rLtdutinXAK9 for ; Tue, 25 Apr 2017 07:40:35 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [122.56.26.1]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5BEA1314F4 for ; Tue, 25 Apr 2017 07:37:53 -0700 (PDT) Received: From [192.168.1.146] (unverified [192.168.1.146]) by SMTP Server [192.168.1.3] (WinGate SMTP Receiver v9.0.5 (Build 5926)) with SMTP id <0001029713@smtp.qbik.com>; Wed, 26 Apr 2017 02:37:50 +1200 From: "Adrien de Croy" To: "Paul Smith" , "Cyrus Daboo" , "jmap@ietf.org" Date: Tue, 25 Apr 2017 14:37:50 +0000 Message-Id: In-Reply-To: References: <1492996915.3310412.953749536.0F1C8B46@webmail.messagingengine.com> <20170424014957.39235.qmail@ary.lan> <6319482c-e53f-4483-870b-844e23030f8c@gulbrandsen.priv.no> Reply-To: "Adrien de Croy" User-Agent: eM_Client/7.0.27943.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Jmap] Address Validation (was Re: Submission) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 14:40:40 -0000 I'd expect a lot of servers don't honour SUCCESS DSNs for a number of=20 reasons (privacy, spam avalanche etc). Cyrus: Relayed is what I'd expect when forwarding to a server that=20 doesn't support DSN (us), so that's expected. Adrien ------ Original Message ------ From: "Paul Smith" To: "Cyrus Daboo" ; "Adrien de Croy"=20 ; "jmap@ietf.org" Sent: 26/04/2017 2:01:31 AM Subject: Re: [Jmap] Address Validation (was Re: Submission) >On 25/04/2017 14:53, Cyrus Daboo wrote: >> >>Yup, I implemented DSN and MDM in Mulberry - but as you say, due to=20 >>the fact that there is no guarantee that status will be returned, it=20 >>is not very useful in the general case. I can't remember the last time= =20 >>I used DSN - but I'll try it out on this message just to see what=20 >>happens! >> >>However, there some environments where it may be useful - e.g. an=20 >>enterprise which has a required policy to enforce MDM read receipt or=20 >>DSN success (something that could be controlled via device management=20 >>restrictions). I doubt it is something that would ever be useful for a= =20 >>non-enterprise system. > >The original statement was something like "it would be useful to know=20 >that the submission server has sent the message out". It seems to me=20 >that DSN would meet that requirement, especially if the MUA or JMAP=20 >server parsed the MDN and flagged the message appropriately. > >Of course, if the server doesn't support DSN, then it won't help - but=20 >you'd need some support from the server to handle delivery=20 >notifications of any type, so why not DSN? > >(BTW, did you receive the "delivered" MDN from our server from the DSN=20 >request? It looks like it left here OK) > > > > > >_______________________________________________ >Jmap mailing list >Jmap@ietf.org >https://www.ietf.org/mailman/listinfo/jmap From nobody Tue Apr 25 08:03:32 2017 Return-Path: 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 C7D7D131BA8 for ; Tue, 25 Apr 2017 08:03:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.622 X-Spam-Level: X-Spam-Status: No, score=-2.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 E-qk1CIDHSNc for ; Tue, 25 Apr 2017 08:03:29 -0700 (PDT) Received: from mail.pscs.co.uk (mail.pscs.co.uk [188.65.177.237]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A143131B95 for ; Tue, 25 Apr 2017 08:03:03 -0700 (PDT) Authentication-Results: mail.pscs.co.uk; spf=none; auth=pass (cram-md5) smtp.auth=paul Received: from lmail.pscs.co.uk ([82.68.5.206]) by mail.pscs.co.uk ([188.65.177.237] running VPOP3) with ESMTP; Tue, 25 Apr 2017 16:02:47 +0100 Authentication-Results: lmail.pscs.co.uk; spf=none; auth=pass (cram-md5) smtp.auth=paul Received: from [192.168.66.101] ([192.168.66.101]) by lmail.pscs.co.uk ([192.168.66.70] running VPOP3) with ESMTPSA; Tue, 25 Apr 2017 15:57:11 +0100 To: Adrien de Croy , Cyrus Daboo ,"jmap@ietf.org" References: <1492996915.3310412.953749536.0F1C8B46@webmail.messagingengine.com> <20170424014957.39235.qmail@ary.lan> <6319482c-e53f-4483-870b-844e23030f8c@gulbrandsen.priv.no> From: Paul Smith Message-ID: Date: Tue, 25 Apr 2017 15:57:10 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V7.2 - Registered X-Organisation: Paul Smith Computer Services X-VPOP3Tester: 12 345 X-Authenticated-Sender: paul Archived-At: Subject: Re: [Jmap] Address Validation (was Re: Submission) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 15:03:31 -0000 On 25/04/2017 15:37, Adrien de Croy wrote: > > I'd expect a lot of servers don't honour SUCCESS DSNs for a number of > reasons (privacy, spam avalanche etc). I'm not sure of that - is it any worse than accepting a message with a 2xx response? 'Delivered' means it has been dumped in a user's mailbox, not that it has been read or anything so it doesn't give any more information other than the final SMTP server accepting the message. If it does cause problems, those would probably happen for any scalable delivery notification system dreamt up for JMAP as well. From nobody Tue Apr 25 08:03:43 2017 Return-Path: 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 C5D79131B95 for ; Tue, 25 Apr 2017 08:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 nCaeDlPCWcu4 for ; Tue, 25 Apr 2017 08:03:30 -0700 (PDT) Received: from mail.pscs.co.uk (mail.pscs.co.uk [188.65.177.237]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58AE7131B96 for ; Tue, 25 Apr 2017 08:03:04 -0700 (PDT) Authentication-Results: mail.pscs.co.uk; spf=none; auth=pass (cram-md5) smtp.auth=paul Received: from lmail.pscs.co.uk ([82.68.5.206]) by mail.pscs.co.uk ([188.65.177.237] running VPOP3) with ESMTP; Tue, 25 Apr 2017 15:52:30 +0100 Authentication-Results: lmail.pscs.co.uk; spf=none; auth=pass (cram-md5) smtp.auth=paul Received: from [192.168.66.101] ([192.168.66.101]) by lmail.pscs.co.uk ([192.168.66.70] running VPOP3) with ESMTPSA; Tue, 25 Apr 2017 15:46:35 +0100 To: Cyrus Daboo , Adrien de Croy , jmap@ietf.org References: <1492996915.3310412.953749536.0F1C8B46@webmail.messagingengine.com> <20170424014957.39235.qmail@ary.lan> <6319482c-e53f-4483-870b-844e23030f8c@gulbrandsen.priv.no> <129D134A09971EC26CEF9853@cyrus.local> From: Paul Smith Message-ID: <37be91b9-21c9-87f5-10a4-c7f05357c940@pscs.co.uk> Date: Tue, 25 Apr 2017 15:46:34 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <129D134A09971EC26CEF9853@cyrus.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V7.2 - Registered X-Organisation: Paul Smith Computer Services X-VPOP3Tester: 12 345 X-Authenticated-Sender: paul Archived-At: Subject: Re: [Jmap] Address Validation (was Re: Submission) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 15:03:32 -0000 On 25/04/2017 15:12, Cyrus Daboo wrote: > Hi Paul, > > --On April 25, 2017 at 3:01:31 PM +0100 Paul Smith > wrote: > >> (BTW, did you receive the "delivered" MDN from our server from the DSN >> request? It looks like it left here OK) > > Your server gave me a "delivered" status. Good :-) Does Mulberry indicate this in the 'sent items' folder somehow? I think that's what users would like (?) (I haven't used Mulberry for a while - IIRC, it disappeared for a while some time ago, and I hadn't realised it had come back...) > I think the later is not very useful as I expect my own server to be > reliable, and if not expect to know about problems pretty quickly. Agreed, but that's what the earlier person was saying would be good. For the average user it tells them that THEIR mail server has sent the message out, which is the best you can expect if the onward server doesn't support any form of notification. If the 'sent items' folder indicates somehow when messages have been sent out by the MSA (or delivered to the recipient if possible) then I can see that would help usability. From nobody Tue Apr 25 09:06:54 2017 Return-Path: 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 C7A481293F8 for ; Tue, 25 Apr 2017 09:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 bEbAFiW0nN27 for ; Tue, 25 Apr 2017 09:06:50 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [122.56.26.1]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D30312F280 for ; Tue, 25 Apr 2017 09:06:30 -0700 (PDT) Received: From [192.168.1.146] (unverified [192.168.1.146]) by SMTP Server [192.168.1.3] (WinGate SMTP Receiver v9.0.5 (Build 5926)) with SMTP id <0001029818@smtp.qbik.com>; Wed, 26 Apr 2017 04:06:26 +1200 From: "Adrien de Croy" To: "Paul Smith" , "Cyrus Daboo" , "jmap@ietf.org" Date: Tue, 25 Apr 2017 16:06:27 +0000 Message-Id: In-Reply-To: References: <1492996915.3310412.953749536.0F1C8B46@webmail.messagingengine.com> <20170424014957.39235.qmail@ary.lan> <6319482c-e53f-4483-870b-844e23030f8c@gulbrandsen.priv.no> Reply-To: "Adrien de Croy" User-Agent: eM_Client/7.0.27943.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Jmap] Address Validation (was Re: Submission) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 16:06:53 -0000 ------ Original Message ------ From: "Paul Smith" To: "Adrien de Croy" ; "Cyrus Daboo"=20 ; "jmap@ietf.org" Sent: 26/04/2017 2:57:10 AM Subject: Re: [Jmap] Address Validation (was Re: Submission) >On 25/04/2017 15:37, Adrien de Croy wrote: >> >>I'd expect a lot of servers don't honour SUCCESS DSNs for a number of=20 >>reasons (privacy, spam avalanche etc). > >I'm not sure of that - is it any worse than accepting a message with a=20 >2xx response? it sure is, especially if the return path is invalid / spoofed / victim. It's a whole new email, rather than a protocol response code. >'Delivered' means it has been dumped in a user's mailbox, not that it=20 >has been read or anything so it doesn't give any more information other= =20 >than the final SMTP server accepting the message. > >If it does cause problems, those would probably happen for any scalable= =20 >delivery notification system dreamt up for JMAP as well. If it uses emails for messages yes. Which it probably would. Adrien > > > > > >_______________________________________________ >Jmap mailing list >Jmap@ietf.org >https://www.ietf.org/mailman/listinfo/jmap From nobody Tue Apr 25 09:23:53 2017 Return-Path: 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 56D0113166D for ; Tue, 25 Apr 2017 09:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.622 X-Spam-Level: X-Spam-Status: No, score=-2.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 S9XGb7f8leH7 for ; Tue, 25 Apr 2017 09:23:46 -0700 (PDT) Received: from mail.pscs.co.uk (mail.pscs.co.uk [188.65.177.237]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CDA813165B for ; Tue, 25 Apr 2017 09:23:44 -0700 (PDT) Authentication-Results: mail.pscs.co.uk; spf=none; auth=pass (cram-md5) smtp.auth=paul Received: from lmail.pscs.co.uk ([82.68.5.206]) by mail.pscs.co.uk ([188.65.177.237] running VPOP3) with ESMTP; Tue, 25 Apr 2017 17:23:32 +0100 Authentication-Results: lmail.pscs.co.uk; spf=none; auth=pass (cram-md5) smtp.auth=paul Received: from [192.168.66.101] ([192.168.66.101]) by lmail.pscs.co.uk ([192.168.66.70] running VPOP3) with ESMTPSA; Tue, 25 Apr 2017 17:18:08 +0100 To: Adrien de Croy ,"jmap@ietf.org" References: <1492996915.3310412.953749536.0F1C8B46@webmail.messagingengine.com> <20170424014957.39235.qmail@ary.lan> <6319482c-e53f-4483-870b-844e23030f8c@gulbrandsen.priv.no> From: Paul Smith Message-ID: <6a74e88a-8376-9879-a918-5b9a3d8a4802@pscs.co.uk> Date: Tue, 25 Apr 2017 17:18:07 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V7.2 - Registered X-Organisation: Paul Smith Computer Services X-VPOP3Tester: 12 345 X-Authenticated-Sender: paul Archived-At: Subject: Re: [Jmap] Address Validation (was Re: Submission) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 16:23:48 -0000 On 25/04/2017 17:06, Adrien de Croy wrote: > On 25/04/2017 15:37, Adrien de Croy wrote: >>> >>> I'd expect a lot of servers don't honour SUCCESS DSNs for a number >>> of reasons (privacy, spam avalanche etc). >> >> I'm not sure of that - is it any worse than accepting a message with >> a 2xx response? > > it sure is, especially if the return path is invalid / spoofed / victim. > > It's a whole new email, rather than a protocol response code. Well, you'd get the same effect with RELAYED/FAILED DSNs... I'm not sure the fact that it's a SUCCESS DSN would make any difference as far as that goes. (BATV FTW?) > If it uses emails for messages yes. Which it probably would. It'd pretty much have to use messages if it was to be scalable. From nobody Tue Apr 25 10:20:40 2017 Return-Path: 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 F34F71316E9 for ; Tue, 25 Apr 2017 10:20:38 -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 GTUDBBcAi4SY for ; Tue, 25 Apr 2017 10:20:34 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 2E6571316F0 for ; Tue, 25 Apr 2017 10:19:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1493140790; d=isode.com; s=june2016; i=@isode.com; bh=q9nUHDdJ17ekcdbFPfA/Wqq+X90Wt0AD3Zf2Vs1MbGo=; 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=mIBSzyubpi0qvK4ec7+DThoQkXX5wQZmmhZDgKT2rHr9P39dDe+Z5IC74kHm2AhUVfJYf4 q5a2x9r8nQ9WitdvAeRTCeSEniZsAbYzl7n/hTvaKHYpvCE6PUm7GNn9gifA8NcTxZwXBa JZa1AFYT7AMnICZs5RE8cPmz9ryalGw=; Received: from [192.168.8.184] ((unknown) [82.113.183.179]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 25 Apr 2017 18:19:49 +0100 X-SMTP-Protocol-Errors: NORDNS PIPELINING From: Alexey Melnikov X-Mailer: iPad Mail (14A456) In-Reply-To: Date: Tue, 25 Apr 2017 18:41:04 +0100 Cc: Paul Smith , jmap@ietf.org Message-Id: <329861C7-3822-4587-AE04-A6C28982BEDD@isode.com> References: <1492996915.3310412.953749536.0F1C8B46@webmail.messagingengine.com> <20170424014957.39235.qmail@ary.lan> <6319482c-e53f-4483-870b-844e23030f8c@gulbrandsen.priv.no> To: Ted Lemon MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=Apple-Mail-EA048C24-7364-40FD-8779-44F677A6A820 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Jmap] Address Validation (was Re: Submission) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 17:20:39 -0000 --Apple-Mail-EA048C24-7364-40FD-8779-44F677A6A820 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On 25 Apr 2017, at 14:41, Ted Lemon wrote: >=20 >> On Apr 25, 2017, at 4:33 AM, Paul Smith wrote: >> I may be wrong, but I believe you can already do that with DSN/MDNs. Howe= ver, I have yet to see an MUA which does it even though it doesn't seem like= it'd be that hard to do with the MUA requesting success DSNs and parsing th= e responses. I've done this in a MUA that talks IMAP. While further integration in JMAP w= ould be nice, I don't think this is either hard or that it is the first orde= r of priorities for this group. > One of the stated goals of the JMAP work is to remove one of the major pai= n points in writing MUAs: IMAP (specifically the lack of consistent implemen= tation, which causes interop issues). So perhaps we will see more MUA inno= vation. --Apple-Mail-EA048C24-7364-40FD-8779-44F677A6A820 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On 25 Apr 20= 17, at 14:41, Ted Lemon <mellon@fugue= .com> wrote:

On Apr 25, 20= 17, at 4:33 AM, Paul Smith <paul@pscs.co.uk> wrote:
I may be wrong, but I believe you can already do that with DSN/MDNs. Howe= ver, I have yet to see an MUA which does it even though it doesn't seem like= it'd be that hard to do with the MUA requesting success DSNs and parsing th= e responses.

I've done this in a MUA that talks IMAP. While furt= her integration in JMAP would be nice, I don't think this is either hard or t= hat it is the first order of priorities for this group.

One of the stated goals of the JMAP work i= s to remove one of the major pain points in writing MUAs: IMAP (specifically= the lack of consistent implementation, which causes interop issues).  = So perhaps we will see more MUA innovation.
<= /body>= --Apple-Mail-EA048C24-7364-40FD-8779-44F677A6A820-- From nobody Tue Apr 25 10:33:34 2017 Return-Path: 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 4FF6C131708 for ; Tue, 25 Apr 2017 10:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 oSd1I7eDCnFu for ; Tue, 25 Apr 2017 10:33:32 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CAA21316E6 for ; Tue, 25 Apr 2017 10:33:32 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v3PHXSru018133 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 25 Apr 2017 17:33:29 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v3PHXS07012346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 25 Apr 2017 17:33:28 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v3PHXRbF029433; Tue, 25 Apr 2017 17:33:28 GMT Received: from [10.145.239.182] (/10.145.239.182) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 25 Apr 2017 10:33:27 -0700 From: "Chris Newman" To: "Neil Jenkins" Cc: jmap@ietf.org Date: Tue, 25 Apr 2017 10:33:25 -0700 Message-ID: <45E4DC37-A0FA-4573-83B1-3701E0FE2A69@oracle.com> In-Reply-To: <1493087082.2882732.955078288.61343C16@webmail.messagingengine.com> References: <1492998899.3316920.953769616.254C9CBD@webmail.messagingengine.com> <1493084134.2830550.955039432.5403CAFB@webmail.messagingengine.com> <1493087082.2882732.955078288.61343C16@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Subject: Re: [Jmap] Draft messages - mutability X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 17:33:33 -0000 On 24 Apr 2017, at 19:24, Neil Jenkins wrote: > On Tue, 25 Apr 2017, at 12:18 PM, Chris Newman wrote: >> Why is it important to keep the same ID when modifying a draft? >> The approach draft-brandt-imap-replace uses is to include the new >> ID in the> response to the modification operation. > > That's great if you're only using one client to edit the draft. But > consider the following scenario: > 1. I start a draft on my laptop. I'm not finished, it's still open on > the screen and I just put the laptop to sleep. > 2. I continue editing on my phone. Maybe I finish and send it or > maybe I don't. > 3. I go back to my laptop, which immediately resyncs with the server > to > find out what's changed. > Now with immutable messages, all my laptop MUA can see is that the > draft > has been deleted from the server, but this might just mean there's a > newer version of the draft. I can see the newer draft but can't know > for > sure it's an update to the one I have open or not. So I can either > resave the draft that's open (which could cause a duplicate old draft > to > "reappear" in the Drafts mailbox), or I can just delete it and hope > for > the best (and the user can reopen the new draft if they still hadn't > finished sending). > > With mutable messages, I would see there's an update to the current > message I have open. If I know the user's last changes were saved to > the > server I would just fetch the update and immediately show this > instead. > If the user has made other changes then I know we have a split and I > can > prompt the user what they want to do. It's a much better user > experience. I'd prefer not to make the common-case resync more complicated just to handle the rare case of multiple clients editing a draft. But if you think it's important to handle that case, another option is to introduce a draft unique identifier that's preserved across replace operations; then the client can know that a new message is a new version of a previous draft and the problem is resolved without making common-case resync more complicated. - Chris From nobody Tue Apr 25 15:36:47 2017 Return-Path: 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 6511D1205F0 for ; Tue, 25 Apr 2017 15:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=teamaol.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 s46ngbYclV44 for ; Tue, 25 Apr 2017 15:36:45 -0700 (PDT) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4840C126B71 for ; Tue, 25 Apr 2017 15:36:45 -0700 (PDT) Received: by mail-it0-x235.google.com with SMTP id f187so23440332ite.1 for ; Tue, 25 Apr 2017 15:36:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=teamaol.com; s=google; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=4XfvpWAcBmXjK6TV3nHOBHU2ZWsZzicmHsdpjyZutuU=; b=NQlQElVFOj6cDEvvjTKN74FXJJINYc+xg0mBEjJd80SltQfIxh+s8NDWk0GcVyP6lG OE14USoveLlH7N19XDXCr9g4ZR33jZwxe5BinTiXsn0ehgzChXE3PJ+8ZPz+rAY9KjUQ Mvfavg7zRv79p37plVgVKH2wIpOZbVdJlToUWpTkzFNL/rMWflOdiHof8WgnHmnUxAp+ 5/cdnqcdR2r5h2A9WSSvVBeomqxFVZXO212en5S6YI2nOm82dR4XBko0YzPO1VcR8SXB lt+GS9bokf9RBWnZ6H5wDua1VA4RHhMa8q05AuIDCodgKdb9eoBAlXoXq8fxib5QfGao 8tKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=4XfvpWAcBmXjK6TV3nHOBHU2ZWsZzicmHsdpjyZutuU=; b=TjwM5yYbDsC6Rgzv0BRK07Ix/7sT+LMaKruNinTMayobe0dwN4/o7lJpF+Ku3A0Gh5 k4+uaSyRIJHi01bvCJD1eoLYEyx5Q6jAmYtycHBJpD6woVMNkxyq3hz5Elcpd03W+q61 wu+TnSD0JGxD/wXfT6S391+vxgaQsh8gMKUd2iaTKrk9jTtK7YO6g7WQRSgE7veg5Xza iGiU44UkRYObCyBhIgZpgRG33GKunrMsITcOFmOMNVu94HiGKQwQL/TnnfCFRAmPga/c MfNz8nk0NPFboVRjYxDctuDvjPIMJakNAqVF+iE5hXef5qaXqpwotmiuigor3fsyfDPS 4f+w== X-Gm-Message-State: AN3rC/7fEKO+vawueKQIDm4g4qm7DQqCtwMhcxDGP+Fvu1sC6KTFs8yU nC/9m7KUZR1tJqaO X-Received: by 10.36.92.84 with SMTP id q81mr8177876itb.46.1493159804520; Tue, 25 Apr 2017 15:36:44 -0700 (PDT) Received: from [10.172.167.84] ([64.236.138.3]) by smtp.gmail.com with ESMTPSA id i7sm720019iod.23.2017.04.25.15.36.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Apr 2017 15:36:43 -0700 (PDT) To: Ted Lemon , Neil Jenkins References: <1492998899.3316920.953769616.254C9CBD@webmail.messagingengine.com> <1493084134.2830550.955039432.5403CAFB@webmail.messagingengine.com> Cc: jmap@ietf.org, Bron Gondwana , Chris Newman From: Stu Brandt Message-ID: <818e7cf2-82fd-2101-227e-a6628dcad3ec@teamaol.com> Date: Tue, 25 Apr 2017 15:36:41 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Jmap] Draft messages - mutability X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 22:36:47 -0000 Agreed. Mutability opens the door to needing to sync only those body parts (or portions thereof) that changed since last sync point. It's also unlikely that a mutable content concept could be restricted to just "drafts" since there are all sorts of use cases around a user wanting to change the content of messages they received. In Alto, for example, once a user sees the photo stack the inevitable question is "how do I delete these old photos...I want to keep the email but without the photos". We can totally re-envision the mail store as a versioned document store, which I agree would be interesting, but that seems like a significant scope change for JMAP to cover it. And it seems like we have enough of that already. - Stuart On 4/24/17 7:00 PM, Ted Lemon wrote: > If drafts are mutable, the implication is that synchronization based on > message ID can't happen without something like a version modifier. At > which point why not make every message versioned? > > On Apr 24, 2017 9:35 PM, "Neil Jenkins" > wrote: > > __ > On Tue, 25 Apr 2017, at 11:02 AM, Chris Newman wrote: >> I see a lot of cost and no benefit to making a draft a different >> datatype from a message. > > I don't see any benefit to making it a different data type. However, > what we currently have is that, like IMAP, a message is immutable > except for flags/mailboxes. This is a pain for client authors trying > to keep track of a single draft as it is saved through multiple > revisions (especially when the user has multiple clients). One > possible solution to this is to simply say any message with the > \Draft flag set is fully mutable (while keeping the same id). I > think we would also want the server to enforce that a message cannot > be changed from/to draft state after creation. If it starts a draft > it stays a draft, or vice versa. > > From a protocol perspective, since most messages won't be drafts > (with a normal user) you still get the efficiency of immutable > messages (you only have to refetch flags/mailboxes, not the whole > message) for most of the messages in the mail store. But it will be > easier for MUAs to handle drafts, and particularly allow for a much > better experience when editing the same draft message across > multiple devices. > > Neil. > > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap > > > > > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap > From nobody Tue Apr 25 16:01:33 2017 Return-Path: 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 BAFB4126E01 for ; Tue, 25 Apr 2017 16:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 x_mDx5cIlssm for ; Tue, 25 Apr 2017 16:01:30 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 628041205F0 for ; Tue, 25 Apr 2017 16:01:30 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v3PN1OLI020592 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 25 Apr 2017 23:01:26 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v3PN1Obi032752 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 25 Apr 2017 23:01:24 GMT Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v3PN1O0c026730; Tue, 25 Apr 2017 23:01:24 GMT Received: from [10.145.239.182] (/10.145.239.182) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 25 Apr 2017 16:01:24 -0700 From: "Chris Newman" To: "Bron Gondwana" Cc: jmap@ietf.org Date: Tue, 25 Apr 2017 16:01:22 -0700 Message-ID: <33553450-82F4-4CB4-8679-C9F52D8A8839@oracle.com> In-Reply-To: <1493099769.3023399.955193288.6D0312CC@webmail.messagingengine.com> References: <46F700A6-C2B1-488B-A8B4-6ACD45B03C31@oracle.com> <1493099769.3023399.955193288.6D0312CC@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Subject: Re: [Jmap] Best vs Good enough - adoption of JMAP X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 23:01:32 -0000 On 24 Apr 2017, at 22:56, Bron Gondwana wrote: > On Tue, 25 Apr 2017, at 11:41, Chris Newman wrote: >> True, if the WG finds rough consensus around the outbox model despite >> my >> objections, then my implementation will have an always-empty outbox >> as >> that's the only way to implement it without infrastructure >> disruption. >> I'd prefer a JMAP design that allows me to provide delivery status UX >> without infrastructure disruption. > > Ahh, I see you already replied with this. Yeah, always-empty outbox > is my first plan too as a server implementer. It's what I did for the > proxy, since it doesn't have reliable storage. > > The reason to hold email in the outbox temporarily is to implement > both undo-send and delayed send, both of which are popular features in > new mail clients. We'll definitely do outbox-as-queue at FastMail > eventually. Our infrastructure already supports FUTURERELEASE and an undo send capability to go with it. I'd love to expose those features to mail clients. So if JMAP had a submission command with envelope options and an undo send command that keyed off the \Sent folder; it'd be no problem for our implementation to provide both delayed send and undo send as client features. But if JMAP has the outbox model that forces mailstore semantics and queue semantics to be combined in one object, that's a huge amount of extra work on the server so I'd opt for the always-empty outbox approach (mostly for the improved security and scalability of a much simpler implementation). So given we have at least two server implementers on the list who will do always-empty outbox for the first implementation, I think that begs the question of what's the more important feature for JMAP to offer: A) outbox model B) undo send and delayed send If B is more important than A, I think we need to replace the outbox model with a simpler submit/undo-submit model so it's easier for servers to provide those features to clients. - Chris From nobody Tue Apr 25 16:02:54 2017 Return-Path: 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 75E8612945C for ; Tue, 25 Apr 2017 16:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.719 X-Spam-Level: X-Spam-Status: No, score=-1.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=M2jYj0Al; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=exhMIHah 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 c-B_qrsKgycV for ; Tue, 25 Apr 2017 16:02:51 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14B1712785F for ; Tue, 25 Apr 2017 16:02:51 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 525E621161; Tue, 25 Apr 2017 19:02:50 -0400 (EDT) Received: from web4 ([10.202.2.214]) by compute6.internal (MEProxy); Tue, 25 Apr 2017 19:02:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=b+di7Trf7d9cxBCzxT6ENsklV/zxc M2n/9WD2XM8+J4=; b=M2jYj0AlFkHtxzxD9wnuxYW2OPURY+/hM17iEBLBbBZZB a4+zxvfqCG0LogFOrQ056rxOihudm2kGLCBVrPsoGktkqN5yJSbZlhkeQi+dn3ES ym2A1po6kYHjTLF68kl0P2arScYgPnDGr3PU4j+YDdkEqQDwfZ9KbR4melUS6WCW eWbxO3tkHLJQbh1IlBXHCTTojM4AwPERpPIviuhNcROQ/POY0N9p6i1tLZkYRp7W 0UX5tzPNZ2wawh6PBT36eLXoh5JN2ytQsaagvZI+wNwPslfrOhhOq05vZpRX1zfs DxDAbO9v+a5sfX7lyosvOBRXsxSQx//dWQ7M9qd9w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=b+di7T rf7d9cxBCzxT6ENsklV/zxcM2n/9WD2XM8+J4=; b=exhMIHahVHp5P5NgH2IQKV 3xqvfD0ihlyX+9e8N2gG9xTsHKmZwf68w+RdgaLABX81UC+httYrEWb9RmEw4o1O UFthmECC7pQyKBe3VjNPc6YWS9bX1vfOzK9WG96Iu++Mp0d32POPA7mnn7OQJ1hl +rRICJbwlmys3zmhIaOqT9vDU5fVmXFAwWqbYCFz3x3xLaLfmneZ3OBj/bIrV8wx IG7D5283riuVhoBQcLZiQz4pjUqn9sv83jTVyw0C+vM9RUaKzfHrWZob2dAWkiyx yBRIkeGDHujofTPRHaebf9WMbJVOIbfqk6DD/L8JLvt2yDltxixuXc47OBIJcrtw == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 2AB55BAB6F; Tue, 25 Apr 2017 19:02:50 -0400 (EDT) Message-Id: <1493161370.738031.956233680.34739D08@webmail.messagingengine.com> From: Bron Gondwana To: Stu Brandt , Ted Lemon , Neil Jenkins Cc: jmap@ietf.org, Chris Newman MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-29d47332 Date: Wed, 26 Apr 2017 09:02:50 +1000 In-Reply-To: <818e7cf2-82fd-2101-227e-a6628dcad3ec@teamaol.com> References: <1492998899.3316920.953769616.254C9CBD@webmail.messagingengine.com> <1493084134.2830550.955039432.5403CAFB@webmail.messagingengine.com> <818e7cf2-82fd-2101-227e-a6628dcad3ec@teamaol.com> Archived-At: Subject: Re: [Jmap] Draft messages - mutability X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 23:02:52 -0000 Yeah, we have a strip attachments feature at FastMail. Generates a new email with same body structure but the part for each attachment replaced with a short bit of text explaining that the attachment was stripped. It's a feature that is needed less now that quotas are gigabytes rather than handful of megabytes. The downside of the draft id is that you would need to search on it. The message object id will already have a fat index. Bron. On Wed, 26 Apr 2017, at 08:36, Stu Brandt wrote: > Agreed. Mutability opens the door to needing to sync only those body > parts (or portions thereof) that changed since last sync point. It's > also unlikely that a mutable content concept could be restricted to just > "drafts" since there are all sorts of use cases around a user wanting to > change the content of messages they received. In Alto, for example, once > a user sees the photo stack the inevitable question is "how do I delete > these old photos...I want to keep the email but without the photos". > > We can totally re-envision the mail store as a versioned document store, > which I agree would be interesting, but that seems like a significant > scope change for JMAP to cover it. And it seems like we have enough of > that already. > > - Stuart > > On 4/24/17 7:00 PM, Ted Lemon wrote: > > If drafts are mutable, the implication is that synchronization based on > > message ID can't happen without something like a version modifier. At > > which point why not make every message versioned? > > > > On Apr 24, 2017 9:35 PM, "Neil Jenkins" > > wrote: > > > > __ > > On Tue, 25 Apr 2017, at 11:02 AM, Chris Newman wrote: > >> I see a lot of cost and no benefit to making a draft a different > >> datatype from a message. > > > > I don't see any benefit to making it a different data type. However, > > what we currently have is that, like IMAP, a message is immutable > > except for flags/mailboxes. This is a pain for client authors trying > > to keep track of a single draft as it is saved through multiple > > revisions (especially when the user has multiple clients). One > > possible solution to this is to simply say any message with the > > \Draft flag set is fully mutable (while keeping the same id). I > > think we would also want the server to enforce that a message cannot > > be changed from/to draft state after creation. If it starts a draft > > it stays a draft, or vice versa. > > > > From a protocol perspective, since most messages won't be drafts > > (with a normal user) you still get the efficiency of immutable > > messages (you only have to refetch flags/mailboxes, not the whole > > message) for most of the messages in the mail store. But it will be > > easier for MUAs to handle drafts, and particularly allow for a much > > better experience when editing the same draft message across > > multiple devices. > > > > Neil. > > > > _______________________________________________ > > Jmap mailing list > > Jmap@ietf.org > > https://www.ietf.org/mailman/listinfo/jmap > > > > > > > > > > _______________________________________________ > > Jmap mailing list > > Jmap@ietf.org > > https://www.ietf.org/mailman/listinfo/jmap > > > -- Bron Gondwana brong@fastmail.fm From nobody Tue Apr 25 16:05:44 2017 Return-Path: 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 912AA12785F for ; Tue, 25 Apr 2017 16:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 8W9_Ccpsyd-j for ; Tue, 25 Apr 2017 16:05:40 -0700 (PDT) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABF721205F0 for ; Tue, 25 Apr 2017 16:05:40 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id c45so152990060qtb.1 for ; Tue, 25 Apr 2017 16:05:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=nuZTtPXHCc5YeYNTzS7bvEAcaGMXfGyaJy4/PS5azIY=; b=Zm7XgWWFiuFliMg0pHeHh62UU2G87twuiwr09sB3jaoUkZfgqeAdtEhCfVsc6GC/KV QFfOCRe8Q0NKpOPBwyB+MIcqp8SUpOKGSTd0jgpkXlxviZhd/KV2+7X1d/9WWpauJD5W Y2+R1rkNlGgoasgXv95is5FsQ/1ehZbNonnL3s4BdJCfPuuDxtaM5/XVpkCzXCP6H4CA 7F8rpYfL0/rj0C7+RCa9RGURfR+KJuHaoELhuctRdqUTomsEQOnnhOHFD12ZLKl6c4nl r3IqHa+UBb4mGbWpKyvJKgNmSi7scbqqeCXMl/69mY1vRH13RhMQoPl76pLHmKUFDLQ3 hgFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=nuZTtPXHCc5YeYNTzS7bvEAcaGMXfGyaJy4/PS5azIY=; b=EM5HgidS3rPrBmiGAGjTY5YpwNcZOu6wGKZ378sfNKEvUkZRWKk8aZLpPtHc8/Nxd2 LPKtaW1B4fyZpqlRXv9r48S0PTISei+2SWvtN+sRc1KCCHqU5ny4QV1XFFitEWkGk/ZS /RiZoGIAQ8J16hyGUHmwCZQIF11IxF+DmKn7yarZYGGg/QcfmUuEfqyxTRQEQE6Zlvs4 itS9MWbYXW+TSirsJGUNFIdEsYHWc+vJl3zIiW/kgW4jxK6MuJgR9Sj9+oEtr9c5spGc 1Ym9VVcaDKm8CUdYKNW+CwUFiJwWQcB1LbL9fWpBStFP3HSquq197nwmYrZxvMvRRELq ZOXA== X-Gm-Message-State: AN3rC/6ZaSlbn4ev4Nm/SMUvOAU5cSCBkmu6osF6Xv0RyEy5OXnf84GN ZnnMLYB0m+QzZA== X-Received: by 10.237.53.236 with SMTP id d41mr36892863qte.158.1493161539923; Tue, 25 Apr 2017 16:05:39 -0700 (PDT) Received: from macbook-pro-6.home (pool-108-31-94-75.washdc.fios.verizon.net. [108.31.94.75]) by smtp.gmail.com with ESMTPSA id p64sm16184671qkc.3.2017.04.25.16.05.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Apr 2017 16:05:39 -0700 (PDT) From: Ted Lemon Message-Id: <6E855C48-EAAE-478B-93A5-59F7261E3467@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_60FB98E8-0690-498F-A7F6-20CBA1880971" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 25 Apr 2017 19:05:37 -0400 In-Reply-To: <33553450-82F4-4CB4-8679-C9F52D8A8839@oracle.com> Cc: Bron Gondwana , jmap@ietf.org To: Chris Newman References: <46F700A6-C2B1-488B-A8B4-6ACD45B03C31@oracle.com> <1493099769.3023399.955193288.6D0312CC@webmail.messagingengine.com> <33553450-82F4-4CB4-8679-C9F52D8A8839@oracle.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Jmap] Best vs Good enough - adoption of JMAP X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 23:05:43 -0000 --Apple-Mail=_60FB98E8-0690-498F-A7F6-20CBA1880971 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 25, 2017, at 7:01 PM, Chris Newman = wrote: > So given we have at least two server implementers on the list who will = do always-empty outbox for the first implementation, I think that begs = the question of what's the more important feature for JMAP to offer: > A) outbox model > B) undo send and delayed send Obviously the cure is to combine the sent folder and the outbox... --Apple-Mail=_60FB98E8-0690-498F-A7F6-20CBA1880971 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Apr 25, 2017, at 7:01 PM, Chris Newman <chris.newman@oracle.com> wrote:
So given we have at least two server = implementers on the list who will do always-empty outbox for the first = implementation, I think that begs the question of what's the more = important feature for JMAP to offer:
A) outbox = model
B) undo send and delayed = send

Obviously the cure is to combine the sent folder and the = outbox...

= --Apple-Mail=_60FB98E8-0690-498F-A7F6-20CBA1880971-- From nobody Tue Apr 25 16:46:19 2017 Return-Path: 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 86F30126FDC for ; Tue, 25 Apr 2017 16:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=D42Jm/QI; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Zp/dL5DE 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 xlND77giES3K for ; Tue, 25 Apr 2017 16:46:16 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2BC61294BC for ; Tue, 25 Apr 2017 16:46:15 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id CB858218E7 for ; Tue, 25 Apr 2017 19:46:14 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Tue, 25 Apr 2017 19:46:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=I1axL1qmig9PL1PHMMjwZqraWOozX qPB/AoCIAA7YN4=; b=D42Jm/QIL1gtLqCQrkL0SykJdTc4VahnVCtznjLgEoctV FtJJcNqqYyAC7xZUdvxCUpn1g7yNod3h/y8dF+98IkCHWe4BDeRov58+hgliTbUP neNebBcmR8InIOkV9S6J2W4QMuMETAAjH1FhhRkk+leR9Msm7iTiwrtcKoMgDKfP xZYz4EIvf6j2h2C0ShJIhLZ51hvJqqU8/jzW65vjd6nGaGwlF3RvJYA/TA8mq4DI 7XAZKFbShqk41R8N2OJayAQNv5mAWQTmdd+Z3HZFnAf9bXl9kf14IH96oIcBjeeu ysNYAbqwTCmaMy53TzLhZfkaqZeB78QEUJ5oQcSvQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=I1axL1 qmig9PL1PHMMjwZqraWOozXqPB/AoCIAA7YN4=; b=Zp/dL5DEDzUaRejJ9sFSId IbtwrruQ70hELgJ/TBA6LmnSf/Es8trCBgLTWIEiVA1Yp+3hWSEtIfMfGdVvEnOY MXMTg4w+GJellG01H8oPrgbF00rBqtDtkPDi9sworBR7B0YJ5tXmo0wlW3NJ2c+P Qxuhp5mfE9xyFEEYQ7DFQYNI37KJh9gthsV9MVp3zoRD+XhI7f/UpMGIo7iFUvUJ ZNFWcUqg2IZER/xBtGkH8JZIii49EarBm7VWuE8qhHhxXF+u0pjhSAQtGstxzyQv a8IBeTKbaHshDPS2IIc1thkJ1XNn9wLMM4SUnb9dvdXfkXMaNa5olpyLiSS4LjdQ == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 88F66E276C; Tue, 25 Apr 2017 19:46:14 -0400 (EDT) Message-Id: <1493163974.4122214.956244160.6735E49C@webmail.messagingengine.com> From: Neil Jenkins To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_149316397441222143" X-Mailer: MessagingEngine.com Webmail Interface - ajax-71880675 References: <46F700A6-C2B1-488B-A8B4-6ACD45B03C31@oracle.com> <1493099769.3023399.955193288.6D0312CC@webmail.messagingengine.com> <33553450-82F4-4CB4-8679-C9F52D8A8839@oracle.com> In-Reply-To: <33553450-82F4-4CB4-8679-C9F52D8A8839@oracle.com> Date: Wed, 26 Apr 2017 09:46:14 +1000 Archived-At: Subject: Re: [Jmap] Best vs Good enough - adoption of JMAP X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 23:46:18 -0000 This is a multi-part message in MIME format. --_----------=_149316397441222143 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" I think there's been some misconception over the intended semantics of the outbox proposal. The outbox was never intended to be the submission queue, with mail queue semantics. It is intended as a standard mailbox, with mailstore semantics, because it is where messages go **before** they are passed on to submission. The server would validate the message/envelope at the time of moving it to the outbox to ensure it can be accepted for submission later of course. If you have existing mailstore + SMTP infrastructure, implementation is not much more than having some small demon that triggers to take the message from the mailstore and submit it to the SMTP queue at the appropriate time. >From a user experience point of view, this model gives us an understandable conceptual place for messages that are *going* to be sent but have not yet been picked up by the postman, to use a real world analogy. Because it is a standard mailbox, we automatically have an API for the client to fetch and show to the user all the currently scheduled messages. I think this is important functionality as a user if we have delayed send (and of course we also have the ability to then cancel any of the future submissions, by just moving the messages back out of the outbox). With my client author hat on, I like this model because it makes it easier to implement full offline support. If I am offline, the outbox represents messages waiting to go out from the client. From an implementation perspective it is much easier if my offline sync code doesn't need a separate path for keeping track of messages to be sent vs. normal messages moved to another folder. The *only real difference* between a "sendMessage" command and using "move to outbox" as the equivalent command, is that clients can get the list of "delayed" messages waiting for submission. I think this is valuable, and pretty much required for "scheduled send", although not so important for "undo send". The fact that this is really the only difference is why servers that can't or don't want to implement delayed send or expose messages waiting to be sent can use the "empty outbox" model. Neil. --_----------=_149316397441222143 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
I think there's been some misconception over the intended semantics of the outbox proposal. The outbox was never intended to be the submission queue, with mail queue semantics. It is intended as a standard mailbox, with mailstore semantics, because it is where messages go before they are passed on to submission. The server would validate the message/envelope at the time of moving it to the outbox to ensure it can be accepted for submission later of course. If you have existing mailstore + SMTP infrastructure, implementation is not much more than having some small demon that triggers to take the message from the mailstore and submit it to the SMTP queue at the appropriate time.

From a user experience point of view, this model gives us an understandable conceptual place for messages that are going to be sent but have not yet been picked up by the postman, to use a real world analogy. Because it is a standard mailbox, we automatically have an API for the client to fetch and show to the user all the currently scheduled messages. I think this is important functionality as a user if we have delayed send (and of course we also have the ability to then cancel any of the future submissions, by just moving the messages back out of the outbox).

With my client author hat on, I like this model because it makes it easier to implement full offline support. If I am offline, the outbox represents messages waiting to go out from the client. From an implementation perspective it is much easier if my offline sync code doesn't need a separate path for keeping track of messages to be sent vs. normal messages moved to another folder.

The only real difference between a "sendMessage" command and using "move to outbox" as the equivalent command, is that clients can get the list of "delayed" messages waiting for submission. I think this is valuable, and pretty much required for "scheduled send", although not so important for "undo send". The fact that this is really the only difference is why servers that can't or don't want to implement delayed send or expose messages waiting to be sent can use the "empty outbox" model.

Neil.
--_----------=_149316397441222143-- From nobody Tue Apr 25 18:06:19 2017 Return-Path: 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 BC021126D05 for ; Tue, 25 Apr 2017 18:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=U53BvetI; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=AQoDAf0T 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 KUuAp4tp3g64 for ; Tue, 25 Apr 2017 18:06:17 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68AF61205D3 for ; Tue, 25 Apr 2017 18:06:17 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id D5E4C21452 for ; Tue, 25 Apr 2017 21:06:16 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Tue, 25 Apr 2017 21:06:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=R/1GRpduwM7sO7tYx0I6VQQNDAxtM U1qpnXz54mwaGc=; b=U53BvetIV1fbK0iOe0RZnxzyc0EVNMUws6DS5//OemAVu cp5XLVp4ljacNM3zXwgfhieo9qzgnrc5zIvxpD94j5aRVk9NjbRhSNoVxzERZn6X J5ZPrEnlZQr4jtDIa3CnKydFY1bzXPQVUOsHuqo34z8MEs9o2qCFEm2lj/yO1lJz IHhIiWKa1g/nrUOe0Fvorhj9LxRIiq8kEUq0oLHqVRDbLEzaDN5qBGZX+1fhKUgh n9du4L2p5cZ/WcxGG4EueI8S/g18peSbfLvi37/ZMP1m9ru157pGwMawNQKm/Vdu Pkp7ISb4UG4aTg5rQ8ZKu/2vMhwu/geG+uYXzxi0Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=R/1GRp duwM7sO7tYx0I6VQQNDAxtMU1qpnXz54mwaGc=; b=AQoDAf0TYj6UPhssEg+DJH ZnoNV8+kHPnpTqGVpRoAP4Kp6/PdSRR5ns1s5G20wZUwrDbeDL101u/NAE6wMx6f DbEs07e7uBzBoGuK8ZvzkfCPWAmPTdoYUD7KQ6O0IZu8gOq0XASzp04PlpFTjiYp U+tj07zCPt98VKzXIUgwexcXVaMLDSNugKbJo8qTQRyv9Es0Ll7nUYaHY36+8FCc oHGA919i4t5kEPO1Ol1T9vG07W6PsZBJHfd8/e72tE/lvOf3IYa/8CUWGl/rZMUi VmOWZgE36EiGZNjob7YivNHHux8uUqJUDxijbCGDzcW5L4E/k8rqTPcG4SlSwAAg == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 97F0FE276C; Tue, 25 Apr 2017 21:06:16 -0400 (EDT) Message-Id: <1493168776.24902.956297280.180E7202@webmail.messagingengine.com> From: Neil Jenkins To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_1493168776249020" X-Mailer: MessagingEngine.com Webmail Interface - ajax-71880675 References: <1492998899.3316920.953769616.254C9CBD@webmail.messagingengine.com> <1493084134.2830550.955039432.5403CAFB@webmail.messagingengine.com> <1493087082.2882732.955078288.61343C16@webmail.messagingengine.com> <45E4DC37-A0FA-4573-83B1-3701E0FE2A69@oracle.com> Date: Wed, 26 Apr 2017 11:06:16 +1000 In-Reply-To: <45E4DC37-A0FA-4573-83B1-3701E0FE2A69@oracle.com> Archived-At: Subject: Re: [Jmap] Draft messages - mutability X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 01:06:19 -0000 This is a multi-part message in MIME format. --_----------=_1493168776249020 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" Yeh, a persistent identifier can certainly do much of the same job (in theory the RFC5322 Message-Id should do this if you generate it in a sensible way). And I agree that it simplifies sync code if all messages are the same in terms of mutability (although I don't think it would be too hard to support). As Bron points out, you do have more work in the client to find the message by the draft id, but given the above, and that this is also more easily compatible with IMAP, I think sticking with the current immutable model is probably better. As Chris mentioned earlier, an atomic "replace" *would* be very helpful for handling drafts. I actually think we can model this as a standard JMAP update, just it returns a new id. So you would have something like: [ [ "setMessages", { "update": { "${currentMessageId}": { "to": [{ "name": "Joe Bloggs", "email": "joe@example.com" }], ... all the other properties you normally pass to create ... } } }, "tag" ] ] which returns [ [ "messagesSet", { "updated": { "${currentMessageId}": { "id": "${newMessageId}" } } }, "tag" ] ] Neil. --_----------=_1493168776249020 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
Yeh, a persistent identifier can certainly do much of the same job (in theory the RFC5322 Message-Id should do this if you generate it in a sensible way). And I agree that it simplifies sync code if all messages are the same in terms of mutability (although I don't think it would be too hard to support).

As Bron points out, you do have more work in the client to find the message by the draft id, but given the above, and that this is also more easily compatible with IMAP, I think sticking with the current immutable model is probably better.

As Chris mentioned earlier, an atomic "replace" would be very helpful for handling drafts. I actually think we can model this as a standard JMAP update, just it returns a new id. So you would have something like:

[
    [ "setMessages", {
        "update": {
            "${currentMessageId}": {
                "to": [{
                    "name": "Joe Bloggs",
                    "email": "joe@example.com"
                }],
                ... all the other properties you normally pass to create ...
            }
        }
    }, "tag" ]
]

which returns

[
    [ "messagesSet", {
        "updated": {
            "${currentMessageId}": {
                "id": "${newMessageId}"
            }
        }
    }, "tag" ]
]

Neil.
--_----------=_1493168776249020-- From nobody Tue Apr 25 19:40:12 2017 Return-Path: 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 3137C131809 for ; Tue, 25 Apr 2017 19:40:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 JN7_sBlD-XUk for ; Tue, 25 Apr 2017 19:40:08 -0700 (PDT) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 478191273E2 for ; Tue, 25 Apr 2017 19:40:08 -0700 (PDT) Received: by mail-qt0-x232.google.com with SMTP id g60so156176324qtd.3 for ; Tue, 25 Apr 2017 19:40:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ESPPdCVYXcNaWbflrZm9vTgsujNyqzjcQv583k8DXBo=; b=czm99yq0A95myN4gUtevzCdvUmxNAXzvCXRCYTF1tjAlxsJmHWG/X7SJjeLSG9Ff1C EG5yPKmK5QA2NY1NNR6nvqBvL50RkScmNDvkwzAg0QTMTmCVFdDAGstx/6FncMMIclMd t/4POaYXtZH5qdHMH01oK4XG0WC2R+DrB5Fzng2VPTtg4jl7XBPgvpDh7gLnArJ3V0UI 4+paLyBxgxrrjFe/VlLZrbjIDQiBMykmY7MYMAy9SbNixI06oEWQ81eO1mf0LbzMlSVm iCwpjmqjX+ztFSE5yJbWgwyJKMKvzxhNXBifU1Jh31CTuFzNIblyMeMk0WdvZegnMqhO n3Hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=ESPPdCVYXcNaWbflrZm9vTgsujNyqzjcQv583k8DXBo=; b=MsztMQBir5JCaJoNoXiaQdbtUYUcm/0UiGSmDCwXY47aeRXTZ2h1hP9V+ZQGihKuoh lgXI7EzbV341zkmowImkPwnqVWZnudHSEyxq3gkah9lip9DtDA5BP87/LXAl1gNrkvat +bdvxg/nTkDR4EiZuPSnwNefGPlbdCmLN4eZ+Q/qFl/4lpQAkoGVkAqUpIAlGc4eDdLb Hb2wOaTNqnY9DLbCzj7iywajGjRvgFuN6xFEjx5WTGlRaDDvA5pO/eoDjANB8u3FQkgF QTPV9Dq9g2MKFChA1DtUpx+NXqLo0SuI07lluR9baOOhuCpX/A8Dxwugo58TXe8TgXxS INSg== X-Gm-Message-State: AN3rC/6AH6+sp9B8aSE7q2Ua24l3jYC9yOzHFYQW6v+CV0xvWwK4R5CH JIGdlyeU4Dlp3ZxTMlA= X-Received: by 10.237.62.115 with SMTP id m48mr34695505qtf.192.1493174407434; Tue, 25 Apr 2017 19:40:07 -0700 (PDT) Received: from macbook-pro-6.home (pool-108-31-94-75.washdc.fios.verizon.net. [108.31.94.75]) by smtp.gmail.com with ESMTPSA id n5sm16503763qtd.7.2017.04.25.19.40.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Apr 2017 19:40:06 -0700 (PDT) From: Ted Lemon Message-Id: <63973317-543D-4E5C-80D3-16F5979D747D@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_D43457ED-D90A-4F2D-886D-CAC9B17F9EDB" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 25 Apr 2017 22:40:05 -0400 In-Reply-To: <1493087082.2882732.955078288.61343C16@webmail.messagingengine.com> Cc: Chris Newman , jmap@ietf.org To: Neil Jenkins References: <1492998899.3316920.953769616.254C9CBD@webmail.messagingengine.com> <1493084134.2830550.955039432.5403CAFB@webmail.messagingengine.com> <1493087082.2882732.955078288.61343C16@webmail.messagingengine.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Jmap] Draft messages - mutability X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 02:40:10 -0000 --Apple-Mail=_D43457ED-D90A-4F2D-886D-CAC9B17F9EDB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 24, 2017, at 10:24 PM, Neil Jenkins wrote: > Now with immutable messages, all my laptop MUA can see is that the = draft has been deleted from the server, but this might just mean there's = a newer version of the draft. I can see the newer draft but can't know = for sure it's an update to the one I have open or not. So I can either = resave the draft that's open (which could cause a duplicate old draft to = "reappear" in the Drafts mailbox), or I can just delete it and hope for = the best (and the user can reopen the new draft if they still hadn't = finished sending). I can see where this can happen if the client hasn't synchronized with = the server, or if the message has been modified on the client before the = sync happened, but in the normal case where the client is up to date, = shouldn't the old version of the draft be gone from the list of drafts, = and the new one present? It's not like the _user_ is going to look at = the message ID. I suppose that if the old draft were present in a viewer, the user would = see the weird behavior of the viewer disappearing, and they'd have to go = click on the message again, so it would be good to have a way to = discover the message that replaced it and open that one when removing = the old one from the viewer. And of course the MUA would have to = notice that the old draft is no longer marked as in the draft folder, = and possibly is marked as in the trash folder, and know to take some = action because of that. --Apple-Mail=_D43457ED-D90A-4F2D-886D-CAC9B17F9EDB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Apr 24, 2017, at 10:24 PM, Neil Jenkins <neilj@fastmail.com> = wrote:
Now with immutable messages, all = my laptop MUA can see is that the draft has been deleted from the = server, but this might just mean there's a newer version of the draft. I = can see the newer draft but can't know for sure it's an update to the = one I have open or not. So I can either resave the draft that's open = (which could cause a duplicate old draft to "reappear" in the Drafts = mailbox), or I can just delete it and hope for the best (and the user = can reopen the new draft if they still hadn't finished = sending).

I = can see where this can happen if the client hasn't synchronized with the = server, or if the message has been modified on the client before the = sync happened, but in the normal case where the client is up to date, = shouldn't the old version of the draft be gone from the list of drafts, = and the new one present?   It's not like the _user_ is going to = look at the message ID.

I suppose that if the old draft were present in a viewer, the = user would see the weird behavior of the viewer disappearing, and they'd = have to go click on the message again, so it would be good to have a way = to discover the message that replaced it and open that one when removing = the old one from the viewer.   And of course the MUA would have to = notice that the old draft is no longer marked as in the draft folder, = and possibly is marked as in the trash folder, and know to take some = action because of that.

= --Apple-Mail=_D43457ED-D90A-4F2D-886D-CAC9B17F9EDB-- From nobody Tue Apr 25 19:56:15 2017 Return-Path: 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 59603124D68 for ; Tue, 25 Apr 2017 19:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=Y9H6hdxV; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=MEEK91Ac 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 UPJBDvKynHud for ; Tue, 25 Apr 2017 19:56:12 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB9DF1204DA for ; Tue, 25 Apr 2017 19:56:12 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id 38C8920B3E; Tue, 25 Apr 2017 22:56:12 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Tue, 25 Apr 2017 22:56:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=pSA5AC4/io7NYpJXZMJJSeFiIADW1 XPTiijvctJj9rk=; b=Y9H6hdxVSiWNOqTOHSl4JnVkuh7a6xg2P0kEdx+l4LxAf VCUDsPMp0n4WVF7ha2a12YkB+5zrcc0gs1Jbn0VhL4s1UEbn5nrTp5Lftr8ZPB5n 8CdF7RrDf0SsCenDiKN1t7/LCrLI2fEaqUh8yR0wlil3x7INp2TMgbgtwsaYgMvv NQPk9fDlbH9fxF9/2V7ipU9dheRUzHpeGlphAMbnw60NC63OYJ8x6Osq+MjA0EeY t9b1+8lZZJZEV9q7zIvfeiWcRHhjfslXmnfPnFyhSAvx0JFYQedSV9SmcWdUu+eh w9LHlVF4BasPAR28BNMn0yoei57coKFXcLHgtRQcg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=pSA5AC 4/io7NYpJXZMJJSeFiIADW1XPTiijvctJj9rk=; b=MEEK91AcNdFygkev2FD8mM +bqi2OAXhPuw66sU/xfJEYurtFcvNonuWJ4/lFkPDx5qj4jASXlIF7l6SGHd8xvG FheV+Aq1gN38WtH7kXmZFViaxZLHCX3SK4NgwPlWCRKniatJUrKLNcLn+l4Pmlt0 XQD/TZD57W3Xarbm+ijA9Cj7eW1W9xRZNe0triSxs3ASSpErHIQZF2sSwDwaVIxU yCuT/4idM1UzE1MA5ZzK+gOd3uZ1cAQQU2Rz6xwJh8aIm/91wjp68OyPWRqh+EVz jdILMxtQeQK2t+wLPQOTxZlsmK2I4hpB4LMtKvAJWa874d4LSbn6AK4QcJckm7yw == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id E1B6DE276C; Tue, 25 Apr 2017 22:56:11 -0400 (EDT) Message-Id: <1493175371.126749.956396640.2F6911DF@webmail.messagingengine.com> From: Neil Jenkins To: Ted Lemon Cc: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_14931753711267490" X-Mailer: MessagingEngine.com Webmail Interface - ajax-71880675 Date: Wed, 26 Apr 2017 12:56:11 +1000 In-Reply-To: <63973317-543D-4E5C-80D3-16F5979D747D@fugue.com> References: <1492998899.3316920.953769616.254C9CBD@webmail.messagingengine.com> <1493084134.2830550.955039432.5403CAFB@webmail.messagingengine.com> <1493087082.2882732.955078288.61343C16@webmail.messagingengine.com> <63973317-543D-4E5C-80D3-16F5979D747D@fugue.com> Archived-At: Subject: Re: [Jmap] Draft messages - mutability X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 02:56:14 -0000 This is a multi-part message in MIME format. --_----------=_14931753711267490 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Wed, 26 Apr 2017, at 12:40 PM, Ted Lemon wrote: > I suppose that if the old draft were present in a viewer, Yes, this is the case I was referring to: where the draft is currently open for editing. Neil. --_----------=_14931753711267490 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Wed, 26 Apr 2017, at 12:40 PM, Ted Lemon wrote:
I suppose that if the old draft were present in a viewer,

Yes, this is the case I was referring to: where the draft is currently open for editing.

Neil.
--_----------=_14931753711267490-- From nobody Tue Apr 25 21:50:05 2017 Return-Path: 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 5FB21120046 for ; Tue, 25 Apr 2017 21:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 WzpQsD5LZamU for ; Tue, 25 Apr 2017 21:50:02 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3BDC127071 for ; Tue, 25 Apr 2017 21:50:02 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v3Q4nwXu013267 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 26 Apr 2017 04:49:58 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v3Q4nv12006727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 26 Apr 2017 04:49:57 GMT Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id v3Q4ntQP021535; Wed, 26 Apr 2017 04:49:56 GMT Received: from [192.168.15.59] (/66.214.236.56) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 25 Apr 2017 21:49:55 -0700 From: "Chris Newman" To: "Neil Jenkins" Cc: jmap@ietf.org Date: Tue, 25 Apr 2017 21:49:54 -0700 Message-ID: In-Reply-To: <1493163974.4122214.956244160.6735E49C@webmail.messagingengine.com> References: <46F700A6-C2B1-488B-A8B4-6ACD45B03C31@oracle.com> <1493099769.3023399.955193288.6D0312CC@webmail.messagingengine.com> <33553450-82F4-4CB4-8679-C9F52D8A8839@oracle.com> <1493163974.4122214.956244160.6735E49C@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Subject: Re: [Jmap] Best vs Good enough - adoption of JMAP X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 04:50:04 -0000 On 25 Apr 2017, at 16:46, Neil Jenkins wrote: > I think there's been some misconception over the intended semantics of > the outbox proposal. The outbox was never intended to be the > submission > queue, with mail queue semantics. It is intended as a standard > mailbox, > with mailstore semantics, because it is where messages go **before** > they are passed on to submission. The server would validate the > message/envelope at the time of moving it to the outbox to ensure it > can > be accepted for submission later of course. If you have existing > mailstore + SMTP infrastructure, implementation is not much more than > having some small demon that triggers to take the message from the > mailstore and submit it to the SMTP queue at the appropriate time. And as soon as you add that "small daemon" (also known as a mail queue processing daemon), you've now required the mailstore to also have mail queue semantics. This includes key semantics such as: the mail queue daemon has full read / delete access to those messages even when the user is offline. If the delivery doesn't happen when the user expects, the user is going to make a support call, so we now need all the monitoring, logging and robustness that comes with a mail queue. And addresses that were valid at the time the message entered this mail queue can become invalid later, so there has to be bounce-processing for when that happens, etc, etc. The only way to have a server-side outbox that is not a mail queue would be if messages sit in the outbox indefinitely unless the user is online and their client decides to issue a submit command for a message in that fictitious outbox. > From a user experience point of view, this model gives us an > understandable conceptual place for messages that are *going* to be > sent but have not yet been picked up by the postman, to use a real > world analogy. This analogy only works with a desktop MUA where the "outbox" is on the desktop and thus owned by the "postal customer" (and incidentally, the outbox won't empty if the desktop is shut down). The hardware running JMAP is not owned but the "postal customer"; it's effectively owned by the postman. So an "outbox" on the JMAP server means the message has been given to the postman already; the postman is just waiting for the right time to release it to the next hop. > Because it is a standard mailbox, we automatically have > an API for the client to fetch and show to the user all the currently > scheduled messages. I think this is important functionality as a user > if we have delayed send (and of course we also have the ability to > then > cancel any of the future submissions, by just moving the messages back > out of the outbox). The problem with server-side-outbox in JMAP is that it constrains the server implementation to three options: 1. The mail store includes a mail queue for each user. 2. The mail queue, at least for delayed messages, can be accessed with full JMAP semantics. Including things like body structure, mod sequence, flags, etc. 3. The JMAP outbox is always empty. I really want a fourth option for server implementation: 4. The mail store and mail queue are completely separate. The mail queue daemon never accesses the mail store. The set of actions JMAP performs on objects in the mail queue is limited to only those that are strictly necessary to achieve a useful goal (envelope extensions like future release at submission time, unsend for messages still in local queue, and status feedback tagging on sent messages). > With my client author hat on, I like this model because it makes it > easier to implement full offline support. If I am offline, the outbox > represents messages waiting to go out from the client. From an > implementation perspective it is much easier if my offline sync code > doesn't need a separate path for keeping track of messages to be sent > vs. normal messages moved to another folder. A client-side outbox makes sense to me. It's a server-side outbox that I find problematic. Let me ask you this: Suppose JMAP implements a server-side outbox (aka mail queue). The JMAP client synchronizes the server-side outbox and goes offline. While the client is offline, the message gets submitted and the user decides they don't want to submit the message and delete it from the local cached outbox. Now what? Have you really simplified things by adding a server-side outbox to the mix? > The *only real difference* between a "sendMessage" command and using > "move to outbox" as the equivalent command, is that clients can get > the list of "delayed" messages waiting for submission. I think this is > valuable, and pretty much required for "scheduled send", although not > so important for "undo send". The fact that this is really the only > difference is why servers that can't or don't want to implement > delayed send or expose messages waiting to be sent can use the "empty > outbox" model. My product has already implemented future release, already implemented unsend from local mail queue and implemented message tracking so we can get status of a message in the local queue (and potentially beyond that). I'm willing to expose these in JMAP if the protocol is designed in such a way that we preserve clean functional separation between mail store and mail queue. I'm very much not interested in all the complexity a server-side outbox adds on top of those three features. I'd argue that "scheduled send" is a mail client feature and "future release" is a mail server feature. If there's a daemon that can move the message to the next hop even when the client is offline, you're talking about "future release" and the message has semantically been submitted already. So I think JMAP should put "future release" messages in the Sent folder to avoid confusion with a client-side outbox. I'd like JMAP to include a way to "unsend" future release messages so JMAP clients have access to the unsend feature we've already implemented. - Chris From nobody Tue Apr 25 22:41:05 2017 Return-Path: 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 12F1212EBD8 for ; Tue, 25 Apr 2017 22:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=uNzVsMHl; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Cgcc2UEH 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 RqGA-fztg-BQ for ; Tue, 25 Apr 2017 22:41:01 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6F921201F8 for ; Tue, 25 Apr 2017 22:41:01 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 0EEC120230 for ; Wed, 26 Apr 2017 01:41:01 -0400 (EDT) Received: from web2 ([10.202.2.212]) by compute6.internal (MEProxy); Wed, 26 Apr 2017 01:41:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=f9KG30dqqsCv3cOu5SGYMuGTH9qmN xvWh7inuXUWP14=; b=uNzVsMHll7hi9/IbRWI6/Wib+T2ZOfnkreN/KbFnLIlVH D6pYONh6bSIosJQXuW8R+7GoV8/KrxIHbZNFpK+CvsxcT5b0JGE/S3kcRPjfbbXE g2uSNWXS7cu0ucOe4EIDP/PRlyNQ9lw7y0PmAtR2qHQjJcrc8E8v6epGYcZqcAWP rnbnquozaN0D4QUDRsQiNO6AMQVzyPFgT7ShwjIZumPscI7rFfl+g9l1t2pMeNcH cmKVv3AtWI2FZpgp7sGdgvGQo/NQBbZXHNt1b4vR62rAwu49i6D3TN0b4s95Vc3I lEOMsBZ3YdCq2zAd7r4oCYilE1zZutVZSiMiPre+g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=f9KG30 dqqsCv3cOu5SGYMuGTH9qmNxvWh7inuXUWP14=; b=Cgcc2UEHE2p8M5Knnw/hOJ zP2t+oo+QStajekbpqF/CxcAsEWJC7VQ0oQ2DiFM9i5iib311FvOV5oUSv9DqOtz ykavyl8XEOsfKyQn6q3xZlqEzsiIG8aFYKUZsOLs1JUo50Rv1SAu068D+8pcqmi/ ea1u3eK0hl52y116kXdc4p26FZCJ7vDXh5nzhe4NL+tH5u7PX7eFPNSMYjeXmSB1 zlZ1Z4PUd9GP43tHMm5OZb7Q/Kmu8m8AwatJclHOEuivqWbc7BbM4uuji4vFUuk2 cGmAWUYfR7FsAq57e4UtC/vYPR17XsD3610HC1M9X/XXHvfRRdvnXf1OGTt8Gg/g == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id DAEA862737; Wed, 26 Apr 2017 01:41:00 -0400 (EDT) Message-Id: <1493185260.709114.956477904.75CB343B@webmail.messagingengine.com> From: Bron Gondwana To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-88a795dc Date: Wed, 26 Apr 2017 15:41:00 +1000 References: <46F700A6-C2B1-488B-A8B4-6ACD45B03C31@oracle.com> <1493099769.3023399.955193288.6D0312CC@webmail.messagingengine.com> <33553450-82F4-4CB4-8679-C9F52D8A8839@oracle.com> <1493163974.4122214.956244160.6735E49C@webmail.messagingengine.com> In-Reply-To: Archived-At: Subject: Re: [Jmap] Best vs Good enough - adoption of JMAP X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 05:41:04 -0000 On Wed, 26 Apr 2017, at 14:49, Chris Newman wrote: > On 25 Apr 2017, at 16:46, Neil Jenkins wrote: > > I think there's been some misconception over the intended semantics of > > the outbox proposal. The outbox was never intended to be the > > submission > > queue, with mail queue semantics. It is intended as a standard > > mailbox, > > with mailstore semantics, because it is where messages go **before** > > they are passed on to submission. The server would validate the > > message/envelope at the time of moving it to the outbox to ensure it > > can > > be accepted for submission later of course. If you have existing > > mailstore + SMTP infrastructure, implementation is not much more than > > having some small demon that triggers to take the message from the > > mailstore and submit it to the SMTP queue at the appropriate time. > > And as soon as you add that "small daemon" (also known as a mail queue > processing daemon), you've now required the mailstore to also have mail > queue semantics. This includes key semantics such as: the mail queue > daemon has full read / delete access to those messages even when the > user is offline. If the delivery doesn't happen when the user expects, > the user is going to make a support call, so we now need all the > monitoring, logging and robustness that comes with a mail queue. And > addresses that were valid at the time the message entered this mail > queue can become invalid later, so there has to be bounce-processing for > when that happens, etc, etc. Disagree on bounce processing. It's no different than the next SMTP hop in that regard. It's exactly the same as other scheduled stuff we already support in our server such as calendar alarms based on calendar events - which we happen to store in the same backend - so it already needs event scheduling. I even blogged about our plans https://blog.fastmail.com/2015/12/25/a-ghost-of-fastmail-future/ (complete with over-enthusiastic date predictions) But adding the message to the Outbox also generates a full logged, replicated, replayable event in the #events mailbox which will be processed by a single queue daemon per server, and which will be monitored in the same way we monitor all our queues - by injecting messages at the start and making sure they are flowing out the other end. > The only way to have a server-side outbox that is not a mail queue would > be if messages sit in the outbox indefinitely unless the user is online > and their client decides to issue a submit command for a message in that > fictitious outbox. Yeah, that makes delayed outbox mostly pointless. Particularly in the multi-client world. > > From a user experience point of view, this model gives us an > > understandable conceptual place for messages that are *going* to be > > sent but have not yet been picked up by the postman, to use a real > > world analogy. > > This analogy only works with a desktop MUA where the "outbox" is on the > desktop and thus owned by the "postal customer" (and incidentally, the > outbox won't empty if the desktop is shut down). The hardware running > JMAP is not owned but the "postal customer"; it's effectively owned by > the postman. So an "outbox" on the JMAP server means the message has > been given to the postman already; the postman is just waiting for the > right time to release it to the next hop. We could imagine it in the case where there's a company "postman" who's still in the building for a pre-determined amount of time before they take the packages down to the central processing facility, and while it's still in the building you can waylay the postman and ask for it to removed from the postbag... > > Because it is a standard mailbox, we automatically have > > an API for the client to fetch and show to the user all the currently > > scheduled messages. I think this is important functionality as a user > > if we have delayed send (and of course we also have the ability to > > then > > cancel any of the future submissions, by just moving the messages back > > out of the outbox). > > The problem with server-side-outbox in JMAP is that it constrains the > server implementation to three options: > > 1. The mail store includes a mail queue for each user. > 2. The mail queue, at least for delayed messages, can be accessed with > full JMAP semantics. Including things like body structure, mod sequence, > flags, etc. > 3. The JMAP outbox is always empty. > > I really want a fourth option for server implementation: > > 4. The mail store and mail queue are completely separate. The mail queue > daemon never accesses the mail store. The set of actions JMAP performs > on objects in the mail queue is limited to only those that are strictly > necessary to achieve a useful goal (envelope extensions like future > release at submission time, unsend for messages still in local queue, > and status feedback tagging on sent messages). You appear to be proposing one of: a) there is no support for delayed sending or undo b) the user has no visibility or control of queued messages after submitting them c) the user can control queued messages, but needs to use a different protocol than JMAP to do it d) a new object type for queued messages needs to be defined in JMAP, with operations that allow achieving the above useful goals. If (d), are you willing to write up the object definitions and client advice for how they would be used, so they can be tested? > > With my client author hat on, I like this model because it makes it > > easier to implement full offline support. If I am offline, the outbox > > represents messages waiting to go out from the client. From an > > implementation perspective it is much easier if my offline sync code > > doesn't need a separate path for keeping track of messages to be sent > > vs. normal messages moved to another folder. > > A client-side outbox makes sense to me. It's a server-side outbox that I > find problematic. Let me ask you this: > > Suppose JMAP implements a server-side outbox (aka mail queue). The JMAP > client synchronizes the server-side outbox and goes offline. While the > client is offline, the message gets submitted and the user decides they > don't want to submit the message and delete it from the local cached > outbox. Now what? Have you really simplified things by adding a > server-side outbox to the mix? When the client re-syncs, it sees that the message it tried to move back out to Drafts no longer exists, but there's a new message in Sent. The user notices that the send happened, oh well. This is the same as if you hit "undo" in the Gmail interface after sending a message, but unfortunately your internet connection dropped for 30 seconds, and it was too late. Clearly the client can't know for sure that the undo succeeded until it gets confirmation from the server. In functional programming parlance, moving messages in and out of the "Outbox" folder is impure - it has side effects. > > The *only real difference* between a "sendMessage" command and using > > "move to outbox" as the equivalent command, is that clients can get > > the list of "delayed" messages waiting for submission. I think this is > > valuable, and pretty much required for "scheduled send", although not > > so important for "undo send". The fact that this is really the only > > difference is why servers that can't or don't want to implement > > delayed send or expose messages waiting to be sent can use the "empty > > outbox" model. > > My product has already implemented future release, already implemented > unsend from local mail queue and implemented message tracking so we can > get status of a message in the local queue (and potentially beyond > that). I'm willing to expose these in JMAP if the protocol is designed > in such a way that we preserve clean functional separation between mail > store and mail queue. I'm very much not interested in all the complexity > a server-side outbox adds on top of those three features. > > I'd argue that "scheduled send" is a mail client feature and "future > release" is a mail server feature. If there's a daemon that can move the > message to the next hop even when the client is offline, you're talking > about "future release" and the message has semantically been submitted > already. So I think JMAP should put "future release" messages in the > Sent folder to avoid confusion with a client-side outbox. I'd like JMAP > to include a way to "unsend" future release messages so JMAP clients > have access to the unsend feature we've already implemented. If you could write up how, over JMAP, a client could tell that a message was future release and interact with its queue, that would probably help everyone understand how what you're proposing would work. Thanks, Bron. -- Bron Gondwana brong@fastmail.fm From nobody Wed Apr 26 07:18:42 2017 Return-Path: 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 1D6AE12EAEC for ; Wed, 26 Apr 2017 07:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.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 vgPMCltTW1_g for ; Wed, 26 Apr 2017 07:18:39 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 502E112EA42 for ; Wed, 26 Apr 2017 07:11:55 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QDMH1TGY0W008S06@mauve.mrochek.com> for jmap@ietf.org; Wed, 26 Apr 2017 07:07:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1493215662; bh=N0Pu6vxvyBghwZxdgwqDDNHPisUesGKDfdyUm13f54c=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=YB1SZ/AzLa86tfARjPq/8uF68O6Ei/u2r6ztT6ErUcVAOrNbJWA0gDt/u76O9R+kg 7/VvFpjLHELsWztGt5F16myTuWkuWuA18GLS0L72qqhGTo7H1Q23qj5Mq5pe7Ip/1/ HDURH7okKfxBbx/L6uYdGKJqn+xnGnJ9wxHY/yuQ= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QDLR9E01A800008D@mauve.mrochek.com>; Wed, 26 Apr 2017 07:07:38 -0700 (PDT) Cc: Neil Jenkins , jmap@ietf.org Message-id: <01QDMH1QNOUK00008D@mauve.mrochek.com> Date: Wed, 26 Apr 2017 06:45:51 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 25 Apr 2017 21:49:54 -0700" References: <46F700A6-C2B1-488B-A8B4-6ACD45B03C31@oracle.com> <1493099769.3023399.955193288.6D0312CC@webmail.messagingengine.com> <33553450-82F4-4CB4-8679-C9F52D8A8839@oracle.com> <1493163974.4122214.956244160.6735E49C@webmail.messagingengine.com> To: Chris Newman Archived-At: Subject: Re: [Jmap] Best vs Good enough - adoption of JMAP X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 14:18:41 -0000 > On 25 Apr 2017, at 16:46, Neil Jenkins wrote: > > I think there's been some misconception over the intended semantics of > > the outbox proposal. The outbox was never intended to be the > > submission > > queue, with mail queue semantics. It is intended as a standard > > mailbox, > > with mailstore semantics, because it is where messages go **before** > > they are passed on to submission. The server would validate the > > message/envelope at the time of moving it to the outbox to ensure it > > can > > be accepted for submission later of course. If you have existing > > mailstore + SMTP infrastructure, implementation is not much more than > > having some small demon that triggers to take the message from the > > mailstore and submit it to the SMTP queue at the appropriate time. > And as soon as you add that "small daemon" (also known as a mail queue > processing daemon), you've now required the mailstore to also have mail > queue semantics. This includes key semantics such as: the mail queue > daemon has full read / delete access to those messages even when the > user is offline. If the delivery doesn't happen when the user expects, > the user is going to make a support call, so we now need all the > monitoring, logging and robustness that comes with a mail queue. And > addresses that were valid at the time the message entered this mail > queue can become invalid later, so there has to be bounce-processing for > when that happens, etc, etc. Now take these semantics and multiply them by the number of users you have, which can be in the many millions. And while sometimes you can treat this as single, system-wide queue for monitoring purposes, sometimes you'll need to lookup and probably monitor on a per-user basis. I also assume there won't be a hardcoded name or location for this special use mailbox. So its specialness arises from some sort of attribute. Can that attribute be set? Reset? Can it be set on more than one mailbox? If not why not? It's not that I can' think of various possible ways to implement all this at scale. I can. But none of them are easy. > The only way to have a server-side outbox that is not a mail queue would > be if messages sit in the outbox indefinitely unless the user is online > and their client decides to issue a submit command for a message in that > fictitious outbox. At which point I don't see why you're bothering with it. > > From a user experience point of view, this model gives us an > > understandable conceptual place for messages that are *going* to be > > sent but have not yet been picked up by the postman, to use a real > > world analogy. > This analogy only works with a desktop MUA where the "outbox" is on the > desktop and thus owned by the "postal customer" (and incidentally, the > outbox won't empty if the desktop is shut down). The hardware running > JMAP is not owned but the "postal customer"; it's effectively owned by > the postman. So an "outbox" on the JMAP server means the message has > been given to the postman already; the postman is just waiting for the > right time to release it to the next hop. Actually, I think it's a great analogy. In the US at least, the post office imposes specific requirements on mailboxes, including the fact that something put in one is now in the custody of the post office, and only the mailbox owner can remove it. But the part I like best about the analogy is that while the ability to have a mailbox at every address in the country is incredibly convenient for the customer, the cost to the postal service is absolutely staggering. So much so that nobody other than the post office itself - who is obligated by history and custom - provides this service at scale. Ned From nobody Wed Apr 26 07:37:05 2017 Return-Path: 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 A983C12EAB0 for ; Wed, 26 Apr 2017 07:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 zB28k7-lLStE for ; Wed, 26 Apr 2017 07:36:56 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6B2B129C43 for ; Wed, 26 Apr 2017 07:34:20 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id y63so2234294qkd.1 for ; Wed, 26 Apr 2017 07:34:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Lm6UVInH3OH1jD+Y23Nq9GYb5ypBnBASdglurxQf2Do=; b=VlJnESEjrpOtJKPnDAGeV2hRG7TsrecF7fKJ1HB+JEKP6lfmuY1nj+RK7jkGjKbiAs UF88xgPqw9YKuJkxN4GzkI+qFo5BgxsJvNukWMQaAPK41U9thaElJ9BkBhUeXqHJLwYW xy81Rt6FveZi1StynFWkUML+KmjBRbSKodr0ZlR4xvlgB8xncKMC+D79k5slnGSwS4q/ bnzbrHpddXrAC1vrWlk4ACSdHjLitNw9TjYQMXIlimkaxtZ82S3PW34VAN2ryzXo0uSK YVslN03CkCRpZ6BDmbTYsLqF5f6XGP6joG/uasYwBn6qLOvSQ0AzyOYF2uJrahIclLkc swoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Lm6UVInH3OH1jD+Y23Nq9GYb5ypBnBASdglurxQf2Do=; b=sF3Ji7p5DabcUVIipoT7rsXxi3sVs/XSunsmL939MJ8Zv2etAH0FyPGcir71aiAhZM dVXZI2udtcfbcjkZTsd/pxdhWBCfGmW7WJjpJr8/71ijNR40FhQ4OA322/YgRYgcfX94 v9kvrvJy1Vwegb1ZL6qI2hKxRf8/loLdzNqq0hgPK7cWvuyueOM9SeDe0aPJxwPdK8SS 03A1NsrANdpvgWLMN8/KasCzEsMA0LHZoCjkRkQ0QUabuoKa/cd3g9R1CtgoiwQl9GDq H5yERkXRrPRnqIYayxVoyDsK9mPsSTNwsDqOAieB8BCppWjx1+WvkUirBKZvxEEZnF+q VHpA== X-Gm-Message-State: AN3rC/5B3ggJEE988foFcTWk/Dfetf/K2YWvG3whICizKm2sI0xrPKFW zgI4gr4ekrNSTg== X-Received: by 10.55.81.139 with SMTP id f133mr53014qkb.125.1493217259830; Wed, 26 Apr 2017 07:34:19 -0700 (PDT) Received: from macbook-pro-6.home (pool-108-31-94-75.washdc.fios.verizon.net. [108.31.94.75]) by smtp.gmail.com with ESMTPSA id z33sm273449qta.48.2017.04.26.07.34.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Apr 2017 07:34:18 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_8CE05B60-4E3D-41B7-AF78-8EC2F6BEAEA6" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 26 Apr 2017 10:34:18 -0400 In-Reply-To: Cc: Neil Jenkins , jmap@ietf.org To: Chris Newman References: <46F700A6-C2B1-488B-A8B4-6ACD45B03C31@oracle.com> <1493099769.3023399.955193288.6D0312CC@webmail.messagingengine.com> <33553450-82F4-4CB4-8679-C9F52D8A8839@oracle.com> <1493163974.4122214.956244160.6735E49C@webmail.messagingengine.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Jmap] Best vs Good enough - adoption of JMAP X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 14:37:04 -0000 --Apple-Mail=_8CE05B60-4E3D-41B7-AF78-8EC2F6BEAEA6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 26, 2017, at 12:49 AM, Chris Newman = wrote: > Suppose JMAP implements a server-side outbox (aka mail queue). The = JMAP client synchronizes the server-side outbox and goes offline. While = the client is offline, the message gets submitted and the user decides = they don't want to submit the message and delete it from the local = cached outbox. Now what? Have you really simplified things by adding a = server-side outbox to the mix? Why is the message in the outbox if the user doesn't want to submit it? = It should be in the drafts folder. It's a real problem if the outbox and the drafts folder are not = synchronized between clients. Insisting that the outbox be only on the = client means that every client has a different view of the state of the = mail store, even when all clients are up to date. This is confusing = and inconvenient for users. And why is it a problem for the submit service to remove stuff from the = outbox when the client isn't online? Effectively, it's just another = client making changes, something that JMAP is designed to deal with very = cleanly. --Apple-Mail=_8CE05B60-4E3D-41B7-AF78-8EC2F6BEAEA6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Apr 26, 2017, at 12:49 AM, Chris Newman <chris.newman@oracle.com> wrote:
Suppose JMAP implements a server-side = outbox (aka mail queue). The JMAP client synchronizes the server-side = outbox and goes offline. While the client is offline, the message gets = submitted and the user decides they don't want to submit the message and = delete it from the local cached outbox. Now what? Have you really = simplified things by adding a server-side outbox to the = mix?

Why = is the message in the outbox if the user doesn't want to submit it? =   It should be in the drafts folder.

It's a real problem if the outbox and = the drafts folder are not synchronized between clients.   Insisting = that the outbox be only on the client means that every client has a = different view of the state of the mail store, even when all clients are = up to date.   This is confusing and inconvenient for = users.

And why = is it a problem for the submit service to remove stuff from the outbox = when the client isn't online?   Effectively, it's just another = client making changes, something that JMAP is designed to deal with very = cleanly.

= --Apple-Mail=_8CE05B60-4E3D-41B7-AF78-8EC2F6BEAEA6-- From nobody Wed Apr 26 07:40:11 2017 Return-Path: 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 EA038129C6B for ; Wed, 26 Apr 2017 07:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 I9t6NKmOwns9 for ; Wed, 26 Apr 2017 07:40:08 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8220012EB28 for ; Wed, 26 Apr 2017 07:39:31 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id m36so2312674qtb.0 for ; Wed, 26 Apr 2017 07:39:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=rywM7p3HVI/WbmKqvz1wraKArr1ISE39Xfiip6e9vfk=; b=TfWRRWsCK4v2tVTP1A65vyjHXZbs1kqTQaHhNZ+K09i7Sen/gsm9tM7RFYHaMJ1evX ib07lGQQ4yyxJp5g4AZuJuX90aofyrBxlS7aOKMmYfSws3f7IzRfVEcHkjiGSblMlKlg +GD1P0vR03oivFUVn3Huz/PLUxV1ixXlDG1n/L00ZrCckpKf9xrHumREmyBhMHaZ2G+Z FSpqDEexKDT6kFJ+UZwZ+NsE0pIdeuMEXWbiTWoudZWjMPFDszRiw7LV/3KmAgvV9rS+ FxZ0aOzbL1mxgYUVrcq7DQS5YXFdl996GBw1Kwy3qKX82IIrg7CRWa4hxr3bUN7xG3ty 21CA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=rywM7p3HVI/WbmKqvz1wraKArr1ISE39Xfiip6e9vfk=; b=sXVz+A6kewXzR/tni0O5dmsQtwlZR5agbJdDAcOduJR/btQoZzk5DnBop4H628jM/x tLZNJcmcSDW27vdhFUCFT721G5ts+yWWBOLrZfBplISThzDpWPVqfcIfEnXWaEPJ+wKp yk2qjMK7NNx/14Vmyt620ru2FsuPfMbLVAAMooD2o7EwOu7eRzIjqrBKO82XrDsxDTVm gFJoWjIMQBDcGjsTxCkUBVk4d0v3CZahCnXIgrtcEdBINLN2z2BCi1GiC4jXGY3KndfK M2QcJ3STn/lTfsxw4aBcCTLCg0iLUaEzd97OnoephA1UWy0+qJMS9koHqCmR14Kx8fzE imBQ== X-Gm-Message-State: AN3rC/6fZAUp0wf65gW6Owvaoee9CS6faK1U7RN1jgj9zAMfKmN1Y3yd Fbjmzgn6+ON03g== X-Received: by 10.237.36.212 with SMTP id u20mr65546qtc.217.1493217570712; Wed, 26 Apr 2017 07:39:30 -0700 (PDT) Received: from macbook-pro-6.home (pool-108-31-94-75.washdc.fios.verizon.net. [108.31.94.75]) by smtp.gmail.com with ESMTPSA id o91sm285422qte.42.2017.04.26.07.39.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Apr 2017 07:39:30 -0700 (PDT) From: Ted Lemon Message-Id: <4488B4E2-53A0-44E4-911A-3A67B7EF67FC@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_4AAEA0E8-8EAB-400F-9FB4-A90FFCDCE3A3" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 26 Apr 2017 10:39:28 -0400 In-Reply-To: <01QDMH1QNOUK00008D@mauve.mrochek.com> Cc: Chris Newman , jmap@ietf.org, Neil Jenkins To: Ned Freed References: <46F700A6-C2B1-488B-A8B4-6ACD45B03C31@oracle.com> <1493099769.3023399.955193288.6D0312CC@webmail.messagingengine.com> <33553450-82F4-4CB4-8679-C9F52D8A8839@oracle.com> <1493163974.4122214.956244160.6735E49C@webmail.messagingengine.com> <01QDMH1QNOUK00008D@mauve.mrochek.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Jmap] Best vs Good enough - adoption of JMAP X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 14:40:10 -0000 --Apple-Mail=_4AAEA0E8-8EAB-400F-9FB4-A90FFCDCE3A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 26, 2017, at 9:45 AM, Ned Freed wrote: > Now take these semantics and multiply them by the number of users you = have, > which can be in the many millions. And while sometimes you can treat > this as single, system-wide queue for monitoring purposes, sometimes > you'll need to lookup and probably monitor on a per-user basis. Of course, when the user calls in with a problem with their email, the = fact that all the information about that user's email is in their unique = mail store is kind of convenient. If there is a systemic problem with = mail delivery, you would need different tools to notice it. I don't = see how one or the other of these approaches is clearly superior; what = is true is that the latter approach is what people are used to. --Apple-Mail=_4AAEA0E8-8EAB-400F-9FB4-A90FFCDCE3A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Apr 26, 2017, at 9:45 AM, Ned Freed <ned.freed@mrochek.com> wrote:
Now take these semantics and multiply = them by the number of users you have,
which can be in the = many millions. And while sometimes you can treat
this as single, system-wide queue for monitoring = purposes, sometimes
you'll need to = lookup and probably monitor on a per-user = basis.

Of = course, when the user calls in with a problem with their email, the fact = that all the information about that user's email is in their unique mail = store is kind of convenient.   If there is a systemic problem with = mail delivery, you would need different tools to notice it.   I = don't see how one or the other of these approaches is clearly superior; = what is true is that the latter approach is what people are used = to.

= --Apple-Mail=_4AAEA0E8-8EAB-400F-9FB4-A90FFCDCE3A3-- From nobody Wed Apr 26 07:55:17 2017 Return-Path: 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 893BC12EBC8 for ; Wed, 26 Apr 2017 07:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.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 7oVtwHJXQc8x for ; Wed, 26 Apr 2017 07:55:14 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8426C12EAF3 for ; Wed, 26 Apr 2017 07:55:05 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QDMIL2S51S008862@mauve.mrochek.com> for jmap@ietf.org; Wed, 26 Apr 2017 07:51:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1493218288; bh=JvoEvD8KmV7JHIT0OtMqhwn/0JA+rJux1s9upMdd6CU=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=MUjqo9+WkV3P0Iu9bL9MJKIr8HUNovSjVQjvXsPln3NOaVtF1oC8Z5TDkg6sS5NVM nsm3FVb4jlwHUXjMD3Xt/ATItTGXrLQLf8fxsI0raldKl2IQoJPj/ABGGIaXHuvTkJ RxcFjIyEwQ+iQVfz2cFrnUvexIwzk8ofJTVdvXSc= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QDLR9E01A800008D@mauve.mrochek.com>; Wed, 26 Apr 2017 07:51:25 -0700 (PDT) Cc: Ned Freed , Chris Newman , jmap@ietf.org, Neil Jenkins Message-id: <01QDMIL0HUYS00008D@mauve.mrochek.com> Date: Wed, 26 Apr 2017 07:41:28 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 26 Apr 2017 10:39:28 -0400" <4488B4E2-53A0-44E4-911A-3A67B7EF67FC@fugue.com> References: <46F700A6-C2B1-488B-A8B4-6ACD45B03C31@oracle.com> <1493099769.3023399.955193288.6D0312CC@webmail.messagingengine.com> <33553450-82F4-4CB4-8679-C9F52D8A8839@oracle.com> <1493163974.4122214.956244160.6735E49C@webmail.messagingengine.com> <01QDMH1QNOUK00008D@mauve.mrochek.com> <4488B4E2-53A0-44E4-911A-3A67B7EF67FC@fugue.com> To: Ted Lemon Archived-At: Subject: Re: [Jmap] Best vs Good enough - adoption of JMAP X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 14:55:15 -0000 > On Apr 26, 2017, at 9:45 AM, Ned Freed wrote: > > Now take these semantics and multiply them by the number of users you have, > > which can be in the many millions. And while sometimes you can treat > > this as single, system-wide queue for monitoring purposes, sometimes > > you'll need to lookup and probably monitor on a per-user basis. > Of course, when the user calls in with a problem with their email, the fact > that all the information about that user's email is in their unique mail store > is kind of convenient. Actually, it offers no utility whatsoever. If you provide the ability to answer such queries at high scale, you do it based on trasactional information produced by the message transport infrastructure. This information is fed into some kind of database that lets you lookup whatever you want for whatever combination of sender, recipient, time window, etc. you want to support. You most certainly don't want to do it by accessing the mailstores. They carry enough load as it is; using them to handle a problem that's easily separable makes no sense. There's also a nontrivial security separation concern here. The access rights associated with being able to look at transaction data are not the same as the rights needed to look at message content. Ned From nobody Wed Apr 26 07:56:24 2017 Return-Path: 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 21BF612EBEB for ; Wed, 26 Apr 2017 07:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 dmoUqHJlqEwO for ; Wed, 26 Apr 2017 07:56:21 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBDEA12EB86 for ; Wed, 26 Apr 2017 07:56:20 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id y63so2881820qkd.1 for ; Wed, 26 Apr 2017 07:56:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=5JxaSqJZr29ml5tq8F7qLZv2ebOoVC+AeRHZmLWQA4Q=; b=rKTCCqEJRuRIqWNbS6MgmM4aBPLA6VV2lelVEZnLA2R/Aq/V/j+9diS9Jd8L3xTYps 4+Jh1SEQpnLgytO5maU4VDi5wb/DObTEilWneWwoutNfbr2fWWinnvTT5i0PT+AwLFIL CfXy8wiGhmB4WaKuKpWUM8Y7Rvt4TIbrktlexGad2xOakCbasuXKhhkh4+jEk+TYQgWh 7KMb2HkVhqcJg4pnbLsWbzT5oPlnp5Z36xqz82p6cc5Xl8hBhvXvBcHMe9xOfkyCdhKG gAqnfBCfi6XeI9vbOBnm+Xk5CoaJPLCezOtVoOETDI7zG26icnePZvr56wmLe4Nkk+EL nHjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=5JxaSqJZr29ml5tq8F7qLZv2ebOoVC+AeRHZmLWQA4Q=; b=eGcnJY/hKaSTMxUHfWnv3KvYWHVloPGe25RHJ/Nvjt/5kBD0WmtEJKict2XzSaviUU cLUdT2hcKjALdmAZnpCX/W/rzMW2Yg3W8trOtm7Zv1ZkiXVBlLWJocCBpq7i/aejCapT R6M4ylx5WupSdZGh3KEB1lnlr0X7io1Yb+2fxbXXGVlJ11euVY8/T9iQvK2FSeqvQara 46Ev91vo47PFfvXc5r4ckGVW+QK8RD+6gWokFjTWHfi6Nm5l76xCpnG9KKn4cjCNrBT6 KTcve3VI7VDMJiBTfAdr3cim3cxL+eeCQTNSupnREadHum3tNU2Vql9cwREnn5+7p3n3 fL5g== X-Gm-Message-State: AN3rC/4CqiZXtS7+x7ryCUBXq3H8bYEG4MavrV34s0QCtX2gTe/1qTZT sANV80IMP9anWA== X-Received: by 10.55.87.132 with SMTP id l126mr153454qkb.29.1493218580047; Wed, 26 Apr 2017 07:56:20 -0700 (PDT) Received: from macbook-pro-6.home (pool-108-31-94-75.washdc.fios.verizon.net. [108.31.94.75]) by smtp.gmail.com with ESMTPSA id p48sm348977qte.4.2017.04.26.07.56.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Apr 2017 07:56:19 -0700 (PDT) From: Ted Lemon Message-Id: <15F2FFD3-2789-49A1-A527-DBE717CF6733@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_0FA82A24-8E5A-4121-8E6D-20FF3EA16B9C" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 26 Apr 2017 10:56:17 -0400 In-Reply-To: <01QDMIL0HUYS00008D@mauve.mrochek.com> Cc: Chris Newman , jmap@ietf.org, Neil Jenkins To: Ned Freed References: <46F700A6-C2B1-488B-A8B4-6ACD45B03C31@oracle.com> <1493099769.3023399.955193288.6D0312CC@webmail.messagingengine.com> <33553450-82F4-4CB4-8679-C9F52D8A8839@oracle.com> <1493163974.4122214.956244160.6735E49C@webmail.messagingengine.com> <01QDMH1QNOUK00008D@mauve.mrochek.com> <4488B4E2-53A0-44E4-911A-3A67B7EF67FC@fugue.com> <01QDMIL0HUYS00008D@mauve.mrochek.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Jmap] Best vs Good enough - adoption of JMAP X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 14:56:23 -0000 --Apple-Mail=_0FA82A24-8E5A-4121-8E6D-20FF3EA16B9C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 26, 2017, at 10:41 AM, Ned Freed wrote: > Actually, it offers no utility whatsoever. If you provide the ability = to answer > such queries at high scale, you do it based on trasactional = information > produced by the message transport infrastructure. This information is = fed into > some kind of database that lets you lookup whatever you want for = whatever > combination of sender, recipient, time window, etc. you want to = support. >=20 > You most certainly don't want to do it by accessing the mailstores. = They > carry enough load as it is; using them to handle a problem that's = easily > separable makes no sense. >=20 > There's also a nontrivial security separation concern here. The access = rights > associated with being able to look at transaction data are not the = same as the > rights needed to look at message content. These are all good points, but from this perspective then it doesn't = really matter where the transaction happens as long as the database can = be updated. --Apple-Mail=_0FA82A24-8E5A-4121-8E6D-20FF3EA16B9C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Apr 26, 2017, at 10:41 AM, Ned Freed <ned.freed@mrochek.com> wrote:
Actually, it offers no utility = whatsoever. If you provide the ability to answer
such queries at high scale, you do it based on = trasactional information
produced by the = message transport infrastructure. This information is fed into
some kind of database that lets you lookup = whatever you want for whatever
combination of = sender, recipient, time window, etc. you want to support.

You most certainly don't want to do it by = accessing the mailstores. They
carry enough load = as it is; using them to handle a problem that's easily
separable makes no sense.

There's also a nontrivial security = separation concern here. The access rights
associated with = being able to look at transaction data are not the same as the
rights needed to look at message = content.

These are all good points, but from this perspective then it = doesn't really matter where the transaction happens as long as the = database can be updated.

= --Apple-Mail=_0FA82A24-8E5A-4121-8E6D-20FF3EA16B9C-- From nobody Wed Apr 26 09:16:33 2017 Return-Path: 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 E8C1513149A for ; Wed, 26 Apr 2017 09:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.401 X-Spam-Level: X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 JZQz9Abwlq3t for ; Wed, 26 Apr 2017 09:16:29 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 237D313147E for ; Wed, 26 Apr 2017 09:16:20 -0700 (PDT) Received: from pps.filterd (m0083689.ppops.net [127.0.0.1]) by m0083689.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v3QGF5RH041327; Wed, 26 Apr 2017 12:16:04 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0083689.ppops.net-00191d01. with ESMTP id 2a2vbw0rkp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 26 Apr 2017 12:16:03 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v3QGG21q031608; Wed, 26 Apr 2017 12:16:03 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v3QGFncr031062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 26 Apr 2017 12:15:56 -0400 Received: from MISOUT7MSGHUBAE.ITServices.sbc.com (MISOUT7MSGHUBAE.itservices.sbc.com [130.9.129.149]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Wed, 26 Apr 2017 16:15:40 GMT Received: from MISOUT7MSGUSRCG.ITServices.sbc.com ([169.254.7.29]) by MISOUT7MSGHUBAE.ITServices.sbc.com ([130.9.129.149]) with mapi id 14.03.0319.002; Wed, 26 Apr 2017 12:15:40 -0400 From: "HANSEN, TONY L" To: Cyrus Daboo , "jmap@ietf.org" Thread-Topic: [Jmap] Submission: options for github issue Thread-Index: AQHSvQbMhkECnRTPeECyUCEQUCF1gaHU2yWA///bJwCAAErZgIAC1X2A Date: Wed, 26 Apr 2017 16:15:39 +0000 Message-ID: References: <1492997737.3312553.953738776.7D27901C@webmail.messagingengine.com> <43747FEE-5EBE-4F89-BE13-94701F88A5BA@fugue.com> <4A4B1A7AC839999470A6D83C@caldav.corp.apple.com> <14DCEF5C-CB51-442B-9A35-B64F37ECD1B4@att.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.114.249] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-26_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1704260277 Archived-At: Subject: Re: [Jmap] Submission: options for github issue X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 16:16:32 -0000 Q3lydXMsIHRoYXQgY3VzdG9taXphYmxlIHRleHQgaXMgYSBuaWNlIG9wdGlvbi4NCg0KCVRvbnkN Cg0KT24gNC8yNC8xNywgMTI6NTkgUE0sICJDeXJ1cyBEYWJvbyIgPGN5cnVzQGRhYm9vLm5hbWU+ IHdyb3RlOg0KDQogICAgSGkgVE9OWSwNCiAgICANCiAgICAtLU9uIEFwcmlsIDI0LCAyMDE3IGF0 IDQ6MzE6MDggUE0gKzAwMDAgIkhBTlNFTiwgVE9OWSBMIiA8dG9ueUBhdHQuY29tPiANCiAgICB3 cm90ZToNCiAgICANCiAgICA+IFRoYXQgaGFzIGNlcnRhaW5seSBhbHdheXMgYmVlbiBteSBwcmVm ZXJyZWQgd2F5IG9mIHNlZWluZyBCQ0NzIGhhbmRsZWQuDQogICAgDQogICAgQWN0dWFsbHkgd2hh dCB3ZSBlbmRlZCB1cCBkb2luZyBpbiBNdWxiZXJyeSBpcyBhZGQgYW4gb3B0aW9uIHdoZXJlIGEg DQogICAgc2VwYXJhdGUgbWVzc2FnZSBjb3VsZCBiZSBzZW50IHRvIGp1c3QgdGhlIGJjYyByZWNp cGllbnRzLCBidXQgd2l0aCANCiAgICBhZGRpdGlvbmFsIHRleHQgYWRkZWQgdG8gdGhlIHRvcCBv ZiB0aGUgbWVzc2FnZS4gVGhlIHRleHQgY291bGQgYmUgDQogICAgY3VzdG9taXplZCwgYnV0IHRo ZSBkZWZhdWx0IHdhcyBhIHdhcm5pbmcgbWVzc2FnZToNCiAgICANCiAgICAgICAgSU1QT1JUQU5U ISBUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gYmxpbmQtY2FyYm9uLWNvcGllZCB0byB5b3UuDQogICAg ICAgIFBsZWFzZSBkbyBub3QgcmVwbHktdG8tYWxsIG9yIGZvcndhcmQgdGhpcyB3aXRob3V0IHBl cm1pc3Npb24gb2YgdGhlDQogICAgICAgIGF1dGhvci4NCiAgICANCiAgICBUaGlzIHdhcyBkZWVt ZWQgdG8gcmVkdWNlIHRoZSBjaGFuY2Ugb2YgYWNjaWRlbnRhbCByZXBseS1hbGwgYnkgYmNjIA0K ICAgIHJlY2lwaWVudHMgKGluIHRoZSBhYnNlbmNlIG9mIHRob3NlIHJlY2lwaWVudHMnIGVtYWls IGNsaWVudHMgcHJvdmlkaW5nIA0KICAgIHRoZWlyIG93biB3YXJuaW5nIG1lY2hhbmlzbSkuDQog ICAgDQogICAgLS0gDQogICAgQ3lydXMgRGFib28NCiAgICANCiAgICANCg0K From nobody Wed Apr 26 10:37:25 2017 Return-Path: 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 44DF0129489 for ; Wed, 26 Apr 2017 10:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.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 nK8ydBwTBWEn for ; Wed, 26 Apr 2017 10:37:20 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22FB3120454 for ; Wed, 26 Apr 2017 10:37:20 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QDMO9LO1V4007TMG@mauve.mrochek.com> for jmap@ietf.org; Wed, 26 Apr 2017 10:34:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1493228040; bh=f+4urBsCp5lEwcsymUir95UqH3Xo+CR5MxerZKayKwo=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=lJ9qszszUgTJp2NEHhwM/l/GnMBW8OuNolsM6WuU3b26/F6s5r1VruCO+Jj3IUtj3 FfJnQIFSQmXS6ugvjw9J25wUSKij7DrD/tMWZLAzqOQU6hNqZnrQZuwTu85yLwoBVy UAA4wbHfaTPpubmeztCpWiRxoCMIwHmEv4Z7aZmw= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QDLR9E01A800008D@mauve.mrochek.com>; Wed, 26 Apr 2017 10:33:58 -0700 (PDT) Cc: Cyrus Daboo , "jmap@ietf.org" Message-id: <01QDMO9K81HY00008D@mauve.mrochek.com> Date: Wed, 26 Apr 2017 10:24:36 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 26 Apr 2017 16:15:39 +0000" References: <1492997737.3312553.953738776.7D27901C@webmail.messagingengine.com> <43747FEE-5EBE-4F89-BE13-94701F88A5BA@fugue.com> <4A4B1A7AC839999470A6D83C@caldav.corp.apple.com> <14DCEF5C-CB51-442B-9A35-B64F37ECD1B4@att.com> To: "HANSEN, TONY L" Archived-At: Subject: Re: [Jmap] Submission: options for github issue X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 17:37:24 -0000 > Cyrus, that customizable text is a nice option. You're think so, but I've lost track of the number of times I've received replies where that sort text was included, quoted, in the response. And this is when I was a recipient of the original message. Not the author. The problem is you cannot count on people reading the contents of the message they're responding to. This has always been true, but in the age of Twitter it's gotten much, much worse. FWIW, the approach I prefer, and which my own client uses, is to check bcc information at reply time, prompt and require signoff before allowing reply-all. But regardless, we're now talking about client quality issues that seem, at least to me, to be entirely independent of access and submission protocol. More generally, there are some problems that can be solved by switching to a different access protocols. And there are lots of problems that cannot. We need to focus on the problems that can be solved and which fit into this group's charter. Ned > Tony > On 4/24/17, 12:59 PM, "Cyrus Daboo" wrote: > Hi TONY, > --On April 24, 2017 at 4:31:08 PM +0000 "HANSEN, TONY L" > wrote: > > That has certainly always been my preferred way of seeing BCCs handled. > Actually what we ended up doing in Mulberry is add an option where a > separate message could be sent to just the bcc recipients, but with > additional text added to the top of the message. The text could be > customized, but the default was a warning message: > IMPORTANT! This message has been blind-carbon-copied to you. > Please do not reply-to-all or forward this without permission of the > author. > This was deemed to reduce the chance of accidental reply-all by bcc > recipients (in the absence of those recipients' email clients providing > their own warning mechanism). > -- > Cyrus Daboo > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap From nobody Wed Apr 26 10:54:20 2017 Return-Path: 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 3A5751296B3 for ; Wed, 26 Apr 2017 10:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 mXcmLCFMqWQS for ; Wed, 26 Apr 2017 10:54:18 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 135E1124BE8 for ; Wed, 26 Apr 2017 10:54:18 -0700 (PDT) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v3QHsEb2020927 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 26 Apr 2017 17:54:15 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.13.8/8.14.4) with ESMTP id v3QHsEKp030455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 26 Apr 2017 17:54:14 GMT Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v3QHsDOL022998; Wed, 26 Apr 2017 17:54:14 GMT Received: from [10.145.239.185] (/10.145.239.185) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 26 Apr 2017 10:54:13 -0700 From: "Chris Newman" To: "Bron Gondwana" Cc: jmap@ietf.org Date: Wed, 26 Apr 2017 10:54:11 -0700 Message-ID: In-Reply-To: <1493185260.709114.956477904.75CB343B@webmail.messagingengine.com> References: <46F700A6-C2B1-488B-A8B4-6ACD45B03C31@oracle.com> <1493099769.3023399.955193288.6D0312CC@webmail.messagingengine.com> <33553450-82F4-4CB4-8679-C9F52D8A8839@oracle.com> <1493163974.4122214.956244160.6735E49C@webmail.messagingengine.com> <1493185260.709114.956477904.75CB343B@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Subject: [Jmap] simpler future release & unsend without outbox (was Re: Best vs Good enough - adoption of JMAP) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 17:54:19 -0000 On 25 Apr 2017, at 22:41, Bron Gondwana wrote: >> I really want a fourth option for server implementation: >> >> 4. The mail store and mail queue are completely separate. The mail >> queue >> daemon never accesses the mail store. The set of actions JMAP >> performs >> on objects in the mail queue is limited to only those that are >> strictly >> necessary to achieve a useful goal (envelope extensions like future >> release at submission time, unsend for messages still in local queue, >> and status feedback tagging on sent messages). > > You appear to be proposing one of: > > a) there is no support for delayed sending or undo > b) the user has no visibility or control of queued messages after > submitting them > c) the user can control queued messages, but needs to use a different > protocol than JMAP to do it > d) a new object type for queued messages needs to be defined in JMAP, > with operations that allow achieving the above useful goals. > > If (d), are you willing to write up the object definitions and client > advice for how they would be used, so they can be tested? I'll describe a model that achieves my goal (which is to provide the desired future release & unsend functionality without requiring the server to implement a storage model with combined mail store and mail queue semantics). I don't want to get bogged down in specification details yet. Here's one way to accomplish my goal: 1. Get rid of the server-side outbox. We only have a drafts folder and a sent folder. 2. Add a submission command with envelope (same structure as SMTP envelope but JSON syntax and quoting). We pass this command a reference to a draft message in the drafts folder, and if the submission succeeds, the message is moved to the sent folder with the envelope as an annotation. The envelope can include the already-standard future release extension. 3. Add an unsend command which takes a reference to a message in the sent folder. If the unsend succeeds, the message can be moved back to the drafts folder as part of this action. How the server correlates a message in the sent folder with a message in the mail queue is an implementation detail; the spec need not specify that detail in order to provide the functionality with this model. 4. Add a way to search/select messages in the Sent folder that may be possible to unsend. This model has a lot of advantages over the outbox model: * Every server that supports future release and unsend will provide the same interface to the client. No need for the "always empty outbox" alternative server behavior that you'll see with the outbox model. * This does not unnecessarily constrain server implementation, and permits simpler server designs. * This preserves clean mail store and mail queue separation including the security and operational benefits that provides. * This makes it clear when the message enters the submission system. There's no confusion as one has with an outbox model where a message in the outbox may be submitted (if it's on the server) or maybe not (if the client is offline when the message moves to the outbox). * Submission can have semantics fully compatible with existing infrastructure, making this easier/faster to deploy. * The "outbox" model constrains unsend to only work if the message is in the outbox. This model has no such constraint and works the same regardless of where a message that can be "unsent" lives in the infrastructure. - Chris From nobody Wed Apr 26 12:09:13 2017 Return-Path: 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 3D159128C84 for ; Wed, 26 Apr 2017 12:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 6Dra7OPVaIHC for ; Wed, 26 Apr 2017 12:09:10 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D2F61205F1 for ; Wed, 26 Apr 2017 12:09:10 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id h123so9476359qke.0 for ; Wed, 26 Apr 2017 12:09:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=xM4kxtCPfe0o79AdHBsI9UraN2+mx3ItkYroj645Oww=; b=mrPY93V1pQQqEuW2x1o79siE8iHDn2bAEMjwK6bQgjHM8LbgBKl2NzZO4/6iN3aWp7 idDp0cm+l5cprTlU8W8CH+OJnY2dYqQw/whfMLgnzcb6I9zkvHz1EGN5x9/drIXzaUEn SNAV173Vkfq1kkYaw+SWUlF6SUDcbrwVBmBh/StP3+nQtaPUahTC+Mu23s/+QBl+i2Wk 1jaSBAKzIrf00uiK6O+et3Kr15SNcbvHfx+1KkQDjbALR1YpnjZnfXV8Dp7AOZ/zkDlH AKWb7Gz5a2wMBuyYVzyYBrAmIlWmQgRSkxEmvHsMp+zfvXlu7aiTzFAz5q++tGVU/jsK 3h7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=xM4kxtCPfe0o79AdHBsI9UraN2+mx3ItkYroj645Oww=; b=FAauw2nGpAfHeEYd+yS6ZmxBT8oWIrIxtQT+sTfEs0gnjOSw6fSmL2DMKfvgkiK8wL JilB977ICMpZbtBKC2381jnJk3jwmORuKevMNj9SMIlpKad7Mg/g6YRojukz8CzC7MW0 xRUc2sXWvnElA68C+cevXq7q3oWPbmzecfZyHGz0TlqaXCfGAr0J0ztaPDq6kJ/IRwKh TMtgPt3rTMw1oVtYfJewPf6hOUFDyoWUxuOjPAEItw22TE8eGNMpYfXjz2LQtS+TJpUI xMR+NQdJQFVOiOPY5IBmF8F+z+4JgX0imUOOSQTIhg6HXs3yh52mX6coIJO7tG0QZcJT 0b6g== X-Gm-Message-State: AN3rC/7QmRBrH8Ixxgvhbh7XC3nJ+T0byi0BVwM4ft1fSlvfJTuKwAxc xANSGcSuTnJJ8w== X-Received: by 10.55.19.86 with SMTP id d83mr1449820qkh.196.1493233749517; Wed, 26 Apr 2017 12:09:09 -0700 (PDT) Received: from macbook-pro-6.home (pool-108-31-94-75.washdc.fios.verizon.net. [108.31.94.75]) by smtp.gmail.com with ESMTPSA id x26sm75374qtx.69.2017.04.26.12.09.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Apr 2017 12:09:08 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_E37A0006-0649-4608-8025-3BF8A7C3DEEB" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 26 Apr 2017 15:09:07 -0400 In-Reply-To: Cc: Bron Gondwana , jmap@ietf.org To: Chris Newman References: <46F700A6-C2B1-488B-A8B4-6ACD45B03C31@oracle.com> <1493099769.3023399.955193288.6D0312CC@webmail.messagingengine.com> <33553450-82F4-4CB4-8679-C9F52D8A8839@oracle.com> <1493163974.4122214.956244160.6735E49C@webmail.messagingengine.com> <1493185260.709114.956477904.75CB343B@webmail.messagingengine.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Jmap] simpler future release & unsend without outbox (was Re: Best vs Good enough - adoption of JMAP) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 19:09:12 -0000 --Apple-Mail=_E37A0006-0649-4608-8025-3BF8A7C3DEEB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 26, 2017, at 1:54 PM, Chris Newman = wrote: > I'll describe a model that achieves my goal (which is to provide the = desired future release & unsend functionality without requiring the = server to implement a storage model with combined mail store and mail = queue semantics). > [...] This looks good to me, FWIW. :) --Apple-Mail=_E37A0006-0649-4608-8025-3BF8A7C3DEEB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Apr 26, 2017, at 1:54 PM, Chris Newman <chris.newman@oracle.com> wrote:
I'll describe a model that achieves my = goal (which is to provide the desired future release & unsend = functionality without requiring the server to implement a storage model = with combined mail store and mail queue = semantics).
[...]

This looks = good to me, FWIW. :)

= --Apple-Mail=_E37A0006-0649-4608-8025-3BF8A7C3DEEB-- From nobody Wed Apr 26 12:22:30 2017 Return-Path: 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 F0417126CE8 for ; Wed, 26 Apr 2017 12:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.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 yeG1l_daE6na for ; Wed, 26 Apr 2017 12:22:28 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F04531201FA for ; Wed, 26 Apr 2017 12:22:27 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QDMNWNTXDS009N7F@mauve.mrochek.com> for jmap@ietf.org; Wed, 26 Apr 2017 10:24:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1493227461; bh=qA+gbDitxIqFf1HzdYt0T9C2J/bmxO7IsRMSGhePi1U=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=GWR5vt2CDWeYr8wOcRc7VyiI/xRuruSmIBcM4rTPmmN0OIIsu0IZSVE9b+WPP3RIz OcHQ3z5b/7eB5DkyGx82xcT1eKItltDlnbde4yEGlbGXBHqbOJ4d4Cp0LFZ5JXFtFE fOsO9vqJ9YUb+9PQZ9P8TXvwZDLSHmGhHrf1at5w= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QDLR9E01A800008D@mauve.mrochek.com>; Wed, 26 Apr 2017 10:24:19 -0700 (PDT) Cc: Ned Freed , Chris Newman , Neil Jenkins , jmap@ietf.org Message-id: <01QDMNWLS3IG00008D@mauve.mrochek.com> Date: Wed, 26 Apr 2017 10:09:03 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 26 Apr 2017 10:56:17 -0400" <15F2FFD3-2789-49A1-A527-DBE717CF6733@fugue.com> References: <46F700A6-C2B1-488B-A8B4-6ACD45B03C31@oracle.com> <1493099769.3023399.955193288.6D0312CC@webmail.messagingengine.com> <33553450-82F4-4CB4-8679-C9F52D8A8839@oracle.com> <1493163974.4122214.956244160.6735E49C@webmail.messagingengine.com> <01QDMH1QNOUK00008D@mauve.mrochek.com> <4488B4E2-53A0-44E4-911A-3A67B7EF67FC@fugue.com> <01QDMIL0HUYS00008D@mauve.mrochek.com> <15F2FFD3-2789-49A1-A527-DBE717CF6733@fugue.com> To: Ted Lemon Archived-At: Subject: Re: [Jmap] Best vs Good enough - adoption of JMAP X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 19:22:29 -0000 > On Apr 26, 2017, at 10:41 AM, Ned Freed wrote: > > Actually, it offers no utility whatsoever. If you provide the ability to answer > > such queries at high scale, you do it based on trasactional information > > produced by the message transport infrastructure. This information is fed into > > some kind of database that lets you lookup whatever you want for whatever > > combination of sender, recipient, time window, etc. you want to support. > > > > You most certainly don't want to do it by accessing the mailstores. They > > carry enough load as it is; using them to handle a problem that's easily > > separable makes no sense. > > > > There's also a nontrivial security separation concern here. The access rights > > associated with being able to look at transaction data are not the same as the > > rights needed to look at message content. > These are all good points, but from this perspective then it doesn't really > matter where the transaction happens as long as the database can be updated. First, it most certainly does matter where the transaction happens, and the fact that it isn't at all clear where submission to the transport infrastructure occurs is a big problems with these magic folder proposals. Second, just as it makes no sense to use the store as a means of tracking transactions - and in that regard I'll note that transactions have to be trackable even if the associated messages have been deleted - it also makes no sense to use the transaction log as a queue management facility. For one thing, general-purpose databases tend to suck at implementing anything but the simplest of queues, and mail queues are anything but simple. The operational constraints are also very different. The transaction log is almost always a lower priority thing than getting mail processed. So you can take some liberties with coherence, update speed, and even reliability and save some $$$. This is important when you realize that it's often necessary to retain transacton records for long periods of time. In contrast, the queue manager database needs to be up to date at all times, and in the event of failure it needs to be possible to sync it up to reality in fairly short order. Ned From nobody Wed Apr 26 15:08:49 2017 Return-Path: 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 8A7B3126CE8 for ; Wed, 26 Apr 2017 15:08:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 kqs18V6SxICV for ; Wed, 26 Apr 2017 15:08:46 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A654C12940F for ; Wed, 26 Apr 2017 15:08:42 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id j201so17697287oih.2 for ; Wed, 26 Apr 2017 15:08:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XJWwkjZ8Ys6oJvQ2lmOoSoslS8E7NzGVNPjhk096sTE=; b=PgodcwNXUrpZHD+h/hPEQJFtJA20DC2jpsVgiDsfKSvQxGsMK/MqkS7hhnPOMeW1oC 2EOmXaFCQQpVYthoEorJwciaIJ2cLKvv4NEEmlb70n08MO2jSYn6Fw1xAm4oYmnvKYrH 1FsHccG9AqW8pbirY4fPJ+W6m8TnEv8/RanMfco6vnlDneezczScvn4I9SqqI5ZYqWBY E5lDEBzgYxv7PcXWaMIV8yVdUXuKQFfjI+SXvMw8uAxe902obAlFw0yGdCtYnBaojai9 U2OcxMurcd3OoKxtjngwmW5AY44Qzlf89L7u74bQn51xss5nV8otl3hU+y277BrF/Zbq N8+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XJWwkjZ8Ys6oJvQ2lmOoSoslS8E7NzGVNPjhk096sTE=; b=PhCcnRK9m72L3qGnq3mAp6uSRHl4yxDBDExkqUZI9mWgOVDpNmlhPCjXsp/dGyNuTn NTPLD+v01iPSm2/mm8EiHWp5ZYGunbsDmi0JI2CoKluluQIdi6pzRDypCmuF3BUusOuB CerHEToYfE7sIOAtQhqHx2C45pupITuvi3WGT5zEeeo0Ovpc984ogbkCz1t1+0VS9zOI HWbmWQxMztQLcUluGtB/rXrZUsd54rr/Uyg/fqFgAvZ6UxxoPesAdLY1rbR0DfhhvlZk rGujuk34YdikSbQvwYC6ALM0+MkwGelyEOuTw641+YZRCHB1Os+iQYN6FKFWvKR6DFJh SLrw== X-Gm-Message-State: AN3rC/72dBqV8jO64FI94aFdnsHFhhV2PeU393tbIRR4KTpYlN2C/NB/ fh5rImORPuLhEXz4ImBJM7fW5s9J1oLJ X-Received: by 10.157.15.205 with SMTP id m13mr1214537otd.6.1493244521530; Wed, 26 Apr 2017 15:08:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.8.101 with HTTP; Wed, 26 Apr 2017 15:08:40 -0700 (PDT) In-Reply-To: <00616B85-F365-4B1F-82EA-2FF2623CED77@oracle.com> References: <20170421001702.24991.qmail@ary.lan> <00616B85-F365-4B1F-82EA-2FF2623CED77@oracle.com> From: Brandon Long Date: Wed, 26 Apr 2017 15:08:40 -0700 Message-ID: To: Chris Newman Cc: Adrien de Croy , "jmap@ietf.org" Content-Type: multipart/alternative; boundary=001a113d0c78451ca6054e19159d Archived-At: Subject: Re: [Jmap] Address Validation (was Re: Submission) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 22:08:48 -0000 --001a113d0c78451ca6054e19159d Content-Type: text/plain; charset=UTF-8 This is the second time you've asked for the SMTP status codes and enhanced status codes, I'm very unclear what the utility of those would be, and why we would need to expose them to JMAP. We very rarely care about the difference between the codes beyond ok/temp/perm, and find that folks are fairly inconsistent about the enhanced codes, or that the enhanced codes don't actually translate into useful information from a user perspective. At best they provide a fallback for what is otherwise a long list of regexes for the error messages themselves. It also ties the implementation to SMTP when SMTP may not even be used, ie local delivery on a service using JMAP may never use SMTP. It also ties it to SMTP when we know that we can't implement it with SMTP (due to address scraping concerns). One could make a better case for tying it to LDAP, for example. Brandon On Fri, Apr 21, 2017 at 6:02 PM, Chris Newman wrote: > On 20 Apr 2017, at 23:16, Adrien de Croy wrote: > >> In article someone >>> write: >>> >>>> I'd love to see a mail client that does at least initial validation on >>>> destination email addresses as they are added to the message, so that >>>> errors in the addresses which can be resolved at that stage (e.g. >>>> NXDOMAIN) can be raised with the email author before the mail is even >>>> submitted. >>>> >>> >>> This is quite the can of worms. It's easy enough to look up a domain >>> and see if it has an A or an MX, but whatever you were planning to do >>> to validate mailboxes will get you blacklisted as a listwashing >>> spammer. >>> >> sure, I think there are fundamental issues with trying to go further than >> an A/MX for now, but if we built in a mechanism to verify addresses, it >> could be extended later, rather than being blocked off for all of eternity. >> >> Even A/MX would have some value. Who knows what kind of trusted mail >> delivery infrastructure may come out in the future, at some stage we have >> to fix SMTP. Forever is a long time. >> > > The present model for MUA mail address validation is to authenticate to an > IETF standard submission server, issue a MAIL FROM + RCPT TO + RSET. > Anyway, I support adding a feature in JMAP that does the equivalent of > performing this sequence of commands on the Submission server and returns a > 3-digit SMTP status code, optionally SMTP enhanced status codes (see RFC > 3463 section 3.2) and text string. > > This is quite extensible and I believe this specific functionality is > in-scope of the JMAP charter as Submission (RFC 6409) is explicitly > in-scope. Doing address validation this way is already quite powerful. For > example, if the submission server chooses to implement the SMTP 251/551 > response codes for local users, the mail client gains the ability to prompt > the user to correct the address book entry for that recipient. > > How much validation the submission server does then becomes a > quality-of-implementation issue (and there are, of course, security/privacy > issues). Future work would be to define additional SMTP/Submit enhanced > status codes for additional address validation, but that's presently > out-of-scope for the JMAP charter. > > The JMAP charter does not permit development of a new address validation > mechanism and I object to development of a new incompatible validation > mechanism on the grounds that having two mechanisms to perform the same > function is poor design, when a full-standard mechanism to do address > validation already exists. I support mapping the existing Submission > validation mechanism to JMAP in a way that preserves all the semantics of > the existing mechanism. > > - Chris > > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap > --001a113d0c78451ca6054e19159d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This is the second time you've asked for the SMTP stat= us codes and enhanced status codes, I'm very unclear what the utility o= f those would be, and why we would need
to expose them to JMAP.

We very rarely care about the difference between the code= s beyond ok/temp/perm, and find that folks are fairly inconsistent about th= e enhanced codes, or that the enhanced codes don't actually translate i= nto useful information from a user perspective.=C2=A0 At best they provide = a fallback for what is otherwise a long list of regexes for the error messa= ges themselves.

It also ties the implementation to SMTP when SMTP ma= y not even be used, ie local delivery on a service using JMAP may never use= SMTP.=C2=A0 It also ties it to SMTP when we know that we can't impleme= nt it with SMTP (due to address scraping concerns).

One could make a= better case for tying it to LDAP, for example.

Br= andon

= On Fri, Apr 21, 2017 at 6:02 PM, Chris Newman <chris.newman@oracle.c= om> wrote:
On 20 Apr 2017, = at 23:16, Adrien de Croy wrote:
In article <emd3533c0d-dc08-45c3-801c-07972858ad64@bodybag> some= one write:
I'd love to see a mail client that does at least initial validation on<= br> destination email addresses as they are added to the message, so that
errors in the addresses which can be resolved at that stage (e.g.
NXDOMAIN) can be raised with the email author before the mail is even
submitted.

This is quite the can of worms.=C2=A0 It's easy enough to look up a dom= ain
and see if it has an A or an MX, but whatever you were planning to do
to validate mailboxes will get you blacklisted as a listwashing
spammer.
sure, I think there are fundamental issues with trying to go further than a= n A/MX for now, but if we built in a mechanism to verify addresses, it coul= d be extended later, rather than being blocked off for all of eternity.

Even A/MX would have some value.=C2=A0 Who knows what kind of trusted mail = delivery infrastructure may come out in the future, at some stage we have t= o fix SMTP.=C2=A0 Forever is a long time.

The present model for MUA mail address validation is to authenticate to an = IETF standard submission server, issue a MAIL FROM + RCPT TO + RSET. Anyway= , I support adding a feature in JMAP that does the equivalent of performing= this sequence of commands on the Submission server and returns a 3-digit S= MTP status code, optionally SMTP enhanced status codes (see RFC 3463 sectio= n 3.2) and text string.

This is quite extensible and I believe this specific functionality is in-sc= ope of the JMAP charter as Submission (RFC 6409) is explicitly in-scope. Do= ing address validation this way is already quite powerful. For example, if = the submission server chooses to implement the SMTP 251/551 response codes = for local users, the mail client gains the ability to prompt the user to co= rrect the address book entry for that recipient.

How much validation the submission server does then becomes a quality-of-im= plementation issue (and there are, of course, security/privacy issues). Fut= ure work would be to define additional SMTP/Submit enhanced status codes fo= r additional address validation, but that's presently out-of-scope for = the JMAP charter.

The JMAP charter does not permit development of a new address validation me= chanism and I object to development of a new incompatible validation mechan= ism on the grounds that having two mechanisms to perform the same function = is poor design, when a full-standard mechanism to do address validation alr= eady exists. I support mapping the existing Submission validation mechanism= to JMAP in a way that preserves all the semantics of the existing mechanis= m.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - Chris

_______________________________________________
Jmap mailing list
Jmap@ietf.org
https://www.ietf.org/mailman/listinfo/jmap

--001a113d0c78451ca6054e19159d-- From nobody Wed Apr 26 15:24:12 2017 Return-Path: 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 6E9B912946C for ; Wed, 26 Apr 2017 15:24:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 URt2iQoX58Xe for ; Wed, 26 Apr 2017 15:23:57 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A18391270FC for ; Wed, 26 Apr 2017 15:23:57 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id j201so18064671oih.2 for ; Wed, 26 Apr 2017 15:23:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=B6fyUz8JbecFdqBXiEMRgCXLuy1qdpqxffyoYNAj+ZA=; b=GkoCjvXvUAb8xFSowrkKSldCTsXazbUVpwTOfciE1duv3YYE2kHLEqNYs5tiJsEt/K ZeyBNg4Vlz7uMSgmCxehhANkOZlAW+1lGbX1HQmuz4MHLxT4wZILt27U1sKCbsyRAr2Q nM9M5XPgZitCApTGPGLloQOVh4fM6Wi/fNvT6qK32N+wbHfNy7JB1Gp8vY4HZh/QA2PQ J/tvmjTxdkUhbisO3iwevz2oBLLGNOExC+AC5sV5RNKV5DdyIfw8vlQwOwkxEQFsn9+B MOzdLg9zJ7saUcaXZDftVthHQJawb6y5vovkjcsoY8kqAmenRPoVVrCiHbgt94IEgbTR WeYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=B6fyUz8JbecFdqBXiEMRgCXLuy1qdpqxffyoYNAj+ZA=; b=SXL7AoAhGwwFsTqrIFeXOeNYYoDdC1u18AHkLevtZsfvsjhCWF3YyeKXvL4VEjcdjD klvooFF5pc96Up2zKs3iL/GSYD/3Slfp4cN1r+Udt4oVpRrQhilpdNBAAEfwPiiJ8tL1 O03K/RRgum5cacAiB4zQMFiPGbTXoR0fr8rSzk/P2viEMqOlv0GV8QD3GqunyyXft/nI ZF0h6koC3bjGIZgC78YS7qvF3TjdcEzcL+hvgSyrdJSYp0j2DNEyyiUF6G3Ky6NlONnP IGJQ3RiLQo0kRcOPHn1o7vZYIi2PAjJrL2E3vEgMNMvP73HgD+DVLvRNiX15H57ZyQoG l2wA== X-Gm-Message-State: AN3rC/5tyw0LhwrtuM6ADriEUGwfFZLddwxrJIgfL/mKAjF4X9mN7cCS jLBeqPTy3VfOAC6jwO7A5cPzcZcQhSqjnn0= X-Received: by 10.157.15.205 with SMTP id m13mr1245510otd.6.1493245436624; Wed, 26 Apr 2017 15:23:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.8.101 with HTTP; Wed, 26 Apr 2017 15:23:56 -0700 (PDT) In-Reply-To: <01QDMH1QNOUK00008D@mauve.mrochek.com> References: <46F700A6-C2B1-488B-A8B4-6ACD45B03C31@oracle.com> <1493099769.3023399.955193288.6D0312CC@webmail.messagingengine.com> <33553450-82F4-4CB4-8679-C9F52D8A8839@oracle.com> <1493163974.4122214.956244160.6735E49C@webmail.messagingengine.com> <01QDMH1QNOUK00008D@mauve.mrochek.com> From: Brandon Long Date: Wed, 26 Apr 2017 15:23:56 -0700 Message-ID: To: Ned Freed Cc: Chris Newman , jmap@ietf.org, Neil Jenkins Content-Type: multipart/alternative; boundary=001a113d0c78d050ad054e194b15 Archived-At: Subject: Re: [Jmap] Best vs Good enough - adoption of JMAP X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 22:24:01 -0000 --001a113d0c78d050ad054e194b15 Content-Type: text/plain; charset=UTF-8 On Wed, Apr 26, 2017 at 6:45 AM, Ned Freed wrote: > On 25 Apr 2017, at 16:46, Neil Jenkins wrote: >> > I think there's been some misconception over the intended semantics of >> > the outbox proposal. The outbox was never intended to be the >> > submission >> > queue, with mail queue semantics. It is intended as a standard >> > mailbox, >> > with mailstore semantics, because it is where messages go **before** >> > they are passed on to submission. The server would validate the >> > message/envelope at the time of moving it to the outbox to ensure it >> > can >> > be accepted for submission later of course. If you have existing >> > mailstore + SMTP infrastructure, implementation is not much more than >> > having some small demon that triggers to take the message from the >> > mailstore and submit it to the SMTP queue at the appropriate time. >> > > And as soon as you add that "small daemon" (also known as a mail queue >> processing daemon), you've now required the mailstore to also have mail >> queue semantics. This includes key semantics such as: the mail queue >> daemon has full read / delete access to those messages even when the >> user is offline. If the delivery doesn't happen when the user expects, >> the user is going to make a support call, so we now need all the >> monitoring, logging and robustness that comes with a mail queue. And >> addresses that were valid at the time the message entered this mail >> queue can become invalid later, so there has to be bounce-processing for >> when that happens, etc, etc. >> > > Now take these semantics and multiply them by the number of users you have, > which can be in the many millions. And while sometimes you can treat > this as single, system-wide queue for monitoring purposes, sometimes > you'll need to lookup and probably monitor on a per-user basis. > > I also assume there won't be a hardcoded name or location for this special > use mailbox. So its specialness arises from some sort of attribute. Can > that attribute be set? Reset? Can it be set on more than one mailbox? > If not why not? > > It's not that I can' think of various possible ways to implement all this > at > scale. I can. But none of them are easy. I think a modern mail store already has need for this type of scheduled events for many cases, and as such is implemented by many of them. Off the top of my head, beyond undo send/future send, there is also automatic emptying of the trash, remind me later, and enterprise style retention policies. Once you have such a model, you'll find it useful for a bunch of other things, such as data migration or applying changes across a very large mail store. Brandon --001a113d0c78d050ad054e194b15 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Apr 26, 2017 at 6:45 AM, Ned Freed <ned.freed@mrochek.com<= /a>> wrote:
On 25 Apr 2017, at 16:46, Neil Jenkins wrote:
> I think there's been some misconception over the intended semantic= s of
> the outbox proposal. The outbox was never intended to be the
> submission
> queue, with mail queue semantics. It is intended as a standard
> mailbox,
> with mailstore semantics, because it is where messages go **before** > they are passed on to submission. The server would validate the
> message/envelope at the time of moving it to the outbox to ensure it > can
> be accepted for submission later of course. If you have existing
> mailstore + SMTP infrastructure, implementation is not much more than<= br> > having some small demon that triggers to take the message from the
> mailstore and submit it to the SMTP queue at the appropriate time.

And as soon as you add that "small daemon" (also known as a mail = queue
processing daemon), you've now required the mailstore to also have mail=
queue semantics. This includes key semantics such as: the mail queue
daemon has full read / delete access to those messages even when the
user is offline. If the delivery doesn't happen when the user expects,<= br> the user is going to make a support call, so we now need all the
monitoring, logging and robustness that comes with a mail queue. And
addresses that were valid at the time the message entered this mail
queue can become invalid later, so there has to be bounce-processing for when that happens, etc, etc.

Now take these semantics and multiply them by the number of users you have,=
which can be in the many millions. And while sometimes you can treat
this as single, system-wide queue for monitoring purposes, sometimes
you'll need to lookup and probably monitor on a per-user basis.

I also assume there won't be a hardcoded name or location for this spec= ial
use mailbox. So its specialness arises from some sort of attribute. Can
that attribute be set? Reset? Can it be set on more than one mailbox?
If not why not?

It's not that I can' think of various possible ways to implement al= l this at
scale. I can. But none of them are easy.

I = think a modern mail store already has need for this type of scheduled event= s for many cases, and as such is implemented by many of them.
Off the top of my head, beyond undo send/future send, there is = also automatic emptying of the trash, remind me later, and enterprise style= retention policies.
Once you have such a model, you'll find = it useful for a bunch of other things, such as data migration or applying c= hanges across a very large mail store.

Brandon
--001a113d0c78d050ad054e194b15-- From nobody Wed Apr 26 15:25:48 2017 Return-Path: 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 C5E87128B8D for ; Wed, 26 Apr 2017 15:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 0u3ml8PwDE0i for ; Wed, 26 Apr 2017 15:25:45 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D23701272E1 for ; Wed, 26 Apr 2017 15:25:44 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id j201so18105405oih.2 for ; Wed, 26 Apr 2017 15:25:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7FaHU24E51tlGRjmg2P19mMDReqgKnHtHUOnlyttHts=; b=P9zV+cU5ven4BCOOqN2Z4z3U6SehVNcKZGItLXWX4BojBlrUfXDMFj0pimMAVHeS10 ok0a9/Mms525WgadFg9cIQp4X1DnVg7QQlU7wXDTUOnaEWFOMWfB2XPzSfjODkzQNgTN R7OZJFJscRHKqsrAwbmUJNzXGYBD8Td/drZdkU11a2wCg9i+dkfK8Gh2WDzEObobjFpo 7njZQsAOCSHx6waKQHQYYbO7akO3w1sZHVpY01iUMfSjg6nVTFZL4PxUw2Ioho8A0jp4 iI8wk+QssukY3O46339rEq2kndDyBnE6t1egL0l+26ol8z1W1gqkSX4kbSzrEC48B4Rz tqrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7FaHU24E51tlGRjmg2P19mMDReqgKnHtHUOnlyttHts=; b=nVV0+6kK67Rh7LorAE8IePQ5+Gm+W7LTqUHEpP6y9DuYIL2KXuXiSwwowZGqp9icTK 47KSW09yaoC/THeMl0bC63e2IrPEhxUQQ0AXzW+fHS3cLM3pKu9KAcnGq7UfeOFaVFD1 0dnNDAzqgm1+DFVzd9ED54N2Mv+xsGag54xgGzVPVN6J6ifvxJ1XIQgBnvCpTOMkZKE5 R6McturT/wlIlP4u6kN6Jusejj2yU/b4j6pbDRmiscYkAMCtczbltaZg7lV1yyqUVKDo oq2+NHflYjDVv61LhRe+olouEmxhM1oYSC20HpEAX0sMUjyRhBb55bayUmUgUvnAWQxu 2rHg== X-Gm-Message-State: AN3rC/4uxb02EQkeEyJ3tD8lH+2gsr7Xrz3Bshjp+6hxNundlhCXu/jL 6PghWYYr498rxjGka1NGqCNutbhmcep/ X-Received: by 10.157.39.161 with SMTP id c30mr1272126otb.135.1493245543856; Wed, 26 Apr 2017 15:25:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.8.101 with HTTP; Wed, 26 Apr 2017 15:25:43 -0700 (PDT) In-Reply-To: <46F700A6-C2B1-488B-A8B4-6ACD45B03C31@oracle.com> References: <46F700A6-C2B1-488B-A8B4-6ACD45B03C31@oracle.com> From: Brandon Long Date: Wed, 26 Apr 2017 15:25:43 -0700 Message-ID: To: Chris Newman Cc: Adrien de Croy , "jmap@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c04f8e234bc4b054e19522a Archived-At: Subject: Re: [Jmap] Best vs Good enough - adoption of JMAP X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 22:25:47 -0000 --94eb2c04f8e234bc4b054e19522a Content-Type: text/plain; charset=UTF-8 On Mon, Apr 24, 2017 at 5:39 PM, Chris Newman wrote: > On 24 Apr 2017, at 15:43, Adrien de Croy wrote: > >> On the topic of best vs good enough. >> > > This is a misleading dichotomy for an engineering discussion. My immediate > response when you say "best" is "best for whom?" If you design the best > possible protocol for end-user experience, it will place unreasonable > requirements on servers and won't deploy. Good engineering involves > tradeoffs, cost/benefit analysis, deployability analysis, extensibility > design, etc. > > I agree they are perhaps opposed, you could say that good enough is the >> enemy of best however, since once you have something that is good enough, >> your incentive to do any better is greatly diminished. >> >> However, we are up against several obstacles when it comes to adoption of >> JMAP. >> >> 1. Server authors won't want to add support unless there are clients >> 2. Client authors won't want to add support unless there are servers >> 3. Client or server authors won't want to add support unless they can >> make things significantly better for mail users. >> > > 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. > > 4. We are losing customers to alternate messaging systems. >> >> If our target is just going to end up providing no benefits to users over >> what we already have with IMAP+SMTP, then nobody will bother. >> >> Where it gets interesting for me personally at least is if we can push >> the boundary of mail experience. In many cases this can be done in the MUA >> but in some cases it requires support from the protocols. >> >> I hear the arguments that the more complex we make the spec, the less >> likely it will be implemented, at least correctly. I'm not a fan of >> complexity either, and neither of my suggestions do I consider to be >> particularly complex. >> >> My argument is that if the design doesn't hold out a carrot for better >> mail experience for users, then nobody will bother, and we're wasting our >> time here, which would be a shame because we have the potential to achieve >> a lot here. >> >> At the moment, there is a benefit on the table, mostly being the ability >> to only require configuration of access to 1 service (that's if JMAP does >> submission). >> >> I believe we should be looking for opportunities to make mail the best >> experience possible, come up with ideas, and we may decided to defer some >> or not implement others, but we should keep them in mind so that perhaps we >> don't close off the path to some of them. We don't need another protocol >> that is hamstrung by lack of foresight. >> >> there are plenty of ideas around, look at the competition. >> > > Email is the most widely deployed multi-vendor messaging system on the > Internet. The major value of doing JMAP as a standard is to get > multi-vendor deployment. A walled garden will always have features that an > open multi-vendor system can't achieve (simply for privacy reasons). Yes, > we should look at the features that are popular in walled garden messaging > systems and do a cost/benefit analysis. If the cost is low and benefit is > high, let's consider it. But if the cost is high or the feature will > involve a lot of careful design work and is outside the charter scope, then > you'll get opposition to adding that feature to the JMAP base spec. > > A multi-vendor standard needs to support both small and large deployments > and support both cloud and on-premises deployments. There are hundreds of > deployed IMAP and Submission server implementations on the Internet and > JMAP will deploy a lot faster if it "plays well" with those > implementations. And by "play well", I mean it can be added to an existing > deployment without major infrastructure changes. > > 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. > > Suppose we remove the "outbox" model from JMAP and replace it with a > submission command with envelope extensions. Now suppose we want to require > JMAP servers to support BINARYMIME submission (and/or append) as a boon to > JMAP submission client authors? 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). Want to have the JMAP submission command handle both > the \Sent folder copy and the Submission without duplicate data > transmission? I think we need to do that. Want to have the base JMAP > submission or append command include IMAP CATENATE functionality (assemble > a message including server-stored attachments in order to "forward without > download")? I have no problem with that. > > There's quite a bit of room to improve the JMAP client author's experience > without forcing major infrastructure changes. The WG exists to discuss the > cost/benefit of various features and make an engineering judgment call. The > proposals that are most likely to succeed are ones that can be implemented > in a JMAP proxy without significant changes to IMAP/Submission. And > proposals that would require reasonably straightforward or well-understood > IMAP/Submission extensions are worth considering (e.g., if I need a > per-user unique/persistent message identifier for IMAP, I understand the > implications of that). > But, if all JMAP is is a proxy of existing protocols, then it seems like an expensive undertaking for little gain. And does that mean any future extensions have to be also implemented in IMAP? Brandon --94eb2c04f8e234bc4b054e19522a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Apr 24, 2017 at 5:39 PM, Chris Newman <chris.newman@orac= le.com> wrote:
On 24 Apr 2017, at 15:43, Adrien de Croy wrote:
On the topic of best vs good enough.

 This is a misleading dichotomy for an engineering discussion. My immediate = response when you say "best" is "best for whom?" If you= design the best possible protocol for end-user experience, it will place u= nreasonable requirements on servers and won't deploy. Good engineering = involves tradeoffs, cost/benefit analysis, deployability analysis, extensib= ility design, etc.

I agree they are perhaps opposed, you could say that good enough is the ene= my of best however, since once you have something that is good enough, your= incentive to do any better is greatly diminished.

However, we are up against several obstacles when it comes to adoption of J= MAP.

1. Server authors won't want to add support unless there are clients 2. Client authors won't want to add support unless there are servers 3. Client or server authors won't want to add support unless they can m= ake things significantly better for mail users.

 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 unneces= sarily hostile to server developers (like myself) and server operators. But= I agree we also want JMAP to provide significant benefits to client author= s and their users. There are many design choices JMAP can make that meet al= l of these goals.

4. We are losing customers to alternate messaging systems.

If our target is just going to end up providing no benefits to users over w= hat we already have with IMAP+SMTP, then nobody will bother.

Where it gets interesting for me personally at least is if we can push the = boundary of mail experience.=C2=A0 In many cases this can be done in the MU= A but in some cases it requires support from the protocols.

I hear the arguments that the more complex we make the spec, the less likel= y it will be implemented, at least correctly. I'm not a fan of complexi= ty either, and neither of my suggestions do I consider to be particularly c= omplex.

My argument is that if the design doesn't hold out a carrot for better = mail experience for users, then nobody will bother, and we're wasting o= ur time here, which would be a shame because we have the potential to achie= ve a lot here.

At the moment, there is a benefit on the table, mostly being the ability to= only require configuration of access to 1 service (that's if JMAP does= submission).

I believe we should be looking for opportunities to make mail the best expe= rience possible, come up with ideas, and we may decided to defer some or no= t implement others, but we should keep them in mind so that perhaps we don&= #39;t close off the path to some of them.=C2=A0 We don't need another p= rotocol that is hamstrung by lack of foresight.

there are plenty of ideas around, look at the competition.

 Email is the most widely deployed multi-vendor messaging system on the Inte= rnet. The major value of doing JMAP as a standard is to get multi-vendor de= ployment. A walled garden will always have features that an open multi-vend= or system can't achieve (simply for privacy reasons). Yes, we should lo= ok at the features that are popular in walled garden messaging systems and = do a cost/benefit analysis. If the cost is low and benefit is high, let'= ;s consider it. But if the cost is high or the feature will involve a lot o= f careful design work and is outside the charter scope, then you'll get= opposition to adding that feature to the JMAP base spec.

A multi-vendor standard needs to support both small and large deployments a= nd support both cloud and on-premises deployments. There are hundreds of de= ployed IMAP and Submission server implementations on the Internet and JMAP = will deploy a lot faster if it "plays well" with those implementa= tions. And by "play well", I mean it can be added to an existing = deployment without major infrastructure changes.

For example, if I'm operating a million-user deployment, it's criti= cal to monitor the mail queues for problems. The proposed JMAP "outbox= " model means I'm adding one million new mail queues to the monito= ring system. That's a major deployment change; and thus a significant b= arrier to JMAP deployability.

Suppose we remove the "outbox" model from JMAP and replace it wit= h a submission command with envelope extensions. Now suppose we want to req= uire JMAP servers to support BINARYMIME submission (and/or append) as a boo= n to JMAP submission client authors? Well that's no problem from an inf= rastructure viewpoint as long as the JMAP server is permitted to perform th= e base64-encoding on binary message parts at submission/append time in orde= r to remain compatible with IMAP mail stores (and non-BINARYMIME submission= servers). Want to have the JMAP submission command handle both the \Sent f= older copy and the Submission without duplicate data transmission? I think = we need to do that. Want to have the base JMAP submission or append command= include IMAP CATENATE functionality (assemble a message including server-s= tored attachments in order to "forward without download")? I have= no problem with that.

There's quite a bit of room to improve the JMAP client author's exp= erience without forcing major infrastructure changes. The WG exists to disc= uss the cost/benefit of various features and make an engineering judgment c= all. The proposals that are most likely to succeed are ones that can be imp= lemented in a JMAP proxy without significant changes to IMAP/Submission. An= d proposals that would require reasonably straightforward or well-understoo= d IMAP/Submission extensions are worth considering (e.g., if I need a per-u= ser unique/persistent message identifier for IMAP, I understand the implica= tions of that).

But, if all JMAP is is a proxy of = existing protocols, then it seems like an expensive undertaking for little = gain.

And does that mean any future extensions hav= e to be also implemented in IMAP?

Brandon=C2=A0
--94eb2c04f8e234bc4b054e19522a-- From nobody Wed Apr 26 15:38:25 2017 Return-Path: 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 DAD31128DE7 for ; Wed, 26 Apr 2017 15:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 TWUc2r1-hHBD for ; Wed, 26 Apr 2017 15:38:22 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1A16128B8F for ; Wed, 26 Apr 2017 15:38:21 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id y11so18473142oie.0 for ; Wed, 26 Apr 2017 15:38:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/DFsrzLC2HOYIrWaInMZG0/sMJcgfv+h156MHAbfdBQ=; b=Nzfe/FZWkCKox9lfe2W3xVHVNlkBXb2t3KvpK/0RDCgxd0Nlq22fwJmnQePb+LerQp PaRSgP3OPKkfYRkqt33rIek59Jg8Jooea+bUk87KV6VDGJhSdi/pBnw7nnOKC+c75j1A RXKlkqyQNhS/CTvVhjgYKlVVMAO2jD8OIc48Ul5NcbeLW9P8aksrn/qUKLz0D1wiRpvK 5r58vjZOA4m+OZGYj5opQwc1znLQl/iylf2jOEKMfPFthS757oTfDmYdyDaJrvC6h1ww xExfMrgJlq0l0yvfTU/ZkRg8VNm5qHV1TBApofSAyuNYbjlOR1DGZoBBFMzerT9VlB+p x6wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/DFsrzLC2HOYIrWaInMZG0/sMJcgfv+h156MHAbfdBQ=; b=hZy0FkORvR4w0BbryBDUGiRjQgqd71wdYcNpEkFIbsYjTKssNrM8Ro8yfWc64UsW7M sTvo9h5lPIi6axwEVB5KdE/bzAJxHpO0LGJRtJpxMGUsHCvnC9Mdewy/1e/NWR7fs6bp hx8jZ3xoNUdSvgq8zApPOT8Lpa+hXdeiCd9Ak4JX8I2Frge4uNhkiGghWiCWn6tfs8tS 0qbVHvIdRuGBS/PMQSymvQlxaNZMPlnYL2urg1cikChQOWq4+gZiJoB+NC9Ty25G1GtV JN+1tR59ANYCgEPaSrWa0dkuLm2Sel8Mwm4O9skm6MjG+kRKjZmuMB3DhsjvaKG1Ojw6 fXcw== X-Gm-Message-State: AN3rC/7IQHlBnEge79js6Ot23NCKxbKe1oHrInUjxXSPr1fvaupX3hWj G/2Hyj5WXCKgj8+rkiZhRhDr4yr4a1iL X-Received: by 10.157.63.143 with SMTP id r15mr1132642otc.89.1493246300877; Wed, 26 Apr 2017 15:38:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.8.101 with HTTP; Wed, 26 Apr 2017 15:38:20 -0700 (PDT) In-Reply-To: <1493175371.126749.956396640.2F6911DF@webmail.messagingengine.com> References: <1492998899.3316920.953769616.254C9CBD@webmail.messagingengine.com> <1493084134.2830550.955039432.5403CAFB@webmail.messagingengine.com> <1493087082.2882732.955078288.61343C16@webmail.messagingengine.com> <63973317-543D-4E5C-80D3-16F5979D747D@fugue.com> <1493175371.126749.956396640.2F6911DF@webmail.messagingengine.com> From: Brandon Long Date: Wed, 26 Apr 2017 15:38:20 -0700 Message-ID: To: Neil Jenkins Cc: Ted Lemon , jmap@ietf.org Content-Type: multipart/alternative; boundary=001a11c0ab9053ca29054e197f46 Archived-At: Subject: Re: [Jmap] Draft messages - mutability X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 22:38:24 -0000 --001a11c0ab9053ca29054e197f46 Content-Type: text/plain; charset=UTF-8 In terms of message mutability, we've had another case for plain messages that we find complicated, which is if the server chooses to modify the message. As an example case, suppose the server has decided that a message a client has already synced is now a phishing message, and as such, wants to rewrite all of the links in the message or make them not-linkable. The only way to do this with immutable messages is to remove the old message and create a new one.[1] If the client has already synced the message and read it, then on the next sync, it will fail to apply the read action since the message no longer exists, and the user will be presented with the message again as new, which for a phishing message seems like a bad idea. Perhaps we don't need to make them mutable, but a replace semantic which was available in both directions would allow the client to sync state to the new copy of the message. [1] Of course, if you own the MUA and server, you can just say the message is $Phishing and the MUA can modify how it displays the message, but enterprise customers like to use their favorite clients and their security ops folks like to protect them On Tue, Apr 25, 2017 at 7:56 PM, Neil Jenkins wrote: > On Wed, 26 Apr 2017, at 12:40 PM, Ted Lemon wrote: > > I suppose that if the old draft were present in a viewer, > > > Yes, this is the case I was referring to: where the draft is currently > open for editing. > > Neil. > > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap > > --001a11c0ab9053ca29054e197f46 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In terms of message mutability, we've had another case= for plain messages that we find complicated, which is if the server choose= s to modify the message.

As an example case, suppose the= server has decided that a message a client has already synced is now a phi= shing message, and as such, wants to rewrite all of the links in the messag= e or make them not-linkable.=C2=A0 The only way to do this with immutable m= essages is to remove the old message and create a new one.[1]
If the client has already synced the message and read it, then = on the next sync, it will fail to apply the read action since the message n= o longer exists, and the user will be presented with the message again as n= ew, which for a phishing message seems like a bad idea.

Perhaps we don't need to make them mutable, but a replace semanti= c which was available in both directions would allow the client to sync sta= te to the new copy of the message.

[1] Of course, = if you own the MUA and server, you can just say the message is $Phishing an= d the MUA can modify how it displays the message, but enterprise customers = like to use their favorite clients and their security ops folks like to pro= tect them

On T= ue, Apr 25, 2017 at 7:56 PM, Neil Jenkins <neilj@fastmail.com> wrote:
On Wed, 26 Apr 2017, at 12:40 PM, Ted Lemon wrot= e:
I suppose that if the old draft were present= in a viewer,

Yes, this is the case I was referring to: where the draft is cu= rrently open for editing.

Neil.

_______________________________________________
Jmap mailing list
Jmap@ietf.org
https://www.ietf.org/mailman/listinfo/jmap


--001a11c0ab9053ca29054e197f46-- From nobody Wed Apr 26 15:45:49 2017 Return-Path: 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 64B2A128616 for ; Wed, 26 Apr 2017 15:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 1unVcYOG2eh3 for ; Wed, 26 Apr 2017 15:45:45 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51CCB127B31 for ; Wed, 26 Apr 2017 15:45:45 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id j201so18551028oih.2 for ; Wed, 26 Apr 2017 15:45:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eCy56Uu0rrDmhYP+in5ov8pMV3WQgS/CjZvdpVZyhJU=; b=HwsoQghRfoow1PWc9ANxFuqh0ou3wnARwdKJ+DDsLB+4n0+tTK/cePOPXwBUlelOSs OESE0JfkchCnq4hgPKudrpoOwCZt4VPiYrWz9XSBMbdHQ/uqEgURzKOrpfJuvQENRduq JWGB0H/XAwgbTnnn+4m3ek9l+sgmgcfKdK01xB7++gGHjVh3tkXCVGfhSKdNGE4KeXqf i3bbX5R14XL/JWVfAbIFXbH6C2zNzbuVK4XcaAykkKu8n/iq2M3gw2ki4U6q2YG5+e5/ ZUqnE1MQ5bVJrRljm74lSApjZqAszXU35R5aK0RSTGzyqmYUuGAulfjEcJDDZDQtG81d C7lA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eCy56Uu0rrDmhYP+in5ov8pMV3WQgS/CjZvdpVZyhJU=; b=SLPXmuQdFps2V9Ab74kkCwVtQ2MAixOemnCC3+pRbUpeBDLqR98tCDKfR9NpgaBmpb RJwxubSj6SXje+ffzD83ze9rvSRRgnrpysdTi2glHt7LWj7mVtChwpQ1WY1vPWe6888K bbwfZwnlkg8wy7Zldwqwzv6O8Sayiv3x/mMWqZVvZaN0Lhmx4vUoSxA46NUDWx4Jn8TZ qmwBb6nDJELOleEixQS7e8OGxAdguM+a9RnhVI57b/4w0nzMtmdWtwgm36SBC+DsJbwA M6jHR6z8LHil7GqLJaMoiSkUFEbNGxbhRfIp00q0A8Yw7EW5TcQY0o+TuMgzINasOziV HVIA== X-Gm-Message-State: AN3rC/7P/cAt6QQCCR1NCcwyBpLthhoBDNGfEwugvEN+jpHcos43Z+vZ crbFjVLtilPw66S/NVShP3uRPlO1xbCr X-Received: by 10.202.212.131 with SMTP id l125mr1133399oig.194.1493246744191; Wed, 26 Apr 2017 15:45:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.8.101 with HTTP; Wed, 26 Apr 2017 15:45:43 -0700 (PDT) In-Reply-To: References: <1492997737.3312553.953738776.7D27901C@webmail.messagingengine.com> <43747FEE-5EBE-4F89-BE13-94701F88A5BA@fugue.com> <4A4B1A7AC839999470A6D83C@caldav.corp.apple.com> From: Brandon Long Date: Wed, 26 Apr 2017 15:45:43 -0700 Message-ID: To: Gren Elliot Cc: Ted Lemon , Cyrus Daboo , jmap@ietf.org, Adrien de Croy , Bron Gondwana Content-Type: multipart/alternative; boundary=001a113acec8c076cd054e199940 Archived-At: Subject: Re: [Jmap] Submission: options for github issue X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 22:45:47 -0000 --001a113acec8c076cd054e199940 Content-Type: text/plain; charset=UTF-8 Gmail does bcc splitting, has for several years now. About once a year we get someone complaining that it exposes private data (I didn't want people to know they were on the losers@ mailing list) or confused that they think this means everyone got the bcc header. Apparently it's subtle. Brandon On Mon, Apr 24, 2017 at 7:43 AM, Gren Elliot wrote: > I have worked on a server that did BCC splitting - i.e. A separate message > was sent to each BCC user including their address in the BCC header and a > message sent to all the rest excluding the BCC header. > > Regards, > Gren Elliot > > From: Cyrus Daboo > Reply: Cyrus Daboo > Date: 24 April 2017 at 15:26:35 > To: Ted Lemon > Cc: Adrien de Croy , jmap@ietf.org > , Bron Gondwana > > Subject: Re: [Jmap] Submission: options for github issue > > Hi Ted, > > --On April 24, 2017 at 10:12:56 AM -0400 Ted Lemon > wrote: > > >> we may need to special Bcc headers even if the envelope is preserved - > >> but then it because a little awkward because of the duplication of > >> information in two places. > > > > Except that the bcc header shouldn't be in the message in the first > > place, for privacy reasons. So either the message in the JMAP store is > > different than what was actually sent, or the Bcc info should _only_ be > > on the envelope. > > > > Of course, this requires the MUA to do some creative gymnastics to make > > it all look good, but such is life. > > > > Most MUAs today store Bcc information in the sent-mail copy of a message - > of course they never include the Bcc header in the message that was > actually sent > > However it is worth noting that RFC 5322 > () does define 3 > different ways that the Bcc header can be used and in two of those the Bcc > header is included in some fashion in a message being sent. I don't think > those two modes are common enough to warrant support in JMAP, but I could > be wrong. > > -- > Cyrus Daboo > > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap > > > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap > > --001a113acec8c076cd054e199940 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Gmail does bcc splitting, has for several years now.=C2=A0= About once a year we get someone complaining that it exposes private data = (I didn't want people to know they were on the losers@ mailing list) or= confused that they think this means everyone got the bcc header.

<= /div>
Apparently it's subtle.

Brandon
<= /div>

On Mon= , Apr 24, 2017 at 7:43 AM, Gren Elliot <fatkudu@gmail.com> w= rote:
I have worked on a server that did BCC splitting - i.e. A separate mess= age was sent to each BCC user including their address in the BCC header and= a message sent to all the rest excluding the BCC header.

Regards,
Gren Elliot

From:=C2=A0C= yrus Daboo <= ;cyrus@daboo.name>
Reply:=C2=A0Cyrus = Daboo <cyru= s@daboo.name>
Date:=C2=A024 April 201= 7 at 15:26:35
To:=C2=A0Ted Lemon <mellon@fugue.c= om>
Cc:=C2=A0Adrien de Croy <adrien@qbik.com><= /a>, jmap@ietf.org <jmap@ietf.org>, Bron Gon= dwana <bro= ng@fastmail.fm>
Subject:=C2=A0 Re: [J= map] Submission: options for github issue

Hi Ted,

--On April 24, 2017 at 10:12:56 AM -0400 Ted Lemon <mellon@fugue.com> wrote:

>> we may need to special Bcc headers even if the envelope is pre= served -
>> but then it because a little awkward because of the duplicatio= n of
>> information in two places.
>
> Except that the bcc header shouldn't be in the message in the = first
> place, for privacy reasons. So either the message in the JMAP st= ore is
> different than what was actually sent, or the Bcc info should _onl= y_ be
> on the envelope.
>
> Of course, this requires the MUA to do some creative gymnastics to= make
> it all look good, but such is life.
>

Most MUAs today store Bcc information in the sent-mail copy of a messag= e - =20
of course they never include the Bcc header in the message that was =20
actually sent

However it is worth noting that RFC 5322 =20
(<https://tools.ietf.org/html/rfc5322#section-3.6.3>= ;) does define 3 =20
different ways that the Bcc header can be used and in two of those the = Bcc =20
header is included in some fashion in a message being sent. I don't= think =20
those two modes are common enough to warrant support in JMAP, but I cou= ld =20
be wrong.

-- =20
Cyrus Daboo

_______________________________________________
Jmap mailing list
Jmap@ietf.org
https://www.ietf.org/mailman/listinfo/jmap

_______________________________________________
Jmap mailing list
Jmap@ietf.org
https://www.ietf.org/mailman/listinfo/jmap


--001a113acec8c076cd054e199940-- From nobody Wed Apr 26 16:04:48 2017 Return-Path: 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 16E5E1294D8 for ; Wed, 26 Apr 2017 16:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=C/UpGWpy; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Hq5tvoMa 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 av6bzbmyLvIW for ; Wed, 26 Apr 2017 16:04:45 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DD2E1294C5 for ; Wed, 26 Apr 2017 16:04:44 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id A59EB21E69 for ; Wed, 26 Apr 2017 19:04:43 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Wed, 26 Apr 2017 19:04:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=YcsmvbvQnxioZ4/m48BRiZAKcta+k OHHtBeaPtjdDzo=; b=C/UpGWpyH80SC1mzpOwODSdRLCiD3+vJV5DZB8z2VdC/J HzJ3sI1oFxVog3P5gDDHwf9vxd1M233eGMRpBg2LMIa4awUloyMrWeDlidOY0QGN RyXRsK7iyaz+GNCYX+nvsj1GnD8NXibkYLRsJPJCVIZT82/RgPqOUcimnyZMC+Xb EFHYjjhWputlbaHQPmdcKgaGhL56TiGxwfPqCC0z8cKMweGtgF4iG9Vef/zfU0go 2YVQ+HINwK3LNj5fuc3zzEJeHpf9LWEmmK/InI6V54yryx00fLkH92M3cTB+UDOw sN2dbIgwV5h3ViEEcyBMJBA73Dut3EoheBPVrW8aw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=Ycsmvb vQnxioZ4/m48BRiZAKcta+kOHHtBeaPtjdDzo=; b=Hq5tvoMa/y1JAU88SYFWe5 J9/o8RqbljWKh1xL8g+bz7NUygNv3Yfp50ZsUJr5GsTvn1We8pmsUoa96pOmzBWa xi1Yk8gAmsgSPqklh6/CYOF7ekygiTrvDecQuZ5qWlz4FfKG1TRj+bVN4U4943FR ib9o0zs9oWTQob/3XKcEYDNVuRfCdBo/yzskKFoZtTiUHoOx3Ca7voJBuiUAsgEZ /AuA2xpItgzdBBDu05tcC+tdpdsEQkl37U53QanQ4YAXrWAELuqYOPWQAzssgSr3 tDAZOhbgCihM/KDkBMfH3e00LGMEsx69CTxvu7wkMKYlxX/Fa/1hr8aLiinKOP3g == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 67A88E27D8; Wed, 26 Apr 2017 19:04:43 -0400 (EDT) Message-Id: <1493247883.1296252.957528008.3E96BD8F@webmail.messagingengine.com> From: Neil Jenkins To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_149324788312962521" X-Mailer: MessagingEngine.com Webmail Interface - ajax-843b6574 In-Reply-To: References: <46F700A6-C2B1-488B-A8B4-6ACD45B03C31@oracle.com> Date: Wed, 26 Apr 2017 23:04:43 +0000 Archived-At: Subject: Re: [Jmap] Best vs Good enough - adoption of JMAP X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 23:04:47 -0000 This is a multi-part message in MIME format. --_----------=_149324788312962521 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Wed, 26 Apr 2017, at 10:25 PM, Brandon Long wrote: > But, if all JMAP is is a proxy of existing protocols, then it seems > like an expensive undertaking for little gain. Agreed. JMAP is not just a proxy. We have implemented a proxy[1] to test with, but it's not stateless (in fact quite heavyweight), as it needs to build indexes to provide features that are not available in the protocols it's proxying through to. The goal with designing JMAP has been to make it possible to implement JMAP and IMAP interfaces to the same backend mail store (so someone could happily use both an IMAP client and a JMAP client concurrently and see a consistent view of their data). We know the current draft achieves this, because there's a pretty complete implementation of the current draft in Cyrus[2]. This is a necessary property for having a migration path, however it still gives flexibility to fix the many deficiencies of the current standards. Neil. Links: 1. https://proxy.jmap.io/ 2. http://cyrusimap.org/imap/download/installation/http/jmap.html --_----------=_149324788312962521 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Wed, 26 Apr 2017, at 10:25 PM, Brandon Long wrote:
But, if all JMAP is is a proxy of existing protocols, then it seems like an expensive undertaking for little gain.

Agreed. JMAP is not just a proxy. We have implemented a proxy to test with, but it's not stateless (in fact quite heavyweight), as it needs to build indexes to provide features that are not available in the protocols it's proxying through to.

The goal with designing JMAP has been to make it possible to implement JMAP and IMAP interfaces to the same backend mail store (so someone could happily use both an IMAP client and a JMAP client concurrently and see a consistent view of their data). We know the current draft achieves this, because there's a pretty complete implementation of the current draft in Cyrus. This is a necessary property for having a migration path, however it still gives flexibility to fix the many deficiencies of the current standards.

Neil.
--_----------=_149324788312962521-- From nobody Wed Apr 26 16:12:17 2017 Return-Path: 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 6EF061294BF for ; Wed, 26 Apr 2017 16:12:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=utZCWXkh; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Fl4+WXOr 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 oi7t3J3bd_MH for ; Wed, 26 Apr 2017 16:12:14 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5E13120727 for ; Wed, 26 Apr 2017 16:12:13 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id 4907020D52 for ; Wed, 26 Apr 2017 19:12:13 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Wed, 26 Apr 2017 19:12:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=RtQxZIa11usqSAa+5ZtW88g2Le+AS KZRZBcuRxNuK9c=; b=utZCWXkh7UGodMvzCktpD4xx89RWaBJO0ZE++UQ1S8RiA gQJ1uZbhLP8nG4NrDMF6YvvZD5w6p4AUMU3yRaqP3IjXLSdr3nBHH2ZdE+N0ax2R CUrzF48ouDQgug/HdiwhKY6j8U+K/DmVsQXl+9XQauoJyLq/xGUKYi/M8vSsWPMl OsDDtF3StXtbWknuzTD/sG01JzVCb/HsWoyLq0U+usGPzx+oJ5K4WtzJR/wfj4zJ +IjWSEeDQcpdFXTARnjYz5g0f3yYLE4SHEUONCYIhZeWABFnTtdqfDARRF95lNa0 NRqTMoCbYzxDVbpDPX+VStG0NBhHa4wk9EaFoO4kg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=RtQxZI a11usqSAa+5ZtW88g2Le+ASKZRZBcuRxNuK9c=; b=Fl4+WXOrbuUmMaamiDlAw6 WRS1XgcOyxGeKJhaYZhcNKYIDRmXlyiyx/y6jYyyrQQU6tM79XzjmasKBo+iaNoq kklJYwh34hqTRVj85mlpAJpf/dBFAckwWYuABeHgeMrAQu9eGwAtGm76wGpI+ZN0 mAECmF2owLbJWVVB02IcACyXjtzrG/e3RwGzEIE7z8h351LpSiYordPfnZe5HxDQ f0DvDC/mI6DpoMml1SCLwLR0ZrLjL70EcJfY0TR9cGgaY06qr3xdg5RB7ZtWNwk+ oHMXyLXFKO25ruuZLu0hGaV34QVQZWBX/CEmFBET750douHFcRlwXgBFjw6kAzcg == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 0B855E27D8; Wed, 26 Apr 2017 19:12:13 -0400 (EDT) Message-Id: <1493248332.1295949.957537688.05443911@webmail.messagingengine.com> From: Neil Jenkins To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_149324833212959495" X-Mailer: MessagingEngine.com Webmail Interface - ajax-843b6574 In-Reply-To: Date: Wed, 26 Apr 2017 23:12:12 +0000 References: <46F700A6-C2B1-488B-A8B4-6ACD45B03C31@oracle.com> <1493099769.3023399.955193288.6D0312CC@webmail.messagingengine.com> <33553450-82F4-4CB4-8679-C9F52D8A8839@oracle.com> <1493163974.4122214.956244160.6735E49C@webmail.messagingengine.com> <1493185260.709114.956477904.75CB343B@webmail.messagingengine.com> Archived-At: Subject: Re: [Jmap] simpler future release & unsend without outbox (was Re: Best vs Good enough - adoption of JMAP) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 23:12:15 -0000 This is a multi-part message in MIME format. --_----------=_149324833212959495 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Wed, 26 Apr 2017, at 05:54 PM, Chris Newman wrote: > I'll describe a model that achieves my goal [=E2=80=A6] > 1. Get rid of the server-side outbox. We only have a drafts folder > and a> sent folder. >=20 > 2. Add a submission command with envelope (same structure as SMTP > envelope but JSON syntax and quoting). We pass this command a > reference> to a draft message in the drafts folder, and if the submission > succeeds,> the message is moved to the sent folder with the envelope as an > annotation. The envelope can include the already-standard > future release> extension. >=20 > 3. Add an unsend command which takes a reference to a message in the > sent folder. If the unsend succeeds, the message can be moved back to> th= e drafts folder as part of this action. How the server correlates a> messag= e in the sent folder with a message in the mail queue is an > implementation detail; the spec need not specify that detail in > order to> provide the functionality with this model. >=20 > 4. Add a way to search/select messages in the Sent folder that may be> po= ssible to unsend. >From a protocol perspective, this model is basically identical to the outbox model proposed. The only difference is that rather than put the messages that can still be recalled in a separate "outbox" mailbox, you put them in the sent mailbox and require some kind of search. The only extra component your server will need is something that moves the message from outbox to sent when it can no longer be recalled; I seriously don't think this is a huge implementation burden. As Brandon has pointed out, modern mailstores need this kind of "scheduled events" plumbing for a number of user-facing features, and it has already been implemented at scale in a number of systems. >From a user interface perspective, I maintain it is clearer for the user for these to be two separate mailboxes, and it also has the advantage that mailboxes have a message count so MUAs can more easily see if there are any messages waiting to be sent still. (I would expect most MUAs to hide the outbox when empty.) Neil. --_----------=_149324833212959495 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
On Wed, 26 Apr 2017, at 05:54 PM, Chris Newman wrote:
I'll describe a model that achieves my goal = [=E2=80=A6]
1. Get rid of the server-side outbox. We only have a drafts folder and= a
sent folder.

2. Add a submission command with envelope (same structure as SMTP
<= /div>
envelope but JSON syntax and quoting). We pass this command a referenc= e
to a draft message in the drafts folder, and if the submission succeed= s,
the message is moved to the sent folder with the envelope as an
annotation. The envelope can include the already-standard future relea= se
extension.

3. Add an unsend command which takes a reference to a message in the
sent folder. If the unsend succeeds, the message can be moved back to<= br>
the drafts folder as part of this action. How the server correlates a<= br>
message in the sent folder with a message in the mail queue is an
<= /div>
implementation detail; the spec need not specify that detail in order = to
provide the functionality with this model.

4. Add a way to search/select messages in the Sent folder that may be<= br>
possible to unsend.

From a protocol perspective, this model is basically identical to the = outbox model proposed. The only difference is that rather than put the mess= ages that can still be recalled in a separate "outbox" mailbox, you put the= m in the sent mailbox and require some kind of search. The only extra = component your server will need is something that moves the message from ou= tbox to sent when it can no longer be recalled; I seriously don't think thi= s is a huge implementation burden. As Brandon has pointed out, modern mails= tores need this kind of "scheduled events" plumbing for a number of user-fa= cing features, and it has already been implemented at scale in a number of = systems.

From a user interface perspective, I maintain it is clearer for the us= er for these to be two separate mailboxes, and it also has the advantage th= at mailboxes have a message count so MUAs can more easily see if there are = any messages waiting to be sent still. (I would expect most MUAs to hide th= e outbox when empty.)

Neil.
--_----------=_149324833212959495-- From nobody Wed Apr 26 16:27:58 2017 Return-Path: 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 75CD11294E4 for ; Wed, 26 Apr 2017 16:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=lSnu+FtA; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=R8O/rTgh 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 p74E6koSQqa0 for ; Wed, 26 Apr 2017 16:27:56 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FE821294D8 for ; Wed, 26 Apr 2017 16:27:56 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id 65A5E20869 for ; Wed, 26 Apr 2017 19:27:55 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Wed, 26 Apr 2017 19:27:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=J6728oGmzhzLljl6ewJKWPpkiUI7Z 4MepPBORkgvjRs=; b=lSnu+FtATMnMrI8Pjtc9Huqt42EgamuKHbPZ6wjMc/2mC mBNScwn/aZ+ewp6ktkWtQvmBJDNReeKBroqJv6aUFvC3S6OGFD0HnVLqPVZGlkkG jU+OklPkorVFEmdawEKRjQcLOS7+Paeb+rC7QwJ5MFdJ9S0IbepzbPZ6HAhgG1dQ kBRLDxBiZGZXOYGO+mBxzJyvAH4L64Dxr5Z/XVi4DVJiI+WWquuEvtYRnPb+xODF 10KsjZl3MGldPTkWgUQ7nVx6ZauY+CHuM7iFE8QOr0N3f31LVGo1z9rx+YteZXMB rwiqfshFuEvyGz91rpowzdGuCan1rQVrl0a/++jtw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=J6728o GmzhzLljl6ewJKWPpkiUI7Z4MepPBORkgvjRs=; b=R8O/rTghCd/lUH12FE/Zgi fZ/LYfu2khHkMKsODqYaqvFHzGjsENijMJuIAkAewlmwf45Naq4619kbQjSDt2XN WUvA8A1tIqGKfkyNwOSOHfpdpoeJSKFIWHW005L1J3m/mkQlrVZkK07EkuJwMUA0 Pl7RIsiERzdCmGhTWshtcHRS+2wFQ7GinTULgGuwwAXvIKoJe7nwCc2dor6tm31B j9yGWdPVy20fyA9rfGw2wox/s6Cfwu+QkuM2Y4EBstRvFhaNmkDsPXtRCK/bAiDc wNq+5pIBovYgRUaBrkq5pDovlZ7qxF8QEHcsMOz5RqUHK5j3LUW3+evHDW+ZWtAQ == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 26153E27D8; Wed, 26 Apr 2017 19:27:55 -0400 (EDT) Message-Id: <1493249275.1321598.957543872.3BF1C665@webmail.messagingengine.com> From: Neil Jenkins To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_149324927513215982" X-Mailer: MessagingEngine.com Webmail Interface - ajax-843b6574 References: <46F700A6-C2B1-488B-A8B4-6ACD45B03C31@oracle.com> <1493099769.3023399.955193288.6D0312CC@webmail.messagingengine.com> <33553450-82F4-4CB4-8679-C9F52D8A8839@oracle.com> <1493163974.4122214.956244160.6735E49C@webmail.messagingengine.com> <1493185260.709114.956477904.75CB343B@webmail.messagingengine.com> <1493248332.1295949.957537688.05443911@webmail.messagingengine.com> Date: Wed, 26 Apr 2017 23:27:55 +0000 In-Reply-To: <1493248332.1295949.957537688.05443911@webmail.messagingengine.com> Archived-At: Subject: Re: [Jmap] simpler future release & unsend without outbox (was Re: Best vs Good enough - adoption of JMAP) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 23:27:57 -0000 This is a multi-part message in MIME format. --_----------=_149324927513215982 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" And just to reinforce: users consider "sent" to be different to "scheduled to be sent". The concept of an outbox is the common approach that MUAs take to distinguishing this. For example: Outlook[1]: *You can delay the delivery of an individual email message or you can use rules to delay the delivery of all messages by having them held in the Outbox for a specified time after you click Send.* Boomerang for Gmail[2]: *To view all messages scheduled to be sent out, simply go to the Boomerang-Outbox folder in your Google account.* Mixmax for Gmail[3]: *You'll see a list of your scheduled emails in your Outbox. You can click to Reschedule or Stop your email which moves it to your drafts.* MailButler for Apple Mail[4]:* Your scheduled emails will be saved in the Outbox folder until the delivery time. [=E2=80=A6] When your email is s= ent automatically, it is placed in your Sent folder, as with any other sent email.* I have yet to find one that puts the messages straight in your sent folder. Neil. Links: 1. https://support.office.com/en-us/article/Delay-or-schedule-sending-ema= il-messages-026af69f-c287-490a-a72f-6c65793744ba?ui=3Den-US&rs=3Den-US&ad= =3DUS 2. http://www.boomeranggmail.com/faq.html 3. http://success.mixmax.com/article/35-send-later 4. https://support.mailbutler.io/en/support/solutions/articles/6000115079= -how-to-schedule-emails- --_----------=_149324927513215982 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
And just to reinforce: users consider "sent" to be different to = "scheduled to be sent". The concept of an outbox is the common approach tha= t MUAs take to distinguishing this. For example:

Outlook: You can delay the delivery of = an individual email message or you can use rules to delay the delivery of a= ll messages by having them held in the Outbox for a specified time after yo= u click Send.

Boomerang for Gmail= : To view all messages scheduled to be sent out, simply go to t= he Boomerang-Outbox folder in your Google account.

Mixmax&nbs= p;for Gmail: You'll see a list of your scheduled emails in your= Outbox. You can click to Reschedule or Stop your email which moves it to y= our drafts.

MailButler for Apple Mail: = ;Your scheduled emails will be saved in the Outbox folder until the deliver= y time. [=E2=80=A6] When your email is sent automatically, it is placed in = your Sent folder, as with any other sent email.

I have yet to find one that puts the messages straight in your sent fo= lder.

Neil.
--_----------=_149324927513215982-- From nobody Wed Apr 26 16:40:49 2017 Return-Path: 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 7F32A12951F for ; Wed, 26 Apr 2017 16:40:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 gI5aATq3q7GQ for ; Wed, 26 Apr 2017 16:40:45 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [122.56.26.1]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C606F1294E4 for ; Wed, 26 Apr 2017 16:40:44 -0700 (PDT) Received: From [192.168.1.146] (unverified [192.168.1.146]) by SMTP Server [192.168.1.3] (WinGate SMTP Receiver v9.0.5 (Build 5926)) with SMTP id <0001031396@smtp.qbik.com>; Thu, 27 Apr 2017 11:40:41 +1200 From: "Adrien de Croy" To: "Neil Jenkins" , "jmap@ietf.org" Date: Wed, 26 Apr 2017 23:40:41 +0000 Message-Id: In-Reply-To: <1493248332.1295949.957537688.05443911@webmail.messagingengine.com> References: <46F700A6-C2B1-488B-A8B4-6ACD45B03C31@oracle.com> <1493099769.3023399.955193288.6D0312CC@webmail.messagingengine.com> <33553450-82F4-4CB4-8679-C9F52D8A8839@oracle.com> <1493163974.4122214.956244160.6735E49C@webmail.messagingengine.com> <1493185260.709114.956477904.75CB343B@webmail.messagingengine.com> <1493248332.1295949.957537688.05443911@webmail.messagingengine.com> Reply-To: "Adrien de Croy" User-Agent: eM_Client/7.0.27943.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MB4690195A-3184-4EC1-ABBD-1E6DE7931F86" Archived-At: Subject: Re: [Jmap] simpler future release & unsend without outbox (was Re: Best vs Good enough - adoption of JMAP) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 23:40:47 -0000 --------=_MB4690195A-3184-4EC1-ABBD-1E6DE7931F86 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable my personal experience with the outbox folder is that it's a pain in the= =20 neck.. it means if I need to find a message I submitted, there are now 2 places= =20 to look for it instead of one, depending on its state. This doesn't seem like a bonus to me, rather the opposite. Adrien ------ Original Message ------ From: "Neil Jenkins" To: "jmap@ietf.org" Sent: 27/04/2017 11:12:12 AM Subject: Re: [Jmap] simpler future release & unsend without outbox (was=20 Re: Best vs Good enough - adoption of JMAP) >On Wed, 26 Apr 2017, at 05:54 PM, Chris Newman wrote: >>I'll describe a model that achieves my goal [=E2=80=A6] >>1. Get rid of the server-side outbox. We only have a drafts folder and= =20 >>a >>sent folder. >> >>2. Add a submission command with envelope (same structure as SMTP >>envelope but JSON syntax and quoting). We pass this command a=20 >>reference >>to a draft message in the drafts folder, and if the submission=20 >>succeeds, >>the message is moved to the sent folder with the envelope as an >>annotation. The envelope can include the already-standard future=20 >>release >>extension. >> >>3. Add an unsend command which takes a reference to a message in the >>sent folder. If the unsend succeeds, the message can be moved back to >>the drafts folder as part of this action. How the server correlates a >>message in the sent folder with a message in the mail queue is an >>implementation detail; the spec need not specify that detail in order=20 >>to >>provide the functionality with this model. >> >>4. Add a way to search/select messages in the Sent folder that may be >>possible to unsend. > >From a protocol perspective, this model is basically identical to the=20 >outbox model proposed. The only difference is that rather than put the=20 >messages that can still be recalled in a separate "outbox" mailbox, you= =20 >put them in the sent mailbox and require some kind of search. The only=20 >extra component your server will need is something that moves the=20 >message from outbox to sent when it can no longer be recalled; I=20 >seriously don't think this is a huge implementation burden. As Brandon=20 >has pointed out, modern mailstores need this kind of "scheduled events"= =20 >plumbing for a number of user-facing features, and it has already been=20 >implemented at scale in a number of systems. > >From a user interface perspective, I maintain it is clearer for the=20 >user for these to be two separate mailboxes, and it also has the=20 >advantage that mailboxes have a message count so MUAs can more easily=20 >see if there are any messages waiting to be sent still. (I would expect= =20 >most MUAs to hide the outbox when empty.) > >Neil. --------=_MB4690195A-3184-4EC1-ABBD-1E6DE7931F86 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

my personal experience with the outbox folder= is that it's a pain in the neck..

it means if= I need to find a message I submitted, there are now 2 places to look for= it instead of one, depending on its state.

This= doesn't seem like a bonus to me, rather the opposite.

Adri= en


------ Original Message ------
From: "Neil Jenkins" <neilj@f= astmail.com>
To: "jmap@ietf.org" <jmap@ietf.org= >
Sent: 27/04/2017 11:12:12 AM
Subject: Re: [Jmap] simpler future release & unsend without outbox= (was Re: Best vs Good enough - adoption of JMAP)

On Wed, 26 Apr 2017, at 05:54 PM, Chris Newman wrote:
I'll describe a model that= achieves my goal [=E2=80=A6]
1. Get rid of the server-side outbox. We only have a drafts folder = and a
sent folder.

2. Add a submission command with envelope (same structure as SMTP
envelope but JSON syntax and quoting). We pass this command a referenc= e
to a draft message in the drafts folder, and if the submission succeed= s,
the message is moved to the sent folder with the envelope as an
annotation. The envelope can include the already-standard future relea= se
extension.

3. Add an unsend command which takes a reference to a message in the
sent folder. If the unsend succeeds, the message can be moved back = to
the drafts folder as part of this action. How the server correlates= a
message in the sent folder with a message in the mail queue is an
implementation detail; the spec need not specify that detail in order= to
provide the functionality with this model.

4. Add a way to search/select messages in the Sent folder that may = be
possible to unsend.

From a protocol perspective, this model is basically identical to the= outbox model proposed. The only difference is that rather than put the = messages that can still be recalled in a separate "outbox" mailbox, you = put them in the sent mailbox and require some kind of search.=C2=A0The only= extra component your server will need is something that moves the message= from outbox to sent when it can no longer be recalled; I seriously don't= think this is a huge implementation burden. As Brandon has pointed out,= modern mailstores need this kind of "scheduled events" plumbing for a numb= er of user-facing features, and it has already been implemented at scale= in a number of systems.

From a user interface perspective, I maintain it is clearer for the= user for these to be two separate mailboxes, and it also has the advantage= that mailboxes have a message count so MUAs can more easily see if there= are any messages waiting to be sent still. (I would expect most MUAs to= hide the outbox when empty.)

Neil.
--------=_MB4690195A-3184-4EC1-ABBD-1E6DE7931F86-- From nobody Wed Apr 26 16:43:40 2017 Return-Path: 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 83EAD1294E4 for ; Wed, 26 Apr 2017 16:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 eIPj0AzG44ZJ for ; Wed, 26 Apr 2017 16:43:36 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAC4D1294D8 for ; Wed, 26 Apr 2017 16:43:36 -0700 (PDT) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v3QNhWp7024910 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 26 Apr 2017 23:43:32 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0021.oracle.com (8.13.8/8.14.4) with ESMTP id v3QNhWYi003934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 26 Apr 2017 23:43:32 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id v3QNhTYL022641; Wed, 26 Apr 2017 23:43:30 GMT Received: from [10.145.239.185] (/10.145.239.185) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 26 Apr 2017 16:43:29 -0700 From: "Chris Newman" To: "Brandon Long" Cc: "Adrien de Croy" , "jmap@ietf.org" Date: Wed, 26 Apr 2017 16:43:27 -0700 Message-ID: <733165A2-0BBD-4B3A-84E8-9D0D63B1C8FE@oracle.com> In-Reply-To: References: <46F700A6-C2B1-488B-A8B4-6ACD45B03C31@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Subject: Re: [Jmap] Best vs Good enough - adoption of JMAP X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 23:43:38 -0000 On 26 Apr 2017, at 15:25, Brandon Long wrote: > On Mon, Apr 24, 2017 at 5:39 PM, Chris Newman > > wrote: > >> On 24 Apr 2017, at 15:43, Adrien de Croy wrote: >> >>> On the topic of best vs good enough. >>> >> >> This is a misleading dichotomy for an engineering discussion. My >> immediate >> response when you say "best" is "best for whom?" If you design the >> best >> possible protocol for end-user experience, it will place unreasonable >> requirements on servers and won't deploy. Good engineering involves >> tradeoffs, cost/benefit analysis, deployability analysis, >> extensibility >> design, etc. >> >> I agree they are perhaps opposed, you could say that good enough is >> the >>> enemy of best however, since once you have something that is good >>> enough, >>> your incentive to do any better is greatly diminished. >>> >>> However, we are up against several obstacles when it comes to >>> adoption of >>> JMAP. >>> >>> 1. Server authors won't want to add support unless there are clients >>> 2. Client authors won't want to add support unless there are servers >>> 3. Client or server authors won't want to add support unless they >>> can >>> make things significantly better for mail users. >>> >> >> 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. >> >> 4. We are losing customers to alternate messaging systems. >>> >>> If our target is just going to end up providing no benefits to users >>> over >>> what we already have with IMAP+SMTP, then nobody will bother. >>> >>> Where it gets interesting for me personally at least is if we can >>> push >>> the boundary of mail experience. In many cases this can be done in >>> the MUA >>> but in some cases it requires support from the protocols. >>> >>> I hear the arguments that the more complex we make the spec, the >>> less >>> likely it will be implemented, at least correctly. I'm not a fan of >>> complexity either, and neither of my suggestions do I consider to be >>> particularly complex. >>> >>> My argument is that if the design doesn't hold out a carrot for >>> better >>> mail experience for users, then nobody will bother, and we're >>> wasting our >>> time here, which would be a shame because we have the potential to >>> achieve >>> a lot here. >>> >>> At the moment, there is a benefit on the table, mostly being the >>> ability >>> to only require configuration of access to 1 service (that's if JMAP >>> does >>> submission). >>> >>> I believe we should be looking for opportunities to make mail the >>> best >>> experience possible, come up with ideas, and we may decided to defer >>> some >>> or not implement others, but we should keep them in mind so that >>> perhaps we >>> don't close off the path to some of them. We don't need another >>> protocol >>> that is hamstrung by lack of foresight. >>> >>> there are plenty of ideas around, look at the competition. >>> >> >> Email is the most widely deployed multi-vendor messaging system on >> the >> Internet. The major value of doing JMAP as a standard is to get >> multi-vendor deployment. A walled garden will always have features >> that an >> open multi-vendor system can't achieve (simply for privacy reasons). >> Yes, >> we should look at the features that are popular in walled garden >> messaging >> systems and do a cost/benefit analysis. If the cost is low and >> benefit is >> high, let's consider it. But if the cost is high or the feature will >> involve a lot of careful design work and is outside the charter >> scope, then >> you'll get opposition to adding that feature to the JMAP base spec. >> >> A multi-vendor standard needs to support both small and large >> deployments >> and support both cloud and on-premises deployments. There are >> hundreds of >> deployed IMAP and Submission server implementations on the Internet >> and >> JMAP will deploy a lot faster if it "plays well" with those >> implementations. And by "play well", I mean it can be added to an >> existing >> deployment without major infrastructure changes. >> >> 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. >> >> Suppose we remove the "outbox" model from JMAP and replace it with a >> submission command with envelope extensions. Now suppose we want to >> require >> JMAP servers to support BINARYMIME submission (and/or append) as a >> boon to >> JMAP submission client authors? 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). Want to have the JMAP submission command handle >> both >> the \Sent folder copy and the Submission without duplicate data >> transmission? I think we need to do that. Want to have the base JMAP >> submission or append command include IMAP CATENATE functionality >> (assemble >> a message including server-stored attachments in order to "forward >> without >> download")? I have no problem with that. >> >> There's quite a bit of room to improve the JMAP client author's >> experience >> without forcing major infrastructure changes. The WG exists to >> discuss the >> cost/benefit of various features and make an engineering judgment >> call. The >> proposals that are most likely to succeed are ones that can be >> implemented >> in a JMAP proxy without significant changes to IMAP/Submission. And >> proposals that would require reasonably straightforward or >> well-understood >> IMAP/Submission extensions are worth considering (e.g., if I need a >> per-user unique/persistent message identifier for IMAP, I understand >> the >> implications of that). > > But, if all JMAP is is a proxy of existing protocols, then it seems > like an > expensive undertaking for little gain. The JMAP charter states: "JMAP needs to be implementable on top of an IMAP server, which also supports IMAP extensions specified below. The JMAP data model needs to remain backwards compatible with the IMAP mailstore model (where a message is always associated with a single mailbox), but it might support other underlying models (e.g. Gmail-style labels). I largely support that constraint on the WG. Although the WG can change its charter to add non-controversial IMAP extensions to the list (e.g., draft-brandt-imap-replace-02 may fall in that category). > And does that mean any future extensions have to be also implemented > in IMAP? No. I'd implement all JMAP mail store functionality I choose to expose as IMAP extensions, but that's my personal implementation choice and not a constraint on the WG. - Chris From nobody Wed Apr 26 16:45:57 2017 Return-Path: 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 10067126B71 for ; Wed, 26 Apr 2017 16:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 zGhur07zT4Ya for ; Wed, 26 Apr 2017 16:45:54 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [122.56.26.1]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72535129487 for ; Wed, 26 Apr 2017 16:45:53 -0700 (PDT) Received: From [192.168.1.146] (unverified [192.168.1.146]) by SMTP Server [192.168.1.3] (WinGate SMTP Receiver v9.0.5 (Build 5926)) with SMTP id <0001031402@smtp.qbik.com>; Thu, 27 Apr 2017 11:45:51 +1200 From: "Adrien de Croy" To: "Ted Lemon" , "Chris Newman" Cc: "jmap@ietf.org" , "Bron Gondwana" Date: Wed, 26 Apr 2017 23:45:52 +0000 Message-Id: In-Reply-To: References: <46F700A6-C2B1-488B-A8B4-6ACD45B03C31@oracle.com> <1493099769.3023399.955193288.6D0312CC@webmail.messagingengine.com> <33553450-82F4-4CB4-8679-C9F52D8A8839@oracle.com> <1493163974.4122214.956244160.6735E49C@webmail.messagingengine.com> <1493185260.709114.956477904.75CB343B@webmail.messagingengine.com> Reply-To: "Adrien de Croy" User-Agent: eM_Client/7.0.27943.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MB36014651-0FE8-491B-BB87-05ACF633845B" Archived-At: Subject: Re: [Jmap] simpler future release & unsend without outbox (was Re: Best vs Good enough - adoption of JMAP) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 23:45:57 -0000 --------=_MB36014651-0FE8-491B-BB87-05ACF633845B Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable ------ Original Message ------ From: "Ted Lemon" To: "Chris Newman" Cc: "jmap@ietf.org" ; "Bron Gondwana" Sent: 27/04/2017 7:09:07 AM Subject: Re: [Jmap] simpler future release & unsend without outbox (was=20 Re: Best vs Good enough - adoption of JMAP) >On Apr 26, 2017, at 1:54 PM, Chris Newman =20 >wrote: >>I'll describe a model that achieves my goal (which is to provide the=20 >>desired future release & unsend functionality without requiring the=20 >>server to implement a storage model with combined mail store and mail=20 >>queue semantics). >>[...] > >This looks good to me, FWIW. :) > same > --------=_MB36014651-0FE8-491B-BB87-05ACF633845B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

------ Original Message ------
From: "Ted Lemon" <mellon@fugue= .com>
To: "Chris Newman" <chri= s.newman@oracle.com>
Cc: "jmap@ietf.org" <jmap@ietf.org= >; "Bron Gondwana" <brong@fa= stmail.fm>
Sent: 27/04/2017 7:09:07 AM
Subject: Re: [Jmap] simpler future release & unsend without outbox= (was Re: Best vs Good enough - adoption of JMAP)

On Apr 26, 2017, at 1:54 PM, Chris Newman <chris.newman@oracle.com> wrote:
I'll describe a model that achieves my goal (which is to= provide the desired future release & unsend functionality without requ= iring the server to implement a storage model with combined mail store and= mail queue semantics).
[...]

This= looks good to me, FWIW. :)


<= div id=3D"x0bfbd48213584be592954e509196cf6f">
same

--------=_MB36014651-0FE8-491B-BB87-05ACF633845B-- From nobody Wed Apr 26 16:52:58 2017 Return-Path: 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 0736B129487 for ; Wed, 26 Apr 2017 16:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=CbKTIaSX; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=hNKRAnp1 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 DZ_tsvEE1nwO for ; Wed, 26 Apr 2017 16:52:55 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCB12126B71 for ; Wed, 26 Apr 2017 16:52:55 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id 0C15C21BAA; Wed, 26 Apr 2017 19:52:55 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Wed, 26 Apr 2017 19:52:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=w2MK1Pv45CLgkF2AgYQMISljbdLof b4X1H1jOIuGF1E=; b=CbKTIaSXeGofF1EVu7qXdvbhqD0BLkjZ9KE9E5yQ4vrlE vsAEYMB8nP09aXS0Pu66HVYi5xL2XZNV7I5MrsaKZNipJNvjm+MCv7K78ACHhhIw sunHK9V+R18Q7wMfzWeG2LAZfj0uGccgNSztrSsfrabtsyJcPfWdMx2grjgPBNVo BdRmS8JZH3l/45Y+wGddOErsmv8ebElttIHfiAoVRm8V89nqjFFIWCeCYC40nGX+ Vt5LiCUuR6F/nGHdvbIgvXEFqKz+zjJRvo7G0cIDuLpDQHt0dUuWy3cPxpBgrtfo 5AWpKBBSwMRuWo9F0vTxl1QVPTS+tgPRerjvtcc1A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=w2MK1P v45CLgkF2AgYQMISljbdLofb4X1H1jOIuGF1E=; b=hNKRAnp1YZEPbvjJ3pb8nC e1wRirvs9xEo4SzJHXR9ZYYfao7NWJymrw9nQ3VpcF5Ejr9mEzx+RiSIp0KE4o15 XL1qbr6Kdm9IjVLbUbdvGYZZ7pkSFI+qStFYsrQZayVOVvTmv4UKVJGjnjIhBw6Q GpmOZ6v8za2uRycl7cW3OqRq9tCyv5awd3Rh0NRQnYECjkc7ySZvL8dTF7hXHdC6 rBJra7xdAQ5pkJTenaw8y+V1zJ0OLP6NZw6b9xHqUqsL5k60oPrz1E4eTElC5yGN IVFe5LLOUHiO4099wMi14WAbNf+cfnDN+Sfus6Lh6wgy5Tyfq1y1qYYVkm5ZjZsw == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id BA521E27D8; Wed, 26 Apr 2017 19:52:54 -0400 (EDT) Message-Id: <1493250774.1341635.957564528.05401825@webmail.messagingengine.com> From: Neil Jenkins To: Adrien de Croy Cc: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_149325077413416351" X-Mailer: MessagingEngine.com Webmail Interface - ajax-843b6574 In-Reply-To: References: <46F700A6-C2B1-488B-A8B4-6ACD45B03C31@oracle.com> <1493099769.3023399.955193288.6D0312CC@webmail.messagingengine.com> <33553450-82F4-4CB4-8679-C9F52D8A8839@oracle.com> <1493163974.4122214.956244160.6735E49C@webmail.messagingengine.com> <1493185260.709114.956477904.75CB343B@webmail.messagingengine.com> <1493248332.1295949.957537688.05443911@webmail.messagingengine.com> Date: Wed, 26 Apr 2017 23:52:54 +0000 Archived-At: Subject: Re: [Jmap] simpler future release & unsend without outbox (was Re: Best vs Good enough - adoption of JMAP) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 23:52:57 -0000 This is a multi-part message in MIME format. --_----------=_149325077413416351 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Wed, 26 Apr 2017, at 11:40 PM, Adrien de Croy wrote: > my personal experience with the outbox folder is that it's a pain in > the neck.. Ignoring the fact that this is one anecdote vs the UX design choice of a multitude of real products, if the outbox is separate to the sent mailbox at the protocol level it is still trivial for an MUA to present them as a single mailbox should that be what you wish to implement. You can easily get a message list with messages in (A OR B). Doing the inverse is much harder. Neil. --_----------=_149325077413416351 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Wed, 26 Apr 2017, at 11:40 PM, Adrien de Croy wrote:
my personal experience with the outbox folder is that it's a pain in the neck..

Ignoring the fact that this is one anecdote vs the UX design choice of a multitude of real products, if the outbox is separate to the sent mailbox at the protocol level it is still trivial for an MUA to present them as a single mailbox should that be what you wish to implement. You can easily get a message list with messages in (A OR B). Doing the inverse is much harder.

Neil.
--_----------=_149325077413416351-- From nobody Wed Apr 26 18:48:28 2017 Return-Path: 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 A8E3D126D05 for ; Wed, 26 Apr 2017 18:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 5jXXzpZ0rAp1 for ; Wed, 26 Apr 2017 18:48:24 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B13E812441E for ; Wed, 26 Apr 2017 18:48:24 -0700 (PDT) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v3R1mLqQ024818 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 27 Apr 2017 01:48:22 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v3R1mLuO026120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 27 Apr 2017 01:48:21 GMT Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v3R1mLo1022764; Thu, 27 Apr 2017 01:48:21 GMT Received: from [10.145.239.185] (/10.145.239.185) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 26 Apr 2017 18:48:20 -0700 From: "Chris Newman" To: "Brandon Long" Cc: "Adrien de Croy" , "jmap@ietf.org" Date: Wed, 26 Apr 2017 18:48:18 -0700 Message-ID: <3D9D8003-F757-432D-BE9E-C75665DAF990@oracle.com> In-Reply-To: References: <20170421001702.24991.qmail@ary.lan> <00616B85-F365-4B1F-82EA-2FF2623CED77@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: MailMate (1.9.6r5347) X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Subject: Re: [Jmap] Address Validation (was Re: Submission) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 01:48:26 -0000 On 26 Apr 2017, at 15:08, Brandon Long wrote: > This is the second time you've asked for the SMTP status codes and = > enhanced > status codes, I'm very unclear what the utility of those would be, and = > why > we would need to expose them to JMAP. Good protocol design requires both machine readable and human readable = status information, and IETF experience suggests that status codes need = to be extensible in a way that is lighter-weight than publishing an RFC = (a first-come-first-served or expert review IANA registry seems = reasonable to me). As JMAP submission will need status codes for the = different things that can go right or wrong at submission time, we can = either use the already defined status codes and registry, or we can = create a new set of status codes. If we create a JMAP submission status = codes registry, the registry should include a column listing SMTP = Submission status codes that map to the JMAP code. Using the existing = codes is less work in the spec but I'm fine with either approach. > We very rarely care about the difference between the codes beyond > ok/temp/perm, I won't argue this point. But I'll observe that rarely is not the same = as never. > and find that folks are fairly inconsistent about the > enhanced codes, or that the enhanced codes don't actually translate = > into > useful information from a user perspective. At best they provide a > fallback for what is otherwise a long list of regexes for the error > messages themselves. That argument may support creation of a new JMAP submission status codes = registry. > It also ties the implementation to SMTP when SMTP may not even be = > used, ie > local delivery on a service using JMAP may never use SMTP. I don't see how status codes ties JMAP to SMTP. On the flip side, the = JMAP charter already requires us to tie JMAP to Submission (RFC 6409). = That's a good thing since all non-local messages will travel over SMTP = for a very long time. > It also ties it > to SMTP when we know that we can't implement it with SMTP (due to = > address > scraping concerns). Submission (RFC 6409, port 587/465) is not the same as SMTP (RFC 5321 = port 25). I'm not aware of any address scraping concerns in = authenticated submission that wouldn't also apply to JMAP. Either the = deployment allows authenticated users to validate addresses or it = doesn't -- that's a policy choice of the deployment and nothing we say = in any spec will change that. > One could make a better case for tying it to LDAP, for example. For curiosity's sake, I'd like to hear you make that argument but I = doubt it's relevant to this list; maybe a fun bar BOF topic at an IETF = ;-). I don't think JMAP should be tied to LDAP but I wrote the pooling = LDAP client library from scratch that is deeply integrated in our server = so I'm quite familiar with that protocol. - Chris > Brandon > > On Fri, Apr 21, 2017 at 6:02 PM, Chris Newman = > > wrote: > >> On 20 Apr 2017, at 23:16, Adrien de Croy wrote: >> >>> In article someone >>>> write: >>>> >>>>> I'd love to see a mail client that does at least initial = >>>>> validation on >>>>> destination email addresses as they are added to the message, so = >>>>> that >>>>> errors in the addresses which can be resolved at that stage (e.g. >>>>> NXDOMAIN) can be raised with the email author before the mail is = >>>>> even >>>>> submitted. >>>>> >>>> >>>> This is quite the can of worms. It's easy enough to look up a = >>>> domain >>>> and see if it has an A or an MX, but whatever you were planning to = >>>> do >>>> to validate mailboxes will get you blacklisted as a listwashing >>>> spammer. >>>> >>> sure, I think there are fundamental issues with trying to go further = >>> than >>> an A/MX for now, but if we built in a mechanism to verify addresses, = >>> it >>> could be extended later, rather than being blocked off for all of = >>> eternity. >>> >>> Even A/MX would have some value. Who knows what kind of trusted = >>> mail >>> delivery infrastructure may come out in the future, at some stage we = >>> have >>> to fix SMTP. Forever is a long time. >>> >> >> The present model for MUA mail address validation is to authenticate = >> to an >> IETF standard submission server, issue a MAIL FROM + RCPT TO + RSET. >> Anyway, I support adding a feature in JMAP that does the equivalent = >> of >> performing this sequence of commands on the Submission server and = >> returns a >> 3-digit SMTP status code, optionally SMTP enhanced status codes (see = >> RFC >> 3463 section 3.2) and text string. >> >> This is quite extensible and I believe this specific functionality is >> in-scope of the JMAP charter as Submission (RFC 6409) is explicitly >> in-scope. Doing address validation this way is already quite = >> powerful. For >> example, if the submission server chooses to implement the SMTP = >> 251/551 >> response codes for local users, the mail client gains the ability to = >> prompt >> the user to correct the address book entry for that recipient. >> >> How much validation the submission server does then becomes a >> quality-of-implementation issue (and there are, of course, = >> security/privacy >> issues). Future work would be to define additional SMTP/Submit = >> enhanced >> status codes for additional address validation, but that's presently >> out-of-scope for the JMAP charter. >> >> The JMAP charter does not permit development of a new address = >> validation >> mechanism and I object to development of a new incompatible = >> validation >> mechanism on the grounds that having two mechanisms to perform the = >> same >> function is poor design, when a full-standard mechanism to do address >> validation already exists. I support mapping the existing Submission >> validation mechanism to JMAP in a way that preserves all the = >> semantics of >> the existing mechanism. >> >> - Chris >> >> _______________________________________________ >> Jmap mailing list >> Jmap@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_ma= ilman_listinfo_jmap&d=3DDwIBaQ&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057= SbK10&r=3DQBZgPENFbjFadxqU4HJ3ZDpRz3X1JlDY-keqMt52FFo&m=3D1vWqS7msmD233b9= CaI98kh4rSO2gJ-Vly0EVUxduLcE&s=3DkkW8-WUbouatu9xo78ad7vt4KcIqOQ5maMWA4RMe= w_M&e=3D >> From nobody Wed Apr 26 19:06:12 2017 Return-Path: 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 B75D612702E for ; Wed, 26 Apr 2017 19:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 WaCW5gyAGg1Q for ; Wed, 26 Apr 2017 19:06:09 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40B5312441E for ; Wed, 26 Apr 2017 19:06:09 -0700 (PDT) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v3R266JI006496 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 27 Apr 2017 02:06:06 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.13.8/8.14.4) with ESMTP id v3R265FJ014331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 27 Apr 2017 02:06:05 GMT Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v3R265GX005911; Thu, 27 Apr 2017 02:06:05 GMT Received: from [10.145.239.185] (/10.145.239.185) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 26 Apr 2017 19:06:05 -0700 From: "Chris Newman" To: "Neil Jenkins" Cc: jmap@ietf.org Date: Wed, 26 Apr 2017 19:06:03 -0700 Message-ID: In-Reply-To: <1493248332.1295949.957537688.05443911@webmail.messagingengine.com> References: <46F700A6-C2B1-488B-A8B4-6ACD45B03C31@oracle.com> <1493099769.3023399.955193288.6D0312CC@webmail.messagingengine.com> <33553450-82F4-4CB4-8679-C9F52D8A8839@oracle.com> <1493163974.4122214.956244160.6735E49C@webmail.messagingengine.com> <1493185260.709114.956477904.75CB343B@webmail.messagingengine.com> <1493248332.1295949.957537688.05443911@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5347) X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Subject: Re: [Jmap] simpler future release & unsend without outbox (was Re: Best vs Good enough - adoption of JMAP) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 02:06:11 -0000 On 26 Apr 2017, at 16:12, Neil Jenkins wrote: > On Wed, 26 Apr 2017, at 05:54 PM, Chris Newman wrote: >> I'll describe a model that achieves my goal […] >> 1. Get rid of the server-side outbox. We only have a drafts folder >> and a> sent folder. >> >> 2. Add a submission command with envelope (same structure as SMTP >> envelope but JSON syntax and quoting). We pass this command a >> reference> to a draft message in the drafts folder, and if the >> submission >> succeeds,> the message is moved to the sent folder with the envelope >> as an >> annotation. The envelope can include the already-standard >> future release> extension. >> >> 3. Add an unsend command which takes a reference to a message in the >> sent folder. If the unsend succeeds, the message can be moved back >> to> the drafts folder as part of this action. How the server >> correlates a> message in the sent folder with a message in the mail >> queue is an >> implementation detail; the spec need not specify that detail in >> order to> provide the functionality with this model. >> >> 4. Add a way to search/select messages in the Sent folder that may >> be> possible to unsend. > > From a protocol perspective, this model is basically identical to the > outbox model proposed. Well, if you believe that and I don't believe that, then the path to rough consensus is to start with my proposal and refine it until you find it acceptable :-) So let me refine item 4 a bit. It's my theory that JMAP should have a virtual folder / smart folder feature that basically behaves the same way as a real/physical folder to the client. I think JMAP should have that feature regardless of the outcome of this debate (smart/virtual folders is an even more dominant client UI feature than outbox). So let's assume we've added that feature to JMAP. Now if the client wants to present a server-side outbox view based on my proposal, it just creates an "outbox" smart folder. If the client wants to not include the release-in-the-future messages in the Sent folder view, it can create a smart folder to do that. So now the UI model you prefer is simple to implement and it doesn't have the deployment problems a server-side outbox creates. > The only difference is that rather than put the > messages that can still be recalled in a separate "outbox" mailbox, > you > put them in the sent mailbox and require some kind of search. The only > extra component your server will need is something that moves the > message from outbox to sent when it can no longer be recalled; I > seriously don't think this is a huge implementation burden. Well, it's an implementation burden that disappears completely from the system with my proposal. Thus you've made an argument that my proposal is simpler (and thus better) than the magic-server-side-outbox model. > As Brandon > has pointed out, modern mailstores need this kind of "scheduled > events" > plumbing for a number of user-facing features, and it has already been > implemented at scale in a number of systems. > From a user interface perspective, I maintain it is clearer for the > user > for these to be two separate mailboxes, and it also has the advantage > that mailboxes have a message count so MUAs can more easily see if > there > are any messages waiting to be sent still. (I would expect most MUAs > to > hide the outbox when empty.) I happen to like the client-side-outbox UI model, but I believe a server-side-outbox is a confusing UI that violates the least astonishment principle whenever an offline client is used. But my proposal puts no constraints on the UI. If you want to express the server-side-outbox UI model using my proposal, we can refine my proposal to make that easy (I just suggested a way to do that). The magic-outbox-on-server puts a number of constraints on the server design which is one of many reasons I dislike that proposal. If you're still not convinced, I can enumerate more reasons why magic-outbox-on-server is a problem and/or further refine my proposal. - Chris From nobody Thu Apr 27 08:50:46 2017 Return-Path: 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 49E4F129AD4 for ; Thu, 27 Apr 2017 08:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.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 Nb-N6QOc-IQY for ; Thu, 27 Apr 2017 08:50:43 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D756129AAA for ; Thu, 27 Apr 2017 08:49:03 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QDNYPJNTKW009F4S@mauve.mrochek.com> for jmap@ietf.org; Thu, 27 Apr 2017 08:44:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1493307839; bh=f5Ubc4++yVBQmbZ0L/JKKPryNxNo7O358JRNPLmcdCI=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=Ijteacrb6EV1oxw1I1+5cL8sLOwKLEXys01GSAPSY57isN8vKNYN/cTprtVlHUQKY ZW+2HAdqUl+76vverjWLgxn2eycTiJeOfzcR7ahT7pftzF5UdzxaEROFunVnRGzSrR DJRz2d7VlX5wYSh7WhR0mnr9JHlvlk9XG8So6b6E= MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: TEXT/PLAIN; charset=utf-8 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QDMUYC8LOW00008D@mauve.mrochek.com>; Thu, 27 Apr 2017 08:43:57 -0700 (PDT) Cc: jmap@ietf.org Message-id: <01QDNYPIIO2E00008D@mauve.mrochek.com> Date: Thu, 27 Apr 2017 08:29:09 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 26 Apr 2017 23:12:12 +0000" <1493248332.1295949.957537688.05443911@webmail.messagingengine.com> References: <46F700A6-C2B1-488B-A8B4-6ACD45B03C31@oracle.com> <1493099769.3023399.955193288.6D0312CC@webmail.messagingengine.com> <33553450-82F4-4CB4-8679-C9F52D8A8839@oracle.com> <1493163974.4122214.956244160.6735E49C@webmail.messagingengine.com> <1493185260.709114.956477904.75CB343B@webmail.messagingengine.com> <1493248332.1295949.957537688.05443911@webmail.messagingengine.com> To: Neil Jenkins Archived-At: Subject: Re: [Jmap] simpler future release & unsend without outbox (was Re: Best vs Good enough - adoption of JMAP) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 15:50:44 -0000 > On Wed, 26 Apr 2017, at 05:54 PM, Chris Newman wrote: > > I'll describe a model that achieves my goal […] > > 1. Get rid of the server-side outbox. We only have a drafts folder > > and a> sent folder. > > > > 2. Add a submission command with envelope (same structure as SMTP > > envelope but JSON syntax and quoting). We pass this command a > > reference> to a draft message in the drafts folder, and if the submission > > succeeds,> the message is moved to the sent folder with the envelope as an > > annotation. The envelope can include the already-standard > > future release> extension. > > > > 3. Add an unsend command which takes a reference to a message in the > > sent folder. If the unsend succeeds, the message can be moved back to> the drafts folder as part of this action. How the server correlates a> message in the sent folder with a message in the mail queue is an > > implementation detail; the spec need not specify that detail in > > order to> provide the functionality with this model. > > > > 4. Add a way to search/select messages in the Sent folder that may be> possible to unsend. > From a protocol perspective, this model is basically identical to the > outbox model proposed. Maybe it is from the client side, but from the server side it's very, very different. The key point is there's no longer a queue that has to be maintained in a mailbox. > The only difference is that rather than put the > messages that can still be recalled in a separate "outbox" mailbox, you > put them in the sent mailbox and require some kind of search. That's from the client perspective. > The only > extra component your server will need is something that moves the > message from outbox to sent when it can no longer be recalled; I > seriously don't think this is a huge implementation burden. It's not even close to being the only additional component. > As Brandon > has pointed out, modern mailstores need this kind of "scheduled events" > plumbing for a number of user-facing features, and it has already been > implemented at scale in a number of systems. We don't have any such plumbing in our product that's connected to folder or messages. And I cannot think of a single case where we've been asked for a feature that required it. Ned From nobody Thu Apr 27 09:17:13 2017 Return-Path: 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 C3F8A1270A0 for ; Thu, 27 Apr 2017 09:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.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 4mdiS4CXVngW for ; Thu, 27 Apr 2017 09:17:10 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4435A129AD8 for ; Thu, 27 Apr 2017 09:15:32 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QDNZR1PF8W009T1S@mauve.mrochek.com> for jmap@ietf.org; Thu, 27 Apr 2017 09:14:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1493309653; bh=IbMsgJ+n5LaqtIbkRR/00kz5qCuKPdiHYiJtDsslisc=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=QhlOthSxJaPQXeusOwyBwK6z8ZZr7ntHLT98CaE1EOtqL3/mIWv4vwthI52aUZ6RS ZIajtNRFeuVSGv7DNIsPMLX5DIpIFQ0fuwlV5jRX4YZaz7vWIUIlpka+jvK1yNDHAR WQ/71WsgWBWKU8+Z012pIRNcgcciTmUqvaJA5SDY= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QDMUYC8LOW00008D@mauve.mrochek.com>; Thu, 27 Apr 2017 09:14:11 -0700 (PDT) Cc: Ned Freed , Chris Newman , jmap@ietf.org, Neil Jenkins Message-id: <01QDNZQZRDY800008D@mauve.mrochek.com> Date: Thu, 27 Apr 2017 08:56:43 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 26 Apr 2017 15:23:56 -0700" References: <46F700A6-C2B1-488B-A8B4-6ACD45B03C31@oracle.com> <1493099769.3023399.955193288.6D0312CC@webmail.messagingengine.com> <33553450-82F4-4CB4-8679-C9F52D8A8839@oracle.com> <1493163974.4122214.956244160.6735E49C@webmail.messagingengine.com> <01QDMH1QNOUK00008D@mauve.mrochek.com> To: Brandon Long Archived-At: Subject: Re: [Jmap] Best vs Good enough - adoption of JMAP X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 16:17:12 -0000 > I think a modern mail store already has need for this type of scheduled > events for many cases, and as such is implemented by many of them. > Off the top of my head, beyond undo send/future send, Done on the MTA side of things, where the queue structures don't have to map to users and there are many, many, many orders of magnitude less data. > there is also > automatic emptying of the trash, There's no need for a queue or queue management to do folder content expiration. > remind me later, and enterprise style retention policies. These are simply elaborations on future release and folder content expiration. > Once you have such a model, you'll find it useful for a bunch of other > things, such as data migration or applying changes across a very large mail > store. Again, that just doesn't match our reality. Ned From nobody Thu Apr 27 15:10:40 2017 Return-Path: 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 D1F39129B22 for ; Thu, 27 Apr 2017 15:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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, RCVD_IN_DNSWL_MED=-2.3, 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 (2048-bit key) header.d=apple.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 B2Jxsk9vUios for ; Thu, 27 Apr 2017 15:10:37 -0700 (PDT) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0A01129B6A for ; Thu, 27 Apr 2017 15:07:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1493330853; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=lfzbWqWEoiqll0o1xYzPB8qGKOYISgYNwj6A/tdJjqA=; b=BM0Ao0rB7O64bpUTbwPKmSKmVLGo7y1wJ8hqqbTw4C6V3vyJ8ZDCrKvvXd4+4koF QP3GAeyjEq7l9IdjwSgvblyiOaxidY25BdduTGxr04LnRwLKnXPZs4sEUTpoCeCf 78/qvILoi5XzqTzAoWi8E4q5HWhcFDLJ3R1mrYFHzgHLCyZv+gF4TrNXLnt2o4na Vcok9Q6T2EKyi7GRDB9V1ZLvGC/qKePLi8Cz5bbW8HOdoxar3rp5fhab6Q9GNuHX ys0eLZMYbfAEfKoZDWC1cQ66CNw+wjpY1BetZTmRFghGrabtcUE8W/sR+UDSvqwC LWvOBjYysHjAWJhL/PL9Dg==; Received: from relay7.apple.com (relay7.apple.com [17.128.113.101]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id 92.2E.18640.5AB62095; Thu, 27 Apr 2017 15:07:33 -0700 (PDT) X-AuditID: 11973e12-29af39a0000048d0-09-59026ba57160 Received: from mailex13.apple.com (nwk-mbx16p-w01.pex.exch.apple.com [17.146.17.20]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by relay7.apple.com (Apple SCV relay) with SMTP id 55.50.18088.5AB62095; Thu, 27 Apr 2017 15:07:33 -0700 (PDT) Received: from nwk-mbx16p-w01.pex.exch.apple.com (17.146.17.20) by nwk-mbx16p-w01.pex.exch.apple.com (17.146.17.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.845.34; Thu, 27 Apr 2017 15:07:32 -0700 Received: from nwk-mbx16p-w01.pex.exch.apple.com ([17.146.17.20]) by nwk-mbx16p-w01.pex.exch.apple.com ([17.146.17.20]) with mapi id 15.01.0845.034; Thu, 27 Apr 2017 15:07:32 -0700 From: Neil Jhaveri To: Neil Jenkins CC: "jmap@ietf.org" Thread-Topic: [Jmap] Adding the Message::isForwarded property Thread-Index: AQHSrFqZUamWuQglA0y5SBdM0Bf22qG0Vv2AgAAJKoCAARNPgIAAQM4AgAAI8QCACHy7AIABibAAgAE2jwCAC8YfAIANoaqA Date: Thu, 27 Apr 2017 22:07:32 +0000 Message-ID: <1A7624AF-2FD9-4FE8-A29D-23BFADEED04B@apple.com> References: <148716911729.17277.15371202023742081890.idtracker@ietfa.amsl.com> <9eb1fd3c-8868-9d24-6c30-46d333b69fef@isode.com> <3c1711a2-46dd-db1c-506e-5e1ad89ce56d@linagora.com> <92769755-62c6-7257-ce3d-7d0b5699735d@isode.com> <27c62cc8-68e0-49b5-4900-34c26d7b4c6a@linagora.com> <1492581452.3025596.948906456.71780673@webmail.messagingengine.com> In-Reply-To: <1492581452.3025596.948906456.71780673@webmail.messagingengine.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [17.202.38.69] Content-Type: multipart/alternative; boundary="_000_1A7624AF2FD94FE8A29D23BFADEED04Bapplecom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrAIsWRmVeSWpSXmKPExsUi2FCYqrs0mynS4HqPlEXv/RlsFl+3Gjgw eSx6OZ/dY8mSn0wBTFFcNimpOZllqUX6dglcGT82drMXfJCuaN71m7WBcZpEFyMHh4SAicTx SVpdjFwcQgJrmCTmrbvC3MXICRa/M2sbM0RiPZPEqgtP2SCcDiaJWx2fWSGcHYwSc+8fYwMZ xSagLrH5XBpIt4iAqsThuRtYQWxmAWWJCTcOsIHYwgI2Ei/vf2GBqLGV2Pa1lRHCzpN4vnQp mM0C1Ht7/TR2EJsXqH77hAZ2iF3zWCXWfn8M1swpECDxas1RMJtRQEzi+6k1TBDLxCVuPZnP BPGCgMSSPeeh3hGVePn4HyuErSNx9voTRghbQaJl43NGiN4Eid977kEtFpQ4OfMJC8hiCYHX bBLdO26yTmCUnIVkxywkPbOQ9EDEdSQW7P7EBmFrSyxb+JoZxj5z4DFUr6PE3nlT2ZHVLGDk WMUolJuYmaObmWeil1hQkJOql5yfu4kRFOXT7YR2MJ5aZXWIUYCDUYmHl+EDY6QQa2JZcWXu IUZpDhYlcd4qYIoQEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwLjscMeClrhXN3P2prwN8LKI St//Ly98mZDXkd0LDJbf3V0dbfAjkivqotmKLTcy9t+r7ZdIUMz70XpQ+RaXWemBE76x/EsL +q+pHclijfvo8vuq9azF9sUnpzE0HEgvX9j2lXHt0r8/vj+7/+d3m9NbTtViUR2Dj9n/TnFm /+r4KXx4ngvn1TNKLMUZiYZazEXFiQBVi2Gs0wIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCIsWRmVeSWpSXmKPExsUiOElQRHdpNlOkwb63Qha992ewWXzdauDA 5LHo5Xx2jyVLfjIFMEVx2aSk5mSWpRbp2yVwZfzY2M1e8EG6onnXb9YGxmkSXYycHBICJhJ3 Zm1j7mLk4hASWM8kserCUzYIp4NJ4lbHZ1YIZwejxNz7x4AyHBxsAuoSm8+lgXSLCKhKHJ67 gRXEZhZQlphw4wAbiC0sYCPx8v4XFogaW4ltX1sZIew8iedLl4LZLEC9t9dPYwexeYHqt09o YIfYNY9VYu33x2DNnAIBEq/WHAWzGQXEJL6fWsMEsUxc4taT+UwQLwhILNlznhnCFpV4+fgf K4StI3H2+hNGCFtBomXjc0aI3gSJ33vuQS0WlDg58wnLBEaxWUjGzkJSNgtJGURcR2LB7k9s ELa2xLKFr5lh7DMHHkP1OkrsnTeVHVnNAkaOVYwCRak5iZXmeokFBTmpesn5uZsYQXHZUJi6 g7FxudUhRgEORiUe3ohPjJFCrIllxZW5hxglOJiVRHglE5kihXhTEiurUovy44tKc1KLDzFK c7AoifMubwOqFkhPLEnNTk0tSC2CyTJxcEoB49k2bI/YxzeX/TmeWfyJe3uuJE1LZ+eZDWfW zDa32bejWu/3m72hvDu3BgsIf8zRbtDx7Ipf9820VL2jleWFf+LaXbxVt6Otc90yyj//6Tgc u9vxRPZ29zPn5hx0TCqqO++hbfl1roj1wi3S30verV6qy3dNomLuCb37beIy04/nGN5avZR3 gRJLcUaioRZzUXEiADmsxbTHAgAA Archived-At: Subject: Re: [Jmap] Adding the Message::isForwarded property X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 22:10:39 -0000 --_000_1A7624AF2FD94FE8A29D23BFADEED04Bapplecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Apr 18, 2017, at 10:57 PM, Neil Jenkins > wrote: This means we would remove the "isUnread", "isFlagged", "isAnswered" and "i= sDraft" properties from the Message object and introduce a single "keywords= " property (with respectively "\Seen" (flipped meaning), "\Flagged", "\Answ= ered" and "\Draft" keywords, as per IMAP). The main downside is I think is this is slightly less accessible for newcom= ers who haven't been exposed to IMAP, but this is probably outweighed by th= e benefits already discussed. Given the discussion above, this makes sense to me, too. My original motiva= tion for supporting an isForwarded property was to eliminate the incongruen= ce between answered and forwarded. Going back to a keywords list achieves t= hat. --_000_1A7624AF2FD94FE8A29D23BFADEED04Bapplecom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
On Apr 18, 2017, at 10:57 PM, Neil Jenkins <neilj@fastmail.com> wrote:
This means we would remove the "isUnread", "isFlagged",= "isAnswered" and "isDraft" properties from the Message= object and introduce a single "keywords" property (with respecti= vely "\Seen" (flipped meaning), "\Flagged", "\Answ= ered" and "\Draft" keywords, as per IMAP).

The main downside is I think is this is slightly less accessible for newcom= ers who haven't been exposed to IMAP, but this is probably outweighed by th= e benefits already discussed.

Given the discussion above, this makes sense to me, too. My= original motivation for supporting an isForwarded property was to eliminat= e the incongruence between answered and forwarded. Going back to a keywords= list achieves that.
--_000_1A7624AF2FD94FE8A29D23BFADEED04Bapplecom_-- From nobody Thu Apr 27 22:48:37 2017 Return-Path: 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 4D04A127A90 for ; Thu, 27 Apr 2017 22:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=ObdWCC3+; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=DkPVH97F 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 gsewNngjHxBW for ; Thu, 27 Apr 2017 22:48:33 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 218521294FD for ; Thu, 27 Apr 2017 22:46:27 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id 830CC20A70; Fri, 28 Apr 2017 01:46:26 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Fri, 28 Apr 2017 01:46:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=YG0MbOAGXYyQ7N4XPA77yLA5Xhn8E n6qKc1xxAUHaWk=; b=ObdWCC3+JD0y52g50sULK+nZQVjagYslcZPiQCHCvZpQC LoCNfcgl00CSbQ6rM6Ug33jW8s/7kcbeiEBaJKpH09QZ6LAnzE4SlJckP9XEABpE sprgZOyY4RK0RxY+55WXP4Q0wbhMZfQqoxcA6Wg62d3yQLrDfqEm7xtAvpv1w0bF jcOu6JosSFjM5RD18Gd4Izpt8cK09POl7Dg+m3mUpxjBOYQNRniCSklPfhRpf3ZS lr0dVjU9EC0V8PbLyJ3DHcmtZXkcxWqlz3iUibrV+pUfIXywYupT+VOTFxEwUahr 2ePXm1ytmQ7e47MPAwJjT/xeBK5b5HVwf27xu5qOA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=YG0MbO AGXYyQ7N4XPA77yLA5Xhn8En6qKc1xxAUHaWk=; b=DkPVH97F+CEKP0Vc+SXeHb Kc0I1Ii64A0DDIVZ1lD4fQhus9dP2+cpb94d4Njacb8muaPieX9bagHC45v/vdYK y3AZR2iIIsuN3GjWVykkxSW0coXuvVHvwdK2dp4M2euNFDzO8BZjBQJ7n4XMvOrQ 7IQV4BWreSVis9UiCXoNIz4NinepxXbmGkrB14LiMxH97CA7+SnunhFqz/lNZlPt GPkNN0SD7zUnUIy0y9hQkytm87bWMzDyGfmQG7oADo2LGW5mW8v6cs3Ka/Pn5voO KRJzPjW2SiqDeFBD5O5yarJydNk09IXIGxiLa7K6KNrl6XBZpQWrH6j5jBkkB2/A == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 475E9E24CD; Fri, 28 Apr 2017 01:46:26 -0400 (EDT) Message-Id: <1493358386.1136069.958999408.285D03F1@webmail.messagingengine.com> From: Neil Jenkins To: Chris Newman Cc: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-843b6574 In-Reply-To: References: <46F700A6-C2B1-488B-A8B4-6ACD45B03C31@oracle.com> <1493099769.3023399.955193288.6D0312CC@webmail.messagingengine.com> <33553450-82F4-4CB4-8679-C9F52D8A8839@oracle.com> <1493163974.4122214.956244160.6735E49C@webmail.messagingengine.com> <1493185260.709114.956477904.75CB343B@webmail.messagingengine.com> <1493248332.1295949.957537688.05443911@webmail.messagingengine.com> Date: Fri, 28 Apr 2017 05:46:26 +0000 Archived-At: Subject: Re: [Jmap] simpler future release & unsend without outbox (was Re: Best vs Good enough - adoption of JMAP) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 05:48:35 -0000 On Thu, 27 Apr 2017, at 02:06 AM, Chris Newman wrote: > Well, if you believe that and I don't believe that, Then clearly we need to discover where the divergence in mental models is occurring. > * Every server that supports future release and unsend will provide > the same interface to the client. No need for the "always empty > outbox" alternative server behavior that you'll see with the outbox > model. The server will have to advertise whether it supports scheduled send regardless of the mechanics underneath. For servers that do not support scheduled send, I agree that an always-empty outbox mailbox may feel a little superfluous, however the point is to, as you say, always provide the same interface to the client regardless. The client will know from the capabilities that it must always be empty, so will probably hide it in the sidebar or equivalent navigation mechanism (in fact I expect clients will probably hide the outbox when empty regardless of scheduled send support). > * This does not unnecessarily constrain server implementation, and > permits simpler server designs. I do not believe this to be the case, as I will explain below. > * This preserves clean mail store and mail queue separation including > the security and operational benefits that provides. This is I think where the confusion lies. The outbox really isn't a mail queue, and no one is suggesting you merge it with your mail store. You clearly have existing infrastructure that supports holding scheduled messages inside your mail queue and possibly cancelling them from that. You wish to reuse this infrastructure, of course! That's fine. To do so, when the message is moved to the outbox, you would *also* submit it into your mail queue. The copy in the outbox would be the representation in JMAP land, not part of your mail queue. When the message is sent to the next hop and can no longer be recalled, you then move the JMAP message from outbox to sent, and remove the `\Draft` keyword. Other systems may choose to implement it differently, not passing it to the mail queue until the scheduled time is reached. As has been pointed out already, many systems such as Gmail, FastMail etc. already have infrastructure to do this kind of thing since it is also used for deleting messages that are X days old from the trash, supporting snoozed mail, etc. The outbox protocol is agnostic to how you wish to implement this. Your proposal constrains you to only the option *you* already have implemented. > * This makes it clear when the message enters the submission system. > There's no confusion as one has with an outbox model where a message > in the outbox may be submitted (if it's on the server) or maybe not > (if the client is offline when the message moves to the outbox). This is clearly up to the client to distinguish, but I strongly disagree this is a confusion. For the user, there is the outbox, which represents the messages that are yet to be sent. If they open the outbox, I expect most MUAs would label why they have not yet been sent (e.g. waiting for internet connection, scheduled for time X). > * Submission can have semantics fully compatible with existing > infrastructure, making this easier/faster to deploy. As mentioned above, a lot of systems already have infrastructure for "do action X in folder Y when time Z is reached", or you can alternatively use your SMTP-queue-scheduled-send to implement the outbox model, so this is actually *more* compatible with existing infrastructure than your proposal. > * The "outbox" model constrains unsend to only work if the message is > in the outbox. This model has no such constraint and works the same > regardless of where a message that can be "unsent" lives in the > infrastructure. When composing and sending a message, it goes through 2 or 3 states. These need to be represented in the mail store (and thus the protocol) so that users can understand what is going on, and what actions are available to them. Two of these we (I believe) agree on, since they are from IMAP: (1) The message is still being composed. It SHOULD be in the "drafts" mailbox and MUST have the "\Draft" keyword. This is the same as IMAP. (2) The message has been sent, cannot be recalled. It SHOULD be in the "sent" mailbox (although services may provide means for users to ask it to go somewhere else, for example we have a few users that prefer their sent mail to in the same mailbox as the message they were replying to). The third (new) state is for "scheduled" messages. We have two options for how this is represented: 1. By its presence in the "outbox". Moving it out is therefore the logical thing to unschedule it. 2. By a keyword. This permits it to be in any mailbox, although we would probably add an outbox mailbox to our server for holding these messages by default. Removing the keyword would probably be a logical way to unschedule it. This option is quite a bit less efficient at the protocol level, as without a Mailbox object (which has a precalculated total count), the client will have to issue a search every single time there's a state change to see if there are any scheduled messages. I'm presuming you are not advocating for option (3), which is no representation in the mail store, since this would be terrible for the user experience, and your proposal explicitly said "Add a way to search/select messages in the Sent folder that may be possible to unsend", which would indicate there must be some kind of state representing this status. So however you implement it, you need to trigger some state change on the JMAP server for each logical step so that clients can represent this, and update its local model as changes occur. The choice of representation is mainly down to what will map more easily to how clients wish to represent the set of scheduled messagese to users. UX designers seem to have overwhelmingly decided that putting these scheduled messages in an outbox rather than mixing them in with sent items or elsewhere is a clearer model for users to understand. I provided 5 example products in the previous email that do this, but if that's insufficient I noice we have representatives from Apple, Google and AOL on this list; perhaps they can ask their respective UI teams to comment on what they would recommend? Neil. From nobody Thu Apr 27 23:24:42 2017 Return-Path: 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 201A1129434 for ; Thu, 27 Apr 2017 23:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=xL9c9b0V; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=CdNMV/ot 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 NnY4QxKueY06 for ; Thu, 27 Apr 2017 23:24:39 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C67E9128CD5 for ; Thu, 27 Apr 2017 23:22:03 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id 201092090E; Fri, 28 Apr 2017 02:22:03 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Fri, 28 Apr 2017 02:22:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=GOc5BiXMCz5A5OtuosJK96luwxbeA FuWc482LZWkYiU=; b=xL9c9b0V5HPNcpBaOF6QwRg7367ISdaAXj3fdxFgzSS9R /wmr5uhHJJl9mdANtC06ygVdU+IAbGZE4anYhPGsA8If/f0slVtMaPHkiJPAnfT+ UmXoKzvJ1rp3wmMZu/52/nJU2iQBuvuin02SizXATRJjCgOOSt7JVnA6GXVI4lx3 67Q5uMNmTn10/mtaJh6Yq7QeAn+mr8NbrpSE8wn4dBtDfBBh0TPXRn9Uv1J5/vqc mw9pgJ7qMGw4glc12H9qAx2zI2FxYMfgKMrUAQOgGfDe8OXUCeX9dviVWaATsqkF 21wXd2ZL48Wfhg50trHLXpfNyBt8/8e/CtCfZBVmg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=GOc5Bi XMCz5A5OtuosJK96luwxbeAFuWc482LZWkYiU=; b=CdNMV/otCfxFB79sEmjRNO uJ/uzScxQz7s85ILrqkt1FfytjoSQ31DnCJxAeCPDGi20UY56FXE0kdos4GFdqy6 eRY7JY08a/bSAPA3fgJE7epAhG7yE4z9BYSOHT5FZnSbs7fHxES+MMuLv0uPKND1 D5kUHjPwYuffmrtNk4xpHNR6OZQio1nVkSs1Bz+oCttsAWvxQPafHKG33sNDijDf gvR2obLymDrE4tYTCY5AoaYHh/5yj12X/nHjiE8HmRUSxB+RD/26h84Em7/Zh+hk 1o5syHA58djF+1XLiv5AsaCnPE5j/YDb27kFnJymVLDJhC1rETtxoFx8Neq9IUrQ == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id D3EFDE266D; Fri, 28 Apr 2017 02:22:02 -0400 (EDT) Message-Id: <1493360522.1171603.959013464.217C003E@webmail.messagingengine.com> From: Neil Jenkins To: Neil Jhaveri Cc: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_149336052211716031" X-Mailer: MessagingEngine.com Webmail Interface - ajax-843b6574 References: <148716911729.17277.15371202023742081890.idtracker@ietfa.amsl.com> <9eb1fd3c-8868-9d24-6c30-46d333b69fef@isode.com> <3c1711a2-46dd-db1c-506e-5e1ad89ce56d@linagora.com> <92769755-62c6-7257-ce3d-7d0b5699735d@isode.com> <27c62cc8-68e0-49b5-4900-34c26d7b4c6a@linagora.com> <1492581452.3025596.948906456.71780673@webmail.messagingengine.com> <1A7624AF-2FD9-4FE8-A29D-23BFADEED04B@apple.com> In-Reply-To: <1A7624AF-2FD9-4FE8-A29D-23BFADEED04B@apple.com> Date: Fri, 28 Apr 2017 06:22:02 +0000 Archived-At: Subject: Re: [Jmap] Adding the Message::isForwarded property X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 06:24:41 -0000 This is a multi-part message in MIME format. --_----------=_149336052211716031 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Thu, 27 Apr 2017, at 10:07 PM, Neil Jhaveri wrote: > Given the discussion above, this makes sense to me, too. My original > motivation for supporting an isForwarded property was to eliminate the > incongruence between answered and forwarded. Going back to a keywords > list achieves that. OK, I think we have consensus on this. I've made a pull request on GitHub with the changes[1] for people to review. Two interesting points: Firstly, I think we should map the 4 \System flags to $System in JMAP. Using backslash is a real pain because it is an escape character in JSON, so examples in the spec are confusing if nothing else! Changing it to $ would make the system keywords consistent with the IANA registered keywords, which I believe will be less confusing for developers coming in without an IMAP background. The only issue would be what to do if someone has added "$Flagged" etc. user keywords on an IMAP server. This seems unlikely to be much of a real-world occurrence to me, on the basis it would have been very confusing, but I think we can just specify that these keywords are not visible over JMAP. Secondly, matching the setting of the \Answered keyword, I've added a section that the server SHOULD automatically set the $Forwarded keyword if appropriate on send (the request that started this whole thread!). This is looking at the X-Forwarded-Message-Id header though, which as mentioned earlier in the thread is not a standard (it seems it was first introduced by Thunderbird). Any thoughts on either of these, or the change as a whole? Neil. Links: 1. https://github.com/jmapio/jmap/pull/61/files --_----------=_149336052211716031 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
On Thu, 27 Apr 2017, at 10:07 PM, Neil Jhaveri wrote:
Given the discussion above, this makes sense= to me, too. My original motivation for supporting an isForwarded property = was to eliminate the incongruence between answered and forwarded. Going bac= k to a keywords list achieves that.

OK, I think we have consensus on this. I've made a pull request on GitHub with the chang= es for people to review. Two interesting points:

Firstly, I think we should map the 4 \System flags to $System in JMAP. Using backslash is a real pain because it is an escape c= haracter in JSON, so examples in the spec are confusing if nothing else! Ch= anging it to $ would make the system keywords consistent with the IANA regi= stered keywords, which I believe will be less confusing for developers comi= ng in without an IMAP background. The only issue would be what to do if som= eone has added "$Flagged" etc. user keywords on an IMAP server. This seems = unlikely to be much of a real-world occurrence to me, on the basis it would= have been very confusing, but I think we can just specify that these keywo= rds are not visible over JMAP.

Secondly, matching the setting of the \Answered keyword, I've= added a section that the server SHOULD automatically set the $Forwarded keyword if appropriate on send (the request that started this whol= e thread!). This is looking at the X-Forwarded-Message-Id hea= der though, which as mentioned earlier in the thread is not a standard (it = seems it was first introduced by Thunderbird).

Any thoughts on either of these, or the change as a whole?

Neil.
--_----------=_149336052211716031-- From nobody Thu Apr 27 23:30:10 2017 Return-Path: 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 EBE04129457 for ; Thu, 27 Apr 2017 23:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=eY3h6mP+; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=f+wzW7D+ 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 EW5Q2f20Su7A for ; Thu, 27 Apr 2017 23:30:08 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95BF8129441 for ; Thu, 27 Apr 2017 23:27:38 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id EBDD720A42; Fri, 28 Apr 2017 02:27:37 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Fri, 28 Apr 2017 02:27:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=BEy+yJJAint+IjoFG3AUz//NDg+nM GP7JudpXCkxKkY=; b=eY3h6mP+Jiq/ZGM3MdOAximgbW6vJAi54/zAn+xxh0W7x DzUwAJSwYkuzQbGrfAkG2sMgP7k5PjJw9gzqh26jXC/McbJA5Of3JhZspmODHg07 PIpOnCru6y3MyjOb/dqMsNtRCMHBldN1IUHvoFGXyeLo7pIxK9n1ku+PS+/mlADM UFRZXDpXciYYcOTc29/3lka8Qp6WnPI0VYrJ8UuRybGUe2MzRsFOg9Jf1XnYLtAB /NjK0+4reNWj8pdWxsJgE73feh2J30ZvpU6YN7oFIFZLGwVtrYj9UMpanIj0Y3nl 8gauFNDzgGcqSQ68cp2+nKdLE+KMOxVTAl9NFc69A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=BEy+yJ JAint+IjoFG3AUz//NDg+nMGP7JudpXCkxKkY=; b=f+wzW7D+FHUsxOzTUNOlcS noqBFNoZoGwghZ4L26YHvnB2/Fiolkuwb41IWJiHYa3h7qkb3M8euvDKSmBOl0/V 1DskvN30ZUmF21p772l7BBkp14f0iCACZKbnAa+z0aosPsGVKPe1aChSJc1ricDg xpdlKnsQybkfZmeSID6Rs89kxjh7yU5Fj3KVYuL9ZfRyrsk2cPqneoi2M6JhwFdK Byn0iedcUT8Uy6oL4pbtmV6eAnBPGZF0chm7Rj6C3Vvje/UscTDZEnYsqi+cdORW uaTmT+vOG41wjM6ag4VQEyHTz/6UFba4YLwN6cWqM81aUDqi5Mg5t8i8sJQ5Qd5Q == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id BBF47E266D; Fri, 28 Apr 2017 02:27:37 -0400 (EDT) Message-Id: <1493360857.1167883.959018960.73919234@webmail.messagingengine.com> From: Neil Jenkins To: Brandon Long Cc: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_149336085711678832" X-Mailer: MessagingEngine.com Webmail Interface - ajax-843b6574 Date: Fri, 28 Apr 2017 06:27:37 +0000 In-Reply-To: References: <1492998899.3316920.953769616.254C9CBD@webmail.messagingengine.com> <1493084134.2830550.955039432.5403CAFB@webmail.messagingengine.com> <1493087082.2882732.955078288.61343C16@webmail.messagingengine.com> <63973317-543D-4E5C-80D3-16F5979D747D@fugue.com> <1493175371.126749.956396640.2F6911DF@webmail.messagingengine.com> Archived-At: Subject: Re: [Jmap] Draft messages - mutability X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 06:30:10 -0000 This is a multi-part message in MIME format. --_----------=_149336085711678832 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Wed, 26 Apr 2017, at 10:38 PM, Brandon Long wrote: > In terms of message mutability, we've had another case for plain > messages that we find complicated, which is if the server chooses to > modify the message.> > As an example case, suppose the server has decided that a message a > client has already synced is now a phishing message, and as such, > wants to rewrite all of the links in the message or make them not- > linkable. This is an interesting use case, and I don't have a good solution. Do you have any suggestions for how this replacement might be represented in JMAP? Happy to consider something, and whether any added complexity is worth the benefit. I can see this could also be useful in the draft case being discussed, for other clients to know which draft replaced a previous one. Neil. --_----------=_149336085711678832 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Wed, 26 Apr 2017, at 10:38 PM, Brandon Long wrote:
In terms of message mutability, we've had another case for plain messages that we find complicated, which is if the server chooses to modify the message.

As an example case, suppose the server has decided that a message a client has already synced is now a phishing message, and as such, wants to rewrite all of the links in the message or make them not-linkable. 

This is an interesting use case, and I don't have a good solution. Do you have any suggestions for how this replacement might be represented in JMAP? Happy to consider something, and whether any added complexity is worth the benefit. I can see this could also be useful in the draft case being discussed, for other clients to know which draft replaced a previous one.

Neil.
--_----------=_149336085711678832--