Closed brong closed 3 years ago
From: Alexander Drozdov
LIST and LSUB commands don't return "INBOX" and subfolders if userid have dot (".") in the name and unixhierarchysep config variable is not set.
My imapd.conf file is simple:
configdirectory: <somedir> partition-default: <somedir> loginrealms: domain.ru
I have some test users on the server.
Let we send some commands to IMAP server.
. login u3@domain.ru q . OK User logged in . list "" *
We can see that server didn't return INBOX and subfolders. Instead, user.u3@domain^ru* is returned. You can see my patch.
Attachment-Id: 389 From: Alexander Drozdov Type: text/plain File: dottedid_inbox.diff
A patch.
From: Ken Murchison
You cannot use '.' in userids unless you have unixhierarchysep set. You're trying to make the server do something that it was not designed to do.
From: Alexander Drozdov
Sorry, but I've seen the documentation (http://asg.web.cmu.edu/cyrus/download/imapd/altnamespace.html#unixhiersep):
[quote] When the UNIX hierarchy convention is used, the "." character MAY be used in mailbox names, including user names. In order to maintain backwards compatibility with the internal namespace, all "." characters are translated to a benign character (currently "^") before any data is stored to disk. For example, if user "elmer.fudd" had a personal "rabbit.holes" mailbox, it would be stored as "user.elmer^fud.rabbit^holes" in the internal namespace. It is important to remember this phenomenon if/when reverting back to the netnews hierarchy convention. [/quote]
When I turn on or turn off unixhierarchysep variable, user login is not changed (because of using SASL). Therefore, if "." in usernames is possible when unixhierarchysep is set, and if I can unset it in any time, then the server shall process userids with "." correctly. My patch just converts userid to an internal namespace before using it in any commands.
This looks very similar to https://github.com/cyrusimap/cyrus-imapd/issues/797 .
Is the complaint still valid for the current code?
Same OP, same day, but I think slightly different issue -- this one is talking about unixhs, the other was about altns.
Same answer though: this was all refactored extensively in 2.5 and 3.0, and all of these name translations are now handled through the mbname API. I don't think this is relevant anymore.
From: Alexander Drozdov Bugzilla-Id: 2747 Version: 2.2.x Owner: Ken Murchison