On Thursday, December 30 at 12:33 PM, quoth Timo Sirainen:

On Sun, 2010-12-26 at 14:40 -0600, Kyle Wheeler wrote:

...

I am trying to use two namespaces to create an "archival" directory that is stored as mboxes (the rest of my tree is all stored as maildirs). However, when I add the second namespace, suddenly Dovecot starts emitting, in response to the LIST command, a second version of the INBOX that is marked as \NoSelect. Here are my namespac definitions... am I doing this wrong?

That's definitely a bug if there are two INBOXes listed. But you didn't say which Dovecot version does this.

Ahh, well, I wasn't sure if I was doing it right.

I'm using Dovecot 2.0.6. Here's the output of dovecot -n:

# 2.0.6: /service/dovecot-memoryhole.net//dovecot.conf # OS: Linux 2.6.32-5-amd64 x86_64 Debian squeeze/sid auth_default_realm = memoryhole.net auth_mechanisms = plain login base_dir = /var/run/dovecot/memoryhole first_valid_gid = 64020 first_valid_uid = 64020 last_valid_gid = 64020 last_valid_uid = 64020 log_path = /dev/stderr log_timestamp = login_greeting = ...you two suckers! Stop shirkin' and get workin'! mail_gid = 64020 mail_location = maildir:%h/Maildir mail_plugins = fts fts_squat zlib listescape mail_uid = 64020 mbox_write_locks = fcntl namespace { hidden = yes list = no location = mbox:~/Maildir/Archive:LAYOUT=fs:INDEX=~/Maildir/ArchiveIndexes/ prefix = INBOX/Archive/ separator = / type = private } namespace { hidden = no inbox = yes list = yes location = maildir:~/Maildir prefix = separator = / type = private } passdb { args = /var/lib/dovecot/dovecot-ldap.conf driver = ldap } plugin { fts = squat fts_squat = partial=4 full=4 zlib_save = gz zlib_save_level = 6 } protocols = imap service auth { user = vpopmail } service imap-login { inet_listener imap { address = imap.memoryhole.net port = 143 } inet_listener imaps { address = imap.memoryhole.net port = 993 } service_count = 0 user = dovecot } service imap { executable = /usr/local/bin/relay-ctrl-allow-wrapper.sh /usr/local/libexec/dovecot/imap service_count = 0 } service pop3-login { user = dovecot } ssl_cert =

Here is an example IMAP conversation:

• OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE AUTH=PLAIN AUTH=LOGIN] ...you two suckers! Stop shirkin' and get workin'! 1 LOGIN kyle ________ 1 OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT IDLE CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS COMPRESS=DEFLATE] Logged in 2 LIST "" "INBOX"
• LIST (\HasChildren) "/" "INBOX"
• LIST (\Noselect \HasChildren) "/" "INBOX" 2 OK List completed. 3 LOGOUT
• BYE Logging out 3 OK Logout completed.

Just out of curiosity... why is IDLE listed twice in the second CAPABILITY response?

~Kyle

A woman has the last word in any argument. Anything a man says after that is the beginning of a new argument. -- Unknown

On Tuesday, January 4 at 12:14 PM, quoth Timo Sirainen:

On Thu, 2010-12-30 at 08:33 -0700, Kyle Wheeler wrote:

...

I'm using Dovecot 2.0.6. Here's the output of dovecot -n: .. 2 LIST "" "INBOX"

• LIST (\HasChildren) "/" "INBOX"
• LIST (\Noselect \HasChildren) "/" "INBOX" 2 OK List completed.

I remember fixing something related to this. Also I couldn't reproduce this with your config and latest hg version. Maybe it's already fixed in v2.0.8.

I just upgraded to v2.0.8 and was able to reproduce the problem. :(

I don't see anything in the hg changelog summaries since 2.0.8 was released that suggest something related to this... hrm.

If it helps understand the problem, here's a slightly different example of the problem:

2 LIST "" "%"

• LIST (\HasChildren) "." "INBOX"
• LIST (\HasNoChildren) "." "Trash"
• LIST (\HasNoChildren) "." "Sent"
• LIST (\HasNoChildren) "." "addressbook"
• LIST (\HasNoChildren) "." "remote_pinerc"
• LIST (\Noselect \HasChildren) "." "INBOX" 2 OK List completed.

The fact that it repeated INBOX *after* giving all the mailboxes in the first namespace suggested to me that it was the second namespace that is (for some reason) generating this unselectable INBOX.

Is there anything else I can provide you with to help reproduce it?

~Kyle

To brand a book as unsuitable is an important step toward making it required reading. -- Marvin Kaye