From nobody Wed Jan 3 07:55:38 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 A3C51127873; Wed, 3 Jan 2018 07:55:36 -0800 (PST) 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.68.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151499493662.30944.11702671671689594133@ietfa.amsl.com> Date: Wed, 03 Jan 2018 07:55:36 -0800 Archived-At: Subject: [Extra] I-D Action: draft-ietf-extra-imap-list-myrights-01.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 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, 03 Jan 2018 15:55:37 -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 for Returning MYRIGHTS Information in Extended LIST Authors : Kenneth Murchison Bron Gondwana Filename : draft-ietf-extra-imap-list-myrights-01.txt Pages : 6 Date : 2018-01-03 Abstract: This document defines an extension to the to 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-extra-imap-list-myrights/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-extra-imap-list-myrights-01 https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap-list-myrights-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-imap-list-myrights-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jan 3 16:38:02 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 A3586124D37 for ; Wed, 3 Jan 2018 16:38:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=gSBrPgHU; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=lFoQQWD9 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uysDaTJ4lNv0 for ; Wed, 3 Jan 2018 16:37:59 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C4CC126C3D for ; Wed, 3 Jan 2018 16:37:58 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 1FDFD209B0; Wed, 3 Jan 2018 19:37:58 -0500 (EST) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Wed, 03 Jan 2018 19:37:58 -0500 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=fm1; bh=3uXZfdPN94bFRyZQgKZWbUEjAUsrp e29xQ9bHOozo+A=; b=gSBrPgHU9CxPS1w3QB9lsc/b1WDW8bERIYE8CtnDXA6Y+ aoTGFOLwltdw/+pg1jC54aYgOMhsNxf92vrPTUtlgHmVtJNDEsvB8Wc5WtI8LNU+ jJ8TnedTbDDheOvH8oWN8wYRTMUicFfya+ufGF4PEZ8VsAUidHbDhYbTjI+9l1cO y2Zik/R28CevOW1iYEhe49jplANREopzMtfqqnTm0PVjLN5iKe7eccKG4D6YZ57u X0KH1IQzayNagsJXDg48bYtPqAxfRZ+Tg8/uWk3zkmIHNy5vBavq2XlQueVwBrGe 5dQCCYi8odjp3mzZ6hPH8r1SuRwfZH83snggr92cA== 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=fm1; bh=3uXZfdPN94bFRyZQgKZWbUEjAUsrp e29xQ9bHOozo+A=; b=lFoQQWD9mGDgLZr8ogyb8eL2nK7Q9CR5xKIYR3vjDS9Jt OS/WMwGDsbMIP5wrApmDRQMiR4Y5fSZVFX952NriQQIkzrBvZ1EEAkUnuPwDf0DL UjqjzBtPwRPONf/zeVBZn3ICXMa5+pE45vTiRLO8Xmv/58OZ/0JCU162M/o2kC7E L9xJzMqAS//8mjJKNSHBY4oMeKRIGJmV7WtZPzmqAwahHj1BQ5VnH715hPF5ngcO Q0SSXWUSB5MarlHCUKepwqB/NmRzMB3uF3TeFRNneJLBpppyez3GHO8Fyw0pPzpg pV4aMF0FjN77Ekh4IVy2T+95d06Xa7itKhapdmqKg== X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id D60D29E259; Wed, 3 Jan 2018 19:37:57 -0500 (EST) Message-Id: <1515026277.3124718.1223557384.0EE2A362@webmail.messagingengine.com> From: Bron Gondwana To: extra@ietf.org Cc: stephan.bosch@dovecot.fi MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_151502627731247180" X-Mailer: MessagingEngine.com Webmail Interface - ajax-cc9a457c Date: Thu, 04 Jan 2018 11:37:57 +1100 Archived-At: Subject: [Extra] STATUS=SIZE todos X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 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, 04 Jan 2018 00:38:01 -0000 This is a multi-part message in MIME format. --_----------=_151502627731247180 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" Hi Stephan, I've created two issues on github for you with two things that need to be resolved for STATUS=SIZE before it goes on towards publication. Sorry about the delay. https://github.com/ietfextra/tracking/issues/10 https://github.com/ietfextra/tracking/issues/11 And of course the copyright date now needs to be 2018 :) Cheers, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_151502627731247180 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
Hi Stephan,

I've created two issues on github for you with two things that need to be resolved for STATUS=SIZE before it goes on towards publication.  Sorry about the delay.


And of course the copyright date now needs to be 2018 :)

Cheers,

Bron.

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


--_----------=_151502627731247180-- From nobody Wed Jan 3 16:54:59 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 86763126C3D for ; Wed, 3 Jan 2018 16:54:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=r/Uw++QG; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=NO96DB1w Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8aM01x6kG8qE for ; Wed, 3 Jan 2018 16:54:56 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6CA41243F3 for ; Wed, 3 Jan 2018 16:54:56 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id A1ADE20FD4; Wed, 3 Jan 2018 19:54:55 -0500 (EST) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Wed, 03 Jan 2018 19:54:55 -0500 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=fm1; bh=AGXQPh90BA3SwXz8xBIGPh8fsyMPq 5mPWnrfSogWpDU=; b=r/Uw++QGTtpu5unhTXhE4yfebSx0wxgW/REm7sSFEdjJc /pxgehRdwtdxuL3/gN4RNTLW54mDR7GTMkaqAA4kC09ehZgE/AnZ2njjtqDZNv/6 HPOBDuMSmNpNduhqlOGBgy0cD1Gt7Bm98BSTulM9pKhXkqMKnec7Irj9vj0pYkOB X8Cuum8nRDQwO3kB9lwrB1833CjnIhbplRBbjLiq5LXZ+ANRkxLnvioxA4VfVBgh Tcr09+SArcFtUnkuJsZ8O4Dqy3zpMLN5bQz7biTNXn/YcrCmlgDFffkSyydX7cVB 4MiIVLgbUUgBgudf+VnDdzf7DcqLyWQ4+EaDcf75g== 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=fm1; bh=AGXQPh90BA3SwXz8xBIGPh8fsyMPq 5mPWnrfSogWpDU=; b=NO96DB1weCve7z9T4U2vUjgpLdb1XO74P3XZf/8bmmbXK oh4b7hkiFD+yy1VJoqATb+DhNQUykeKwr9DQy+0A3APWdEoQt9tH00tf3A3WGYwd 7oFVl0wohbfsQn2w2JsB0s7ZqeDvwIDTtKVolFmQl4iRWsWIwpUGTYy/e3MKG5m6 lV6XPRJgwU6Yh4husIMvQ2Tqx2+U3dtX+EEhOrVboYQxLEXr0t5AF/wib44KRqQu dcV8+a0TXauRY6oxuRp03Sp6rfliwchItJhgRLjhaEBcX233Ol9Kv1jheAy0C2L/ Ja9IFHEXNDssGNWLY0MAowhzJdw9/9KApBrVpHs9w== X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 636519E259; Wed, 3 Jan 2018 19:54:55 -0500 (EST) Message-Id: <1515027295.3130822.1223568456.6D1D8F15@webmail.messagingengine.com> From: Bron Gondwana To: extra@ietf.org Cc: stephan.bosch@dovecot.fi MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_151502729531308220" X-Mailer: MessagingEngine.com Webmail Interface - ajax-cc9a457c Date: Thu, 04 Jan 2018 11:54:55 +1100 Archived-At: Subject: [Extra] SAVEDATE updated required X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 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, 04 Jan 2018 00:54:58 -0000 This is a multi-part message in MIME format. --_----------=_151502729531308220 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" HI Stephan, I've also created a couple of tasks for SAVEDATE: https://github.com/ietfextra/tracking/issues/12 https://github.com/ietfextra/tracking/issues/13 Of course, reading the standard that closely is really good, because it also forced me to think about it! I have some opinions! 1: if the mailbox doesn't support storing save date, the behaviour should be to return SAVEDATE NIL/ 2: if the mailbox doesn't support storing save date, the SEARCH extensions should return an error if used, rather than a result, since there's no way to calculate a sensible answer to any of those three. SAVEDBEFORE Messages whose save date (disregarding time and timezone) is earlier than the specified date. SAVEDON Messages whose save date (disregarding time and timezone) is within the specified date. SAVEDSINCE Messages whose save date (disregarding time and timezone) is within or later than the specified date. The "disregarding time and timezone" is a horrorshow if you have users in multiple timezones, but RFC3501 says that's how BEFORE and AFTER work for INTERNALDATE commands, so I guess we're stuck with it. 3: Do we need to define SAVEDATE as a SORT key extending RFC5256 as well? In theory it should always sort the same as UID. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_151502729531308220 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
HI Stephan,

I've also created a couple of tasks for SAVEDATE:


Of course, reading the standard that closely is really good, because it also forced me to think about it!  I have some opinions!

1: if the mailbox doesn't support storing save date, the behaviour should be to return SAVEDATE NIL/

2: if the mailbox doesn't support storing save date, the SEARCH extensions should return an error if used, rather than a result, since there's no way to calculate a sensible answer to any of those three.


   SAVEDBEFORE <date>
      Messages whose save date (disregarding time and timezone) is
      earlier than the specified date.

   SAVEDON <date>
      Messages whose save date (disregarding time and timezone) is
      within the specified date.

   SAVEDSINCE <date>
      Messages whose save date (disregarding time and timezone) is
      within or later than the specified date.


The "disregarding time and timezone" is a horrorshow if you have users in multiple timezones, but RFC3501 says that's how BEFORE and AFTER work for INTERNALDATE commands, so I guess we're stuck with it.


3: Do we need to define SAVEDATE as a SORT key extending RFC5256 as well?  In theory it should always sort the same as UID.

Bron.

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


--_----------=_151502729531308220-- From nobody Wed Jan 3 17:08:18 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 97CAC12D838 for ; Wed, 3 Jan 2018 17:08:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=PdoozbK/; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=c7kMyewQ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PyC1fhtYUoET for ; Wed, 3 Jan 2018 17:08:15 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A398612D7F7 for ; Wed, 3 Jan 2018 17:08:15 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id E3AC620BB7; Wed, 3 Jan 2018 20:08:14 -0500 (EST) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Wed, 03 Jan 2018 20:08:14 -0500 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=fm1; bh=4ADd5C rT5RqFz3HBLY5atqzsmNw8qH/XJszoekkBrwE=; b=PdoozbK/pVTQ9bosof/mqT MFmzNnT+9MsAQYGBdWOvDKCJBHqpEnSD/JDGNZqkO9LBLzp1iwdsZHwv6xOc0Jok /x/P4oAB6oRv9zHEG8hk0nu8w1HePCubLE6ndgFF0izIJ7q5ui045N0NvJVZSSm4 JA5IWM2r+IR0+X+nXxkjHIO4NcO1qqdaJ/C/z+sMHnuwKO5UlXybwvpnSgmTgx1P g9Fhtc1DufwjhbsdVOKx4ePZlEPSh8bcv6fi63jYVZ7/DUrNrip029RLGuOdRL0n 2oZo61bjmdvnI7A9TXIjHHyYmV2+C7EckVh/WVyILmlKpB3lvFuHVDK7A0gzo4pA == DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=4ADd5C rT5RqFz3HBLY5atqzsmNw8qH/XJszoekkBrwE=; b=c7kMyewQwluMc0RXNJ3KoB PvQUQRGDelnb9i2oP8yGzwjXSxm8T9t4gPa5DkzWKG74hcwvnKOrcbvvs9Tfreee O14hw9Hil+oei9qKAiZjB+ajFujzZrHuxvcknNk50gJFSKwkqerGls6oOy/HBgOY 0mNyZjjv6TpRS6Y08niUj4QT+bsbZg+NHoBuh9hy4ICfLjZujTh4e5wQTu1xEaFm TSpI3MjM7DPmqjnh8lDcVZmPjSFJclGJrkt5GQGPOtzvEiYq/CJeJgoMv96xallP 2gRR3pgJtPqqBysyxfkYLxI+G2Bl40TGwq3XfiRi8orThgwDCl5ADLHMkhR+hT1A == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id A9D339E259; Wed, 3 Jan 2018 20:08:14 -0500 (EST) Message-Id: <1515028094.3135331.1223576440.053F86DC@webmail.messagingengine.com> From: Bron Gondwana To: Stan Kalisch Cc: extra@ietf.org, Ned Freed , Murchison Ken MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_151502809431353312" X-Mailer: MessagingEngine.com Webmail Interface - ajax-cc9a457c Date: Thu, 04 Jan 2018 12:08:14 +1100 In-Reply-To: References: <1510734636.1704307.1173072248.27572238@webmail.messagingengine.com> Archived-At: Subject: Re: [Extra] Sieve REJECT and :fcc [was Re: Meeting minutes and notes from today] X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 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, 04 Jan 2018 01:08:17 -0000 This is a multi-part message in MIME format. --_----------=_151502809431353312 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Fri, 17 Nov 2017, at 09:06, Stan Kalisch wrote: > > Hi, > > On Nov 15, 2017, at 3:30 AM, Bron Gondwana > wrote:>> *There is an open question for this one:* >> >> https://datatracker.ietf.org/doc/draft-ietf-extra-sieve-fcc/ >> >> Ned Freed objected to supporting :fcc for the REJECT action because >> it allows the sieve server to "lie" about whether it's keeping a copy >> of the message. There was debate about whether we should stop people >> lying at this level, especially since a mail flow could take a copy >> of every single email before it reached sieve.> > I haven't been able to watch any video of the meeting yet, but would > it be fair to say the main points of this debate were laid out in this > thread on the Sieve mailing list earlier this year?> > https://www.ietf.org/mail-archive/web/sieve/current/msg05362.html > I don't know if this was ever resolved. I prefer the user to be allowed to lie, Ned objects to that. I don't actually care that much though, so I'm happy to say no :fcc on REJECT. It's not like I would actually use it because sieve REJECT is bad anyway, it creates backscatter. So Ken - I'm happy to go ahead with "not supported on reject". The other open issue was separate capability string. I don't think that's necessary, and nobody else seems to have commented on it. I've created one task for each: https://github.com/ietfextra/tracking/issues/14 https://github.com/ietfextra/tracking/issues/15 Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_151502809431353312 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Fri, 17 Nov 2017, at 09:06, Stan Kalisch wrote:

Hi,

On Nov 15, 2017, at 3:30 AM, Bron Gondwana <brong@fastmailteam.com> wrote:
There is an open question for this one:


Ned Freed objected to supporting :fcc for the REJECT action because it allows the sieve server to "lie" about whether it's keeping a copy of the message.  There was debate about whether we should stop people lying at this level, especially since a mail flow could take a copy of every single email before it reached sieve.

I haven't been able to watch any video of the meeting yet, but would it be fair to say the main points of this debate were laid out in this thread on the Sieve mailing list earlier this year?



I don't know if this was ever resolved.  I prefer the user to be allowed to lie, Ned objects to that.  I don't actually care that much though, so I'm happy to say no :fcc on REJECT.  It's not like I would actually use it because sieve REJECT is bad anyway, it creates backscatter.

So Ken - I'm happy to go ahead with "not supported on reject".

The other open issue was separate capability string.  I don't think that's necessary, and nobody else seems to have commented on it.

I've created one task for each:


Bron.

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


