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

[Ned Freed <[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.

WFM.

				Ned