Re: [Extra] I-D Action: draft-ietf-extra-sieve-special-use-01.txt

Ned Freed <ned.freed@mrochek.com> Tue, 09 January 2018 22:24 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 26C2912422F for <extra@ietfa.amsl.com>; 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 <extra@ietfa.amsl.com>; 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 <extra@ietf.org>; 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 <ned.freed@mrochek.com>, extra@ietf.org
Message-id: <01QNNBB3GEW0000051@mauve.mrochek.com>
Date: Tue, 09 Jan 2018 13:44:08 -0800
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Tue, 09 Jan 2018 20:35:13 +0100" <d3a952db-a264-9234-dff6-452d38a53d81@dovecot.fi>
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>
To: Stephan Bosch <stephan.bosch@dovecot.fi>
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/-GEO0t569-Rt-bXfegcBjOwr9G8>
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 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