Re: [Extra] I-D Action: draft-ietf-extra-sieve-special-use-01.txt
Stephan Bosch <stephan.bosch@dovecot.fi> Tue, 09 January 2018 19:35 UTC
Return-Path: <stephan.bosch@dovecot.fi>
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 <extra@ietfa.amsl.com>; 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 <extra@ietfa.amsl.com>; 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 <extra@ietf.org>; 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 <ned.freed@mrochek.com>
Cc: extra@ietf.org
References: <151533655607.10858.793231788332492256@ietfa.amsl.com> <ce56fc8f-366a-8e1e-2f00-1ed22da28d15@dovecot.fi> <01QNLYA7BLVQ000051@mauve.mrochek.com>
From: Stephan Bosch <stephan.bosch@dovecot.fi>
Message-ID: <d3a952db-a264-9234-dff6-452d38a53d81@dovecot.fi>
Date: Tue, 09 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: <https://mailarchive.ietf.org/arch/msg/extra/-6LCGofcdx6I8NwptRO511mshWQ>
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 <extra.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/extra>, <mailto:extra-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/extra/>
List-Post: <mailto:extra@ietf.org>
List-Help: <mailto:extra-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/extra>, <mailto:extra-request@ietf.org?subject=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 <mailbox: string>] > <special-use-flags: string-list> 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 -------------------------------------------------------------------------------------
- Re: [Extra] I-D Action: draft-ietf-extra-sieve-sp… Ned Freed
- [Extra] I-D Action: draft-ietf-extra-sieve-specia… internet-drafts
- Re: [Extra] I-D Action: draft-ietf-extra-sieve-sp… Stephan Bosch
- Re: [Extra] I-D Action: draft-ietf-extra-sieve-sp… Ned Freed
- Re: [Extra] I-D Action: draft-ietf-extra-sieve-sp… Stephan Bosch
- Re: [Extra] I-D Action: draft-ietf-extra-sieve-sp… Ned Freed
- Re: [Extra] I-D Action: draft-ietf-extra-sieve-sp… Stephan Bosch
- Re: [Extra] I-D Action: draft-ietf-extra-sieve-sp… Stephan Bosch
- Re: [Extra] I-D Action: draft-ietf-extra-sieve-sp… Stephan Bosch
- Re: [Extra] I-D Action: draft-ietf-extra-sieve-sp… Stephan Bosch
- Re: [Extra] I-D Action: draft-ietf-extra-sieve-sp… Ned Freed
- Re: [Extra] I-D Action: draft-ietf-extra-sieve-sp… Stephan Bosch
- Re: [Extra] I-D Action: draft-ietf-extra-sieve-sp… Stephan Bosch
- Re: [Extra] I-D Action: draft-ietf-extra-sieve-sp… Stan Kalisch
- Re: [Extra] I-D Action: draft-ietf-extra-sieve-sp… Stephan Bosch
- Re: [Extra] I-D Action: draft-ietf-extra-sieve-sp… Stephan Bosch
- Re: [Extra] I-D Action: draft-ietf-extra-sieve-sp… Bron Gondwana
- Re: [Extra] I-D Action: draft-ietf-extra-sieve-sp… Stephan Bosch
- Re: [Extra] I-D Action: draft-ietf-extra-sieve-sp… Ned Freed
- Re: [Extra] I-D Action: draft-ietf-extra-sieve-sp… Bron Gondwana
- Re: [Extra] I-D Action: draft-ietf-extra-sieve-sp… Stephan Bosch
- Re: [Extra] I-D Action: draft-ietf-extra-sieve-sp… Bron Gondwana
- [Extra] SPECIAL-USE MAY appear in LIST responses … Ned Freed
- Re: [Extra] SPECIAL-USE MAY appear in LIST respon… Bron Gondwana
- Re: [Extra] I-D Action: draft-ietf-extra-sieve-sp… Chris Newman
- Re: [Extra] I-D Action: draft-ietf-extra-sieve-sp… Ned Freed
- Re: [Extra] I-D Action: draft-ietf-extra-sieve-sp… Chris Newman
- Re: [Extra] I-D Action: draft-ietf-extra-sieve-sp… Stephan Bosch
- Re: [Extra] I-D Action: draft-ietf-extra-sieve-sp… Stephan Bosch