I’m trying to understand the best practice for maintaining an email archive on a second storage volume while preserving folder structure.
So far, I experimented with the following setup:
Assume an existing mailbox: info@company.com
Create a public shared mailbox: info-archive@company.com
Grant full access to info@company.com
Use Roundcube to archive emails older than 4 years while preserving folder structure
Attempt to move archived folders to info-archive@company.com
This initially failed due to IMAP namespace issues.
As a workaround, I then:
Moved .archive* folders directly at filesystem level into the info-archive@company.com Maildir
Attempted to reapply permissions via the GUI (no visible effect)
Created a temporary folder in Roundcube inside info-archive@company.com
Copied the dovecot-acl file from the temporary folder to the manually moved folders
After this, the folders became visible and subscribable in Roundcube
Observation
It appears that when setting permissions for a shared mailbox in the GUI, ACLs are only applied at the mailbox root level.
Subfolders (especially those created or manipulated outside IMAP/Roundcube) may retain independent ACL states, which can lead to inconsistent behaviour.
This was unexpected, as I assumed that setting a mailbox to “read-only” would enforce that restriction across the entire mailbox hierarchy.
Is this the intended behaviour of the ACL system?
Question / Discussion
What would be the recommended best practice for maintaining an email archive in this scenario, while:
Preserving folder structure
Using a second storage volume
Keeping access manageable via shared mailboxes
The shared mailbox approach seems promising, but manual filesystem operations combined with ACL handling appear fragile.
If I’m not mistaken, Piler works more as a centralized email archiving system rather than an IMAP-style mailbox replica.
From what I understand, it indexes emails for search and compliance purposes, but it doesn’t preserve or rely on the original folder structure as maintained by users in their mailboxes.
In my case, keeping the folder hierarchy is quite important for how users organize and retrieve archived information.
Am I correct in this interpretation, or is there a way Piler can preserve or reflect IMAP folder structures in the archive view?
Could be, but these days compliancy is more important then personal preferences from the past.
That being said, I do not know the exact motivaton. An exact replica can be achived in many more ways (either active or passive or sync). But is this what you really want, for Piler can find an email out of a zillion.
No, at least in our current setup, Piler receives mail through SMTP, so the folder structure is lost. For now, only authorized operators can access the archive, but there are plans to introduce self-service archive access in the future.
If you want an IMAP synchronization tool that fully preserves the mailbox structure, consider also IMAPSync. As you want separate storage, splitting the active mail server and the passive mail archive into two Mail instances on separate nodes may be necessary.
Besides those ideas, consider also that Mail has built-in selective restoration: the sysadmin can restore individual IMAP folders from backups if someone accidentally deletes one.
Thank you for confirming this. My goal is to keep older emails (and shared files) on secondary storage (HDD), while preserving the original folder structure defined by users.
My idea was to keep archive folders unsubscribed most of the time, so they would:
not impact search performance in Roundcube
not occupy space on the main SSD storage
but still remain easily accessible when needed, almost as if they had never been moved
About this:
“splitting the active mail server and the passive mail archive into two Mail instances on separate nodes may be necessary.”
I am trying to avoid managing two separate Mail instances if possible.
I was considering using bind mounts or moving only archive-related Maildir paths to secondary storage. Do you think this approach would be stable/safe with the current Mail implementation?
Also:
“Mail has built-in selective restoration”
This actually sounds like a good alternative for disaster recovery scenarios, although perhaps not as convenient from the end-user perspective as simply re-subscribing an archive folder when needed.
Regarding my ACL question:
I took a look at 20alter_public_mailbox and, unless I misunderstood the code, it seems ACLs are only applied to the root mailbox itself and not recursively to subfolders.
Would it make sense to eventually add an optional “Recursive” checkbox in the add/edit public mailbox GUI, so ACL changes could also be applied recursively to all mailbox subfolders?
From a user perspective, when assigning “read-only” access to a shared mailbox, it feels natural to expect the restriction to apply consistently across the whole mailbox tree.
A Maildir structure is a flat directory layout. The logical IMAP folder hierarchy is mapped to composite directory names that use “.” as a logical separator (with additional escaping rules). For example:
Level One.Level Two.Level Three
This makes it difficult to mount a logical IMAP subtree on a separate device. There is no one-to-one mapping between IMAP folders and filesystem directories.
Avoiding the operational overhead of two Mail instances is understandable.
I don’t know; let’s consider it a research area for now. What we currently have is the “additional volumes” feature[1], which may help by mounting the dovecot-data volume on a given path, then mounting one of its subfolders on a different device. I never tried it, but it could work.
However, consider the Maildir layout limitations described above: mapping a complete IMAP hierarchy to a separate filesystem is not straightforward.
Also, to preserve performance, Dovecot index files should stay on a fast disk. At the moment they are stored together with the email files. I’d like to offer a separate volume for index files in the future, but for now it’s just an idea.
Yes, in public folders Mail manages only the root folder, not its subfolders. This can be considered either a limitation or a feature for users who want to manage ACLs manually with a client like Roundcube and never lose their custom settings.
So the proposed “Recursive” checkbox sounds reasonable, but it would need careful handling to avoid overwriting manual ACL customizations.
Based on your explanation and the current limitations of the Maildir structure, I tried a pragmatic approach to evaluate whether separating archive data could work in practice without introducing a second mail instance.
What I have done so far (purely as a test setup):
Created a new Dovecot namespace called “Archive”
Configured ACLs for the vmail user
Created a folder structure per mailbox archive (e.g. info, sales, etc.)
Assigned ACLs per user to their respective archive folders
Used bind mounts to map the Archive namespace to a secondary storage device
I fully understand this is not an officially supported pattern and that updates may overwrite parts of this setup.
My idea was to experiment with whether this could be stabilized, possibly by extending or adapting the current ACL tooling (e.g. making recursive ACL application more explicit or reusable for this namespace), but I also understand this may not align with the long-term direction of the project.
I’d really appreciate your thoughts on whether this direction is completely misguided, or if there is any chance it could be aligned with future improvements (for example around “additional volumes” or index separation).
Thanks again for your time and clarity.
P.S. — I realized that using “Archive” as the namespace name may not be ideal due to potential conflicts or ambiguity with existing/future mail folder conventions, so I plan to rename it.