Re: [secdir] secdir review of draft-ietf-morg-list-specialuse-05

[Barry Leiba <[e-mail]>]

Hi, Chris, and thanks for the review.

> I am not altogether familiar with the placement of IMAP mailboxes to have a
> solid grasp on the subject.  Please take my comments with a grain of salt.
>  :)

Noted.

> You mention at the end of Section 2 that users may configure shared
> mailboxes.  Does that imply that mailboxes are not normally shared, and
> would then mean that another user would not have any access to any of the
> mailboxes identified by IMAP unless they were specifically given a common,
> shared mailbox?
>
> An example of my concern is that the \Junk mailbox may be configured to be
> common to all the users.  In some cases, a legitimate piece of mail may be
> incorrectly marked as spam by a filter and then placed into the Junk bin. If
> that were to happen, anyone who had access to that mailbox would be able to
> see the contents of that email.

Personal IMAP mailboxes are normally private.  Users may also have
access to public mailboxes (say, archives of mailing lists, or netnews
collections), to group mailboxes (our department's "to-do" folder), or
to personal mailboxes of others that have been explicitly shared.
These are usually presented in a separate namespace from the personal
mailboxes.

Your concern is reflected in the second paragraph in the Security
Considerations:

   CREATE command "USE" parameter: In some server implementations, some
   special uses may imply automatic action by the server.  For example,
   creation of a "\Junk" mailbox might cause the server to start placing
   messages that have been evaluated as spam into the mailbox.
   Implementors SHOULD consider the consequences of allowing a user (or
   client program) to designate the target of such automatic action.

I can make this more explicit, if you think that's important, by
adding another paragraph:

   Example: If a user is allowed to give the "\Junk" attribute to a
shared mailbox,
   legitimate mail that's misclassified as junk (false positives) will
be put into that
   shared mailbox, exposing the user's private mail to others.  The server might
   warn a user of that possibility, or might refuse to allow the
specification to be
   made on a shared mailbox.  (Note that this problem exists independent of this
   specification, if the server allows a user to share a mailbox
that's already in use
   for such a function.)

Does that help, do you think?

Barry