> Although the behavior seems strange and is arguably wrong, it is compliant
> with the IMAP protocol specification and is brought about by how INBOX is
> implemented in UW imapd.
>
> If neither \HasChildren or \HasNoChildren is indicated, then the child
> status is indeterminate. The lack of \NoInferiors indicates that the
> mailbox could have inferiors.
>
> When you referenced the name INBOX, you referenced the case-independent
> special mailbox defined in IMAP for incoming messages.
OK, but why leave the child status indeterminate? Presumably imapd always
knows which mailbox INBOX "really" refers to.
> When you referenced the name INBOX/, you referenced the dual-use mailbox
> with the case-dependent name INBOX. Note, in particular, the following
> behavior:
>
> 10 LIST "" inbox/
> 10 OK LIST completed
>
> This is because there is no such name as "inbox/".
Understood, but if this answers the new question I ask above, I'm not
following how.
> The story gets worse. If you create "inbox/foo", you end up with an
> "inbox" which is shadowed by INBOX and thus is not directly accessible;
> you can also have an INBOX/foo that is separate from inbox/foo. There's
> other stuff that goes wrong...
How is it shadowed?...
1 list "" %
* LIST (\HasNoChildren) "/" Sent
* LIST (\HasNoChildren) "/" Trash
* LIST (\HasNoChildren) "/" Drafts
...
* LIST () "/" inbox
* LIST () "/" INBOX
1 OK LIST completed
Sorry if I'm missing something obvious here.
(inbox in that test is just a directory; INBOX is still a mix mailbox)
Thanks,
- Joel
_______________________________________________
Imap-uw mailing list
Imap-uw@u.washington.edu
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
