1377784 - Thunderbird shows incoming mail from CCTV DVRs with date 1/1/1970

Status: RESOLVED INVALID

(Thunderbird :: Untriaged, defect)

Description

[Fotis_Greece]

Attachment: emailsource.txt

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:54.0) Gecko/20100101 Firefox/54.0
Build ID: 20170628145605

Steps to reproduce:

Receive Mail from CCTV DVR


Actual results:

Date shows as 1/1/1970


Expected results:

It should have shown date as 30/6/2017 18:30 as with all my other email clients, Like Outlook and Gmail web and mobile email app.
I atatch the email source which clearly show that there is a date header. It's a pity Thunderbird still suffer from some childish bugs.

Comment 1

[Fotis_Greece]

Email source was altered a bit so as not to show the real email address and hostname/ip of mailserver

Comment 2

[Jorg K (CEST = GMT+2)]

That's because the date format in the Date: header is wrong:
Is:        Date: Fri, 2017-6-30 18:38:10
Should be: Date: Fri 30 June 2017 18:38:10
Refer to https://www.ietf.org/rfc/rfc2822.txt, section 3.3.

The Received column looks OK (if you enable it).

It's a pity supposedly well programmed and professional (and expensive?) CCTV DVR systems still suffer from some childish bugs.

Comment 3

[Fotis_Greece]

Dear sir,
First of all thank you very much for your reply. I appreciate it. May I kindly comment that the status should not set to resolved as the Received column still shows wrong date.
As a matter of fact I would like to invite you to have a look at these screenshots, a sort of comparison of how these emails from the DVR is treated in other email clients

https://www.dropbox.com/s/mb1cl92v37gdyvz/sc1.jpg?dl=0

https://www.dropbox.com/s/ip96y6lzvwq3hdv/sc2.jpg?dl=0

https://www.dropbox.com/s/m4avkbs2ihb0mi4/sc3.jpg?dl=0

https://www.dropbox.com/s/591jxx4x0k2w1jm/sc4.jpg?dl=0

https://www.dropbox.com/s/e9oxqus9io6aq3u/sc5.jpg?dl=0

I am a huge fan of Thunderbird and I would like to work with you if needed to have this issue sort out. There must be a way TB can overcome this.
Thanks in advance

Comment 4

[Jorg K (CEST = GMT+2)]

I really don't understand why you insist that TB should handle non-compliant dates better.

Frankly, I've been using TB since 2010 and I have migrated all my previous e-mail from the beginning of 2000 into TB. As far as I recall, I have only ever seen messages dated 1970 in case of corruption. I have never ever seen a message being sent with a badly formatted Date: header like the ones you're presenting.

Why don't you talk to the manufacturer of the CCTV DVR software and ask them to send RFC 2822 compliant messages?

This bug here is really invalid. Please respect this decision. We don't want to have complicated code in the system that deals with incorrect input data, since, if we cover one invalid case, tomorrow there will be another invalid case we don't cover. That's what standards are for, right? If you buy some pants/trousers size L (assuming you're size L) and they don't fit but they fit your 14 y/o son who has size M, what do you do? Join the gym and lose weight to fit into those pants, or perhaps take them back to the shop since they are too small?

Comment 5

[Fotis_Greece]

Thank you again for your reply. I have already contacted the manufacturer and pointed this discussion but I don't have high hopes as the issue is non-existent in other email clients.
I was hoping for some flexibility here but anyway. I would really appreciate if you could possibly re-evaluate in the future.
Best regards from Greece

Comment 6

[Jorg K (CEST = GMT+2)]

Look, we have a few enhancement requests along the lines of "Make Thunderbird more tolerant to bad input data". I always fight with colleagues in these cases, since my colleagues *insist* that everyone needs to adhere to the defined standards. I am a bit more lenient as I like all users to have a nice experience and the software behaves along the lines of "be tolerant in what you accept and strict in what you produce". Some reading, bug 1366273 comment #11 (quote): 'The old "be liberal in what you accept" mantra has been debunked as a major contributor to crappiness in software, ...'.

That said, the date format used in the message is such a rare and blatant infringement of RFC 2822, that there is really no excuse to bend backwards to support that format.

Say we really support
  Date: Fri, 2017-6-30 18:38:10
which is already *MISSING* the time zone information, so the time really means nothing here, the next poorly written system will produce:
  Date: Friday 6/30/2017 6:38 PM
and insist that that be interpreted as well. There is no end to it since there are many different date/time format in use. That's why a standard was defined, and as I said, this is the first infringement I've come across in many years.