--_----------=_151502809431353312-- From nobody Thu Jan 4 02:09: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 516F3126C89 for ; Thu, 4 Jan 2018 02:09:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.811 X-Spam-Level: X-Spam-Status: No, score=-2.811 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 el9el9LxL3C9 for ; Thu, 4 Jan 2018 02:09:35 -0800 (PST) Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id 9708F1205F0 for ; Thu, 4 Jan 2018 02:09:35 -0800 (PST) Received: from [10.168.3.2] (klara.student.utwente.nl [130.89.162.218]) by mail.dovecot.fi (Postfix) with ESMTPSA id 76D962B3DD3; Thu, 4 Jan 2018 12:09:33 +0200 (EET) To: Bron Gondwana , extra@ietf.org References: <1515026277.3124718.1223557384.0EE2A362@webmail.messagingengine.com> From: Stephan Bosch Message-ID: Date: Thu, 4 Jan 2018 11:09:30 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <1515026277.3124718.1223557384.0EE2A362@webmail.messagingengine.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: nl Archived-At: Subject: Re: [Extra] STATUS=SIZE todos X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 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, 04 Jan 2018 10:09:37 -0000 Op 1/4/2018 om 1:37 AM schreef Bron Gondwana: > Hi Stephan, > > I've created two issues on github for you with two things that need to > be resolved for STATUS=SIZE before it goes on towards publication.  > Sorry about the delay. > > https://github.com/ietfextra/tracking/issues/10 > https://github.com/ietfextra/tracking/issues/11 > > And of course the copyright date now needs to be 2018 :) OK, I will tend to this in the coming weekend. Regards, -- Stephan Bosch Senior Developer Phone: +49 2761 75252 00 Fax: +49 2761 75252 30 Email: stephan.bosch@dovecot.fi ------------------------------------------------------------------------------------- Open-Xchange AG, Rollnerstr. 14, 90408 Nuremberg, District Court Nuremberg HRB 24738 Managing Board: Rafael Laguna de la Vera, Carsten Dirks, Michael Knapstein Chairman of the Board: Richard Seibt Dovecot Oy, Lars Sonckin Kaari 10, 02600 Espoo, Finland Managing Director: Markku Kentta Chairman of the Board: Timo Sirainen Board Member: Carsten Dirks ------------------------------------------------------------------------------------- From nobody Thu Jan 4 02:10:42 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 EA8FC126DD9 for ; Thu, 4 Jan 2018 02:10:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 MJGE1ol5xbuk for ; Thu, 4 Jan 2018 02:10:39 -0800 (PST) Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id 12542126D45 for ; Thu, 4 Jan 2018 02:10:39 -0800 (PST) Received: from [10.168.3.2] (klara.student.utwente.nl [130.89.162.218]) by mail.dovecot.fi (Postfix) with ESMTPSA id 32E622B3DD3; Thu, 4 Jan 2018 12:10:38 +0200 (EET) To: Bron Gondwana , extra@ietf.org References: <1515027295.3130822.1223568456.6D1D8F15@webmail.messagingengine.com> From: Stephan Bosch Message-ID: Date: Thu, 4 Jan 2018 11:10:36 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <1515027295.3130822.1223568456.6D1D8F15@webmail.messagingengine.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Extra] SAVEDATE updated required X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 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, 04 Jan 2018 10:10:41 -0000 Op 1/4/2018 om 1:54 AM schreef Bron Gondwana: > HI Stephan, > > I've also created a couple of tasks for SAVEDATE: > > https://github.com/ietfextra/tracking/issues/12 > https://github.com/ietfextra/tracking/issues/13 > > Of course, reading the standard that closely is really good, because > it also forced me to think about it!  I have some opinions! > > 1: if the mailbox doesn't support storing save date, the behaviour > should be to return SAVEDATE NIL/ > > 2: if the mailbox doesn't support storing save date, the SEARCH > extensions should return an error if used, rather than a result, since > there's no way to calculate a sensible answer to any of those three. > > >    SAVEDBEFORE >       Messages whose save date (disregarding time and timezone) is >       earlier than the specified date. > >    SAVEDON >       Messages whose save date (disregarding time and timezone) is >       within the specified date. > >    SAVEDSINCE >       Messages whose save date (disregarding time and timezone) is >       within or later than the specified date. > > > The "disregarding time and timezone" is a horrorshow if you have users > in multiple timezones, but RFC3501 says that's how BEFORE and AFTER > work for INTERNALDATE commands, so I guess we're stuck with it. > > > 3: Do we need to define SAVEDATE as a SORT key extending RFC5256 as > well?  In theory it should always sort the same as UID. OK, I will get back to you in the coming weekend. Regards, -- Stephan Bosch Senior Developer Phone: +49 2761 75252 00 Fax: +49 2761 75252 30 Email: stephan.bosch@dovecot.fi ------------------------------------------------------------------------------------- Open-Xchange AG, Rollnerstr. 14, 90408 Nuremberg, District Court Nuremberg HRB 24738 Managing Board: Rafael Laguna de la Vera, Carsten Dirks, Michael Knapstein Chairman of the Board: Richard Seibt Dovecot Oy, Lars Sonckin Kaari 10, 02600 Espoo, Finland Managing Director: Markku Kentta Chairman of the Board: Timo Sirainen Board Member: Carsten Dirks ------------------------------------------------------------------------------------- From nobody Thu Jan 4 07:44:52 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 A301312D7EE for ; Thu, 4 Jan 2018 07:44:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 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, T_RP_MATCHES_RCVD=-0.01] 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 mAmLwp48h9mn for ; Thu, 4 Jan 2018 07:44:49 -0800 (PST) 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 B7D6D128D2E for ; Thu, 4 Jan 2018 07:44:49 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QNFXVS8PBK000UCX@mauve.mrochek.com> for extra@ietf.org; Thu, 4 Jan 2018 07:39:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1515080378; bh=5GUxovo0fu0AKWl7BbqRY5NgTy57Fxy7XsQVBhLCQ84=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=XX1ktQyaoB+oTVPWCIhuV2nRXeQFEzK35/VxVc/3SK/JpmHkeNP3y4fLmJB7ToTBw ajCe78xHYA8oUE+e0RAQh7oCoTw7EpV2syTvS0Xn27cLhghyFM8akN0+lZgC9/T9aE U8dUOEb3Km1Lm/ILpJSX6pGRYspGfFP5T+cdb5mg= 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 <01QNFVO5W1CW000051@mauve.mrochek.com>; Thu, 04 Jan 2018 07:39:32 -0800 (PST) Cc: Stan Kalisch , extra@ietf.org, Ned Freed , Murchison Ken Message-id: <01QNFXVO7LVS000051@mauve.mrochek.com> Date: Thu, 04 Jan 2018 07:17:55 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Thu, 04 Jan 2018 12:08:14 +1100" <1515028094.3135331.1223576440.053F86DC@webmail.messagingengine.com> References: <1510734636.1704307.1173072248.27572238@webmail.messagingengine.com> <1515028094.3135331.1223576440.053F86DC@webmail.messagingengine.com> To: Bron Gondwana Archived-At: Subject: Re: [Extra] Sieve REJECT and :fcc [was Re: Meeting minutes and notes from today] X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 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, 04 Jan 2018 15:44:52 -0000 > On Fri, 17 Nov 2017, at 09:06, Stan Kalisch wrote: > > > > Hi, > > > > On Nov 15, 2017, at 3:30 AM, Bron Gondwana > > wrote:>> *There is an open question for this one:* > >> > >> https://datatracker.ietf.org/doc/draft-ietf-extra-sieve-fcc/ > >> > >> Ned Freed objected to supporting :fcc for the REJECT action because > >> it allows the sieve server to "lie" about whether it's keeping a copy > >> of the message. There was debate about whether we should stop people > >> lying at this level, especially since a mail flow could take a copy > >> of every single email before it reached sieve.> That's true but beside the point. Making service-level copies of messages is one thing, giving users a direct way to conveniently say "I didn't get this message" when they actually did is quite another. > > I haven't been able to watch any video of the meeting yet, but would > > it be fair to say the main points of this debate were laid out in this > > thread on the Sieve mailing list earlier this year?> > > https://www.ietf.org/mail-archive/web/sieve/current/msg05362.html I would have thought so, but since the point that service-level copying of messages made above is still deemed relevant, apparently not. > I don't know if this was ever resolved. I prefer the user to be allowed > to lie, Ned objects to that. Very strongly. > I don't actually care that much though, so > I'm happy to say no :fcc on REJECT. It's not like I would actually use > it because sieve REJECT is bad anyway, it creates backscatter. Not if it's properly implemented around delivery time and at the SMTP level. (LMTP level is too late.) Perhap this is the key point - it's one thing to cause a DSN to be sent saying "this message was never delivered" when in fact it was. It's quite another to send a MDN saying "I threw this message away." The latter carries no implication the message wasn't read and the content possibly retained by the user in some way. The former does carry such an implication. And sure enough, if you check RFC 8098 you'll find that the disposition types allowed in an MDN are "displayed", "deleted", "dispatched", and "processed". (If the sieve reject action uses an MDN it's required to set the type to "deleted".) "delivery failed" is conspicuous by it's absence. > So Ken - I'm happy to go ahead with "not supported on reject". The alternative is to require an MDN be used in this case. Which of course creates a possible source of backscatter. > The other open issue was separate capability string. I don't think > that's necessary, and nobody else seems to have commented on it. Certainly not if :fcc only applies to vacation. However, if it applies to reject in a way that forces that extension to behave in a way some people find undesirable, things get a little more tricky. > I've created one task for each: > https://github.com/ietfextra/tracking/issues/14 > https://github.com/ietfextra/tracking/issues/15 Can you apply :fcc to a notify action that generates an email message? If not why not? And for that matter, can you apply :fcc to a notify action that generates some other kind of notification that could be mapped to an email? Ned From nobody Thu Jan 4 07:47:48 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 495E01271DF for ; Thu, 4 Jan 2018 07:47:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gulbrandsen.priv.no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hnKcVBIlue-D for ; Thu, 4 Jan 2018 07:47:45 -0800 (PST) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 477911270AB for ; Thu, 4 Jan 2018 07:47:45 -0800 (PST) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 5EF5AFA0003; Thu, 4 Jan 2018 15:47:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1515080863; bh=wFcrAX69fM2lopkvuCjwr8tcpdQFzas2EtWaxwQliSI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=sg3DiBt5eTJSunHMjPsZWLHHYBpPEHi26rCu6cOk9xu8L5+XsSUFdFoCApkp8KJSw Zm28tEgbH1kyfM6yZ174nRx7336R1r0VF0iPgzs9YDZ9OlfoGUcdQ6OOe9n5KLlRg3 RVexbCBaVnqfPI+XDCHD3URS9lrI7FLbM+Obu/nA= Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1515080862-7408-22429/11/34; Thu, 4 Jan 2018 15:47:42 +0000 From: Arnt Gulbrandsen To: extra@ietf.org Date: Thu, 4 Jan 2018 15:47:42 +0000 User-Agent: Trojita/v0.5-9-g8961725; Qt/4.8.6; X11; Linux; Devuan GNU/Linux 1.0 (jessie) Mime-Version: 1.0 Message-Id: <2d0523cb-5b0b-4cd0-8fd5-301ccbbc4342@gulbrandsen.priv.no> In-Reply-To: <01QNFXVO7LVS000051@mauve.mrochek.com> References: <1510734636.1704307.1173072248.27572238@webmail.messagingengine.com> <1515028094.3135331.1223576440.053F86DC@webmail.messagingengine.com> <01QNFXVO7LVS000051@mauve.mrochek.com> Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: Subject: Re: [Extra] Sieve REJECT and :fcc [was Re: Meeting minutes and notes from today] X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 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, 04 Jan 2018 15:47:47 -0000 Ned Freed writes: > Making service-level copies of messages is > one thing, giving users a direct way to conveniently say "I didn't get this > message" when they actually did is quite another. Sieve is used for both service-level and user-level scripts, right? Arnt From nobody Thu Jan 4 07:58:16 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 0893E127867 for ; Thu, 4 Jan 2018 07:58:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=O2ow0saf; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=U2BB2vFW Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tj71XUUWue8o for ; Thu, 4 Jan 2018 07:58:12 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1015412704A for ; Thu, 4 Jan 2018 07:58:12 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 7766C20AEA; Thu, 4 Jan 2018 10:58:11 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Thu, 04 Jan 2018 10:58:11 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=z0b5QyaZe5MnWddsaF49ArpxqE+8k MIr49HdBeSsBOM=; b=O2ow0safjcBDw8mufZt9xsVTwGPiYL24wZGYHHyEejk+z AcRLbN76+auEM/QMeaT02VIv69kzyik4NVBAGqDbXUbTNgPUAE3eQHS6pysUayGW b3ZdgMWS8c//bTBFprX1p50TcpkacnEt5x6IjvGFiJr1h3AxTlQ+RuY2o6wMfOMQ PmPNAK/Tc3FYYsJGO3IWbJFXIuf1NbwTio7jU+kCXZ2SaN+qHbmoc6DESIJckp9J MfGXL2xIesg0sIN95gXxmyxbBeoBs+Gsvg4n4e8n6o1uJiKpb3NZwBq4z7zRnqY8 BlstifMdV7FToudaoVt373mYWAO24xDb65VVJ/MLA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=z0b5Qy aZe5MnWddsaF49ArpxqE+8kMIr49HdBeSsBOM=; b=U2BB2vFWFPL47710nunwZ/ tD42CtnEsc2uz5uNVmJpdxvqKMrPmLgvbHchr51JV9Pu2e1HJg7e3viNd0iFQ+On TrbAk9n+JCcaWRQuH9kdQSR6ZWrk9KZw58CxSNEkW0OzQosvQZyktPQBntnWSVwm Z2Cln6P6V0ubptMmo5PmJ1hPJNi/08nK2hnnZZklB8gmz1O4g0gguy5GoBkmDhEh LHW5AyMf/5QeGS1Z/Pg3rE5yeWGcLV7xhiSX5W0p/JGbM6hFytGgC1TC4GnB7q5V OchcYuqCR1y7qnmIbF7jQofs+lnERwcEakDCDgrg81UKTjjbvO1lbzYp3ygYzRdw == X-ME-Sender: Received: from [192.168.1.22] (cpe-74-77-85-250.buffalo.res.rr.com [74.77.85.250]) by mail.messagingengine.com (Postfix) with ESMTPA id 1726E7E183; Thu, 4 Jan 2018 10:58:11 -0500 (EST) To: Ned Freed , Bron Gondwana Cc: extra@ietf.org References: <1510734636.1704307.1173072248.27572238@webmail.messagingengine.com> <1515028094.3135331.1223576440.053F86DC@webmail.messagingengine.com> <01QNFXVO7LVS000051@mauve.mrochek.com> From: Ken Murchison Message-ID: <5985d59e-ae0b-030d-cae1-94b63d1e807e@fastmail.com> Date: Thu, 4 Jan 2018 10:58:10 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <01QNFXVO7LVS000051@mauve.mrochek.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Extra] Sieve REJECT and :fcc [was Re: Meeting minutes and notes from today] X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 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, 04 Jan 2018 15:58:14 -0000 On 01/04/2018 10:17 AM, Ned Freed wrote: >> >>> On Nov 15, 2017, at 3:30 AM, Bron Gondwana >>> wrote:>> *There is an open question for this one:* >>> >> So Ken - I'm happy to go ahead with "not supported on reject". > The alternative is to require an MDN be used in this case. Which of course > creates a possible source of backscatter. My current plan is to disallow :fcc with reject, unless someone feels this needs more discussion. >> The other open issue was separate capability string. I don't think >> that's necessary, and nobody else seems to have commented on it. > Certainly not if :fcc only applies to vacation. However, if it applies > to reject in a way that forces that extension to behave in a way some > people find undesirable, things get a little more tricky. Agreed.  If we exclude :fcc use with reject, are we comfortable having just one capability that covers :fcc use with both vacation and notify? > Can you apply :fcc to a notify action that generates an email message? If > not why not? > > And for that matter, can you apply :fcc to a notify action that generates some > other kind of notification that could be mapped to an email? I had planned on adding text specifically mentioning that :fcc could be used with email notifications. I'm open to allowing it to be used with any notification action.  My initial thought would be to state that the mapping of the non-email notification content to an RFC5322 formatted message is implementation specific.  Do we feel the need to define strict mappings for all known notification methods? -- Kenneth Murchison Cyrus Development Team FastMail Pty Ltd From nobody Thu Jan 4 09:33: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 3E017129C6C for ; Thu, 4 Jan 2018 09:33:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 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, T_RP_MATCHES_RCVD=-0.01] 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 lfQaxRFQUKi1 for ; Thu, 4 Jan 2018 09:33:31 -0800 (PST) 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 BC816129C56 for ; Thu, 4 Jan 2018 09:33:31 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QNG1OLYC5C000PWS@mauve.mrochek.com> for extra@ietf.org; Thu, 4 Jan 2018 09:28:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1515086903; bh=SJSaVXaSWAWA2qkayBXSS7AlwtJwg63an8Zh/ezEUTU=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=Wx+MyAmVspE79IHhKrhE1bSnRRhwCZ3tDoFsjBvomXPGqe0dybxRux+cD0gLrsIbA C89XzkLmOsgQ/djMgaXqbricniXFvmVbQ5ACiRwsW0IZAUDidnDdhI56UqSu5cogdj MshbbdeFYJDGXWavmsYpl2nyQQ8vvBQP91770j4M= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QNFVO5W1CW000051@mauve.mrochek.com>; Thu, 04 Jan 2018 09:28:17 -0800 (PST) Cc: extra@ietf.org Message-id: <01QNG1OISUGO000051@mauve.mrochek.com> Date: Thu, 04 Jan 2018 09:25:01 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Thu, 04 Jan 2018 15:47:42 +0000" <2d0523cb-5b0b-4cd0-8fd5-301ccbbc4342@gulbrandsen.priv.no> References: <1510734636.1704307.1173072248.27572238@webmail.messagingengine.com> <1515028094.3135331.1223576440.053F86DC@webmail.messagingengine.com> <01QNFXVO7LVS000051@mauve.mrochek.com> <2d0523cb-5b0b-4cd0-8fd5-301ccbbc4342@gulbrandsen.priv.no> To: Arnt Gulbrandsen Archived-At: Subject: Re: [Extra] Sieve REJECT and :fcc [was Re: Meeting minutes and notes from today] X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 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, 04 Jan 2018 17:33:33 -0000 > Ned Freed writes: > > Making service-level copies of messages is > > one thing, giving users a direct way to conveniently say "I didn't get this > > message" when they actually did is quite another. > Sieve is used for both service-level and user-level scripts, right? And mailing list level. And head of household level. And spam filter level. Lots of levels. And multiple scripts can be active at once. See for example: https://tools.ietf.org/html/draft-degener-sieve-multiscript-00 Ned From nobody Thu Jan 4 10:07: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 97FEB126C89 for ; Thu, 4 Jan 2018 10:07:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gulbrandsen.priv.no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLHPO4IGtIzc for ; Thu, 4 Jan 2018 10:07:55 -0800 (PST) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43245124205 for ; Thu, 4 Jan 2018 10:07:54 -0800 (PST) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 56760FA0003; Thu, 4 Jan 2018 18:07:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1515089273; bh=GJN9j9JT1cg10fdP4GG4ZSLdUncCDLNdpIQqyES4tUg=; h=From:To:Subject:Date:References:From; b=o/xFCOeHSaLP9wMxMs4fe0LyTVGa7HVVVZIOvkzYqhs+Lj9n97jSMm2fNXwW/GySj BzO4ecqJ6z4acGBO1plu9+mHAr8kpIdTXYr3Z5gCrrti86wI1+jw+NOWZHm/lBUnOj fLqbTdk9xGeu6nLgPpcTMYw+ttEcAxDRPKtqpifA= Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1515089272-7408-22429/12/1817; Thu, 4 Jan 2018 18:07:52 +0000 From: Arnt Gulbrandsen To: extra@ietf.org, Ned Freed Date: Thu, 4 Jan 2018 19:07:50 +0100 Message-Id: References: <1510734636.1704307.1173072248.27572238@webmail.messagingengine.com> <1515028094.3135331.1223576440.053F86DC@webmail.messagingengine.com> <01QNFXVO7LVS000051@mauve.mrochek.com> <2d0523cb-5b0b-4cd0-8fd5-301ccbbc4342@gulbrandsen.priv.no> <01QNG1OISUGO000051@mauve.mrochek.com> Mime-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: Re: [Extra] Meeting minutes and notes from today X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 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, 04 Jan 2018 18:07:56 -0000 Right. I feel that the main disconnect here is that the reject/fcc combination may cause one party (the site/company/...) to make a false representation about delivery on the instructions of another (the addressee). When those two are the same, this is okayish. Lying on my own accord is not pretty, but it is better than lying because someone else told me to. The right answer may be that reject/fcc should be available only when the mta owner and the script owner are the same. Or that may be unwarranted complexity, and the right answer is to cater to one of the two cases and knowingly disregard the other. Arnt From nobody Thu Jan 4 11:40: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 EEE96126CD8 for ; Thu, 4 Jan 2018 11:40:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mailforce.net header.b=VF1UxW1A; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=L7eTXuW8 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9z6uczsAEZEI for ; Thu, 4 Jan 2018 11:40:40 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 855441201F2 for ; Thu, 4 Jan 2018 11:40:40 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id C4BAF20CBB; Thu, 4 Jan 2018 14:40:39 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Thu, 04 Jan 2018 14:40:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailforce.net; 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=fm2; bh=JNueB+8t6G3srR25o MlgLbGJKsO8OBPtM/H5pQmR/hw=; b=VF1UxW1AEysgqGtvpcWTMWi5bc95IKNYL 8KK8o9tvtYt2RdyWOwcuwwpgWFyXqqSd15rICfUxAY1ZL4QTl5GQGZaQTKphjRTt 6BFYJxbWPNQm7O9du1KZL8Ocfgb4Tph0KeoCJQRagKKcc5h9+wdK2JR27AHTj45y g9sqiKWCp0vy3UJoVoA+hwbsn3+d5e4IwzM6qQDBEEb8RAHGDNr/9S0w5Udhm6Dh bb6Qo9wDABjWMrdVuUFbe5C/H7GEOn9LJ+NE4t0WQStaCDihRs9nTa2uCsJFtBgG Kg+BXkFQdRXue7vhkdajvUSwGgIgHvBJQ5JZe9/BHLbBw3SeRTrhA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=JNueB+ 8t6G3srR25oMlgLbGJKsO8OBPtM/H5pQmR/hw=; b=L7eTXuW8BTGW3XJq+sSIbD 3h1U5Gw5BBAuLj1CbeZAbSHRo47bAWyc0FI1rhMi9ZCqssZNnzgiHU7HTxFYogX5 BN1bZagYQ2a/NHqlvW71f+YzBe3luyeZrUrCeAoxhuYdgirVMs3BW12gnoMtSFse rv9NI+wBApKOGURzaG1CUtINLAOuaerJCskYZlOEZ+0rjEzNj1JPwzRKlsWC4pIX kRLkBKKYLtzV8nRO9dcv0eMHnOY3TDOo4PoL+F1rf9qp70hY5F06s6yx5Cpid7eX hRqMzcvUKJPctRgTbsXqBwzKICacge0leHd6GJkXs/SEc/+obtv1ofUgSywH2iqw == X-ME-Sender: Received: from [192.168.1.71] (108-84-31-27.lightspeed.tukrga.sbcglobal.net [108.84.31.27]) by mail.messagingengine.com (Postfix) with ESMTPA id 43BD57E353; Thu, 4 Jan 2018 14:40:39 -0500 (EST) References: <1510734636.1704307.1173072248.27572238@webmail.messagingengine.com> <1515028094.3135331.1223576440.053F86DC@webmail.messagingengine.com> <01QNFXVO7LVS000051@mauve.mrochek.com> In-Reply-To: <01QNFXVO7LVS000051@mauve.mrochek.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: Cc: Bron Gondwana , extra@ietf.org, Murchison Ken X-Mailer: iPhone Mail (13G36) From: Stan Kalisch Date: Thu, 4 Jan 2018 14:40:36 -0500 To: Ned Freed Archived-At: Subject: Re: [Extra] Sieve REJECT and :fcc [was Re: Meeting minutes and notes from today] X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 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, 04 Jan 2018 19:40:43 -0000 On Jan 4, 2018, at 10:17 AM, Ned Freed wrote: >>> On Fri, 17 Nov 2017, at 09:06, Stan Kalisch wrote: >>>=20 >>> Hi, >>>=20 >>> On Nov 15, 2017, at 3:30 AM, Bron Gondwana >>> wrote:>> *There is an open question for this on= e:* >>>>=20 >>>> https://datatracker.ietf.org/doc/draft-ietf-extra-sieve-fcc/ >>>>=20 >>>> Ned Freed objected to supporting :fcc for the REJECT action because >>>> it allows the sieve server to "lie" about whether it's keeping a copy >>>> of the message. There was debate about whether we should stop people >>>> lying at this level, especially since a mail flow could take a copy >>>> of every single email before it reached sieve.> >=20 > That's true but beside the point. Making service-level copies of messages i= s > one thing, giving users a direct way to conveniently say "I didn't get thi= s > message" when they actually did is quite another. Perhaps, but, after all, reject already provides that facility. But that's n= ot the central point of my argument in favor of allowing reject to invoke :f= cc. Some users have arguably (at least, certainly morally) legitimate reasons to= lie about the delivery of mail. The users who first come to my mind are su= rvivors of domestic violence and/or sexual assault. Google surely had in mi= nd stalking and harassment when it provided Google Voice a mechanism to lie a= bout whether or not someone had placed a call to a user's valid phone number= . Granted, backscatter, MDN, DSN, etc., of course, aren't even peripheral c= onsiderations in rolling out something like that for phone calls. But, agai= n, we're only talking about :fcc; reject's ship has already sailed. I acknowledge your point that "delivery failed" is conspicuous by virtue of t= he fact that it is missing from RFC 8098. And I can't say that this gives m= e no pause of any kind. But it still seems to me, when you look at both the= technical and very real human considerations, that this effort is more trou= ble than it's worth=E2=80=94I'm having a hard time believing adding :fcc to r= eject is substantially going to increase reject's (mis)use. So this strikes= me as something that, in effect, merely serves as a lecture to users who ma= y lie, but 1) are not necessarily sanguine or happy about lying, and 2) may a= ctually have the need to lie. That is a scenario that is not implausible at= all. It is a privacy issue. I don't want to *encourage* users to lie, but= , on the other hand, I don't think the technical arguments are strong enough= for the IETF to dictate that a language does or does not deal with such pro= blems. That should really be entrusted to users and administrators. Some t= hings, in the end, have to be entrusted to the community. Thanks, Stan >>> I haven't been able to watch any video of the meeting yet, but would >>> it be fair to say the main points of this debate were laid out in this >>> thread on the Sieve mailing list earlier this year?> >>> https://www.ietf.org/mail-archive/web/sieve/current/msg05362.html >=20 > I would have thought so, but since the point that service-level > copying of messages made above is still deemed relevant, apparently not. >=20 >> I don't know if this was ever resolved. I prefer the user to be allowed >> to lie, Ned objects to that. >=20 > Very strongly. >=20 >> I don't actually care that much though, so >> I'm happy to say no :fcc on REJECT. It's not like I would actually use >> it because sieve REJECT is bad anyway, it creates backscatter. >=20 > Not if it's properly implemented around delivery time and at the SMTP leve= l. > (LMTP level is too late.) Perhap this is the key point - it's one thing to= > cause a DSN to be sent saying "this message was never delivered" when in f= act > it was. It's quite another to send a MDN saying "I threw this message away= ." >=20 > The latter carries no implication the message wasn't read and the content > possibly retained by the user in some way. The former does carry such an > implication. >=20 > And sure enough, if you check RFC 8098 you'll find that the disposition ty= pes > allowed in an MDN are "displayed", "deleted", "dispatched", and "processed= ".=20 > (If the sieve reject action uses an MDN it's required to set the type to > "deleted".) "delivery failed" is conspicuous by it's absence. >=20 >> So Ken - I'm happy to go ahead with "not supported on reject". >=20 > The alternative is to require an MDN be used in this case. Which of course= > creates a possible source of backscatter. >=20 >> The other open issue was separate capability string. I don't think >> that's necessary, and nobody else seems to have commented on it. >=20 > Certainly not if :fcc only applies to vacation. However, if it applies > to reject in a way that forces that extension to behave in a way some > people find undesirable, things get a little more tricky. >=20 >> I've created one task for each: >=20 >> https://github.com/ietfextra/tracking/issues/14 >> https://github.com/ietfextra/tracking/issues/15 >=20 > Can you apply :fcc to a notify action that generates an email message? If > not why not? >=20 > And for that matter, can you apply :fcc to a notify action that generates s= ome > other kind of notification that could be mapped to an email? >=20 > Ned >=20 > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra From nobody Thu Jan 4 13:33: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 D625012421A for ; Thu, 4 Jan 2018 13:33:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gulbrandsen.priv.no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rC19ctMM8Rk5 for ; Thu, 4 Jan 2018 13:33:30 -0800 (PST) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 167B51201FA for ; Thu, 4 Jan 2018 13:33:29 -0800 (PST) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 1C152FA0003; Thu, 4 Jan 2018 21:33:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1515101608; bh=J+7pKYU8et71D0c8J6UK6lVtY+bT6+ALd24QxnPjNHg=; h=From:To:Subject:Date:In-Reply-To:References:From; b=rAeOyVElwmtk7IwGIBNe6uLT4V4xgbpAH2eo1QuQuFoNGPoaHWht9YKUiDCrA2CnR GRFmjvG7JOsK09h6HyeFkfhH35GhRyeX+TvIJtxlQXVDDhRIE7ffK85eyjTqLF1Up7 /egrVozuZ/M9zTtUab+DYHFpBv/GDeJiyOpT9U64= Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1515101607-14443-22429/11/3; Thu, 4 Jan 2018 21:33:27 +0000 From: Arnt Gulbrandsen To: extra@ietf.org Date: Thu, 4 Jan 2018 21:33:26 +0000 User-Agent: Trojita/v0.5-9-g8961725; Qt/4.8.6; X11; Linux; Devuan GNU/Linux 1.0 (jessie) Mime-Version: 1.0 Message-Id: <4ae4f1d5-bf40-483a-ae88-befe01d3adef@gulbrandsen.priv.no> In-Reply-To: References: <1510734636.1704307.1173072248.27572238@webmail.messagingengine.com> <1515028094.3135331.1223576440.053F86DC@webmail.messagingengine.com> <01QNFXVO7LVS000051@mauve.mrochek.com> Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: Subject: Re: [Extra] Sieve REJECT and :fcc [was Re: Meeting minutes and notes from today] X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 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, 04 Jan 2018 21:33:32 -0000 Stan Kalisch writes: > Perhaps, but, after all, reject already provides that facility. > But that's not the central point of my argument in favor of > allowing reject to invoke :fcc. > > Some users have arguably (at least, certainly morally) > legitimate reasons to lie about the delivery of mail. You can also argue that software has a duty to serve its user. If the user wants to send mail claiming that 2+2=7 on Tuesdays, that the check is in the mail, or that he/she hadn't received that other mail, that's the user's business. The software's duty is to serve its master. (But as I said in another message, sieve may serve two masters, and even if the software will loyally lie in the name of one master, that doesn't mean one of the masters should be able to force the software to lie in the name of the other.) Arnt From nobody Thu Jan 4 15:34: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 1EA1B1273E2 for ; Thu, 4 Jan 2018 15:34:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mailforce.net header.b=b6YW8bhe; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=W52cRAC1 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tf4SnZpaGIIT for ; Thu, 4 Jan 2018 15:34:26 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B268126CF9 for ; Thu, 4 Jan 2018 15:34:25 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id CB84020A92 for ; Thu, 4 Jan 2018 18:34:24 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Thu, 04 Jan 2018 18:34:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailforce.net; 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=fm2; bh=NMmXef8Zqd/NnA/nCzgJa7864Op5M oKoLg9EaukPfCY=; b=b6YW8bheKsPQzCpj7oQwEJGFVg86F+hjVacLqYJUAVwoz RSeTc8KdPyE8XuDIv546VUmdm/gSXY9Yc0LrIc0KO2JAiQZa6uHtdxa5EXGRrLNX /K3HBA8TSOOnvIvjrHNtRGJ4sAs3wOQuXQiNS32EwP2+o7eFL+UCNhk0Hi0FXP15 vR8kU4Fm9DKjWhteNSmQ6E+2VvXgk/hN997FJK+9w549bpVzrTZJ3nWS6w4viG6Z 7qKNIXF9TfMxfZjQPffnCgrovA1IP50IkZpqpzbZxBznKB2TfFrOFWZnRdzlpqAt PNTesyv8kiyEUcMsglTEeR/KeP+GmIMQANLCLFrVQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=NMmXef 8Zqd/NnA/nCzgJa7864Op5MoKoLg9EaukPfCY=; b=W52cRAC1a/h0zy7wL7fSls NIcQSYiWB39zharOBo4siVwLkTbl6KJIfu/Eovh54U6gLfJ2FwJt+YrHf3igJokF T75iiopKEUHkQhnDGboBUbPtcqQBgnMSNU+8zlwS25t0RPn071mL8ynIPUUCOvkq dgzkMhWd2RdhRaLzuy0ZZ1Yrg+dvbkcFd8E9K1fSY4kc6naZjGygJ0JYrI/Gd1Sx +7GvVrmUeMGfN5y+crihLUhstBa3zCXbXQAnkEWOgftMJrNYFzikbyAJvPfGQunb Bid5rkYzW5u+WxEXAyaZEMXXvp2OXVbFS5ZLhdZp8lC7O5at+Ml/9cOXpeYUcz/g == X-ME-Sender: Received: from [192.168.1.71] (108-84-31-27.lightspeed.tukrga.sbcglobal.net [108.84.31.27]) by mail.messagingengine.com (Postfix) with ESMTPA id 7455C7E3D4 for ; Thu, 4 Jan 2018 18:34:24 -0500 (EST) References: <1510734636.1704307.1173072248.27572238@webmail.messagingengine.com> <1515028094.3135331.1223576440.053F86DC@webmail.messagingengine.com> <01QNFXVO7LVS000051@mauve.mrochek.com> <4ae4f1d5-bf40-483a-ae88-befe01d3adef@gulbrandsen.priv.no> From: Stan Kalisch Content-Type: text/plain; charset=us-ascii X-Mailer: iPhone Mail (13G36) In-Reply-To: <4ae4f1d5-bf40-483a-ae88-befe01d3adef@gulbrandsen.priv.no> Message-Id: <7C65B98D-6755-4957-A181-CBA08354D11B@glyphein.mailforce.net> Date: Thu, 4 Jan 2018 18:34:22 -0500 To: extra@ietf.org Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Archived-At: Subject: Re: [Extra] Sieve REJECT and :fcc [was Re: Meeting minutes and notes from today] X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 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, 04 Jan 2018 23:34:28 -0000 > On Jan 4, 2018, at 4:33 PM, Arnt Gulbrandsen wr= ote: >=20 > Stan Kalisch writes: >> Perhaps, but, after all, reject already provides that facility. I should have been more precise and said "can accommodate" that facility. A= s RFC 5429 says: "Making "reject" compatible with actions that cause mail delivery violates t= he RFC 5321 [SMTP] principle that a message is either delivered or bounced b= ack to the sender. So bouncing a message back (rejecting) and delivering it= will make the sender believe that the message was not delivered. "However, there are existing laws requiring certain organizations to archive= all received messages, even the rejected ones. Also, it can be quite usefu= l to save copies of rejected messages for later analysis." >> But that's not the central point of my argument in favor of allowing reje= ct to invoke :fcc. >>=20 >> Some users have arguably (at least, certainly morally) legitimate reasons= to lie about the delivery of mail. >=20 > You can also argue that software has a duty to serve its user. >=20 > If the user wants to send mail claiming that 2+2=3D7 on Tuesdays, that the= check is in the mail, or that he/she hadn't received that other mail, that'= s the user's business. The software's duty is to serve its master. >=20 > (But as I said in another message, sieve may serve two masters, and even i= f the software will loyally lie in the name of one master, that doesn't mean= one of the masters should be able to force the software to lie in the name o= f the other.) And as reject already minimally allows a user to do that (lie about the reas= on a message was rejected), this sounds to me like something that should be l= eft to the discretion of an administrator. For some systems, the administra= tor is going to want to give primacy to the user's privacy; for others, the a= dministrator is going to desire to give primacy to accountability to some en= tity or organization. To me, this seems like a fair trade-off. I do conced= e that's not entirely consistent with RFC 5429's language about archiving le= aving the decision up to the "implementation" and that that's something that= has to be considered. Thanks, Stan From nobody Thu Jan 4 15:40:28 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 AC64C1275AB for ; Thu, 4 Jan 2018 15:40:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=k21zK8ef; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=VSyzxJiK Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHMT5TdXIjT7 for ; Thu, 4 Jan 2018 15:40:25 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EF03126C22 for ; Thu, 4 Jan 2018 15:40:25 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id B6B0620AAF for ; Thu, 4 Jan 2018 18:40:24 -0500 (EST) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Thu, 04 Jan 2018 18:40:24 -0500 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=fm1; bh=ivibUVUUEdfgdl3J7 wSuBuxqCWYCgN+fhDR4i7a9f/M=; b=k21zK8efmnLh1zc2vBmEhAYWECAN7W8Go UwvyBc+qK0KeXN7mgtiYWC87DKBeNjMcTwYC/oNCL/vNW4hRVea3c5Oo1/7aIUo9 +W1AAF6u4pkaY7UOOBrvVaD1KB0hHeawQRg29nullPpJKwfe42FbnmaNKGouIs2L i7AEzDa033/MWOE8YGRFxF257TG1mUCt/A31wo0kjYFMzqEbxCUaAvrpHglwrDCl VKufWNr0evH4rvWIWKl6NNtpriMg+bUbOcytVLOU+WtuVnjE/Y5pxUzXGJACcICr Bl0JBiyDZErZ9ZsUyG2z4gZ+6sznM36OI3u9k4g40Z/8D0K5YsbeA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=ivibUV UUEdfgdl3J7wSuBuxqCWYCgN+fhDR4i7a9f/M=; b=VSyzxJiKwtjEHNVZHiI6Xb x2FTbcC31UYsiSoV5eG5A6q6Tj6A309yhMulHZ2kyqsURYKpeedRfjhzqzooY+hH I5VFRFong47X+BX6+VWYXuHDLhUvU7Yb/COAfnC4i+gx1HsPIZhjQkwV4tFf6tEO XWKrxak0MKU/aKDwLjrVCUUT38POsi+eedomAuxFwhsTlbc40lauq7ZnFu98KCW+ 49PsHdyNV+5xpHYLSA8I359XMDmUqoehlEuUD4wzX5yIu89I1m0wcKqg1fLN2Cce o1HKtqeeZCreDEVzH4YkxlbEvfI0pG+B9UMfuO4dvX7RMWqhZJvh580O6Mhem3yg == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 8D58E9E2C2; Thu, 4 Jan 2018 18:40:24 -0500 (EST) Message-Id: <1515109224.681625.1224717176.520E1500@webmail.messagingengine.com> From: Bron Gondwana To: extra@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15151092246816252" X-Mailer: MessagingEngine.com Webmail Interface - ajax-cc9a457c In-Reply-To: <7C65B98D-6755-4957-A181-CBA08354D11B@glyphein.mailforce.net> References: <1510734636.1704307.1173072248.27572238@webmail.messagingengine.com> <1515028094.3135331.1223576440.053F86DC@webmail.messagingengine.com> <01QNFXVO7LVS000051@mauve.mrochek.com> <4ae4f1d5-bf40-483a-ae88-befe01d3adef@gulbrandsen.priv.no> <7C65B98D-6755-4957-A181-CBA08354D11B@glyphein.mailforce.net> Date: Fri, 05 Jan 2018 10:40:24 +1100 Archived-At: Subject: Re: [Extra] Sieve REJECT and :fcc [was Re: Meeting minutes and notes from today] X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 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, 04 Jan 2018 23:40:28 -0000 This is a multi-part message in MIME format. --_----------=_15151092246816252 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" Is everybody OK with having fcc not include reject, and having a separate capability (fcc-reject or similar) which administrators can decide whether or not to allow - and indeed, software implementations the choice whether or not to implement. That fixes both issues - those who really want the ability to lie can do so, but it's clear that they're enabling that facility, and it's also possible for both software vendors and administrators to not provide the facility in the first place. Bron. On Fri, 5 Jan 2018, at 10:34, Stan Kalisch wrote: > >> On Jan 4, 2018, at 4:33 PM, Arnt Gulbrandsen >> wrote:>> >> Stan Kalisch writes: >>> Perhaps, but, after all, reject already provides that facility. > > I should have been more precise and said "can accommodate" that > facility. As RFC 5429 says:> > "Making "reject" compatible with actions that cause mail delivery > violates the RFC 5321 [SMTP] principle that a message is either > delivered or bounced back to the sender. So bouncing a message back > (rejecting) and delivering it will make the sender believe that the > message was not delivered.> > "However, there are existing laws requiring certain organizations to > archive all received messages, even the rejected ones. Also, it can > be quite useful to save copies of rejected messages for later > analysis."> >>> But that's not the central point of my argument in favor of allowing >>> reject to invoke :fcc.>>> >>> Some users have arguably (at least, certainly morally) legitimate >>> reasons to lie about the delivery of mail.>> >> You can also argue that software has a duty to serve its user. >> >> If the user wants to send mail claiming that 2+2=7 on Tuesdays, that >> the check is in the mail, or that he/she hadn't received that other >> mail, that's the user's business. The software's duty is to serve its >> master.>> >> (But as I said in another message, sieve may serve two masters, and >> even if the software will loyally lie in the name of one master, that >> doesn't mean one of the masters should be able to force the software >> to lie in the name of the other.)> > And as reject already minimally allows a user to do that (lie about > the reason a message was rejected), this sounds to me like something > that should be left to the discretion of an administrator. For some > systems, the administrator is going to want to give primacy to the > user's privacy; for others, the administrator is going to desire to > give primacy to accountability to some entity or organization. To me, > this seems like a fair trade-off. I do concede that's not entirely > consistent with RFC 5429's language about archiving leaving the > decision up to the "implementation" and that that's something that has > to be considered.> > > Thanks, > Stan > > _________________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_15151092246816252 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
Is everybody OK with having fcc not include reject, and having a separate capability (fcc-reject or similar) which administrators can decide whether or not to allow - and indeed, software implementations the choice whether or not to implement.

That fixes both issues - those who really want the ability to lie can do so, but it's clear that they're enabling that facility, and it's also possible for both software vendors and administrators to not provide the facility in the first place.

Bron.


On Fri, 5 Jan 2018, at 10:34, Stan Kalisch wrote:

On Jan 4, 2018, at 4:33 PM, Arnt Gulbrandsen <arnt@gulbrandsen.priv.no> wrote:

Stan Kalisch writes:
Perhaps, but, after all, reject already provides that facility.

I should have been more precise and said "can accommodate" that facility.  As RFC 5429 says:

"Making "reject" compatible with actions that cause mail delivery violates the RFC 5321 [SMTP] principle that a message is either delivered or bounced back to the sender.  So bouncing a message back (rejecting) and delivering it will make the sender believe that the message was not delivered.

"However, there are existing laws requiring certain organizations to archive all received messages, even the rejected ones.  Also, it can be quite useful to save copies of rejected messages for later analysis."

But that's not the central point of my argument in favor of allowing reject to invoke :fcc.

Some users have arguably (at least, certainly morally) legitimate reasons to lie about the delivery of mail.

You can also argue that software has a duty to serve its user.

If the user wants to send mail claiming that 2+2=7 on Tuesdays, that the check is in the mail, or that he/she hadn't received that other mail, that's the user's business. The software's duty is to serve its master.

