Closed Bug 194585 Opened 21 years ago Closed 17 years ago

EMail Date should be corrected if received mail is dated in the future !

Categories

(MailNews Core :: Database, enhancement)

x86
All
enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: 1234abc, Assigned: Bienvenu)

References

(Blocks 1 open bug)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130

If a sender sends an Email with a date in the future (e.g. 02.02.2031) then the
mail-program should correct it to the date of reception, otherwise this mail
will always be on top of a date-sorted list.

Reproducible: Always

Steps to Reproduce:
1. Send Email with date in the future
2. Receive Mail
3. Sort Mails by date

Actual Results:  
Date in the future accepted

Expected Results:  
Change the date in the future to the date of reception (today)
isn't it possible that you system can have a wrong date ?
Many people will think that Mozilla is buggy if the date of all incoming mails
are changed to 2000/01/01 because the system date is wrong.
 
You can sort by "Order received" (Bug 72463 is about the missing column, but
anyway the sort works now.

and I wouldn't like this option: The only mails that I get with incorrect date
are the one from spammers so I'm glad to delete them as soon as I get as they
are very easy to spot. If someone I know has a wrong date in his computer it's
easier to just tell him the problem instead of changing anything on my side.
This sounds invalid. A mail client should not tamper with the mail headers.
Jens Bente: would the solution in Bug 166254 suit you?  That's a request for
enhancement, but it appears to give you results more like what you want.

I concur with R.K.Aa that changing the information is not a good idea.
I don't think an additional field with the information of date/time received
would be a major change. In addition a commentary field (e.g. to add the email a
comment after reading it) would be very helpfull too.
So I don't think that the only solution is just changing the date.
For displaying the information, the solution mentioned (sort by order received)
would be a good workaround.
I also wanted to request this enhancement.
The fix in Bug 166254 suits me.

Here are some additional considerations:
Consider using ntp to get a reliable date. I'd be more concerned about
discrepancies of more than 2 days.
An alternate solution is to check that the sent date of current email is more
than 1.5 weeks greater than the sent date of the previous email.
If true, then invoke ntp, or other recourse.

Any email decided to be of a future date should increase its bayesian
probability of being Junk.
Similar rules should also apply for email that is more than 6 months old.

Only once in all my years of connection to the 'net, have I gotten future dated
email, that was not spam.
This is a bugzilla issue:
I found this bug, by searching for "future"
Then I logged in, and searched again.
Only half as many hits showed up, and this bug did not show up!

It is not clear to a novice Bugzilla user, like myself, that one way of
searching Bugzilla should be any different, or any more effective, than another way.
Why not reading Received lines.
In the code that choose the date we have:
if ("Date in header">"One of Received Date in header") {
  Selected Date = "Date in header";
}

So we would NOT change the content of the mail, but we would change the way the
mails is displayed.

and yes... I would be a good way to see spam.
if ("Received Date from the 1-2 first line" is different from 1-2 days from
"Date in header") {
 Mail is probably spam.
}

-----------------------------

Some headers...
Received: (qmail 23708 invoked by alias); Sun, 27 Jul 2003 22:07:00 +0000
Received: (qmail 23670 invoked from network); Sun, 27 Jul 2003 22:06:57 +0000
Received: from 200-158-27-98.dsl.telesp.net.br (HELO masterloans.com)
 (200.158.27.98)  by mail1.epfl.ch with SMTP; Sun, 27 Jul 2003 22:06:57 +0000
Date: Wed, 27 Jul 2005 19:12:03 -0300
Whiteboard: DUPEME
*** Bug 200785 has been marked as a duplicate of this bug. ***
Status: UNCONFIRMED → NEW
Ever confirmed: true
Product: MailNews → Core
(In reply to comment #8)
> Why not reading Received lines.
> In the code that choose the date we have:
> if ("Date in header">"One of Received Date in header") {
>   Selected Date = "Date in header";
> }

That is a different RFE than the one this bug was opened for. 

It looks to me like this bug should be marked as WONTFIX, as in many cases it is not a robust, or even acceptable, to make this sort of a date change; another solution is necessary.
OS: Windows 2000 → All
-dupme: I searched both Product==Thunderbird and Product==Mozilla && Component=MailNews:*, and found a couple later duplicates, but nothing that came before.

I think the proper wording of this bug is: add a preference that modifies the parsed Date header, if it is [x] days in the future.

In other words:

1- We should not be, by default, deciding what is and isn't acceptable for a Date header value. Mail is weird, it could time warp, or your system could fall back in time...

2- If we implemented this, it should be a preference, that is off by default, and only acts to modify the display only when a threshold has been violated.

I've actually just spent a lot of time testing Date header parsing at a company, and my experience is that it is best to simply parse the Date header in the message into the date/time format your client is going to support, and not make judgements about the content of that line.

3- The reason this is so confusing is that this is what, on AppleMail is called "Date Sent". What a lot of people usually want is "Date Received". This, from what I can tell, could be the IMAP timestamp -or- the last Received line's timestamp. By design, most mail clients have messed up implementing the two fields.

QA Contact: esther → benc
Whiteboard: DUPEME
mailnews.use_received_date=false(default)/true is already added to trunk nightly by a patch for Bug 166254(on 2007/4/17). Then user can choose mail-date (date in "Date column") from Received: instead of from Date: header. See Bug 341548 for detail.
The enhancement can be a relief of this bug's case for some(I think many) users, although it is independent from this bug's enhancement request.
Bug 166254 introduced the Received date column, people wanting that can choose to use it. Don't know what's left here to do - messing with the physical headers would be WONTFIX.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WONTFIX
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.