[Dovecot] dovecot 1.2.3: TB fails to unsubscribe folder after deletion
Hi,
I'm running dovecot 1.2.3 with "imap_client_workarounds = tb-extra-mailbox-sep" and noticed that after deleting a folder (moving to Trash and emptying it on exit) that folder in Trash still keeps subscribed. I think the reason for that behavior is that the call for mailbox_list_set_subscribed() in imap/cmd-subscribe.c (line 84) is fed with the original mailbox name and not the stripped version in verify_name. Assigning verify_name to mailbox in the workaround-conditional fixes this issue for me.
I'm not very familiar with C programming but while tracing cmd_subscribe_full() I stumbled upon another thing. In mail_namespace_find_mask() (lib-storage/mail-namespace.c at line 413) mailbox is reassigned with a local string (not t_strduped). I think this might be a problem when mailbox is dereferenced after returning from that function?!
.max
Max Dittrich wrote:
I'm not very familiar with C programming but while tracing
qed
cmd_subscribe_full() I stumbled upon another thing. In mail_namespace_find_mask() (lib-storage/mail-namespace.c at line 413) mailbox is reassigned with a local string (not t_strduped). I think this might be a problem when mailbox is dereferenced after returning from that function?!
Looks like the string "INBOX" isn't allocated from the stack. ;)
.max
On Tue, 2009-08-11 at 12:12 +0200, Max Dittrich wrote:
Hi,
I'm running dovecot 1.2.3 with "imap_client_workarounds = tb-extra-mailbox-sep" and noticed that after deleting a folder (moving to Trash and emptying it on exit) that folder in Trash still keeps subscribed. I think the reason for that behavior is that the call for mailbox_list_set_subscribed() in imap/cmd-subscribe.c (line 84) is fed with the original mailbox name and not the stripped version in verify_name. Assigning verify_name to mailbox in the workaround-conditional fixes this issue for me.
Well, I guess it was kind of intentional and this isn't necessarily always a problem. TB subscribes mailbox as "box/" and unsubscribes it as "box/". Dovecot internally also stores it as "box/" so all of that should be ok. Except if some other client subscribes to it, or perhaps TB doesn't always subscribe to it as "box/".
Anyway.. http://hg.dovecot.org/dovecot-1.2/rev/339be408f49a should help.
Timo Sirainen wrote:
On Tue, 2009-08-11 at 12:12 +0200, Max Dittrich wrote:
Hi,
I'm running dovecot 1.2.3 with "imap_client_workarounds = tb-extra-mailbox-sep" and noticed that after deleting a folder (moving to Trash and emptying it on exit) that folder in Trash still keeps subscribed. I think the reason for that behavior is that the call for mailbox_list_set_subscribed() in imap/cmd-subscribe.c (line 84) is fed with the original mailbox name and not the stripped version in verify_name. Assigning verify_name to mailbox in the workaround-conditional fixes this issue for me.
Well, I guess it was kind of intentional and this isn't necessarily always a problem. TB subscribes mailbox as "box/" and unsubscribes it as "box/". Dovecot internally also stores it as "box/" so all of that should be ok. Except if some other client subscribes to it, or perhaps TB doesn't always subscribe to it as "box/".
Anyway.. http://hg.dovecot.org/dovecot-1.2/rev/339be408f49a should help.
Hi Timo,
Sorry to "unbury" such an old patch, but it seems to be related to a bug I'm seeing right now, that I described in a mail sent on Thursday. In short, TB *and* OE, when talking to a Dovecot server using an mbox backend, complain with messages stating that "the mailbox isn't selectable", for "folders of folders" mailbox types.
You say that Dovecot internally stores folders of folders as "box/" (just as it is subscribed/unsubsribed to by TB). However, the patch you mention above changes this behaviour and Dovecot now stores folders of folders as "box" with no trailing slash. This seems to break things on the Dovecot side, for mbox backend users, as there is no way left to distinguish between both kinds of folders. As a consequence, there is an inconsistency between the way the folder is created (as a directory on the filesystem) and the way it is advertised in the .subscription file (without the trailing "/"). Is this really meant ?
The behaviour was different before that patch, and notably in the 1.1 branch, that I still use on another server: the subscribed mailboxes bear a trailing slash in the .subscriptions file.
Best regards,
Bruno
On Mon, 2011-03-07 at 16:07 +0100, Bruno Tréguier wrote:
Sorry to "unbury" such an old patch, but it seems to be related to a bug I'm seeing right now, that I described in a mail sent on Thursday. In short, TB *and* OE, when talking to a Dovecot server using an mbox backend, complain with messages stating that "the mailbox isn't selectable", for "folders of folders" mailbox types.
That is intentional. It works the same way with UW-IMAP. With mbox you can't select a folder that has subfolders, it has nothing to do with trailing slashes or anything. (Or if you really want to, you can work around it: http://wiki2.dovecot.org/MboxChildFolders)
Timo Sirainen wrote:
On Mon, 2011-03-07 at 16:07 +0100, Bruno Tréguier wrote:
Sorry to "unbury" such an old patch, but it seems to be related to a bug I'm seeing right now, that I described in a mail sent on Thursday. In short, TB *and* OE, when talking to a Dovecot server using an mbox backend, complain with messages stating that "the mailbox isn't selectable", for "folders of folders" mailbox types.
That is intentional. It works the same way with UW-IMAP. With mbox you can't select a folder that has subfolders, it has nothing to do with trailing slashes or anything. (Or if you really want to, you can work around it: http://wiki2.dovecot.org/MboxChildFolders)
Thanks for your answer, Timo, but I think my explanation wasn't really clear.
I do agree with you regarding the limitations of the mbox system, and my intention was not to find a workaround.
I'm just questionning the choice of not putting the slash at the end of the mailbox name in the .subscriptions file (for "folders of folders"), as it seems Dovecot solely relies on this to determine which type of mailbox it is dealing with.
In response to a 'LSUB "" "*"' command from the client, the server sends all the names of the mailboxes. This is the only way the client (be it TB or OE or anything else) can be made aware the mailboxes it is subscribed to. So in the absence of trailing /, there is no way for that client to know if a mailbox is a folder of folders, or a folder of messages (except if it maintains a kind of internal state, independent of the server itself, but this should not be mandatory, the "spirit" of IMAP being that eveything important is kept on the server side and you can start a new connection with a new client anytime).
On the contrary, if the trailing / is present in the names returned by the LSUB command, the client (at least TB) is able to take that into account, and the "folder of folders" type of mailbox is greyed out (and is unselectable, so), and when you right-click on it, the menu allows you to create further subfolders in them. With no way to distinguish between both types of mailboxes, this behaviour is broken...
Do you see what I mean ?
Thanks a lot & best regards,
Bruno
On Mon, 2011-03-07 at 17:07 +0100, Bruno Tréguier wrote:
I'm just questionning the choice of not putting the slash at the end of the mailbox name in the .subscriptions file (for "folders of folders"), as it seems Dovecot solely relies on this to determine which type of mailbox it is dealing with.
The .subscriptions file should never have trailing slashes.
On the contrary, if the trailing / is present in the names returned by the LSUB command, the client (at least TB) is able to take that into account, and the "folder of folders" type of mailbox is greyed out (and is unselectable, so), and when you right-click on it, the menu allows you to create further subfolders in them. With no way to distinguish between both types of mailboxes, this behaviour is broken...
It's not right to send trailing / to non-selectable mailboxes, even if it happens to make Thunderbird handle them better.. It might just as easily break other clients.
The right way to determine if mailbox is selectable is by looking at its \NoSelect flag. That is returned correctly in LIST replies. With LSUB replies Dovecot does what other servers too: It doesn't bother seeing what the correct flags are, because it wastes time and clients probably don't use them anyway.
You could try if the attached patch helps.
Timo Sirainen wrote:
The right way to determine if mailbox is selectable is by looking at its \NoSelect flag. That is returned correctly in LIST replies. With LSUB replies Dovecot does what other servers too: It doesn't bother seeing what the correct flags are, because it wastes time and clients probably don't use them anyway.
Ok, right, thanks for this quick and clear answer Timo. I know what is wrong now.
You could try if the attached patch helps.
I'll certainly do and I'll let the list know whether it fixes the problem.
Best regards again.
Bruno
Le 07/03/2011 à 17:22, Timo Sirainen a écrit :
You could try if the attached patch helps.
Hi again Timo,
It works *great* !
Would you accept a patch from me, tranforming this little compile-time kludge into a runtime configuration option in the "imap_client_workarounds" field, let's say "verbose-lsub" or something similar ?
I think it would be convenient, what about you ?
Thanks again.
Bruno
On 7.3.2011, at 22.51, Bruno Tréguier wrote:
You could try if the attached patch helps.
Hi again Timo,
It works *great* !
Would you accept a patch from me, tranforming this little compile-time kludge into a runtime configuration option in the "imap_client_workarounds" field, let's say "verbose-lsub" or something similar ?
I think it would be convenient, what about you ?
Oh, that's a good idea. I hate adding new settings, but a new workaround would be ok :) "tb-lsub-flags" maybe.
Le 07/03/2011 à 21:59, Timo Sirainen a écrit :
Would you accept a patch from me, tranforming this little compile-time kludge into a runtime configuration option in the "imap_client_workarounds" field, let's say "verbose-lsub" or something similar ?
I think it would be convenient, what about you ?
Oh, that's a good idea. I hate adding new settings, but a new workaround would be ok :) "tb-lsub-flags" maybe.
:-)
Ok, let's go for it then. I'll be back soon.
Regards,
Bruno
participants (3)
-
Bruno Tréguier
-
Max Dittrich
-
Timo Sirainen