(But as I said in another message, sieve may serve two masters, and even if the software will loyally lie in the name of one master, that doesn't mean one of the masters should be able to force the software to lie in the name of the other.)

And as reject already minimally allows a user to do that (lie about the reason a message was rejected), this sounds to me like something that should be left to the discretion of an administrator.  For some systems, the administrator is going to want to give primacy to the user's privacy; for others, the administrator is going to desire to give primacy to accountability to some entity or organization.  To me, this seems like a fair trade-off.  I do concede that's not entirely consistent with RFC 5429's language about archiving leaving the decision up to the "implementation" and that that's something that has to be considered.


Thanks,
Stan

_______________________________________________
Extra mailing list

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


--_----------=_15151092246816252-- From nobody Thu Jan 4 17:40:49 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 6E4D81241F8 for ; Thu, 4 Jan 2018 17:40:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mailforce.net header.b=rbMrYcuB; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=hg6DCVn+ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0skUD-LkjNPb for ; Thu, 4 Jan 2018 17:40:45 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64D681201F8 for ; Thu, 4 Jan 2018 17:40:45 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 6416E20A81 for ; Thu, 4 Jan 2018 20:40:44 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Thu, 04 Jan 2018 20:40:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailforce.net; 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=fm2; bh=Uo83RVtk4+WtsQnjHRkwV+6wZ+eK0 uEoTMxIPP41Ckg=; b=rbMrYcuBoGEVTD+U2LAYoUEFhwDWsimlJFqc7Q2oGEqzI haZzguCn6wYPgT4BDBYq0jTXSrwBg3v8QmCzPvpJE/g5JGQXEabQLadgOGw6qTIu EePM1eAg9/YCihNFP+ecCVnetAOtNe6f/cQgO6wxBEXJMNmMEqVESPQ/dYWh89WV Ue7IKAX316VMCKSXoX3zwGtdf2EryKWbZMJ/m8vxx8+PlxZvMEYQy6nRF7pEXXlc WyZIYBATTqzXV3p+joVe8VAMHILLbvXZm/Z2CW+f6N6lJI6g4MfoMqVGee7TPtDy ckSPbp9ET5NAoyjQBJ4r4uUiFvACFLFlj4BYRz1SQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=Uo83RV tk4+WtsQnjHRkwV+6wZ+eK0uEoTMxIPP41Ckg=; b=hg6DCVn+/MZYEpfJFOC5qe rZVHFz5/Ohhcgbmt3gQdYhyzWqCxYBjv4B4LEIW4gWClueD9WAci7CQxDV0Hnf5L S5Otg0TspKKz/TYlD8kZB/7dhtm++Icbifdt8xWkNShnAtUKJMQaKD0bADPKiiF9 tClTcDHLbphr9SX2xAz7d3OGzpYHXqUBc4x8iSydM/qBgzvUhSJMY6tdEBxg0sav tBpJE1YgO+Ia1slOcF0lsRj21QYKd4BrTDsL51FCJJjKIeS8IRQnJSW1kcc56k9s P/kqr63gn4EjYBRnQbTi4AgLDR/omoqBtfy1OPSUBBc2Q6DYUSCYRqmJjsBN5t2A == X-ME-Sender: Received: from [192.168.1.71] (108-84-31-27.lightspeed.tukrga.sbcglobal.net [108.84.31.27]) by mail.messagingengine.com (Postfix) with ESMTPA id 08E7A7E34D for ; Thu, 4 Jan 2018 20:40:44 -0500 (EST) References: <1510734636.1704307.1173072248.27572238@webmail.messagingengine.com> <1515028094.3135331.1223576440.053F86DC@webmail.messagingengine.com> <01QNFXVO7LVS000051@mauve.mrochek.com> <4ae4f1d5-bf40-483a-ae88-befe01d3adef@gulbrandsen.priv.no> <7C65B98D-6755-4957-A181-CBA08354D11B@glyphein.mailforce.net> <1515109224.681625.1224717176.520E1500@webmail.messagingengine.com> From: Stan Kalisch Content-Type: multipart/alternative; boundary=Apple-Mail-127FEBC4-505C-4265-B5FA-4D4EE5C58C0D X-Mailer: iPhone Mail (13G36) In-Reply-To: <1515109224.681625.1224717176.520E1500@webmail.messagingengine.com> Message-Id: <2520156B-CD12-4204-9940-A003CDBB686B@glyphein.mailforce.net> Date: Thu, 4 Jan 2018 20:40:41 -0500 To: extra@ietf.org Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Archived-At: Subject: Re: [Extra] Sieve REJECT and :fcc [was Re: Meeting minutes and notes from today] X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 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, 05 Jan 2018 01:40:47 -0000 --Apple-Mail-127FEBC4-505C-4265-B5FA-4D4EE5C58C0D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On Jan 4, 2018, at 6:40 PM, Bron Gondwana wrote: >=20 > Is everybody OK with having fcc not include reject, and having a separate c= apability (fcc-reject or similar) which administrators can decide whether or= not to allow - and indeed, software implementations the choice whether or n= ot to implement. >=20 > That fixes both issues - those who really want the ability to lie can do s= o, but it's clear that they're enabling that facility, and it's also possibl= e for both software vendors and administrators to not provide the facility i= n the first place. I personally think it should be up to administrators only, but I recognize t= hat's an ugly hack to the spec already in place. So I'm okay with it. Thanks, Stan= --Apple-Mail-127FEBC4-505C-4265-B5FA-4D4EE5C58C0D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On Jan 4, 2018, at 6:40 PM, Bron Gondwana <brong@fastmailteam.com> wrote:

Is everybody OK with having fcc not include reject, and having a separate capability (fcc-reject or similar) which administrators can decide whether or not to allow - and indeed, software implementations the choice whether or not to implement.

That fixes both issues - those who really want the ability to lie can do so, but it's clear that they're enabling that facility, and it's also possible for both software vendors and administrators to not provide the facility in the first place.

I personally think it should be up to administrators only, but I recognize that's an ugly hack to the spec already in place.  So I'm okay with it.


Thanks,
Stan
--Apple-Mail-127FEBC4-505C-4265-B5FA-4D4EE5C58C0D-- From nobody Thu Jan 4 21:58: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 2C61D1270A7 for ; Thu, 4 Jan 2018 21:58:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 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, T_RP_MATCHES_RCVD=-0.01, 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 ju2j9ln9PUWa for ; Thu, 4 Jan 2018 21:58:23 -0800 (PST) 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 DAF83126C2F for ; Thu, 4 Jan 2018 21:58:22 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QNGRP4HFW0001133@mauve.mrochek.com> for extra@ietf.org; Thu, 4 Jan 2018 21:53:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1515131594; bh=HJZ5zXa9UMWUTnU/Fzba2uI+NSBEwpmZKvaG+bEI9Iw=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=ruJ3yzhEyIXL/EOulk1oSBh25seFV6L+OBj4JBRJhEyWYvXg3Tzeqc1UoNwAFMrgy 2F4PJrUVsEbr3TWiIwpunXhIyRJdq04vC610TGzgviCsINISVlDlm5szGcIBmftEWn CwLQdsrrrYEYvids2/FPc9xejAU9O2L+ogWOCmbw= 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 <01QNGRDZCUDC000052@mauve.mrochek.com>; Thu, 04 Jan 2018 21:53:10 -0800 (PST) Cc: Ned Freed , Bron Gondwana , extra@ietf.org Message-id: <01QNGRP0BAO2000052@mauve.mrochek.com> Date: Thu, 04 Jan 2018 21:50:35 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Thu, 04 Jan 2018 10:58:10 -0500" <5985d59e-ae0b-030d-cae1-94b63d1e807e@fastmail.com> References: <1510734636.1704307.1173072248.27572238@webmail.messagingengine.com> <1515028094.3135331.1223576440.053F86DC@webmail.messagingengine.com> <01QNFXVO7LVS000051@mauve.mrochek.com> <5985d59e-ae0b-030d-cae1-94b63d1e807e@fastmail.com> To: Ken Murchison Archived-At: Subject: Re: [Extra] Sieve REJECT and :fcc [was Re: Meeting minutes and notes from today] X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 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, 05 Jan 2018 05:58:24 -0000 > On 01/04/2018 10:17 AM, Ned Freed wrote: > >> > >>> On Nov 15, 2017, at 3:30 AM, Bron Gondwana > >>> wrote:>> *There is an open question for this one:* > >>> > >> So Ken - I'm happy to go ahead with "not supported on reject". > > The alternative is to require an MDN be used in this case. Which of course > > creates a possible source of backscatter. > My current plan is to disallow :fcc with reject, unless someone feels > this needs more discussion. I have no real preference between a mandatory MDN and removing the capability. > >> The other open issue was separate capability string. I don't think > >> that's necessary, and nobody else seems to have commented on it. > > Certainly not if :fcc only applies to vacation. However, if it applies > > to reject in a way that forces that extension to behave in a way some > > people find undesirable, things get a little more tricky. > Agreed.  If we exclude :fcc use with reject, are we comfortable having > just one capability that covers :fcc use with both vacation and notify? Works for me. Vacation and notify are essentially the same code in our implementation; two capability strings are actually more work. > > Can you apply :fcc to a notify action that generates an email message? If > > not why not? > > > > And for that matter, can you apply :fcc to a notify action that generates some > > other kind of notification that could be mapped to an email? > I had planned on adding text specifically mentioning that :fcc could be > used with email notifications. > I'm open to allowing it to be used with any notification action.  My > initial thought would be to state that the mapping of the non-email > notification content to an RFC5322 formatted message is implementation > specific.  Do we feel the need to define strict mappings for all known > notification methods? I don't know enough about other methods people have implemented to make any sort of assessment. Ned From nobody Sun Jan 7 01:57:16 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 1998D127337 for ; Sun, 7 Jan 2018 01:57:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 0AIjoMXZ4LKs for ; Sun, 7 Jan 2018 01:57:13 -0800 (PST) Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id 93B5A1273E2 for ; Sun, 7 Jan 2018 01:57:11 -0800 (PST) Received: from [10.168.3.2] (klara.student.utwente.nl [130.89.162.218]) by mail.dovecot.fi (Postfix) with ESMTPSA id 416A62AEF55; Sun, 7 Jan 2018 11:57:09 +0200 (EET) To: Bron Gondwana , extra@ietf.org References: <1515026277.3124718.1223557384.0EE2A362@webmail.messagingengine.com> From: Stephan Bosch Message-ID: <86933152-e2bc-7a03-e997-f361b5d7ee8b@dovecot.fi> Date: Sun, 7 Jan 2018 10:56:56 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <1515026277.3124718.1223557384.0EE2A362@webmail.messagingengine.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Extra] STATUS=SIZE todos X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 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, 07 Jan 2018 09:57:15 -0000 Hi Bron, Op 1/4/2018 om 1:37 AM schreef Bron Gondwana: > Hi Stephan, > > I've created two issues on github for you with two things that need to > be resolved for STATUS=SIZE before it goes on towards publication.  > Sorry about the delay. Published my git repository. > https://github.com/ietfextra/tracking/issues/10 > https://github.com/ietfextra/tracking/issues/11 Fixed one of these. Left a question on the other one. > > And of course the copyright date now needs to be 2018 :) Made an ietf-00 submission. Regards, Stephan. -- Stephan Bosch Senior Developer Phone: +49 2761 75252 00 Fax: +49 2761 75252 30 Email: stephan.bosch@dovecot.fi ------------------------------------------------------------------------------------- Open-Xchange AG, Rollnerstr. 14, 90408 Nuremberg, District Court Nuremberg HRB 24738 Managing Board: Rafael Laguna de la Vera, Carsten Dirks, Michael Knapstein Chairman of the Board: Richard Seibt Dovecot Oy, Lars Sonckin Kaari 10, 02600 Espoo, Finland Managing Director: Markku Kentta Chairman of the Board: Timo Sirainen Board Member: Carsten Dirks ------------------------------------------------------------------------------------- From nobody Sun Jan 7 05:07:24 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 402F4126C25 for ; Sun, 7 Jan 2018 05:07:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 MtfQ6CoN285U for ; Sun, 7 Jan 2018 05:07:21 -0800 (PST) Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id 24DDD1205F1 for ; Sun, 7 Jan 2018 05:07:21 -0800 (PST) Received: from [10.168.3.2] (klara.student.utwente.nl [130.89.162.218]) by mail.dovecot.fi (Postfix) with ESMTPSA id 003A12AEF55; Sun, 7 Jan 2018 15:04:03 +0200 (EET) To: Bron Gondwana , extra@ietf.org References: <1515027295.3130822.1223568456.6D1D8F15@webmail.messagingengine.com> From: Stephan Bosch Message-ID: Date: Sun, 7 Jan 2018 14:04:01 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <1515027295.3130822.1223568456.6D1D8F15@webmail.messagingengine.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Extra] SAVEDATE updated required X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 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, 07 Jan 2018 13:07:23 -0000 Hi Bron, Op 1/4/2018 om 1:54 AM schreef Bron Gondwana: > HI Stephan, > > I've also created a couple of tasks for SAVEDATE: > > https://github.com/ietfextra/tracking/issues/12 > https://github.com/ietfextra/tracking/issues/13 Fixed and closed one of these already. For the other one, read further.. > Of course, reading the standard that closely is really good, because > it also forced me to think about it!  I have some opinions! > > 1: if the mailbox doesn't support storing save date, the behaviour > should be to return SAVEDATE NIL/ I agree. Timo also suggested this a while back. I changed this in the last version. > 2: if the mailbox doesn't support storing save date, the SEARCH > extensions should return an error if used, rather than a result, since > there's no way to calculate a sensible answer to any of those three. > > >    SAVEDBEFORE >       Messages whose save date (disregarding time and timezone) is >       earlier than the specified date. > >    SAVEDON >       Messages whose save date (disregarding time and timezone) is >       within the specified date. > >    SAVEDSINCE >       Messages whose save date (disregarding time and timezone) is >       within or later than the specified date. Ok, for the sake of discussion, I added text with this effect in the last version. However, I am not quite happy with it yet. Returning an error seems a bit harsh. Do we need to provide some means for the client to find out whether the mailbox supports the save date attribute before trying to use it? Also, there's the MULTISEARCH extension (RFC7377), which adds an ESEARCH command that allows searching across a wide selection of mailboxes, some of which may in fact lack support for the save date attribute. What is to be done in that case? Fail the whole ESEARCH command? Ignore the mailboxes that lack support? Make the SAVED* search items yield a false result for that mailbox? None of these options seem very appealing. > The "disregarding time and timezone" is a horrorshow if you have users > in multiple timezones, but RFC3501 says that's how BEFORE and AFTER > work for INTERNALDATE commands, so I guess we're stuck with it. Yes, that is what this is based on. > 3: Do we need to define SAVEDATE as a SORT key extending RFC5256 as > well?  In theory it should always sort the same as UID. > I don't think this is particularly useful, although it is not difficult to add. I agree that sorting is normally equal to seq/UID. I checked: Dovecot does not currently implement a sort key for this. Still, this should be a point for discussion. Anyone else wish to comment? I published my git repository and made a new draft submission. Regards, Stephan. -- Stephan Bosch Senior Developer Phone: +49 2761 75252 00 Fax: +49 2761 75252 30 Email: stephan.bosch@dovecot.fi ------------------------------------------------------------------------------------- Open-Xchange AG, Rollnerstr. 14, 90408 Nuremberg, District Court Nuremberg HRB 24738 Managing Board: Rafael Laguna de la Vera, Carsten Dirks, Michael Knapstein Chairman of the Board: Richard Seibt Dovecot Oy, Lars Sonckin Kaari 10, 02600 Espoo, Finland Managing Director: Markku Kentta Chairman of the Board: Timo Sirainen Board Member: Carsten Dirks ------------------------------------------------------------------------------------- From nobody Sun Jan 7 05:46: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 C685A1200C5 for ; Sun, 7 Jan 2018 05:46:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 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, T_RP_MATCHES_RCVD=-0.01] 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 iNvhxALBIjTD for ; Sun, 7 Jan 2018 05:46:26 -0800 (PST) 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 8E05712422F for ; Sun, 7 Jan 2018 05:46:26 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QNK0MWM8WW001RDD@mauve.mrochek.com> for extra@ietf.org; Sun, 7 Jan 2018 05:41:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1515332475; bh=OlB8k00iXTCJF3zHUvbaOmq3S/QOezxIllzyDoCFQiA=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=nojxnGSe10XRbNZlt1+Gw7dNPPDcNGBo5VqBA2SI/br0y+VEf3z4PvLJ3g/BS5RJV Hx2NQRaM09R+Qa40rj4w03crVSXVonKYZRUJQug2BqkyWACW6rG6+DJNWSRPBuxesO xDyWDxOsw78WGQSTSoYxeoWFKZOF0I8xs2upUxtw= 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 <01QNK0JD8F5C000052@mauve.mrochek.com>; Sun, 07 Jan 2018 05:41:02 -0800 (PST) Cc: extra@ietf.org Message-id: <01QNK0MRGMKC000052@mauve.mrochek.com> Date: Sun, 07 Jan 2018 05:39:34 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Fri, 05 Jan 2018 10:40:24 +1100" <1515109224.681625.1224717176.520E1500@webmail.messagingengine.com> References: <1510734636.1704307.1173072248.27572238@webmail.messagingengine.com> <1515028094.3135331.1223576440.053F86DC@webmail.messagingengine.com> <01QNFXVO7LVS000051@mauve.mrochek.com> <4ae4f1d5-bf40-483a-ae88-befe01d3adef@gulbrandsen.priv.no> <7C65B98D-6755-4957-A181-CBA08354D11B@glyphein.mailforce.net> <1515109224.681625.1224717176.520E1500@webmail.messagingengine.com> To: Bron Gondwana Archived-At: Subject: Re: [Extra] Sieve REJECT and :fcc [was Re: Meeting minutes and notes from today] X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 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, 07 Jan 2018 13:46:28 -0000 > Is everybody OK with having fcc not include reject, and having a > separate capability (fcc-reject or similar) which administrators can > decide whether or not to allow - and indeed, software implementations > the choice whether or not to implement. Not without the added condition that a MDN MUST be used if :fcc is present. > That fixes both issues - those who really want the ability to lie can do > so, but it's clear that they're enabling that facility, and it's also > possible for both software vendors and administrators to not provide the > facility in the first place. My issue is that we have no business messing with the meaning of a 5YZ code in response to a message transder. That cannot be fixed with capabilities. Ned From nobody Sun Jan 7 06:49:17 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 1EC44124B18; Sun, 7 Jan 2018 06:49:16 -0800 (PST) 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.68.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151533655607.10858.793231788332492256@ietfa.amsl.com> Date: Sun, 07 Jan 2018 06:49:16 -0800 Archived-At: Subject: [Extra] I-D Action: draft-ietf-extra-sieve-special-use-01.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 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, 07 Jan 2018 14:49:16 -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 Email Filtering: Delivering to Special-Use Mailboxes Author : Stephan Bosch Filename : draft-ietf-extra-sieve-special-use-01.txt Pages : 8 Date : 2018-01-07 Abstract: The SPECIAL-USE capability of the IMAP protocol (RFC 6154) allows clients to identify special-use mailboxes; e.g., where draft or sent messages should be put. This simplifies client configuration. 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 test for checking whether a special-use attribute is assigned for a particular mailbox or any mailbox, and it adds the ability to file messages into an anonymous mailbox that has a particular special-use attribute assigned. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-extra-sieve-special-use/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-extra-sieve-special-use-01 https://datatracker.ietf.org/doc/html/draft-ietf-extra-sieve-special-use-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-sieve-special-use-01 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 Sun Jan 7 06:57: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 0C538126CE8 for ; Sun, 7 Jan 2018 06:57:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 ypYESUNmgXqH for ; Sun, 7 Jan 2018 06:57:26 -0800 (PST) Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB31124B18 for ; Sun, 7 Jan 2018 06:57:26 -0800 (PST) Received: from [10.168.3.2] (klara.student.utwente.nl [130.89.162.218]) by mail.dovecot.fi (Postfix) with ESMTPSA id 9C47C2AEF55 for ; Sun, 7 Jan 2018 16:57:24 +0200 (EET) To: extra@ietf.org References: <151533655607.10858.793231788332492256@ietfa.amsl.com> From: Stephan Bosch Message-ID: Date: Sun, 7 Jan 2018 15:57:23 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <151533655607.10858.793231788332492256@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 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.22 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, 07 Jan 2018 14:57:28 -0000 Op 1/7/2018 om 3:49 PM schreef internet-drafts@ietf.org: > 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 Email Filtering: Delivering to Special-Use Mailboxes > Author : Stephan Bosch > Filename : draft-ietf-extra-sieve-special-use-01.txt > Pages : 8 > Date : 2018-01-07 Submitted a new version of this draft. Not much has changed. The significant changes are as follows: - Addresses a comment by Stan Kalisch: refer to the variables extension in Security Considerations section. - Addresses a final FIXME item in the Acknowledgements section. It adds credits for some borrowed text. The revisions are tagged in the git repository, so you can check the changes there in more detail. Regards, -- Stephan Bosch Senior Developer Phone: +49 2761 75252 00 Fax: +49 2761 75252 30 Email: stephan.bosch@dovecot.fi ------------------------------------------------------------------------------------- Open-Xchange AG, Rollnerstr. 14, 90408 Nuremberg, District Court Nuremberg HRB 24738 Managing Board: Rafael Laguna de la Vera, Carsten Dirks, Michael Knapstein Chairman of the Board: Richard Seibt Dovecot Oy, Lars Sonckin Kaari 10, 02600 Espoo, Finland Managing Director: Markku Kentta Chairman of the Board: Timo Sirainen Board Member: Carsten Dirks ------------------------------------------------------------------------------------- From nobody Sun Jan 7 12:15:49 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 D6ABB126C2F for ; Sun, 7 Jan 2018 12:15:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mailforce.net header.b=ww2HBb3S; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=PzjFR8ck Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gp5BmQVrSN7Q for ; Sun, 7 Jan 2018 12:15:46 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 381D11241FC for ; Sun, 7 Jan 2018 12:15:46 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 5CB7620AF8; Sun, 7 Jan 2018 15:15:45 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Sun, 07 Jan 2018 15:15:45 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailforce.net; 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=fm2; bh=YTIfh5F2FDDz28+6T mRv1YPf04KBTMAO56ZS4IAaS+U=; b=ww2HBb3SjM7urDmr7Cv4GCj9WvbjVa3b+ DlkFIu5yxMxovnKgLSE9HReE1by2c4lRNPngoX1U+ALU1sSRt1NQg8R3Z3UIGfSM hJ3r4HSP0WHL4qppu8sS7FMfrdl2Y9v2FzvRBI5O2e0Njozxil/b91Uq5rvV74G/ ZOQBQulgVaDso4Vj0DOR8U6ul0rtFUgXk32uY7l0/Baj+091TRQF48BFau5bXcy4 V2O02+dZ4TU3OvuLu0FP33U+JNzWd4QevWAUF7DPvTfVdC6/oacQ2ngVKCDcT138 zkYT/TiHAoT64yIJjV5+IRDJ1LNQ9G5XPAuCmENT57wywBC4S5DAA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=YTIfh5 F2FDDz28+6TmRv1YPf04KBTMAO56ZS4IAaS+U=; b=PzjFR8ckr8NxenzLtqU1Uy JTulFPusqlap6W0dXZzg3286TbWJhyLOWkUINZOS90pcmrUyOV/g1JRagqTFaIPd pyU2fWhOcKW/Sl3mcZcp9MqG6R7c7vc34ravxXr8FUeDUTyMciMzl5cb/vPhcfVF HfJzPePfb+I5ykK0EXfLGJFIepJ+ipzPl9qacc8G8zRrM/bHdsxaP97x0l/jA00g 8CsskLn+6cOe/UC3KXbtET6zq5XMXlmGbHptEpB034Sm/isV3TQokmlQRo8Eshzp m9hFtn4bVAZlf2H42fl8LkI0FMp9iuhtiZny4W7Nuh1G25FykYgReF+qLjmFHoxQ == X-ME-Sender: Received: from [192.168.1.71] (108-84-31-27.lightspeed.tukrga.sbcglobal.net [108.84.31.27]) by mail.messagingengine.com (Postfix) with ESMTPA id F26C17E322; Sun, 7 Jan 2018 15:15:44 -0500 (EST) References: <1510734636.1704307.1173072248.27572238@webmail.messagingengine.com> <1515028094.3135331.1223576440.053F86DC@webmail.messagingengine.com> <01QNFXVO7LVS000051@mauve.mrochek.com> <4ae4f1d5-bf40-483a-ae88-befe01d3adef@gulbrandsen.priv.no> <7C65B98D-6755-4957-A181-CBA08354D11B@glyphein.mailforce.net> <1515109224.681625.1224717176.520E1500@webmail.messagingengine.com> <01QNK0MRGMKC000052@mauve.mrochek.com> In-Reply-To: <01QNK0MRGMKC000052@mauve.mrochek.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: Cc: Bron Gondwana , extra@ietf.org X-Mailer: iPhone Mail (13G36) From: Stan Kalisch Date: Sun, 7 Jan 2018 15:15:40 -0500 To: Ned Freed Archived-At: Subject: Re: [Extra] Sieve REJECT and :fcc [was Re: Meeting minutes and notes from today] X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 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, 07 Jan 2018 20:15:48 -0000 On Jan 7, 2018, at 8:39 AM, Ned Freed wrote: >> Is everybody OK with having fcc not include reject, and having a >> separate capability (fcc-reject or similar) which administrators can >> decide whether or not to allow - and indeed, software implementations >> the choice whether or not to implement. >=20 > Not without the added condition that a MDN MUST be used if :fcc is present= . Again, RFC 5429 explicitly mentions messages that have been rejected and the= n archived. It does not require MDNs for them. In fact, the section where i= t discusses archiving rejected messages refers to both MDNs and DSNs. How d= oes using :fcc/:fcc-reject meaningfully semantically differ from just chaini= ng fileinto and reject? The only additional thing you retain is the outgoin= g rejection message; the original message that was rejected is still (per th= e requirements of the spec) the same. >> That fixes both issues - those who really want the ability to lie can do >> so, but it's clear that they're enabling that facility, and it's also >> possible for both software vendors and administrators to not provide the >> facility in the first place. >=20 > My issue is that we have no business messing with the meaning of a 5YZ > code in response to a message transder. I think it's a bit hasty to say "messing". After all, 5YZ codes were adapte= d over the years for spam. No one is suggesting to overtly add "stalking" o= r something like that to the IANA registry. But why throw the baby out with= the bathwater and close the door to a possible future algorithm or procedur= e that carefully attempts to address at least a subset of these things? Thanks, Stan= From nobody Sun Jan 7 12:24:54 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 23A16126C2F for ; Sun, 7 Jan 2018 12:24:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 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, T_RP_MATCHES_RCVD=-0.01] 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 z3V0sHcc5-V1 for ; Sun, 7 Jan 2018 12:24:50 -0800 (PST) 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 DE1C61241FC for ; Sun, 7 Jan 2018 12:24:49 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QNK22M6RPS001T5M@mauve.mrochek.com> for extra@ietf.org; Sun, 7 Jan 2018 06:22:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1515334931; bh=SVA0EWdV6ZuVTNaUyn1OmslnRS6k1QI50woQ3Zdf930=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=k+V1AtkTLwQSDWuKnA7ZP+6cNa55hXZrnssPNqIDwzpQ3tZXkHqvubWNWpUw0Z6Ii oI39nh8rE1ZmR8MLY38EzSw1YtUc7QSI7cI+Z1E53otAK0Osudy35+mMjgVeL6ec+v knKNlcTJNpo0xphnz/1IDwdXb/MvsyjHkqLJ84YQ= MIME-version: 1.0 Content-transfer-encoding: QUOTED-PRINTABLE Content-type: TEXT/PLAIN; charset=utf-8 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QNFVO5W1CW000051@mauve.mrochek.com>; Sun, 07 Jan 2018 06:21:55 -0800 (PST) Cc: Ned Freed , Bron Gondwana , extra@ietf.org, Murchison Ken Message-id: <01QNK22FBJC0000051@mauve.mrochek.com> Date: Sun, 07 Jan 2018 05:42:09 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Thu, 04 Jan 2018 14:40:36 -0500" References: <1510734636.1704307.1173072248.27572238@webmail.messagingengine.com> <1515028094.3135331.1223576440.053F86DC@webmail.messagingengine.com> <01QNFXVO7LVS000051@mauve.mrochek.com> To: Stan Kalisch Archived-At: Subject: Re: [Extra] Sieve REJECT and :fcc [was Re: Meeting minutes and notes from today] X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 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, 07 Jan 2018 20:24:52 -0000 > On Jan 4, 2018, at 10:17 AM, Ned Freed wrot= e: > >>> On Fri, 17 Nov 2017, at 09:06, Stan Kalisch wrote: > >>> > >>> Hi, > >>> > >>> On Nov 15, 2017, at 3:30 AM, Bron Gondwana > >>> wrote:>> *There is an open question fo= r this one:* > >>>> > >>>> https://datatracker.ietf.org/doc/draft-ietf-extra-sieve-fcc/ > >>>> > >>>> Ned Freed objected to supporting :fcc for the REJECT action be= cause > >>>> it allows the sieve server to "lie" about whether it's keeping= a copy > >>>> of the message. There was debate about whether we should stop= people > >>>> lying at this level, especially since a mail flow could take a= copy > >>>> of every single email before it reached sieve.> > > > > That's true but beside the point. Making service-level copies of = messages is > > one thing, giving users a direct way to conveniently say "I didn'= t get this > > message" when they actually did is quite another. > Perhaps, but, after all, reject already provides that facility. Bu= t that's not the central point of my argument in favor of allowing re= ject to invoke :fcc. > Some users have arguably (at least, certainly morally) legitimate r= easons to > lie about the delivery of mail. The users who first come to my min= d are > survivors of domestic violence and/or sexual assault. I object even more strongly to this justification for adding such a f= eature. There are at least two problems here: We haven't even attempted to wo= rk through all the security implications of trying to hide delivery of email. (R= ejection after delivery is another matter entirely, but we're not talking abou= t that here.) There are all sorts of ways information can leak and getting this wro= ng in matters of life and death is completely unacceptable. (You might star= t by thinking about the handling of multi-recipient cases and how you inte= nd to maintain the privacy of bcc recipients while maintaining a consistent appearance of the DSNs you send back versus the ones you provide via = :fcc.) Additionally, even if we do all the work to specify this properly, do= you think implementors will get it right? Past experiences says the chances of = that are essentially nil. And a badly implemented system of this sort could ca= use exactly the harm it was trying to prevent. More generally, the business of mail interception for legal/law enfor= cment purposes should not be delegated to - let's face it - an obscure feat= ure on an obscure extension. It's too important for that, and too important to = get right. > Google surely had in > mind stalking and harassment when it provided Google Voice a mechan= ism to lie > about whether or not someone had placed a call to a user's valid ph= one number.=20 This would be more or less equivalent to an MSP providing the means t= o say "this is not a valid address" instead of saying "you're not allowed = to send to this address". Which Sieve reject provides, modulo the ability to use= a 5.1.1 response versus a 5.7.x response code. (A feature our implement= ation provides for system-level sieves.) However, a word of caution about side channel risks is once again in = order. 5.1.1 no such user responses are typically given to RCPT TO; whereas = Sieves responses come after the message has been transferred. So it may be = possible to tell when such a mechanism is used. And let's please not entertain the notion that we can simply ignore side-channel attacks here. Not to put too fine a point on it, but it = seems a bunch of Intel engineers thought that way back in the 90s, and look w= here we are now. > Granted, backscatter, MDN, DSN, etc., of course, aren't even periph= eral > considerations in rolling out something like that for phone calls. = But, again, > we're only talking about :fcc; reject's ship has already sailed. I have no idea what this means. > I acknowledge your point that "delivery failed" is conspicuous by v= irtue of the fact that it is missing from RFC 8098. And I can't say = that this gives me no pause of any kind. But it still seems to me, w= hen you look at both the technical and very real human considerations= , that this effort is more trouble than it's worth=E2=80=94I'm having= a hard time believing adding :fcc to reject is substantially going t= o increase reject's (mis)use. So this strikes me as something that, = in effect, merely serves as a lecture to users who may lie, but 1) ar= e not necessarily sanguine or happy about lying, and 2) may actually = have the need to lie. That is a scenario that is not implausible at = all. It is a privacy issue. I don't want to *encourage* users to li= e, but, on the other hand, I don't think the technical arguments are = strong enough for the IETF to dictate that a language does or does no= t deal with such problems. That should really be entrusted to users = and administrators. Some things, in the end, have to be entru > to the community. And again, I have no objection whatsoever to reject :fcc generating a= "deleted" MDN response. But once again you have the side channel situation to c= onsider - reject :fcc causing a different response than reject without :fcc als= o leaks information. =09=09=09=09Ned From nobody Sun Jan 7 12:30:17 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 82C93126C2F for ; Sun, 7 Jan 2018 12:30:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 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, T_RP_MATCHES_RCVD=-0.01] 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 6Qh8UYCPVX8L for ; Sun, 7 Jan 2018 12:30:13 -0800 (PST) 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 606FA1241FC for ; Sun, 7 Jan 2018 12:30:13 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QNKEQ84LXS001V81@mauve.mrochek.com> for extra@ietf.org; Sun, 7 Jan 2018 12:24:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1515356713; bh=zyDLNd+572OSZzoWaTHUzykn+61oA/vkz3k8OUmH07o=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=Gac6FEAQbt/skTI9qI9+lsRD6gUfKSFVB4JXfcAcLsrHd85nn1t1KvTakwecF20xq E4ej3nXgDVc6sYb6MqilQXBziEaGREtSSOFzKpuCgiHYDO9tExPhDO+Z5frsO9gNe8 ukzKnuPP6XjtXeLMYQ8a8fHEJkKULNRHncnCJP+I= 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 <01QNFVO5W1CW000051@mauve.mrochek.com>; Sun, 07 Jan 2018 06:32:02 -0800 (PST) Cc: extra@ietf.org Message-id: <01QNK2F0RI5W000051@mauve.mrochek.com> Date: Sun, 07 Jan 2018 06:26:32 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Thu, 04 Jan 2018 20:40:41 -0500" <2520156B-CD12-4204-9940-A003CDBB686B@glyphein.mailforce.net> References: <1510734636.1704307.1173072248.27572238@webmail.messagingengine.com> <1515028094.3135331.1223576440.053F86DC@webmail.messagingengine.com> <01QNFXVO7LVS000051@mauve.mrochek.com> <4ae4f1d5-bf40-483a-ae88-befe01d3adef@gulbrandsen.priv.no> <7C65B98D-6755-4957-A181-CBA08354D11B@glyphein.mailforce.net> <1515109224.681625.1224717176.520E1500@webmail.messagingengine.com> <2520156B-CD12-4204-9940-A003CDBB686B@glyphein.mailforce.net> To: Stan Kalisch Archived-At: Subject: Re: [Extra] Sieve REJECT and :fcc [was Re: Meeting minutes and notes from today] X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 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, 07 Jan 2018 20:30:14 -0000 > > On Jan 4, 2018, at 6:40 PM, Bron Gondwana wrote: > > > > Is everybody OK with having fcc not include reject, and having a separate capability (fcc-reject or similar) which administrators can decide whether or not to allow - and indeed, software implementations the choice whether or not to implement. > > > > That fixes both issues - those who really want the ability to lie can do so, but it's clear that they're enabling that facility, and it's also possible for both software vendors and administrators to not provide the facility in the first place. > I personally think it should be up to administrators only, but I recognize > that's an ugly hack to the spec already in place. So I'm okay with it. System-level (or if you prefer, administrative) sieve use is not something our standards cover. They are exclusively focused on user sieves. And you can't simply throw in an administrative feature or three willy-nilly without looking at the whole picture, which turns out to be fairly complicated. Many years ago Jutta Degener and I proposed working on extending our documents to cover the system-level case. There was some apetite for that, but unfortunately the absoltuely appalling handling of sieve base specification revision by the IESG at the time drained the energy of the group and that, as they say, was that. I certainly would not object to work in this area, but I'm skeptical that there's sufficient interest. Ned From nobody Sun Jan 7 12:30: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 2D4D31241FC for ; Sun, 7 Jan 2018 12:30:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 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, T_RP_MATCHES_RCVD=-0.01] 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 g70lczzTCnpn for ; Sun, 7 Jan 2018 12:30:14 -0800 (PST) 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 DFDF91243F6 for ; Sun, 7 Jan 2018 12:30:13 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QNKEQ84LXS001V81@mauve.mrochek.com> for extra@ietf.org; Sun, 7 Jan 2018 12:24:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1515356715; bh=At4leYUrvyje+AOttdwK8r/h2VQ/ehdRYGCW7LFZ0b4=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=EVSKS4FTnSGmtVnzbW6AmDfPwyCeHn3x3FE96zvZ2I5T2poYokaLel3Z6uZbDi+mX J3tjXbccOVe9WxoYIgBs7y7TT/1FyTbDM76KLlmBIud8gF1Pw+wz2oFy0LtinOt7is EpokB9H0r7hVFTieznSr6T/O4gU6NE2grdL7eVNw= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QNFVO5W1CW000051@mauve.mrochek.com>; Sun, 07 Jan 2018 07:47:50 -0800 (PST) Cc: extra@ietf.org, Ned Freed Message-id: <01QNK51YQ2JI000051@mauve.mrochek.com> Date: Sun, 07 Jan 2018 07:33:03 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Thu, 04 Jan 2018 19:07:50 +0100" References: <1510734636.1704307.1173072248.27572238@webmail.messagingengine.com> <1515028094.3135331.1223576440.053F86DC@webmail.messagingengine.com> <01QNFXVO7LVS000051@mauve.mrochek.com> <2d0523cb-5b0b-4cd0-8fd5-301ccbbc4342@gulbrandsen.priv.no> <01QNG1OISUGO000051@mauve.mrochek.com> To: Arnt Gulbrandsen Archived-At: Subject: Re: [Extra] Meeting minutes and notes from today X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 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, 07 Jan 2018 20:30:15 -0000 > Right. I feel that the main disconnect here is that the reject/fcc > combination may cause one party (the site/company/...) to make a false > representation about delivery on the instructions of another (the > addressee). That's part of it, but not the entire story. The main issue is undoubtedly the ability of a user to get the site as a whole to lie about whether or mail was delivered to them. But consider the case of system-level use of reject :fcc. This is also problematic. For one thing, if this results in a 5YZ response in the SMTP diaglogue, the :fcc copy is going to differ from the DSN that's sent to the originator (assuming a DSN is even sent - what about SUBMIT?). So what you have here is a different form of lying: The administrator (or however owns the system-level sieve) gets a wholly synthetic DSN that may differ substantially from what the remote system actually sent. I suppose you could address this issue by making the action of :fcc conditional on whether or not a DSN/MDN, on the theory that the point of :fcc is to capture the DSN/MDN, not the underlying message. I also note in passing that it's not a reliable means of capturing the underlying message, since the DSN/MDN may not include the whole thing. So it's actually kind of a worst case: You can't be sure that the message is there, but you also can't assume it isn't. > When those two are the same, this is okayish. Lying on my > own accord is not pretty, but it is better than lying because someone > else told me to. > The right answer may be that reject/fcc should be > available only when the mta owner and the script owner are the same. Or > that may be unwarranted complexity, and the right answer is to cater to > one of the two cases and knowingly disregard the other. I don't think this addresses all the issues. What does appear to me to do so is to require the use of an MDN for user-level reject :fcc. As for system-level, I'll again point out that we lack the necessary context for discussing this in our documents, but if we were to do so I'd say :fcc on a system-level sieve only provides a copy of the DSN if the system produced one. Ned From nobody Sun Jan 7 13:46:17 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 8F1D6124F57 for ; Sun, 7 Jan 2018 13:46:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 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, T_RP_MATCHES_RCVD=-0.01] 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 6lMruAvWYgwS for ; Sun, 7 Jan 2018 13:46:14 -0800 (PST) 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 4E4E7124239 for ; Sun, 7 Jan 2018 13:46:14 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QNKHFRS51C001XDO@mauve.mrochek.com> for extra@ietf.org; Sun, 7 Jan 2018 13:42:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1515361386; bh=qmZc6h4/+VTQKqRpfE0pZEQKUlGXzBrgbbxi9juCqAQ=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=BoL1iCkmU3U48rtfcarTNFtU2Ba2DVt10oEcjqA9tRtYuRkp20i3Ndnnoj7dy/H+q JFzTg/YZ1NHaIPP8t/izgp4pLVddPKpx8fwM/m1KcuwXE5EH8rTq/3RK6NwOr/8GFw NrpmaRBvLnExughFUeVv5LeYvt2wdLx5mImxFxhM= 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 <01QNFVO5W1CW000051@mauve.mrochek.com>; Sun, 07 Jan 2018 13:42:29 -0800 (PST) Cc: Ned Freed , Bron Gondwana , extra@ietf.org Message-id: <01QNKHFPA38A000051@mauve.mrochek.com> Date: Sun, 07 Jan 2018 13:21:57 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Sun, 07 Jan 2018 15:15:40 -0500" References: <1510734636.1704307.1173072248.27572238@webmail.messagingengine.com> <1515028094.3135331.1223576440.053F86DC@webmail.messagingengine.com> <01QNFXVO7LVS000051@mauve.mrochek.com> <4ae4f1d5-bf40-483a-ae88-befe01d3adef@gulbrandsen.priv.no> <7C65B98D-6755-4957-A181-CBA08354D11B@glyphein.mailforce.net> <1515109224.681625.1224717176.520E1500@webmail.messagingengine.com> <01QNK0MRGMKC000052@mauve.mrochek.com> To: Stan Kalisch Archived-At: Subject: Re: [Extra] Sieve REJECT and :fcc [was Re: Meeting minutes and notes from today] X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 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, 07 Jan 2018 21:46:15 -0000 > On Jan 7, 2018, at 8:39 AM, Ned Freed wrote: > >> Is everybody OK with having fcc not include reject, and having a > >> separate capability (fcc-reject or similar) which administrators can > >> decide whether or not to allow - and indeed, software implementations > >> the choice whether or not to implement. > > > > Not without the added condition that a MDN MUST be used if :fcc is present. > Again, RFC 5429 explicitly mentions messages that have been rejected and > then archived. You're referring to this paragraph: However, there are existing laws requiring certain organizations to archive all received messages, even the rejected ones. Also, it can be quite useful to save copies of rejected messages for later analysis. This is in reference to legal intercept, compliance archiving, and similar mechanisms. This has nothing whatsoever to do with giving random users the means to falsely claim that a message wasn't delivered when in fact it was. > It does not require MDNs for them. Of course it doesn't. In many cases legal intercept requirements call for the interception to be done invisibly. > In fact, the section where it discusses archiving rejected messages refers > to both MDNs and DSNs. How does using :fcc/:fcc-reject meaningfully > semantically differ from just chaining fileinto and reject? See above. One is a tool for users to keep track of the messages sent on their behalf by sending them a copy of those messages; the other is a tool for organizations and law enforcement intended to monitor some subset of the traffic the site receives. Semantically they aren't even close. I'll also note that the requirements of legal intercept are in general not met by keeping copies of MDNs and DSNs for rejected messages; in many if not most cases those MDNs and DSNs do not contain the entire message and even when they do the message may not be in its original form. > The only additional thing you retain is the outgoing rejection message; the > original message that was rejected is still (per the requirements of the spec) > the same. The same as what the sieve agent received. Which can be and often is markedly dissimilar to what came in over the wire. Legal intercept tends to favor collection of the latter, and may require it. > >> That fixes both issues - those who really want the ability to lie can do > >> so, but it's clear that they're enabling that facility, and it's also > >> possible for both software vendors and administrators to not provide the > >> facility in the first place. > > > > My issue is that we have no business messing with the meaning of a 5YZ > > code in response to a message transder. > I think it's a bit hasty to say "messing". After all, 5YZ codes were adapted > over the years for spam Actually, no. AFAIK the only time RFC 5321 has been updated to add a 5YZ code is by RFC 7504, which adds 521 and 556: 521 Host does not accept mail 556 Domain does not accept mail Neither of these have anything to do with handling spam. > No one is suggesting to overtly add "stalking" or > something like that to the IANA registry. But why throw the baby out with the > bathwater and close the door to a possible future algorithm or procedure that > carefully attempts to address at least a subset of these things? I have no idea what this is in reference to. I'm only talking about the handling of reject :fcc here. Ned From nobody Sun Jan 7 14:04:31 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 5F9DF126D45 for ; Sun, 7 Jan 2018 14:04:29 -0800 (PST) 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=sjjvcLr1; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=EMcO5kyx Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qL0LNr2m71Gw for ; Sun, 7 Jan 2018 14:04:27 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68D95124239 for ; Sun, 7 Jan 2018 14:04:27 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id B021A20B52; Sun, 7 Jan 2018 17:04:26 -0500 (EST) Received: from web2 ([10.202.2.212]) by compute6.internal (MEProxy); Sun, 07 Jan 2018 17:04:26 -0500 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=fm1; bh=Bbwx49AWfiXVbPSIh IKgqKw6ZTSWj1/91lwG0hdIMDE=; b=sjjvcLr1H/CnsZZy0VE8DWDZZuVOaZvkD oXx8s2Df2xxevn1CoaNdTi57kstl7NwkLR1ZThSynSkCToy1pBx9YqWxHUoM8qTn 62Fumm1oddl7snLE+qZ9D7X5gqkYtCMmh02Ag7D3VYZRztqday2XHK9RzJx5RW8a IWSgFgx2exxy5clhdD/HFgf8uIiiBvforsrRDQjqP0xuCSEnC3+2Q8Emqgea0SBo ADEYQ7PcQsNuYXnmNPuE+Gs5Zua9YJiKcOj9U2D2IT/0D9llvO1NkzmfDce/JDon aNvY0c7RvNTsASRz/h7aqofnzWbplRLtM1yQouoKx5A/+1/Vo1aGg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=Bbwx49 AWfiXVbPSIhIKgqKw6ZTSWj1/91lwG0hdIMDE=; b=EMcO5kyxHBRlLKVCm19bF7 Od0fd0L/WYGHLTEo4uEP6W4FPn05TZ12M2he/e4NoFj+xr1mZwyiK/Yw5d1cwfl4 88kzH+eweDdc9gBqZH7ctVKg6BtLRrwHbsF3QHiudW2dr5ML5wWMHf171biz0Rxn Fdpcnvh6Mc6wFLiNU0POMplfri6PtExWOiChwzw5LrXuxYzPoTGR620LuKUDVL1Z f+H2+LWgcqQL9UO84Cdqg3FQaP3tUAjAvBkCfUXy+wZ2rmThkYeih4M6EJ7PkX5F h5L2Ho5geM6Kte7C03jsX1Hrw5McuednqS8JCGOHw1zfHBWYhP5y2kb8BAQmHhyg == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 87A3A62B9F; Sun, 7 Jan 2018 17:04:26 -0500 (EST) Message-Id: <1515362666.2687647.1227253816.726EA133@webmail.messagingengine.com> From: Bron Gondwana To: Stephan Bosch , extra@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_151536266626876470" X-Mailer: MessagingEngine.com Webmail Interface - ajax-1d83f2c7 References: <1515027295.3130822.1223568456.6D1D8F15@webmail.messagingengine.com> In-Reply-To: Date: Mon, 08 Jan 2018 09:04:26 +1100 Archived-At: Subject: Re: [Extra] SAVEDATE updated required X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 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, 07 Jan 2018 22:04:29 -0000 This is a multi-part message in MIME format. --_----------=_151536266626876470 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Mon, 8 Jan 2018, at 00:04, Stephan Bosch wrote: > Hi Bron, > > Op 1/4/2018 om 1:54 AM schreef Bron Gondwana: >> 2: if the mailbox doesn't support storing save date, the SEARCH >> extensions should return an error if used, rather than a >> result, since>> there's no way to calculate a sensible answer to any of those three.>> >> >> SAVEDBEFORE >> Messages whose save date (disregarding time and timezone) is >> earlier than the specified date. >> >> SAVEDON >> Messages whose save date (disregarding time and timezone) is >> within the specified date. >> >> SAVEDSINCE >> Messages whose save date (disregarding time and timezone) is >> within or later than the specified date. > > Ok, for the sake of discussion, I added text with this effect in the > last version. However, I am not quite happy with it yet. Returning an> error seems a bit harsh. Do we need to provide some means for > the client> to find out whether the mailbox supports the save date > attribute before> trying to use it? That could be done: TAG select "foo" * 1 EXISTS * 1 RECENT * FLAGS (\Answered \Flagged \Draft \Deleted \Seen) * OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Seen \*)] Ok * OK [UNSEEN 1] Ok * OK [UIDVALIDITY 1515362059] Ok * OK [UIDNEXT 2] Ok * OK [HIGHESTMODSEQ 7] Ok * OK [URLMECH INTERNAL] Ok * OK [ANNOTATIONS 65536] Ok TAG OK [READ-WRITE] Completed Another line in there that said something like: * OK [SAVEDATE] Ok Would probably work fine. > Also, there's the MULTISEARCH extension (RFC7377), which adds > an ESEARCH> command that allows searching across a wide selection of > mailboxes, some> of which may in fact lack support for the save date attribute. What is> to be done in that case? Fail the whole ESEARCH command? Ignore the > mailboxes that lack support? Make the SAVED* search items yield a > false> result for that mailbox? None of these options seem very appealing. There are three choices: 1) reject the command if any folder doesn't support SAVEDATE 2) reject the command if none of the folders support SAVEDATE 3) succeed regardless of the support for SAVEDATE And if there are folders that don't support SAVEDATE for case 2 or 3, you can:a) use the INTERNALDATE instead b) don't match the message I think (a) is clearly wrong here - if you're deleting everything that's SAVEDBEFORE 1 month ago from a Trash folder, then INTERNALDATE will purge things before you want to. The alternative is to treat SAVEDATE as NULL in the same way SQL does, and I think that's the right choice. So you can say "SEARCH NOT SAVEDAFTER {X} BEFORE {X}" if you want to get the behaviour of deleting everything that was SAVEDBEFORE a time, or fallback to INTERNALDATE if it's not supported. >> 3: Do we need to define SAVEDATE as a SORT key extending RFC5256 as >> well? In theory it should always sort the same as UID. > > I don't think this is particularly useful, although it is not > difficult> to add. I agree that sorting is normally equal to seq/UID. I checked:> Dovecot does not currently implement a sort key for this. I'm fine with not having it. By the way, I have plans for a JMAP extension which maps SAVEDATE into JMAP. Have been chatting with Neil about it. It seems a good first case for an example extension :) Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_151536266626876470 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Mon, 8 Jan 2018, at 00:04, Stephan Bosch wrote:
Hi Bron,

