From nobody Thu Jan 3 04:04:14 2019 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 49F8B12D4E8; Thu, 3 Jan 2019 04:03:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Cc: jmap@ietf.org, draft-ietf-jmap-core.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154651703823.29557.748556981627156046@ietfa.amsl.com> Date: Thu, 03 Jan 2019 04:03:58 -0800 Archived-At: Subject: [Jmap] Secdir last call review of draft-ietf-jmap-core-12 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2019 12:03:59 -0000 Reviewer: Tero Kivinen Review result: Has Issues I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This is quite complicated JSON based meta application protocol, which allows all kind of operations to be done on the server. The security considerations lists most of the security concerns, including the fact that owner of the account can use push event notifications to cause denial of service attacks against 3rd party. Instead of just pointing it out, I think we should disallow that kind of DoS options, i.e., I think the push subscription needs to be extended to include initial verification step, i.e., when client registers a PushSubscription the server should immediately send one "event" notifying the creation of the push subscription and then when client sees that event it could verify that it can see it (this would also allow easy way to find out whether the given url actually works) and send verification token given in the first event back to server confirming that it can actually see the events. This would forbid client to set up denial service attacks against 3rd parties, and would also verify that the event channel is actually working, i.e. the url is accessible by the server and that the keys are correct etc. This document also has quite a lot of privacy concerns which are not addressed by it. For example email delivery and event notifications can leak lots of information even to passive attackers. I.e., if someone can see that wikileaks smtp server sends email to corporate smtp server, but the smtp traffic is encrypted so they do not know the recipient of the email, but then few seconds later see push event notification stream going to the Joe's laptop indicating something has happened in his mail box, they can find out the who the recipient was. Of course sharing mailboxes between multiple users (one of the examples given in 1.6.2), has lots of privacy issues. Perhaps some text explaining these issues would be needed in the security considerations section. Also I think it would be better example to say people share calendars, not mailboxes, as sharing calendars between different users is much more common than sharing mails. Group mailboxes do have their uses in cases of shared support mailbox, but it might be good idea to use that example instead of the current text in 1.6.2. I.e., user has their own primary mailbox, and then they also have access to shared support mailbox. From nobody Thu Jan 3 09:21:36 2019 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 598F21311BA for ; Thu, 3 Jan 2019 09:21:28 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.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 isID09d1sUHW for ; Thu, 3 Jan 2019 09:21:27 -0800 (PST) Received: from mail-it1-x130.google.com (mail-it1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 1C5EC1311BB for ; Thu, 3 Jan 2019 09:21:25 -0800 (PST) Received: by mail-it1-x130.google.com with SMTP id h193so43584281ita.5 for ; Thu, 03 Jan 2019 09:21:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6vMn7htPIDVTMG3vdYiac13Q/33PjJycg5SNJcgrrOM=; b=MUFgbIbiDM5QPjHxqRvEZaAzV8QhUHTN1DUI8cXTTB4ARL8YZ8Gk2Xk0j0DZoXm2pl OxMpU69jxUMWuD3pVtkdhADY/+Bzx+mT8b9xbADC34B80JQeA7Rsn2eRoLWyiXgrYjRN Au26ssQWvmaI2w+tVGI/jTVWXGN3P/MwHP8qQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6vMn7htPIDVTMG3vdYiac13Q/33PjJycg5SNJcgrrOM=; b=sVuuCK3cRILDRT7O4g4FI2oOU8PLLl2GxhN9/YmJL7CSp3alfJtxyio23o9fkpctei LBBqggxJkrSR9W7CFs/lrRoFX9Pb2qluQDewS2WYHLSsFRX49WFGgPAHFZwqzHZ6mONY 0Su7W6bqtq+6PdkvMMY1BAYSMYa/VxwAGEDNJOzPl1Eo8LRNLsguaOkNN5Dy2LrECJTq PdJO9U46KH398nsmzfYIO8iXqAZTf6eAKM1pNTIgeeIHhroVhBS43add0jBqXNcp2wtS tRBRKI7zOCYVjLywiTgcaVffkmj4FMc7TxcrkwewCWTTfgORlBYO6C4KJW3ALOrKOLID BE+Q== X-Gm-Message-State: AA+aEWYooXcoOmhtEMGIKJpBz8qSnG68p/s4QF65iLF6mFtaEYOFV39+ gA4EFQkoMl2Qm6N+iLYg4qh4BV9h2HkuJtUwoPi/T7lTqnpNcg== X-Google-Smtp-Source: AFSGD/WAe2NQou/Az76GN6+ksX6yyZtr57wB/nbOoJAe/tyCeGaQtBv1P2sXTp6wvBYNoFGo5yFRNPXmYtT/RYyUFIg= X-Received: by 2002:a24:3282:: with SMTP id j124mr31364799ita.173.1546536084187; Thu, 03 Jan 2019 09:21:24 -0800 (PST) MIME-Version: 1.0 References: <154651703823.29557.748556981627156046@ietfa.amsl.com> In-Reply-To: <154651703823.29557.748556981627156046@ietfa.amsl.com> From: "Kurt Andersen (IETF)" Date: Thu, 3 Jan 2019 09:21:12 -0800 Message-ID: To: Tero Kivinen Cc: secdir@ietf.org, IETF JMAP Mailing List , draft-ietf-jmap-core.all@ietf.org Content-Type: multipart/alternative; boundary="000000000000ee3618057e90fd32" Archived-At: Subject: Re: [Jmap] Secdir last call review of draft-ietf-jmap-core-12 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2019 17:21:29 -0000 --000000000000ee3618057e90fd32 Content-Type: text/plain; charset="UTF-8" On Thu, Jan 3, 2019 at 4:04 AM Tero Kivinen wrote: > Reviewer: Tero Kivinen > Review result: Has Issues > > This document also has quite a lot of privacy concerns which are not > addressed by it. For example email delivery and event notifications can > leak lots of information even to passive attackers. > How is this any different than the risks present in current mechanisms (websockets, HTTP, MAPI, IMAP, etc.)? I don't see this as a new risk being introduced by the JMAP protocol. Of course sharing mailboxes between multiple users (one of the > examples given in 1.6.2), has lots of privacy issues. > Again, this is not a new risk being introduced by JMAP. It seems unfair to saddle the JMAP protocol with the responsibility of documenting a comprehensive set of privacy and security risks for bad or risky behaviours that have been a wide part of common practice for decades. --Kurt Andersen --000000000000ee3618057e90fd32 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jan 3, 2019 at 4:04 AM Tero Kivin= en <kivinen@iki.fi> wrote:
<= /div>
Reviewer: Tero Kivinen
Review result: Has Issues

This document also has quite a lot of privacy concerns which are not
addressed by it. For example email delivery and event notifications can
leak lots of information even to passive attackers.
How is this any different than the risks present in current me= chanisms (websockets, HTTP, MAPI, IMAP, etc.)? I don't see this as a ne= w risk being introduced by the JMAP protocol.

Of course sharing mailboxes between multiple users (one of the
examples given in 1.6.2), has lots of privacy issues.=C2=A0

Again, this is not a new risk being introduced by JMAP= . It seems unfair to saddle the JMAP protocol with the responsibility of do= cumenting a comprehensive set of privacy and security risks for bad or risk= y behaviours that have been a wide part of common practice for decades.

--Kurt Andersen
--000000000000ee3618057e90fd32-- From nobody Thu Jan 3 16:31:47 2019 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 61E5913139F; Thu, 3 Jan 2019 16:31:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 8DfxrA0QpGJW; Thu, 3 Jan 2019 16:31:43 -0800 (PST) Received: from mail-io1-f43.google.com (mail-io1-f43.google.com [209.85.166.43]) (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 3B276131392; Thu, 3 Jan 2019 16:31:43 -0800 (PST) Received: by mail-io1-f43.google.com with SMTP id s22so28400127ioc.8; Thu, 03 Jan 2019 16:31:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/lHtNsfmhEuWLztp8kozShaHhIyxsp7bffxLLvOMEyM=; b=S7BWYxANcmhS/CwLz/AIt3d5h5NORzultpIMLvx04y956DvundqFt3yJwwl96vjHOZ /iEQnawqVUfVO7/e54HiGMOedbMtJyOpOPY3I1A1KF01d/gtSXevyRbve41uAVOsQjuy d2hN7hgpXRqZ6rSJ6Jpm+1bX6Nq6i9szMqGiHpnIx332GNEiPm/4+CjxDXBCLljFzPhI uu168QzrJryX1kF/OfJguDCKmbt150l/NZJOVLGK9BPNMQ/a8k+m2pIlmyXgw3FJej+M mK+nVqc3h0w4pIvzu5u/0HKlXtCHd9inbCa6cjqt3U62ABqyzPJod1q7KLFc/qrV3XMC fMiQ== X-Gm-Message-State: AJcUukeITUI5fAYiyO86C0Wn3oFYtrVuTkufjD8qLPe4ro1+ihkd7zb6 4zOg20sqNbo+xqeEoc9yeM9bUonRYQtxyTGuLTjgtsIv X-Google-Smtp-Source: ALg8bN47cmj+6JaA3NVDOxVCFEiyRVdPu1k07xUmsUnp6H0ieXZa+yexzHpHJGNm7/i1wiPS+4DE2Bab65DAkXg1eR4= X-Received: by 2002:a6b:6814:: with SMTP id d20mr26970253ioc.76.1546561902248; Thu, 03 Jan 2019 16:31:42 -0800 (PST) MIME-Version: 1.0 References: <154651703823.29557.748556981627156046@ietfa.amsl.com> In-Reply-To: From: Barry Leiba Date: Fri, 4 Jan 2019 08:31:31 +0800 Message-ID: To: "Kurt Andersen (IETF)" Cc: IETF JMAP Mailing List , Tero Kivinen , draft-ietf-jmap-core.all@ietf.org, secdir@ietf.org Content-Type: multipart/alternative; boundary="000000000000ce8899057e9700a4" Archived-At: Subject: Re: [Jmap] Secdir last call review of draft-ietf-jmap-core-12 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2019 00:31:46 -0000 --000000000000ce8899057e9700a4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think that advice to use TLS whenever possible is the extent of what makes sense to say here. As to shared folders, that is neither =E2=80=9Cbad=E2=80=9D nor =E2=80=9Cri= sky=E2=80=9D: it=E2=80=99s necessary for many use cases. For example, IETF itself uses shared IMAP folders to serve up our mailing lists. Help desks will use a shared inbox for, say, ithelp@example.com, to allow multiple agents to handle questions and complaints, while maintaining accountability (each agent has a separate login, so their activity is tracked). Barry On Fri, Jan 4, 2019 at 1:21 AM Kurt Andersen (IETF) wrote: > On Thu, Jan 3, 2019 at 4:04 AM Tero Kivinen wrote: > >> Reviewer: Tero Kivinen >> Review result: Has Issues >> >> This document also has quite a lot of privacy concerns which are not >> addressed by it. For example email delivery and event notifications can >> leak lots of information even to passive attackers. >> > > How is this any different than the risks present in current mechanisms > (websockets, HTTP, MAPI, IMAP, etc.)? I don't see this as a new risk bein= g > introduced by the JMAP protocol. > > Of course sharing mailboxes between multiple users (one of the >> examples given in 1.6.2), has lots of privacy issues. >> > > Again, this is not a new risk being introduced by JMAP. It seems unfair t= o > saddle the JMAP protocol with the responsibility of documenting a > comprehensive set of privacy and security risks for bad or risky behaviou= rs > that have been a wide part of common practice for decades. > > --Kurt Andersen > --000000000000ce8899057e9700a4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think that advice to use TLS whenever possible is = the extent of what makes sense to say here.
As to shared folders, that is neither =E2=80=9Cba= d=E2=80=9D nor =E2=80=9Crisky=E2=80=9D: it=E2=80=99s necessary for many use= cases.=C2=A0 For example, IETF itself uses shared IMAP folders to serve up= our mailing lists.=C2=A0 Help desks will use a shared inbox for, say, ithelp@example.com, to allow multiple= agents to handle questions and complaints, while maintaining accountabilit= y (each agent has a separate login, so their activity is tracked).

Barry

On Fri, Jan 4, 2019 at 1:21 AM Kurt Ander= sen (IETF) <kurta+ietf@drkurt= .com> wrote:
On Thu, Jan 3, 2019 at 4:04 AM Tero Kivinen <kivinen@iki.fi> wrote:<= br>
Reviewer: Tero Kivinen
Review result: Has Issues

This document also has quite a lot of privacy concerns which are not
addressed by it. For example email delivery and event notifications can
leak lots of information even to passive attackers.
How is this any different than the risks present in current me= chanisms (websockets, HTTP, MAPI, IMAP, etc.)? I don't see this as a ne= w risk being introduced by the JMAP protocol.

Of course sharing mailboxes between multiple users (one of the
examples given in 1.6.2), has lots of privacy issues.=C2=A0

Again, this is not a new risk being introduced by JMAP= . It seems unfair to saddle the JMAP protocol with the responsibility of do= cumenting a comprehensive set of privacy and security risks for bad or risk= y behaviours that have been a wide part of common practice for decades.

--Kurt Andersen
--000000000000ce8899057e9700a4-- From nobody Fri Jan 4 14:10:52 2019 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 35A18130E90; Fri, 4 Jan 2019 14:10:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.208 X-Spam-Level: X-Spam-Status: No, score=-1.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no 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 4_GoaJV21sNr; Fri, 4 Jan 2019 14:10:49 -0800 (PST) Received: from mauve.mrochek.com (unknown [66.159.242.17]) (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 2F7BC126BED; Fri, 4 Jan 2019 14:10:49 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01R1M7QJJPG000AVXT@mauve.mrochek.com>; Fri, 4 Jan 2019 14:05:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1546639545; bh=kkXce7HsCIDRBhoN1l8cVfW+AEXOob5s5Yj/yXjMRp0=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=gZkOylh7WTm1Wrdtb+eRtO9TdY58lY1yOL/JvQA8i2RlpnhXTfh+tzv56GmZXo4zW csfFWywde8W1esxzfgArNwTkWzbtlbW6Wu4b/191wx8okz33w8KkQPdcW/wwN+GL+D I332p1fpU3XwcMSm3E1K2oW2u+7NeGZfIcY9oDqU= 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 <01R1LW7PXKJ400004R@mauve.mrochek.com>; Fri, 4 Jan 2019 14:05:41 -0800 (PST) Cc: Tero Kivinen , IETF JMAP Mailing List , draft-ietf-jmap-core.all@ietf.org, secdir@ietf.org Message-id: <01R1M7QIBP9I00004R@mauve.mrochek.com> Date: Fri, 04 Jan 2019 13:45:49 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Thu, 03 Jan 2019 09:21:12 -0800" References: <154651703823.29557.748556981627156046@ietfa.amsl.com> To: "Kurt Andersen (IETF)" Archived-At: Subject: Re: [Jmap] Secdir last call review of draft-ietf-jmap-core-12 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2019 22:10:50 -0000 > On Thu, Jan 3, 2019 at 4:04 AM Tero Kivinen wrote: > > Reviewer: Tero Kivinen > > Review result: Has Issues > > > > This document also has quite a lot of privacy concerns which are not > > addressed by it. For example email delivery and event notifications can > > leak lots of information even to passive attackers. > > > How is this any different than the risks present in current mechanisms > (websockets, HTTP, MAPI, IMAP, etc.)? I don't see this as a new risk being > introduced by the JMAP protocol. AFAICT it's different in the sense that this is the first push email notification mechanism we have standardized. Push notifications also aren't mentioned in RFC 5598. So we get stuck with documenting the security concerns. An update to RFC5598 may also be order, but that's a problem for another day. > > Of course sharing mailboxes between multiple users (one of the > > examples given in 1.6.2), has lots of privacy issues. > Again, this is not a new risk being introduced by JMAP. It seems unfair to > saddle the JMAP protocol with the responsibility of documenting a > comprehensive set of privacy and security risks for bad or risky behaviours > that have been a wide part of common practice for decades. I'll first note that although the JMAP specification refers to the IMAP ACL security model extensively, RFC 4314 is not in the references list. That needs to be fixed, and a note in the security considerations section saying that the security considerations for IMAP ACLs apply to JMAP would also be good. And if the security considerations in the IMAP ACL document are deemed to be insufficient, further elaboration of some additional points may also be in order. As for fairness, the goal here is to produce quality standards. Sometimes achieving that goal means you get stuck with stuff you'd rather not have to do. Ned From nobody Fri Jan 4 15:00:12 2019 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 436D5130EA1; Fri, 4 Jan 2019 15:00:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.421 X-Spam-Level: X-Spam-Status: No, score=-3.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779] 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 0e2L44XmxcYy; Fri, 4 Jan 2019 15:00:07 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 12F9C126BED; Fri, 4 Jan 2019 15:00:06 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id x04N023K004057 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 5 Jan 2019 01:00:02 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x04N02MQ020933; Sat, 5 Jan 2019 01:00:02 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <23599.58738.605524.89790@fireball.acr.fi> Date: Sat, 5 Jan 2019 01:00:02 +0200 From: Tero Kivinen To: "Kurt Andersen \(IETF\)" Cc: secdir@ietf.org, IETF JMAP Mailing List , draft-ietf-jmap-core.all@ietf.org In-Reply-To: References: <154651703823.29557.748556981627156046@ietfa.amsl.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 13 min X-Total-Time: 12 min Archived-At: Subject: Re: [Jmap] Secdir last call review of draft-ietf-jmap-core-12 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2019 23:00:10 -0000 Kurt Andersen (IETF) writes: > On Thu, Jan 3, 2019 at 4:04 AM Tero Kivinen wrote: >=20 > Reviewer: Tero Kivinen > Review result: Has Issues > =20 > This document also has quite a lot of privacy concerns which are = not > addressed by it. For example email delivery and event notificatio= ns can > leak lots of information even to passive attackers. >=20 > How is this any different than the risks present in current mechanism= s > (websockets, HTTP, MAPI, IMAP, etc.)=3F I don't see this as a new ris= k being > introduced by the JMAP protocol. There is some similarities and differences. For example http does not have built in event notification system. In most of the other protocols the event system notification system is built on top of the other protocol running over for example http. Here if I understood correctly the event notifications are generated automatically and application writer using generic JMAP server backend might not even have any control how those events are generated and when they are generated. Because of this I think this issue belongs to the JMAP protocol document. The main difference with event notification system is, that it is not between the two peers running the JMAP protocol, or two parties running some external API connected to JMAP. It involves the third party, i.e., the party where the notifications are sent to.=20 Also the examples given in the document talk about mail, calendar, contacts etc, which all are data related to privacy and where there are lots of privacy issues, so clearly this JMAP is designed to be used in environments where privacy concerns are important, but still it is silent about them.=20 > Of course sharing mailboxes between multiple users (one of the > examples given in 1.6.2), has lots of privacy issues.=A0 >=20 > Again, this is not a new risk being introduced by JMAP. It seems unfa= ir to > saddle the JMAP protocol with the responsibility of documenting a com= prehensive > set of privacy and security risks for bad or risky behaviours that ha= ve been a > wide part of common practice for decades. If you provide example of bad and risky behaviours in your document, you need to also include the warnings about it. Thats why I did suggested you using different example (i.e., shared work calendar, shared between co-workers, or shared calendar between family members). And if you write protocol that can be used to do all kind of things you should really write comprehensive set of privacy and security risks inherintly associated with the JMAP protocol, and also include some generic warnings about common mistakes that users of JMAP can do.=20= --=20 kivinen@iki.fi From nobody Fri Jan 4 15:10:08 2019 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 6ACDA130EA2; Fri, 4 Jan 2019 15:10:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.421 X-Spam-Level: X-Spam-Status: No, score=-3.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779] 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 2UKthjD4mCPm; Fri, 4 Jan 2019 15:10:03 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 49215126BED; Fri, 4 Jan 2019 15:10:03 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id x04N9vP9021362 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 5 Jan 2019 01:09:57 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x04N9vWC011125; Sat, 5 Jan 2019 01:09:57 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <23599.59333.151268.270953@fireball.acr.fi> Date: Sat, 5 Jan 2019 01:09:57 +0200 From: Tero Kivinen To: Barry Leiba Cc: "Kurt Andersen \(IETF\)" , IETF JMAP Mailing List , draft-ietf-jmap-core.all@ietf.org, secdir@ietf.org In-Reply-To: References: <154651703823.29557.748556981627156046@ietfa.amsl.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 8 min X-Total-Time: 8 min Archived-At: Subject: Re: [Jmap] Secdir last call review of draft-ietf-jmap-core-12 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2019 23:10:06 -0000 Barry Leiba writes: > I think that advice to use TLS whenever possible is the extent of > what makes sense to say here. Using TLS does not help here, as this attack is traffic analysis attack, and you can do traffic analysis even when all the traffic is encrypted. The current draft already says that all request MUST use TLS. > As to shared folders, that is neither =E2=80=9Cbad=E2=80=9D nor =E2=80= =9Crisky=E2=80=9D: it=E2=80=99s necessary for > many use cases.=C2=A0 For example, IETF itself uses shared IMAP folde= rs to serve up > our mailing lists.=C2=A0 Help desks will use a shared inbox for, say,= =20 > ithelp@example.com, to allow multiple agents to handle questions and > complaints, while maintaining accountability (each agent has a separa= te login, > so their activity is tracked). Agreed. I was not saying it is bad or risky, but the none of the examples you gave are not really examples of ... if another user is sharing their mail with the logged in user, ... All of those are examples of user gaining access of group account (which is also mentioned). So my comment was that two individual users sharing their individual mails with each other is not really that common, and has much more privacy concerns than it help desk having shared inbox. Sharing calendar entries also has privacy concerns, but most people do understand them better and calendars provide ways of separating private / public entries already. So, I think changing the text: A single set of credentials may provide access to multiple accounts,= for example if another user is sharing their mail with the logged in= user, or if there is a group account. to something like this: A single set of credentials may provide access to multiple accounts, for example if another user is sharing their work calendar information with the logged in user. Another example of cases where access to multiple accounts can be useful is when logged in user can also access shared group account mailbox (for example it help desk inbox). would make the text better.=20 --=20 kivinen@iki.fi From nobody Fri Jan 4 15:10:19 2019 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 BE6B2130F17; Fri, 4 Jan 2019 15:10:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 90tITB1vv8VN; Fri, 4 Jan 2019 15:10:13 -0800 (PST) Received: from relay-exchange.andrew.cmu.edu (RELAY-EXCH-06.ANDREW.CMU.EDU [128.2.157.23]) (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 E165F130F2A; Fri, 4 Jan 2019 15:10:12 -0800 (PST) Received: from dcns-msgp-05.andrew.ad.cmu.edu (DCNS-MSGP-05.ANDREW.AD.CMU.EDU [128.2.157.89]) by relay-exchange.andrew.cmu.edu (8.15.2/8.15.2) with ESMTPS id x04NABM7100878 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 4 Jan 2019 18:10:11 -0500 Received: from dcns-msgp-03.andrew.ad.cmu.edu (128.2.157.87) by dcns-msgp-05.andrew.ad.cmu.edu (128.2.157.89) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1591.10; Fri, 4 Jan 2019 18:10:10 -0500 Received: from dcns-msgp-03.andrew.ad.cmu.edu ([128.2.157.87]) by dcns-msgp-03.andrew.ad.cmu.edu ([128.2.157.87]) with mapi id 15.01.1591.008; Fri, 4 Jan 2019 18:10:10 -0500 From: Jeffrey Hutzelman To: Ned Freed , "Kurt Andersen (IETF)" CC: IETF JMAP Mailing List , "draft-ietf-jmap-core.all@ietf.org" , "secdir@ietf.org" Thread-Topic: [secdir] [Jmap] Secdir last call review of draft-ietf-jmap-core-12 Thread-Index: AQHUpHpfuK2jQo3itUebxw51h9uhn6Wftx/H Date: Fri, 4 Jan 2019 23:10:10 +0000 Message-ID: References: <154651703823.29557.748556981627156046@ietfa.amsl.com> , <01R1M7QIBP9I00004R@mauve.mrochek.com> In-Reply-To: <01R1M7QIBP9I00004R@mauve.mrochek.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.2.42.4] Content-Type: multipart/alternative; boundary="_000_a7fdf568d65e4d5aa60201dcfc5c45e0cmuedu_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.78 on 128.2.157.23 Archived-At: Subject: Re: [Jmap] [secdir] Secdir last call review of draft-ietf-jmap-core-12 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2019 23:10:16 -0000 --_000_a7fdf568d65e4d5aa60201dcfc5c45e0cmuedu_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable From: secdir on behalf of Ned Freed Sent: Friday, January 4, 2019 4:45 PM To: Kurt Andersen (IETF) Cc: IETF JMAP Mailing List; draft-ietf-jmap-core.all@ietf.org; secdir@ietf.= org Subject: Re: [secdir] [Jmap] Secdir last call review of draft-ietf-jmap-cor= e-12 > On Thu, Jan 3, 2019 at 4:04 AM Tero Kivinen wrote: > > Reviewer: Tero Kivinen > > Review result: Has Issues > > > > This document also has quite a lot of privacy concerns which are not > > addressed by it. For example email delivery and event notifications can > > leak lots of information even to passive attackers. > > > How is this any different than the risks present in current mechanisms > (websockets, HTTP, MAPI, IMAP, etc.)? I don't see this as a new risk bein= g > introduced by the JMAP protocol. AFAICT it's different in the sense that this is the first push email notification mechanism we have standardized. Push notifications also aren't mentioned in RFC 5598. So we get stuck with documenting the security concerns. It may be the first such mechanism we've standardized, but it's certainly n= ot the first time we've contemplated push notification of email delivery. C= onsider RFC5435 (the Sieve notify extension), published just about 10 years= ago this month. Among other things, it contains extensive discussion of se= curity considerations surrounding push notification. > > Of course sharing mailboxes between multiple users (one of the > > examples given in 1.6.2), has lots of privacy issues. > Again, this is not a new risk being introduced by JMAP. It seems unfair t= o > saddle the JMAP protocol with the responsibility of documenting a > comprehensive set of privacy and security risks for bad or risky behaviou= rs > that have been a wide part of common practice for decades. I'll first note that although the JMAP specification refers to the IMAP ACL security model extensively, RFC 4314 is not in the references list. That ne= eds to be fixed, and a note in the security considerations section saying that = the security considerations for IMAP ACLs apply to JMAP would also be good. And if the security considerations in the IMAP ACL document are deemed to be insufficient, further elaboration of some additional points ma= y also be in order. As for fairness, the goal here is to produce quality standards. Sometimes achieving that goal means you get stuck with stuff you'd rather not have to do. True, but shared mailboxes are hardly new. They've been around pretty much = since the beginning of time. Giving advice to operators about security and = privacy issues surrounding shared mailboxes or any of a number of common us= er practices seems, to me, to be far out of scope for an access protocol sp= ecification. That's not to say that JMAP doesn't need to document security issues; of co= urse it does. If those are substantially similar to, say, IMAP, then the do= cumentation is going to be, too. And if there are issues that were missed i= n the past or have only recently become topics of discussion, that doesn't = mean they can just be ignored. But I do think it's important to keep the sc= ope manageable. -- Jeff --_000_a7fdf568d65e4d5aa60201dcfc5c45e0cmuedu_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

From: secdir <secdir-b= ounces@ietf.org> on behalf of Ned Freed <ned.freed@mrochek.com>
Sent: Friday, January 4, = 2019 4:45 PM
To: Kurt Andersen (IETF)<= /font>
Cc: IETF JMAP Mailing Lis= t; draft-ietf-jmap-core.all@ietf.org; secdir@ietf.org
Subject: Re: [secdir] [Jm= ap] Secdir last call review of draft-ietf-jmap-core-12
 
> On Thu, Jan 3, 2019 at 4:04 AM Tero Kivinen &= lt;kivinen@iki.fi> wrote:

> > Reviewer: Tero Kivinen
> > Review result: Has Issues
> >
> > This document also has quite a lot of pr= ivacy concerns which are not
> > addressed by it. For example email deliv= ery and event notifications can
> > leak lots of information even to passive= attackers.
> >

> How is this any different than the risks pres= ent in current mechanisms
> (websockets, HTTP, MAPI, IMAP, etc.)? I don't= see this as a new risk being
> introduced by the JMAP protocol.

AFAICT it's different in the sense that this is th= e first push email
notification mechanism we have standardized. Push = notifications also
aren't mentioned in RFC 5598.

So we get stuck with documenting the security conc= erns.

It may be the first such mechanism we= 've standardized, but it's certainly not the first time we've contemplated = push notification of email delivery. Consider RFC5435 (the Sieve notify ext= ension), published just about 10 years ago this month. Among other things, it contains extensive discussion of se= curity considerations surrounding push notification.



> > Of course sharing mailboxes between mult= iple users (one of the
> > examples given in 1.6.2), has lots of pr= ivacy issues.

> Again, this is not a new risk being introduce= d by JMAP. It seems unfair to
> saddle the JMAP protocol with the responsibil= ity of documenting a
> comprehensive set of privacy and security ris= ks for bad or risky behaviours
> that have been a wide part of common practice= for decades.

I'll first note that although the JMAP specificati= on refers to the IMAP ACL
security model extensively, RFC 4314 is not in the= references list. That needs
to be fixed, and a note in the security considerat= ions section saying that the
security considerations for IMAP ACLs apply to JMA= P would also be good.

And if the security considerations in the IMAP ACL= document are
deemed to be insufficient, further elaboration of = some additional points may
also be in order.

As for fairness, the goal here is to produce quali= ty standards. Sometimes
achieving that goal means you get stuck with stuff= you'd rather not have
to do.

True, but shared mailboxes are hardly new. They've= been around pretty much since the beginning of time. Giving advice to oper= ators about security and privacy issues surrounding shared mailboxes or any= of a number of common user practices seems, to me, to be far out of scope for an access protocol specification.=

That's not to say that JMAP doesn't need to docume= nt security issues; of course it does. If those are substantially similar t= o, say, IMAP, then the documentation is going to be, too. And if there are = issues that were missed in the past or have only recently become topics of discussion, that doesn't mean they = can just be ignored. But I do think it's important to keep the scope manage= able.

-- Jeff
--_000_a7fdf568d65e4d5aa60201dcfc5c45e0cmuedu_-- From nobody Sat Jan 5 10:51:16 2019 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 ECDF1130E5F; Sat, 5 Jan 2019 10:51:00 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mit.edu 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 67JI9sr7WF7L; Sat, 5 Jan 2019 10:50:58 -0800 (PST) Received: from NAM04-CO1-obe.outbound.protection.outlook.com (mail-eopbgr690127.outbound.protection.outlook.com [40.107.69.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43C3A130E36; Sat, 5 Jan 2019 10:50:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=U4qBFEilrMVxyRi03lzFdQ/pftifXnXKPXiZf7I6wzQ=; b=xLVULcrGjY8kcZLgVmTQZlKJledGEjUFV9ZGJlZIelYdcF00xKil8tXKVm5iubTHj/sA4RvX2sjukLfErsSwvNZIB2+aj8/lSYufJ1Ea4ZCL2jQ6a27QccJkfw74qqfgLlRNQbv8Jgfi2NdOIJ8vtlF472t3oJeXi1ZLFIknK4g= Received: from BL0PR0102CA0011.prod.exchangelabs.com (2603:10b6:207:18::24) by DM6PR01MB4025.prod.exchangelabs.com (2603:10b6:5:2e::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1495.6; Sat, 5 Jan 2019 18:50:56 +0000 Received: from CO1NAM03FT034.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e48::209) by BL0PR0102CA0011.outlook.office365.com (2603:10b6:207:18::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1495.6 via Frontend Transport; Sat, 5 Jan 2019 18:50:55 +0000 Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=mit.edu; Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu; Received: from outgoing.mit.edu (18.9.28.11) by CO1NAM03FT034.mail.protection.outlook.com (10.152.80.177) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1471.13 via Frontend Transport; Sat, 5 Jan 2019 18:50:55 +0000 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x05IookR031194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 5 Jan 2019 13:50:52 -0500 Date: Sat, 5 Jan 2019 12:50:50 -0600 From: Benjamin Kaduk To: "Kurt Andersen (IETF)" CC: Tero Kivinen , IETF JMAP Mailing List , , , Message-ID: <20190105185050.GB28515@kduck.kaduk.org> References: <154651703823.29557.748556981627156046@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(39860400002)(136003)(396003)(376002)(346002)(2980300002)(199004)(189003)(786003)(26826003)(16586007)(58126008)(54906003)(50466002)(14444005)(26005)(5660300001)(316002)(86362001)(486006)(53546011)(47776003)(36906005)(46406003)(106002)(33656002)(8676002)(9686003)(8936002)(336012)(23726003)(106466001)(53416004)(508600001)(2906002)(186003)(476003)(305945005)(1076003)(246002)(97756001)(6246003)(76176011)(356004)(11346002)(88552002)(426003)(956004)(104016004)(446003)(55016002)(75432002)(4326008)(126002)(7696005)(229853002)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR01MB4025; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; A:1; MX:1; X-Microsoft-Exchange-Diagnostics: 1; CO1NAM03FT034; 1:PlfI+GeI6MxeSjShGoVlfz4+XgoxeUeT7eKrQok4qNNChohdUO+Cts4u6Tfs5G2WbIES9ZhXvAwJYYYnN2fl2BUOMNYAkxOS9fJKHsQshKhH/Nhp9ahn2XgnlUU/GdEW X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 29262ba7-f578-4174-18db-08d6733eb971 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600109)(711020)(4608076)(4709027)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060); SRVR:DM6PR01MB4025; X-Microsoft-Exchange-Diagnostics: 1; DM6PR01MB4025; 3:lQALM+D9bfmBnQ7BHDYaotEZj1og8m3elrmDOz/nLj0DJZXKl2NWqRUyAk0af55dICaCkkKPPjgx6pveLZJe0DTqeICQwh1uWhZ1fpyWoAZzbPIWB+otqbYYJe9Z02Z709vrNQkCKMp1m4YZter88zhpTQFH+AZYHX8+G6C4PhBMSjFam+587JFbslIoFBqqIMT7cMURdz1Zh8/NRxN64bLItC2u960VJTnNUBy1Q6IuJycxXMtXv1Urqc2v5DpZQsHRw7SKkl8EgRkO/bmeEgKfBJJVsIdSn8aI0A2hnGQTjaJbp+lQAEFa8iAhuo/yDKSn/xp6ObbTiT2GWNVwydcIC8S3OGhlBBGMvRmpUEtSUDaJ3rRFsfUv670Vrg9s; 25:L6hPVeAggpoQBcmCRq7j+ewxAZ9DpfOSoGr2s8C3RyF+PLOFJGz22Atyo+SYigmQQKRtk1mR0dz3Nq+ZVHCHuERMb+vIfE5yEfSm9uXnkTfy3nyKprhSXXRjOjriJYTCjIBupQQXPwxjJIRH7dBjwdqovXeBPdWsH/l83chKntLb4xxqB8RynoTaZxSyv1wz3hWgOtqCwklDBPhyM0riK5OnTskuUue09OQJS15t2/sdQoqBpuAWMM3lxaVrpxOIHeBVgtMlvvnfkSXo8XTOy4R9SaHgPNtwWsYh0OvzarBRhmNLM+u5wYU29e/TZGfHUkuDNpAgI+XmHu9fqiELuw== X-MS-TrafficTypeDiagnostic: DM6PR01MB4025: X-Microsoft-Exchange-Diagnostics: 1; DM6PR01MB4025; 31:d3lVnjdTDV9My1oXn50jCHXhGo0YjcbX4E3Apn6eCQM0Crvw6W+zunQ6qkpRz+wY7xXgrfdEwOPewKQb92lUridYx6JRiQS02b6ufRX0yrwCNmJlqxqWRSx7MU9yuqRfHWuKvyricwaOqCcjUFhDGhP5OF501N8l1vsl6AQXkQeqwaMVuBkjUuo8lNqCLSG67FSrFA8GxwL8emmwGzfut1nNXCWaqOBvaRXQojtdTAw=; 20:GChGfZsc7XyvPT5IbMQeIDvZQUwWOA30B8iqFQIIRYBGAnR4U9HOXVVcENAc0UaMAjL437grA5FjeSdxf9ZYIC1d4XP1890X3N/UObuUu4gZ/1bZ71dBhql2r/HoJYC9EUptjqK5bi//+YJbIevsbbgfLX4wR3WqorcI8E65HPkUVikXjzgMltrBcw2cv94GHeynQiSsAZ3iBScfg6JmG/QHfio+QTEYr8mc4yDKPyphKWb3JK/QsljFCUmLq3UijJF44DlxUzhg/j0oDbSxf7F9LxveSC3rKLUQ2tm9EUAUFhT3/4PyhgUaJEHbIfh1OypGJed935OL24Y22xuM5qBE0Ci2j3LD4gu86CcnlYR6XnKa1V/QOo1dbeEUaiaZSl7n3flq7HSKtGS0zkLNXcJdEAbivn+zbmjnVAJta+Mmhpo1Csfe1q+1W5Q9RYZPRrtedqnEwB5wzK4qJYesCUNa5EbmTrQaRXCf0DexMS/wkRjv3C7Ko4ITAR+iFbBq X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(908002)(999002)(5005026)(6040522)(8220060)(2401047)(8121501046)(93006095)(93004095)(3231475)(944501520)(4982022)(52105112)(10201501046)(3002001)(6041310)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(201702281529075)(20161123555045)(201703061421075)(20161123560045)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:DM6PR01MB4025; BCL:0; PCL:0; RULEID:; SRVR:DM6PR01MB4025; X-Microsoft-Exchange-Diagnostics: 1; DM6PR01MB4025; 4:fnwkLcuWCQXQj8yisPbcE6trpRgB/nRaJwBiKwdbCSM2rEnKhy9vifUYVWtQvHBX2hTTCxRnNf6HxzDucmU1Z1fXYP3x8P7n9d1a2A1ZzVFa7sfHNavPoFekyCZ8zeFd4Zy+CoLdBoSWhHMqUb1qkFOZRI/fwrYT1Xz4Qk0YzrUHfu7Tvdr9gbZsFfDXzRfavmg2wy59SHO8VrhNGFpWcHuaZAa6f3cVUekJZYTld+/YEynuR3FnKdlhpzguiN6r/o7y39Qf5FqjePoxLfpX3W13vCRGzb9giq3qhiuhI9L3BZ5Iu23ef3RZXJRARw4i X-Forefront-PRVS: 09086FB5C5 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM6PR01MB4025; 23:nmbYMX32bKEl9fJK1345xnMwtjIKOYVpMzBk7zaMb?= =?us-ascii?Q?Yn6slbG8fSO6G25LvkjA5I6rdfBw57NscsOdl5QwiLviuo2jtfkyTP5rN3FM?= =?us-ascii?Q?1B+dyWGkGRjkeyWwa5/PkVrSDg1WIemmh9uJbSTLGeUNAIN5w7xQ2bM22Osr?= =?us-ascii?Q?ohsCyMikJa76C5U3FrunNKbPv8bQ9/UCEbndrNY/vBrWZTrt72vTwEXlOjTo?= =?us-ascii?Q?2N0M0q8vlX4uH6RT+82OX+ySijmN4qftsD65vVS/TmT4MAhjZlb67bSyW8Ia?= =?us-ascii?Q?Zgsf03ofJPRIG+zpBrnGMy1qpk20Z5DqcsESdmy0oS5fymtDDCMQRRLVK1t1?= =?us-ascii?Q?aHkhg4Dtenay3c3qaBFPvtiL1BXCDRXTMQjWQd5MMXQmN+RAgfSCe/wn1Q67?= =?us-ascii?Q?w315/8TPD4mREAQHWs96XwavyQR2br5pBFVWmdqcU28QUgFvBR4TT8V7IZLy?= =?us-ascii?Q?MSIm2AWDoYwI2FrMwnOsueE4eZZelGbzAXssIeKgTheInGcW14oLa25ixv1h?= =?us-ascii?Q?pAmn4b93XbKdBFFJMQAIqQdpy0nwmjxbGDmQKMpETdhOtcXJ2yMlklwyguSk?= =?us-ascii?Q?KIKzKoGRd7GiMovGVKBoQDIhD0GfJBtqt3QPfBiT5WHKoU8S5BUX0E46DrwK?= =?us-ascii?Q?QQ8/k/Lkbl2AruXzunFhNNyNgUgKLV//znv5T88EWO4Eq4ndPrmWAKTdw6aq?= =?us-ascii?Q?2IZR3LIi4nYF/LRzw0iU6v0WNtYnzQJGwAAMhULUi5SHVVVaRlEr4x79mN1U?= =?us-ascii?Q?CXZBybtdu5aPMpVuJ6dkjBSZNTcKgaQQdXYBdXHnULUrEV8SkmYAdFkNm5Bq?= =?us-ascii?Q?DyfP8oKci+sYxyDbQ2hycvBeStEwulGGCWitRkc0pxXYHGXhDnQZylQXvsBb?= =?us-ascii?Q?GYx+qKIuZxaWq4SqN50B12wPZNan2OsxTH10Vh/jksPsC8m8MvGOl1iteNLd?= =?us-ascii?Q?lc+a3vn0zZisvb4ghwkd8LDtQ17ZLscku6o/xZvC1TnA5E7YpInbPBsb+olx?= =?us-ascii?Q?yxHRTKIYPhl9ZddRn6Kf79xYRnenYG9EGvfD8mPFG6Q0TN6yhJDW2Xkqnaso?= =?us-ascii?Q?EW1VZn4SiL2DZ2sGATT9UzxJaJPxMDAOCQ43qP34eut+iHC6eghK9ip/Jfx3?= =?us-ascii?Q?pj57rJM7lffHz1FjEv2hxFjadKUymBC5M7f8xY4Dx2DY4bvyoskD1WvqHT5E?= =?us-ascii?Q?iXdCnojdOMcCbGn/nKKFBfyAvdkR+pypM/j/j1ZTfdVQZUmoq9HAuo1NLcqU?= =?us-ascii?Q?2WocfZLAH5TKwi9iS4=3D?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: PSZUr9TGyK0f9zV6t+v5V7ikLhSGDMslcAWAnKl61rXQQ9XTRD/rcj+KnnUCegDgIbxdgJIYDlmkpIqP9MXaCdzxxYHh5jp5rVngfOc0JwIanlsNB+hbjCQzGrrA03mRBBdL39b70ynO3kc7IRunwdec7Q03lNWHSYAnxAa3Sf+oDBdccZl7vkTg18REXnVS5ldHfyAacNv3pHWYsufgVyUkyrKE099HL4IVVrbBijYcMPMfHQvRP/YoI6syY1V2b8zhPoDj07hsLYJDOgj4qa2EZ1HWRM/aLMaLBQn3Mk8hMAyJc++2vXC7AcZrAPoX X-Microsoft-Exchange-Diagnostics: 1; DM6PR01MB4025; 6:PB+zKsOwT4cAGY5IDB+TtnEVVINlHrJG52pX1BSgk7NMCtqwv7WQ/znmCVFYbfsZvKwO4cwKUrJzjehc8pwrsVrVNst5ibo+wRr8685nCfaaMwvPJcb/krAaB238sGnWjdh0UK2CK9bZIx3nt4cYfW24beFBRNf+O4mWFVLd/vO6oXxgwruUmlQybi5xj3b7zYG/QouT5vRp7OwmhcKSfiCVaZyea0TwjHccyEhDm8KC3eVZCJJ0bfjviUhwmgbd9C1qXPJqP3+lcjQ3RM1/otcUOKS0D5txoWbbaKAbrEzbQyeYt/+iv7hGfyfYLGFmD1cTIQh8YfgwJw+sFA00dt1J7gs3+tKH/Jfj3YuQiGOfFxiu6FC4QFYxiv+dCAM6zU2Bbu4Ib0IxUnkqTHb/dzb7smiH5RMN09yzOFuttruzJo8cue10VBhMkR413wXsMafCx1lZJL1+cZcu+8yJ0A==; 5:ipad+kuBVGpcp6J/3fOWSKcwyRXkwwTZgOgxwySBbXqOLBHTAl/4t/wLx2DO+XK+ZOR2Sa+vrMaYDxosVwCsHvFa/QKSb1LdK92/vtoI5B3PBvwU3EjVz0nL0p/c/3bUZuTn8ILg+hTbsZyYG2XKEVvKZdvTwSD3AaXxWzaP0sMNkvFasa0BFi7FuxCqWI5TS1398VtBCoTWlHPe/oHR7g==; 7:AcnpFXoZ8YQyUmZKCNHBcwom0gAhvOf7SqGXIV8ClZ5J/wu7XDxGtSifzbXUJAOamKKaERT49aiyFLBQuO6fs1tPk1T+j2GXL9+W972jxC2KgRnwDX9ODy3C+69nN67mlVzC+0yzw7uUD5po1b3zJA== SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Jan 2019 18:50:55.1023 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 29262ba7-f578-4174-18db-08d6733eb971 X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR01MB4025 Archived-At: Subject: Re: [Jmap] [secdir] Secdir last call review of draft-ietf-jmap-core-12 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2019 18:51:01 -0000 [I wrote this before I noticed that half the thread was stuck in my spam quarantine. Some of the points were made already, but I've left my text unchanged to avoid making it even less comprehensible that it was to start with.] On Thu, Jan 03, 2019 at 09:21:12AM -0800, Kurt Andersen (IETF) wrote: > On Thu, Jan 3, 2019 at 4:04 AM Tero Kivinen wrote: > > > Reviewer: Tero Kivinen > > Review result: Has Issues > > > > This document also has quite a lot of privacy concerns which are not > > addressed by it. For example email delivery and event notifications can > > leak lots of information even to passive attackers. > > > > How is this any different than the risks present in current mechanisms > (websockets, HTTP, MAPI, IMAP, etc.)? I don't see this as a new risk being > introduced by the JMAP protocol. But where is it documented for those other protocols? > Of course sharing mailboxes between multiple users (one of the > > examples given in 1.6.2), has lots of privacy issues. > > > > Again, this is not a new risk being introduced by JMAP. It seems unfair to > saddle the JMAP protocol with the responsibility of documenting a > comprehensive set of privacy and security risks for bad or risky behaviours > that have been a wide part of common practice for decades. In general, we need to either document ourselves or point to existing documentation of the security considerations relating to protocols we publish. "Everybody already does [bad practice X]" does not excuse us from ensuring that the risks are adequately documented. Is it unfair? Perhaps. But the IETF consensus so far seems to be that we need to properly document that which we cannot make secure, and if we're the first one to actually document it properly, then we do incur the extra burden of doing things right. -Benjamin From nobody Sat Jan 5 11:34:19 2019 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 2FDA5130DD7; Sat, 5 Jan 2019 11:34:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.208 X-Spam-Level: X-Spam-Status: No, score=-1.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no 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 Se7xloCgjvoG; Sat, 5 Jan 2019 11:34:02 -0800 (PST) Received: from mauve.mrochek.com (unknown [66.159.242.17]) (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 9176B130EBE; Sat, 5 Jan 2019 11:34:02 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01R1NGKEZT6O00CU83@mauve.mrochek.com>; Sat, 5 Jan 2019 11:28:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1546716534; bh=sf4c36YZ4BNCMpQJ5V5igQn3Ldam/WhPWvkvpXIiZ/I=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=ZSTpVD8P5VUslVAyBlJ9Xs6X28+x6NMouWyQMA2dJ5GBeP9M8DtAIBvTaZ25Q/idR FYMHUyMhczd8Wdb9WCZ/pbLJP+TPhCs/iNpikkJFc3vG81ACGX/HHPqI1w+WVPqVV6 APOvuz5PZ4gUgglioX7ClZW4jLAssQexc6lXs5EE= 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 <01R1N39ADWKW00004L@mauve.mrochek.com>; Sat, 5 Jan 2019 11:28:47 -0800 (PST) Cc: Ned Freed , "Kurt Andersen (IETF)" , IETF JMAP Mailing List , "draft-ietf-jmap-core.all@ietf.org" , "secdir@ietf.org" Message-id: <01R1NGKAIUZQ00004L@mauve.mrochek.com> Date: Sat, 05 Jan 2019 11:15:43 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Fri, 04 Jan 2019 23:10:10 +0000" References: <154651703823.29557.748556981627156046@ietfa.amsl.com> <01R1M7QIBP9I00004R@mauve.mrochek.com> To: Jeffrey Hutzelman Archived-At: Subject: Re: [Jmap] [secdir] Secdir last call review of draft-ietf-jmap-core-12 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2019 19:34:04 -0000 > It may be the first such mechanism we've standardized, but it's certainly not > the first time we've contemplated push notification of email delivery. Consider > RFC5435 (the Sieve notify extension), published just about 10 years ago this > month. Among other things, it contains extensive discussion of security > considerations surrounding push notification. Not really. The security considerations, while extensive, do not cover traffic analysis of notifications pushed directly to the client, which is the main concern here. And neither do the other RFCs defining specific sieve notification mechanisms. This is likely because all of the mechanisms we were standardizing have a different set of security issues. Indeed, almost all of the considerations covered in RFC 5435 et al. are orthogonal to the current case, which is why I didn't suggest citing RFC 5435 et al. in the current document. Ned From nobody Sat Jan 5 14:26:34 2019 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 9C380130DEC; Sat, 5 Jan 2019 14:26:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 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_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=Ac4vhkIE; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=drCyqhnm 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 sYkH6VPj7H7R; Sat, 5 Jan 2019 14:26:31 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2681B130E8A; Sat, 5 Jan 2019 14:26:31 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id B88D312C9; Sat, 5 Jan 2019 17:26:29 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Sat, 05 Jan 2019 17:26:30 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:cc:subject:content-type; s=fm1; bh=RA/AtDvOddrtwaEJnPyOwwlLq tPh2E+UNyhNmoL2zIM=; b=Ac4vhkIEAy4QOpwI3K9l4IVC6VzTyAqf8qaILCS64 dgM3Em022YZ95SNVsHgASCpil2Wbt8ayBf9c2y8EyYNGnvwHxF21Q6N30bdFTpm6 KoYP5ZcyjFypBhKuYolwoAyCekLbHq6HLpNDZo7gqIdJelYTUouNzkADSAlCFNRC kEhaOm6o4A3aBE2Ajb6Hh2PxxklILeDWGC2D/vHBg03FlpbdcGetXgzvTxfMWaEO wkP+Bdo+HRqH4uatMKTY/IYcc9KtE3LrzUakW9BoRXUATdisnpK4bBKQgvZGT7dd 7sB9XXdVAqfM9CJ94k1yhNvZmCTA2vl2SQftI3/EV//Qw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=RA/AtDvOddrtwaEJn PyOwwlLqtPh2E+UNyhNmoL2zIM=; b=drCyqhnmP2kHjXeozWqlLkLp6uKAajKDi uEvqM7ywNGbdGc7JevytpjGUBZd6LIgAygycbOYLQLLiFJyEnxYox10doWhk4Iz0 ZYViESAaUm9Jue+PoFMTfmeVZTms1k5gxBz+846xOfsKztaRPPZ5/BE3ddinMqZe FDhblK7VQcASkAYwuXPIpaBnd7cp2gscrX09xRSKtkFBUy/YRJk0sW8H5v2AjiOe j281un2VHamfJlpnIGUIrzcYZdXN0kVRSdaeZ+ytHpy4WuS7QXhauyXJJlDZZ6Yk W1yf2AVTi6ZJv5wvwH+A6wM9R2paZqMmVaMRACRTrXnr1Jnos+CeA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrvdefgdduieegucdltddurdegtdekrddttd dmucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhht necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgfkjghffffhvffutgesrgdtreerreertdenucfhrhhomhepfdeurhho nhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomh eqnecuffhomhgrihhnpehgihhthhhusgdrtghomhenucfrrghrrghmpehmrghilhhfrhho mhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhmnecuvehluhhsthgvrhfuih iivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7BCFF203BE; Sat, 5 Jan 2019 17:26:28 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-739-g7452a1e-fmstable-20190103v1 X-Me-Personality: 56629417 Message-Id: In-Reply-To: <154651703823.29557.748556981627156046@ietfa.amsl.com> References: <154651703823.29557.748556981627156046@ietfa.amsl.com> Date: Sat, 05 Jan 2019 17:26:26 -0500 From: "Bron Gondwana" To: secdir@ietf.org, "Tero Kivinen" Cc: jmap@ietf.org, draft-ietf-jmap-core.all@ietf.org, ietf@ietf.org Content-Type: multipart/alternative; boundary=8cb4414092ff4b229d537eb89e72113d Archived-At: Subject: Re: [Jmap] Secdir last call review of draft-ietf-jmap-core-12 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2019 22:26:34 -0000 --8cb4414092ff4b229d537eb89e72113d Content-Type: text/plain Hi All, sorry for the late reply - I'm on vacation with spotty internet. I am replying to the original message to retain the full CC list, but will mention things in the followup emails I have seen as well. Regarding RFC4314 - that should definitely be referenced, but by jmap-mail, not jmap-core. I don't believe that that we should change the sharing example from mail to calendar - shared mail accounts are a common thing in the business world as well as in universities. I take exception to calling that "bad or risky behaviour", not all email is private personal email. It's not unreasonable to have another personal account shared with somebody though - the secretary use case often works like this, where the secretary has read access to the boss's Inbox. I've added the discussion to the ticket for RFC4314 anyway, and created it here: https://github.com/jmapio/jmap/issues/274 We definitely need to document the security considerations for immediate third party push. https://github.com/jmapio/jmap/issues/275 And look at making the push protocol have a confirmation step: https://github.com/jmapio/jmap/issues/276 I believe that's everything from the thread - please let me know if I've missed any actions we need the authors to take. Thanks, Bron. On Thu, Jan 3, 2019, at 23:04, Tero Kivinen wrote: > Reviewer: Tero Kivinen > Review result: Has Issues > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > This is quite complicated JSON based meta application protocol, which > allows all kind of operations to be done on the server. The security > considerations lists most of the security concerns, including the fact > that owner of the account can use push event notifications to cause > denial of service attacks against 3rd party. > > Instead of just pointing it out, I think we should disallow that kind > of DoS options, i.e., I think the push subscription needs to be > extended to include initial verification step, i.e., when client > registers a PushSubscription the server should immediately send one > "event" notifying the creation of the push subscription and then when > client sees that event it could verify that it can see it (this would > also allow easy way to find out whether the given url actually works) > and send verification token given in the first event back to server > confirming that it can actually see the events. > > This would forbid client to set up denial service attacks against 3rd > parties, and would also verify that the event channel is actually > working, i.e. the url is accessible by the server and that the keys > are correct etc. > > This document also has quite a lot of privacy concerns which are not > addressed by it. For example email delivery and event notifications can > leak lots of information even to passive attackers. I.e., if someone > can see that wikileaks smtp server sends email to corporate smtp > server, but the smtp traffic is encrypted so they do not know the > recipient of the email, but then few seconds later see push event > notification stream going to the Joe's laptop indicating something has > happened in his mail box, they can find out the who the recipient was. > > Of course sharing mailboxes between multiple users (one of the > examples given in 1.6.2), has lots of privacy issues. Perhaps some > text explaining these issues would be needed in the security > considerations section. Also I think it would be better example to say > people share calendars, not mailboxes, as sharing calendars between > different users is much more common than sharing mails. > > Group mailboxes do have their uses in cases of shared support mailbox, > but it might be good idea to use that example instead of the current > text in 1.6.2. I.e., user has their own primary mailbox, and then they > also have access to shared support mailbox. > > -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --8cb4414092ff4b229d537eb89e72113d Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi All, sorry for the la= te reply - I'm on vacation with spotty internet.  I am replying to = the original message to retain the full CC list, but will mention things= in the followup emails I have seen as well.

Regarding RFC4314 - that should definitely b= e referenced, but by jmap-mail, not jmap-core.  I don't believe tha= t that we should change the sharing example from mail to calendar - shar= ed mail accounts are a common thing in the business world as well as in = universities.  I take exception to calling that "bad or risky behav= iour",  not all email is private personal email.  It's not unr= easonable to have another personal account shared with somebody though -= the secretary use case often works like this, where the secretary has r= ead access to the boss's Inbox.  I've added the discussion to the t= icket for RFC4314 anyway, and created it here:

https://github.com/jmapio/jmap/issues/274

We definitely need to document the se= curity considerations for immediate third party push.


And look at making t= he push protocol have a confirmation step:


I believe that's everything from the thread= - please let me know if I've missed any actions we need the authors to = take.

Thanks,

Bron.


On Thu, Jan 3, 2019, at 23:04, Tero Kivinen wro= te:
Reviewer: Tero Kivinen
Review result: Has Issues

I have review= ed this document as part of the security directorate's
ongoing effort to review all IETF documents be= ing processed by the
IESG.&nb= sp; These comments were written primarily for the benefit of the
security area directors.  Docum= ent editors and WG chairs should treat
these comments just like any other last call comments.

This is quite complicated JSON based meta application protocol, = which
allows all kind of oper= ations to be done on the server. The security
considerations lists most of the security concerns, inc= luding the fact
that owner of= the account can use push event notifications to cause
denial of service attacks against 3rd party.

Instead of just pointing it out, I think we should disallo= w that kind
of DoS options, i= .e., I think the push subscription needs to be
extended to include initial verification step, i.e., w= hen client
registers a PushSu= bscription the server should immediately send one
"event" notifying the creation of the push subscrip= tion and then when
client see= s that event it could verify that it can see it (this would
also allow easy way to find out whether t= he given url actually works)
= and send verification token given in the first event back to server
<= /div>
confirming that it can actually s= ee the events.

This would forbid client to set up denial = service attacks against 3rd
p= arties, and would also verify that the event channel is actually
working, i.e. the url is accessible = by the server and that the keys
are correct etc.

This document also has quite a lot of= privacy concerns which are not
addressed by it. For example email delivery and event notifications c= an
leak lots of information e= ven to passive attackers. I.e., if someone
can see that wikileaks smtp server sends email to corporat= e smtp
server, but the smtp t= raffic is encrypted so they do not know the
recipient of the email, but then few seconds later see pu= sh event
notification stream = going to the Joe's laptop indicating something has
happened in his mail box, they can find out the who= the recipient was.

Of course sharing mailboxes between m= ultiple users (one of the
exa= mples given in 1.6.2), has lots of privacy issues. Perhaps some
text explaining these issues would be= needed in the security
consi= derations section. Also I think it would be better example to say
people share calendars, not mailbox= es, as sharing calendars between
different users is much more common than sharing mails.

Group mailboxes do have their uses in cases of shared support mailbox= ,
but it might be good idea t= o use that example instead of the current
text in 1.6.2. I.e., user has their own primary mailbox, an= d then they
also have access = to shared support mailbox.


--
  Bron Gondwana, C= EO, FastMail Pty Ltd
  brong@fast= mailteam.com


--8cb4414092ff4b229d537eb89e72113d-- From nobody Sat Jan 5 15:06:24 2019 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 81698130DEC; Sat, 5 Jan 2019 15:06:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 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_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=mDdSEfhh; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=IHD3uDuQ 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 GB-62YSS4cUz; Sat, 5 Jan 2019 15:06:13 -0800 (PST) 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 1509B129AB8; Sat, 5 Jan 2019 15:06:12 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id B8A0B21B74; Sat, 5 Jan 2019 18:06:10 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Sat, 05 Jan 2019 18:06:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:cc:subject:content-type; s=fm1; bh=u10ZO7RBHZdaC77a8j3ab0x+y QvjokmxPWqgeB1HlGU=; b=mDdSEfhhj5EYH9tvHZfcF+Uy0Vb70ANrur0CAcmbE gL8GAoW1gIjekEU5U82H8ybmAQDLGKfQWaNBKMroePBtIoVykVDpNkLJ5e1h+MKM DG2AZzkyPzxNn+Bj1BDOHI42ISuiV4Jdy2bQc7TG1S2uryVsLY90ssDpx42QteQA gF7ahWTSb47dYUhzJNs+dUGbR6Hwk71fPO4Mxenx2lTk6X/BjKhLyfcNY4nuetp7 8nxVt7BQpsxvxvt3byujcw3Sy0cZU5MQ7IspzB45LS0ShYE4U9OBU7fdx3prGbRj WdNn4pKRXgXAVJGqKsyNzCQsg+soD0O2L9WaDCPi9b84A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=u10ZO7RBHZdaC77a8 j3ab0x+yQvjokmxPWqgeB1HlGU=; b=IHD3uDuQpBQPEEN14s0/gxdGenvCCAGK2 aviekS2mWXTei8jp8072GHrcw+kH9hwYfgqER9MfltfNwEffiQMGWYq/V/ouVYYe 1clgCMnsikYJ1ASAzBPoIX6GwbKVPHmOvanPDJL3cxi2x4OJh4FtMNXD38zvYq2G dJPd1tcxbPsigXnLzXl0Jmfz04AJTZH3WSRKkG4j+cYExPDFxFxJ5/OuxU18oOXr 7JoQ7/vLXEOv9Lox6QN+TXRpGAHKKvB6+5ddmufET6LjeGkT3McMtTDWZZheVfgY 9clqUcJGfI4RfKCl84Tp+VlwANxKcFvXEeHOAQwDqmzhFdek9KJJA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrvdeggddtjeculddtuddrgedtkedrtddtmd cutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfkfgjfhffhffvufgtsegrtderreerredtnecuhfhrohhmpedfpfgvihhl ucflvghnkhhinhhsfdcuoehnvghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomheqne cuffhomhgrihhnpehhthhtphhrvghquhgvshhtshdrhihouhdpghhithhhuhgsrdgtohhm necurfgrrhgrmhepmhgrihhlfhhrohhmpehnvghilhhjsehfrghsthhmrghilhhtvggrmh drtghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id A8B5D203BE; Sat, 5 Jan 2019 18:06:09 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-739-g7452a1e-fmstable-20190103v1 X-Me-Personality: 64588216 Message-Id: <7beebd38-7999-4a49-b892-c3c75b36eab4@beta.fastmail.com> In-Reply-To: References: <154651703823.29557.748556981627156046@ietfa.amsl.com> Date: Sat, 05 Jan 2019 18:06:09 -0500 From: "Neil Jenkins" To: secdir@ietf.org, "Tero Kivinen" , "Bron Gondwana" Cc: "IETF JMAP Mailing List" , draft-ietf-jmap-core.all@ietf.org, ietf@ietf.org Content-Type: multipart/alternative; boundary=579f7d2c679049869e501976f579f99c Archived-At: Subject: Re: [Jmap] Secdir last call review of draft-ietf-jmap-core-12 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2019 23:06:15 -0000 --579f7d2c679049869e501976f579f99c Content-Type: text/plain On Sun, 6 Jan 2019, at 9:26 AM, Bron Gondwana wrote: > And look at making the push protocol have a confirmation step: > https://github.com/jmapio/jmap/issues/276 I'm not convinced this is necessary and/or helpful. In the current system, the first time a push is triggered the application (JMAP) server sends a request to the push server (the URL registered by the client); if this is not accepted with a reasonable HTTP response, it would automatically disable it. The danger is meant to be DOSing this URL (it's not really a push server); however with a confirmation step, you still need to do that first request so you're not reducing the number of HTTP requests. You are however relying on the push being received by the client in order for it to be able to complete registration, and all common push services do not guarantee delivery, so this becomes much less reliable. (With this in mind, the JMAP push system happily copes with dropped push packets while still guaranteeing full resynchronisation.) I note this issue doesn't really seem to be specific to JMAP, and yet RFC8030 (which is what the push system is implementing) does not require a confirmation step. Neil. --579f7d2c679049869e501976f579f99c Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Sun, 6 = Jan 2019, at 9:26 AM, Bron Gondwana wrote:
And look at making the push protocol have a con= firmation step:

I'm not convinced this is necessary an= d/or helpful. In the current system, the first time a push is triggered = the application (JMAP) server sends a request to the push server (the UR= L registered by the client); if this is not accepted with a reasonable H= TTP response, it would automatically disable it. The danger is meant to = be DOSing this URL (it's not really a push server); however with a confi= rmation step, you still need to do that first request so you're not redu= cing the number of HTTP requests. You are however relying on the push be= ing received by the client in order for it to be able to complete regist= ration, and all common push services do not guarantee delivery, so this = becomes much less reliable. (With this in mind, the JMAP push system hap= pily copes with dropped push packets while still guaranteeing full resyn= chronisation.)

I note this issue doesn't re= ally seem to be specific to JMAP, and yet RFC8030 (which is what the pus= h system is implementing) does not require a confirmation step.

Neil.
--579f7d2c679049869e501976f579f99c-- From nobody Sat Jan 5 17:01:26 2019 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 360F0130ED9; Sat, 5 Jan 2019 17:01:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 gqdWx6ntjU9T; Sat, 5 Jan 2019 17:01:15 -0800 (PST) Received: from mail-it1-f173.google.com (mail-it1-f173.google.com [209.85.166.173]) (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 B59E3130ED4; Sat, 5 Jan 2019 17:01:15 -0800 (PST) Received: by mail-it1-f173.google.com with SMTP id i145so6433696ita.4; Sat, 05 Jan 2019 17:01:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YsAUkMcUOqZMdFK1YecIWKd8txpq7HeDgJYQou/tk8w=; b=H5wLMLouvSdcGk50sLTpAPV5IDGfg3IVuG4QT1XFnlgSnrjwwVXpmHck/m/ONVAmAL gPe3Bh3cZaC2qLTEJXO5EagUMeXUA7fwIFcxhKf8GwJg6QmsJEK7cBpPoeCgxduKJGqf 5o0ygtN4unjIHj0tKBbZw+KnR5G+Q73yUz6H+a3zEBlS+IWjIv3+PiRoqubYBzxu/EyD Ie5ZgXMd6tcxWXZbLZWNbSa/nMbRrZO9L/T1tTbMUn+VcmunX+JsIjmg5H8Eiqj8U/y+ cZ5tyLV7L7S2i4EBC62kAqxuVr3dEwTziD5RFjzwzBzBUAcMKwWbiKLsCEMuPoTAdJ+2 kncw== X-Gm-Message-State: AJcUukfEixiiYD26s/gdfuSRKgGE9T5N32/CrZ0lyTDiC9so4NdV0ukP ISkaQ0RtlWzYx8DPzo/LhXdSR+bvbpDxFXp+uX8= X-Google-Smtp-Source: ALg8bN6NVr0yZbxhykAk6YAFcOPSFUGFublIW5Uw0kTWcIYYD01tFEEzsARTpjLBqcZmPr9HLKpVeT7Cdwm6CpcOCd8= X-Received: by 2002:a24:a04:: with SMTP id 4mr4271565itw.122.1546736473687; Sat, 05 Jan 2019 17:01:13 -0800 (PST) MIME-Version: 1.0 References: <154651703823.29557.748556981627156046@ietfa.amsl.com> <20190105185050.GB28515@kduck.kaduk.org> In-Reply-To: <20190105185050.GB28515@kduck.kaduk.org> From: Barry Leiba Date: Sun, 6 Jan 2019 09:01:02 +0800 Message-ID: To: Benjamin Kaduk Cc: IETF JMAP Mailing List , "Kurt Andersen (IETF)" , Tero Kivinen , draft-ietf-jmap-core.all@ietf.org, iesg@ietf.org, secdir@ietf.org Content-Type: multipart/alternative; boundary="000000000000134dbe057ebfa6be" Archived-At: Subject: Re: [Jmap] [secdir] Secdir last call review of draft-ietf-jmap-core-12 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2019 01:01:18 -0000 --000000000000134dbe057ebfa6be Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree with Ben that when documentation has been lacking in the past we may need to fix that in current documents. The problem, I fear, is that we write much of this, especially at the app layer, to the wrong readers, so let=E2=80=99s think about the shared mailbox case, for example, and see if = we know what will actually help, rather than tick off some IETF-process-related box= . What we write in RFCs is primarily for software developers. It would be truly bad if security/privacy warnings dissuaded developers from supporting shared mailboxes: any mail system that lacks such support would be hobbled and bad. So the best we could try would be to get vendors to copy or paraphrase our warnings in their documents, and/or to show warnings when the features are configured at installation. I think it=E2=80=99s unlikely to happen. Simi= larly, when a user shares a mailbox a popup could show... also unlikely. And what are we going to say? That sharing a mailbox that contains personal mail can expose private information? That=E2=80=99s at the same t= ime so obvious as to be silly, and entirely irrelevant to the actual shared-mailbox use cases. I think the best approach is to give examples of common use cases for sharing. That might be informative and might actually prompt some vendors to include similar examples in their doc. Barry On Sun, Jan 6, 2019 at 2:51 AM Benjamin Kaduk wrote: > [I wrote this before I noticed that half the thread was stuck in my spam > quarantine. Some of the points were made already, but I've left my text > unchanged to avoid making it even less comprehensible that it was to star= t > with.] > > On Thu, Jan 03, 2019 at 09:21:12AM -0800, Kurt Andersen (IETF) wrote: > > On Thu, Jan 3, 2019 at 4:04 AM Tero Kivinen wrote: > > > > > Reviewer: Tero Kivinen > > > Review result: Has Issues > > > > > > This document also has quite a lot of privacy concerns which are not > > > addressed by it. For example email delivery and event notifications c= an > > > leak lots of information even to passive attackers. > > > > > > > How is this any different than the risks present in current mechanisms > > (websockets, HTTP, MAPI, IMAP, etc.)? I don't see this as a new risk > being > > introduced by the JMAP protocol. > > But where is it documented for those other protocols? > > > Of course sharing mailboxes between multiple users (one of the > > > examples given in 1.6.2), has lots of privacy issues. > > > > > > > Again, this is not a new risk being introduced by JMAP. It seems unfair > to > > saddle the JMAP protocol with the responsibility of documenting a > > comprehensive set of privacy and security risks for bad or risky > behaviours > > that have been a wide part of common practice for decades. > > In general, we need to either document ourselves or point to existing > documentation of the security considerations relating to protocols we > publish. "Everybody already does [bad practice X]" does not excuse us fr= om > ensuring that the risks are adequately documented. Is it unfair? Perhap= s. > But the IETF consensus so far seems to be that we need to properly docume= nt > that which we cannot make secure, and if we're the first one to actually > document it properly, then we do incur the extra burden of doing things > right. > > -Benjamin > --000000000000134dbe057ebfa6be Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree with Ben that when documentation has been la= cking in the past we may need to fix that in current documents.=C2=A0 The p= roblem, I fear, is that we write much of this, especially at the app layer,= to the wrong readers, so let=E2=80=99s think about the shared mailbox case= , for example, and see if we know what will actually help, rather than tick= off some IETF-process-related box.

=
What we write in RFCs is primarily for software developer= s.=C2=A0 It would be truly bad if security/privacy warnings dissuaded devel= opers from supporting shared mailboxes: any mail system that lacks such sup= port would be hobbled and bad.

So the best we could try would be to get vendors to copy or paraphra= se our warnings in their documents, and/or to show warnings when the featur= es are configured at installation.=C2=A0 I think it=E2=80=99s unlikely to h= appen.=C2=A0 Similarly, when a user shares a mailbox a popup could show... = also unlikely.

And what = are we going to say?=C2=A0 That sharing a mailbox that contains personal ma= il can expose private information?=C2=A0 That=E2=80=99s at the same time so= obvious as to be silly, and entirely irrelevant to the actual shared-mailb= ox use cases.

I think th= e best approach is to give examples of common use cases for sharing.=C2=A0 = That might be informative and might actually prompt some vendors to include= similar examples in their doc.

Barry

O= n Sun, Jan 6, 2019 at 2:51 AM Benjamin Kaduk <kaduk@mit.edu> wrote:
[I wrote this before I noticed that half the thread was stuck in my spam quarantine.=C2=A0 Some of the points were made already, but I've left m= y text
unchanged to avoid making it even less comprehensible that it was to start<= br> with.]

On Thu, Jan 03, 2019 at 09:21:12AM -0800, Kurt Andersen (IETF) wrote:
> On Thu, Jan 3, 2019 at 4:04 AM Tero Kivinen <kivinen@iki.fi> wrote:
>
> > Reviewer: Tero Kivinen
> > Review result: Has Issues
> >
> > This document also has quite a lot of privacy concerns which are = not
> > addressed by it. For example email delivery and event notificatio= ns can
> > leak lots of information even to passive attackers.
> >
>
> How is this any different than the risks present in current mechanisms=
> (websockets, HTTP, MAPI, IMAP, etc.)? I don't see this as a new ri= sk being
> introduced by the JMAP protocol.

But where is it documented for those other protocols?

> Of course sharing mailboxes between multiple users (one of the
> > examples given in 1.6.2), has lots of privacy issues.
> >
>
> Again, this is not a new risk being introduced by JMAP. It seems unfai= r to
> saddle the JMAP protocol with the responsibility of documenting a
> comprehensive set of privacy and security risks for bad or risky behav= iours
> that have been a wide part of common practice for decades.

In general, we need to either document ourselves or point to existing
documentation of the security considerations relating to protocols we
publish.=C2=A0 "Everybody already does [bad practice X]" does not= excuse us from
ensuring that the risks are adequately documented.=C2=A0 Is it unfair?=C2= =A0 Perhaps.
But the IETF consensus so far seems to be that we need to properly document=
that which we cannot make secure, and if we're the first one to actuall= y
document it properly, then we do incur the extra burden of doing things
right.

-Benjamin
--000000000000134dbe057ebfa6be-- From nobody Sun Jan 6 02:57:57 2019 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 E485E130E3F; Sun, 6 Jan 2019 02:57:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 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_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, 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=fastmailteam.com header.b=VQ1Q7woz; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=sbeBd6uZ 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 IXbS6QQBsqb1; Sun, 6 Jan 2019 02:57:48 -0800 (PST) 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 C3C4E130DE9; Sun, 6 Jan 2019 02:57:47 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id CFFEB219EB; Sun, 6 Jan 2019 05:57:46 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Sun, 06 Jan 2019 05:57:46 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:cc:subject:content-type; s=fm1; bh=V9Bz/qfjju61fPu2n254j5uAu ftijAlE1hA8rSWR1qw=; b=VQ1Q7wozh1lYxD+J8KZDfRmu0kPhs55IuX8AI7F3Q hGJ9O4NT0gyBjAkOlC2DAVQjCZIyGAo4dklQsW54sl2gmZtd7Z1h/VJO/03TJp/l g3JYNVmXuqUqNBFVR0fT+IXrB0DLaT2zO8uNHB4HqAc8+B7L1u0OpQzTQIqrZ+gM Cac2qQYArwEQzezCNYMDgItDJtbPMiBYRUodVMszEJlWcU7DiHSixZYysIoXu4nU T+x2rxg3iVobUbjhjE/pKUx3vdfAHp1LpnBAjL/BGNhVkLeBBTret1C5wt4GFGf2 KaF2b0sBw59T+rmKr+sPsZ99EYPzEsBomhTEwCrljXDAg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=V9Bz/qfjju61fPu2n 254j5uAuftijAlE1hA8rSWR1qw=; b=sbeBd6uZVF3DgoYmdJ2iWQGSovin/axdo xijKMyD8g/cv4TA2HVpeYKTingN69P20FHxkzONdEgASeKROVyAAh6JtqUqEvBdu vRG0G6aB/7tuaA77/C8cki1xOWvveDh5vam7mFZGm46NZsNcNRh/lL6vEZ3SiqKM 0oQDKOUeOpk55cVsi2XdkUk/QYKeQJHZUtlbkdQoDDA3/Ka9JKZFt1aWzQSriQEg 2FOULZDbDFUJErZfF9mclbiOB9fDYqeRlEFbs0WMWRkSpVkGRvcRUfqqibnysKMz HSJPI7qY9jm0VLR07atXItrv+yNABhb/d089a6A5c+qG27zrszWng== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrvdehgddvfeculddtuddrgedtkedrtddtmd cutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfkfgjfhffhffvufgtsegrtderreerredtnecuhfhrohhmpedfuehrohhn ucfiohhnugifrghnrgdfuceosghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhmqe enucffohhmrghinhephhhtthhprhgvqhhuvghsthhsrdihohhupdhgihhthhhusgdrtgho mhenucfrrghrrghmpehmrghilhhfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrg hmrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 28A38203BE; Sun, 6 Jan 2019 05:57:46 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-739-g7452a1e-fmstable-20190103v1 X-Me-Personality: 56629417 Message-Id: <5c5a39bb-96e9-4a2f-bf20-4fdb1bbb6f6d@www.fastmail.com> In-Reply-To: <7beebd38-7999-4a49-b892-c3c75b36eab4@beta.fastmail.com> References: <154651703823.29557.748556981627156046@ietfa.amsl.com> <7beebd38-7999-4a49-b892-c3c75b36eab4@beta.fastmail.com> Date: Sun, 06 Jan 2019 05:57:43 -0500 From: "Bron Gondwana" To: secdir@ietf.org, "Tero Kivinen" , "Neil Jenkins" Cc: "IETF JMAP Mailing List" , draft-ietf-jmap-core.all@ietf.org, ietf@ietf.org Content-Type: multipart/alternative; boundary=8c1e39e2af2d404592cdcc3be2a22ea6 Archived-At: Subject: Re: [Jmap] Secdir last call review of draft-ietf-jmap-core-12 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2019 10:57:50 -0000 --8c1e39e2af2d404592cdcc3be2a22ea6 Content-Type: text/plain On Sun, Jan 6, 2019, at 10:06, Neil Jenkins wrote: > On Sun, 6 Jan 2019, at 9:26 AM, Bron Gondwana wrote: >> And look at making the push protocol have a confirmation step: >> https://github.com/jmapio/jmap/issues/276 > > I'm not convinced this is necessary and/or helpful. In the current system, the first time a push is triggered the application (JMAP) server sends a request to the push server (the URL registered by the client); if this is not accepted with a reasonable HTTP response, it would automatically disable it. The danger is meant to be DOSing this URL (it's not really a push server); however with a confirmation step, you still need to do that first request so you're not reducing the number of HTTP requests. You are however relying on the push being received by the client in order for it to be able to complete registration, and all common push services do not guarantee delivery, so this becomes much less reliable. (With this in mind, the JMAP push system happily copes with dropped push packets while still guaranteeing full resynchronisation.) > > I note this issue doesn't really seem to be specific to JMAP, and yet RFC8030 (which is what the push system is implementing) does not require a confirmation step. Tero - are you satisfied with this response? The fact that RFC8030 didn't see the need to add a confirmation step suggests that not having a confirmation step in JMAP isn't wildly different from current practice or current IETF standards, and Neil's justification that it makes setup less reliable for common push services seems reasonable. If we need to beef up the language that the server MUST disable the push channel if the endpoint URL doesn't reply correctly, and maybe even a suggestion that the server rate limit individual authenticated users and similarly detect weird behaviour and limit it. It would be great to solve this with clear advice to server implementations on how to not become a DOS amplifier rather than hobble the protocol. Cheers, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --8c1e39e2af2d404592cdcc3be2a22ea6 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Sun, Jan 6, 2019, at 10:06, Neil Jenkins wrote:
On Sun, 6 J= an 2019, at 9:26 AM, Bron Gondwana wrote:
And look at making the push prot= ocol have a confirmation step:

I'm not convinced this = is necessary and/or helpful. In the current system, the first time a pus= h is triggered the application (JMAP) server sends a request to the push= server (the URL registered by the client); if this is not accepted with= a reasonable HTTP response, it would automatically disable it. The dang= er is meant to be DOSing this URL (it's not really a push server); howev= er with a confirmation step, you still need to do that first request so = you're not reducing the number of HTTP requests. You are however relying= on the push being received by the client in order for it to be able to = complete registration, and all common push services do not guarantee del= ivery, so this becomes much less reliable. (With this in mind, the JMAP = push system happily copes with dropped push packets while still guarante= eing full resynchronisation.)

I note this i= ssue doesn't really seem to be specific to JMAP, and yet RFC8030 (which = is what the push system is implementing) does not require a confirmation= step.

Tero - are you satisfied with this re= sponse?  The fact that RFC8030 didn't see the need to add a confirm= ation step suggests that not having a confirmation step in JMAP isn't wi= ldly different from current practice or current IETF standards, and Neil= 's justification that it makes setup less reliable for common push servi= ces seems reasonable.

If we need to beef up the language = that the server MUST disable the push channel if the endpoint URL doesn'= t reply correctly, and maybe even a suggestion that the server rate limi= t individual authenticated users and similarly detect weird behaviour an= d limit it.  It would be great to solve this with clear advice to s= erver implementations on how to not become a DOS amplifier rather than h= obble the protocol.

Cheers,

Bron.

<= /div>
--
  Bron Gondwana, CEO, FastMail Pty Ltd
=
  brong@fastmailteam.com


<= /div> --8c1e39e2af2d404592cdcc3be2a22ea6-- From nobody Mon Jan 7 04:25:11 2019 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 45823130E97; Mon, 7 Jan 2019 04:25:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 8RBHtaXQKxKP; Mon, 7 Jan 2019 04:25:02 -0800 (PST) Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [131.111.8.132]) (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 47057130E0A; Mon, 7 Jan 2019 04:25:02 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:38462) by ppsw-32.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.138]:25) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1ggTxd-000fRl-05 (Exim 4.91) (return-path ); Mon, 07 Jan 2019 12:24:53 +0000 Date: Mon, 7 Jan 2019 12:24:52 +0000 From: Tony Finch To: Ned Freed cc: "Kurt Andersen (IETF)" , IETF JMAP Mailing List , draft-ietf-jmap-core.all@ietf.org, Tero Kivinen , secdir@ietf.org In-Reply-To: <01R1M7QIBP9I00004R@mauve.mrochek.com> Message-ID: References: <154651703823.29557.748556981627156046@ietfa.amsl.com> <01R1M7QIBP9I00004R@mauve.mrochek.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Jmap] Secdir last call review of draft-ietf-jmap-core-12 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2019 12:25:04 -0000 Ned Freed wrote: > > AFAICT it's different in the sense that this is the first push email > notification mechanism we have standardized. What about RFC 2177 IMAP IDLE? Tony. -- f.anthony.n.finch http://dotat.at/ Southeast Iceland: Northwesterly 7 to severe gale 9, decreasing 5 or 6, becoming variable 4 later. Rough or very rough, becoming moderate later in west. Showers at first. Poor, becoming good. From nobody Mon Jan 7 05:10:53 2019 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 4830D130E0A for ; Mon, 7 Jan 2019 05:10:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 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_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=vYGSNK3w; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=SqFt1IFz 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 F-UuICtZvu9h for ; Mon, 7 Jan 2019 05:10:50 -0800 (PST) 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 942BF1200D7 for ; Mon, 7 Jan 2019 05:10:50 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 84C3C231C1 for ; Mon, 7 Jan 2019 08:10:49 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Mon, 07 Jan 2019 08:10:49 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:subject:content-type; s=fm1; bh=+9NlKyX+YlBXni4DWZv1qdFItUfs yhRIB6UaN/7E9dI=; b=vYGSNK3wcs7X6xF+NjEU/aQv7UczSdCeBgDjqMsGO9Hl N+4wlR/TC8h3gKsKGrrnrU7TttEmh+JPzV9E6d78vSNs8LAgrvMuXqhZ/461/jIc taDBClXFy0hL5GTiEnLt/b/PCiRo1oG5032JHDVFGzIfcXlXCLJOnGLXf6qDWDP/ ZEwb/nITlqNA5NTzVNM2G6lgJfsmIHd/g33s5EO2lxSI6JvaAvRG5Jy5ka39u/0+ +flWU/jc2xv0L6xf+kuZ99Tpfmi3zcOKFz8kOIYJMYGRMlZvUX6Lz9PW7JTyBdwA OP5cek0XR8nyQW9HMvz9w8WcXJIaJ8bLbl6Y/a0/Gw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=+9NlKyX+YlBXni4DW Zv1qdFItUfsyhRIB6UaN/7E9dI=; b=SqFt1IFzxTMve1IrxEkad5alMvKt6nxo7 Satogdfp7T7Imi1rqk2E6cakjDKn+fWGUzQrIJHSvSg80lg73YuTaB4vRrP3Yy77 NgipwYmRHADwfJIyXEY5jp5IaFC81SAJ0MOuVSRbqhtVeG0YKQPrOnY0bIM9fV1l Dhifnd4zbYJ+59Y7P/8I744TD+PBr287bLr0a2Aw2gf3q8Ol5scvGJXpgE/vIZri 4/ysGd84fvcm5A9P2da7uhCvtVu4XwL8TNZFqDufDnX9OoHyDk64zaN4GeySYJ33 vIlvrg9cOXY2uZbtId3IcEow28XJzg2YvR5U92K73sthS/QiVXygw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrvdejgdegkeculddtuddrgedtkedrtddtmd cutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgfkjghffffhvffutgesrgdtre erreertdenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehf rghsthhmrghilhhtvggrmhdrtghomheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrh honhhgsehfrghsthhmrghilhhtvggrmhdrtghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id CE9E2203BE; Mon, 7 Jan 2019 08:10:48 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-739-g7452a1e-fmstable-20190103v1 X-Me-Personality: 56629417 Message-Id: <9ac0aca4-9993-47c5-8a05-524c6e19d844@www.fastmail.com> In-Reply-To: References: <154651703823.29557.748556981627156046@ietfa.amsl.com> <01R1M7QIBP9I00004R@mauve.mrochek.com> Date: Mon, 07 Jan 2019 08:10:47 -0500 From: "Bron Gondwana" To: jmap@ietf.org Content-Type: multipart/alternative; boundary=ffcc97dfa3f347629ca33c341d31bc5f Archived-At: Subject: Re: [Jmap] Secdir last call review of draft-ietf-jmap-core-12 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2019 13:10:52 -0000 --ffcc97dfa3f347629ca33c341d31bc5f Content-Type: text/plain On Mon, Jan 7, 2019, at 23:25, Tony Finch wrote: > Ned Freed wrote: > > > > AFAICT it's different in the sense that this is the first push email > > notification mechanism we have standardized. > > What about RFC 2177 IMAP IDLE? To be fair - IMAP IDLE doesn't involve a third party passing a notification like JMAP push can (if it's configured using a third party channel, as we do via both Google and Apple in our implementation - when talking to clients on their platforms) Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --ffcc97dfa3f347629ca33c341d31bc5f Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Mon, Jan 7, 2019, at 23:25, Tony Finch wrote:
=
Ned Freed <ned.freed@mrochek.com> wrote:
>
> AFAICT it's different in the sense that this is the first push= email
> notification mech= anism we have standardized.
<= br>
What about RFC 2177 IMAP IDLE= ?

To be fair - IMAP IDLE doesn't involve a t= hird party passing a notification like JMAP push can (if it's configured= using a third party channel, as we do via both Google and Apple in our = implementation - when talking to clients on their platforms)

Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com


--ffcc97dfa3f347629ca33c341d31bc5f-- From nobody Mon Jan 7 05:18:06 2019 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 9614E130E90; Mon, 7 Jan 2019 05:18:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.421 X-Spam-Level: X-Spam-Status: No, score=-3.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779] 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 fpdoSxIE68DB; Mon, 7 Jan 2019 05:18:01 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 37CAB130E46; Mon, 7 Jan 2019 05:18:01 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id x07DHpjx010998 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 7 Jan 2019 15:17:51 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x07DHp4c022960; Mon, 7 Jan 2019 15:17:51 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23603.20862.976183.378013@fireball.acr.fi> Date: Mon, 7 Jan 2019 15:17:50 +0200 From: Tero Kivinen To: "Neil Jenkins" Cc: secdir@ietf.org, "Bron Gondwana" , "IETF JMAP Mailing List" , draft-ietf-jmap-core.all@ietf.org, ietf@ietf.org In-Reply-To: <7beebd38-7999-4a49-b892-c3c75b36eab4@beta.fastmail.com> References: <154651703823.29557.748556981627156046@ietfa.amsl.com> <7beebd38-7999-4a49-b892-c3c75b36eab4@beta.fastmail.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 89 min X-Total-Time: 25 min Archived-At: Subject: Re: [Jmap] Secdir last call review of draft-ietf-jmap-core-12 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2019 13:18:05 -0000 Neil Jenkins writes: > On Sun, 6 Jan 2019, at 9:26 AM, Bron Gondwana wrote: > > And look at making the push protocol have a confirmation step: > https://github.com/jmapio/jmap/issues/276 > > I'm not convinced this is necessary and/or helpful. In the current system, the > first time a push is triggered the application (JMAP) server sends a request to > the push server (the URL registered by the client); if this is not accepted > with a reasonable HTTP response, it would automatically disable it. The danger > is meant to be DOSing this URL (it's not really a push server); however with a > confirmation step, you still need to do that first request so you're not > reducing the number of HTTP requests. You are however relying on the push being > received by the client in order for it to be able to complete registration, and > all common push services do not guarantee delivery, so this becomes much less > reliable. (With this in mind, the JMAP push system happily copes with dropped > push packets while still guaranteeing full resynchronisation.) Actually I think adding confirmation step will make the push notifications more reliable, as that will give you positive feedback that your push notifications do work. It is really annoying trying to debug which firewall / proxy / encryption is causing the notification to be blocked, if I need to reregister again for every time and need to then somehow still cause one push notification to be sent before I can see does it work. > I note this issue doesn't really seem to be specific to JMAP, and yet RFC8030 > (which is what the push system is implementing) does not require a confirmation > step. My understanding is that RFC8030 does not connect random urls, the push notifications are received by client doing GET request to the subscription server and then later server using server push to that connection or something like that (in section 6 of the RFC8030). Usually that is only way things can work, as most of the people are behind firewalls / NATs / Proxies etc, thus connecting to them from outside is impossible or hard. The interaction between UA and the Application server is using "an application-specific method" which is not described in the RFC8030: An application-specific method is used to distribute the push URI to the application server. Confidentiality protection and application server authentication MUST be used to ensure that this URI is not disclosed to unauthorized recipients (Section 8.3). The verification would be inside this application-specific method, thus it is not covered in the 8030 because of that. In Jmap case the URL can be anything in the network and server is assumed to connect to that URL every time something happens. Yes, if something goes wrong in that url then notifications are disabled, but if server just answers HTTP ok 200 back, and JMAP server will be happy to keep sending notifications. With verification step the amplification factor would be around 1, as attacker does subscription registration (small packet), JMAP server sends first notification indication subscription is registed to given url (small packet), and when JMAP server does not get confirmation back from the attacker (which most likely cannot see the notifications), then it will delete subscription. Attacker can also do 10000 subscriptions to same victim (perhaps using different URLs, but destioned to same victim). It can do this overnight, and then on the morning when someone triggers event the victim will suddenly receive 10000 event notifications (https-connections) from the well connected JMAP server farm, and will be completely swamped before it can even respond to any errors to those notifications. -- kivinen@iki.fi From nobody Mon Jan 7 05:22:53 2019 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 D265A130E46 for ; Mon, 7 Jan 2019 05:22:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.421 X-Spam-Level: X-Spam-Status: No, score=-3.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779] autolearn=unavailable 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 IJx4bZ7ap9i7 for ; Mon, 7 Jan 2019 05:22:45 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 5C9C0130E8D for ; Mon, 7 Jan 2019 05:22:45 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id x07DMehU002280 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 7 Jan 2019 15:22:40 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x07DMeBW003930; Mon, 7 Jan 2019 15:22:40 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <23603.21152.388621.403480@fireball.acr.fi> Date: Mon, 7 Jan 2019 15:22:40 +0200 From: Tero Kivinen To: Barry Leiba Cc: Benjamin Kaduk , IETF JMAP Mailing List , "Kurt Andersen \(IETF\)" , draft-ietf-jmap-core.all@ietf.org, iesg@ietf.org, secdir@ietf.org In-Reply-To: References: <154651703823.29557.748556981627156046@ietfa.amsl.com> <20190105185050.GB28515@kduck.kaduk.org> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 26 min X-Total-Time: 4 min Archived-At: Subject: Re: [Jmap] [secdir] Secdir last call review of draft-ietf-jmap-core-12 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2019 13:22:47 -0000 Barry Leiba writes: > I agree with Ben that when documentation has been lacking in the past= we may > need to fix that in current documents.=C2=A0 The problem, I fear, is = that we write > much of this, especially at the app layer, to the wrong readers, so l= et=E2=80=99s think > about the shared mailbox case, for example, and see if we know what w= ill > actually help, rather than tick off some IETF-process-related box. >=20 > What we write in RFCs is primarily for software developers.=C2=A0 It = would be truly > bad if security/privacy warnings dissuaded developers from supporting= shared > mailboxes: any mail system that lacks such support would be hobbled a= nd bad. >=20 > So the best we could try would be to get vendors to copy or paraphras= e our > warnings in their documents, and/or to show warnings when the feature= s are > configured at installation.=C2=A0 I think it=E2=80=99s unlikely to ha= ppen.=C2=A0 Similarly, when > a user shares a mailbox a popup could show... also unlikely. >=20 > And what are we going to say=3F=C2=A0 That sharing a mailbox that con= tains personal > mail can expose private information=3F=C2=A0 That=E2=80=99s at the sa= me time so obvious as to > be silly, and entirely irrelevant to the actual shared-mailbox use ca= ses. >=20 > I think the best approach is to give examples of common use cases for= sharing.=C2=A0 > That might be informative and might actually prompt some vendors to i= nclude > similar examples in their doc. There is already huge difference in sharing mail and sharing calendars. Most of the calendars support easy way of sharing only limited set of data, i.e., you can mark entries as private where those will not be shared out, or will be shared out only as "busy", i.e., you can only see person is not available but not what calendar entry is. In mailboxes we do not have that kind of features. One thing we could suggest to implementors to allow sharing subfolders of the actual account instead of full mailbox, i.e., allow filtering rules to mark emails to specific folders, and only share those folders. I.e., create rules that puts all emails with specific keywords / or from specific users etc to subfolder and share this. This would allow solving some of the privacy issues when sharing mailboxes. The same privacy issues are mostly already solved for calendar, but not at all for mail... So if we provide such examples and features in our protocols, perhaps the implementors would implement them, and perhaps then we can actually make people to get some privacy... --=20 kivinen@iki.fi From nobody Mon Jan 7 06:12:52 2019 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 E85CF130EA1 for ; Mon, 7 Jan 2019 06:12:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 8H7UUPk6YoQT for ; Mon, 7 Jan 2019 06:12:47 -0800 (PST) Received: from ppsw-31.csi.cam.ac.uk (ppsw-31.csi.cam.ac.uk [131.111.8.131]) (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 BC145124BE5 for ; Mon, 7 Jan 2019 06:12:47 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:38344) by ppsw-31.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.137]:25) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1ggVe1-000akj-Li (Exim 4.91) (return-path ); Mon, 07 Jan 2019 14:12:45 +0000 Date: Mon, 7 Jan 2019 14:12:45 +0000 From: Tony Finch To: Bron Gondwana cc: jmap@ietf.org In-Reply-To: <9ac0aca4-9993-47c5-8a05-524c6e19d844@www.fastmail.com> Message-ID: References: <154651703823.29557.748556981627156046@ietfa.amsl.com> <01R1M7QIBP9I00004R@mauve.mrochek.com> <9ac0aca4-9993-47c5-8a05-524c6e19d844@www.fastmail.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Jmap] Secdir last call review of draft-ietf-jmap-core-12 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2019 14:12:50 -0000 Bron Gondwana wrote: > On Mon, Jan 7, 2019, at 23:25, Tony Finch wrote: > > Ned Freed wrote: > > > > > > AFAICT it's different in the sense that this is the first push email > > > notification mechanism we have standardized. > > > > What about RFC 2177 IMAP IDLE? > > To be fair - IMAP IDLE doesn't involve a third party passing a > notification like JMAP push can Ah, yes, that is an important difference :-) Tony. -- f.anthony.n.finch http://dotat.at/ Southeast Fitzroy: Northeasterly 5 to 7. Moderate or rough. Fair. Good. From nobody Mon Jan 7 08:57:55 2019 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 AB9A0130F61; Mon, 7 Jan 2019 08:57:45 -0800 (PST) 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, 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 7DlhREjP8Y8S; Mon, 7 Jan 2019 08:57:44 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.218.59.24]) (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 F2C86130F4D; Mon, 7 Jan 2019 08:57:43 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01R1Q3OCHS8000CGN6@mauve.mrochek.com>; Mon, 7 Jan 2019 08:52:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1546879959; bh=O47qt/JpRE5dpigGQmc6Fub8funuTwzLroQn+ERfi3k=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=Kx/ezKI2hTaHnkWKIZ1OfY4ov0aB5DSBbgrLTZrCpyzUtd3oR4FdN0/bZ7Oa2jKJ5 r1Di8IPu01R+WNyBCFzTO9r+DAKHT0m+9CYxUn9xBvT4nLeo8K/TMIaXJisF7ptYts luHWgsuYCBRhK4fcrHFCwquGV8GnNF55gxUL6ZYA= 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 <01R1N39ADWKW00004L@mauve.mrochek.com>; Mon, 7 Jan 2019 08:52:32 -0800 (PST) Cc: Ned Freed , "Kurt Andersen (IETF)" , IETF JMAP Mailing List , draft-ietf-jmap-core.all@ietf.org, Tero Kivinen , secdir@ietf.org Message-id: <01R1Q3OA5O7800004L@mauve.mrochek.com> Date: Mon, 07 Jan 2019 08:43:59 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Mon, 07 Jan 2019 12:24:52 +0000" References: <154651703823.29557.748556981627156046@ietfa.amsl.com> <01R1M7QIBP9I00004R@mauve.mrochek.com> To: Tony Finch Archived-At: Subject: Re: [Jmap] Secdir last call review of draft-ietf-jmap-core-12 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2019 16:57:46 -0000 > Ned Freed wrote: > > > > AFAICT it's different in the sense that this is the first push email > > notification mechanism we have standardized. > What about RFC 2177 IMAP IDLE? IDLE is an odd mix of pull and push. I don't think it really meets the criteria for a pure push mechanism, although on futher consideration I suppose with some persistance and careful observation of multiple IMAP streams you could perform this sort of traffic analysis on it. That said, the fact that the security considerations section in RFC 2177 says in its entirety: There are no known security issues with this extension. is pretty disturbing regardless. At a minimum an IDLE stream leaks information about a particular mailbox's activity, even when uncorrelated with incoming messages. Ned From nobody Mon Jan 7 15:46:58 2019 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 EFD7712008A; Mon, 7 Jan 2019 15:46:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 T_jeNkXYZJqc; Mon, 7 Jan 2019 15:46:48 -0800 (PST) Received: from mail-it1-f182.google.com (mail-it1-f182.google.com [209.85.166.182]) (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 97413124408; Mon, 7 Jan 2019 15:46:48 -0800 (PST) Received: by mail-it1-f182.google.com with SMTP id i145so3797290ita.4; Mon, 07 Jan 2019 15:46:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VXjr4S+tIR7RyNjfIppAlE1Nw8gJi9rLPZrAyGgcJX8=; b=STOloBCi1Ycyv33UTq0qINVbWeU+/zqwpmT/1jUjFqGHDJEBtcFdZmn4DPtSph2vY2 XRAFXSrz/Z2V5A2NXYA+aQgnrbrFBWqYOULwh/USXjM1D7NpwZs2JstkoL+7bddGnp9j AnaZ28e5iqNp4BfVNDXS+gQ5gJ1Ui12R3g0rbCTx64CxmcLoHG2u1MMquQwGkCBfJNa4 K54DleUbh3zx4oGXTv2GxIwSNuELb0npSsMRJh/mrBgoSR6j9NTJU42UlaPwbxOISpD/ SUvP2PwDT/vzJOxqaOXtxKifSfNRPd9myokEc7/5lrNvllY0Z4Q3OddIiJNl82GhpV8/ ZuEA== X-Gm-Message-State: AJcUukcf9INsRNltY6XVjb8Hmz2o0IjkFpD9HHE01mgXAzHwDigVAZ5x GnPFrI3UxHfG/x82ZLOMisbAUWMDHv0+m9gm1/8= X-Google-Smtp-Source: ALg8bN61Uf7w4fd3vFHraGIfI42dqdeWymqPpTDfeJMx3G4pnqluhJ7Ygx3vTXp9iOsw+RUXtvYye/9z/xeu9ZLb0vw= X-Received: by 2002:a24:dd8d:: with SMTP id t135mr8175177itf.84.1546904807539; Mon, 07 Jan 2019 15:46:47 -0800 (PST) MIME-Version: 1.0 References: <154651703823.29557.748556981627156046@ietfa.amsl.com> <01R1M7QIBP9I00004R@mauve.mrochek.com> <01R1Q3OA5O7800004L@mauve.mrochek.com> In-Reply-To: <01R1Q3OA5O7800004L@mauve.mrochek.com> From: Barry Leiba Date: Tue, 8 Jan 2019 07:46:36 +0800 Message-ID: To: Ned Freed Cc: IETF JMAP Mailing List , "Kurt Andersen (IETF)" , Tero Kivinen , Tony Finch , draft-ietf-jmap-core.all@ietf.org, secdir@ietf.org Content-Type: multipart/alternative; boundary="0000000000008e07f0057ee6d79c" Archived-At: Subject: Re: [Jmap] Secdir last call review of draft-ietf-jmap-core-12 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2019 23:46:51 -0000 --0000000000008e07f0057ee6d79c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hm. I don=E2=80=99t see that. All you get in response to the IDLE command= is the same stuff you get from the NOOP command or from any other IMAP command: untagged FETCH and EXPUNGE responses. Technically, they=E2=80=99re not act= ually responses to the command: they=E2=80=99re unsolicited messages in the IMAP = protocol. What security considerations should there be for IDLE that are beyond those for NOOP (that is, IMAP itself? Barry On Tue, Jan 8, 2019 at 12:58 AM Ned Freed wrote: > > Ned Freed wrote: > > > > > > AFAICT it's different in the sense that this is the first push email > > > notification mechanism we have standardized. > > > What about RFC 2177 IMAP IDLE? > > IDLE is an odd mix of pull and push. I don't think it really meets the > criteria > for a pure push mechanism, although on futher consideration I suppose wit= h > some > persistance and careful observation of multiple IMAP streams you could > perform > this sort of traffic analysis on it. > > That said, the fact that the security considerations section in RFC 2177 > says in its entirety: > > There are no known security issues with this extension. > > is pretty disturbing regardless. At a minimum an IDLE stream leaks > information > about a particular mailbox's activity, even when uncorrelated with incomi= ng > messages. > > Ned > --0000000000008e07f0057ee6d79c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hm.=C2=A0 I don=E2=80=99t see that.=C2=A0 All you ge= t in response to the IDLE command is the same stuff you get from the NOOP c= ommand or from any other IMAP command: untagged FETCH and EXPUNGE responses= .=C2=A0 Technically, they=E2=80=99re not actually responses to the command:= they=E2=80=99re unsolicited messages in the IMAP protocol.

What security considerations should t= here be for IDLE that are beyond those for NOOP (that is, IMAP itself?

Barry

On Tue, Jan 8, 2019 at 12:58 AM N= ed Freed <ned.freed@mrochek.com= > wrote:
> Ned Freed <= ned.freed@mroche= k.com> wrote:
> >
> > AFAICT it's different in the sense that this is the first pus= h email
> > notification mechanism we have standardized.

> What about RFC 2177 IMAP IDLE?

IDLE is an odd mix of pull and push. I don't think it really meets the = criteria
for a pure push mechanism, although on futher consideration I suppose with = some
persistance and careful observation of multiple IMAP streams you could perf= orm
this sort of traffic analysis on it.

That said, the fact that the security considerations section in RFC 2177 says in its entirety:

=C2=A0 There are no known security issues with this extension.

is pretty disturbing regardless. At a minimum an IDLE stream leaks informat= ion
about a particular mailbox's activity, even when uncorrelated with inco= ming
messages.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Ned
--0000000000008e07f0057ee6d79c-- From nobody Mon Jan 7 18:30:26 2019 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 F364C130EA8; Mon, 7 Jan 2019 18:30:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 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_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, 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=fastmailteam.com header.b=wt8WQvpN; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=L5rWvRS9 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 uJ3VSUumH6Oy; Mon, 7 Jan 2019 18:30:11 -0800 (PST) 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 EDB0D130EA3; Mon, 7 Jan 2019 18:30:10 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 8A4D124537; Mon, 7 Jan 2019 21:30:09 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Mon, 07 Jan 2019 21:30:09 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:cc:subject:content-type; s=fm1; bh=hBmqAZEWT4x1NqB554GwLTo2o c0z4YvHBuLTf3vqLyU=; b=wt8WQvpN5CNhDbKsyYLbwvFyaX1wzrl+N+4YQQfIG /dYGtj1gnd3RaraL3c5TqV+g4vLLP5LH0o2SSGs8U4iJ1520cWxrYhLqAg+zHkQK WLYDyPnibe8ZMSB2R6AH6lHhE07FlhCFkEuirhMInIUOlu9TvTDZLW3ZfduNAFXb xd+NogF7ADXavL/fVM9q/9ZUMvIc3YGqZ/RySRuXdJ1mMUuEZVVxRLLoDei3wrPS ffL6fRH1QcbQjN+G7RDit4fF8KTigH1vsSHVtx2WP5kaKPxnn6cTw39xlcpxNgaI 8WvVKxoMxi9n1wc0VIDp0UAQyhMGHNC7TNT5rTtgtUY8A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=hBmqAZEWT4x1NqB55 4GwLTo2oc0z4YvHBuLTf3vqLyU=; b=L5rWvRS9NAUFEi6qFlDpC+v48mg53NSop NW39Y+/a04emD3Au03o9V6TT0d5S5IklQ9MclnnP++Omn38Oon3Ovz+TZe4Lzj9r 8F1+qEfUspNeNJTn2OaAOOnsdJxIcWmgAXJfeGKlnL0tGxJjRbcXaNCg/kDfy59k 2w5olju3RH3XTAu2Ud+dqis5d9vHD+9hzSkPBZsaAg7rRpRdZPFvKi6De+Uloc8Z ALRLulfBMKTBv/SFMXk4WnJni267UJAhLXiDl86b5x5q+VKkfjMupIgdn8VuKQTF m8lGXEB1I+E0i9oHzp+8VXolPJpt6b6RVhZMr33OjkBFih5OcFDlw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrvdekgdegleculddtuddrgedtkedrtddtmd cutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne goufhushhpvggtthffohhmrghinhculdegledmnecujfgurhepofgfkfgjfhffhffvufgt segrtderreerreejnecuhfhrohhmpedfpfgvihhlucflvghnkhhinhhsfdcuoehnvghilh hjsehfrghsthhmrghilhhtvggrmhdrtghomheqnecuffhomhgrihhnpehgihhthhhusgdr ihhonecurfgrrhgrmhepmhgrihhlfhhrohhmpehnvghilhhjsehfrghsthhmrghilhhtvg grmhdrtghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id A5D6F203BE; Mon, 7 Jan 2019 21:30:08 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-739-g7452a1e-fmstable-20190103v1 X-Me-Personality: 64588216 Message-Id: In-Reply-To: <23603.20862.976183.378013@fireball.acr.fi> References: <154651703823.29557.748556981627156046@ietfa.amsl.com> <7beebd38-7999-4a49-b892-c3c75b36eab4@beta.fastmail.com> <23603.20862.976183.378013@fireball.acr.fi> Date: Mon, 07 Jan 2019 21:30:07 -0500 From: "Neil Jenkins" To: "Tero Kivinen" Cc: secdir@ietf.org, "Bron Gondwana" , "IETF JMAP Mailing List" , draft-ietf-jmap-core.all@ietf.org, ietf@ietf.org Content-Type: multipart/alternative; boundary=9ebb9715cf3f4a36b4e65b8b9eecb72d Archived-At: Subject: Re: [Jmap] Secdir last call review of draft-ietf-jmap-core-12 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2019 02:30:13 -0000 --9ebb9715cf3f4a36b4e65b8b9eecb72d Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Tue, 8 Jan 2019, at 12:17 AM, Tero Kivinen wrote: > Actually I think adding confirmation step will make the push > notifications more reliable, as that will give you positive feedback > that your push notifications do work. The issue is that push services (e.g. Apple's APNS and Google's FCM) do = not guarantee that any particular push will be received. They normally w= ill, but may not, especially if the device goes offline for a while. So = if your first push doesn't make it through your push never works. It's l= ikely to be rare, but painful when it happens and makes it feel unreliab= le. > It is really annoying trying to debug which firewall / proxy / encrypt= ion is causing the notification to be blocked, if I need to reregister a= gain for every time and need to then somehow still cause one push notifi= cation to be sent before I can see does it work.=20 I'm not sure what you're referring to here. Do you mean the JMAP (applic= ation) server connecting to the push server? Or the push server connecti= ng to the client (which is not part of JMAP at all, but where you're mor= e likely to run into issues with corporate firewalls and the like)? > My understanding is that RFC8030 does not connect random urls, My understanding is that is incorrect. There are three entities involved= in an 8030 push system, and JMAP is only involved with two of them: * The client, which wants to receive the push notifications (the JMAP c= lient) * The application server which contains the data and wants to send the = push notifications (the JMAP server)=20 * The push server (3rd party, depends on the device what is possible) The situation of the client/application server being one entity and the = push server being a completely unrelated entity is what 8030 is designed= for. For example, each browser implements the Push API , whereby if you have a web app you can ask the browser= for a push subscription endpoint, then send it to your application serv= er to connect to. The application server does not know in advance which = browser the user has or what domains that browser currently uses for pus= h subscriptions. It simply gets given an arbitrary URL to post to.=20 JMAP is not defining anything new here. It is just defining the applicat= ion server portion exactly as expected by RFC8030. > the push notifications are received by client doing GET request to the= > subscription server and then later server using server push to that > connection or something like that (in section 6 of the RFC8030). > Usually that is only way things can work, as most of the people are > behind firewalls / NATs / Proxies etc, thus connecting to them from > outside is impossible or hard. Yes, this is how the client receives the data from the push server in RF= C8030. This is entirely orthogonal to what we are discussing though. > The interaction between UA and the Application server is using > "an application-specific method" =E2=80=A6 > The verification would be inside this application-specific method, > thus it is not covered in the 8030 because of that. Hmm, yes I see your point, although it seems odd for it not to mention a= t all given this is going to apply to pretty much every app that uses th= is system; not specifically JMAP. > but if server just answers HTTP ok 200 back, and JMAP server will be > happy to keep sending notifications. Yes, this is indeed a risk, and I agree that a confirmation step would b= e the only way to mitigate this. > Attacker can also do 10000 subscriptions to same victim (perhaps using= > different URLs, but destioned to same victim). It can do this > overnight, and then on the morning when someone triggers event the > victim will suddenly receive 10000 event notifications > (https-connections) from the well connected JMAP server farm, and will= > be completely swamped before it can even respond to any errors to > those notifications. I would expect the JMAP server to rate limit the number of push subscrip= tions any one user may have to something considerably lower than that. I= f the attacker had compromised many accounts on the JMAP server though, = it could set up push subscriptions with each of them but then it would h= ave to coordinate making a change in each of those accounts at the same = time in order to flood the target server with a large single burst of re= quests, which is a much harder thing to do. Summing up, I think that adding a confirmation step removes a small risk= of being able to use a JMAP application server as a DDOS vector, but ad= ds a small risk of the push not being received and the push system faili= ng to establish. (Although, the client would at least know this was the = case so could alert the user and give them the option to try again.) Wou= ld anyone else like to weigh in on the relative merits of the options he= re to help come to a consensus on the way forward? I would be particular= ly interested to hear if this was discussed at all, and any conclusions = reached, in the development of RFC8030. Neil. --9ebb9715cf3f4a36b4e65b8b9eecb72d Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Tue, 8 = Jan 2019, at 12:17 AM, Tero Kivinen wrote:
Actually I think adding confirmation s= tep will make the push
notifications more reliable, as tha= t will give you positive feedback
that your push notificat= ions do work.

The issue is tha= t push services (e.g. Apple's APNS and Google's FCM) do not guarantee th= at any particular push will be received. They normally will, but may not= , especially if the device goes offline for a while. So if your first pu= sh doesn't make it through your push never works. It's likely to be rare= , but painful when it happens and makes it feel unreliable.

It is = really annoying trying to debug which firewall / proxy / encryption is c= ausing the notification to be blocked, if I need to reregister again for= every time and need to then somehow still cause one push notification t= o be sent before I can see does it work. 

I'm not sure what you're referring to here. Do you mean= the JMAP (application) server connecting to the push server? Or the pus= h server connecting to the client (which is not part of JMAP at all, but= where you're more likely to run into issues with corporate firewalls an= d the like)?

My understanding is that RFC8030 does not connect ran= dom urls,

My understanding is = that is incorrect. There are three entities involved in an 8030 push sys= tem, and JMAP is only involved with two of them:

  • The client, which wants to receive the push notifications (the = JMAP client)
  • The application server which contains the data = and wants to send the push notifications (the JMAP server) 
  • The push server (3rd party, depends on the device what is possible)=

The situation of the client/applicatio= n server being one entity and the push server being a completely unrelat= ed entity is what 8030 is designed for. For example, each browser implem= ents the Push API, where= by if you have a web app you can ask the browser for a push subscription= endpoint, then send it to your application server to connect to. The ap= plication server does not know in advance which browser the user has or = what domains that browser currently uses for push subscriptions. It simp= ly gets given an arbitrary URL to post to.

JMAP is not defining anything new here. It is just defining the applica= tion server portion exactly as expected by RFC8030.

the push notif= ications are received by client doing GET request to the
s= ubscription server and then later server using server push to that
connection or something like that (in section 6 of the RFC8030)= .
Usually that is only way things can work, as most of the= people are
behind firewalls / NATs / Proxies etc, thus co= nnecting to them from
outside is impossible or hard.

Yes, this is how the client receive= s the data from the push server in RFC8030. This is entirely orthogonal = to what we are discussing though.

The interaction between UA and t= he Application server is using
"an application-specific me= thod" =E2=80=A6
The verification would be inside this application-spe= cific method,
thus it is not covered in the 8030 because o= f that.

Hmm, yes I see your po= int, although it seems odd for it not to mention at all given this is go= ing to apply to pretty much every app that uses this system; not specifi= cally JMAP.

but if server just answers HTTP ok 200 back, and JMAP = server will be
happy to keep sending notifications.

Yes, this is indeed a risk, and I ag= ree that a confirmation step would be the only way to mitigate this.
=

Attacker can also do 10000 subscriptions to same victim (perhaps usin= g
different URLs, but destioned to same victim). It can do= this
overnight, and then on the morning when someone trig= gers event the
victim will suddenly receive 10000 event no= tifications
(https-connections) from the well connected JM= AP server farm, and will
be completely swamped before it c= an even respond to any errors to
those notifications.
<= /div>

I would expect the JMAP server to = rate limit the number of push subscriptions any one user may have to som= ething considerably lower than that. If the attacker had compromised man= y accounts on the JMAP server though, it could set up push subscriptions= with each of them but then it would have to coordinate making a change = in each of those accounts at the same time in order to flood the target = server with a large single burst of requests, which is a much harder thi= ng to do.

Summing up, I think that adding a= confirmation step removes a small risk of being able to use a JMAP appl= ication server as a DDOS vector, but adds a small risk of the push not b= eing received and the push system failing to establish. (Although, the c= lient would at least know this was the case so could alert the user and = give them the option to try again.) Would anyone else like to weigh in o= n the relative merits of the options here to help come to a consensus on= the way forward? I would be particularly interested to hear if this was= discussed at all, and any conclusions reached, in the development of RF= C8030.

Neil.
--9ebb9715cf3f4a36b4e65b8b9eecb72d-- From nobody Mon Jan 7 18:52:55 2019 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 86BD2130E76; Mon, 7 Jan 2019 18:52:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 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_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, 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=fastmailteam.com header.b=TAl0w3Mk; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=GuivZxBf 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 22ctcsTmRfyY; Mon, 7 Jan 2019 18:52:52 -0800 (PST) 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 57D8212D4EB; Mon, 7 Jan 2019 18:52:52 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 17CC422075; Mon, 7 Jan 2019 21:52:51 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Mon, 07 Jan 2019 21:52:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:cc:subject:content-type; s=fm1; bh=HL4BTD2SkBjgXcL7t7ukDcUKv wF2DsDxizyTIpzuHq0=; b=TAl0w3Mk9GOTBLTs4hLxgrZc4xoRR8kHChdg80i6u JZ+pke6qzBDTbQNMLrT1wM5gDRErqgwUdb4/G8DK9nGlecwe3ZibOtAC5LJL2AE4 +5dD2+S3LGjuvYuxJa+q20a8Qb2FeSyclWwd+e2zrzdmn1XMVv2wIqeFaEgeMqAf Q5+M2kxXP9ebcvf6my6oEv4nrwJduPeBrVC8MnLRT9t8hmDRS/BuWzB/xCMTrexO J9fRnoBRPUc9Koyzt3gbIfuzDUZ3V2ZE88xO6pCQF4QmFoHYyf0Rk83MnwIsonSd iEezp08qIlgYioZuxYukdxW5ZlrtPTtR6tOtXepi9LeLw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=HL4BTD2SkBjgXcL7t 7ukDcUKvwF2DsDxizyTIpzuHq0=; b=GuivZxBfoDUOgdATqgbeMZ0ac12c/XW+j 60h/SqREKkQdi27aU/6QR1jEabhLHZi4c+aPOqtuT6azZf5Yv7F+ebi4Eo9eq8/o loYiOBBavo9zprjQXIyy0fsWS8U3XrqXg+x08E2sjmI8JboNjZChaSh2Xv1jHJxQ 6eVyNsSldstK6uxma2k5NnkyJj2V1QZIMM8kGrfmKYVni3OcXyBUIEv7wXxJjrp/ f/6kECkDnPkYnbYupbHHasePrjS+arThc8/1u/LBbXDYfBaFoeHcEOXBgT3xHYZp xxWexkfdGggAA3hT68vmMB7Vud+oBCBZd/w6Al6SnPmI5usZ6tU/g== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrvdekgdehgeculddtuddrgedtkedrtddtmd cutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfkfgjfhffhffvufgtsegrtderreerreejnecuhfhrohhmpedfuehrohhn ucfiohhnugifrghnrgdfuceosghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhmqe enucfrrghrrghmpehmrghilhhfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrghm rdgtohhmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 3DDC1203BE; Mon, 7 Jan 2019 21:52:50 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-739-g7452a1e-fmstable-20190103v1 X-Me-Personality: 56629417 Message-Id: In-Reply-To: <23603.21152.388621.403480@fireball.acr.fi> References: <154651703823.29557.748556981627156046@ietfa.amsl.com> <20190105185050.GB28515@kduck.kaduk.org> <23603.21152.388621.403480@fireball.acr.fi> Date: Mon, 07 Jan 2019 21:52:48 -0500 From: "Bron Gondwana" To: "Barry Leiba" , "Tero Kivinen" Cc: "Benjamin Kaduk" , "IETF JMAP Mailing List" , "Kurt Andersen (IETF)" , draft-ietf-jmap-core.all@ietf.org, iesg@ietf.org, secdir@ietf.org Content-Type: multipart/alternative; boundary=f800bcbd89b2475e9e7a25f195986367 Archived-At: Subject: Re: [Jmap] [secdir] Secdir last call review of draft-ietf-jmap-core-12 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2019 02:52:53 -0000 --f800bcbd89b2475e9e7a25f195986367 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Tue, Jan 8, 2019, at 00:22, Tero Kivinen wrote: > Barry Leiba writes: > > I agree with Ben that when documentation has been lacking in the pas= t we may > > need to fix that in current documents. The problem, I fear, is that = we write > > much of this, especially at the app layer, to the wrong readers, so = let=E2=80=99s think > > about the shared mailbox case, for example, and see if we know what = will > > actually help, rather than tick off some IETF-process-related box. > >=20 > > What we write in RFCs is primarily for software developers. It would= be truly > > bad if security/privacy warnings dissuaded developers from supportin= g shared > > mailboxes: any mail system that lacks such support would be hobbled = and bad. > >=20 > > So the best we could try would be to get vendors to copy or paraphra= se our > > warnings in their documents, and/or to show warnings when the featur= es are > > configured at installation. I think it=E2=80=99s unlikely to happen.= Similarly, when > > a user shares a mailbox a popup could show... also unlikely. > >=20 > > And what are we going to say? That sharing a mailbox that contains p= ersonal > > mail can expose private information? That=E2=80=99s at the same time= so obvious as to > > be silly, and entirely irrelevant to the actual shared-mailbox use c= ases. > >=20 > > I think the best approach is to give examples of common use cases fo= r sharing.=20 > > That might be informative and might actually prompt some vendors to = include > > similar examples in their doc. >=20 > There is already huge difference in sharing mail and sharing > calendars. Most of the calendars support easy way of sharing only > limited set of data, i.e., you can mark entries as private where those= > will not be shared out, or will be shared out only as "busy", i.e., > you can only see person is not available but not what calendar entry > is. >=20 > In mailboxes we do not have that kind of features. One thing we could > suggest to implementors to allow sharing subfolders of the actual > account instead of full mailbox, i.e., allow filtering rules to mark > emails to specific folders, and only share those folders. I.e., create= > rules that puts all emails with specific keywords / or from specific > users etc to subfolder and share this. >=20 > This would allow solving some of the privacy issues when sharing > mailboxes. The same privacy issues are mostly already solved for > calendar, but not at all for mail... I feel like we're talking at cross purposes here. I'm not sure which mai= l services you've used before, but every mail services I've used with ma= il sharing allows you to share individual sub-mailboxes only. I've been = using JMAP in exactly that way, with individual notifications folders sh= ared to me from other accounts, and not the full contents of those accou= nts. > So if we provide such examples and features in our protocols, perhaps > the implementors would implement them, and perhaps then we can > actually make people to get some privacy... Sharing individual folder is precisely what RFC3501 specifies and RFC431= 4 expands on, and JMAP is duplicating that same pattern. I don't like th= e idea of changing the examples just because one reviewer has not person= ally experienced a use-case for a feature. I have never heard of a case = of people feeling that their privacy is negatively impacted by the fact = that there are ACLs on their mailboxes. A server could easily provide ba= ckdoor access into data WITHOUT telling users via the protocol, so as Ba= rry said - not having that ability just makes a less useful server, not = an increase in privacy. Regards, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --f800bcbd89b2475e9e7a25f195986367 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jan 8, 2019, at 00:22, Tero Kivinen wrote:
Barry Leiba writes:
> I agree with Ben that when documentation has been lacking in th= e past we may
> need to fi= x that in current documents.  The problem, I fear, is that we write=
> much of this, especiall= y at the app layer, to the wrong readers, so let=E2=80=99s think
> about the shared mailbox case, = for example, and see if we know what will
> actually help, rather than tick off some IETF-process-= related box.
> 
> What we write in RFCs is prim= arily for software developers.  It would be truly
> bad if security/privacy warnings dissuade= d developers from supporting shared
> mailboxes: any mail system that lacks such support would be = hobbled and bad.
> 
> So the best we could try = would be to get vendors to copy or paraphrase our
> warnings in their documents, and/or to show wa= rnings when the features are
= > configured at installation.  I think it=E2=80=99s unlikely to = happen.  Similarly, when
> a user shares a mailbox a popup could show... also unlikely.
> 
> And what are we going to say?  That sharin= g a mailbox that contains personal
> mail can expose private information?  That=E2=80=99s at = the same time so obvious as to
> be silly, and entirely irrelevant to the actual shared-mailbox us= e cases.
> 
=
> I think the best approach is to g= ive examples of common use cases for sharing. 
> That might be informative and might actually p= rompt some vendors to include
> similar examples in their doc.

There is already hug= e difference in sharing mail and sharing
calendars. Most of the calendars support easy way of sharing= only
limited set of data, i.= e., you can mark entries as private where those
will not be shared out, or will be shared out only as= "busy", i.e.,
you can only s= ee person is not available but not what calendar entry
is.

In mailboxes we do not have= that kind of features. One thing we could
suggest to implementors to allow sharing subfolders of the= actual
account instead of fu= ll mailbox, i.e., allow filtering rules to mark
emails to specific folders, and only share those fold= ers. I.e., create
rules that = puts all emails with specific keywords / or from specific
users etc to subfolder and share this.
<= /div>

This would allow solving some of the privacy issues when shar= ing
mailboxes. The same priva= cy issues are mostly already solved for
calendar, but not at all for mail...

I feel like we're talking at cross purposes here.  I'm not sure= which mail services you've used before, but every mail services I've us= ed with mail sharing allows you to share individual sub-mailboxes only.&= nbsp; I've been using JMAP in exactly that way, with individual notifica= tions folders shared to me from other accounts, and not the full content= s of those accounts.

So if we provide such examples and features in our protocol= s, perhaps
the implementors w= ould implement them, and perhaps then we can
actually make people to get some privacy...

Sharing individual folder is precisely what RFC3501 spec= ifies and RFC4314 expands on, and JMAP is duplicating that same pattern.=   I don't like the idea of changing the examples just because one r= eviewer has not personally experienced a use-case for a feature.  I= have never heard of a case of people feeling that their privacy is nega= tively impacted by the fact that there are ACLs on their mailboxes. = ; A server could easily provide backdoor access into data WITHOUT tellin= g users via the protocol, so as Barry said - not having that ability jus= t makes a less useful server, not an increase in privacy.

Regards,

Bron.
=

--
  Bron Go= ndwana, CEO, FastMail Pty Ltd
  b= rong@fastmailteam.com

=

--f800bcbd89b2475e9e7a25f195986367-- From nobody Mon Jan 7 18:54:50 2019 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 AF51F130E76; Mon, 7 Jan 2019 18:54:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 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_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=wdk5fro2; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ujouY7TQ 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 bQqRzuaehgBJ; Mon, 7 Jan 2019 18:54:34 -0800 (PST) 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 6C12712D4EB; Mon, 7 Jan 2019 18:54:34 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 5B91D22121; Mon, 7 Jan 2019 21:54:33 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Mon, 07 Jan 2019 21:54:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:cc:subject:content-type; s=fm1; bh=6b4RKDgrT+BoEsocznT42ngk1 fKjwJ/wLg30YLinRsc=; b=wdk5fro2cGhjvhtv4cHv3D25KJMlymVeDvAlRVoYE JFVPwXr19LuO12PlIOEIBo0diVD3Z8Lwc/+AyMklSzYMfJEuG/RhP1ZANRbiRuLh 8o+BELZOrO3JDQOFbfxXPwppiXxWXtTI7sUFT1I+F8Eo8Ic0T2Svs4KIArU7eDBF fuPIew5BthM7Xvx7IrkeN+oJ8xtQq3M2FiL8wJCFkmS9Ir0zuLVldUP4lXD1hmtn s3j9fAhyz5bNQMqd0OTe2ctZC6NmW9gNvSER3OQPk2j3lVuR+pAC27fdwpebe368 6lcNwfodyutnSZH6BWKqn3dHAuGO+RcC/JrryuaodxslA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=6b4RKDgrT+BoEsocz nT42ngk1fKjwJ/wLg30YLinRsc=; b=ujouY7TQECjMuCRmgGmTMkiFk+O1zD4Gy aFhTn4WzNrg1qjVPDuzsHYSDVTriSsVJ2sWWz+69WpWxF2WDlg8CHvggwbZNmnHQ 6rFI1OBkK1aqQdG52WRlaP1Pi0p+IPDtH/BZQofAyB9id7boc5gmcyUzKnYnlWfl JPuticx4z/kLhhFTGyrcNh/V83fXZXQo240Ncaf4eP7I+H+aMUok33gxk4cDXUFD 5BjRDZfqHPj+QJVdExrFBtWUAtyJbjcS/XolSVhC9WXf8LpRVTDwKxlNV5YKg+VW PHH1nP3DW/AbV3ECFmF52fz8hGbd0yH4faYf0gdogGoJHG29AHTEA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrvdekgdehgeculddtuddrgedtkedrtddtmd cutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfkfgjfhffhffvufgtsegrtderreerredtnecuhfhrohhmpedfpfgvihhl ucflvghnkhhinhhsfdcuoehnvghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomheqne curfgrrhgrmhepmhgrihhlfhhrohhmpehnvghilhhjsehfrghsthhmrghilhhtvggrmhdr tghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 0B6E6203BE; Mon, 7 Jan 2019 21:54:33 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-739-g7452a1e-fmstable-20190103v1 X-Me-Personality: 64588216 Message-Id: In-Reply-To: <23603.21152.388621.403480@fireball.acr.fi> References: <154651703823.29557.748556981627156046@ietfa.amsl.com> <20190105185050.GB28515@kduck.kaduk.org> <23603.21152.388621.403480@fireball.acr.fi> Date: Mon, 07 Jan 2019 21:54:32 -0500 From: "Neil Jenkins" To: "Barry Leiba" , "Tero Kivinen" Cc: "Benjamin Kaduk" , "IETF JMAP Mailing List" , "Kurt Andersen (IETF)" , draft-ietf-jmap-core.all@ietf.org, iesg , secdir@ietf.org Content-Type: multipart/alternative; boundary=bfdcece0f01540669854ff55535653f2 Archived-At: Subject: Re: [Jmap] [secdir] Secdir last call review of draft-ietf-jmap-core-12 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2019 02:54:36 -0000 --bfdcece0f01540669854ff55535653f2 Content-Type: text/plain On Tue, 8 Jan 2019, at 12:22 AM, Tero Kivinen wrote: > There is already huge difference in sharing mail and sharing > calendars. Most of the calendars support easy way of sharing only > limited set of data, i.e., you can mark entries as private where those > will not be shared out, or will be shared out only as "busy", i.e., > you can only see person is not available but not what calendar entry > is. > > In mailboxes we do not have that kind of features. One thing we could > suggest to implementors to allow sharing subfolders of the actual > account instead of full mailbox, Err, not sure what you're talking about here. Most email systems already support sharing on a per-folder (or *mailbox* as they're called in IMAP and JMAP) granularity. That's why JMAP and IMAP can return you a "myRights" object with your permissions for each mailbox. Calendars are identical; you generally share on a per-calendar basis (which acts the same as a mailbox for mail; a collection of individual data items). Neil. --bfdcece0f01540669854ff55535653f2 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Tue, 8 Jan 2= 019, at 12:22 AM, Tero Kivinen wrote:
There is already huge difference in sharing= mail and sharing
calendars. Most of the calendars support= easy way of sharing only
limited set of data, i.e., you c= an mark entries as private where those
will not be shared = out, or will be shared out only as "busy", i.e.,
you can o= nly see person is not available but not what calendar entry
is.

In mailboxes we do not have that kind= of features. One thing we could
suggest to implementors t= o allow sharing subfolders of the actual
account instead o= f full mailbox,

Err, not sure = what you're talking about here. Most email systems already support shari= ng on a per-folder (or mailbox as they're called in IMAP and JMAP= ) granularity. That's why JMAP and IMAP can return you a "myRights" obje= ct with your permissions for each mailbox. Calendars are identical; you = generally share on a per-calendar basis (which acts the same as a mailbo= x for mail; a collection of individual data items).

Neil.
--bfdcece0f01540669854ff55535653f2-- From nobody Mon Jan 7 19:42:52 2019 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 32E961310A6; Mon, 7 Jan 2019 19:42:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 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_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=wHowMhW3; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=gWB6JYDA 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 15JuApIsRbet; Mon, 7 Jan 2019 19:42:33 -0800 (PST) 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 8D66D1310A9; Mon, 7 Jan 2019 19:42:33 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 9EEDF24667; Mon, 7 Jan 2019 22:42:32 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Mon, 07 Jan 2019 22:42:32 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:cc:subject:content-type; s=fm1; bh=KGqT6qxaz7JMUM/+QKSHddOJ1 jCloi2BdoFe/V+stV8=; b=wHowMhW34C2izZ+tqkylnZDFCcsx1jLS9dYSeiwea ZN8IVv06iV8mwie0pI6Hqy9KLadcigw5x0kKwxt3aQGZMgEUsG5yCviZDghY4LQq E/8wgxAEWA8sGKQgGZFI7bWdtNQcLg0ZaqzZMCWowOnd2ZYRY4Z1mbnaSIaxjIvw e7Edw+T2vWrG7Y4na93tbSZ5tfEtm30MWFxrsL0ba0kI2Iv22heCgTomq23Gffdd YoxuYGHlj52NX8G6/c2+j7rqMwscQ8UQpzYm0NOgRt3eenQJ+C/+p9QN1UpwfHna OBFPKjm1TAflM9hBZ1DmMkNBr8VcPFEZGMr9LUXRumZiQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=KGqT6qxaz7JMUM/+Q KSHddOJ1jCloi2BdoFe/V+stV8=; b=gWB6JYDA53hw1FZbvMpjaKRupjHoE/tXU KhGb43NYsOWF4HDf/DQEeuCac+2SaI8alZ7WzyRRx93bzsGZeyozoj47Qup0wIID NmpgGg8YfQqkijhsV77M//8WONYWhEJFtYArOZbBDNB5l25UCFwESZ+OPjpqD0o7 BIA+TXlTKokKQ8TwAs5amVQzbr0pvlkRl3xxVzGboNKTi8SHsr/8z7Eaq0r7KT4S yvKkbHClz9YLzxFUrtTn6nwyKPv7JQHusvWgo80fLTXKmMn3Y4xDn8VkpzoIKd6a FRYXwZTbNFNCIc5i/Yly3/IlfUKYRzNNYQFhtQUlSyAspLpFMhgWQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrvdekgdeiheculddtuddrgedtkedrtddtmd cutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfkfgjfhffhffvufgtsegrtderreerreejnecuhfhrohhmpedfpfgvihhl ucflvghnkhhinhhsfdcuoehnvghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomheqne curfgrrhgrmhepmhgrihhlfhhrohhmpehnvghilhhjsehfrghsthhmrghilhhtvggrmhdr tghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 93B5F203BE; Mon, 7 Jan 2019 22:42:31 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-739-g7452a1e-fmstable-20190103v1 X-Me-Personality: 64588216 Message-Id: <77c37c56-a40a-4a52-95a0-553e63dc6a08@beta.fastmail.com> In-Reply-To: <01R1M7QIBP9I00004R@mauve.mrochek.com> References: <154651703823.29557.748556981627156046@ietfa.amsl.com> <01R1M7QIBP9I00004R@mauve.mrochek.com> Date: Mon, 07 Jan 2019 22:42:31 -0500 From: "Neil Jenkins" To: "Kurt Andersen (IETF)" , "Ned Freed" Cc: "Tero Kivinen" , "IETF JMAP Mailing List" , draft-ietf-jmap-core.all@ietf.org, secdir@ietf.org Content-Type: multipart/alternative; boundary=20b0ab2b3c2e4a4f907bd6c328212b8f Archived-At: Subject: Re: [Jmap] Secdir last call review of draft-ietf-jmap-core-12 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2019 03:42:35 -0000 --20b0ab2b3c2e4a4f907bd6c328212b8f Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Sat, 5 Jan 2019, at 9:10 AM, Ned Freed wrote: > I'll first note that although the JMAP specification refers to the IMA= P ACL > security model extensively, RFC 4314 is not in the references list. Th= at needs > to be fixed, Agreed, I have now added a reference to this. > and a note in the security considerations section saying that the > security considerations for IMAP ACLs apply to JMAP would also be good= . I've read through the security considerations section here and I don't a= ctually think any of them apply to JMAP; bear in mind the current spec d= oes not have any way to set ACLs, it just exposes the user's current rig= hts. (Setting ACLs is left to a future extension.) --- I have added the following section to the JMAP Core security considerati= ons: *8.8 Push traffic analysis* While the data is encrypted, a passive observer with the ability to moni= tor network traffic may be able to glean information from the timing of = push notifications. For example, suppose an email or calendar invitation= is sent from User A (hosted on Server X) to User B (hosted on Server Y)= . If Server X hosts data for many users, a passive observer can see that= the two servers connected but does not know who the data was for. Howev= er, if a push notification is immediately sent to User B and the attacke= r can observe this as well, they may reasonably conclude that someone on= Server X is connecting to User B. This can be partially mitigated by the JMAP server applying some random = jitter before sending out push notifications, however the jitter would h= ave to be small so as not to affect quality of service. This is also mit= igated inately on large services with high traffic flows hosting data fo= r many users, as it becomes much harder for an attacker to correlate inc= oming data events with outgoing push notifications, allowing users to =E2= =80=9Chide in the crowd=E2=80=9D. --- I await the conclusion on whether we should add a confirmation step to p= ush notifications, but other than that I don't believe there are any out= standing issues to address from this review. Please let me know if I've = missed something. Neil. --20b0ab2b3c2e4a4f907bd6c328212b8f Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Sat, 5 Jan 2= 019, at 9:10 AM, Ned Freed wrote:
I'll first note that although the JMAP specificat= ion refers to the IMAP ACL
security model extensively, RFC= 4314 is not in the references list. That needs
to be fixe= d,

Agreed, I have now added a = reference to this.

and a note in the security considerations sectio= n saying that the
security considerations for IMAP ACLs ap= ply to JMAP would also be good.

I've read through the security considerations section here and I don't= actually think any of them apply to JMAP; bear in mind the current spec= does not have any way to set ACLs, it just exposes the user's current r= ights. (Setting ACLs is left to a future extension.)

<= /div>
---

I have added the following se= ction to the JMAP Core security considerations:

=
8.8 Push traffic analysis

While= the data is encrypted, a passive observer with the ability to monitor n= etwork traffic may be able to glean information from the timing of push = notifications. For example, suppose an email or calendar invitation is s= ent from User A (hosted on Server X) to User B (hosted on Server Y). If = Server X hosts data for many users, a passive observer can see that the = two servers connected but does not know who the data was for. However, i= f a push notification is immediately sent to User B and the attacker can= observe this as well, they may reasonably conclude that someone on Serv= er X is connecting to User B.

This can be p= artially mitigated by the JMAP server applying some random jitter before= sending out push notifications, however the jitter would have to be sma= ll so as not to affect quality of service. This is also mitigated inatel= y on large services with high traffic flows hosting data for many users,= as it becomes much harder for an attacker to correlate incoming data ev= ents with outgoing push notifications, allowing users to =E2=80=9Chide i= n the crowd=E2=80=9D.

---
I await the conclusion on whether we should add a confirmati= on step to push notifications, but other than that I don't believe there= are any outstanding issues to address from this review. Please let me k= now if I've missed something.

Neil.
--20b0ab2b3c2e4a4f907bd6c328212b8f-- From nobody Mon Jan 7 21:08:26 2019 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 368421310E4 for ; Mon, 7 Jan 2019 21:08:25 -0800 (PST) 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, 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=lowentropy.net header.b=M3yETsNk; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=b213B4Ed 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 PT--CFeIYxWs for ; Mon, 7 Jan 2019 21:08:23 -0800 (PST) Received: from new4-smtp.messagingengine.com (new4-smtp.messagingengine.com [66.111.4.230]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D9CF127133 for ; Mon, 7 Jan 2019 21:08:23 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailnew.nyi.internal (Postfix) with ESMTP id 709CEC7C4 for ; Tue, 8 Jan 2019 00:08:22 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute1.internal (MEProxy); Tue, 08 Jan 2019 00:08:22 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=message-id:from:to:mime-version:content-transfer-encoding :content-type:references:in-reply-to:date:subject; s=fm1; bh=IqQ ZdAGTryGCKTiE9tuetMM+4EL9BSNCR5a9zEpS3oA=; b=M3yETsNkCHKkVSREAwH UzvelMm9iGTMeaPbawlx3dpxx+xcAsUZF41/WxMxYvg6Ek2Nlyc7bmn8ORkRzaMn ZivUDUMJdyd9S0caQBkEH43QlyzmaTtjhhwdvx/Ai9Z8kUrnqK0k0xQK0nHh/qfi WSiUsDVkold2ORqj3jPuLddxaPW+gufOvyyrvHMPBuoteXgr/IY4YtL+Yms9AmRR vdd9O+TSlhIQ8Jsul3LWeo20G9oKl0oqXyRj6LatGrw9o6/bZtAvurn9dOjV2Jng WMs0P5zrTQtdX6mtGLGF+XleqpyZWjnJ5W0wzGXEoWl/7zVtS2uMNcGXoZglKEt6 tuQ== 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-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=IqQZdAGTryGCKTiE9tuetMM+4EL9BSNCR5a9zEpS3 oA=; b=b213B4EdAhlQSSfrl9aiXQDcwsIWRtmb/RNHhiJSEsWJQHuX6m0Dr4PjU hHVo9xBImAGb+sSmQOkAR+ye+s8LwE5W0rEZ8SirBAnWn6yht4udcSS0ie64d3dL 5xIppT9H/tNKmleD0EOp8BQvx+NeT4VdpJp0AqeOHfS2+qjqMsuz3+2lueSEJgqH jYFoRXOq8Km4WXnyhepmsP2Ea2d6mLlnJBPlnVpP2UaytqsjoLjpLbAnTRIu8tMv uf5kK4QjsADQwFDf7iNHKvNdpJu3SFSoZWQUBFGlzVmG7jFoo7xvDWXcXdY+47bu 3vidaoOAgszN827qgE+P57+3qaiaA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrvdekgdekfeculddtuddrgedtkedrtddtmd cutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthen uceurghilhhouhhtmecufedttdenucenucfjughrpefkhffvggfgtgfofhgjfffusehtqh ertdertdejnecuhfhrohhmpeforghrthhinhcuvfhhohhmshhonhcuoehmtheslhhofigv nhhtrhhophihrdhnvghtqeenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvg hnthhrohhphidrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 99) id B15AB9E2F9; Tue, 8 Jan 2019 00:08:20 -0500 (EST) Message-Id: <1546924100.2435004.1628427896.3C145F9C@webmail.messagingengine.com> From: Martin Thomson 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-5ae1f753 References: <154651703823.29557.748556981627156046@ietfa.amsl.com> <01R1M7QIBP9I00004R@mauve.mrochek.com> <77c37c56-a40a-4a52-95a0-553e63dc6a08@beta.fastmail.com> In-Reply-To: <77c37c56-a40a-4a52-95a0-553e63dc6a08@beta.fastmail.com> Date: Tue, 08 Jan 2019 16:08:20 +1100 Archived-At: Subject: Re: [Jmap] Secdir last call review of draft-ietf-jmap-core-12 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2019 05:08:25 -0000 On Tue, Jan 8, 2019, at 14:42, Neil Jenkins wrote: > *8.8 Push traffic analysis* >=20 > While the data is encrypted, a passive observer with the ability to=20 > monitor network traffic may be able to glean information from the timing= =20 > of push notifications. For example, suppose an email or calendar=20 > invitation is sent from User A (hosted on Server X) to User B (hosted on= =20 > Server Y).. If Server X hosts data for many users, a passive observer=20 Extra period here. > can see that the two servers connected but does not know who the data=20 > was for. However, if a push notification is immediately sent to User B=20 > and the attacker can observe this as well, they may reasonably conclude=20 > that someone on Server X is connecting to User B. This is all good. =20 > This can be partially mitigated by the JMAP server applying some random=20 > jitter before sending out push notifications, however the jitter would=20 > have to be small so as not to affect quality of service. This is also=20 > mitigated inately on large services with high traffic flows hosting data= =20 > for many users, as it becomes much harder for an attacker to correlate=20 > incoming data events with outgoing push notifications, allowing users to= =20 > =E2=80=9Chide in the crowd=E2=80=9D. This is a little problematic. If you look at how push notification service= s typically manage this sort of thing, the direct mapping is often masked b= y a little store-and-forward, which looks like the "jitter" you suggest, bu= t it's not really a well-proven defense against traffic analysis. Rather than describe - in some detail - a defense that is questionable, I = would simply limit this to the facts. Acknowledge that traffic analysis is= feasible and then move on. If you must, note the typical defenses against= traffic analysis are inducing delays, padding, and mix networks. Your sug= gestion here leans on delays and a single-layer mixnet at the push service.= As you allude to, these defenses each come with costs that need some cons= ideration of the trade-offs. Separately, you probably need to concern yourself with the push service as = an attacker as well. There's more text on that in RFC 8030 if you care to = cite that. From nobody Tue Jan 8 06:28:19 2019 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 50DCC1200B3; Tue, 8 Jan 2019 06:28:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.42 X-Spam-Level: X-Spam-Status: No, score=-3.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779, 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 0qSKSJhTOo7i; Tue, 8 Jan 2019 06:28:14 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 E08F91200D7; Tue, 8 Jan 2019 06:28:13 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id x08ES5gQ020863 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 8 Jan 2019 16:28:05 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x08ES5QJ022217; Tue, 8 Jan 2019 16:28:05 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <23604.45941.279266.464196@fireball.acr.fi> Date: Tue, 8 Jan 2019 16:28:05 +0200 From: Tero Kivinen To: "Neil Jenkins" Cc: secdir@ietf.org, "Bron Gondwana" , "IETF JMAP Mailing List" , draft-ietf-jmap-core.all@ietf.org, ietf@ietf.org In-Reply-To: References: <154651703823.29557.748556981627156046@ietfa.amsl.com> <7beebd38-7999-4a49-b892-c3c75b36eab4@beta.fastmail.com> <23603.20862.976183.378013@fireball.acr.fi> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 183 min X-Total-Time: 45 min Archived-At: Subject: Re: [Jmap] Secdir last call review of draft-ietf-jmap-core-12 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2019 14:28:17 -0000 Neil Jenkins writes: > On Tue, 8 Jan 2019, at 12:17 AM, Tero Kivinen wrote: >=20 > Actually I think adding confirmation step will make the push > notifications more reliable, as that will give you positive feedb= ack > that your push notifications do work. >=20 > The issue is that push services (e.g. Apple's APNS and Google's FCM) = do not > guarantee that any particular push will be received. They normally wi= ll, but > may not, especially if the device goes offline for a while. So if you= r first > push doesn't make it through your push never works. It's likely to be= rare, but > painful when it happens and makes it feel unreliable. When you are subscribing the push notifications your devices should be running and not offline. Note, that you do not need reconfirmation if you extended the time, but only when new URL is given. If client gives url, it should make sure it can actually receive those notifications in the given url for few seconds...=20 > It is really annoying trying to debug which firewall / proxy / en= cryption > is causing the notification to be blocked, if I need to reregiste= r again > for every time and need to then somehow still cause one push noti= fication > to be sent before I can see does it work.=20 >=20 > I'm not sure what you're referring to here. Do you mean the JMAP (app= lication) > server connecting to the push server=3F Or the push server connecting= to the > client (which is not part of JMAP at all, but where you're more likel= y to run > into issues with corporate firewalls and the like)=3F Perhaps my understanding of the jmap push service is then wrong, or perhaps it is badly defined in JMAP.=20 > My understanding is that RFC8030 does not connect random urls, >=20 > My understanding is that is incorrect. There are three entities invol= ved in an > 8030 push system, and JMAP is only involved with two of them: >=20 > * The client, which wants to receive the push notifications (the JM= AP client) > * The application server which contains the data and wants to send = the push > notifications (the JMAP server)=20 > * The push server (3rd party, depends on the device what is possibl= e) But client and application server protocol is not defined in RFC8030. It is left outside the scope of that document. RFC8030 seems to only document interaction between the client and push service, and interaction between application and push service. The URL returned from the push service is somehow magically given to the application server and whatever verification happens there is not covered.=20 > The situation of the client/application server being one entity and t= he push > server being a completely unrelated entity is what 8030 is designed f= or. For > example, each browser implements the Push API, whereby if you have a = web app > you can ask the browser for a push subscription endpoint, then send i= t to your > application server to connect to. The application server does not kno= w in > advance which browser the user has or what domains that browser curre= ntly uses > for push subscriptions. It simply gets given an arbitrary URL to post= to. Looking at the text in jmap. It says in section 7.2: A push subscription is a message delivery context established betwee= n the client and a push service. Push service is not defined in this document, and it does not refer to RFC8030 for that term. My understanding was that push worked as follows: Client does PushSubscription as defined in 7.2 to JMAP server: Clients may create a push subscription on the JMAP server, which wil= l then make a POST request to the associated push endpoint whenever an= event occurs. This push subscription includes an url and when something happens the JMAP server will connect to that url and send some random garbage (from the receiver point of view if it does not assume receiveing push notications) to it using POST. If the receiver end is proper push service then it will notify the client using some other means. I.e., when email etc is received the JMAP server will then push StateChange object (section 7.1): When something changes on the server, the server pushes a *StateChange* object to the client. Actually that says "to the client" not to the "push service". Which one should it be=3F I always assumed this StateChange object is sent to= the url given in the PushSubscription. Hmm... and 7.2 then also uses term "push endpoint" which is not defined anywhere=3F Is that the same as push service at given url or something else: Clients may create a push subscription on the JMAP server, which wil= l then make a POST request to the associated push endpoint whenever an= event occurs. Then section 7.2 seems to also describe things not related to the PushSubscription but instead to the notifications sent by the JMAP server. Perhaps it would be better to move that to the StateChange object section, i.e., put all things related to the "push service" in same place. Now it is split in two places, i.e., StateChange is defined in section 7.1, but how to transmit that inside https POST with content type of application/json is described in 7.2. Also it is not clear which server this is talking about: =09=09=09=09=09=09=09The server is expected to understand and handle HTTP status responses in a reasonable manner. Is it push service server, JMAP server, Application server (same as JMAP server in this case=3F). My guess it is supposed to be JMAP server= which is actually acting as http-client and making https request to push service, and if push service returns http errors JMAP server acting as http-client will process those in reasonable manner. Is that understaning correct=3F Perhaps rewording it a bit to make it clear. Then I have no idea what this text is trying to say: The use of this push endpoint conforms with the use of a push endpoint by an Application Server as defined in [RFC8030]. what push endpoint=3F JMAP server=3F URL given by the client to JMAP server=3F=20 > JMAP is not defining anything new here. It is just defining the appli= cation > server portion exactly as expected by RFC8030. >=20 > the push notifications are received by client doing GET request t= o the > subscription server and then later server using server push to th= at > connection or something like that (in section 6 of the RFC8030). > Usually that is only way things can work, as most of the people a= re > behind firewalls / NATs / Proxies etc, thus connecting to them fr= om > outside is impossible or hard. >=20 > Yes, this is how the client receives the data from the push server in= RFC8030. > This is entirely orthogonal to what we are discussing though. >=20 > The interaction between UA and the Application server is using > "an application-specific method" =E2=80=A6 > The verification would be inside this application-specific method= , > thus it is not covered in the 8030 because of that. >=20 > Hmm, yes I see your point, although it seems odd for it not to mentio= n at all > given this is going to apply to pretty much every app that uses this = system; > not specifically JMAP. Most likely it is not describied in the RFC8030 because the details depends on the application server.=20 > but if server just answers HTTP ok 200 back, and JMAP server will= be > happy to keep sending notifications. >=20 > Yes, this is indeed a risk, and I agree that a confirmation step > would be the only way to mitigate this. I would expect it to be very easy to find urls in host that will return success to http posts with application/json and ignore contents. >=20 > Attacker can also do 10000 subscriptions to same victim (perhaps = using > different URLs, but destioned to same victim). It can do this > overnight, and then on the morning when someone triggers event th= e > victim will suddenly receive 10000 event notifications > (https-connections) from the well connected JMAP server farm, and= will > be completely swamped before it can even respond to any errors to= > those notifications. >=20 > I would expect the JMAP server to rate limit the number of push > subscriptions any one user may have to something considerably lower > than that. There is text saying frequency of pushes to be rate limited, but there is no limit for number of subscriptions account can have, or even suggestion that there should be limit. This kind of attacks can also use multiple accounts especially if there is some kind of public services available.=20 > If the attacker had compromised many accounts on the JMAP > server though, it could set up push subscriptions with each of them > but then it would have to coordinate making a change in each of > those accounts at the same time in order to flood the target server > with a large single burst of requests, which is a much harder thing > to do. As people pointed out we have imap server providing access to ietf mailing lists. There is lots of people on those lists, and even if we require datatracker account to be able to make subscriptions, making those accounts require just email address and ability to receive emails. Most likely datatracker allows creating accounts for: example+1@gmail.com example+2@gmail.com example+3@gmail.com ... example+99999@gmail.com and then making subscription for all of those accounts to all ietf mailing lists and sending notifications to same url x... Verification step would disable that attack vector too.=20 > Summing up, I think that adding a confirmation step removes a small > risk of being able to use a JMAP application server as a DDOS > vector, but adds a small risk of the push not being received and the > push system failing to establish. Actually I think it will make push system much more reliable, as it immediately verifies that the system is working, and you will not have silent failure, where you just notice few days later that I have not received any notifications, something must be broken. > (Although, the client would at least know this was the case so could > alert the user and give them the option to try again.) Would anyone > else like to weigh in on the relative merits of the options here to > help come to a consensus on the way forward=3F I would be particularl= y > interested to hear if this was discussed at all, and any conclusions > reached, in the development of RFC8030. --=20 kivinen@iki.fi From nobody Tue Jan 8 06:49:28 2019 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 6CFD1124C04; Tue, 8 Jan 2019 06:49:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.42 X-Spam-Level: X-Spam-Status: No, score=-3.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779, 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 lquTl9uVbM2T; Tue, 8 Jan 2019 06:49:17 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 578BE124BF6; Tue, 8 Jan 2019 06:49:17 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id x08En3Sc005729 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 8 Jan 2019 16:49:03 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x08En2Gh009000; Tue, 8 Jan 2019 16:49:02 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23604.47198.503637.521152@fireball.acr.fi> Date: Tue, 8 Jan 2019 16:49:02 +0200 From: Tero Kivinen To: "Neil Jenkins" Cc: "Barry Leiba" , "Benjamin Kaduk" , "IETF JMAP Mailing List" , "Kurt Andersen \(IETF\)" , draft-ietf-jmap-core.all@ietf.org, iesg , secdir@ietf.org In-Reply-To: References: <154651703823.29557.748556981627156046@ietfa.amsl.com> <20190105185050.GB28515@kduck.kaduk.org> <23603.21152.388621.403480@fireball.acr.fi> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 59 min X-Total-Time: 15 min Archived-At: Subject: Re: [Jmap] [secdir] Secdir last call review of draft-ietf-jmap-core-12 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2019 14:49:19 -0000 Neil Jenkins writes: > Err, not sure what you're talking about here. Most email systems > already support sharing on a per-folder (or mailbox as they're > called in IMAP and JMAP) granularity. I have no idea how to do that for example in gmail. The imap server I am running does not list support for 4314, and as I have never needed such feature I have never checked if or how it can be done. On the other hand I did not see any support for that in ipad or android mail software either (or it might be well hidden in those things, they are not very easy to use). > That's why JMAP and IMAP can return you a "myRights" object with > your permissions for each mailbox. Calendars are identical; you > generally share on a per-calendar basis (which acts the same as a > mailbox for mail; a collection of individual data items). Calendars usually have separate per item flag that tells whether event is private, i.e., it is not only per calendar or per mailbox level. Anyways, I have seen several cases where people share their personal calendars, I have not seen cases where people share their personal mailboxes. There cases where family members know other members passwords, and can login if needed. Also group mailboxes, or reading mail from multiple accounts in same mail software is very common, sharing private mail boxes not so. I.e., is it really common that: ... another user is sharing their mail with the logged in user,... when not talking about group (support etc) or role (secretary) based mail boxes? If so, I am happy that I live in places where people do value privacy, and I have not seen such things done... -- kivinen@iki.fi From nobody Tue Jan 8 09:22:45 2019 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 25D61130F0B; Tue, 8 Jan 2019 09:22:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.208 X-Spam-Level: X-Spam-Status: No, score=-1.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no 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 KWAIxI9tmppO; Tue, 8 Jan 2019 09:22:35 -0800 (PST) Received: from mauve.mrochek.com (unknown [66.159.242.17]) (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 CFD56130F08; Tue, 8 Jan 2019 09:22:34 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01R1RITPR28000DL4N@mauve.mrochek.com>; Tue, 8 Jan 2019 09:16:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1546967843; bh=YlmX2BSOFsNN3GP6rqL6fsCWlPdXnoDAor4nhcv9/LY=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=K/5tbu6n+deV3YKpbscIujqHwySaZpKv33Yqmgm/NfzAAlWeQjXCjKx4Pq/WUH9wI Y+2dvBXkkjBgGsWPwNWdIHqnqbLs8XC/clJOmjsGaYE6fIunu/BApYzzU9dOSwqaid PqhocFAch1HMjE5o/5+Qa/ehvnHJx7o2NksvAOAw= 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 <01R1N39ADWKW00004L@mauve.mrochek.com>; Tue, 8 Jan 2019 09:16:43 -0800 (PST) Cc: Ned Freed , IETF JMAP Mailing List , "Kurt Andersen (IETF)" , Tero Kivinen , Tony Finch , draft-ietf-jmap-core.all@ietf.org, secdir@ietf.org Message-id: <01R1RITKNL3G00004L@mauve.mrochek.com> Date: Tue, 08 Jan 2019 08:04:29 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Tue, 08 Jan 2019 07:46:36 +0800" References: <154651703823.29557.748556981627156046@ietfa.amsl.com> <01R1M7QIBP9I00004R@mauve.mrochek.com> <01R1Q3OA5O7800004L@mauve.mrochek.com> To: Barry Leiba Archived-At: Subject: Re: [Jmap] Secdir last call review of draft-ietf-jmap-core-12 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2019 17:22:36 -0000 > Hm. I don’t see that. All you get in response to the IDLE command is the > same stuff you get from the NOOP command or from any other IMAP command: > untagged FETCH and EXPUNGE responses. If IDLE was the same as NOOP then we wouldn't have added the IDLE command to the protocol. > Technically, they’re not actually > responses to the command: they’re unsolicited messages in the IMAP protocol. It's right there in the abstract: The Internet Message Access Protocol [IMAP4] requires a client to poll the server for changes to the selected mailbox (new mail, deletions). It's often more desirable to have the server transmit updates to the client in real time. This allows a user to see new mail immediately. It also helps some real-time applications based on IMAP, which might otherwise need to poll extremely often (such as every few seconds). (While the spec actually does allow a server to push EXISTS responses aysynchronously, a client can't expect this behaviour and must poll.) Note the last sentence: If accepted IDLE requires that the server return changes in mailbox state in real time. That opens the door to certain types of traffic analysis. Now, since the protocol does allow EXISTS responses to be pushed regardless of IDLE, you can include RFC 3501 in having deficient security considerations in this regard. The fact remains that there's a missing security consideration here. > What security considerations should there be for IDLE that are beyond those > for NOOP (that is, IMAP itself? NOOP is pull and done at the client's discretion, IDLE is push and triggered by server changes. Ned From nobody Tue Jan 8 12:24:00 2019 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 AD4F0130F96 for ; Tue, 8 Jan 2019 12:23:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 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_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, 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=fastmailteam.com header.b=zS7/tNfw; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=kHgcPjy8 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 RmmfVZzAimkL for ; Tue, 8 Jan 2019 12:23:56 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFCAE131022 for ; Tue, 8 Jan 2019 12:23:56 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 292541418 for ; Tue, 8 Jan 2019 15:23:56 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Tue, 08 Jan 2019 15:23:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:subject:content-type; s=fm1; bh=QhxKrcklFg6jwifItzFZ+cnwPDPm NoqQN2kGHWqtfTg=; b=zS7/tNfwQ7B6VEjl2cA5RQ96NOxEGoa9AeyP/P6sSldq 1NXN3l8fQjnzqmCIKjgie0TOxt+IUT8tcaxBVirw4lWR1bkP/Ia1BPzQGlYaWYUI Vwy4Bj89CgN9oUwcrh9BPsUzOGemp+uZCdwkop6Vid9SwwVAvqPB9MRz2DtnV5q/ OTSU3Rn5JdUWRM/j6r0AzKTx8utSqdZDDEzZZIUye5o4946x3nNyVROMc3Xc+FaF 4odmN4BEJgJcK6XaJU7vUxxIlP0Bl5+c5LM1GtYhVslI3n9qmHpaTFVqpFoANyPQ 1QN1R4Y+Qu9fNotFOr1nXqgs7KRhNtQt8+lEZOrk3A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=QhxKrcklFg6jwifIt zFZ+cnwPDPmNoqQN2kGHWqtfTg=; b=kHgcPjy860MDe0ZQXq+6xS6DAcyPpRqyz 0tunzAVSmo+ec/ydagBfqEPUi2mL5XE+yrWLM3cQQhuu6RuIhRTxrWUopEcF5r0l PxRyZMmrk2IavMGtXqTEKYNjtfvbb8VXahJBfKOZ3kfZYZ3aZ5OmuaMgCrEBJTCT GSbI7IT18gKPg5duOOuQwiNhIjurbudj3FBcuyeFWGkhr/kfyRDEANMB9DQCpBce YQ3JIxf6lLN4Xv4Y/bpzzfxdxJBx/i1fal5CwbLPnOh3y/PY61kJbdsXoYySiu8B Jqn3HTPTa4vslwBy1xO0OkXAzDvFIDwHFdgxTmxUqKW15fUGTt/ww== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrvdelgddufeeiucdltddurdegtdekrddttd dmucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhht necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfkfgjfhffhffvufgtsegrtd erreerreejnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucffohhmrghinhepihgvthhfrdhorhhgne curfgrrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdr tghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 30B2C203F1; Tue, 8 Jan 2019 15:23:55 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-739-g7452a1e-fmstable-20190103v1 X-Me-Personality: 56629417 Message-Id: <18ed534b-fca8-416e-a506-7397dcaac0a2@www.fastmail.com> In-Reply-To: <23604.47198.503637.521152@fireball.acr.fi> References: <154651703823.29557.748556981627156046@ietfa.amsl.com> <20190105185050.GB28515@kduck.kaduk.org> <23603.21152.388621.403480@fireball.acr.fi> <23604.47198.503637.521152@fireball.acr.fi> Date: Tue, 08 Jan 2019 15:23:52 -0500 From: "Bron Gondwana" To: jmap@ietf.org Content-Type: multipart/alternative; boundary=cb7067633b154b5693ee5450b3da9123 Archived-At: Subject: Re: [Jmap] =?utf-8?q?=5Bsecdir=5D_Secdir_last_call_review_of_draft-i?= =?utf-8?q?etf-jmap-core-12?= X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2019 20:23:59 -0000 --cb7067633b154b5693ee5450b3da9123 Content-Type: text/plain Ok - this is just getting silly. *Tero:* is this something on which you feel strongly enough to block the progress of JMAP unless it's changed. *Neil:* is this something which you feel strongly enough to insist on keeping? If both of these are true, we need to keep debating this - otherwise, we can find a path forward on this particular point easily. Cheers, Bron. On Wed, Jan 9, 2019, at 01:49, Tero Kivinen wrote: > Neil Jenkins writes: > > Err, not sure what you're talking about here. Most email systems > > already support sharing on a per-folder (or mailbox as they're > > called in IMAP and JMAP) granularity. > > I have no idea how to do that for example in gmail. The imap server I > am running does not list support for 4314, and as I have never needed > such feature I have never checked if or how it can be done. > > On the other hand I did not see any support for that in ipad or > android mail software either (or it might be well hidden in those > things, they are not very easy to use). > > > That's why JMAP and IMAP can return you a "myRights" object with > > your permissions for each mailbox. Calendars are identical; you > > generally share on a per-calendar basis (which acts the same as a > > mailbox for mail; a collection of individual data items). > > Calendars usually have separate per item flag that tells whether event > is private, i.e., it is not only per calendar or per mailbox level. > > Anyways, I have seen several cases where people share their personal > calendars, I have not seen cases where people share their personal > mailboxes. There cases where family members know other members > passwords, and can login if needed. Also group mailboxes, or reading > mail from multiple accounts in same mail software is very common, > sharing private mail boxes not so. > > I.e., is it really common that: > > ... another user is sharing their mail with the logged in > user,... > > when not talking about group (support etc) or role (secretary) based > mail boxes? > > If so, I am happy that I live in places where people do value > privacy, and I have not seen such things done... > -- > kivinen@iki.fi > > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap > -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --cb7067633b154b5693ee5450b3da9123 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Ok - this is just getting silly.

Tero: is this something on which you feel strongly enough to block the prog= ress of JMAP unless it's changed.

Neil: is this something which you feel strongly enough t= o insist on keeping?

If both of these are true, we need to ke= ep debating this - otherwise, we can find a path forward on this particu= lar point easily.

<= div style=3D"font-family:Arial;">Cheers,

Bron.

On Wed, Jan 9, 2019, at 01:49, Tero= Kivinen wrote:
Neil Jenkins writes:
> Err, not sure what you're talking about= here. Most email systems
>= ; already support sharing on a per-folder (or mailbox as they're
> called in IMAP and JMAP) granul= arity.

I have no idea how to do that for example in gmail.= The imap server I
am running= does not list support for 4314, and as I have never needed
such feature I have never checked if or h= ow it can be done.

=
On the other hand I did not see any su= pport for that in ipad or
and= roid mail software either (or it might be well hidden in those
=
things, they are not very easy to use)= . 

> That's why JMAP and IMAP can return you a "myR= ights" object with
> your = permissions for each mailbox. Calendars are identical; you
> generally share on a per-calendar bas= is (which acts the same as a
= > mailbox for mail; a collection of individual data items).
=

Calendars usually have separate per item flag that tells whether e= vent
is private, i.e., it is = not only per calendar or per mailbox level.

Anyways, I ha= ve seen several cases where people share their personal
calendars, I have not seen cases where people= share their personal
mailbox= es. There cases where family members know other members
passwords, and can login if needed. Also grou= p mailboxes, or reading
mail = from multiple accounts in same mail software is very common,
sharing private mail boxes not so.

I.e., is it really common that:

  &nb= sp;   ... another user is sharing their mail with the logged i= n
    &nb= sp; user,...

when not talking about group (support etc) o= r role (secretary) based
mail= boxes?

If so, I am happy that I live in places where peopl= e do value
privacy, and I hav= e not seen such things done... 
-- 
kivinen@iki.= fi

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


--<= br>
  Bron Gondwana, CEO, FastMail Pt= y Ltd
  brong@fastmailteam.com


--cb7067633b154b5693ee5450b3da9123-- From nobody Tue Jan 8 12:24:55 2019 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 51442131029 for ; Tue, 8 Jan 2019 12:24:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 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_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, 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=fastmailteam.com header.b=GLCmtbVj; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=orjpGzOj 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 5NFYj7R5MGUS for ; Tue, 8 Jan 2019 12:24:52 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3DD8130F96 for ; Tue, 8 Jan 2019 12:24:51 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id E965D7A4 for ; Tue, 8 Jan 2019 15:24:50 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Tue, 08 Jan 2019 15:24:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:subject:content-type; s=fm1; bh=oDbF58U/Y72glVJSezRTibympOhO oToJLB6uf54lsL8=; b=GLCmtbVjS6ypNjoz1/ig7l1k+Y9diazBHEFacjMAiOhE ClhegGbhv75gDssXfK/obKl2/6KUBA66z+mecEypj5SiT2l3ugHuBzbpbUGucfEl FlawTlOcdQYajN0aap8+u8yhks58EZw9cBq8mbMhn11JsKG3dZ2j6nFdq3KG05CS JeZKtX2ERdd9PIhQvlzEvB8xcS1bw9JthaKJccy41vz4PsofuNs+JwD3xSGbF+fi KzWQiD9yavebxF1nR+6nTjGxzh7SODo51MTGZxMVw5ibYsWGcTdyDw7F119j05CC y91y7ZxvWg/1xPHHZql+ctImLqEz7FH7NDo6zf99Zw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=oDbF58U/Y72glVJSe zRTibympOhOoToJLB6uf54lsL8=; b=orjpGzOja/EqruQ4EM0KM16n1ISQ2eEI1 1uZUcLOw1EB/AeXKaA5+LhElSOFKtohq/c67+eNcvson/bo1oDFuDMO1rh+k8JLZ Ovp8fOCVFK7IFk5zrhD11+T/KCYvmaSfWt3sfEG8uuez9+i6K/DItmRGzNHUslJI DaHHt2qTTJNmO0nzfWfjVo/X3upwmBXfup5hJr1fQCwT9KMMj9XdlfmbJHJPYiP0 UFdbjE0RBtTJzR8v3w6RR5EsxlG+gVwrOR+p+tOy7giI+l7SE3dYf+0lDcxz5TNO raYpYtk/ZUdcHko+7zW7esq3RzR6GecQs83cyc+ggkDVr7BzVXQGQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrvdelgddufeeiucdltddurdegtdekrddttd dmucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhht necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfkfgjfhffhffvufgtsegrtd erreerreejnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucffohhmrghinhepihgvthhfrdhorhhgne curfgrrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdr tghomhenucevlhhushhtvghrufhiiigvpedu X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 3F475203F1; Tue, 8 Jan 2019 15:24:50 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-739-g7452a1e-fmstable-20190103v1 X-Me-Personality: 56629417 Message-Id: <401948ae-7577-4d4b-8e12-ec4058099987@www.fastmail.com> In-Reply-To: <18ed534b-fca8-416e-a506-7397dcaac0a2@www.fastmail.com> References: <154651703823.29557.748556981627156046@ietfa.amsl.com> <20190105185050.GB28515@kduck.kaduk.org> <23603.21152.388621.403480@fireball.acr.fi> <23604.47198.503637.521152@fireball.acr.fi> <18ed534b-fca8-416e-a506-7397dcaac0a2@www.fastmail.com> Date: Tue, 08 Jan 2019 15:24:48 -0500 From: "Bron Gondwana" To: jmap@ietf.org Content-Type: multipart/alternative; boundary=6492865b4f6b4fae8449716065940e27 Archived-At: Subject: Re: [Jmap] =?utf-8?q?=5Bsecdir=5D_Secdir_last_call_review_of_draft-i?= =?utf-8?q?etf-jmap-core-12?= X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2019 20:24:53 -0000 --6492865b4f6b4fae8449716065940e27 Content-Type: text/plain Sorry: I should clarify. By "this" I mean the wording in core mentioning mail as an example for isPersonal, not the existence of a mapping of RFC4314 into JMAP. Bron. On Wed, Jan 9, 2019, at 07:23, Bron Gondwana wrote: > Ok - this is just getting silly. > > *Tero:* is this something on which you feel strongly enough to block the progress of JMAP unless it's changed. > > *Neil:* is this something which you feel strongly enough to insist on keeping? > > If both of these are true, we need to keep debating this - otherwise, we can find a path forward on this particular point easily. > > Cheers, > > Bron. > > On Wed, Jan 9, 2019, at 01:49, Tero Kivinen wrote: >> Neil Jenkins writes: >> > Err, not sure what you're talking about here. Most email systems >> > already support sharing on a per-folder (or mailbox as they're >> > called in IMAP and JMAP) granularity. >> >> I have no idea how to do that for example in gmail. The imap server I >> am running does not list support for 4314, and as I have never needed >> such feature I have never checked if or how it can be done. >> >> On the other hand I did not see any support for that in ipad or >> android mail software either (or it might be well hidden in those >> things, they are not very easy to use). >> >> > That's why JMAP and IMAP can return you a "myRights" object with >> > your permissions for each mailbox. Calendars are identical; you >> > generally share on a per-calendar basis (which acts the same as a >> > mailbox for mail; a collection of individual data items). >> >> Calendars usually have separate per item flag that tells whether event >> is private, i.e., it is not only per calendar or per mailbox level. >> >> Anyways, I have seen several cases where people share their personal >> calendars, I have not seen cases where people share their personal >> mailboxes. There cases where family members know other members >> passwords, and can login if needed. Also group mailboxes, or reading >> mail from multiple accounts in same mail software is very common, >> sharing private mail boxes not so. >> >> I.e., is it really common that: >> >> ... another user is sharing their mail with the logged in >> user,... >> >> when not talking about group (support etc) or role (secretary) based >> mail boxes? >> >> If so, I am happy that I live in places where people do value >> privacy, and I have not seen such things done... >> -- >> kivinen@iki.fi >> >> _______________________________________________ >> Jmap mailing list >> Jmap@ietf.org >> https://www.ietf.org/mailman/listinfo/jmap >> > > -- > Bron Gondwana, CEO, FastMail Pty Ltd > brong@fastmailteam.com > > -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --6492865b4f6b4fae8449716065940e27 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Sorry: I should clarify.  By "this" I mean the w= ording in core mentioning mail as an example for isPersonal, not the exi= stence of a mapping of RFC4314 into JMAP.

Bron.
=

On Wed, Jan 9, 2019, at 07:23, Bron Gondwana wrote:
Ok - this is just getting silly.

Tero: is th= is something on which you feel strongly enough to block the progress of = JMAP unless it's changed.

Neil: is this something which you feel strongly enough to insi= st on keeping?

If both of these are true, we need t= o keep debating this - otherwise, we can find a path forward on this par= ticular point easily.

Cheers,

Bron.

On Wed, Jan 9, 2019, at = 01:49, Tero Kivinen wrote:
Neil Jenk= ins writes:
> Err, not sur= e what you're talking about here. Most email systems
> already support sharing on a per-folder (or= mailbox as they're
> call= ed in IMAP and JMAP) granularity.

I have no idea how to d= o that for example in gmail. The imap server I
am running does not list support for 4314, and as I ha= ve never needed
such feature = I have never checked if or how it can be done.

On the oth= er hand I did not see any support for that in ipad or
android mail software either (or it might be we= ll hidden in those
things, th= ey are not very easy to use). 

> That's why JMAP = and IMAP can return you a "myRights" object with
> your permissions for each mailbox. Calendars ar= e identical; you
> general= ly share on a per-calendar basis (which acts the same as a
> mailbox for mail; a collection of ind= ividual data items).

Calendars usually have separate per = item flag that tells whether event
is private, i.e., it is not only per calendar or per mailbox level= .

Anyways, I have seen several cases where people share t= heir personal
calendars, I ha= ve not seen cases where people share their personal
mailboxes. There cases where family members know ot= her members
passwords, and ca= n login if needed. Also group mailboxes, or reading
mail from multiple accounts in same mail software i= s very common,
sharing privat= e mail boxes not so.

I.e., is it really common that:
<= /div>

      ... another user is sharing th= eir mail with the logged in
&= nbsp;     user,...

when not talking a= bout group (support etc) or role (secretary) based
mail boxes?

If so, I am happy that I= live in places where people do value
privacy, and I have not seen such things done... 
-- 
kivinen@iki.fi

___________________________= ____________________
Jmap mai= ling list
Jmap@ietf.org
https://www.ietf.org/mailman/listi= nfo/jmap


--
  Bron Gondwana, CEO, FastMail= Pty Ltd
  brong@= fastmailteam.com

<= /div>


--
  Bron Gondwa= na, CEO, FastMail Pty Ltd
  brong= @fastmailteam.com


--6492865b4f6b4fae8449716065940e27-- From nobody Tue Jan 8 18:19:55 2019 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 5445D12D7EA for ; Tue, 8 Jan 2019 18:19:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 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_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=PL9uhdpd; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ivqb2Nuq 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 bksrUfZtqxDM for ; Tue, 8 Jan 2019 18:19:52 -0800 (PST) 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 43F2D12008A for ; Tue, 8 Jan 2019 18:19:52 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 87A5824F59 for ; Tue, 8 Jan 2019 21:19:51 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Tue, 08 Jan 2019 21:19:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:subject:content-type; s=fm1; bh=hTpYB50O9R8TaZ65UZEK7lJ9JzrB y8adM+YDfG9f1kU=; b=PL9uhdpderxone1Pv4owOl6f9vegQAOIFFpxcSiriXej EUzWAh/kdu2CazQDufiLrtPgftlF2Unfk468Pt2mtqYVLUP7Yy7SLrP0Mn9dqCgE dGJXBBosrdvKXq+MU3Jkss1RpW2uljIBi+SjeUchKJHX8wNKWvZSMXdsjuQI14Kc VpXmE18UzB0UcLYZnARZJbASCYVJdQa/x4XM8PLD9Nicww3IsMNuhCeS82gX0Cpc ROrHxG/eoOaNB762OLyJ6IaYXUuzeyqvgnH3i2+wTRx02w5VJl8ONorNtdGPjZDS 63WRVQdasBcla3MPyxtaGo176YeQ9X2c14Xaeomykw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=hTpYB50O9R8TaZ65U ZEK7lJ9JzrBy8adM+YDfG9f1kU=; b=ivqb2NuqH/EICyIgKiJTqNsDE4qIXJxJF 8VI3gfPoIpt8lLsCsrQt0V3j1jgFk4mGRMg9lSqtreoGxZTdg/8+bkji18nghMHG DS1ClCNeOkakG5niyzOUQxZ+vM3K0J2luRFD2yBgt0TAUo0paoFHXcBCuXRh804a eubUPP7Oph4OXdkc2HvKQSJX7549K6/zgK+wcltdZhlophMbQhH4+gvTgmg8txxh 3p5rIiiO7VGZlVec6OJO3FWHewQfEU7Pkbq6xq16W/8Cbd3ULBypPKLlvM4NA7WR NqGRjIUFEcvWccRDk7N12CJKokFa0Au/ekXKw7wQpsc+wwd8pbttg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrfedtgdegieculddtuddrgedtkedrtddtmd cutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfkfgjfhffhffvufgtsegrtderreerredtnecuhfhrohhmpedfpfgvihhl ucflvghnkhhinhhsfdcuoehnvghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomheqne cuffhomhgrihhnpehivghtfhdrohhrghenucfrrghrrghmpehmrghilhhfrhhomhepnhgv ihhljhesfhgrshhtmhgrihhlthgvrghmrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 359DE203F1; Tue, 8 Jan 2019 21:19:51 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-739-g7452a1e-fmstable-20190103v1 X-Me-Personality: 64588216 Message-Id: In-Reply-To: <1546924100.2435004.1628427896.3C145F9C@webmail.messagingengine.com> References: <154651703823.29557.748556981627156046@ietfa.amsl.com> <01R1M7QIBP9I00004R@mauve.mrochek.com> <77c37c56-a40a-4a52-95a0-553e63dc6a08@beta.fastmail.com> <1546924100.2435004.1628427896.3C145F9C@webmail.messagingengine.com> Date: Tue, 08 Jan 2019 21:19:50 -0500 From: "Neil Jenkins" To: "IETF JMAP Mailing List" Content-Type: multipart/alternative; boundary=38117e3c8c3744f897015037af4f7b80 Archived-At: Subject: Re: [Jmap] Secdir last call review of draft-ietf-jmap-core-12 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2019 02:19:54 -0000 --38117e3c8c3744f897015037af4f7b80 Content-Type: text/plain On Tue, 8 Jan 2019, at 4:08 PM, Martin Thomson wrote: > This is a little problematic. If you look at how push notification services typically manage this sort of thing, the direct mapping is often masked by a little store-and-forward, which looks like the "jitter" you suggest, but it's not really a well-proven defense against traffic analysis. > > Rather than describe - in some detail - a defense that is questionable, I would simply limit this to the facts. Sure, agreed. I didn't mean to imply in any way that this was a comprehensive defence, and I agree it's better to just acknowledge the problem rather than give people a false sense of security. I have removed this second paragraph. > Separately, you probably need to concern yourself with the push service as an attacker as well. There's more text on that in RFC 8030 if you care to cite that. We already have the *Push encryption* subsection of the security considerations, which reads as follows. Is there something you would like to see that is still missing from this? *When data changes, a small object is pushed with the new state strings for the types that have changed. While the data here is minimal, a passive man-in-the-middle attacker may be able to gain useful information. To ensure confidentiality and integrity, if the push is sent via a third party outside of the control of the client and JMAP server the client MUST specify encryption keys when establishing the PushSubscription and ignore any push notification received that is not encrypted and signed with those keys.** * * * *The privacy and security considerations of **RFC8030* * and **RFC8291* * also all apply to the use of the PushSubscription mechanism.* Cheers, Neil. --38117e3c8c3744f897015037af4f7b80 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Tue, 8 = Jan 2019, at 4:08 PM, Martin Thomson wrote:
This is a little problematic.  I= f you look at how push notification services typically manage this sort = of thing, the direct mapping is often masked by a little store-and-forwa= rd, which looks like the "jitter" you suggest, but it's not really a wel= l-proven defense against traffic analysis.

= Rather than describe - in some detail  - a defense that is question= able, I would simply limit this to the facts. 

Sure, agreed. I didn't mean to imply in any way th= at this was a comprehensive defence, and I agree it's better to just ack= nowledge the problem rather than give people a false sense of security. = I have removed this second paragraph.

Separately, you probably nee= d to concern yourself with the push service as an attacker as well. = ; There's more text on that in RFC 8030 if you care to cite that.

We already have the Push encrypti= on subsection of the security considerations, which reads as follows= . Is there something you would like to see that is still missing from th= is?

When data changes, a small object is= pushed with the new state strings for the types that have changed. Whil= e the data here is minimal, a passive man-in-the-middle attacker may be = able to gain useful information. To ensure confidentiality and integrity= , if the push is sent via a third party outside of the control of the cl= ient and JMAP server the client MUST specify encryption keys when establ= ishing the PushSubscription and ignore any push notification received th= at is not encrypted and signed with those keys.

The privacy and security considerations of&nbs= p;RFC8030=  and RFC8= 291 also all apply to the use of the PushSubscription mechani= sm.

Cheers,
Neil.
--38117e3c8c3744f897015037af4f7b80-- From nobody Tue Jan 8 19:49:18 2019 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 92EEB129AB8 for ; Tue, 8 Jan 2019 19:49:17 -0800 (PST) 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, 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=lowentropy.net header.b=TC6XGiT1; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=XdSZKnyI 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 FZq7r-KjiadM for ; Tue, 8 Jan 2019 19:49:15 -0800 (PST) Received: from new4-smtp.messagingengine.com (new4-smtp.messagingengine.com [66.111.4.230]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95793129C6A for ; Tue, 8 Jan 2019 19:49:15 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailnew.nyi.internal (Postfix) with ESMTP id 79CB11ADB0 for ; Tue, 8 Jan 2019 22:49:14 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute1.internal (MEProxy); Tue, 08 Jan 2019 22:49:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=message-id:from:to:mime-version:content-transfer-encoding :content-type:references:in-reply-to:date:subject; s=fm1; bh=8XJ 6mvRva4TkAn9cnIb8SzkGvREFA1lQaKHd5+6fBJo=; b=TC6XGiT1KmK6zGUH1m/ fdJPUItNHxZDHJq4RbjnsT3e9i9UKSqoAfPTj86SgmolpVXlw2/ogQT/MEcVJiov SRRqF4Q2pja411S5PR9P3WSROdfojDnvm6UI700hkQkZjocLnvgpAK2iJ42Axp2h LQ9eAwy21WZ8bTsKKsNLX4Bf7urfPfq9KjDfwaBa80++UgGyQk4Ivai8dD75bEn+ Bei/uta2cKUSPdlEIJHphEdAWs8g1fOpZylQMxUUqQeIPU+saYkF0TtDvvw6qwwx gXvuu5599EM/Lq0VtNCrRkHA4UKepX78UeZwDsqiPG9jvMRanzrFPeY3twOktzhs CeA== 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-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=8XJ6mvRva4TkAn9cnIb8SzkGvREFA1lQaKHd5+6fB Jo=; b=XdSZKnyIcLlisM0gMGFRrIGXJoeTLNF0kZHIxyQQL/sG0oAXMkrvE8F7z bYunju8fpxvF8GsS2mE1oaVQd5apFeI4dTHlezHEzjNw6n5Wc+VPAywtVxj7il4n ll7lXIN5K2I8F+UL6tUtJeH+2SkGU1/GhpDvvMnalmUbGRzzG4hHYM0szSRmWGLZ zQzf+b+4uHs+yP6+OP6GjZGeC2bz9O0rhif9Y9ltX4ZsUld6ML95OwcJVOw6d426 35aETDA8U+Ml4PtDt01+n9zNhdOKaVp6ZhcjvbEzSW3D6L4ggrm2i188iRoD6Awn 2x427ZJs3qs/wdso9VVWvNoXpC3+w== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrfedtgdeiheculddtuddrgedtkedrtddtmd cutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthen uceurghilhhouhhtmecufedttdenucgoteefjeefqddtgeculdehtddmnecujfgurhepkf fhvfgggfgtofhfjgffufesthejredtredtjeenucfhrhhomhepofgrrhhtihhnucfvhhho mhhsohhnuceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecuffhomhgrihhnpehivg htfhdrohhrghenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhp hidrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 99) id AE0569E59D; Tue, 8 Jan 2019 22:49:11 -0500 (EST) Message-Id: <1547005751.862899.1629465272.24550209@webmail.messagingengine.com> From: Martin Thomson 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-5ae1f753 References: <154651703823.29557.748556981627156046@ietfa.amsl.com> <01R1M7QIBP9I00004R@mauve.mrochek.com> <77c37c56-a40a-4a52-95a0-553e63dc6a08@beta.fastmail.com> <1546924100.2435004.1628427896.3C145F9C@webmail.messagingengine.com> In-Reply-To: Date: Wed, 09 Jan 2019 14:49:11 +1100 Archived-At: Subject: Re: [Jmap] Secdir last call review of draft-ietf-jmap-core-12 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2019 03:49:18 -0000 On Wed, Jan 9, 2019, at 13:19, Neil Jenkins wrote: > On Tue, 8 Jan 2019, at 4:08 PM, Martin Thomson wrote: > *The privacy and security considerations of **RFC8030* > * and **RFC8291* > * also all apply to the use of the > PushSubscription mechanism.* Yeah, that's good. Just a case of not having done the search. Sorry for the noise. From nobody Tue Jan 8 20:18:42 2019 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 0A46712D4EB; Tue, 8 Jan 2019 20:18:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 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_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=0j1ExoO9; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=sKOu+l+l 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 1Im2O7NQ3bmV; Tue, 8 Jan 2019 20:18:38 -0800 (PST) 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 14C9A129AB8; Tue, 8 Jan 2019 20:18:38 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 3CA592538B; Tue, 8 Jan 2019 23:18:37 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Tue, 08 Jan 2019 23:18:37 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:cc:subject:content-type; s=fm1; bh=BzscEGMa9ySZG8Co9mwBDQDL6 En1y+1sss3Y0auLZUs=; b=0j1ExoO99WprG6LoSkR+XmBIJJrraOPgIbXM4HgsH bRsWXNULZQhCporMKTbUXR9Y++kXImtwBnaIUY6cmu9Q+oORuaE0Y8VITuxS67nF DZX8MEpf6E0LplGdRLftpodfHnVtG3oinG/suxP6RzjZfIeuM/7ZcABxVJY9RJk+ TaJ2WdF07DFTcZq4C7WLHdWrhn8xym0BUc3Qz2c9gI6D9zuL1m3O2MxwwDRBN0eq ReyrXqOJA03Z3Pu5mQ9q5n9Jx2irQPb0BpPUbP8zvLirIh1EB1n2gkycQeP8ibmT Y6KJohhkTpu0lG8vrnln4scausonnze5h2GReatf9hCxA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=BzscEGMa9ySZG8Co9 mwBDQDL6En1y+1sss3Y0auLZUs=; b=sKOu+l+luaVOcY3qEEAYT4XSGjTvpN0yZ 9pt+HwbUMAArSo66Eb9tWtj5mVBKbxdICpyW0YTuu1SWAYo4Oc5Ob9EXV1cHI+FI WyqbwoRKSEbcTnnFUl+b/HoYiUDoYzyBLI3un+TUvoRBrYJet/EyODN3hCaC5aWp jbbxj2wYnECRw5EpvYzhgrDy1DKJ8TIpNwQgVryWEpP5398zqrJa/hGgsYyjzZ5X QDZSV43KYtrTCqcFVYxHm95+ByLLg+PHFYlVkMaw5QSgrcezbaPLlV2DlT2an+LF uZpli0Vg2EcHW/QU/1sI18nwno6PAofaz6xEB47N/ObLAHUNPJgaw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrfedtgdejudculddtuddrgedtkedrtddtmd cutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfkfgjfhffhffvufgtsegrtderreerredtnecuhfhrohhmpedfpfgvihhl ucflvghnkhhinhhsfdcuoehnvghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomheqne cuffhomhgrihhnpehgihhthhhusgdrtghomhenucfrrghrrghmpehmrghilhhfrhhomhep nhgvihhljhesfhgrshhtmhgrihhlthgvrghmrdgtohhmnecuvehluhhsthgvrhfuihiivg eptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 79A18203F1; Tue, 8 Jan 2019 23:18:36 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-739-g7452a1e-fmstable-20190103v1 X-Me-Personality: 64588216 Message-Id: In-Reply-To: <23604.45941.279266.464196@fireball.acr.fi> References: <154651703823.29557.748556981627156046@ietfa.amsl.com> <7beebd38-7999-4a49-b892-c3c75b36eab4@beta.fastmail.com> <23603.20862.976183.378013@fireball.acr.fi> <23604.45941.279266.464196@fireball.acr.fi> Date: Tue, 08 Jan 2019 23:18:36 -0500 From: "Neil Jenkins" To: "Tero Kivinen" Cc: secdir@ietf.org, "Bron Gondwana" , "IETF JMAP Mailing List" , draft-ietf-jmap-core.all@ietf.org, ietf@ietf.org Content-Type: multipart/alternative; boundary=a589e271320c4d059cd84835353b537e Archived-At: Subject: Re: [Jmap] Secdir last call review of draft-ietf-jmap-core-12 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2019 04:18:40 -0000 --a589e271320c4d059cd84835353b537e Content-Type: text/plain On Wed, 9 Jan 2019, at 1:28 AM, Tero Kivinen wrote: > When you are subscribing the push notifications your devices should be > running and not offline. Agreed. It's still possible for the initial message not to arrive, but in the vast majority of cases it will; if it doesn't, the client can destroy and recreate the subscription to try again. Weighing this up, I agree that adding a verification step is the best way forward here. > When something changes on the server, the server pushes a > *StateChange* object to the client. > > Actually that says "to the client" not to the "push service". Which > one should it be? Well, it's to the client, possibly via a push service, but possibly not because there are two "push" mechanisms defined here; the other is where the client can maintain a permanent TCP connection directly to the JMAP server in which case it can use an EventSource connection to receive push events directly without going via a 3rd party. > Hmm... and 7.2 then also uses term "push endpoint" which is not > defined anywhere? Is that the same as push service at given url Reading through it again, there was some confusion in the use of terminology. I have rewritten a few sections to attempt to clarify this and the other confusing points you pointed out. You can see the changes for this here . The addition of a verification step is added in this change here . Are you happy that this is sufficient to address your concerns? Regards, Neil. --a589e271320c4d059cd84835353b537e Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Wed, 9 = Jan 2019, at 1:28 AM, Tero Kivinen wrote:
When you are subscribing the push notif= ications your devices should be
running and not offline.

Agreed. It's still possible for= the initial message not to arrive, but in the vast majority of cases it= will; if it doesn't, the client can destroy and recreate the subscripti= on to try again. Weighing this up, I agree that adding a verification st= ep is the best way forward here.

   When something chang= es on the server, the server pushes a
   *StateC= hange* object to the client.

Actually that = says "to the client" not to the "push service". Which
one = should it be?

Well, it's to th= e client, possibly via a push service, but possibly not because there ar= e two "push" mechanisms defined here; the other is where the client can = maintain a permanent TCP connection directly to the JMAP server in which= case it can use an EventSource connection to receive push events direct= ly without going via a 3rd party.

Hmm... and 7.2 then also uses te= rm "push endpoint" which is not
defined anywhere? Is that = the same as push service at given url

Reading through it again, there was some confusion in the use of= terminology. I have rewritten a few sections to attempt to clarify this= and the other confusing points you pointed out. You can see the changes= for this here. The addition of a verification st= ep is added in this change here.
Are you happy that this is sufficient to address your conce= rns?

Regards,
Neil.
= --a589e271320c4d059cd84835353b537e-- From nobody Tue Jan 8 20:27:34 2019 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 8D40F129AB8 for ; Tue, 8 Jan 2019 20:27:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 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_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=Yk9qdu+W; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=beMjq+tD 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 coV8kosZM-rS for ; Tue, 8 Jan 2019 20:27:31 -0800 (PST) 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 73D7912872C for ; Tue, 8 Jan 2019 20:27:31 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 6216F256CF for ; Tue, 8 Jan 2019 23:27:30 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Tue, 08 Jan 2019 23:27:30 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:subject:content-type; s=fm1; bh=BQol+mhswQ0L/v/Z2xkE4iCTL1iq f7oV7zILE7mudRc=; b=Yk9qdu+WBkaUVRQpxUH2LsKjgdGjUgZXe/czIDrtfDct jJFeLOeFcjdexnLgjRf8CFIH+T0RqepZeHEbpaLjAalHvTw2x0y/eFMWZHjFZ1VL IfxXzn4JoCNs/p79Ah3t+GaMIdvWWSd5BU1tkwhAKLK8Cy2BJI8sBY2rrZbRgi66 EQri5XokjyeACHDILn0yvxI6NBv+LIs966Q8MsGhd7rWskaLGP/nMcVY+sJEjVut 9vRJssOiRYFDB+ZN5Fwd0H9h7crRor/t/XbgJQ+8eF70dL9Hq10JH2fMbyRlNRAT oCfAcEdxg4ePCukiiTmivyI4TL34f6X+UpWDT6oaDA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=BQol+mhswQ0L/v/Z2 xkE4iCTL1iqf7oV7zILE7mudRc=; b=beMjq+tDVRU/OyvsFFDM8iaRULdimthqs PVZJmMZ3F0TRtj+d2jBEJ10lmIaaMybKVrGTOh2GBYaYncBtvzVyQ/Jg45I8H/Iu kognpn3WD1KwhebRLHT2mjUlB1gpKKtgVb8Sbzcf2zD4UAwUNbmudAhLwwRIqqBc U/9aOvitnwPh038sISi7ZlrFSn75NvHQMMAIRDpA2aeRnqTKvG61Ti5HPidqswRf S/0FlqarG8Qmn64iTDHf48bztwjr76qGxJta8dR8N2LE89WY8E6wAbbW/9yepf6l 8D1BZEO4AxBNAUBepn0wDCQ/C/v6rOrE2jeCKYuZSkA/J5dh/dxHw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrfedtgdejfeculddtuddrgedtkedrtddtmd cutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfkfgjfhffhffvufgtsegrtderreerreejnecuhfhrohhmpedfpfgvihhl ucflvghnkhhinhhsfdcuoehnvghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomheqne curfgrrhgrmhepmhgrihhlfhhrohhmpehnvghilhhjsehfrghsthhmrghilhhtvggrmhdr tghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id DFC42203F1; Tue, 8 Jan 2019 23:27:29 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-739-g7452a1e-fmstable-20190103v1 X-Me-Personality: 64588216 Message-Id: <50d80caa-ce1a-44e6-a6d9-2a3b42e91e2c@beta.fastmail.com> In-Reply-To: <18ed534b-fca8-416e-a506-7397dcaac0a2@www.fastmail.com> References: <154651703823.29557.748556981627156046@ietfa.amsl.com> <20190105185050.GB28515@kduck.kaduk.org> <23603.21152.388621.403480@fireball.acr.fi> <23604.47198.503637.521152@fireball.acr.fi> <18ed534b-fca8-416e-a506-7397dcaac0a2@www.fastmail.com> Date: Tue, 08 Jan 2019 23:26:37 -0500 From: "Neil Jenkins" To: "IETF JMAP Mailing List" Content-Type: multipart/alternative; boundary=c7fbed289c1e41789f4d71ddfe2619cd Archived-At: Subject: Re: [Jmap] =?utf-8?q?=5Bsecdir=5D_Secdir_last_call_review_of_draft-i?= =?utf-8?q?etf-jmap-core-12?= X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2019 04:27:32 -0000 --c7fbed289c1e41789f4d71ddfe2619cd Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Wed, 9 Jan 2019, at 7:24 AM, Bron Gondwana wrote: > *Neil:* is this something which you feel strongly enough to insist on = keeping? I've gone back to the original email to try to see what the original com= ment was, before we digressed into arguing over whether people are able = to share individual mailboxes or not. As far as I can see the paragraph = that raised the issue was this in section 1.6.2: *A single set of credentials may provide access to multiple accounts, fo= r example if another user is sharing their mail with the logged in user,= or if there is a group account.* And Tero would like to see the word *mail* changed to *calendar*? I mean= , sure that can work equally well as an example. I don't really see the = need for the change, but if that resolves the issue I'm happy to change = it. *Tero* =E2=80=93 can you please let me know what change you are look= ing for if it's more than this. Neil. --c7fbed289c1e41789f4d71ddfe2619cd Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Wed, 9 = Jan 2019, at 7:24 AM, Bron Gondwana wrote:
N= eil: is this something which you feel strongly enough to insist on k= eeping?

I've gone back t= o the original email to try to see what the original comment was, before= we digressed into arguing over whether people are able to share individ= ual mailboxes or not. As far as I can see the paragraph that raised the = issue was this in section 1.6.2:

A singl= e set of credentials may provide access to multiple accounts, for exampl= e if another user is sharing their mail with the logged in user, or if t= here is a group account.

And Tero would= like to see the word mail changed to calendar? I mean, su= re that can work equally well as an example. I don't really see the need= for the change, but if that resolves the issue I'm happy to change it. = Tero =E2=80=93 can you please let me know what change you are loo= king for if it's more than this.

Neil.
<= /div> --c7fbed289c1e41789f4d71ddfe2619cd-- From nobody Wed Jan 9 09:33:58 2019 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 CE214130EE2 for ; Wed, 9 Jan 2019 09:33:56 -0800 (PST) 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, 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 pEVOD7QglCDw for ; Wed, 9 Jan 2019 09:33:55 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 1754C130EB1 for ; Wed, 9 Jan 2019 09:33:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1547055234; d=isode.com; s=june2016; i=@isode.com; bh=aXYeU+tkV36GNmcDyOM7Lr+qITB3weiiaWYrz8diELA=; 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=CUHujgxORRiJrY9j956pbU52ECDkfO6YJVHQWQHBl2VA7kwgDGE/+On0UxAOGNU7F4mkLS +LuT/0UdEIRXFIf0Ja2NsuI9HviCvTesUZ3o2+rnzh9Gvy7NmWADWrUZUqo/I14rjpREs1 Li/zb14z65p+xB78VPUgqpzLlwl4A44=; 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 ; Wed, 9 Jan 2019 17:33:54 +0000 From: Alexey Melnikov To: jmap@ietf.org Message-ID: <98b0db46-93e6-d03b-085d-15f66912fca6@isode.com> Date: Wed, 9 Jan 2019 17:33:39 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-GB Content-transfer-encoding: quoted-printable Archived-At: Subject: [Jmap] AD review of draft-ietf-jmap-mail-12 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2019 17:33:57 -0000 Hi, The document is nearly ready for IETF LC, but there are a few things=20 that need to be fixed before it would be ready to be reviewed by wider=20 IETF community. The document is not clear that RFC XXXX is draft-ietf-jmap-core-XX (This=20 is only clear for somebody already following JMAP WG). If you don't know=20 how to insert a proper Normative reference to draft-ietf-jmap-core-XX,=20 at least add a note explaining that this is what is intended. In Section 1.3.2: =A0=A0 o=A0 *submissionExtensions*: "String[String[]]" A JMAP implementatio= n =A0=A0=A0=A0=A0 that talks to a Submission [RFC6409] server SHOULD have a =A0=A0=A0=A0=A0 configuration setting that allows an administrator to expos= e a new =A0=A0=A0=A0=A0 submission EHLO capability in this field.=A0 This allows a = JMAP =A0=A0=A0=A0=A0 server to gain access to a new submission extension without= code =A0=A0=A0=A0=A0 changes.=A0 By default, the JMAP server should hide EHLO =A0=A0=A0=A0=A0 capabilities that are to do with the transport mechanism an= d thus =A0=A0=A0=A0=A0 are only relevant to the JMAP server (for example PIPELININ= G, =A0=A0=A0=A0=A0 CHUNKING, or STARTTLS).=A0 Each key in the object is the _e= hlo- =A0=A0=A0=A0=A0 name_, and the value is a list of _ehlo-args_.=A0 Examples = of =A0=A0=A0=A0=A0 Submission extensions to include: =A0=A0=A0=A0=A0 *=A0 FUTURERELEASE ([RFC4865]) =A0=A0=A0=A0=A0 *=A0 SIZE ([RFC1870]) =A0=A0=A0=A0=A0 *=A0 DSN ([RFC3461]) =A0=A0=A0=A0=A0 *=A0 DELIVERYBY ([RFC2852]) =A0=A0=A0=A0=A0 *=A0 MT-PRIORITY ([RFC6710]) Is it worth having a registry for these a la Section 6.2 of RFC 8494? In Section 1.5: =A0=A0 In addition, servers MUST support a psuedo-type called =A0=A0 "EmailDelivery" in the push mechanisms.=A0 The state string for this =A0=A0 MUST change whenever a new Email is added to the store, but SHOULD =A0=A0 NOT change upon any other change to the Email objects. I think an example or pointer to an example would be useful here. I only=20 found an example in JMAP CORE, but I am still not entirely sure what you=20 are describing here. In Section 2: > Servers MUST forbid sibling Mailboxes with the same name. What exactly is this trying to say? Do you mean 2 siblings with the same=20 name? (is it just a way to say that a mailbox name is unique among all=20 of its siblings?) Or does it mean that a mailbox A can't have sibling A? If yes, then why? RFC 4314 (IMAP ACL) needs to be referenced at least Informatevely (due=20 to Myrights command reference). IMAP4rev1 (RFC 3501) should be an Informative reference (due to=20 referencing the following terms: subscriptions, internal date). In Section 4.1.2.1: >=A0=A0 A server MAY use heuristics to >=A0=A0 determine a charset and decode the octets, or MAY replace any octet >=A0=A0 or octet run with the high bit set that violates UTF-8 syntax with >=A0=A0 the unicode replacement character (U+FFFD). Do we really want to encourage the "MAY use heuristics" part? Such email=20 messages are non compliant and thus not in scope for this document! So RAW will typically have the leading space, as most generated messages=20 have a space after ":" that terminates the header field name. Is it=20 worth pointing this out to implementors? In Section 4.1.2.2: >5. Any [RFC6532] UTF-8 values decoded. Decoded from what? They are already in UTF-8! =A0=A0 o=A0 Comment RFC 5322 defines "Comments" header field (note that it is plural). Also, what about "Keywords" header field? Is it worth explicitly mentioning Content-Description header field here=20 as well? In Section 4.1.2.3: "Any [RFC6532] UTF-8 values MUST be decoded." -- again, decoded from what? Is RFC 2231 encoding allowed in this and the following section? In 4.1.3: asText and asAddresses is not defined in the document. Did you mean: 4.1.2.2.=A0 Text 4.1.2.3.=A0 Addresses ? If yes, you need to clarify this somewhere. In Section 4.1.4: You need to define handling for unrecognised Content-Transfer-Encoding=20 values here. "cid:" needs to Normatively reference RFC 2392. HTML needs a reference=20 as well. In Section 4.2 (and similar text in 4.9): maxBodyValueBytes: =A0"The server MUST ensure the truncation results in valid UTF-8 and does= =20 not occur mid-codepoint." -- The document needs to make sure that this is only true for body parts=20 which are known to be textual (e.g. text/plain, text/html, XML, JSON).=20 If a body part is a JPEG image, this requirement doesn't make sense. In Sections 4.8/4.9: The document needs to explicitly allow EAI messages, not just RFC 5322=20 format. In Section 5: HTML is now definitely a Normative reference. More details of what is=20 expected in HTML escaping, other than wrap? In Section 7: Are "MDN" and "DSN" blobIds referencing only the machine parseable part=20 or the whole multipart/report coming back? I think the document should=20 clarify this and (ideally) give some examples. End of Section 7.5: =A0"The server MAY choose to localise this string into the user's=20 preferred language, if known." How can this be done? Should the identity object contain some preferred=20 language tag(s)? This needs a bit more thought. In Section 9.3: SMTP XCLIENT should be an Informative reference. In Section 10.4.4 (Registration of JMAP keyword '$answered') =A0=A0 Security Considerations: A server implementing this keyword as a =A0=A0 shared keyword may disclose that a user considers the message as =A0=A0 flagged for urgent/special attention. This looks like a cut & paste error from the text specified for $flagged. =A0=A0 This information would be =A0=A0 exposed to other users with read permission for the mailbox keywords= . Best Regards, Alexey From nobody Wed Jan 9 14:45:36 2019 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 C1927126DBF for ; Wed, 9 Jan 2019 14:45:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 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_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=edhPu4c3; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=qiGNzkF8 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 y7Q0mbUgNuIl for ; Wed, 9 Jan 2019 14:45:34 -0800 (PST) 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 EB5EF124D68 for ; Wed, 9 Jan 2019 14:45:33 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 3752C23144 for ; Wed, 9 Jan 2019 17:45:32 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Wed, 09 Jan 2019 17:45:32 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:subject:content-type; s=fm1; bh=qwYR8UD11ywgkpVGLV/gZ1CXtEGj z5r33+og1yBE8eg=; b=edhPu4c3FvqG8+o8QQbF7LZxggesC0agQTg2bvf9jROB eZEBRGQUrr2BOrkg5ZT+E+QfXkkIkbAJdgd3oC+XZ3WI3F8Eosdzevp28vtEPc2a Tt5w6Ds3hClnXaP2z0A2zbXuMaDH87lzvjS68zYOMPSiDBbWdVmKPq3/UNRSRzjr LwxjQ+6sSrTJ6Q6/fONVYI8+z9DbH6VYF7r4Dz5nT5utaUjZkaX0McAoTuDY0m2V fCvWX+feaEhV5rRWzk6tBPEE0rXDuAMxdEhHG0EJv/3mW28AZ5Q+soNyvIpaP90J NUAxfprkBX3Wu4PH1sXXry7mEyFj+0qpK/jhFKWApA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=qwYR8UD11ywgkpVGL V/gZ1CXtEGjz5r33+og1yBE8eg=; b=qiGNzkF8R4RyhdE2Fx/ZKuCIrzm4KrFJp PXADov4YZHxV0LwvuT3wx0RJmPUz04O3d4hap67vWfiPT5b8p4R2EDlegMjNvHhM 2k2+BLumVyUDth9+gKmjwsRxY7ssi7PStTpsTGWMvokbPyX5wz1/cejs5sabUp3O vJZi4ySTr0udK4ZMdFI86HrqOi1T8Z2YsPeXsFGYI++SLieymoZjPEn0aNiFKuV0 9ZIYFMvQVs4Q3D3gZJoObNIa2V0X64IMTMDBdxnOtAr6kCkRcKwKn4y62IGFw7eH fGjJ5gbTjkY770EW3Z2eBVxjpQxLaOM5aG9OlvBypBPeMEjI+rgWw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrfedugdduieeiucdltddurdegtdekrddttd dmucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhht necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucffohhmrghinhepghhithhhuhgsrdgtoh hmnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgsehfrghsthhmrghilhhtvggr mhdrtghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id B153F203F1; Wed, 9 Jan 2019 17:45:31 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-739-g7452a1e-fmstable-20190103v1 X-Me-Personality: 56629417 Message-Id: In-Reply-To: <98b0db46-93e6-d03b-085d-15f66912fca6@isode.com> References: <98b0db46-93e6-d03b-085d-15f66912fca6@isode.com> Date: Wed, 09 Jan 2019 17:45:29 -0500 From: "Bron Gondwana" To: jmap@ietf.org Content-Type: multipart/alternative; boundary=fa842d9f95ea4155801c0f071089e9c6 Archived-At: Subject: Re: [Jmap] AD review of draft-ietf-jmap-mail-12 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2019 22:45:36 -0000 --fa842d9f95ea4155801c0f071089e9c6 Content-Type: text/plain On Thu, Jan 10, 2019, at 04:34, Alexey Melnikov wrote: > Is it worth having a registry for these a la Section 6.2 of RFC 8494? Do we want to do this afterwards and reference both JMAP and SMTP-SUBMISSION in an RFC which collects up the current status and bootstraps the registry, like we did for \Important? I ask because I'm not sure if we should do this work in JMAP or EXTRA. > > In Section 2: > > > Servers MUST forbid sibling Mailboxes with the same name. > > What exactly is this trying to say? Do you mean 2 siblings with the same > name? (is it just a way to say that a mailbox name is unique among all > of its siblings?) > > Or does it mean that a mailbox A can't have sibling A? If yes, then why? It was the first of those, no two folders with the same (parentId, name) tuple. > > RFC 4314 (IMAP ACL) needs to be referenced at least Informatevely (due > to Myrights command reference). This got discussed during the core review. I believe it's already fixed. > IMAP4rev1 (RFC 3501) should be an Informative reference (due to > referencing the following terms: subscriptions, internal date). Yep, good point: https://github.com/jmapio/jmap/issues/277 > > In Section 4.1.2.1: > > > A server MAY use heuristics to > > determine a charset and decode the octets, or MAY replace any octet > > or octet run with the high bit set that violates UTF-8 syntax with > > the unicode replacement character (U+FFFD). > > Do we really want to encourage the "MAY use heuristics" part? Such email > messages are non compliant and thus not in scope for this document! Leaving this one for Neil to comment on before creating an issue > > So RAW will typically have the leading space, as most generated messages > have a space after ":" that terminates the header field name. Is it > worth pointing this out to implementors? That's sounds like a definitely worthwhile thing to point out! https://github.com/jmapio/jmap/issues/278 > In Section 4.1.2.2: > > >5. Any [RFC6532] UTF-8 values decoded. > > Decoded from what? They are already in UTF-8! > > o Comment > > RFC 5322 defines "Comments" header field (note that it is plural). > > Also, what about "Keywords" header field? > > Is it worth explicitly mentioning Content-Description header field here > as well? > > > In Section 4.1.2.3: > > "Any [RFC6532] UTF-8 values MUST be decoded." -- again, decoded from what? > > > Is RFC 2231 encoding allowed in this and the following section? > > > In 4.1.3: > > asText and asAddresses is not defined in the document. Did you mean: > > 4.1.2.2. Text > > 4.1.2.3. Addresses > > ? > > If yes, you need to clarify this somewhere. > > > In Section 4.1.4: > > You need to define handling for unrecognised Content-Transfer-Encoding > values here. > > > "cid:" needs to Normatively reference RFC 2392. HTML needs a reference > as well. https://github.com/jmapio/jmap/issues/279 https://github.com/jmapio/jmap/issues/280 > In Section 4.2 (and similar text in 4.9): > > maxBodyValueBytes: > > "The server MUST ensure the truncation results in valid UTF-8 and does > not occur mid-codepoint." -- > > The document needs to make sure that this is only true for body parts > which are known to be textual (e.g. text/plain, text/html, XML, JSON). > If a body part is a JPEG image, this requirement doesn't make sense. The "bodyValues" is only defined for text/ parts I believe: o *bodyValues*: "String[EmailBodyValue]" (immutable) This is a map of _partId_ to an *EmailBodyValue* object for none, some or all "text/*" parts. Which parts are included and whether the value is truncated is determined by various arguments to _Email/get_ and _Email/parse_. An *EmailBodyValue* object has the following properties: Hence it always contains UTF-8 data. > > > In Sections 4.8/4.9: > > The document needs to explicitly allow EAI messages, not just RFC 5322 > format. https://github.com/jmapio/jmap/issues/281 > > In Section 5: > > HTML is now definitely a Normative reference. More details of what is > expected in HTML escaping, other than wrap? > > > In Section 7: > > Are "MDN" and "DSN" blobIds referencing only the machine parseable part > or the whole multipart/report coming back? I think the document should > clarify this and (ideally) give some examples. https://github.com/jmapio/jmap/issues/282 > > End of Section 7.5: > > "The server MAY choose to localise this string into the user's > preferred language, if known." > > How can this be done? Should the identity object contain some preferred > language tag(s)? This needs a bit more thought. > https://github.com/jmapio/jmap/issues/283 I also commented that it might be better to have the user's preferred language as part of core rather than part of mail. > In Section 9.3: SMTP XCLIENT should be an Informative reference. https://github.com/jmapio/jmap/issues/284 > > In Section 10.4.4 (Registration of JMAP keyword '$answered') > > Security Considerations: A server implementing this keyword as a > shared keyword may disclose that a user considers the message as > flagged for urgent/special attention. > > This looks like a cut & paste error from the text specified for $flagged. > > This information would be > exposed to other users with read permission for the mailbox keywords. https://github.com/jmapio/jmap/issues/285 Phew! Thanks for the detailed review Alexey. Cheers, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --fa842d9f95ea4155801c0f071089e9c6 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Thu, Jan 10, 2019, at 04:34, Alexey Melnikov wrote:
=
Is it worth having a registry for these a la Section 6.= 2 of RFC 8494?
<= br>
Do we want to do this afterwa= rds and reference both JMAP and SMTP-SUBMISSION in an RFC which collects= up the current status and bootstraps the registry, like we did for \Imp= ortant?  I ask because I'm not sure if we should do this work in JM= AP or EXTRA.


In Section 2:
=

> Servers MUST forbid sibling Mailboxes with the same name.
=

What exactly is this trying to say? Do you mean 2 siblings w= ith the same 
name? (is = it just a way to say that a mailbox name is unique among all 
of its siblings?)

O= r does it mean that a mailbox A can't have sibling A? If yes, then why?<= br>

It was the first of those, no two folders wi= th the same (parentId, name) tuple.


= RFC 4314 (IMAP ACL) needs to be referenced at least Informatevely (due&n= bsp;
to Myrights command refe= rence).

This got discussed during the core r= eview.  I believe it's already fixed.

IMAP4rev1 (RFC 3501) should be an Inf= ormative reference (due to 
referencing the following terms: subscriptions, internal date).
<= /div>

Yep, good point:



In Section 4.1.2.1:
<= /div>

>   A server MAY use heuristics to
>   determine a charset and d= ecode the octets, or MAY replace any octet
>   or octet run with the high bit set that v= iolates UTF-8 syntax with
>= ;   the unicode replacement character (U+FFFD).

Do we really want to encourage the "MAY use heuristics" part? Such emai= l 
messages are non comp= liant and thus not in scope for this document!

Leaving this one for Neil to comment on before creating an issue
<= /div>


So RAW will typically have the leading s= pace, as most generated messages 
have a space after ":" that terminates the header field name. = Is it 
worth pointing th= is out to implementors?

That's sounds like a= definitely worthwhile thing to point out!


In Section 4.1.2.2:
>5. Any [RFC6532] UTF-8 valu= es decoded.

Decoded from what? They are already in UTF-8!=

   o  Comment

RFC 5322 def= ines "Comments" header field (note that it is plural).

Al= so, what about "Keywords" header field?

Is it worth expli= citly mentioning Content-Description header field here 
as well?


In Section 4.1.2.3:

"Any [RFC= 6532] UTF-8 values MUST be decoded." -- again, decoded from what?


Is RFC 2231 encodin= g allowed in this and the following section?


In 4.1.3:

asText and asAd= dresses is not defined in the document. Did you mean:

4.1= .2.2.  Text

4.1.2.3.  Addresses

= ?

If yes, you need to clarify this somewhere.


In Section 4.1.4:

You need to define handling for unrecognised Content-Transfer-E= ncoding 
values here.


"cid:" needs to= Normatively reference RFC 2392. HTML needs a reference 
<= div style=3D"font-family:Arial;">as well.

https://github.com/j= mapio/jmap/issues/279

=
In Section 4.2 (and similar text in 4.9):

maxBodyValueBytes:

 "The server MUST ensure the tr= uncation results in valid UTF-8 and does 
not occur mid-codepoint." --

The docume= nt needs to make sure that this is only true for body parts 
which are known to be textual (e.g.= text/plain, text/html, XML, JSON). 
If a body part is a JPEG image, this requirement doesn't ma= ke sense.

The "bodyValues" is only defined f= or text/ parts I believe:
 o  *bodyValues*: "String[EmailBodyValue]" (immutable) This =
is a map
      of _partId_ to an *EmailBodyValue* object for none, some or all
      "text/*" parts.  Which parts are included and whether the value is=

      truncated is determined by various arguments to _Email/get_ and
      _Email/parse_.  An *EmailBodyValue* object has the following
      properties:

<= div style=3D"font-family:Arial;">Hence it always contains UTF-8 data.


=

In Sections 4.8/4.9:
The document needs to explicit= ly allow EAI messages, not just RFC 5322 
format.



In Section 5:

HTML is now definitely a Normative reference. More details of what is=  
expected in HTML escap= ing, other than <mark> wrap?


In Section 7:

Are "MDN" and "DSN" bl= obIds referencing only the machine parseable part 
or the whole multipart/report coming back? I = think the document should 
clarify this and (ideally) give some examples.
=



En= d of Section 7.5:

<= div style=3D"font-family:Arial;"> "The server MAY choose to localis= e this string into the user's 
preferred language, if known."

How can this be don= e? Should the identity object contain some preferred 
language tag(s)? This needs a bit more tho= ught.

=


I also commented that i= t might be better to have the user's preferred language as part of core = rather than part of mail.
In Section 9.3: SMTP XCLIENT should be an Informative = reference.

<= /div>
https://github.com/jmapio/jmap/issues/284


In Section 10.4.4 (Registration of JMAP k= eyword '$answered')

   Security Considerations:= A server implementing this keyword as a
   shared keyword may disclose that a user conside= rs the message as
  = ; flagged for urgent/special attention.

This looks like a= cut & paste error from the text specified for $flagged.

   This information would be
   exposed to other users with read permission f= or the mailbox keywords.


Phew!  Thanks for the detailed review Alexe= y.

Cheers,
Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com
=

--fa842d9f95ea4155801c0f071089e9c6-- From nobody Wed Jan 9 19:42:57 2019 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 B67C7131113 for ; Wed, 9 Jan 2019 19:42:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 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_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, 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=fastmailteam.com header.b=m9IeP+ai; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=kFHWRCp9 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 JTGxsyS6UYzP for ; Wed, 9 Jan 2019 19:42:52 -0800 (PST) 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 B3AAF124408 for ; Wed, 9 Jan 2019 19:42:52 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id C7FDA2311B; Wed, 9 Jan 2019 22:42:50 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Wed, 09 Jan 2019 22:42:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:cc:subject:content-type; s=fm1; bh=PQ6+QPy8YH/D7voPfpJYy1PzN 7NQlHZ7C6RWyjQ6ZVo=; b=m9IeP+aidLR5rbZfVN5hc7P9CqGvjNncYcv7+uyNo qCvnM+VDauEOCrLZv4IpM8/Rf7q9fL2q1DLDtZWWi7iNOkpZldVwC3mjWc3h0mS2 VVVgT3XKbnUvH8aKQ0J187WAWPrbHMwU6G+9QMAk+Hqpc3TjgrjCBW2vL4qh+eWm I12Nna8/j+QGTU8pKFzTUWReYReB3meF7/GzWMqRMJSOKBunFm9K0rifzTyQOV/Z EbedsJyQK4qfee7GTK+/InP8DOm93sRx5bpVwosuoESyrosMV+CaXz9RnFa6lPAf V5TzVjtJ7k3UA3TZC6rE0eMmADLm4hDCncehaMaQKkcag== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=PQ6+QPy8YH/D7voPf pJYy1PzN7NQlHZ7C6RWyjQ6ZVo=; b=kFHWRCp9YGkF00mtaBO4hXvkW4ffSbhmV PiFXTkf7Qs/yJuHCbcJT3uH/bj0cnT/mMcV9s7udQof6ONrAFYKi50fk9XSPsX3R O8hetQ6zetPnCPGq2J7NW6JorrbkE7rWMPMfDABNBpfPzZxfmReCljowRsQA7TVT Aw3qokq/mOt8/ZI8X0v22it5dlWng31wyboynjspf2pZS5eq5x7Us3zTeP4mfCVL SOhmUpovQMe4AgbQ05dr1UZU892vX17MtWZtjSpSQWtKWGO5AAkBRYYbI7+GJiH8 gfvcIipYnWorsf7APuSykQM6UcvClWvLLQNm55sTUkl0ms4sqXS4Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrfedvgdeiudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepofgfkfgjfhffhf fvufgtsegrtderreerreejnecuhfhrohhmpedfpfgvihhlucflvghnkhhinhhsfdcuoehn vghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomheqnecuffhomhgrihhnpehgihhthh husgdrtghomhdpjhhmrghprdhiohenucfrrghrrghmpehmrghilhhfrhhomhepnhgvihhl jhesfhgrshhtmhgrihhlthgvrghmrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id EC4CC203F1; Wed, 9 Jan 2019 22:42:49 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-739-g7452a1e-fmstable-20190103v1 X-Me-Personality: 64588216 Message-Id: In-Reply-To: <98b0db46-93e6-d03b-085d-15f66912fca6@isode.com> References: <98b0db46-93e6-d03b-085d-15f66912fca6@isode.com> Date: Wed, 09 Jan 2019 22:42:49 -0500 From: "Neil Jenkins" To: "Alexey Melnikov" Cc: "IETF JMAP Mailing List" Content-Type: multipart/alternative; boundary=aecf8264a8d14081a1d4350c01a213ec Archived-At: Subject: Re: [Jmap] AD review of draft-ietf-jmap-mail-12 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2019 03:42:56 -0000 --aecf8264a8d14081a1d4350c01a213ec Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Thu, 10 Jan 2019, at 4:34 AM, Alexey Melnikov wrote: > The document is not clear that RFC XXXX is draft-ietf-jmap-core-XX This is now referenced properly. =20 > By default, the JMAP server should hide EHLO > capabilities that are to do with the transport mechanism and thus > are only relevant to the JMAP server >=20 > Is it worth having a registry for these a la Section 6.2 of RFC 8494? I don't feel a need for one strongly, but we can add one if you think it= 's necessary? > In addition, servers MUST support a psuedo-type called > "EmailDelivery" in the push mechanisms.=20 >=20 > I think an example or pointer to an example would be useful here. I've added the following example to the document; does this clarify it f= or you? *The client has registered for push notifications just for the `EmailDel= ivery` type (see [@!I-D.ietf-jmap-core] for details of the push system).= The user marks an email as read on another device, causing the state st= ring for the `Email` type to change, however as nothing new was added to= the store the `EmailDelivery` state does not change and nothing is push= ed to the client. A new message arrives in the user's inbox, again causi= ng the `Email` state to change. This time the `EmailDelivery` state also= changes, and a StateChange object is pushed to the client with the new = state string. The client may then resync to fetch the new message immedi= ately.* > In Section 2: >=20 > > Servers MUST forbid sibling Mailboxes with the same name. > What exactly is this trying to say? I have rewritten this to say: *There MUST NOT be two mailboxes with both the same parent and the same = name.* Is that clear? (IMAP is path based so naturally you cannot have two sibl= ing mailboxes with the same name; but JMAP is id based so in theory you = could. For IMAP compatibility, and to avoid user confusion, this is forb= idden by fiat.) > RFC 4314 (IMAP ACL) needs to be referenced at least Informatevely (du= e=20 > to Myrights command reference). As Bron mentioned, this has already done following the secdir core revie= w. > IMAP4rev1 (RFC 3501) should be an Informative reference (due to=20 > referencing the following terms: subscriptions, internal date). Added. > > A server MAY use heuristics to > > determine a charset and decode the octets, or MAY replace any octet > > or octet run with the high bit set that violates UTF-8 syntax with > > the unicode replacement character (U+FFFD). >=20 > Do we really want to encourage the "MAY use heuristics" part? Such ema= il=20 > messages are non compliant and thus not in scope for this document! Well, they appear in the real world so servers do need to deal with them= . Using heuristics to determine what the sender intended often provides = the best user experience (customers tend not to care that it was the sen= der that sent something broken=E2=80=A6). However, I'm not strongly atta= ched. Would you prefer me to replace this with the following? *A server SHOULD replace any octet or octet run with the high bit set th= at violates UTF-8 syntax with the unicode replacement character (U+FFFD)= .** * > So RAW will typically have the leading space, as most generated messag= es=20 > have a space after ":" that terminates the header field name. Is it=20= > worth pointing this out to implementors? Doesn't hurt. I have added: *This form will typically have a leading space, as most generated messag= es** * *insert a space after the colon that terminates the header field name.* > >5. Any [RFC6532] UTF-8 values decoded. > Decoded from what? They are already in UTF-8! The idea was that your implementation has a unicode string implementatio= n that may not be UTF-8; that's just one possible encoding. You are deco= ding everything into your internal string format, normalising the unicod= e (next step) and then it will be encoded as UTF-8 when output as JSON a= s this is the encoding used for that. However, I have now just removed this step as I think it just confuses t= he matter and the step is obvious if required. >=20 > o Comment >=20 > RFC 5322 defines "Comments" header field (note that it is plural). Thanks, fixed. > Also, what about "Keywords" header field? Sure, I've added that. > Is it worth explicitly mentioning Content-Description header field her= e=20 > as well? The spec currently only has restrictions on RFC5322 and RFC2369 headers.= Other headers such as this one are not explicitly forbidden so may be u= sed with the form already. So I don't think it's necessary to mention ex= plicitly. > In Section 4.1.2.3: >=20 > "Any [RFC6532] UTF-8 values MUST be decoded." -- again, decoded from w= hat? Same as above; I have now removed. > Is RFC 2231 encoding allowed in this and the following section? I don't think so, as To, Cc etc. don't have parameter values. Or have I = got that wrong? >=20 > In 4.1.3: >=20 > asText and asAddresses is not defined in the document. Did you mean: This is defined at the top of page 26 in 4.1.3: o *:as{header-form}* This means the value is in a parsed form, where "{header-form}" is one of the parsed-form names specified above. If not given, the value is in _Raw_ form. > In Section 4.1.4: >=20 > You need to define handling for unrecognised Content-Transfer-Encoding= =20 > values here. I have added *If the transfer encoding is unknown, it is treated as though it had no = transfer-encoding.* > "cid:" needs to Normatively reference RFC 2392. HTML needs a reference= =20 > as well. Added. > In Section 4.2 (and similar text in 4.9): >=20 > maxBodyValueBytes: >=20 > "The server MUST ensure the truncation results in valid UTF-8 and doe= s=20 > not occur mid-codepoint." -- >=20 > The document needs to make sure that this is only true for body parts=20= > which are known to be textual (e.g. text/plain, text/html, XML, JSON).= =20 > If a body part is a JPEG image, this requirement doesn't make sense. As Bron pointed out, bodyValue is only returned like this for text/* typ= es. > In Sections 4.8/4.9: >=20 > The document needs to explicitly allow EAI messages, not just RFC 5322= =20 > format. I'm not entirely sure how to specify this. I have added this sentence to= the introduction to each of these methods: *The server SHOULD support messages with [@!RFC6532] EAI headers.* Is that sufficient? (And should it be a MUST?) > In Section 5: >=20 > HTML is now definitely a Normative reference. More details of what is=20= > expected in HTML escaping, other than wrap? Good, catch this was inadequately specified. I have rewritten it as: *subject*: `String|null` If text from the filter matches the subject, this is the subject of the = email with the following transformations: 1. Any instance of the following three characters MUST be replaced by a= n appropriate HTML entity: & (ampersand), < (less-than sign), and > (gre= ater-than sign). Other characters MAY also be replaced with an HTML enti= ty form. 2. The matching words/phrases from the filter are wrapped in [@!HTML] `= ` tags. If the subject does not match text from the filter, this property is `nu= ll`. *preview*: `String|null` If text from the filter matches the plain-text or HTML body, this is the= relevant section of the body (converted to plain text if originally HTM= L), with the same transformations as the *subject* property. It MUST NOT= be bigger than 255 octets in size. If the body does not contain a match= for the text from the filter, this property is `null`. > In Section 7: >=20 > Are "MDN" and "DSN" blobIds referencing only the machine parseable par= t=20 > or the whole multipart/report coming back? I think the document should= =20 > clarify this and (ideally) give some examples. This is intended to be the whole MIME message a with a top-level content= -type of multipart/report; I have added the following line to the two pr= operties to clarify: *The blob is the whole MIME message (with a top-level content-type of mu= ltipart/report), as received.* > End of Section 7.5: >=20 > "The server MAY choose to localise this string into the user's=20 > preferred language, if known." >=20 > How can this be done? This is just acknowledging the server may have some kind of out-of-band = knowledge about the authenticated user and if so should use it to increa= se the likelihood of presenting an understandable error to the user. I t= hink anything more is out of scope of the current specification. =20 > In Section 9.3: SMTP XCLIENT should be an Informative reference. Done. > In Section 10.4.4 (Registration of JMAP keyword '$answered') >=20 > Security Considerations: A server implementing this keyword as a > shared keyword may disclose that a user considers the message as > flagged for urgent/special attention. >=20 > This looks like a cut & paste error from the text specified for $flagg= ed. Yes, fixed. Thanks for the review Alexey. All fixes are pushed to the Git repo for the spec and live on jmap.io ; I'll cut a new IETF draft once the remaini= ng clarifications have been settled. Neil. --aecf8264a8d14081a1d4350c01a213ec Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Thu, 10 Jan = 2019, at 4:34 AM, Alexey Melnikov wrote:
The document is not clear that RFC XXXX = is draft-ietf-jmap-core-XX

Thi= s is now referenced properly.

    By default, the JMAP server should hide EHLO
      capabilities that are to do = with the transport mechanism and thus
   &n= bsp;  are only relevant to the JMAP server

=
Is it worth having a registry for these a la Section 6.2 of RFC 849= 4?

I don't feel a need for one= strongly, but we can add one if you think it's necessary?

   In addition, serv= ers MUST support a psuedo-type called
   "EmailD= elivery" in the push mechanisms. 

I th= ink an example or pointer to an example would be useful here.
<= /blockquote>

I've added the following example to the = document; does this clarify it for you?

= The client has registered for push notifications just for the `EmailDeli= very` type (see [@!I-D.ietf-jmap-core] for details of the push system). = The user marks an email as read on another device, causing the state str= ing for the `Email` type to change, however as nothing new was added to = the store the `EmailDelivery` state does not change and nothing is pushe= d to the client. A new message arrives in the user's inbox, again causin= g the `Email` state to change. This time the `EmailDelivery` state also = changes, and a StateChange object is pushed to the client with the new s= tate string. The client may then resync to fetch the new message immedia= tely.

In Sec= tion 2:

> Servers MUST forbid sibling Ma= ilboxes with the same name.
What exactly is this trying to= say?

I have rewritten this to= say:

There MUST NOT be two mailboxes wi= th both the same parent and the same name.

<= div>Is that clear? (IMAP is path based so naturally you cannot have two = sibling mailboxes with the same name; but JMAP is id based so in theory = you could. For IMAP compatibility, and to avoid user confusion, this is = forbidden by fiat.)

RFC 4314 (IMAP ACL) needs to be referenced at least Informatevely (d= ue 
to Myrights command reference).

As Bron mentioned, this has already done follow= ing the secdir core review.

IMAP4rev1 (RFC 3501) should be an Informative reference (due = to 
referencing the following terms: subscriptions, i= nternal date).

Added.

>   A server= MAY use heuristics to
>   determine a charse= t and decode the octets, or MAY replace any octet
>&nbs= p;  or octet run with the high bit set that violates UTF-8 syntax w= ith
>   the unicode replacement character (U+= FFFD).

Do we really want to encourage the "= MAY use heuristics" part? Such email 
messages are no= n compliant and thus not in scope for this document!

Well, they appear in the real world so servers do= need to deal with them. Using heuristics to determine what the sender i= ntended often provides the best user experience (customers tend not to c= are that it was the sender that sent something broken=E2=80=A6). However= , I'm not strongly attached. Would you prefer me to replace this with th= e following?

A server SHOULD replace any= octet or octet run with the high bit set that violates UTF-8 syntax wit= h the unicode replacement character (U+FFFD).
<= br>
So RAW will typically have the l= eading space, as most generated messages 
have a spac= e after ":" that terminates the header field name. Is it 
=
worth pointing this out to implementors?

Doesn't hurt. I have added:

This form will typically have a leading space, as most generated mes= sages
insert a space after the colon that te= rminates the header field name.

>5. Any [RFC6532] UTF-8 values decoded.
<= div>Decoded from what? They are already in UTF-8!
=

The idea was that your implementation has a unicode = string implementation that may not be UTF-8; that's just one possible en= coding. You are decoding everything into your internal string format, no= rmalising the unicode (next step) and then it will be encoded as UTF-8 w= hen output as JSON as this is the encoding used for that.
=
However, I have now just removed this step as I think it = just confuses the matter and the step is obvious if required.
<= div>

  = o  Comment

RFC 5322 defines "Comments= " header field (note that it is plural).

=
Thanks, fixed.

Also, what about "Keywords" header field?

Sure, I've added that.

Is it worth explicitly mentioning Content-Des= cription header field here 
as well?

The spec currently only has restrictions on RF= C5322 and RFC2369 headers. Other headers such as this one are not explic= itly forbidden so may be used with the form already. So I don't think it= 's necessary to mention explicitly.

In Section 4.1.2.3:

"Any= [RFC6532] UTF-8 values MUST be decoded." -- again, decoded from what?

Same as above; I have now remov= ed.

Is RFC 2231 e= ncoding allowed in this and the following section?

I don't think so, as To, Cc etc. don't have paramet= er values. Or have I got that wrong?


In 4.1.3:

asText and asAddresses is not defined in the document. Did you mean:

This is defined at the top of p= age 26 in 4.1.3:

o  *:as{header-form}* This means =
the value is in a parsed form, where
      "{header-form}" is one of the parsed-form names specified above.
      If not given, the value is in _Raw_ form.

=
In Section 4.1.4:

You need to define handling for unrecognised Content-Transfer-Enco= ding 
values here.

I have added

If the transfer enc= oding is unknown, it is treated as though it had no transfer-encoding.

"cid:" needs t= o Normatively reference RFC 2392. HTML needs a reference 
=
as well.

Added.

In Section 4.2 (and similar te= xt in 4.9):

maxBodyValueBytes:

 "The server MUST ensure the truncation results in= valid UTF-8 and does 
not occur mid-codepoint." --

The document needs to make sure that this is= only true for body parts 
which are known to be text= ual (e.g. text/plain, text/html, XML, JSON). 
If a bo= dy part is a JPEG image, this requirement doesn't make sense.
<= /blockquote>

As Bron pointed out, bodyValue is only r= eturned like this for text/* types.

In Sections 4.8/4.9:

The doc= ument needs to explicitly allow EAI messages, not just RFC 5322 
format.

I'm not en= tirely sure how to specify this. I have added this sentence to the intro= duction to each of these methods:

The se= rver SHOULD support messages with [@!RFC6532] EAI headers.
=

Is that sufficient? (And should it be a MUST?)

In Section 5:

HTML is now definitely a Normative reference. More = details of what is 
expected in HTML escaping, other = than <mark> wrap?

Good, = catch this was inadequately specified. I have rewritten it as:
=

subject: String|null
If t= ext from the filter matches the subject, this is the subject of the emai= l with the following transformations:
  1. Any instance of t= he following three characters MUST be replaced by an appropriate HTML en= tity: & (ampersand), < (less-than sign), and > (greater-than s= ign). Other characters MAY also be replaced with an HTML entity form.
  2. The matching words/phrases from the filter are wrapped in [@!H= TML] <mark></mark> tags.
If the= subject does not match text from the filter, this property is `null`.

preview: String|null
<= div>If text from the filter matches the plain-text or HTML body, this is= the relevant section of the body (converted to plain text if originally= HTML), with the same transformations as the *subject* property. It MUST= NOT be bigger than 255 octets in size. If the body does not contain a m= atch for the text from the filter, this property is `null`.

In Section 7:
<= br>
Are "MDN" and "DSN" blobIds referencing only the machine p= arseable part 
or the whole multipart/report coming b= ack? I think the document should 
clarify this and (i= deally) give some examples.

Th= is is intended to be the whole MIME message a with a top-level cont= ent-type of multipart/report; I have added the following line to the two= properties to clarify:

The blob is the = whole MIME message (with a top-level content-type of multipart/repo= rt), as received.

=
End of Section 7.5:

 "The server = MAY choose to localise this string into the user's 
p= referred language, if known."

How can this = be done?

This is just acknowle= dging the server may have some kind of out-of-band knowledge about the a= uthenticated user and if so should use it to increase the likelihood of = presenting an understandable error to the user. I think anything more is= out of scope of the current specification.

In Section 9.3: SMTP XCLIENT should be an In= formative reference.

Done.

In Section 10.4.4 (Regis= tration of JMAP keyword '$answered')

 =   Security Considerations: A server implementing this keyword as a<= br>
   shared keyword may disclose that a user consi= ders the message as
   flagged for urgent/specia= l attention.

This looks like a cut & pa= ste error from the text specified for $flagged.

Yes, fixed.

Thanks for th= e review Alexey. All fixes are pushed to the Git repo for the spec and live on jmap.io; I'll cut a new IETF draft o= nce the remaining clarifications have been settled.

Neil.
--aecf8264a8d14081a1d4350c01a213ec-- From nobody Thu Jan 10 02:57:58 2019 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 8FBF6130DC8 for ; Thu, 10 Jan 2019 02:57:56 -0800 (PST) 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, 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 3bPOlGtAXVTP for ; Thu, 10 Jan 2019 02:57:54 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id C43BE1271FF for ; Thu, 10 Jan 2019 02:57:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1547117872; d=isode.com; s=june2016; i=@isode.com; bh=Qb7z0v1G2cOfpjcvFR7XEPeNGUzkansXd7FcS9L2T9I=; 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=mOrw+3XwtdCf4g1zIGn1w4BQ8jfzn+EFLi2vlgTCvu9dZDPbVPOG4+7qZ18RCRmeRfxZ7w ak/ilAg4QD1KAxvDjGSh1Tx1Vuo9juAi6Es9pGCZ/T+JQAPa/9iobX6cxJ08/n7dAlclh7 BPOI3AnLYs9KjbbF/Ku0zwUw4zimSxk=; 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 ; Thu, 10 Jan 2019 10:57:52 +0000 To: Neil Jenkins Cc: IETF JMAP Mailing List References: <98b0db46-93e6-d03b-085d-15f66912fca6@isode.com> From: Alexey Melnikov Message-ID: <0f1c0d19-f473-c7f6-11e2-a60f12b5a106@isode.com> Date: Thu, 10 Jan 2019 10:57:30 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------110BE3B836CAE9356D2E2F60" Content-Language: en-GB Archived-At: Subject: Re: [Jmap] AD review of draft-ietf-jmap-mail-12 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2019 10:57:56 -0000 --------------110BE3B836CAE9356D2E2F60 Content-Type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: quoted-printable Hi Neil, Below I removed comments from my reply where we are in agreement: On 10/01/2019 03:42, Neil Jenkins wrote: > On Thu, 10 Jan 2019, at 4:34 AM, Alexey Melnikov wrote: >> =C2=A0 =C2=A0 By default, the JMAP server should hide EHLO >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 capabilities that are to do with the trans= port mechanism and thus >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 are only relevant to the JMAP server >> >> Is it worth having a registry for these a la Section 6.2 of RFC 8494? > > I don't feel a need for one strongly, but we can add one if you think=20 > it's necessary? This is a possible interop issue and I would rather have a registry. I=20 am Ok with Bron's proposal to define it in another document. >> =C2=A0=C2=A0 In addition, servers MUST support a psuedo-type called >> =C2=A0=C2=A0 "EmailDelivery" in the push mechanisms. >> >> I think an example or pointer to an example would be useful here. > > I've added the following example to the document; does this clarify it=20 > for you? > > /The client has registered for push notifications just for the=20 > `EmailDelivery` type (see [@!I-D.ietf-jmap-core] for details of the=20 > push system)./ This mostly works, but EmailDelivery is not defined in CORE, it is only=20 shown there in examples. / / > /The user marks an email as read on another device, causing the state=20 > string for the `Email` type to change, however as nothing new was=20 > added to the store the `EmailDelivery` state does not change and=20 > nothing is pushed to the client. A new message arrives in the user's=20 > inbox, again causing the `Email` state to change. This time the=20 > `EmailDelivery` state also changes, and a StateChange object is pushed=20 > to the client with the new state string. The client may then resync to=20 > fetch the new message immediately./ The rest looks fine. > >> In Section 2: >> >> > Servers MUST forbid sibling Mailboxes with the same name. >> What exactly is this trying to say? > > I have rewritten this to say: > > /There MUST NOT be two mailboxes with both the same parent and the=20 > same name./ //// > > Is that clear? (IMAP is path based so naturally you cannot have two=20 > sibling mailboxes with the same name; but JMAP is id based so in=20 > theory you could. For IMAP compatibility, and to avoid user confusion,=20 > this is forbidden by fiat.) If you change "two mailboxes" to "two sibling mailboxes", that would be=20 clear. > > >=C2=A0=C2=A0 determine a charset and decode the octets, or MAY replace an= y octet >> >=C2=A0=C2=A0 or octet run with the high bit set that violates UTF-8 synt= ax with >> >=C2=A0=C2=A0 the unicode replacement character (U+FFFD). >> >> Do we really want to encourage the "MAY use heuristics" part? Such email >> messages are non compliant and thus not in scope for this document! > > Well, they appear in the real world so servers do need to deal with=20 > them. Using heuristics to determine what the sender intended often=20 > provides the best user experience (customers tend not to care that it=20 > was the sender that sent something broken=E2=80=A6). MAY is compliance language, but "MAY use heuristics" is impossible to=20 test for interoperability. > However, I'm not strongly attached. Would you prefer me to replace=20 > this with the following? > > /A server SHOULD replace any octet or octet run with the high bit set=20 > that violates UTF-8 syntax with the unicode replacement character=20 > (U+FFFD).// > / Yes, please. =C2=A0[snip] >> Is it worth explicitly mentioning Content-Description header field here >> as well? > > The spec currently only has restrictions on RFC5322 and RFC2369=20 > headers. Other headers such as this one are not explicitly forbidden=20 > so may be used with the form already. So I don't think it's necessary=20 > to mention explicitly. It just took me some time to realize that it is allowed. I don't have a=20 strong preference. >> In Section 4.1.2.3: >> Is RFC 2231 encoding allowed in this and the following section? > > I don't think so, as To, Cc etc. don't have parameter values. Or have=20 > I got that wrong? You are right. I think I want a new type for parsing ;-separated=20 attribute=3Dvalue pairs with RFC 2231 parameters, as this is a pain to do=20 in clients. >> >> In 4.1.3: >> >> asText and asAddresses is not defined in the document. Did you mean: > > This is defined at the top of page 26 in 4.1.3: > > o *:as{header-form}* This means the value is in a parsed form, where > "{header-form}" is one of the parsed-form names specified above. > If not given, the value is in _Raw_ form. Never mind than. >> In Section 4.1.4: >> >> You need to define handling for unrecognised Content-Transfer-Encoding >> values here. > > I have added > > /If the transfer encoding is unknown, it is treated as though it had=20 > no transfer-encoding./ Ok. I think you should also mention that this would result in=20 isEncodingProblem being true as well. =C2=A0[snip] >> In Section 4.2 (and similar text in 4.9): >> >> maxBodyValueBytes: >> >> =C2=A0"The server MUST ensure the truncation results in valid UTF-8 and d= oes >> not occur mid-codepoint." -- >> >> The document needs to make sure that this is only true for body parts >> which are known to be textual (e.g. text/plain, text/html, XML, JSON). >> If a body part is a JPEG image, this requirement doesn't make sense. > > As Bron pointed out, bodyValue is only returned like this for text/*=20 > types. Ok. Maybe explain this in a comment, if you feel like it. > >> In Sections 4.8/4.9: >> >> The document needs to explicitly allow EAI messages, not just RFC 5322 >> format. > > I'm not entirely sure how to specify this. I have added this sentence=20 > to the introduction to each of these methods: > > /The server SHOULD support messages with [@!RFC6532] EAI headers./ In IMAP4rev2 we made it a MUST. I wouldn't mind if you add a capability=20 for this. > Is that sufficient? (And should it be a MUST?) > > In Section 7: >> >> Are "MDN" and "DSN" blobIds referencing only the machine parseable part >> or the whole multipart/report coming back? I think the document should >> clarify this and (ideally) give some examples. > > This is intended to be the whole MIME message=C2=A0a with a top-level=20 > content-type of multipart/report; I have added the following line to=20 > the two properties to clarify: > > /The blob is the whole MIME message=C2=A0(with a top-level content-type of= =20 > multipart/report), as received./ Ok. I suggest you add Normative references to RFCs that define MDN and=20 DSN report types. >> End of Section 7.5: >> >> =C2=A0"The server MAY choose to localise this string into the user's >> preferred language, if known." >> >> How can this be done? > > This is just acknowledging the server may have some kind of=20 > out-of-band knowledge about the authenticated user and if so should=20 > use it to increase the likelihood of presenting an understandable=20 > error to the user. I think anything more is out of scope of the=20 > current specification. Use of MAY is compliance language, but you don't provide a way to do=20 this interoperably (or at all). At minimum clients should be able to=20 deduce the language tag used, so you must have a field for conveying it=20 (even if it is omitted in most cases.) I think I agree with Bron that=20 the mechanism for specifying user's preferred language(s) should be=20 specified in CORE. Best Regards, Alexey --------------110BE3B836CAE9356D2E2F60 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+DQogIDxoZWFkPg0KICAgIDxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PVVURi04Ij4NCiAgPC9oZWFkPg0KICA8Ym9k eSB0ZXh0PSIjMDAwMDAwIiBiZ2NvbG9yPSIjRkZGRkZGIj4NCiAgICA8cD5IaSBOZWlsLDwv cD4NCiAgICA8cD5CZWxvdyBJIHJlbW92ZWQgY29tbWVudHMgZnJvbSBteSByZXBseSB3aGVy ZSB3ZSBhcmUgaW4gYWdyZWVtZW50Ojxicj4NCiAgICA8L3A+DQogICAgPGRpdiBjbGFzcz0i bW96LWNpdGUtcHJlZml4Ij5PbiAxMC8wMS8yMDE5IDAzOjQyLCBOZWlsIEplbmtpbnMNCiAg ICAgIHdyb3RlOjxicj4NCiAgICA8L2Rpdj4NCiAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRl Ig0KICAgICAgY2l0ZT0ibWlkOmFlNjViYjU1LWJlNjMtNDExNy05OGQ0LWE4ZmYxMGJjNjc1 ZUBiZXRhLmZhc3RtYWlsLmNvbSI+DQogICAgICA8bWV0YSBodHRwLWVxdWl2PSJjb250ZW50 LXR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1VVEYtOCI+DQogICAgICA8dGl0 bGU+PC90aXRsZT4NCiAgICAgIDxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI+cC5Nc29Ob3JtYWws cC5Nc29Ob1NwYWNpbmd7bWFyZ2luOjB9PC9zdHlsZT4NCiAgICAgIDxkaXY+T24gVGh1LCAx MCBKYW4gMjAxOSwgYXQgNDozNCBBTSwgQWxleGV5IE1lbG5pa292IHdyb3RlOjxicj4NCiAg ICAgIDwvZGl2Pg0KICAgICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQogICAgICAgIDxk aXY+wqAgwqAgQnkgZGVmYXVsdCwgdGhlIEpNQVAgc2VydmVyIHNob3VsZCBoaWRlIEVITE88 YnI+DQogICAgICAgIDwvZGl2Pg0KICAgICAgICA8ZGl2PsKgwqDCoMKgwqAgY2FwYWJpbGl0 aWVzIHRoYXQgYXJlIHRvIGRvIHdpdGggdGhlIHRyYW5zcG9ydA0KICAgICAgICAgIG1lY2hh bmlzbSBhbmQgdGh1czxicj4NCiAgICAgICAgPC9kaXY+DQogICAgICAgIDxkaXY+wqDCoMKg wqDCoCBhcmUgb25seSByZWxldmFudCB0byB0aGUgSk1BUCBzZXJ2ZXI8YnI+DQogICAgICAg IDwvZGl2Pg0KICAgICAgICA8ZGl2Pjxicj4NCiAgICAgICAgPC9kaXY+DQogICAgICAgIDxk aXY+SXMgaXQgd29ydGggaGF2aW5nIGEgcmVnaXN0cnkgZm9yIHRoZXNlIGEgbGEgU2VjdGlv biA2LjIgb2YNCiAgICAgICAgICBSRkMgODQ5ND88YnI+DQogICAgICAgIDwvZGl2Pg0KICAg ICAgPC9ibG9ja3F1b3RlPg0KICAgICAgPGRpdj48YnI+DQogICAgICA8L2Rpdj4NCiAgICAg IDxkaXY+SSBkb24ndCBmZWVsIGEgbmVlZCBmb3Igb25lIHN0cm9uZ2x5LCBidXQgd2UgY2Fu IGFkZCBvbmUgaWYNCiAgICAgICAgeW91IHRoaW5rIGl0J3MgbmVjZXNzYXJ5Pzxicj4NCiAg ICAgIDwvZGl2Pg0KICAgIDwvYmxvY2txdW90ZT4NCiAgICBUaGlzIGlzIGEgcG9zc2libGUg aW50ZXJvcCBpc3N1ZSBhbmQgSSB3b3VsZCByYXRoZXIgaGF2ZSBhIHJlZ2lzdHJ5Lg0KICAg IEkgYW0gT2sgd2l0aCBCcm9uJ3MgcHJvcG9zYWwgdG8gZGVmaW5lIGl0IGluIGFub3RoZXIg ZG9jdW1lbnQuPGJyPg0KICAgIDxicj4NCiAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIg0K ICAgICAgY2l0ZT0ibWlkOmFlNjViYjU1LWJlNjMtNDExNy05OGQ0LWE4ZmYxMGJjNjc1ZUBi ZXRhLmZhc3RtYWlsLmNvbSI+DQogICAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCiAg ICAgICAgPGRpdj7CoMKgIEluIGFkZGl0aW9uLCBzZXJ2ZXJzIE1VU1Qgc3VwcG9ydCBhIHBz dWVkby10eXBlIGNhbGxlZDxicj4NCiAgICAgICAgPC9kaXY+DQogICAgICAgIDxkaXY+wqDC oCAiRW1haWxEZWxpdmVyeSIgaW4gdGhlIHB1c2ggbWVjaGFuaXNtcy7CoDxicj4NCiAgICAg ICAgPC9kaXY+DQogICAgICAgIDxkaXY+PGJyPg0KICAgICAgICA8L2Rpdj4NCiAgICAgICAg PGRpdj5JIHRoaW5rIGFuIGV4YW1wbGUgb3IgcG9pbnRlciB0byBhbiBleGFtcGxlIHdvdWxk IGJlIHVzZWZ1bA0KICAgICAgICAgIGhlcmUuPGJyPg0KICAgICAgICA8L2Rpdj4NCiAgICAg IDwvYmxvY2txdW90ZT4NCiAgICAgIDxkaXY+PGJyPg0KICAgICAgPC9kaXY+DQogICAgICA8 ZGl2PkkndmUgYWRkZWQgdGhlIGZvbGxvd2luZyBleGFtcGxlIHRvIHRoZSBkb2N1bWVudDsg ZG9lcyB0aGlzDQogICAgICAgIGNsYXJpZnkgaXQgZm9yIHlvdT88YnI+DQogICAgICA8L2Rp dj4NCiAgICAgIDxkaXY+PGJyPg0KICAgICAgPC9kaXY+DQogICAgICA8ZGl2PjxpPlRoZSBj bGllbnQgaGFzIHJlZ2lzdGVyZWQgZm9yIHB1c2ggbm90aWZpY2F0aW9ucyBqdXN0IGZvcg0K ICAgICAgICAgIHRoZSBgRW1haWxEZWxpdmVyeWAgdHlwZSAoc2VlIFtAIUktRC5pZXRmLWpt YXAtY29yZV0gZm9yDQogICAgICAgICAgZGV0YWlscyBvZiB0aGUgcHVzaCBzeXN0ZW0pLjwv aT48L2Rpdj4NCiAgICA8L2Jsb2NrcXVvdGU+DQogICAgVGhpcyBtb3N0bHkgd29ya3MsIGJ1 dCBFbWFpbERlbGl2ZXJ5IGlzIG5vdCBkZWZpbmVkIGluIENPUkUsIGl0IGlzDQogICAgb25s eSBzaG93biB0aGVyZSBpbiBleGFtcGxlcy4gPGk+PGJyPg0KICAgIDwvaT4NCiAgICA8Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIg0KICAgICAgY2l0ZT0ibWlkOmFlNjViYjU1LWJlNjMtNDEx Ny05OGQ0LWE4ZmYxMGJjNjc1ZUBiZXRhLmZhc3RtYWlsLmNvbSI+DQogICAgICA8ZGl2Pjxp PiBUaGUgdXNlciBtYXJrcyBhbiBlbWFpbCBhcyByZWFkIG9uIGFub3RoZXIgZGV2aWNlLA0K ICAgICAgICAgIGNhdXNpbmcgdGhlIHN0YXRlIHN0cmluZyBmb3IgdGhlIGBFbWFpbGAgdHlw ZSB0byBjaGFuZ2UsDQogICAgICAgICAgaG93ZXZlciBhcyBub3RoaW5nIG5ldyB3YXMgYWRk ZWQgdG8gdGhlIHN0b3JlIHRoZQ0KICAgICAgICAgIGBFbWFpbERlbGl2ZXJ5YCBzdGF0ZSBk b2VzIG5vdCBjaGFuZ2UgYW5kIG5vdGhpbmcgaXMgcHVzaGVkIHRvDQogICAgICAgICAgdGhl IGNsaWVudC4gQSBuZXcgbWVzc2FnZSBhcnJpdmVzIGluIHRoZSB1c2VyJ3MgaW5ib3gsIGFn YWluDQogICAgICAgICAgY2F1c2luZyB0aGUgYEVtYWlsYCBzdGF0ZSB0byBjaGFuZ2UuIFRo aXMgdGltZSB0aGUNCiAgICAgICAgICBgRW1haWxEZWxpdmVyeWAgc3RhdGUgYWxzbyBjaGFu Z2VzLCBhbmQgYSBTdGF0ZUNoYW5nZSBvYmplY3QNCiAgICAgICAgICBpcyBwdXNoZWQgdG8g dGhlIGNsaWVudCB3aXRoIHRoZSBuZXcgc3RhdGUgc3RyaW5nLiBUaGUgY2xpZW50DQogICAg ICAgICAgbWF5IHRoZW4gcmVzeW5jIHRvIGZldGNoIHRoZSBuZXcgbWVzc2FnZSBpbW1lZGlh dGVseS48L2k+PGJyPg0KICAgICAgPC9kaXY+DQogICAgPC9ibG9ja3F1b3RlPg0KICAgIFRo ZSByZXN0IGxvb2tzIGZpbmUuPGJyPg0KICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiDQog ICAgICBjaXRlPSJtaWQ6YWU2NWJiNTUtYmU2My00MTE3LTk4ZDQtYThmZjEwYmM2NzVlQGJl dGEuZmFzdG1haWwuY29tIj4NCiAgICAgIDxkaXY+PGJyPg0KICAgICAgPC9kaXY+DQogICAg ICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCiAgICAgICAgPGRpdj4gSW4gU2VjdGlvbiAy Ojxicj4NCiAgICAgICAgPC9kaXY+DQogICAgICAgIDxkaXY+PGJyPg0KICAgICAgICA8L2Rp dj4NCiAgICAgICAgPGRpdj4mZ3Q7IFNlcnZlcnMgTVVTVCBmb3JiaWQgc2libGluZyBNYWls Ym94ZXMgd2l0aCB0aGUgc2FtZQ0KICAgICAgICAgIG5hbWUuPGJyPg0KICAgICAgICA8L2Rp dj4NCiAgICAgICAgPGRpdj5XaGF0IGV4YWN0bHkgaXMgdGhpcyB0cnlpbmcgdG8gc2F5Pzxi cj4NCiAgICAgICAgPC9kaXY+DQogICAgICA8L2Jsb2NrcXVvdGU+DQogICAgICA8ZGl2Pjxi cj4NCiAgICAgIDwvZGl2Pg0KICAgICAgPGRpdj5JIGhhdmUgcmV3cml0dGVuIHRoaXMgdG8g c2F5Ojxicj4NCiAgICAgIDwvZGl2Pg0KICAgICAgPGRpdj48YnI+DQogICAgICA8L2Rpdj4N CiAgICAgIDxkaXY+PGk+VGhlcmUgTVVTVCBOT1QgYmUgdHdvIG1haWxib3hlcyB3aXRoIGJv dGggdGhlIHNhbWUgcGFyZW50DQogICAgICAgICAgYW5kIHRoZSBzYW1lIG5hbWUuPC9pPjxi cj4NCiAgICAgIDwvZGl2Pg0KICAgIDwvYmxvY2txdW90ZT4NCiAgICA8aT48aT48L2k+PC9p Pg0KICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiDQogICAgICBjaXRlPSJtaWQ6YWU2NWJi NTUtYmU2My00MTE3LTk4ZDQtYThmZjEwYmM2NzVlQGJldGEuZmFzdG1haWwuY29tIj4NCiAg ICAgIDxkaXY+PGJyPg0KICAgICAgPC9kaXY+DQogICAgICA8ZGl2PklzIHRoYXQgY2xlYXI/ IChJTUFQIGlzIHBhdGggYmFzZWQgc28gbmF0dXJhbGx5IHlvdSBjYW5ub3QNCiAgICAgICAg aGF2ZSB0d28gc2libGluZyBtYWlsYm94ZXMgd2l0aCB0aGUgc2FtZSBuYW1lOyBidXQgSk1B UCBpcyBpZA0KICAgICAgICBiYXNlZCBzbyBpbiB0aGVvcnkgeW91IGNvdWxkLiBGb3IgSU1B UCBjb21wYXRpYmlsaXR5LCBhbmQgdG8NCiAgICAgICAgYXZvaWQgdXNlciBjb25mdXNpb24s IHRoaXMgaXMgZm9yYmlkZGVuIGJ5IGZpYXQuKTxicj4NCiAgICAgIDwvZGl2Pg0KICAgIDwv YmxvY2txdW90ZT4NCiAgICBJZiB5b3UgY2hhbmdlICJ0d28gbWFpbGJveGVzIiB0byAidHdv IHNpYmxpbmcgbWFpbGJveGVzIiwgdGhhdCB3b3VsZA0KICAgIGJlIGNsZWFyLg0KICAgIDxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiDQogICAgICBjaXRlPSJtaWQ6YWU2NWJiNTUtYmU2My00 MTE3LTk4ZDQtYThmZjEwYmM2NzVlQGJldGEuZmFzdG1haWwuY29tIj4NCiAgICAgIDxkaXY+ PGJyPg0KICAgICAgPC9kaXY+DQogICAgICAmZ3Q7wqDCoCBkZXRlcm1pbmUgYSBjaGFyc2V0 IGFuZCBkZWNvZGUgdGhlIG9jdGV0cywgb3IgTUFZIHJlcGxhY2UNCiAgICAgIGFueSBvY3Rl dDxicj4NCiAgICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KICAgICAgICA8ZGl2PiZn dDvCoMKgIG9yIG9jdGV0IHJ1biB3aXRoIHRoZSBoaWdoIGJpdCBzZXQgdGhhdCB2aW9sYXRl cw0KICAgICAgICAgIFVURi04IHN5bnRheCB3aXRoPGJyPg0KICAgICAgICA8L2Rpdj4NCiAg ICAgICAgPGRpdj4mZ3Q7wqDCoCB0aGUgdW5pY29kZSByZXBsYWNlbWVudCBjaGFyYWN0ZXIg KFUrRkZGRCkuPGJyPg0KICAgICAgICA8L2Rpdj4NCiAgICAgICAgPGRpdj48YnI+DQogICAg ICAgIDwvZGl2Pg0KICAgICAgICA8ZGl2PkRvIHdlIHJlYWxseSB3YW50IHRvIGVuY291cmFn ZSB0aGUgIk1BWSB1c2UgaGV1cmlzdGljcyINCiAgICAgICAgICBwYXJ0PyBTdWNoIGVtYWls wqA8YnI+DQogICAgICAgIDwvZGl2Pg0KICAgICAgICA8ZGl2Pm1lc3NhZ2VzIGFyZSBub24g Y29tcGxpYW50IGFuZCB0aHVzIG5vdCBpbiBzY29wZSBmb3IgdGhpcw0KICAgICAgICAgIGRv Y3VtZW50ITxicj4NCiAgICAgICAgPC9kaXY+DQogICAgICA8L2Jsb2NrcXVvdGU+DQogICAg ICA8ZGl2Pjxicj4NCiAgICAgIDwvZGl2Pg0KICAgICAgPGRpdj5XZWxsLCB0aGV5IGFwcGVh ciBpbiB0aGUgcmVhbCB3b3JsZCBzbyBzZXJ2ZXJzIGRvIG5lZWQgdG8NCiAgICAgICAgZGVh bCB3aXRoIHRoZW0uIFVzaW5nIGhldXJpc3RpY3MgdG8gZGV0ZXJtaW5lIHdoYXQgdGhlIHNl bmRlcg0KICAgICAgICBpbnRlbmRlZCBvZnRlbiBwcm92aWRlcyB0aGUgYmVzdCB1c2VyIGV4 cGVyaWVuY2UgKGN1c3RvbWVycyB0ZW5kDQogICAgICAgIG5vdCB0byBjYXJlIHRoYXQgaXQg d2FzIHRoZSBzZW5kZXIgdGhhdCBzZW50IHNvbWV0aGluZyBicm9rZW7igKYpLjwvZGl2Pg0K ICAgIDwvYmxvY2txdW90ZT4NCiAgICBNQVkgaXMgY29tcGxpYW5jZSBsYW5ndWFnZSwgYnV0 ICJNQVkgdXNlIGhldXJpc3RpY3MiIGlzIGltcG9zc2libGUNCiAgICB0byB0ZXN0IGZvciBp bnRlcm9wZXJhYmlsaXR5Ljxicj4NCiAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIg0KICAg ICAgY2l0ZT0ibWlkOmFlNjViYjU1LWJlNjMtNDExNy05OGQ0LWE4ZmYxMGJjNjc1ZUBiZXRh LmZhc3RtYWlsLmNvbSI+DQogICAgICA8ZGl2PiBIb3dldmVyLCBJJ20gbm90IHN0cm9uZ2x5 IGF0dGFjaGVkLiBXb3VsZCB5b3UgcHJlZmVyIG1lIHRvDQogICAgICAgIHJlcGxhY2UgdGhp cyB3aXRoIHRoZSBmb2xsb3dpbmc/PGJyPg0KICAgICAgPC9kaXY+DQogICAgICA8ZGl2Pjxi cj4NCiAgICAgIDwvZGl2Pg0KICAgICAgPGRpdj48aT5BIHNlcnZlciBTSE9VTEQgcmVwbGFj ZSBhbnkgb2N0ZXQgb3Igb2N0ZXQgcnVuIHdpdGggdGhlDQogICAgICAgICAgaGlnaCBiaXQg c2V0IHRoYXQgdmlvbGF0ZXMgVVRGLTggc3ludGF4IHdpdGggdGhlIHVuaWNvZGUNCiAgICAg ICAgICByZXBsYWNlbWVudCBjaGFyYWN0ZXIgKFUrRkZGRCkuPC9pPjxpPjxicj4NCiAgICAg ICAgPC9pPjwvZGl2Pg0KICAgIDwvYmxvY2txdW90ZT4NCiAgICBZZXMsIHBsZWFzZS48YnI+ DQogICAgwqBbc25pcF08YnI+DQogICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSINCiAgICAg IGNpdGU9Im1pZDphZTY1YmI1NS1iZTYzLTQxMTctOThkNC1hOGZmMTBiYzY3NWVAYmV0YS5m YXN0bWFpbC5jb20iPg0KICAgICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQogICAgICAg IDxkaXY+SXMgaXQgd29ydGggZXhwbGljaXRseSBtZW50aW9uaW5nIENvbnRlbnQtRGVzY3Jp cHRpb24NCiAgICAgICAgICBoZWFkZXIgZmllbGQgaGVyZcKgPGJyPg0KICAgICAgICA8L2Rp dj4NCiAgICAgICAgPGRpdj5hcyB3ZWxsPzxicj4NCiAgICAgICAgPC9kaXY+DQogICAgICA8 L2Jsb2NrcXVvdGU+DQogICAgICA8ZGl2Pjxicj4NCiAgICAgIDwvZGl2Pg0KICAgICAgPGRp dj5UaGUgc3BlYyBjdXJyZW50bHkgb25seSBoYXMgcmVzdHJpY3Rpb25zIG9uIFJGQzUzMjIg YW5kDQogICAgICAgIFJGQzIzNjkgaGVhZGVycy4gT3RoZXIgaGVhZGVycyBzdWNoIGFzIHRo aXMgb25lIGFyZSBub3QNCiAgICAgICAgZXhwbGljaXRseSBmb3JiaWRkZW4gc28gbWF5IGJl IHVzZWQgd2l0aCB0aGUgZm9ybSBhbHJlYWR5LiBTbyBJDQogICAgICAgIGRvbid0IHRoaW5r IGl0J3MgbmVjZXNzYXJ5IHRvIG1lbnRpb24gZXhwbGljaXRseS48YnI+DQogICAgICA8L2Rp dj4NCiAgICA8L2Jsb2NrcXVvdGU+DQogICAgPHA+SXQganVzdCB0b29rIG1lIHNvbWUgdGlt ZSB0byByZWFsaXplIHRoYXQgaXQgaXMgYWxsb3dlZC4gSSBkb24ndA0KICAgICAgaGF2ZSBh IHN0cm9uZyBwcmVmZXJlbmNlLiA8L3A+DQogICAgPGJyPg0KICAgIDxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiDQogICAgICBjaXRlPSJtaWQ6YWU2NWJiNTUtYmU2My00MTE3LTk4ZDQtYThm ZjEwYmM2NzVlQGJldGEuZmFzdG1haWwuY29tIj4NCiAgICAgIDxibG9ja3F1b3RlIHR5cGU9 ImNpdGUiPg0KICAgICAgICA8ZGl2PkluIFNlY3Rpb24gNC4xLjIuMzo8YnI+DQogICAgICAg IDwvZGl2Pg0KICAgICAgPC9ibG9ja3F1b3RlPg0KICAgICAgPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSI+DQogICAgICAgIDxkaXY+SXMgUkZDIDIyMzEgZW5jb2RpbmcgYWxsb3dlZCBpbiB0 aGlzIGFuZCB0aGUgZm9sbG93aW5nDQogICAgICAgICAgc2VjdGlvbj88YnI+DQogICAgICAg IDwvZGl2Pg0KICAgICAgPC9ibG9ja3F1b3RlPg0KICAgICAgPGRpdj48YnI+DQogICAgICA8 L2Rpdj4NCiAgICAgIDxkaXY+SSBkb24ndCB0aGluayBzbywgYXMgVG8sIENjIGV0Yy4gZG9u J3QgaGF2ZSBwYXJhbWV0ZXIgdmFsdWVzLg0KICAgICAgICBPciBoYXZlIEkgZ290IHRoYXQg d3Jvbmc/PGJyPg0KICAgICAgPC9kaXY+DQogICAgPC9ibG9ja3F1b3RlPg0KICAgIDxicj4N CiAgICA8cD5Zb3UgYXJlIHJpZ2h0LiBJIHRoaW5rIEkgd2FudCBhIG5ldyB0eXBlIGZvciBw YXJzaW5nIDstc2VwYXJhdGVkDQogICAgICBhdHRyaWJ1dGU9dmFsdWUgcGFpcnMgd2l0aCBS RkMgMjIzMSBwYXJhbWV0ZXJzLCBhcyB0aGlzIGlzIGEgcGFpbg0KICAgICAgdG8gZG8gaW4g Y2xpZW50cy48L3A+DQogICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSINCiAgICAgIGNpdGU9 Im1pZDphZTY1YmI1NS1iZTYzLTQxMTctOThkNC1hOGZmMTBiYzY3NWVAYmV0YS5mYXN0bWFp bC5jb20iPg0KICAgICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQogICAgICAgIDxkaXY+ PGJyPg0KICAgICAgICA8L2Rpdj4NCiAgICAgICAgPGRpdj5JbiA0LjEuMzo8YnI+DQogICAg ICAgIDwvZGl2Pg0KICAgICAgICA8ZGl2Pjxicj4NCiAgICAgICAgPC9kaXY+DQogICAgICAg IDxkaXY+YXNUZXh0IGFuZCBhc0FkZHJlc3NlcyBpcyBub3QgZGVmaW5lZCBpbiB0aGUgZG9j dW1lbnQuIERpZA0KICAgICAgICAgIHlvdSBtZWFuOjxicj4NCiAgICAgICAgPC9kaXY+DQog ICAgICA8L2Jsb2NrcXVvdGU+DQogICAgICA8ZGl2Pjxicj4NCiAgICAgIDwvZGl2Pg0KICAg ICAgPGRpdj5UaGlzIGlzIGRlZmluZWQgYXQgdGhlIHRvcCBvZiBwYWdlIDI2IGluIDQuMS4z Ojxicj4NCiAgICAgIDwvZGl2Pg0KICAgICAgPGRpdj48YnI+DQogICAgICA8L2Rpdj4NCiAg ICAgIDxwcmUgc3R5bGU9ImJveC1zaXppbmc6Ym9yZGVyLWJveDtvdmVyZmxvdy14OmF1dG87 b3ZlcmZsb3cteTphdXRvO2ZvbnQtZmFtaWx5OiZxdW90O1BUIE1vbm8mcXVvdDssIE1vbmFj bywgbW9ub3NwYWNlO2ZvbnQtc2l6ZToxNHB4O2Rpc3BsYXk6YmxvY2s7cGFkZGluZy10b3A6 MTBweDtwYWRkaW5nLXJpZ2h0OjEwcHg7cGFkZGluZy1ib3R0b206MTBweDtwYWRkaW5nLWxl ZnQ6MTBweDttYXJnaW4tdG9wOjBweDttYXJnaW4tcmlnaHQ6MHB4O21hcmdpbi1ib3R0b206 MTAuNXB4O21hcmdpbi1sZWZ0OjBweDtsaW5lLWhlaWdodDoxLjIxNDtjb2xvcjpyZ2IoMCwg MCwgMCk7d29yZC1icmVhazpicmVhay1hbGw7b3ZlcmZsb3ctd3JhcDpicmVhay13b3JkO2Jh Y2tncm91bmQtY29sb3I6cmdiKDI1NSwgMjUzLCAyNDUpO2JvcmRlci10b3Atd2lkdGg6MXB4 O2JvcmRlci1yaWdodC13aWR0aDoxcHg7Ym9yZGVyLWJvdHRvbS13aWR0aDoxcHg7Ym9yZGVy LWxlZnQtd2lkdGg6MXB4O2JvcmRlci10b3Atc3R5bGU6c29saWQ7Ym9yZGVyLXJpZ2h0LXN0 eWxlOnNvbGlkO2JvcmRlci1ib3R0b20tc3R5bGU6c29saWQ7Ym9yZGVyLWxlZnQtc3R5bGU6 c29saWQ7Ym9yZGVyLXRvcC1jb2xvcjpyZ2IoMjA0LCAyMDQsIDIwNCk7Ym9yZGVyLXJpZ2h0 LWNvbG9yOnJnYigyMDQsIDIwNCwgMjA0KTtib3JkZXItYm90dG9tLWNvbG9yOnJnYigyMDQs IDIwNCwgMjA0KTtib3JkZXItbGVmdC1jb2xvcjpyZ2IoMjA0LCAyMDQsIDIwNCk7Ym9yZGVy LWltYWdlLXNvdXJjZTppbml0aWFsO2JvcmRlci1pbWFnZS1zbGljZTppbml0aWFsO2JvcmRl ci1pbWFnZS13aWR0aDppbml0aWFsO2JvcmRlci1pbWFnZS1vdXRzZXQ6aW5pdGlhbDtib3Jk ZXItaW1hZ2UtcmVwZWF0OmluaXRpYWw7Ym9yZGVyLXRvcC1sZWZ0LXJhZGl1czo0cHg7Ym9y ZGVyLXRvcC1yaWdodC1yYWRpdXM6NHB4O2JvcmRlci1ib3R0b20tcmlnaHQtcmFkaXVzOjRw eDtib3JkZXItYm90dG9tLWxlZnQtcmFkaXVzOjRweDtmb250LXN0eWxlOm5vcm1hbDtmb250 LXZhcmlhbnQtbGlnYXR1cmVzOm5vcm1hbDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7Zm9u dC13ZWlnaHQ6NDAwO2xldHRlci1zcGFjaW5nOm5vcm1hbDtvcnBoYW5zOjI7dGV4dC1hbGln bjpzdGFydDt0ZXh0LWluZGVudDowcHg7dGV4dC10cmFuc2Zvcm06bm9uZTt3aWRvd3M6Mjt3 b3JkLXNwYWNpbmc6MHB4Oy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6MHB4O3RleHQtZGVj b3JhdGlvbi1zdHlsZTppbml0aWFsO3RleHQtZGVjb3JhdGlvbi1jb2xvcjppbml0aWFsOyI+ byAgKjphc3toZWFkZXItZm9ybX0qIFRoaXMgbWVhbnMgdGhlIHZhbHVlIGlzIGluIGEgcGFy c2VkIGZvcm0sIHdoZXJlDQogICAgICAie2hlYWRlci1mb3JtfSIgaXMgb25lIG9mIHRoZSBw YXJzZWQtZm9ybSBuYW1lcyBzcGVjaWZpZWQgYWJvdmUuDQogICAgICBJZiBub3QgZ2l2ZW4s IHRoZSB2YWx1ZSBpcyBpbiBfUmF3XyBmb3JtLg0KPC9wcmU+DQogICAgPC9ibG9ja3F1b3Rl Pg0KICAgIE5ldmVyIG1pbmQgdGhhbi48YnI+DQogICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSINCiAgICAgIGNpdGU9Im1pZDphZTY1YmI1NS1iZTYzLTQxMTctOThkNC1hOGZmMTBiYzY3 NWVAYmV0YS5mYXN0bWFpbC5jb20iPg0KICAgICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+ DQogICAgICAgIDxkaXY+SW4gU2VjdGlvbiA0LjEuNDo8YnI+DQogICAgICAgIDwvZGl2Pg0K ICAgICAgICA8ZGl2Pjxicj4NCiAgICAgICAgPC9kaXY+DQogICAgICAgIDxkaXY+WW91IG5l ZWQgdG8gZGVmaW5lIGhhbmRsaW5nIGZvciB1bnJlY29nbmlzZWQNCiAgICAgICAgICBDb250 ZW50LVRyYW5zZmVyLUVuY29kaW5nwqA8YnI+DQogICAgICAgIDwvZGl2Pg0KICAgICAgICA8 ZGl2PnZhbHVlcyBoZXJlLjxicj4NCiAgICAgICAgPC9kaXY+DQogICAgICA8L2Jsb2NrcXVv dGU+DQogICAgICA8ZGl2Pjxicj4NCiAgICAgIDwvZGl2Pg0KICAgICAgPGRpdj5JIGhhdmUg YWRkZWQ8YnI+DQogICAgICA8L2Rpdj4NCiAgICAgIDxkaXY+PGJyPg0KICAgICAgPC9kaXY+ DQogICAgICA8ZGl2PjxpPklmIHRoZSB0cmFuc2ZlciBlbmNvZGluZyBpcyB1bmtub3duLCBp dCBpcyB0cmVhdGVkIGFzDQogICAgICAgICAgdGhvdWdoIGl0IGhhZCBubyB0cmFuc2Zlci1l bmNvZGluZy48L2k+PGJyPg0KICAgICAgPC9kaXY+DQogICAgPC9ibG9ja3F1b3RlPg0KICAg IDxwPk9rLiBJIHRoaW5rIHlvdSBzaG91bGQgYWxzbyBtZW50aW9uIHRoYXQgdGhpcyB3b3Vs ZCByZXN1bHQgaW4NCiAgICAgIGlzRW5jb2RpbmdQcm9ibGVtIGJlaW5nIHRydWUgYXMgd2Vs bC48L3A+DQogICAgPHA+wqBbc25pcF08YnI+DQogICAgPC9wPg0KICAgIDxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiDQogICAgICBjaXRlPSJtaWQ6YWU2NWJiNTUtYmU2My00MTE3LTk4ZDQt YThmZjEwYmM2NzVlQGJldGEuZmFzdG1haWwuY29tIj4NCiAgICAgIDxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiPg0KICAgICAgICA8ZGl2PkluIFNlY3Rpb24gNC4yIChhbmQgc2ltaWxhciB0 ZXh0IGluIDQuOSk6PGJyPg0KICAgICAgICA8L2Rpdj4NCiAgICAgICAgPGRpdj48YnI+DQog ICAgICAgIDwvZGl2Pg0KICAgICAgICA8ZGl2Pm1heEJvZHlWYWx1ZUJ5dGVzOjxicj4NCiAg ICAgICAgPC9kaXY+DQogICAgICAgIDxkaXY+PGJyPg0KICAgICAgICA8L2Rpdj4NCiAgICAg ICAgPGRpdj7CoCJUaGUgc2VydmVyIE1VU1QgZW5zdXJlIHRoZSB0cnVuY2F0aW9uIHJlc3Vs dHMgaW4gdmFsaWQNCiAgICAgICAgICBVVEYtOCBhbmQgZG9lc8KgPGJyPg0KICAgICAgICA8 L2Rpdj4NCiAgICAgICAgPGRpdj5ub3Qgb2NjdXIgbWlkLWNvZGVwb2ludC4iIC0tPGJyPg0K ICAgICAgICA8L2Rpdj4NCiAgICAgICAgPGRpdj48YnI+DQogICAgICAgIDwvZGl2Pg0KICAg ICAgICA8ZGl2PlRoZSBkb2N1bWVudCBuZWVkcyB0byBtYWtlIHN1cmUgdGhhdCB0aGlzIGlz IG9ubHkgdHJ1ZSBmb3INCiAgICAgICAgICBib2R5IHBhcnRzwqA8YnI+DQogICAgICAgIDwv ZGl2Pg0KICAgICAgICA8ZGl2PndoaWNoIGFyZSBrbm93biB0byBiZSB0ZXh0dWFsIChlLmcu IHRleHQvcGxhaW4sIHRleHQvaHRtbCwNCiAgICAgICAgICBYTUwsIEpTT04pLsKgPGJyPg0K ICAgICAgICA8L2Rpdj4NCiAgICAgICAgPGRpdj5JZiBhIGJvZHkgcGFydCBpcyBhIEpQRUcg aW1hZ2UsIHRoaXMgcmVxdWlyZW1lbnQgZG9lc24ndA0KICAgICAgICAgIG1ha2Ugc2Vuc2Uu PGJyPg0KICAgICAgICA8L2Rpdj4NCiAgICAgIDwvYmxvY2txdW90ZT4NCiAgICAgIDxkaXY+ PGJyPg0KICAgICAgPC9kaXY+DQogICAgICA8ZGl2PkFzIEJyb24gcG9pbnRlZCBvdXQsIGJv ZHlWYWx1ZSBpcyBvbmx5IHJldHVybmVkIGxpa2UgdGhpcyBmb3INCiAgICAgICAgdGV4dC8q IHR5cGVzLjwvZGl2Pg0KICAgIDwvYmxvY2txdW90ZT4NCiAgICA8cD5Pay4gTWF5YmUgZXhw bGFpbiB0aGlzIGluIGEgY29tbWVudCwgaWYgeW91IGZlZWwgbGlrZSBpdC48YnI+DQogICAg PC9wPg0KICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiDQogICAgICBjaXRlPSJtaWQ6YWU2 NWJiNTUtYmU2My00MTE3LTk4ZDQtYThmZjEwYmM2NzVlQGJldGEuZmFzdG1haWwuY29tIj4N CiAgICAgIDxkaXY+PGJyPg0KICAgICAgPC9kaXY+DQogICAgICA8YmxvY2txdW90ZSB0eXBl PSJjaXRlIj4NCiAgICAgICAgPGRpdj5JbiBTZWN0aW9ucyA0LjgvNC45Ojxicj4NCiAgICAg ICAgPC9kaXY+DQogICAgICAgIDxkaXY+PGJyPg0KICAgICAgICA8L2Rpdj4NCiAgICAgICAg PGRpdj5UaGUgZG9jdW1lbnQgbmVlZHMgdG8gZXhwbGljaXRseSBhbGxvdyBFQUkgbWVzc2Fn ZXMsIG5vdA0KICAgICAgICAgIGp1c3QgUkZDIDUzMjLCoDxicj4NCiAgICAgICAgPC9kaXY+ DQogICAgICAgIDxkaXY+Zm9ybWF0Ljxicj4NCiAgICAgICAgPC9kaXY+DQogICAgICA8L2Js b2NrcXVvdGU+DQogICAgICA8ZGl2Pjxicj4NCiAgICAgIDwvZGl2Pg0KICAgICAgPGRpdj5J J20gbm90IGVudGlyZWx5IHN1cmUgaG93IHRvIHNwZWNpZnkgdGhpcy4gSSBoYXZlIGFkZGVk IHRoaXMNCiAgICAgICAgc2VudGVuY2UgdG8gdGhlIGludHJvZHVjdGlvbiB0byBlYWNoIG9m IHRoZXNlIG1ldGhvZHM6PGJyPg0KICAgICAgPC9kaXY+DQogICAgICA8ZGl2Pjxicj4NCiAg ICAgIDwvZGl2Pg0KICAgICAgPGRpdj48aT5UaGUgc2VydmVyIFNIT1VMRCBzdXBwb3J0IG1l c3NhZ2VzIHdpdGggW0AhUkZDNjUzMl0gRUFJDQogICAgICAgICAgaGVhZGVycy48L2k+PGJy Pg0KICAgICAgPC9kaXY+DQogICAgPC9ibG9ja3F1b3RlPg0KICAgIEluIElNQVA0cmV2MiB3 ZSBtYWRlIGl0IGEgTVVTVC4gSSB3b3VsZG4ndCBtaW5kIGlmIHlvdSBhZGQgYQ0KICAgIGNh cGFiaWxpdHkgZm9yIHRoaXMuPGJyPg0KICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiDQog ICAgICBjaXRlPSJtaWQ6YWU2NWJiNTUtYmU2My00MTE3LTk4ZDQtYThmZjEwYmM2NzVlQGJl dGEuZmFzdG1haWwuY29tIj4NCiAgICAgIDxkaXY+SXMgdGhhdCBzdWZmaWNpZW50PyAoQW5k IHNob3VsZCBpdCBiZSBhIE1VU1Q/KTxicj4NCiAgICAgIDwvZGl2Pg0KICAgICAgPGRpdj48 YnI+DQogICAgICA8L2Rpdj4NCiAgICAgIEluIFNlY3Rpb24gNzo8YnI+DQogICAgICA8Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIj4NCiAgICAgICAgPGRpdj48YnI+DQogICAgICAgIDwvZGl2 Pg0KICAgICAgICA8ZGl2PkFyZSAiTUROIiBhbmQgIkRTTiIgYmxvYklkcyByZWZlcmVuY2lu ZyBvbmx5IHRoZSBtYWNoaW5lDQogICAgICAgICAgcGFyc2VhYmxlIHBhcnTCoDxicj4NCiAg ICAgICAgPC9kaXY+DQogICAgICAgIDxkaXY+b3IgdGhlIHdob2xlIG11bHRpcGFydC9yZXBv cnQgY29taW5nIGJhY2s/IEkgdGhpbmsgdGhlDQogICAgICAgICAgZG9jdW1lbnQgc2hvdWxk wqA8YnI+DQogICAgICAgIDwvZGl2Pg0KICAgICAgICA8ZGl2PmNsYXJpZnkgdGhpcyBhbmQg KGlkZWFsbHkpIGdpdmUgc29tZSBleGFtcGxlcy48YnI+DQogICAgICAgIDwvZGl2Pg0KICAg ICAgPC9ibG9ja3F1b3RlPg0KICAgICAgPGRpdj48YnI+DQogICAgICA8L2Rpdj4NCiAgICAg IDxkaXY+VGhpcyBpcyBpbnRlbmRlZCB0byBiZSB0aGUgd2hvbGUgTUlNRSBtZXNzYWdlwqBh IHdpdGggYQ0KICAgICAgICB0b3AtbGV2ZWwgY29udGVudC10eXBlIG9mIG11bHRpcGFydC9y ZXBvcnQ7IEkgaGF2ZSBhZGRlZCB0aGUNCiAgICAgICAgZm9sbG93aW5nIGxpbmUgdG8gdGhl IHR3byBwcm9wZXJ0aWVzIHRvIGNsYXJpZnk6PGJyPg0KICAgICAgPC9kaXY+DQogICAgICA8 ZGl2Pjxicj4NCiAgICAgIDwvZGl2Pg0KICAgICAgPGRpdj48aT5UaGUgYmxvYiBpcyB0aGUg d2hvbGUgTUlNRSBtZXNzYWdlwqAod2l0aCBhIHRvcC1sZXZlbA0KICAgICAgICAgIGNvbnRl bnQtdHlwZSBvZiBtdWx0aXBhcnQvcmVwb3J0KSwgYXMgcmVjZWl2ZWQuPC9pPjxicj4NCiAg ICAgIDwvZGl2Pg0KICAgIDwvYmxvY2txdW90ZT4NCiAgICBPay4gSSBzdWdnZXN0IHlvdSBh ZGQgTm9ybWF0aXZlIHJlZmVyZW5jZXMgdG8gUkZDcyB0aGF0IGRlZmluZSBNRE4NCiAgICBh bmQgRFNOIHJlcG9ydCB0eXBlcy48YnI+DQogICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIN CiAgICAgIGNpdGU9Im1pZDphZTY1YmI1NS1iZTYzLTQxMTctOThkNC1hOGZmMTBiYzY3NWVA YmV0YS5mYXN0bWFpbC5jb20iPg0KICAgICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQog ICAgICAgIDxkaXY+RW5kIG9mIFNlY3Rpb24gNy41Ojxicj4NCiAgICAgICAgPC9kaXY+DQog ICAgICAgIDxkaXY+PGJyPg0KICAgICAgICA8L2Rpdj4NCiAgICAgICAgPGRpdj7CoCJUaGUg c2VydmVyIE1BWSBjaG9vc2UgdG8gbG9jYWxpc2UgdGhpcyBzdHJpbmcgaW50byB0aGUNCiAg ICAgICAgICB1c2VyJ3PCoDxicj4NCiAgICAgICAgPC9kaXY+DQogICAgICAgIDxkaXY+cHJl ZmVycmVkIGxhbmd1YWdlLCBpZiBrbm93bi4iPGJyPg0KICAgICAgICA8L2Rpdj4NCiAgICAg ICAgPGRpdj48YnI+DQogICAgICAgIDwvZGl2Pg0KICAgICAgICA8ZGl2PkhvdyBjYW4gdGhp cyBiZSBkb25lPzxicj4NCiAgICAgICAgPC9kaXY+DQogICAgICA8L2Jsb2NrcXVvdGU+DQog ICAgICA8ZGl2Pjxicj4NCiAgICAgIDwvZGl2Pg0KICAgICAgPGRpdj5UaGlzIGlzIGp1c3Qg YWNrbm93bGVkZ2luZyB0aGUgc2VydmVyIG1heSBoYXZlIHNvbWUga2luZCBvZg0KICAgICAg ICBvdXQtb2YtYmFuZCBrbm93bGVkZ2UgYWJvdXQgdGhlIGF1dGhlbnRpY2F0ZWQgdXNlciBh bmQgaWYgc28NCiAgICAgICAgc2hvdWxkIHVzZSBpdCB0byBpbmNyZWFzZSB0aGUgbGlrZWxp aG9vZCBvZiBwcmVzZW50aW5nIGFuDQogICAgICAgIHVuZGVyc3RhbmRhYmxlIGVycm9yIHRv IHRoZSB1c2VyLiBJIHRoaW5rIGFueXRoaW5nIG1vcmUgaXMgb3V0DQogICAgICAgIG9mIHNj b3BlIG9mIHRoZSBjdXJyZW50IHNwZWNpZmljYXRpb24uPGJyPg0KICAgICAgPC9kaXY+DQog ICAgPC9ibG9ja3F1b3RlPg0KICAgIDxwPlVzZSBvZiBNQVkgaXMgY29tcGxpYW5jZSBsYW5n dWFnZSwgYnV0IHlvdSBkb24ndCBwcm92aWRlIGEgd2F5IHRvDQogICAgICBkbyB0aGlzIGlu dGVyb3BlcmFibHkgKG9yIGF0IGFsbCkuIEF0IG1pbmltdW0gY2xpZW50cyBzaG91bGQgYmUN CiAgICAgIGFibGUgdG8gZGVkdWNlIHRoZSBsYW5ndWFnZSB0YWcgdXNlZCwgc28geW91IG11 c3QgaGF2ZSBhIGZpZWxkIGZvcg0KICAgICAgY29udmV5aW5nIGl0IChldmVuIGlmIGl0IGlz IG9taXR0ZWQgaW4gbW9zdCBjYXNlcy4pIEkgdGhpbmsgSQ0KICAgICAgYWdyZWUgd2l0aCBC cm9uIHRoYXQgdGhlIG1lY2hhbmlzbSBmb3Igc3BlY2lmeWluZyB1c2VyJ3MgcHJlZmVycmVk DQogICAgICBsYW5ndWFnZShzKSBzaG91bGQgYmUgc3BlY2lmaWVkIGluIENPUkUuPC9wPg0K ICAgIDxwPkJlc3QgUmVnYXJkcyw8L3A+DQogICAgPHA+QWxleGV5PGJyPg0KICAgIDwvcD4N CiAgICA8cD48YnI+DQogICAgPC9wPg0KICA8L2JvZHk+DQo8L2h0bWw+DQo= --------------110BE3B836CAE9356D2E2F60-- From nobody Thu Jan 10 03:32:09 2019 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 67A80130E0E for ; Thu, 10 Jan 2019 03:32:08 -0800 (PST) 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 qGf75eu0e_zq for ; Thu, 10 Jan 2019 03:32:07 -0800 (PST) Received: from stabil.gulbrandsen.priv.no (stabil.gulbrandsen.priv.no [144.76.73.169]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCDFD130E13 for ; Thu, 10 Jan 2019 03:32:06 -0800 (PST) Received: from stabil.gulbrandsen.priv.no (stabil.gulbrandsen.priv.no [IPv6:2a01:4f8:191:91a8::3]) by stabil.gulbrandsen.priv.no (Postfix) with ESMTP id 42CEDC007C; Thu, 10 Jan 2019 11:33:33 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1547120013; bh=C179r3GbL/3e3tKaKtlZkbrw54qtngEXl/WJyuK2jlA=; h=From:To:Subject:Date:In-Reply-To:References:From; b=RIGm3fgLJmeVdsJpucSvlAteNcNq85m3RDgeum8BEEEQiHX5Kf4k6tpG5lVIaTajX xGuJg1AIO3iZ9sD48Y/J1gxwWKyNuRKg1d8jwdK1EtuXyJ2+DpmI+tKXBfexiSuMed vJJn6GlxFTps1jWfmCL3WFWsOIi9sH0lH0sKsp+w= Received: from arnt@gulbrandsen.priv.no by stabil.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1547120012-2663-2661/9/35; Thu, 10 Jan 2019 11:33:32 +0000 From: Arnt Gulbrandsen To: IETF JMAP Mailing List Date: Thu, 10 Jan 2019 12:32:05 +0100 Mime-Version: 1.0 Message-Id: <76c95a44-40cd-404f-a01e-43c2f24c2187@gulbrandsen.priv.no> In-Reply-To: <0f1c0d19-f473-c7f6-11e2-a60f12b5a106@isode.com> References: <98b0db46-93e6-d03b-085d-15f66912fca6@isode.com> <0f1c0d19-f473-c7f6-11e2-a60f12b5a106@isode.com> User-Agent: Trojita/0.7; Qt/5.3.2; xcb; Linux; Devuan GNU/Linux 1.0 (jessie) Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: Subject: Re: [Jmap] AD review of draft-ietf-jmap-mail-12 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2019 11:32:08 -0000 > > The server SHOULD support messages with [@!RFC6532] EAI headers. > In IMAP4rev2 we made it a MUST. I wouldn't mind if you add a > capability for this. IMO IMAP4rev2 is right. SHOULD sounds like pointless diversity. (Unless there is a point of which I am unaware?) Happy new year BTW. Arnt From nobody Thu Jan 10 21:20:17 2019 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 9C8F512D84C for ; Thu, 10 Jan 2019 21:20:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 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_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=XiurbTE5; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=x36uWcdQ 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 A1OLHJz9zhzJ for ; Thu, 10 Jan 2019 21:20:13 -0800 (PST) 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 B651512D4ED for ; Thu, 10 Jan 2019 21:20:13 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id A0BD622044; Fri, 11 Jan 2019 00:20:12 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Fri, 11 Jan 2019 00:20:12 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:cc:subject:content-type; s=fm1; bh=5eWq0hId0MVAPVia6L6zp3f9M qC+5acashVx56eiSmU=; b=XiurbTE54RHhtVCrl2OmUg7JVey9DEUSSCzW7Hbhp gq8c0tZh6RiDUoATatEWDbgo2qY0FGzuA/auiQXPdPPtLo15RnQm1CHxbJlHH/Ah 54FMR3OW1DOkSYhzAR3EzHF9+n7vSGMO1utaT7gQV7Ahuj8hmKyTsi+lcVSmIUe+ yEASsCETYyS4lkckh8Ig+tGfP7xmYTDRK0vMrZNeyvvgUOjmMwSDGZgm0JMllE2u 7JNaQWD48+rywlrNXME/0D0bjk0PvQULDSlUhKCqRGSC3hzT7eV43E5qJvtxlBf5 Dc9vjSTH3OkYH2DinauXwnFO+NLNNuqGhNsYeY/RJvnig== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=5eWq0hId0MVAPVia6 L6zp3f9MqC+5acashVx56eiSmU=; b=x36uWcdQ1Aj455F5cwUBQM10LV/mc4aUx 6Yz32Ziz2vZ+s0bIEHj4TSK/r6brygw56Y2uK/o4VgXHS9jwylti/QI+JDTYTf2r UpdqXuG+xrnhw+Ae+c/erc2GWohlzOCPcJoyGgZZ7hXOPlKVhdFmuaQyWzFyrXx2 Mp/3MDEsCISfi5JXUYP1fLI77Gt/IkH4N5MnVB0sGDQrbuQUAbU/O6rBq5dlCl9h G6x+ba6w+SylpqNL6Nqa/vlnf2wZtLE8ijkH7ces0lU5ySHjMJki66Fn7PA8fpEU pVrFsCaqZs48fYaXDr3zsGX/ZzYSCgllhCFeTAsrH00X0h7+q9NgA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrfeeggdekvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepofgfkfgjfhffhf fvufgtsegrtderreerredtnecuhfhrohhmpedfpfgvihhlucflvghnkhhinhhsfdcuoehn vghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomheqnecuffhomhgrihhnpehhthhtph hfohhrthhrrghnshhpohhrthifvggrlhhrvggrugihhhgrvhgvrghmvggthhgrnhhishhm fhhorhhthhhishdrshhopdhivghtfhdrohhrghenucfrrghrrghmpehmrghilhhfrhhomh epnhgvihhljhesfhgrshhtmhgrihhlthgvrghmrdgtohhmnecuvehluhhsthgvrhfuihii vgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 19380203F2; Fri, 11 Jan 2019 00:20:12 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-739-g7452a1e-fmstable-20190103v1 X-Me-Personality: 64588216 Message-Id: <1c8e5f38-87ac-4bfe-a941-ce80aac49f51@beta.fastmail.com> In-Reply-To: <0f1c0d19-f473-c7f6-11e2-a60f12b5a106@isode.com> References: <98b0db46-93e6-d03b-085d-15f66912fca6@isode.com> <0f1c0d19-f473-c7f6-11e2-a60f12b5a106@isode.com> Date: Fri, 11 Jan 2019 00:20:11 -0500 From: "Neil Jenkins" To: "Alexey Melnikov" Cc: "IETF JMAP Mailing List" Content-Type: multipart/alternative; boundary=0cbd8283477e42d58fd74dbf503c78a6 Archived-At: Subject: Re: [Jmap] AD review of draft-ietf-jmap-mail-12 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2019 05:20:16 -0000 --0cbd8283477e42d58fd74dbf503c78a6 Content-Type: text/plain On Thu, 10 Jan 2019, at 9:57 PM, Alexey Melnikov wrote: > This is a possible interop issue and I would rather have a registry. I am Ok with Bron's proposal to define it in another document. OK, I will leave that to be established later. >> *The client has registered for push notifications just for the `EmailDelivery` type (see [@!I-D.ietf-jmap-core] for details of the push system).* > This mostly works, but EmailDelivery is not defined in CORE, it is only shown there in examples. Well, no, it is being defined right here in the JMAP Mail spec. Clearly my description of this is still insufficient; here's another go: *In addition, servers MUST support pushing state changes for a type called "EmailDelivery". There are no methods to act on this type; it only exists as part of the push mechanism. The state string for this MUST change whenever a new Email is added to the store, but SHOULD NOT change upon any other change to the Email objects, for example if one is marked as read or deleted.*** ** *Clients in battery constrained environments may wish to delay fetching changes initiated by the user, but fetch new messages immediately so they can notify the user. To do this, they can register for pushes for the EmailDelivery type rather than the Email type **(defined in section 4)**.* **Example** *The client has registered for push notifications (see [@!I-D.ietf-jmap-core]) just for the `EmailDelivery` type. The user marks an email as read on another device, causing the state string for the `Email` type to change, however as nothing new was added to the store the `EmailDelivery` state does not change and nothing is pushed to the client. A new message arrives in the user's inbox, again causing the `Email` state to change. This time the `EmailDelivery` state also changes, and a StateChange object is pushed to the client with the new state string. The client may then resync to fetch the new message immediately.* Is that any better? > You are right. I think I want a new type for parsing ;-separated attribute=value pairs with RFC 2231 parameters, as this is a pain to do in clients. Is that something you want in this spec, or leave to an extension? >> I have added >> *If the transfer encoding is unknown, it is treated as though it had no transfer-encoding.* > Ok. I think you should also mention that this would result in isEncodingProblem being true as well. The isEncodingProblem definition has been updated to note this. >> *The server SHOULD support messages with [@!RFC6532] EAI headers.* > In IMAP4rev2 we made it a MUST. I wouldn't mind if you add a capability for this. I'm interested in *what implementors on the list think about this*; would you prefer this be a MUST, or optional with a capability to indicate support? > I suggest you add Normative references to RFCs that define MDN and DSN report types. Sure, done. > Use of MAY is compliance language, but you don't provide a way to do this interoperably (or at all). At minimum clients should be able to deduce the language tag used, so you must have a field for conveying it (even if it is omitted in most cases.) I think I agree with Bron that the mechanism for specifying user's preferred language(s) should be specified in CORE. Since we're using HTTP for transport we already have a mechanism for this. So I have changed this to: *The server SHOULD use information from the Accept-Language header of the request, as defined in RFC7231 section 5.3.5 , to help determine the choice of localisation if multiple are available. The Content-Language header of the response (see section 3.1.3.2 of RFC7231) SHOULD indicate the language being used for user-visible strings.* Does that sound reasonable? Neil. --0cbd8283477e42d58fd74dbf503c78a6 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Thu, 10= Jan 2019, at 9:57 PM, Alexey Melnikov wrote:

This is a possible interop issue and = I would rather have a registry. I am Ok with Bron's proposal to define it in another document.


OK, I will leave that to be establish= ed later.

The client has registered for p= ush notifications just for the `EmailDelivery` type (see [@!I-D.ietf-jmap-core] for details of the push system).
Th= is mostly works, but EmailDelivery is not defined in CORE, it is only shown there in examples.

<= div>Well, no, it is being defined right here in the JMAP Mail spec. Clea= rly my description of this is still insufficient; here's another go:
=

In addition, servers MUST support pushing s= tate changes for a type called "EmailDelivery". There are no methods to = act on this type; it only exists as part of the push mechanism. The stat= e string for this MUST change whenever a new Email is added to the store= , but SHOULD NOT change upon any other change to the Email objects, for = example if one is marked as read or deleted.

Clients in battery constrained environments may w= ish to delay fetching changes initiated by the user, but fetch new messa= ges immediately so they can notify the user. To do this, they can regist= er for pushes for the EmailDelivery type rather than the Email type = (defined in section 4).

Example

The client has register= ed for push notifications (see [@!I-D.ietf-jmap-core]) just for the `Ema= ilDelivery` type. The user marks an email as read on another device, cau= sing the state string for the `Email` type to change, however as nothing= new was added to the store the `EmailDelivery` state does not change an= d nothing is pushed to the client. A new message arrives in the user's i= nbox, again causing the `Email` state to change. This time the `EmailDel= ivery` state also changes, and a StateChange object is pushed to the cli= ent with the new state string. The client may then resync to fetch the n= ew message immediately.

Is that any bet= ter?

You are righ= t. I think I want a new type for parsing ;-separated attribute=3Dvalue pairs with RFC 2231 parameters, as this is a pai= n to do in clients.

Is tha= t something you want in this spec, or leave to an extension?

I have= added
If the transfer encoding is unknown, it is treat= ed as though it had no transfer-encoding.
=

Ok. I think you should also mention that this would result in isEncodingProblem being true as well.

The isEncodingProblem definition has been updated to note th= is.

=
The server SHOULD support messages with [@!RFC6532] EAI headers.
In IMAP4rev2 we made i= t a MUST. I wouldn't mind if you add a capability for this.

I'm i= nterested in what implementors on the list think about this; woul= d you prefer this be a MUST, or optional with a capability to indicate s= upport?

I suggest= you add Normative references to RFCs that define MDN and DSN report types.

Sure= , done.

Use of MA= Y is compliance language, but you don't provide a way to do this interoperably (or at all). At minimum clients should be able to deduce the language tag used, so you must have a field for= conveying it (even if it is omitted in most cases.) I think I agree with Bron that the mechanism for specifying user's preferred= language(s) should be specified in CORE.

Since we're using HTTP for transport we already have a = mechanism for this. So I have changed this to:

<= div>The server SHOULD use information from the Accept-Language header= of the request, as defined in RFC7231 section 5.3.5, to help determine the ch= oice of localisation if multiple are available. The Content-Language hea= der of the response (see section 3.1.3.2 of RFC7231) SHOULD indicate th= e language being used for user-visible strings.

Does that sound reasonable?

Neil.<= br>
--0cbd8283477e42d58fd74dbf503c78a6-- From nobody Fri Jan 11 03:46:10 2019 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 E9072129B88 for ; Fri, 11 Jan 2019 03:46:08 -0800 (PST) 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, 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 UdSv_MD-IcwW for ; Fri, 11 Jan 2019 03:46:07 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id AF4E312872C for ; Fri, 11 Jan 2019 03:46:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1547207166; d=isode.com; s=june2016; i=@isode.com; bh=ot9RRY9MNkXvg1PksviMjFlbn09x17oRFMgAEhrjUdg=; 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=mhB+5Uwc7hzKcT1iGmn+S9BInfde8f6lgEC9CydJgDegftX5/k5LSAGZpuAsuLUMABk3Ko r5f89kR1c4beI2BUmNFCqLobdjQ1vi/Qtl3mPFaebsCwOtiXiB2Oh22dyVkAGN98zagVPk D0zos0JpxyVewAt1qBSt2mHU763m8cU=; 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 ; Fri, 11 Jan 2019 11:46:05 +0000 To: Neil Jenkins Cc: IETF JMAP Mailing List References: <98b0db46-93e6-d03b-085d-15f66912fca6@isode.com> <0f1c0d19-f473-c7f6-11e2-a60f12b5a106@isode.com> <1c8e5f38-87ac-4bfe-a941-ce80aac49f51@beta.fastmail.com> From: Alexey Melnikov Message-ID: Date: Fri, 11 Jan 2019 11:45:38 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 In-Reply-To: <1c8e5f38-87ac-4bfe-a941-ce80aac49f51@beta.fastmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------ADE194FF26C1C5A727BF3080" Content-Language: en-GB Archived-At: Subject: Re: [Jmap] AD review of draft-ietf-jmap-mail-12 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2019 11:46:09 -0000 --------------ADE194FF26C1C5A727BF3080 Content-Type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: quoted-printable Hi Neil, On 11/01/2019 05:20, Neil Jenkins wrote: > On Thu, 10 Jan 2019, at 9:57 PM, Alexey Melnikov wrote: >> >> This is a possible interop issue and I would rather have a registry.=20 >> I am Ok with Bron's proposal to define it in another document. >> > > OK, I will leave that to be established later. > >>> /The client has registered for push notifications just for the=20 >>> `EmailDelivery` type (see [@!I-D.ietf-jmap-core] for details of the=20 >>> push system)./ >> This mostly works, but EmailDelivery is not defined in CORE, it is=20 >> only shown there in examples. > > Well, no, it is being defined right here in the JMAP Mail spec.=20 > Clearly my description of this is still insufficient; here's another go: > > /In addition, servers MUST support pushing state changes for a type=20 > called "EmailDelivery". There are no methods to act on this type; it=20 > only exists as part of the push mechanism. The state string for this=20 > MUST change whenever a new Email is added to the store, but SHOULD NOT=20 > change upon any other change to the Email objects, for example if one=20 > is marked as read or deleted./ > > /Clients in battery constrained environments may wish to delay=20 > fetching changes initiated by the user, but fetch new messages=20 > immediately so they can notify the user. To do this, they can register=20 > for pushes for the EmailDelivery type rather than the Email type=20 > //(defined in section 4)//./ > > /*Example*/ > > /The client has registered for push notifications (see=20 > [@!I-D.ietf-jmap-core]) just for the `EmailDelivery` type. The user=20 > marks an email as read on another device, causing the state string for=20 > the `Email` type to change, however as nothing new was added to the=20 > store the `EmailDelivery` state does not change and nothing is pushed=20 > to the client. A new message arrives in the user's inbox, again=20 > causing the `Email` state to change. This time the `EmailDelivery`=20 > state also changes, and a StateChange object is pushed to the client=20 > with the new state string. The client may then resync to fetch the new=20 > message immediately./ > > Is that any better? This is much better, thank you! >> You are right. I think I want a new type for parsing ;-separated=20 >> attribute=3Dvalue pairs with RFC 2231 parameters, as this is a pain to=20 >> do in clients. > > Is that something you want in this spec, or leave to an extension? As a client developer I would prefer to have this in the base spec,=20 because I think this would make JMAP more useful for me. As the responsible AD, I am ambivalent about base spec versa extension. >>> /The server SHOULD support messages with [@!RFC6532] EAI headers./ >> In IMAP4rev2 we made it a MUST. I wouldn't mind if you add a=20 >> capability for this. > > I'm interested in *what implementors on the list think about this*;=20 > would you prefer this be a MUST, or optional with a capability to=20 > indicate support? As a developer I appreciate that this might be a non trivial amount of=20 work (more work than adding RFC 2231 decoding ;-)), so I don't mind this=20 being an extra capability. As AD, I think this needs to be in the=20 current MAIL document (whether as an extension or as a MUST). I would also like to hear what other people think about this. >> I suggest you add Normative references to RFCs that define MDN and=20 >> DSN report types. > > Sure, done. > >> Use of MAY is compliance language, but you don't provide a way to do=20 >> this interoperably (or at all). At minimum clients should be able to=20 >> deduce the language tag used, so you must have a field for conveying=20 >> it (even if it is omitted in most cases.) I think I agree with Bron=20 >> that the mechanism for specifying user's preferred language(s) should=20 >> be specified in CORE. > > Since we're using HTTP for transport we already have a mechanism for=20 > this. So I have changed this to: > > /The server SHOULD use information from the Accept-Language header of=20 > the request, as defined in RFC7231 section 5.3.5=20 > , to help determine=20 > the choice of localisation if multiple are available. The=20 > Content-Language header of the response (see section=C2=A03.1.3.2=20 > of RFC7231)=20 > SHOULD indicate the language being used for user-visible strings./ > > Does that sound reasonable? Yes. But again, this probably belongs to CORE. Either way, can you add an example (or extend an existing one) to=20 demonstrate use of this feature? Best Regards, Alexey --------------ADE194FF26C1C5A727BF3080 Content-Type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

Hi Neil,

On 11/01/2019 05:20, Neil Jenkins wrote:
On Thu, 10 Jan 2019, at 9:57 PM, Alexey Melnikov wrote:

This is a possible interop issue and I would rather have a registry. I am Ok with Bron's proposal to define it in another document.


OK, I will leave that to be established later.

The client has registered for push notifications just for the `EmailDelivery` type (see [@!I-D.ietf-jmap-core] for details of the push system).
This mostly works, but EmailDelivery is not defined in CORE, it is only shown there in examples.

Well, no, it is being defined right here in the JMAP Mail spec. Clearly my description of this is still insufficient; here's another go:

In addition, servers MUST support pushing state changes for a type called "EmailDelivery". There are no methods to act on this type; it only exists as part of the push mechanism. The state string for this MUST change whenever a new Email is added to the store, but SHOULD NOT change upon any other change to the Email objects, for example if one is marked as read or deleted.

Clients in battery constrained environments may wish to delay fetching changes initiated by the user, but fetch new messages immediately so they can notify the user. To do this, they can register for pushes for the EmailDelivery type rather than the Email type (defined in section 4).

Example

The client has registered for push notifications (see [@!I-D.ietf-jmap-core]) just for the `EmailDelivery` type. The user marks an email as read on another device, causing the state string for the `Email` type to change, however as nothing new was added to the store the `EmailDelivery` state does not change and nothing is pushed to the client. A new message arrives in the user's inbox, again causing the `Email` state to change. This time the `EmailDelivery` state also changes, and a StateChange object is pushed to the client with the new state string. The client may then resync to fetch the new message immediately.

Is that any better?

This is much better, thank you!


You are right. I think I want a new type for parsing ;-separated attribute=3Dvalue pairs with RFC 2231 parameters, as this is a pain to do in clients.

Is that something you want in this spec, or leave to an extension?

As a client developer I would prefer to have this in the base spec, because I think this would make JMAP more useful for me.

As the responsible AD, I am ambivalent about base spec versa extension.

The server SHOULD support messages with [@!RFC6532] EAI headers.
In IMAP4rev2 we made it a MUST. I wouldn't mind if you add a capability for this.

I'm interested in what implementors on the list think about this; would you prefer this be a MUST, or optional with a capability to indicate support?

As a developer I appreciate that this might be a non trivial amount of work (more work than adding RFC 2231 decoding ;-)), so I don't mind this being an extra capability. As AD, I think this needs to be in the current MAIL document (whether as an extension or as a MUST).

I would also like to hear what other people think about this.

I suggest you add Normative references to RFCs that define MDN and DSN report types.

Sure, done.

Use of MAY is compliance language, but you don't provide a way to do this interoperably (or at all). At minimum clients should be able to deduce the language tag used, so you must have a field for conveying it (even if it is omitted in most cases.) I think I agree with Bron that the mechanism for specifying user's preferred language(s) should be specified in CORE.

Since we're using HTTP for transport we already have a mechanism for this. So I have changed this to:

The server SHOULD use information from the Accept-Language header of the request, as defined in RFC7231 section 5.3.5, to help determine the choice of localisation if multiple are available. The Content-Language header of the response (see section=C2=A03.1.3.2 of RFC7231) SHOULD indicate the language being used for user-visible strings.

Does that sound reasonable?

Yes. But again, this probably belongs to CORE.

Either way, can you add an example (or extend an existing one) to demonstrate use of this feature?

Best Regards,

Alexey

--------------ADE194FF26C1C5A727BF3080-- From stephane.blondon@gmail.com Fri Jan 11 12:12:58 2019 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 A320E128B14 for ; Fri, 11 Jan 2019 12:12:58 -0800 (PST) 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, FREEMAIL_FROM=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=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 PoYRYu9V9jwi for ; Fri, 11 Jan 2019 12:12:56 -0800 (PST) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (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 55523128AFB for ; Fri, 11 Jan 2019 12:12:56 -0800 (PST) Received: by mail-wr1-x42c.google.com with SMTP id j2so16569765wrw.1 for ; Fri, 11 Jan 2019 12:12:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:openpgp:autocrypt:message-id:date:user-agent :mime-version; bh=yMD4ruKEf9TK/6geooFpS/SZjXHYoWuABfEN+9F2KE4=; b=PJl/dYP3aRgcWugbr8ZUaRRam3VCjhohsXWHJQnHmFRApYjHap1XoueXxqxgmRI3HS jYTN8oUGjK81ok7aof3CKT9/Ey5InIi+yI/425tFZ7fKO08aZGM/qIh/EcWq9+fx6wf5 blGo+FHkxQTtoYzUGAJ4HAElXzXBee+bExUqkLYz213UrsyaAEsGve3FhUElwNhw3b4k a8ys+PdirGChvhNnBfEqs0cUir+zHsRmJUBxHTSBLCtgDUTbbQXuPeW9GPmvJF8vbEl7 9cTWPbHP4F7GAWFsQ4/wg874RTMHTdTANvcE5eMuNd5JbZBWg7ujwa/faEMmwAVjydcg LNFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:openpgp:autocrypt:message-id :date:user-agent:mime-version; bh=yMD4ruKEf9TK/6geooFpS/SZjXHYoWuABfEN+9F2KE4=; b=Vdm4Qf0WXNCxtQD750Imm9TnHbzKSdm5D04FXCglSYBCkxix+7ettFBoKU8KmODMgC NpogTMrMBXlNJ9mUWAsbWKNK5uedr0DubxYJeBXQ+/7c/D25iXqT0H+0sA8eaFRNC30a 3OCB20Yv2+6/90Qslk0kr+Utm3GfDBJgcbODx/4Y57q5OttOhkVBR1Onlkx8t8xULezT pZqUQUVW8wiwmUEl2tHoBwI0TZtulke3KQDbGM0moQwzTt9NUx72yc1jaWsSsZgOph0P sTS+6XBIlL6oWi/kKEZOrmxMbwHR1wryXozNZ2CiAoyajCyAf+xLV+pCGOHW+LpwMiC6 fwxg== X-Gm-Message-State: AJcUukcWqndlHnz/KlT0cU1BQZF527JHWBMWk8uC4WxrMOo/uc6E6msh mXIPwFBO1DOGYWtXeMsggjN5YvMY X-Google-Smtp-Source: ALg8bN7SOwDdGmgGbEovjT5JX5JCMZOnTPpubVMA7ebWeUgHN+B7s7S3qofLTO0D/I7RcWkzD0ZtNw== X-Received: by 2002:a5d:46cd:: with SMTP id g13mr15455369wrs.49.1547237574546; Fri, 11 Jan 2019 12:12:54 -0800 (PST) Received: from [192.168.1.54] (250.177.69.86.rev.sfr.net. [86.69.177.250]) by smtp.gmail.com with ESMTPSA id t70sm28594303wmd.36.2019.01.11.12.12.53 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Jan 2019 12:12:53 -0800 (PST) To: jmap@ietf.org From: =?UTF-8?Q?St=c3=a9phane_Blondon?= Openpgp: preference=signencrypt Autocrypt: addr=stephane.blondon@gmail.com; prefer-encrypt=mutual; keydata= mQINBFXJJhYBEAC7/HFBixd8OKor6GYAAgK6b596hQsZxAcChP4/Mg2vO5QK5jPKAoMye3Gn 2qtZmlUUds7kwxlXIMli7dqr/twYJ4+BWNHhwWYbcIjS+w9koYkqH1oDaoi2X7/VLuxHxk1I fwACSMGOeKWFqPHqNGfGKOS+u7grme5vTZ9WuvwxDU9JywQYdHaR6a857/US6tqBLlKB148V 5wtyKaWGvLssTrphJ2U+v4Pt1NExI0uAZK41D9y+MGYa7pkMqalTMUZ+0z0B0iEQFRfgRnwZ EiHLdFuOZlSxaKPbBMiOF3MuVjzaHjMb1yM0v7nwv1MxCTgFU/zihJP2CS53gQKLdkWgqQBP CrHJQOttoueQCNpq+FjUQlzwg40Wo0/Y5QrDOMW8g4QqKaZXVRf9Em68TLE75ZWN8RMLntX6 oByEYfYljxumbB8GFgoj88/z5Zf31x0bgRG3Az8xqToD2nQodRCjhz7KyKJl7IQw3/SSAqm/ LIO6mSE1e1QMg5sS/YUXm1sgqHaU2UbddxLkh14/XJbfgr+goGlB/iyE93zqPrpygzla/r6S JUL67A7M1eeYGG2aGOlMCfKVtFAdLGJPX3VvINoudp7zdCjF8pzlmq3scZF5oU/gO1sdfRYY llQE7OaneHzt8KzEJtWA8xA0ib/iQ6rka2/eYvFn1l80mRHIuQARAQABtC5TdMOpcGhhbmUg QmxvbmRvbiA8c3RlcGhhbmUuYmxvbmRvbkBnbWFpbC5jb20+iQJUBBMBCAA+AhsDBQsJCAcD BRUKCQgLBRYCAwEAAh4BAheAFiEEFXRbhjtX1pKPhY7rorkbxs1OvdwFAlltC5wFCQdmTHwA CgkQorkbxs1OvdwhLRAAlQbN41OM/rIcgYO+Fd2HLHK1ObIpkfo6vw+3KBi6tnnwICcXtR6S 4IUIVTB7KaB4MDqPNHiTJVAsIOzmBxnlGNHJ+28nxPvLYxJh7pMPzt41qzf9NH4WNgtBLMU9 rP1Qge6/GtZ3TOIhfJI6P43s/LTWysT0YCEv88ZiSItiRGxPu5cr8h3v4dPgQgwHstDqHb34 LeyzFfnihMN6jS2WS7GOL573I/6QflKqIhNK0q4j0Hj+XdXwP61ka/iSiHnewMn4kh6eOb7U n4MW0vodf0XdxopUeUfYY2DHomp5qTxwrRk435lO8023ARgQBqG0xaizkzZ+ZHQJrlmyv/j9 3FzJQyopxkel1yA/7ce36EVgKi1175bUQwG3/umtF973JP4YpAiYPtp/yh7bUTF0X+MtnSCB TIlJoL1TmYGs6+eW9MbUVSHYDVFvbofcyS18a4LCiBAdtuXpmpRM91ldf6Mi5iUWrAiN6xWt ZNLQ0s9fj3aYaOwBXoSsNoqpPqZ558L6c7IeW0T3QJUVl0ck3QhnHiEUulBp44TZxLyICo1f Kn7jZfoWOg7RNCfdQMa/zmLUyRMxYvfq0xXH+4PkkUj4AQF5JeYwEak0wHYaIfQbpgEEo0MU g/ew9Sb5qnfXa+1PUBgcUmlIUL8XM79XhYQFkPOM//aUpUFkCUOclzu5Ag0EVckmFgEQAKz7 uWxb3tyFkVHpng9dNCkWbzXIDywcPiskmT9KBb+5xo9Z4lSClejaqFu7NvoT2AmCGD8oWVCh lWtIkssCtqDr8tn73tbS0L6DDosUQUuAf44FLFynuiyaqHMEKQSU/PmK3eKgck8XBqSs5eyp O0WR7D31gFMqKTCmQHKj+sAtmMuPF2oi/1ton7mywtARtJqLbmPRKzCw293tagKebK+7pgm+ ZRbfBUg49A5nxTE1J/OpiR642tI5NpK7DybLr4D+NKA5XQfQsM+s/LZ6DVLxiR41GsMRxUxS oLXBEzJdto2wqDqkc5AyB5/zRD/AuAbreCSgEm4eDKR/G5ayk/8k8b7UVCkjC5fn96Sh0Axl /0RySfOoQQQMzoQ2tB/YDYzllkrep83AFHcwtPTY9Oi7fDACtNHUKQEmux2F3VG2F1cjnPBs 6BOvZulYXu5K2ORxIOkMr36NUPGQO+OeWJuHekEkCSImH75sjxuAxodpnGnHqG8P70b/6UAJ aOWM62UdRmDIpB2OcmHuYB0ky0TjiWPqz2Q/armdqQnWWg/UWf84DDe5TSaRgATISiUxsf8Z rhbs+qIhJYZTGLgkHtoj7zyGOjQMRM5wugkhlRRAZPhhUUoo2tG67fZGCOHDLMPTntVmpAU8 xsItOp79bELIZtt500Fn+2/R6smV0ot1ABEBAAGJAjwEGAEIACYCGwwWIQQVdFuGO1fWko+F juuiuRvGzU693AUCWW0LqQUJB2ZMkwAKCRCiuRvGzU693OkVEACHWK6oLvx0G2TsZgCdYnnR TVpgP+8rx3NLBq1hdTBOkczc1lH6PudHzIOFI7kHK69mHsiFLmeeZOxTA8ONAGqz2zwATMd7 7nTaR4awvqkuo16v12ugLIKGOg9IKphxZ3DOP5pWAP1X4082k0uWhHe6Oax3hyo4Kfb/rAgT XUEqzBxiMnheOEQrP/TR/nqAJ+/eVozT3ro5RrvZYhyLGAuorwmUKm6piHTpWg3PxqNK7utJ jiulzIpqWxftiVSidVZlWKI6p17XqUDdNZ5Iv9k9AssARSW0UOPUOfbiNUJsVpJckGm0GCCF ycob8nu0cUS3kG3p6+AbLq2cVi5z/Bz4q3j0YEy9fyBWKrEf9KasaeZ2SGs9VXsBQjfFff/W onosDypJfl3iPEdPo5QcjRN4z+Q9QQzhAAtUztKICcML6iZyEMMNixYykBWNlsQDAJwLxwh6 XngUcQ3Sg5k2GfivK1EAcG4GQHr4DtuyNVpWDMXv1zZy+NxNEvNNo0JE77lzkKkQRX8fxzfO W3/nj5rYFafSvDkFyliTleppUCty8oNVTCZ02fibJW58ZECuSumj9vFK6lNL9OjI8i1+hkA2 W82FVjs+7NlXgl9gF049Cr9Ga6PDJXCn6avjAPlSUr0HAROizZhFVozUcVPMGzD8wSq45f3V +hK2GY8icLkiwA== Message-ID: <16c06787-294e-70a1-8414-57d070185bd7@gmail.com> Date: Fri, 11 Jan 2019 21:12:38 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Tcl2BzNGWajlXZ76hWFpC7RxcXdokz9G4" Archived-At: X-Mailman-Approved-At: Fri, 11 Jan 2019 13:14:28 -0800 Subject: [Jmap] questions about batch of commands and smtpReply string X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2019 20:14:17 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Tcl2BzNGWajlXZ76hWFpC7RxcXdokz9G4 Content-Type: multipart/mixed; boundary="iFwxciPpOlNUQmGecmYq5ygOgRXzDScSq"; protected-headers="v1" From: =?UTF-8?Q?St=c3=a9phane_Blondon?= To: jmap@ietf.org Message-ID: <16c06787-294e-70a1-8414-57d070185bd7@gmail.com> Subject: questions about batch of commands and smtpReply string --iFwxciPpOlNUQmGecmYq5ygOgRXzDScSq Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable I read the documentation on jmap.io and I have two questions/remarks: 1. Batch of commands -------------------- Jmap has the ability to get a batch of commands. What is the expected behaviour if an error occurs in one of the command? For example, a batch submit 3 e-mails (A, B and C). The e-mail A is sent, B has an error (invalidEmail for example). Should the server send e-mail C? As there is no atomicity for the whole batch, I guess there will be problems if the batch ignore the error and pass to next command. However, I didn't found which behaviour is required in the specification. 2. smtpReply ------------ It's in section 7: Email submission. Perhaps, it would be easier if it would be an array with the SMTP reply code, SMTP Enhanced Mail System Status Code and additionnal infos instead of a string concatening those data by a space. Example: 550 5.7.1 Our system has detected that this message is likely spam. would be [550, "5.7.1", "Our system has detected that this message is likely spam.= "] Regards --=20 St=C3=A9phane --iFwxciPpOlNUQmGecmYq5ygOgRXzDScSq-- --Tcl2BzNGWajlXZ76hWFpC7RxcXdokz9G4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEFXRbhjtX1pKPhY7rorkbxs1OvdwFAlw4+L4ACgkQorkbxs1O vdzLtg/+NfGeCxyz1vrBHcwWLYexm6nv8XT+YBhkvAY8xiFZKwzQ9wvpLLtOnu6v P6bCqqxnbHmxXCxAqBrC0zXvNRIfs/flel4mqMqJyuAbyNrc+RC1/GTM+BExd9Vc Ah95yDz96GKvQAnIk0jaUaIpS38wUsPSDdSN6vspgHtQjwdT2OpRzYUddWOD0oHH EfQ6IRflS5FqC+u0HqyeqtMcAh4d+VduLVx/SWf2PVSay5Ji4aXrxw4d2opM8g0J HoBlS+ZsCX4njsnY0eZToAQUjdAAU8PFDsWzCxDkKRSXBhaq+G9gNqdgNb4Z922b t6s8+wcZUqn8LYzSQkOcyMZehvVQtb5s3aE2lDfq46PQ/dpFhcNJNmCW5DbXuw7W Z2GPaAUCbEPN7fuooBY/i6rOXuVox/fMNxHxryVEd/n9k0CbOzEUowv2t6kMurgi sMT+ueGhAAU6SbaBBpsS38HJQzGwi5EIXWMien2MGV9g+3jMXi0xu5DcClXNqKmV yi64xzPghawJbUPLvwNVqTxOlFWx1w4Dd+LU0WpBqVvZG/c0yeGiycW0MU4W15Xs 34HF2KUsi7BhgFDFkMG32GQG1c+CUJqBgMauhA5k5KuBR245MeLNkDqnJpxjNaOy /EIhnWJPA1AtdyEGIFoYbbahliz46qBys1La2KffrOy8Ihn0LI4= =AlC/ -----END PGP SIGNATURE----- --Tcl2BzNGWajlXZ76hWFpC7RxcXdokz9G4-- From nobody Sun Jan 13 16:09:07 2019 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 7D32D1200D7 for ; Sun, 13 Jan 2019 16:09:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 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_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=jwBnx/1L; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Vv5k3qhx 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 6FniAgGH9mrY for ; Sun, 13 Jan 2019 16:09:04 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB5B71200B3 for ; Sun, 13 Jan 2019 16:09:04 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 9EEAA289BA for ; Sun, 13 Jan 2019 19:09:03 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Sun, 13 Jan 2019 19:09:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:subject:content-type; s=fm1; bh=hpmiQlTwS73DrixjFcODNzOeH6kd T3IXZyfFauhYD5Q=; b=jwBnx/1Lgpk8sH2uue6Yc1RSMP4nu35luhnkZuYoVroU 5BemUDhc8gXsQrlb8L6lu061xyl5ki0dMNiQwuuFhn+TrqUMKSb0Wg6UteZ/PS0d gFCox61c4VjKW7ZzgiNLSoR/9NJ+ZxVfpckFuhzIpwt4CKAaVdcJ95n5FaqObj7a qat50bTvVBToRB32e70friXwtQ3Q/4j/fQ9UxBhoC4jYfCgIR6J8zzvH9SMCzd0h 6K6+weByrSPctbx2rN1C5aATtZaK4zliYzeg3g66TnCYlDL70BojmDGmPLowy5sT rRHWeIgGN1homUjQd1aHAYkgWmLq9bEuITepCYg5Yg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=hpmiQlTwS73DrixjF cODNzOeH6kdT3IXZyfFauhYD5Q=; b=Vv5k3qhxvQZ0O4bo7PP8o96KKj34/W+ap w9M5TZgJ9zJH9V1WSA9m9iWjJCD//f1yqJjRUFAQiG/nz2C8yqfDAze4QDccEQ/T YeI1OEDg045XdQ4vILDtthHkWH6cTxJRbQ3tDIz7vNOLUzJT+q40ah/0vQAqP8h7 v9131uE+GqLTyf7nLAzvqti8KTUElMBbU79eeJNVkhyrh2mRE6cQJKO8/Zovx5UP khQ58dkKL9vkN/PyVHQLO52FjubYH6MZK+GEvA/go72btQ6f7W7eqRZFhT+xAYIp xBustLrJ7fGKN13G/4pPZyYfKSPgT80oAInWGsQAkMoDKnW24fjWg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrgedtgddukecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepofgfkfgjfhffhf fvufgtsegrtderreerreejnecuhfhrohhmpedfpfgvihhlucflvghnkhhinhhsfdcuoehn vghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomheqnecuffhomhgrihhnpehjmhgrph drihhonecurfgrrhgrmhepmhgrihhlfhhrohhmpehnvghilhhjsehfrghsthhmrghilhht vggrmhdrtghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id C70EC203F2; Sun, 13 Jan 2019 19:09:02 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-739-g7452a1e-fmstable-20190103v1 X-Me-Personality: 64588216 Message-Id: In-Reply-To: <16c06787-294e-70a1-8414-57d070185bd7@gmail.com> References: <16c06787-294e-70a1-8414-57d070185bd7@gmail.com> Date: Sun, 13 Jan 2019 19:08:19 -0500 From: "Neil Jenkins" To: "IETF JMAP Mailing List" Content-Type: multipart/alternative; boundary=0d987a0e9db044759fd8db86fc19dbaf Archived-At: Subject: Re: [Jmap] questions about batch of commands and smtpReply string X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2019 00:09:06 -0000 --0d987a0e9db044759fd8db86fc19dbaf Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Sat, 12 Jan 2019, at 08:14, St=C3=A9phane Blondon wrote: > Jmap has the ability to get a batch of commands. What is the expected > behaviour if an error occurs in one of the command? It is expected to continue with the next command, 3.5.2 Method-level errors *If a method encounters an error, the appropriate error response MUST be= inserted at the current point in the methodResponses array and, unless = otherwise specified, further processing MUST NOT happen within that meth= od call. * * * *Any further method calls in the request MUST then be processed as norma= l. Errors at the method level MUST NOT generate an HTTP-level error.* 5.3 /set (for set-level errors) *Each creation, modification or destruction of an object is considered a= n atomic unit. It is permissible for the server to commit changes to som= e objects but not others* Neil. --0d987a0e9db044759fd8db86fc19dbaf Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Sat, 12 Jan = 2019, at 08:14, St=C3=A9phane Blondon wrote:
Jmap has the ability to get a batch o= f commands. What is the expected
behaviour if an error occ= urs in one of the command?

It = is expected to continue with the next command,


If a method encounters an error,= the appropriate error response MUST be inserted at the current point in= the methodResponses array and, unless otherwise specified, further proc= essing MUST NOT happen within that method call.
Any further method calls in the request MUST then be = processed as normal. Errors at the method level MUST NOT generate an HTT= P-level error.

5.3 /set (for set-level errors)

Each creation, modification or destruction of an obj= ect is considered an atomic unit. It is permissible for the server to co= mmit changes to some objects but not others

=
Neil.
--0d987a0e9db044759fd8db86fc19dbaf-- From nobody Mon Jan 14 19:37:41 2019 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EFE2E126BED; Mon, 14 Jan 2019 19:37:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <154752345394.9580.15033909195675398679@ietfa.amsl.com> Date: Mon, 14 Jan 2019 19:37:33 -0800 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-core-13.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2019 03:37:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the JSON Mail Access Protocol WG of the IETF. Title : JSON Meta Application Protocol Authors : Neil Jenkins Chris Newman Filename : draft-ietf-jmap-core-13.txt Pages : 74 Date : 2019-01-14 Abstract: This document specifies a protocol for clients to efficiently query, fetch and modify JSON-based data objects, with support for push notification of changes and fast resynchronisation, and out-of-band binary data upload/download. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jmap-core/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-jmap-core-13 https://datatracker.ietf.org/doc/html/draft-ietf-jmap-core-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-core-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jan 14 19:39:10 2019 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0340712F1AB; Mon, 14 Jan 2019 19:39:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <154752354899.9540.6683710651877099808@ietfa.amsl.com> Date: Mon, 14 Jan 2019 19:39:09 -0800 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-mail-13.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2019 03:39:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the JSON Mail Access Protocol WG of the IETF. Title : JMAP for Mail Authors : Neil Jenkins Chris Newman Filename : draft-ietf-jmap-mail-13.txt Pages : 90 Date : 2019-01-14 Abstract: This document specifies a data model for synchronising email data with a server using JMAP. Clients can use this to efficiently search, access, organise and send messages, and get pushed notifications for fast resynchronisation when new messages are delivered or a change is made in another client. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jmap-mail/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-jmap-mail-13 https://datatracker.ietf.org/doc/html/draft-ietf-jmap-mail-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-mail-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jan 14 19:40:35 2019 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 B9F9D12F1AB for ; Mon, 14 Jan 2019 19:40:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 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_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=RsxC5N3k; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=c+qtcuaF 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 cp0V90EwgS2f for ; Mon, 14 Jan 2019 19:40:32 -0800 (PST) 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 0AD16126BED for ; Mon, 14 Jan 2019 19:40:32 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 37AE828829; Mon, 14 Jan 2019 22:40:31 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Mon, 14 Jan 2019 22:40:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:cc:subject:content-type; s=fm1; bh=+DFgjBt2sHMgUXcNosHp94nej DnxOIfNmJhCZgsz8wM=; b=RsxC5N3k1Da91ixKhb05mwUR+6q+jJOCVWRGJ35yO Wa/Tnn+rDSVEr+WcUC82HZgXzpsoV6yL202Fv4Rd446u678YORxCbuBc1b1RhaXq fM0jAbNde9Cv3R028rlNVBzbnt3YqbqijW7Q6Cy4x5sJXdwtwLRlZFkYQl+b6xY6 uUjGJuYwhTj/XzhuG4LXmqTpAmWKh3tXUXnBI/eiECEq2m9VNJOLipNPkkW3pLos wJ44k5eSaChiVwX4qbfRZ0jFaTHCScSry+Iusv8o+rW2c30n/whSHFhY3eWjCFoR a3JO8xcyU6z/VqT3LU5A+p51WU87D/iX/asyfNViE9Qng== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=+DFgjBt2sHMgUXcNo sHp94nejDnxOIfNmJhCZgsz8wM=; b=c+qtcuaFiDCoDpgt2OTuLWlmf8GCKHbzj MpAqHxzlnEYBuBifqPYY5x7vlThtq3WJwT4RgmYTmHp11LQTfDGYfvyund0Slzsk zw/wM/mSnLL70hxEejKBN0Lqut2ppoAto/KPCNmnsyL+R1BVzIXFaE//20K7NOv+ MzFss1uYzYUkZmOzZFpAW3ssnBCqT2WgT4UfSd6YE6ojTgGgeYyI3GcIJEkIpFbM kx+oVO4c175bz5HgNaJ1IVtUhDJXSyQIiC9reGUtZLYOQjwZOP6zdzxcnt4nBgmU 1PSkfHLrUcB6gHUgQhvMVVQyLBG96AR8cHBYIyng11azZhMd4NzXQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrgedvgdeiudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepofgfkfgjfhffhf fvufgtsegrtderreerreejnecuhfhrohhmpedfpfgvihhlucflvghnkhhinhhsfdcuoehn vghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomheqnecuffhomhgrihhnpehhthhtph hfohhrthhrrghnshhpohhrthifvggrlhhrvggrugihhhgrvhgvrghmvggthhgrnhhishhm fhhorhhthhhishdrshhopdhivghtfhdrohhrghenucfrrghrrghmpehmrghilhhfrhhomh epnhgvihhljhesfhgrshhtmhgrihhlthgvrghmrdgtohhmnecuvehluhhsthgvrhfuihii vgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id B23302040E; Mon, 14 Jan 2019 22:40:30 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-739-g7452a1e-fmstable-20190103v1 X-Me-Personality: 64588216 Message-Id: In-Reply-To: References: <98b0db46-93e6-d03b-085d-15f66912fca6@isode.com> <0f1c0d19-f473-c7f6-11e2-a60f12b5a106@isode.com> <1c8e5f38-87ac-4bfe-a941-ce80aac49f51@beta.fastmail.com> Date: Mon, 14 Jan 2019 22:40:26 -0500 From: "Neil Jenkins" To: "Alexey Melnikov" Cc: "IETF JMAP Mailing List" Content-Type: multipart/alternative; boundary=f921759657454b7cb26dbe5e66dcbf38 Archived-At: Subject: Re: [Jmap] AD review of draft-ietf-jmap-mail-12 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2019 03:40:35 -0000 --f921759657454b7cb26dbe5e66dcbf38 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Fri, 11 Jan 2019, at 22:46, Alexey Melnikov wrote: >>> I think I want a new type for parsing ;-separated attribute=3Dvalue = pairs with RFC 2231 parameters, as this is a pain to do in clients./ >> Is that something you want in this spec, or leave to an extension? > As a client developer I would prefer to have this in the base spec, be= cause I think this would make JMAP more useful for me. As the responsibl= e AD, I am ambivalent about base spec versa extension. This is a bit of a pain to define as a generic type because it's not a g= eneric form in any of the RFCs. There's the Content-Type definition in 2= 045, and the Content-Disposition definition in 6266. I think I will leav= e this for someone else to do as an extension if there's demand. >>>> *The server SHOULD support messages with [@!RFC6532] EAI headers.* >>> In IMAP4rev2 we made it a MUST. I wouldn't mind if you add a capabil= ity for this. >>=20 >> I'm interested in *what implementors on the list think about this*; w= ould you prefer this be a MUST, or optional with a capability to indicat= e support? > As a developer I appreciate that this might be a non trivial amount of= work (more work than adding RFC 2231 decoding ;-)), so I don't mind thi= s being an extra capability. As AD, I think this needs to be in the curr= ent MAIL document (whether as an extension or as a MUST). > I would also like to hear what other people think about this. I've made this a MUST. Makes sense given IMAPrev2 is doing it, let's for= ward to a brave new world=E2=80=A6 >> Since we're using HTTP for transport we already have a mechanism for = this. So I have changed this to: >>=20 >> *The server SHOULD use information from the Accept-Language header of= the request, as defined in RFC7231 section 5.3.5 , to help determine the choice of localisat= ion if multiple are available. The Content-Language header of the respon= se (see section 3.1.3.2 of RFC7231) SHOULD indicate the language being used for user-visib= le strings.* >>=20 >> Does that sound reasonable? > Yes. But again, this probably belongs to CORE. > Either way, can you add an example (or extend an existing one) to demo= nstrate use of this feature? OK. I've added this to the Core spec: *3.7 Localisation of user-visible strings* *If returning a custom string to be displayed to the user, for example a= n error message, the server SHOULD use information from the Accept-Langu= age header of the request (as defined in [@!RFC7231] section 5.3.5) to h= elp determine the choice of localisation if multiple are available. The = Content-Language header of the response (see section 3.1.3.2 of [@!RFC72= 31]) SHOULD indicate the language being used for user-visible strings.**= * ** *For example, suppose a request was made with the following header:*** ** ` Accept-Language: fr-CH, fr;q=3D0.9, de;q=3D0.8, en;q=3D0.7, *;q=3D0.5`= ** ** *and a method generated an error to display to the user. The server has = translations of the error message in English and German. Looking at the = Accept-Language header, the user's preferred language is French. Since w= e don't have a translation for this, we look at the next most preferred = which is German. We have a German translation so the server returns this= , and indicates the language chosen in a Content-Language header like so= :*** ** ` Content-Language: de`** and then replaced the MessageSubmission rejection example in the Mail sp= ec with this: *Suppose instead an admin has removed sending rights for the user, and s= o the email submission is rejected with a "forbiddenToSend" error. The d= escription argument of the error is intended for display to the user, so= should be localised appropriately. Let's suppose the request was sent w= ith an Accept-Language header like this:*** ** ` Accept-Language: de;q=3D0.9,en;q=3D0.8`** ** *The server should attempt to choose the best localisation from those it= has available based on the Accept-Language header, as described in [@!I= -D.ietf-jmap-core], section 3.7. If the server has English, French and G= erman translations it would choose German as the preferred language and = return a response like this:*** ** [[ "EmailSubmission/set", { "accountId": "ue411d190", "oldState": "012421s6-8nrq-4ps4-n0p4-9330r951ns21", "newState": "012421s6-8nrq-4ps4-n0p4-9330r951ns21", "notCreated": { "k1490": { "type": "forbiddenToSend", "description": "Verzeihung, wegen verd=C3=A4chtiger Aktivit=C3= =A4ten Ihres Benutzerkontos haben wir den Versand von Nachrichten gesper= rt. Bitte wenden Sie sich f=C3=BCr Hilfe an unser Support Team." } } }, "0" ]] I think that addresses all the concerns raised so far, so I have release= d new core and = mail drafts to = progress to IESG last call. Cheers, Neil. --f921759657454b7cb26dbe5e66dcbf38 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Fri, 11= Jan 2019, at 22:46, Alexey Melnikov wrote:
I think I want a new type for parsing ;-separated attribute=3Dvalue pairs with RFC 2231 parameters, = as this is a pain to do in clients./
I= s that something you want in this spec, or leave to an extension?

As a client developer I woul= d prefer to have this in the base spec, because I think this would make JMAP more useful for me. As = the responsible AD, I am ambivalent about base spec versa extension.


This is a bit o= f a pain to define as a generic type because it's not a generic form in = any of the RFCs. There's the Content-Type definition in 2045, and the Co= ntent-Disposition definition in 6266. I think I will leave this for some= one else to do as an extension if there's demand.

The server SHOULD s= upport messages with [@!RFC6532] EAI headers.
In IMAP4rev2 w= e made it a MUST. I wouldn't mind if you add a capability for this.

I'm interested in what implementors on the list think about this; would you prefer this be a MUST, or optional with a capability to indicate support?

= As a developer I appreciate that this might be a non trivial amount of work (more work than adding RFC 2231 decoding ;-)), so I= don't mind this being an extra capability. As AD, I think this needs to be in the current MAIL document (whether as an extension or as a MUST).

I would also like to hear what other peop= le think about this.


I've made t= his a MUST. Makes sense given IMAPrev2 is doing it, let's forward to a b= rave new world=E2=80=A6

Since we're using HT= TP for transport we already have a mechanism for this. So I have changed this to:
The server SHOULD use information from the Accept-Languag= e header of the request, as defined in RFC7231 section 5.3.5, to help determine the choice of localisation if multiple are available. The Content-Language header of the response (see section&nb= sp;3.1.3.2 of RFC7231) SHOULD indicate the language being used for user-visible strings.

Does that sound reas= onable?

Yes. But again, this probably belongs t= o CORE.

Either way, can you add an example (or extend an exist= ing one) to demonstrate use of this feature?


OK. I've added this to the Core spec:

3.7 Localisation of user-visible strings

If returning a custom string to be displayed to the user, for = example an error message, the server SHOULD use information from the Acc= ept-Language header of the request (as defined in [@!RFC7231] section 5.= 3.5) to help determine the choice of localisation if multiple are availa= ble. The Content-Language header of the response (see section 3.1.3= .2 of [@!RFC7231]) SHOULD indicate the language being used for user-visi= ble strings.

For examp= le, suppose a request was made with the following header:
=

    Accept-Language: fr= -CH, fr;q=3D0.9, de;q=3D0.8, en;q=3D0.7, *;q=3D0.5

and a method generated an error to displ= ay to the user. The server has translations of the error message in Engl= ish and German. Looking at the Accept-Language header, the user's prefer= red language is French. Since we don't have a translation for this, we l= ook at the next most preferred which is German. We have a German transla= tion so the server returns this, and indicates the language chosen in a = Content-Language header like so:

    Content-Language: de
=

and then replaced the MessageSubmission rejection ex= ample in the Mail spec with this:

Suppos= e instead an admin has removed sending rights for the user, and so the e= mail submission is rejected with a "forbiddenToSend" error. The descript= ion argument of the error is intended for display to the user, so should= be localised appropriately. Let's suppose the request was sent with an = Accept-Language header like this:

    Accept-Language: de;q=3D0.9,en;q=3D0.8

The server should attem= pt to choose the best localisation from those it has available based on = the Accept-Language header, as described in [@!I-D.ietf-jmap-core], sect= ion 3.7. If the server has English, French and German translations it wo= uld choose German as the preferred language and return a response like t= his:

    [[ "EmailSubmission/set", {
      "accountId": "ue411d190",
      "oldState": "012421s6-8nrq-4ps4-n0p4-9330r951ns21",
      "newState": "012421s6-8nrq-4ps4-n0p4-9330r951ns21",
      "notCreated": {
        "k1490": {
          "type": "forbiddenToSend",
          "description": "Verzeihung, wegen verd=C3=A4chtiger Aktivit=C3=
=A4ten Ihres Benutzerkontos haben wir den Versand von Nachrichten gesper=
rt. Bitte wenden Sie sich f=C3=BCr Hilfe an unser Support Team."
        }
      }
    }, "0" ]]

I think that addresses all th= e concerns raised so far, so I have released new core and mail drafts to p= rogress to IESG last call.

Cheers,
Neil.
--f921759657454b7cb26dbe5e66dcbf38-- From nobody Tue Jan 15 05:27:54 2019 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 A309C130E59 for ; Tue, 15 Jan 2019 05:27:52 -0800 (PST) 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, 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 V95tNECVRBgr for ; Tue, 15 Jan 2019 05:27:51 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id F34F7130DE3 for ; Tue, 15 Jan 2019 05:27:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1547558870; d=isode.com; s=june2016; i=@isode.com; bh=X3VarIO0FghmQdGcgKT99LbGscS6/E38DzYwdhiO4tU=; 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=OGjoQabv6ZTnZnvUpbW7sPQaAqpj3/whGgWlN0tVoO+C1aXQlr5e1hT7ge9ANGzvMX+FJt ydpl/cyZ2qM7CDsJ9kkzaXt97FCQtIWBQDiomExRk8PX7a14CRrGgK5Xvh6g374ElJt93B 4zuEmNfibZiRitH3+2UIlegDtgivkdo=; 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, 15 Jan 2019 13:27:50 +0000 From: Alexey Melnikov To: "jmap@ietf.org" , Neil Jenkins Message-ID: Date: Tue, 15 Jan 2019 13:27:46 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------FFAFBAF4096CD8337E250D44" Content-Language: en-GB Archived-At: Subject: [Jmap] AD review of draft-ietf-jmap-core-13 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2019 13:27:53 -0000 --------------FFAFBAF4096CD8337E250D44 Content-Type: text/plain; charset=windows-1252; format=flowed Content-transfer-encoding: quoted-printable Hi, This is my delayed review of the document. Most of the issues are minor,=20 so I didn't think they were worth delaying IETF LC for. In Section 2: o *primaryAccounts*: "String[Id]" A map of specification URIs -- Definition of Id doesn't allow for ":" or "/" used in URIs. Does it=20 need fixing? In Section 5.5: =A0=A0=A0=A0=A0 *=A0 *collation*: "String" (optional; default is server-dep= endent) =A0=A0=A0=A0=A0=A0=A0=A0 The identifier, as registered in the collation reg= istry defined =A0=A0=A0=A0=A0=A0=A0=A0 in [RFC4790], for the algorithm to use when compar= ing the order =A0=A0=A0=A0=A0=A0=A0=A0 of strings.=A0 The algorithms the server supports = are advertised =A0=A0=A0=A0=A0=A0=A0=A0 in the capabilities object returned with the JMAP = Session =A0=A0=A0=A0=A0=A0=A0=A0 object.=A0 If omitted, the default algorithm is se= rver-dependent, =A0=A0=A0=A0=A0=A0=A0=A0 but: =A0=A0=A0=A0=A0=A0=A0=A0 1.=A0 It MUST be unicode-aware. =A0=A0=A0=A0=A0=A0=A0=A0 2.=A0 It SHOULD have reasonable default behavior f= or many =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 languages when the user's language is = unknown. What exactly does this mean and how can this be tested for interoperability? =A0=A0=A0=A0=A0=A0=A0=A0 3.=A0 It MAY be selected based on out-of-band info= rmation about =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 the user's language/locale. You might want to mention your recently added text about use of=20 Accept-Language here. =A0=A0=A0=A0=A0=A0=A0=A0 4.=A0 It SHOULD be case-insensitive where such a c= oncept makes =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 sense for a language/locale. You might want to point to Section 5.2.3 of RFC 8264 here. In Section 5.7: description before the response doesn't mention keyword=20 "video", but the request included both "video" and "music". In Section 6.2: Is it worth recommending use of RFC 8246 (" HTTP Immutable Responses") here? 6.3.=A0 Blob/copy =A0=A0 The *SetError* may be any of the standard set errors that may be =A0=A0 returned for a _create_. In addition, the "notFound" SetError error =A0=A0 may be returned if the blobId to be copied cannot be found. =A0=A0 The following additional errors may be returned instead of the _Blob= / =A0=A0 copy_ response: =A0=A0 "fromAccountNotFound": The _fromAccountId_ included with the request =A0=A0 does not correspond to a valid account. This is hard to read and your earlier text was better. Can you maybe=20 talk about "notFound" and "fromAccountNotFound" together? In Section 9.4.5: "Intended use"should mention "placeholder", which is used in 9.4.7. In 9.4.6/9.4.7: use RFC XXXX instead of "this document". You can also=20 just reference draft-ietf-jmap-core reference here, I think RFC Editor=20 will understand that. Best Regards, Alexey --------------FFAFBAF4096CD8337E250D44 Content-Type: text/html; charset=windows-1252 Content-transfer-encoding: quoted-printable

Hi,

This is my delayed review of the document. Most of the issues are minor, so I didn't think they were worth delaying IETF LC for.


In Section 2:

o *primaryAccounts*: "String[Id]" A map of specification URIs

-- Definition of Id doesn't allow for ":" or "/" used in URIs. Does it need fixing?

In Section 5.5:

=A0=A0=A0=A0=A0 *=A0 *collation*: "String" (optional; default is server-dependent)
=A0=A0=A0=A0=A0=A0=A0=A0 The identifier, as registered in the collation = registry defined
=A0=A0=A0=A0=A0=A0=A0=A0 in [RFC4790], for the algorithm to use when com= paring the order
=A0=A0=A0=A0=A0=A0=A0=A0 of strings.=A0 The algorithms the server suppor= ts are advertised
=A0=A0=A0=A0=A0=A0=A0=A0 in the capabilities object returned with the JM= AP Session
=A0=A0=A0=A0=A0=A0=A0=A0 object.=A0 If omitted, the default algorithm is server-dependent,
=A0=A0=A0=A0=A0=A0=A0=A0 but:

=A0=A0=A0=A0=A0=A0=A0=A0 1.=A0 It MUST be unicode-aware.

=A0=A0=A0=A0=A0=A0=A0=A0 2.=A0 It SHOULD have reasonable default behavio= r for many

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 languages when the user's langua= ge is unknown.

What exactly does this mean and how can this be tested for interoperability?

=A0=A0=A0=A0=A0=A0=A0=A0 3.=A0 It MAY be selected based on out-of-band i= nformation about

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 the user's language/locale.

You might want to mention your recently added text about use of Accept-Language here.

=A0=A0=A0=A0=A0=A0=A0=A0 4.=A0 It SHOULD be case-insensitive where such = a concept makes

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 sense for a language/locale.

You might want to point to Section 5.2.3 of RFC 8264 here.


In Section 5.7: description before the response doesn't mention keyword "video", but the request included both "video" and "music".


In Section 6.2:

Is it worth recommending use of RFC 8246 ("

HTTP Immutable Responses") here?


6.3.=A0 Blob/copy

=A0=A0 The *SetError* may be any of the standard set errors that may be
=A0=A0 returned for a _create_. In addition, the "notFound" SetError error
=A0=A0 may be returned if the blobId to be copied cannot be found.

=A0=A0 The following additional errors may be returned instead of the _Blob/
=A0=A0 copy_ response:

=A0=A0 "fromAccountNotFound": The _fromAccountId_ included with the request
=A0=A0 does not correspond to a valid account.

This is hard to read and your earlier text was better. Can you maybe talk about "notFound" and "fromAccountNotFound" together?


In Section 9.4.5:

"Intended use"should mention "placeholder", which is used in 9.4.7.


In 9.4.6/9.4.7: use RFC XXXX instead of "this document". You can also just reference draft-ietf-jmap-core reference here, I think RFC Editor will understand that.


Best Regards,

Alexey


--------------FFAFBAF4096CD8337E250D44-- From nobody Tue Jan 15 05:44:47 2019 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 B29B1130DE3 for ; Tue, 15 Jan 2019 05:44:45 -0800 (PST) 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, 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 TQDjBKUTW9JY for ; Tue, 15 Jan 2019 05:44:44 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 4C15312D4E8 for ; Tue, 15 Jan 2019 05:44:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1547559883; d=isode.com; s=june2016; i=@isode.com; bh=t3oSFPb/r2pKbDmWeFTr+LgC3ZGjbdWTVcIVbqthpG8=; 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=pKDUbjy2KHihJGaop38BOc8uhR5OdM4PLLfyUN6KJmWZpGZcsKSEMxA3+pWIFg8RmgRBHq tHpcdv6yK2cYj8GQ2mUYgz8JsivEI5kDAgS+45EDAdOt1HU6wIRgMyPSdsF8GNXB9kN1p5 4ChindL87juCVgIM8b+6XPTn6zdHdp8=; 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, 15 Jan 2019 13:44:43 +0000 To: Neil Jenkins References: <154752354899.9540.6683710651877099808@ietfa.amsl.com> Cc: "jmap@ietf.org" From: Alexey Melnikov Message-ID: <2576229b-768d-f531-6467-ed97b4a3675a@isode.com> Date: Tue, 15 Jan 2019 13:44:42 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 In-Reply-To: <154752354899.9540.6683710651877099808@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [Jmap] I-D Action: draft-ietf-jmap-mail-13.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2019 13:44:46 -0000 Hi Neil, Thank you for working on addressing my comments. I think this addresses all agreed concerns from me. I would just request=20 one more change before I initiate IETF LC: Can you please move: =C2=A0=C2=A0 [XCLIENT]=C2=A0 Postfix, "Postfix XCLIENT Howto", 2019, =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 . from Normative to Informative? I don't believe it is required to=20 implement and it is used as an example of what to do. Having this normative reference to undocumented (as far as IETF is=20 concerned) SMTP extension might be a problem in IESG review. Thank you, Alexey From nobody Wed Jan 16 19:27:37 2019 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 03C4B130F55; Wed, 16 Jan 2019 19:27:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 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_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=rpZ8WdZN; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=CSBIlKOn 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 YT5wDTOWbfRD; Wed, 16 Jan 2019 19:27:34 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7FF012785F; Wed, 16 Jan 2019 19:27:34 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id BA3221329; Wed, 16 Jan 2019 22:27:33 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Wed, 16 Jan 2019 22:27:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:date:from:to:cc:subject :content-type; s=fm1; bh=i4TYWfB/foQqr1OEacwQqX8Pn0VS4uNoz9BfLPl X0T0=; b=rpZ8WdZNTZ4atJeUZ6YhuBYg5XcGm9cXq9CJmaUpHRRldG0PfSYATCy UmOd9gRoorWFshOZcWt526vHRcTz6XIexu8iTSGxVzA5HXJfflibceXUhHIKZxg6 lXAhkUoYalmMM6cQLUa1lwmHI3mRgDL8LEVCz2d2p4YNTpfpbDS5TeYxbwrJ6A+T 1xO4jnqMm7/MOVoxMKC510NNnHaeWQaE5t3ylNxU5pG2MClueAW0nfj3uc51dXSG W6/i3AACDlszhrz3Y4kyPZlsR7X/YebUjclfRV/HTZ6/+gVhON775Sg28tcFrmDt gREL/BzdkZgl8kX9/v67W59YwDTpuHg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:message-id :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=i4TYWfB/foQqr1OEacwQqX8Pn0VS4uNoz9BfLPlX0 T0=; b=CSBIlKOnOj1FbpmiRoFOcOo1SBKmZBEG+eusMTjbysKdoI+SMRzfGkY8a 9lwUSxT82B/3C77Q/VxlQHcrMK9+ACwpEwn+SgUP/vXoKp3dpBarfk4amuuUGC0s otbMIb8WJhakfkUEC3d6w2qQIYCASO1Gs9WF4am6zAaPfG3fFdKuWUDBOKvwB7yq 60I3iYZnmXUNqvHD6mLTclxtm1cXwlubJcoWt/NzyV3burOEfWqNwlNeqb1iksi3 PiRsz5nEKyLEY12RLfoKx7mS41BxZx2SpBbZfHFEU5KeWiVv4ryWv8bLfr6TlSK3 5Jds5JxOb8TK9dXvNMOAdCDFeKeyw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrgeeigdehkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucenucfjughrpefofgfkfffhvffutgesrgdtreerreertdenucfhrhhomhepfdeurh honhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtgho mheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgsehfrghsthhmrghilhhtvg grmhdrtghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id AD7552042D; Wed, 16 Jan 2019 22:27:32 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-761-gc103c9b-fmstable-20190103v1bis X-Me-Personality: 56629417 Message-Id: Date: Wed, 16 Jan 2019 22:27:32 -0500 From: "Bron Gondwana" To: jmap@ietf.org Cc: extra@ietf.org Content-Type: multipart/alternative; boundary=2fff86c72db34a36af2878e0777a9af2 Archived-At: Subject: [Jmap] I'm speaking about JMAP at Fosdem X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2019 03:27:36 -0000 --2fff86c72db34a36af2878e0777a9af2 Content-Type: text/plain Hi All, I'll be speaking at Fosdem in Brussels in a couple of weeks - just a lightning talk about JMAP and EXTRA work - telling people what's happening the open email standards world, and how to get involved. If anyone else is going to be in Brussels, I'd love to catch up. 2019-02-02 | 15:40:00 | H.2215 (Ferrer) | IMAP, JMAP and the future of open email standards I'll also be at CalConnect in Zurich the week after that, which I'll let the calsify list know about :) Cheers, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --2fff86c72db34a36af2878e0777a9af2 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi All,

I'll be speaking at Fosdem in Bruss= els in a couple of weeks - just a lightning talk about JMAP and EXTRA wo= rk - telling people what's happening the open email standards world, and= how to get involved.  If anyone else is going to be in Brussels, I= 'd love to catch up.

2019-02-02 | 15:40:00 | H.2215 (Ferr= er) | IMAP, JMAP and the future of open email standards

I= 'll also be at CalConnect in Zurich the week after that, which I'll let = the calsify list know about :)

Cheers,

Bro= n.

<= div class=3D"signature">--
  Bron= Gondwana, CEO, FastMail Pty Ltd
 = ; brong@fastmailteam.com


--2fff86c72db34a36af2878e0777a9af2-- From nobody Wed Jan 16 21:10:28 2019 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DBB261292F1; Wed, 16 Jan 2019 21:10:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <154770182086.29598.5878633421087005172@ietfa.amsl.com> Date: Wed, 16 Jan 2019 21:10:20 -0800 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-core-14.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2019 05:10:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the JSON Mail Access Protocol WG of the IETF. Title : JSON Meta Application Protocol Authors : Neil Jenkins Chris Newman Filename : draft-ietf-jmap-core-14.txt Pages : 75 Date : 2019-01-16 Abstract: This document specifies a protocol for clients to efficiently query, fetch and modify JSON-based data objects, with support for push notification of changes and fast resynchronisation, and out-of-band binary data upload/download. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jmap-core/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-jmap-core-14 https://datatracker.ietf.org/doc/html/draft-ietf-jmap-core-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-core-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jan 16 21:11:54 2019 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 045A81292F1; Wed, 16 Jan 2019 21:11:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <154770191300.29454.6860421512912477716@ietfa.amsl.com> Date: Wed, 16 Jan 2019 21:11:53 -0800 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-mail-14.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2019 05:11:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the JSON Mail Access Protocol WG of the IETF. Title : JMAP for Mail Authors : Neil Jenkins Chris Newman Filename : draft-ietf-jmap-mail-14.txt Pages : 90 Date : 2019-01-16 Abstract: This document specifies a data model for synchronising email data with a server using JMAP. Clients can use this to efficiently search, access, organise and send messages, and get pushed notifications for fast resynchronisation when new messages are delivered or a change is made in another client. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jmap-mail/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-jmap-mail-14 https://datatracker.ietf.org/doc/html/draft-ietf-jmap-mail-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-mail-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jan 16 21:12:36 2019 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 838CF130DE5 for ; Wed, 16 Jan 2019 21:12:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 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_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=OR5ImrYf; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=huOnaepZ 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 PQf46bbA45uN for ; Wed, 16 Jan 2019 21:12:33 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A5351292F1 for ; Wed, 16 Jan 2019 21:12:33 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 2978A27DC3; Thu, 17 Jan 2019 00:12:32 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Thu, 17 Jan 2019 00:12:32 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:cc:subject:content-type; s=fm1; bh=iod85DQz6iSQQ/xN9y80ZlaDE SkHds4/k3GX8OMLRWE=; b=OR5ImrYfAkYp7imuFa2yIb5O+LXrSUqWERZD3M6Ay VdL8iSBc+vUGgyHqOogX34CmCQ1AB9BYPEQGVbORd6K3Cm+7yNGbCnCiEjhrLnhT 8Y8274Nat3ITaRjSt57lBJoLXBHyLH8lLs2p1XbuhnTP4lV4x7MRXc2n/JdHXPrQ CawDxqYISdJPlL28DWSwPwnRessOrLKjjD4ss5+5i0eUU8655H9nQWMjhvZ5YbnM Wi2qPw+wyFmy7K5dllrU4099I51dVpUBdBX5Rd/SExKU5RorY/bTytC7JwknQ0Zj NlwELD7rNRQMvYDQTz4ASv0lUX0jJ0s9/5DbONbj/ZYfQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=iod85DQz6iSQQ/xN9 y80ZlaDESkHds4/k3GX8OMLRWE=; b=huOnaepZbIiOkuDOZINMcKUgumtaA8eya 1VUqf8SrcO5i1e9BAgwZAjsQnjhmxTICTqhevbq5ra1GjM28vyElmdO77mD3ygPH eucGu/UWiGJvgvW9qQCiyZyGDrBeT/XiIsDolqGdT6OrZmieCJduzk5znkFWmWCm BNmELsKhwCVRsgVaL6NW7LgOQv+wBhmMlyreIobsmsA6Dq4BK25OqjmVphxHdam/ lsf5QWjDBDux/V/bQVcRICFQ3ifFoEX7FowgVih+k10RkNohebxqXHSYvuN1Cfak dhkAs/em1eLbcQ/DSFKk9dEDQx8YsDYBlZDIYawAkcaxt9As5FhBg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrgeeigdektdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepofgfkfgjfhffhf fvufgtsegrtderreerredtnecuhfhrohhmpedfpfgvihhlucflvghnkhhinhhsfdcuoehn vghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomheqnecurfgrrhgrmhepmhgrihhlfh hrohhmpehnvghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomhenucevlhhushhtvghr ufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id BAAB62042D; Thu, 17 Jan 2019 00:12:31 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-785-g293c41d-fmnext-20190117v1 X-Me-Personality: 64588216 Message-Id: <5087743f-57bb-45e4-9554-7130e0a15107@beta.fastmail.com> In-Reply-To: References: Date: Thu, 17 Jan 2019 00:12:31 -0500 From: "Neil Jenkins" To: "Alexey Melnikov" Cc: "IETF JMAP Mailing List" Content-Type: multipart/alternative; boundary=16fc9a310c1947b0a2bf7feafd14dbc4 Archived-At: Subject: Re: [Jmap] AD review of draft-ietf-jmap-core-13 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2019 05:12:34 -0000 --16fc9a310c1947b0a2bf7feafd14dbc4 Content-Type: text/plain On Wed, 16 Jan 2019, at 00:27, Alexey Melnikov wrote: > o *primaryAccounts*: "String[Id]" A map of specification URIs > -- Definition of Id doesn't allow for ":" or "/" used in URIs. Does it need fixing? No, this is correct. The map is of type `String` to `Id`. The keys are specification URIs, which is why this is type `String`. The values are account ids, which is why the value type of the map is `Id`. > 2. It SHOULD have reasonable default behavior for many > languages when the user's language is unknown. > What exactly does this mean and how can this be tested for interoperability? Yeh, this is a bit wishy washy. It's trying to say the ordering should be as unsurprising as possible for as large a number of languages as possible. I agree this is not a sufficiently strong requirement to test inter-operably, so I have removed this text and instead just noted that the two recommended algorithms provide reasonable behaviour for a large number of languages. > 3. It MAY be selected based on out-of-band information about > the user's language/locale. > You might want to mention your recently added text about use of Accept-Language here. Sure. I've changed this to: *It MAY be selected based on an Accept-Language header in the request (as defined in [@!RFC7231] section 5.3.5), or out-of-band information about the user's language/locale.*** > 4. It SHOULD be case-insensitive where such a concept makes > sense for a language/locale. > You might want to point to Section 5.2.3 of RFC 8264 here. OK. I've changed this to: *It SHOULD be case-insensitive where such a concept makes sense for a language/locale. Where the user's language is unknown, it is RECOMMENDED to follow the advice in section 5.2.3 of [@!RFC 8264].* > In Section 5.7: description before the response doesn't mention keyword "video", but the request included both "video" and "music". I have fixed the text here. > In Section 6.2: > Is it worth recommending use of RFC 8246 ("** > HTTP Immutable Responses") here? Yes, that's reasonable. I have done this. > 6.3. Blob/copy > > The *SetError* may be any of the standard set errors that may be > returned for a _create_. In addition, the "notFound" SetError error > may be returned if the blobId to be copied cannot be found. > > The following additional errors may be returned instead of the _Blob/ > copy_ response: > > "fromAccountNotFound": The _fromAccountId_ included with the request > does not correspond to a valid account. > > This is hard to read and your earlier text was better. Can you maybe talk about "notFound" and "fromAccountNotFound" together? Hmm, I'm not sure how best to clarify this. The notFound error is at the set level, whereas the fromAccountNotFound is at the method level so it's hard to combine. I've made some small tweaks to clarify this and reference the standard set-level errors: *The *SetError* may be any of the standard set errors that may be returned for create, as defined in section 5.3. In addition, the `notFound` SetError error may be returned if the blobId to be copied cannot be found.*** ** *The following additional method-level error may be returned instead of the Blob/copy response:*** ** *`fromAccountNotFound`: The fromAccountId included with the request does not correspond to a valid account.* Is that sufficient? > In Section 9.4.5: > "Intended use"should mention "placeholder", which is used in 9.4.7. Thanks, fixed. > In 9.4.6/9.4.7: use RFC XXXX instead of "this document". You can also just reference draft-ietf-jmap-core reference here, I think RFC Editor will understand that. Right, fixed. I have now published new drafts with the fixes. Cheers, Neil. --16fc9a310c1947b0a2bf7feafd14dbc4 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Wed, 16= Jan 2019, at 00:27, Alexey Melnikov wrote:

o *primaryAccounts*: "String[Id]" A map= of specification URIs

-- Definition of Id doesn't allow fo= r ":" or "/" used in URIs. Does it need fixing?

No,= this is correct. The map is of type String to Id. The k= eys are specification URIs, which is why this is type String= . The values are account ids, which is why the value type of the map is = Id.

         2.&nb= sp; It SHOULD have reasonable default behavior for many
&n= bsp;            l= anguages when the user's language is unknown.

What exactly d= oes this mean and how can this be tested for interoperability?


Yeh, thi= s is a bit wishy washy. It's trying to say the ordering should be as uns= urprising as possible for as large a number of languages as possible. I = agree this is not a sufficiently strong requirement to test inter-operab= ly, so I have removed this text and instead just noted that the two reco= mmended algorithms provide reasonable behaviour for a large number = of languages.

         3.&= nbsp; It MAY be selected based on out-of-band information about
        =      the user's language/locale.

You mig= ht want to mention your recently added text about use of Accept-Language here.


Sure= . I've changed this to:

It MAY be select= ed based on an Accept-Language header in the request (as defined in [@!R= FC7231] section 5.3.5), or out-of-band information about the user's lang= uage/locale.

       =   4.  It SHOULD be case-insensitive where such a concept makes
        =      sense for a language/locale.

You mi= ght want to point to Section 5.2.3 of RFC 8264 here.


OK. I've changed this to:

<= div>It SHOULD be case-insensitive where such a concept makes sense fo= r a language/locale. Where the user's language is unknown, it is RECOMME= NDED to follow the advice in section 5.2.3 of [@!RFC 8264].

In S= ection 5.7: description before the response doesn't mention keyword "video", but the request included both "video" and "music".


I have fixed the = text here.

In Section 6.2:

Is it worth recommending use of= RFC 8246 ("

HTTP Immutable Responses") here?


Yes, that's reasonable. I have d= one this.

6.3.  Blob/copy

 =   The *SetError* may be any of the standard set errors that may be
   returned for a _create_. In addition= , the "notFound" SetError error
   may be returned if the blobId to = be copied cannot be found.

   The= following additional errors may be returned instead of the _Blob/
   copy_ response:
   "fromAccountNotFound": The _fromAccountId_ inc= luded with the request
   does not correspond to a valid = account.


This is hard to read and your earlier te= xt was better. Can you maybe talk about "notFound" and "fromAccountNotFound" together?


Hmm, I'm not sure how best to clar= ify this. The notFound error is at the set level, whereas the fromAccoun= tNotFound is at the method level so it's hard to combine. I've made some= small tweaks to clarify this and reference the standard set-level error= s:

The SetError may be any o= f the standard set errors that may be returned for create, as defined in= section 5.3. In addition, the notFound SetError error may = be returned if the blobId to be copied cannot be found.

The following additional method-level = error may be returned instead of the Blob/copy response:
<= /div>

fromAccountNotFound: The from= AccountId included with the request does not correspond to a valid accou= nt.

Is that sufficient?
<= br>

In Section = 9.4.5:

"Intended use"should mention "placeholder", which is us= ed in 9.4.7.


Thanks, fixed.
<= /div>

= In 9.4.6/9.4.7: use RFC XXXX instead of "this document". You can also just reference draft-ietf-jmap-core reference here, I think RFC Editor will understand that.


Right, fixed.

I have now published n= ew drafts with the fixes.

Cheers,
=
Neil.
--16fc9a310c1947b0a2bf7feafd14dbc4-- From nobody Wed Jan 16 21:14:20 2019 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 8CB6312F1AB for ; Wed, 16 Jan 2019 21:14:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 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_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=XW0mpQjI; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=a2DhRg0w 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 FSL3ykxOOQHl for ; Wed, 16 Jan 2019 21:14:17 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 785551292F1 for ; Wed, 16 Jan 2019 21:14:17 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 98CF325531; Thu, 17 Jan 2019 00:14:15 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Thu, 17 Jan 2019 00:14:15 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:cc:subject:content-type; s=fm1; bh=8HHSALNFxOHFvXvdiXUuIFVCY YI0/so12EzJJfTxB18=; b=XW0mpQjIX5OITubHvjwIfI59zDUafsYIjmgcUGkCj e8cVDWAeX7/4CPS7AKCnRK2S0CsO58NSOTfui8vVzfxSllC74jQady4xfzWjx2uy SJROtRIneolMxUliZJ6ZcvMBN3EecXZN61P6OTssT+aFJa0Rtot5AnEMsFD0A1z8 hX+L+XDz+z67xE0MS0k4gSPOVAfJO2KtvdtNTQ9lLP4Nc27J/53cCoVzhe3Mia15 mMeBPuAK9RTpKzr99beKKfJWKa5qF+yZcl7ycQ9uk6AROEe00l+aSZzRvvYPXqqj vZ4q0oYwDkWqjM9wv5uOUskUEXuvGBIYMrKgj0dMSmH7A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=8HHSALNFxOHFvXvdi XUuIFVCYYI0/so12EzJJfTxB18=; b=a2DhRg0wXR3N/TOFn0/VXLF8IEtjjIxfA ijjcD9ypLVgAEiPaxCqDjyKez1CpAE2sBqXUiZEs/XEhm34k2TtuW0N2WXplJxl3 5Q0QAsTvd8e810/yTGynHBBiz2XnxEtJiZaE55eBvoQrQ9qZEB1buagICrseaXv7 8kRg0I2F7RLqGHaQeHnMo77cKrfytlJAJ2m2vdHVbf6fh09jm6/iRDb18AYhpGQa BAPUU/T5eiPG52XY5i8cZowxj+mXrpYFACwStigYNO7QvgXvEiiuAkKo64az3aMY hFHoykFP8ND8mmIuH8RhOzfS2X2OFi3Lx1pXIryZzGYUkqpLuL1gg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrgeeigdekudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepofgfkfgjfhffhf fvufgtsegrtderreerredtnecuhfhrohhmpedfpfgvihhlucflvghnkhhinhhsfdcuoehn vghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomheqnecuffhomhgrihhnpehpohhsth hfihigrdhorhhgnecurfgrrhgrmhepmhgrihhlfhhrohhmpehnvghilhhjsehfrghsthhm rghilhhtvggrmhdrtghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 67EED2042D; Thu, 17 Jan 2019 00:14:15 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-785-g293c41d-fmnext-20190117v1 X-Me-Personality: 64588216 Message-Id: In-Reply-To: <2576229b-768d-f531-6467-ed97b4a3675a@isode.com> References: <154752354899.9540.6683710651877099808@ietfa.amsl.com> <2576229b-768d-f531-6467-ed97b4a3675a@isode.com> Date: Thu, 17 Jan 2019 00:14:15 -0500 From: "Neil Jenkins" To: "Alexey Melnikov" Cc: "IETF JMAP Mailing List" Content-Type: multipart/alternative; boundary=d770354a22824f1fb0a5caab357b7e15 Archived-At: Subject: Re: [Jmap] I-D Action: draft-ietf-jmap-mail-13.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2019 05:14:18 -0000 --d770354a22824f1fb0a5caab357b7e15 Content-Type: text/plain On Wed, 16 Jan 2019, at 00:44, Alexey Melnikov wrote: > Can you please move: > > [XCLIENT] Postfix, "Postfix XCLIENT Howto", 2019, > . > > from Normative to Informative? I don't believe it is required to > implement and it is used as an example of what to do. Done, and published in draft v14. Neil. --d770354a22824f1fb0a5caab357b7e15 Content-Type: text/html
On Wed, 16 Jan 2019, at 00:44, Alexey Melnikov wrote:
Can you please move:

   [XCLIENT]  Postfix, "Postfix XCLIENT Howto", 2019,
              <http://www.postfix.org/XCLIENT_README.html>.

from Normative to Informative? I don't believe it is required to 
implement and it is used as an example of what to do.

Done, and published in draft v14.

Neil.
--d770354a22824f1fb0a5caab357b7e15-- From nobody Mon Jan 21 11:52:10 2019 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B1B23126BED; Mon, 21 Jan 2019 11:52:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.89.3 Auto-Submitted: auto-generated Precedence: bulk CC: brong@fastmailteam.com, draft-ietf-jmap-mail@ietf.org, jmap@ietf.org, alexey.melnikov@isode.com, Bron Gondwana , jmap-chairs@ietf.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Message-ID: <154810032171.8145.4973483328327211530.idtracker@ietfa.amsl.com> Date: Mon, 21 Jan 2019 11:52:01 -0800 Archived-At: Subject: [Jmap] Last Call: (JMAP for Mail) to Proposed Standard X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2019 19:52:02 -0000 The IESG has received a request from the JSON Mail Access Protocol WG (jmap) to consider the following document: - 'JMAP for Mail' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2019-02-04. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies a data model for synchronising email data with a server using JMAP. Clients can use this to efficiently search, access, organise and send messages, and get pushed notifications for fast resynchronisation when new messages are delivered or a change is made in another client. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-jmap-mail/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-jmap-mail/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Wed Jan 23 03:16:37 2019 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 3EC69130E57 for ; Wed, 23 Jan 2019 03:16:35 -0800 (PST) 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, 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 Ju9dg1B2-Usq for ; Wed, 23 Jan 2019 03:16:33 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC7712D4F2 for ; Wed, 23 Jan 2019 03:16:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1548242192; d=isode.com; s=june2016; i=@isode.com; bh=u7/dTkNkc1MPSO/JY+R+Cv3fMRLzbTMa0HQBq7DVxJg=; 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=F4hYyFdbMLIHGWN6RyvYSOQ4Uwl4+dx6FOLZMGu+yOE1efnnDbI8R+fYwicgJ6Ky8AFARh zyA/YUmPVRpbXu2lxeGnkjaBDkJgiYw3GJCaB2fVcyEWN/obaG/jroGfnxmb47TxVq9shS YuvPn8gQw7//nZty9xtotA6jpFhCoHU=; 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, 23 Jan 2019 11:16:32 +0000 To: Neil Jenkins Cc: IETF JMAP Mailing List References: <5087743f-57bb-45e4-9554-7130e0a15107@beta.fastmail.com> From: Alexey Melnikov Message-ID: Date: Wed, 23 Jan 2019 11:15:41 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 In-Reply-To: <5087743f-57bb-45e4-9554-7130e0a15107@beta.fastmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------C94A670F222E5B2EC5555739" Content-Language: en-GB Archived-At: Subject: Re: [Jmap] AD review of draft-ietf-jmap-core-13 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2019 11:16:35 -0000 --------------C94A670F222E5B2EC5555739 Content-Type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: quoted-printable Hi Neil, On 17/01/2019 05:12, Neil Jenkins wrote: > On Wed, 16 Jan 2019, at 00:27, Alexey Melnikov wrote: >> >> o *primaryAccounts*: "String[Id]" A map of specification URIs >> >> -- Definition of Id doesn't allow for ":" or "/" used in URIs. Does=20 >> it need fixing? > > No, this is correct. The map is of type |String| to |Id|. The keys are=20 > specification URIs, which is why this is type |String|.. The values=20 > are account ids, which is why the value type of the map is |Id|. > Never mind then :-). >> 6.3.=C2=A0 Blob/copy >> >> =C2=A0=C2=A0 The *SetError* may be any of the standard set errors that ma= y be >> =C2=A0=C2=A0 returned for a _create_. In addition, the "notFound" SetErro= r error >> =C2=A0=C2=A0 may be returned if the blobId to be copied cannot be found. >> >> =C2=A0=C2=A0 The following additional errors may be returned instead of t= he _Blob/ >> =C2=A0=C2=A0 copy_ response: >> >> =C2=A0=C2=A0 "fromAccountNotFound": The _fromAccountId_ included with the= request >> =C2=A0=C2=A0 does not correspond to a valid account. >> >> >> This is hard to read and your earlier text was better. Can you maybe=20 >> talk about "notFound" and "fromAccountNotFound" together? >> > > Hmm, I'm not sure how best to clarify this. The notFound error is at=20 > the set level, whereas the fromAccountNotFound is at the method level=20 > so it's hard to combine. I've made some small tweaks to clarify this=20 > and reference the standard set-level errors: > > /The *SetError*=C2=A0may be any of the standard set errors that may be=20 > returned for create, as defined in section 5.3. In addition, the=20 > |notFound|=C2=A0SetError error may be returned if the blobId to be copied= =20 > cannot be found./ > > /The following additional method-level error may be returned instead=20 > of the Blob/copy response:/ > > /|fromAccountNotFound|: The fromAccountId included with the request=20 > does not correspond to a valid account./ > > Is that sufficient? I think this would be fine. Best Regards, Alexey --------------C94A670F222E5B2EC5555739 Content-Type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

Hi Neil,

On 17/01/2019 05:12, Neil Jenkins wrote:
On Wed, 16 Jan 2019, at 00:27, Alexey Melnikov wrote:

o *primaryAccounts*: "String[Id]" A map of specification URIs

-- Definition of Id doesn't allow for ":" or "/" used in URIs. Does it need fixing?

No, this is correct. The map is of type String to Id. The keys are specification URIs, which is why this is type=C2=A0String.. The values are account ids, which is why the value type of the map is Id.

Never mind then :-).
6.3.=C2=A0 Blob/copy

=C2=A0=C2=A0 The *SetError* may be any of the standard set erro= rs that may be
=C2=A0=C2=A0 returned for a _create_. In addition, the "notFoun= d" SetError error
=C2=A0=C2=A0 may be returned if the blobId to be copied cannot = be found.

=C2=A0=C2=A0 The following additional errors may be returned in= stead of the _Blob/
=C2=A0=C2=A0 copy_ response:

=C2=A0=C2=A0 "fromAccountNotFound": The _fromAccountId_ include= d with the request
=C2=A0=C2=A0 does not correspond to a valid account.


This is hard to read and your earlier text was better. Can you maybe talk about "notFound" and "fromAccountNotFound" together?


Hmm, I'm not sure how best to clarify this. The notFound error is at the set level, whereas the fromAccountNotFound is at the method level so it's hard to combine. I've made some small tweaks to clarify this and reference the standard set-level errors:

The SetError=C2=A0may be any of the standard set errors that may be returned for create, as defined in section 5.3. In addition, the notFound=C2=A0SetError error ma= y be returned if the blobId to be copied cannot be found.

The following additional method-level error may be returned instead of the Blob/copy response:

fromAccountNotFound: The fromAccountId included with the request does not correspond to a valid account.

Is that sufficient?

I think this would be fine.

Best Regards,

Alexey

--------------C94A670F222E5B2EC5555739-- From nobody Thu Jan 24 13:31:06 2019 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 0BAE3127B4C; Thu, 24 Jan 2019 13:31:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.42 X-Spam-Level: X-Spam-Status: No, score=-3.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779, 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 DxIr6MfshuKM; Thu, 24 Jan 2019 13:30:57 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 163ED131182; Thu, 24 Jan 2019 13:30:55 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id x0OLUi83023861 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 24 Jan 2019 23:30:44 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x0OLUhXv006091; Thu, 24 Jan 2019 23:30:43 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23626.11907.681078.321687@fireball.acr.fi> Date: Thu, 24 Jan 2019 23:30:43 +0200 From: Tero Kivinen To: "Neil Jenkins" Cc: secdir@ietf.org, "Bron Gondwana" , "IETF JMAP Mailing List" , draft-ietf-jmap-core.all@ietf.org, ietf@ietf.org In-Reply-To: References: <154651703823.29557.748556981627156046@ietfa.amsl.com> <7beebd38-7999-4a49-b892-c3c75b36eab4@beta.fastmail.com> <23603.20862.976183.378013@fireball.acr.fi> <23604.45941.279266.464196@fireball.acr.fi> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 4 min X-Total-Time: 4 min Archived-At: Subject: Re: [Jmap] Secdir last call review of draft-ietf-jmap-core-12 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2019 21:31:00 -0000 Neil Jenkins writes: > On Wed, 9 Jan 2019, at 1:28 AM, Tero Kivinen wrote: > > When you are subscribing the push notifications your devices should be > running and not offline. > > Agreed. It's still possible for the initial message not to arrive, but in the > vast majority of cases it will; if it doesn't, the client can destroy and > recreate the subscription to try again. Weighing this up, I agree that adding > a verification step is the best way forward here. > > When something changes on the server, the server pushes a > *StateChange* object to the client. > > Actually that says "to the client" not to the "push service". Which > one should it be? > > Well, it's to the client, possibly via a push service, but possibly not > because there are two "push" mechanisms defined here; the other is where the > client can maintain a permanent TCP connection directly to the JMAP server in > which case it can use an EventSource connection to receive push events > directly without going via a 3rd party. > > Hmm... and 7.2 then also uses term "push endpoint" which is not > defined anywhere? Is that the same as push service at given url > > Reading through it again, there was some confusion in the use of terminology. > I have rewritten a few sections to attempt to clarify this and the other > confusing points you pointed out. You can see the changes for this here. The > addition of a verification step is added in this change here. > > Are you happy that this is sufficient to address your concerns? Yes, I think this addresses my concerns about the denial of service issues. The text also seems to make little bit more clear about the terminology, and perhaps the Terminology section should refer to the terms defined in the RFC8030, so it would be clear which terms comes from there. Sorry that it took so long to reply, but last week I was in the IEEE meeting, thus I was not able to check these during that time. -- kivinen@iki.fi From nobody Thu Jan 24 16:00:40 2019 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 6C62E1311FC for ; Thu, 24 Jan 2019 16:00:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 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_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, 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=fastmailteam.com header.b=YESJnpL7; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=lnT5w2lp 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 Es6R011IuI8D for ; Thu, 24 Jan 2019 16:00:32 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6F02130EC8 for ; Thu, 24 Jan 2019 16:00:31 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id DDD8D221C7 for ; Thu, 24 Jan 2019 19:00:30 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Thu, 24 Jan 2019 19:00:30 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:subject:content-type; s=fm1; bh=9By676Y9ffF3CyIoQVBX2ia+l8sU hyS3V+3ybzb7Vxc=; b=YESJnpL700JTdOzlW2mWse+tYAF7mEM7rf24ZmbuFOSE tGBTXFaO4BHJQKrWKuDQbEDJAbNkY8A6TCUQkxU5HmnLu8zmgNuo07G06Ht/1vRj f/2lD2QME0yDWg8SJdmuQ46sR6N+Z9MJIxGFu2pmLt5AigLTGyUr3OFSzCmn7XHH gZjUpnf5pRVZErEkPsQYUMMSScwNM8ZvkgWUzXV4amhLhtCgW/t6fB9FfYekMZ87 Ax6veb/SrwVnq6LpSV2yQW9WH05coSZr6xvZ/8oEJKSk+oc3OIwWBkyHfPvtOj+r +c13ExwdVFm1Rye5slG1JjtsJxvWIqb2H0Kp0Lb9qw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=9By676Y9ffF3CyIoQ VBX2ia+l8sUhyS3V+3ybzb7Vxc=; b=lnT5w2lp4qAcPRjMrf+X15twCnCE58eCt wZcI3fPDgIszPjpQ8anbuoFw5x6w+5GrbXHogXFQ9KcMFg/qbn3ndx0esUe9/+y4 Ra7Dm5xfV0zDssw9ajXKdAPTOpCOOZT4DGdNRZcxcWxRrrJd9C0fMjgiMavkt6Ec sSiqFI8oEtb3/lF+fQVX76nU34T6as2/i0iTeGeBsplH3SrkDuRpCdRJ/7AI2GC1 jfzE5MSxNLE/palQBLyZ9NssElNTOFGiDvVjJmnyJ8hqK9YaepRSxLr99vFIb2A+ DirEn5Q8XlhuCDv87srOSrtk0EUcTUWLuFpXXO5dhWW/1eFYGwq9Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrieefgddujecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucenucfjughrpefofgfkjghffffhvffutgesrgdtreerreertdenucfhrhhomhepfd eurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdr tghomheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgsehfrghsthhmrghilh htvggrmhdrtghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 5BAFF20250; Thu, 24 Jan 2019 19:00:30 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-816-g6582a22-fmnext-20190123v1 X-Me-Personality: 56629417 Message-Id: <0c14834e-e98c-4c67-b943-5285088635c5@beta.fastmail.com> In-Reply-To: <23626.11907.681078.321687@fireball.acr.fi> References: <154651703823.29557.748556981627156046@ietfa.amsl.com> <7beebd38-7999-4a49-b892-c3c75b36eab4@beta.fastmail.com> <23603.20862.976183.378013@fireball.acr.fi> <23604.45941.279266.464196@fireball.acr.fi> <23626.11907.681078.321687@fireball.acr.fi> Date: Thu, 24 Jan 2019 19:00:29 -0500 From: "Bron Gondwana" To: jmap@ietf.org Content-Type: multipart/alternative; boundary=7dc635bd576c4f3db57c2b209e61e68b Archived-At: Subject: Re: [Jmap] Secdir last call review of draft-ietf-jmap-core-12 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2019 00:00:33 -0000 --7dc635bd576c4f3db57c2b209e61e68b Content-Type: text/plain Thanks Tero - welcome back! On Fri, Jan 25, 2019, at 08:31, Tero Kivinen wrote: > Neil Jenkins writes: > > On Wed, 9 Jan 2019, at 1:28 AM, Tero Kivinen wrote: > > > > When you are subscribing the push notifications your devices should be > > running and not offline. > > > > Agreed. It's still possible for the initial message not to arrive, but in the > > vast majority of cases it will; if it doesn't, the client can destroy and > > recreate the subscription to try again. Weighing this up, I agree that adding > > a verification step is the best way forward here. > > > > When something changes on the server, the server pushes a > > *StateChange* object to the client. > > > > Actually that says "to the client" not to the "push service". Which > > one should it be? > > > > Well, it's to the client, possibly via a push service, but possibly not > > because there are two "push" mechanisms defined here; the other is where the > > client can maintain a permanent TCP connection directly to the JMAP server in > > which case it can use an EventSource connection to receive push events > > directly without going via a 3rd party. > > > > Hmm... and 7.2 then also uses term "push endpoint" which is not > > defined anywhere? Is that the same as push service at given url > > > > Reading through it again, there was some confusion in the use of terminology. > > I have rewritten a few sections to attempt to clarify this and the other > > confusing points you pointed out. You can see the changes for this here. The > > addition of a verification step is added in this change here. > > > > Are you happy that this is sufficient to address your concerns? > > Yes, I think this addresses my concerns about the denial of service > issues. The text also seems to make little bit more clear about the > terminology, and perhaps the Terminology section should refer to the > terms defined in the RFC8030, so it would be clear which terms comes > from there. > > Sorry that it took so long to reply, but last week I was in the IEEE > meeting, thus I was not able to check these during that time. Just to confirm - are you happy to clear your "has issues" now, or do you need further changes to the terminology reference first. Thanks, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --7dc635bd576c4f3db57c2b209e61e68b Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Thanks Tero - welcome back!

On Fri, Jan 25,= 2019, at 08:31, Tero Kivinen wrote:
Neil Jenkins wr= ites:
> On Wed, 9 Jan 2019= , at 1:28 AM, Tero Kivinen wrote:
> 
> &nb= sp;   When you are subscribing the push notifications your dev= ices should be
> &nbs= p;   running and not offline.
> 
> Ag= reed. It's still possible for the initial message not to arrive, but in = the
> vast majority of cas= es it will; if it doesn't, the client can destroy and
> recreate the subscription to try again. We= ighing this up, I agree that adding
> a verification step is the best way forward here.
<= div style=3D"font-family:Arial;">> 
>        When somet= hing changes on the server, the server pushes a
>        *State= Change* object to the client.
>    
>     Actually that says "to the client" not to = the "push service". Which
>= ;     one should it be?
> 
>= ; Well, it's to the client, possibly via a push service, but possibly no= t
> because there are two = "push" mechanisms defined here; the other is where the
> client can maintain a permanent TCP conne= ction directly to the JMAP server in
> which case it can use an EventSource connection to receive = push events
> directly wit= hout going via a 3rd party.
&= gt; 
>  &nb= sp;  Hmm... and 7.2 then also uses term "push endpoint" which is no= t
>    = ; defined anywhere? Is that the same as push service at given url
> 
> Reading through it again, there was some confusi= on in the use of terminology.
> I have rewritten a few sections to attempt to clarify this and the= other
> confusing points = you pointed out. You can see the changes for this here. The
> addition of a verification step is a= dded in this change here.
>= ; 
> Are you happy th= at this is sufficient to address your concerns?

Yes, I th= ink this addresses my concerns about the denial of service
issues. The text also seems to make little= bit more clear about the
ter= minology, and perhaps the Terminology section should refer to the
terms defined in the RFC8030, so it= would be clear which terms comes
from there.

Sorry that it took so long to reply, but= last week I was in the IEEE
= meeting, thus I was not able to check these during that time.
<= /blockquote>

Just to confirm - are you happy to clear your "has iss= ues" now, or do you need further changes to the terminology reference fi= rst.

Thanks,
<= br>Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com


--7dc635bd576c4f3db57c2b209e61e68b-- From nobody Thu Jan 31 22:28:55 2019 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA4F131214; Thu, 31 Jan 2019 22:28:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Dan Romascanu To: Cc: jmap@ietf.org, draft-ietf-jmap-mail.all@ietf.org, ietf@ietf.org, dromasca@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.90.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154900252324.10128.7132833415832444034@ietfa.amsl.com> Date: Thu, 31 Jan 2019 22:28:43 -0800 Archived-At: Subject: [Jmap] Genart last call review of draft-ietf-jmap-mail-14 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2019 06:28:43 -0000 Reviewer: Dan Romascanu Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-jmap-mail-?? Reviewer: Dan Romascanu Review Date: 2019-01-31 IETF LC End Date: 2019-02-04 IESG Telechat date: Not scheduled for a telechat Summary: This is a clear and complete specification which is READY for publication from a Gen-ART perspective. Major issues: Minor issues: Nits/editorial comments: