270386 - Deleted emails remain on hard disk

Status: VERIFIED DUPLICATE of bug 183837

(Thunderbird :: General, enhancement)

Description

[tloehnert]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:1.7.5) Gecko/20041108 Firefox/1.0
Build Identifier: Version 0.9 (20041103)

I recently stumbled across a Thunderbird feature which I would call a "3-tier
deletion process" for pop3-accounts: (a) If an email is deleted, it is per
default moved to the trash-folder of the respective account. (b) If the
trash-folder is emptied the mail becomes "invisible" in the folder structure,
but still resides in the respective inbox-file on the hard disk (including
attachements). (c) If the folders of the respective are being compressed, the
email is finally physically deleted.   

Reproducible: Always
Steps to Reproduce:
1. Delete email from inbox (pop3-account).
2. Empty trash-folder of the respective account.  


Actual Results:  
The email becomes "invisible" (via change of "X-Mozilla-Status") but remains
physically on the hard disk.

Expected Results:  
The user expectation in this case is clearly that the email is being
deleted/purged completely from his hard disk.

My arguments against the current policy are the following:

1. Security: possibly harmful code (virus, worm, trojan attachments) still
resides on hard disk

2. Privacy: private information still resides on harddisk; especially critical
on publicly accessible computers (Internet cafe) 

3. Breaks the user's WYSIWYG expectation

Bottom line: A 2-tier deletion strategy (Inbox -> Trash folder) should be
sufficient to fulfill data-loss prevention requirements. If the current behavior
is not to be changed, please explain it prominently in the thunderbird
documentation.

Comment 1

[Jo Hermans]

Reporter, that's why there's a 'compact folders' entry in the menubar, and (in
case of IMAP) a 'clean up (expunge) inbox' in the account settings. Diskspace
isn't reclaimed immediately for performance reasons. Most other mail clients
behave in the same way, actually.

bug 270386 ?

see also bug 237464 for the workaround (it's currently hidden in the offline
extension)

Comment 2

[tloehnert]

(In reply to comment #1)
> Reporter, that's why there's a 'compact folders' entry in the menubar, and (in
> case of IMAP) a 'clean up (expunge) inbox' in the account settings. Diskspace
> isn't reclaimed immediately for performance reasons. Most other mail clients
> behave in the same way, actually.

I'm aware of the 'compact folders' functionality. The question is, is the
*common user* aware of that? And isn't 'compact' in this case a misnomer?

> see also bug 237464 for the workaround (it's currently hidden in the offline
> extension)

Yes, the offline-extension is per default included in the latest thunderbird
releases I saw ... but it does not (IMO) address the problems I see with the
current behavior. 

What is your opinion to points (1) - (3) I listed? Regading point (1) (Security)
there is the additional issue, that the virus-scanner is still complaining after
one has presumably "deleted" a sinsiter email ... Thanks for looking into this.

Comment 3

[Mike Cowperthwaite]

(In reply to comment #2)
> I'm aware of the 'compact folders' functionality. The question is, is the
> *common user* aware of that?

The common user would certainly notice if compaction were performed after every 
local file deletion, because the performance of deleting a message would slow to 
a crawl.

There is bug 205756 which requests that the automatic file compaction on startup 
be enabled by default.  This would be OK, except that the automatic file 
compaction results in a slew of other problems: bug 152675 especially, but also 
bug 139215, bug 255167 and some other minor ones.

There are also several RFEs about improving automatic compaction, particularly 
bug 197605, bug 255687, bug 260252.

> And isn't 'compact' in this case a misnomer?

What-EVER.

> What is your opinion to points (1) - (3) I listed?

(1) That's a problem, but not a security problem -- the trojan is not going to 
be run.
(2) Anyone using TB to access POP mail on a public system should not leave the 
account in existence.
(3) For certain highly excitable users, I suppose that may be true, but for 
local folders, with an mbox format, there is no way around it: compaction is 
required, but automatic compaction is problematic.


This problem was noted as early as bug 59950; it would appear on the Most 
Duplicated list except every time it crops up, it gets marked Invalid rather 
than duped.  See the similarly tedious discussion at bug 225280.

*** This bug has been marked as a duplicate of 183837 ***