User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20050105 Galeon/1.3.19 (Debian package 1.3.19-4) Build Identifier: If this setting is wrong with a server supporting mbox (as it is by default), user cannot delete mailboxes because Thunderbird tries to RENAME them under Trash/ mailbox. The error message which comes out of this isn't exactly easy to understand either. How about just drop this whole setting and auto-detect it? It's simple: Just see if server returns \NoInferiors for the Trash mailbox in LIST command reply. Reproducible: Always Steps to Reproduce:
Component: General → Networking: IMAP
OS: Linux → All
Product: Thunderbird → Core
Hardware: PC → All
Version: unspecified → Trunk
Duplicate of bug 263098?
Product: Core → MailNews Core
5+ years and nothing? I've seen numerous complaints from the devs when asked to do things that will *increase* the number of options in the GUI. This one would obviously be easy (the solution is in the report), but would also lose one option in the GUI *and* create fewer problems for users. So how about it?
Can we have this block Bug 551415? If auto-detection of NoInferiors was done, then archiving could take the appropriate steps automatically.
This is an important setting to get right. Yet it's neither auto-detected (as Timo, the primary dovecot developer suggested), nor is it easy to find. It's not in the initial account setup, so it WILL be wrong when initially setting up an account on an mbox-style server. If there MUST be a setting (afraid that autodetect might get it wrong), at least let autodetect default it to the almost certainly correct value. It's burried under Advanced settings - despite being a common case. Worse, the Advanced tab in question is uner "message storage" -- yet all of these settings have nothing to do with client-side message storage - they are SERVER parameters! From a UI perspective, that "advanced" button needs to move into "Server Settings"! I agree with Comment3 - 7 years is too long for a simple fix that simplifies the GUI and eliminates a setup problem common to many unix clients. Note that mbox, while ugly, is the default mail storage format on unix. One has to go out of one's way to setup a format that does NOT have this problem. It would be extremely helpful if this could be picked up and worked-on. Thanks.
:dlech, is this something that you have the skills to take on?
I will take a look at it.
It turns out that there is already code that looks for \NoInferiors and handles things properly. The reason folks are not seeing the expected results here is because of Bug 317597. When a Dovecot server with mbox responds to LSUB, it does not return the \NoInferiors flag (or \NoSelect as in the other bug). If you turn off subscribed folders - Tools > Account Settings... > [account with mbox server] > Server Settings > Advanced... (button) > Show Only Subscribed folders (uncheck), then you can delete folders as expected regardless of the 'Server supports folders that contain sub-folders and messages' setting. This is just a workaround too. So, we need to mark this bug as depends on Bug 317597 and fix that bug instead.
(In reply to Timo Sirainen from comment #0) > > If this setting is wrong with a server supporting mbox (as it is by default), > user cannot delete mailboxes because Thunderbird tries to RENAME them under > Trash/ mailbox. The error message which comes out of this isn't exactly easy > to understand either. > > How about just drop this whole setting and auto-detect it? It's simple: Just > see if server returns \NoInferiors for the Trash mailbox in LIST command reply. The symptoms of this bug should be fixed by bug 799821, which makes the setting obsolete. The question that is still open for discussion is if (or when) we should get rid of the setting. I don't think we should get rid of it right away in case there is a problem with bug 799821 when it is released to a wider audience, but I think that it should be removed eventually.
Removing myslef on all the bugs I'm cced on. Please NI me if you need something on MailNews Core bugs from me.
You need to log in before you can comment on or make changes to this bug.