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

[Barry Leiba <[e-mail]>]

> 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?

Perhaps, but it seemed to be the consensus of the client folks that it
didn't matter, and it would be more useful to them to have the command
succeed as long as there were some "valid" mailboxes in the list.  We
could allow the command to succeed and return results for the good
mailboxes, and untagged error responses to indicate the bad ones.  But
we'd only want that for ones explicitly specified, not those that are
implicitly included.

For example, using the command from the example:

C: tag1 ESEARCH IN (mailboxes "folder1" subtree "folder2") unseen

If "folder1" or "folder2" doesn't exist (or the user has no access),
notification of that might be appropriate.  But if, say, "folder2/aaa"
and "folder2/bbb" both exist and the user has access to the former and
not the latter, sending an error for "folder2/bbb" would give away
information.  We wouldn't want this to become a way to probe for
mailbox names.

Apart from that, we'd have to define a new way to indicate the
situation, perhaps with a further extension to the ESEARCH response.
We have a response code "NONEXISTENT" that we can use for single
mailboxes, putting it on a tagged or untagged "NO":

C: tag1 RENAME folder1 folderX
S: tag1 NO [NONEXISTENT] failed because folder1 doesn't exist

But if you get this:
C: tag1 ESEARCH IN (mailboxes "folder1" subtree "folder2") unseen
S: * NO [NONEXISTENT] failed because folder1 doesn't exist
S: * ESEARCH (TAG "tag1" MAILBOX "folder2" UIDVALIDITY 1) UID ALL
   4001,4003,4005,4007,4009
S: tag1 OK done

...then the client doesn't know which mailbox(es) failed, because the
text after the response code isn't machine parsable.  We'd have to
extend the ESEARCH response for it, somewhat like this:

S: * ESEARCH [NONEXISTENT] (TAG "tag1" MAILBOX "folder1")

We could certainly do that, but given that the only ways this can
happen is through a serious client bug or another client's deleting or
renaming "folder1" out from under this client, that the latter doesn't
actually happen very often, that client developers have already told
us that they don't care, and that clients that get it wrong may expose
information about inaccessible mailboxes... it's best to leave it as
it is.

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

Apart from LIST, this is the first such IMAP command.  I'd be happy to
repeat or refer to some of the text from section 2 in the security
considerations.

Barry