Re: [Extra] I-D Action: draft-ietf-extra-sieve-special-use-01.txt
Stephan Bosch <stephan.bosch@dovecot.fi> Tue, 16 January 2018 23:14 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 77A9912EBA1 for <extra@ietfa.amsl.com>; 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 <extra@ietfa.amsl.com>; 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 <extra@ietf.org>; 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 <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> <d3a952db-a264-9234-dff6-452d38a53d81@dovecot.fi> <01QNNBB3GEW0000051@mauve.mrochek.com>
From: Stephan Bosch <stephan.bosch@dovecot.fi>
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: <https://mailarchive.ietf.org/arch/msg/extra/qpjZ9wUrkL8O2TS5Xk-gUyingL4>
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, 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 -------------------------------------------------------------------------------------
- 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