From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; N; NT4.0; en-US) Mozilla/M14 de-AT BuildID: 2000022820 Mails with localized, e.g. German, Date: tag in the header appear with date 1.1.1970. Only english date/time abbreviations are properly recognized. Reproducible: Always Steps to Reproduce: 1.create mail with non-english date: tag in header 2.send and receive mail 3. sort mails by date Actual Results: mail programs states that mail was sent 1.1.1970 Expected Results: mail date should be, e.g., 03-17-2000. english date tag in header: Date: Fri, 17 Mar 2000 12:29:40 +0100 german date tag in header: Date: Di, 14 Mrz 2000 16:56:44 +0100 Perhaps, it's safer to sort by the time stamp of the smtp server.

Someone, please check this out and confirm this bug. I can't do it until Monday.

>1.create mail with non-english date: tag in header Could you tell me how to do that? I am not familiar with localization. Tao, are we using localized dates in 4.x? I am using 4.7 japanese but not see localized date string in a mail header. Date: Mon, 31 Jan 2000 19:11:43 -0800 From: Naoki Hotta <nhotta@netscape.com> X-Mailer: Mozilla 4.7 [ja] (Win98; I) cc to rhp, putterman, ducarroz.

In RFC, there is a section for "DATE AND TIME SPECIFICATION". ftp://ftp.isi.edu/in-notes/rfc822.txt It deos not inlcude localized strings. So the date in header should not be localized.

The actual mail headers as defined by the standard which nhotta cites uses English as a "canonical" format -- nothing we can do about it. In the thread pane, we should display a localized date format. Isn't that working?

Yes, the thread pane can display localized date format.

A non-english Date: tag can't be created with Netscape, but some other software unaware of RFC 822 does! Netscape/Mozilla does not properly read in the -erroneous localized- date/time and therefore writes 1.1.1970. The latter dat/time is correctly localized. - Christophe Veber

Do you have a suggestion on how to deal with non-standard date headers? How does a receiving mail-agent know which localized version to parse when receiving a mail message? It would be impractical to build in special handling for every possible illegal header. Headers must be canonical to ensure interoperability. It is unfortunate that the RFC uses US-English date strings for the canonical date format... Do you know which mail-agents generate these illegal email headers? And how wide-spread are they used? Do other popular mail-agent (e.g., Outlook, Eudora) handled these?

Outlook (Express), KMail and XFMail properly sorted mails with non-standard Date: tags. I guess they sort mail by the date of the smtp server, that is, the date/time coming with the first Received: tag. I think this approach is safer than anticipating thousands of mail clients.

hmmm, interesting. So the Received headers include dates formatted according to RFC 822, and it's only the Date header which uses the non-compliant date format? Can you attach a copy of these mail messages, so we can use it for testing? We should look into this. Should we use the dates from the 1st Received header instead of the date from the Date header? Reopening this bug for another evaluation.

I don't know how to forward within the Bugzilla system, so I forwarded sample mails with a localized Date: tag to the persons in the cc: list. If you didn't get it properly, please tell me. - Christophe Veber

> Outlook (Express), KMail and XFMail properly sorted mails with non-standard > Date: tags. Are they also display the dates properly?

Hi Christophe, Who did you forward the mail to? I have not received anything. To include an example in the bugzilla report, please save one of these emails in its raw form (including the headers) to a plain text file, then you click on the "Create a new attachment" (below "Summary", "Status Whiteboard" and "Keywords"), and then attach the plain text file to the bug.

Outlook, etc., also display the date properly.

One more question, does outlook seem to be using the server time stamp or interpreting the localized date?

Outlook seems to use the server time stamp.

When we say the "server time stamp", do we mean the date-time of the earliest Received header? Using the Received header date-time insteaded of the Date orig-date seems to be wrong, although practically they are probably pretty close (unless the clocks on the 2 systems our out of sync as in the attached example). If we wanted to do the "right" thing, could we look at the Received header only if the Date header is malformed? I see 3 choices: (1) Do nothing and be "correct" but be user-unfriendly and appear to fail as compared to competitive products, (2) Use the earliest Received header, but be technically incorrect, or (3) Use the earliest Received header only if the Date header is malformed. Ignoring implementation issues, I favor (3). I'd guess that normally we do not parse the Received headers and that we would not want to unless necessary. If the Date header is malformed, is it easy to grab the Received headers at that point and then to parse them?

