Yeeeahh! I got it. For those who have the same problem:
> http://wiki.dovecot.org/Clients#Thunderbird Then, I took a look in conf.d/20-imap.conf and found the following: > # Workarounds for various client bugs: > # delay-newmail: > # Send EXISTS/RECENT new mail notifications only when replying to NOOP > # and CHECK commands. Some clients ignore them otherwise, for example > OSX > # Mail (<v2.1). Outlook Express breaks more badly though, without this > it > # may show user "Message no longer in server" errors. Note that OE6 > still > # breaks even with this workaround if synchronization is set to > # "Headers Only". > # tb-extra-mailbox-sep: > # With mbox storage a mailbox can contain either mails or submailboxes, > # but not both. Thunderbird separates these two by forcing server to > # accept '/' suffix in mailbox names in subscriptions list. > # tb-lsub-flags: > # Show \Noselect flags for LSUB replies with LAYOUT=fs (e.g. mbox). > # This makes Thunderbird realize they aren't selectable and show them > # greyed out, instead of only later giving "not selectable" popup error. > # > # The list is space-separated. > imap_client_workarounds = delay-newmail tb-extra-mailbox-sep tb-lsub-flags As we have a very heterogenous infrastructure, with Mac OS X Thunderbird, I added the missing 2 TB options (I also have LAYOUT=fs on the public folders) and restarted Dovecot. Now it works without showing obscure messages - it just deletes a subfolder as a user would expect! :-D Of course TB must be still set up to delete immediately. Regards Karsten On 08/24/2011 10:34 AM, Karsten Becker wrote: > Step 1 accomplished: It worked. > > So, it's a TB bug? Some known workarounds? > > Regards > Karsten > > On 08/24/2011 12:48 AM, Timo Sirainen wrote: >> On 24.8.2011, at 1.08, Karsten Becker wrote: >> >>> I have the problem that I'm unable to delete a subfolder (again) I >>> created within a public folder. >>> >>> I've already read about configuring Thunderbird to delete immediately - >>> which I did. But it still doesn't work. >> >> Step 1: Verify that it really is a DELETE command that fails and that the >> returned error is "Permission denied". For example: >> >> telnet localhost 143 >> a login username password >> b delete Folders/test01 >> >
