647689 - A "message date received" value is incorrect

Status: RESOLVED DUPLICATE of bug 402594

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Peter Slacik]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.18) Gecko/20110320 SeaMonkey/2.0.13
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.18) Gecko/20110320 SeaMonkey/2.0.13

Whatever value was meant to show up as "Date received" for an incoming e-mail message, the value displayed is always effectively "Date sent". No matter whether there were some delivery problems or delayn en-route...

Should it be the time the email client picked the message from server, or when the last-in-chain server received the message, or even something else?

I've one email contact person, who's local computer's time is off by approx. 22 minutes to future. Already for years... I'm receiving these e-mails in few seconds, thus their "time sent" is always off by this offset. An example from 15 minutes ago (all IPs (irrelevant) are modified, some IDs stripped):

Delivered-To: [e-mail]
Received: by 10.22.136.91 with SMTP id ....;
        Mon, 4 Apr 2011 08:22:16 -0700 (PDT)
Received: by 10.240.12.134 with SMTP id ......;
        Mon, 04 Apr 2011 08:22:15 -0700 (PDT)
Return-Path: <[e-mail]>
Received: from smtp.domain.com (smtp.domain.com [207.189.121.194])
        by mx.google.com with ESMTPS id .....41.2011.04.04.08.22.13
        (version=TLSv1/SSLv3 cipher=OTHER);
        Mon, 04 Apr 2011 08:22:14 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
	by smtp.domain.com (Postfix) with ESMTP id ......
	for <[e-mail]>; Mon,  4 Apr 2011 17:22:13 +0200 (CEST)
Received: from theserver (dsl-static-35.221-3-158.adomain.com [212.5.201.43])
	by smtp.adomain.com (Postfix) with ESMTPA id ......
	for <[e-mail]>; Mon,  4 Apr 2011 17:22:08 +0200 (CEST)
Received: from localhost ([127.0.0.1])
	by theserver
	for [e-mail];
	Mon, 4 Apr 2011 17:22:06 +0200
From: Him Self <[e-mail]>
To: "'My Self'" <[e-mail]>
Subject: Message subject
Date: Mon, 4 Apr 2011 17:55:47 +0200


Reproducible: Always

Actual Results:  
As can be seen on this example, the message was sent on Mon, 4 Apr 2011 17:55:47 +0200 (17:55 my local time). I've received the notification about storing the message into my Inbox in a few seconds. At the same moment, it was just 17:22 my local time.

Expected Results:  
I'm expecting seeing "17:22 my local time" as the value for "Date received".

Comment 1

[Philip Chee]

Go to about:config
Filter for:
mailnews.use_received_date
Is it set to true or false?

Comment 2

[Peter Slacik]

(In reply to comment #1)
> Go to about:config / mailnews.use_received_date
> Is it set to true or false?
It was set to false. But even after setting it to true, the behavior does not change: received-time is still the exact copy of sent-time.

Comment 3

[Peter Slacik]

(In reply to comment #2)
> (In reply to comment #1)
> > Go to about:config / mailnews.use_received_date
> > Is it set to true or false?
> It was set to false. But even after setting it to true, the behavior does not
> change: received-time is still the exact copy of sent-time.
Just to add: even received-time of the newly coming messages.

Comment 4

[Frank Wein [:mcsmurf]]

Peter: Do you use IMAP? Then this bug is a dupe of Bug 402594.

BTW: Looks like the mailnews.use_received_date pref does not exist anymore.

Comment 5

[johann]

c. six years ago the 'mailnews.use_received_date' was slipped in to handle -- primarily, i believe -- a POP3 issue. i have no knowledge of what effect it had on "news', if any. after a couple of years the POP3 issue(s) got addressed in core and the setting remained (you can add it still), but it no longer did/does anything. it is unfortunate that it never did anything for IMAP at any time.

this bug dates back to the mozilla-suite/netscape era, so it is a decade-old problem. re the 402594 bug, the only staff that ever cared has been absent for a couple of years now and it is going nowhere ... also.

as to dates, SM/TB are not RFC compliant, defy common sense, and are using an approach that made some sense back when email was over 300 baud modems, people checked their email infrequently, and major mailservers (universities, DOD/contractors, et cetera) could be off-line for days at a time and many people would not even notice.

there was a time when the SM developers could be relied upon to take care of issues like this one themselves. but, they are going the way of the auto industry and "standardizing" everything under the hood so that the unique SM product is fast becoming a simple re-packaging of TB and FF. the glee with which they are accomplishing this is touted in their "feature releases". this path is producing problems that never existed with SM before and they are cropping up solely due to this "integration" of FF and -- to a lesser extent -- TB.

i wish i could offer some hope to readers that something will be done about this, but it seems to have absolutely no priority amongst the development crowd.

Comment 6

[Tony Mechelynck [:tonymec]]

After reading the above comments, this bug seems to have become less and less meaningful with time, to the point where (IIUC) it is about the "malfunction" of a pref which has been intentionally removed.

Owners/Peers, what do you think?

Comment 7

[Peter Slacik]

(In reply to Frank Wein [:mcsmurf] from comment #4)
> Peter: Do you use IMAP? Then this bug is a dupe of Bug 402594.
Yes, I do. I've noted the duplicity there.

(In reply to Tony Mechelynck [:tonymec] from comment #6)
> ...this bug seems to have become less and less meaningful with time...
If the "Date received" column will be removed, I can at most silently rant that it was removed. Until then I'm complaining that it's buggy and does not display correct values.

Comment 8

[johann]

i do not think tony grasped the scope of the problem. the sender's date (now reflected as the SM/TB 'Date Received') can be spoofed and militates against recognizing in-transit delays. moreover, it can cause the threading to be haphazard and, therefore, not meaningful.

for years now, the RFC's have clearly stated that the 'Date:' ('INTERNALDATE' in IMAP-speak) must come from the "header" listing the latest 'Received:' timestamp. this header appears in the raw email data as the 'Received:' header nearest the front of the file. 

with IMAP as important as it is, it is difficult to fathom why the SM/TB people have dragged their feet for ten years!

thank you,

Comment 9

[Frank Wein [:mcsmurf]]

Marking as dupe based on Comment 7.