The simple answer is that it is a bug in Mozilla.
#public is not a "folder". It is a namespace.
Think of a namespace as like an A: drive in Windows. If, and only if,
there is a floppy inserted on your PC, you can reference names in a
separate hierarchy starting with A:
A namespace similiarly identifies a separate hierarchy that may exist.
If, and only if, that hierarchy actually exists, you can references names
that start with that namespace name.
In UW IMAP, the namespace #public identifies a hierarchy whose root is the
home directory of user imappublic. Thus, #public/foo is exactly
equivalent to ~imappublic/foo.
If the IMAP client LISTs #public/*, one of two things will happen:
[1] No results. The user imappublic does not exist.
[2] The contents of the home directory of user imappublic.
In the case of [2], you will see "#public/" returned as a \NoSelect name,
as this is the root of the #public space.
#public/#public is simply nonsense. Something concatenated #public twice.
UW IMAP will never do that, so it must have been Mozilla.
Perhaps Mozilla was attempting to apply a "prefix"; if so, it did it
incorrectly. The correct way to apply a "prefix" is to use the reference
field of the LIST command. That is, given a "prefix" of "#public/" and a
request to open "#public#":
Wrong: concatenate "#public/" and "#public", forming "#public/#public"
Correct: in IMAP, do the command:
tag LIST #public/ #public
and use the name that is returned from LIST. If no name is returned,
there is no such name.
In conclusion, this is completely a bug in Mozilla. I should also mention
that this comment in bug 497096 that claims a server bug is also
completely wrong:
5 list "" "Trash/emu2000/*"
* LIST (\HasNoChildren) "/" "Trash/emu2000/"
(B) This response means folder named under emu2000 under Trash.
Folder name in response has to be correct name which can be specified in
SELECT commant etc. So this is apparently server side bug.
There is no such thing as a "folder named ". The LIST response here
simply confirms that Trash/emu2000 exists as a directory. Otherwise,
there would be no way to distinguish "directory empty" from "directory
does not exist".
The bottom line is that if a client developer claims that there is a bug
in UW IMAP, he is almost always wrong; and is confused by a subtle aspect
of the IMAP protocol.
On Sat, 2 Jan 2010, Juergen Edner wrote:
Hello,
I'm using uw-imapd 2007b on my mail server. For quite a while
I'm now using public/shared folders to share information between
different users or provide a central spam mailbox.
This is e.g. my folder/mailbox structure:
#public -> folder
+ Spam-Mail -> mailbox
Sometimes I'm erroneously selecting the #public (or #shared)
folder in my Thunderbird client which causes the following
error message:
Can't open mailbox #public/#public: no such mailbox
I raised a bug request for TB but based on the following
discussion of the developers this problem seems to be a
uw-imapd problem because the server doesn't return a
\NoSelect if such a folder is selected.
Here you can find further debug information and the discussion
of the problem:
https://bugzilla.mozilla.org/show_bug.cgi?id=517054
Now I wonder if this is really a problem of uw-imapd and
if so, how it can be solved?
Thanks
Juergen
--
Mail: juer...@eisfair.org
___
Imap-uw mailing list
Imap-uw@u.washington.edu
http://mailman2.u.washington.edu/mailman/listinfo/imap-uw
-- Mark --
http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
___
Imap-uw mailing list
Imap-uw@u.washington.edu
http://mailman2.u.washington.edu/mailman/listinfo/imap-uw
