Open Bug 80858 Opened 24 years ago Updated 3 years ago

Use IMAP namespace response for auto hiding of namespace folder at folder pane

Categories

(MailNews Core :: Networking: IMAP, enhancement)

Product:
MailNews Core
Component:
Networking: IMAP
Type:
enhancement

Tracking

(blocking-thunderbird5.0 -)

Tracking Flags:
Tracking Status
blocking-thunderbird5.0 --- -

People

(Reporter: mozilla, Unassigned)

References

(Blocks 4 open bugs,
URL
)

Details

(Keywords: imap-interop)

Attachments

(4 files)

Courier Folder Hierachy
5.31 KB, image/gif
Details
Special Folders Preferences
17.91 KB, image/gif
Details
Evolution folder view of Courier IMAP tree
59.59 KB, image/png
Details
Mozilla 1.3 view of same folder Courier IMAP tree
58.52 KB, image/png
Details
When using Courier IMAP, the folder hierarchy all show up under the INBOX, and no folders can be created at the 'root'. It might be related to the inability to specify INBOX. as the mailbox prefix. It also might be related to the bug with Courier-IMAP where you cannot empty the TRASH when 'move to trash' is selected as the disposal method.
triaging to naving. =)
Assignee: mscott → naving
Keywords: interop
QA Contact: esther → huang
Marking nEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I thought that empty trash on courier was fixed. Can we get an acct on a courier IMAP to test this ?
Viewing & emptying the trash works for me with a cvs build from yesterday. Using courier-imap 1.3.2 on the server side.
This behavior is true with 4x also. I am not sure if this is a bug. please verify with tomorrow's nightly builds.
Courier-imap's faq has this listed as a client side bug although it has always seemed like a courier-imap feature. http://inter7.com/courierimap/FAQ.html#namespace
Just upgraded from 0.9 to 0.9.1, and it looks like the deleting folders problem (My deleted folders are finally deleted YEA!)... although all folders are still rooted under INBOX (boo). Entering INBOX. (or "INBOX.") as the imap server directory always adds a "/" to the end of it... (i.e. INBOX./ or "INBOX."/)
> although all folders are still rooted under INBOX (boo). This also happens in 4x and the server does not allow create foo. It only allows create INBOX.foo.
Does Mozilla support namespaces per http://www.rfc-editor.org/rfc/rfc2342.txt ?
Ccing David & Scott.
Seems the bug is still there ;-( Mozilla 0.9.7 Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.7) Gecko/20011221 and it's still a pain to work with courier-imapd
It seems to be fixed in my installation. Indeed, it seems to have been running correectly for a while now (since 0.9.5 at least). I currently run: - Moz 0.9.7 on Windows and on Linux (from tarred binary release) - Courier-IMAP version 1.3.10 over SSL - Works properly when compiled "clean" - Works properly when compiled "--with-workarounds-for-client-bugs" or whatever the flag is. I would humbly suggest its a configuration issue in most of the cases. Just letting the server override namespaces (the default config) sorts it out.
I'll try rebuilding Courier and see what I get. Question: If it truly is a 'workaround for imap client bug', shouldn't the bug be fixed, rather than rely on a server to compensate for the 'imap client bug'?
I just upgraded to courier-imap 1.4.1 (from 1.3.2) "clean" and the bug is still there. My Mozilla imap acct settings have always been set to "allow server override namespaces". Outside of increasing the number of daemons, I haven't changed any of the imapd options.
Here's a silly question: is everyone using Courier-imap + qmail or courier-imap + courier ?
Sure. It works (with maildirs of course).
Courier IMAP + Sendmail
*** Bug 107646 has been marked as a duplicate of this bug. ***
I too have been having problems with Mozilla 0.9.8 (2002020406) and courier-imap. Specifically, after setting up the IMAP account, sending a message fails because Mozilla can't save a copy to 'Sent' on the IMAP server. I suspect it should be trying to save to 'INBOX.Sent'? I'm using a recent courier + qmail + maildirs. According to the Courier FAQ this is because Mozilla doesn't support the IMAP NAMESPACE extension(s) properly.
Two things: what is your fcc pref set to? It should look something like: user_pref("mail.identity.id13.fcc_folder", "imap://user@host/Sent"); or Inbox.Sent And if you generate an imap protocol log of this failed append, could you attach it or send it to me? http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap
To answer Sam Jonhson's problem, this was working properly until approx 0.9.4 or 0.9.5. At that stage other CourierIMAP interop blocker bugs where fixed, and this functionality was broken. The workaround is to explicitly choose "Other" and in the drop-down menu navigate down to the proper folder, which is usually "INBOX.Sent" . This affects "Sent" , "Drafts" and "Templates" folders. And however easy the workaround, it is a serious annoyance to less savvy users, and to tech support teams.
Keywords: mail6, mozilla1.0
I can confirm this on Moz 0.9.9. Running Courier IMAP 1.4.3/qmail I don't believe I compiled with the --enable-workarounds-for-imap-client-bugs option. Given a bit of ambition I'll see if this fixes the problem. I also tried (as per some Netscape help doc) changing the "server_sub_directory" pref in prefs.js to "INBOX." This properly roots mail folders (yay) but they don't work then (boo). Requests to view the folder contents simply hang.
Compiling courier with the --enable-workarounds-for-imap-client-bugs option does not fix the problem for me.
Could 80858 and 60360 be related? Can we expand 80858 to for all OS? I experience 80858 on win and lin.
I created a new profile, and set everything up the only way that allows Mozilla to use the sent items folder. The mail.identity.id13.fcc_folder string is: user_pref("mail.identity.id1.fcc_folder", "imap://dave@192.168.1.21/INBOX/Sent"); By default, the IMAP server folder gets set to "INBOX."/ I've tried switching it to just INBOX. , but when mozilla goes to save a message to the sent items folder, it can't find the folder. I'm still trying to figure how how to do an IMAP protocol trace w/ Courier, so bear with me...
I have been VERY SUCCESSFUL running Moz 0.9.5 and higher with Courier IMAP with many clients. I have 2 installs, one with --enable-workarounds-for-client-bugs and one without. The only difference I ever had was that moz 0.9.6 could not an attachmen from a particular email when runnning against the server compiled with workarounds. That problem is gone now, or at least I could not get it to reproduce reliably. So --enable-wokrarounds-for-client-bugs does not make any difference for my moz users. Regarding ROOTing folders to the "server root", there are two issues: - Display: the folders seem to hang from inbox, not from the server-account. This replicates what NetscapeCommunicator 4.7x does. Many other IMAP clients share this behaviour. It is just a visual representation, and I don't think it is a big problem -- though it might be strictly a bug. - Behaviour: Currently, Sent/Drafts/Templates folders don't auto-set. *** I believe this to be a very real bug... this was working properly in the early 0.9.x series, but other things were broken ***. To get the folders to work properly, you have to follow the steps I outlines in an earlier post (http://bugzilla.mozilla.org/show_bug.cgi?id=80858#c21). Following those instructions you end up having the following settings: user_pref("mail.identity.id2.fcc_folder", "imap://martin%40nz.scim.net@nz.scim.net/INBOX/Sent"); but this will only work if you have the following setting: user_pref("mail.imap.server.nz.scim.net.namespace.personal", "\"INBOX.\""); But this setting auto-sets itself if you allow the server to override your namespace. . Basically, I think the real problem is when you "create a new account", sent/drafts/templates does not auto-set properly and needs manual correction. It would be nice for Sent/Drafts/Templates to know that they have to observe the personal namespace setting.
Additionally, I can offer test accounts to the moz team on two different servers for debugging if need be.
I believe martin is right that the basic problem is the default location for special folders isn't respecting the namespace setting. Rooting off the inbox is the natural thing for clients to do since the server is basically telling us that all folders are sub-folders of the Inbox, since their names are all Inbox.xxx and the hierarchy delimiter is '.'
But, if you explicitly set the IMAP server directory to be "INBOX.", all subfolders should be rooted under the top, not inbox. The client should 'prepend' all of it's subfolder access with the value of the 'root folder'. Likewise, it should display them in the folder tree such that the root folder path wasn't there. There is no point to allowing them to specifying the root folder path if you're going to display the tree like it wasn't defined. Once the tree is displayed and accessed properly using the IMAP Server directory, the Sent/Drafts/templates folder selection process, as it is implemented, is perfect. I believe that Outlook Express 5 behaves correctly. Once I specify the root folder of "INBOX.", all folders directly under 'INBOX' show up as top level folders, and the Sent and Drafts folders specifications workd properly.
>There is no point to allowing them to specifying the root folder path if you're >going to display the tree like it wasn't defined. It tells us that all folders will be sub-folders of the inbox, so there is a point.
I'm not sure that is true. My current settings include NOTHING in the IMAP Server Folder, and everything works perfectly. The only thing 'special' I had to do was in the copies and folders, I had to select the path to the folder. If you only use the server folder for the copies and folders, then in the tree, it looks like 'INBOX/Sent', but in the settings, it looks like '/Sent'. Won't that be confusing to people? It seems like it would to me. Why not use it in the display of the tree as well as the selection of the folders? OH, and Courier isn't the only IMAP server that has this problem. Mirapoint Messaging Servers also use the INBOX. folder heirarchy, and they are subject to this as well..
The reason you don't have to set up anything special is that the server tells us this with the NAMESPACE response - Courier IMAP tells us the personal folder namespace is "INBOX." The 4.0x versions of Netscape didn't support NAMESPACEs, 4.5+ did. I don't know if Courier has always supported NAMESPACE or not, so it's conceivable that this would also be required for very old versions of the Courier server. If I could wave a magic wand and make Mozilla display all the sub-folders of the INBOX as top level folders, I would. I agree that it's the right thing to do. However, it's not trivial, and the potential for regressions is high. I first want to make sure that the special folders are handled correctly. These are separate issues, in the sense that they're different pieces of code.
Assignee: naving → bienvenu
Could someone add a comment that describes the what the proposed source of the problem is and the solution? Is it a Moz bug (if so, whats the coming workaround)? A Courier bug? Just bad chemistry between the two applications?
I'm confused. If we're discussing how Mozilla can/should use the namespace in the display of the folder tree, then it still seems to me that the purpose of the namespace feature is to allow an IMAP client to display the folders such that the special folder INBOX can be displayed at the same level as the top set of non-special folders. I can't see any other reason to specify that prefix. It'd be similar to using '<ail/' with the UofW IMAP server (which used to work in NS 4.5+, although I haven't tried it with mozilla). If we're discussing what is feasible to fix for 1.0, then with out a doubt, the project leaders are the ones to make that call. If there's too great a risk at this stage in the development, that is your call. This is definately not a job stopper. I've been using it as is since I reported the bug 11 months ago. I don't expect 'magic'. If there is any confusion as to exactly what this bug is referring to, then I am more than happy to clarify it: it is with regard to the folder tree, and how it's displayed. It appears to be ignoring the namespace definition. A side effect of that is that in the Copies and Folders setting(s), you cannot use the 'Sent on <servername> pic. You have to use the "Other" pick and navigate to Server->INBOX->Sent. Lastly, move to trash and empty trash are no longer an issue.
Attached image Courier Folder Hierachy —
Shows Mozilla displaying all folders under the 'Inbox' folder, rather than alongside it as expected.
Shows special folders are under Inbox rather than alongside it. I have not tried 'choose this folder' but suspect it will not work, and should instead refer to 'Inbox', which is listed separately.
I find the special folders handling issue very annoying, both as an end user and as technical support for other end users. I get caught by it every time I set up Mozilla on a new machine (once or twice a week) and regularly have to explain to users that after the error message appears the progress bar won't go away, and that they will have to copy the text of their message(s) to new message(s) to resend them since the send button is no longer responsive. I've also been assuring them that it is a known bug in pre-release software which will be resolved by the time it ships. We're now RC2 so I'm not so sure this is going to happen. The image 'Courier Folder Hierachy' shows all folders appearing under 'Inbox', despite the NAMESPACE setting (which I understand is meant to resolve this). In reality this doesn't concern me a great deal since the workaround is obvious and doesn't cause that much confusion. The second, 'Special Folders Preferences' shows Mozilla displaying all folders underneath 'Inbox', as above. Here the problem is more serious, resulting in the behaviour described above. I imagine 'Inbox' should map to 'choose this folder' and not be displayed at all, with the rest of the folders being displayed at this (first) level rather than the next level which is not displayed. I also imagine that this is not a trivial fix and is unlikely to make it into 1.0. After manually setting one of the second level folders as a special folder everything works as expected and the relevant folders are displayed with different icons as per 'Courier Folder Hierachy'. This is stored in prefs.js as: user_pref("mail.identity.id1.fcc_folder", "imap://samj@imap.aos.net.au/INBOX/Sent"); I suspect that the default for this setting is simply 'Sent' and that a simple, if temporary workaround may be to prepend the 'NAMESPACE' setting at this stage rather than forcing users to do it themselves. The advantage of this approach is that NAMESPACE information is not embedded in the config files and could potentially be changed if required. I wonder whether namespace information should ever appear in settings like this and I suspect it should not. Remember this is something we may not be able to change once the users come in droves after a 1.0 release. At the very least failures should be better handled. Users should be able to change the settings and send again without having to copy the mail over to a new message. There's more people on the CC list for this bug than there are votes - if this bug affects you why not vote for it as per http://bugzilla.mozilla.org/votehelp.html
QA Contact: huang → meehansqa
CC'ing to myself
The problem with all folders appearing as a subfolder of INBOX is due to bug 105385 . The problem with special folders not working correctly without manually specifying them is due to bug 27002 . Bug 105385 is caused by Mozilla incorrectly assuming that the server folder always ends with '/', and adding it if it's not there. It should instead use the delimiter found from a LIST command, or just not add any delimiter not provided by the user. These bugs do not just impact Courier, but any IMAP server that does not use '/' as a delimiter, or uses a personal namespace other than "". Bug 27002 is caused by Mozilla failing to prepend the Personal Namespace to special folders. Instead it prepends the Server Folder Path, which due to bug 105385 can not be correctly specified in the UI. I have tested removing from mailnews/imap/src/nsImapIncomingServer.cpp the relevent lines of nsImapIncomingServer::SetServerDirectory to stop adding a '/', and can confirm that both of these bugs are resolved by doing this. An alternative workaround is to simply add a user.js line to provide the correct inbox path without the '/'. The larger issue here is that Mozilla has both a "Server Folder Path", which is not part of any RFC, as well as IMAP namespace support, which is covered by RFC 2342. Removing the server folder path entirely and replacing all functions that query it with a query for the personal namespace will clear up a lot of the resulting confusion. The server folder path was originally developed in bug 20878 , which did not discuss the use of the personal folder path as a potential solution.
If I modify my prefs.js to force the personal namespace to end in a dot, like http://www.hmetzger.de/net6e.html#40 explains how, Mozilla will correctly show folders under the root. The only problem is Mozilla does not prepend the value of the "IMAP Server Directory" option to all requests (verified server side with strace), so every request to a folder that isn't a subfolder of the Inbox results in the error "The current command did not succeed. The mail server responded: Invalid mailbox." So Mozilla appending the trailing slash is not the only problem.
I only have 2 days experience of the source, but my opinion is that bug #105385 is NOT a bug. The reason: Internally in the source, Mozilla keeps track of directories and the directory delimiter is always a /. It is the task of nsImapUrl to decode the directory and convert the /es to the proper delimiters, and this is working. We can see this because we are able to get mail. Also, in everything I have debugged so far, I have always seen the proper delimiter being used. Please note though that while I am an experienced software engineer, I am totally new to Mozilla Source and not an IMAP expert either, but I am growing more of one every hour. My guess is, that the f**&up happens somewhere during the folder discovery. nsImapUrl::AddOnlineDirectoryIfNecessary or a function this function calls and is the function I'll be debugging tomorrow evening European time. This is where the result of the list command is processed and matched against the server directory and added to the list of folders if necessary.
courier-imap-1.4.6.20020529 [without --enable-workarounds-for-imap-client-bugs], Mozilla 2002061808. Same problem here. After setting the profile up sending mail results in an error [can't find sent directory [which is actually placed under INBOX as INBOX.send]]. Tried editing the js.prefs changing the server_sub_directory from "\"INBOX.\"/" to "INBOX.". Helped display it properly, but I can not see the contents now ["invalid mailbox"]. Just compiling the imapd with --*workarounds* and will test weather it helps. As already said in http://bugzilla.mozilla.org/show_bug.cgi?id=80858#c38 the workaround [redefine sent, trash and drafts from gui] is really annoying for both users and support people. Hope you find a way to fix it soon =)
Well first of all, there are two bugs: 1) Mozilla always appends a / after you've entered a new imap server directory, so you can't work around the other mozilla bug => 2) Mozilla seems to retrieve the namespaces from the courier imap server, but it doesn't use them: That's why you have to manually edit prefs.js(because of bug #1) to get it working. I hope these bugs will be corrected soon
I believe that first problem has already been fixed.
Nope, i justed tested it with 1.1a and it's still there.
there's a bug filed on it with a patch from several weeks ago - I thought the patch had been checked in, but perhaps it hasn't.
bug 105385 is the bug I was refering to, and the patch there was checked into the trunk on 6/19/02 - I don't know if 1.1a is on a branch or not, or if the fix in bug 105385 didn't work, or is fixing a different problem (though it seems like the same problem to me)
Matthias Liertzer, The patch for bug 105385 has been checked in on June 19, 2002. And mozilla 1.1a is released on June 5 or so. So you saw your two questions have not been fixed. Would you please try the trunk to see if they still exist? Thx. Henry
Bug 105385 is really the same as your two questions.
*** Bug 155900 has been marked as a duplicate of this bug. ***
Latest nightly still doesn't automatically assume the Personal namespace to be the root, though, unlike 1.0, I can use "INBOX" as an "IMAP server directory" to place all those folders in the top of the hierarchy. What I'd like to see is Personal folders appearing in the top of the hierarchy, while Shared folders could be either in a "Shared" subfolder or separated from the personal folders with a horizontal bar ala: ------ <small>shared</small> ---------- (and maybe those shared folders should have a different icon, one with an attached emblem which symbolizes sharing, like a small emblem of two siluets -- just throwing around ideas). One thing is sure -- nobody wants to dive into a 2nd hierarchy to see his personal folders.
Blocks: 160644
Anybody make a change, recently, in this code area or one that might have a side-effect here? I just downloaded 8/6/2002 for Linux. "Copying mail to sent folder" now fails. It worked around 7/20/2002. This timeframe is the last time I downloaded a nighly build. "copying to sent folder" used to work. I had been editing the "copies & folders" to specifically select the "Sent" folder under the inbox.
OS: Linux → All
Yes, Henry has been making changes in this area. You might want to attach a protocol log: http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap it would also be interesting to know what some of your prefs are set to, especially the fcc pref, and if you have a server directory set on your advanced imap server prefs.
My appologies. How is a protocol log generated? My setup has exim delivering to ~/Maildir in maildir format. Couriour IMAP is providing IMAP to Mozilla. some prefs.js ============= user_pref("mail.identity.id1.drafts_folder_picker_mode", "1"); user_pref("mail.identity.id1.fcc_folder", "imap://hanasaki@imap/INBOX/Sent")
hanasaki, Thx for the feedback. But I test with a Cyrus IMAP server & a Courier IMAP server, everything is ok. I tested with 3 circumstances. 1. default user_pref("mail.identity.id1.drafts_folder_picker_mode", "0"); user_pref("mail.identity.id1.fcc_folder", "imap://henry@imap/Sent"); 2. set the preferences to 'Other' without IMAP Server Directory Setting user_pref("mail.identity.id1.drafts_folder_picker_mode", "1"); user_pref("mail.identity.id1.fcc_folder", "imap://henry@imap/INBOX/Sent") 3. set the preferences to 'Other' with IMAP Server Directory Setting of 'INBOX' user_pref("mail.identity.id1.drafts_folder_picker_mode", "1"); user_pref("mail.identity.id1.fcc_folder", "imap://henry@imap/Sent") Can you verify with the refresh nightly build? Because my patch has been just checked in (6/8). Not sure the one you used include the patch. Thx. Can anyone else also help to verify? Thx. P.S. To generate a protocol log, set the following enviroment variables. setenv NSPR_LOG_MODULES IMAP:5 setenv NSPR_LOG_FILE /work/imap.log Henry
For me the behaviour also changed: "copying to sent folder" used to work only by specifying 'Place a copy in: Other:' and manually selecting the 'Sent' folder under the inbox. This does no longer work. Now only 'Place a copy in: "Sent" Folder on: ' works, which did not work before. I use a Courier IMAP server and the latest nightly: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1b) Gecko/20020807. Nearby: The issues which I mentioned with bug # 154778 still exist: Specifying the server directory INBOX. correctly shows folders on the same level as inbox, not as subfolders but the folders are no longer readable: 'The mail server responded: Invalid mailbox'. Only one level of nested subfolders are displayed. Subfolders of subfolders are ignored. Manfred
Thx, hanasaki & Manfred Usselmann. There is a logical problem in my newly added function nsImapIncomingServer::GetUriWithNamespacePrefixIfNecessary. I've given a patch for this issue in bug 27002. Thx again.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1b) Gecko/20020808 Specifically selecting Drafts/Sent/Templates folders results in IMAP server error Selecting only the IMAP server and letting Drafts/Sent/Templates be the default on the IMAP server works. Sent email goes into the Sentfolder under INBOX. This gave the, invalid mailbox error, in the past. IMAP server is courier
This issue is resolved in trunk. Please re-verify. Thx. Henry
are there any other issues left besides the desire to have sub-folders of the inbox displayed at the top level, with the inbox? I believe the other problems have been fixed on the trunk.
As expected - Sent/Template/Trash folders have the special icons if put them in "OtherFolders" and specifically select the right folder under the IMAP account. Folders appear at the top of the folder list (ie: not in alpha order) Not as expected - Sent/Template/Trash folders are in alpha order and do not have the custom folder icon if the default of "place in ___ folder on IMAP server" is selected. In all cases, sent mail does go into the sent folder. In the past, sometimes there was an "invalid folder" error.
hanasaki, Just as you saw, the function of Send/Save should work now. Please refer to bug 148062 for the scenario of special icons issue. :-) Henry
Yes, send/save now works both ways (send folder on server or selected folder). Tested with Gecko/20020812 on Win NT. For me the issue 'show subfolders at top level not below INBOX' is more cosmetic but what really bothers me is the problem that nested subfolders are not showing up reliablely (as mentioned with bug 154778).
Manfred Usselmann, I can't confirm bug 154778 yet. After I finish some bugs at hand, I'll take a look at it. At the first glance, it seems that the test account on backup2.canaan.co.il has no familiar issues. Would you please give more clues? You may add comments in bug 154778. Thx. Henry
Marking new comments in bug 154778. Manfred Usselmann, please take a look at it and verify the issues. :-)
I'm not sure if these were side-effects of this patch or not. For my previously established IMAP account, I was unable to switch from using "Place a copy in: Other:...." to "Place a copy in: "Sent" Folder on:..." . Everytime that I made the change and clicked "OK" or switched to a different preference window, it was restored the old setting. When I deleted the account entry and created a new account using the same imap account, then it would accept the '"Sent" Folder' setting and I can freely switch between the two options. When I recreated the account, I didn't specify any namespaces (though I did unset 'show only subscribed folders'); they were auto-detected. The Trash folder has a custom icon but the Sent folder does not. The Sent folder did have a custom icon before I recreated the account. Emptying trash still works correctly.
Chris, I don't know what would cause that problem selecting the sent folder - that sounds more like a prefs UI thing. We'll just have to keep an eye out for that.
I know there is an aversion to creating preferences for things, but I have to put my $.02 in here. comment 52 suggests that nobody wants to dive into a second hierarchy to see his personal folders. Count me as a nobody then! I have so many accounts listed that I can't see them all in the account pane whenever I have the INBOX folder expanded on them. If all of the subfolders are moved to the root level under the account, then I will be forced to create a single subfolder for each account for the sole purpose of collapsing the account list pane. Even that will double the number of lines displayed for each account. It might be a better solution to list the number of unread messages in checked folders alongside the account name... then I could collapse everything down to one line and I won't be a nobody anymore!
If the namespace is implemented in a specific way, you would still be able to create all of your sub-folders under 'inbox', and maintain the heirarchy the way you want. But for those of us who do want the other view, there is currently no way to implement it. If you decided to OVERRIDE the namespace, and not give it one, the behaviour should match the way it works now. But, with Courier, if you define the namespace as "INBOX." then all the subfolders under INBOX should appear as though they are at the same level as the Inbox. I haven't had a chance to test out the new trunk build yet, but I hope the behavior matches what I've described here...
*** Bug 174976 has been marked as a duplicate of this bug. ***
*** Bug 175591 has been marked as a duplicate of this bug. ***
FYI - Evolution (from Ximian/Gnome) displayes the folders in the proper sequence without any configuration. INBOX is displayed at the same level as other 'top level' folders.
*** Bug 188196 has been marked as a duplicate of this bug. ***
Anyone actively working on this? Any way to bump up its priority. My business users are "commenting" on this feature.
I'd have to agree with hanasaki: Is this still being fixed? There hasn't been a lot of activity on it since the beginning of the year. I just recently started using Courier-IMAP 1.7.1 on my Linux server here and was baffled by the folder behavior. In short, everything listed here I can reproduce. Strangely enough, it seems like Mozilla wants to list them properly. When I was testing with a fresh profile, the folders would list correctly in the root (not under the Inbox) and even with their proper custom icons. I would enter my password and the server would be accessed and then the root folders would disappear and the ones I had previous used (like 'Sent') would reappear under the Inbox, with plain folder icons. I was under the impression from comments here and in related bugs (such as bug# 27002) that patches are being created to help resolve this. I recently upgraded from 1.3a to 1.3(release) and it still exhibits the same behavior, but that's understandable: I'm sure the freeze for 1.3 occured a while ago. How is progress on this bug going?
There isn't an easy fix to this bug. This has something related to the realization of Courier IMAP server. When you create a new profile, all the special folders like Drafts Sent and Templates are all listed paralled with INBOX, but that is only a fake, only mozilla assumes things will be. Because Courier server has different folder hierachy struct with some other kinds of server for examply Cyrus server, Courier always add namespace "INBOX" to all the personal namespace folders. And all the special folder are created there, So you will still get the special folders as subfolder of INBOX. To fix this bug, I'm afraid we must give a change to the architecture mozilla used to assume the realization of servers. And also the namespace's actural useness though RFC2342 has defined the definition, but not defined how to use it.
I'm a little confused by 'realization of the Courier IMAP server'. Isn't that what the 'namespace' is is for? To determine the reality if the server? INBOX is a reserved mailbox, and is always accessed as "INBOX". All other 'folder' access should be prepended with the namespace, whatever it is. For UofW IMAP, That's typically prepending "Mail/" to all the accesses. As for the folder display itself, if a folder list is requested from the server, I'd imagine you would REMOVE the namespace from the items returned from the list, and build the tree from that... What I can't figure out is how "Mail/" for UofW is different from "INBOX." for Courier, Cyrus, and other imap server that uses the 'maildir' folder tree structure.
A common configured Courier server will take "INBOX." as its personal namespace and add this prefix to all the special folders and other folders in personal namespace. And thus we sure will see the special folder listed as subfolder of INBOX. To REMOVE or not the namespace of a url when mozilla communicate with the server is a problem about consistance of the folder tree struct of the mozilla side and server side. Server will not recognize wrong url: For example, on Couire server, when the folder is imap://username@server/INBOX/Drafts in server side, and mozilla sent imap://username@server/Drafts , an error dialog will come out which say that there has no this folder. So I still think this bug is something related the useness of namespace. And the namespace of servers are different always, this bring us difficult, so I had always think it's server related.
A bit of extra info... My courier stores mail in ~/Maildir All mozilla viewable folders, at any level, are directly in this directory and have the names: ~/Maildir/.Drafts ~/Maildir/.MyFolder ~/Maildir/.MyFolder.SubFolder ============== What does "useness of namespace mean"? ============== Ok so I think I hear the courier pages saying its a client (read: mozilla) bug and the last posting by philip saying its a server (read: courier) bug. Suggestion: would the mozilla person who is working on this bugzilla issue contact the courier developer and jointly work toward resolution (read: teamwork/collaboration)
Not a server bug, but a server *namespace* related bug.
It's intersting, this battle between the Courier developer and the Mozilla mail developers have had for almost 2 years now. And this problem has existed since Netscape 4.5/4.7x. Also, what's interesting is that other IMAP clients don't seem to have the same issues with Courier style IMAP servers that mozilla does. Outlook Express (not that I would EVER use it) works exactly as I would expect. When I first set up the account, all the folders appeared under INBOX. Then I added the name space of INBOX., and viola, everything that was one level under inbox, is now even with inbox. Evolution. Not only does it work, but it figured out the server namespace without me having to 'override' it. Special folders (Draft, in particular) worked fine as well. So, is this something that just can't be fixed because of something in the initial design? If so, you might as well mark this as 'won't fix' and close it, rather than giving me hope that it will be fixed for 2 years (5 if you count the fact that Netscape 4.7 couldn't do this correctly either..) If I was a C++ programmer, I'd probably rewrite it myself. Unfortunately, I'm just a user/admin and can't, so all I get to do is test and then whine.
/Not a server bug, but a server *namespace* related bug./ Po-tay-to, Po-tah-to. Either way, you're stating that it's a problem with Courier, not with Mozilla.... and I disagree, based on my previous post. Mozilla initially had problems with UofW IMAP too, but those were fixed.
I think the description of the bug should be updated as it does not reflect the true problem being reported. Things we know: - This bug is related to the _namespace_, not to CourierIMAP. - Access to folders _works_ so it is far from 'critical' - There _is_ a serious UI issue: special folders "sent", "drafts" and "templates" don't work with the default behaviour of Moz when creating a new account because Moz expects them to be at the top level of the namespace. Workaround: choose 'other' and tell moz explicitly _where_ the Sent folder is. See the image attached to the bug. This problem exists since around M18 -- before M16 there were bad interop bugs with Courier. And it is still present in 1.3final for sure. There are a few dups of this bug: #27002, probably #146418, #148460 and #166603 . - There is a minor UI-aesthetics, seen in one of the attachments. Arguably, Moz should fake the UI so that the folders don't appear as 'hanging from' INBOX. Correctness against user-friendliness and consistency. Again, arguable.
Since I was the one that submitted the bug, I'd like to disagree. I understand the work around for the special folders, and you're correct, it does work. By the problem isn't about getting the special folders to work, it's about them not working when the correct name space is defined. It about having to choose between a folder list is not all listed under INBOX, or not being able to use server-side send/drafs/templates folders at all. It is definately a namespace issue, as it has changed over time. For example, if I put INBOX. in as the namespace, the folder tree is then displayed correctly. But, if I go to access ANY folder other than INBOX, I get "the current command did not succeed. The mailserver responded: Invalid Mailbox". It IS usable with no namespace defined. But that's not the point. I still don't believe/agree that it's a server problem, as is evidenced by other clients that work PERFECTLY with the exact same server.
Okay, more of my two cents. I'll say up front, I am a programmer, but I have just a basic understanding of C/C++. So you'll excuse me if I work in the abstract, and I'll completely accept someone telling me 'You can't do that'. The way I see it, Mozilla correctly builds the access URLs for the special folders, for example: imap://username@server/Drafts Wouldn't all you have to do is make it: imap://username@server/{namespace}Drafts For those using the UW-IMAP server and Mozilla works correctly as is now, your namespace would be NULL, yeilding: imap://.../Drafts The Courier people would use a namespace of INBOX. (which is what Courier appears to override with, or at least my Courier does), giving you: imap://../INBOX.Drafts Which should work correctly, right? And if you use slashes instead of dots, you'd use a namespace of INBOX/ and get the correct URL. As I said at the start, I've not much experience with C and certainly zero with the Mozilla source code, so maybe this is an impossible addition to make, or it would be at best difficult, or maybe it would break six other modules. I don't know. But on paper, in theory, it looks like it would work to me. If this has already been considered and/or tried, then I'm sorry for bringing it back up. I'm new here on bugzilla (at least posting, been reading for a while) and I'm deathly afraid of making a misstep and upsetting people. ^_^ James
Erf. No sooner did I post that last comment than I found the IMAP namespace & server tracking metabug. I now realize that while the solution is simple, the implementation is a whole 'nother story. So I hope you'll forgive me. I had the best of intentions at heart, but I should have done more reading before shooting off my mouth. :) James
Others can learn alot from your details... What is the cause? solution? level of effort for implementation? What is the plan? target timeframe? who is assiged to implement?
Using the latest 1.4, it is possible to set "IMAP Server Directory" to "INBOX." The folder hierarchy is then rebuild, and all folders are at the same level then Inbox. However, it is then no longer possible to select a folder other then Inbox, because the prefix "INBOX." is not appended to the folder name when issuing the IMAP SELECT command: 003-04-07 16:40:55.453581500 27145 < 2 select "XTest1" 003-04-07 16:40:55.454028500 27145 > 2 NO Invalid mailbox The correct select command would be: 2 select "INBOX.XTest1" It does not matter what is configured as "Personal Namespace". BTW, what is the difference between "Personal Namespace" and "IMAP Server Directory"? Are these two preference items redundant? Lars
Lars,You're right of the perfomance of mozilla1.4 can't access other folders except INBOX if we set IMAP server directory to INBOX. While that *is* because the personal namespace of Courier server is "INBOX.".Please see bug 154778.
Hi Philip, Yes, bug 154778 is about the same problem. But what is the proposed solution for this? Could you explain to me what are the difference between "Personal Namespace" and "IMAP Server Directory"? Lars
Blocks: 201332
Lars,As far as I know,IMAP server directory works as a setting which let users have a more favor display of his folder-tree.Personal Namespace please see RFC2342 for details. I think we should delete IMAP server directory in future, for it leads many problems because of the difference of mozilla folder tree struct and the folder struct on server side. But we now should forbidden users setting of IMAP server directory when this setting leads to problem, while enable the setting if it's safe to do so(For exam, on Cyrus is safe to set "INBOX" because personal namespace is ""). What's your oponion?
I tried 'disabling' the personal namespace (setting it to ""), and just having the IMAP server directory. The personal namespace seems to be having absolutely no bearing on anything. All folders are still rooted under inbox in the folder tree, and if you set the IMAP server directory, you can't access anything other than inbox. WHere is 'personal namespace' used?
Hi Philip, > Lars,As far as I know,IMAP server directory works as a setting which let users > have a more favor display of his folder-tree. I think this preference Option schould be removed. The folder tree schould show up at the same level then "Inbox", regardless what NAMESPACE a server uses. The "Personal Namespace" schould be left for advanced users to override a Servers NAMESPACE, or to support servers which does not implement NAMESPACE. Lars
Surely you will see the performance , David. But I think if special folders like Drafts and Templates and Sent can work well, weather or not they are listed under INBOX or paralled with INBOX will not be a big problem. Now this is the problem that if Drafts Templates are listed Under INBOX, they will not work well. So we need to : 1.make them work well if they are listed under INBOX. Please see bug 166603. 2.forbidden users setting of IMAP server directory to "INBOX" since the setting will make us can't access those folders.(Of course we can let mozilla can access those folders, but IMAP server directory is leading many other problems still if it's not deleted) Please see bug 154778. 3.Delete IMAP server directory's setting. Thus , we will get special folders work well, and never confused on IMAP server directory. But all the folders will list under INBOX if the personal namespace is "INBOX". But it doesn't matter much. How about you think? David and Lars?
Lars, acturlly, if the server's personal namespace is INBOX, it will have a different folder struct on server side with those servers whose personal namespace is "". So if we still want to see all other folders parall with INBOX, we will get many trouble. I always think client side folder tree struct should be same with server side. This is the simple solution to questions coming with the inconsistance of client folder struct and server folder struct.
Reading the postings leaves me with the impression that the requirements/goals are not clearly understood and uniformly interpreted by all. As a Mozilla user, this is my concept of the requirement(s): 1. Ability to make folders that appear under the email client inbox 2. Ability to make folders that appear at the same level as the email client inbox 3. Mozilla email client MUST display folders as they are displayed in Outlook and Evolution 4. Server-side folder naming is not important. do not expose it to the user. 5. autoconfigure to support 1,2,3,4 using server provided namespaces if available
I would strongly disagree with philip's statement that the client folder tree should match the server's folder tree. I believe that the entire point of the namespace is to ADJUST the client view to accomodate the server structure. For example, Courier doesn't actually create a directory tree structure to accomodate subfolders. Physically speaking, under the Maildir in my home directory, there is a directory called .Friends, and a directory called .Friends.Chris, and a folder '.Friends.Chris.Old'. Now mozilla (correctly) displays this is a hierarchy of folders, even though physically, they are not. The namespace should be the the last step in presenting the folder tree correctly. It should instruct mozilla that, when displaying the tree, the namespace string should be removed, but when accessing the folders,messages, and etc, the namespace should be added to all folder access 'transparently'.
I have noticed people mention that the folders 'Drafts', 'Sent", and "Templates" are 'special folders'. Where I can see they are special to Mozilla, I don't understand what that has to do with the IMAP protocol and the 'namespace' feature. To the protocol, it should just be another folder. As for the 'todo' list: 1) Seems like a backwards approache to the problem. Ignore the namespace paramter all together EXCEPT for when defining the drafts, templates and Sent folders? If you're going to decide that this bug is not to be fixed, then I would at least hope you'd make it transparent in the rest of the program. I feel that, if you fix THIS bug, the other bug becomes a non-issue. 2) Becareful about this one. Netscape 4.x would never have worked with U of W IMAP without being able to set the namespace. I would agree that listing the namespace twice is redundant. 3) See #2. I still think you're addressing all the problems that are a result mozilla not using the namespace paramter correctly. Philip, I'll make you a deal, if you'd like. I will offer to create you a mailbox on my courier server so that you can set up mozilla against it, and see the (incorrect) behavior, and then you can also set up outlook express, outlook, or evolution, and see the (correct) behavior. If you can look at how those programs work compared to mozilla, I think you'll better understand what needs to happen. Please conctact me off-list and I'll create the mailbox, and send you the information for it.
I agree with Dave. The folder tree schould be the same, regardless what IMAP server/NAMESPACE is in use. So basically here is what I think is the ToDo: 1) Rework the Advanced IMAP Server Preferences Dialog: +remove the "IMAP Server Directory" preference. It is redundant with "Personal Namespace". + remove the "Allow Server to Override these Namespaces". The Preferences schould have precedence, allways. + Allow to configure the Folder Seperator for each Namespace ("/", ".", ...) 2) Implement NAMESPACE (auto)-configuration +On connect, try the NAMESPACE command (or use CAPABILITY) +If it fails, try a LIST "" "%", to guess the correct NAMESAPACE. +It it fails, prompt the User via Advanced Preferences/"Personal Namespace" 3) Fix the internal/external folder representation: +server2internal: remove "Personal Namespace". ("INBOX.Level1.Level2" => "Level1/Level2") +internal2server: prepend "Personal Namespace". ("Sent" => "INBOX.Sent") Lars
Hi,Dave, I will try to look into bug 80858 but not sure enough to meet the needs. Would you please give me an account on your Courier server for a test? Thanks. Best regards! -philip
Hi,Dave and all, Thanks for the courier account. I test it on mozilla and evolution. But I don't see Drafts Sent at the same level with INBOX in evolution. (Trash is paralled with INBOX.) Drafts Sent are still subfolder of INBOX. And I can't create any folders parall with INBOX . (This is a feature of Courier server who only permit users create subfolder of INBOX and sub-sub folders.) This test result quit different with yours? I use evolution-1.3 , the most latest version build from trunk. -philip
This is a screen shot of Evolution and the folder tree it built when I connected it to an established IMAP tree on a Courier Imap server.
This is a Mozilla 1.3 fiew of the same Courier IMAP server. Note, all boxes are displayed under INBOX, where the previous attachment shows Evolution showing no folders under INBOX...
I've uploaded screenshots of Evolution 1.0.8 and Mozilla 1.3 viewing the same folder tree on Courier IMAP. Evolution has not place to define the namespace, so it is picking up the namespace from the IMAP server itself. Mozilla also picks up the information correctly. If you're seeing Inbox and Sent as subfolders of INBOX, then our results are very different. Since 1.3 is not an 'official' release from Ximian (1.2.5 is the latest stable release), you might want to try 1.2.5.
Flags: blocking1.5?
Re: Comment #101 - Philip, Are you still looking for a Courier IMAP server to test this against? I can provide one for you use if you would like to email me to arrange it.
Antony, here's the state of this bug, I believe, in Moz 1.6. If this is not what you see, you can send me the test account info and I'll try it. If you leave the online server directory blank, the sub-folders of the INBOX will show up as sub-folders of the INBOX. If you set the online server directory to "INBOX.", they will show up as siblings of the INBOX. If that's not what you see, let me know.
Flags: blocking1.5? → blocking1.5-
Not coming up as siblings for me? running Mozilla 1.5a Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5a; MultiZilla v1.4.0.3J) Gecko/20030715 The nightly builds havent worked for IMAP for me for a couple weeks. My server is IMAP courier The current nitely build 9/24/2003 gives an error when selecting a folder however the folder list comes up fine (although as subfolders of Inbox)
hanasaki, what's your online server directory set to?
Using the 1.6a nightly build (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20030924), by setting the Server Directory to INBOX. it seems to work well. It also appears as though the folders can be accessed normally (a previous issue was the tree displayed correctly, but it couldn't access messages. Even the server based sent/draft/template folder selections (Sent folder on <server>) as opposed to having to use 'other sent on <server>'. Note: You cannot include the quotation marks in the server directory string as the personal namespace entries uses them. Without the quotes, it works fine. With the quotes, it only shows the "INBOX". From my quick examination, this is the behavior I desired (save for the 'quote' issue). I'll work with it a bit and see if I find any problems...
mail is in ~/Maildir Allow server to override is checked unchecking it and setting it to [nothing] or "INBOX" only shows the inbox.. no other folders at all Inbox, folders under it, none at the same level, are displayed if the server directory is set to empty string or to "~/Maildir"
hanasaki, I think you would set your online server directory to ~/maildir - are you running Cyrus or UW?
(In reply to comment #110) > Using the 1.6a nightly build (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; > rv:1.6a) Gecko/20030924), by setting the Server Directory to INBOX. it seems to > work well. One question, Can you then create folders below the Inbox as well as Besides it ? Like this Inbox ..priavte mails .. some more Sent Drafts Another folder .. sub folder currently I have either All folders below inbox (server path emtpy) or all folders besides inbox (server path INBOX.)
I also have an imap server to test with if anyone needs it
Still having the same problem. Also having it with the below Thunderbird. Mozilla Thunderbird 0.5 (20040306
Henrik, that's the current state of affairs - you can either have all your folders displayed as sub-folders of the INBOX, or as top-level folders. How would you get both if what people want is sub-folders of the Inbox to be displayed as top-level folders?
I really don't understand why this is so hard. There is a sequence to doing these things: 1. Connect to server 2. Ask server about Namespace and separator 3. Ask for list of folders. 4. Remove Namespace prefix from all folders except INBOX, which is special 5. Draw tree. In every communication with the server prepend Namespace to foldername (Except for INBOX, which is special) Use the separator specified by the server to separate foldernames in hierachical folders. This would work for every IMAP server out there that is capable of answering (2). Now, it should actually be possible to both have folders at the same level as INBOX and inside INBOX at the same time. The folders at the same level are eg.: INBOX.Sent INBOX.Drafts Folders inside INBOX would then be: INBOX.INBOX.Folder1 INBOX.INBOX.Folder2 Some servers don't implement the Namesspace extension, for these the current default values could still be used. The "Server directory" parameter in Mozilla is really a band-aid solution that in my opinion scars an otherwise outstanding mail application. Just my $0.02
Changing the root mailbox prefix to "INBOX." works for me with Mozilla 1.6 & Courier-IMAP 3.0.3. I would note that I had to manually update 20-30 mailbox filters after changing the root prefix. It seems to me that either the mail filters should be updated when the root prefix is changed, as happens on mail folder renames ("At least one mail filter points to the renamed mailbox... would you like to update the mail filters... Yes/No."), or the root prefix should be assumed to be included in mail filter names (in other words, do not append the root prefix when accessing folders attached to mail filters - assume the name is already an "absolute path").
Product: MailNews → Core
I just tried this on Thunderbird 2.0.0.6, and it is still a problem. Thunderbird does not seem to use the Personal Namespace when it draws the folder tree, but it does use the Serverfolder, which should not even exist as a variable.
Blocks: 234010
dupes: bug 365009, bug 215960, bug 248080?
QA Contact: meehansqa → networking.imap
Summary: Improper INBOX format with Courier IMAP → Autodetect IMAP namespace - Improper INBOX format with Courier IMAP
Product: Core → MailNews Core
Blocks: 475139
No longer blocks: 475139
No longer blocks: 557718
Depends on: 557718
No longer depends on: 557718
Changing bug summary(I believe similar to title/abstract of research paper) for ease of bug understanding.
Summary: Autodetect IMAP namespace - Improper INBOX format with Courier IMAP → Use IMAP namespace response for auto hiding of namespace folder at folder pane
IMAP namespace is defined by RFC 2342. http://tools.ietf.org/html/rfc2342 > 6. Formal Syntax > Namespace = nil / "(" 1*( "(" string SP (<"> QUOTED_CHAR <"> / > nil) *(Namespace_Response_Extension) ")" ) ")" > Namespace_Response = "*" SP "NAMESPACE" SP Namespace SP Namespace SP > Namespace > ; The first Namespace is the Personal Namespace(s) > ; The second Namespace is the Other Users' Namespace(s) > ; The third Namespace is the Shared Namespace(s)
Resetting "Assigned To:",because it was set on 2002-04-13.
Assignee: bienvenu → nobody
Severity: normal → enhancement
Hardware: x86 → All
"Flat Folder Tree" Add-on seems to fix the problem: https://addons.mozilla.org/fr/thunderbird/addon/195535/ However, such a useful feature would really need to be implemented into Thunderbird core, because average user will simply not find this add-on.
This bug has been identified CRITICAL(meaning it would make it difficult or even impossible to use the application on a regular basis) during sessions of usability testing of Thunderbird. Quote: "There are 4 main folders they (the users) want visible: inbox, sent, junk and draft. It is worth noting that the ’sent’ folder in Thunderbird is a sub-folder of gmail; this was confusing to participants. As a case in point, several participants failed at checking if a message they had sent me had really been sent because they couldn’t find the ’sent’ folder at all." Source: http://design.canonical.com/2011/02/thunderbird-in-the-usability-lab/
> "There are 4 main folders they (the users) want visible: inbox, sent, junk and draft. Only slightly related to the bug, but: This sentence is nonsense. Having watched users myself, they were *thrilled* and *very* happy to see all their folders, particularly the folders they created themselves. In fact, that the point where Thunderbird exceeded their expectations and wishes and made them excited about Thunderbird. That said, I agree that folders should not be shown as subfolders of INBOX, that's confusing indeed.
I agree with you Ben, I should have deleted the first sentence from the quote.
Given that Ubuntu default install would be significant for TB and they care, and I agree this is a usability problem, I am requesting this to block TB 3.3, to raise awareness and hopefully put this on bienvenu's agenda :).
blocking-thunderbird5.0: --- → ?
(In reply to comment #129) It is worth noting that the ’sent’ folder in Thunderbird is a sub-folder > of gmail; this was confusing to participants. As a case in point, several > participants failed at checking if a message they had sent me had really been > sent because they couldn’t find the ’sent’ folder at all." > > Source: http://design.canonical.com/2011/02/thunderbird-in-the-usability-lab/ Gmail does not return [Gmail] as an imap namespace (it returns empty namespaces - NAMESPACE (("" "/")) NIL NIL. So, this bug is not directly relevant to the gmail case. Also, note that gmail has some top level folders, and some folders under the [gmail] folder, so we can't pretend that [gmail] is the personal folder namespace.
We wouldn't block on this bug considering David's comment.
blocking-thunderbird5.0: ? → -
Mark, GMail is not terribly relevant, it has 10-15% market share among our users. Ubuntu just tested with that. This bug still applies to all others.
blocking-thunderbird5.0: - → ?
(In reply to comment #135) > This bug still applies to all others. Among them two big French provider of imap accounts in France: Free.fr and Laposte.net...
(In reply to comment #135) > Mark, GMail is not terribly relevant, it has 10-15% market share among our > users. Ubuntu just tested with that. This bug still applies to all others. In bug 637641, we now expand sub-folders by default when special folders are added. I think that mitigates the usability issue, and means that we don't need to implement to solve that issue. Therefore not blocking.
blocking-thunderbird5.0: ? → -

Courier and dovecot and probably others usually make Inbox the root folder with all other folders in the personal namespace (called "INBOX.") under Inbox. This can be changed at the server but that is typically unlikely unless the tb user controls the server. You can flatten the folder tree that tb shows so Inbox and the folders that were under inbox are now at the same level by setting advance server setting "IMAP server directory" to "INBOX" (no quotes). It seems to be case sensitive since just "inbox" doesn't have an effect. Make the change and collapse and expand the server's tree and/or restart tb. This changes the tree to flatten the folders to the Inbox level.

So this seems to be mostly fixed as originally described in comment 0 above and in several dups.

Maybe the fact that the server directory must be set to INBOX (uppercase) for this to work is still a bug, not sure. (IMAP treats mailbox INBOX as case insentivite.) However, since servers report the personal namespace as INBOX, maybe it makes sense for the server directory to also be set to the exact same string to show INBOX's sub-folders at INBOX's (root) level.

One other observation: Once the tree is flat and if you create a folder under Inbox, tb physically creates Inbox/Inbox/newFolder but it appears to be just under Inbox. Then if you remove INBOX from the "server directory" setting, collapse/expand and view the folders again, you see a "gray" Inbox/newFolder under the toplevel Inbox. Probably not a big problem but some might consider this a bug.

The objective here is to detect this automatically and get it right without custom preferences. As you said, most local IMAP servers are affected.

...get it right without custom preferences...

I assume that by "right" it means show the folders in a flat way with inbox on the same level as what the server puts below inbox.
Not sure everyone objects to showing the folders the same way the servers presents them.
Also, maybe the [Gmail] folder is another example. Is it "right" to hide it too and move its contents up by default?

Anyhow, my intention was not to fix this bug but I was just doing research for another bug I was working on regarding namespaces and server directories: Bug 1530157
The namespace code in tb is not well documented and was hoping to find some info on it in bugzilla. However, some of these old bug reports just say "I fixed and committed the change" but no patch is shown so that doesn't help a lot. Also, old reports mention UW server some. I've been working on tb imap for maybe 3 years now and haven't run across a problem where the user's server is UW. (It's still available in Fedora repo but not sure anyone uses it as a production server. I think it was mostly just a reference implementation written my Mr. Imap, Mark Crispin.)

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: