From nobody Thu Aug 2 05:55:19 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0E8130E52; Thu, 2 Aug 2018 05:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=GBccqsIJ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=q9ImEWm3 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DWtW0vWAY1RY; Thu, 2 Aug 2018 05:55:02 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3032130E55; Thu, 2 Aug 2018 05:55:02 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id A58F1291; Thu, 2 Aug 2018 08:55:01 -0400 (EDT) Received: from web2 ([10.202.2.212]) by compute6.internal (MEProxy); Thu, 02 Aug 2018 08:55:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=iB821w6fo7vBnta0xYzEK0B+atKV4 QopWQpdnxOoFwA=; b=GBccqsIJHEpL3ZdQv+BdHY5hKEQ3BGZ/seRPjSQiIKFKV sDgG4LnAIyDseuEVzGRXwTeu2x//mB4JBYspEtc9t0THrxslxvJc4PDeBNSf9N5O HdtNHox4PYk3ZphrSPGMaO8vqyP7E5XJ2BR20O+5V7HE4SWvNzIbFIkkmoPLlHGW 6A6yjjEhghbs7JriOliThIX0ilF7oxr8WQYjtKW0zvFX24q9BiAJ3QMQZcbnOM6c luP8N6abPd4jIqAV+RtM9tv2rH7nu50omjgNFU38tTlOLtS78XOU7U+iGwJ+SVEd hlzGQ8NjKCw5ebwDJeG3Ef9rl2Px/KKr5N3Qtlulg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=iB821w6fo7vBnta0xYzEK0B+atKV4 QopWQpdnxOoFwA=; b=q9ImEWm33DFXJ42LgW7k66eKA/h5KDAq4C6ywaBpDzt3k j5Wn2DrX/txSh9XhNG0xt9A96/MZ1oTyN54EXsOw1ECCBI0Og5YtJvSTLp3XUXIz C5Tjh+elcPmvzr6kvBPuOlnWmewgreiwbL160Wd4pqtmZs9mgiwxlgqdFIcPtomT JW16EXluPRgyGplYgBCkukKwB60B3ZZDFFXV9xehcbgJnb5vERV2JamOPo4FLPhZ XP1jrARk9r8aYLhyBEpbAwe4/2DWTheEXnStUw0RyqGS56NjgF+gJ6WthkRl9oB5 407HDF829is6+gXwsYFMg4ER+3isLerhyWK0uuvnQ== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 5B7C5621BF; Thu, 2 Aug 2018 08:55:00 -0400 (EDT) Message-Id: <1533214500.3848794.1461144040.2D1CFB21@webmail.messagingengine.com> From: Bron Gondwana To: Adam Roach , The IESG Cc: extra@ietf.org, yaojk@cnnic.cn, draft-ietf-extra-imap-objectid@ietf.org, extra-chairs@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_153321450038487940" X-Mailer: MessagingEngine.com Webmail Interface - ajax-2be8cd1b Date: Thu, 02 Aug 2018 22:55:00 +1000 Archived-At: Subject: Re: [Extra] Adam Roach's Yes on draft-ietf-extra-imap-objectid-07: (with COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2018 12:55:06 -0000 This is a multi-part message in MIME format. --_----------=_153321450038487940 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Wed, Aug 1, 2018, at 10:34, Adam Roach wrote: > Adam Roach has entered the following ballot position for > draft-ietf-extra-imap-objectid-07: Yes Thanks for your detailed feedback! Responses below. I'm updating my source file for v-08. > When responding, please keep the subject line intact and reply to all> em= ail addresses included in the To and CC lines. (Feel free to > cut this> introductory paragraph, however.) >=20 >=20 > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html> for more infor= mation about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-extra-imap-objectid/ >=20 >=20 >=20 > ----------------------------------------------------------------------> C= OMMENT: > ---------------------------------------------------------------------->=20 > Thanks for the work that went into defining this mechanism -- it > seems like a> very useful optimization. I have a few minor comments. >=20 > ------------------------------------------------------------------- > -------->=20 > =C2=A77: >=20 >> resp-text-code =3D/ "MAILBOXID" SP "(" objectid ")" >> ; incorporated before the expansion rule of >> ; atom [SP 1*] >> ; that appears in [@!RFC3501] >=20 > The "<" and ">" in the preceding text should be replaced with literal> le= ss-than and greater-than symbols. Hmm, yes - this is roundtripping the markdown just fine now. Removed. > ------------------------------------------------------------------- > -------->=20 > =C2=A78.1: >=20 >> An objectid is a string of 1 to 255 characters from the following set>> = of 64 codepoints. a-z, A-Z, 0-9, '_', '-'. >=20 > It would probably be helpful for implementors if this section > indicated that> these are the same characters used by the "base64url" enc= oding > defined in RFC> 4648. Doing so will let implementors know that they can u= se existing > implementations of base64url to convert the output of a hash > function into a> syntactically valid objectid. Thanks, I have added an informative reference to RFC4648 in the objectid definition. > ------------------------------------------------------------------- > -------->=20 > =C2=A711: >=20 >> The use of a digest for ID generation may be used as proof that a >> particular sequence of bytes was seen by the server, however this is>> o= nly a risk if IDs are leaked to clients who don't have permission to>> fetc= h the data directly. Servers that are expected to handle highly>> sensitiv= e data should consider using a ID generation mechanism which>> doesn't deri= ve from a digest. >=20 > Couldn't this be addressed with a per-user salt value rather than a > non-digest> identifier? I've just changed it to "Servers that are expected to handle highly sensitive data should consider this when choosing how to create IDs." Here's a risk, consider if it applies to you. Done. Cheers, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_153321450038487940 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
On Wed, Aug 1, 2018, at 10:34, Adam= Roach wrote:
Adam Roach has entered the following ballot = position for
draft-ietf-extra-imap-objectid-07: Yes

Thanks for your detailed feedback!  = Responses below.  I'm updating my source file for v-08.

When responding, please keep the subject lin= e intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut thi= s
introductory paragraph, however.)


for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:



----------------------------------------------------------------------=
COMMENT:
----------------------------------------------------------------------=

Thanks for the work that went into defining this mechanism -- it seems= like a
very useful optimization. I have a few minor comments.

----------------------------------------------------------------------= -----

=C2=A77:

  resp-text-code =3D/ "MAILBOXID" SP "(" objectid ")"=
          ; incorporated before the expansion= rule of
          ;  atom [SP 1*<any TEXT-CHA= R except "]">]
          ; that appears in [@!RFC3501]

The "<" and ">" in the preceding text should be replaced with li= teral
less-than and greater-than symbols.

Hmm, yes - this is roundtripping the mark= down just fine now.  Removed.

--------------------------------------------= -------------------------------

=C2=A78.1:

An objectid is a string of 1 to 255 characters from the fo= llowing set
of 64 codepoints. a-z, A-Z, 0-9, '_', '-'.

It would probably be helpful for implementors if this section indicate= d that
these are the same characters used by the "base64url" encoding defined= in RFC
4648. Doing so will let implementors know that they can use existing
implementations of base64url to convert the output of a hash function = into a
syntactically valid objectid.

Thanks, I have added an informative refer= ence to RFC4648 in the objectid definition.

--------------------------------------------= -------------------------------

=C2=A711:

The use of a digest for ID generation may be used as proof= that a
particular sequence of bytes was seen by the server, however this is
only a risk if IDs are leaked to clients who don't have permission to<= br>
fetch the data directly.  Servers that are expected to handle hig= hly
sensitive data should consider using a ID generation mechanism which
doesn't derive from a digest.

Couldn't this be addressed with a per-user salt value rather than a no= n-digest
identifier?

I've just changed it to "Servers that are= expected to handle highly sensitive data should consider this when choosin= g how to create IDs."  Here's a risk, consider if it applies to you.&n= bsp; Done.

Cheers,

Bron.


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


--_----------=_153321450038487940-- From nobody Thu Aug 2 05:59:35 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA400130E6D; Thu, 2 Aug 2018 05:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=sLBGSDNh; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Saw1Aa1r Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hkpEMnx9vh5y; Thu, 2 Aug 2018 05:59:31 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 800FE130E64; Thu, 2 Aug 2018 05:59:31 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id A51BE294; Thu, 2 Aug 2018 08:59:30 -0400 (EDT) Received: from web2 ([10.202.2.212]) by compute6.internal (MEProxy); Thu, 02 Aug 2018 08:59:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=qEKF01 w+C93ESH1HUE9GCAfaSTWot8mgJLsBFpr517M=; b=sLBGSDNhp0JONiHG8/RhQs c6tO2omGBa7mDXj/VrzLHg9rs4wBjYXvDQ5Kkj7O+CfBs3gW9W9AdJlMBsQit9n4 s2DzEekCigxeDv+xnNpfdgLvcIEq2x9xlhuFSg1f9WQY4FVrt/rSs2vwqPitzOge 8yzjsKz/j4lcN62E7bbwhg5os4/+ztw1doX2OFdH/VEHo4qnvKCmDV52WQo+aN5w O916ldNb6E+5ZTwk2jdZs+Dw5g9UAktCPPBVuJJKML7YZEON7rDgGnlxAPH4ivyU gGq0NKdh47/g07vNAVvkrrW3XAgXG7mDmBb98QDfbGLZPzb3yS5O1iYUqpycr3CA == DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=qEKF01 w+C93ESH1HUE9GCAfaSTWot8mgJLsBFpr517M=; b=Saw1Aa1rJSGkWBRq35emKa kVoR1tqRuvQ+kmkJGcwv0W8N93TQ+/b/dZaFJuJrU8jIMa16ixC8fncXT7oeaXqn 8pqQEoQAcC8wWBCUB8w50vOohKdlAqhOe8XNNqwIcQcXjFRUj/7r+slsrPMlCazH ubLIa/yWQ3WqopmuoBrkWM8Z2x5HDIbetXeJj//nepMYo0wwYgthLsqwexTCLrNU 2tWfW+LYlaJtNkND3DixAjTsbVy5JnQkS13XP3WmV2ep63+gQM7Q0XWgoAnesxsO zDm7EcNPrrE/LCCzlU+j/kn4QRckgYX0ay1LQCPsON1/i/d79bg7lKzAmG2lcI+w == X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id BB3C1621CB; Thu, 2 Aug 2018 08:59:28 -0400 (EDT) Message-Id: <1533214768.3850163.1461149216.222A22A0@webmail.messagingengine.com> From: Bron Gondwana To: Alissa Cooper , The IESG Cc: extra@ietf.org, yaojk@cnnic.cn, draft-ietf-extra-imap-objectid@ietf.org, extra-chairs@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_153321476838501630" X-Mailer: MessagingEngine.com Webmail Interface - ajax-2be8cd1b References: <153306063928.3243.5362552823157836437.idtracker@ietfa.amsl.com> Date: Thu, 02 Aug 2018 22:59:28 +1000 In-Reply-To: <153306063928.3243.5362552823157836437.idtracker@ietfa.amsl.com> Archived-At: Subject: Re: [Extra] Alissa Cooper's No Objection on draft-ietf-extra-imap-objectid-07: (with COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2018 12:59:34 -0000 This is a multi-part message in MIME format. --_----------=_153321476838501630 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" Thanks Alissa! Both very useful comments and I've merged changes for both into what will be -08. Cheers, Bron. On Wed, Aug 1, 2018, at 04:10, Alissa Cooper wrote: > Alissa Cooper has entered the following ballot position for > draft-ietf-extra-imap-objectid-07: No Objection > > When responding, please keep the subject line intact and reply to all> email addresses included in the To and CC lines. (Feel free to > cut this> introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html> for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-extra-imap-objectid/ > > > > ----------------------------------------------------------------------> COMMENT: > ----------------------------------------------------------------------> > Section 5.2: > > "The THREADID data item is an objectid which uniquely identifies a set> of messages which the server believes should be grouped > together when> presented. > ... > The server SHOULD return the same THREADID for related messages even > if they are in different mailboxes." > > "related" seems like a broader characterization than "messages which > the server> believes should be grouped together when presented," but I'm assuming > they are> meant to be equivalent. I think it would help to clarify this in > the second> sentence, i.e., that messages that would appear threaded if they > were in the> same mailbox SHOULD return the same THREADID even if they are in > different> mailboxes. > > Section 8.1: > > s/from the following set of 64 codepoints. a-z, A-Z, 0-9, '_', '- > './from the> following set of 64 codepoints: a-z, A-Z, 0-9, '_', '-'./ > > > _________________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_153321476838501630 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
Thanks Alissa!  Both very useful comments and I've merged changes for both into what will be -08.

Cheers,

Bron.


On Wed, Aug 1, 2018, at 04:10, Alissa Cooper wrote:
Alissa Cooper has entered the following ballot position for
draft-ietf-extra-imap-objectid-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 5.2:

"The THREADID data item is an objectid which uniquely identifies a set
  of messages which the server believes should be grouped together when
  presented.
        ...
The server SHOULD return the same THREADID for related messages even
  if they are in different mailboxes."

"related" seems like a broader characterization than "messages which the server
believes should be grouped together when presented," but I'm assuming they are
meant to be equivalent. I think it would help to clarify this in the second
sentence, i.e., that messages that would appear threaded if they were in the
same mailbox SHOULD return the same THREADID even if they are in different
mailboxes.

Section 8.1:

s/from the following set of 64 codepoints. a-z, A-Z, 0-9, '_', '-'./from the
following set of 64 codepoints: a-z, A-Z, 0-9, '_', '-'./


_______________________________________________
Extra mailing list

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


--_----------=_153321476838501630-- From nobody Thu Aug 2 06:05:04 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABA5C130E53 for ; Thu, 2 Aug 2018 06:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=JPf3jQqt; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=p4SKwUxd Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gUFjT_Db_7dV for ; Thu, 2 Aug 2018 06:04:59 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A15A3130E39 for ; Thu, 2 Aug 2018 06:04:59 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 35ACE2D1 for ; Thu, 2 Aug 2018 09:04:59 -0400 (EDT) Received: from web2 ([10.202.2.212]) by compute6.internal (MEProxy); Thu, 02 Aug 2018 09:04:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=7aSuPPs2j6qY37tF6 +CtyPWh8LyHiNBb4K967SWiAmg=; b=JPf3jQqtFUNHGW07EIRS/doCJMVwRhPaH gPcivfd8P+MxgSHsylmeubSRdyM43gWiwWk23rjmFievYfDM1NusEuIvNrVkwV+n yvkrgDYl1cPCfBfsX3v1fq/Cqh2HbLSHD4hjkTU4AkPdq+fukPgjJSx9UIWXcvDU GxCeOCV5D31bSkZNrylYg4TGzxU1+6OukEL3yYvEP+qUctyc2fbCsCutiEtboFAG aJirZoF1zmcj+gtU0l2wLWefJcIhb1yUmSa3k7cyfXjYUNPSLmm5wSySWoc+KZWy 0SXsoaFrkZH7dwYY2xiGGjzgLOg5aEe5/lAlvZfqkcpqxDHAFUIWA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=7aSuPP s2j6qY37tF6+CtyPWh8LyHiNBb4K967SWiAmg=; b=p4SKwUxdDutsHNlxNYIfHb XZ08cdnObAVENIabHJe8cUNMu70oknRxYFOgoc5x2nHwdFoHcWU8QosNyIxUPHTE mHjhNcG/CKsata2lOchwVti9Cp1rvbmDiqi+sT48DITzYsN5KYESklBAlB6IzlSY /ZSaqBsRDNhdOHmc7tZagHguFDa9IAYc1NEyAfUM1nQfJhZQ1D/Y1/ZtqN+JmYsS yN9FK4Hx19AEyIIBgTBTfbftob46Z6sLD9OvprStOqpnSOQVNAt9Ahhc7mQa3gaO SrYrpmF/3lEuD0KCEp3vBetE1A5lJv5IqPJI1CYv7u3LjCcd5+1YWeChO/L/MQnw == X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 3D7D5621BF; Thu, 2 Aug 2018 09:04:58 -0400 (EDT) Message-Id: <1533215098.3851992.1461157920.4427B7C0@webmail.messagingengine.com> From: Bron Gondwana To: extra@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_153321509838519920" X-Mailer: MessagingEngine.com Webmail Interface - ajax-2be8cd1b In-Reply-To: <153307744579.3110.9297337364956440515.idtracker@ietfa.amsl.com> Date: Thu, 02 Aug 2018 23:04:58 +1000 References: <153307744579.3110.9297337364956440515.idtracker@ietfa.amsl.com> Archived-At: Subject: Re: [Extra] Eric Rescorla's No Objection on draft-ietf-extra-imap-objectid-07: (with COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2018 13:05:03 -0000 This is a multi-part message in MIME format. --_----------=_153321509838519920 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Wed, Aug 1, 2018, at 08:50, Eric Rescorla wrote: > Eric Rescorla has entered the following ballot position for > draft-ietf-extra-imap-objectid-07: No Objection > > When responding, please keep the subject line intact and reply to all> email addresses included in the To and CC lines. (Feel free to > cut this> introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html> for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-extra-imap-objectid/ > > > > ----------------------------------------------------------------------> COMMENT: > ----------------------------------------------------------------------> > Rich version of this review at: > https://mozphab-ietf.devsvcdev.mozaws.net/D7116 > > > > IMPORTANT > S 11. >> If a digest is used for ID generation, it must have a collision >> resistent property, so server implementations are advised to >> monitor>> current security research and choose secure digests. >> >> The use of a digest for ID generation may be used as proof that a>> particular sequence of bytes was seen by the server. > > I don't understand this text. How does the client know whether a > digest was sued. The client doesn't care, unless the server breaks the contract and returns the same objectid for two different objects. So using a non-collision- resistant digest is bad. The proof of sequence of bytes is the flip side - if you use the sha256 of the message content as your id (for example), then anybody who has a message ID from your server can prove that you had that full email content by showing the email content and the ID, because you couldn't have generated that ID without having that particular email in your mailbox. This might be relevant if you claim you never had that email, but there's a protocol trace of a mailbox listing which includes that EMAILID. > COMMENTS > S 7. >> IMAP ABNF extensions [RFC4466] specifications. >> >> Except as noted otherwise, all alphabetic characters are case- >> insensitive. The use of upper- or lowercase characters to define>> token strings is for editorial clarity only. Implementations >> MUST>> accept these strings in a case-insensitive fashion. > > For clarity: IDs are not case insensitive, right? Because otherwise > the text below about differing in case doesn't make sense. I've added wording to that effect. Indeed IDs are case sensitive. > > S 8.1. >> >> o ids which contain only digits >> >> o ids which differ only by ASCII case (A vs a) >> >> o the specific sequence of 3 characters NIL > > Nit. Do you want to quote "NIL"? No - it's an IMAP protocol construct. but I might add some more descriptive text to it. Thanks. Cheers, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_153321509838519920 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Wed, Aug 1, 2018, at 08:50, Eric Rescorla wrote:
Eric Rescorla has entered the following ballot position for
draft-ietf-extra-imap-objectid-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Rich version of this review at:



IMPORTANT
S 11.
    If a digest is used for ID generation, it must have a collision
    resistent property, so server implementations are advised to monitor
    current security research and choose secure digests.
 
    The use of a digest for ID generation may be used as proof that a
    particular sequence of bytes was seen by the server.

I don't understand this text. How does the client know whether a
digest was sued.

The client doesn't care, unless the server breaks the contract and returns the same objectid for two different objects.  So using a non-collision-resistant digest is bad.  The proof of sequence of bytes is the flip side - if you use the sha256 of the message content as your id (for example), then anybody who has a message ID from your server can prove that you had that full email content by showing the email content and the ID, because you couldn't have generated that ID without having that particular email in your mailbox.  This might be relevant if you claim you never had that email, but there's a protocol trace of a mailbox listing which includes that EMAILID.

COMMENTS
S 7.
    IMAP ABNF extensions [RFC4466] specifications.
 
    Except as noted otherwise, all alphabetic characters are case-
    insensitive.  The use of upper- or lowercase characters to define
    token strings is for editorial clarity only.  Implementations MUST
    accept these strings in a case-insensitive fashion.

For clarity: IDs are not case insensitive, right? Because otherwise
the text below about differing  in case doesn't make sense.

I've added wording to that effect.  Indeed IDs are case sensitive.


S 8.1.
 
    o  ids which contain only digits
 
    o  ids which differ only by ASCII case (A vs a)
 
    o  the specific sequence of 3 characters NIL

Nit. Do you want to quote "NIL"?

No - it's an IMAP protocol construct.  but I might add some more descriptive text to it.  Thanks.

Cheers,

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


--_----------=_153321509838519920-- From nobody Thu Aug 2 06:11:58 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC65130E55; Thu, 2 Aug 2018 06:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=Cn6zyk+u; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=CY/6r3Vy Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCX6b3Jzk_zx; Thu, 2 Aug 2018 06:11:48 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE6C7130E39; Thu, 2 Aug 2018 06:11:47 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 3F19C2E4; Thu, 2 Aug 2018 09:11:47 -0400 (EDT) Received: from web2 ([10.202.2.212]) by compute6.internal (MEProxy); Thu, 02 Aug 2018 09:11:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=gaTUIH qZpAA5wz022TlInuVR5SEKALEDuKbvn3BDe18=; b=Cn6zyk+uHCawBdQGukZA2F e6u9L1QrAm9bejugjJ9ODmyDVw1RooH0hSzST9r6sc9cBdXB9fhP2BMOR6IK00su UtVrzhsUptDRhO1dUwY1aQYX0VRThyIiwH6/wJzHEM1XqYXKtc+aZOH5Q6gAPY8i lQbzLxcGRnfv3z7GIt/IAk1E0hmAT55L2ESt2ghPO9uHoTVKAD2YSnq+AIBh5bcF KDn9H3OADuSEn//+vNX39VdjFMrK2BUo7fN2/XkVzE5rzgkli5PIDIuRPhTHCozp hF6/BjeSbbyB9wxXl5kqziLg/gsPBQ+LjARzQdbbsJ/42TEghgEO0sRyEly7rwGw == DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=gaTUIH qZpAA5wz022TlInuVR5SEKALEDuKbvn3BDe18=; b=CY/6r3Vy3GVuVLaWgG5prp cktq4vh4qtIUMpK0zY4d1nV8uc8N75voRcHbbwRDFGMYp3zuc3+VdBN4ZeLZ0YUD il1fIGS+wDYOq/6d8P3d6SBnn1+cLGvvseWY5lqWd4oxl3QR8GY0xIchtlepH2+3 nsNYoTl/wZuotVnTjy6W00XCv8aMmEjQ6JBOveXkwvIZf6pDSO3oZ4/3DAF2NMkM pjNAFItKxpDgdkfzRxee2SZUYD9m2jGsJcrDriyfzq1RHHJRsbBft/lZiao6Wyvj bcdHQ2WxBJbREw+3nSIjnO9qAJ/cutChvuLRchDoG+k5GMfIbPIkyB4a3qHShOxg == X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 66297621CB; Thu, 2 Aug 2018 09:11:46 -0400 (EDT) Message-Id: <1533215506.3854543.1461163256.7570C1DE@webmail.messagingengine.com> From: Bron Gondwana To: Pete Resnick , gen-art@ietf.org Cc: extra@ietf.org, draft-ietf-extra-imap-objectid.all@ietf.org, ietf@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_153321550638545432" X-Mailer: MessagingEngine.com Webmail Interface - ajax-2be8cd1b Date: Thu, 02 Aug 2018 23:11:46 +1000 References: <153271422661.32667.3834516374113335159@ietfa.amsl.com> In-Reply-To: <153271422661.32667.3834516374113335159@ietfa.amsl.com> Archived-At: Subject: Re: [Extra] Genart telechat review of draft-ietf-extra-imap-objectid-06 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2018 13:11:49 -0000 This is a multi-part message in MIME format. --_----------=_153321550638545432 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Sat, Jul 28, 2018, at 03:57, Pete Resnick wrote: > Reviewer: Pete Resnick > Review result: Ready with Nits >=20 > 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 wait for direction from your > document shepherd or AD before posting a new version of the draft. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-extra-imap-objectid-06 > Reviewer: Pete Resnick > Review Date: 2018-07-27 > IETF LC End Date: 2018-07-13 > IESG Telechat date: 2018-08-02 >=20 > Summary: Ready with Nits >=20 > Major issues: None >=20 > Minor issues: None >=20 > Nits/editorial comments: >=20 > Thanks for the changes responding to my review. Good work. >=20 > =C2=A75.2, =C2=B66: >=20 > OLD > THREADID is optional, if the server doesn't support THREADID or is > NEW > THREADID is OPTIONAL; if the server doesn't support THREADID or is Yep, fixed. > =C2=A75.2 =C2=B67: >=20 > Not clear to me why the THREADID and EMAILID can't be the same. I > assume given> the MUST it's going to be some sort of interoperability pro= blem, > but it does> seem odd. But don't change it on my account. This is basically a "developers will make assumptions about relatedness which may not always hold". We even XOR our THREADID against a constant after calculating it from the EMAILID in our server now, so that developers don't get lazy and make shortcuts. > =C2=A78.2 =C2=B62: >=20 > s/backend object collide/backend object identifiers Fixed this too. Thanks again for great feedback, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_153321550638545432 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
On Sat, Jul 28, 2018, at 03:57, Pet= e Resnick wrote:
Reviewer: Pete Resnick
Review result: Ready with Nits

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 wait for direction from your
document shepherd or AD before posting a new version of the draft.
=

For more information, please see the FAQ at


Document: draft-ietf-extra-imap-objectid-06
Reviewer: Pete Resnick
Review Date: 2018-07-27
IETF LC End Date: 2018-07-13
IESG Telechat date: 2018-08-02

Summary: Ready with Nits

Major issues: None

Minor issues: None

Nits/editorial comments:

Thanks for the changes responding to my review. Good work.

=C2=A75.2, =C2=B66:

OLD
  THREADID is optional, if the server doesn't support THREADID or= is
NEW
  THREADID is OPTIONAL; if the server doesn't support THREADID or= is

Yep, fixed.

=C2=A75.2 =C2=B67:

Not clear to me why the THREADID and EMAILID can't be the same. I assu= me given
the MUST it's going to be some sort of interoperability problem, but i= t does
seem odd. But don't change it on my account.