Op 1/4/2018 om 1:54 AM schreef Bron Gondwana:
2: if the mailbox doesn't support storing save date, the SEARCH
extensions should return an error if used, rather than a result, since
there's no way to calculate a sensible answer to any of those three.


   SAVEDBEFORE <date>
      Messages whose save date (disregarding time and timezone) is
      earlier than the specified date.

   SAVEDON <date>
      Messages whose save date (disregarding time and timezone) is
      within the specified date.

   SAVEDSINCE <date>
      Messages whose save date (disregarding time and timezone) is
      within or later than the specified date.

Ok, for the sake of discussion, I added text with this effect in the
last version. However, I am not quite happy with it yet. Returning an
error seems a bit harsh. Do we need to provide some means for the client
to find out whether the mailbox supports the save date attribute before
trying to use it?

That could be done:

TAG select "foo"
* 1 EXISTS
* 1 RECENT
* FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
* OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Seen \*)] Ok
* OK [UNSEEN 1] Ok
* OK [UIDVALIDITY 1515362059] Ok
* OK [UIDNEXT 2] Ok
* OK [HIGHESTMODSEQ 7] Ok
* OK [URLMECH INTERNAL] Ok
* OK [ANNOTATIONS 65536] Ok
TAG OK [READ-WRITE] Completed

Another line in there that said something like:

* OK [SAVEDATE] Ok

Would probably work fine.

Also, there's the MULTISEARCH extension (RFC7377), which adds an ESEARCH
command that allows searching across a wide selection of mailboxes, some
of which may in fact lack support for the save date attribute. What is
to be done in that case? Fail the whole ESEARCH command? Ignore the
mailboxes that lack support? Make the SAVED* search items yield a false
result for that mailbox? None of these options seem very appealing.

There are three choices:
1) reject the command if any folder doesn't support SAVEDATE
2) reject the command if none of the folders support SAVEDATE
3) succeed regardless of the support for SAVEDATE

And if there are folders that don't support SAVEDATE for case 2 or 3, you can:
a) use the INTERNALDATE instead
b) don't match the message

I think (a) is clearly wrong here - if you're deleting everything that's SAVEDBEFORE 1 month ago from a Trash folder, then INTERNALDATE will purge things before you want to.

The alternative is to treat SAVEDATE as NULL in the same way SQL does, and I think that's the right choice.  So you can say "SEARCH NOT SAVEDAFTER {X} BEFORE {X}" if you want to get the behaviour of deleting everything that was SAVEDBEFORE a time, or fallback to INTERNALDATE if it's not supported.

3: Do we need to define SAVEDATE as a SORT key extending RFC5256 as
well?  In theory it should always sort the same as UID.

I don't think this is particularly useful, although it is not difficult
to add. I agree that sorting is normally equal to seq/UID. I checked:
Dovecot does not currently implement a sort key for this.

I'm fine with not having it.

By the way, I have plans for a JMAP extension which maps SAVEDATE into JMAP.  Have been chatting with Neil about it.  It seems a good first case for an example extension :)

Bron.

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


