Bug 30707

On Thursday 16 August 2001 11:00 dax@gurulabs.com wrote:
>
> Kmail sees all my folders as "sub-folders" of Inbox and doesn't allow me
> to see the messages in my Inbox.  When using Courier-IMAP.

Yes I also see the folders as sub folders of INBOX I don't consider that as 
a real problem. That is the way Courier IMAP offers them. Even if I would 
consider INBOX as namespace then there wouldn't be an INBOX folder at all 
which is probably also not intended.

But I definetely do see the mails in the INBOX folder using Courier IMAP 
server 1.3.7.
What exactely do you mean with "doesn't allow me to see the messages" ?

> Pine Mutt Mozilla Evolution all work fine with Courier-IMAP.
>
> See the following URL for more info.
> http://www.inter7.com/courierimap/FAQ.html#namespace

That is a nice FAQ. Do you want to know how many bugs I already found in IMAP 
servers? I can send you a long list.

> Basically Kmail's IMAP needs to support RFC 2060 and 2342

KMail's IMAP implementation does follow RFC 2060.
I'm happy to support the standart. IMAP4rev1 leaves already a lot of freedom 
to the servers and many servers have already trouble with that. The 
extensions can wait.

At least I read there in section 5.1.2 that namespaces have to begin with 
"#" what the namespaces of Courier IMAP don't do.

You can enter a namespace a "prefix to folder" in KMail's configuration. 
However I just saw that there is indeed a problem if the namespace is 
called INBOX with all other namespaces it should however work.

Regards
Michael Häckel

I've added Sam Varshavchik author of Courier-IMAP. to the Cc.

My goal is to have my favorite open source packages play nicely together.

Great work and much appreciation on my part to everyone involved.

I've additional comments below.

On Thu 16 Aug 2001 Michael Häckel wrote:

> On Thursday 16 August 2001 11:00 dax@gurulabs.com wrote:
> >
> > Kmail sees all my folders as "sub-folders" of Inbox and doesn't allow me
> > to see the messages in my Inbox.  When using Courier-IMAP.
>
> Yes I also see the folders as sub folders of INBOX I don't consider that as
> a real problem. That is the way Courier IMAP offers them. Even if I would
> consider INBOX as namespace then there wouldn't be an INBOX folder at all
> which is probably also not intended.

Other IMAP clients (pineOutlook Express/OutlookMozillaNetscape) can
consider INBOX as a namespace yet still have an "inbox".  It must be
possible.

> But I definetely do see the mails in the INBOX folder using Courier
> IMAP server 1.3.7. What exactely do you mean with "doesn't allow me to
> see the messages" ?

Nevermind on this I DO see the messages.  I just have a very large inbox
and I was "far away" network wise.  I didn't see any immediate (or even
after a bit) feedback that it was loading.  When I came back 10-15mins
later I saw messages.

> > Pine Mutt Mozilla Evolution all work fine with Courier-IMAP.
> >
> > See the following URL for more info.
> > http://www.inter7.com/courierimap/FAQ.html#namespace
>
> That is a nice FAQ. Do you want to know how many bugs I already found in IMAP
> servers? I can send you a long list.
>
> > Basically Kmail's IMAP needs to support RFC 2060 and 2342
>
> KMail's IMAP implementation does follow RFC 2060. I'm happy to support
> the standart. IMAP4rev1 leaves already a lot of freedom to the servers
> and many servers have already trouble with that. The extensions can
> wait.
>
> At least I read there in section 5.1.2 that namespaces have to begin with
> "#" what the namespaces of Courier IMAP don't do.
>
> You can enter a namespace a "prefix to folder" in KMail's configuration.
> However I just saw that there is indeed a problem if the namespace is
> called INBOX with all other namespaces it should however work.

According to my reading it is in the specs for the IMAP client and server
to auto-negotiate namespaces.  At least that supporting that extension
would be very nice.

Sam can you speak to the claim that the namespaces must begin with '#'
and that courier-imap doesn't do this.

Kind regards
Dax

Dax Kelson writes: 

> Sam can you speak to the claim that the namespaces must begin with '#'
> and that courier-imap doesn't do this.

