Open Bug 1872360 Opened 5 months ago Updated 3 months ago

Deleted email metadata remains in msf files

Categories

(MailNews Core :: Database, defect)

Thunderbird 115
defect

Tracking

(Not tracked)

People

(Reporter: robrwo, Unassigned)

References

Details

(Keywords: dupeme, privacy)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:120.0) Gecko/20100101 Firefox/120.0

Steps to reproduce:

  1. Received an email to an IMAP account.
  2. Information about the Email shows up in INBOX.msf
  3. Deleted Email, so it is moved to Trash. It disappears from Inbox in Thunderbird and shows up in Deleted folder.
  4. Information about the Email shows up in Trash.msf
  5. Using alternative email software (e.g. web interface for email system), permanently delete the email. It disappears from Deleted folder in Thunderbird.
  6. Notice in Thunderbird that email

Actual results:

After step 3, metadata for the email still remains in INBOX.msf

After step 5, metadata also still remains in Trash.msf

Running Compact on the folder does not remove the metadata.

Note: I suspect the bug shows up in Step 3, and that steps 4-6 simply repeat that for the Trash folder.

Also note that deleting the Trash and Trash.msf files so that they are rebuilt via IMAP storage shows that the metadata for the deleted emails disappears. So this seems to be an issue with Thunderbird, not the IMAP metadata.

Expected results:

The metadata should have been removed entirely. Users would expect that metadata for permanently deleted messages are removed.

This may be important for users who live in authoritarian regimes who may incorrectly believe that messages were permanently deleted.

Group: mail-core-security

This is a hard problem. Even if Thunderbird were more thorougly deleting all information, you still wouldn't be completely safe. Using forensic software, traces of the files can still be recovered from your harddisk, from sectors that are simply "marked as deleted", but not yet overwritten.

If a user is worried about traces of files on their harddisk, they should avoid producing that information on their disk in the first place, for example, by using a operating system that doesn't need persistent storage. The user could e.g. use the Tails operating system, which can run entirely from memory, and only optionally record persistent information on an encrypted USB flash drive.

Even when using webmail with a browser, it might be possible that traces of your old emails are written to disk, as part of using "memory swap to disk", or as part of the browser cache.

If your threat model is, that at any time authorities could come to you and read your harddisk, and jail you simply for having read or written certain emails, you probably shouldn't even allow temporary data to arrive on your storage devices.

I think Thunderbird cannot easily provide the level of disk cleanup that you are you looking for.

You should either use harddisk encryption to avoid that anyone can read traces of old data on your disk. Or, if you could be forced to unlock your encrypted disk, avoid that information is recorded at all.

Having said the above, if someone finds time to do so, they could investigate what metadata exactly is still contained in the files, and if that the cleanup could be improved. (You didn't explain the details of what data you were able to see yet.)

But I'm afraid by doing so, you wouldn't get to your goal of having a clean disk.

That data is left in the "deleted" disk sectors etc is a separate issue. If one backed up the files or copied them to a new system, then it would have the unexpected metadata.

The metadata in the .msf file looks like below, replacing :

<(2FE10="From Name Here" <info@example.com>)(2FE11
    =my-email@example.net)(2FE12=Subject Line)
  (2FE13=some-message-id@example.com)

(In reply to Robert Rothenberg from comment #2)

That data is left in the "deleted" disk sectors etc is a separate issue. If one backed up the files or copied them to a new system, then it would have the unexpected metadata.

Agreed.

Keywords: privacy
Status: UNCONFIRMED → NEW
Ever confirmed: true

I'm not sure if we can make this a priority.

Geoff, Magnus, if we ever decided to work on a fix, who might understand the underlying data storage, and why this meta information isn't completely cleaned up?

Component: Untriaged → Database
Product: Thunderbird → MailNews Core

partial bug list https://mzl.la/3T0yYcz

Keywords: dupeme
See Also: → 402730
You need to log in before you can comment on or make changes to this bug.