This is basically a "developers will make= assumptions about relatedness which may not always hold".  We even XO= R our THREADID against a constant after calculating it from the EMAILID in = our server now, so that developers don't get lazy and make shortcuts.

=C2=A78.2 =C2=B62:

s/backend object collide/backend object identifiers

Fixed this too.

Thanks again for great feedback,

Bron.

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


--_----------=_153321550638545432-- From nobody Thu Aug 2 06:14:05 2018 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 38CC5130E82; Thu, 2 Aug 2018 06:13:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: extra@ietf.org Message-ID: <153321563720.22154.9226854655812028273@ietfa.amsl.com> Date: Thu, 02 Aug 2018 06:13:57 -0700 Archived-At: Subject: [Extra] I-D Action: draft-ietf-extra-imap-objectid-08.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2018 13:13:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email mailstore and eXtensions To Revise or Amend WG of the IETF. Title : IMAP Extension for object identifiers Author : Bron Gondwana Filename : draft-ietf-extra-imap-objectid-08.txt Pages : 19 Date : 2018-08-02 Abstract: This document updates RFC3501 (IMAP4rev1) with persistent identifiers on mailboxes and messages to allow clients to more efficiently re-use cached data when resources have changed location on the server. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-extra-imap-objectid/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-extra-imap-objectid-08 https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap-objectid-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-imap-objectid-08 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 Thu Aug 2 06:53:45 2018 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 02F5A128BAC; Thu, 2 Aug 2018 06:53:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ignas Bagdonas To: "The IESG" Cc: draft-ietf-extra-imap-objectid@ietf.org, Jiankang Yao , extra-chairs@ietf.org, yaojk@cnnic.cn, extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153321801700.2103.13086699478558607326.idtracker@ietfa.amsl.com> Date: Thu, 02 Aug 2018 06:53:37 -0700 Archived-At: Subject: [Extra] Ignas Bagdonas' No Objection on draft-ietf-extra-imap-objectid-08: (with COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2018 13:53:37 -0000 Ignas Bagdonas has entered the following ballot position for draft-ietf-extra-imap-objectid-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-extra-imap-objectid/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The document has implementation considerations section - thank you for that. In the context of IETF 102 plenary discussions on running code - what would be the status and interoperability of existing implementations, if any? Could that be added to the abvementioned section? From nobody Thu Aug 2 16:37:45 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 484F8130DC9 for ; Thu, 2 Aug 2018 16:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.51 X-Spam-Level: X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1mNk3KFF6ahb for ; Thu, 2 Aug 2018 16:37:42 -0700 (PDT) Received: from mail-yw1-xc34.google.com (mail-yw1-xc34.google.com [IPv6:2607:f8b0:4864:20::c34]) (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 965EF126CC7 for ; Thu, 2 Aug 2018 16:37:42 -0700 (PDT) Received: by mail-yw1-xc34.google.com with SMTP id y203-v6so303511ywd.9 for ; Thu, 02 Aug 2018 16:37:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pK0H/MRG+RcHTl9b43AbuzN3Izb2FLrqDbfvu1lMRJA=; b=a0YCcB32x7/szd8bJI8sQcys9XQxsFhowQ5KW20Tj7900hMrDNyBRIfAWjyE5AqRkD FAlzBnnlKGCz0/zoPhDimuPrGJbLrj5HuhZJemy35dZdzljjn/HUSCcF5lFNsXHgM4HR hra0ypvDa0mn7vqXtWCkAjMkyqX8anwu7Ok9TsgT0KejLUHu5lBOjKabG8eZFTcQl2X1 Fh4gf4p9Ou6AhvlfCS6rHHN8DSZL/X/MAGJZ8uj8NgEYMM/Q3/V/0GJiC6B+KaFEiVQw JpMo/DJyFDl+A+qA9HT4dP6NMhihxQBxBrBLTiPptR5IZcq07iyT4WFUMxkdeDhn8Ct6 Kl2w== 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=pK0H/MRG+RcHTl9b43AbuzN3Izb2FLrqDbfvu1lMRJA=; b=anapYrZ/aPb7VwE8zDoPogTzT1tFgSDB9CmpC7ggykaPHW8ukRpmCFD/XcczUwDtvG RPJ+hv5jbILw0alUU0qW3Ua8nYJiYtyO4Cg3JWSurBBady7jHAy9mldVHagTt8TZG145 4cGhrJ/R/FBuDAhG3XuMp0qpY9bbBm2JRC6f6o3MNAMT/Tvde+KU7aQEYQ2IctDJeKXv pvmnl46PSWrdbPMaBCTN0sAZBDgKcOui9ijF+X6c3U9KclFbeIv9XTw2kx3N8lUPnF1e XAErqM+K32HGZroNRRhopJ1r4D4NXr0TFOZW0iym7RAPrDBp0JDY/VvwA66CFG5Aybz2 KoOg== X-Gm-Message-State: AOUpUlGf8gNdu6OqsINcUB6wxgz3Uy7Ykdl6TuHUHxXm0v2+xyJz6GDG +/qpzMM1Pe7Yi5SHNqKbZ/irUQN4GxpuAj5xZqJl X-Google-Smtp-Source: AAOMgpd/S9CfhmVzznUkpHx1bDWLQBUHHvGr1yBcCSsOgFxMPJgWfYqTwQlO8F8DEMj5hduO5wLz2sUirht99U0pYQo= X-Received: by 2002:a0d:e501:: with SMTP id o1-v6mr901654ywe.409.1533253061107; Thu, 02 Aug 2018 16:37:41 -0700 (PDT) MIME-Version: 1.0 References: <1dc71d96-c3be-4ae3-7644-13f7accecace@linuxmagic.com> <79A4C4F2-E4BA-4B4C-B8E0-295B7216EC9C@oracle.com> In-Reply-To: <79A4C4F2-E4BA-4B4C-B8E0-295B7216EC9C@oracle.com> From: Brandon Long Date: Thu, 2 Aug 2018 16:37:29 -0700 Message-ID: To: Chris Newman Cc: Michael Peddemors , extra@ietf.org Content-Type: multipart/alternative; boundary="0000000000000fa3d705727c4c49" Archived-At: Subject: Re: [Extra] CLIENT ID - Next Steps - General Discussion Overview X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2018 23:37:44 -0000 --0000000000000fa3d705727c4c49 Content-Type: text/plain; charset="UTF-8" (catching up on email from vacation) On Mon, Jul 23, 2018 at 3:53 PM Chris Newman wrote: > On 23 Jul 2018, at 11:27, Michael Peddemors wrote: > > > > * It was questioned, is the proper place for this in a SASL mechanism, > > vs in the protocol itself, and while our development work and > > research > > show that the advantages for a 'device identifier' to be part of the > > protocol/syntax rather than a SASL, and our assertion this will help > > in the adoption curve in the industry, it was one of the strongest > > points of contention, with the arguments for SASL, was one SASL can > > apply to many services, and thus if that argument holds, then maybe > > the SASL or a security group would be better for this. We intend to > > argue against this, but the topic alone is key to discussions, so it > > requires a separate thread to discuss this. > > We have a case where client-id facilities (device-specific token, a > subset of the client-id problem) were deployed in production using > custom SASL mechanisms on our server and custom changes to a client. So > I assert this is a proof-of-concept that SASL is deployable for > client-id, that it can solve the problem for multiple protocols with one > specification and shared code (Submission & IMAP), that it comes with an > extensible capability model for interoperability, and does not break > interoperability with unmodified clients. Furthermore, no custom changes > were required to our server to support this since we have a SASL > abstraction API we support. That means our customers could deploy a > SASL-based mechanism without requiring a server upgrade, thus > significantly simplifying deployment. We do not have an API for IMAP > commands and have no intention of providing one, so our customers will > not be able to deploy client ID unless it is SASL or there is an IETF > rough consensus around a non-SASL client-id model for > submission+imap(+pop+managesieve+jmap+etc). > > I consider it unfortunate this use case involved proprietary SASL > mechanisms so I'd support a standardized mechanism, but we have running > code showing a SASL approach is deployable and backwards compatible. > > I'm aware of another deployed use of client-id like facilities for push > notifications. > Note that PLAIN-CLIENTTOKEN that gmail still offers for MSA/POP/IMAP is a form of this in SASL as well, something that we worked on with several clients (and intended to be taken for standardization) before deciding to go the OAUTH route that led to OAUTHBEARER eventually. Just adding the token into the sasl data seemed pretty straightforward. (not sure if it was mentioned in the presentation or not) Brandon --0000000000000fa3d705727c4c49 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(catching up on email from vacation)

On Mon, Jul 23, 2018 at 3:53 PM Chris Newman = <chris.newman@oracle.com&= gt; wrote:
On 23 Jul 2018, at 11:27= , Michael Peddemors wrote:
>
> * It was questioned, is the proper place for this in a SASL mechanism,=
>=C2=A0 =C2=A0vs in the protocol itself, and while our development work = and
> research
>=C2=A0 =C2=A0show that the advantages for a 'device identifier'= to be part of the
>=C2=A0 =C2=A0protocol/syntax rather than a SASL, and our assertion this= will help
>=C2=A0 =C2=A0in the adoption curve in the industry, it was one of the s= trongest
>=C2=A0 =C2=A0points of contention, with the arguments for SASL, was one= SASL can
>=C2=A0 =C2=A0apply to many services, and thus if that argument holds, t= hen maybe
>=C2=A0 =C2=A0the SASL or a security group would be better for this.=C2= =A0 We intend to
>=C2=A0 =C2=A0argue against this, but the topic alone is key to discussi= ons, so it
>=C2=A0 =C2=A0requires a separate thread to discuss this.

We have a case where client-id facilities (device-specific token, a
subset of the client-id problem) were deployed in production using
custom SASL mechanisms on our server and custom changes to a client. So I assert this is a proof-of-concept that SASL is deployable for
client-id, that it can solve the problem for multiple protocols with one specification and shared code (Submission & IMAP), that it comes with a= n
extensible capability model for interoperability, and does not break
interoperability with unmodified clients. Furthermore, no custom changes were required to our server to support this since we have a SASL
abstraction API we support. That means our customers could deploy a
SASL-based mechanism without requiring a server upgrade, thus
significantly simplifying deployment. We do not have an API for IMAP
commands and have no intention of providing one, so our customers will
not be able to deploy client ID unless it is SASL or there is an IETF
rough consensus around a non-SASL client-id model for
submission+imap(+pop+managesieve+jmap+etc).

I consider it unfortunate this use case involved proprietary SASL
mechanisms so I'd support a standardized mechanism, but we have running=
code showing a SASL approach is deployable and backwards compatible.

I'm aware of another deployed use of client-id like facilities for push=
notifications.

Note that PLAIN-CLIENTTO= KEN that gmail still offers for MSA/POP/IMAP is a form of this in SASL as w= ell, something that we worked on with several clients (and intended to be t= aken for standardization) before deciding to go the OAUTH route that led to= OAUTHBEARER eventually.

Just adding the token into the sasl data se= emed pretty straightforward.

(not sure if it was mentioned in the pr= esentation or not)

Brandon
--0000000000000fa3d705727c4c49-- From nobody Thu Aug 2 17:01:43 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36D43130DDE for ; Thu, 2 Aug 2018 17:01:19 -0700 (PDT) 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=bhnTqGni; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=tNFkWsE/ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xuJz_dcLZztC for ; Thu, 2 Aug 2018 17:01:18 -0700 (PDT) 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 4294B126CC7 for ; Thu, 2 Aug 2018 17:01:18 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id A21552A3 for ; Thu, 2 Aug 2018 20:01:17 -0400 (EDT) Received: from imap22 ([10.202.2.72]) by compute6.internal (MEProxy); Thu, 02 Aug 2018 20:01:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-type:date:from:message-id:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=wmFB8k/9M4DoiNUR/ kKZ1xuEdRali+V94ud5zpmlo1M=; b=bhnTqGnivPjaTKSGCh6axifmoKnyzQi1a aySNKKd8h3eAZxYqubVKCOzwXM/NPgt5HbDV+/90sk2F9Rn0tbKDg7racTbBl1TX NrwL8N01cs0rVhWmAFz/sgpkcAzWReXad+MBBi1iInEWQfwKWCygwww1USMGBHlV N2mweoOOpPwESsxWacyy8eQo9YErfcqOgZ8IoCkoMDuUCN6tSFFvusovSifOrirE S3gtsiyuk7YAiYy+JklVYkVe5uHu+ssrRyKCYvaz82fLJD6HtzzCCkFP+5dCQoBr vJEisVia9ra1fxqTFbbA9B2LOCbN7PZ7TyhNwUFr8bKNKDVSYl9Hg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id:subject :to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=wmFB8k/9M4DoiN UR/kKZ1xuEdRali+V94ud5zpmlo1M=; b=tNFkWsE/HKFQOtVzJ5CSSB5JUUS6zM GfmBewEZ90siugdBkaahhNYYmoWY3v8JCsaBEe9Y33nJrANgNH5VXkI+K/0CzLOB ndBmeOvxKuOgNhLIEj/wF9WsSqYSJoUDzWg7ulw7Zf8pNiBpsV34+sESBsz5Lo8V ouf0bTUJiO+fesT17P0d2Xt9V7UDaSHYyAAvagsC0fP/6mbE8KaSwNcEPeHC9FAK 0FpYfje3nPnpK3ZyEj1QU578V9V/WgUFyX38wboluDIF7p1zbqRuv/Nbxy96CTH0 2lLN4mJrog3sLAcg4TIUZ68WVeGmTUwZq1bw7TdTt/0MSFMgZOcFujLg== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 501) id C62DEEE93; Thu, 2 Aug 2018 20:01:16 -0400 (EDT) Message-Id: <384c9ff3-7531-4202-ac9a-50d07577a765@sloti22d1t06> User-Agent: Cyrus-JMAP/3.1.5-137-g843a534-fmnext-20180801v1 x-jmap-identity-id: 56629417 Date: Thu, 02 Aug 2018 20:01:12 -0400 From: Bron Gondwana To: extra@ietf.org Content-Type: multipart/alternative; boundary=3c135029b380443ba754213c84e269ab Archived-At: Subject: [Extra] Reminder: 1 week left on SAVEDATE last call X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2018 00:01:19 -0000 --3c135029b380443ba754213c84e269ab Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Just a reminder that draft-ietf-extra-imap-savedate-01 has been in Worki= ng Group Last Call for 2 weeks, and has one week left in this state, so = if you have any additional feedback, now's a good time :) Cheers, Bron. -- =C2=A0 Bron Gondwana, CEO, FastMail Pty Ltd =C2=A0 brong@fastmailteam.com --3c135029b380443ba754213c84e269ab Content-Type: text/html
Just a reminder that draft-ietf-extra-imap-savedate-01 has been in Working Group Last Call for 2 weeks, and has one week left in this state, so if you have any additional feedback, now's a good time :)

Cheers,

Bron.

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


--3c135029b380443ba754213c84e269ab-- From nobody Thu Aug 2 17:06:22 2018 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 05BDB130E34; Thu, 2 Aug 2018 17:06:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153325478101.2113.8316558541724191239.idtracker@ietfa.amsl.com> Date: Thu, 02 Aug 2018 17:06:21 -0700 Archived-At: Subject: [Extra] The EXTRA WG has placed draft-brandt-imap-replace in state "Adopted by a WG" X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2018 00:06:21 -0000 The EXTRA WG has placed draft-brandt-imap-replace in state Adopted by a WG (entered by Bron Gondwana) The document is available at https://datatracker.ietf.org/doc/draft-brandt-imap-replace/ Comment: As agreed at IETF102 and discussed on the list, we are accepting this document into the working group. From nobody Thu Aug 2 17:07:06 2018 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C9D7C130E4C; Thu, 2 Aug 2018 17:07:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153325482282.2349.7849278678429080803.idtracker@ietfa.amsl.com> Date: Thu, 02 Aug 2018 17:07:02 -0700 Archived-At: Subject: [Extra] The EXTRA WG has placed draft-slusarz-imap-fetch-snippet in state "Adopted by a WG" X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2018 00:07:03 -0000 The EXTRA WG has placed draft-slusarz-imap-fetch-snippet in state Adopted by a WG (entered by Bron Gondwana) The document is available at https://datatracker.ietf.org/doc/draft-slusarz-imap-fetch-snippet/ Comment: As agreed at IETF102 and discussed on the list, we are accepting this document into the working group. From nobody Thu Aug 2 17:10:03 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 408E1130E0A for ; Thu, 2 Aug 2018 17:10:02 -0700 (PDT) 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=C2Vlo+oT; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=nBbLtrsQ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k17vCd7VxDfK for ; Thu, 2 Aug 2018 17:10:00 -0700 (PDT) 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 DC2A4130DE8 for ; Thu, 2 Aug 2018 17:10:00 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 090C924D; Thu, 2 Aug 2018 20:09:59 -0400 (EDT) Received: from imap22 ([10.202.2.72]) by compute6.internal (MEProxy); Thu, 02 Aug 2018 20:10:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc:content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=SPllnnaeShTogRllZ64E5zF6AJkxesoWKOE3VjZsy 58=; b=C2Vlo+oTj2rKHGFuwq2CgRpz7a2GNTF2ZC2UKtiTYe9E8Wwiypcigi7Ex VMQeesVejkH8XHFEocztLEJ9suLr4Z4O3HbuziQOj9eni3PQlNL9vFIhuK5wrw1T z/q/wzLKrJuLwyiwce1TkgsOGIOGOPwYlblI3pFCOqA+bIooU7a+jpacLWpqsVOH y51KRq0CFKg9fsHlIu9c7i7nxJKNExtCjnnrBLkkLWzuJy6tnGey9ve/DPcaUbsO bp3oeUy2t83jA/J0LPLGJqth2itFDx43U8uzkJBJ8VDSwkePSS2SLCY/7wK29Ml7 TGGCTOO3dnOmr59AjgRFRrla6LaZw== 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-sender:x-me-sender :x-sasl-enc; s=fm3; bh=SPllnnaeShTogRllZ64E5zF6AJkxesoWKOE3VjZsy 58=; b=nBbLtrsQmn07UTtSfAatSHIZ00o6m1AoYNstM9y38HvrSHuaPCosBz30b F7E9UaQbrtdDRLJgMjIrpprc/qzjy2nCxCN/0T0hrDht6A3mfgn4WLRv5GejS4B7 QfZBqfQZS5WljB1g8uOqRLqHnkiTjkfx57LsEguUZilJUxJnuNbL50ZYtgF9AH+b B5PgHhPsy2aJSVpdA5dhVoAYmQKecozdMvRKbt+oeHguGl/+VsJV7VlIjR3ul2y6 zVNZdldf+sTsmNPCaIrtBzr0q1ta590NcXfKNWJuqjSoLLNbrg2unvx0nqwApzX/ gJg3RFvpwYE7FNTTrkGWPN/+UXN5A== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 501) id B2D7FEE93; Thu, 2 Aug 2018 20:09:58 -0400 (EDT) Message-Id: <5294db5b-f0ef-45b3-a997-69f68a0df352@sloti22d1t06> User-Agent: Cyrus-JMAP/3.1.5-137-g843a534-fmnext-20180801v1 x-jmap-identity-id: 56629417 In-Reply-To: <1532034781.1793667.1446611920.5FAB04E6@webmail.messagingengine.com> References: <1532034781.1793667.1446611920.5FAB04E6@webmail.messagingengine.com> Date: Thu, 02 Aug 2018 20:09:49 -0400 From: Bron Gondwana To: extra@ietf.org Cc: Michael Slusarz Content-Type: multipart/alternative; boundary=dc00ddde6fc041be9b56d51ff0d22a79 Archived-At: Subject: Re: [Extra] Call for adoption - draft-slusarz-imap-fetch-snippet X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2018 00:10:02 -0000 --dc00ddde6fc041be9b56d51ff0d22a79 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable And that's the two weeks up, and everyone's been responding positivitely= .=C2=A0 I have adopted this draft into the working group. Michael, if you want to upload a new version as draft-extra-imap-fetch-s= nippet-00 that's all good :) Cheers, Bron. On Fri, Jul 20, 2018, at 07:13, Bron Gondwana wrote: > Hi All, >=20 > As discussed in today's meeting, this is a formal call for adoption fo= r: >=20 > https://datatracker.ietf.org/doc/draft-slusarz-imap-fetch-snippet/ >=20 > It was clear in the room that this isn't the final form of the documen= t, so this is a call to adopt the document into the group for ongoing wo= rk.=C2=A0 Please let the group know if you have any objection to taking = on this document. >=20 > I will give two weeks for this, so please file any objections by Augus= t 3rd. >=20 > Kind regards, >=20 > Bron. >=20 > -- > =C2=A0 Bron Gondwana, CEO, FastMail Pty Ltd > =C2=A0 brong@fastmailteam.com >=20 >=20 -- =C2=A0 Bron Gondwana, CEO, FastMail Pty Ltd =C2=A0 brong@fastmailteam.com --dc00ddde6fc041be9b56d51ff0d22a79 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
And that's the two weeks up, and everyone's been resp= onding positivitely.  I have adopted this draft into the working gr= oup.

Michael, if you want to upload a new version as draf= t-extra-imap-fetch-snippet-00 that's all good :)

Cheers,<= br>

Bron.

On Fri, Jul 20, 2018, at 07:13, Bron= Gondwana wrote:
Hi All,

As discussed= in today's meeting, this is a formal call for adoption for:


It was clear in the room that this isn't the fi= nal form of the document, so this is a call to adopt the document into t= he group for ongoing work.  Please let the group know if you have a= ny objection to taking on this document.

I will give two = weeks for this, so please file any objections by August 3rd.

Kind regards,

Bron.

--
  Bron Gondwana, CE= O, FastMail Pty Ltd
&n= bsp; brong@fastmailteam.com



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


--dc00ddde6fc041be9b56d51ff0d22a79-- From nobody Thu Aug 2 17:46:20 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF103130E68 for ; Thu, 2 Aug 2018 17:46:15 -0700 (PDT) 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=fIv8mOEE; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=UGisw17R Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mbzbTqaD31nL for ; Thu, 2 Aug 2018 17:46:14 -0700 (PDT) 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 51AD6130E51 for ; Thu, 2 Aug 2018 17:46:14 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 8756D2E1 for ; Thu, 2 Aug 2018 20:46:13 -0400 (EDT) Received: from imap22 ([10.202.2.72]) by compute6.internal (MEProxy); Thu, 02 Aug 2018 20:46:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=LJjavkewVtjIC+Fml97VxBcNlrXnEY10V+WargKnF hg=; b=fIv8mOEE33ge/+OjBOO9s4abcvzkVCu2jVmbLyh/4kTIc0UI6UqeVJWjJ VVwRXQkPvFQY1NXEvfkbravC50GlosEG0iePOgdFQyi/a98NJ2ho+IYrJ7Mybq69 +syus6z6CQNxZZsVnNGQ2olI7o29oZeLGnMOTn3KdCFmEJrAEPS4MHRkCykB/6u+ H2EdNlLZFuUmM900S9Y6QVVsNHDw0j59+b7mFiXE/xNKw9LZiG+BLpPPuRRXGJU9 /eKojfWDpUWLulLdVvJVbsNlH0l0ixNLAsJ8vtm8exWRZigMtwWjVogagd/elmOP DltNzE9PBlh1IuJH2vAFbWC5QTb6w== 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-sender:x-me-sender :x-sasl-enc; s=fm3; bh=LJjavkewVtjIC+Fml97VxBcNlrXnEY10V+WargKnF hg=; b=UGisw17RBwWCiVLfBR+hec1fT8DIHKwhLm6i+Vpj/aiNKsmUyrWf8SVcQ 4s0Z12HoGxAU0K8OCMNB+HJXycDe621DRsqgWyu8SovVToaXcNGzjvGvadfmodRF CpBUHRjuD2O3qYClPf/5LxDZtxjrioFv80REGdskmBpV1C3kBAFoJVpt4H+3ogBH SikDLiQqlvBvgZ5iEjkxZNXxD72LrsTogRX7V8Fe0alwyc3AMURwEijm8EmQbh+r kDfh5M6cdZXMJRej6CuKDhTa9djgIB5TE2w4V/9G2xJRsFmwxAhFzLuNPfGeN+9H HPY8WvxNSSRDokfJ1yvJhWaRXog2A== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 501) id D841DEE93; Thu, 2 Aug 2018 20:46:12 -0400 (EDT) Message-Id: <6831c19f-849b-409e-bf55-0f57ae985d48@sloti22d1t06> User-Agent: Cyrus-JMAP/3.1.5-137-g843a534-fmnext-20180801v1 x-jmap-identity-id: 56629417 In-Reply-To: <1532034526.1792463.1446606328.14CB8B22@webmail.messagingengine.com> References: <1532034526.1792463.1446606328.14CB8B22@webmail.messagingengine.com> Date: Thu, 02 Aug 2018 20:46:07 -0400 From: Bron Gondwana To: extra@ietf.org Content-Type: multipart/alternative; boundary=80887705cd3144abb1669be3ad40e576 Archived-At: Subject: Re: [Extra] =?utf-8?q?Call_for_adoption_and_directly_to_WGLC_-_draft?= =?utf-8?q?-brandt-imap-replace?= X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2018 00:46:16 -0000 --80887705cd3144abb1669be3ad40e576 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable I'm assuming the lack of discussion here is because everyone's already b= asically happy with this draft as is!=C2=A0 The two weeks is up, and I'v= e adopted the document into the group and then directly to WGLC. Stuart, if you could please upload a draft-ietf-extra-imap-replace-00. Also idnits complained about the [UID] in the sample equivalent IMAP com= mands: 1. APPEND 2. [UID] STORE +FLAGS.SILENT \DELETED 3. UID EXPUNGE I would probably just take the brackets off the UID.=C2=A0 The "same eff= ect" will still mean the same thing! Cheers, Bron. On Fri, Jul 20, 2018, at 07:08, Bron Gondwana wrote: > The draft is here: >=20 > https://datatracker.ietf.org/doc/draft-brandt-imap-replace/ >=20 > There's already been a bunch of discussion on the list, and the docume= nt appears to be in good shape.=C2=A0 I'd like to kill two birds with on= e stone, so I'm asking if there are any objections to either of: >=20 > a) adopting this document into this working group > b) taking version -02 to working group last call >=20 > I'll give two weeks for this.=C2=A0 If there are no objections given, = I intend to adopt the document and then immediately make a working group= last call, which will be an additional period of 3 weeks. >=20 > If you're happy to adopt, but think there's more discussion required -= please do say, happy to do that too. >=20 > Kind regards, >=20 > Bron. >=20 > -- > =C2=A0 Bron Gondwana, CEO, FastMail Pty Ltd > =C2=A0 brong@fastmailteam.com >=20 >=20 -- =C2=A0 Bron Gondwana, CEO, FastMail Pty Ltd =C2=A0 brong@fastmailteam.com --80887705cd3144abb1669be3ad40e576 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
I'm assuming the lack of discussion here is because e= veryone's already basically happy with this draft as is!  The two w= eeks is up, and I've adopted the document into the group and then direct= ly to WGLC.

