(*** This bug was imported into bugs.kde.org ***) Package: kmail Version: 1.3.1 (using KDE 2.2.0 ) Severity: normal Installed from: Red Hat Linux 7.1.93 Compiler: gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-96) OS: Linux (i686) release 2.4.3-12 OS/Compiler notes: 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. 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 Basically Kmail's IMAP needs to support RFC 2060 and 2342 (Submitted via bugs.kde.org) (Called from KBugReport dialog)
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).