headers
Joel Reicher | 17 Apr 14:48

Childless mix INBOX lacking \HasNoChildren?

I don't know if this is a bug or not because I don't know what the
correct behaviour should be. If this isn't a bug, could someone explain
the output?

7 list "" %
* LIST (\HasNoChildren) "/" Sent
* LIST (\HasNoChildren) "/" Trash
* LIST (\HasNoChildren) "/" Drafts
...
* LIST () "/" INBOX
7 OK LIST completed
8 list "" INBOX*
* LIST () "/" INBOX
8 OK LIST completed
9 list "" INBOX/
* LIST (\HasNoChildren) "/" INBOX/
9 OK LIST completed

All the mailboxes seen here are mix.

Thanks,

	- Joel
_______________________________________________
Imap-uw mailing list
Imap-uw <at> u.washington.edu
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
Permalink | Reply |
headers
Mark Crispin | 17 Apr 21:34

Re: Childless mix INBOX lacking \HasNoChildren?

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.

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

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

Consequently, my Official Position is that children of INBOX are NOT 
SUPPORTED and any use of these is at your own risk.

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
(Continue reading)

Permalink | Reply |
headers
Mark Crispin | 17 Apr 21:38

Re: Childless mix INBOX lacking \HasNoChildren?

On Thu, 17 Apr 2008, Mark Crispin wrote:
> 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.

To clarify further, imapd used to report \NoInferiors for INBOX 
unconditionally, which had the effect of enforcing the "no children of 
INBOX" policy.  But since the dual-use formats (mix, mx, and mh) don't 
actually prohibit the creation of children (*IF* you get the case right), 
some people who understaood the limitations reported that their clients 
crapped out when it got a \NoInferiors INBOX but then children.

So, what's there now is a compromise.  I still urge people "don't go 
there, here be dragons"... ;-)

-- 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 <at> u.washington.edu
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
Permalink | Reply |
headers
Joel Reicher | 18 Apr 07:51

Re: Childless mix INBOX lacking \HasNoChildren?

> 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...
(Continue reading)

Permalink | Reply |
headers
Mark Crispin | 18 Apr 08:28

Re: Childless mix INBOX lacking \HasNoChildren?

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.
(Continue reading)

Permalink | Reply |
headers
Joel Reicher | 18 Apr 14:20

Re: Childless mix INBOX lacking \HasNoChildren?

> 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
(Continue reading)

Permalink | Reply |
headers
Mark Crispin | 18 Apr 17:33

Re: Childless mix INBOX lacking \HasNoChildren?

On Fri, 18 Apr 2008, Joel Reicher wrote:
> 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.

Yes.  Just pull that code that tests for a dual-use format, and do the 
obvious simple version.

The original code (which is what you propose reverting to) was right and 
should have been left alone.  Someone deliberately went around the 
protocol-stated restriction; and then complained that his client core 
dumped when it got LIST results that reported a \NoInferiors INBOX along 
with children of INBOX.  I gave in to his complaint.  This email thread is 
my punishment for not taking a hard line and saying "no".

Sigh.

-- 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 <at> u.washington.edu
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
Permalink | Reply |
headers
Michael Cashwell | 18 Apr 15:09

Re: Childless mix INBOX lacking \HasNoChildren?

On Apr 18, 2008, at 8:20 AM, Joel Reicher wrote:

>> 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 must be being dense here, but isn't having an inferior to INBOX  
named identically but with only case differences a very special case?  
Wouldn't it make more sense to prohibit only that similar to how a  
case-preserving but case-insensitive file system won't let you create  
"foo" where "Foo" already exists?

Having inferiors to INBOX called anything else would not be ambiguous,  
right? To prohibit ALL inferiors on INBOX just to avoid this one  
instance of case-ambiguity seems like overkill.

But I'm likely not understanding something basic.

-Mike
(Continue reading)

Permalink | Reply |
headers
Mark Crispin | 18 Apr 17:42

Re: Childless mix INBOX lacking \HasNoChildren?

On Fri, 18 Apr 2008, Michael Cashwell wrote:
> I must be being dense here, but isn't having an inferior to INBOX named 
> identically but with only case differences a very special case? Wouldn't it 
> make more sense to prohibit only that similar to how a case-preserving but 
> case-insensitive file system won't let you create "foo" where "Foo" already 
> exists?

The problem is not with the children, but rather the parent.  You are 
assuming, falsely, that there is something magic that will take 
"inbox/foo" and know that it really must be "INBOX/foo" even though there 
is nothing in the IMAP specification (or most UNIX filesystems) that says 
so.

