Re: [Extra] I-D Action: draft-ietf-extra-sieve-special-use-01.txt
Ned Freed <ned.freed@mrochek.com> Mon, 08 January 2018 23:00 UTC
Return-Path: <ned.freed@mrochek.com>
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 <extra@ietfa.amsl.com>; 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 <extra@ietfa.amsl.com>; 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 <extra@ietf.org>; 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
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Sun, 07 Jan 2018 15:57:23 +0100" <ce56fc8f-366a-8e1e-2f00-1ed22da28d15@dovecot.fi>
References: <151533655607.10858.793231788332492256@ietfa.amsl.com> <ce56fc8f-366a-8e1e-2f00-1ed22da28d15@dovecot.fi>
To: Stephan Bosch <stephan.bosch@dovecot.fi>
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/-56iFCZ1Vn-BWUSt-YFxzVkT30w>
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: 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 <mailbox: string>] <special-use-flags: string-list> 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
- 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