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

[Stephan Bosch <[e-mail]>]

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: [phone]  Fax: [phone]
Email: [e-mail]


-------------------------------------------------------------------------------------
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

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