MBOX-Line: From mrc+uw at Panda.COM  Wed Nov 18 13:22:39 2009
To: imap-protocol@u.washington.edu
From: Mark Crispin <mrc+uw@Panda.COM>
Date: Fri Jun  8 12:34:43 2018
Subject: [Imap-protocol] wildcards in other users' namespace
In-Reply-To: <alpine.BSO.2.00.0911181248280.8115@vanye.sendmail.com>
References: <2134052040.817.1258573414683.JavaMail.root@dogfood.zimbra.com>
	<1258574152.3022.695.camel@timo-desktop>
	<alpine.OSX.2.00.0911181212090.244@hsinghsing.panda.com>
	<alpine.BSO.2.00.0911181248280.8115@vanye.sendmail.com>
Message-ID: <alpine.OSX.2.00.0911181308150.244@hsinghsing.panda.com>

On Wed, 18 Nov 2009, Philip Guenther wrote:
>> Should these mailboxes be published to the world due to the anyone
>> rights, and thus show up in everybody's list of mailboxes?  Or, as I
>> contend, just to those who know to look in the mrc-class account?
> Wasn't that the intent of the distinction between +l and +r?  A mailbox
> that is +r-l can be selected if you can enter its name.

I agree that this was the original intent, but it reflects a 1990s mindset 
of security.  The past ~15 years have shown us how deeply flawed that 
mindset is.

The fact that something is accessible, and even discoverable if you know 
the (superior) place to look, should not equate to it being published.

The underlying problem is that there is no right that controls the descent 
of a hierarchy via "*".

> I guess the problem with +r-l is that it is dependent on client support
> for directly entering mailbox names and that is apparently not something
> someone can count on.

Sadly, I agree.  The vast majority of IMAP clients suck; and in many cases 
that suckage is intentional.

When I designed IMAP, I intended a protocol that guaranteed by its design 
that implementations do not (and can not) suck.  The entire reason for 
IMAP's excrutiatingly strict syntax rules was to aid that goal.

I failed utterly in the client space, and failed in much of the server 
space.  I was younger then, and naively believed that I could defeat 
suckage.

> In order to design a fix, what *can* be depended
> on?  The ability of a client to show that /Users/mrc exists at all and
> peek into it with something like that last LIST above?  More?  Less?

That's the difficult problem that we must wrestle with.

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