--_----------=_151536266626876470-- From nobody Sun Jan 7 14:57:42 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 1B005126DC2 for ; Sun, 7 Jan 2018 14:57:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mailforce.net header.b=Hyar7+YE; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=YO/5Sp9N Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N27Wr4-TZb0G for ; Sun, 7 Jan 2018 14:57:39 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F76D126DED for ; Sun, 7 Jan 2018 14:57:39 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 28A0A20B4C for ; Sun, 7 Jan 2018 17:57:38 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Sun, 07 Jan 2018 17:57:38 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailforce.net; 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=fm2; bh=YejpYvgLUe0Toh8y4xyj9dgAJuW44 SBZs61oR7suW8A=; b=Hyar7+YEtpa3vOE59yFDavazggTq2+JEC9asPNb3cse9g wKbiYSE6BXB3K5eeYnenXIuGPJeuMUOoAsz57yx62BpaDX43pch3ao8HHq5+4Zic uqjCsZuXrQEFt9bVEVPWJvhcUbRBS7REnteUFNPOxeCN69Wh6eDW4+4mZH2yTHsY lHkjHipZ+qCT70WEWBUp4UU/4ockpJahgKYPxeNtHQE3cKeelDjYyaHc6cdTuMmR WHjzvvemNSk5+emqiBGaIrnluP5z3M04XUKq3nUp3O4JtRMLmCZss670yZB8ugT+ +aI+PX+Rp/l/+4H1j0yrY3xz1oOQ8f7jTSyv/IXUw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=YejpYv gLUe0Toh8y4xyj9dgAJuW44SBZs61oR7suW8A=; b=YO/5Sp9N7U2Lsx8druj7OX FVjrgkC2Au3s+0+OK60dG7lVmji9dwZz/bhm32y6iETcbJfveVAR44JS7C88lWYX Of1EsI+i94vVB9oLaapEfSdH/QsWwl5ujW2tJs/1QMbQwFPcyic+aBAvLhrK6Nn8 +R3J1vJ65GgzkJ7ndNANx9gruYCSFt4RaLTtAsUV5S40wfsUvQwWAKRVJmxRJMMg h3XLEyQBClILrcnPavqyyB/EAeH0K2LMEWU70goisH30eGTxH/uUhYB1ZNsooIx+ RNYs5DyQKGOYWErb7eONvwtF5xiC9N2OmYD77UNyfGJJc5tkPFKc//BJy770Y4Jg == X-ME-Sender: Received: from [192.168.1.71] (108-84-31-27.lightspeed.tukrga.sbcglobal.net [108.84.31.27]) by mail.messagingengine.com (Postfix) with ESMTPA id C1AD97E3E1 for ; Sun, 7 Jan 2018 17:57:37 -0500 (EST) References: <1510734636.1704307.1173072248.27572238@webmail.messagingengine.com> <1515028094.3135331.1223576440.053F86DC@webmail.messagingengine.com> <01QNFXVO7LVS000051@mauve.mrochek.com> <01QNK22FBJC0000051@mauve.mrochek.com> From: Stan Kalisch Content-Type: text/plain; charset=utf-8 X-Mailer: iPhone Mail (13G36) In-Reply-To: <01QNK22FBJC0000051@mauve.mrochek.com> Message-Id: Date: Sun, 7 Jan 2018 17:57:34 -0500 To: extra@ietf.org Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Archived-At: Subject: Re: [Extra] Sieve REJECT and :fcc [was Re: Meeting minutes and notes from today] X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 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, 07 Jan 2018 22:57:41 -0000 On Jan 7, 2018, at 8:42 AM, Ned Freed wrote: >>> Making service-level copies of messages is >>> one thing, giving users a direct way to conveniently say "I didn't get t= his >>> message" when they actually did is quite another. >=20 >> Perhaps, but, after all, reject already provides that facility. But that= 's not the central point of my argument in favor of allowing reject to invok= e :fcc. >=20 >> Some users have arguably (at least, certainly morally) legitimate reasons= to >> lie about the delivery of mail. The users who first come to my mind are >> survivors of domestic violence and/or sexual assault. >=20 > I object even more strongly to this justification for adding such a featur= e. >=20 > There are at least two problems here: We haven't even attempted to work th= rough > all the security implications of trying to hide delivery of email. (Reject= ion > after delivery is another matter entirely, but we're not talking about tha= t > here.) Actually, I'm talking about both. Users can in fact lie about the reason a message triggers, say, a MDN. > There are all sorts of ways information can leak and getting this wrong in= > matters of life and death is completely unacceptable. I am not denying this and couldn't agree more. > (You might start by > thinking about the handling of multi-recipient cases and how you intend to= > maintain the privacy of bcc recipients while maintaining a consistent > appearance of the DSNs you send back versus the ones you provide via :fcc.= ) >=20 > Additionally, even if we do all the work to specify this properly, do you t= hink > implementors will get it right? Past experiences says the chances of that a= re > essentially nil. My reaction to that is that implementors getting a spec right is *always* a c= oncern of mine. With regard to the issue of DSNs, I'll concede I'm not aware of what all Sie= ve implementations do and was somewhat surprised by the text about them in R= FC 5429. (This isn't a criticism; I know that people sometimes do experimen= ts that specs have to attempt to address.) I do know if I were to write an i= mplementation that integrated DSNs, I would tiptoe toward it for many of the= same reasons you describe. Given that Sieve was designed to act on messages upon delivery, if enough im= plementors here in the WG aren't interested in the idea of even pursuing any= thing linking Sieve to DSNs, then it's not of the greatest concern to me if t= he MDN for :fcc on reject is made mandatory. > And a badly implemented system of this sort could cause > exactly the harm it was trying to prevent. Of course. > More generally, the business of mail interception for legal/law enforcment= > purposes should not be delegated to - let's face it - an obscure feature o= n an > obscure extension. > It's too important for that, and too important to get right. >=20 >> Google surely had in >> mind stalking and harassment when it provided Google Voice a mechanism to= lie >> about whether or not someone had placed a call to a user's valid phone nu= mber. >=20 > This would be more or less equivalent to an MSP providing the means to say= > "this is not a valid address" instead of saying "you're not allowed to se= nd to > this address". Which Sieve reject provides, modulo the ability to use a > 5.1.1 response versus a 5.7.x response code. (A feature our implementation= > provides for system-level sieves.) >=20 > However, a word of caution about side channel risks is once again in order= . > 5.1.1 no such user responses are typically given to RCPT TO; whereas Sieve= s > responses come after the message has been transferred. So it may be possi= ble > to tell when such a mechanism is used. >=20 > And let's please not entertain the notion that we can simply ignore > side-channel attacks here. > Not to put too fine a point on it, but it seems a > bunch of Intel engineers thought that way back in the 90s, and look where w= e > are now. No, I think that's apropos. >> Granted, backscatter, MDN, DSN, etc., of course, aren't even peripheral >> considerations in rolling out something like that for phone calls. But, a= gain, >> we're only talking about :fcc; reject's ship has already sailed. >=20 > I have no idea what this means. Again, it's about the fact that reject can accommodate the ability to be use= d with fileinto, etc, and that reject essentially carries a minimal ability t= o lie about why a message's disposition has ended up the way it has. >> I acknowledge your point that "delivery failed" is conspicuous by virtue o= f the fact that it is missing from RFC 8098. And I can't say that this give= s me no pause of any kind. But it still seems to me, when you look at both t= he technical and very real human considerations, that this effort is more tr= ouble than it's worth=E2=80=94I'm having a hard time believing adding :fcc t= o reject is substantially going to increase reject's (mis)use. So this stri= kes me as something that, in effect, merely serves as a lecture to users who= may lie, but 1) are not necessarily sanguine or happy about lying, and 2) m= ay actually have the need to lie. That is a scenario that is not implausibl= e at all. It is a privacy issue. I don't want to *encourage* users to lie,= but, on the other hand, I don't think the technical arguments are strong en= ough for the IETF to dictate that a language does or does not deal with such= problems. That should really be entrusted to users and administrators. So= me things, in the end, have to be entru >> to the community. >=20 > And again, I have no objection whatsoever to reject :fcc generating a "del= eted" > MDN response. But once again you have the side channel situation to consid= er - > reject :fcc causing a different response than reject without :fcc also > leaks information. I haven't looked at Cyrus code in a while, but, presumably, the implementors= behind this draft have considered such things. Thanks, Stan From nobody Sun Jan 7 15:30:42 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 B4EA6124B17 for ; Sun, 7 Jan 2018 15:30:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mailforce.net header.b=i/W4aIa4; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=OF+5MEW6 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vj2QG3B3kMvR for ; Sun, 7 Jan 2018 15:30:39 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8268D126DC2 for ; Sun, 7 Jan 2018 15:30:39 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id E5FBB20B16 for ; Sun, 7 Jan 2018 18:30:38 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Sun, 07 Jan 2018 18:30:38 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailforce.net; 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=fm2; bh=m8Ek0/nf1C11Rjrioa1DnWBl0+KcX QlplGcp2jO8IvY=; b=i/W4aIa4J8HW6c271Q7neLXM4JNeYB4FJ0XBdnmwdun58 J6pXIiBEn8w5QJL+Flb3IwTYSVuag5GwqIKA74aXkQ+QzQAOzVZf0+UKTg12ZO7d ELy1gOGJXCootwyJUESwd3/xvbGTErsUSVbXkj1jk/v2F46ICUvJ5Sj5Oarf9exA ak5fZj6Y0BaIa7iV7l/vg6upT3C+PXcW6qznis7y8U+3eKaLpEqphGq+1HCD6mgS cX+8Q2wk1uyD75F1JKXDobzXpBTN1dtv2SS8Wjl7Et4ADR3iBKxkQtLysHsJh4DI 72s49PslzVHdzU/WuxLRSp9WgQ1tRonOPTwJ+ILpA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=m8Ek0/ nf1C11Rjrioa1DnWBl0+KcXQlplGcp2jO8IvY=; b=OF+5MEW6VZiCefearmX+hs 8JU7ZVZla5WG3i/VdaRxWstmxkNTB0eyw7u9q8HB5+aTYZqI5TKk6LsPAmiejAsb 0trNkn6eKL5kjVeJYa+Y6ME112oXdcd3rq2mSc0RFQtj2ydqAoadPUcwtbOyuxpv 0m2zNJpZ5Brp7+uuX5gARyP/FkyFREhDsuQw0wnubPo9A7qNqPXlWISquE6KSMeM rT1Y9oll1s6B4EQ7yiZYHi+sZ7LDRwjBLwcrlUFSDwr2eDftqEzOBjPSb0cAvZz/ 1Xgytd4n3UHo/VZeGumX0yR6d3p5XY+WKJAQfHvWx2v0KXGCy6jR8XMGd1G4KZDA == X-ME-Sender: Received: from [192.168.1.71] (108-84-31-27.lightspeed.tukrga.sbcglobal.net [108.84.31.27]) by mail.messagingengine.com (Postfix) with ESMTPA id 8A12B7E430 for ; Sun, 7 Jan 2018 18:30:38 -0500 (EST) References: <1510734636.1704307.1173072248.27572238@webmail.messagingengine.com> <1515028094.3135331.1223576440.053F86DC@webmail.messagingengine.com> <01QNFXVO7LVS000051@mauve.mrochek.com> <4ae4f1d5-bf40-483a-ae88-befe01d3adef@gulbrandsen.priv.no> <7C65B98D-6755-4957-A181-CBA08354D11B@glyphein.mailforce.net> <1515109224.681625.1224717176.520E1500@webmail.messagingengine.com> <01QNK0MRGMKC000052@mauve.mrochek.com> <01QNKHFPA38A000051@mauve.mrochek.com> From: Stan Kalisch Content-Type: text/plain; charset=utf-8 X-Mailer: iPhone Mail (13G36) In-Reply-To: <01QNKHFPA38A000051@mauve.mrochek.com> Message-Id: <252F7193-FFAD-4F5D-967F-708D79AA2661@glyphein.mailforce.net> Date: Sun, 7 Jan 2018 18:30:37 -0500 To: extra@ietf.org Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Archived-At: Subject: Re: [Extra] Sieve REJECT and :fcc [was Re: Meeting minutes and notes from today] X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 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, 07 Jan 2018 23:30:42 -0000 On Jan 7, 2018, at 4:21 PM, Ned Freed wrote: >> On Jan 7, 2018, at 8:39 AM, Ned Freed wrote: >=20 >>>> Is everybody OK with having fcc not include reject, and having a >>>> separate capability (fcc-reject or similar) which administrators can >>>> decide whether or not to allow - and indeed, software implementations >>>> the choice whether or not to implement. >>>=20 >>> Not without the added condition that a MDN MUST be used if :fcc is prese= nt. >=20 >> Again, RFC 5429 explicitly mentions messages that have been rejected and >> then archived. >=20 > You're referring to this paragraph: Yes. > However, there are existing laws requiring certain organizations to > archive all received messages, even the rejected ones. Also, it can > be quite useful to save copies of rejected messages for later > analysis. >=20 > This is in reference to legal intercept, compliance archiving, and similar= > mechanisms. This has nothing whatsoever to do with giving random users > the means to falsely claim that a message wasn't delivered when in fact > it was. "Random users" can do things like archive messages for their own legal couns= el (something I've done, actually) or law enforcement while not wanting to r= ead the messages, themselves. >> It does not require MDNs for them. >=20 > Of course it doesn't. In many cases legal intercept requirements call for > the interception to be done invisibly. I only made these comments in response to your assertions that random users f= ind it convenient to get the system to lie. Etc. The technical argument is different entirely. Again, if the argument is the appetite isn't there for further development, t= hen I'm in agreement with your stipulation about the use of MDNs. Which bas= ically applies to the rest of my comments below. Most of this discussion ha= s unfortunately been the two of us talking past one another; I think we're b= asically in agreement. >> In fact, the section where it discusses archiving rejected messages refer= s >> to both MDNs and DSNs. How does using :fcc/:fcc-reject meaningfully >> semantically differ from just chaining fileinto and reject? >=20 > See above. One is a tool for users to keep track of the messages sent on t= heir > behalf by sending them a copy of those messages; the other is a tool for > organizations and law enforcement intended to monitor some subset of the > traffic the site receives. Again, a user can retain a subset of communications for, say, legal counsel.= > Semantically they aren't even close. >=20 > I'll also note that the requirements of legal intercept are in general > not met by keeping copies of MDNs and DSNs for rejected messages; in many > if not most cases those MDNs and DSNs do not contain the entire message an= d > even when they do the message may not be in its original form. >=20 >> The only additional thing you retain is the outgoing rejection message; t= he >> original message that was rejected is still (per the requirements of the s= pec) >> the same. >=20 > The same as what the sieve agent received. Which can be and often is marke= dly > dissimilar to what came in over the wire. Legal intercept tends to favor > collection of the latter, and may require it. >=20 >>>> That fixes both issues - those who really want the ability to lie can d= o >>>> so, but it's clear that they're enabling that facility, and it's also >>>> possible for both software vendors and administrators to not provide th= e >>>> facility in the first place. >>>=20 >>> My issue is that we have no business messing with the meaning of a 5YZ >>> code in response to a message transder. >=20 >> I think it's a bit hasty to say "messing". After all, 5YZ codes were ada= pted >> over the years for spam I should have said "the purposes for which 5YZ codes have been used." I think we basically agree about careless implementations and security impli= cations. I don't think we agree on the purposes users have, but that's neit= her here nor there at this point. I certainly have no disagreement about yo= ur comments about side-channel attacks=E2=80=94I don't think those points ca= n be overstated. Thanks, Stan > Actually, no. AFAIK the only time RFC 5321 has been updated to add a 5YZ > code is by RFC 7504, which adds 521 and 556: >=20 > 521 Host does not accept mail > 556 Domain does not accept mail >=20 > Neither of these have anything to do with handling spam. >=20 >> No one is suggesting to overtly add "stalking" or >> something like that to the IANA registry. But why throw the baby out wit= h the >> bathwater and close the door to a possible future algorithm or procedure t= hat >> carefully attempts to address at least a subset of these things? >=20 > I have no idea what this is in reference to. I'm only talking about the > handling of reject :fcc here. >=20 > Ned >=20 > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra From nobody Sun Jan 7 16:05:41 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 29647120727 for ; Sun, 7 Jan 2018 16:05:40 -0800 (PST) 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=Eb5DHJjy; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Znh1R7AV Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YmI14jRgagkH for ; Sun, 7 Jan 2018 16:05:38 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F35B120227 for ; Sun, 7 Jan 2018 16:05:38 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 0F5EB20BBE for ; Sun, 7 Jan 2018 19:05:37 -0500 (EST) Received: from web2 ([10.202.2.212]) by compute6.internal (MEProxy); Sun, 07 Jan 2018 19:05:37 -0500 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=fm1; bh=FF2Q070Lf/9N4pFOg rP4lhWjK5B6qh9SIgK/0iWIsLo=; b=Eb5DHJjyYUYOts/AIQnn/zfEBdJxvJrcu i8V5mStbpFeIugVqB0xlIIACFxYER9SFt16uc42n959wt5qWM5DbWFg/wQkwqm2s qi1FkgOXmzTIBUs5SsNwRkNjLoNL2lA2pZuzP92125uQ7Op4DDFu8fvkU5Fix1GE X2/21QrmrTdE5Qg/aDQFUJUgSLtwLYbXY1M5t3I+AbN0UkIKd+Lk55Y73mztc1rw RO3M3zyPbLWRESDr6lIAWXx/77W53vFCOsA8C4chgk5n0UVr3HoDIB7Mp+fEbUgR OIMB8QT/DuQHAy+IjXJpTk+EJgcP5gdsqyiPQ8gcEq/RdVJNBfemw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=FF2Q07 0Lf/9N4pFOgrP4lhWjK5B6qh9SIgK/0iWIsLo=; b=Znh1R7AVhEXUVBjY2/xgNL BQWV87kfM4FytdBzxFJIQhALQ6XQBWIhiAvfxO1EMDvhVdUA858OK1H/8Cxr2tnj HBIkStymnCe10ITY0PFSj269k60C1qRQyhN2iPvcxZOZ0vl3CRxJxqJ1+GJUyeqI v/nS2ebWQ6JHbi03IhQC1DJzojBPiZ+JBo8/vEZ0a2J5nvIpnhyC22wP+fZH3aK8 ekjXADfP6FPCRuNjSamJ8XAp1oDLXo/wkreIVpsoAxLiEL7dl9UVKlm3Egxj3NEF mybv+McsOtjbJvJ4ock66WbJXQNxU8o59eGZdPUP5W6aBvwCkKOwFtc8AjXx99fA == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id DB64262B9E; Sun, 7 Jan 2018 19:05:36 -0500 (EST) Message-Id: <1515369936.2716353.1227337920.5333B762@webmail.messagingengine.com> From: Bron Gondwana To: extra@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_151536993627163532" X-Mailer: MessagingEngine.com Webmail Interface - ajax-1d83f2c7 Date: Mon, 08 Jan 2018 11:05:36 +1100 In-Reply-To: <01QNK51YQ2JI000051@mauve.mrochek.com> References: <1510734636.1704307.1173072248.27572238@webmail.messagingengine.com> <1515028094.3135331.1223576440.053F86DC@webmail.messagingengine.com> <01QNFXVO7LVS000051@mauve.mrochek.com> <2d0523cb-5b0b-4cd0-8fd5-301ccbbc4342@gulbrandsen.priv.no> <01QNG1OISUGO000051@mauve.mrochek.com> <01QNK51YQ2JI000051@mauve.mrochek.com> Archived-At: Subject: Re: [Extra] Meeting minutes and notes from today X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 08 Jan 2018 00:05:40 -0000 This is a multi-part message in MIME format. --_----------=_151536993627163532 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Mon, 8 Jan 2018, at 02:33, Ned Freed wrote: >> Right. I feel that the main disconnect here is that the reject/fcc >> combination may cause one party (the site/company/...) to make >> a false>> representation about delivery on the instructions of another (the >> addressee). > > That's part of it, but not the entire story. The main issue is > undoubtedly> the ability of a user to get the site as a whole to lie about > whether or> mail was delivered to them. > > But consider the case of system-level use of reject :fcc. This is also> problematic. For one thing, if this results in a 5YZ response in > the SMTP> diaglogue, the :fcc copy is going to differ from the DSN that's > sent to the> originator (assuming a DSN is even sent - what about SUBMIT?). So > what you> have here is a different form of lying: The administrator (or however> owns the system-level sieve) gets a wholly synthetic DSN that may > differ substantially from what the remote system actually sent. > > I suppose you could address this issue by making the action of :fcc > conditional> on whether or not a DSN/MDN, on the theory that the point of :fcc is > to capture> the DSN/MDN, not the underlying message. > > I also note in passing that it's not a reliable means of capturing the> underlying message, since the DSN/MDN may not include the whole > thing. So it's> actually kind of a worst case: You can't be sure that the message is > there, but> you also can't assume it isn't. > >> When those two are the same, this is okayish. Lying on my >> own accord is not pretty, but it is better than lying because someone>> else told me to. > >> The right answer may be that reject/fcc should be >> available only when the mta owner and the script owner are the >> same. Or>> that may be unwarranted complexity, and the right answer is to >> cater to>> one of the two cases and knowingly disregard the other. > > I don't think this addresses all the issues. What does appear to me to > do so is> to require the use of an MDN for user-level reject :fcc. As for > system-level,> I'll again point out that we lack the necessary context for > discussing this in> our documents, but if we were to do so I'd say :fcc on a system- > level sieve> only provides a copy of the DSN if the system produced one. > > Ned That seems fine to me. I think there's some confusion about the point of FCC, and we might need some clarifying text. FCC in supposed to be a copy of the message that was sent on your behalf, so if the system didn't generate a message, there's nothing to store. Basically, I want to be able to have sieve take a copy of any message it generates, even if that message includes part of the original text of a message that wasn't accepted. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_151536993627163532 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Mon, 8 Jan 2018, at 02:33, Ned Freed wrote:
Right. I feel that the main disconnect here is that the reject/fcc
combination may cause one party (the site/company/...) to make a false
representation about delivery on the instructions of another (the
addressee).

That's part of it, but not the entire story. The main issue is undoubtedly
the ability of a user to get the site as a whole to lie about whether or
mail was delivered to them.

But consider the case of system-level use of reject :fcc. This is also
problematic. For one thing, if this results in a 5YZ response in the SMTP
diaglogue, the :fcc copy is going to differ from the DSN that's sent to the
originator (assuming a DSN is even sent - what about SUBMIT?). So what you
have here is a different form of lying: The administrator (or however
owns the system-level sieve) gets a wholly synthetic DSN that may
differ substantially from what the remote system actually sent.

I suppose you could address this issue by making the action of :fcc conditional
on whether or not a DSN/MDN, on the theory that the point of :fcc is to capture
the DSN/MDN, not the underlying message.

I also note in passing that it's not a reliable means of capturing the
underlying message, since the DSN/MDN may not include the whole thing. So it's
actually kind of a worst case: You can't be sure that the message is there, but
you also can't assume it isn't.

When those two are the same, this is okayish. Lying on my
own accord is not pretty, but it is better than lying because someone
else told me to.

The right answer may be that reject/fcc should be
available only when the mta owner and the script owner are the same. Or
that may be unwarranted complexity, and the right answer is to cater to
one of the two cases and knowingly disregard the other.

I don't think this addresses all the issues. What does appear to me to do so is
to require the use of an MDN for user-level reject :fcc. As for system-level,
I'll again point out that we lack the necessary context for discussing this in
our documents, but if we were to do so I'd say :fcc on a system-level sieve
only provides a copy of the DSN if the system produced one.

Ned

That seems fine to me.  I think there's some confusion about the point of FCC, and we might need some clarifying text.

FCC in supposed to be a copy of the message that was sent on your behalf, so if the system didn't generate a message, there's nothing to store.

Basically, I want to be able to have sieve take a copy of any message it generates, even if that message includes part of the original text of a message that wasn't accepted.

Bron.

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


--_----------=_151536993627163532-- From nobody Sun Jan 7 16:53:42 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 AEBB11242F7 for ; Sun, 7 Jan 2018 16:53:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 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, T_RP_MATCHES_RCVD=-0.01] 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 4bNZQeMUk-lL for ; Sun, 7 Jan 2018 16:53:38 -0800 (PST) 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 D1DED1200B9 for ; Sun, 7 Jan 2018 16:53:38 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QNKNXF9OMO001XAM@mauve.mrochek.com> for extra@ietf.org; Sun, 7 Jan 2018 16:48:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1515372514; bh=xDY7hRSxg//37x4ehQjnzGNyt9K6WzRzLxylwbTl40E=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=ASR7h8/7ceTzUiHGg2AQOWq1t2bYEnoEqXP6wEeBHd4hToOinLa7UzaGf1KDKwlAk vcyxnjUQvSDTEoNh2H+0KjEkc3GZ1KNpauCzildhua2JXkZT2+yDkosJWyuDCXVfsG Vu7VkZD80429YkvmzjRzE06WRfoKD+k02QMR7Vxc= 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 <01QNFVO5W1CW000051@mauve.mrochek.com>; Sun, 07 Jan 2018 16:48:32 -0800 (PST) Cc: extra@ietf.org Message-id: <01QNKNXDT7B0000051@mauve.mrochek.com> Date: Sun, 07 Jan 2018 16:15:52 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Sun, 07 Jan 2018 17:57:34 -0500" References: <1510734636.1704307.1173072248.27572238@webmail.messagingengine.com> <1515028094.3135331.1223576440.053F86DC@webmail.messagingengine.com> <01QNFXVO7LVS000051@mauve.mrochek.com> <01QNK22FBJC0000051@mauve.mrochek.com> To: Stan Kalisch Archived-At: Subject: Re: [Extra] Sieve REJECT and :fcc [was Re: Meeting minutes and notes from today] X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 08 Jan 2018 00:53:41 -0000 > On Jan 7, 2018, at 8:42 AM, Ned Freed wrote: > >>> Making service-level copies of messages is > >>> one thing, giving users a direct way to conveniently say "I didn't get this > >>> message" when they actually did is quite another. > > > >> Perhaps, but, after all, reject already provides that facility. But that's not the central point of my argument in favor of allowing reject to invoke :fcc. > > > >> Some users have arguably (at least, certainly morally) legitimate reasons to > >> lie about the delivery of mail. The users who first come to my mind are > >> survivors of domestic violence and/or sexual assault. > > > > I object even more strongly to this justification for adding such a feature. > > > > There are at least two problems here: We haven't even attempted to work through > > all the security implications of trying to hide delivery of email. (Rejection > > after delivery is another matter entirely, but we're not talking about that > > here.) > Actually, I'm talking about both. I'm not. The situation after delivery is entirely different. Once something is delivered to a user's mailbox the transport system is no longer involved. Everything about MDNs is discretionary: generation, content, everything. Users and their agents are free to say or do whatever they want. They can send a "deleted" MDN and keep the message, or send a "dispatched" MDN when in fact they simply deleted the message. > Users can in fact lie about the reason a message triggers, say, a MDN. Absolutely. This is expected to be the case. Of course senders can elect to trust a sender, but if they do this is an arrangement that lies outside the service architecture the mail system provides. The transport infrastructure is a different story. We all have to trust it, and there are enough issues with that already; we should not be adding more. > Given that Sieve was designed to act on messages upon delivery, Sorry, that's incorrect. Sieve was designed to operate at some point around the time of delivery. There are implementations that operate before, during, or after delivery. In the specific case of reject, a user agent needs to use MDNs since the time for the generation of DSNs is past. Something operating at the SMTP server level should use SMTP status codes if at all possible - and the specification goes to considerable trouble to make that possible. This is further complicated by there being two verbs (reject/ereject), which further complicates matters. > if enough > implementors here in the WG aren't interested in the idea of even pursuing > anything linking Sieve to DSNs, then it's not of the greatest concern to me if > the MDN for :fcc on reject is made mandatory. FWIW, our implementation operates at the SMTP server level and uses SMTP status codes whenever possible. > >> Granted, backscatter, MDN, DSN, etc., of course, aren't even peripheral > >> considerations in rolling out something like that for phone calls. But, again, > >> we're only talking about :fcc; reject's ship has already sailed. > > > > I have no idea what this means. > Again, it's about the fact that reject can accommodate the ability to be used > with fileinto, etc, case. First, such usage is NOT RECOMMENDED, meaning it should only be done if there's a really good reason. Second, as the RFC points out, doing this at the SMTP level is a direct violation of RFC 5321. Call me a stickler if you like, but I don't think that's a good thing. Third, it seems clear that the presence of all this text in the RFC is in a misguided attempt to try and make sieve actions like keep and fileinto somewhat compatible with legal intercept applications. Unfortunately the entire cant of Sieve is such that this is basically a fool's journey in user-space sieves, and as I have pointed out previously, system sieves are beyond the scope of what's covered in the RFCs. > and that reject essentially carries a minimal ability to > lie about why a message's disposition has ended up the way it has. This is a result of the range of places where Sieve can be applied. What's appropriate prior to delivery is different from what's appropriate after delivery. Ned From nobody Mon Jan 8 06:34: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 869A7128896 for ; Mon, 8 Jan 2018 06:34:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 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, T_RP_MATCHES_RCVD=-0.01] 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 m-WJ_NvVUbTj for ; Mon, 8 Jan 2018 06:34:12 -0800 (PST) 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 4B68F12895E for ; Mon, 8 Jan 2018 06:34:12 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QNLGQWICVK002421@mauve.mrochek.com> for extra@ietf.org; Mon, 8 Jan 2018 06:33:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1515421996; bh=14S681gS8CbkVH03vD9lfTz3ZBZFb4y/uVTevuKJ/nY=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=laSIN6d/MYozF4xMDrwquQYw5rxS4XsWzeDFDowPL+vnEyedO6fhkA6T8mR5fBeBd FqUy49XFHfcb5Sie2HJabbnVrBt7/BGQeA0ylNZ4H/9vwhcuijEU72AGf7R8onInGp cLc0niBO4AZkPYwugLKv1Q0GGl1YN6itxmZ2cwv0= 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 <01QNFVO5W1CW000051@mauve.mrochek.com>; Mon, 08 Jan 2018 06:33:14 -0800 (PST) Cc: extra@ietf.org Message-id: <01QNLGQUTCI8000051@mauve.mrochek.com> Date: Mon, 08 Jan 2018 06:05:30 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Mon, 08 Jan 2018 11:05:36 +1100" <1515369936.2716353.1227337920.5333B762@webmail.messagingengine.com> References: <1510734636.1704307.1173072248.27572238@webmail.messagingengine.com> <1515028094.3135331.1223576440.053F86DC@webmail.messagingengine.com> <01QNFXVO7LVS000051@mauve.mrochek.com> <2d0523cb-5b0b-4cd0-8fd5-301ccbbc4342@gulbrandsen.priv.no> <01QNG1OISUGO000051@mauve.mrochek.com> <01QNK51YQ2JI000051@mauve.mrochek.com> <1515369936.2716353.1227337920.5333B762@webmail.messagingengine.com> To: Bron Gondwana Archived-At: Subject: Re: [Extra] Meeting minutes and notes from today X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 08 Jan 2018 14:34:13 -0000 > That seems fine to me. I think there's some confusion about the point > of FCC, and we might need some clarifying text. I agree. > FCC in supposed to be a copy of the message that was sent on your > behalf, so if the system didn't generate a message, there's > nothing to store. Exactly. I would suggest changing the Abstract to read something like: 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 reply message to be filed into a target mailbox. And the Introduction should begin with the same sentence: The Sieve Email Filtering Language [RFC5228] provides a number of action commands, some of which can generate additional messages on behalf of the user. And conclude with: This extension defines a ":fcc" argument to action commands which generate additional messages to allow a copy of the reply message to be filed into a target mailbox. The ":fcc" argument is a no-op if the associated action command does not directly generate an additional message. The capability string associated with this extension is "fcc". > Basically, I want to be able to have sieve take a copy of any message it > generates, even if that message includes part of the original text of a > message that wasn't accepted. From nobody Mon Jan 8 14:22: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 64EBC124BFA for ; Mon, 8 Jan 2018 14:22:03 -0800 (PST) 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=Bg9GdeIx; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=cUfFw8xY Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7451uTiIaoz for ; Mon, 8 Jan 2018 14:22:01 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B38881200F1 for ; Mon, 8 Jan 2018 14:22:01 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 2961820B2D; Mon, 8 Jan 2018 17:22:01 -0500 (EST) Received: from web2 ([10.202.2.212]) by compute6.internal (MEProxy); Mon, 08 Jan 2018 17:22:01 -0500 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=fm1; bh=twAhYc jqFqEewKQHUGEos/PSqjm/Y/CzbJd+Y2botQQ=; b=Bg9GdeIxNkeGg7gaut0gZb BqrbbUfJE55xT0Z48F9CBFAAR+VUGfMGxKZf2qnw0eINlu37Hk+YVIe/5c7E1uA5 j/6N+bkeqqwFcIiXUVfAPCmk15kbFrgmuDQwxZ69jEEB4yG4yu50Wh8LBdAQTzrf 0AAjWUuO1UP2Lsx6Eh4HIOmQMYe2okDZ74iPCrIkTZ6roHVFZnEkV+gyUBwBQSk+ ekwU6z6i55wVuvfnjIAgAAexdCIVZF9moW2X6bx6iLahUKhnAh0HZIX38HnuzkvF brNrYCa6vuNhPqLOJQniolYSYxa2HT24iC83yizvvCnxGvfQdaLCExEA8bkQu8oQ == DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=twAhYc jqFqEewKQHUGEos/PSqjm/Y/CzbJd+Y2botQQ=; b=cUfFw8xYpSGNBxbcjXEivR VtqHAylvCoiRw2ZCISgoC6tbhzdze+oseAzMMFP2kGhNhBPuRrdtI2KjJzrxqran eB+tR1kKv1GtbriiQ55ixLTjcoxdMiCnFVIke/VstaVXGgPkXZbTeNQl79Sy2pay nKR8VvCvsP9qC1SLCqvnQ+Aj34vu8ul6u8uOg4K6f446k2eRbZ//tDy4IJ9I4Lvh LRxXF3+eN7SeDC64NwXrNS9lZrhnMJMwwvbB/vKXZVUJV9YlNThjcExccZpy3Hlm m6AP/JIYNHx71kIwtqlT2CgqJtOXNo/czxQdy+FqQMLLIm8N8lIkEbVkdrad2rfQ == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id E449462B9E; Mon, 8 Jan 2018 17:22:00 -0500 (EST) Message-Id: <1515450120.3634930.1228547800.1FFE489D@webmail.messagingengine.com> From: Bron Gondwana To: extra@ietf.org Cc: Murchison Ken MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_151545012036349301" X-Mailer: MessagingEngine.com Webmail Interface - ajax-6368b27c In-Reply-To: <01QNLGQUTCI8000051@mauve.mrochek.com> References: <1510734636.1704307.1173072248.27572238@webmail.messagingengine.com> <1515028094.3135331.1223576440.053F86DC@webmail.messagingengine.com> <01QNFXVO7LVS000051@mauve.mrochek.com> <2d0523cb-5b0b-4cd0-8fd5-301ccbbc4342@gulbrandsen.priv.no> <01QNG1OISUGO000051@mauve.mrochek.com> <01QNK51YQ2JI000051@mauve.mrochek.com> <1515369936.2716353.1227337920.5333B762@webmail.messagingengine.com> <01QNLGQUTCI8000051@mauve.mrochek.com> Date: Tue, 09 Jan 2018 09:22:00 +1100 Archived-At: Subject: Re: [Extra] Meeting minutes and notes from today X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 08 Jan 2018 22:22:03 -0000 This is a multi-part message in MIME format. --_----------=_151545012036349301 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Tue, 9 Jan 2018, at 01:05, Ned Freed wrote: > 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 reply message to be filed into a target mailbox. I would remove the word "reply" from that. A notify message sent to a third party isn't a reply, but I'd still want to FCC it. (e.g. FastMail used to have a notify feature that allowed you to send a squashed copy of the message as an SMS to your registered phone). Otherwise I entirely agree - that text is a lot clearer. Thanks! Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_151545012036349301 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Tue, 9 Jan 2018, at 01:05, Ned Freed wrote:
  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 reply message to be filed into a target mailbox.

