78025 - Messages without time stamps sort improperly

Status: RESOLVED WORKSFORME

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Philip Andrew]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.17-14 i686; en-US; 0.8.1) Gecko/20010326
BuildID:    2001032614

I occasionally receive, in my IMAP inbox, messages which don't have a "Date:"
field in the header; when this happens, the value in the "Date" column of the
header display is "12/31/1969 04:00:00 PM" (I'm in US/Pacific time zone, so
that's the epoch, I guess).  I assert that this is incorrect behavior, not to
mention annoying, because these messages appear at the "oldest" end of my header
pane, rather than at the "newest" end, which is where they should be.

On all other mail clients that I've used (including Netscape 4.7x and Outlook
Express), the date/time stamp displayed in the header pane (and used for sorting
there) is the one from the latest "Received:" header field (either that or it's
from the initial "From " line in the message's header).

Anyway, look at what Netscape 4.7* did, and do it that way.

I don't know if this behavior is the same for POP inboxes, but I would suspect
that it might act the same way.

Reproducible: Always
Steps to Reproduce:
1. Send self a message without a "Date:" field in the header.
   (not sure how to do this, probably have to use a script
   which accesses 'sendmail' directly, or just TELNET to
   port 25 of the mailer, and send a message manually, without
   a proper header; it might also work to just edit a mailbox
   text file, copy one of the messages, and remove the "Date:"
   field from the copy's header block).
2. "Get Mail" so that this header is in the header pane.

Actual Results:  Message has the value "12/31/1969 04:00:00 PM" in the "Date"
column of the header pane; the message is then sorted as the "oldest" message in
the inbox, and therefore appears at the "oldest" end of the header list (since I
sort my messages most recent at the top, this means that the message appears at
the bottom of the header pane.

Expected Results:  The message *should* appear as the "newest" message in the
inbox, since that's what it is; the value displayed in the "Date" column of the
header pane should be EITHER the date/time from the top-most "Received:" field
in the message header, OR the date/time from the "From " field at the top of the
message header.

Comment 1

[Keyser Sose]

marking NEW.

Comment 2

[Bryce Mozilla Nesbitt]

Sort by date received would be more useful, as spammers often forge the sending
date, and people's PC's often have the wrong time.

Comment 3

[Philip Andrew]

There's a kludgy workaround to this bug with the advent of the "Order Received"
field, whereby you can add this field, and sort by that instead of by the "Date"
field.

This is annoying, though, since I'll often go and sort by "Date" (out of force
of habit).  I'd much rather be able to have just a "Date Received" field
(replacing both the "Date" and "Order Received" ones), and sort by that.

Comment 4

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 5

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 6

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 7

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 8

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 9

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420

Comment 10

[Karsten Düsterloh]

We do several fallbacks these days (and mail server usually set a Date: server on reception if missing).