I don't know the sources. but from the above problem it seems to me that an error or undefined value can't be distinguished in Mozilla from a correct date.

I don't know the source either, but it is must parse the string. "Di" and "Mrz" are not going to recognized as valid tokens and I assume that is why the date is being reported as 1.1.1970. So I guess we can catch the malformed date headers pretty easily, but then we need to grab the earliest Received header and parse its date string.

Reassign to ducarroz (or please reassing to the right person). Please implement the third option mentioned by bobj's comment (2000-03-21 01:35).

Reassign to rhp

This time is really reassigned!

I think this is working for me...I tried the attached message and it looks correct. Possibly someone can verify. - rhp

I'm going to pass this on to marina. The test message simply did not show any header with 9/11/2000 Win32 build. I thought that there is dependency on there being a first line like this: From - Wed May 05 14:37:44 1999 The test message does tno contain this and the header does not show in thread pane at all -- including the dates. if you supply the correct date in the above format, it does show. I wonder how people were testing this to re-produce the problem. Good luck.

i am verifying it as wfm ( reporter can add comments if he still has a problem)

Problem not resolved: I use Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1. When I receive mail with a localized Date: tag, Netscape Mail shows it as 01-01- 1970. Christophe Veber

I am not sure i'll be able to test this bug: - when changing regional default locale settings the Western Europe and USA have the same format in Date.Unfortunately i am not able to chose a long format for date display, mozilla uses a short one by default, so i can not get a mail to display day/month/year in d/mmmm/yyyy. We have to have an option in Prefs to be able to chose between short and long format. ( actually it is possible to chose a different default locale for Japanese and using the short format mozilla sorts mails with the localized tags just fine, Xianglan tested this).Well, my guess is that the SMTP server stamps the mail, we dont have a localized server here, the testing message that Christophe attached shows up as a blank folder probably because of its localized tags. It looks like i'll need the reporter help to verify this bug when it'll get fixed.

After editing the mail header (changing date into a bogus name) i was able to see this problem in my local folder. The edited mail was stamped as 12-31-1969....So we can reproduce this problem (differently) in house.

The behaviour depends on the Date: stamp of the sending mail app, not on the date given in the various Received: entries in the header which are created by smtp servers. I don't think this problem depends in short/long date display.

Cristophe, you're right, in my last comments i've said that after changing the date stamped by the sending server to a bogus one i was able to reproduce this bug. I mentionned long format as opposed to short as a way to reproduce it.. I don't need mozilla displaying a long format now when i know another way to see this bug.

How will you solve this? Afaik, the Date: stamp must not be localized (see RFC 822 mentioned above), parsing the Date: using the client's localization would be convenient, but not necessarily compliant. The problem we talk about here is caused not be Outlook or Communicator, but by ill-tested client software, so perhaps it is safer to get the date by which mails are sorted from the Received: tag(s) of the smtp server(s): a) The probability is higher that their time is correct, b) th probability is higher that the date/time is given by an english, unlocalized server software.

<How will you solve this? Cristophe, please read comments #17 from bobj, especially (3) that he favors for malformed headers.

OK, (when) will this issue be solved?

reassigning to ducarroz

Really reassign to me...

i am getting more and more mails stamped with incorrect day, now they are arriving as year 2029 or 1969. The way the server/client talk now introduces a lot of inconviniences for the user when the date tag is localized or malformed. It gets filed at the bottom or the top of your Inbox according to the way you sort and it is easy to disregard and miss such mail. I think we have attend to this problem and fix it as soon as our resources allow us... Changing the summary

I don't think we're going to be doing this any time soon. Renominating for reconsideration by triage team.

Discussed in 2/25 bug meeting with Mktng, PjM, Engineering. Decision to minus and future.

related to bug 131983?

Don't think so. Date: tag in bug 131983 looks OK and _not_ localized. Christophe Veber

