User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/536.11 (KHTML, like Gecko) Ubuntu/12.04 Chromium/20.0.1132.47 Chrome/20.0.1132.47 Safari/536.11 Steps to reproduce: I have been using Thunderbird for a few days on Ubuntu 12.04 (I was using Evolution before) for accessing an IMAP account. Note that I haven't downloaded any addon for Thunderbird. I have enabled the option that automatically compacts folders when the gain is at least 20MB. Actual results: My home partition overflowed. Reason: thunderbird was using several hundreds of gygabytes of harddrive! Just after a few days, and I'm not even doing anything fancy with my email. To check the growth rate of disk usage, I have first restarted thunderbird, then compacted my email folders, then run "du -s .thunderbird" every five minutes (the values are in kilobytes). Note that I haven't received any email during this period, nor do I have even touched thunderbird, I have just let it run in the background: 832556 .thunderbird/ 1019204 .thunderbird/ 1125316 .thunderbird/ 1400176 .thunderbird/ 1430760 .thunderbird/ 1437208 .thunderbird/ 1443660 .thunderbird/ 1580244 .thunderbird/ 1743068 .thunderbird/ 1755768 .thunderbird/ 1763336 .thunderbird/ So, as you can see, it does not take long for the .thunderbird folder to grow by 1GB over its freshly compacted size. And seeing as it ended up using hundreds of GBs after a few days, there is no reason to believe it ever slows down. Expected results: Obviously, the disk usage should not increase when there are no new emails. Moreover, even if it needs to grow a bit (for indexing purpose?), it should never grow up to the point of causing a Denial-of-Service. Finally, the automatic compacter should have kicked in. (Though, somehow it is fortunate it didn't, otherwise it would be constantly running, seeing that 5 minutes are enough for thunderbird to go over 20MB over useless disk usage.)

Something like this was fixed in bug 803843 for TB 16.0.2. Compact the folders after installing that version. If the problem is not fixed in TB 16.0.2 please reopen this bug.