MBOX-Line: From vladimir_butenko at stalker.com  Mon Apr 10 13:51:20 2006
To: imap-protocol@u.washington.edu
From: "Vladimir A. Butenko" <vladimir_butenko@stalker.com>
Date: Fri Jun  8 12:34:37 2018
Subject: [Imap-protocol] LIST Clarification
In-Reply-To: <Pine.OSX.4.64.0604101053530.2906@pangtzu.panda.com>
References: <443A7A2D.2070708@consilient.com> <web-35034698@mail.stalker.com>
	<Pine.OSX.4.64.0604101053530.2906@pangtzu.panda.com>
Message-ID: <web-35035906@mail.stalker.com>

On Mon, 10 Apr 2006 11:14:08 -0700 (PDT)
  Mark Crispin <mrc@cac.washington.edu> wrote:
> Vladimir's interpretation is valid.  The LIST argument is definitely not a 
>mailbox name.
> 
> However, I disagree about it being useful or desirable compared to other 
>interpretations.  In particular, I do not think that it is useful or 
>desirable for a server to respond to
> 	tag LIST "" inbox
> with no data because of case-mismatch with INBOX.

One of the biggest problem with any protocol are "useful exceptions". It has 
been proven too many times that whereever a problem (or misunderstanding) 
can emerge, it will emerge.
  
> The case of
> 	tag LIST "" In%B%
> is less clear, particularly given that the specification says "uppercase 
>string" instead of "case-insensitive" string.
> 
> However, the kicker is that (as Vladimir notes) INBOX may be included in 
>the output with a case-insensitive server.  I disagree with Vladimir's 
>interpretation that the specification forces INBOX to be case-sensitive in 
>LIST even on a case-insensitive server

I did not say that. I've said that (according to the written standard):

a) when interpreting a command with a mailbox name parameter, the server 
should interpret any combination of the InBoX letters as a reference to the 
INBOX name (which is supposed to be a [virtual] name for the mailbox 
accepting incoming mail).

b) when interpreting the LIST command and its argument (which is a pattern, 
not a mailbox name), the special "incoming" mailbox name matches it if the 
name INBOX (all caps) matches the specified pattern.

If a server happens to use case-insensitive names, and, as a result, all 
operations (including the pattern match) are case insensitive, then search 
results can be different when compared to case-sensitive systems.

The IMAP protocol does not explicitly specify what the REAL NAME of the 
"incoming mailbox" is. If it would specify that the name is INBOX, it would 
eliminate a lot of misunderstanding. Unfortunately, it does not.

> as well as the notion of a "regular 
>mailbox named INBOX" vs. a "special name INBOX" (that is an implementation 
>detail).

>Fortunately, though, this discussion is more academic than practical, for 
>the following reasons:

Unfortunately, it's not the case. The initial request was sent to our 
support group because the author of the question used "Inbox" as the 
reference to the incoming mailbox. And while it works fine with all SELECT & 
Co commands, it worked OK with LIST only because it was used on a 
case-insensitive platform. Switching to a case-sensitive platform revealed 
the problem.
  
> The specification uses "INBOX" throughout as the canonical form of the 
>name, and hammers on the point that this is case-insensitive.  Postel's 
>robustness principle (this being a correct use!) says that clients should 
>always send the name as "INBOX", and servers should always do a 
>case-insensitive match even when the specification allows a loophole.

This is exactly the answer we have given: using any name instead of INBOX is 
a call for trouble. BUT: there is nothing in the IMAP specs that explicitly 
says so. And many people who do not know (and have no reason to know) about 
all historical details behind the name "INBOX" in all caps, may conclude 
that it's OK to use Inbox as that special mailbox name, especially because 
many UI applications render it this way.