Can someone take a look at bug 132779 and dupe it to this if it looks similar enough?

I am tempted to mark both bugs #131983 and #132779 as dups of this one. This bug is a more general case and talk not only about localized headers but also about malformed headers that eventually would be stamped as 1/1/1970 or 12/31/69. Bob, could you please look into it?

i take my previous comments back, the other two bugs are not dups or this one, even though the results look the same and might confuse about the cause. Let's leave this bug as dealing with localized headers only and i post my comments about other two( that might be dups between them) on #131983

Maybe its offtopic there, but I see same bug without localised date in mail. Now I have 5 mails in inbox, dated 01.01.1970. No one (as I can see) havent localized date. 4 from it have normal date when viewing message - in preview pane, or in single window. 1 of this message have incorrect date (with y2k bug - from old version of elm - and contayn 102 year :) ) for example this is header from non-localized-date message, correctlu showed in message pane, and incorrectly showed in message list like 01.01.1970 02:00: (addresses is bastardized by adding random letters - against spam-bots) --------------------------------------------------------------------------- From - Tue Mar 05 16:20:21 2002 Received: from server1.btv.lv (mail.btv.lv [217.198.224.80]) by sun3.lateko.lv (8.9.3/8.9.3) with ESMTP id QAA12768 for <iavz@latekoz.lv>; Tue, 5 Mar 2002 16:19:39 +0200 (EET) Received: from r3u6i4 (unknown [10.20.239.18]) by server1.btv.lv (Postfix) with SMTP id 28328FA44D; Tue, 5 Mar 2002 16:19:39 +0200 (EET) Message-ID: <006e01c1c450$9bf2e860$12ef140a@btv.lv> From: "Aleksandrs Volperts" <quizz_1@mboxi.riga.lv> To: "Igor Velkov" <iavz@latekoz.lv>, "tink" <tinkz@lpstudioz.net> References: <3C84B1B5.C30204D@latekoz.lv> <144436927488.20020305082010@lpstudioz.net> <3C84D04C.29A09F85@latekoz.lv> Subject: =?koi8-r?B?UmU6IFtGd2Q6IERFTEZJIC0g5M/Fwcza2iDJzNXW3iDOxc/F1NXK3g==?= =?koi8-r?B?IN/BzdfZysXJ0M/NzMzR18HFz9/VPV0=?= Date: Tue, 5 Mar 2002 16:17:56 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Length: 1159 Status: X-Mozilla-Status: 8003 X-Mozilla-Status2: 00000000 X-UIDL: 3bce7c4a000010af Мои старые болванки датируются 98 годом. Никаких проблем с ними не было.

I tried the message in comment #44 using 4/26 commerical branch. The subject was blank but date was shown as "3/5/2002 6:17 AM" and sender shown as "Aleksandrs Volperts". I got a same result using 4.x. It might be caused by bug 131983, please try using the latest build.

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

It seems that there is another strange format of date-since-1900 in use. Have attached a sample. Thks.

Is the behaviour shown in attachment (id=87035) really identical to my submission (id=6738)? Peter Woo's Date: tag looks RFC-compliant. Perhaps this is rather a Y2K problem?

could someone summarized a list of mailer which will produce these localized date in the RFC822 headers?

Bug 73565 may be a duplicate.

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

Frank Tang: Do you want to assess the relevance of the flaw or do you want a mailer that creates malformed Date: tags?

simon will take a look at this bug and summarize it to see where the problem arises specifically.

Win32 app that sends german localized Date: tag. The program can be used to see if Netscape mailer behaves correctly.

Simon: Perhaps the demo mailer helps? Was comment #54 about which mail programs send mailformed Date: tags? Some bulk mailers do, like StreamServe MailOut 3.0. Otherwise, see comments #8, #31.

