Sub1/Sub2 folder created on server, Thunderbird says Sub1 doesn't exist
Using IMAP with the latest Thunderbird over Windows 10.
When Sieve filters create a folder Sub1/Sub2 using "fileinto :create", most operations in Thunderbird that see that folder tree will trigger a "Mailbox doesn't exist" warning. The Sub1 folder is grey/disabled.
What is the "state" of these folders that causes them to be greyed. That is, what exactly does a greyed folder name indicate to us?
I'd like to know what we need to do from the Thunderbird client side OR the server side, even with Sieve, to make Sub1 a legitimate folder.
Related: Sub2 folders created on the server are not auto Subscribed. What can be done in the client app or on the server to automatically ensure new folders are all Subscribed? The only way I know how to do this is to manually go into the account Subscribe option in Thunderbird, Refresh, select all folders, click Subscribe, then OK/Save.
Similarly : Sub2 folders created on the server are not checked as "When getting new messages for this account, always check this folder" What is the difference between "always checking this folder" and "subscribed"? What can be done in the client app or on the server to automatically ensure new folders are all set to be checked when getting new messages?
As a developer I would be fine with looking at code, creating an Thunderbird addon, or coding some process in the server to change folder settings. But I need to understand exactly how and where these settings are made so that I know what code to write.
Thanks!
Todas las respuestas (2)
My understanding of the greying is that those folders are not available for writing mail. I am not sure what the correct IMAP term is.
Here is what I found on research.
When we manually create a hierarchy of IMAP folders, each folder on the server has its own directory: dir .Sub1 dir .Sub1.Sub2 We can access Sub1 because it has a dedicated folder. We can access /Sub1/Sub2 because it also has a dedicated folder.
When we use the "fileinto: create" sieve action, it only creates the single folder that we direct, not the tree. That is, the server has directory .Sub1.Sub2, not .Sub1. So while the email client displays /Sub1/Sub2 as a tree structure, there is no /Sub1 folder to contain mail items.
The ideal solution to this would be for Sieve processors to create each folder if required to lead up to the final folder. This is equivalent to "mkdir /p /sub1/sub2" which will create sub1 if it doesn't exist, on its way to sub2. I'll pursue that later but there can never be a guarantee that it will work for any given email account.
My solution has been to post-fix (pun intended I guess) the folders on the server side:
- Use cron to run a process every few minutes. - Loop through all email accounts on the server. - Detect the condition where a folder .A1.A2.A3.A4 exists without supporting sub-folders .A1.A2.A3. - Create the subfolder, set ownership (vmail:vmail). - Subscribe (dovecot) the user account to the new folder. - On completion, re-index (dovecot) the entire account so that all mailboxes are available to client apps.
I have this JavaScript code running on my primary server now. There are no more errors related to missing folders, and now Thunderbird actually completes all scan operations - it doesn't perpetually show the progress icon for server activity.
I will post the code to my GitHub repo soon and publish the link here.
For indexing, I'd like to use the '-q' option on the dovecot index command so that the operation is queued rather than done immediately, but it doesn't look like my system is running a queue process to index anyway, so this seems to fix that problem too. If anyone can help with setting that up, I'd appreciate it.
Does anyone have any more insight on this so that I can get it into the code before publication? Or perhaps a more elegant solution that doesn't rely on cron on the server?