> 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".
Ah, I get it now. I wasn't understanding how the case insensitivity worked;
I don't know how I wasn't understanding it, but I wasn't. :)
> 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.
In an earlier email you said
> By request, there is explicit code in UW imapd (dummy_scan() in dummy.c)
> to list INBOX, and not report \NoInferiors if the INBOX is in a dual-use
> format. But it's still not supported.
and explained this compromise a bit more. If I am sure none of my
users will work around the server to create a child of INBOX is there
anything wrong with imapd reporting \NoInferiors for INBOX unconditionally?
I can see the code in dummy_scan() for this.
Thanks,
- Joel
_______________________________________________
Imap-uw mailing list
[email protected]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
