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

Phillip Hallam-Baker <hallam@gmail.com> Wed, 02 March 2011 13:12 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5665B3A67D8; Wed, 2 Mar 2011 05:12:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.57
X-Spam-Level:
X-Spam-Status: No, score=-3.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aFCigS7VM7MK; Wed, 2 Mar 2011 05:12:01 -0800 (PST)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id CB2023A67EB; Wed, 2 Mar 2011 05:12:00 -0800 (PST)
Received: by bwz13 with SMTP id 13so153494bwz.31 for <multiple recipients>; Wed, 02 Mar 2011 05:13:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=fsqzI//j1KcpmiAISen/GQm0UQLW4T+nKxq/ENyihAA=; b=qhyegXCJMstEsQXeEGDcTA1gWCFqVQ5n42gJ5cOxA6wHDIyvA+YhJiqI5ht19fqWzu pjJys34B8iRu+Cj0+iaPEJLR1mJIC5lzBqep2+02v/FTUo+I90MUnFmiOlsTVJG/K3xi 811qTfi5D3erch/rASnOCnxWWC5Wk3FbCPsT8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=WZwGYjg32R55f/ARc4tY8bINwXts03XFstV5F5N6iN04O+LwenHeoHQRwVDYvEjBnN OSAnrC9UaHpxBz0of7IPToXtJhnsNMYDnSb/y6P+mzNsXVx0qW7aWhcbYA8ZNEn0+8kp MXrN5zltIARaBIO4YLlv6fIX/WLrAG5nY2RIM=
MIME-Version: 1.0
Received: by 10.204.100.82 with SMTP id x18mr7269654bkn.20.1299071585793; Wed, 02 Mar 2011 05:13:05 -0800 (PST)
Received: by 10.204.14.139 with HTTP; Wed, 2 Mar 2011 05:13:05 -0800 (PST)
In-Reply-To: <alpine.BSF.2.00.1102260635310.9639@fledge.watson.org>
References: <AANLkTi=dK8tZibPfR2F+s5rZ8OEsafgHBSk0_Ein-G0w@mail.gmail.com> <alpine.BSF.2.00.1102260635310.9639@fledge.watson.org>
Date: Wed, 2 Mar 2011 08:13:05 -0500
Message-ID: <AANLkTinMxqZqzdpT6ycAPAx4OxztAdv04DAT=hmg2=te@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Samuel Weiler <weiler@watson.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Alexey.Melnikov@isode.com, Barry Leiba <barryleiba@computer.org>, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] SECDIR Review of draft-ietf-morg-multimailbox-search-06
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Mar 2011 13:12:02 -0000

On Sat, Feb 26, 2011 at 6:43 AM, Samuel Weiler <weiler@watson.org>; wrote:
> 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?

I don't see any value there.

If the user is not permitted access to a mailbox, they don't get the
information. There might be value sending the notice to an exception
log, but it does not make much sense to send it to the user's client.
If the user is trying to maliciously access material they should not,
what would be the value in telling them?

The use case that would likely arise for this would be where there are
shared folders (e.g. mailing lists) in some sort of hierarchy.


-- 
Website: http://hallambaker.com/