I would remove the word "reply" from that.  A notify message sent to a third party isn't a reply, but I'd still want to FCC it.  (e.g. FastMail used to have a notify feature that allowed you to send a squashed copy of the message as an SMS to your registered phone).

Otherwise I entirely agree - that text is a lot clearer.  Thanks!

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


--_----------=_151545012036349301-- From nobody Mon Jan 8 15:00: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 38709126C26 for ; Mon, 8 Jan 2018 15:00:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.468 X-Spam-Level: X-Spam-Status: No, score=-0.468 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0lzV7LMNWTHA for ; Mon, 8 Jan 2018 15:00:18 -0800 (PST) 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 D708E12711B for ; Mon, 8 Jan 2018 15:00:17 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QNLYA8IYRK0025R2@mauve.mrochek.com> for extra@ietf.org; Mon, 8 Jan 2018 14:55:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1515452114; bh=LQr+iUAzJN7JZKvwMNU6RnuUPJNaMnOpLY3QY6vWz74=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=oqifos/lK1kmFR657oyWkWYnWytAhftK2EFMp4rNaNqhg2otP6Cc9myZMCP8/c8qx 99k0UtgVTKEOCkRTjqaA7e+VruPGkAidzXtmSV1GIfFHQ2egDYgAMg/sO5uCu35Vjw 6T3gL6kMDG2K7UX+3XD/wfmnBMTMJCk08C/o+lac= 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 <01QNFVO5W1CW000051@mauve.mrochek.com>; Mon, 08 Jan 2018 14:55:12 -0800 (PST) Cc: extra@ietf.org Message-id: <01QNLYA7BLVQ000051@mauve.mrochek.com> Date: Mon, 08 Jan 2018 08:50:27 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Sun, 07 Jan 2018 15:57:23 +0100" References: <151533655607.10858.793231788332492256@ietfa.amsl.com> To: Stephan Bosch 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.22 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: Mon, 08 Jan 2018 23:00:19 -0000 I have a few observations and comments on this draft. The sieve language is designed not to be specific to IMAP. However, this extension seems to specifically tied to IMAP in general and to RFC 6154 in particular. This means there's really no reason not to tighten the association - in particular, would it not make sense to provide sample IMAP command sequences to implement the various things in this specification? This would be quite helpful to implementors, who might otherwise overlook an important step. Special use is, in effect, a many-to-many mapping of special use attributes to mailboxes. That is, mailboxes can have multiple special use attributes and a given attribute can be associated with multiple mailboxes. As far as choosing the right mailbox when more than one has the specified special-use attribute, the draft says "implementations MUST ensure that this choice is made consistently, so that the same mailbox is used every time." I don't know how to implement this short of keeping a per-user list of what mailbox was used for a given special use attribute. And even a list doesn't guarantee that no least astonishment violations will occur. Consider: Suppose there's only mailbox for a given special use and I deliver to it. Then the user adds an additional special use mailbox. No simple selection criteria, e.g., first alphabetically will work in general in this case, because I can alway construct an example where the new mailbox beats the old one. Creation date doesn't work either, because you can add a special use attribute to an existing, old maibox. Mailboxes can also be deleted and recreated. You can solve these problems by keeping a list of mailboxes you've used for a given special use attribute. But this is a royal PITA, and it still doesn't address sequences like createa-delivera-createb-deletea-deliverb-deleteb-createa-deliver? The bottom line is I think this needs to be relaxed to a SHOULD. It probably should also be made clear that if a previously used mailbox no longer exists then the mailbox default from the command is used rather than recreating the old mailbox. That is, the mailbox explicitly listed in the command wins over consistency with the past. The other aspect of the many-many mapping is the fact that a single mailbox can have multiple special use attributes. The draft supports this in the context of specialuse_exists but not in the context of fileinto. I think this is fine, but I want to make sure everyone is happy with this limitation, including the fact that because of this you won't be able to create mailbox with fileinto with multiple special use attributes. Section 3 says: If the "mailbox" string argument is omitted, the "specialuse_exists" test yields true if all of the following statements are true for each of the special-use flags listed in the "special-use-flags" argument: a. at least one mailbox exists in the mail store that has that particular special-use flag assigned, and b. that mailbox allows the user in whose context the Sieve script runs to "deliver" messages into it. I'm concerned about a. - the phrase "the mail store" conjures up an image of searching through folders belonging to millions of users looking for one that has an ACL allowing the sieve owner to write to it. I'm pretty sure you don't intend this to cover shared folders, so I suggest changing the text to say something like: a. at least one mailbox exists in the user's personal namespace [NAMESPACE] that has that particular special-use flag assigned, and And add the [NAMESPACE] reference pointing at RFC 2342. 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. The specialuse_exists makes use of an optional positional parameter. I'm fine with this, but I want to make sure everyone else is, and that we don't need to switch to something like: specialuse_exists [:mailbox ] The same point about special use mailboxes being in the user's personal namespace needs to be reiterated in the fileinto discussion in section 4. The text and examples showing the interaction of :specialuse with :create seem to assume that mailboxes won't be created without :create. This assumption is incorrect; the sieve base specification is quite clear that an implementation MAY create the specified mailbox if it doesn't exist even if :create isn't specified. (Our implementation is one that always creates missing mailboxes specified in fileinto; :create is therefore a no-op.) I think an implementation that creates by default SHOULD also assign the special use attribute by default if it able to do so. This should be covered in the text. A reference to the text about fileinto in RFC 5228 is probably in order here. The first example should probably be changed to note that what happens in the event there's no mailbox with the \Junk attribute and a mailbox named "Spam" doesn't exist is implementation-dependent. The second example should be tweaked a bit to make it clear that the effect of :create is to make the creation of the mailbox unconditional. That's it for now. Ned From nobody Mon Jan 8 15:00: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 424EF126C26 for ; Mon, 8 Jan 2018 15:00:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 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, T_RP_MATCHES_RCVD=-0.01] 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 NvkaVtFXPGip for ; Mon, 8 Jan 2018 15:00:18 -0800 (PST) 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 386891271FD for ; Mon, 8 Jan 2018 15:00:18 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QNLYBP7N7K0023L8@mauve.mrochek.com> for extra@ietf.org; Mon, 8 Jan 2018 14:56:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1515452185; bh=JHZCFj8nwPGyNdSIaaquochUjrMpjkG23QnR2FTmJC0=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=pMkW26h5zO2eDK5PmLsaLsbi57w3d1Rp7pGiwfqnyiRgD8/ASkuXYIxm4FQn+SQ8a Q9JwlIuLVV+De95LvDNq9b9qutL+37d3pXd9xFcjwywY4rihxv4mxf2QDrP29yOvLh VxIWKpshOTB0PrZqklQK/Ml5I7umLg4j7HyGZHG0= 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 <01QNFVO5W1CW000051@mauve.mrochek.com>; Mon, 08 Jan 2018 14:56:23 -0800 (PST) Cc: extra@ietf.org, Murchison Ken Message-id: <01QNLYBNTQ6U000051@mauve.mrochek.com> Date: Mon, 08 Jan 2018 14:55:55 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Tue, 09 Jan 2018 09:22:00 +1100" <1515450120.3634930.1228547800.1FFE489D@webmail.messagingengine.com> References: <1510734636.1704307.1173072248.27572238@webmail.messagingengine.com> <1515028094.3135331.1223576440.053F86DC@webmail.messagingengine.com> <01QNFXVO7LVS000051@mauve.mrochek.com> <2d0523cb-5b0b-4cd0-8fd5-301ccbbc4342@gulbrandsen.priv.no> <01QNG1OISUGO000051@mauve.mrochek.com> <01QNK51YQ2JI000051@mauve.mrochek.com> <1515369936.2716353.1227337920.5333B762@webmail.messagingengine.com> <01QNLGQUTCI8000051@mauve.mrochek.com> <1515450120.3634930.1228547800.1FFE489D@webmail.messagingengine.com> To: Bron Gondwana Archived-At: Subject: Re: [Extra] Meeting minutes and notes from today X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 08 Jan 2018 23:00:20 -0000 > On Tue, 9 Jan 2018, at 01:05, Ned Freed wrote: > > 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 reply message to be filed into a target mailbox. > I would remove the word "reply" from that. A notify message sent to a > third party isn't a reply, but I'd still want to FCC it. (e.g. FastMail > used to have a notify feature that allowed you to send a squashed copy > of the message as an SMS to your registered phone). > Otherwise I entirely agree - that text is a lot clearer. Thanks! Crap, I thought I have removed it. My bad. Ned From nobody Tue Jan 9 11:35: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 45DDB126E01 for ; Tue, 9 Jan 2018 11:35:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 DU7AFAkISiL1 for ; Tue, 9 Jan 2018 11:35:19 -0800 (PST) Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC9F120721 for ; Tue, 9 Jan 2018 11:35:19 -0800 (PST) Received: from [10.168.3.2] (klara.student.utwente.nl [130.89.162.218]) by mail.dovecot.fi (Postfix) with ESMTPSA id 72B922AEF53; Tue, 9 Jan 2018 21:35:17 +0200 (EET) To: Ned Freed Cc: extra@ietf.org References: <151533655607.10858.793231788332492256@ietfa.amsl.com> <01QNLYA7BLVQ000051@mauve.mrochek.com> From: Stephan Bosch Message-ID: Date: Tue, 9 Jan 2018 20:35:13 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <01QNLYA7BLVQ000051@mauve.mrochek.com> Content-Type: text/plain; charset=utf-8 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.22 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, 09 Jan 2018 19:35:21 -0000 Hi Ned, Thanks for the review! Op 1/8/2018 om 5:50 PM schreef Ned Freed: > I have a few observations and comments on this draft. > > The sieve language is designed not to be specific to IMAP. However, this > extension seems to specifically tied to IMAP in general and to RFC 6154 > in particular. This means there's really no reason not to tighten the > association - in particular, would it not make sense to provide sample > IMAP command sequences to implement the various things in this specification? > > This would be quite helpful to implementors, who might otherwise overlook an > important step. Hmm, I am not exactly sure what you mean here. Can you give an example?  At our end, there is no intermission of IMAP for executing Sieve rules; both just use the same APIs to operate: i.e., one is not layered above the other. Also, IMAP command sequences can only show the actions that are performed, not the decisions that lead to those actions. > Special use is, in effect, a many-to-many mapping of special use attributes to > mailboxes. That is, mailboxes can have multiple special use attributes and a > given attribute can be associated with multiple mailboxes. > > As far as choosing the right mailbox when more than one has the specified > special-use attribute, the draft says "implementations MUST ensure that this > choice is made consistently, so that the same mailbox is used every time." > > I don't know how to implement this short of keeping a per-user list of what > mailbox was used for a given special use attribute. And even a list doesn't > guarantee that no least astonishment violations will occur. > > Consider: Suppose there's only mailbox for a given special use and I deliver to > it. Then the user adds an additional special use mailbox. No simple selection > criteria, e.g., first alphabetically will work in general in this case, because > I can alway construct an example where the new mailbox beats the old one. > > Creation date doesn't work either, because you can add a special use attribute > to an existing, old maibox. Mailboxes can also be deleted and recreated. > > You can solve these problems by keeping a list of mailboxes you've used for a > given special use attribute. But this is a royal PITA, and it still doesn't > address sequences like > createa-delivera-createb-deletea-deliverb-deleteb-createa-deliver? > > The bottom line is I think this needs to be relaxed to a SHOULD. It probably > should also be made clear that if a previously used mailbox no longer exists > then the mailbox default from the command is used rather than recreating the > old mailbox. That is, the mailbox explicitly listed in the command wins over > consistency with the past. I see what you mean. What about relaxing this statement so that consistency is required only for as long as the set of mailboxes with the specified special-use flag remains unchanged? Adding/removing mailboxes is then allowed to change the effective mailbox of the fileinto :specialuse action. The actual choice of the effective mailbox after each change is still left to the implementation. Summarizing, consistency is then only guaranteed while the user doesn't mess with the assignments of the involved special-use flag. > The other aspect of the many-many mapping is the fact that a single mailbox can > have multiple special use attributes. The draft supports this in the context of > specialuse_exists but not in the context of fileinto. I think this is fine, but > I want to make sure everyone is happy with this limitation, including the fact > that because of this you won't be able to create mailbox with fileinto with > multiple special use attributes. Good point. For sake of discussion, let's assume we allow a string list for the :specialuse parameter. The semantics for creation of a mailbox would be quite clear: all of those flags are assigned to the new mailbox. But what would that mean for the mailbox lookup? Are we looking for a mailbox that has all of these flags, one of these flags or just the first flag listed? Another question is whether mailboxes with several special-use flags are really that useful. > Section 3 says: > > If the "mailbox" string argument is omitted, the "specialuse_exists" > test yields true if all of the following statements are true for each > of the special-use flags listed in the "special-use-flags" argument: > > a. at least one mailbox exists in the mail store that has that > particular special-use flag assigned, and > > b. that mailbox allows the user in whose context the Sieve script > runs to "deliver" messages into it. > > I'm concerned about a. - the phrase "the mail store" conjures up an image > of searching through folders belonging to millions of users looking for > one that has an ACL allowing the sieve owner to write to it. > > I'm pretty sure you don't intend this to cover shared folders, so I suggest > changing the text to say something like: > > a. at least one mailbox exists in the user's personal namespace > [NAMESPACE] that has that particular special-use flag assigned, and > > And add the [NAMESPACE] reference pointing at RFC 2342. I must say I didn't consider any special problems with shared mailboxes. The scenario you describe is that lots of people are sharing some of their mailboxes with pretty much everyone. In that case, indeed, it could be a lengthy lookup. I guess the impact is implementation/deployment-dependent. I think we should warn about situations like this, but not restrict access to the personal namespace(s) in the specification. Also, couldn't an account have more than one private namespace? For example, there could be a main namespace containing the INBOX and another namespace on a different slow storage that contains archived messages. > 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. Sorry, I don't understand what you mean. > The specialuse_exists makes use of an optional positional parameter. I'm > fine with this, but I want to make sure everyone else is, and that we don't > need to switch to something like: > > specialuse_exists [:mailbox ] > Well, this would not be the first extension doing that. E.g., the imap4flags extension has similar optional positional arguments. Still, I have no objection to the syntax you propose. Anybody else have a preference? > The text and examples showing the interaction of :specialuse with :create seem > to assume that mailboxes won't be created without :create. This assumption is > incorrect; the sieve base specification is quite clear that an implementation > MAY create the specified mailbox if it doesn't exist even if :create isn't > specified. (Our implementation is one that always creates missing mailboxes > specified in fileinto; :create is therefore a no-op.) > > I think an implementation that creates by default SHOULD also assign the > special use attribute by default if it able to do so. This should be covered in > the text. A reference to the text about fileinto in RFC 5228 is probably in > order here. Good point. > The first example should probably be changed to note that what happens in the > event there's no mailbox with the \Junk attribute and a mailbox named "Spam" > doesn't exist is implementation-dependent. > > The second example should be tweaked a bit to make it clear that the effect of > :create is to make the creation of the mailbox unconditional. Yeah. Regards, Stephan. -- Stephan Bosch Senior Developer Phone: +49 2761 75252 00 Fax: +49 2761 75252 30 Email: stephan.bosch@dovecot.fi ------------------------------------------------------------------------------------- Open-Xchange AG, Rollnerstr. 14, 90408 Nuremberg, District Court Nuremberg HRB 24738 Managing Board: Rafael Laguna de la Vera, Carsten Dirks, Michael Knapstein Chairman of the Board: Richard Seibt Dovecot Oy, Lars Sonckin Kaari 10, 02600 Espoo, Finland Managing Director: Markku Kentta Chairman of the Board: Timo Sirainen Board Member: Carsten Dirks ------------------------------------------------------------------------------------- From nobody Tue Jan 9 11:37: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 7ECBB120725 for ; Tue, 9 Jan 2018 11:37:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 w6CHL0In9IO5 for ; Tue, 9 Jan 2018 11:37:32 -0800 (PST) Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id 5B704126E01 for ; Tue, 9 Jan 2018 11:37:32 -0800 (PST) Received: from [10.168.3.2] (klara.student.utwente.nl [130.89.162.218]) by mail.dovecot.fi (Postfix) with ESMTPSA id 7CCE42AEF53; Tue, 9 Jan 2018 21:37:31 +0200 (EET) To: Bron Gondwana , extra@ietf.org References: <1515027295.3130822.1223568456.6D1D8F15@webmail.messagingengine.com> <1515362666.2687647.1227253816.726EA133@webmail.messagingengine.com> From: Stephan Bosch Message-ID: <84ae8816-7654-707a-d0f7-24d1ae1e7e12@dovecot.fi> Date: Tue, 9 Jan 2018 20:37:28 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <1515362666.2687647.1227253816.726EA133@webmail.messagingengine.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Extra] SAVEDATE updated required X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 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, 09 Jan 2018 19:37:34 -0000 Hi Bron, I need to think about this a little more. I will reply this one a bit later. Regards, Stephan. Op 1/7/2018 om 11:04 PM schreef Bron Gondwana: > On Mon, 8 Jan 2018, at 00:04, Stephan Bosch wrote: >> Hi Bron, >> >> Op 1/4/2018 om 1:54 AM schreef Bron Gondwana: >> >> 2: if the mailbox doesn't support storing save date, the SEARCH >> extensions should return an error if used, rather than a result, >> since >> there's no way to calculate a sensible answer to any of those three. >> >> >>    SAVEDBEFORE >>       Messages whose save date (disregarding time and timezone) is >>       earlier than the specified date. >> >>    SAVEDON >>       Messages whose save date (disregarding time and timezone) is >>       within the specified date. >> >>    SAVEDSINCE >>       Messages whose save date (disregarding time and timezone) is >>       within or later than the specified date. >> >> >> Ok, for the sake of discussion, I added text with this effect in the >> last version. However, I am not quite happy with it yet. Returning an >> error seems a bit harsh. Do we need to provide some means for the client >> to find out whether the mailbox supports the save date attribute before >> trying to use it? > > That could be done: > > TAG select "foo" > * 1 EXISTS > * 1 RECENT > * FLAGS (\Answered \Flagged \Draft \Deleted \Seen) > * OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Seen \*)] Ok > * OK [UNSEEN 1] Ok > * OK [UIDVALIDITY 1515362059] Ok > * OK [UIDNEXT 2] Ok > * OK [HIGHESTMODSEQ 7] Ok > * OK [URLMECH INTERNAL] Ok > * OK [ANNOTATIONS 65536] Ok > TAG OK [READ-WRITE] Completed > > Another line in there that said something like: > > * OK [SAVEDATE] Ok > > Would probably work fine. > >> Also, there's the MULTISEARCH extension (RFC7377), which adds an ESEARCH >> command that allows searching across a wide selection of mailboxes, some >> of which may in fact lack support for the save date attribute. What is >> to be done in that case? Fail the whole ESEARCH command? Ignore the >> mailboxes that lack support? Make the SAVED* search items yield a false >> result for that mailbox? None of these options seem very appealing. > > There are three choices: > 1) reject the command if any folder doesn't support SAVEDATE > 2) reject the command if none of the folders support SAVEDATE > 3) succeed regardless of the support for SAVEDATE > > And if there are folders that don't support SAVEDATE for case 2 or 3, > you can: > a) use the INTERNALDATE instead > b) don't match the message > > I think (a) is clearly wrong here - if you're deleting everything > that's SAVEDBEFORE 1 month ago from a Trash folder, then INTERNALDATE > will purge things before you want to. > > The alternative is to treat SAVEDATE as NULL in the same way SQL does, > and I think that's the right choice.  So you can say "SEARCH NOT > SAVEDAFTER {X} BEFORE {X}" if you want to get the behaviour of > deleting everything that was SAVEDBEFORE a time, or fallback to > INTERNALDATE if it's not supported. > >> 3: Do we need to define SAVEDATE as a SORT key extending RFC5256 as >> well?  In theory it should always sort the same as UID. >> >> >> I don't think this is particularly useful, although it is not difficult >> to add. I agree that sorting is normally equal to seq/UID. I checked: >> Dovecot does not currently implement a sort key for this. > > I'm fine with not having it. > > By the way, I have plans for a JMAP extension which maps SAVEDATE into > JMAP.  Have been chatting with Neil about it.  It seems a good first > case for an example extension :) > > Bron. > > -- >   Bron Gondwana, CEO, FastMail Pty Ltd >   brong@fastmailteam.com > > > > > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra -- Stephan Bosch Senior Developer Phone: +49 2761 75252 00 Fax: +49 2761 75252 30 Email: stephan.bosch@dovecot.fi ------------------------------------------------------------------------------------- Open-Xchange AG, Rollnerstr. 14, 90408 Nuremberg, District Court Nuremberg HRB 24738 Managing Board: Rafael Laguna de la Vera, Carsten Dirks, Michael Knapstein Chairman of the Board: Richard Seibt Dovecot Oy, Lars Sonckin Kaari 10, 02600 Espoo, Finland Managing Director: Markku Kentta Chairman of the Board: Timo Sirainen Board Member: Carsten Dirks ------------------------------------------------------------------------------------- From nobody Tue Jan 9 14:07:37 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 817C012D574 for ; Tue, 9 Jan 2018 14:07:35 -0800 (PST) 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=i8ij93w+; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=pk9MSgmm Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2bHVOablMpyA for ; Tue, 9 Jan 2018 14:07:33 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A8DC12773A for ; Tue, 9 Jan 2018 14:07:33 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 7B63120DBC; Tue, 9 Jan 2018 17:07:32 -0500 (EST) Received: from web2 ([10.202.2.212]) by compute6.internal (MEProxy); Tue, 09 Jan 2018 17:07:32 -0500 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=fm1; bh=Z0KeMnVNlenT18KmG TElb4KDR4U/+w3PAZukcKU5mgg=; b=i8ij93w+ZIwx/pzQvHZRsumr8kuROipcn WBmzNafkJ7Xr//ur0koWg2V3f+O5sYrkk8EM54dc2fcWsY8gA9jR36bJlP6viXTv P0RbksVeslMQDMEe20z5TtVWFX6g+2i6p6FSSt8Xsnxbk5BG5epUuZjBkz1zaEf3 piMQ9h+WDBShyFkL81ejOjUuVOHtycCQ/lTbkZvzkrY4csXkvy3XTELM/ZCx7x3c KgPoAHLKm6JKbo5h2ae+tQEtuvV5ysKAPA+2f9yrOzwBfy62BtH7VDBUz3p6KN5B VA/O/BoElUEIniS5AcRbp4Ul0QB1rW2ekYE9OcQiH8o7nKKgRbcjw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=Z0KeMn VNlenT18KmGTElb4KDR4U/+w3PAZukcKU5mgg=; b=pk9MSgmmNQoVh9BlJWjwvo 71WrY7FsxL3ckIncaOhJyNax9dw5ofb1WxDjnP20JdBG77gr+UpgT5KaYvyHgMoB +Rftuc3nPYPBsi21KW4pShApZzPHqXTtVf7q+nUM0mS6Y0PVOC9rxoMhWIFDY3RC r67XeSz7wyg8nwJDvBgBCvfZ0jNrSSTZqFFF81uetoB8xV+RqgdEskZkm4GNqmVh SLtjG5gnZ4+fPxpl/IpBlSrsKlPbjdemxzQK3E2DCw8shE9GQ/YPFbYjyo02ystS 85Wr4iKxCtBygruVEDgDtvtQC00l/FGyGA4Ir4+4zq+98QKc5oeU/cQRuGkJHFLA == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 4E45462B8D; Tue, 9 Jan 2018 17:07:32 -0500 (EST) Message-Id: <1515535652.2227838.1229863408.73E33F10@webmail.messagingengine.com> From: Bron Gondwana To: Stephan Bosch , extra@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_151553565222278380" X-Mailer: MessagingEngine.com Webmail Interface - ajax-6368b27c Date: Wed, 10 Jan 2018 09:07:32 +1100 References: <1515027295.3130822.1223568456.6D1D8F15@webmail.messagingengine.com> <1515362666.2687647.1227253816.726EA133@webmail.messagingengine.com> <84ae8816-7654-707a-d0f7-24d1ae1e7e12@dovecot.fi> In-Reply-To: <84ae8816-7654-707a-d0f7-24d1ae1e7e12@dovecot.fi> Archived-At: Subject: Re: [Extra] SAVEDATE updated required X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 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, 09 Jan 2018 22:07:35 -0000 This is a multi-part message in MIME format. --_----------=_151553565222278380 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" No problem at all! I'm running a choir festival for the next 10 days, so I'm going to have very limited availability anyway :) Cheers, Bron. On Wed, 10 Jan 2018, at 06:37, Stephan Bosch wrote: > Hi Bron, > > I need to think about this a little more. I will reply this one a > bit later.> > Regards, > > Stephan. > > Op 1/7/2018 om 11:04 PM schreef Bron Gondwana: >> On Mon, 8 Jan 2018, at 00:04, Stephan Bosch wrote: >>> Hi Bron, >>> >>> Op 1/4/2018 om 1:54 AM schreef Bron Gondwana: >>> >>> 2: if the mailbox doesn't support storing save date, the SEARCH >>> extensions should return an error if used, rather than a result, >>> since >>> there's no way to calculate a sensible answer to any of those >>> three.>>> >>> >>> SAVEDBEFORE >>> Messages whose save date (disregarding time and timezone) is>>> earlier than the specified date. >>> >>> SAVEDON >>> Messages whose save date (disregarding time and timezone) is>>> within the specified date. >>> >>> SAVEDSINCE >>> Messages whose save date (disregarding time and timezone) is>>> within or later than the specified date. >>> >>> >>> Ok, for the sake of discussion, I added text with this effect in the>>> last version. However, I am not quite happy with it yet. >>> Returning an>>> error seems a bit harsh. Do we need to provide some means for the >>> client>>> to find out whether the mailbox supports the save date attribute >>> before>>> trying to use it? >> >> That could be done: >> >> TAG select "foo" >> * 1 EXISTS >> * 1 RECENT >> * FLAGS (\Answered \Flagged \Draft \Deleted \Seen) >> * OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Seen \*)] Ok >> * OK [UNSEEN 1] Ok >> * OK [UIDVALIDITY 1515362059] Ok >> * OK [UIDNEXT 2] Ok >> * OK [HIGHESTMODSEQ 7] Ok >> * OK [URLMECH INTERNAL] Ok >> * OK [ANNOTATIONS 65536] Ok >> TAG OK [READ-WRITE] Completed >> >> Another line in there that said something like: >> >> * OK [SAVEDATE] Ok >> >> Would probably work fine. >> >>> Also, there's the MULTISEARCH extension (RFC7377), which adds an >>> ESEARCH>>> command that allows searching across a wide selection of >>> mailboxes, some>>> of which may in fact lack support for the save date attribute. >>> What is>>> to be done in that case? Fail the whole ESEARCH command? Ignore the>>> mailboxes that lack support? Make the SAVED* search items yield >>> a false>>> result for that mailbox? None of these options seem very appealing.>> >> There are three choices: >> 1) reject the command if any folder doesn't support SAVEDATE >> 2) reject the command if none of the folders support SAVEDATE >> 3) succeed regardless of the support for SAVEDATE >> >> And if there are folders that don't support SAVEDATE for case 2 or 3,>> you can: >> a) use the INTERNALDATE instead >> b) don't match the message >> >> I think (a) is clearly wrong here - if you're deleting everything >> that's SAVEDBEFORE 1 month ago from a Trash folder, then INTERNALDATE>> will purge things before you want to. >> >> The alternative is to treat SAVEDATE as NULL in the same way >> SQL does,>> and I think that's the right choice. So you can say "SEARCH NOT >> SAVEDAFTER {X} BEFORE {X}" if you want to get the behaviour of >> deleting everything that was SAVEDBEFORE a time, or fallback to >> INTERNALDATE if it's not supported. >> >>> 3: Do we need to define SAVEDATE as a SORT key extending RFC5256 >>> as>>> well? In theory it should always sort the same as UID. >>> >>> >>> I don't think this is particularly useful, although it is not >>> difficult>>> to add. I agree that sorting is normally equal to seq/UID. I >>> checked:>>> Dovecot does not currently implement a sort key for this. >> >> I'm fine with not having it. >> >> By the way, I have plans for a JMAP extension which maps >> SAVEDATE into>> JMAP. Have been chatting with Neil about it. It seems a good first>> case for an example extension :) >> >> Bron. >> >> -- >> Bron Gondwana, CEO, FastMail Pty Ltd >> brong@fastmailteam.com >> >> >> >> >> _________________________________________________ >> Extra mailing list >> Extra@ietf.org >> https://www.ietf.org/mailman/listinfo/extra > > > -- > Stephan Bosch > Senior Developer > > > Phone: +49 2761 75252 00 Fax: +49 2761 75252 30 > Email: stephan.bosch@dovecot.fi > > > ---------------------------------------------------------------------- > ---------------> Open-Xchange AG, Rollnerstr. 14, 90408 Nuremberg, District Court > Nuremberg HRB 24738> Managing Board: Rafael Laguna de la Vera, Carsten Dirks, Michael > Knapstein> Chairman of the Board: Richard Seibt > > Dovecot Oy, Lars Sonckin Kaari 10, 02600 Espoo, Finland > Managing Director: Markku Kentta > Chairman of the Board: Timo Sirainen > Board Member: Carsten Dirks > > ---------------------------------------------------------------------- > ---------------> -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_151553565222278380 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
No problem at all!  I'm running a choir festival for the next 10 days, so I'm going to have very limited availability anyway :)

