Closed Bug 799450 Opened 12 years ago Closed 9 years ago

Thunderbird adds the text of an email in the Drafts folder to an email I send (Confidential data in other/irrelevant draft mail is silently exposed to unexpected recipients by Tb as data of image part)

Categories

(MailNews Core :: Composition, defect)

defect
Not set
critical

Tracking

(Not tracked)

VERIFIED FIXED
Thunderbird 39.0

People

(Reporter: john, Unassigned)

References

(Blocks 2 open bugs)

Details

(Keywords: dataloss, privacy, testcase, Whiteboard: [bug 832519 has been fixed])

User Story

See comment #10 for Steps to reproduce and test mails.

Because bug 832519 has been fixed, and because messageKey is not altered by Compact after the bug fix, this bug(and member of family) won't be produced by Compact only any more.
This bug can occur only when messageKey is changed or relevant messageKey is re-used after Compact, by intentional or accidental Repair Folder and/or by intentional or accidental Copy/Move/Move Back of relevant or non-relevant mail at relevant BerkleyStore_LocalMessageFolder.

Attachments

(3 files)

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20100101 Firefox/15.0.1
Build ID: 20120905151427

Steps to reproduce:

1  Compose an email and save it as a draft
2  Edit the saved email, and send it


Actual results:

1  Thunderbird has added the text of a completely different email saved in the Drafts folder to the composed email.  The yahoo.co.uk web mail user recipient sees the composed email, and the "added text" below it.  Gmail users and Thunderbird users do NOT see the added text unless they view the message source, when they see it.
2  My copy of the sent email does not display the "added text" so I do not know this has occurred.  
3  I can see the "added text" if I View > Message source the sent email  

Other points.
1  I sent it to a yahoo.co.uk web email user who saw the "added text"

2  I copied it to a gmail.com user who uses Thunderbird.  He cannot see the "added text" on the email stored on the gmail mail server.  He cannot see the "added text" when he downloads the email into Thunderbird.  But he can see the "added text" by View > Message source in Thunderbird, showing it is there, but Thunderbird is not displaying it.



Expected results:

1  Thunderbird should not have added the email from the Drafts folder to my composed email
2  I cannot see the "added text" in the Sent copy of my email.  Thunderbird should display the "added text" in my sent copy - it is there because I can see it with View > Message source 
3  I had the problem some months ago and posted this problem report http://forums.mozillazine.org/viewtopic.php?f=39&t=2513657  I deleted and recreated my Drafts folder in an unsucessful attempt to fix the problem.
4  I do not know how many of my emails are having emails from the Drafts folder attached to them as only some recipients (yahoo.co.uk) see the added text, whereas other users (gmail.com, and Thunderbird users) do not see the added text.

I believe this is a VERY severe security exposure.  Thunderbird users are probably sending what could be confidential text without their knowing it, and without a visible record of having done so.
I think it is probably an intermittent fault and does not happen with all composed email saved in the Drafts folder before sending.
I have AutoSave set to 2 minutes
A variant of bug 766495?

(1) Original draft mail at offset=nnn (call mail-A) :
      multipart/related
         part1.1 : text/html,  img src="cid:abc"
         part1.2 : image/xxx,  Content-Id: <abc>
(2) Edit draft mail-A at offset=nnn
      => image url : mailbox:.../Drafts%3Ennn?part=1.2&filename=...
(3) Compact happens on Drafts folder. 
    New draft mail at offset=nnn (Call mail-B) :
      multipart/(any)
         part1.1 : (any)
                          bug 766495            This bug
         part1.2 :        image/xxx             text/html
(4) Send/Send Later/Save as draft => Data in part1.2 of mail-B is used
    Generate mail data :
      multipart/related
         part1.1 : text/html,  img src="cid:pqr"
                          bug 766495            This bug
         part1.2 :        image/xxx             text/html
                          Content-Id: <pqr>     Content-Id: <pqr>
                          Data from mail-B      Data from mail-B
(5) bug 766495 : image of mail-B is used, and is shown because of image data.
    This bug   : image is broken, because of non-image data(html).
                 because of "text/html in multipart/related",
                 "html from mail-B" is not shown unless message source is viewed.
                 (recent Tb perhaps shows it as attachment)