> In the case of a client sending
> 	tag LIST "" inbox
> and getting nothing back, the primary onus is on the client for not using 
>the canonical form.  The server, arguably, is being naughty too; but the 
>loophole exists.
> 
> Although the In%B% case is more troubling, I observe it is not something 
>that generally occurs in real life.  A client which actually uses such a 
>pattern is probably looking for names other than INBOX; but I don't think 
>that I've ever seen a client use such a pattern.
> 
> I think that, although a server should match INBOX to In%B%, Vladimir is 
>correct that it does not have to.  Even with Vladimir's interpretation, it 
>is ambiguous (due to underlying implementation details) whether or not the 
>server would return it.  So a client should not depend upon the behavior 
>either way.

I'd suggest we put all that "reasonable" stuff aside: the standards are the 
standards are the standards. They are created to switch from "reasonable" 
(which is, by definition, different for different souls) to [well-defined] 
"standard" .

The question here is simple:
if
a LIST "" "%n%ox"
should show any name for the incoming mailbox should it
show INBOX? Or Inbox? Or InBox? Or InBOx?

Consider the following:
a) the server should always return the mailbox name in the same "case". If 
the server itself returns INBOX in one response and Inbox in others, it will 
only create confusion (again, a note that this special mailbox DOES have a 
well-defined name, and that name is INBOX would help a lot). The answer - if 
it should return anything, it should return INBOX.

b) If (a) is correct, then the question is:

should
a LIST "" "%n%ox"
return
* INBOX

There is no reason why it should - on a case-sensitive system (on a 
case-insensitive - it can and should). The only special rule about the INBOX 
name that can be used here explicitly says that the upper-case word INBOX 
should be compared against the pattern. On a case-senstive system it will 
not match the pattern. So, the answer is "no".

c) If (b) is correct, then the answer to:
should
a LIST "" "Inbox"
return
* INBOX

is clear: on a case-insensitive system - yes, on a case-sensitive - no. The 
reason is simple: "Inbox" in the LIST command is a pattern, not a name. So, 
see (b). Also, anything that matches the "Inbox" patten, should match the
"%n%ox" pattern, otherwise we need to add "reasonable exceptions" to the "%" 
handling, too. I hope we won't.


> I think that we all agree that the following patterns all match INBOX:
> 	*
> 	%
> 	INBOX
> 	INBOX%
> 	INBOX*
> and the following patterns do NOT match INBOX:
> 	%/%
> 	foo
> 	foo/%
> 	INBOX/*
> 	INBOX/%

Yes. But servers that do not follow strict and well-defined rules do cause 
much more trouble that good. We did observe those servers returning "Inbox" 
when List "Inbox" was called, thus causing clients to display 2 different 
INBOXes, and we saw servers returning "INBOX" for List "i%" ("paged" mailbox 
list display) causing clients to loop (though it's a client problem, as on a 
case-insenstive system this later case is legal).

The "special case" of INBOX is a terrible thing, causing many problems in 
any case, so we should try to be as strict as possible about it, and not add 
additional "reasonable exceptions".

Clients should carefully process these names, NOT assuming anything not 
already specified in the standard.

More,
a) what about:
  INBOX/mailbox
  InBox/mailbox
  INBOX/mailBOX
  InBox/mailBOX
(our interpretation - 1 and 2 are the same mailbox, 3 and 4 are the same 
mailbox, they all are the same mailbox on a case-insensitive system).

b) what about:
  ~user@domain/INBOX
  ~user@domain/INBoX
  ~user@domain/INBOX/Mailbox
  ~user@domain/INBoX/Mailbox

or whatever notation is used with that server to access "foreign" mailboxes.
(our interpretation - 1 and 2, 3 and 4 they are the same, the INBOX name is 
a special name not on the top of the mailbox name hierearchy, but on the top 
of the hierarchy for a particular "mailbox set" or "account").

The standard does not really say anything about using INBOX in 
LSUB/SUBSCRIBE - fortunately, almost no client uses mailbox subscriptions 
these days, otherwise it would create even more problems.

Bottom line - we all agree here, I hope:

always use INBOX as the name of the "incoming mail" mailbox.
  
> -- Mark --

Sincerely,
Vladimir

