User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030810 Mozilla Firebird/0.6.1+ Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030810 Mozilla Firebird/0.6.1+ Emails are often sent with the wrong 'date' field (by spammers or just people with the wrong date/time -- even the wrong year!). TB defaults to sorting by this (allegedly) 'sent date', and it's often very confusing to find new mail randomly scattered around the inbox or other folders. The "Order Received" column (consisting of numbers) is pretty useless to the end user -- especially when they want to know when the mail was really received. What would be much more useful is a "Date Received" -- i.e. the date that YOUR mailserver received the email (most users trust it's clock, and at least its date/time shouldn't change wildly). People concerned with usability should discuss if this should be the default column instead of 'Date sent' -- many other clients do this (e.g. Outlook), and it's more intuitive. Reproducible: Always Steps to Reproduce: 1. Receive email from a computer with incorrect (e.g. in the past) date/time into an inbox containing some recent valid entries 2. Try using the "Order received" column 3. Try finding out when the email was really received Actual Results: 1. Witness how unintuitive it is that the new email appears out-of-order with other inbox entries (may even be difficult to find) 2. See how counter-intuitive and technical the "Order received" column appears to the average user 3. Almost impossible to determine when an email was really received for the layman (have to 'View Source' or 'Full Headers' and scan through fields) Expected Results: 1. By default, should sort by "Date received" so that the email would arrive in a consistent order. 2. The "Order Received" column should be replaced by "Date Received", as this would be much more useful to people. 3. It should be easy to determine when an email was really received at a glance (and NOT just seeing what incorrect time the sender had on their computer) This is also discussed in the Mozilla Mail/News Bugzilla as Bug #166254 I believe the "Date Received" could be (easily?) extracted from the server's mail headers (at the end of the top-most 'Received' header).

A second way of handling this, would be to do as Eudora does, and allow the user to edit, and amend, the 'Sent' date. In at least some cases the time discrepancy can be used as part of the testing the mail for spam/junk.

It is ridiculous that a modern mail client as robust and generally cool as Thunderbird can have this sort of problem. I would further add that it's not simply* a problem that Thunderbird uses the 'Date Sent', which is often highly inaccurate, but that it refers to this field as simply 'Date'. Please add/modify the fields as follows: 1) Date Sent, off by default 2) Date Received, on by default The 'Order Received' field seems like it has no practical end-user use, but feel free to leave it in for whatever bug/spam testing needs are out there. With this bugfix, we can recommend this client over all others, as there are no other great 'gotchas' remaining. But this is a hugely* important bug to fix from an end-user standpoint.

RFE: If we could both have a colum for 'date sent' as well as 'date recieved', the end-user will be made aware of the (possible) time-delay involved in the server-to-server traffic. (Typical end-user scenario: a end-user complains about a missing e-mail: someone did sent her an e-mail but the mail didn't (yet) arrive... Currently, when the message arrives, TB displays the date as the date/time it was sent. So if there was a large time-delay involved, the user is misled into thinking that she overlooked the expected e-mail, that the email indeed did arrive in time (and that it was sitting in the inbox all the time). So I find this aspect of ThunderBirds' behaviour somewhat confusing.) This RFE will also be useful for system administrators in helping troubleshoot mailservers and network routes that are problematic, by clearly visualizing time-delays involved in message routing.

Why is this classified as an enhancement?! This is a very serious deficiency that is one of the 3 reasons left that i've noticed why most people would not want to switch to TB from OE. Its severity should be labeled "major". By the way, the two other main reasons for not using TB are also ignored or belittled! What's going on? So, even though this is strictly speaking off topic, i'll describe the other two TB blockers here to help analyse how 216033 and all the 3 problems considered most serious by normal users i know are apparently ignored and/or not known by the experts on Bugzilla: 2) Severe deficiencies in the TB Search function (Looks like i'll have to post a bug report on this; at least i couldn't find anything using Bugzilla's Search: - TB's search function much slower than OE's - can't search in all accounts simultaneosly like in OE - no option of moving items in search results to other folders! - clicking the Search results' date column does not put all messages in same order by date only but instead also groups them by folder! In addition, even some of these are a few days (and some even a few months or years) earlier or later than others. Is this perhaps due to the date sent being displayed even though the actual order is according to date received?! - Search needs option "in headers" to find (junk)mail sent to, but not addressed to a certain address) 3) TB's inability to open messages that it itself stores as .eml. For some bizarre reasons, Bugzilla's search finds nothing on this second one, and the third one http://bugzilla.mozilla.org/show_bug.cgi?id=217149 is also classified as "enhancement" instead of "major".

"Why is this classified as an enhancement?! This is a very serious deficiency" The fact that it is a "deficiency" and not an existing function that doesn't work as it should is exactly why it is an enhancement. The fact that it is an enhancement does not mean it's not a serious deficiency. The other 2 things have nothing to do with this bug - bug comments are supposed to help fix bugs. If you want to discuss priorities, the forums or newsgroups are the right place for that.

Status? It's more than 3 months old already... I'd really like to see this marked with a higher priority or something. This is really the only thing that makes me not want to send you guys tons of money (If I had it)....

This is a duplicate of Bug 166254, as stated by the reporter. If a bug is filed for Mozilla Mail/News, there's no need to submit a separate bug for Thunderbird. See "Reporting Thunderbird Bugs" <http://forums.mozillazine.org/viewtopic.php?t=10450>.

*** Bug 262777 has been marked as a duplicate of this bug. ***

*** Bug 267646 has been marked as a duplicate of this bug. ***

