User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; InfoPath.1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 1.1.4322) Build Identifier: Thunderbird version 2.0.0.6 (20070728) When using a fresh install of TB2.0.0.6 talking to a UW-IMAP server I can create folder hierarchies by simply selecting "New Folder" and entering something like "Parent/Child" and the appropriate hierarchy is created on the imap server and all is well. When I then go to the Account Settings->Server Settings->Adv. Settings and deselect "Server Supports folders that contain sub-folders and messages" (since the uw-imap server on unix doesn't), restart TB and then attempt to create another folder hierarchy - eg "Box/Contents", TB replaces the "/" delimiters with "." (periods) and creates on the imap server a flat structure with no hierarchy (just folders with dots in their names) eg "Box.Contents". Reproducible: Always Steps to Reproduce: 1.Insall TB 2.de-select "Server Supports folders that contain sub-folders and messages" 3.restart TB Actual Results: "/" no longer works as an IMAP hierachy delimiter Expected Results: TB should continue to create hierarchies on the imap server if the mailbox name includes "/"s - rather than convering the delimiter to "." (dot) and therefore only creating top level folders with dots in their names. de-selecting "Server Supports folders that contain sub-folders and messages" doesn't break the "/" imap delimiter until TB is restarted. other accounts within the same TB client are uneffected. ie I can still create "/" delimited hierarchies on accounts connecting to a Courier-IMAP server. telnetting to the UW-IMAP server and requesting the delimiter symbol seems to work: :~ > telnet postie.ics.mq.edu.au imap Trying 137.111.216.15... Connected to postie.ics.mq.edu.au. Escape character is '^]'. * OK [CAPABILITY IMAP4REV1 LITERAL+ SASL-IR LOGIN-REFERRALS STARTTLS] postie.ics.mq.edu.au IMAP4rev1 2006j.388 at Thu, 11 Oct 2007 11:12:38 +1000 (EST) 1 login richard XXXXX 1 OK [CAPABILITY IMAP4REV1 LITERAL+ IDLE UIDPLUS NAMESPACE CHILDREN MAILBOX-REFERRALS BINARY UNSELECT ESEARCH SCAN SORT THREAD=REFERENCES THREAD=ORDEREDSUBJECT MULTIAPPEND] User richard authenticated 2 list "/" "" * LIST (\NoSelect \HasChildren) "/" / 2 OK LIST completed This anomoly also means "/" as the namespace delimiter doesn't work either. ie creating a new folder in TB called "#driver.mbx/Test-Folder" results in nothing being created on the imap server (whereas it works are expected prior to de-selecting "Server Supports folders that contain sub-folders and messages" and restarting TB. Re-selecting "Server Supports folders that contain sub-folders and messages" doesn't fix the problem (ie revert to the behavor before it was de-selected where "/" work - even after a restart). With "Server Supports folders that contain sub-folders and messages" selected (as it is after a fresh install) it is not possible to delete folders (since the uw-imap) trash cannot contain folders (this is ofcourse is expected behavour). Un-installing TB (deleteing the profiles) and reinstall TB seems to be the only way to get "/"s working again (but then ofcourse folder delete doesn't work).

Please see dependency tree for Bug 124287, both "Hide Resolved" version and "Show Resolved" version. Recently fixed Bug 391556 has relation to hierarchy delimiter of IMAP, "." & "/". "/" related IMAP issues still remain. Can you find DUP or related bugs in dependency tree for Bug 124287? Or completely new problem?

(In reply to comment #1) > Please see dependency tree for Bug 124287, both "Hide Resolved" version and > "Show Resolved" version. > Recently fixed Bug 391556 has relation to hierarchy delimiter of IMAP, "." & > "/". > "/" related IMAP issues still remain. > Can you find DUP or related bugs in dependency tree for Bug 124287? > Or completely new problem? As far as I can tell there are no DUPs in the tree for Bug 124287 or 391556. This issue relates to a non reversable change in behavour when changing the "Server Supports folders that contain sub-folders and messages" rather than how TB handles the special characters in general

I think it's mainly bug 29926. Creating a folder named a/b isn't supposed to create the hierarchy, but a folder with that name.

... but according to rfc2060: "If the mailbox name is suffixed with the server's hierarchy separator character (as returned from the server by a LIST command), this is a declaration that the client intends to create mailbox names under this name in the hierarchy. Server implementations that do not require this declaration MUST ignore it. If the server's hierarchy separator character appears elsewhere in the name, the server SHOULD create any superior hierarchical names that are needed for the CREATE command to complete successfully. In other words, an attempt to create "foo/bar/zap" on a server in which "/" is the hierarchy separator character SHOULD create foo/ and foo/bar/ if they do not already exist." .. and even if I attempt to create "A/", TB actually request the IMAP to create "A." The oddness is that it happens only after I de-select: "Server Supports folders that contain sub-folders and messages" and the orginal behavour doesn't return when I reselect it.

Yes, low level... But if you look at RFC 2060 5.1.3. the '/' should be encoded if used in a name. Obviously tb isn't doing this atm -> bug 29926.

Hmmm, ok '/' is illegal as part of a name - however we should be able to create a hierarchy if that is indeed the user's intention. This is infact TB default behavor with either embedded or trailing hierarchy delimiters. It is still a bit unclear why TB subs embedded hierarchy characters in an attempt to create a flat name message container(even when 'Folder Only' is selected when creating the name). Also, I have been trying to reproduce the problem on other machines and have found '/' replaced by '|' on one machine (TB2.0.0.6/XP Pro), however I've also discovered that it only occurs with some accounts on the same server.

(In reply to comment #6) > Hmmm, ok '/' is illegal as part of a name Is it? Where do you get that from? And why would 5.1.3. point 2) even exist in that case?

Ok, not illegal - but 5.1.3 indicates that "," is used instead of "/" by the *convention* of using modified UTF-7 for mailbox names. Without the '/' becomes ',' modification to the UTF-7 encoding, '/' would UTF-7 encode to itself, and if present in a mailbox name would present to to imap server as a hierarchy delimiter (assuming that particular imap is using '/' as it delimiter). I suppose it would be possible for a user to request a mailbox name including a '/' and have their client map it an underlying name is ',' substitions. However at present TB accepts mailbox name containing arbitary numbers of '/' and passes them straight through to the imap server (which then interupts them as delimiters). This is reasonaly intutive behavour from a users point of view - however requires the user to have knowledge of the underlying imap server's delimiter. But complelely apart from how TB handles '/' when it is happy - for some reason I get '/' sub'ed to '.' - even then when I create a "Folder Only" New Folder. Ie if I create "name" (with "Folder Only" selected) I actually get "name." created on the imap server and "name." in my TB folder pane.

This might have been fixed in TB3 - Richard could you check ?

Richard ?

RESOLVED INCOMPLETE due to a lack of response to previous question. If you feel this change is in error, please respond to this bug with your reasons why.