On Fri, 18 Apr 2008, Joel Reicher wrote:
OK, but why leave the child status indeterminate? Presumably imapd always
knows which mailbox INBOX "really" refers to.
It's indeterminate because any case string matches INBOX, but when
children are involved an exact case is required. INBOX matches inbox and
INBOX and Inbox and iNbOx and iNBOX.
This is why you should never create children of INBOX. It is an undefined
concept.
How is it shadowed?...
* LIST () "/" inbox
* LIST () "/" INBOX
1 OK LIST completed
The shadowing occurs if you attempt to access "inbox". You will actually
access "INBOX".
I don't know how I can make this any more clear:
There is no unambiguous definition in IMAP for the semantics of children
of INBOX, especially in a mail store which has case dependency in mailbox
names. It was never intended that INBOX would have children. If a server
allows children of INBOX, the way that it works is specific to that server
and another server will almost certainly work differently.
The only reason why UW imapd does not forbid it utterly is that it was too
difficult to close all the possible loopholes by which such could be
created.
Regardless of whether or not the server reports \NoInferiors to INBOX, you
should always treat INBOX as a \NoInferiors name. You should never create
children of INBOX, even if the server lets you.
-- 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
[email protected]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
