Re: [MORG] I-D Action:draft-ietf-morg-multimailbox-search-04.txt

Timo Sirainen <> Tue, 16 November 2010 17:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 73E533A6CCA for <>; Tue, 16 Nov 2010 09:17:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.524
X-Spam-Status: No, score=-106.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6F8Lehr-TC6E for <>; Tue, 16 Nov 2010 09:17:08 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 13F0B3A6DC5 for <>; Tue, 16 Nov 2010 09:17:07 -0800 (PST)
Received: from [] (unknown []) by (Postfix) with ESMTP id D8EBDFA8B3B; Tue, 16 Nov 2010 19:17:49 +0200 (EET)
From: Timo Sirainen <>
To: Barry Leiba <>
In-Reply-To: <>
References: <20101109021529.26008.63016.idtracker@localhost> <>
Content-Type: text/plain; charset="UTF-8"
Date: Tue, 16 Nov 2010 17:17:48 +0000
Message-ID: <>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3
Content-Transfer-Encoding: 7bit
Subject: Re: [MORG] I-D Action:draft-ietf-morg-multimailbox-search-04.txt
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Messaging Organization <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 16 Nov 2010 17:17:09 -0000

On Tue, 2010-11-09 at 16:16 +0800, Barry Leiba wrote:
> I have posted a new version of multimailbox-search.  I believe this
> version takes care of all comments so far, and that this version is
> now ready for working group last call.  Other chairs, if you agree,
> please issue a working group last call on this version.

What about the "open issues" section?

Some simple ways to get rid of them:

> Interaction with IMAP Contexts [RFC5267] needs to be defined.

a) Disallow them
b) Allow them when mailboxes include "selected", and make it apply only
to whichever mailbox is selected at the time.

> There's a suggestion to add an EXCLUDE clause (with a nested search
>    criteria).  For example, one might want to search "personal" but
>    exclude "mailboxes (Trash Spam)".

A server might be able to do this internally as well, similar to how
SPECIAL-USE's \Flagged mailbox works. EXCLUDE itself is too complex I
think, but maybe something like "personal-useful" which is like
"personal", but server is allowed to drop some "unwanted" mailboxes out
of it.