Cheers,

Bron.


On Wed, 10 Jan 2018, at 06:37, Stephan Bosch wrote:
Hi Bron,

I need to think about this a little more. I will reply this one a bit later.

Regards,

Stephan.

Op 1/7/2018 om 11:04 PM schreef Bron Gondwana:
On Mon, 8 Jan 2018, at 00:04, Stephan Bosch wrote:
Hi Bron,

Op 1/4/2018 om 1:54 AM schreef Bron Gondwana:

  2: if the mailbox doesn't support storing save date, the SEARCH
  extensions should return an error if used, rather than a result,
  since
  there's no way to calculate a sensible answer to any of those three.


     SAVEDBEFORE <date>
        Messages whose save date (disregarding time and timezone) is
        earlier than the specified date.

     SAVEDON <date>
        Messages whose save date (disregarding time and timezone) is
        within the specified date.

     SAVEDSINCE <date>
        Messages whose save date (disregarding time and timezone) is
        within or later than the specified date.


Ok, for the sake of discussion, I added text with this effect in the
last version. However, I am not quite happy with it yet. Returning an
error seems a bit harsh. Do we need to provide some means for the client
to find out whether the mailbox supports the save date attribute before
trying to use it?

That could be done:

TAG select "foo"
* 1 EXISTS
* 1 RECENT
* FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
* OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Seen \*)] Ok
* OK [UNSEEN 1] Ok
* OK [UIDVALIDITY 1515362059] Ok
* OK [UIDNEXT 2] Ok
* OK [HIGHESTMODSEQ 7] Ok
* OK [URLMECH INTERNAL] Ok
* OK [ANNOTATIONS 65536] Ok
TAG OK [READ-WRITE] Completed

Another line in there that said something like:

* OK [SAVEDATE] Ok

Would probably work fine.

Also, there's the MULTISEARCH extension (RFC7377), which adds an ESEARCH
command that allows searching across a wide selection of mailboxes, some
of which may in fact lack support for the save date attribute. What is
to be done in that case? Fail the whole ESEARCH command? Ignore the
mailboxes that lack support? Make the SAVED* search items yield a false
result for that mailbox? None of these options seem very appealing.

There are three choices:
1) reject the command if any folder doesn't support SAVEDATE
2) reject the command if none of the folders support SAVEDATE
3) succeed regardless of the support for SAVEDATE

And if there are folders that don't support SAVEDATE for case 2 or 3,
you can:
a) use the INTERNALDATE instead
b) don't match the message

I think (a) is clearly wrong here - if you're deleting everything
that's SAVEDBEFORE 1 month ago from a Trash folder, then INTERNALDATE
will purge things before you want to.

The alternative is to treat SAVEDATE as NULL in the same way SQL does,
and I think that's the right choice.  So you can say "SEARCH NOT
SAVEDAFTER {X} BEFORE {X}" if you want to get the behaviour of
deleting everything that was SAVEDBEFORE a time, or fallback to
INTERNALDATE if it's not supported.

  3: Do we need to define SAVEDATE as a SORT key extending RFC5256 as
  well?  In theory it should always sort the same as UID.


I don't think this is particularly useful, although it is not difficult
to add. I agree that sorting is normally equal to seq/UID. I checked:
Dovecot does not currently implement a sort key for this.

I'm fine with not having it.

By the way, I have plans for a JMAP extension which maps SAVEDATE into
JMAP.  Have been chatting with Neil about it.  It seems a good first
case for an example extension :)

Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd




_______________________________________________
Extra mailing list


--
Stephan Bosch
Senior Developer


Phone: +49 2761 75252 00  Fax: +49 2761 75252 30


-------------------------------------------------------------------------------------
Open-Xchange AG,  Rollnerstr. 14, 90408 Nuremberg, District Court Nuremberg HRB 24738
Managing Board: Rafael Laguna de la Vera, Carsten Dirks, Michael Knapstein
Chairman of the Board: Richard Seibt

Dovecot Oy, Lars Sonckin Kaari 10, 02600 Espoo, Finland
Managing Director: Markku Kentta
Chairman of the Board: Timo Sirainen
Board Member: Carsten Dirks

-------------------------------------------------------------------------------------


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


--_----------=_151553565222278380-- From nobody Tue Jan 9 14:24: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 26C2912422F for ; Tue, 9 Jan 2018 14:24:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 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, T_RP_MATCHES_RCVD=-0.01] 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 Wtdy7QrSTx_x for ; Tue, 9 Jan 2018 14:24:27 -0800 (PST) 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 31D8E120726 for ; Tue, 9 Jan 2018 14:24:27 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QNNBB54RPS002H25@mauve.mrochek.com> for extra@ietf.org; Tue, 9 Jan 2018 14:19:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1515536363; bh=ocyXbeWnG/0LiaPIEMAjz4eJbG0pQsH5ZmEGnxS2EBQ=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=MdVd6ckgfqTOBClQlH7xdTE1pp5Wt3tpwizy4iMeVpGOLw1Nz0G7ldPOhnMuYGEvr celfKeJGYVa0lgWj0Snd3tZ9MkKvg/sx+0jFUfWT10r4lepdrek7W7AvmD2wFDvcVE MKZhGFbvUp6/LvK7sH1yCkoeZbWf0DVTr6RgNh+g= MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: TEXT/PLAIN; charset=utf-8 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QNFVO5W1CW000051@mauve.mrochek.com>; Tue, 09 Jan 2018 14:19:21 -0800 (PST) Cc: Ned Freed , extra@ietf.org Message-id: <01QNNBB3GEW0000051@mauve.mrochek.com> Date: Tue, 09 Jan 2018 13:44:08 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Tue, 09 Jan 2018 20:35:13 +0100" References: <151533655607.10858.793231788332492256@ietfa.amsl.com> <01QNLYA7BLVQ000051@mauve.mrochek.com> To: Stephan Bosch 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.22 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, 09 Jan 2018 22:24:29 -0000 > Hi Ned, > Thanks for the review! > Op 1/8/2018 om 5:50 PM schreef Ned Freed: > > I have a few observations and comments on this draft. > > > > The sieve language is designed not to be specific to IMAP. However, this > > extension seems to specifically tied to IMAP in general and to RFC 6154 > > in particular. This means there's really no reason not to tighten the > > association - in particular, would it not make sense to provide sample > > IMAP command sequences to implement the various things in this specification? > > > > This would be quite helpful to implementors, who might otherwise overlook an > > important step. > Hmm, I am not exactly sure what you mean here. Can you give an example?  Pretty simple: Where applicable, show the general sequence of IMAP operations you'd need to perform to implement a given function. > At our end, there is no intermission of IMAP for executing Sieve rules; > both just use the same APIs to operate: i.e., one is not layered above > the other. That's true of our implementation as well. But that's beside the point - we to make sure that these things can be implemented over protocol reasonably, and documenting how its done will help avoid implementation problems. > Also, IMAP command sequences can only show the actions that > are performed, not the decisions that lead to those actions. It doesn't have to be the exact sequence. > > Special use is, in effect, a many-to-many mapping of special use attributes to > > mailboxes. That is, mailboxes can have multiple special use attributes and a > > given attribute can be associated with multiple mailboxes. > > As far as choosing the right mailbox when more than one has the specified > > special-use attribute, the draft says "implementations MUST ensure that this > > choice is made consistently, so that the same mailbox is used every time." > > I don't know how to implement this short of keeping a per-user list of what > > mailbox was used for a given special use attribute. And even a list doesn't > > guarantee that no least astonishment violations will occur. > > Consider: Suppose there's only mailbox for a given special use and I deliver to > > it. Then the user adds an additional special use mailbox. No simple selection > > criteria, e.g., first alphabetically will work in general in this case, because > > I can alway construct an example where the new mailbox beats the old one. > > Creation date doesn't work either, because you can add a special use attribute > > to an existing, old maibox. Mailboxes can also be deleted and recreated. > > You can solve these problems by keeping a list of mailboxes you've used for a > > given special use attribute. But this is a royal PITA, and it still doesn't > > address sequences like > > createa-delivera-createb-deletea-deliverb-deleteb-createa-deliver? > > The bottom line is I think this needs to be relaxed to a SHOULD. It probably > > should also be made clear that if a previously used mailbox no longer exists > > then the mailbox default from the command is used rather than recreating the > > old mailbox. That is, the mailbox explicitly listed in the command wins over > > consistency with the past. > I see what you mean. What about relaxing this statement so that > consistency is required only for as long as the set of mailboxes with > the specified special-use flag remains unchanged? I think that's acceptable. > Adding/removing > mailboxes is then allowed to change the effective mailbox of the > fileinto :specialuse action. The actual choice of the effective mailbox > after each change is still left to the implementation. Summarizing, > consistency is then only guaranteed while the user doesn't mess with the > assignments of the involved special-use flag. That sounds reasonable. > > The other aspect of the many-many mapping is the fact that a single mailbox can > > have multiple special use attributes. The draft supports this in the context of > > specialuse_exists but not in the context of fileinto. I think this is fine, but > > I want to make sure everyone is happy with this limitation, including the fact > > that because of this you won't be able to create mailbox with fileinto with > > multiple special use attributes. > Good point. For sake of discussion, let's assume we allow a string list > for the :specialuse parameter. The semantics for creation of a mailbox > would be quite clear: all of those flags are assigned to the new > mailbox. Seems reasonable. > But what would that mean for the mailbox lookup? Are we looking > for a mailbox that has all of these flags, one of these flags or just > the first flag listed? The convention elsewhere seems pretty clearly to be for it to be an AND rather than an OR. > Another question is whether mailboxes with several special-use flags are > really that useful. Apart from \All, which I would hope is not up to clients to set, I don't see them as being useful. But I may be missing some use cases, which is why I brought it up. > > Section 3 says: > > > > If the "mailbox" string argument is omitted, the "specialuse_exists" > > test yields true if all of the following statements are true for each > > of the special-use flags listed in the "special-use-flags" argument: > > > > a. at least one mailbox exists in the mail store that has that > > particular special-use flag assigned, and > > > > b. that mailbox allows the user in whose context the Sieve script > > runs to "deliver" messages into it. > > > > I'm concerned about a. - the phrase "the mail store" conjures up an image > > of searching through folders belonging to millions of users looking for > > one that has an ACL allowing the sieve owner to write to it. > > > > I'm pretty sure you don't intend this to cover shared folders, so I suggest > > changing the text to say something like: > > > > a. at least one mailbox exists in the user's personal namespace > > [NAMESPACE] that has that particular special-use flag assigned, and > > > > And add the [NAMESPACE] reference pointing at RFC 2342. > I must say I didn't consider any special problems with shared mailboxes. > The scenario you describe is that lots of people are sharing some of > their mailboxes with pretty much everyone. It's not a question of lots of people doing it, it's a question of whether or not you have an optimized way of looking through the entire list of mailboxes in a deployment. Remember that per RFC 6154 section 2, special use attributes are not required to be user-specific. (Although oddly, they only appear in private metadata.) > In that case, indeed, it > could be a lengthy lookup. I guess the impact is > implementation/deployment-dependent. I think we should warn about > situations like this, but not restrict access to the personal > namespace(s) in the specification. I'm afraid I have to disagree. Restricting things to the personal namespace needs to be an allowed implementation option. Frankly, I'm not all that comfortable with even a MAY on allowing more, because I don't think the implications of special-use flags on shared folders have been given any real scrutiny, especially when they are not necessarily per-user. At an absolute minimum this is going to require some discussion in the security considerations. A situation where someone can create a shared folder, open it up with an ACL, and then gather up sent mail from a new user is not really acceptable. > Also, couldn't an account have more than one private namespace? Indeed they can, and this is why you need to use the NAMESPACE extension to find them all and then use LIST on each to find all the relevant special use mailboxes. And this is a good example of why documenting the IMAP command sequences is a good idea. Not everyone is going to pick up on the fact that when implementing this extension over protocol if the NAMESPACE extension is supported you need to make use of it rather than just assuming that LIST "" * is going to give you all the relevant mailboxes. > For > example, there could be a main namespace containing the INBOX and > another namespace on a different slow storage that contains archived > messages. Exactly. Ned From nobody Wed Jan 10 17:43: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 D084412DA49 for ; Wed, 10 Jan 2018 17:43:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_QUOTING=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mailforce.net header.b=FLMmBgaJ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=A0ltnr+t Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-16DT9p6CfQ for ; Wed, 10 Jan 2018 17:43:23 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79A8412D96B for ; Wed, 10 Jan 2018 17:43:23 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 596D620A70; Wed, 10 Jan 2018 20:43:22 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Wed, 10 Jan 2018 20:43:22 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailforce.net; 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=fm2; bh=qHI1kRrZx1GmZJCJg jnXylmi82iUs6O+AGiLAbZdDoo=; b=FLMmBgaJXdHLdh5GSZHFERtInPFoMSGyl uFcW6e87WElSaNTMZCKGnA57x6oPEBVV0apNOwYxgZk2VrqRt1UPRbgTm2UkqHft IX8WvoTEQvKVD2HmM1tgR4fPff+XxmpL8BCiSIB2/skHnQD/YnlwzO0dCqPNl5XI 6IA4rzYyStJRcNtIPf13GQm6rp/zbps0NZi8MeOfSD/vnR12POuPS22wOcFQ/5Ux TqrXzcL5A5d3BRUvUpVjZCu6Zh0XjoJQCOcEo42J95Z7ox5ceVRsx18ts27jFHyX kGM8YY8oiKrQCCDl2EAvlXMBLD9eAuWxL9ZDGeRzmUpQQPKc1W2gQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=qHI1kR rZx1GmZJCJgjnXylmi82iUs6O+AGiLAbZdDoo=; b=A0ltnr+tUz8fSfM71WnGFZ KeTqT705s8FGW0wmonsIZUzAh6taApAYgpbdaZ1pwBh27V+Ygdhru0H4hgg8ZdhM UfRwwHtqybQ4Xhii9PuNgMVyg8vMrZXKZqNAObfFzQPQi3cvw4K96OTgdXusz/IA vpIoKdWGgriAiup0/yErYTHic73meMjwnsfUKtmw2gUyH2Jvv1M6mR2o/c90Rl5E 7CUR7c6H/vvUYBAEDyB7NNyfmjSuDbUNTTYiZkSdgviZrcy9xAh02uJfvhG0SP2b GoQHs0erh5K4IFNY3Bfw7LIlxnKTLp8vkhz/lxlovDmxlXlJLcaRVXpUj3hYnCBA == X-ME-Sender: Received: from [10.234.220.242] (156.sub-97-45-0.myvzw.com [97.45.0.156]) by mail.messagingengine.com (Postfix) with ESMTPA id 722277E353; Wed, 10 Jan 2018 20:43:21 -0500 (EST) References: <1515026277.3124718.1223557384.0EE2A362@webmail.messagingengine.com> <86933152-e2bc-7a03-e997-f361b5d7ee8b@dovecot.fi> In-Reply-To: <86933152-e2bc-7a03-e997-f361b5d7ee8b@dovecot.fi> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <3953E648-8F6A-4582-AD41-A9E9464D9232@glyphein.mailforce.net> Cc: Bron Gondwana , extra@ietf.org X-Mailer: iPhone Mail (13G36) From: Stan Kalisch Date: Wed, 10 Jan 2018 20:43:18 -0500 To: Stephan Bosch Archived-At: Subject: Re: [Extra] STATUS=SIZE todos X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 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, 11 Jan 2018 01:43:26 -0000 Hi Stephan, > On Jan 7, 2018, at 4:56 AM, Stephan Bosch wrote= : >=20 > Hi Bron, >=20 > Op 1/4/2018 om 1:37 AM schreef Bron Gondwana: >> Hi Stephan, >>=20 >> I've created two issues on github for you with two things that need to >> be resolved for STATUS=3DSIZE before it goes on towards publication.=20 >> Sorry about the delay. >=20 > Published my git repository. I looked at the copy in the EXTRA Github repo. The nit that was in draft-ie= tf-extra-imap-list-myrights-00 has found its way into this draft. I ran the= Github copy through idnits; it's the extra space in between ""."" and ""INB= OX"" in Section 3, Line 145. I can't remember if I found one or two RFCs with this bug right before the h= olidays before I put this to the side; I'm still catching up on my old notes= . I'll probably report errata soon. Thanks, Stan >> https://github.com/ietfextra/tracking/issues/10 >> https://github.com/ietfextra/tracking/issues/11 >=20 > Fixed one of these. Left a question on the other one. >=20 >>=20 >> And of course the copyright date now needs to be 2018 :) >=20 > Made an ietf-00 submission. >=20 > Regards, >=20 > Stephan. >=20 > --=20 > Stephan Bosch > Senior Developer=20 >=20 >=20 > Phone: +49 2761 75252 00 Fax: +49 2761 75252 30 > Email: stephan.bosch@dovecot.fi >=20 >=20 > --------------------------------------------------------------------------= ----------- > Open-Xchange AG, Rollnerstr. 14, 90408 Nuremberg, District Court Nurember= g HRB 24738 > Managing Board: Rafael Laguna de la Vera, Carsten Dirks, Michael Knapstein= =20 > Chairman of the Board: Richard Seibt >=20 > Dovecot Oy, Lars Sonckin Kaari 10, 02600 Espoo, Finland > Managing Director: Markku Kentta > Chairman of the Board: Timo Sirainen > Board Member: Carsten Dirks >=20 > --------------------------------------------------------------------------= ----------- >=20 > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra From nobody Thu Jan 11 14:11:55 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 A9EC712DA72; Thu, 11 Jan 2018 14:11:49 -0800 (PST) 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.68.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151570870965.7423.15928071100449458192@ietfa.amsl.com> Date: Thu, 11 Jan 2018 14:11:49 -0800 Archived-At: Subject: [Extra] I-D Action: draft-ietf-extra-sieve-fcc-01.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 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, 11 Jan 2018 22:11:50 -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-01.txt Pages : 8 Date : 2018-01-11 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-01 https://datatracker.ietf.org/doc/html/draft-ietf-extra-sieve-fcc-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-sieve-fcc-01 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 Tue Jan 16 15:15: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 77A9912EBA1 for ; Tue, 16 Jan 2018 15:14:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 SsCpd1IUyrep for ; Tue, 16 Jan 2018 15:14:55 -0800 (PST) Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id DF23512EB99 for ; Tue, 16 Jan 2018 15:14:54 -0800 (PST) Received: from [10.168.3.2] (klara.student.utwente.nl [130.89.162.218]) by mail.dovecot.fi (Postfix) with ESMTPSA id C90512AEF53; Wed, 17 Jan 2018 01:14:52 +0200 (EET) To: Ned Freed Cc: extra@ietf.org References: <151533655607.10858.793231788332492256@ietfa.amsl.com> <01QNLYA7BLVQ000051@mauve.mrochek.com> <01QNNBB3GEW0000051@mauve.mrochek.com> From: Stephan Bosch Message-ID: <990a2344-d003-5a05-6b5c-c9d72a259753@dovecot.fi> Date: Wed, 17 Jan 2018 00:14:49 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <01QNNBB3GEW0000051@mauve.mrochek.com> Content-Type: text/plain; charset=utf-8 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.22 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, 16 Jan 2018 23:14:58 -0000 Hi Ned, Op 1/9/2018 om 10:44 PM schreef Ned Freed: > Op 1/8/2018 om 5:50 PM schreef Ned Freed: >>> I have a few observations and comments on this draft. >>> >>> The sieve language is designed not to be specific to IMAP. However, this >>> extension seems to specifically tied to IMAP in general and to RFC 6154 >>> in particular. This means there's really no reason not to tighten the >>> association - in particular, would it not make sense to provide sample >>> IMAP command sequences to implement the various things in this specification? >>> >>> This would be quite helpful to implementors, who might otherwise overlook an >>> important step. >> Hmm, I am not exactly sure what you mean here. Can you give an example?  > Pretty simple: Where applicable, show the general sequence of IMAP operations > you'd need to perform to implement a given function. > >> At our end, there is no intermission of IMAP for executing Sieve rules; >> both just use the same APIs to operate: i.e., one is not layered above >> the other. > That's true of our implementation as well. But that's beside the point - we > to make sure that these things can be implemented over protocol reasonably, > and documenting how its done will help avoid implementation problems. > >> Also, IMAP command sequences can only show the actions that >> are performed, not the decisions that lead to those actions. > It doesn't have to be the exact sequence. Ok, I'll give that a look. >>> The bottom line is I think this needs to be relaxed to a SHOULD. It probably >>> should also be made clear that if a previously used mailbox no longer exists >>> then the mailbox default from the command is used rather than recreating the >>> old mailbox. That is, the mailbox explicitly listed in the command wins over >>> consistency with the past. >> I see what you mean. What about relaxing this statement so that >> consistency is required only for as long as the set of mailboxes with >> the specified special-use flag remains unchanged? > I think that's acceptable. > >> Adding/removing >> mailboxes is then allowed to change the effective mailbox of the >> fileinto :specialuse action. The actual choice of the effective mailbox >> after each change is still left to the implementation. Summarizing, >> consistency is then only guaranteed while the user doesn't mess with the >> assignments of the involved special-use flag. > That sounds reasonable. Ok, I will make this change. >>> The other aspect of the many-many mapping is the fact that a single mailbox can >>> have multiple special use attributes. The draft supports this in the context of >>> specialuse_exists but not in the context of fileinto. I think this is fine, but >>> I want to make sure everyone is happy with this limitation, including the fact >>> that because of this you won't be able to create mailbox with fileinto with >>> multiple special use attributes. >> Good point. For sake of discussion, let's assume we allow a string list >> for the :specialuse parameter. The semantics for creation of a mailbox >> would be quite clear: all of those flags are assigned to the new >> mailbox. > Seems reasonable. > >> But what would that mean for the mailbox lookup? Are we looking >> for a mailbox that has all of these flags, one of these flags or just >> the first flag listed? > The convention elsewhere seems pretty clearly to be for it to be an AND rather > than an OR. I agree. >> Another question is whether mailboxes with several special-use flags are >> really that useful. > Apart from \All, which I would hope is not up to clients to set, I don't see > them as being useful. But I may be missing some use cases, which is why I > brought it up. Ok. >>> Section 3 says: >>> >>> If the "mailbox" string argument is omitted, the "specialuse_exists" >>> test yields true if all of the following statements are true for each >>> of the special-use flags listed in the "special-use-flags" argument: >>> >>> a. at least one mailbox exists in the mail store that has that >>> particular special-use flag assigned, and >>> >>> b. that mailbox allows the user in whose context the Sieve script >>> runs to "deliver" messages into it. >>> >>> I'm concerned about a. - the phrase "the mail store" conjures up an image >>> of searching through folders belonging to millions of users looking for >>> one that has an ACL allowing the sieve owner to write to it. >>> >>> I'm pretty sure you don't intend this to cover shared folders, so I suggest >>> changing the text to say something like: >>> >>> a. at least one mailbox exists in the user's personal namespace >>> [NAMESPACE] that has that particular special-use flag assigned, and >>> >>> And add the [NAMESPACE] reference pointing at RFC 2342. >> I must say I didn't consider any special problems with shared mailboxes. >> The scenario you describe is that lots of people are sharing some of >> their mailboxes with pretty much everyone. > It's not a question of lots of people doing it, it's a question of whether or > not you have an optimized way of looking through the entire list of mailboxes > in a deployment. Right. We have an (optional) list index for that. > Remember that per RFC 6154 section 2, special use attributes are not required > to be user-specific. (Although oddly, they only appear in private metadata.) > >> In that case, indeed, it >> could be a lengthy lookup. I guess the impact is >> implementation/deployment-dependent. I think we should warn about >> situations like this, but not restrict access to the personal >> namespace(s) in the specification. > I'm afraid I have to disagree. Restricting things to the personal > namespace needs to be an allowed implementation option. Frankly, I'm > not all that comfortable with even a MAY on allowing more, because I don't > think the implications of special-use flags on shared folders have > been given any real scrutiny, especially when they are not necessarily > per-user. > > At an absolute minimum this is going to require some discussion > in the security considerations. A situation where someone can > create a shared folder, open it up with an ACL, and then gather > up sent mail from a new user is not really acceptable. Hmm, I'll look into this when I make a new version. >> Also, couldn't an account have more than one private namespace? > Indeed they can, and this is why you need to use the NAMESPACE extension > to find them all and then use LIST on each to find all the relevant > special use mailboxes. > > And this is a good example of why documenting the IMAP command sequences is a > good idea. Not everyone is going to pick up on the fact that when implementing > this extension over protocol if the NAMESPACE extension is supported you need > to make use of it rather than just assuming that LIST "" * is going to give you > all the relevant mailboxes. Ok. I hope I have time make a new version by the end of this week. We'll see. Regards, -- Stephan Bosch Senior Developer Phone: +49 2761 75252 00 Fax: +49 2761 75252 30 Email: stephan.bosch@dovecot.fi ------------------------------------------------------------------------------------- Open-Xchange AG, Rollnerstr. 14, 90408 Nuremberg, District Court Nuremberg HRB 24738 Managing Board: Rafael Laguna de la Vera, Carsten Dirks, Michael Knapstein Chairman of the Board: Richard Seibt Dovecot Oy, Lars Sonckin Kaari 10, 02600 Espoo, Finland Managing Director: Markku Kentta Chairman of the Board: Timo Sirainen Board Member: Carsten Dirks ------------------------------------------------------------------------------------- From nobody Sun Jan 21 19:31:09 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 568BE126CC7 for ; Sun, 21 Jan 2018 19:31:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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=mailforce.net header.b=gABreerO; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Ss5Nlrmu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6yyAdWuB55dW for ; Sun, 21 Jan 2018 19:31:05 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BDCD1200F1 for ; Sun, 21 Jan 2018 19:31:05 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 9FA3B20BC9 for ; Sun, 21 Jan 2018 22:31:04 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Sun, 21 Jan 2018 22:31:04 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailforce.net; 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=fm2; bh=ZVMd7meCaC4WfaIBtSnAjdO7BzVAx i4kA0FQcTIFzAs=; b=gABreerOmPcXKHZfhpOmwNEVzBpfWimraI6Jn1umTGgfs 5l30WXHKP6NMcmTlWtIhdKdf651+5qVUj3n7/XK69YJJaV+9eOijfIOBUfDpKY3/ IvyAVsDkKpsx/6VMOH/Qy1Z019VlwYqCrVbo/McuhZReQ7YC+IzQng4WxkPUZSS0 Mqoydm4r+Y/qoHRRDTiQlya6A4ExUivwqXIFIGcKd3qPezRIBJObK1nXCc57j8ra UsL3ogwCAo+0OqqQwFJabUne0RG2bWl3H5N9LowC/dd9NSC2ARb5yRWL7DIg7KFA xw6xcJcWSWRvfNc03Ydp/lzjyAbLtjMlWbC2CdpvA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=ZVMd7m eCaC4WfaIBtSnAjdO7BzVAxi4kA0FQcTIFzAs=; b=Ss5NlrmugB0tzOHsbqJ9SQ j6ml5rg7n/iAkz0QNMbuiHqX2xJTR6k17x5JBCY7SoUr/RjvmZ3ywMfnbQh/h1Rv Jps57YgCTW5cEUux35mhx7bPtkS/3ut1CzKzF8yg3pUjbbyfrstuVlIBsgmOefT7 7HsG1XqajpFLkWLxBebVMivD+gaOKbP/grI23hfqCxl5tdKZH8jPxT7vEbYH2NPK Shjxm1JK0ItXbvqYFwmOAE2XdJ/JHEYKMaVzeyxxX12ILSz4ZQZzu6zvvH+H0K+B Fk3WMuQMp/Zn3y9srUSCCIrL2n1hV0mZUKm9Hm41Fe4SK3WNc5R7wrHbdzCzEeZw == X-ME-Sender: Received: from [192.168.1.71] (108-84-31-27.lightspeed.tukrga.sbcglobal.net [108.84.31.27]) by mail.messagingengine.com (Postfix) with ESMTPA id 471377E3DE for ; Sun, 21 Jan 2018 22:31:04 -0500 (EST) References: <151570870965.7423.15928071100449458192@ietfa.amsl.com> From: Stan Kalisch Content-Type: multipart/alternative; boundary=Apple-Mail-1221F3A3-BDC7-4A8B-9A7B-8FD84A915B6B X-Mailer: iPhone Mail (13G36) In-Reply-To: <151570870965.7423.15928071100449458192@ietfa.amsl.com> Message-Id: Date: Sun, 21 Jan 2018 22:31:01 -0500 To: extra@ietf.org Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Archived-At: Subject: Re: [Extra] I-D Action: draft-ietf-extra-sieve-fcc-01.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 22 Jan 2018 03:31:07 -0000 --Apple-Mail-1221F3A3-BDC7-4A8B-9A7B-8FD84A915B6B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On Jan 11, 2018, at 5:11 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts directo= ries. > This draft is a work item of the Email mailstore and eXtensions To Revise o= r Amend WG of the IETF. >=20 > Title : Sieve Extension: File Carbon Copy (Fcc) > Authors : Kenneth Murchison > Bron Gondwana > Filename : draft-ietf-extra-sieve-fcc-01.txt > Pages : 8 > Date : 2018-01-11 special-use uses variables, if present. So it couldn't hurt to reference th= at in the Security Considerations here. Thanks, Stan > 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. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-extra-sieve-fcc/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-extra-sieve-fcc-01 > https://datatracker.ietf.org/doc/html/draft-ietf-extra-sieve-fcc-01 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-extra-sieve-fcc-01 >=20 >=20 > Please note that it may take a couple of minutes from the time of submissi= on > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra --Apple-Mail-1221F3A3-BDC7-4A8B-9A7B-8FD84A915B6B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On Jan 1= 1, 2018, at 5:11 PM, internet-dr= afts@ietf.org wrote:

