User Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20100101 Firefox/13.0.1 Build ID: 20120614114901 Steps to reproduce: I replied to a message, which had in-line images. Actual results: In my sent message the in-line images were substituted by random other images (attachments from other messages, not relevant to the communication in the corrupt message), which were not the original ones. Expected results: Thunderbird should have preserved the original in-line images.

The corrupt messages appear with the wrong in-line images in 13.0.1 as well.

The corruption happens on my machine. While composing the reply, numerous incremental drafts of the same message are saved in Drafts folder and remain there as drafts after the message has been sent. At some point and without any particular action of mine, the in-line images are substituted one by one with random images from other incremental drafts, which belong to other conversations.

Not only shows in drafts, but sends messages with substituted (wrong) in-line images.

(In reply to Andrey Marinov from comment #3) > Not only shows in drafts, but sends messages with substituted (wrong) > in-line images. This could be similar to bug 765548.

(In reply to Hashem Masoud from comment #4) > (In reply to Andrey Marinov from comment #3) > > Not only shows in drafts, but sends messages with substituted (wrong) > > in-line images. > > This could be similar to bug 765548. It is similar.

Andrey, Can you clarify a few points. Are you using pop or imap When you say "incremental save" do you mean manually saving copies to the draft folder at various stages of composition.(BTW I use "send later for that) Do you also use the autosave option Tools>>Options>>Composition.

The account is using pop. "Incremental save" means Thunderbird is creating a new auto-saved draft each 5 minutes (Tools>>Options>>Composition: [check-marked] Autosave every 5 minutes). 50 minutes = 10 separate incremental auto-saved messages, which remain in the Drafts folder even after sending the message (I noticed this behavior in Thunderbird 12 for the first time; before, it was just 1 draft per composed message, which was auto-deleted after sending). I haven't saved the drafts manually. At some point of the message composition I was seeing a progress bar (probably also each 5 minutes) in the compose window, which was telling "attaching file..." or something like that.

I am not able to reproduce this is current trunk. (You should not be getting multiple copies of the draft) Perhaps if you could supply a testcase eml I could better determine that the problem is not a matter of one particular content type)

(In reply to Joe Sabash from comment #8) > I am not able to reproduce this is current trunk. > (You should not be getting multiple copies of the draft) > Perhaps if you could supply a testcase eml I could better determine that the > problem is not a matter of one particular content type) The communication cannot be disclosed. I would have to strip off all the writing, e-mail addresses and part of the message header data. Would that be fine to create and supply a testcase eml?

As long as the images structures are retained, that should be fine. Do you happen to know if those are remote images. Look for CID refs in the message source. (Ctrl+u)

(In reply to Andrey Marinov from comment #9) > fine to create and supply a testcase eml? Andrey, can you provide the testcase.eml?

(In reply to Andrey Marinov from comment #0) > Steps to reproduce: > I replied to a message, which had in-line images. Assuming "inline-image" as "<img src="cid:..."> of HTML mail. (In reply to Andrey Marinov from comment #7) > The account is using pop. Local mail folder is used in your environment. "Different image data while editing draft mail" was observed by following test. (1) Create a draft mail, Compact Drafts folder. Offset=0, Subject: draft-000 multipart/related text/html, <img src="cid:gif-000-000"> image/gif, Content-ID: <gif-000-000>, used image file = gif-000.gif (2) Edit the draft mail, change subject Original draft offset=0 Subject: draft-A-001 image location = mailbox:///C:/wada/@@@/Mail0/Drafts?number=0&part=1.2 shown image file = gif-000.gif (3) Open second Edit Draft window, change subject Original draft offset=0 Subject: draft-B-001 image location = mailbox:///C:/wada/@@@/Mail0/Drafts?number=0&part=1.2 shown image file = gif-000.gif (4) At first Edit Draft window, (4-1) Change image file Original draft offset=0 Subject: draft-A-001 used image file = gif-A-001.gif image location = mailbox:///C:/wada/@@@/Mail0/Drafts?number=0&part=1.2 (4-2) Save as draft Original draft at offset=0 is deleted New draft offset=4000 Subject: draft-A-001 used image file = gif-A-001.gif image location = mailbox:///C:/wada/@@@/Mail0/Drafts?number=0&part=1.2 (4-3) Compact Drafts folder draft at offset=0 is changed to mail of Subject: draft-A-001 Subject: draft-A-001 used image file = gif-A-001.gif image location = mailbox:///C:/wada/@@@/Mail0/Drafts?number=0&part=1.2 (5) At second Edit Draft window, (5-1) Subject: draft-B-001 shown image file at composition window = gif-000.gif (5-2) View image location (double click image) image location = mailbox:///C:/wada/@@@/Mail0/Drafts?number=0&part=1.2 shown image file at image location panel = gif-A-001.gif (5-3) Cancel at image location panel shown image file at preview window is still gif-000.gif (5-4) Save as draft Original draft at offset=0 is deleted New draft offset=4000 Subject: draft-B-001 image location = mailbox:///C:/wada/@@@/Mail0/Drafts?number=0&part=1.2 shown image file at composiion window is changed to = gif-A-001.gif Note: Due to "offset change of previous version of local draft mail by Compact while editing draft", delete of wrong draft mail can occur upon draft save or mail send, if different draft mail is incidentaly placed at offset=NNN which is for offset of previous version of draft editing. This is known problem. Because image data is pointed by number=NNN(offset of mail data when local mail folder) and part=P.Q, used image data upon mail send or draft save may be changed, (a) if Compact happens on (a-1) local mail folder of replied mail while mail composition is running and before first draft save, (a-2) or local Drafts folder after first draft save at mail composition window, and (b) if different mail's offset is changed to NNN by Compact, and (c) if part=P.Q of the different mail at offset=NNN is a valid image part. Bug opener, do you enable auto-compact? mail.prompt_purge_threshhold = true/false mail.purge_threshhold_mb = MMM(in Mega bytes) If yes, do you enable "prompt before auto-compact"? mail.purge.ask = true/false Do you enable "dialog after draft save"? Copies&Folders setting of each Identity, [?] Show Confirmation dialog when messages are saved

Note-2: If Compact happens on local Drafts folder while draft editing, old version of draft mail at offset=NNN is not deleted, if data at offset=NNN in local Drafts folder is changed to mid of a draft mail or nothing exists at offset=NNN. This is known bug, and "delte of wrong draft" is an special/edge case of the bug when different draft mail is placed at offset=NNN.

Simpler [Steps to reproduce]. Checked with Tb 13.0.1 on Win-XP. (0) auto-save=Disaled, auto-compact=disabled. (1) Create two mails by "Send Later", move to a local mail folder(call FolderX). Offset=0 Subject: mail-001 multipart/related Content-Type: text/html, <img src="cid:part1.001.001@x.x.x"> Content-Type: image/gif; name="gif-001.gif" Content-ID: <part1.001.001@x.x.x> Content-Disposition: inline; filename="gif-001.gif" Offset=NNNN Subject: mail-002 multipart/related Content-Type: text/html, <img src="cid:part1.002.002@x.x.x"> Content-Type: image/gif; name="gif-002.gif" Content-ID: <part1.002.002@x.x.x> Content-Disposition: inline; filename="gif-002.gif" (2) Reply to mail-001, in HTML mode. Shown image file at composition window = gif-001.gif image location : > mailbox:///C:/wada/@@@/Mail0/FolderX?number=0&header=quotebody&part=1.2&filename=gif-001.gif (3) Shift+Delete mail-001 at FolderX, Compact FolderX. Mail data at Offset=0 is changed to mail-002. Subject: mail-002 multipart/related Content-Type: text/html, <img src="cid:part1.002.002@x.x.x"> Content-Type: image/gif; name="gif-002.gif" Content-ID: <part1.002.002@x.x.x> Content-Disposition: inline; filename="gif-002.gif" (4) At composition window of Reply to mail-001. Shown image at composition window = gif-001.gif (image embed in mail-001) (4-1) View image location. image location : > mailbox:///C:/wada/@@@/Mail0/FolderX?number=0&header=quotebody&part=1.2&filename=gif-001.gif Shown image at image location panel = gif-002.gif (image embed in mail-002) (4-2) Cancel at image location panel(no change). Shown image at composition window=still gif-001.gif(image embed in mail-001) (4-3) Send Later Image embed in reply mail(Subject: Re: mail-001) = gif-002.gif. Content-Type: image/gif Content-ID: <part1.NNNN1.NNNN2@x.x.x> (name= and filename= parameter seen by "Insert Image" at step (1) is removed) If following occurs, same as above can occur on edited draft mail. (i) mail-001 & mail-002 of above is draft-001(at offset=NNN1) & draft-002(at offset=NNN2) of local Drafts(NNN1 < NNN2), and draft-001 is edited. (image location=milbox:.../Drafts/number=NNN1,part=P.Q) (ii) Deleted draft mails exist before offset=NNN1. (iii) Compact occurs on the local Drafts folder. (iv) Offset of draft-002 is changed to NNN1 after Compact. (v) draft-002 has valid image part of same part number = P.Q. (if part=P.Q of draft-002 is not image, broken image happen?) (or "attaching error" occurs?) Confirming.

Thank you WADA for analysing & confirming this, great job. Especially now that the bird is out in the rough wild, it's comforting to know there's somebody out there who knows things inside-out. :)

FYI. When image location=milbox:.../number=NNN1,part=P.Q for image data of replied mail(or edited draft mail), if "data at offset=NNN1 after compact" is not valid mail data(mid of a mail) or nothing exists(file size is less than NNN1 after compact), draft save error occurs.

FYI. Bug 532395(never-ending Attaching ... message) was found for non-accessible image data case.

As I wrote in bug 532395 comment #42, this bug is a special case of phenomena of bug 532395 comment #42. Setting dependency for ease of tracking and analysis.

FYI. URL: field is test mails attached to bug 799450 comment #10. By STR of bug 799450 comment #10, you can see phenomenon of this bug(bug 766495) and bug 799450 at same time. - this bug(bug 766495) inline image data is replaced by inline image of other mail. so, wrong image is sent by Tb. - bug 799450 inline image data is replaced by text data of other mail with base64 encoded. inline image of sent mail is broken. if text data of other mail is confidential data, confidential data is exposed to unexpected recipients by Tb. even if non-confidential data, garbage is sent by Tb.

I have the same problem (Thunderbird 17.0.2 / Windows XP). I see that this issue takes at least a year. Is there a chance that it will ever be fixed? Who do I send a message to fix it? Expected results: The program has to send a message that as be seen. And not to change its contents.

I've had this issue many years back with TB until version 17. Now it seems to have resolved, after I DISABLED ALL Plugins and Extensions for TB. Hope this helps.

I had this issue for quite a while too until someone usefully suggested it's linked to automatic compacting. To solve that issue I just set my inbox to compact to something high like 100MB and then the problem seems to have stopped - just remember to manually compact now and again, perhaps over your morning coffee so that the inbox folder never reaches the maximum you set.

(In reply to Tristram from comment #27) Symptom of this bug 799450 occurs when all next conditions met; (i) Composing mail refers to embed image of existent mail. - Forward Inline of HTML mail which has embed image - Edit HTML draft which has embed image (ii) While mail composition, Compact is executed. (iii) By the Compact executed while mail composition, different mail is placed at same offset. (if not-just-same-offset, pointed mail is not found,) (so phenomenon of bug 817245 occurs. ) "Larger threshold value of auto-compact" will surely reduce frequency of (ii). "Disabling auto-compact and manual Compact only" will make possibility of (ii) ZERO. "Don't hold all mails in Inbox which is "mail drop", "letter box”, "mail tray"' is aother workaround of non-Draft case. If "frequency of delete of mails in a mail folder" is very low, probability of "all of above three conditions occurs at same time" is pretty low, even if auto-compact is used. (In reply to jerakeen from comment #25) (In reply to ykloh9228 from comment #26) Phenomnon of this bug is a special case of bug 817245 which is put in Depends on: field of this bug. - bug 817245 : pointed draft/mail is not found after Compact. - this bug and bug 799450 which is put in Blocks: field of his bug : pointed but different draft/mail exists after Compact. this bug : in the different mail, image is embeded. bug 799450 : in the different mail, non-image data is contained. possible phenomenon : in the different mail, no attachment is contained, so null data of image part is generated. And, cause of problem, required change etc. is already known in that bug. So, there is no need of "Me too" comments, additional complaints etc. in this bug. Read thru bug 817245, please. For solution etc., read bug 817245 and bugs pointed in that bug well, please.

The "sending the wrong image" flavor of this bug bit me this morning. In my case, the image in the sent email appeared "broken". When I did a view source, I found that the MIME part that was supposed to contain the image actually contained a complete email received in 2006 (7.5 years old). The new message that I was sending was generated from 'edit-message-as-new' from another email in the Sent folder. The email displayed correctly before I pressed the send button. If auto-compact is the root cause of this problem, then I will certainly make sure that I turn it off. However, given the security issues surrounding this, I think that auto-compact should be turned off by default. I am interested in whether Mozilla views this as a security issue....

(In reply to Philip Gladstone from comment #30) > I found that the MIME part that was supposed to contain the image actually contained > a complete email received in 2006 (7.5 years old). Your case is already kept as Bug 799450 independently. There is no need to disabele auto-compact for this bug. Required action for this bug is; to avoid Compact while you are composing mail. This is possible by; mail.purge.ask=true, restart Tb(mandatory), Reply "Cancel" at "confirmation dialog before start auto-compact", if you are composing mail, Never check "do this automatically" at confirmation dialog. (if you checked, "set mail.purge.ask=true, restart Tb" is needed again. This is also a known issue) Another possible workaround : Don't use image in signature. Even if you are eager to use image in signature, after you know this bug, you can do "stop using image in signature". and, if no image in signature, I believe frequency of this bug will be sufficiently reduced.

I had no image in my signature (in fact, this identity has no signature at all). It was not the primary identity of the account. I did have auto-compact on, but it certainly did not ask me during the 30 seconds of message composition. I checked, and I have plenty of folders (and MSF files) that were last updated a long time ago (no where close to the message composition time). I couldn't find any log of when the last compaction was run. Can it run silently without warning? I checked, and mail.purge.ask is status default, true. If auto-compact always prompts you about compaction when mail.purge.ask is set to default, then I can confidently say that this bug was *not* triggered by a compaction. In which case, then I should probably move to a different bug which should not be marked as a duplicate of this one.

After some more investigation, I believe that it picked up the other content from a different folder. My sequence of operations was: * Create message, send it to myself to check formatting (it was an announcement to be sent to hundreds of people) * The message had a single banner image at the top the email. * The received message looked good. * I went to the 'Sent' folder and found the message that I had just sent at the bottom (most recent). * Clicked 'edit message as new' * Added the final recipient list (as bcc) (somewhere between 500 and 1000 recipients) * Pressed send. The message that was sent had another message attached in place of the image. The saved message in the 'Sent' folder also had the corrupted image. I verified that the message from 2006 that was sent was *not* present in the 'Sent' folder, but was in a folder imaginatively named '2006'. It does not appear to be in the sent folder (e.g. as a forwarded message). I have followed this procedure in the past and have had it work as expected.....

(In reply to Philip Gladstone from comment #32) > I couldn't find any log of when the last compaction was run. Can it run silently without warning? If auto-compact=enabled, and if mail.purge.ask=false, auto-compact silently runs always. If auto-compact=enabled, and if mail.purge.ask=true is effective, and unless you check "do it automatically" at "confirmaton dialg", "confirmation dialog before start auto-compact" always shown before start auto-compact, and you can reply OK/NO, Go/Cancel etc. always. If you select "Compact Folders" menu, compact of all folders silently starts. "Compact was executed" is known only by "Compact done" message shown at status bar, which is easily overrided by other status message. So, it can be called "semi-silent semi-auto compact which was started from menu". Did you see "confirmation dialog before start auto-compact" in the past?

(In reply to Philip Gladstone from comment #33) > I believe that it picked up the other content from a different folder. Different from "Which Folder"? Different from "Drafts"? Different from "Sent"? Different from "other than Drafts/Sent"? As you say "Edit As New of a sent mail copy in Sent folder", "previous version in bug 817245, bug 799450, bug 766495(this bug)" is Sent folder in your case, isn't it? Or wrong data was obtaine from other folder than Sent/Drafts(if draft save happens, wrong data from mail in Drfats may occur)?

Original content isn't sent out -> dataloss Unintended content is sent out -> violating user's privacy (covertly & badly) -> critical Reduced testcase: see attachment 669907 [details] from Bug 799450, with STR from Bug 799450 Comment 10.

This affects amd64 linux too. (Ubuntu 14.10)

Hi. Thunderbird 31.6.0 on Mac OS X Yosemite (10.10.3) - POP 3 account. This happened again to me today and it happened a number of months ago also. I have been using a workaround to avoid the issue since the first incident, but forgot to do it today. Fortunately, the image that is being sent in error is not super confidential or embarrassing, however it was in an email announcing the death of a neighbour so not ideal timing. I put a text and image signature in the bottom of emails that I compose in Thunderbird using the POP3 email account. The issue arises when I go to the "Sent" folder of my account and copy the text and image from a previously sent email (an email I sent a few days ago). I paste that in to the body of the new email I'm sending and everything looks as it should. However, after sending it - the image is no longer the one I copied/pasted/viewed...! It's an image I included in an email to someone else a number of years ago! Recipients of the email, also see this old, unrelated image. When this same situation happened a number of months ago, the "old/incorrect" image was the exact same one so there must be some connection. To avoid the problem in the last few months, I've been inserting the image separately using the toolbar, and dialog boxes in the compose window instead of the "copy/paste" method described above. Thanks for reading, and let me know if you need additional information.

This should have been fixed by bug 854798 for TB 38. WADA, can we just close this bug because it must be fixed, or is it possible to test if this bug 766495 has really been fixed?

This bug still can occur by "messageKey change due to Rebuild-Index". So, essential problem of this bug is not resolved yet. However, it may be better to open separate bug for Rebuild-Index case in order to to avoid confusion.

(In reply to WADA from comment #41) > This bug still can occur by "messageKey change due to Rebuild-Index". So, > essential problem of this bug is not resolved yet. > However, it may be better to open separate bug for Rebuild-Index case in > order to to avoid confusion. Thanks. But Rebuild-Index will always require manual user intervention of "Repair Folder", right? So this bug can no longer occur automatically by itself, right?

(In reply to Thomas D. from comment #42) > But Rebuild-Index will always require manual user intervention of "Repair Folder", right? No, it's wrong. If "Outdated msf condition" is generated in local mail folder, Rebuild-Index is automatically invoked upon some events ; Folder open, Show Folder Properties, Virtual Folder(Unified folder, Search folder) open whose search target folder contains the mail folder, etc. Trigger is "manual operation", but it's not always "Repair Folder". So this bug can no longer occur automatically by itself, right? Even if "manual operation by user" is involved in "internal/automatic Rebuild-Index", "internal Rebuild-Index" is automatically invoked when "Outdated msf condition" exists. No one can perfectly aviod "Outdated msf condition", and no one can know "internal/automatic Rebuild-Index" is invoked or not by his "manual operation". Even if following is pretty rare, it's never "no longer occurs". 1. Edit a draft or forward a mail 2. while editing draft or forwarding a mail, "Outdated msf condition" is generated in Drafts or Inbox 3. Upon an "manual operation" on Drafts or Inbox, "internal/automatic Rebuild-Index" is invoked So, answer is "No, it's not right".

Hi, This bug 766495 could be related to bug 117332 which I related two days ago. With kind regards

Oops! I mean it is related with bug 1173332. I typed the number wrongly. With kind regards

I closed bug 817245 according to fix of bug 854798. See bug 817245 comment #36 please.

I have this problem with 38.2. Is there any workaround to avoid this bug, until the fix is released?

(In reply to Samuel Langlois from comment #47) > I have this problem with 38.2. Is there any workaround to avoid this bug, until the fix is released? Unable to reproduce problem by STR & test mails of Bug 799450 Comment #10 in Tb 38.2.0. i.e. this bug(Bug 766495), Bug 799450, are resolved in Tb 38.2.0. Is your problem actually same as this bug, Bug 799450, Bug 817245?

I don't know if it's exactly the same bug, but I will repeat what I described in another ticket (bug 1180201): I "Reply All" to a message with two inline images and compose my reply. At this point, everything is fine, the two inline images are correctly displayed in the bottom section. But after clicking Send, I go to my sent mail, and those two images got replaced with... other images, probably received from other customers in completely unrelated emails. The inline images I added myself have not been replaced though. Looking at the drafts saved for this email, the first saved draft is OK, but the second one has the wrong inline images. As I mentioned, I have thunderbird v38.2.

(In reply to Samuel Langlois from comment #49) > I don't know if it's exactly the same bug, but I will repeat what I > described in another ticket (bug 1180201): Please report detail of your problem in bug 1180201.

(In reply to WADA from comment #50) > (In reply to Samuel Langlois from comment #49) > > I don't know if it's exactly the same bug, but I will repeat what I > > described in another ticket (bug 1180201): > > Please report detail of your problem in bug 1180201. Do you mean it's a different bug? It seems very similar to the behavior described in this ticket... All the info I reported here is already reported in bug 1180201 also.

(In reply to Samuel Langlois from comment #51) > Do you mean it's a different bug? This bug is for phenomenon of concrete/solid STR & test mails of Bug 799450 Comment #10. I can say nothing about your problem because problem detail and data required for problem analysis is not provided by you.

(In reply to Samuel Langlois from comment #49) > As I mentioned, I have thunderbird v38.2. If same phenomenon occurs in Tb 38.2.0, it may be one of next. (a) Interfere by Repair Folder : In STR of Bug 799450 Comment #10 : after Compact, in Tb 38.2.0, mail at Offset=4000 is changed to messageKey=4000, messageOffset=0. At this step, this bug is resolved, because messageKey is not changed by Compact. Hoewever, if Repair Folder of relevnt folder is executed after Compact before Draft save at composer, phenomenon of this bug can occur, because referred maii is changed to messageKey=0, messageOffset=0, and other mail held at offset=4000 becomes mail of messageKey=4000, messageOffset=4000. (b) Interfere by Mail Copy to relevant folder : In STR of Bug 799450 Comment #10 : after Compact, in Tb 38.2.0, mail at Offset=4000 is changed to messageKey=4000, messageOffset=0. At this step, this bug is resolved, because messageKey is not chaged by Compact. Hoewever, if no other mail is held in in this folder, and if other mail is copied to folder after Compact before Draft save at composer, copied mail has messageKey=4000, messageOffset=4000. By this copied mail, referred mail of messageKey=4000, messageOffset=0 is hidden, and the copied mail of messageKey=4000, messageOffset=4000 is used upon next draft save at composer. If the copied mail of messageKey=4000, messageOffset=4000 has similar mail data structure, same phenomenon as this bug can happen. This is a dataloss issue in bug 1183490. To resolve (a), following is needed. (i) Repair Folder of BerkleyStore_LocalFolder assigns messageKey from 1, incrementing by 1, as done in MailDirStore To resolve (b), following is needed. In addition to (i), (ii) Mail Copy assigns messageKey = Highest key in msgDB + 1, as done in MailDirStore. as done in MailDirStore Even after these changes, if "Compact + Repair Folder" is executed after start of mail composition before next draft save, other mail can have same messageKey which originally referred mail had. This can not be avoided as far as "pointer by messageKey" is used to refer other mail in mail composition. This is a reason why solution of "copy mail data and referred data upon start of mail composition" is still needed.

If you see phenomenon of this bug in Tb 38 or newer, see and read bug 1201782, please.

This happened to me in version 45.4.0. I have never noticed this problem previously. It is very disconcerting since I am exchanging sensitive communication with a security firm!

Occurred in a big company here, with a lot of employers. 45.5.1 in Linux Mint Operating System. The e-mail images are changed not only in the signature but in all images, note that everybody runs mint, but I am running Debian with Icedove in 45.0.1, well Icedove does not differ from Thunderbird source code isn't, but only the compilation made by the debian maintaners (correct?) So i am thinking that maybe that is a compilation problem and not in thunderdbird source code. What do you suggest? Thank you very much for the help.

(and i am not experiencing this trouble in Icedove)

The same problem on linux version 45.7.0. Ubuntu. Randomly changes any pasted images.

Hello this started to happen to me quite a lot now I have 45.8.0 version. After I sent an email reply (email was new yesterday), image was changed. I am using windows 10, original version from Thundebird webpage - Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 So I do not think that this was fixed at all.

Use the current version of TB instead. It was fixed recently (in TB 52). https://bugzilla.mozilla.org/show_bug.cgi?id=1201782#c42 https://www.mozilla.org/en-US/thunderbird/52.0/releasenotes/