Url describing bug in comment 0 has gone stale. However it is still in wayback machine here:
https://web.archive.org/web/20130502153645/http://bleedingedge.com.au/blog/archives/2005/11/waiting_for_thunderbird.html
with this text:

November 09, 2005
Waiting for Thunderbird

It's hard to write a decent email program - I know, because I've done it myself. Indeed, the mantra of the Mutt E-Mail Client is "All mail clients suck. This one just sucks less." So, I don't want to sound like I'm whinging too much, when I say: Hey Thunderbird developers, wake up!

Thunderbird is the email program that comes from the same fine folks that being us the Firefox web browser. Firefox is fast, stable, and effective - one might expect the same qualities from Thunderbird. Alas, for at least some uses, Thunderbird is slooooooooooowwwwwwwww.

My FastMail.FM partner Rob Mueller yesterday was looking at an email containing some photos of our ski trip to Mt Hotham (which was a great trip, if you put aside the bit where I broke a rib!) The email was 15MB, including 6 attached photos. We generally find downloads zip along at around 140KB per second at work, so we expected that downloading the email would take 15000/140 = 110 seconds (under 2 minutes). However, it actually took 48 minutes!

Rob and I had a look at the diagnostics on the server to see what on Earth Thunderbird was doing to make this take 25x longer than it should be. We discovered that when it displayed the text of the email, it downloaded the entire 15MB including photos - when it only needed to download to 0.01MB of text! Then, it went to display the first photo inline, and instead of using the photo included in the 15MB it had just downloaded, it threw all that away and downloaded it a second time... and of course, rather than just downloading the 1 photo it was rendering, it downloaded the entire 15MB yet again. It repeated this another 5 times - once per photo. So all in all, it had downloaded the whole 15MB 7 times - once for the text, and once for each photo. So that explains a lot of the problem.

The next thing that we discovered is that rather than just sending the whole email over the internet, it first sends 12k, then another 14k, then another 16k, and so forth, until it reaches about 80k. Then it goes back to the start and sends 12k, 14k, etc... This is a really slow way to send a file - it completely breaks all the clever optimisations that are built into the TCP/IP protocols that the internets runs on, and it introduces a lot of overhead as each little transfer has to be acknowledged by the PC. In fact, this method is about 3x slower than just sending the data in one go.

So my advice is, if you need an email client that is good for displaying photos, or downloading large attachments, don't use Thunderbird. So, what should you use instead? Well... err... "All mail clients suck". Personally, I use FastCheck, which is wonderfully fast and works perfectly for my needs.

Update: Bob Peers on the EmailDiscussions forums points out that the latter problem (caused by downloading in chunks) is easily fixed. He says: The fetching by chunks can be turned off by setting user_pref("mail.imap.fetch_by_chunks", false); in your user.js file. Or in TB 1.5 RC1 just go to Edit:Preferences:Advanced:Config Editor and filter for it there. In my opinion it should be false by default. This fix brings the time down from 48 minutes to 16 minutes - still much worse than the 2 minutes that it should take, but still a nice improvement.