From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc1) Gecko/20020417 BuildID: 2002041711 I have the following email in my inbox; (Email addresses removed to prevent spam). It's a message I typed myself by telnetting to port 25 to make sure that the mail server was working. I typed an illegal RFC-822 date in the date field, "Date: Now" since this was a test. Looking at the message window, I get a different date each time I re-select the message! E.g.: 2-Jul-62, 3:05PM, 21-May-58 11:52PM, etc. In the message list (top right pane), it consistently appears as 1-1-1970 (there are other bugs mentionening this), which is acceptable; however, there seems to be an un-initialized variable used when the date cannot be parsed for the message header display. Actual message attached (strip "" from beginning of each line): ------------------------- "" From - Mon May 06 13:47:39 2002 "" X-UIDL: 2002050610465210503o6et7e00014k "" X-Mozilla-Status: 0001 "" X-Mozilla-Status2: 00000000 "" Received: from spf5.us4.outblaze.com (x.outblaze.com[205.158.62.27]) "" by prserv.net (in5) with ESMTP "" id <2002050610465210503o6et7e>; Mon, 6 May 2002 10:46:53 +0000 "" Received: from world (techunix.technion.ac.il [132.68.1.28]) "" by x.outblaze.com (8.11.6/8.11.6/us4-srs) with SMTP id "" g46Aix484521 "" for spam-me-not@writeme.com; Mon, 6 May 2002 10:45:59 GMT "" Message-Id: <200205061045.g46Aix484521@spf5.us4.outblaze.com> "" From: Ori Berger <spam-me-not@tx.technion.ac.il> "" To: Ori <spam-me-not@spam-me-not.net> "" Subject: Hello "" Date: Now "" "" This is yet another test ---------------- Reproducible: Sometimes Steps to Reproduce: 1. Send message with malformed "Date:" header to self (e.g., the one attached below). Alternatively, it may be possible to just inject this into the Inbox file. 2. Open message with malformed "Date:" header in a new window, e.g., by double clicking. 3. Repeat step 2 several times. Actual Results: The "Date" line in each new message window is different. Expected Results: All "Date" lines would be consistent. Actually, even if the date header is malformed, it should display the string value (possibly noting that it is malformed). At the very least, it should be consistent and be either a minimal or a maximal date (1970 or 2090 or something) so that it is not confused with any real date. The same problem happens even when a new window for the message is not openned, e.g., instead of steps 2 and 3 above do: 2. select message with malformed date by clicking once on it in the message list; Note "Date:" header in message display pane (bottom pane). 3. Select a different message than the one selected in 2. 4. Repeat 2-3 as many time as desired; Each time you will receive a different date value.

*** This bug has been marked as a duplicate of 32216 ***

See also bug 73565, which may be an outright DUP of bug 32216.

This is not a duplicate of either 32216 or 73565 even though it is probably related to both. Note that the reported problem is _not_ that it shows 1-jan-1970 (or 31-dec-1969) for malformed dates. The reported problem is that in the actual message window (not the message list window!), every time you look at the message you get a DIFFERENT date and time, seemingly random. This means there's an uninitialized variable somewhere in case the date value is malformed.

Confirming on Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0+) Gecko/20020527. I get an absurd (by consistent) date: 12/06/05 77:17 pi

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2.1) Gecko/20021130 I've attached a screenshot showing the same message open several times. You can see the date is different every time (it seems random). I agree with Ori Berger that an uninitialized time_t variable is probably used somewhere. http://www.wikipedia.org/wiki/Unix_epoch

They are all part of the same problem, which is: Date header parsing has weak exception handling. I think sorting this out so it remain separate from bug 32216 and bug bug 73565, because the processing is likely failing at different places, for different reasons in the code. Given the age/matureity of MailNews/Thunderbird, I'm surprised this wasn't resolved long ago, but this might be a "world got more inconsistent recently" problem. At my most recent employer, we build a new mail client, and we went through a series of these bugs relatively quickly... I think I have the regression tests somewhere, so I'll try to re-configure my test harness and run them and check the other open bugs.

WORKSFORME with Tb 2.0.0.4(Win-XP SP2). See Bug 318323I Comment #12 & Bug 318323I Comment #13. When phenomenon of Bug 32216 or Bug 216613 is observed, result was very "CONSISTENT" with Tb 2.0. To Ori Berger(bug opener) and Shill(poster of Comment #6): Are you still able to re-create the problem? If no, I recommend you to close as WORKSFORME.