Subject: rfc 3348 (CHILDREN extension) support?

From: Matt Selsky <[email-masked]>
Date: Thu, 7 Apr 2005 19:00:15 -0400

Are there any plans to add RFC 3348 support to imapd?  I'm currently 
trying to improve performance in Horde IMP 4.x when accessing a 
UW-IMAP server.  IMP does 'LIST "" #shared/*' and then imapd returns a 
huge list of shared folders, even though the user doesn't have access to 
most of those folders.

C: a01 LIST "" #shared/*
S: * LIST (\NoSelect) "/" #shared/
   * LIST (\NoSelect) "/" #shared/survey
   * LIST (\NoSelect) "/" #shared/exec
   * LIST (\NoSelect) "/" #shared/assembly
   * LIST (\NoSelect) "/" #shared/senate
   * LIST (\NoSelect) "/" #shared/mstu
   * LIST (\NoSelect) "/" #shared/nct
...
   a01 OK LIST completed

Our directory layout looks like this:

$ ls -ld /sharemail/shared/{,miles,admin}
drwxr-xr-x  497 imapshar staff 16384 Apr  7 18:30 /sharemail/shared/
drwxrws---  2 imapshar miles                 4096 Apr  7 15:07 /sharemail/shared/mile/
drwxrws---  2 imapshar admit               4096 May 28  2003 /sharemail/shared/admit/

I'm not in any of these groups so I'll never have access to any 
mailboxes within those directories.  I'd like to have imapd not bother 
returning those mailboxes at all.  From playing with Cyrus imapd, which 
does supprt RFC 3348, they seem to implement this behavior.

Looking at the imapd source, src/osdep/unix/dummy.c, around line 280, 
seems to be the place to modify this behavior.  After checking that an 
object is a directory, I can check that the user actually has 
permissions on the directory.  Am I on the right track?

Cheers,

-- 
Matt
-- 
------------------------------------------------------------------
 For information about this mailing list, and its archives, see: 
 http://www.washington.edu/imap/c-client-list.html
------------------------------------------------------------------

---

From: Mark Crispin <[email-masked]>
Date: Thu, 7 Apr 2005 16:31:38 -0700 (PDT)

On Thu, 7 Apr 2005, Matt Selsky wrote:
> Are there any plans to add RFC 3348 support to imapd?

CHILDREN is being replaced by LISTEXT in the IETF IMAP Extensions Working 
Group.  Among other desirable things, LISTEXT will require the client to 
indicate that it wants children information.

The bad thing about CHILDREN is that a server that does it must always do 
it.  With a UNIX filesystem, that means that you must open the directory 
and examine its contents, which means a lot more work in the case of % 
wildcards.

You seem to be asking not about CHILDREN, but rather about suppressing 
listing of directories which you don't have access to.  If you do that, 
you get into issues about why you can't create a mailbox with the name of 
a list-suppressed mailbox, or what about lower-level names that you can 
access.  For example, suppose you can access /foo/bar/zap but not the 
superior /foo/bar -- do you really want to suppress bar from being listed 
in /foo?

The point is, yes, you can do as you propose, but that isn't what CHILDREN 
is about, and you may create other problems for yourself (and your users).

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

---

From: Matt Selsky <[email-masked]>
Date: Thu, 7 Apr 2005 19:45:55 -0400

Mark,

Thanks for the quick response and the clarification.  The way we 
organized our shared folders a user will never have access to a 
child mailbox is they don't have access to the parent and they would 
never create folders in #shared.

Am I correct in that we'd want to modify dummy_list_work() to implement 
this?

---

From: Mark Crispin <[email-masked]>
Date: Thu, 7 Apr 2005 16:50:16 -0700 (PDT)

> Am I correct in that we'd want to modify dummy_list_work() to implement

To alter list behavior, yes.  Either there or in dummy_listed(), which has 
filters for other reasons.

-- Mark --