<= /span>
A New Internet-Draft is available from the on-line Internet-= Drafts directories.
This draft is a work item of the Email m= ailstore and eXtensions To Revise or Amend WG of the IETF.
<= /span>
       Title   = ;        : Sieve Extension: File Car= bon Copy (Fcc)
       Au= thors         : Kenneth Murchison
          &= nbsp;            = ;  Bron Gondwana
   Filename  &nbs= p;     : draft-ietf-extra-sieve-fcc-01.txt    Pages         =   : 8
   Date     &= nbsp;      : 2018-01-11

special-use uses variables, if present.  So it couldn't hurt to r=
eference that in the Security Considerations here.


<=
/font>
Than=
ks,
Stan

Abstract:
   T=
he Sieve Email Filtering Language provides a number of action
   commands, some of which can generate additional messages on b=
ehalf of
   the user.  This document defines a=
n extension to such commands to
   allow a copy of=
 any generated message to be filed into a target
  &nbs=
p;mailbox.


The IETF datatr=
acker status page for this draft is:
https://datatracker.ietf.o=
rg/doc/draft-ietf-extra-sieve-fcc/

Ther=
e are also htmlized versions available at:
https://tools.ietf.org/=
html/draft-ietf-extra-sieve-fcc-01
https://datatrack=
er.ietf.org/doc/html/draft-ietf-extra-sieve-fcc-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-extra-sieve-fcc-01


Please note that it may take=
 a couple of minutes from the time of submission
until the h=
tmlized version and diff are available at =
tools.ietf.org.

Internet-Drafts are als=
o available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
=
Extra mailing list
E=
xtra@ietf.org
https://www.ietf.org/mailman/listinfo/extra
= --Apple-Mail-1221F3A3-BDC7-4A8B-9A7B-8FD84A915B6B-- From nobody Sun Jan 28 01:08:48 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 748FC12D88C for ; Sun, 28 Jan 2018 01:08:46 -0800 (PST) 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=M+KBG6Kn; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=JAqF5n7+ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sKzypzqs708f for ; Sun, 28 Jan 2018 01:08:45 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 054E412DB6D for ; Sun, 28 Jan 2018 01:08:45 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 6CBAB20EE2 for ; Sun, 28 Jan 2018 04:08:44 -0500 (EST) Received: from web2 ([10.202.2.212]) by compute6.internal (MEProxy); Sun, 28 Jan 2018 04:08:44 -0500 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=fm1; bh=iGVclDyHnaYCE/ifxsTVM+7KiA2r6U84OlIOenWHb qI=; b=M+KBG6Kn6KWynDr7QPvc5J2cepYaCZJldbPB+10iNHtcqVSGdkDJmTZo3 KbmR5GAe6Gt05OoMkNAN7DMZ3vpGr9i7ETuRWFjroLTwLZqKGBMAiUtH95AZXZZQ SW/8oeT1hz35HuIy545tczIws2WAfH9qPupEY//KoqZDTuvdrp8AmgQq624DF66b eibvM3F2PbU6NN5t8VZn+sfdDBKYT/Or+KYACCsOAvlM9sckg2XyS2pF+y/mjhNN dTu28DkZdypkN/Bu4l/6Z16u4Z3rdIUbUFt/y2pCfzu0bR9wwA9n/ZZgFmYNdaKn Y2h3uImOCfUtGzoDjVXBeR3Jyrb+w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=iGVclDyHnaYCE/ifxsTVM+7KiA2r6 U84OlIOenWHbqI=; b=JAqF5n7+h4zMxvyLr6UbLGKwNbpkbY2YcJ9oo3LTwBpr/ GpQPDaupXUpjB4NwHOqexQ8Aw7acyGueXzDt5yy/7CA3+9smfjJQ9qw1OTGzZM4i nDpGGClWIrJYDNuh55BVzoVy7KO68Oy1mhgincywsJtnydEC1i8vv0HXqJWFiiUo 8gJWR8T3Cc8TGr4ihxGg/Y8fdsy8cmnprQe7YiG5Lp33pacxLAekc+iuA47JvcRz VPx1DLA68OJyY321nRfuMoGzk/WE8Amg1MH0IXOvc6pVrnCXCnwMsheoDcSYTqTr MxOzOPF8piILDJfUvoNsGN0gdU6Y1v59ULK0MEEVg== X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 4E6B362AF4; Sun, 28 Jan 2018 04:08:44 -0500 (EST) Message-Id: <1517130524.344000.1250648088.47FFBC57@webmail.messagingengine.com> From: Bron Gondwana To: extra@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15171305243440001" X-Mailer: MessagingEngine.com Webmail Interface - ajax-20f48d70 Date: Sun, 28 Jan 2018 20:08:44 +1100 Archived-At: Subject: [Extra] Planning for X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 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, 28 Jan 2018 09:08:46 -0000 This is a multi-part message in MIME format. --_----------=_15171305243440001 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" Hi All, I've just send a proposed list of conflicts for the JMAP session to the JMAP mailing list. I'm going to post the same list here, though I suspect we can pare the conflicts list back a bit for EXTRA. I don't want to make things a total headache for the people doing scheduling. I guess the other question is: do we have much to discuss in London? Is there much benefit in scheduling official face time? How much do you think we need - just grab a half hour, or is there more meat on the bone? Primary blockers: * jmap * dispatch * dcrup * doh * uta * oauth With secondary against: * saag * tls * ace I think that's everything that interacts with our purpose as EXTRA, but let me know if there's anything else - particularlyJiankang as co-chair :) Cheers, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_15171305243440001 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
Hi All,

I've just send a proposed list of conflicts for the JMAP session to the JMAP mailing list.  I'm going to post the same list here, though I suspect we can pare the conflicts list back a bit for EXTRA.  I don't want to make things a total headache for the people doing scheduling.

I guess the other question is: do we have much to discuss in London?  Is there much benefit in scheduling official face time?  How much do you think we need - just grab a half hour, or is there more meat on the bone?

Primary blockers:

* jmap
* dispatch
* dcrup
* doh
* uta
* oauth

With secondary against:
* saag
* tls
* ace

I think that's everything that interacts with our purpose as EXTRA, but let me know if there's anything else - particularly
Jiankang as co-chair :)

Cheers,

Bron.

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


--_----------=_15171305243440001-- From nobody Sun Jan 28 01:09: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 7453E12DA6D for ; Sun, 28 Jan 2018 01:09:29 -0800 (PST) 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=Iwwew1/5; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=DnqKvR11 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ajj0nKkNx5ki for ; Sun, 28 Jan 2018 01:09:27 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91CA912D88C for ; Sun, 28 Jan 2018 01:09:27 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 0564420F99 for ; Sun, 28 Jan 2018 04:09:27 -0500 (EST) Received: from web2 ([10.202.2.212]) by compute6.internal (MEProxy); Sun, 28 Jan 2018 04:09:27 -0500 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=fm1; bh=vPdDu05RgofqDPBwB yq04YZLe44Los/05af1/35Cews=; b=Iwwew1/51QcMxvW4ifpsMjHMYwZl6oWAO m+w3a1G9upQ5KuRA7FYuC+S65wVR7UFOVQOHTYWGMD7FJc9RiOTQwLUFkQieBaJh L2fX9KQEiFPYQKCVqYQDSZraTXE4ATRcd2uMBxFzSW84s7IqTaZgpCLDH9zCwZwL jYE+wKt7dTvbtZ4HsBZYNr09BWro/0gj9kWcjYvS8t4nlIlHuCU56X+yr8KhHl2T kjXuK+k5xPKcqWnBx2p+Msj/q/LnRtW2oMbDf73KRE3czjWYHIMS4HhSkZlRChce SeSqy9ROacN7vO25IMa2P9HmxAERkTRI8FeF1R8DAEJwLR6lSrXBA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=vPdDu0 5RgofqDPBwByq04YZLe44Los/05af1/35Cews=; b=DnqKvR11APTeF2mnKjxzAc qEN1Q3lWU6eR+rm6yX7solVcu2DvXDPiDs3xAOxPKpl2v/Nl5GFsMsZH5615WOWi etoI1gaYNRun40yxudrEzXYEsktht+a1lC7telSYyaG/QC5FriX/WNN7i41n5TRy 1tPomTrjcwAbxR6xWZ6cjkXJp88hNG1msJFTZj6grtauIcmV6IXqgv1x1Crv+Gtk rhGF9/7VApWeKBy0VLFI35zwbaqO6u3h1CXITzSGqh+JJctSkF0so5xsc1/GGyfJ WpSQ7w3HXG9YeMUVumOAlqdmuBMyLRifZD2Nrr/vTCtwasyBUhvtbsVZjWWibreg == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id D65F562AF4; Sun, 28 Jan 2018 04:09:26 -0500 (EST) Message-Id: <1517130566.344125.1250651728.3FCB0DE6@webmail.messagingengine.com> From: Bron Gondwana To: extra@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15171305663441252" X-Mailer: MessagingEngine.com Webmail Interface - ajax-20f48d70 In-Reply-To: <1517130524.344000.1250648088.47FFBC57@webmail.messagingengine.com> Date: Sun, 28 Jan 2018 20:09:26 +1100 References: <1517130524.344000.1250648088.47FFBC57@webmail.messagingengine.com> Archived-At: Subject: Re: [Extra] Planning for session in London X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 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, 28 Jan 2018 09:09:29 -0000 This is a multi-part message in MIME format. --_----------=_15171305663441252 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" (oops, sorry about forgetting to complete Subject!) On Sun, 28 Jan 2018, at 20:08, Bron Gondwana wrote: > Hi All, > > I've just send a proposed list of conflicts for the JMAP session to > the JMAP mailing list. I'm going to post the same list here, though I > suspect we can pare the conflicts list back a bit for EXTRA. I don't > want to make things a total headache for the people doing scheduling.> > I guess the other question is: do we have much to discuss in London? > Is there much benefit in scheduling official face time? How much do > you think we need - just grab a half hour, or is there more meat on > the bone?> > Primary blockers: > > * jmap > * dispatch > * dcrup > * doh > > * uta > > * oauth > > With secondary against: > * saag > * tls > * ace > > I think that's everything that interacts with our purpose as EXTRA, > but let me know if there's anything else - particularly> Jiankang as co-chair :) > > Cheers, > > Bron. > > -- > Bron Gondwana, CEO, FastMail Pty Ltd > brong@fastmailteam.com > > > _________________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_15171305663441252 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
(oops, sorry about forgetting to complete Subject!)

On Sun, 28 Jan 2018, at 20:08, Bron Gondwana wrote:
Hi All,

I've just send a proposed list of conflicts for the JMAP session to the JMAP mailing list.  I'm going to post the same list here, though I suspect we can pare the conflicts list back a bit for EXTRA.  I don't want to make things a total headache for the people doing scheduling.

I guess the other question is: do we have much to discuss in London?  Is there much benefit in scheduling official face time?  How much do you think we need - just grab a half hour, or is there more meat on the bone?

Primary blockers:

* jmap
* dispatch
* dcrup
* doh

* uta

* oauth

With secondary against:
* saag
* tls
* ace

I think that's everything that interacts with our purpose as EXTRA, but let me know if there's anything else - particularly
Jiankang as co-chair :)

Cheers,

Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd


_______________________________________________
Extra mailing list

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


--_----------=_15171305663441252-- From nobody Sun Jan 28 05:48: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 7B2C112EC09 for ; Sun, 28 Jan 2018 05:48:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, WEIRD_QUOTING=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 ax8-aHgyvqGr for ; Sun, 28 Jan 2018 05:48:27 -0800 (PST) Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id 08EB512EBFC for ; Sun, 28 Jan 2018 05:48:27 -0800 (PST) Received: from [10.168.3.2] (klara.student.utwente.nl [130.89.162.218]) by mail.dovecot.fi (Postfix) with ESMTPSA id 4AE2F2AEF53; Sun, 28 Jan 2018 15:48:25 +0200 (EET) To: Stan Kalisch Cc: extra@ietf.org, Bron Gondwana References: <1515026277.3124718.1223557384.0EE2A362@webmail.messagingengine.com> <86933152-e2bc-7a03-e997-f361b5d7ee8b@dovecot.fi> <3953E648-8F6A-4582-AD41-A9E9464D9232@glyphein.mailforce.net> From: Stephan Bosch Message-ID: <4f566c40-4e3a-622d-55da-eeda9bd2f5dd@dovecot.fi> Date: Sun, 28 Jan 2018 14:48:23 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <3953E648-8F6A-4582-AD41-A9E9464D9232@glyphein.mailforce.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: nl Archived-At: Subject: Re: [Extra] STATUS=SIZE todos X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 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, 28 Jan 2018 13:48:28 -0000 Op 1/11/2018 om 2:43 AM schreef Stan Kalisch: > Hi Stephan, > >> On Jan 7, 2018, at 4:56 AM, Stephan Bosch wrote: >> >> Hi Bron, >> >> Op 1/4/2018 om 1:37 AM schreef Bron Gondwana: >>> Hi Stephan, >>> >>> I've created two issues on github for you with two things that need to >>> be resolved for STATUS=SIZE before it goes on towards publication. >>> Sorry about the delay. >> Published my git repository. > I looked at the copy in the EXTRA Github repo. The nit that was in draft-ietf-extra-imap-list-myrights-00 has found its way into this draft. I ran the Github copy through idnits; it's the extra space in between ""."" and ""INBOX"" in Section 3, Line 145. > > I can't remember if I found one or two RFCs with this bug right before the holidays before I put this to the side; I'm still catching up on my old notes. I'll probably report errata soon. Fixed: https://github.com/ietfextra/draft-ietf-extra-imap-status-size/commit/41d8c62519804c52d710df4a4591b8dc192930e1 -- Stephan Bosch Senior Developer Phone: +49 2761 75252 00 Fax: +49 2761 75252 30 Email: stephan.bosch@dovecot.fi ------------------------------------------------------------------------------------- Open-Xchange AG, Rollnerstr. 14, 90408 Nuremberg, District Court Nuremberg HRB 24738 Managing Board: Rafael Laguna de la Vera, Carsten Dirks, Michael Knapstein Chairman of the Board: Richard Seibt Dovecot Oy, Lars Sonckin Kaari 10, 02600 Espoo, Finland Managing Director: Markku Kentta Chairman of the Board: Timo Sirainen Board Member: Carsten Dirks ------------------------------------------------------------------------------------- From nobody Sun Jan 28 06:51:14 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 9197312EBC8 for ; Sun, 28 Jan 2018 06:51:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 n9DuIM2L99sN for ; Sun, 28 Jan 2018 06:51:11 -0800 (PST) Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id 90EAD128D2E for ; Sun, 28 Jan 2018 06:51:10 -0800 (PST) Received: from [10.168.3.2] (klara.student.utwente.nl [130.89.162.218]) by mail.dovecot.fi (Postfix) with ESMTPSA id 8A84C2AEF53; Sun, 28 Jan 2018 16:51:08 +0200 (EET) To: Bron Gondwana , extra@ietf.org References: <1515027295.3130822.1223568456.6D1D8F15@webmail.messagingengine.com> <1515362666.2687647.1227253816.726EA133@webmail.messagingengine.com> From: Stephan Bosch Message-ID: <7d5e0617-cba4-c19c-8426-64f2a9e8f1eb@dovecot.fi> Date: Sun, 28 Jan 2018 15:51:07 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <1515362666.2687647.1227253816.726EA133@webmail.messagingengine.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Extra] SAVEDATE updated required X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 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, 28 Jan 2018 14:51:13 -0000 Op 1/7/2018 om 11:04 PM schreef Bron Gondwana: > On Mon, 8 Jan 2018, at 00:04, Stephan Bosch wrote: >> Hi Bron, >> >> Op 1/4/2018 om 1:54 AM schreef Bron Gondwana: >> >> 2: if the mailbox doesn't support storing save date, the SEARCH >> extensions should return an error if used, rather than a result, >> since >> there's no way to calculate a sensible answer to any of those three. >> >> >> Ok, for the sake of discussion, I added text with this effect in the >> last version. However, I am not quite happy with it yet. Returning an >> error seems a bit harsh. Do we need to provide some means for the client >> to find out whether the mailbox supports the save date attribute before >> trying to use it? > > That could be done: > > TAG select "foo" > * 1 EXISTS > * 1 RECENT > * FLAGS (\Answered \Flagged \Draft \Deleted \Seen) > * OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Seen \*)] Ok > * OK [UNSEEN 1] Ok > * OK [UIDVALIDITY 1515362059] Ok > * OK [UIDNEXT 2] Ok > * OK [HIGHESTMODSEQ 7] Ok > * OK [URLMECH INTERNAL] Ok > * OK [ANNOTATIONS 65536] Ok > TAG OK [READ-WRITE] Completed > > Another line in there that said something like: > > * OK [SAVEDATE] Ok > > Would probably work fine. Yes, that could work. Although, when the SQL NULL semantics (discussed below) are implemented, this would likely no longer be necessary/useful. >> Also, there's the MULTISEARCH extension (RFC7377), which adds an ESEARCH >> command that allows searching across a wide selection of mailboxes, some >> of which may in fact lack support for the save date attribute. What is >> to be done in that case? Fail the whole ESEARCH command? Ignore the >> mailboxes that lack support? Make the SAVED* search items yield a false >> result for that mailbox? None of these options seem very appealing. > > There are three choices: > 1) reject the command if any folder doesn't support SAVEDATE > 2) reject the command if none of the folders support SAVEDATE > 3) succeed regardless of the support for SAVEDATE > > And if there are folders that don't support SAVEDATE for case 2 or 3, > you can: > a) use the INTERNALDATE instead > b) don't match the message > > I think (a) is clearly wrong here - if you're deleting everything > that's SAVEDBEFORE 1 month ago from a Trash folder, then INTERNALDATE > will purge things before you want to. Yes, indeed. > The alternative is to treat SAVEDATE as NULL in the same way SQL does, > and I think that's the right choice.  So you can say "SEARCH NOT > SAVEDAFTER {X} BEFORE {X}" if you want to get the behaviour of > deleting everything that was SAVEDBEFORE a time, or fallback to > INTERNALDATE if it's not supported. I see what you're trying to do here and I agree that something like that would be a good idea. However, we need  to be very careful about the semantics. With SQL 3-valued logic, I think (with my rather limited SQL-fu) your example would evaluate to Unknown: `NOT SAVEDAFTER {X} BEFORE {X}' logically translates to: (not `SAVEDAFTER {X}') and `BEFORE {X}' (not Unknown) and `BEFORE {X}' Unknown and `BEFORE {X}' Unknown So, how did you expect this example to work? Or am I doing something wrong in this inference? > > By the way, I have plans for a JMAP extension which maps SAVEDATE into > JMAP.  Have been chatting with Neil about it.  It seems a good first > case for an example extension :) Ok, good. :) Regards, -- Stephan Bosch Senior Developer Phone: +49 2761 75252 00 Fax: +49 2761 75252 30 Email: stephan.bosch@dovecot.fi ------------------------------------------------------------------------------------- Open-Xchange AG, Rollnerstr. 14, 90408 Nuremberg, District Court Nuremberg HRB 24738 Managing Board: Rafael Laguna de la Vera, Carsten Dirks, Michael Knapstein Chairman of the Board: Richard Seibt Dovecot Oy, Lars Sonckin Kaari 10, 02600 Espoo, Finland Managing Director: Markku Kentta Chairman of the Board: Timo Sirainen Board Member: Carsten Dirks ------------------------------------------------------------------------------------- From nobody Sun Jan 28 17:45: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 426001274D2 for ; Sun, 28 Jan 2018 17:45:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 YAcnl8XQka6e for ; Sun, 28 Jan 2018 17:45:55 -0800 (PST) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 50A32127444 for ; Sun, 28 Jan 2018 17:45:53 -0800 (PST) Received: from healthyao-PC (unknown [218.241.103.110]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0A5QNDIfG5acVfNAA--.41686S2; Mon, 29 Jan 2018 09:45:44 +0800 (CST) Date: Mon, 29 Jan 2018 09:45:45 +0800 From: "Jiankang Yao" To: brong , extra Reply-To: yaojk References: <1517130524.344000.1250648088.47FFBC57@webmail.messagingengine.com>, <1517130566.344125.1250651728.3FCB0DE6@webmail.messagingengine.com> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.92[cn] Mime-Version: 1.0 Message-ID: <2018012909453626942569@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart803785566377_=----" X-CM-TRANSID: AQAAf0A5QNDIfG5acVfNAA--.41686S2 X-Coremail-Antispam: 1UD129KBjvJXoWxJrWDuw1kAFykAF1xGFyDZFb_yoW8GrW8pr 45Gr1IkryDGF1UJw1xAw1xW3Wjy395X347try5t3y0k398Ga1jgr1UtwnxZFyUXrn5tw1q 939ru34DCws3Ca7anT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUB0b7Iv0xC_tr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_Gr1j6F4UJwA2z4x0Y4 vEx4A2jsIEc7CjxVAFwI0_Cr1j6rxdM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVCF 0I0E4I0vr24l5I8CrVC2YI8G0VAIFx02awAv7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2z2 80aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcxkI7VAKI48JM4xvF2IE b7IF0Fy264kE64k0F24lc2xSY4AK67AK6w4l42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x 0Yz7v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUGVWUWwC20s026x8GjcxK67AKxVWUGVWUWwC2 zVAF1VAY17CE14v26r1Y6r17MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF 4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWrZr1j 6s0DMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Jr0_Gr1l6V ACY4xI67k04243AbIYCTnIWIevJa73UjIFyTuYvjxU22YLDUUUU X-CM-SenderInfo: x1dryyw6fq0xffof0/ Archived-At: Subject: Re: [Extra] Planning for session in London X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 29 Jan 2018 01:45:57 -0000 This is a multi-part message in MIME format. ------=_001_NextPart803785566377_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sDQogICAgDQogICAgSSBwcmVmZXIgdG8gbGlzdCBSRUdFWFQgYXMgdGhlIFByaW1hcnkg YmxvY2tlciwgICAgYW5kIEROU09QICBhcyB0aGUgUHJpbWFyeSBvciBzZWNvbmRhcnkgYmxvY2tl ci4NCg0KdGhhbmtzLg0KDQoNCg0KDQpKaWFua2FuZyBZYW8NCg0KRnJvbTogQnJvbiBHb25kd2Fu YQ0KRGF0ZTogMjAxOC0wMS0yOCAxNzowOQ0KVG86IGV4dHJhDQpTdWJqZWN0OiBSZTogW0V4dHJh XSBQbGFubmluZyBmb3Igc2Vzc2lvbiBpbiBMb25kb24NCihvb3BzLCBzb3JyeSBhYm91dCBmb3Jn ZXR0aW5nIHRvIGNvbXBsZXRlIFN1YmplY3QhKQ0KDQoNCg0KT24gU3VuLCAyOCBKYW4gMjAxOCwg YXQgMjA6MDgsIEJyb24gR29uZHdhbmEgd3JvdGU6DQoNCkhpIEFsbCwNCg0KDQoNCkkndmUganVz dCBzZW5kIGEgcHJvcG9zZWQgbGlzdCBvZiBjb25mbGljdHMgZm9yIHRoZSBKTUFQIHNlc3Npb24g dG8gdGhlIEpNQVAgbWFpbGluZyBsaXN0LiAgSSdtIGdvaW5nIHRvIHBvc3QgdGhlIHNhbWUgbGlz dCBoZXJlLCB0aG91Z2ggSSBzdXNwZWN0IHdlIGNhbiBwYXJlIHRoZSBjb25mbGljdHMgbGlzdCBi YWNrIGEgYml0IGZvciBFWFRSQS4gIEkgZG9uJ3Qgd2FudCB0byBtYWtlIHRoaW5ncyBhIHRvdGFs IGhlYWRhY2hlIGZvciB0aGUgcGVvcGxlIGRvaW5nIHNjaGVkdWxpbmcuDQoNCg0KDQpJIGd1ZXNz IHRoZSBvdGhlciBxdWVzdGlvbiBpczogZG8gd2UgaGF2ZSBtdWNoIHRvIGRpc2N1c3MgaW4gTG9u ZG9uPyAgSXMgdGhlcmUgbXVjaCBiZW5lZml0IGluIHNjaGVkdWxpbmcgb2ZmaWNpYWwgZmFjZSB0 aW1lPyAgSG93IG11Y2ggZG8geW91IHRoaW5rIHdlIG5lZWQgLSBqdXN0IGdyYWIgYSBoYWxmIGhv dXIsIG9yIGlzIHRoZXJlIG1vcmUgbWVhdCBvbiB0aGUgYm9uZT8NCg0KDQoNClByaW1hcnkgYmxv Y2tlcnM6DQoNCg0KDQoqIGptYXANCg0KKiBkaXNwYXRjaA0KDQoqIGRjcnVwDQoNCiogZG9oDQoN Cg0KDQoqIHV0YQ0KDQoNCg0KKiBvYXV0aA0KDQoNCg0KV2l0aCBzZWNvbmRhcnkgYWdhaW5zdDoN Cg0KKiBzYWFnDQoNCiogdGxzDQoNCiogYWNlDQoNCg0KDQpJIHRoaW5rIHRoYXQncyBldmVyeXRo aW5nIHRoYXQgaW50ZXJhY3RzIHdpdGggb3VyIHB1cnBvc2UgYXMgRVhUUkEsIGJ1dCBsZXQgbWUg a25vdyBpZiB0aGVyZSdzIGFueXRoaW5nIGVsc2UgLSBwYXJ0aWN1bGFybHkNCg0KSmlhbmthbmcg YXMgY28tY2hhaXIgOikNCg0KDQoNCkNoZWVycywNCg0KDQoNCkJyb24uDQoNCg0KDQotLQ0KDQog IEJyb24gR29uZHdhbmEsIENFTywgRmFzdE1haWwgUHR5IEx0ZA0KDQogIGJyb25nQGZhc3RtYWls dGVhbS5jb20NCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KDQpFeHRyYSBtYWlsaW5nIGxpc3QNCg0KRXh0cmFAaWV0Zi5vcmcNCg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9leHRyYQ0KDQoNCg0KLS0NCg0KICBC cm9uIEdvbmR3YW5hLCBDRU8sIEZhc3RNYWlsIFB0eSBMdGQNCg0KICBicm9uZ0BmYXN0bWFpbHRl YW0uY29t ------=_001_NextPart803785566377_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
Hello,
   
    I prefer to list REGEXT as the Primary=20 blocker,    and DNSOP  as the Primary or=20 secondary blocker.
 
thanks.
 
Jiankang Yao
 
Date: 2018-01-28 17:09
To: extra
Subject: Re: [Extra] Planning for session in=20 London
(oops, sorry about forgetting to complet= e=20 Subject!)

On Sun, 28 Jan 2018, at 20:08, Bron Gondwana wrote:
Hi All,

I've just send a proposed list of= =20 conflicts for the JMAP session to the JMAP mailing list.  I'm going= to=20 post the same list here, though I suspect we can pare the conflicts list= back=20 a bit for EXTRA.  I don't want to make things a total headache for = the=20 people doing scheduling.

I guess the other question is: do we h= ave much=20 to discuss in London?  Is there much benefit in scheduling official= face=20 time?  How much do you think we need - just grab a half hour, or is= there=20 more meat on the bone?

Primary blockers:

* jmap
* dispatch
* dcrup
* doh

* uta

* oauth

With secondary against:
* saag
* tls
* ace

I think that's everything that interac= ts with=20 our purpose as EXTRA, but let me know if there's anything else -=20 particularly
Jiankang as co-chair :)

Cheers,

Bron.

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


_______________________________________________
Extra mailing list
https://www.ietf.or= g/mailman/listinfo/extra

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


------=_001_NextPart803785566377_=------ From nobody Tue Jan 30 11:43:35 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 7A71312FAD3; Tue, 30 Jan 2018 11:43:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: extra@ietf.org, brong@fastmailteam.com, extra-chairs@ietf.org, aamelnikov@fastmail.fm X-Test-IDTracker: no X-IETF-IDTracker: 6.70.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151734141445.31736.17517215075153946683.idtracker@ietfa.amsl.com> Date: Tue, 30 Jan 2018 11:43:34 -0800 Archived-At: Subject: [Extra] extra - New Meeting Session Request for IETF 101 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 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, 30 Jan 2018 19:43:34 -0000 A new meeting session request has just been submitted by Bron Gondwana, a Chair of the extra working group. --------------------------------------------------------- Working Group Name: Email mailstore and eXtensions To Revise or Amend Area Name: Applications and Real-Time Area Session Requester: Bron Gondwana Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 30 Conflicts to Avoid: First Priority: jmap, dmarc, regext, dispatch, dcrup, doh, uta Second Priority: oauth, saag, tls, ace, dnsop, calext People who must be present: Alexey Melnikov Jiankang Yao Bron Gondwana Resources Requested: Experimental Room Setup (U-Shape and classroom, subject to availability) Flipcharts: please specify number in Special Requests field Special Requests: One flipchart please ---------------------------------------------------------