Perhaps there is no way to handle all date formats in the world (including erroneous formats...). Actually, is it applicable that for unrecognized dates (such as those 1900's), Mozilla simply assigns the PC datetime stamp to it?

See comment #8 ff.: You could use the Received: tag of the SMTP server instead or as a fall-back. It seems to be Mozillas intent to use the date when the mail was sent as the sorting criterium, not the reception time. Therefore, using the Received: tag is more consistent. Will this bug be fixed soon? This was opened 2000-03-17 !

reassigning to smontagu and marking nsbeta1+ per mcarlson

Info: The bug is not fixed in the following versions of Netscape & Mozilla: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0

i18n triage team: nsbeta1-

date time was displayed as 06/02/2101 06:28 it was actually 01 dec 2003 13:20:06

Set Bug 73565 as "Depends on:" of this bug, which is bug for "No Date: header" case.

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

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

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

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

works with Firebird Version 1.0.6 (20050716). Nice to see that - but: what this fix intentional?

(In reply to comment #68) > works with Firebird Version 1.0.6 (20050716). > > Nice to see that - but: what this fix intentional? Firefox? Where is firefox parsing a "date" "header"?

Sorry - I mixed it up: I meant Thunderbird, of course.

I don't see any evidence of a patch that was checked in or reference to another specific bug that fixed this. -> WORKSFORME

who will verify/close this?

I have several e-mails with the date in the formats: Date: WED,22JUN2005 21:14:15 -0500 or Date: ¿ù, 04 7 2005 03:29:06 +0100 These show up as 12/31/1969 4:00 p.m. in Thunderbird 1.0.6 (20050716)

(In reply to comment #68, comment #70, comment #71, comment #72) To Christophe Veber(who changed to FIXED at 2005-07-30 02:29 PDT) and Jason Bassford (who changed to WORKSFORME 2005-07-30 06:48 PDT) : Could you attach evidence of "FIXED" or "WORKSFORME", please. (1) Malformed Date: header which was displayed "correctrly" by your Thunderbird. (2) Displayed "correct" date by your Thunderbird when malformed Date: header. - What was displayed? - Where it was displayed?

Christophe Veber, do you set mailnews.display.original_date to true?

for comment #74: (1) The attached header displayed properly with my Thunderbird (version 1.0.6 (20050716), german WinXP). (2) In Thunderbird, my Inbox mails are sorted by "Date", with the mail with the malformed Date: appearing correctly on top (displaying "17:25" for today)

for comment #75: No, the setting is ... pref("mailnews.display.original_date", false); // display date string from mail headers without interpreting ...

(In reply to comment #76 & comment #77) Your case, original case of this bug and "localized but well formed date header" case, looks to be resolved in your environment. But according to comment #73, problem when "localized header" still exists apparently even when "malformed" is "localized weekday" only. Problem when "corrupted date header" is not resolved yet too. Christophe Veber, please keep this bug OPEN, since this bug already involves "malformed/corrupted date header" case, and since many bugs are already closed as DUP of this bug.

cf comment #78

This started happening to me today in Thunderbird 1.5 beta 1. It worked in "Aug" and "Sep" (regardless of the weekday), but now is "Okt"/"Oct" and some mails get tagged as 01.01.1970. The "Received" headers have the correct English format.

Changing conmonent from "MaiNews: Internationalization" to "MailNews: MIME", because "malformed Date: header" handling problem.

Reassigning to default bug owner due to component change.

At last, David has started to care on "No Date: header" case in Bug 166254.

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

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

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

mailnews.use_received_date=false(default)/true is added to latest-trunk nightly, and user can choose mail-date(date in "Date column") from Received: instead of from Date: header now. This enhancement can be a relief of this bug's case for some(I think many) users. See Bug 341548 for detail.

mailnews.use_received_date was unfortunately landed on Tb2, but it removed from Tb3. Tb3 introduced "Received" column unstead. See bug 166254.

This bug was started 2000-03-17. Today is 2013-01-22, and the bug is still alive and well. Could we please get a bit of action on this bug? According to comment #8, other programs handle incorrectly formatted dates, also posted back in year 2000. Voting +1 for me. I happen to be running on: User agent: Mozilla/5.0 (X11; Linux x86_64; rv:18.0) Gecko/20100101 Firefox/18.0 SeaMonkey/2.15 Build identifier: 20130105222033 The official Mozilla build installed via UbuntuZilla.

Oh, per comment #87 on this thread, that preference is not in my build of SeaMonkey. Nothing comparable appears when searching for preferences via: mailnews.*date*

I'm not sure if this is the right issue, correct me if I'm wrong: I received an email with the following header: Date: =?Windows-1252?B?RnJpLCAxNyBKdWwgMjAxNSAxNTo1ODoyNyArMDIwMA==?= but the date is displayed as 01.01.1970 01:00 in Thunderbird 38.1.0. Is this header malformed or is thunderbird just not able to read it unlike other applications (e.g. K-9 Mail on Android is displaying the correct date) Should I open a new issue?

(In reply to Peter from comment #95) > I'm not sure if this is the right issue, correct me if I'm wrong: > > I received an email with the following header: > Date: =?Windows-1252?B?RnJpLCAxNyBKdWwgMjAxNSAxNTo1ODoyNyArMDIwMA==?= > > but the date is displayed as 01.01.1970 01:00 in Thunderbird 38.1.0. > > Is this header malformed or is thunderbird just not able to read it unlike > other applications (e.g. K-9 Mail on Android is displaying the correct date) Yes, that is a seriously malformed header. Date is a structured header, and RFC 2047 encoding an entire structured header is illegal. Please contact the author(s) of the application that originated said message and inform them that their application is seriously broken in this regard.

(In reply to Peter from comment #95) > I received an email with the following header: > Date: =?Windows-1252?B?RnJpLCAxNyBKdWwgMjAxNSAxNTo1ODoyNyArMDIwMA==?= ?B? means base64-encoded. https://tools.ietf.org/html/rfc2047#section-4 https://tools.ietf.org/html/rfc2231 $ echo 'RnJpLCAxNyBKdWwgMjAxNSAxNTo1ODoyNyArMDIwMA==' | base64 -d Fri, 17 Jul 2015 15:58:27 +0200 I'm not sure RFC 5322 allows this format. https://tools.ietf.org/html/rfc5322

Turns out Peter's issue has already been discussed in bug 276199 (RFC-2047-encoded Date header not parsed or displayed correctly) => RESOLVED INVALID

I've got a date header as date: 2017-11-15T09:52:25.025 that shows up as 01/01/1970 00:00

(In reply to Craig Emery from comment #99) > I've got a date header as > > date: 2017-11-15T09:52:25.025 > > that shows up as 01/01/1970 00:00 AFAIU, the date shown is in ISO 8601 format. https://en.wikipedia.org/wiki/ISO_8601 However, the Date format for emails is specified by RFC 5322 https://tools.ietf.org/html/rfc5322#section-3.3 The two are not compatible. (FWIW, I think it would be slightly better to display the Received date, instead of the beginning of the epoch, when the header cannot be parsed or doesn't exist.)

Comment on attachment 9018834 [details] [diff] [review] If the 'Date' header is invalid, use date from 'Received' header instead. If the 'Date' header is invalid, use date from 'Received' header or current time (if their is no 'Received' date) instead. This uses also to the date from 'Received' header, if there is no 'Date' header and no envelope.

(In reply to Alfred Peters from comment #102) > This uses also to the date from 'Received' header, if there is no 'Date' > header and no envelope. See also: Bug 73565: Messages that lack a Date: header are displayed as "sent in 1969/12/31"(or 1970/01/01, Epoc time) Bug 266434: if msg doesn't have a Date: header, we use the time we received the message Bug 512930: If mail of no Date: header is copied to IMAP folder, today is set as date of the mail (Tb's date display for no Date: header, malformed Date: header is inconsistent)

This is ugly all over. I added a bit more "Meister Proper": - Variable deliveryDate is really not needed. - No need to convert seconds back to PRTime if you grab the received time when it's available, that simplifies the branch were you get 'now'. - 'dateValue' wasn't a great variable name. - There was no need to store status values. - Moved the comments where they should go. Should we check 'rcvTimeSecs' before calling? m_newMsgHdr->SetUint32Property("dateReceived", rcvTimeSecs);

Comment on attachment 9018931 [details] [diff] [review] bug32216.patch (JK, v1) Review of attachment 9018931 [details] [diff] [review]: ----------------------------------------------------------------- (In reply to Jorg K (GMT+2) from comment #104) > Created attachment 9018931 [details] [diff] [review] > bug32216.patch (JK, v1) > > This is ugly all over. I added a bit more "Meister Proper": Looks good for me. > Should we check 'rcvTimeSecs' before calling? Unixtime should be an integer with values from 0 (1 January 1970) to 2^31 (~19 January 2038). However, we interpret the value as an unsigned value and therefore indicate a date up to ~2075. I don't think that's a problem.

(In reply to Alfred Peters from comment #105) > > Should we check 'rcvTimeSecs' before calling? > Unixtime should be an integer with values from 0 (1 January 1970) to 2^31 > (~19 January 2038). I meant: if (rcvTimeSecs) m_newMsgHdr->SetUint32Property("dateReceived", rcvTimeSecs); Otherwise we will actively set 1 January 1970 which is undesired. But what happens when the property is unset? Actually, can you explain to me how the patch fixes the headline here: Mail date 1.1.1970(or 12.31.1969) when Date: header is localized or malformed Didn't it default to "now" before in that case?

(In reply to Jorg K (GMT+2) from comment #106) > > > Should we check 'rcvTimeSecs' before calling? > if (rcvTimeSecs) > m_newMsgHdr->SetUint32Property("dateReceived", rcvTimeSecs); No. Even in the old code 'rcvTimeSecs' was initialized with 0 and set in any case. > Otherwise we will actively set 1 January 1970 which is undesired. But what > happens when the property is unset? I never tested that. But we definitely don't want a random value. > Actually, can you explain to me how the patch fixes the headline here: > Mail date 1.1.1970(or 12.31.1969) when Date: header is localized or > malformed > > Didn't it default to "now" before in that case? No: | if (date) | { // Date: | - PRStatus timeStatus = PR_ParseTimeString (date->value, false, &resultTime); | if (PR_SUCCESS == timeStatus) | - m_newMsgHdr->SetDate(resultTime); SetDate() was called only if PR_ParseTimeString() was successful, ... | } | - else | - { // PR_Now() or if there was no 'date' at all. | - PRTime resultTime = PR_Now(); | - m_newMsgHdr->SetDate(resultTime); | - }

Comment on attachment 9018931 [details] [diff] [review] bug32216.patch (JK, v1) OK, thanks for the explanations, I'll get this landed.

Sorry, I straightened out some white-space and added 'delivery' date back in for consistency.

Pushed by mozilla@jorgk.com: https://hg.mozilla.org/comm-central/rev/6876e8c9ea75 If the 'Date' header is invalid, use date from 'Received' header instead. r=jorgk

Beta (TB 64): https://hg.mozilla.org/releases/comm-beta/rev/6e8c0cff670e

Comment on attachment 9019434 [details] [diff] [review] bug32216.patch (JK, v2) Good for 60.4.

TB 60.3.2/60.4 ESR: https://hg.mozilla.org/releases/comm-esr60/rev/b02fba3200f5c14b88dcb672fc9fd4aa8c3b8083

FWIW, Bugzilla currently produces email messages with "Date" headers in this format. I'm surprised that nobody found that irritating enough over the past 20 years to fix it before now. Thanks for getting to this one, folks. From a Bugzilla message I received just this morning: Date: =?UTF-8?Q?Fri=2C=2023=20Nov=202018=2015=3A36=3A52=20=2B0000?= X-Bugzilla-Reason: =?UTF-8?Q?AssignedTo=20CC?= X-Bugzilla-Type: =?UTF-8?Q?changed?= X-Bugzilla-Watch-Reason: =?UTF-8?Q?None?= X-Bugzilla-Severity: =?UTF-8?Q?enhancement?= X-Bugzilla-Status: =?UTF-8?Q?ASSIGNED?= X-Bugzilla-Priority: =?UTF-8?Q?P1?= X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: =?UTF-8?Q?bug=5Fstatus?= [...] Almost every single field is encoded using RFC 2047 encoded-word format.

Very strange, I see: Date: Fri, 23 Nov 2018 15:52:34 +0000 X-Bugzilla-Reason: CC AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Classification: Components X-Bugzilla-ID: 32216 Etc.