Dragging a msg from TB into Windows Explorer adds wrong Date and Contents to the created .EML file

RESOLVED DUPLICATE of bug 939519

Status

defect
RESOLVED DUPLICATE of bug 939519
7 years ago
6 months ago

People

(Reporter: michel.merlin, Unassigned)

Tracking

(Blocks 2 bugs)

13 Branch
x86_64
Windows 7
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Reporter

Description

7 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.56 Safari/536.5

Steps to reproduce:

I dragged a plain simple message (no attachment), from Thunderbird message pane, to Windows Explorer file pane


Actual results:

A text file was duly created, containing the message MIME source. However that MIME source had some additions and alterations, and the file Modified Date, instead of being the Date in the MIME source (as happens when dragging from Outlook Express), is the date... when I dragged the file!!! This error (that prevents me from any further use of the file) is apparently caused by the 1st line that TB added in the file:

"From - Tue Jun 19 10:39:57 2012"


Expected results:

TB should do as OE6 does:

- The EML file Contents should be EXACTLY the MIME source, with no addition, no removal, no other alteration

- The file Modified Date should be EXACTLY the one specified in the "Date: " line in the MIME source, AT THE SECOND, and ACCORDING TO THE TIME OFFSET specified in the MIME source following http://tools.ietf.org/html/rfc5322#section-3.3 RFC5322 §"3.3.  Date and Time Specification".

(Bug report submitted Tue 19 Jun 2012 14:39:00 +0200)

Updated

7 years ago
Blocks: 227305
Reporter

Comment 1

6 years ago
This bug 766073 prevents from using Thunderbird
~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--~-
This bug, while preventing from using TB as email client in serious handling of a significant amount of email, is still NOT FIXED in http://www.mozilla.org/en-US/thunderbird/24.1.0/releasenotes ThunderBird 24.1.0 of 29 Oct 2013. Yet it is unfortunately labeled "UNCONFIRMED", which is IMO inconsistent with its obviousness.

Could someone escalate it to some administrative level and development actions matching its real importance? TIA,

Versailles, Sat 16 Nov 2013 17:18:10 +0100

Comment 2

