[Dovecot] Maildir hierarchy sep bug ?
Hello Timo,
I'm experiencing the following different behaviors with dovecot-1.1.8/Maildir.
My Maildir hierarchy separator is the "." (dot) character. My namespaces, when I use them, separator is "/".
When I run the server without any namespaces, I can create mailboxes named something like
first.name
which, of course, are shown to the client as
first/ (non selectionnable) first/name
For instance in Mutt, if I save a message (the "s" key) from
first.name@some.domain
dovecot happilly creates the
.first.name/ Maildir
But if I create a public Namespace, then I have to create a private default namespace as well and the server doesn't behave the same way :
They're set up like this :
namespace private { separator = / prefix = location = maildir:/courriel/boites/%u:CONTROL=/courriel/meta/%u:INDEX=/var/dovecot/indexes/%1u/%u inbox = yes hidden = no list = yes subscriptions = yes }
namespace public { separator = / prefix = '#Foo/' location = maildir:/courriel/boites/public/foo inbox = no hidden = yes list = no subscriptions = no }
Then users cannot create mailboxes with a dot in it :
Character not allowed in mailbox name: '.'
which seems normal but can be confusing since, a user used to saving his mail in first.name (in Mutt for instance) wouldn't be able to do so anymore if the server goes from the first to the second setting described above.
Granted, a user which does so, probably doesn't do what he thinks he does (he probably thinks he save his message in a folder named "first.name" while instead he actually saves it in a subfolder of "first" named "name"). Still it can be confusing.
Is that difference of behavior normal ? Which is the correct behavior ?
And is there still no way (except to patch the source) to allow dots in mailbox names in Maildir ?
Thanks.
-- Thomas Hummel | Institut Pasteur hummel@pasteur.fr | Pôle informatique - systèmes et réseau
On Feb 16, 2009, at 11:24 AM, Thomas Hummel wrote:
But if I create a public Namespace, then I have to create a private
default namespace as well and the server doesn't behave the same way :
I'd think it behaves the same way if you simply created the private
namespace? The public namespace creation shouldn't make a difference.
Then users cannot create mailboxes with a dot in it :
Character not allowed in mailbox name: '.'
Yes, that's expected.
And is there still no way (except to patch the source) to allow dots
in mailbox names in Maildir ?
On Mon, Feb 16, 2009 at 11:36:48AM -0500, Timo Sirainen wrote:
But if I create a public Namespace, then I have to create a private
default namespace as well and the server doesn't behave the same way :I'd think it behaves the same way if you simply created the private
namespace? The public namespace creation shouldn't make a difference.
I'd think so too, but it doesn't work that way : if I set up only one private namespace and no public namespace like this :
namespace private { separator = / prefix = location = maildir:/courriel/boites/%u:CONTROL=/courriel/meta/%u:INDEX=/var/dovecot-test/indexes/%1u/%u inbox = yes hidden = no list = yes subscriptions = yes }
[Note that I've got in the setup above, I've got no mail_location set up globally since I set it up in the default namespace.]
I cannot create a mailbox named "foo.bar" as I could with a global configuration with no namespace at all.
-- Thomas Hummel | Institut Pasteur hummel@pasteur.fr | Pôle informatique - systèmes et réseau
On Mon, Feb 16, 2009 at 07:24:47PM +0100, Thomas Hummel wrote:
I cannot create a mailbox named "foo.bar" as I could with a global configuration with no namespace at all.
Would you agree that the behavior which denies dot is the correct one ?
-- Thomas Hummel | Institut Pasteur hummel@pasteur.fr | Pôle informatique - systèmes et réseau
On Mon, 2009-02-16 at 19:24 +0100, Thomas Hummel wrote:
I'd think it behaves the same way if you simply created the private
namespace? The public namespace creation shouldn't make a difference.I'd think so too, but it doesn't work that way : if I set up only one private namespace and no public namespace like this :
namespace private { separator = / .. [Note that I've got in the setup above, I've got no mail_location set up globally since I set it up in the default namespace.]
I cannot create a mailbox named "foo.bar"
Isn't that what I also said? The public namespace makes no difference, only the private namespace.
as I could with a global configuration with no namespace at all.
Yes, because then the separator is '.' instead of '/'.
Would you agree that the behavior which denies dot is the correct one ?
Yes. I explicitly added code to disallow that. It just confused clients and users when it was allowed.
Anyway, listescape plugin will help you.
On Mon, Feb 16, 2009 at 01:28:40PM -0500, Timo Sirainen wrote:
as I could with a global configuration with no namespace at all.
Yes, because then the separator is '.' instead of '/'.
I think there is a misunderstanding :
What confused me is that,
. with global setup (no namespace at all), both '/' and '.' works (from the client of the client), i.e. I can, in TB create
a.bor
a/band it will shows up as subfolder b of folder a (and on the server .a.b/ Maildir).
So the separator seems to be both '.' and '/'. I wonder if it is normal.
. with a private namesapce with '/' as a separator, only '/' is accepted, as expected.
-- Thomas Hummel | Institut Pasteur hummel@pasteur.fr | Pôle informatique - systèmes et réseau
On Feb 17, 2009, at 8:25 AM, Thomas Hummel wrote:
What confused me is that,
. with global setup (no namespace at all), both '/' and '.' works
(from the client of the client), i.e. I can, in TB createa.b
or
a/b
and it will shows up as subfolder b of folder a (and on the
server .a.b/ Maildir).So the separator seems to be both '.' and '/'. I wonder if it is
normal.
That's a Thunderbird feature then. Trying to use '/' directly gives
just:
x create foo/bar x NO Invalid mailbox name: foo/bar
On Tue, Feb 17, 2009 at 10:54:10AM -0500, Timo Sirainen wrote:
That's a Thunderbird feature then. Trying to use '/' directly gives
just:x create foo/bar x NO Invalid mailbox name: foo/bar
Ok thanks.
-- Thomas Hummel | Institut Pasteur hummel@pasteur.fr | Pôle informatique - systèmes et réseau
participants (2)
-
Thomas Hummel
-
Timo Sirainen