276199 - RFC-2047-encoded Date header not parsed or displayed correctly

Status: RESOLVED INVALID

(MailNews Core :: MIME, defect)

Description

[Daniel Brands]

Some friends of mine use Incredimail as their e-Mail client. Everytime when I
receive an email from them, this e-Mail is shown with Date 01.01.1970 01:00 and
sorted in Group By Sort under "Yesterday".

Screenshot: http://www.grasschnixe.de/meri/Group_by_Sort.gif

In M$ Outlook 2003 and Outlook XP, mails are always shown correctly. On IMAP and
POP3. This problem appears only, when i receive emails with TB and were sent by
incredimail.

The Date in the header of the GMX Mail watched with TB 0.8, 0.9 and 1.0 is:
Date:
=?iso-8859-1?B?TW9uLCAyMiBOb3YgMjAwNCAxNzo1OTo1MCArMDEwMCAoV2VzdGV1cm9w5GlzY2hlIE5vcm1hbHplaXQp?=

As I watched the Header in my GMX Webinterface, it looked normal:
Date: Mon, 22 Nov 2004 17:59:50 +0100 (Westeuropäische Normalzeit)

And on my Unisurf Account (The same email sent to GMX and Unisurf at the same
time) it is that:
Date: Mon, 22 Nov 2004 18:00:01 +0100 (Westeuropäische Normalzeit)

The funny thing is, when I open this email and watch the header, Date is
correct, in both emails. So it seems, as if the Viewpane-Code has a Bug

Comment 1

[Mike Cowperthwaite]

I set up a message in my mail with the date string supplied by reporter.
In Thunderbird 1.0, Win2K:
  The date in the date column is incorrect, I see 31-Dec-69 06:00pm
  (I'm in the CDT (-0600) timezone)
  But the date in the Envelope panel is correctly shown as 22-Nov-04, 10:59am

In Mozilla 1.8a6-1217, Win2K:
  The date in the date column is shown with the same incorrect value
  But the date in the Envelope panel is also incorrectly displayed -- and
  *differently* displayed every time I select the message.
  Here are some samples:
     21-Sep-63 09:20 pm
     28-Aug-17 11:20 am
     10-Oct-34 10:28 pm
     19-Apr-23 09:26 am

Comment 2

[Frank Wein [:mcsmurf]]

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

Comment 3

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #1)
RFC2047 says : ( http://www.faqs.org/rfcs/rfc2047.html )
> 6. Support of 'encoded-word's by mail readers
> 6.1. Recognition of 'encoded-word's in message headers
(snip)
>   'encoded-word's are to be recognized as follows:
>   (1) Any message or body part header field defined as '*text', or any
>       user-defined header field, should be parsed as follows:
(snip)
>   (2) Any header field not defined as '*text' should be parsed
>       according to the syntax rules for that header field.  However,
>       any 'word' that appears within a 'phrase' should be treated as an
>       'encoded-word' if it meets the syntax rules in section 2.
>       Otherwise it should be treated as an ordinary 'word'.

I think that RFC2822's definition of each field of Date: header is NOT "*text",
NOT "phrase", NOT "word", although used characters in each field is subset of
characters used for "atext", "ctext", "phrase" or "word".
 - For example,
   day-name = "Mon" / "Tue" / "Wed" / "Thu" / "Fri" / "Sat" / "Sun"
   (See http://www.faqs.org/rfcs/rfc2822.html for other fields)
Then I think RFC2047 6.1 (2) should be applied to Date: header.
ie. Encoding of Date: header field(s) to "encoded-word"(s) is violation of
RFC2047 and RFC2822.

Mike, what do you think?

Comment 4

[WADA:World Anti-bad-Duping Agency]

Correction of my comment #3.
 - 'comment' field in Date: header (last "( comment-text-string )" part)
    can be 'encoded-word' becaue next is CFWS definition.
     CFWS     = *([FWS] comment) (([FWS] comment) / FWS)
     comment  = "(" *([FWS] ccontent) [FWS] ")"
     ccontent = ctext / quoted-pair / comment
     ctext    = NO-WS-CTL /     ; Non white space controls
                %d33-39 /       ; The rest of the US-ASCII
                %d42-91 /       ;  characters not including "(",
                %d93-126        ;  ")", or "\"

Another RFC2047 violation in comment #0 case.

RFC2047 "2. Syntax of encoded-words" section says:
>   An 'encoded-word' may not be more than 75 characters long, including
>   'charset', 'encoding', 'encoded-text', and delimiters.  If it is
>   desirable to encode more text than will fit in an 'encoded-word' of
>   75 characters, multiple 'encoded-word's (separated by CRLF SPACE) may
>   be used.
>
>   While there is no limit to the length of a multiple-line header
>   field, each line of a header field that contains one or more
>   'encoded-word's is limited to 76 characters.

'encoded-word' in Date: header of comment #0 is 97 bytes long.

Comment 5

[Mike Cowperthwaite]

(In reply to comment #3)
> Mike, what do you think?

I think you're right on both counts.

Comment 6

[(not reading, please use [e-mail] instead)]

sorry for the spam.  making bugzilla reflect reality as I'm not working on these bugs.  filter on FOOBARCHEESE to remove these in bulk.