Those alternatives are not applicabile.
-------- Original Message -------- On 9/18/25 14:29, Genes Lists wrote:
On Thu, 2025-09-18 at 09:19 +0000, Rupert Gallagher via dovecot wrote:
Hello,
I note the following problem. If the inbox holds many subfolders with mail, thunderbird spends a lot of time on startup.
Does seem a bit odd to attempt to limit/cripple the server when the flaw resides entirely with the client.
I suggest instead that working to improve TB would be better approach. Engaging with the TB folks would probably be a good idea too.
There may be things you can do on the TB side (make sure to use maildir for local storage - remove unnneeded offline folders etc). It is also possible that reducing the number of sub folders could make TB worse, since then its index file would get even larger, have more "holes" and need manual "compressing" more frequently. I found these index files got really really enormous - far larger than they should, likely as they left holes and tried to keep the file mostly append only.
There were mumbings a long time ago about them auto "compressing" their index file. Still, when I used TB I found I had to periodically stop TB - delete all index files (gigantic GB)- start TB - wait a few minutes and things work better. A work around for poor design for sure but it helped tb work a little faster.
TB is just not a terribly good client inho.
Alternatvely, switch clients to evolution (or something else) which works far better than tb. If some of your users are on mswin, there is outlook I guess.
Either way, it really sounds like the better path for this problem is be to move on from TB or at least focus your energy on TB not the imap server.
good luck - let us know how things work out.
--
Gene
Those alternatives are not applicabile.
-------- Original Message -------- On 9/18/25 14:29, Genes Lists <lists@sapience.com> wrote:
On Thu, 2025-09-18 at 09:19 +0000, Rupert Gallagher via dovecot wrote:
Hello,
I note the following problem. If the inbox holds many subfolders with
mail, thunderbird spends a lot of time on startup.
Does seem a bit odd to attempt to limit/cripple the server when the flaw
resides entirely with the client.
I suggest instead that working to improve TB would be better approach.
Engaging with the TB folks would probably be a good idea too.
There may be things you can do on the TB side (make sure to use maildir
for local storage - remove unnneeded offline folders etc). It is also
possible that reducing the number of sub folders could make TB worse,
since then its index file would get even larger, have more "holes" and
need manual "compressing" more frequently. I found these index files
got really really enormous - far larger than they should, likely as they
left holes and tried to keep the file mostly append only.
There were mumbings a long time ago about them auto "compressing" their
index file. Still, when I used TB I found I had to periodically stop TB
- delete all index files (gigantic GB)- start TB - wait a few minutes
and things work better. A work around for poor design for sure but it
helped tb work a little faster.
TB is just not a terribly good client inho.
Alternatvely, switch clients to evolution (or something else) which
works far better than tb. If some of your users are on mswin, there is
outlook I guess.
Either way, it really sounds like the better path for this problem is be
to move on from TB or at least focus your energy on TB not the imap
server.
good luck - let us know how things work out.--
Gene