Stuart, if you could please upload a draft-ie= tf-extra-imap-replace-00.
Also idnits complained about th= e [UID] in the sample equivalent IMAP commands:

      1. APPEND
      2. [UID] STORE +FLAGS.SILENT \DELETED
      3. UID EXPUNGE

I would probably just take the brack= ets off the UID.  The "same effect" will still mean the same thing!=

Cheers,

B= ron.

On Fri, Jul 20, 2018, at 07:08, Bron Gondwana wrote:=
The draft is here:


There's al= ready been a bunch of discussion on the list, and the document appears t= o be in good shape.  I'd like to kill two birds with one stone, so = I'm asking if there are any objections to either of:

a) a= dopting this document into this working group
b) taking version -02 to working group last call

I'll give two weeks for this.  If there are no objections = given, I intend to adopt the document and then immediately make a workin= g group last call, which will be an additional period of 3 weeks.

If you're happy to adopt, but think there's more discussion req= uired - please do say, happy to do that too.

Kind regards= ,

Bron.
=

--
  Bron Gondwana, CEO, FastMail Pt= y Ltd
  brong@fas= tmailteam.com



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


--80887705cd3144abb1669be3ad40e576-- From nobody Thu Aug 2 17:47:46 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60A9A130E51 for ; Thu, 2 Aug 2018 17:47:46 -0700 (PDT) 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=D3WYEJFy; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=v5QmyZlZ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0aOzxKB0YqH for ; Thu, 2 Aug 2018 17:47:45 -0700 (PDT) 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 A2A77130DE3 for ; Thu, 2 Aug 2018 17:47:45 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 280B0389; Thu, 2 Aug 2018 20:47:45 -0400 (EDT) Received: from imap22 ([10.202.2.72]) by compute6.internal (MEProxy); Thu, 02 Aug 2018 20:47:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc:content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=zqrsDE/uHdbR4uzaumFJME8ypPDe+xSQ+n+PGy0yR GE=; b=D3WYEJFy1Il0ScVC8yjpDLqyYWu98yZDbNNRLlvbn6GqXI0rxHf1CZZIR PSCLnCWvqm8AXhql5ne1pHvxTmt65VOKTqFg9kd8hiHleBOo5K1WJwHorSj1pqGX Mt52OgwSVH6OnBVML6k/GiEYWFT3doBHhkn14OlVpKhlZfsxpqtCSbtGuPCfcvjA 0mCf/CHSgsFq0oC3jZrAQ4O3Ntyoq+e3ITI/gbYCuHCm4CSr+gWpXuZYQT/VI7cU FKxPM5xXoCpPdBwMeJOUjJ83qbHRhJCoAKNlyVoPaKrgfw95jgMQM5VtFVo9Gnp6 ek941i6Bj+EyfAcKZ//bukHqPUTlQ== 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-sender:x-me-sender :x-sasl-enc; s=fm3; bh=zqrsDE/uHdbR4uzaumFJME8ypPDe+xSQ+n+PGy0yR GE=; b=v5QmyZlZLiCKP6hCz7J+EHLvO1fuqLAg0g/KomNfwHDb3LZJDZFmrpRB7 +yXWtJXBMQJPcYgC5lA+KrbOrvajz1+ALDohzXb5qaW7aLnKk3qchjv3eRsVzHUw ZDAJFl+l6wsbxjN64rYTshcR74hwZ+Oizai1/kpRIQQ123GFVDRLHcU4Rv0Pg9uf YbEmbOcG+mi19NKAO0S+DnGAoHIUYngdwqjLw4t8FjdmZSkMXtwu+aoHjv6DcVNl qhZD9gj51JXsuPW7R4iF1VCYivMs94ndRtFugQfiQzlwpdTHLYh2lyyWBT8BIucf yzpIL51XC4mHrr7IMubD2QWa1i7XQ== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 4C152EE93; Thu, 2 Aug 2018 20:47:44 -0400 (EDT) Message-Id: User-Agent: Cyrus-JMAP/3.1.5-137-g843a534-fmnext-20180801v1 x-jmap-identity-id: 56629417 In-Reply-To: <5294db5b-f0ef-45b3-a997-69f68a0df352@sloti22d1t06> References: <1532034781.1793667.1446611920.5FAB04E6@webmail.messagingengine.com> <5294db5b-f0ef-45b3-a997-69f68a0df352@sloti22d1t06> Date: Thu, 02 Aug 2018 20:47:43 -0400 From: Bron Gondwana To: extra@ietf.org Cc: Michael Slusarz Content-Type: multipart/alternative; boundary=c9663a40b0a64ad7a7fb18484a1c2a4c Archived-At: Subject: Re: [Extra] Call for adoption - draft-slusarz-imap-fetch-snippet X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2018 00:47:46 -0000 --c9663a40b0a64ad7a7fb18484a1c2a4c Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Fri, Aug 3, 2018, at 10:10, Bron Gondwana wrote: > And that's the two weeks up, and everyone's been responding positivite= ly.=C2=A0 I have adopted this draft into the working group. >=20 > Michael, if you want to upload a new version as draft-extra-imap-fetch= -snippet-00 that's all good :) Erm, sorry.=C2=A0 I of course meant draft-ietf-extra-imap-fetch-snippet-= 00. Bron. -- =C2=A0 Bron Gondwana, CEO, FastMail Pty Ltd =C2=A0 brong@fastmailteam.com --c9663a40b0a64ad7a7fb18484a1c2a4c Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Fri, Aug 3, 2018, at 10:10, Bron Gondwana wrote:
And that's the two weeks up, and everyone's been resp= onding positivitely.  I have adopted this draft into the working gr= oup.

Michael, if you want to upload a new version as draf= t-extra-imap-fetch-snippet-00 that's all good :)
<= div style=3D"font-family:Arial;">
Erm, sorry.  I of course meant draft-ietf-extra-imap-fetch-sni= ppet-00.

Bron.

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


--c9663a40b0a64ad7a7fb18484a1c2a4c-- From nobody Fri Aug 3 07:44:29 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C857F131029 for ; Fri, 3 Aug 2018 07:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 YPudDE5I7QuM for ; Fri, 3 Aug 2018 07:44:25 -0700 (PDT) Received: from fe1.cityemail.com (mail-ob1.cityemail.com [104.128.152.18]) by ietfa.amsl.com (Postfix) with ESMTP id 729BE130DFC for ; Fri, 3 Aug 2018 07:44:25 -0700 (PDT) Received: (qmail 30108 invoked from network); 3 Aug 2018 14:44:23 -0000 Received: from riddle.wizard.ca (HELO [192.168.1.55]) (michael@wizard.ca@104.128.144.8) by fe1.cityemail.com with (DHE-RSA-AES128-SHA encrypted) SMTP (b5d75098-972b-11e8-ab7d-6ffc6cbb562c); Fri, 03 Aug 2018 07:44:23 -0700 To: extra@ietf.org References: <1dc71d96-c3be-4ae3-7644-13f7accecace@linuxmagic.com> <79A4C4F2-E4BA-4B4C-B8E0-295B7216EC9C@oracle.com> From: Michael Peddemors Organization: LinuxMagic Inc. Message-ID: <8d0f565e-54d7-a44d-1527-8c42ee09f44f@linuxmagic.com> Date: Fri, 3 Aug 2018 07:44:22 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-MagicMail-OS: Linux 3.11 and newer X-MagicMail-UUID: b5d75098-972b-11e8-ab7d-6ffc6cbb562c X-MagicMail-Authenticated: michael@wizard.ca X-MagicMail-SourceIP: 104.128.144.8 X-MagicMail-RegexMatch: 0 X-MagicMail-EnvelopeFrom: X-Archive: Yes Archived-At: Subject: Re: [Extra] CLIENT ID - Next Steps - General Discussion Overview X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2018 14:44:28 -0000 Thanks Brandon, for weighing in on this.. And it is good that we seem to have consensus on the following: * Concept of CLIENTID is worthwhile to pursue * Standardization is also worthwhile However, again we should point out. It isn't that doing this (coding) in a SASL is difficult, we already examined this, and found that it limited the scope and abilities that CLIENTID offers. By presenting this at the protocol level, we can always pass it to a SASL that wishes to implement it, but by doing it at the protocol layer it makes it available to all SASL methods that might be developed/extended in the future. AS well, no use creating a standard that isn't going to see adoption, and our team looked at many of the client implementations (opensource) as well as several other IMAP server implementations, and realized that it is easier to port the protocol implementation, than SASL's across the board. And in some cases, what you want the CLIENTID to interact with, is only available at the protocol level, whereas the SASL implementations might not have access. CLIENTID is more than just authentication, as pointed out several times already, which is why we call it 'two and 1/2' factor authentication. The IMAP protocol can handle the verification/sanity and interact with external systems, including identifying attack heuristics, and it will be available to any SASL which is interested in using it in the authentication layer, including legacy SASL and other authentication schemes. -- Michael -- PS, we are still moving forward with implementation at this level, and publishing patches for email clients and other opensource IMAP implementations based on our model, so it would be nice to see standardization around this model. So far the only change to our plans has been taking into account the opinions of others that we should not use the CID acronym, and consider using CLIENTID/DEVICEID instead. Trying to reach a consensus on opinions on this in the mean time. On 18-08-02 04:37 PM, Brandon Long wrote: > (catching up on email from vacation) > > On Mon, Jul 23, 2018 at 3:53 PM Chris Newman > wrote: > > On 23 Jul 2018, at 11:27, Michael Peddemors wrote: > > > > * It was questioned, is the proper place for this in a SASL > mechanism, > >   vs in the protocol itself, and while our development work and > > research > >   show that the advantages for a 'device identifier' to be part > of the > >   protocol/syntax rather than a SASL, and our assertion this will > help > >   in the adoption curve in the industry, it was one of the strongest > >   points of contention, with the arguments for SASL, was one SASL can > >   apply to many services, and thus if that argument holds, then maybe > >   the SASL or a security group would be better for this.  We > intend to > >   argue against this, but the topic alone is key to discussions, > so it > >   requires a separate thread to discuss this. > > We have a case where client-id facilities (device-specific token, a > subset of the client-id problem) were deployed in production using > custom SASL mechanisms on our server and custom changes to a client. So > I assert this is a proof-of-concept that SASL is deployable for > client-id, that it can solve the problem for multiple protocols with > one > specification and shared code (Submission & IMAP), that it comes > with an > extensible capability model for interoperability, and does not break > interoperability with unmodified clients. Furthermore, no custom > changes > were required to our server to support this since we have a SASL > abstraction API we support. That means our customers could deploy a > SASL-based mechanism without requiring a server upgrade, thus > significantly simplifying deployment. We do not have an API for IMAP > commands and have no intention of providing one, so our customers will > not be able to deploy client ID unless it is SASL or there is an IETF > rough consensus around a non-SASL client-id model for > submission+imap(+pop+managesieve+jmap+etc). > > I consider it unfortunate this use case involved proprietary SASL > mechanisms so I'd support a standardized mechanism, but we have running > code showing a SASL approach is deployable and backwards compatible. > > I'm aware of another deployed use of client-id like facilities for push > notifications. > > > Note that PLAIN-CLIENTTOKEN that gmail still offers for MSA/POP/IMAP is > a form of this in SASL as well, something that we worked on with several > clients (and intended to be taken for standardization) before deciding > to go the OAUTH route that led to OAUTHBEARER eventually. > > Just adding the token into the sasl data seemed pretty straightforward. > > (not sure if it was mentioned in the presentation or not) > > Brandon -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. From nobody Fri Aug 3 08:01:29 2018 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D9148131041; Fri, 3 Aug 2018 08:01:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: extra@ietf.org Message-ID: <153330848683.18523.8534390498817157856@ietfa.amsl.com> Date: Fri, 03 Aug 2018 08:01:26 -0700 Archived-At: Subject: [Extra] I-D Action: draft-ietf-extra-sieve-fcc-03.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2018 15:01:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email mailstore and eXtensions To Revise or Amend WG of the IETF. Title : Sieve Extension: File Carbon Copy (Fcc) Authors : Kenneth Murchison Bron Gondwana Filename : draft-ietf-extra-sieve-fcc-03.txt Pages : 13 Date : 2018-08-03 Abstract: The Sieve Email Filtering Language provides a number of action commands, some of which can generate additional messages on behalf of the user. This document defines an extension to such commands to allow a copy of any generated message to be filed into a target mailbox. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-extra-sieve-fcc/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-extra-sieve-fcc-03 https://datatracker.ietf.org/doc/html/draft-ietf-extra-sieve-fcc-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-sieve-fcc-03 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 Fri Aug 3 08:08:22 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD36B130E8F for ; Fri, 3 Aug 2018 08:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=H+E/IwGm; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=SbFCItDy Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wS8oLRcXpDTc for ; Fri, 3 Aug 2018 08:08:18 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B099C130E7F for ; Fri, 3 Aug 2018 08:08:18 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 15DD221C4F; Fri, 3 Aug 2018 11:08:18 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Fri, 03 Aug 2018 11:08:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= cc:content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; bh=Lth+y3WDDnNx9H14L3ECMvvlt5Mv0qpObM6mY9Y27e0=; b=H+E/IwGm rhPfQK9Xq7AZN7pBLLketez8sBRj7hiLN5It+2vR5X9cwiqBz8GmEyWYvpfAPOv2 wZXt1vxA8uTLlR0XqPfuGjq2JP+byudnHCjVN9PDCc/UrCaJ6HSc/c9LgqjZJfw9 m+J8XLC5JvZlb3o5WcTdJoDthlGUQLMSUge9BdWiw39wwdsYxV/BLx/Q1mALGvbA AWW9g/CCWJwFNLeRdqim2lLaiobYV41+n99x6il7eFB2v1HAglFP5VCOQAwoFqdn 8mGxcvTiqkrz/V1Sf1dgHUTAUslSVLYG8cAktVoWb0miRPA+hvMab1XTzsC93/fI 1UN0sLd1vAjS/g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=Lth+y3WDDnNx9H14L3ECMvvlt5Mv0 qpObM6mY9Y27e0=; b=SbFCItDyzpZ5bGWokaBRn65vygFEM+ieeF15IhrOF/eR+ oQ0fYH6PtnDnXASZ9VAfHznU/K+onI1W15s2E0EQlJApRU4JyCI5rxTskd7sCBe+ iEI9fZlrDRr2/PIT0RLr3oG8xZnDK1KXjLHfQ1yvd4uLAHx1evlrm79LMC4epdpH EMfBWpMAEbGE2hrIbk5M9O9eqEjdYICbWQ95yYQRm9RNh8mlXVHtgHTDmJOKpFSR CfzUfZOVwDyUpQWj2Uxhzpa+8JAr2Tn4d1njh0UxvpfgiKpuDskNo0vA9qohoeq4 +UqiqZ6KhpnVHzFgyrVinXpyfh4NY6duVO5QgLZ5A== X-ME-Proxy: X-ME-Sender: Received: from localhost.localdomain (cpe-74-77-85-250.buffalo.res.rr.com [74.77.85.250]) by mail.messagingengine.com (Postfix) with ESMTPA id E0E2BE4BDD; Fri, 3 Aug 2018 11:08:16 -0400 (EDT) To: Ned Freed , Bron Gondwana Cc: extra@ietf.org References: <1527339613.810325.1386461928.7A2775BA@webmail.messagingengine.com> <01QTIJ66FRSK000051@mauve.mrochek.com> From: Ken Murchison Organization: FastMail US LLC Message-ID: Date: Fri, 3 Aug 2018 11:08:16 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <01QTIJ66FRSK000051@mauve.mrochek.com> Content-Type: multipart/mixed; boundary="------------D1225F213BE11846C277CBE7" Content-Language: en-US Archived-At: Subject: Re: [Extra] sieve-fcc next steps X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2018 15:08:21 -0000 This is a multi-part message in MIME format. --------------D1225F213BE11846C277CBE7 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Ned, I believe all of your comments/suggestions/nits have been addressed in the just posted -03 draft. Do you have some text describing your implementation that you are able to contribute to the Implementation Status section of the draft? On 06/09/2018 08:49 PM, Ned Freed wrote: > I have now implemented the fcc extension and thus am in a position to > comment further on the draft. > > I first want to note that this was *far* more difficult to implement than I > expected. There are a number of issues, but the important one in regards to > standardization is that the extension more less assumes direct mailbox access. > This is arguably OK for a Sieve implementation that acts after final delivery, > but that's not how all implementations work. And when you're talking about an > implementation that operates as part of an SMTP server, you can't just blithely > start up an IMAP session and do an APPEND. Even if that's technically feasible, > what if there's an store availability issue or a timeout? > > Of course you can create a new queue to address this, but now you're talking > about an additional thing that needs to be managed, and we like to avoid doing > that if possible. > > The alternative is to use the same mechanism that's used for mailto: > notifications and vacation messages. In effect, it's adding another recipient. > But a special sort of recipient - one that has a regular mailbox and > potentially a special use mailbox, set of IMAP flags, and create flag attached. > > Creating a new mechanism for this would have been a pain, but it occurred to me > that we already have such a mechanism: Sieve. What :fcc effectively does is > create a message with an associated sieve fileinto action. And that's how > I ended up implementing it. > > And relevance of this to the standard is that thinking of :fcc in terms of it > being a fileinto attached to the new message helps nail down the semantics. > For example, nowhere does the current document define the syntax or semantics > of the mailbox argument to :fcc. But RFC 5228 section 4.1 does all of this for > the mailbox argument to fileinto, and I don't see any reason why we shouldn't > say that the syntax and semantics have to be the same. Ditto for :specialuse, > :flags, and :create. > >> I asked a few weeks ago about progressing both objectid and sieve-fcc. >> Since objectid is pretty polished now, I'm ready for that to move on. >> Sieve-fcc has two outstanding questions though: >> * what to do about message format for notify/enotify fcc > The specification of the enotify extension itself provides the tools you need > for this. In particular, section 4 of RFC 5435 defines the valid_notify_method > test, which can be used to check if a given notification method is supported. I > see no reason why we can't add an :fcc parameter to this test to check and see > if the method is both valid and supports :fcc. > > :fcc in this case could be defined to take an argument that would also be > validated. Alternately, the argument could be omitted and the test could simply > be for :fcc support, but I see no reason to do that. > >> * do we need separate capabilities, or just "fcc"? > No. Again, the necessary capabilities are there in the extension; all you need > to do is use them. > >> I am soliciting opinions, either "I agree with you, Bron, sounds great" >> - or suggestions for better ideas! I have no strong attachment to any >> particular choice, but I would like to get this document progressed... >> * Regarding message format for notify - I'm happy to say "it's up to the >> server to serialise something in MESSAGE/RFC822 which is readable and >> contains the details of the notification. Since notify can be >> arbitrary data formats, the alternative of trying to specify a >> particular behaviour beyond that is either very complex, or very >> limiting. I see no need to lock down the format, since this feature >> will be either for a human to read, or for audit/compliance reasons, >> so requirements will vary by site. > Not sufficient IMO. I think that for standardized notification methods we need > to specify the mapping to an email message. > >> * Regarding capability: I'm happy with just fcc - it should be easy to >> implement across all types in our server, and I assume in other >> servers too. > Whereas I can readily envision implementing a notification method > that doesn't translate well if at all to an email message. > >> Please let us know what you think. I'll ask Ken to get it written up >> and maybe we can get this one processed before Montreal as well. >> Cheers, > Here are some specific comments on the current document. > > Section 1. The decision to limit the extension to just vacation and > notify needs to be reflected in the introduction. I suggest changing it to > read: > > The Sieve Email Filtering Language [RFC5228] provides a number of > action commands, some of which can generate additional messages on > behalf of the user. It is sometimes desirable to have an archive of the > messages generated by such commands. > > This extension defines a new optional tagged argument ":fcc" that > can be specified on action commands which generate additional messages to > allow a copy of the generated message to be filed into a target mailbox. > > The capability string associated with this extension is "fcc". > > Each action that generates additional messages will need to specify > how it interfacts with :fcc. This document also specifies the interaction > of :fcc with the Vacation [RFC5230] and Notify [RFC5435] extensions. > > Section 2. There's been pushback to use the updated keyword text in RFC 8174 > rather than RFC 2119. Might as well make the change now. > > Section 3. This should state that the syntax and semantics MUST match those > of the mailbox arugment to fileinto specified in RFC 5228 section 4.1. > > Section 3.3. I suggest that for now this be made specific to the mailto: > method. If someone wants to write some requirements for tel: and xmpp: that's > fine too. > > Section 3.4. Given that this document only specifies use of :fcc with vacation > and notify, and given the content of 3.5, I'm not sure we really need this. I > think it would be best to remove it. If we do retain it, it needs to be recast > along the lines of "Implementations MUST NOT allow use of :fcc with ereject and > reject. > > Section 3.6 needs to state that when fileinto arguments are used with :fcc > they have the same syntax and semantics as they do with fileinto. > > That's it for now. > > Ned > > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra -- Ken Murchison Cyrus Development Team FastMail US LLC --------------D1225F213BE11846C277CBE7 Content-Type: text/x-vcard; name="murch.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="murch.vcf" bnVsbA== --------------D1225F213BE11846C277CBE7-- From nobody Fri Aug 3 14:02:22 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE3741310E2 for ; Fri, 3 Aug 2018 14:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 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_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.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 RC1E5HJylGik for ; Fri, 3 Aug 2018 14:02:19 -0700 (PDT) Received: from userp2120.oracle.com (userp2120.oracle.com [156.151.31.85]) (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 EB0FF130FE4 for ; Fri, 3 Aug 2018 14:02:18 -0700 (PDT) Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w73KxUKK005714; Fri, 3 Aug 2018 21:02:16 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-type; s=corp-2018-07-02; bh=jnWyBQtjAOlDv3T7VC0irsdBMzxdcXhtz2g8sm/zMqE=; b=rXu/Ie9zNyOoa+S/S4wasBgxMo7boNAMOD3AXV8Lbffhe99UC8azbF+8N30RTyaK9Ux2 Ik1L8i/tioNQdH32+MZMpMzqjB/xGILRpPX6xyegqEs4ItwMciGnXXNintypdxITBERE 1HAbGN7m2NmEOh0kKmrWcAT/ofP8z8Y0ze0xyLkv1UnvqlhAKqAV+2kAXiamimriVRMa Vr5/LuH1VPKWI/p6xmM2Sm5i4A7b5+C6wUZBN/Mo44LStz+lPAAnXUx8mF+p3W8I0rOE EhM1Gth0klKAeGbSMvTgnO9KpqBfQRfUK4xxSkOETK7h4O3roGwcc3zT5KAaP3129cxq lA== Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp2120.oracle.com with ESMTP id 2kma043usm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 03 Aug 2018 21:02:16 +0000 Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w73L2FDs014216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 3 Aug 2018 21:02:15 GMT Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w73L2EMF017881; Fri, 3 Aug 2018 21:02:14 GMT Received: from [10.145.183.68] (/10.145.183.68) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 03 Aug 2018 14:02:14 -0700 From: "Chris Newman" To: "Brandon Long" Cc: "Michael Peddemors" , extra@ietf.org Date: Fri, 03 Aug 2018 14:02:11 -0700 X-Mailer: MailMate (1.11.3r5509) Message-ID: <0D7A6217-3207-4F75-8BC6-B0E660EE7D36@oracle.com> In-Reply-To: References: <1dc71d96-c3be-4ae3-7644-13f7accecace@linuxmagic.com> <79A4C4F2-E4BA-4B4C-B8E0-295B7216EC9C@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8974 signatures=668707 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1808030227 Archived-At: Subject: Re: [Extra] CLIENT ID - Next Steps - General Discussion Overview X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2018 21:02:21 -0000 On 2 Aug 2018, at 16:37, Brandon Long wrote: > (catching up on email from vacation) > > On Mon, Jul 23, 2018 at 3:53 PM Chris Newman > wrote: > >> On 23 Jul 2018, at 11:27, Michael Peddemors wrote: >>> >>> * It was questioned, is the proper place for this in a SASL >>> mechanism, >>> vs in the protocol itself, and while our development work and >>> research >>> show that the advantages for a 'device identifier' to be part of >>> the >>> protocol/syntax rather than a SASL, and our assertion this will >>> help >>> in the adoption curve in the industry, it was one of the strongest >>> points of contention, with the arguments for SASL, was one SASL >>> can >>> apply to many services, and thus if that argument holds, then >>> maybe >>> the SASL or a security group would be better for this. We intend >>> to >>> argue against this, but the topic alone is key to discussions, so >>> it >>> requires a separate thread to discuss this. >> >> We have a case where client-id facilities (device-specific token, a >> subset of the client-id problem) were deployed in production using >> custom SASL mechanisms on our server and custom changes to a client. >> So >> I assert this is a proof-of-concept that SASL is deployable for >> client-id, that it can solve the problem for multiple protocols with >> one >> specification and shared code (Submission & IMAP), that it comes with >> an >> extensible capability model for interoperability, and does not break >> interoperability with unmodified clients. Furthermore, no custom >> changes >> were required to our server to support this since we have a SASL >> abstraction API we support. That means our customers could deploy a >> SASL-based mechanism without requiring a server upgrade, thus >> significantly simplifying deployment. We do not have an API for IMAP >> commands and have no intention of providing one, so our customers >> will >> not be able to deploy client ID unless it is SASL or there is an IETF >> rough consensus around a non-SASL client-id model for >> submission+imap(+pop+managesieve+jmap+etc). >> >> I consider it unfortunate this use case involved proprietary SASL >> mechanisms so I'd support a standardized mechanism, but we have >> running >> code showing a SASL approach is deployable and backwards compatible. >> >> I'm aware of another deployed use of client-id like facilities for >> push >> notifications. >> > > Note that PLAIN-CLIENTTOKEN that gmail still offers for MSA/POP/IMAP > is a > form of this in SASL as well, something that we worked on with several > clients (and intended to be taken for standardization) before deciding > to > go the OAUTH route that led to OAUTHBEARER eventually. > > Just adding the token into the sasl data seemed pretty > straightforward. > > (not sure if it was mentioned in the presentation or not) Do you have a spec for PLAIN-CLIENTTOKEN? I hear complaints that OAUTH ends up being not interoperable in a scalable way because each client vendor has to perform a manual registration step with each service provider. I haven't looked at the topic in detail so I may misunderstand something, but that's the impression I have. It would be nice to have a standard that actually interoperates in a scalable fashion. - Chris From nobody Fri Aug 3 15:17:36 2018 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1048E13110E; Fri, 3 Aug 2018 15:17:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: extra@ietf.org Message-ID: <153333465504.18413.7241391074909801973@ietfa.amsl.com> Date: Fri, 03 Aug 2018 15:17:35 -0700 Archived-At: Subject: [Extra] I-D Action: draft-ietf-extra-imap-fetch-snippet-00.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2018 22:17:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email mailstore and eXtensions To Revise or Amend WG of the IETF. Title : IMAP4 Extension: Message Snippet Generation Author : Michael Slusarz Filename : draft-ietf-extra-imap-fetch-snippet-00.txt Pages : 10 Date : 2018-08-03 Abstract: This document specifies an IMAP protocol extension which allows a client to request that a server provide an abbreviated representation of a message (a snippet of text) that can be used by a client to provide a useful contextual preview of the message contents. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-extra-imap-fetch-snippet/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-extra-imap-fetch-snippet-00 https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap-fetch-snippet-00 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 Sat Aug 4 03:37:22 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42CC81294D7 for ; Sat, 4 Aug 2018 03:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 qmQEVlmWdifg for ; Sat, 4 Aug 2018 03:37:19 -0700 (PDT) Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id B348412F1A5 for ; Sat, 4 Aug 2018 03:37:19 -0700 (PDT) Received: from [10.168.3.2] (klara.student.utwente.nl [130.89.162.218]) by mail.dovecot.fi (Postfix) with ESMTPSA id 6E1B62A6905; Sat, 4 Aug 2018 13:37:08 +0300 (EEST) From: Stephan Bosch To: Ned Freed Cc: extra@ietf.org, Bron Gondwana References: <151533655607.10858.793231788332492256@ietfa.amsl.com> <01QNLYA7BLVQ000051@mauve.mrochek.com> <83ddcadc-b756-91c1-3664-81955cd8f0d8@dovecot.fi> <01QTO3THVZ5I00AI1F@mauve.mrochek.com> <53350c64-d021-7f17-86b8-f1b118791cf5@dovecot.fi> Message-ID: <67705936-3c03-30cd-bb39-95fa9673dae3@dovecot.fi> Date: Sat, 4 Aug 2018 12:36:54 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <53350c64-d021-7f17-86b8-f1b118791cf5@dovecot.fi> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Extra] I-D Action: draft-ietf-extra-sieve-special-use-01.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Aug 2018 10:37:21 -0000 Hi Ned, Op 18/07/2018 om 22:58 schreef Stephan Bosch: > Op 13/06/2018 om 17:40 schreef Ned Freed: >> I also reviewed the rest of the revised draft, and it's looking good. >> My one >> remaining concern is with the handling of multiple mailboxes having the >> same special-use flag assigned. The draft currently says: >> >>   More than one mailbox in the user's personal namespace can have a >>   particular special-use flag assigned.  In case of such ambiguity, the >>   mailbox that is chosen for delivery is implementation-defined. >>   However, while the set of mailboxes to which the involved special-use >>   flags are assigned remains unchanged, implementations MUST ensure >>   that the mailbox choice is made consistently, so that the same >>   mailbox is used every time.  Conversely, the chosen mailbox MAY >>   change once the special-use flag assignments that are relevant for >>   the mailbox choice are changed (usually by user interaction). >> >> I don't see a way I can reasonably implement this MUST via IMAP >> unless the IMAP server always returns the list of special-use >> mailboxes in the same order. >> Sure, I can cache the user/special-use-attribute/actual-mailbox-list >> tuple >> somewhere, but caches can always be lost. And mailbox metadata is (a) >> Potentially much too expensive and (b) Subject to the vagarities of user >> actions. >> >> I'm not happy about it, but I think this needs to become a SHOULD. > > Ok. I am not too attached to the MUST anyway. Addressed here: https://github.com/ietfextra/draft-ietf-extra-sieve-special-use/commit/024330130d5af6ff29e48ad137844cbe5fbf5243 >> Another possibility is to use the default mailbox name as a means of >> disambiguating multiple mailboxes with the same special-use attribute: >> If the default mailbox is one of these deliver to it preferentially, >> otherwise the behavior is implementation-defined. Not perfect, but it >> provides a bit more consistent behavior that's easily achievable. >> > > Sounds like a good idea. I'll give this a closer look for the next > revision. Addressed here: https://github.com/ietfextra/draft-ietf-extra-sieve-special-use/commit/a1b8d4f83109424448b51b65fbc014a73a479997 Regards, Stephan. From nobody Sat Aug 4 03:40:57 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B14DD12F1A5 for ; Sat, 4 Aug 2018 03:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 ABlQVmrPYHv0 for ; Sat, 4 Aug 2018 03:40:54 -0700 (PDT) Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5EF1294D7 for ; Sat, 4 Aug 2018 03:40:54 -0700 (PDT) Received: from [10.168.3.2] (klara.student.utwente.nl [130.89.162.218]) by mail.dovecot.fi (Postfix) with ESMTPSA id 3FE172A6905; Sat, 4 Aug 2018 13:40:53 +0300 (EEST) From: Stephan Bosch To: Ned Freed Cc: extra@ietf.org, Bron Gondwana References: <151533655607.10858.793231788332492256@ietfa.amsl.com> <01QNLYA7BLVQ000051@mauve.mrochek.com> <83ddcadc-b756-91c1-3664-81955cd8f0d8@dovecot.fi> <01QTO3THVZ5I00AI1F@mauve.mrochek.com> <53350c64-d021-7f17-86b8-f1b118791cf5@dovecot.fi> Message-ID: <8aee03f5-cb52-0195-889b-f8d4cc3f8332@dovecot.fi> Date: Sat, 4 Aug 2018 12:40:44 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <53350c64-d021-7f17-86b8-f1b118791cf5@dovecot.fi> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Extra] I-D Action: draft-ietf-extra-sieve-special-use-01.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Aug 2018 10:40:56 -0000 Hi Ned, Op 18/07/2018 om 22:58 schreef Stephan Bosch: > Op 13/06/2018 om 17:40 schreef Ned Freed: >>> > This, incidentially, is one of those places where providing the >>> actual IMAP >>> > commands will be especially valuable: Pointing out that you should >>> use the >>> > NAMESPACE extension and if it isn't present, fallback to LIST "" >>> would be very >>> > helpful. >> >>> Here's my initial attempt at addressing this point (separate branch in >>> Github): >> >>> https://github.com/ietfextra/draft-ietf-extra-sieve-special-use/commit/035a1af6137a383089c8d54cd733238dc2dfebda >>> >> The new version of this branch and commit should address all comments related to the IMAP examples: https://github.com/ietfextra/draft-ietf-extra-sieve-special-use/tree/imap-examples https://github.com/ietfextra/draft-ietf-extra-sieve-special-use/commit/daec67edaeb58ea040b640c2814105440692827a I will merge this once you approve. Regards, Stephan. From nobody Mon Aug 6 09:11:44 2018 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E61FC130E5A; Mon, 6 Aug 2018 09:11:41 -0700 (PDT) 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.83.0 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , Jiankang Yao , extra@ietf.org, yaojk@cnnic.cn, extra-chairs@ietf.org, alexey.melnikov@isode.com, draft-ietf-extra-imap-objectid@ietf.org, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <153357190193.26706.7945676930102187801.idtracker@ietfa.amsl.com> Date: Mon, 06 Aug 2018 09:11:41 -0700 Archived-At: Subject: [Extra] Protocol Action: 'IMAP Extension for object identifiers' to Proposed Standard (draft-ietf-extra-imap-objectid-08.txt) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 16:11:42 -0000 The IESG has approved the following document: - 'IMAP Extension for object identifiers' (draft-ietf-extra-imap-objectid-08.txt) as Proposed Standard This document is the product of the Email mailstore and eXtensions To Revise or Amend Working Group. The IESG contact persons are Adam Roach, Alexey Melnikov and Ben Campbell. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-extra-imap-objectid/ Technical Summary This document updates RFC3501 (IMAP4rev1) with persistent identifiers on mailboxes and messages to allow clients to more efficiently re-use cached data when resources have changed location on the server. Working Group Summary The EXTRA WG meeting in IETF 101 had detailed discussion about this draft. The editor had updated it accordingly. Before WGLC, several experts reviewed the draft in detail. All identified issues were reflected in the new version of the draft. During WGLC, a minor issue was identified and fixed in the new version. The WG has looked throught this document in detail. Document Quality The document is in good shape and is ready to be published. The document is based on 2 similar private extensions by Gmail and Dovecot. The WG hopes to move this document quickly as IMAP4rev2 may want to include it. Personnel Document Shepherd - Jiankang Yao (EXTRA co-chair) Responsible Area Director - Alexey Melnikov From nobody Tue Aug 7 03:21:36 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37CA5130EAC for ; Tue, 7 Aug 2018 03:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8NxyvVsRYpCR for ; Tue, 7 Aug 2018 03:21:32 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4E2130DC8 for ; Tue, 7 Aug 2018 03:21:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1533637291; d=isode.com; s=june2016; i=@isode.com; bh=vnCjPdCeOCjmW/Sk0oi/RblrMRj+2Zk6hFevqh52D94=; 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=rb7G/So3kWJ2YjIEIltUZ+xsD0yux2sIFTIobHAk1zx/zMyTZyf5qfZoKYxMe+ZFpgcUIc 8QidO1+9e1ftHDThuwdnFPCY1COSbNTkPIhv7l6hpEjpaY3PRMhzlVaSmjolSYKr1wU7dr iBugLB2Yp5sxuG1LuCWvCKw7m0JNHDk=; 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 ; Tue, 7 Aug 2018 11:21:31 +0100 To: Bron Gondwana , extra@ietf.org References: <1532034526.1792463.1446606328.14CB8B22@webmail.messagingengine.com> <6831c19f-849b-409e-bf55-0f57ae985d48@sloti22d1t06> From: Alexey Melnikov Message-ID: Date: Tue, 7 Aug 2018 11:21:16 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 In-Reply-To: <6831c19f-849b-409e-bf55-0f57ae985d48@sloti22d1t06> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------9C5234F88ED0C7AE8432CD5B" Content-Language: en-GB Archived-At: Subject: Re: [Extra] Call for adoption and directly to WGLC - draft-brandt-imap-replace X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2018 10:21:34 -0000 --------------9C5234F88ED0C7AE8432CD5B Content-Type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: quoted-printable On 03/08/2018 01:46, Bron Gondwana wrote: > I'm assuming the lack of discussion here is because everyone's already=20 > basically happy with this draft as is!=C2=A0 The two weeks is up, and I've= =20 > adopted the document into the group and then directly to WGLC. > > Stuart, if you could please upload a draft-ietf-extra-imap-replace-00. > > Also idnits complained about the [UID] in the sample equivalent IMAP=20 > commands: > > 1. APPEND > 2. [UID] STORE +FLAGS.SILENT \DELETED > 3. UID EXPUNGE > > I would probably just take the brackets off the UID.=C2=A0 The "same=20 > effect" will still mean the same thing! On this one thing: I don't particularly care one way or another, but=20 idnits complaining doesn't mean that this needs to be fixed. It is Ok=20 just to state in the shepherding writeup (when it needs to be written)=20 that some reported nits are not real problems. > Cheers, > > Bron. > > On Fri, Jul 20, 2018, at 07:08, Bron Gondwana wrote: >> The draft is here: >> >> https://datatracker.ietf.org/doc/draft-brandt-imap-replace/ >> >> There's already been a bunch of discussion on the list, and the=20 >> document appears to be in good shape.=C2=A0 I'd like to kill two birds=20 >> with one stone, so I'm asking if there are any objections to either of: >> >> a) adopting this document into this working group >> b) taking version -02 to working group last call >> >> I'll give two weeks for this. If there are no objections given, I=20 >> intend to adopt the document and then immediately make a working=20 >> group last call, which will be an additional period of 3 weeks. >> >> If you're happy to adopt, but think there's more discussion required=20 >> - please do say, happy to do that too. >> >> Kind regards, >> >> Bron. >> >> -- >> =C2=A0 Bron Gondwana, CEO, FastMail Pty Ltd >> brong@fastmailteam.com >> >> > > -- > =C2=A0 Bron Gondwana, CEO, FastMail Pty Ltd > =C2=A0 brong@fastmailteam.com > > > > > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra --------------9C5234F88ED0C7AE8432CD5B Content-Type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

