Re: [Dovecot] Thunderbird namespace handling
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) ?
Re: [Dovecot] Thunderbird namespace handling
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..
Re: [Dovecot] Thunderbird namespace handling
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. -- Thomas Hummel | Institut Pasteur hum...@pasteur.fr | Pôle informatique - systèmes et réseau
Re: [Dovecot] Thunderbird namespace handling
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).
Re: [Dovecot] Thunderbird namespace handling
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. -- Thomas Hummel | Institut Pasteur hum...@pasteur.fr | Pôle informatique - systèmes et réseau
Re: [Dovecot] Thunderbird namespace handling
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. :)
Re: [Dovecot] Thunderbird namespace handling
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
Re: [Dovecot] Thunderbird namespace handling
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 *
Re: [Dovecot] Thunderbird namespace handling
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.html 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.
Re: [Dovecot] Thunderbird namespace handling
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.html 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 ? -- Thomas Hummel | Institut Pasteur hum...@pasteur.fr | Pôle informatique - systèmes et réseau
Re: [Dovecot] Thunderbird namespace handling
Original Message From: Timo Sirainen t...@iki.fi To: Thomas Hummel hum...@pasteur.fr Cc: Dovecot Mailing List dovecot@dovecot.org Sent: Fri, Jun 11, 2010, 21:49 PM Subject: Re: [Dovecot] Thunderbird namespace handling 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.html 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.
Re: [Dovecot] Thunderbird namespace handling
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. -- Thomas Hummel | Institut Pasteur hum...@pasteur.fr | Pôle informatique - systèmes et réseau
Re: [Dovecot] Thunderbird namespace handling
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.
Re: [Dovecot] Thunderbird namespace handling
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. -- Thomas Hummel | Institut Pasteur hum...@pasteur.fr | Pôle informatique - systèmes et réseau
Re: [Dovecot] Thunderbird namespace handling
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.
Re: [Dovecot] Thunderbird namespace handling
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 ? -- Thomas Hummel | Institut Pasteur hum...@pasteur.fr | Pôle informatique - systèmes et réseau
Re: [Dovecot] Thunderbird namespace handling
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 ? -- Thomas Hummel | Institut Pasteur hum...@pasteur.fr | Pôle informatique - systèmes et réseau
Re: [Dovecot] Thunderbird namespace handling
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.
Re: [Dovecot] Thunderbird namespace handling
On Fri, Jun 11, 2010 at 05:26:30PM +0100, Timo Sirainen wrote: Correct ? Yes. Thanks a lot Timo ! -- Thomas Hummel | Institut Pasteur hum...@pasteur.fr | Pôle informatique - systèmes et réseau
Re: [Dovecot] Thunderbird namespace handling
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.html 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 ? -- Thomas Hummel | Institut Pasteur hum...@pasteur.fr | Pôle informatique - systèmes et réseau
Re: [Dovecot] Thunderbird namespace handling
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 ? -- Thomas Hummel | Institut Pasteur hum...@pasteur.fr | Pôle informatique - systèmes et réseau
Re: [Dovecot] Thunderbird namespace handling
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.html
Re: [Dovecot] Thunderbird namespace handling
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.
