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

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