On 03/08/2018 01:46, Bron Gondwana wrote:

I'm assuming the lack of discussion here is because everyone's already basically happy with this draft as is!=C2=A0 The two weeks is up, and I've adopted the document into the group and then directly to WGLC.

Stuart, if you could please upload a draft-ietf-extra-imap-replace-00.

Also idnits complained about the [UID] in the sample equivalent IMAP commands:

      1. APPEND
      2. [UID] STORE +FLAGS.SILENT \DELETED
      3. UID EXPUNGE

I would probably just take the brackets off the UID.=C2=A0 The "same effect" will still mean the same thing!
On this one thing: I don't particularly care one way or another, but idnits complaining doesn't mean that this needs to be fixed. It is Ok just to state in the shepherding writeup (when it needs to be written) that some reported nits are not real problems.

Cheers,

Bron.

On Fri, Jul 20, 2018, at 07:08, Bron Gondwana wrote:
The draft is here:


There's already been a bunch of discussion on the list, and the document appears to be in good shape.=C2=A0 I'd like to kill two birds with one stone, so I'm asking if there are any objections to either of:

a) adopting this document into this working group
b) taking version -02 to working group last call

I'll give two weeks for this.=C2= =A0 If there are no objections given, I intend to adopt the document and then immediately make a working group last call, which will be an additional period of 3 weeks.

If you're happy to adopt, but think there's more discussion required - please do say, happy to do that too.

Kind regards,

Bron.

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



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




_______________________________________________
Extra mailing list
Extra@i=
etf.org
https://www.ietf.org/mailman/listinfo/extra

--------------9C5234F88ED0C7AE8432CD5B-- From nobody Tue Aug 7 03:33:27 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC2F2130F85 for ; Tue, 7 Aug 2018 03:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=zK/QwcZO; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=uMPaUBXm Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CcQTXpC6cZ30 for ; Tue, 7 Aug 2018 03:33:24 -0700 (PDT) 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 E7C90130EEB for ; Tue, 7 Aug 2018 03:33:23 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id B4790258; Tue, 7 Aug 2018 06:33:22 -0400 (EDT) Received: from web2 ([10.202.2.212]) by compute6.internal (MEProxy); Tue, 07 Aug 2018 06:33:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=YPYY6hYR05gc+Qeid FP6nA/idX8CxQd+ov90doOlJMQ=; b=zK/QwcZO9TKxBQ8MLGXXfp1jKbT4QqhMW /myu1HkfoEyVlhgxQXSzb4h1fcXD6XruPkoLC/LRLOBn9Z5ky1PaLPiZwcOCmYKW TTrED2TDJ7FZNEeo7RVi/6jKZrQJHQAzBsi2yu0eP4vaYvNu8n3WWWVoO6+4jGXE jd4BMwW9spE/KN5lgG+GB3aY7CCgA6HVjPcWIreBqPs6cmUprGp482ZDPvcYlEfZ r0OyTsNbKkgPq1i3lh80jAwn1E5D856uU/1TcbqNkh62ePhJBFG/npHeWNJMo76J JqtiUkxdGJ9+YI3Bn1MTb3lgcZCvrTrT1AmAJtWPs0CABXCkhp7UQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=YPYY6h YR05gc+QeidFP6nA/idX8CxQd+ov90doOlJMQ=; b=uMPaUBXm9zCW/2zshnaO7/ yBkuBJwocDtx3XH3SN0ax2Q0sYkkbJ0rslJs9aNz2F/ZD+cGbC1Kf10kOZCu4Ebx 0k+11HTC2S5Fw1QERxllmjGQEH7dxoqUFLunvUBYUZyjw44eWPl7/No6w3ugifGo zlgKrcp0WxDi/oSb0tNLzg0jlC3qMa6rcp58AhYHCCDdA6lULJVzNo1u8WaRJ3dh POn7O5dvAVx2pN1lchOclbA8GnJwmTV/PKRqGwMuJ6Xt9sXQUNlKekXIon51/mXB A/IITq0dw5J36UYrJzlVX8PEi+Y94OlcHP2i3eq4liPvbDhesUnb7ck4K4ViPRkg == X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 00837621CB; Tue, 7 Aug 2018 06:33:21 -0400 (EDT) Message-Id: <1533638001.2826131.1466041392.5CBBBF9C@webmail.messagingengine.com> From: Bron Gondwana To: Alexey Melnikov , extra@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_153363800128261312" X-Mailer: MessagingEngine.com Webmail Interface - ajax-2be8cd1b References: <1532034526.1792463.1446606328.14CB8B22@webmail.messagingengine.com> <6831c19f-849b-409e-bf55-0f57ae985d48@sloti22d1t06> In-Reply-To: Date: Tue, 07 Aug 2018 20:33:21 +1000 Archived-At: Subject: Re: [Extra] Call for adoption and directly to WGLC - draft-brandt-imap-replace X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2018 10:33:26 -0000 This is a multi-part message in MIME format. --_----------=_153363800128261312 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Tue, Aug 7, 2018, at 20:21, Alexey Melnikov wrote: > On 03/08/2018 01:46, Bron Gondwana wrote: >> I'm assuming the lack of discussion here is because everyone's >> already basically happy with this draft as is! The two weeks is >> up, and I've adopted the document into the group and then directly >> to WGLC.>> >> Stuart, if you could please upload a draft-ietf-extra-imap-replace- >> 00.>> >> Also idnits complained about the [UID] in the sample equivalent IMAP >> commands:>> >> 1. APPEND 2. [UID] STORE +FLAGS.SILENT \DELETED 3. UID EXPUNGE >>>> >> I would probably just take the brackets off the UID. The "same >> effect" will still mean the same thing!> On this one thing: I don't particularly care one way or another, but > idnits complaining doesn't mean that this needs to be fixed. It is Ok > just to state in the shepherding writeup (when it needs to be written) > that some reported nits are not real problems.> I already did an initial write-up that basically says that... :) > >> Cheers, >> >> Bron. >> >> On Fri, Jul 20, 2018, at 07:08, Bron Gondwana wrote: >>> The draft is here: >>> >>> https://datatracker.ietf.org/doc/draft-brandt-imap-replace/ >>> >>> There's already been a bunch of discussion on the list, and the >>> document appears to be in good shape. I'd like to kill two birds >>> with one stone, so I'm asking if there are any objections to >>> either of:>>> >>> a) adopting this document into this working group >>> b) taking version -02 to working group last call >>> >>> I'll give two weeks for this. If there are no objections given, I >>> intend to adopt the document and then immediately make a working >>> group last call, which will be an additional period of 3 weeks.>>> >>> If you're happy to adopt, but think there's more discussion required >>> - please do say, happy to do that too.>>> >>> Kind regards, >>> >>> Bron. >>> >>> -- >>> Bron Gondwana, CEO, FastMail Pty Ltd >>> brong@fastmailteam.com >>> >>> >> >> -- >> Bron Gondwana, CEO, FastMail Pty Ltd >> brong@fastmailteam.com >> >> >> >> >> _______________________________________________ Extra mailing list >> Extra@ietf.org https://www.ietf.org/mailman/listinfo/extra >>> > _________________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_153363800128261312 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"



On Tue, Aug 7, 2018, at 20:21, Alexey Melnikov wrote:

On 03/08/2018 01:46, Bron Gondwana wrote:

I'm assuming the lack of discussion here is because everyone's already basically happy with this draft as is!  The two weeks is up, and I've adopted the document into the group and then directly to WGLC.

Stuart, if you could please upload a draft-ietf-extra-imap-replace-00.

Also idnits complained about the [UID] in the sample equivalent IMAP commands:

      1. APPEND
      2. [UID] STORE +FLAGS.SILENT \DELETED
      3. UID EXPUNGE

I would probably just take the brackets off the UID.  The "same effect" will still mean the same thing!
On this one thing: I don't particularly care one way or another, but idnits complaining doesn't mean that this needs to be fixed. It is Ok just to state in the shepherding writeup (when it needs to be written) that some reported nits are not real problems.


I already did an initial write-up that basically says that... :)


Cheers,

Bron.

On Fri, Jul 20, 2018, at 07:08, Bron Gondwana wrote:
The draft is here:


There's already been a bunch of discussion on the list, and the document appears to be in good shape.  I'd like to kill two birds with one stone, so I'm asking if there are any objections to either of:

a) adopting this document into this working group
b) taking version -02 to working group last call

I'll give two weeks for this.  If there are no objections given, I intend to adopt the document and then immediately make a working group last call, which will be an additional period of 3 weeks.

If you're happy to adopt, but think there's more discussion required - please do say, happy to do that too.

Kind regards,

Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd



--
  Bron Gondwana, CEO, FastMail Pty Ltd




_______________________________________________
Extra mailing list
Extra@ietf.org
https://www.ietf.org/mailman/listinfo/extra

_______________________________________________
Extra mailing list

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

--_----------=_153363800128261312-- From nobody Tue Aug 7 19:45:33 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90D091274D0 for ; Tue, 7 Aug 2018 19:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=aol.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 HHRugHATlifk for ; Tue, 7 Aug 2018 19:45:31 -0700 (PDT) Received: from sonic307-4.consmr.mail.bf2.yahoo.com (sonic307-4.consmr.mail.bf2.yahoo.com [74.6.134.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 C7FFD12426A for ; Tue, 7 Aug 2018 19:45:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1533696329; bh=Sj/+qN8XRP2jFFvFl9EAclRZ193DP1mGd0h+3qGILtc=; h=Date:From:To:Subject:References:In-Reply-To:From:Subject; b=R9QZ/ZO93CoUnaUZOLOMiSpabKFgtaRi626In/sVFPkx4VC8wp/ltJDEyJbNUuBUBoQR+NrcR0m4OmmMh8dum5bA8AxYzAGEBD3ffXFJ8RWQNqpblhmsTR63JMWtEe/zO4h0uYXilmd98dDum+8pQADnK3pRuIAAE+P4SKiSEDu9Oc8KJDcCf+f9nviu8EnaQIxIv2rtB8Orcy3q9QVDn833G5ITREGE62kr5iFKZlMxHMX1X0nlC1DX7pNjGltRr0pnlrFlF2HoLfQc2V1Gc+oqiDTZkX6DOnU8FGCRBBvCPjPVbasoIWQxMklnsmXQ74O9CPiIac172iIei4MxsA== X-YMail-OSG: 0u7YZpEVM1k6nB3bGljNqctv8NcSEqfeXIFk_AJWgPNtTZ7VaH6GYdER1Agzt42 MzR4R4tldtq7TCWG1tSxCcgrhdHmdRBFG3jjKOkSlo1dI_mUoVnj4AiqRTMYws_vmRFc2yNSUqqf C_mZ4HhvpheX4f4YpxSHDqZu__nNueSbEGqMfkNCud4z51m_sVj5ZGoxjllKt7y.0ltDysBM76xp k_viDrJU2rXwu7E46cfrSBXWktZA8tr3Rujrjsis1sNuElE6icl1sOMh5f79bE2BDJQXrV1_memz SK93FrvyL86twIhiAfftvhlBGteq5A._QP7pFQzo4JpdwU1uv7LZqvGufqoqTHXFKqlkzsFxs67v TDpmg20umv5zOSD7ul7SzFdxGvTYbPWcnlXgMMtU.HplmjFMfG4TWp3b9FokRPoPmi6zLqGc66BP UdpEmtgvd0u_CBSwegVTBJD14OiWCqzo.IFINusVBrtPemzhynhyJKO477ERHFJZZNdidgUuPIJ2 KBEwCSaCuUlIq9gQ7.sOqVZbgj0.5jazo5f3OzN.P19OIbnwAdPD3jLt_MOqO39gOiubwDTs.TD2 Ny.xhlSFd9VrMf1tJ7N227f6eokFJf4t8YriXb6NE5ieLSSs6KKcD9bVNDtx_EUy9l4sQxnPjWXi dxvigW3VNBwa7MrwKakYENdqvQXlAa8PL91YIZiqCjC0VYUMLtNWO4ECMPSiS7ygT7aCFbr3i4r9 Ea.SPTkitxA5cKbWR__Ub4yX4JITmczmvMbBzLfys31GdHOUCISkbRsO5rSRFZGZ8fyqQsE3hRDH .b6IDMhu45cOISslCa9YZZeFrMc25cT4wYS3VjJqxyvRTU0RRxEKlkmTvFoh1vgv4hS.QL0RZypZ pDXWgzM4u_a.yET9J0tvvbkjXmDUL1Cr_XDwtUFG0g_umAyDMXtMCbH4_WE0M3M2s4lzzgEe1lXI KDe09kAodCMpqcmADW6OCrd5Jq46ySMc0T1OcNjlCz2xKPep4lcU- Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.bf2.yahoo.com with HTTP; Wed, 8 Aug 2018 02:45:29 +0000 Received: from pool-70-106-225-231.clppva.fios.verizon.net (EHLO [192.168.1.13]) ([70.106.225.231]) by smtp401.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 3c55b2b7f65bda131c21b64812592ffa for ; Wed, 08 Aug 2018 02:45:27 +0000 (UTC) Message-ID: <5B6A592B.4050909@aol.com> Date: Tue, 07 Aug 2018 22:44:59 -0400 From: Stuart Brandt User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: extra@ietf.org References: <1532034526.1792463.1446606328.14CB8B22@webmail.messagingengine.com> <6831c19f-849b-409e-bf55-0f57ae985d48@sloti22d1t06> In-Reply-To: <6831c19f-849b-409e-bf55-0f57ae985d48@sloti22d1t06> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Extra] Call for adoption and directly to WGLC - draft-brandt-imap-replace X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2018 02:45:32 -0000 Bron - Sorry for the delay in responding. I have an update to draft-brandt-imap-replace-03 that covers Chris Newman's July 2nd feedback about APPENDUID needing to be untagged based on the interaction with UIDPLUS as discussed in section 4.3. Two quick questions first, though: 1) I would like to cover interaction between REPLACE and OBJECTID. Should I wait a bit longer on OBJECTID, or is now a good time to add something in REPLACE? 2) The section that idnits complained about matches a similar example in section 3.3 of RFC6851 (MOVE). Is this precedent enough to keep it in? - Stuart On 8/2/2018 8:46 PM, Bron Gondwana wrote: > I'm assuming the lack of discussion here is because everyone's already > basically happy with this draft as is! The two weeks is up, and I've > adopted the document into the group and then directly to WGLC. > > Stuart, if you could please upload a draft-ietf-extra-imap-replace-00. > > Also idnits complained about the [UID] in the sample equivalent IMAP > commands: > > 1. APPEND > 2. [UID] STORE +FLAGS.SILENT \DELETED > 3. UID EXPUNGE > > > I would probably just take the brackets off the UID. The "same effect" > will still mean the same thing! > > Cheers, > > Bron. > > On Fri, Jul 20, 2018, at 07:08, Bron Gondwana wrote: >> The draft is here: >> >> https://datatracker.ietf.org/doc/draft-brandt-imap-replace/ >> >> There's already been a bunch of discussion on the list, and the >> document appears to be in good shape. I'd like to kill two birds with >> one stone, so I'm asking if there are any objections to either of: >> >> a) adopting this document into this working group >> b) taking version -02 to working group last call >> >> I'll give two weeks for this. If there are no objections given, I >> intend to adopt the document and then immediately make a working group >> last call, which will be an additional period of 3 weeks. >> >> If you're happy to adopt, but think there's more discussion required - >> please do say, happy to do that too. >> >> Kind regards, >> >> Bron. >> >> -- >> Bron Gondwana, CEO, FastMail Pty Ltd >> brong@fastmailteam.com >> >> > > -- > Bron Gondwana, CEO, FastMail Pty Ltd > brong@fastmailteam.com > > > > > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra > From nobody Tue Aug 7 21:08:22 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 238EA130DDD for ; Tue, 7 Aug 2018 21:08:21 -0700 (PDT) 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=joha7AYB; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=aHc+qz+d Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5PVE1_KX7bAW for ; Tue, 7 Aug 2018 21:08:20 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3F3C1286E3 for ; Tue, 7 Aug 2018 21:08:19 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 2EB9121B0B for ; Wed, 8 Aug 2018 00:08:19 -0400 (EDT) Received: from imap22 ([10.202.2.72]) by compute6.internal (MEProxy); Wed, 08 Aug 2018 00:08:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=fo6xbj2NK4I+p1fVEOmz1Y6FGaE0dHY3reWQnKYhq gA=; b=joha7AYBqh3Ts6TaUayIzk2y/7gsB9Qh3KkxjiOsar9spETwFjVj9qLcS mbLT1qdF/w2KcktNPTzlJ7j6W76xjGkG8mz3kHPleLZfLzGiQjvhGp193b9n/RLr CUVY9UFTrDRKaArqQLTqgAMxkhJ6zxrbqZYHgoKX+FTLSp6v1eYr8C5qkWgjpSFY 8CF65k1BbGakP5imIj+0jUcchNCoZe0dVWrn6Hujp0WjJOMlGEaWo6ldr5OzgK4s NaZ2MjJ4Ehfo5c/C9ACJxQUE7eGGYbwonC8kiDpu1s01y0gsANi2CxLpy5gUiTzW j2d0Hi+wzMsmCaO/zUhraM7lTVejg== 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-sender:x-me-sender :x-sasl-enc; s=fm3; bh=fo6xbj2NK4I+p1fVEOmz1Y6FGaE0dHY3reWQnKYhq gA=; b=aHc+qz+dH2lCA7b7jyOUgOGC6mo2ywsS8/g3iE0L1OxPpYnztbZu2Jfev EeLd3NnMgqaIEVFsb7tec8HrCtjZujGt86/2NW+cOe4lR3CBzlpFRxbn8LTRQI/k CtZQVyzkLR3VyhquGHb4ROGnacJxhjh93Wqs2fQfUgzjryiycKjkSQ6xAuCbl+jQ dQWH2P3O+7g3FYcLSTVA79eIRpMBQ1zh32/TtI77Pfzaxr8Uecnvgn5Mbr/RQHB2 HsQMNEIi7q8nqCpt0uv6/x6feJPVxtldvDpkusGkD+xDf+mG84rJvZiE3FKTxXXG sxuPgMVW3gKXkaNjQxkjTiZRdivUA== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 501) id C0553EE93; Wed, 8 Aug 2018 00:08:18 -0400 (EDT) Message-Id: User-Agent: Cyrus-JMAP/3.1.5-137-g843a534-fmnext-20180801v1 x-jmap-identity-id: 56629417 In-Reply-To: <5B6A592B.4050909@aol.com> References: <1532034526.1792463.1446606328.14CB8B22@webmail.messagingengine.com> <6831c19f-849b-409e-bf55-0f57ae985d48@sloti22d1t06> <5B6A592B.4050909@aol.com> Date: Wed, 08 Aug 2018 00:08:18 -0400 From: Bron Gondwana To: extra@ietf.org Content-Type: multipart/alternative; boundary=bdf24e1114ab46a28d2350568e332b48 Archived-At: Subject: Re: [Extra] =?utf-8?q?Call_for_adoption_and_directly_to_WGLC_-_draft?= =?utf-8?q?-brandt-imap-replace?= X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2018 04:08:21 -0000 --bdf24e1114ab46a28d2350568e332b48 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Wed, Aug 8, 2018, at 12:45, Stuart Brandt wrote: > Bron - >=20 > Sorry for the delay in responding. >=20 > I have an update to draft-brandt-imap-replace-03 that covers Chris=C2=A0= > Newman's July 2nd feedback about APPENDUID needing to be untagged base= d=C2=A0 > on the interaction with UIDPLUS as discussed in section 4.3. >=20 > Two quick questions first, though: > 1) I would like to cover interaction between REPLACE and OBJECTID.=C2=A0= > Should I wait a bit longer on OBJECTID, or is now a good time to add=C2= =A0 > something in REPLACE? It's fine to add something to REPLACE now I'd say.=C2=A0 OBJECTID is pre= tty much ready, and it will be fine to update the shepherding writeup to= say that REPLACE depends on OBJECTID so should be delayed behind it. > 2) The section that idnits complained about matches a similar example = in=C2=A0 > section 3.3 of RFC6851 (MOVE). Is this precedent enough to keep it in?= Yep, that's fine too - especially considering Alexey's comment that idni= ts isn't the be all and end all of things! Cheers, Bron. -- =C2=A0 Bron Gondwana, CEO, FastMail Pty Ltd =C2=A0 brong@fastmailteam.com --bdf24e1114ab46a28d2350568e332b48 Content-Type: text/html Content-Transfer-Encoding: quoted-printable


On Wed, Aug 8, 2018, at 12:45, Stuart Bran= dt wrote:
Bron -

Sorry for the delay = in responding.

I have an update to draft-brandt-imap-repl= ace-03 that covers Chris 
Newman's July 2nd feedback about APPENDUID needing to be untagged base= d 
on the interaction wi= th UIDPLUS as discussed in section 4.3.

Two quick questio= ns first, though:
1) I would = like to cover interaction between REPLACE and OBJECTID. 
<= div style=3D"font-family:Arial;">Should I wait a bit longer on OBJECTID,= or is now a good time to add 
something in REPLACE?

It's fine to ad= d something to REPLACE now I'd say.  OBJECTID is pretty much ready,= and it will be fine to update the shepherding writeup to say that REPLA= CE depends on OBJECTID so should be delayed behind it.

2) The section that idnit= s complained about matches a similar example in 
section 3.3 of RFC6851 (MOVE). Is this preceden= t enough to keep it in?

Yep, that's fine too= - especially considering Alexey's comment that idnits isn't the be all = and end all of things!

Cheers,

Bron.

=
--
  Bro= n Gondwana, CEO, FastMail Pty Ltd
&nbs= p; brong@fastmailteam.com