Note: Bug 766495 is a special case of issues written in bug 532395 comment #42.
(In reply to John_Ha from comment #0)
> Created attachment 669475 [details]
> Fwd Strange problem with central heating - links for valves.eml

Message source in your case.
(1) Content-Type: multipart/related;
(2) cid: url for embed image in message body(text/html, part1.1)
>      <img src="cid:part7.03080308.06010300@MyISP"
(3) Second text/hrml part(part.1.2).
> --------------080608080802020705000705
> Content-Type: text/html; charset=ISO-8859-1
> Content-Transfer-Encoding: 7bit
> Content-ID: <part7.03080308.06010300@MyISP>
(In reply to John_Ha from comment #1)
> I have AutoSave set to 2 minutes

Question about other conditions.
(Q1) local Drafts folder? (POP3/Local Folders) Or IMAP Drafts folder?
(Q2) Do you enable auto-compact?
    (mail.prompt_purge_threshhold=true, mail.purge_threshhold_mb=Positive_number)
(Q3) If yes, do you request Tb to do auto-compact without confirmation?
    (mail.purge.ask=true is not set)
Depends on: 766495
WADA
Thanks
(In reply to WADA from comment #4)
> Question about other conditions.
> (Q1) local Drafts folder? (POP3/Local Folders) Or IMAP Drafts folder?
I am using POP3 for all my accounts
> (Q2) Do you enable auto-compact?
Yes I do use AutoCompact
>     (mail.prompt_purge_threshhold=true,
Advanced config editor shows mail.prompt_purge_threshhold=true
> mail.purge_threshhold_mb=Positive_number)
Advanced config editor shows mail.purge_threshhold_mb=200 
> (Q3) If yes, do you request Tb to do auto-compact without confirmation?
>     (mail.purge.ask=true is not set)
Advanced config editor shows mail.purge.ask=true
Advanced config editor shows all the mail.purge variables are:
mail.purge.ask                  default   boolean true
mail.purge.min_delay            default   integer 480
mail.purge.timer_interval       default   integer 5
mail.purge_threshold            user set  integer 60000
mail.purge_threshold_mb         userset   integer 200
mail.purge_threshold_migrated   user set  boolean true
I read bug 766495 mentioned above.  Other facts which may be relevant:
1  On several occasions, I have seen many (6 or 8) copies of an email I am editing in the drafts folder, all saved at 2 minute intervals.
2  I often add images to my emails by copy image to clipboard > Crtl/v to paste it in-line (ie not adding it as an attachment).  When I forward such an email, TB often does not put the image in the forwarded email, or puts in a placeholder.  I often need to re-insert the image.
3  TB often has a long delay (10+ seconds) when I press Send (I think saying searching for attachment).  I think this is usually because TB cannot find a pasted image in the email.  The email may be a forwarded one with a pasted image in the original; but I also think it happens with a draft email containing a pasted image.  I have discovered a workaround which is 
i) cancel the send
ii) save the email as a draft
iii) open the saved draft
iv) send the email.
It now sends OK.
I will be pleased to do any tests you ask for, and also to make the original eml file or drafts and drafts.msf folders available to you (I could email them to you - I did not want to post them on the web).
(In reply to John_Ha from comment #5)
> mail.prompt_purge_threshhold = true
> mail.purge.ask               = true
> mail.purge_threshold_mb      = 200

If so, "confirmation dialog before invoking auto-compact" should be shown when Tb atempts to invoke auto-compact.
When you experienced your problem, was "confirmation dialog before invoking auto-compact" shown by Tb? If yes, did you reply "OK" to the dialog? Or did you reply "Cancel" to the dialog? 

If Compact(any of auto-compact and manual-compact) occurred on local Drafts folder when you experienced your problem, you probably saw phenomena stated in bug 532395 comment #42(bug 766495 and comment #0 of this bug is a special case of the phenomena).
Any of them is consistently reproduced with very simple test mail and by simple test procedure. I'll attach test mails to this bug.

If Compact is never related to your problem, it may be phenomenon like bug 532395 comment #47, because you enable auto-save(interval=2 min).
Mechanism of "image or text of different draft mail is used" in this case can not be same as bug 532395 comment #42, because offset of referred draft mail won't be changed if Compact never occurs.
Severity: normal → major
Summary: Thunderbird adds the text of an email in the Drafts folder to an email I send → Thunderbird adds the text of an email in the Drafts folder to an email I send (Confidential data in other/irrelevant draft mail is silently sent by Tb to different recipients)
(In reply to WADA from comment #7)
> If so, "confirmation dialog before invoking auto-compact" should be shown
> when Tb atempts to invoke auto-compact.
> When you experienced your problem, was "confirmation dialog before invoking
> auto-compact" shown by Tb? If yes, did you reply "OK" to the dialog? Or did
> you reply "Cancel" to the dialog? 
I am almost certain that on every occasion I am asked to compact, I accept. I have also manually requested compacting after archiving many emails.
> If Compact(any of auto-compact and manual-compact) occurred on local Drafts
> folder when you experienced your problem, you probably saw phenomena stated
> in bug 532395 comment #42(bug 766495 and comment #0 of this bug is a special
> case of the phenomena).
> Any of them is consistently reproduced with very simple test mail and by
> simple test procedure. I'll attach test mails to this bug.
Thank you.  I shall run the test and report my result. 
> If Compact is never related to your problem, it may be phenomenon like bug
> 532395 comment #47, because you enable auto-save(interval=2 min).
I am happy to cancel AutoSave (or set to a large value) if it prevents adding text from another email to the composed email.  
> Mechanism of "image or text of different draft mail is used" in this case
> can not be same as bug 532395 comment #42, because offset of referred draft
> mail won't be changed if Compact never occurs.

Other comments:
1  After I recreated the Drafts folder following the original problem several months ago, I discovered r-click Drafts > Properties > Repair folder and I clicked Repair folder.  
2  I have removed all confidential emails from my Drafts folder so that if I see the problem again, I can post the Drafts.msf and drafts files from the profile.  Is there a procedure you would like me to follow to set up my Drafts folder in a "proper state" so we know what state it was in on 10 October? 
3  I do a daily incremental backup so I normally have 45 days of backups, many of which will have Drafts.msf and Drafts.  Unfortunately, I went on holiday and removed my backup disk to a secure location while I was away, and I had not replaced it before the problem email, so I only have backups from 3 August to 17 September.  I have reconnected it so I will have 45 days of historical changes if it occurs again.
(In reply to WADA from comment #7)
> Any of them is consistently reproduced with very simple test mail and by
> simple test procedure. I'll attach test mails to this bug.
I cannot see the test email or test procedure files in the Attachments box above.  Please let me know how to get them and I will run the test.
Attached file Test mails
4 mails :
  mail-00-A : 4000 bytes text/plain mail
  mail-01   : 4000 bytes multipart/related
                part1.1 : text/html, img src="cid:png-A", img src="cid:png-B"
                part1.2 : image/png, Content-ID: <png-A> (green)
                part1.3 : image/png, Content-ID: <png-B> (magenta)
  mail-02   : 4000 bytes multipart/mixed
                part1.1 : text/plain
                part1.2 : image/png (red)
                part1.3 : text/plain, filename="attached...TXT"
  mail-00-B : 4000 bytes text/plain mail

[Steps to reproduce]
(1) Save the attached file as "Drafts" file of POP3 account or Local Folders,
    Restart Tb, "Repair Folder" of Drafts folder, Show "Order Received" column.
(2) Edit draft mail-01 (Offser=4000)
(3) Delete mail-00-A, Compact
    => mail-02 is shifted to Offset=4000
(4) At composition window, Save as draft, Close composition window
(5) Both bug 766495 and comment #0 of this bug can be observed.
    Content-Id: <png-A> : chaned from green of mail-01 to read of mail-02
    Content-Id: <png-B> : image is broken.
                          content is "attached...TXT" data with base64 encoded.
(In reply to John_Ha from comment #8)
> I am almost certain that on every occasion I am asked to compact, I accept.
> I have also manually requested compacting after archiving many emails.

Compact apparently occurs in your environment, and problem of comment #0 is consistently reproduced by simple test.
Confirming.
Status: UNCONFIRMED → NEW
Component: General → Composition
Ever confirmed: true
Product: Thunderbird → MailNews Core
(In reply to WADA from comment #10)
Wada
Thank you.  I repeated the test several times getting different results each time.  I think this was because I did the test very slowly documenting each step, and one or more AutoSaves happened before I finished, and thye result depended on when the AutoSave occurred.  I had made no change to AutoSave (still set to 2 minutes) but it might have been sensible to switch it off for the test.  I then did the test quickly and I do not think an AutoSave happened during the test.  I got the results below.  
> [Steps to reproduce]
> (1) Save the attached file as "Drafts" file of POP3 account or Local Folders,
I closed TB, removed my Drafts files, and saved the downloaded file as ...\LocalFolders\Drafts
>     Restart Tb, "Repair Folder" of Drafts folder, Show "Order Received"
> column.
Restart TB and R-click Drafts > Properties > Repair folder
Select Show Order received column - it has 
  - mail-00-A     0
  - mail-01    4000
  - mail-02    8000
  - mail-00-B 12000
> (2) Edit draft mail-01 (Offser=4000)
Highlight mail-01 and choose Edit.  Add some text to it.  Do not save it, do not close edit window, do not do anything to the two images.
> (3) Delete mail-00-A, Compact
>     => mail-02 is shifted to Offset=4000
Return to Drafts window.  
  - r-click > Delete mail-00-A (top email)
  - r-click Drafts > Compact
   - mail-01    0000
   - mail-02    4000  >> as expected
   - mail-00-B  8000
> (4) At composition window, Save as draft, Close composition window
At the email being edited, I went File > Save as > Draft and then closed the window. 
> (5) Both bug 766495 and comment #0 of this bug can be observed.
>     Content-Id: <png-A> : changed from green of mail-01 to read of mail-02
>     Content-Id: <png-B> : image is broken.
I have the following:
  - mail-01        0   >> green and magenta image, does not have my added text
  - mail-00-B   8000   >> multiple lines of text
  - mail-01    12000   >> bolded, new datestamp, has my added text followed by red image where it is labelled green.  The image under the magenta label is not there and there is a placeholder. This email is a "copy" of the first email.  I have lost mail-02
I just renamed the Drafts file to Drafts_after_test_in_Comment_12 and did not add a qualifier.
Summary: Thunderbird adds the text of an email in the Drafts folder to an email I send (Confidential data in other/irrelevant draft mail is silently sent by Tb to different recipients) → Thunderbird adds the text of an email in the Drafts folder to an email I send (Confidential data in other/irrelevant draft mail is silently exposed to unexpected recipients by Tb)
Whiteboard: [See comment #10 for Steps to reproduce]
Blocks: tb-drafts
No longer depends on: 532395
No longer blocks: 754203
Tried procedure given by WADA with attachment 669907 [details] (comment #10) and got the same results as John_Ha described in comment #12.
(Windows 7 x86_64, Thunderbird 17.0.6)
Still present in Thunderbird v24.0.1 (Fulle UA "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1")

Some drafts are attached in outgoing e-mail:
----------8<----------
--------------060506060808080701020204
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: base64
Content-ID: <part3.03000000.03010606@domain.tld>

0aXTw0bWjxDQo8+PGhaGVh4NCRsw65EZZDyBicnublgYm5cYWl0V2MlsZX4uxludGbWVgR2V
....
ZDyBw0bWjx0aXTDQ+EcnublgGhaGVh4NCRo8YmPZisw655cYWl0V==
--------------060506060808080701020204--
>From - Mon Jul 08 18:45:47 2013
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
X-Mozilla-Keys:                                                                                 
FCC: mailbox://nobody@Local%20Folders/Sent
X-Identity-Key: id1
X-Account-Key: account8
BCC: jdoe@domain.tld
Message-ID: <51DAECBB.9030307@domain.tld>
Date: Mon, 08 Jul 2013 18:45:47 +0200
From: =?ISO-8859-1?Q?Marie_OLIVE_-_CyberCit=E9?= <jdoe@domain.tld>
X-Mozilla-Draft-Info: internal/draft; vcard=0; receipt=0; DSN=0; uuencode=0
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Jane Smith <jsmith@domain.tld>
Subject: Re: somestuff
References: <064501ce73d0$6d28b820$477a2860$@domain.tld>
In-Reply-To: <064501ce73d0$6d28b820$477a2860$@domain.tld>
Content-Type: multipart/related;
 boundary="------------050603080104000201040301"

This is a multi-part message in MIME format.
--------------050603080104000201040301
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
...
----------8<----------
Original content isn't sent out -> dataloss.
Unintended content is sent out -> violating user's privacy (covertly & badly)

-> critical
Severity: major → critical
Keywords: dataloss, privacy
OS: Windows 7 → All
Hardware: x86_64 → All
Keywords: testcase
Depends on: 854798
See Also: → 766495
I can't claim to understand inner cause(s) of this issue nor I can imagine a fix for it but how come this bug (or the related) are still "assigned to nobody" / "OK to take it and work on it" after all this time.

I get that (all?) Thunderbird developers are coding on a voluntary basis but this terrible privacy issue is doing great damages to Thunderbird's reputation I and cannot imagine anyone here wanting this for our beloved e-mail client.
Many users don't realise that they are doing this as the user has no knowledge or record of it's happening.  It was only when a colleague told me he had received something he thought I should not have sent that I found out about it.
I hope that now it has been lifted to Critical, someone will have a look at it.  I will be pleased to test any fix.
See Also: → 1128892
No longer depends on: 1144020
Summary: Thunderbird adds the text of an email in the Drafts folder to an email I send (Confidential data in other/irrelevant draft mail is silently exposed to unexpected recipients by Tb) → Thunderbird adds the text of an email in the Drafts folder to an email I send (Confidential data in other/irrelevant draft mail is silently exposed to unexpected recipients by Tb as data of image part)
User Story: (updated)
Whiteboard: [See comment #10 for Steps to reproduce] → [bug 832519 has been fixed]
I closed bug 817245 according to fix of bug 854798. See bug 817245 comment #36 please.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 39.0
@WADA

Thank you for fixing this bug!
Unable to reproduce problem by STR & test mails of Bug 799450 Comment #10 in Tb 38.2.0.
i.e. Bug 766495, this bug(Bug 799450), (and Bug 817245 too, are resolved in Tb 38.2.0.
Status: RESOLVED → VERIFIED
User Story: (updated)
No longer blocks: 1201782
If you see phenomenon of this bug in Tb 38 or newer, see and read bug 1201782, please.
No longer depends on: 1202105
No longer blocks: 1128892
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: