399393 - IMAP hierarchy delimiter incorrectly set

Status: RESOLVED INCOMPLETE

(MailNews Core :: Networking: IMAP, defect)

Description

[Richard Miller]

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).

Comment 1

[WADA:World Anti-bad-Duping Agency]

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?

Comment 2

[Richard Miller]

(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

Comment 3

[Magnus Melin [:mkmelin]]

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.

Comment 4

[Richard Miller]

... 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.

Comment 5

[Magnus Melin [:mkmelin]]

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. 

Comment 6

[Richard Miller]

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.

Comment 7

[Magnus Melin [:mkmelin]]

(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?

Comment 8

[Richard Miller]

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.

  

Comment 9

[Ludovic Hirlimann [:Usul]]

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

Comment 10

[Ludovic Hirlimann [:Usul]]

Richard ?

Comment 11

[Joshua Cranmer [:jcranmer]]

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.