--bdf24e1114ab46a28d2350568e332b48-- From nobody Thu Aug 9 14:55:50 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63685130F86 for ; Thu, 9 Aug 2018 14:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cz9H7TzujL7n for ; Thu, 9 Aug 2018 14:55:46 -0700 (PDT) Received: from mail-yw1-xc34.google.com (mail-yw1-xc34.google.com [IPv6:2607:f8b0:4864:20::c34]) (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 31787130F27 for ; Thu, 9 Aug 2018 14:55:46 -0700 (PDT) Received: by mail-yw1-xc34.google.com with SMTP id z143-v6so6811028ywa.7 for ; Thu, 09 Aug 2018 14:55:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jrKxy05YHp7Q5jesCvRSSoecftITAenPCBjhLpLx46U=; b=Tc8TqIcsXMmjLKoq8pOq32hJpXKc+94HDvLEiBrQh/wjO4BtVZsRb15JpDeFgnO+Ec q/Z1jG6MP/aPq5RN0S4BPRjwZbm3eNwqODm4/mTYthATmJiQeZ73sHypq+WYcKZYJrYu ad0dXwViroZ0Qns/nqXGC/gwl3clcovEcgpCY99481ad+xIGTaynZHhWw0+IGjrjloIu Oqx5dNVrrSzWt/tftgUkQtBFjwV9m4q596QW0ZrhPdmjTtTFAk1pdko4HAPsstPKwV4y TXPyLkZJCT3GDWsjexNRh5Lga//BEW40Z460WC0uGEDNPpJnDhrbUywDsp3QOYMhK/DT iKaA== 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=jrKxy05YHp7Q5jesCvRSSoecftITAenPCBjhLpLx46U=; b=lJtnyXdoCju8FixYzZ47L1RlINcIGG5gQfQ1oXUnUIRBKVjgu9UNAs04PxhooIWXkk WpthNOA0oRtwys4/DV0IltbMlrLkkWhkUnqRduxKeXnZNUh0vqdshCY9TsMRWUGjdfuz WZeixgEGoB11kBHx5/U04iV/FMODYwo3ZLn5AnVnvASzED1cJE/5od93dNQB6tKsF1Pg 3FIKwWDvDmqtgqSVUFYL8ENxDZLwqAZBBGGLL9Cj+SIInXsidSV633f0XlnzzrPmoU5R Pqpy5AzqbRb9pGxaeiPnHXxh8FZyo+7lcjfeRALUzHxoqQpyMvSLOiF+sbPijY/S5ltq ybQQ== X-Gm-Message-State: AOUpUlG5XIojEWE/9fIHRbHO8HLv3bYw+iJ0fQDsG4VMy2SJ8lMYlqQO kSsYE6GgjZrl6fwhPXewIpiQzulU1azbSUQIfxgu X-Google-Smtp-Source: AA+uWPzHQrY1X1LN+UnxVFqRaYfX/AiOZC5LkjhEuLCpNO1wy1cqu1tKkCyp6VcphO4B3RsDG8W3qLQi571QEPBpgqo= X-Received: by 2002:a0d:e501:: with SMTP id o1-v6mr2149276ywe.409.1533851744695; Thu, 09 Aug 2018 14:55:44 -0700 (PDT) MIME-Version: 1.0 References: <1dc71d96-c3be-4ae3-7644-13f7accecace@linuxmagic.com> <79A4C4F2-E4BA-4B4C-B8E0-295B7216EC9C@oracle.com> <0D7A6217-3207-4F75-8BC6-B0E660EE7D36@oracle.com> In-Reply-To: <0D7A6217-3207-4F75-8BC6-B0E660EE7D36@oracle.com> From: Brandon Long Date: Thu, 9 Aug 2018 14:55:32 -0700 Message-ID: To: Chris Newman Cc: Michael Peddemors , extra@ietf.org Content-Type: multipart/alternative; boundary="000000000000626823057307b0ca" Archived-At: Subject: Re: [Extra] CLIENT ID - Next Steps - General Discussion Overview X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2018 21:55:49 -0000 --000000000000626823057307b0ca Content-Type: text/plain; charset="UTF-8" On Fri, Aug 3, 2018 at 2:02 PM Chris Newman wrote: > On 2 Aug 2018, at 16:37, Brandon Long wrote: > > > > Note that PLAIN-CLIENTTOKEN that gmail still offers for MSA/POP/IMAP > > is a > > form of this in SASL as well, something that we worked on with several > > clients (and intended to be taken for standardization) before deciding > > to > > go the OAUTH route that led to OAUTHBEARER eventually. > > > > Just adding the token into the sasl data seemed pretty > > straightforward. > > > > (not sure if it was mentioned in the presentation or not) > > Do you have a spec for PLAIN-CLIENTTOKEN? > It was basically: Mechanism: PLAIN-CLIENTTOKEN Payload: [authzid] UTF8NUL authcid UTF8NUL passwd UTF8NUL client-token Example1: \0name\0passwd\0clienttoken Example2: authzid\0name\0passwd\0clienttoken SMTP: S: 220 smtp.example.com ESMTP service ready C: EHLO client.example.com S: 250 smtp.example.com says hello S: 250-ENHANCEDSTATUSCODES S: 250-8BITMIME S: 250-AUTH PLAIN PLAIN-CLIENTTOKEN C: AUTH PLAIN-CLIENTTOKEN YXV0aGNpZO+/vXBhc3N3ZO+/vXNlc3Npb25pZA== S: 235 2.7.0 Authentication successful IMAP: S: * OK example.com IMAP4rev1 C: c CAPABILITY S: * CAPABILITY IMAP4 IMAP4rev1 AUTH=PLAIN AUTH=PLAIN-CLIENTTOKEN S: c OK Completed C: a AUTHENTICATE PLAIN-CLIENTTOKEN YXV0aGNpZO+/vXBhc3N3ZO+/vXNlc3Npb25pZA== S: a OK Success I hear complaints that OAUTH ends up being not interoperable in a > scalable way because each client vendor has to perform a manual > registration step with each service provider. I haven't looked at the > topic in detail so I may misunderstand something, but that's the > impression I have. It would be nice to have a standard that actually > interoperates in a scalable fashion. > Yes, that's true, or at least was when we were getting OAUTHBEARER through the RFC process. Our identity folks were the ones handling the actual OAUTH specs, and I haven't paid much attention recently. It looks like dynamic client registration is now an RFC: https://tools.ietf.org/html/rfc7591 But discovery is still in draft, though active: https://tools.ietf.org/html/draft-ietf-oauth-discovery-10 I don't know how wide spread adoption is yet, or even if Google has adopted it. Brandon --000000000000626823057307b0ca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri= , Aug 3, 2018 at 2:02 PM Chris Newman <chris.newman@oracle.com> wrote:
On 2 Aug 2018, at 16:37, Brandon Long wrot= e:
>
> Note that PLAIN-CLIENTTOKEN that gmail still offers for MSA/POP/IMAP <= br> > is a
> form of this in SASL as well, something that we worked on with several=
> clients (and intended to be taken for standardization) before deciding=
> to
> go the OAUTH route that led to OAUTHBEARER eventually.
>
> Just adding the token into the sasl data seemed pretty
> straightforward.
>
> (not sure if it was mentioned in the presentation or not)

Do you have a spec for PLAIN-CLIENTTOKEN?

It was basically:
Mechanism: PLAIN-CLIENTTOKEN
=
Payload: [authzid] UTF8NUL authcid UTF8NUL passwd UTF8NUL cl= ient-token

Example1: \0name\0passwd\0clienttoken
Example2: authzid\0name\0passwd\0clienttoken

<= /div>
SMTP:

S: 220 smtp.example.c= om ESMTP service ready

C: EHLO = client.example.com

S: 250 smtp.ex= ample.com says hello

S: 250-ENHANCEDSTATUSCODES

S: 250-8BITMIME

S= : 250-AUTH PLAIN PLAIN-CLIENTTOKEN

C: AUTH PLAIN-CLIENTTOKEN YXV0aGNpZO+/= vXBhc3N3ZO+/vXNlc3Npb25pZA=3D=3D
S: 235 2.7= .0 Authentication successful


IMAP:

S: * OK = example.com IMAP4rev1

C: c CAPABILITY

S: * CAPABILITY IMAP4 IMAP4r= ev1 AUTH=3DPLAIN AUTH=3DPLAIN-CLIENTTOKEN

S: c OK Completed

C: a AUTHEN= TICATE PLAIN-CLIENTTOKEN YXV0aGNpZO+/vXBhc3N3ZO+/vXNlc3Npb25pZA=3D=3D

S: = a OK Success


I hear complaints that OAUTH ends up being not interoperable in a
scalable way because each client vendor has to perform a manual
registration step with each service provider. I haven't looked at the <= br> topic in detail so I may misunderstand something, but that's the
impression I have. It would be nice to have a standard that actually
interoperates in a scalable fashion.

Ye= s, that's true, or at least was when we were getting OAUTHBEARER throug= h the RFC process.=C2=A0 Our identity folks were the ones handling the
actual OAUTH specs, and I haven't paid much attention recently.

It looks like dynamic client registration is now an RFC:=C2=A0= https://tools.ietf.org/html= /rfc7591
But discovery is still in draft, though active:=C2= =A0ht= tps://tools.ietf.org/html/draft-ietf-oauth-discovery-10

<= /div>
I don't know how wide spread adoption is yet, or even if Goog= le has adopted it.

Brandon=C2=A0
--000000000000626823057307b0ca-- From nobody Thu Aug 9 15:21:25 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 991A5130E25 for ; Thu, 9 Aug 2018 15:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.509 X-Spam-Level: X-Spam-Status: No, score=-17.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KB5uu9i9m7y5 for ; Thu, 9 Aug 2018 15:21:20 -0700 (PDT) Received: from mail-yw1-xc2d.google.com (mail-yw1-xc2d.google.com [IPv6:2607:f8b0:4864:20::c2d]) (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 6983C130DEA for ; Thu, 9 Aug 2018 15:21:20 -0700 (PDT) Received: by mail-yw1-xc2d.google.com with SMTP id v197-v6so6915807ywg.3 for ; Thu, 09 Aug 2018 15:21:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TIyT8zxUHiqIESiyVxrs3EcgpeNrF2xro2NDkn+HEb0=; b=wTlOiOeuVglDVy7T8ssbmep3Xqdl0ToZbZJng11kSZDR1vKqGH1qtLf87bLD1lbmis bCYrx3VUtrFlMIbEWK+LkdSCyCYYdWWIZIss1PBRAWo6ixXQO+5W/ZLNVa+JSXzLjzzA xlOINBnWXXFxgp2cwfNnR95yTSyyRz+LEKQv4xChK4pkfxjzVG/QxZVQugWwcQaMhdt9 hZ1NI0lk6CvQREhh9uJ+KwZFU/+FOXDtw1ZziH/NSCHrRCGuRuhu4k4KIeKJvyj1PCKf C9tCet5hz/PvoEl9GOZ5i6BBp3hfu35awPbf7JY4oCQnRvDK+sj7BihvrqP+2QP/h82k WGxw== 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=TIyT8zxUHiqIESiyVxrs3EcgpeNrF2xro2NDkn+HEb0=; b=IGZ9SDbeusWBmzrjwCqB1MpdRsAGYb9y98ARiAnIAFeYkvwnM9gbf7FzbYnAHVel7o 6FMBsRCFjfWfFJHWb78LmEMn56F5EMGJnYk9oauqPAIw6RusuDaOGcTE7VMF/tFmn8Bl byiqh9C1UGn+EvQ9Hms9tiDjnUCBqY6ljDS45RLjhzoldqIDgXQlOwWm+/+wzPj1h0nJ 81P1ARyt9E6FTFlG4CNKA9RniJ0f6wohojdf6HV+Kx4RbABrY1BAEA3A08cCqYXYyqIn dR00fF1QnaiHdaCSSedLlyz5A+xAT7YG26vsvqGEx/p4VVN8io/qZxEskffjGv25SD7G mCvw== X-Gm-Message-State: AOUpUlE1G1FPChOgdI1lsXYSYXPBA0CFkoRPUToHycJGiM/qvBU07Fu/ QasDj/6+FaedzVKNEmQ3RsLtxMaYqr3hEv6pAOGBfTk= X-Google-Smtp-Source: AA+uWPy1348wozpzFpOukjXz6pQVe8VKDpfb8q7sjkqC1NrGCukEk7OLJFsuwjpUxY4klmp0CygYiSJWJ0eLNmU25KM= X-Received: by 2002:a81:79c6:: with SMTP id u189-v6mr2280411ywc.255.1533853278967; Thu, 09 Aug 2018 15:21:18 -0700 (PDT) MIME-Version: 1.0 References: <1dc71d96-c3be-4ae3-7644-13f7accecace@linuxmagic.com> <79A4C4F2-E4BA-4B4C-B8E0-295B7216EC9C@oracle.com> <8d0f565e-54d7-a44d-1527-8c42ee09f44f@linuxmagic.com> In-Reply-To: <8d0f565e-54d7-a44d-1527-8c42ee09f44f@linuxmagic.com> From: Brandon Long Date: Thu, 9 Aug 2018 15:21:07 -0700 Message-ID: To: Michael Peddemors Cc: extra@ietf.org Content-Type: multipart/alternative; boundary="000000000000d5529f0573080b6b" Archived-At: Subject: Re: [Extra] CLIENT ID - Next Steps - General Discussion Overview X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2018 22:21:24 -0000 --000000000000d5529f0573080b6b Content-Type: text/plain; charset="UTF-8" On Fri, Aug 3, 2018 at 7:44 AM Michael Peddemors wrote: > Thanks Brandon, for weighing in on this.. > > And it is good that we seem to have consensus on the following: > > * Concept of CLIENTID is worthwhile to pursue > * Standardization is also worthwhile > > However, again we should point out. > > It isn't that doing this (coding) in a SASL is difficult, we already > examined this, and found that it limited the scope and abilities that > CLIENTID offers. By presenting this at the protocol level, we can > always pass it to a SASL that wishes to implement it, but by doing it at > the protocol layer it makes it available to all SASL methods that might > be developed/extended in the future. > And some of those SASL methods already include this type of information. And if it were useful enough, then it would seem likely to become a standard part of any future SASL methods. AS well, no use creating a standard that isn't going to see adoption, > and our team looked at many of the client implementations (opensource) > as well as several other IMAP server implementations, and realized that > it is easier to port the protocol implementation, than SASL's across the > board. > > And in some cases, what you want the CLIENTID to interact with, is only > available at the protocol level, whereas the SASL implementations might > not have access. > Admittedly, we have full access to our stack, so these things are not complications we had to deal with. In fact for us, handling it at the sasl layer meant a single impl across protocols, as opposed to protocol specific handlers. Adding the ID as a token to retrieve from the sasl impl to hand to our auth system was not complicated, and we could have done other things with it if we'd had a use. CLIENTID is more than just authentication, as pointed out several times > already, which is why we call it 'two and 1/2' factor authentication. > The list of examples of where else you can use this seems just as easily to apply to the regular IMAP ID command, modulo the fact that the ID RFC says DON'T do that, and that the ID command as a k/v list has both more data and less consistency. We did consider some poor mans access control and MDM based on the ID, but it was never a high enough priority for the benefit. I don't know if vendors have that ask or not. Today we do offer some of that based on the client-token in the OAUTHBEAER mechanism, because of the registration information, the potential to limit / abuse check creating new tokens, and because all external access across GSuite is by OAUTH2. This means there isn't some special case for IMAP, and tools which touch multiple APIs and sources can be listed and access controlled singly. Your use case list also seems to imply that the CLIENTID would have a structured form, where you can tease apart things to apply those rules, I don't think your draft does that well. In particular, I don't see how the client-id-type is useful. Brandon > The IMAP protocol can handle the verification/sanity and interact with > external systems, including identifying attack heuristics, and it will > be available to any SASL which is interested in using it in the > authentication layer, including legacy SASL and other authentication > schemes. > > -- Michael -- > > PS, we are still moving forward with implementation at this level, and > publishing patches for email clients and other opensource IMAP > implementations based on our model, so it would be nice to see > standardization around this model. > > So far the only change to our plans has been taking into account the > opinions of others that we should not use the CID acronym, and consider > using CLIENTID/DEVICEID instead. > > Trying to reach a consensus on opinions on this in the mean time. > > > > > > > > > On 18-08-02 04:37 PM, Brandon Long wrote: > > (catching up on email from vacation) > > > > On Mon, Jul 23, 2018 at 3:53 PM Chris Newman > > wrote: > > > > On 23 Jul 2018, at 11:27, Michael Peddemors wrote: > > > > > > * It was questioned, is the proper place for this in a SASL > > mechanism, > > > vs in the protocol itself, and while our development work and > > > research > > > show that the advantages for a 'device identifier' to be part > > of the > > > protocol/syntax rather than a SASL, and our assertion this will > > help > > > in the adoption curve in the industry, it was one of the > strongest > > > points of contention, with the arguments for SASL, was one SASL > can > > > apply to many services, and thus if that argument holds, then > maybe > > > the SASL or a security group would be better for this. We > > intend to > > > argue against this, but the topic alone is key to discussions, > > so it > > > requires a separate thread to discuss this. > > > > We have a case where client-id facilities (device-specific token, a > > subset of the client-id problem) were deployed in production using > > custom SASL mechanisms on our server and custom changes to a client. > So > > I assert this is a proof-of-concept that SASL is deployable for > > client-id, that it can solve the problem for multiple protocols with > > one > > specification and shared code (Submission & IMAP), that it comes > > with an > > extensible capability model for interoperability, and does not break > > interoperability with unmodified clients. Furthermore, no custom > > changes > > were required to our server to support this since we have a SASL > > abstraction API we support. That means our customers could deploy a > > SASL-based mechanism without requiring a server upgrade, thus > > significantly simplifying deployment. We do not have an API for IMAP > > commands and have no intention of providing one, so our customers > will > > not be able to deploy client ID unless it is SASL or there is an IETF > > rough consensus around a non-SASL client-id model for > > submission+imap(+pop+managesieve+jmap+etc). > > > > I consider it unfortunate this use case involved proprietary SASL > > mechanisms so I'd support a standardized mechanism, but we have > running > > code showing a SASL approach is deployable and backwards compatible. > > > > I'm aware of another deployed use of client-id like facilities for > push > > notifications. > > > > > > Note that PLAIN-CLIENTTOKEN that gmail still offers for MSA/POP/IMAP is > > a form of this in SASL as well, something that we worked on with several > > clients (and intended to be taken for standardization) before deciding > > to go the OAUTH route that led to OAUTHBEARER eventually. > > > > Just adding the token into the sasl data seemed pretty straightforward. > > > > (not sure if it was mentioned in the presentation or not) > > > > Brandon > > > > -- > "Catch the Magic of Linux..." > ------------------------------------------------------------------------ > Michael Peddemors, President/CEO LinuxMagic Inc. > Visit us at http://www.linuxmagic.com @linuxmagic > A Wizard IT Company - For More Info http://www.wizard.ca > "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. > ------------------------------------------------------------------------ > 604-682-0300 Beautiful British Columbia, Canada > > This email and any electronic data contained are confidential and intended > solely for the use of the individual or entity to which they are addressed. > Please note that any views or opinions presented in this email are solely > those of the author and are not intended to represent those of the company. > > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra > --000000000000d5529f0573080b6b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri= , Aug 3, 2018 at 7:44 AM Michael Peddemors <michael@linuxmagic.com> wrote:
Thanks Brandon, for weighing in on this..

And it is good that we seem to have consensus on the following:

* Concept of CLIENTID is worthwhile to pursue
* Standardization is also worthwhile

However, again we should point out.

It isn't that doing this (coding) in a SASL is difficult, we already examined this, and found that it limited the scope and abilities that
CLIENTID offers.=C2=A0 By presenting this at the protocol level, we can always pass it to a SASL that wishes to implement it, but by doing it at the protocol layer it makes it available to all SASL methods that might be developed/extended in the future.

And some of t= hose SASL methods already include this type of information.=C2=A0 And if
it were useful enough, then it would seem likely to become a standa= rd part of any future
SASL methods.

AS well, no use creating a standard that isn't going to see adoption, <= br> and our team looked at many of the client implementations (opensource)
as well as several other IMAP server implementations, and realized that it is easier to port the protocol implementation, than SASL's across th= e
board.

And in some cases, what you want the CLIENTID to interact with, is only available at the protocol level, whereas the SASL implementations might not have access.

Admittedly, we have fu= ll access to our stack, so these things are not complications we
= had to deal with.=C2=A0 In fact for us, handling it at the sasl layer meant= a single impl across protocols, as opposed to protocol specific handlers.= =C2=A0 Adding the ID as a token to retrieve from the sasl impl to hand to o= ur auth system was not complicated, and we could have done other things wit= h it if we'd had a use.


CLIENTID is more than just authentication, as pointed out several times already, which is why we call it 'two and 1/2' factor authenticatio= n.

The list of examples of where else y= ou can use this seems just as easily
to apply to the regular IMAP= ID command, modulo the fact that the ID RFC says DON'T
do th= at, and that the ID command as a k/v list has both more data and less consi= stency.
We did consider some poor mans access control and MDM based on t= he ID, but it was never
a high enough priority for the benefit.= =C2=A0 I don't know if vendors have that ask or not.

Today we do offer some of that based on the client-token in the OAUT= HBEAER mechanism,
because of the registration information, the po= tential to limit / abuse check creating new
tokens, and because a= ll external access across GSuite is by OAUTH2.=C2=A0 This means there isn&#= 39;t some special case for IMAP, and tools which touch multiple APIs and so= urces can be listed and access controlled singly.

Your use case list= also seems to imply that the CLIENTID would have a structured form, where = you can tease apart things to apply those rules, I don't think your dra= ft does that well.=C2=A0 In particular, I don't see how the client-id-t= ype is useful.

Brandon
=C2=A0
The IMAP protocol can handle the verification/sanity and interact with
external systems, including identifying attack heuristics, and it will
be available to any SASL which is interested in using it in the
authentication layer, including legacy SASL and other authentication
schemes.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Michael --

PS, we are still moving forward with implementation at this level, and
publishing patches for email clients and other opensource IMAP
implementations based on our model, so it would be nice to see
standardization around this model.

So far the only change to our plans has been taking into account the
opinions of others that we should not use the CID acronym, and consider using CLIENTID/DEVICEID instead.

Trying to reach a consensus on opinions on this in the mean time.








On 18-08-02 04:37 PM, Brandon Long wrote:
> (catching up on email from vacation)
>
> On Mon, Jul 23, 2018 at 3:53 PM Chris Newman <chris.newman@oracle.com
> <mailto:chris.newman@oracle.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0On 23 Jul 2018, at 11:27, Michael Peddemors wrote:<= br> >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > * It was questioned, is the proper place for = this in a SASL
>=C2=A0 =C2=A0 =C2=A0mechanism,
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0vs in the protocol itself, and wh= ile our development work and
>=C2=A0 =C2=A0 =C2=A0 > research
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0show that the advantages for a &#= 39;device identifier' to be part
>=C2=A0 =C2=A0 =C2=A0of the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0protocol/syntax rather than a SAS= L, and our assertion this will
>=C2=A0 =C2=A0 =C2=A0help
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0in the adoption curve in the indu= stry, it was one of the strongest
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0points of contention, with the ar= guments for SASL, was one SASL can
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0apply to many services, and thus = if that argument holds, then maybe
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0the SASL or a security group woul= d be better for this.=C2=A0 We
>=C2=A0 =C2=A0 =C2=A0intend to
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0argue against this, but the topic= alone is key to discussions,
>=C2=A0 =C2=A0 =C2=A0so it
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0requires a separate thread to dis= cuss this.
>
>=C2=A0 =C2=A0 =C2=A0We have a case where client-id facilities (device-s= pecific token, a
>=C2=A0 =C2=A0 =C2=A0subset of the client-id problem) were deployed in p= roduction using
>=C2=A0 =C2=A0 =C2=A0custom SASL mechanisms on our server and custom cha= nges to a client. So
>=C2=A0 =C2=A0 =C2=A0I assert this is a proof-of-concept that SASL is de= ployable for
>=C2=A0 =C2=A0 =C2=A0client-id, that it can solve the problem for multip= le protocols with
>=C2=A0 =C2=A0 =C2=A0one
>=C2=A0 =C2=A0 =C2=A0specification and shared code (Submission & IMA= P), that it comes
>=C2=A0 =C2=A0 =C2=A0with an
>=C2=A0 =C2=A0 =C2=A0extensible capability model for interoperability, a= nd does not break
>=C2=A0 =C2=A0 =C2=A0interoperability with unmodified clients. Furthermo= re, no custom
>=C2=A0 =C2=A0 =C2=A0changes
>=C2=A0 =C2=A0 =C2=A0were required to our server to support this since w= e have a SASL
>=C2=A0 =C2=A0 =C2=A0abstraction API we support. That means our customer= s could deploy a
>=C2=A0 =C2=A0 =C2=A0SASL-based mechanism without requiring a server upg= rade, thus
>=C2=A0 =C2=A0 =C2=A0significantly simplifying deployment. We do not hav= e an API for IMAP
>=C2=A0 =C2=A0 =C2=A0commands and have no intention of providing one, so= our customers will
>=C2=A0 =C2=A0 =C2=A0not be able to deploy client ID unless it is SASL o= r there is an IETF
>=C2=A0 =C2=A0 =C2=A0rough consensus around a non-SASL client-id model f= or
>=C2=A0 =C2=A0 =C2=A0submission+imap(+pop+managesieve+jmap+etc).
>
>=C2=A0 =C2=A0 =C2=A0I consider it unfortunate this use case involved pr= oprietary SASL
>=C2=A0 =C2=A0 =C2=A0mechanisms so I'd support a standardized mechan= ism, but we have running
>=C2=A0 =C2=A0 =C2=A0code showing a SASL approach is deployable and back= wards compatible.
>
>=C2=A0 =C2=A0 =C2=A0I'm aware of another deployed use of client-id = like facilities for push
>=C2=A0 =C2=A0 =C2=A0notifications.
>
>
> Note that PLAIN-CLIENTTOKEN that gmail still offers for MSA/POP/IMAP i= s
> a form of this in SASL as well, something that we worked on with sever= al
> clients (and intended to be taken for standardization) before deciding=
> to go the OAUTH route that led to OAUTHBEARER eventually.
>
> Just adding the token into the sasl data seemed pretty straightforward= .
>
> (not sure if it was mentioned in the presentation or not)
>
> Brandon



--
"Catch the Magic of Linux..."
------------------------------------------------------------------------ Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoService= s Ltd.
------------------------------------------------------------------------ 604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended<= br> solely for the use of the individual or entity to which they are addressed.=
Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company.=

_______________________________________________
Extra mailing list
Extra@ietf.org
https://www.ietf.org/mailman/listinfo/extra
--000000000000d5529f0573080b6b-- From nobody Thu Aug 9 21:25:20 2018 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 187F6130EFE; Thu, 9 Aug 2018 21:25:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Bron Gondwana To: X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Cc: extra@ietf.org, brong@fastmailteam.com, Bron Gondwana , iesg-secretary@ietf.org, extra-chairs@ietf.org Message-ID: <153387511809.28730.579849348328984260.idtracker@ietfa.amsl.com> Date: Thu, 09 Aug 2018 21:25:18 -0700 Archived-At: Subject: [Extra] Publication has been requested for draft-ietf-extra-imap-savedate-01 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2018 04:25:18 -0000 Bron Gondwana has requested publication of draft-ietf-extra-imap-savedate-01 as Proposed Standard on behalf of the EXTRA working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-extra-imap-savedate/ From nobody Fri Aug 10 18:19:36 2018 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BFF4D126BED; Fri, 10 Aug 2018 18:19:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: extra@ietf.org Message-ID: <153395037368.25594.14303004976226262531@ietfa.amsl.com> Date: Fri, 10 Aug 2018 18:19:33 -0700 Archived-At: Subject: [Extra] I-D Action: draft-ietf-extra-imap-replace-00.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2018 01:19:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email mailstore and eXtensions To Revise or Amend WG of the IETF. Title : IMAP REPLACE Extension Author : Stuart Brandt Filename : draft-ietf-extra-imap-replace-00.txt Pages : 10 Date : 2018-08-08 Abstract: This document defines an IMAP extension which can be used to replace an existing message in a message store with a new message. Message replacement is a common operation for clients that automatically save drafts or notes as a user composes them. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-extra-imap-replace/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-extra-imap-replace-00 https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap-replace-00 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 Fri Aug 10 22:27:00 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26B36130EC7 for ; Fri, 10 Aug 2018 22:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=sNFCWgr7; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=nXdH8hlC Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LxEd1tu0pZwH for ; Fri, 10 Aug 2018 22:26:57 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01C57130E8B for ; Fri, 10 Aug 2018 22:26:57 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 3F79B21AC2 for ; Sat, 11 Aug 2018 01:26:56 -0400 (EDT) Received: from web2 ([10.202.2.212]) by compute6.internal (MEProxy); Sat, 11 Aug 2018 01:26:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:message-id:mime-version:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=ATVHMeZfYM2Lyn/M44syyLGqK/ftZDR1kMffUqFtX vc=; b=sNFCWgr70wQG3tgaRoWrzon5ISY7ELPy8eUC6ABLHROEtrkKGalUpGzcH uDXOgO4zUah62GnMjPhZKJgmhzCVZkCBQ0ccYw4kowYdfdSRoZb/UCMJyjqvMBNm FwvcykzFNCaYqgNCmQrhCgjZm9N5As9Pgjc+Wb7iDLS6mtQjVyaRmhiiOnPV5rf9 /0v9E2LMyfzF/CpU/QPgL6vW7oIfuADkCzDHlBBJRO6sjkLN3BeMrsPzEjp5xAsG Ap9iURr0nPllXVAHueMXYWUtrJ9UZ+AsdfQL/4mF8ewD5LEowcCUMK22ZRYYPNE3 +65pE9RLxqS7vsBdMCaY3HGNsPBAA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=ATVHMeZfYM2Lyn/M44syyLGqK/ftZ DR1kMffUqFtXvc=; b=nXdH8hlCEF2DjtiXks+hCxqPjQC5pVDoXeN3V2o0xTxVL FNwI+rPfOy5OxxKzDi0+arntGLRNwvVueXKr5fjLfJdcWf2pYStAHNG3L0w7CN0Q +NZq/moSn8hOIoYTpvuMv91rYo91LqVqBM/n6dDh+gQyLO6He9RwPUn+NSbRdMlQ kWriClhR/5JnPN1Dn3mCDmq3eeuW+bInR05HHRftbnyRSVckQngQHcKkzEDYFIvG 9wwB2E+KYEnbrrPna3wfngwFBmcQ07nG41aC3IKo49uKiKTcxDqFDjpf5IiSzSQV O8kKSVF4PkKCuFW1sEo843Sqcq2L1+lH+hvfho6fQ== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 945B5621BF; Sat, 11 Aug 2018 01:26:55 -0400 (EDT) Message-Id: <1533965215.3244415.1470608496.2420C769@webmail.messagingengine.com> From: Bron Gondwana To: extra@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_153396521532444150" X-Mailer: MessagingEngine.com Webmail Interface - ajax-9a5384d7 X-Forwarded-Message-Id: <153396500746.25632.6100353706780841711.idtracker@ietfa.amsl.com> Date: Sat, 11 Aug 2018 15:26:55 +1000 Archived-At: Subject: [Extra] Call for adoption, draft-gondwana-sieve-mailboxid X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2018 05:26:59 -0000 This is a multi-part message in MIME format. --_----------=_153396521532444150 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" As promised, I've written up a way of adding mailboxid support to Sieve. This draft is absolutely a first pass - I'm interested in feedback. Particularly the mailboxidexists test is a little clunky. I'd like to formally adopt this work into the EXTRA working group, it's within scope and fits with the other work we've been doing. I suggest doing that in 2 weeks (Aug 24th) unless there are objections to taking on the work. Cheers, Bron. ----- Original message ----- From: internet-drafts@ietf.org To: Bron Gondwana Subject: New Version Notification for draft-gondwana-sieve-mailboxid-00.txtDate: Fri, 10 Aug 2018 22:23:27 -0700 A new version of I-D, draft-gondwana-sieve-mailboxid-00.txt has been successfully submitted by Bron Gondwana and posted to the IETF repository. Name: draft-gondwana-sieve-mailboxid Revision: 00 Title: Sieve Email Filtering: delivery by mailboxid Document date: 2018-08-11 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-gondwana-sieve-mailboxid-00.txtStatus: https://datatracker.ietf.org/doc/draft-gondwana-sieve-mailboxid/Htmlized: https://tools.ietf.org/html/draft-gondwana-sieve-mailboxid-00Htmlized: https://datatracker.ietf.org/doc/html/draft-gondwana-sieve-mailboxid Abstract: The OBJECTID capability of the IMAP protocol (I-D.ietf-extra-imap- objectid) allows clients to identify mailboxes by a unique identifier which survives rename. In contrast, the Sieve mail filtering language (RFC 5228) currently has no such capability. This memo defines a Sieve extension that fills this gap: it adds a method for specifying the unique identifier of a mailbox as a target for fileinto rules, and a method for testing the existence of a mailbox by its unique identifier. Please note that it may take a couple of minutes from the time of submissionuntil the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_153396521532444150 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
As promised, I've written up a way of adding mailboxid support to Sieve.

This draft is absolutely a first pass - I'm interested in feedback.  Particularly the mailboxidexists test is a little clunky.

I'd like to formally adopt this work into the EXTRA working group, it's within scope and fits with the other work we've been doing.  I suggest doing that in 2 weeks (Aug 24th) unless there are objections to taking on the work.

Cheers,

Bron.


----- Original message -----
To: Bron Gondwana <brong@fastmailteam.com>
Subject: New Version Notification for draft-gondwana-sieve-mailboxid-00.txt
Date: Fri, 10 Aug 2018 22:23:27 -0700


A new version of I-D, draft-gondwana-sieve-mailboxid-00.txt
has been successfully submitted by Bron Gondwana and posted to the
IETF repository.

Name: draft-gondwana-sieve-mailboxid
Revision: 00
Title: Sieve Email Filtering: delivery by mailboxid
Document date: 2018-08-11
Group: Individual Submission
Pages: 6


Abstract:
  The OBJECTID capability of the IMAP protocol (I-D.ietf-extra-imap-
  objectid) allows clients to identify mailboxes by a unique identifier
  which survives rename.  In contrast, the Sieve mail filtering
  language (RFC 5228) currently has no such capability.  This memo
  defines a Sieve extension that fills this gap: it adds a method for
  specifying the unique identifier of a mailbox as a target for
  fileinto rules, and a method for testing the existence of a mailbox
  by its unique identifier.

                                                                                 


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.

The IETF Secretariat


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


--_----------=_153396521532444150-- From nobody Sat Aug 11 11:09:45 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D0A413107D for ; Sat, 11 Aug 2018 11:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id koizm0LI0Ohs for ; Sat, 11 Aug 2018 11:09:41 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5592F131092 for ; Sat, 11 Aug 2018 11:09:41 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QVY2V54J1C0012BM@mauve.mrochek.com> for extra@ietf.org; Sat, 11 Aug 2018 11:04:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1534010673; bh=hDR8xhR6quSgooCFjiqf3IWKfRM7iW+Xi48Y/EwNa9o=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=GrY095hhvry2f2R2RFYlE4dYEYQD12WQ4SKMTtJdLZT/ADHEs5U6nhD4HSptVLVJG C7Gnz6l/yo7xbmdKOJk64v5xewc5iNvfCf8e1xgGaU7yY2xlaBavAA1OjQ2HTtrI2i VFIHA7gGZ/YQk33sX+UzJYbQKXWuRGxcVqKvaMkY= 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 <01QVMTUL8QXS00004T@mauve.mrochek.com>; Sat, 11 Aug 2018 11:04:12 -0700 (PDT) Cc: Michael Peddemors , extra@ietf.org Message-id: <01QVY2V27BWO00004T@mauve.mrochek.com> Date: Sat, 11 Aug 2018 10:51:58 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 09 Aug 2018 15:21:07 -0700" References: <1dc71d96-c3be-4ae3-7644-13f7accecace@linuxmagic.com> <79A4C4F2-E4BA-4B4C-B8E0-295B7216EC9C@oracle.com> <8d0f565e-54d7-a44d-1527-8c42ee09f44f@linuxmagic.com> To: Brandon Long Archived-At: Subject: Re: [Extra] CLIENT ID - Next Steps - General Discussion Overview X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2018 18:09:43 -0000 > On Fri, Aug 3, 2018 at 7:44 AM Michael Peddemors > wrote: > > Thanks Brandon, for weighing in on this.. > > > > And it is good that we seem to have consensus on the following: > > > > * Concept of CLIENTID is worthwhile to pursue > > * Standardization is also worthwhile > > > > However, again we should point out. > > > > It isn't that doing this (coding) in a SASL is difficult, we already > > examined this, and found that it limited the scope and abilities that > > CLIENTID offers. By presenting this at the protocol level, we can > > always pass it to a SASL that wishes to implement it, but by doing it at > > the protocol layer it makes it available to all SASL methods that might > > be developed/extended in the future. > And some of those SASL methods already include this type of information. > And if it were useful enough, then it would seem likely to become a standard part > of any future SASL methods. There's no need to create more than one new SASL mechanism here. As I described previously, this can be done at the SASL layer and used in conjunction with existing SASL mechanisms. The obvious approach is for the client to send the id, the server to respond with a revised list of SASL mechanisms that can now be engaged. > > AS well, no use creating a standard that isn't going to see adoption, > > and our team looked at many of the client implementations (opensource) > > as well as several other IMAP server implementations, and realized that > > it is easier to port the protocol implementation, than SASL's across the > > board. > > And in some cases, what you want the CLIENTID to interact with, is only > > available at the protocol level, whereas the SASL implementations might > > not have access. Actually, the opposite is much more likely to be true. Getting the information to a SASL mechanism may require protocol extensions to whatever the server uses to talk to the authentication source. Of course this issue exists to some extent no matter how this is done if if you want to tie it into existing mechanisms. > Admittedly, we have full access to our stack, so these things are not > complications we > had to deal with. In fact for us, handling it at the sasl layer meant a > single impl across protocols, as opposed to protocol specific handlers. Bingo. We're in exactly the same position. And it's multiplied by the need to change the protocol handling for at least five separate servers. Whereas with a SASL level mechanism we can do it once and we're done. > Adding the ID as a token to retrieve from the sasl impl to hand to our auth > system was not complicated, and we could have done other things with it if > we'd had a use. That's good to hear. > > CLIENTID is more than just authentication, as pointed out several times > > already, which is why we call it 'two and 1/2' factor authentication. > The list of examples of where else you can use this seems just as easily > to apply to the regular IMAP ID command, modulo the fact that the ID RFC > says DON'T > do that, and that the ID command as a k/v list has both more data and less > consistency. > We did consider some poor mans access control and MDM based on the ID, but > it was never > a high enough priority for the benefit. I don't know if vendors have that > ask or not. Given the grosteque situation that's developed around client identifiers in HTTP, I'm not exactly wild about the prospects for use of this information outside of authentication. > Today we do offer some of that based on the client-token in the OAUTHBEAER > mechanism, > because of the registration information, the potential to limit / abuse > check creating new > tokens, and because all external access across GSuite is by OAUTH2. This > means there isn't some special case for IMAP, and tools which touch > multiple APIs and sources can be listed and access controlled singly. This all looks to still be in the authentication space. The problematic uses are things like blocking clients. > Your use case list also seems to imply that the CLIENTID would have a > structured form, where you can tease apart things to apply those rules, I > don't think your draft does that well. In particular, I don't see how the > client-id-type is useful. Well, it depends on how you define "useful". Every time you encounter a web site that says "I don't recognize , go away", for any value of you care to name, you're seening an example of the "usefulness" of these sorts of mechanisms. Ned From nobody Sat Aug 11 11:19:15 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D04913104D for ; Sat, 11 Aug 2018 11:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=TMW5inPR; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=gwn0XmRN Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id plwXLQ6Mu4OU for ; Sat, 11 Aug 2018 11:19:12 -0700 (PDT) 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 F1EBA12F1A2 for ; Sat, 11 Aug 2018 11:19:11 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 80FC32C8 for ; Sat, 11 Aug 2018 14:19:11 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Sat, 11 Aug 2018 14:19:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; bh=TtP2ZdYZJV3V+W4fpZTF9N0MGDJuyDoZ0uo0QAA/qcM=; b=TMW5inPR LGmxhfev6RROdKuqHsp9mj2LHebUHzDDw3iqgwQ23JFYc+GH4K/z1xOvS0uAvfjR 4600KWC8YjZVzb4ENXhB1TCNpJieOcwEvX41U3P+6RbPt5SfiRAn+zqGh+dELU4P vtqVauY6BFPKCG1WDofY3L9al0dfnRH1CzNrC2lkQG8r8y95t76902RRCDrXai2E 3UwIC6lsE9xqlpIbd8syhWZjTwzZSrPQdq9Z6P0wXu9foGXRLrUCmwYMpagPi/ZT DnvPA8jX8o2mdldO8iI4t3Bb6kkF+nZlrJf1H9O7Q1hBAXyWwuFt1asKjAEbexA6 exLrxqRAFlV8xw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=TtP2ZdYZJV3V+W4fpZTF9N0MGDJuy DoZ0uo0QAA/qcM=; b=gwn0XmRNy1k714ueNRUTqGB0IB/CXaIhjAbHlMxOHIjVC BWeUdVM4yN+nEHLIfcvJ1cFRS6qk8S5T1C7DJs0jG39aEURh0nUpdO8L1EjgQ9It DF7o/pB3w5LFZMYgC6DFEBPW1a8DpHrVCX+zju5i8xaF27N5ja8QfQ2aSuD66NX1 CyDChOn+QHLx8ueNqy2zdCthjBbAk1hznIQUEI3WrGXh6i8zXenVPvMPpYCmgxA3 ywlHttPzoBhEg1js5enxEkqVIWt4SH0Gs9WqkAD6yUp1EOTeUSaIm6FKkskUFS6E AWGrc1Z1Ke4U8tGlw+48x/QeoDiuZsBucOq9g07mQ== X-ME-Proxy: X-ME-Sender: Received: from localhost.localdomain (cpe-74-77-85-250.buffalo.res.rr.com [74.77.85.250]) by mail.messagingengine.com (Postfix) with ESMTPA id A2B091025C for ; Sat, 11 Aug 2018 14:19:10 -0400 (EDT) To: extra@ietf.org References: <1533965215.3244415.1470608496.2420C769@webmail.messagingengine.com> From: Ken Murchison Organization: FastMail US LLC Message-ID: <3b91e44b-88ec-4665-fb1e-666ffc87f03e@fastmail.com> Date: Sat, 11 Aug 2018 14:19:10 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <1533965215.3244415.1470608496.2420C769@webmail.messagingengine.com> Content-Type: multipart/mixed; boundary="------------C33156518580974E9007BD7E" Content-Language: en-US Archived-At: Subject: Re: [Extra] Call for adoption, draft-gondwana-sieve-mailboxid X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2018 18:19:14 -0000 This is a multi-part message in MIME format. --------------C33156518580974E9007BD7E Content-Type: multipart/alternative; boundary="------------8EF06188D34E1B664146E034" --------------8EF06188D34E1B664146E034 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit This extension can probably interact with :fcc.  Should the interop be described in this draft of the :fcc draft? Additionally, the :mailboxid argument probably doesn't play well with :create, or at least I don't see how it could without a mailbox name. On 08/11/2018 01:26 AM, Bron Gondwana wrote: > As promised, I've written up a way of adding mailboxid support to Sieve. > > This draft is absolutely a first pass - I'm interested in feedback.  > Particularly the mailboxidexists test is a little clunky. > > I'd like to formally adopt this work into the EXTRA working group, > it's within scope and fits with the other work we've been doing.  I > suggest doing that in 2 weeks (Aug 24th) unless there are objections > to taking on the work. > > Cheers, > > Bron. > > > ----- Original message ----- > From: internet-drafts@ietf.org > To: Bron Gondwana > > Subject: New Version Notification for > draft-gondwana-sieve-mailboxid-00.txt > Date: Fri, 10 Aug 2018 22:23:27 -0700 > > > A new version of I-D, draft-gondwana-sieve-mailboxid-00.txt > has been successfully submitted by Bron Gondwana and posted to the > IETF repository. > > Name: draft-gondwana-sieve-mailboxid > Revision: 00 > Title: Sieve Email Filtering: delivery by mailboxid > Document date: 2018-08-11 > Group: Individual Submission > Pages: 6 > URL: > https://www.ietf.org/internet-drafts/draft-gondwana-sieve-mailboxid-00.txt > Status: https://datatracker.ietf.org/doc/draft-gondwana-sieve-mailboxid/ > Htmlized: https://tools.ietf.org/html/draft-gondwana-sieve-mailboxid-00 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-gondwana-sieve-mailboxid > > > Abstract: >   The OBJECTID capability of the IMAP protocol (I-D.ietf-extra-imap- >   objectid) allows clients to identify mailboxes by a unique identifier >   which survives rename.  In contrast, the Sieve mail filtering >   language (RFC 5228) currently has no such capability.  This memo >   defines a Sieve extension that fills this gap: it adds a method for >   specifying the unique identifier of a mailbox as a target for >   fileinto rules, and a method for testing the existence of a mailbox >   by its unique identifier. > > > > > 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. > > The IETF Secretariat > > > -- >   Bron Gondwana, CEO, FastMail Pty Ltd >   brong@fastmailteam.com > > > > > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra -- Ken Murchison Cyrus Development Team FastMail US LLC --------------8EF06188D34E1B664146E034 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit This extension can probably interact with :fcc.  Should the interop be described in this draft of the :fcc draft?

Additionally, the :mailboxid argument probably doesn't play well with :create, or at least I don't see how it could without a mailbox name.



On 08/11/2018 01:26 AM, Bron Gondwana wrote:
As promised, I've written up a way of adding mailboxid support to Sieve.

This draft is absolutely a first pass - I'm interested in feedback.  Particularly the mailboxidexists test is a little clunky.

I'd like to formally adopt this work into the EXTRA working group, it's within scope and fits with the other work we've been doing.  I suggest doing that in 2 weeks (Aug 24th) unless there are objections to taking on the work.

Cheers,

Bron.


----- Original message -----
To: Bron Gondwana <brong@fastmailteam.com>
Subject: New Version Notification for draft-gondwana-sieve-mailboxid-00.txt
Date: Fri, 10 Aug 2018 22:23:27 -0700


A new version of I-D, draft-gondwana-sieve-mailboxid-00.txt
has been successfully submitted by Bron Gondwana and posted to the
IETF repository.

Name: draft-gondwana-sieve-mailboxid
Revision: 00
Title: Sieve Email Filtering: delivery by mailboxid
Document date: 2018-08-11
Group: Individual Submission
Pages: 6


Abstract:
  The OBJECTID capability of the IMAP protocol (I-D.ietf-extra-imap-
  objectid) allows clients to identify mailboxes by a unique identifier
  which survives rename.  In contrast, the Sieve mail filtering
  language (RFC 5228) currently has no such capability.  This memo
  defines a Sieve extension that fills this gap: it adds a method for
  specifying the unique identifier of a mailbox as a target for
  fileinto rules, and a method for testing the existence of a mailbox
  by its unique identifier.

                                                                                 


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.

The IETF Secretariat


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




_______________________________________________
Extra mailing list
Extra@ietf.org
https://www.ietf.org/mailman/listinfo/extra


-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC
--------------8EF06188D34E1B664146E034-- --------------C33156518580974E9007BD7E Content-Type: text/x-vcard; name="murch.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="murch.vcf" bnVsbA== --------------C33156518580974E9007BD7E-- From nobody Sat Aug 11 12:03:38 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 002AE130FDE for ; Sat, 11 Aug 2018 12:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gM9qWqs7wVqW for ; Sat, 11 Aug 2018 12:03:34 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78C86130E8C for ; Sat, 11 Aug 2018 12:03:34 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QVY4QWSKWG0018TD@mauve.mrochek.com> for extra@ietf.org; Sat, 11 Aug 2018 11:58:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1534013908; bh=b3vAPXtjhsSZ1AoKqhEJuBpdy23p5esC5o1efSlNZks=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=gKIOt5/bA5tfgKAeRQ/569U1Rkq4cgmIl0b+eRi9UlFOR4ZL/o5O2sDB61g40lIHB 7rC8r3BcTpM2rXNKPK9s26hbFa6tEBhZzDXQI8luGJjFVxTYAkaT/dZC4Jn7yLoyNw OKLO87FGNJyFvx3/yWtyM6x3hhF/LywfauJh8/bo= MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: TEXT/PLAIN; charset=utf-8; format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QVMTUL8QXS00004T@mauve.mrochek.com>; Sat, 11 Aug 2018 11:58:00 -0700 (PDT) Cc: extra@ietf.org Message-id: <01QVY4QRCYRI00004T@mauve.mrochek.com> Date: Sat, 11 Aug 2018 11:55:48 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sat, 11 Aug 2018 14:19:10 -0400" <3b91e44b-88ec-4665-fb1e-666ffc87f03e@fastmail.com> References: <1533965215.3244415.1470608496.2420C769@webmail.messagingengine.com> <3b91e44b-88ec-4665-fb1e-666ffc87f03e@fastmail.com> To: Ken Murchison Archived-At: Subject: Re: [Extra] Call for adoption, draft-gondwana-sieve-mailboxid X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2018 19:03:37 -0000 > This extension can probably interact with :fcc. Definitely. >  Should the interop be > described in this draft of the :fcc draft? Why not have it build on the :fcc draft instead of creating a dependency in the other direction? > Additionally, the :mailboxid argument probably doesn't play well with > :create, or at least I don't see how it could without a mailbox name. Not sure I see the conflict. Of course you can't create a mailbox with the specified objectid, but in the fallback case :create would still be valid. It just needs to be spelled out in the document. Ned > On 08/11/2018 01:26 AM, Bron Gondwana wrote: > > As promised, I've written up a way of adding mailboxid support to Sieve. > > > > This draft is absolutely a first pass - I'm interested in feedback.  > > Particularly the mailboxidexists test is a little clunky. > > > > I'd like to formally adopt this work into the EXTRA working group, > > it's within scope and fits with the other work we've been doing.  I > > suggest doing that in 2 weeks (Aug 24th) unless there are objections > > to taking on the work. > > > > Cheers, > > > > Bron. > > > > > > ----- Original message ----- > > From: internet-drafts@ietf.org > > To: Bron Gondwana > > > Subject: New Version Notification for > > draft-gondwana-sieve-mailboxid-00.txt > > Date: Fri, 10 Aug 2018 22:23:27 -0700 > > > > > > A new version of I-D, draft-gondwana-sieve-mailboxid-00.txt > > has been successfully submitted by Bron Gondwana and posted to the > > IETF repository. > > > > Name: draft-gondwana-sieve-mailboxid > > Revision: 00 > > Title: Sieve Email Filtering: delivery by mailboxid > > Document date: 2018-08-11 > > Group: Individual Submission > > Pages: 6 > > URL: > > https://www.ietf.org/internet-drafts/draft-gondwana-sieve-mailboxid-00.txt > > Status: https://datatracker.ietf.org/doc/draft-gondwana-sieve-mailboxid/ > > Htmlized: https://tools.ietf.org/html/draft-gondwana-sieve-mailboxid-00 > > Htmlized: > > https://datatracker.ietf.org/doc/html/draft-gondwana-sieve-mailboxid > > > > > > Abstract: > >   The OBJECTID capability of the IMAP protocol (I-D.ietf-extra-imap- > >   objectid) allows clients to identify mailboxes by a unique identifier > >   which survives rename.  In contrast, the Sieve mail filtering > >   language (RFC 5228) currently has no such capability.  This memo > >   defines a Sieve extension that fills this gap: it adds a method for > >   specifying the unique identifier of a mailbox as a target for > >   fileinto rules, and a method for testing the existence of a mailbox > >   by its unique identifier. > > > > > > > > > > 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. > > > > The IETF Secretariat > > > > > > -- > >   Bron Gondwana, CEO, FastMail Pty Ltd > >   brong@fastmailteam.com > > > > > > > > > > _______________________________________________ > > Extra mailing list > > Extra@ietf.org > > https://www.ietf.org/mailman/listinfo/extra > -- > Ken Murchison > Cyrus Development Team > FastMail US LLC From nobody Sat Aug 11 13:19:07 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BBA0130E6A for ; Sat, 11 Aug 2018 13:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=ndezSChR; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=JxBZn6yi Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gHKi9UMWd5Ij for ; Sat, 11 Aug 2018 13:19:02 -0700 (PDT) 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 CF4F7130E10 for ; Sat, 11 Aug 2018 13:19:02 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id BFC73272; Sat, 11 Aug 2018 16:19:01 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Sat, 11 Aug 2018 16:19:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= cc:content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; bh=JCxMh/uo9RcAeKaO8SyqQ3TaHpEVKW0lv7xh9rSlI0I=; b=ndezSChR +h734VQzZMPKeYx62eKBM9v6bgU1l5ls6ou7lGVkm5F3JAr7OX6mYfQacpe5JecZ GWYkq3aUF8Rwf70A/wb8lOofMZRlrhhCSPwvguufRMRWQoaJbGSK5KwPIcJo7bCi 32zTHJCV55ATbeDAXq+0q2GYSCWZEeKL7mQlfrH06gH8F7osGAzdZUN/o4/XUITH idImQfn2Opc+NqYp6T5A1hsMI7D0jCoZ4wviVV4sxV1cPmrqVe+bycR3dWRItsNj sll5vj7d+VeYnhINjD/LMfuteRX3RpctLIGiuiUOWW4isLVxYOoBLzQaKBoGe+S3 gyM7+I/k7GE8+w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=JCxMh/uo9RcAeKaO8SyqQ3TaHpEVK W0lv7xh9rSlI0I=; b=JxBZn6yiJws3z/cmojyINITd/TmtgypbGmAjp9SlqxB21 OBqR6A/nFJ3Tzhy+75ECg1IH+p/p2McWmJsPDszJdtF1nJ8TLysrTiqauNLZvTPd 7XcaFq6HJYipkfqTL1LEjc8pcdORNO07MNH04INPew64SOJJlGje4Hph2SumcH9y ORv3Pz4scoAeG0+lP6FOQcdyf0+9dHJTZclMcxd+meK3qrWCQFwWfQE8L83+o3H4 Ol0ErjZRCPE9MfIwVrMca6497mzYzjDBvOx4Oo2BQbLkm3DSFzKMOfZRdKNuO/qk YTnWzyQqD+nY3kzLZhhSg3q7/Aw1joi7vcNMbKdwA== X-ME-Proxy: X-ME-Sender: Received: from localhost.localdomain (cpe-74-77-85-250.buffalo.res.rr.com [74.77.85.250]) by mail.messagingengine.com (Postfix) with ESMTPA id A070310286; Sat, 11 Aug 2018 16:19:00 -0400 (EDT) To: Ned Freed Cc: extra@ietf.org References: <1533965215.3244415.1470608496.2420C769@webmail.messagingengine.com> <3b91e44b-88ec-4665-fb1e-666ffc87f03e@fastmail.com> <01QVY4QRCYRI00004T@mauve.mrochek.com> From: Ken Murchison Organization: FastMail US LLC Message-ID: <92650f94-50da-88be-466a-02fbab806c92@fastmail.com> Date: Sat, 11 Aug 2018 16:18:53 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <01QVY4QRCYRI00004T@mauve.mrochek.com> Content-Type: multipart/mixed; boundary="------------8CD5C35F804F406934EB75AC" Content-Language: en-US Archived-At: Subject: Re: [Extra] Call for adoption, draft-gondwana-sieve-mailboxid X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2018 20:19:05 -0000 This is a multi-part message in MIME format. --------------8CD5C35F804F406934EB75AC Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 08/11/2018 02:55 PM, Ned Freed wrote: >> This extension can probably interact with :fcc. > > Definitely. > >>   Should the interop be >> described in this draft of the :fcc draft? > > Why not have it build on the :fcc draft instead of creating a dependency > in the other direction? Agreed. >> Additionally, the :mailboxid argument probably doesn't play well with >> :create, or at least I don't see how it could without a mailbox name. > > Not sure I see the conflict. Of course you can't create a mailbox > with the specified objectid, but in the fallback case :create would > still be valid. > > It just needs to be spelled out in the document. :create wouldn't have a mailbox name to use if :mailboxid is specified.  :mailboxid changes the positional parameter in fileinto from a name to an id (unless I'm reading it incorrectly). >> On 08/11/2018 01:26 AM, Bron Gondwana wrote: >> > As promised, I've written up a way of adding mailboxid support to >> Sieve. >> > >> > This draft is absolutely a first pass - I'm interested in feedback. >> > Particularly the mailboxidexists test is a little clunky. >> > >> > I'd like to formally adopt this work into the EXTRA working group, >> > it's within scope and fits with the other work we've been doing.  I >> > suggest doing that in 2 weeks (Aug 24th) unless there are objections >> > to taking on the work. >> > >> > Cheers, >> > >> > Bron. >> > >> > >> > ----- Original message ----- >> > From: internet-drafts@ietf.org >> > To: Bron Gondwana > > >> > Subject: New Version Notification for >> > draft-gondwana-sieve-mailboxid-00.txt >> > Date: Fri, 10 Aug 2018 22:23:27 -0700 >> > >> > >> > A new version of I-D, draft-gondwana-sieve-mailboxid-00.txt >> > has been successfully submitted by Bron Gondwana and posted to the >> > IETF repository. >> > >> > Name: draft-gondwana-sieve-mailboxid >> > Revision: 00 >> > Title: Sieve Email Filtering: delivery by mailboxid >> > Document date: 2018-08-11 >> > Group: Individual Submission >> > Pages: 6 >> > URL: >> > >> https://www.ietf.org/internet-drafts/draft-gondwana-sieve-mailboxid-00.txt >> > Status: >> https://datatracker.ietf.org/doc/draft-gondwana-sieve-mailboxid/ >> > Htmlized: >> https://tools.ietf.org/html/draft-gondwana-sieve-mailboxid-00 >> > Htmlized: >> > https://datatracker.ietf.org/doc/html/draft-gondwana-sieve-mailboxid >> > >> > >> > Abstract: >> >   The OBJECTID capability of the IMAP protocol (I-D.ietf-extra-imap- >> >   objectid) allows clients to identify mailboxes by a unique >> identifier >> >   which survives rename.  In contrast, the Sieve mail filtering >> >   language (RFC 5228) currently has no such capability. This memo >> >   defines a Sieve extension that fills this gap: it adds a method for >> >   specifying the unique identifier of a mailbox as a target for >> >   fileinto rules, and a method for testing the existence of a mailbox >> >   by its unique identifier. >> > >> > >> > >> > >> > 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. >> > >> > The IETF Secretariat >> > >> > >> > -- >> >   Bron Gondwana, CEO, FastMail Pty Ltd >> >   brong@fastmailteam.com >> > >> > >> > >> > >> > _______________________________________________ >> > Extra mailing list >> > Extra@ietf.org >> > https://www.ietf.org/mailman/listinfo/extra > >> -- >> Ken Murchison >> Cyrus Development Team >> FastMail US LLC > -- Ken Murchison Cyrus Development Team FastMail US LLC --------------8CD5C35F804F406934EB75AC Content-Type: text/x-vcard; name="murch.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="murch.vcf" bnVsbA== --------------8CD5C35F804F406934EB75AC-- From nobody Sat Aug 11 16:03:26 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C276F130E66 for ; Sat, 11 Aug 2018 16:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 FJirDXs7wg8V for ; Sat, 11 Aug 2018 16:03:22 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEB6B130DDF for ; Sat, 11 Aug 2018 16:03:22 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QVYD4LVVY8001ADP@mauve.mrochek.com> for extra@ietf.org; Sat, 11 Aug 2018 15:58:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1534028295; bh=DrPv8EYEqUMbIWfgQLRP4AASOJnxbIm7CFjDI9A112g=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=lp16pf4fa5bvHlPvSpvDrhwHZkdd9OGGSG/fpcKCJloEXTuqiqHG8DKIDertjMCxd lkC5KHkWktFeVXzGhlrlk/laHCm63XoU9oTq6Vae6njIeJG9jXLJXrtdCfV2p7lNWv N9M4PDwzVQoeP3eILB1We1f88iGIUGmhx72a8GY4= MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: TEXT/PLAIN; charset=utf-8; format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QVMTUL8QXS00004T@mauve.mrochek.com>; Sat, 11 Aug 2018 15:58:09 -0700 (PDT) Cc: Ned Freed , extra@ietf.org Message-id: <01QVYD4HLYU800004T@mauve.mrochek.com> Date: Sat, 11 Aug 2018 15:56:16 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sat, 11 Aug 2018 16:18:53 -0400" <92650f94-50da-88be-466a-02fbab806c92@fastmail.com> References: <1533965215.3244415.1470608496.2420C769@webmail.messagingengine.com> <3b91e44b-88ec-4665-fb1e-666ffc87f03e@fastmail.com> <01QVY4QRCYRI00004T@mauve.mrochek.com> <92650f94-50da-88be-466a-02fbab806c92@fastmail.com> To: Ken Murchison Archived-At: Subject: Re: [Extra] Call for adoption, draft-gondwana-sieve-mailboxid X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2018 23:03:24 -0000 > On 08/11/2018 02:55 PM, Ned Freed wrote: > >> This extension can probably interact with :fcc. > > > > Definitely. > > > >>   Should the interop be > >> described in this draft of the :fcc draft? > > > > Why not have it build on the :fcc draft instead of creating a dependency > > in the other direction? > Agreed. > >> Additionally, the :mailboxid argument probably doesn't play well with > >> :create, or at least I don't see how it could without a mailbox name. > > > > Not sure I see the conflict. Of course you can't create a mailbox > > with the specified objectid, but in the fallback case :create would > > still be valid. > > > > It just needs to be spelled out in the document. > :create wouldn't have a mailbox name to use if :mailboxid is specified.  > :mailboxid changes the positional parameter in fileinto from a name to > an id (unless I'm reading it incorrectly). Missed that, sorry. I'm not sure I agree with this approach. Why not use the :specialuse approach instead, where :specialuse takes an argument specifying the specialuse mailbox and if it doesn't exist then the regular fileinto argument is used instead. Wouldn't a similar semantic make sense for objectid in the event that the folder with the specified objectid is gone? Ned From nobody Sat Aug 11 17:32:27 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCA0412F1AC for ; Sat, 11 Aug 2018 17:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=JOB28DEe; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=FQqrjiXh Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4YFlBPNqJbjX for ; Sat, 11 Aug 2018 17:32:23 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98D841277CC for ; Sat, 11 Aug 2018 17:32:23 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id D1E74215C6 for ; Sat, 11 Aug 2018 20:32:22 -0400 (EDT) Received: from web2 ([10.202.2.212]) by compute6.internal (MEProxy); Sat, 11 Aug 2018 20:32:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=Bx+aTSanZrVBbBLyy hrSOMNtRXXV1dllVpxGxGpyoyY=; b=JOB28DEeCI1MhaQn9Sqs3VD87aA+JMP+A U1ZAS3k6QUGkyWP7REwWY0Ve98OU0WMA0m2zxLzqtTksESIPmv52ONLNAYj9j/9z w16UCzvG6i0o6U76blxEXypUVr8tlhzHU3Nx+ggjwPqJq5hky/BHZNjq0hitd/Rb etDj2IKUXXLZj0Sg4EI8PLrLqtRlKav+gfVyTLdwro8LSKx9gvpOnLqQ0d9OdciC FJm1Nr0Ob4DVFU+0uWSq2YnsORGz763Doo2wuJbImEl5xoEhq01BUItpkLCtdG8n +4lAtiVOiTeHHB/2q4rKXKbWPG1J2DYj38x/1ITuu0G1QXyQm8LHQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=Bx+aTS anZrVBbBLyyhrSOMNtRXXV1dllVpxGxGpyoyY=; b=FQqrjiXhxRGOGhOhO7uVjA emGbSXQXCbni43RpQEF/xy5rxSGDRcT+yDop8CkdaananyGAWW8h6+t6hZyVNADB bDZ+cki9S1lotYz7DVjNShLSRNa9xIOXGi5bh0P/PaJI9BMKMstuNYtjWAhMlhiw t5doUXvZwftqLp4XzPrDiwCAujZe2YBeZsJkHoXKQAd0LfGWT2fvCrduUH9/kP1q Gz7tBJzFYwmjRFFrAFQapVtL1bhL7ojreLW3ba0l9AWK8KE2r0oOmgOmoueH6b87 DMq7dCTm2pbq1aW1mnTxDtiT5ZJ6gLiycSOdByvVQYlrRjvOBEjb9a7gyFUhc7Qg == X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 49DBF621BF; Sat, 11 Aug 2018 20:32:22 -0400 (EDT) Message-Id: <1534033942.194082.1471158928.7878DA2E@webmail.messagingengine.com> From: Bron Gondwana To: extra@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15340339421940821" X-Mailer: MessagingEngine.com Webmail Interface - ajax-9a5384d7 Date: Sun, 12 Aug 2018 10:32:22 +1000 In-Reply-To: <01QVYD4HLYU800004T@mauve.mrochek.com> References: <1533965215.3244415.1470608496.2420C769@webmail.messagingengine.com> <3b91e44b-88ec-4665-fb1e-666ffc87f03e@fastmail.com> <01QVY4QRCYRI00004T@mauve.mrochek.com> <92650f94-50da-88be-466a-02fbab806c92@fastmail.com> <01QVYD4HLYU800004T@mauve.mrochek.com> Archived-At: Subject: Re: [Extra] Call for adoption, draft-gondwana-sieve-mailboxid X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Aug 2018 00:32:26 -0000 This is a multi-part message in MIME format. --_----------=_15340339421940821 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Sun, Aug 12, 2018, at 08:56, Ned Freed wrote: > > >> On 08/11/2018 02:55 PM, Ned Freed wrote: >>>> This extension can probably interact with :fcc. >>> >>> Definitely. >>> >>>> Should the interop be >>>> described in this draft of the :fcc draft? >>> >>> Why not have it build on the :fcc draft instead of creating a >>> dependency>>> in the other direction? > >> Agreed. > > > >>>> Additionally, the :mailboxid argument probably doesn't play >>>> well with>>>> :create, or at least I don't see how it could without a mailbox >>>> name.>>> >>> Not sure I see the conflict. Of course you can't create a mailbox >>> with the specified objectid, but in the fallback case :create would>>> still be valid. >>> >>> It just needs to be spelled out in the document. > >> :create wouldn't have a mailbox name to use if :mailboxid is >> specified.>> :mailboxid changes the positional parameter in fileinto from a >> name to>> an id (unless I'm reading it incorrectly). > > Missed that, sorry. > > I'm not sure I agree with this approach. Why not use the :specialuse > approach instead, where :specialuse takes an argument specifying the > specialuse mailbox and if it doesn't exist then the regular fileinto > argument is used instead. > > Wouldn't a similar semantic make sense for objectid in the event > that the folder with the specified objectid is gone? Hrmm... yeah, I guess you could do that with a fallback of INBOX if you didn't have a different name to specify. I wasn't sure if that would be too confusing to somebody reading: fileinto :mailboxid "F213478" "INBOX.Foo"; And then having both INBOX.Foo and a different renamed folder exist. I do agree that it's more consistent to match the specialuse draft though - especially by not repurposing the positional parameter. I'm happy to update the draft and my implementation. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_15340339421940821 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Sun, Aug 12, 2018, at 08:56, Ned Freed wrote:


On 08/11/2018 02:55 PM, Ned Freed wrote:
This extension can probably interact with :fcc.

Definitely.

  Should the interop be
described in this draft of the :fcc draft?

Why not have it build on the :fcc draft instead of creating a dependency
in the other direction?

Agreed.



Additionally, the :mailboxid argument probably doesn't play well with
:create, or at least I don't see how it could without a mailbox name.

Not sure I see the conflict. Of course you can't create a mailbox
with the specified objectid, but in the fallback case :create would
still be valid.

It just needs to be spelled out in the document.

:create wouldn't have a mailbox name to use if :mailboxid is specified. 
:mailboxid changes the positional parameter in fileinto from a name to
an id (unless I'm reading it incorrectly).

Missed that, sorry.

I'm not sure I agree with this approach. Why not use the :specialuse
approach instead, where :specialuse takes an argument specifying the
specialuse mailbox and if it doesn't exist then the regular fileinto
argument is used instead.

Wouldn't a similar semantic make sense for objectid in the event
that the folder with the specified objectid is gone?

Hrmm... yeah, I guess you could do that with a fallback of INBOX if you didn't have a different name to specify.

I wasn't sure if that would be too confusing to somebody reading:

fileinto :mailboxid "F213478" "INBOX.Foo";

And then having both INBOX.Foo and a different renamed folder exist.

I do agree that it's more consistent to match the specialuse draft though - especially by not repurposing the positional parameter.  I'm happy to update the draft and my implementation.

Bron.

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


--_----------=_15340339421940821-- From nobody Sun Aug 12 04:42:08 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52192128CF2 for ; Sun, 12 Aug 2018 04:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=Gi6nue43; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Jd7ugsXu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3vyZzgps4sz7 for ; Sun, 12 Aug 2018 04:42:04 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7ABBD120049 for ; Sun, 12 Aug 2018 04:42:04 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id D1E8020C2B for ; Sun, 12 Aug 2018 07:42:03 -0400 (EDT) Received: from web2 ([10.202.2.212]) by compute6.internal (MEProxy); Sun, 12 Aug 2018 07:42:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=Khfs0FZ7xJMm7xqYw xxNml7O2MYtCiqKez30GVLoeBI=; b=Gi6nue439oUUSvsP7fMoWq6ju1CLUpvtC mnr9PdzVgBjYJ4FmcJdOWqqyQPQ/Aqx0eq08+KqM8lRNg4WqxaI+k2a0e8aznKUX TRMRtrQbhRhTrUxU6i5txkByIdncb1vNPLLLp1tRB3+OwT8r3083EdZHcEB+GBpH 0hZvEp/mNK4gq9PyIo4nIxUZMQlYnjxMBHALZN+5dzLtreLoHd/ftA76bO0NLdRV OMlYrEgHLfpBQ2YYkNcSsyasVF/84xcIGpusJ/JdEoXEl/ozj/rPt8CXpSrW9/HC hZqYSncONCE4cC/f14tYu/TQ+N3Ch8+ulzAw8bBfEZ0VVXINPb/nA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=Khfs0F Z7xJMm7xqYwxxNml7O2MYtCiqKez30GVLoeBI=; b=Jd7ugsXuBAWGnwM7jnKZ7o nvepThMvRsCe5tmSdG/bAJ72dve0q3NrtFaHKtCXIj3TjQy2dEMKO/TUrPBFtUgn TKdXR5thjIyLqwD+ZPJWev2rEo96avQmmOi2jkDwfM2IFrGT6m7zkCQN3j52s22t GuN6/4cqnzdelinJUbyqnO88y4hfp8owrCUytDeTJMfGv15fNHdhHQ50mivyWVhG 8E/WV6LzMtV78aUE92pvZAVXHyNA0hNblaVdz9kWzovyYILVMB2crYAvWx2NRpp6 qKYPLvp31TmkMbFrRy60ZVu/OswlFnAWXYEMT0yDFuPCQ2bVuqW+wqxGGrHwjHbw == X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 893E0621BF; Sun, 12 Aug 2018 07:42:03 -0400 (EDT) Message-Id: <1534074123.325963.1471428976.69051499@webmail.messagingengine.com> From: Bron Gondwana To: extra@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15340741233259630" X-Mailer: MessagingEngine.com Webmail Interface - ajax-9a5384d7 References: <1533965215.3244415.1470608496.2420C769@webmail.messagingengine.com> <3b91e44b-88ec-4665-fb1e-666ffc87f03e@fastmail.com> <01QVY4QRCYRI00004T@mauve.mrochek.com> <92650f94-50da-88be-466a-02fbab806c92@fastmail.com> <01QVYD4HLYU800004T@mauve.mrochek.com> <1534033942.194082.1471158928.7878DA2E@webmail.messagingengine.com> In-Reply-To: <1534033942.194082.1471158928.7878DA2E@webmail.messagingengine.com> Date: Sun, 12 Aug 2018 21:42:03 +1000 Archived-At: Subject: Re: [Extra] Call for adoption, draft-gondwana-sieve-mailboxid X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Aug 2018 11:42:06 -0000 This is a multi-part message in MIME format. --_----------=_15340741233259630 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" OK - I've posted version -01 which I believe addresses all the concerns :) * Switch to :mailboxid tagged parameter value with fallback mailbox name.* Document interation with special-use. * Document security considerations around :mailboxid and :create. I've also updated our implementation, which was very easy. (and I forgot to mention - I also documented interaction with :fcc. I'll add that to my .mdown file now) Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_15340741233259630 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
OK - I've posted version -01 which I believe addresses all the concerns :)

* Switch to :mailboxid tagged parameter value with fallback mailbox name.
* Document interation with special-use.
* Document security considerations around :mailboxid and :create.

I've also updated our implementation, which was very easy.

(and I forgot to mention - I also documented interaction with :fcc.  I'll add that to my .mdown file now)

Bron.

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


--_----------=_15340741233259630-- From nobody Sun Aug 12 07:05:34 2018 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FAE4130DEA; Sun, 12 Aug 2018 07:05:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: extra@ietf.org Message-ID: <153408273239.11884.13419804291548749198@ietfa.amsl.com> Date: Sun, 12 Aug 2018 07:05:32 -0700 Archived-At: Subject: [Extra] I-D Action: draft-ietf-extra-sieve-fcc-04.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Aug 2018 14:05:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email mailstore and eXtensions To Revise or Amend WG of the IETF. Title : Sieve Extension: File Carbon Copy (Fcc) Authors : Kenneth Murchison Bron Gondwana Filename : draft-ietf-extra-sieve-fcc-04.txt Pages : 13 Date : 2018-08-12 Abstract: The Sieve Email Filtering Language provides a number of action commands, some of which can generate additional messages on behalf of the user. This document defines an extension to such commands to allow a copy of any generated message to be filed into a target mailbox. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-extra-sieve-fcc/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-extra-sieve-fcc-04 https://datatracker.ietf.org/doc/html/draft-ietf-extra-sieve-fcc-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-sieve-fcc-04 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 Aug 13 23:35:55 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF6F7126CB6; Mon, 13 Aug 2018 23:35:52 -0700 (PDT) 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=cVOCy++d; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=NxGU54eN Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8unhNoKj9Kov; Mon, 13 Aug 2018 23:35:51 -0700 (PDT) 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 4C1D21292AD; Mon, 13 Aug 2018 23:35:51 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 2D94E258; Tue, 14 Aug 2018 02:35:49 -0400 (EDT) Received: from imap22 ([10.202.2.72]) by compute6.internal (MEProxy); Tue, 14 Aug 2018 02:35:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc:content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=WRrn9BhocsU3s+qvsp80Oyn+A2zp8EPotB+KWFxGI XI=; b=cVOCy++dbY3kmrFfFbZBzX1SIbAPDv/t1kciZoSSMfjLioV8FCQpx7pkp KZUyL7AlRlXigHgJ2jFaa+shOrSXcIHWo36g9cSeDYciAztzRXR6RjP8/RztwKdY tW13TaO+suaUf3MfStpiclB8RHQr+/BYCgeMdR314935mJKpK1EjmS+K/5E4fnK2 06CrwPN98rzxyNrakS7vqCSJ4DGkDbFntOk2RJV/zhaQgm4i1e7bT05wk5E3xaNC kGjb2i7wLjeIfEsY1oGbIeA3gYKNAvSibyxB0HyhZKrKb5uQJmttRvx2QmNkPTOB OXh/tJ0rA5SReqo2xl5K6K0TxVylQ== 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-sender:x-me-sender :x-sasl-enc; s=fm3; bh=WRrn9BhocsU3s+qvsp80Oyn+A2zp8EPotB+KWFxGI XI=; b=NxGU54eNOFjmt57r7gkw4sHvdx1affShRqGN8KpJ2l8iwclDIYERu0Z7k UHTveoB3bz2vt0qaRzryVSw1zzHgxAYDsyzpkZQ3j2a56zfKVoL58Lm5lZKDfDFm 57vsNkxLGMbMB3x86C8hN4IqMmiLhviTpG1PZ3xWqQ1ommOufJEo6BI8f83d16He SnsocUIlgtjJfUi+rsU6pVaryebtRWEDRvxPQr8ZeGe0Kz3IA12R7q1M8VUdRddp Y6FSvefa3/TGHPbej2VHoX/AwiaE18DsxsarZQGj+G8+wCjhuc6HF2SdQdt6cDL5 hONtAB+msLTbajpGsoJcZwTfxZIxQ== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 41E8BEEB1; Tue, 14 Aug 2018 02:35:45 -0400 (EDT) Message-Id: <6404a359-a564-40c8-8236-985b978a2dc9@sloti22d1t06> User-Agent: Cyrus-JMAP/3.1.5-214-gc84e6bd-fmnext-20180810v1 x-jmap-identity-id: 56629417 In-Reply-To: <153357190193.26706.7945676930102187801.idtracker@ietfa.amsl.com> References: <153357190193.26706.7945676930102187801.idtracker@ietfa.amsl.com> Date: Tue, 14 Aug 2018 02:35:45 -0400 From: Bron Gondwana To: IETF-Announce , The IESG Cc: extra@ietf.org, Jiankang Yao , The IESG , extra-chairs@ietf.org, Alexey Melnikov , draft-ietf-extra-imap-objectid@ietf.org, RFC Errata System Content-Type: multipart/alternative; boundary=fb67075441d6484f8851027a19bf3360 Archived-At: Subject: Re: [Extra] =?utf-8?q?Protocol_Action=3A_=27IMAP_Extension_for_objec?= =?utf-8?q?t_identifiers=27_to_Proposed_Standard_=28draft-ietf-extra-imap-?= =?utf-8?q?objectid-08=2Etxt=29?= X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2018 06:35:53 -0000 --fb67075441d6484f8851027a19bf3360 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Advance notice, I'm going to ask (either during auth48 or beforehand if = there's a possibility) to add the following section to this document, ba= sed on feedback received on the mailing list which I failed to include, = and based on reading Mark Nottingham's blog about interpreting requireme= nts and what to do if you see something which the RFC says "MUST NOT" ha= ppen: https://www.mnot.net/blog/2018/07/31/read_rfc Sorry about the late notice! I'm thinking something like this... =3D=3D=3D=3D=3D Section: Advice to client implementers In cases of server failure and disaster recovery, or misbehaving servers= , it is possible that a client will be sent invalid information (e.g. i= dentical objectids, or objectids which have changed where they MUST NOT = change according to this document). In a case where a client detects inconsistent objectid responses from a = server, it SHOULD fall back to relying on RFC3501 guarantees. For simpli= city, a client MAY choose instead discard its entire cache and resync a= ll state from the server. Client authors protecting against server misbehavior MUST ensure that th= eir design can not get into an infinite loop of discarding cache and fet= ching the same data repeatedly without user interaction. =3D=3D=3D=3D=3D Regards, Bron. On Tue, Aug 7, 2018, at 02:11, The IESG wrote: > The IESG has approved the following document: > - 'IMAP Extension for object identifiers' > =C2=A0 (draft-ietf-extra-imap-objectid-08.txt) as Proposed Standard >=20 > This document is the product of the Email mailstore and eXtensions To = Revise > or Amend Working Group. >=20 > The IESG contact persons are Adam Roach, Alexey Melnikov and Ben Campb= ell. >=20 > A URL of this Internet Draft is: > https://datatracker.ietf.org/doc/draft-ietf-extra-imap-objectid/ >=20 >=20 >=20 >=20 > Technical Summary >=20 > =C2=A0=C2=A0 This document updates RFC3501 (IMAP4rev1) with persistent= identifiers > =C2=A0=C2=A0 on mailboxes and messages to allow clients to more effici= ently re-use > =C2=A0=C2=A0 cached data when resources have changed location on the s= erver. >=20 > Working Group Summary >=20 > =C2=A0 The EXTRA WG meeting in IETF 101 had detailed discussion about = this draft. > =C2=A0 The editor had updated it accordingly. Before WGLC, several exp= erts reviewed > =C2=A0 the draft in detail. All identified issues were reflected in th= e new version of the=C2=A0 > =C2=A0 draft. During WGLC, a minor issue was identified and fixed in t= he new version.=C2=A0 > =C2=A0 The WG has looked throught this document in detail. >=20 > Document Quality >=20 > =C2=A0 The document is in good shape and is ready to be published. > =C2=A0 The document is based on 2 similar private extensions by Gmail = and Dovecot. > =C2=A0 The WG hopes to move this document quickly as IMAP4rev2 may wan= t to include it. >=20 > Personnel >=20 > =C2=A0 Document Shepherd - Jiankang Yao (EXTRA co-chair) > =C2=A0 Responsible Area Director - Alexey Melnikov >=20 > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra >=20 -- =C2=A0 Bron Gondwana, CEO, FastMail Pty Ltd =C2=A0 brong@fastmailteam.com --fb67075441d6484f8851027a19bf3360 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Advance notice, I'm going to ask (either during auth48 or = beforehand if there's a possibility) to add the following section to thi= s document, based on feedback received on the mailing list which I faile= d to include, and based on reading Mark Nottingham's blog about interpre= ting requirements and what to do if you see something which the RFC says= "MUST NOT" happen:


Sorry about the late notice!

I'm thinking s= omething like this...

=3D=3D=3D=3D=3D

Sect= ion: Advice to client implementers

In cases of server fai= lure and disaster recovery, or misbehaving servers, it is possible that= a client will be sent invalid information (e.g. identical objectids, or= objectids which have changed where they MUST NOT change according to th= is document).

In a case where a client detects inconsiste= nt objectid responses from a server, it SHOULD fall back to relying on R= FC3501 guarantees. For simplicity, a client MAY choose instead discard i= ts entire cache and resync all state from the server.

Cl= ient authors protecting against server misbehavior MUST ensure that thei= r design can not get into an infinite loop of discarding cache and fetch= ing the same data repeatedly without user interaction.

=3D= =3D=3D=3D=3D

Regards,

Bron.

<= div style=3D"font-family:Arial;">
On Tue, Aug 7, 2018, at 02:11, The IESG wrote:
= The IESG has approved the following document:
- 'IMAP Extension for object identifiers'
  (draft-ietf-extra-imap-objectid-08.= txt) as Proposed Standard
This document is the product of= the Email mailstore and eXtensions To Revise
or Amend Working Group.

The IESG contact= persons are Adam Roach, Alexey Melnikov and Ben Campbell.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-extra-imap-objectid/




Technical Summary

   This document updates RF= C3501 (IMAP4rev1) with persistent identifiers
   on mailboxes and messages to allow clients= to more efficiently re-use
&= nbsp;  cached data when resources have changed location on the serv= er.

Working Group Summary

  The EXTRA= WG meeting in IETF 101 had detailed discussion about this draft.
  The editor had updated it ac= cordingly. Before WGLC, several experts reviewed
  the draft in detail. All identified issues we= re reflected in the new version of the 
  draft. During WGLC, a minor issue was identified = and fixed in the new version. 
  The WG has looked throught this document in detail.

Document Quality
  The document is in good = shape and is ready to be published.
  The document is based on 2 similar private extensions by G= mail and Dovecot.
  The = WG hopes to move this document quickly as IMAP4rev2 may want to include = it.

Personnel
=
  Document Shepherd - J= iankang Yao (EXTRA co-chair)
=   Responsible Area Director - Alexey Melnikov

_______= ________________________________________
Extra mailing list
Extra@ietf.org
https://www.= ietf.org/mailman/listinfo/extra


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


--fb67075441d6484f8851027a19bf3360-- From nobody Tue Aug 14 16:01:23 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCE40130DD1; Tue, 14 Aug 2018 08:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 5-rC7vA4-H7p; Tue, 14 Aug 2018 08:23:36 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE2FF130DC9; Tue, 14 Aug 2018 08:23:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 6C9FB1D2BB0; Tue, 14 Aug 2018 08:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ueHp8tIjg7pb; Tue, 14 Aug 2018 08:23:16 -0700 (PDT) Received: from [10.0.0.5] (c-67-180-18-141.hsd1.ca.comcast.net [67.180.18.141]) by c8a.amsl.com (Postfix) with ESMTPSA id 982F81D2BAD; Tue, 14 Aug 2018 08:23:15 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Lynne Bartholomew In-Reply-To: <6404a359-a564-40c8-8236-985b978a2dc9@sloti22d1t06> Date: Tue, 14 Aug 2018 08:23:34 -0700 Cc: IETF-Announce , "iesg-secretary@ietf.org IESG" , extra@ietf.org, Jiankang Yao , The IESG , extra-chairs@ietf.org, Alexey Melnikov , draft-ietf-extra-imap-objectid@ietf.org, RFC Editor Content-Transfer-Encoding: quoted-printable Message-Id: <85A0C058-E4AE-4189-9224-C932D70EA0D6@amsl.com> References: <153357190193.26706.7945676930102187801.idtracker@ietfa.amsl.com> <6404a359-a564-40c8-8236-985b978a2dc9@sloti22d1t06> To: Bron Gondwana X-Mailer: Apple Mail (2.1878.6) Archived-At: X-Mailman-Approved-At: Tue, 14 Aug 2018 16:01:22 -0700 Subject: Re: [Extra] Protocol Action: 'IMAP Extension for object identifiers' to Proposed Standard (draft-ietf-extra-imap-objectid-08.txt) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2018 15:23:38 -0000 Dear Bron, Thank you for the heads-up. We have flagged this in our database record = for this document; it will be addressed when the document is edited. RFC Editor/lb On Aug 13, 2018, at 11:35 PM, Bron Gondwana = wrote: > Advance notice, I'm going to ask (either during auth48 or beforehand = if there's a possibility) to add the following section to this document, = based on feedback received on the mailing list which I failed to = include, and based on reading Mark Nottingham's blog about interpreting = requirements and what to do if you see something which the RFC says = "MUST NOT" happen: >=20 > https://www.mnot.net/blog/2018/07/31/read_rfc >=20 > Sorry about the late notice! >=20 > I'm thinking something like this... >=20 > =3D=3D=3D=3D=3D >=20 > Section: Advice to client implementers >=20 > In cases of server failure and disaster recovery, or misbehaving = servers, it is possible that a client will be sent invalid information = (e.g. identical objectids, or objectids which have changed where they = MUST NOT change according to this document). >=20 > In a case where a client detects inconsistent objectid responses from = a server, it SHOULD fall back to relying on RFC3501 guarantees. For = simplicity, a client MAY choose instead discard its entire cache and = resync all state from the server. >=20 > Client authors protecting against server misbehavior MUST ensure that = their design can not get into an infinite loop of discarding cache and = fetching the same data repeatedly without user interaction. >=20 > =3D=3D=3D=3D=3D >=20 > Regards, >=20 > Bron. >=20 >=20 > On Tue, Aug 7, 2018, at 02:11, The IESG wrote: >> The IESG has approved the following document: >> - 'IMAP Extension for object identifiers' >> (draft-ietf-extra-imap-objectid-08.txt) as Proposed Standard >>=20 >> This document is the product of the Email mailstore and eXtensions To = Revise >> or Amend Working Group. >>=20 >> The IESG contact persons are Adam Roach, Alexey Melnikov and Ben = Campbell. >>=20 >> A URL of this Internet Draft is: >> https://datatracker.ietf.org/doc/draft-ietf-extra-imap-objectid/ >>=20 >>=20 >>=20 >>=20 >> Technical Summary >>=20 >> This document updates RFC3501 (IMAP4rev1) with persistent = identifiers >> on mailboxes and messages to allow clients to more efficiently = re-use >> cached data when resources have changed location on the server. >>=20 >> Working Group Summary >>=20 >> The EXTRA WG meeting in IETF 101 had detailed discussion about this = draft. >> The editor had updated it accordingly. Before WGLC, several experts = reviewed >> the draft in detail. All identified issues were reflected in the = new version of the=20 >> draft. During WGLC, a minor issue was identified and fixed in the = new version.=20 >> The WG has looked throught this document in detail. >>=20 >> Document Quality >>=20 >> The document is in good shape and is ready to be published. >> The document is based on 2 similar private extensions by Gmail and = Dovecot. >> The WG hopes to move this document quickly as IMAP4rev2 may want to = include it. >>=20 >> Personnel >>=20 >> Document Shepherd - Jiankang Yao (EXTRA co-chair) >> Responsible Area Director - Alexey Melnikov >>=20 >> _______________________________________________ >> Extra mailing list >> Extra@ietf.org >> https://www.ietf.org/mailman/listinfo/extra >>=20 >=20 > -- > Bron Gondwana, CEO, FastMail Pty Ltd > brong@fastmailteam.com From nobody Thu Aug 16 08:21:57 2018 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 41D1A130D7A; Thu, 16 Aug 2018 08:21:50 -0700 (PDT) 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.83.1 Auto-Submitted: auto-generated Precedence: bulk CC: extra@ietf.org, brong@fastmailteam.com, draft-ietf-extra-imap-savedate@ietf.org, extra-chairs@ietf.org, alexey.melnikov@isode.com, Bron Gondwana 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: <153443291022.12140.11418492562901656774.idtracker@ietfa.amsl.com> Date: Thu, 16 Aug 2018 08:21:50 -0700 Archived-At: Subject: [Extra] Last Call: (Internet Message Access Protocol (IMAP) - SAVEDATE Extension) to Proposed Standard X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2018 15:21:50 -0000 The IESG has received a request from the Email mailstore and eXtensions To Revise or Amend WG (extra) to consider the following document: - 'Internet Message Access Protocol (IMAP) - SAVEDATE Extension' 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 2018-08-30. 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 adds a new capability called "SAVEDATE" to the Internet Message Access Protocol (IMAP). It defines a new IMAP message attribute called 'save date' that, unlike the existing 'internal date' attribute, always indicates the moment at which the message was saved in its current mailbox. The SAVEDATE capability extends the FETCH command with the means to retrieve the save date attribute and it extends the SEARCH command to allow using that attribute in searching criteria. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-extra-imap-savedate/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-extra-imap-savedate/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Aug 20 19:37:30 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11884130E04; Mon, 20 Aug 2018 19:37:28 -0700 (PDT) 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, 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 OL4E-JYQB5eq; Mon, 20 Aug 2018 19:37:25 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A619D130DF6; Mon, 20 Aug 2018 19:37:25 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id B6EAAB80D4D; Mon, 20 Aug 2018 19:37:12 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, extra@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20180821023712.B6EAAB80D4D@rfc-editor.org> Date: Mon, 20 Aug 2018 19:37:12 -0700 (PDT) Archived-At: Subject: [Extra] =?utf-8?q?RFC_8440_on_IMAP4_Extension_for_Returning_MYRI?= =?utf-8?q?GHTS_Information_in_Extended_LIST?= X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2018 02:37:28 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8440 Title: IMAP4 Extension for Returning MYRIGHTS Information in Extended LIST Author: K. Murchison, B. Gondwana Status: Standards Track Stream: IETF Date: August 2018 Mailbox: murch@fastmailteam.com, brong@fastmailteam.com Pages: 6 Characters: 11969 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-extra-imap-list-myrights-07.txt URL: https://www.rfc-editor.org/info/rfc8440 DOI: 10.17487/RFC8440 This document defines an extension to the Internet Message Access Protocol (IMAP) LIST command that allows the client to request the set of rights that the logged-in user has been granted on mailboxes, along with other information typically returned by the LIST command. This document is a product of the Email mailstore and eXtensions To Revise or Amend Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Fri Aug 24 13:27:22 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3311130DDA; Fri, 24 Aug 2018 13:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 9O9msR5tXrsE; Fri, 24 Aug 2018 13:27:13 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 584A0130DC0; Fri, 24 Aug 2018 13:27:13 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id B8A11B8163F; Fri, 24 Aug 2018 13:26:57 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, extra@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20180824202657.B8A11B8163F@rfc-editor.org> Date: Fri, 24 Aug 2018 13:26:57 -0700 (PDT) Archived-At: Subject: [Extra] =?utf-8?q?RFC_8437_on_IMAP_UNAUTHENTICATE_Extension_for_?= =?utf-8?q?Connection_Reuse?= X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2018 20:27:15 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8437 Title: IMAP UNAUTHENTICATE Extension for Connection Reuse Author: C. Newman Status: Standards Track Stream: IETF Date: August 2018 Mailbox: chris.newman@oracle.com Pages: 11 Characters: 23574 Updates: RFC 3501 I-D Tag: draft-ietf-extra-imap-unauth-01.txt URL: https://www.rfc-editor.org/info/rfc8437 DOI: 10.17487/RFC8437 This specification extends the Internet Message Access Protocol (IMAP) to allow an administrative client to reuse the same IMAP connection on behalf of multiple IMAP user identities. This document is a product of the Email mailstore and eXtensions To Revise or Amend Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Fri Aug 24 13:27:40 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BCAD130E2A; Fri, 24 Aug 2018 13:27:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 ByUZeHblk85m; Fri, 24 Aug 2018 13:27:18 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DE41130E3B; Fri, 24 Aug 2018 13:27:18 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id CA8C8B81646; Fri, 24 Aug 2018 13:27:02 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, extra@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20180824202702.CA8C8B81646@rfc-editor.org> Date: Fri, 24 Aug 2018 13:27:02 -0700 (PDT) Archived-At: Subject: [Extra] =?utf-8?q?RFC_8438_on_IMAP_Extension_for_STATUS=3DSIZE?= X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2018 20:27:29 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8438 Title: IMAP Extension for STATUS=SIZE Author: S. Bosch Status: Standards Track Stream: IETF Date: August 2018 Mailbox: stephan.bosch@dovecot.fi Pages: 6 Characters: 10672 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-extra-imap-status-size-02.txt URL: https://www.rfc-editor.org/info/rfc8438 DOI: 10.17487/RFC8438 This document adds a new capability called "STATUS=SIZE" to the Internet Message Access Protocol (IMAP). It allows retrieving the total storage size of a mailbox with a single STATUS command rather than retrieving and summing the sizes of all individual messages in that mailbox. This document is a product of the Email mailstore and eXtensions To Revise or Amend Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Tue Aug 28 09:10:40 2018 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8628C130F01; Tue, 28 Aug 2018 09:10:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Sean Turner To: Cc: extra@ietf.org, ietf@ietf.org, draft-ietf-extra-imap-savedate.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153547263252.23664.3169930979223430348@ietfa.amsl.com> Date: Tue, 28 Aug 2018 09:10:32 -0700 Archived-At: Subject: [Extra] Secdir last call review of draft-ietf-extra-imap-savedate-01 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2018 16:10:33 -0000 Reviewer: Sean Turner Review result: Ready The only thing I really wondered about was whether disclosing this new date would leak anything to an attacker. But, if the session is TLS-protected you're good and if it's not well you can get the actual message so whatever. Can't think of anything else. PS - When I first read the subject line I was like oh interesting we're doing something cute with the "savethedate" field :)