Well the only thing that #namespaces give you is the ability to use 
different folder hierarchy delimiter characters in different #namespaces.  
I.E. the UW-IMAP server uses "/" as the hierarchy delimiter in the nameless 
namespace and "." in the #news namespace as a convenient means of 
presenting Usenet newsgroups as IMAP folders. 

That's all that #namespaces give you.  Since all I do is plain garden 
variety mail folders I have no need to utilize other namespaces for the 
purpose of using different folder hierarchy delimiter characters. 

One other thing that should be kept in mind is that Courier-IMAP's IMAP 
namespace is nearly identical to the Cyrus IMAP server's IMAP namespace.  
The Cyrus IMAP server also roots private mail folders underneath the "INBOX" 
hierarchy with periods as hierarchy delimiters.  From an IMAP perspective 
Courier-IMAP and Cyrus are fraternal twins if not identical twins.  I'm not 
exactly sure what your namespace-related problem is but I'm certain that 
you'll also see it with the Cyrus server. 

I recommend that mail clients use two separate abstractions: "incoming" mail 
folders and "private" mail folder collections.  Mixing the two together is 
the usual cause for this sort of a confusion.  "incoming" mail folders 
represent system mailboxes where new mail occasionally appears out of thin 
air.  There may be more than one.  "private" mail folders collections 
represents a hierarchy of mailboxes where archived mail is kept.  There may 
be more than one too.  For a filesystem mbox API the former becomes 
/var/spool/mail/$user and the later becomes $HOME/mail/.  For an IMAP 
mailbox API the former becomes the imap INBOX and the latter is defined by 
IMAP NAMESPACE.  IMAP NAMESPACE also defines other kinds of namespaces 
which may also be used in some fashion. 

And you should be able to mingle the two in any meaningful way.  The only 
thing that's special about incoming mail folders is that you check for new 
mail in them every once in a while.  You may choose to add an mbox file 
other than /var/spool/mail/$user as an incoming folder or add some other 
IMAP folder other than INBOX the concept is the same.  You should also be 
able to use a filesystem mbox for an incoming folder and an IMAP hierarchy 
for a mail folder collection. 

That's how I happened to design my unfinished curses mail client.  The 
design works rather well at least even though there's still quite a 
distance to the finish line... 

-- 
Sam

On Saturday 18 August 2001 23:41 Sam Varshavchik wrote:
>
> One other thing that should be kept in mind is that Courier-IMAP's IMAP
> namespace is nearly identical to the Cyrus IMAP server's IMAP namespace.
> The Cyrus IMAP server also roots private mail folders underneath the
> "INBOX" hierarchy with periods as hierarchy delimiters.  From an IMAP
> perspective Courier-IMAP and Cyrus are fraternal twins if not identical

I always though the purpose of IMAP4rev1 standart is to follow the standard 
and not to imitate other implementations...

> twins.  I'm not exactly sure what your namespace-related problem is but
> I'm certain that you'll also see it with the Cyrus server.

The only problem is that all folders are seen as subfolder of the INBOX 
folder instead of on the same hierarchy. I would consider that just a minor 
optical issue.

> I recommend that mail clients use two separate abstractions: "incoming"
> mail folders and "private" mail folder collections.  Mixing the two
> together is the usual cause for this sort of a confusion.  "incoming" mail
> folders represent system mailboxes where new mail occasionally appears out
> of thin air.  There may be more than one.  "private" mail folders
> collections represents a hierarchy of mailboxes where archived mail is
> kept.  There may be more than one too.  For a filesystem mbox API the
> former becomes /var/spool/mail/$user and the later becomes $HOME/mail/. 
> For an IMAP mailbox API the former becomes the imap INBOX and the latter
> is defined by IMAP NAMESPACE.  IMAP NAMESPACE also defines other kinds of
> namespaces which may also be used in some fashion.

I guess the client has to take the namespaces the server offers. If it 
offers more than two that it also has to deal with that.

UW-IMAP for example offers me a whole bunch of namespaces:
. namespace
* NAMESPACE (("" "/")("#mhinbox" NIL)("#mh/" "/")) (("~" "/")) (("#shared/" 
"/")("#ftp/" "/")("#news." ".")("#public/" "/"))
. OK NAMESPACE completed

