User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:184.108.40.206) Gecko/20060320 Firefox/220.127.116.11
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:18.104.22.168) Gecko/20060320 Firefox/22.214.171.124
I created a folder called "sent mail" subfolder in my AOL/IMAP "saved" mail folder. When I transfer mail to this folder, and view the contents, the sender and recipient columns both show my email addresss. The address to which I sent the email does not display.
Steps to Reproduce:
1. Open sent mail folder.
2. View contents
3. See that sender and recipient are the same.
Same bug occurs with Windwos.
*** Bug 331634 has been marked as a duplicate of this bug. ***
I can confirm this bug. Same problem with my AOL account and Thunderbird 2.0 beta 2
It might be related to a bug I already submited: --> see BUG 370740
Should they therefore be linked in the depedency tree?
Confirming based on multiple reports, but I don't have an AOL account to test with. If a reporter could test whether Seamonkey behaves the same, that would be useful.
i just tried seamonkey, it has the exact same problem. if you need any test-reports let me know what to do for you.
aol imap accounts are free. so if you want, i can set one up for test purposes and mail you the login details.
FYI, this bug does not seem to occur with AOL and other email client apps. Apple Mail displays the AOL saved mail recipient addresses just fine.
As I believe I said in one of the several bugs this is a dup of, we're using AOL IMAP specific commands to fetch information about messages, and that's causing this problem. This is an artifact of the days when AOL's imap server was closed, and we used those commands to lessen the load on the imap server. It's probably pretty easy to stop using the AOL Envelope command now that AOL IMAP is open to all imap clients. I'll do a quick patch.
Created attachment 255697 [details] [diff] [review]
don't issue the aol envelope command to fetch headers - I haven't tried this, but it should make us behave like other imap clients. I could land this on the trunk and have someone try it and see if it fixes their issues.
You would need to do a folder properties | rebuild index on the imap folder in question to test this, to force us to redownload the headers for the imap folder, once this fix lands.
Thanx for the quick try. I'd be happy to test the fix. Is Bug 370740 also fixed in it?
Just tell me where I can get a snapshot (please precompiled for Win2k since I don't have the knowledge nor the tools to compile it myself) and I'll see if it works right away!
fixed on trunk - bug 370740 should also be fixed, assuming the cause is the same, which I think it is.
Here's where you can find a build tomorrow that has the fix in it. This will be a trunk build, which is the latest version of all our code, not just a 1.5.0.x build with this one change in it. So you might want to try this with a new profile, or at least backup your existing profile before running the trunk build. If the fix works for you, after doing the rebuild index step I mentioned earlier, then I can land this fix on the 2.0 branch so that it will be part of 2.0
Thanx alot David! I downloaded the latest Trunk and this Bug as well as Bug 370740 are fixed! I'm looking forward to the next 2.0 release! Thanx again!
Thx for the very quick feedback, Robert. I've landed the fix on the 2.0 branch as well, so tomorrow's 2.0 nightly will have the fix.
Wow, thanks so much! One question, though: How do I get T-bird to go back and re-recognize the saved sent mail? (Mail that I add to the saved sent folder now shows the proper recipient, but mail that had previously been saved still shows the recipient being the same as the sender.)
You would need to do a folder properties | rebuild index on the imap folder in
question to test this, to force us to redownload the headers for the imap
folder, once this fix lands.
Since it's a pretty simple fix, can this be landed on the 1.5 branch so that it can make it into 126.96.36.199?
no, sorry, it's way too late for 188.8.131.52. And 2.0 should come out before the next 1.5.0.x release.
Is there going to be a 184.108.40.206? It looks like Thunderbird 2.0 isn't going to make the spring round of Linux distros (at least Ubuntu, which I run), and it would be nice to have this fix more broadly distributed.
We don't know if there will be a TB 220.127.116.11 - it just depends on if there are any security issues with 18.104.22.168.
I'm surprised there are linux distros that care that much about AOL IMAP :-)
Does it take longer to do TB 2.0 than 22.214.171.124 because there are more changes in 2.0?
Note: I'm not speaking for Ubuntu or any other distro, I'm just a regular user who keeps half an eye on development, or at least the package repositories. I care about this bug because I use an AIM account rather heavily.
Linux distros (or at least Ubuntu) usually freeze package versions a month or two before releasing. Ubuntu has already done their "upstream version freeze" for their spring release (7.04/"Feisty Fawn"), and I did not see any TB2 packages uploaded, so I think it's safe to assume they're not going to ship 2.0 in April.
But they have faster turn around for the .0x releases? Or do they use auto-update?
No, they don't use auto-update.
When Ubuntu 6.10 was still under development, it included prerelease versions of 2.0 (starting with Beta 2, I think), and the final Ubuntu 6.10 release included Firefox 2, even though Firefox 2 final was released after Upstream Version Freeze. I haven't seen any Thunderbird 2.0 prereleases in the current Ubuntu development version, which has already passed Upstream Version Freeze, which leads me to believe that Thunderbird 2 isn't going to make Ubuntu 7.04.
I still don't understand why, if 2.0 comes out before 126.96.36.199, that it's helpful to get this fix into 188.8.131.52...we're planning on shipping TB 2.0 in mid March. Is it easier for linux distros to take the .0x releases, even if they come after the major next release.
*** Bug 376561 has been marked as a duplicate of this bug. ***