Re: IMAP-problems

[Peter Bloomfield <PeterBloomfield bellsouth net>]

On 04/18/2003, Darko Obradovic wrote:
[ snip ]
> I don't know what the correct behaviour is according to the RFCs, but,
> forgive me I'm mentioning Sylpheed all the time, it's the only
> alternative I have and use for the moment, does all that as I would
> expect it in my situation: including INBOX (this is not an option
> anywhere, hard-coded default) without any childs. They must have some
> reasons for that I guess.
> 
> But Courier-IMAP, although definitely IMAP4rev1-compliant according to
> some serious sources, seems to be a little strange, check out this one
> for example:
> http://www.mail-archive.com/lists-bincimap@infeline.org/msg00244.html

I glanced at this thread, and at the RFC that describes the NAMESPACE 
extension ( http://www.rfc-editor.org/rfc/rfc2342.txt ).  The 
discussion in the thread seems to be reading far more into a namespace 
than RFC 2342 seems to state!  All I could get from RFC 2342 is that 
having a namespace "xyz" is an indication that the server may have some 
folders with pathnames beginning "xyz", and that it might reveal them 
in its response to "list xyz%", "lsub xyz*", etc.  However, in the 
thread there seems to be an understanding that the prefix can be 
inferred:

   INBOX. is the namespace prefix, and is equivalent to "".

I don't get that at all!

BTW, it may be relevant that libmutt internally mangles NAMESPACE 
responses--see libmutt/imap/browse.c:

               /* Cyrus doesn't append the delimiter to the namespace,
                * but UW-IMAP does. We'll strip it here and add it back
                * as if it were a normal directory, from the browser */
               if (n && (ns[n-1] == delim))
                 ns[--n] = '\0';

Courier also includes the delimiter as the last character of the 
namespace (which imho is a more accurate description of this behavior 
than `append'), and this piece of code strips it. It probably doesn't 
matter, since the delimiter is reinserted in LIST and LSUB requests, 
but you never know when something like that will bite!

Peter