Re: [secdir] SECDIR Review of draft-ietf-morg-multimailbox-search-06

Samuel Weiler <> Sat, 26 February 2011 11:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6BDC13A681C; Sat, 26 Feb 2011 03:42:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Bi2kKO0Xlupp; Sat, 26 Feb 2011 03:42:34 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 0E8C23A67D4; Sat, 26 Feb 2011 03:42:33 -0800 (PST)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id p1QBhQKv000404; Sat, 26 Feb 2011 06:43:26 -0500 (EST) (envelope-from
Received: from localhost (weiler@localhost) by (8.14.4/8.14.4/Submit) with ESMTP id p1QBhPqW000397; Sat, 26 Feb 2011 06:43:26 -0500 (EST) (envelope-from
X-Authentication-Warning: weiler owned process doing -bs
Date: Sat, 26 Feb 2011 06:43:25 -0500 (EST)
From: Samuel Weiler <>
To: Barry Leiba <>,
In-Reply-To: <>
Message-ID: <>
References: <>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 ( []); Sat, 26 Feb 2011 06:43:26 -0500 (EST)
Subject: Re: [secdir] SECDIR Review of draft-ietf-morg-multimailbox-search-06
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: Sat, 26 Feb 2011 11:42:35 -0000

On Tue, 22 Feb 2011, Phillip Hallam-Baker wrote:

> This document makes a minor adjustment to the search mechanism of 
> imap, allowing searches to be made slightly more efficiently.

If the user specifies some mailbox(es) which she doesn't have access 
rights to AND some mailbox(es) which she can access, the doc says to 
IGNORE the ones she can't access.  Wouldn't it be more useful to send 
an error for those mailboxes rather than silently fail?

Also, the security considerations says:

    Implementations MUST, of course, apply access controls appropriately,
    limiting a user's access to ESEARCH in the same way its access is
    limited for any other IMAP commands.  This extension has no data-
    access risks beyond what may be there in the unextended IMAP

Are there any other IMAP commands that access multiple mailboxes at 
once?  If not, if might be worth repeating some of the text in section 
2, just to call out the new case that must be checked.