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

From: Stephan Bosch <[email-masked]>
Date: Sun, 4 Mar 2018 20:31:12 +0100

Hi Ned,

Op 1/9/2018 om 10:44 PM schreef Ned Freed:
>
>>> 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.

I've addressed this in the latest Github version. It is now fully
restricted to the user's personal namespace. I've added some explanation
to the "Security Considerations" section. I've left the option open to
define a new special use flag that does have an application for shared
mailboxes.

Regards,

-- 
Stephan Bosch
Senior Developer 

Phone: +49 2761 75252 00  Fax: +49 2761 75252 30
Email: [email-masked]

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

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

---

From: Ned Freed <[email-masked]>
Date: Sun, 04 Mar 2018 11:33:52 -0800 (PST)

> define a new special use flag that does have an application for shared

WFM.

				Ned

---

From: Stephan Bosch <[email-masked]>
Date: Sun, 4 Mar 2018 20:39:55 +0100

Hi Ned,

Op 1/8/2018 om 5:50 PM schreef Ned Freed:
> 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.

I made a Github issue for this:
https://github.com/ietfextra/tracking/issues/16

This will not be applied in the document before the IETF draft cut-off.

Regards,

-- 
Stephan Bosch
Senior Developer

---

From: Stephan Bosch <[email-masked]>
Date: Sun, 4 Mar 2018 20:41:26 +0100

Op 2/15/2018 om 11:30 PM schreef Stephan Bosch:
> Op 1/17/2018 om 12:14 AM schreef Stephan Bosch:
>> Hi Ned,
>>
> Slowly making progress on this one.
>
> I just gave the point below a fresh look:
>
>>>>> 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.
> Now my question to everyone is: do I need to change anything or is the
> fileinto limitation acceptable?

Opinions anyone?

Regards,

-- 
Stephan Bosch
Senior Developer

---

From: Stan Kalisch <[email-masked]>
Date: Mon, 5 Mar 2018 14:04:56 -0500

>> On Mar 4, 2018, at 2:41 PM, Stephan Bosch <[email-masked]> wrote:

For the sake of argument, the only somewhat plausible scenario I can come up with is one for outgoing messages, where the sender wants messages dynamically assigned to \Sent mailboxes on based on the identities of recipients.  The sender, however, wants the retention of these messages to be ephemeral, so they also mark these mailboxes with the attribute of \Trash.

Stan