In KMail it is already possible to manually choose the preferred namespace. 

In further versions it would probably be nice if all available namespaces 
would be offered to the user and he can choose in what namespaces he is 
interested in.

Regards
Michael Häckel

*** Bug 55565 has been marked as a duplicate of this bug. ***

*** Bug 41004 has been marked as a duplicate of this bug. ***

*** Bug 74272 has been marked as a duplicate of this bug. ***

*** Bug 94189 has been marked as a duplicate of this bug. ***

SVN commit 412144 by burghard:

Add namespace support to kmail.
Make sure that you also update your imap4 kioslave.
BUGS:30707


 M  +252 -96   trunk/KDE/kdepim/kmail/accountdialog.cpp  
 M  +41 -5     trunk/KDE/kdepim/kmail/accountdialog.h  
 M  +8 -2      trunk/KDE/kdepim/kmail/cachedimapjob.cpp  
 M  +14 -11    trunk/KDE/kdepim/kmail/configuredialog.cpp  
 M  +297 -64   trunk/KDE/kdepim/kmail/imapaccountbase.cpp  
 M  +111 -15   trunk/KDE/kdepim/kmail/imapaccountbase.h  
 M  +17 -5     trunk/KDE/kdepim/kmail/kmacctcachedimap.cpp  
 M  +0 -3      trunk/KDE/kdepim/kmail/kmacctcachedimap.h  
 M  +3 -8      trunk/KDE/kdepim/kmail/kmacctimap.cpp  
 M  +0 -3      trunk/KDE/kdepim/kmail/kmacctimap.h  
 M  +237 -70   trunk/KDE/kdepim/kmail/kmfoldercachedimap.cpp  
 M  +38 -7     trunk/KDE/kdepim/kmail/kmfoldercachedimap.h  
 M  +345 -147  trunk/KDE/kdepim/kmail/kmfolderimap.cpp  
 M  +39 -11    trunk/KDE/kdepim/kmail/kmfolderimap.h  
 M  +20 -9     trunk/KDE/kdepim/kmail/kmfoldertree.cpp  
 M  +1 -1      trunk/KDE/kdepim/kmail/kmkernel.h  
 M  +2 -3      trunk/KDE/kdepim/kmail/kmreaderwin.cpp  
 M  +21 -34    trunk/KDE/kdepim/kmail/listjob.cpp  
 M  +15 -9     trunk/KDE/kdepim/kmail/listjob.h  
 M  +67 -6     trunk/KDE/kdepim/kmail/newfolderdialog.cpp  
 M  +3 -0      trunk/KDE/kdepim/kmail/newfolderdialog.h  
 M  +6 -3      trunk/KDE/kdepim/kmail/renamejob.cpp  
 M  +95 -73    trunk/KDE/kdepim/kmail/subscriptiondialog.cpp  
 M  +21 -1     trunk/KDE/kdepim/kmail/subscriptiondialog.h  

On Tuesday 10 May 2005 22:40, Carsten Burghardt wrote:

> ------- SVN commit 412144 by burghard:
>
> Add namespace support to kmail.
> Make sure that you also update your imap4 kioslave.
> BUGS:30707
>


With dimap and namespace for shared folders: "". I the shared folders are 
deleted locally, then are downloaded again from server. The patch resolves 
this.

Regards


Created an attachment (id=11006)
namespace_sharedfolders.diff

On Tuesday 10 May 2005 22:40, Carsten Burghardt wrote:
> Add namespace support to kmail.
> Make sure that you also update your imap4 kioslave.
> BUGS:30707


I just found another bug. 

Normally I made a imap accout for the user cyrus. BTW I can administer the 
folders, persmissions etc.

	With namespaces patch, I can't see the folders in the server. The debug 
output say:
 kmail: slotListNamespaces
kmail: 0 namespaces fetched
kmail: slotSaveNamespaces cyrus

And no folders are listed.


Regards

I need the debug output from the imap4 kioslave (.xsession-errors or something 
or direct the output of 7116 to a file).