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

Barry Leiba <> Tue, 14 December 2010 02:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2AD0828C124; Mon, 13 Dec 2010 18:04:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.378, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VVExeuU0gEXR; Mon, 13 Dec 2010 18:03:58 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 925AE28C122; Mon, 13 Dec 2010 18:03:58 -0800 (PST)
Received: by iwn40 with SMTP id 40so172318iwn.31 for <multiple recipients>; Mon, 13 Dec 2010 18:05:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=OmQ2JAtgnY/0uadqfOn9tICcvJ5pAa8iXNR2oUu/9Lk=; b=Q7u2LxttNDbraYmC5Z2tS4NRPHPDVq8HPh4O8U1uR0PFhnHORa25edmDqE7zKmZOOQ +BudfseoITe0GIe276LGnM2wf2KamRG7OnDqYV0B4R0Z9OKSTLs9ktzELgG+Ziv/kf6K uOdBn7aK5vjoesU94zf4VjNrrdJZiIIhA2+1g=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=SQKVFZJ2A0dm2YNHjWb06pQqM/s9lNBVLSxkPVY3HepfvLibFmlrK8CeqtUlb4GD8v 6QSILpPRslZ8Rj9BjXdE6nbdQXeZy0c52r9G+8Az+mz+xxP1qzz5wejZCMfoFwPgsYwN AIOO1QBHPDxqbz4czkdfZE36fLItuz5wpg6yc=
MIME-Version: 1.0
Received: by with SMTP id u12mr2648046ibu.109.1292292337569; Mon, 13 Dec 2010 18:05:37 -0800 (PST)
Received: by with HTTP; Mon, 13 Dec 2010 18:05:37 -0800 (PST)
In-Reply-To: <>
References: <>
Date: Mon, 13 Dec 2010 21:05:37 -0500
X-Google-Sender-Auth: ChQ7-_yQbYXjd25_Ur2wvnq1OZw
Message-ID: <>
From: Barry Leiba <>
To: Chris Lonvick <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [secdir] secdir review of draft-ietf-morg-list-specialuse-05
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 14 Dec 2010 02:04:00 -0000

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.
>  :)


> 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

Your concern is reflected in the second paragraph in the Security

   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?