Hi, what's happening with this bug and the ones it depends on? It's been more than a year and the fix seems (relatively) simple, even according to the proposed solutions in the dependencies. Has anything been done about it? (It seems to me that it would simply require to extract the topmost "Received" header's date and make it available to the UI..) This really is a highly critical enhancement and I think most users will expect this basic functionality in 1.0. You cannot seriously have a 1.0 release without sort (and group) by "Date Received". Please :-)

"Hi, what's happening with this bug and the ones it depends on?" What's happening is that people like yourself are adding pointless comments asking what's happening. If anything was happening, you'd see something happening. 1.0 is due out very shortly, and the chances of this happening before then are (I would think), pretty much nil.

> What's happening is that people like yourself are adding pointless comments > asking what's happening. If anything was happening, you'd see something > happening. Perhaps the reason for all the "what's happening" posts are that this _is_ a pretty big issue for most people (myself included) and while it doesn't make Thunderbird unusable, I have trouble recommending it to others who may not understand the problem. I have used Firefox since 0.1 and Thunderbird since ~0.3 & the issue that this bug addresses is the only one I've ever had, but it is a fairly serious one, functionality-wise. So, I'm not trying to criticize here because the mozilla team's do great work and the community appreciates it, but we would appreciate it even more if they would handle this issue a bit faster. Hope I didn't step on any toes here!

this should have had a helpwanted keyword set a long time ago (though I don't know if people really look for that keyword). This would be an ideal thing for a contributor to work on...

*** Bug 274343 has been marked as a duplicate of this bug. ***

(In reply to comment #1) > A second way of handling this, would be to do as Eudora does, and > allow the user to edit, and amend, the 'Sent' date. > > In at least some cases the time discrepancy can be used as part of the testing > the mail for spam/junk. Because this "bug" is really very annoying it would be nice to provide a solution soon, since it is already over 1 year in the pipeline. I personally would love to see a possibility to edit the date/time like you described it and per default that the server received date is displayed. Thanks!

(In reply to comment #15) > (In reply to comment #1) > > A second way of handling this, would be to do as Eudora does, and > > allow the user to edit, and amend, the 'Sent' date. > > > > In at least some cases the time discrepancy can be used as part of the testing > > the mail for spam/junk. > > Because this "bug" is really very annoying it would be nice to provide a > solution soon, since it is already over 1 year in the pipeline. > I personally would love to see a possibility to edit the date/time like you > described it and per default that the server received date is displayed. > > Thanks!

nearly 2 years ago and nothing happened. this is really bad because the bug is very very annoying.

*** Bug 311912 has been marked as a duplicate of this bug. ***

I was wandering if this bug is going to be fixed in the 1.5, since another identical RFE for that version was closed on 10/10/05 because it was considered as a duplicate of this one. Is there anyone who can give us some good news?

this will not be in 1.5 - it's too late to put changes like this into 1.5, sorry. But it will be in 2.0, and trunk builds going forward.

Opened: 2003-08-13 04:53 PST Its soon 2006, and its still not fixed, This is a major problem for us end-users, pls fix it soon, or il change back to OE.

(In reply to comment #21) > Opened: 2003-08-13 04:53 PST > Its soon 2006, and its still not fixed, This is a major problem for us > end-users, pls fix it soon, or il change back to OE. > (In reply to comment #20) > this will not be in 1.5 - it's too late to put changes like this into 1.5, > sorry. But it will be in 2.0, and trunk builds going forward. When can we download the trunk and have this feature? I can't wait to see my emails back in their meaningful order.

opened 2003-08-13. priceless

(In reply to comment #20) > this will not be in 1.5 - it's too late to put changes like this into 1.5, > sorry. But it will be in 2.0, and trunk builds going forward. I can't believe this bug has been known about for so long yet not been fixed. Glad to hear that it will be in 2.0. Meanwhile I shall stick with OE.

(In reply to comment #24) > (In reply to comment #20) > > this will not be in 1.5 - it's too late to put changes like this into 1.5, > > sorry. But it will be in 2.0, and trunk builds going forward. > > I can't believe this bug has been known about for so long yet not been fixed. > Glad to hear that it will be in 2.0. Meanwhile I shall stick with OE. > This has been a thorn in the side of Thunderbird for years. According to https://bugzilla.mozilla.org/show_bug.cgi?id=190337 which is related, it has been annoying people and preventing widespread rollouts since 2003. 3 years later, and this problem is still not resolved. There is a proposed solution, which reads the date from the received headers rather than trusting the sending mail client, so why is this not already applied? Is there some political reason that is holding this back? Actually, after reviewing this, it is STILL not in Thunderbird 2.0 builds, so I am guessing there is a reason the developers are purposely leaving this crippled for a reason (ie. they plan to address this in a different way)?

I doubt there are any conspiracies here. I suspect the issue is that the number of people actually paid to develop Thunderbird is significantly smaller than the number who work on Firefox, and they're all busy with many other features and fixes. It's quite likely that this bug has simply slipped under the radar, probably due to the fact that no "blocking-thunderbird2" flag was set. Developers have so many things to do as major releases approach, that they understandably forget about bugs with no blocker. In such cases, it's useful to set a block request flag (as I just did) and post a little note explaining why you think it's important for it to make the next release.

Moving off bugs that didn't make the deadline for Thunderbird 2.

In light of bug 166254 and bug 123786, is there *any* reason to keep this bug open? There are too many bugs running concurrently about similar issues.

I don't see any reason, I think bug 166254 fixed this one. ->WFM