mailing list archives

Besides Cyrus, what other servers offer a wildcard in the userid field for 
other users?

For example, given a server which exports
 	(("" "/")) (("/Users/" "/")) (("/Public" "/"))

what servers permit a client to do:
 	tag LIST "" /Users/*

To follow-up on my previous question, what clients besides Thunderbird 
attempt to do such a command?

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

On Wed, 2009-11-18 at 10:33 -0800, Mark Crispin wrote:
> Besides Cyrus, what other servers offer a wildcard in the userid field for 
> other users?
> 
> For example, given a server which exports
>  	(("" "/")) (("/Users/" "/")) (("/Public" "/"))
> 
> what servers permit a client to do:
>  	tag LIST "" /Users/*

Dovecot, if configured to do so. And of course not all users, only those
that have mailboxes with +l permission to LISTing user.

> To follow-up on my previous question, what clients besides Thunderbird 
> attempt to do such a command?

If that didn't work, I think shared namespaces would be almost unusable
in most IMAP clients. Clients don't support accessing mailboxes that
they can't LIST (or LSUB, but subscribing would again require LIST to
show them).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 204 bytes
Desc: This is a digitally signed message part
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20091118/30d4e7e0/attachment.sig>

On Wed, 18 Nov 2009, Timo Sirainen wrote:
>> For example, given a server which exports
>>  	(("" "/")) (("/Users/" "/")) (("/Public" "/"))
>> what servers permit a client to do:
>>  	tag LIST "" /Users/*
> Dovecot, if configured to do so. And of course not all users, only those
> that have mailboxes with +l permission to LISTing user.

Does Dovecot configure this by default?  Why or why not?

Does Dovecot scan the entire private user tree looking for +l mailboxes, 
or does it have a reverse cache of accessible names?  Or does it have a 
global ACL database?

>> To follow-up on my previous question, what clients besides Thunderbird
>> attempt to do such a command?
> If that didn't work, I think shared namespaces would be almost unusable
> in most IMAP clients. Clients don't support accessing mailboxes that
> they can't LIST (or LSUB, but subscribing would again require LIST to
> show them).

Please note that I am talking about access to other users' mailboxes and 
not to shared mailboxes.  Of course,
 	tag LIST "" /Public/*
should work in the above example.

What I am trying to determine is the use case for
 	tag LIST "" /Users/*

Is it really true that clients must be able to download a complete tree of 
all possible names in order to be able to access a name?

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

On Wed, 2009-11-18 at 11:00 -0800, Mark Crispin wrote:
> On Wed, 18 Nov 2009, Timo Sirainen wrote:
> >> For example, given a server which exports
> >>  	(("" "/")) (("/Users/" "/")) (("/Public" "/"))
> >> what servers permit a client to do:
> >>  	tag LIST "" /Users/*
> > Dovecot, if configured to do so. And of course not all users, only those
> > that have mailboxes with +l permission to LISTing user.
> 
> Does Dovecot configure this by default?  Why or why not?
> 
> Does Dovecot scan the entire private user tree looking for +l mailboxes, 
> or does it have a reverse cache of accessible names?  Or does it have a 
> global ACL database?

Dovecot uses a database which gets updated when SETACL command is used.
When doing a LIST, it looks up from the database what users probably
have +l mailboxes and then actually verifies that they do before
returning them in LIST.

I guess you could call the database a reverse cache, although there's
currently no way to easily rebuild it so it's less of a cache.. So for
example if a user1 had set +l for foogroup and baruser, and user2 had
set +l for baruser, the database would have entries like:

group=foogroup -> user1
user=baruser -> user1
user=baruser -> user2

This isn't done by default, because Dovecot doesn't really have any
default configuration. It wouldn't really know how to access other
users' mailboxes. It wouldn't know where to store the database. Besides,
the database can be configured in multiple different ways. Admin could
configure a global database file, a per-domain database file, or
everything could be stored in SQL.

If Dovecot had a default configuration, I'd enable this by default.
"anyone" and "anonymous" identifiers are special cases though, SETACLs
to those are disallowed by default to prevent spamming.

> >> To follow-up on my previous question, what clients besides Thunderbird
> >> attempt to do such a command?
> > If that didn't work, I think shared namespaces would be almost unusable
> > in most IMAP clients. Clients don't support accessing mailboxes that
> > they can't LIST (or LSUB, but subscribing would again require LIST to
> > show them).
> 
> Please note that I am talking about access to other users' mailboxes and 
> not to shared mailboxes.  Of course,
>  	tag LIST "" /Public/*
> should work in the above example.
> 
> What I am trying to determine is the use case for
>  	tag LIST "" /Users/*

I don't think any client treats those two cases differently. They just
want LIST to see everything.

> Is it really true that clients must be able to download a complete tree of 
> all possible names in order to be able to access a name?

Do you mean * or also %? I don't know what clients use * vs. %, but I
don't see why * would be any more difficult to implement than %. In any
case I'm not aware of any clients that can access (other users')
mailboxes that can't be reached by LISTing from root level.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 204 bytes
Desc: This is a digitally signed message part
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20091118/0ece228f/attachment.sig>

> > Is it really true that clients must be able to download a complete
> > tree of all possible names in order to be able to access a name?
> 
> In any case I'm not aware of any clients that can access (other
> users') mailboxes that can't be reached by LISTing from root level.

I believe that Thunderbird allows this as well.

On Wed, 2009-11-18 at 11:29 -0800, Dan Karp wrote:
> > > Is it really true that clients must be able to download a complete
> > > tree of all possible names in order to be able to access a name?
> > 
> > In any case I'm not aware of any clients that can access (other
> > users') mailboxes that can't be reached by LISTing from root level.
> 
> I believe that Thunderbird allows this as well.

You mean Thunderbird could allow accessing mailboxes it can't LIST among
regular mailboxes? How? I won't believe it until I see it myself. :) I
didn't see any obvious ways to do that.

There's of course the ways to override the namespace roots. So I suppose
if you wanted to access user foo's mailboxes, you could set the shared
namespace root to /Users/foo/, but that's not very user friendly.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 204 bytes
Desc: This is a digitally signed message part
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20091118/d6ec9ba9/attachment.sig>

> You mean Thunderbird could allow accessing mailboxes it can't LIST
> among regular mailboxes? How? I won't believe it until I see it
> myself. :) I didn't see any obvious ways to do that.

Not sure, but heard that it's possible.  I certainly could be wrong.
But given that the NAMESPACE RFC explicitly allows servers to permit
direct access to a given other user's mailboxes while returning NO
to a wildcarded LIST, I'd think that a good client would *have* to
do something along those lines...

On Wed, 2009-11-18 at 11:43 -0800, Dan Karp wrote:
> > You mean Thunderbird could allow accessing mailboxes it can't LIST
> > among regular mailboxes? How? I won't believe it until I see it
> > myself. :) I didn't see any obvious ways to do that.
> 
> Not sure, but heard that it's possible.  I certainly could be wrong.
> But given that the NAMESPACE RFC explicitly allows servers to permit
> direct access to a given other user's mailboxes while returning NO
> to a wildcarded LIST, I'd think that a good client would *have* to
> do something along those lines...

Sure, but there aren't many good IMAP clients..

Actually I think the whole idea of listing other users' shared mailboxes
without having to explicitly opt-in isn't such a good idea. It's way too
easy to spam others by just sharing your mailboxes to them. The process
should be:

1. foo shares mailbox to bar
2. foo tells bar via email/phone/whatever that he has shared a mailbox
3. bar clicks something and types foo's name
4. foo's shared mailboxes are now appear in LIST to bar
..
x. bar clicks something to get a list of users/groups whose mailboxes
he's accepted. he can delete entries from the list and those users'
shared mailboxes disappear from LIST.

But the "clicks something" part would require some web UI or a new IMAP
extension or something, so for now at least it's not really an option.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 204 bytes
Desc: This is a digitally signed message part
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20091118/c7ffbdf3/attachment.sig>

On Wed, 18 Nov 2009, Timo Sirainen wrote:
> Actually I think the whole idea of listing other users' shared mailboxes
> without having to explicitly opt-in isn't such a good idea. It's way too
> easy to spam others by just sharing your mailboxes to them.

This is my point in a current discussion.

Also, I can think of a case where "accessible" and "published" should be 
very different.  The fact that something can be listed does not mean that 
it should be published.

Consider that I am organizing a class reunion, and have created an account 
and a series of mailboxes in my private space for that purpose.  Since I 
don't know everybody's id (or even everybody) in the far-flung class, I 
give access to anyone.  I then pass on the word to those people I know 
that "the class reunion information is in the mrc-class account", and this 
is passed on by these to others.

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?

Thus, I consider "publishing to shared" and "making accessible via access 
control" to be two separate things, and that the +l right by itself does 
not constitute publication.

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

On Wed, 2009-11-18 at 12:18 -0800, Mark Crispin wrote:
> On Wed, 18 Nov 2009, Timo Sirainen wrote:
> > Actually I think the whole idea of listing other users' shared mailboxes
> > without having to explicitly opt-in isn't such a good idea. It's way too
> > easy to spam others by just sharing your mailboxes to them.
> 
> This is my point in a current discussion.

If there was a reasonable way to do the opt-in, I'd add support for that
in Dovecot and do it as default. But since no one has asked for this
feature and the only way to implement it would be via non-standard IMAP
command or messing directly with Dovecot's database, it's just too much
trouble with no benefit to anyone.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 204 bytes
Desc: This is a digitally signed message part
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20091118/0618f4c1/attachment.sig>

On Wed, 18 Nov 2009, Mark Crispin wrote:
> Also, I can think of a case where "accessible" and "published" should be 
> very different.  The fact that something can be listed does not mean 
> that it should be published.
...
> 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.  What you're 
talking about here is some finer granularity within LIST/LSUB, where 
'broader' operations such as
	tag LIST "" *
require more than +l on some classes of mailboxes for them to be returned, 
or maybe that 'narrower' operations such as
	tag LIST "" /Users/mrc/%
require less than +l.

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


Philip Guenther

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.