Even if imapd attempted to impose such magic, there is nothing that it can 
do about filesystem operations outside of IMAP.  That is the underlying 
cause of the problem.

> Having inferiors to INBOX called anything else would not be ambiguous, right? 
> To prohibit ALL inferiors on INBOX just to avoid this one instance of 
> case-ambiguity seems like overkill.

That's like saying it is overkill to have laws against drunk driving, 
because you can drive safely while drunk.  Even if that is true in your 
particular case, it is not true in the general case.

It is never a good idea to create greater complexity to overcome the 
problems brought about by adding earlier complexity.

IMAP was never intended to allow children of INBOX.  In fact, IMAP was 
never intended to allow children of any mailbox.  It was a terrible
(Continue reading)

Permalink | Reply |
headers
Michael Cashwell | 18 Apr 18:47

Re: Childless mix INBOX lacking \HasNoChildren?

On Apr 18, 2008, at 11:42 AM, Mark Crispin wrote:

> On Fri, 18 Apr 2008, Michael Cashwell wrote:
>
>> I must be being dense here, but isn't having an inferior to INBOX  
>> named identically but with only case differences a very special  
>> case? Wouldn't it make more sense to prohibit only that similar to  
>> how a case-preserving but case-insensitive file system won't let  
>> you create "foo" where "Foo" already exists?
>
> The problem is not with the children, but rather the parent.  You  
> are assuming, falsely, that there is something magic that will take  
> "inbox/foo" and know that it really must be "INBOX/foo" even though  
> there is nothing in the IMAP specification (or most UNIX  
> filesystems) that says so.

But that's what I'm not getting. Doesn't it map "inbox" to "INBOX" as  
a special case already? If not, then "inbox/foo" should fail. If so,  
why is mapping "inbox/foo" to "INBOX/foo" worse?

> Even if imapd attempted to impose such magic, there is nothing that  
> it can do about filesystem operations outside of IMAP.  That is the  
> underlying cause of the problem.

Do you mean other apps that use c-client or apps that fiddle with the  
backing store totally on their own?

If the latter then they deserve what they get. If the former then is  
the problem expecting (or inserting) IMAP semantics when IMAP is not  
really involved? I could see that being a mistake.
(Continue reading)

Permalink | Reply |
headers
Mark Crispin | 18 Apr 19:14

Re: Childless mix INBOX lacking \HasNoChildren?

This thread is closed.

-- 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 <at> u.washington.edu
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
Permalink | Reply |
headers
Esh, Thomas D (Tom | 18 Apr 15:57

RE: Childless mix INBOX lacking \HasNoChildren?


Interesting, my interpretation of the spec is that
only the "inbox" part is case-insensitive.
The other parts of the mailbox name are still case-sensitive.

So all these strings refer to the same mailbox:

inbox/test
Inbox/test
iNbOx/test
INBOX/test

While these are two different mailboxes:

inbox/Test
inbox/test

I believe this is how the Courier IMAP server is implemented.

Tom

Thomas D. Esh
Alcatel-Lucent
Room 4O05-1L
6100 East Broad Street
Columbus, OH  43213
Email: esh <at> alcatel-lucent.com
Work: 614-367-4390
Mobile: 740-334-2319
Home: 740-321-1245
(Continue reading)

Permalink | Reply |
headers
Mark Crispin | 18 Apr 17:27

RE: Childless mix INBOX lacking \HasNoChildren?

On Fri, 18 Apr 2008, Esh, Thomas D (Tom) wrote:
> Interesting, my interpretation of the spec is that
> only the "inbox" part is case-insensitive.
> The other parts of the mailbox name are still case-sensitive.

That is *a* interpretation of the specification.  There are other, equally 
valid, interpretations.  It's an ambiguity.

This is because the specification never intended that there be children of 
INBOX.  I, of all people, should know.

A further complication is that since the INBOX in mix format is a 
directory called "INBOX", nothing prevents the creation (on most UNIX 
filesystems) of a different directory called "inbox", "Inbox", "iNbOx", 
etc.; all of which are separate entities in the filesystem.

Children of INBOX are not supported.  They will never be supported. 
There are, and always will be, undesirable effects.  Over time, the 
undesirable effects will change in unpredictable ways.

> I believe this is how the Courier IMAP server is implemented.

Given that Courier violates the IMAP specification in many ways where the 
specification is explicit and unambiguous, that's hardly a recommendation! 
;-)

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
(Continue reading)

Permalink | Reply |

Gmane