[Dovecot] Thunderbird namespace handling
Hello,
I've noticed that Thunderbird (3.0.3) seems to wrongly "repeat" the namespace prefix when selecting the top level maildir of a namesapce.
It doesn't occur if "list=yes" and TB has no clue about the namespace prefix. But it seems to happen only when TB is aware of the namespace prefix, either via the NAMESPACE command (so in "hidden=no" setups) or via hard setting it up in the "Account Settings".
For instance, if
location = maildir:/courriel/boites/test:CONTROL=/courriel/meta/test hidden = no list = yes
Trying to select the mailbox which appears as "#test" in the UI gives
4 select "#test/#test"
in rawlogs, giving for the user a "Mailbox doesn't exist" error, whereas, via telnet, I can :
x select "#test"
- FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
- OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft *)] Flags permitted.
- 2 EXISTS
- 0 RECENT
- OK [UIDVALIDITY 1271768576] UIDs valid
- OK [UIDNEXT 3] Predicted next UID
- OK [HIGHESTMODSEQ 3] Highest
x OK [READ-WRITE] Select completed.
The same happens with any combination of (hidden=, list=, "Allow Server to override [the namesapce] settings") where TB knows about the namespace.
Any ideas ?
Thanks.
On Thu, 2010-04-22 at 15:31 +0200, Thomas Hummel wrote:
I've noticed that Thunderbird (3.0.3) seems to wrongly "repeat" the namespace prefix when selecting the top level maildir of a namesapce.
hidden = no list = yes
This combination is arguably a wrong way to define namespaces.
The same happens with any combination of (hidden=, list=, "Allow Server to override [the namesapce] settings") where TB knows about the namespace.
So hidden=no, list=no also repeats the prefix? Anyway, I've no idea why TB would do that.
On Tue, May 25, 2010 at 07:04:13PM +0100, Timo Sirainen wrote:
On Thu, 2010-04-22 at 15:31 +0200, Thomas Hummel wrote:
I've noticed that Thunderbird (3.0.3) seems to wrongly "repeat" the namespace prefix when selecting the top level maildir of a namesapce.
hidden = no list = yes
This combination is arguably a wrong way to define namespaces.
I missed your reply :
What's wrong with this combination ?
On ke, 2010-06-09 at 18:58 +0200, Thomas Hummel wrote:
On Tue, May 25, 2010 at 07:04:13PM +0100, Timo Sirainen wrote:
On Thu, 2010-04-22 at 15:31 +0200, Thomas Hummel wrote:
I've noticed that Thunderbird (3.0.3) seems to wrongly "repeat" the namespace prefix when selecting the top level maildir of a namesapce.
hidden = no list = yes
This combination is arguably a wrong way to define namespaces.
I missed your reply :
What's wrong with this combination ?
See this thread: http://mailman2.u.washington.edu/pipermail/imap-protocol/2010-May/001076.htm...
On Wed, Jun 09, 2010 at 06:17:49PM +0100, Timo Sirainen wrote:
On ke, 2010-06-09 at 18:58 +0200, Thomas Hummel wrote:
On Tue, May 25, 2010 at 07:04:13PM +0100, Timo Sirainen wrote:
On Thu, 2010-04-22 at 15:31 +0200, Thomas Hummel wrote:
I've noticed that Thunderbird (3.0.3) seems to wrongly "repeat" the namespace prefix when selecting the top level maildir of a namesapce.
hidden = no list = yes
This combination is arguably a wrong way to define namespaces.
I missed your reply :
What's wrong with this combination ?
See this thread: http://mailman2.u.washington.edu/pipermail/imap-protocol/2010-May/001076.htm...
I've read it but I still don't get the point :
I thought "hidden = no" would advertise this namespace for clients which support NAMESPACE and that "list = yes" would allow clients which don't support NAMESPACE to access this namespace ?
What's wrong with that ?
On to, 2010-06-10 at 18:18 +0200, Thomas Hummel wrote:
See this thread: http://mailman2.u.washington.edu/pipermail/imap-protocol/2010-May/001076.htm...
I've read it but I still don't get the point :
I thought "hidden = no" would advertise this namespace for clients which support NAMESPACE and that "list = yes" would allow clients which don't support NAMESPACE to access this namespace ?
What's wrong with that ?
The point of that thread was: With list=yes the client already can access the mailboxes in it without knowing anything about namespaces, so listing it also in namespaces is pointless.
On Fri, Jun 11, 2010 at 02:48:57PM +0100, Timo Sirainen wrote:
On to, 2010-06-10 at 18:18 +0200, Thomas Hummel wrote:
See this thread: http://mailman2.u.washington.edu/pipermail/imap-protocol/2010-May/001076.htm...
I've read it but I still don't get the point :
I thought "hidden = no" would advertise this namespace for clients which support NAMESPACE and that "list = yes" would allow clients which don't support NAMESPACE to access this namespace ?
What's wrong with that ?
The point of that thread was: With list=yes the client already can access the mailboxes in it without knowing anything about namespaces, so listing it also in namespaces is pointless.
The thread you pointed insisted on the fact that the list "" * command should not cross namespaces boudaries. So how can a client list mailboxes of a namespace if it doesn't discover the namespace name first ?
That's why I thought :
. a modern client which supports NAMESPACE, will discover the namespace name (hidden=no) and list it's content (list=yes).
. an old or bad client which doesn't support NAMESPACE will have to have the namespace(s) hard-coded in its' config
But maybe you mean that dovecot list the namespace content anyway if list = yes without having the need for the client to know anything about the namespace ? In that case, wouldn't it break the "list don't cross namespace boundaries" ?
On pe, 2010-06-11 at 15:56 +0200, Thomas Hummel wrote:
The thread you pointed insisted on the fact that the list "" * command should not cross namespaces boudaries.
Right.
So how can a client list mailboxes of a namespace if it doesn't discover the namespace name first ?
It couldn't.
That's why I thought :
. a modern client which supports NAMESPACE, will discover the namespace name (hidden=no) and list it's content (list=yes).
Or possibly list its contents twice, in two namespaces..
But maybe you mean that dovecot list the namespace content anyway if list = yes without having the need for the client to know anything about the namespace ? In that case, wouldn't it break the "list don't cross namespace boundaries" ?
Yes. hidden=no, list=yes configuration breaks the "list doesn't cross namespace boundaries". That's why I said it's arguably wrong to use such configuration.
With hidden=no, list=no it works the way namespaces were intended to work, but few clients show the namespace's contents then. That's why Mark was talking about his chimera namespace (which is similar to Dovecot's hidden=yes, list=yes namespaces) and the idea of maybe getting rid of namespaces completely.
On Fri, Jun 11, 2010 at 03:13:11PM +0100, Timo Sirainen wrote:
Yes. hidden=no, list=yes configuration breaks the "list doesn't cross namespace boundaries". That's why I said it's arguably wrong to use such configuration.
I do understand why we don't want to break namespaces boudaries. But I don't understand why hidden=no, list=yes breaks it. I must have a wrong understanding of the list=yes semantic.
I thought that hidden=no would provide no means for the client to know about the namespace and that list=yes would allow to list mailboxes in the namespace only if we somehow know the name of the namespace and specify it in the list command.
You seem to imply that a client who would do list "" * would list the mailboxes of all namespaces configured with list=yes. I thought it would list only the default namespace mailboxes.
On pe, 2010-06-11 at 16:38 +0200, Thomas Hummel wrote:
I thought that hidden=no would provide no means for the client to know about the namespace
Right.
and that list=yes would allow to list mailboxes in the namespace only if we somehow know the name of the namespace and specify it in the list command.
No. The list=yes means if the parent namespace should include this namespace's mailboxes in its LIST reply, i.e. break namespace boundaries.
If you know the namespace prefix, its mailboxes are always listable. There wouldn't really be any point in a namespace whose contents couldn't be listed..
You seem to imply that a client who would do list "" * would list the mailboxes of all namespaces configured with list=yes.
Correct.
On Fri, Jun 11, 2010 at 03:41:29PM +0100, Timo Sirainen wrote:
No. The list=yes means if the parent namespace should include this namespace's mailboxes in its LIST reply, i.e. break namespace boundaries.
Not sure we're talking about the same thing. Let's say I have :
x namespace
- NAMESPACE (("" "/")) (("#shared/" "/")) NIL
x OK Namespace completed.
If the shared namespace is configured with list=yes. Can a client list this namespace mailboxes without specifying somewhere in the list command arguments the prefix "#shared/" ? Is yes, how and why ?
Has it something to do with the parent namespace beeing always, at a top level the default (i.e. wihthout prefix) namespace ?
If it cannot, there's no "crossing namespace boundaries" pb. There is only a problem for this client if it doesn't support NAMESPACE or doesn't have the namespace prefix somewhere in its conf.
On pe, 2010-06-11 at 16:52 +0200, Thomas Hummel wrote:
On Fri, Jun 11, 2010 at 03:41:29PM +0100, Timo Sirainen wrote:
No. The list=yes means if the parent namespace should include this namespace's mailboxes in its LIST reply, i.e. break namespace boundaries.
Not sure we're talking about the same thing. Let's say I have :
x namespace
- NAMESPACE (("" "/")) (("#shared/" "/")) NIL
x OK Namespace completed.
If the shared namespace is configured with list=yes. Can a client list this namespace mailboxes without specifying somewhere in the list command arguments the prefix "#shared/" ? Is yes, how and why ?
If client does LIST "" * it sees:
..
- LIST (\Noselect) "#shared"
- LIST (\Noselect) "#shared/user"
- LIST () "#shared/user/box"
..
Has it something to do with the parent namespace beeing always, at a top level the default (i.e. wihthout prefix) namespace ?
If you had namespaces with prefixes "#shared/" and "foobar/", doing a LIST "" * would still show both namespaces' mailboxes. Of course LIST "" foobar/* wouldn't show #shared/*.
If it cannot, there's no "crossing namespace boundaries" pb.
Crossing namespace boundaries means a single LIST command listing mailboxes from more than one namespace.
On Fri, Jun 11, 2010 at 04:01:27PM +0100, Timo Sirainen wrote:
Crossing namespace boundaries means a single LIST command listing mailboxes from more than one namespace.
Ok, so basically, "list=yes" means "when you list my parent namespace content, list my content too". And since all namespaces are default namespace children (since it's the one with an empty prefix), any namespace with "list=yes" will be listed (and their content) by a list "" * command, correct ?
Or, said in a simple way : list=yes == list "" * breaks namespace boudaries ?
On pe, 2010-06-11 at 17:07 +0200, Thomas Hummel wrote:
On Fri, Jun 11, 2010 at 04:01:27PM +0100, Timo Sirainen wrote:
Crossing namespace boundaries means a single LIST command listing mailboxes from more than one namespace.
Ok, so basically, "list=yes" means "when you list my parent namespace content, list my content too". And since all namespaces are default namespace children (since it's the one with an empty prefix), any namespace with "list=yes" will be listed (and their content) by a list "" * command, correct ?
Yes.
Or, said in a simple way : list=yes == list "" * breaks namespace boudaries ?
Yes. (But with hidden=yes it's not a client-visible namespace so it's ok.)
On Fri, Jun 11, 2010 at 04:29:07PM +0100, Timo Sirainen wrote:
Yes. (But with hidden=yes it's not a client-visible namespace so it's ok.)
So, if I do the combinatorics :
a) hidden = no list = no
-> the "best" or "cleaner" way to define namespace since it rewards clients which support NAMESPACE command ?
b) hidden = no list = yes
-> makes no sense to advertise a namespace which is always visible.
c) hidden = yes list = no
-> setting up namespaces in client config is mandatory
d) hidden = yes list = yes
-> a setup where we don't want to support namespaces at all
Correct ?
On pe, 2010-06-11 at 17:45 +0200, Thomas Hummel wrote:
On Fri, Jun 11, 2010 at 04:29:07PM +0100, Timo Sirainen wrote:
Yes. (But with hidden=yes it's not a client-visible namespace so it's ok.)
So, if I do the combinatorics :
a) hidden = no list = no
-> the "best" or "cleaner" way to define namespace since it rewards clients which support NAMESPACE command ?
b) hidden = no list = yes
-> makes no sense to advertise a namespace which is always visible.
c) hidden = yes list = no
-> setting up namespaces in client config is mandatory
Most commonly used for "compatibility namespaces", where client e.g. already has configured ~/mail/ prefix in UW-IMAP ages, and you want to have such namespace point to the default namespace.
d) hidden = yes list = yes
-> a setup where we don't want to support namespaces at all
Correct ?
Yes.
On Fri, Jun 11, 2010 at 05:26:30PM +0100, Timo Sirainen wrote:
Correct ?
Yes.
Thanks a lot Timo !
On Wed, Jun 09, 2010 at 06:58:40PM +0200, Thomas Hummel wrote:
On Tue, May 25, 2010 at 07:04:13PM +0100, Timo Sirainen wrote:
On Thu, 2010-04-22 at 15:31 +0200, Thomas Hummel wrote:
I've noticed that Thunderbird (3.0.3) seems to wrongly "repeat" the namespace prefix when selecting the top level maildir of a namesapce.
hidden = no list = yes
This combination is arguably a wrong way to define namespaces.
As I was editing my 10-mail.conf file, I thought about this old thread.
While I agree with you about the nonsense to hide a namespace which is listed anyway, I noticed that this is still the default in the private namespace example which is commented out in this file.
On Mon, 2010-08-09 at 19:12 +0200, Thomas Hummel wrote:
I've noticed that Thunderbird (3.0.3) seems to wrongly "repeat" the namespace prefix when selecting the top level maildir of a namesapce.
hidden = no list = yes
This combination is arguably a wrong way to define namespaces.
As I was editing my 10-mail.conf file, I thought about this old thread.
While I agree with you about the nonsense to hide a namespace which is listed anyway, I noticed that this is still the default in the private namespace example which is commented out in this file.
Well .. okay, prefix="" namespace is an exception to the above rule. :)
On Mon, Aug 09, 2010 at 06:17:06PM +0100, Timo Sirainen wrote:
On Mon, 2010-08-09 at 19:12 +0200, Thomas Hummel wrote:
I've noticed that Thunderbird (3.0.3) seems to wrongly "repeat" the namespace prefix when selecting the top level maildir of a namesapce.
hidden = no list = yes
This combination is arguably a wrong way to define namespaces.
As I was editing my 10-mail.conf file, I thought about this old thread.
While I agree with you about the nonsense to hide a namespace which is listed anyway, I noticed that this is still the default in the private namespace example which is commented out in this file.
Well .. okay, prefix="" namespace is an exception to the above rule. :)
Why has it to be an exception ? Your previous points still stand, don't they ? :
. isn't there a risk that the default namespace gets listed twice then ?
. what's the point of not hiding a namespace which can be listed in any case ?
-- Thomas Hummel
On 9.8.2010, at 20.35, Thomas Hummel wrote:
Well .. okay, prefix="" namespace is an exception to the above rule. :)
Why has it to be an exception ? Your previous points still stand, don't they ? :
. isn't there a risk that the default namespace gets listed twice then ?
. what's the point of not hiding a namespace which can be listed in any case ?
Because listing mailboxes always starts with the namespace that has no prefix. If you have only one namespace with prefix="" and list=no, you wouldn't have any listable mailboxes anywhere.
For example if you have:
namespace { prefix = foo/ list = no }
It won't show up with normal list:
a LIST "" *
But you can list its mailboxes with:
b LIST "" foo/*
But then if you have
namespace { prefix = list = no }
Now both a and b are exactly the same:
ab LIST "" *
On Mon, Aug 09, 2010 at 10:56:21PM +0100, Timo Sirainen wrote:
Because listing mailboxes always starts with the namespace that has no prefix. If you have only one namespace with prefix="" and list=no, you wouldn't have any listable mailboxes anywhere.
For example if you have:
namespace { prefix = foo/ list = no }
It won't show up with normal list:
a LIST "" *
But you can list its mailboxes with:
b LIST "" foo/*
Yes.
But then if you have
namespace { prefix = list = no }
Now both a and b are exactly the same:
ab LIST "" *
You mean it won't list anything, even if I have a mailbox (not a namespace) named foo ?
Anyway, I wasn't thinking about list = no for the default namespace but about hidden = yes. The default in the conf file is list = yes and hidden = no : why not list = yes and hidden = yes (because of the "why advertise a namespace (hidden = no) which is listable (list=yes) anyway" argument) ?
On 10.8.2010, at 7.56, Thomas Hummel wrote:
But then if you have
namespace { prefix = list = no }
Now both a and b are exactly the same:
ab LIST "" *
You mean it won't list anything, even if I have a mailbox (not a namespace) named foo ?
Right. That's what list=no does with prefix="" namespace (this was actually a recent addition, previously it simply said it's an invalid configuration).
Anyway, I wasn't thinking about list = no for the default namespace but about hidden = yes. The default in the conf file is list = yes and hidden = no : why not list = yes and hidden = yes (because of the "why advertise a namespace (hidden = no) which is listable (list=yes) anyway" argument) ?
The point of namespace list was for clients to be able to figure out what the namespaces there are. With list=yes and hidden=yes for your only namespace you wouldn't be listing any namespaces, so clients would think you don't have any personal namespaces at all..
On Tue, Aug 10, 2010 at 12:52:48PM +0100, Timo Sirainen wrote:
The point of namespace list was for clients to be able to figure out what the namespaces there are. With list=yes and hidden=yes for your only namespace you wouldn't be listing any namespaces, so clients would think you don't have any personal namespaces at all..
You are now confusing me :
My understanding of "list = yes" was "while you're listing my parent namespace's content, list my content as well" or. That is, to me, the "list=yes" totally voids the concept of namespace.
So basically if a client doesn't support NAMESPACE command at all (and if it hasn't any clue in its conf about what the namespaces are), it has to rely on list=yes.
Maybe your sentence above means "if a client who plays by the rules (via NAMESPACE command) and hidden=yes, won't even see the default namespace."
But if so, that would be weird that a bad client would be able to list mailboxes and not a good client ?
Or said in another way, I don't understand why list=yes isn't enough in anycase to list a namespace content.
On 10.8.2010, at 18.10, Thomas Hummel wrote:
On Tue, Aug 10, 2010 at 12:52:48PM +0100, Timo Sirainen wrote:
The point of namespace list was for clients to be able to figure out what the namespaces there are. With list=yes and hidden=yes for your only namespace you wouldn't be listing any namespaces, so clients would think you don't have any personal namespaces at all..
You are now confusing me :
My understanding of "list = yes" was "while you're listing my parent namespace's content, list my content as well" or. That is, to me, the "list=yes" totally voids the concept of namespace.
Yes. And with prefix="" there is no parent.
Maybe your sentence above means "if a client who plays by the rules (via NAMESPACE command) and hidden=yes, won't even see the default namespace."
Yeah, that's what I meant.
But if so, that would be weird that a bad client would be able to list mailboxes and not a good client ?
Right. And that's why one personal namespace with prefix="" and hidden=yes isn't good. :)
Or said in another way, I don't understand why list=yes isn't enough in anycase to list a namespace content.
Like you said above, if client issues NAMESPACE command and sees that there are no personal namespaces, it might not try to list anything (because NAMESPACE reply said there isn't anything).
participants (2)
-
Thomas Hummel
-
Timo Sirainen