A previously unreported lsub/list discrepancy in 1.1rc5 and earlier

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

A previously unreported lsub/list discrepancy in 1.1rc5 and earlier

Adam McDougall
Not sure about 1.0, I don't run it anymore :) But a few users discovered
for a small issue that only affects a very small portion of my userbase
where instructional correction will suffice.  I guess I am reporting it
in the interest of getting it out there, and I can live with it if not
fixed but it might be an issue for some people.  I'm running through my
list of issues.  Basically, if a user has a valid namespace prefix set
such as mail/ (used to be required on old mail server but discouraged on
new mail client setups with dovecot), lsub/list do not show public
namespaces that the user has permission to via acl.  If the user removes
the namespace prefix, they can 'see' the public folders and subscribe.  
Additionally if the user subscribes to a public folder then puts mail/
back in the prefix, the folders are no longer listed.   Not sure if
public folders should be affected by the requested prefix in this
manner, since they are not in the user's account.

With prefix set:
3 lsub "" "mail/*"
4 list "" "mail/%"
5 list "" "mail/%/%"

* OK [RAWLOG TIMESTAMP] 2008-05-05 21:07:16
* LSUB () "/" "mail/INBOX"
* LSUB () "/" "mail/Sent Items"
* LSUB () "/" "mail/Drafts"
* LSUB () "/" "mail/Junk E-mail"
* LSUB () "/" "mail/Sent"
* LSUB () "/" "mail/Trash"
3 OK Lsub completed.
* LIST (\HasNoChildren) "/" "mail/Drafts"
* LIST (\HasNoChildren) "/" "mail/Sent Items"
* LIST (\HasNoChildren) "/" "mail/Junk E-mail"
* LIST (\HasNoChildren) "/" "mail/Sent"
* LIST (\HasNoChildren) "/" "mail/Trash"
4 OK List completed.
5 OK List completed.

Without prefix set:
3 lsub "" "*"
4 list "" "%"
5 list "" "%/%"

* OK [RAWLOG TIMESTAMP] 2008-05-05 21:07:49
* LSUB () "/" "INBOX"
* LSUB () "/" "Sent Items"
* LSUB () "/" "Drafts"
* LSUB () "/" "Junk E-mail"
* LSUB () "/" "Sent"
* LSUB () "/" "Trash"
3 OK Lsub completed.
* LIST (\HasNoChildren) "/" "Drafts"
* LIST (\HasNoChildren) "/" "Sent Items"
* LIST (\HasNoChildren) "/" "Junk E-mail"
* LIST (\HasNoChildren) "/" "Sent"
* LIST (\HasNoChildren) "/" "Trash"
* LIST (\HasNoChildren) "/" "INBOX"
4 OK List completed.
* LIST (\Noselect \HasChildren) "/" "#shared/be"
* LIST (\Noselect \HasChildren) "/" "#shared/me"
* LIST (\Noselect \HasChildren) "/" "#shared/cee"
5 OK List completed.

Reply | Threaded
Open this post in threaded view
|

Re: A previously unreported lsub/list discrepancy in 1.1rc5 and earlier

Timo Sirainen
On May 6, 2008, at 4:20 AM, Adam McDougall wrote:

> Not sure about 1.0, I don't run it anymore :) But a few users  
> discovered for a small issue that only affects a very small portion  
> of my userbase where instructional correction will suffice.  I guess  
> I am reporting it in the interest of getting it out there, and I can  
> live with it if not fixed but it might be an issue for some people.  
> I'm running through my list of issues.  Basically, if a user has a  
> valid namespace prefix set such as mail/ (used to be required on old  
> mail server but discouraged on new mail client setups with dovecot),  
> lsub/list do not show public namespaces that the user has permission  
> to via acl.  If the user removes the namespace prefix, they can  
> 'see' the public folders and subscribe.  Additionally if the user  
> subscribes to a public folder then puts mail/ back in the prefix,  
> the folders are no longer listed.   Not sure if public folders  
> should be affected by the requested prefix in this manner, since  
> they are not in the user's account.
>
> With prefix set:
> 3 lsub "" "mail/*"
> 4 list "" "mail/%"
> 5 list "" "mail/%/%"
The client wants to list only maiboxes under mail/.

> * LIST (\Noselect \HasChildren) "/" "#shared/be"

mail/% doesn't match #shared/*, so these don't get returned.

So this is really a problem with using those namespace prefixes on  
clients. I've always wondered how clients would handle shared  
mailboxes when they're set. Now I know: They don't. :)

You could work around this by creating a new "mail/#shared/" namespace.


PGP.sig (201 bytes) Download Attachment