[Dovecot] namespaces and behaviour of LIST and SELECT with leading ~
Hi
One weirdness when going through the code:
(We are migrating from WU-IMAP and have users with a mixture of ~/IMAP/ and ~/Mail/ for storing mail - but all user INBOX=~/.email thankfully. IMAP client config is even more random and we have 1800 users.
I have been playing with namespaces to translate various prefixes ala:
default_mail_env = mbox:%h/:INBOX=%h/.email:INDEX=/var/cache/dovecot/%n # Note lack of IMAP ^^^ (So clients can use ~/IMAP or ~/Mail - we have a # historic mixture) full_filesystem_access = no namespace private { separator = / inbox = yes prefix = hidden = no location = mbox:.email } namespace private { separator = / prefix = hidden = no location = mbox:IMAP/ } namespace private { separator = / prefix = IMAP/ hidden = no location = mbox:IMAP/ } namespace private { separator = / prefix = ~/IMAP/ hidden = no location = mbox:IMAP/ }
User tstest has INBOX in ~/.email and mail folders in ~/IMAP/ all in mbox format:
Here's a sample conversation:
OK dovecot ready. 1 login tstest ******* 1 OK Logged in. 1 list "" %
LIST (\NoInferiors \UnMarked) "/" INBOX
LIST (\NoInferiors) "/" "Trash"
LIST (\NoInferiors) "/" "Queue"
LIST (\NoInferiors) "/" "Sent"
LIST (\NoInferiors) "/" "Drafts"
LIST (\NoInferiors) "/" "Blah" 1 OK List completed.
Good
1 list "" IMAP/%
LIST (\NoInferiors) "/" "IMAP/Trash"
LIST (\NoInferiors) "/" "IMAP/Queue"
LIST (\NoInferiors) "/" "IMAP/Sent"
LIST (\NoInferiors) "/" "IMAP/Drafts"
LIST (\NoInferiors) "/" "IMAP/Blah" 1 OK List completed.
Good
1 list "" ~/IMAP/% 1 OK List completed.
Oops (being caught by mbox_is_valid_mask as prefix begins with ~ and
the client supplied prefix is being tested, not the virtual one after namespace prefix substitution)
But...
1 select Blah
FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)] Flags permitted.* 5 EXISTS
0 RECENT
OK [UNSEEN 1] First unseen.
OK [UIDVALIDITY 1090326264] UIDs valid
OK [UIDNEXT 6] Predicted next UID 1 OK [READ-WRITE] Select completed.
Yes
1 select IMAP/Blah
FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)] Flags permitted.* 5 EXISTS
0 RECENT
OK [UNSEEN 1] First unseen.
OK [UIDVALIDITY 1090326264] UIDs valid
OK [UIDNEXT 6] Predicted next UID 1 OK [READ-WRITE] Select completed.
Yes
1 select ~/IMAP/Blah
FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)] Flags permitted.* 5 EXISTS
0 RECENT
OK [UNSEEN 1] First unseen.
OK [UIDVALIDITY 1090326264] UIDs valid
OK [UIDNEXT 6] Predicted next UID 1 OK [READ-WRITE] Select completed.
Oo - this works despite the ~
I would argue that with namespace {} directives, the behaviour of SELECT is correct. I would suggest that it may be better to test the final translated path thus:
if full_filesystem_access = yes let anything go. else make sure that final translated mail path is identical OR a subpath of the default_mail_env mbox folder path. (INBOX is a special case and can be matched as well)
This is a suggestion - what do you think? I'd have a go myself but I don't yet feel competant with the dovecot code.
Best wishes
Tim
Tim J Southerwood
On Wed, 2004-07-21 at 18:19, Tim Southerwood wrote:
namespace private { separator = / inbox = yes prefix = hidden = no location = mbox:.email } namespace private { separator = / prefix = hidden = no location = mbox:IMAP/ }
Well, this seems to work because the later namespace declaration overrides the first one with same prefix, but that wasn't really how I thought the inbox was to be used. Rather set the full location for all namespaces, eg.:
location = mbox:IMAP/:INBOX=.email:INDEX=/var/cache/...
and mark one of them with inbox = yes. Or in case there's no inbox=yes, it uses the one with empty prefix.
if full_filesystem_access = yes let anything go. else make sure that final translated mail path is identical OR a subpath of the default_mail_env mbox folder path. (INBOX is a special case and can be matched as well)
This is a suggestion - what do you think? I'd have a go myself but I don't yet feel competant with the dovecot code.
Now that I looked at the code, I think it needs some larger fixing. Namespace prefix should be removed in imap-specific code and lib-storage code shouldn't need to know anything about namespaces. Except subscription code is handled by lib-storage and it needs to know the namespace prefixes. Hmm. Have to think a while how the API should actually work. I guess the subscription handling needs to be more or less separated.
participants (2)
-
Tim Southerwood
-
Timo Sirainen