6 years ago
(In reply to Michel Merlin from comment #0)

Hello Michel,

thank you for filing this report with your observations of problems and proposals, which is appreciated. I'm sorry you did not see a reaction so far, but unfortunately that can happen quite easily with thousands of bugs and RFEs around, and only a very limited number of people looking into them. No comments since 2012-06 /might/ (in a limited and unreliable way) also be read as an indication that there was not much user concern about this, or not many other users affected.
You may or may not be aware that TB is now almost exclusively maintained by the volunteer community (of which I am one).

> Actual results:
> 
> A text file was duly created, containing the message MIME source. However
> that MIME source had some additions and alterations

Can you pls list all of the additions and alterations which you think should not happen.
So far, you only mentioned the added line at the top of each msg:

From - Tue Jun 19 10:39:57 2012

I think that line reflects when you downloadedd the msg into TB. It's not related to the "Last modified on" date attribute of the resulting .eml file.
I'm not sure for what purposes the line is used, we need to find out from folks who know.
:mkmelin, do you know, or can you cc someone who does?

I recall this "From - " line causing some other bugs on record, so IF it's possible for TB to operate without adding that line, by intuition I'd recommend that we stop adding it, or rather add it in another more standards-conforming way as a X-Mozilla-From header or some such. However, I don't think it's a high-priority issue.

Can you describe in what way this line is causing problems for you?

> and the file Modified
> Date, instead of being the Date in the MIME source (as happens when dragging
> from Outlook Express), is the date... when I dragged the file!!! This error
> (that prevents me from any further use of the file) 

Well, if you view the msg.eml file you'll still see the correct date which is in the Date: header of mime source. But I tend to agree with you, it would be better and more correct to use the original date of MIME Date: header as the "Last modified on" date for the .eml file. More so as the file system will add it's own "Date created" on the file anyway which already records when you drag-created the file. Comparing with many other bugs I've seen, this would be a minor problem, almost enhancement.

OK, you couldn't sort multiple .eml files by their internal Mime Date in your file manager, but then, OS file systems are not really made for doing that. Any mailing application will still easily sort those .emls correctly when you view them or otherwise import them. It's not like we're changing the original headers.

Can you explain why you consider this a serious failure which would prevent users from using TB?
I don't quite see that, and again, many other known problems are more problematic than that and affecting more users.

> Expected results:
> 
> TB should do as OE6 does:
> 
> - The EML file Contents should be EXACTLY the MIME source, with no addition,
> no removal, no other alteration

I disagree with that, and that part is certainly wontfix.
We save certain data in the msg source on purpose and by design, e.g. information about replied-status or tags that you assigned to the message:

X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
X-Mozilla-Keys: $label1

It's looks reasonable to me that we preserve that information when you export the msg via drag n drop, so that when you re-import the same msg into TB, it will still have all the same attributes.
If we wouldn't preserve it, we'll have other users complain that we lost their TB-specific meta-information on the msg. I'm also failing to see how this could create problems, but we're open to hear them if there are. (Certainly no priority here either).
Flags: needinfo?(mkmelin+mozilla)
Reporter

Comment 3

6 years ago
The MIME source is altered when the message is downloaded into TB
~--~--~--~--~--~--~- ~--~--~--~--~--~--~--~--~- ~--~--~--~--~--~-
Thx "Thomas D." 2013-11-16 09:42:51 PST for your reply.

> Can you pls list all of the additions and alterations which you think should not happen

As I said in my comment #0, "From - Tue Jun 19 10:39:57 2012" is "the 1st line that TB added". However as you kindly made me realize, the date added is NOT (as I too fast wrote in my comment #0) "the date... when I dragged the file!!!", but "when (someone) downloadedd the msg into TB". I made sure of it this way:

- In my XPMode (the free Windows XP Pro running in a Virtual PC in my Windows 7 64bit Ultimate), I chose in my OE6 a message whose MIME source contained the line "Date: Mon 11 Nov 2013 16:44:00 +0100". I dragged that message from OE to a folder in Windows Explorer (let's call it "C:\XPMode\TEMP"), which created as usual an .EML file with its Name being the Subject (with little adaptations unrelated here), its contents being EXACTLY the MIME source of the message, its Date in Windows Explorer Properties being "Monday 11 November 2013, 16:44:00", i.e. as EXACTLY as possible (given the wrong way Windows handles dates) the one stated on the "Date" line in the MIME source.

- In my Win7 64bit I navigated an instance of Windows Explorer to the Virtual PC then to the "C:\XPMode\TEMP" folder, and from there dragged the said file onto TB message pane, where I released the mouse today Sat 16 Nov 2013 at 19:24:00 exactly (+0100, i.e. GMT+1), which duly created a copy of the message, that showed the right date (Mon 11 Nov 13 16:44) and whose MIME source (Ctrl+U) was identical excepted it had 6 lines added:

- at top:

From - Sat Nov 16 19:24:00 2013
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
X-Mozilla-Keys:                                                                                 
- at bottom: 2 empty lines

- Then in my Win7 64bit I clicked the message in TB message pane and dragged it onto a folder (let's call it "C:\Win7\tmp"), where I released the mouse 1 minute later, i.e. at 19:25:00 exactly, which created as due an .EML file with its Name being the Subject (with the same little adaptations), its contents being EXACTLY the MIME source of the message IN THUNDERBIRD, its Date being NOT the one stated on the "Date" line in the MIME source, BUT the one stated on the NEWLY ADDED "From - " line in the MIME source of the message IN THUNDERBIRD.

Hence the Date falsification does occur as I wrote when the message is dragged from TB to Windows Explorer, but the MIME source alteration entirely happens earlier, at the moment the message is dragged INTO Thunderbird.

Versailles, Sat 16 Nov 2013 23:32:10 +0100
Reporter

Comment 4

6 years ago
This bug is grave, yet easy to fix
~--~--~--~--~--~--~- ~--~--~--~--~
The adding of 6 useless lines just comes on top of the numerous annoyances so many sites or email servers find smart to uselessly add into MIME headers. But in addition this one is badly done, with a dreadful consequence, as TIME is very important in information handling, here in email handling.

Other sites, when adding useless stuff in MIME, at least duly call them "X-something" (safer because forbidden in "normal" headers, as explained in RFC822 and shown at end of its example http://tools.ietf.org/html/rfc822#appendix-A.3.3 ). Now Thunderbird does follow this safer advice in the 2nd, 3rd and 4th useless lines it adds, but FAILS to do so in the 1st one, which may be the reason why the wrong Date gets set in Windows Explorer.

This bug suffices to bar any serious use of TB in email handling (I don't feel alone having the 10 last years of my messages in line in OE, which is about 50,000 messages, of which each one gets correctly dated when dragged into Windows Explorer, from where I can send a zipped copy to anyone when necessary, without bothering to check the Date: it is ALWAYS accurate).

To fix this bug one needs just to change the 1st line added as follows:

X-moz-From - Sat Nov 16 19:24:00 2013

That way, the line will get ignored as due by all serious correspondents (programs, machines, humans), so its multiple stupidities (uselessness, wrong Date format as you can see in the RFC5322 that I referenced in my comment #0) will remain harmless.

Sure the real fix would be to simply, immediately and totally remove the 6 uselessly added lines; but if Mozilla people were able to understand that they would never had added them in the 1st place. So requesting the "X-" workaround may be the safest way to get the biggest damage timely avoided.

I just discover that this is precisely what you think:

> IF it's possible for TB to operate without adding that line, by intuition I'd recommend that we stop adding it, or rather add it in another more standards-conforming way as a X-Mozilla-From header or some such

Versailles, Sat 16 Nov 2013 23:33:00 +0100
Reporter

Comment 5

6 years ago
Responding (uselessly I am afraid) to the Useless Discussion
~--~--~--~--~--~--~--~--~- ~--~--~--~--~--~--~--~--~--~--~--
Oppositely I don't agree with your:

> I'm not sure for what purposes the line is used, we need to find out from folks who know.
> :mkmelin, do you know, or can you cc someone who does?

This (Trying to find where comes that error) would only lose time, get you drowned in ocean or desert, and hit the few people who are against progress, and who will draw you in infinite quibbles. This bug would get better fixed immediately by the 1st person who has access to the code.

As you saw I dramatically disagree with your

> However, I don't think it's a high-priority issue... Comparing with many other bugs I've seen, this would be a minor problem, almost enhancement

Handling Time correctly is of paramount importance in information handling; falsifying Dates is unacceptable and very damaging. Ask developers about the dates of various source editings, ask judges and lawyers, ask managers in any business, ask real journalists (if you can still find one)... In addition, here the fix is easy, so if everyone was forthcoming there would be no discussing.

> OK, you couldn't sort multiple .eml files by their internal Mime Date in your file manager, but then, OS file systems are not really made for doing that

If time were not important, while do OSes put Dates at all in their FS? Discussing such evidences is totally useless and would spend more time than fixing the problem.

> Can you explain why you consider this a serious failure which would prevent users from using TB?

How would you trust a program who intentionally falsifies information? and most importantly, the Times? and whose staff (volunteers or not) advocate the falsification instead of blushing and rushing to fix it?

> and again, many other known problems are more problematic than that and affecting more users

Care to bring some examples of these "known problems" that would be "more problematic", and of these (more numerous) "users"?

> I disagree with that, and that part is certainly wontfix.
> We save certain data in the msg source on purpose and by design, e.g. information about replied-status or tags that you assigned to the message: ...

This is the proof that you are NOT willing that Thunderbird improves or only gets fixed. The email messages anyone receives already have a lot of headers, and email remained efficient only because good management prevented every little chief to add his own headers. If YOU want to add some headers, especially 4 in a row (X-Mozilla-Date, X-Mozilla-Status, X-Mozilla-Status2, X-Mozilla-Keys), then it's up to YOU to explain why. Unless you do, I find them useless and even damaging.

> It's looks reasonable to me that we preserve that information when you export the msg via drag n drop

Everyone has some information that he sees "reasonable... to... preserve". The more you add, the more you dilute the real important one, and particularly, the message body and the fundamental headers (From, To, Subject, Date, References, Message-ID, Received, MIME-Version, Content-Type, Content-Transfer-Encoding).

> If we wouldn't preserve it, we'll have other users complain that we lost their TB-specific meta-information on the msg

I don't buy this. And you won't be able to bring real examples.

> I'm also failing to see how this could create problems

This discussion alone is a problem bigger than fixing that obvious flaw (so obvious that, now that your advocating it opened my eyes, I doubt it was inadvertent)

> but we're open to hear them if there are

As "open" as saying, against evidences and before answers:

> (Certainly no priority here either)

So I realize I wasted my time and effort trying to help TB to improve or cure its flaws.

Versailles, Sat 16 Nov 2013 23:48:40 +0100

Updated

6 years ago
Blocks: 939519

Updated

6 years ago
Blocks: 939575
The mbox separator should't get there in there (but that's not the date used anywhere). 
I don't have a strong opinion about the X-Mozilla-Status headers, but i think ideally they shouldn't get exported as it may be unexpected, if thy actually are applied when you import the msg (didn't try).

Don't know if this bug adds anything beyond bug 939519 + bug 939575.
Flags: needinfo?(mkmelin+mozilla)

Comment 7

5 years ago
(In reply to Thomas D. from comment #2)
> Well, if you view the msg.eml file you'll still see the correct date which
> is in the Date: header of mime source. But I tend to agree with you, it
> would be better and more correct to use the original date of MIME Date:
> header as the "Last modified on" date for the .eml file.

I'm not sure about this, but certainly I wouldn't say it's wrong to
set the "last modified on" date to the actual time the file was created.
If you open a picture in GIMP or Photoshop and save it, I expect the field to
be the current time, not the time the EXIF info says the picture was taken at.

Another point to consider is that the Date: header is set by the sender and
cannot always be relied on or expected to be consistent with the recipient's time.

> OK, you couldn't sort multiple .eml files by their internal Mime Date in
> your file manager, but then, OS file systems are not really made for doing
> that. Any mailing application will still easily sort those .emls correctly
> when you view them or otherwise import them. It's not like we're changing
> the original headers.

I strongly agree.

If having the "last modified on" time as one desires is so crucial for one's
whatever reasons, it shouldn't be that hard to write a small script that
reads the header and sets the time, something like:

touch --date="$(sed -ne 's/^Date: //p' "$EML")" "$EML"
Reporter

Comment 8

5 years ago
Created and Last Modified dates are for Envelope and Contents
~--~--~--~--~--~- ~--~--~--~--~--~--~--~- ~--~--~--~--~--~--~
(In reply to Seungbeom Kim from comment #7)
> I'm not sure about this, but certainly I wouldn't say it's wrong to set
> the "last modified on" date to the actual time the file was created.

Why would OSes (Windows at least) define and maintain both "last modified" and "created" dates, if not to make them DIFFERENT? so it IS wrong to « set the "last modified on" date to the actual time the file was created ».

What could be done in our case (dragging a message into Windows Explorer as an EML file) is to set the "created" to the date the stuff was dragged, and the "last modified" to the date the internal information has been actually last modified (i.e. to the "Date:" in the MIME  headers). This (which makes the "created" date being often more recent than the "last modified" one) would be more consistent with what is done everywhere in Windows and with what users are accustomed to and expecting.
> If you open a picture in GIMP or Photoshop and save it, I expect the field to
> be the current time, not the time the EXIF info says the picture was taken at.
This is what is done most often for "created" date after "Save As", NOT ALWAYS after simple "Save", and most often NOT for "last modified". For instance in many image editors AFAIK there are plenty edits that put the result (despite a "modified" file) in the same file with keeping its filename and "last modified" date unchanged.

As already discussed above, there are plenty FORMAL or THEORETICAL reasons on both sides. But once people have been long confronted to REALITY they most often settle on the way I recalled above ("created" for the date when the PHYSICAL RECORD ON DISK was first created, "last modified" for the date when the REAL INFO contained in it was last modified).

(Thomas D. wrote in comment #2)
> OK, you couldn't sort multiple .eml files
> by their internal Mime Date in your file manager,
> but then, OS file systems are not really made for doing that...
(Seungbeom Kim wrote in comment #7)
> I strongly agree.
This view seems to me too much focused on the technical organization (disk, files) and too less on the real information (text, images) it is in charge of conveying. Windows Explorer and Outlook Express are just tools to handle information, with differences more historical than fundamental in their technical bits (e.g. the same series of messages is called a "folder" in OE but a ".DBX file" in WE). The end user, being more focused on the ground real stuff, is better satisfied and served when both OE and WE concur to the same task as seamlessly as possible. Whence the general habits and expectations I recalled.

(In reply to Seungbeom Kim from comment #7)
> it shouldn't be that hard to write a small script... like:
> touch --date="$(sed -ne 's/^Date: //p' "$EML")" "$EML"
If so easy, why don't you or TB people write a real addon, instead of throwing a one-line script that, with no context or test sample, can't be used or verified or simply understood by most readers? BTW addons, requiring the user to search for them, to choose which ones to select and test, then which ones to keep and recommend, are just little-used workarounds that should only exist temporarily while testing and waiting until they get integrated in the program itself. Which, in FF and TB, happens very rarely...

Anyway if TB people were really willing that TB lives on, they would NOT have prevented for so long to fix the main hurdles in using TB, as this Bug 766073 - Dragging a msg from TB into Windows Explorer adds wrong Date and Contents to the created .EML file, Bug 787434 - Insert HTML deletes empty tag pairs, Bug 166541 - Add support for X-Unsent property in .eml files...

Versailles, Thu 10 Apr 2014 13:28:00 +0200

Comment 9

5 years ago
(In reply to Michel Merlin from comment #8)
> (In reply to Seungbeom Kim from comment #7)
> > I'm not sure about this, but certainly I wouldn't say it's wrong to set
> > the "last modified on" date to the actual time the file was created.
> 
> Why would OSes (Windows at least) define and maintain both "last modified"
> and "created" dates, if not to make them DIFFERENT? so it IS wrong to « set
> the "last modified on" date to the actual time the file was created ».

Both fields usually start out with the same value when the file is created,
simply because creating a file anew is considered as modification as well.
There's no rule saying that they should be different, and if you modify the
file later, they will become different.

> What could be done in our case (dragging a message into Windows Explorer as
> an EML file) is to set the "created" to the date the stuff was dragged, and
> the "last modified" to the date the internal information has been actually
> last modified (i.e. to the "Date:" in the MIME  headers).

That's one way that it *could* be done, which is why I said other ways
wouldn't be wrong. I'm not saying your way is wrong, either.

> > If you open a picture in GIMP or Photoshop and save it, I expect the field to
> > be the current time, not the time the EXIF info says the picture was taken at.
> This is what is done most often for "created" date after "Save As", NOT
> ALWAYS after simple "Save", and most often NOT for "last modified". For
> instance in many image editors AFAIK there are plenty edits that put the
> result (despite a "modified" file) in the same file with keeping its
> filename and "last modified" date unchanged.

I've seen simple image rotators that is launched from the Windows Explorer
context menu, run without its own window, and leave the modified date
untouched, and I agree that it can be useful. However, I would be surprised to
see more serious editors that don't update the modified date with successive
saves; for one thing, it could make sorting on modified dates much less useful.

> But once people have been long confronted to REALITY they
> most often settle on the way I recalled above ("created" for the date when
> the PHYSICAL RECORD ON DISK was first created, "last modified" for the date
> when the REAL INFO contained in it was last modified).

From the OS filesystem point of view, the real info is the bytes contained
in the file, and the OS filesystem modified date keeps track of that.

Anything above that cannot be relied upon to be consistent or even to exist;
e.g. when you drag attached JPEG files to Explorer, some files may have EXIF
info while others don't; are you proposing that only those with EXIF info
should have their modified date set to the EXIF DateTimeOriginal field, and
others to the current time?

> (Thomas D. wrote in comment #2)
> > OK, you couldn't sort multiple .eml files
> > by their internal Mime Date in your file manager,
> > but then, OS file systems are not really made for doing that...
> (Seungbeom Kim wrote in comment #7)
> > I strongly agree.
> This view seems to me too much focused on the technical organization (disk,
> files) and too less on the real information (text, images) it is in charge
> of conveying. Windows Explorer and Outlook Express are just tools to handle
> information, with differences more historical than fundamental in their
> technical bits (e.g. the same series of messages is called a "folder" in OE
> but a ".DBX file" in WE). The end user, being more focused on the ground
> real stuff, is better satisfied and served when both OE and WE concur to the
> same task as seamlessly as possible. Whence the general habits and
> expectations I recalled.

So the filesystem deals with lower-level stuff ("files"), while applications
(OE or Tb or whatever) offer another layer of abstraction ("messages") on
top of that. What's wrong with different layers doing different things?

You are probably right that I'm focusing on the technical side, but then
the filesystem modified date is inherently a technical stuff, not what
most end users should be paying that much attention to.

> (In reply to Seungbeom Kim from comment #7)
> > it shouldn't be that hard to write a small script... like:
> > touch --date="$(sed -ne 's/^Date: //p' "$EML")" "$EML"
> If so easy, why don't you or TB people write a real addon, instead of
> throwing a one-line script that, with no context or test sample, can't be
> used or verified or simply understood by most readers?

I don't know how to write an addon (though I wish I did), and no other
people with such a skill have volunteered to write and publish one yet.
If you're willing enough, you can learn to write one, or convince
other people with such a skill to do it for you.

> BTW addons, requiring
> the user to search for them, to choose which ones to select and test, then
> which ones to keep and recommend, are just little-used workarounds that
> should only exist temporarily while testing and waiting until they get
> integrated in the program itself. Which, in FF and TB, happens very rarely...

Yes, we know that the main developers have a different opinion when we
often see they delete existing features from the main products and let
users come up with addons to get the old behavior, in order to keep the
main products simple. Fortunately, it doesn't matter that much whether
the features are provided by addons, as long as the features are not
too exotic and there are addon developers willing to fill the gap.
Reporter

Comment 10

5 years ago
Created, Modified, Accessed dates in Windows Explorer, EXIF and MIME (sent) dates
~--~--~--~--~--~- ~--~--~--~--~--~--~--~- ~--~--~--~--~--~--~- ~--~--~--~--~--~--
(In reply to Seungbeom Kim from comment #9)
> Both fields usually start out with the same value when the file is created,
> simply because creating a file anew is considered as modification as well
Most people have known for a decade or two that when you copy-drag a file from a Windows Explorer window to another WE window, the then-created copied file gets the Drag-time as "Created" date, and keeps the (older) "modified" date from the original, because copying didn't modify the contents. I just re-re-re-re-re-tested it for you in my Windows 7 64bit Ultimate:

In C:\My\News I have:
Intel_may_marry_CPU_and_RAM_in_future_computers(ZDNet).htm
I Right-click and choose "Properties":
Created: Saturday 09 February 2013, 18:59:33
Modified: Friday 29 September 2006, 11:57:32
Accessed: Saturday 09 February 2013, 18:59:33

On Fri 11 Apr 2014 I copy-drag it to C:\My\Temp, where I release it on 10:07:00 +0200, which duly creates:
Intel_may_marry_CPU_and_RAM_in_future_computers(ZDNet).htm
I Right-click and choose "Properties":
Created: Today 11 April 2014, 10:07:00
Modified: Friday 29 September 2006, 11:57:32
Accessed: Today 11 April 2014, 10:07:00

> I've seen simple image rotators that is launched from the Windows Explorer
> context menu, run without its own window, and leave the modified date
> untouched, and I agree that it can be useful.
> However, I would be surprised to see more serious editors that
> don't update the modified date with successive saves; for one thing,
> it could make sorting on modified dates much less useful.

Just an example, IrfanView (4.37), despite free, is a well appreciated program, recognized as more complete and serious than many expensive ones. When you save an image after resize or resample, IrfanView has a checkbox for "Save file with original date/time". I won't retest this but IIRC most other operations offer same or similar options, and "Save As" offers even more, and the Default is adapted to the task, e.g. a simple rotate adapts the EXIF and resaves with original date. All image programs I used since 1995, even MS Paint, or paid programs from Ulead, Corel, etc, or (then expensive and renown) Paint Shop Pro, as well. And running some operations directly from WE without its own window (or any other "off the beaten track" or innovative features) is not a stamp of unseriousness, sometimes even the opposite.

> From the OS filesystem point of view, the real info is the bytes contained
> in the file, and the OS filesystem modified date keeps track of that.

This is true, but we differ about the exact limits of "the real info"; for most users IMO, the real info in an email message is the contents and the short MIME headers (From, To, Cc, Subject, Sent). The other MIME headers belong to the *envelope* hence are *external* to "the real info", because they are technical data whose purpose and effects are to make sure and let everyone check that the real info is truly conveyed, NOT to change it in any way.

I recall BTW that the MIME "Date" (which actually means "Sent") in an email message one receives, that is set by the sender's PC, is now almost always accurate (probably due to Windows clock being now by default automatically self-adjusting); the rare significant discrepancies between MIME "Date"and last MIME "Received" are caused by intermediate mail servers who retained it, which doesn't alter the validity of the "Date" (Sent).

Versailles, Wed 16 Apr 2014 11:42:40 +0200
Reporter

Comment 11

5 years ago
An addon to WINDOWS to redate files to their internal Date
~--~--~--~--~--~- ~--~--~--~--~--~--~- ~--~--~--~--~--~--~
(In reply to Seungbeom Kim from comment #9)
> when you drag attached JPEG files to Explorer, ... are you proposing that
> only those with EXIF info should have their modified date set to the EXIF
> DateTimeOriginal field, and others to the current time?

First I do regret that attachments in email have NOT their own Date; this is one of the reasons I use to ZIP my important attachments so my addressee knows the real original date. Now assume I received an email msg Dated 09 Jan 2014 12:00 GMT with an attachment last modified 08 Sep 2008; if I download on 10 Apr 2014 that attachment to WE, I regret the copy gets Dated 10 Apr, I would prefer it gets the MIME Date of the msg (09 Jan), and when I have the required 10 seconds free time I do change it that way. I personally never want to change it at that moment to the attach internal date (e.g. 08 Sep 2008 in my example, or EXIF for a JPG, or else), despite I recognize this could be an option if carefully done (engine AND INTERFACE, which is even more important). BTW MOST jpg have their EXIF nowadays, even automatically updated after edits.

Finally I think we could agree on a point: an addon (while waiting for integration) would be welcome, that would offer the user to select a group of files in WE and, with a click, redate the EML files in them to their own MIME Dates. This would be very useful when you have 3,000 files to redate in a folder.

Such addon, while made necessary by the way Thunderbird handles Dates, is not otherwise linked to TB, and should exist and work inside THE OS (Windows or else), and should address as well many other File Types, like the JPG that you appropriately brought in, and others.

Versailles, Wed 16 Apr 2014 11:43:30 +0200

Updated

6 months ago
Status: UNCONFIRMED → RESOLVED
Last Resolved: 6 months ago
Resolution: --- → DUPLICATE
Duplicate of bug: 939519
Reporter

Comment 13

6 months ago
"Matt" on Sat 10 Nov 2018 10:58 GMT ("2018-11-10 02:58 PST") wrote in apparently Comment 12 "Status: UNCONFIRMED → RESOLVED".
Which means that from now on, Dragging a msg from TB into Windows Explorer NO MORE adds wrong Date and Contents to the created .EML file.
Can anyone document this important change and its very important consequence? I saw nothing related to this, neither in https://www.thunderbird.net/en-US/thunderbird/60.0/releasenotes nor in https://www.thunderbird.net/en-US/thunderbird/60.3.0/releasenotes , and I am reluctant to verify this by installing Thunderbird again, with all the related risks (Windows 7 already changes the dates of my .EML files any time for arbitrary reasons, rendering them unusable, what a catastrophe if TB does it too). I totally stopped to use TB or Windows mail programs mainly for that reason: when you have *dozens thousands* .EML messages from 2004 to 2016 suddenly redated "Sat 10 Nov 2018 15:58", with no way back, this makes impossible to find or refer or use any of these files.
If that huge and old bug REALLY got finally fixed, I could at least try to install TB back.
Versailles, Sat 10 Nov 2018 16:29:10 +0100
Resolved *duplicate*. Meaning this was the same as bug 939519 and progress can be followed in that bug.
You need to log in before you can comment on or make changes to this bug.