Securely deleting emails from Apple Mail

Solution 1:

I take it the core of your question is how to securely delete an email which you received via an IMAP email account, and read using your local Mac OS X ''Mail'' application. You ask other interesting questions along the way, to which I'll give only brief answers.

First, it's important to understand the IMAP account, and how it affects deleting messages. The essence of the IMAP approach to email is that mail resides primarily on the mail server. The email client (the Mac OS Mail application in your case) temporarily downloads a copy of the message to your local Mac for you to read. If you were then to feed your Mac to a gigantic crushing machine, the local Mac and its copy of the message would be destroyed, but the original copy of the message remains intact on the IMAP server. When you tell Mail to delete the message, Mail tells the IMAP server to delete its copy of the message, and Mail deletes its own copy of the message. Thus, you might want to concern yourself with how securely the IMAP server deletes its copy.

Second, concerning strictly the way Mail deletes its messages, we can tell that the local copy of the message exists as a file on the local Mac. Telling Mail to delete the message makes it disappear from the Mail window, but might not delete the local file containing the local copy. The Mail command "Erase deleted items..." does reliably delete the local file with the local copy.

You ask, "If I delete an email and empty trash in the client then is the deletion done securely, using srm or in a non-secure way?" I don't have access to the Mail source code, so I don't know how securely it deletes the file. We have to assume that it deletes files using the most fast, easy, and insecure method available from Mac OS.

So, the most secure way I know of to delete the email message from the client is:

• In Mail, delete the message
• In Mail, erase deleted items. Control-click on the mailbox which had contained the message. A pop-up menu appears. Select "Erase deleted items...". A confirmation dialog appears. You are about to delete files related to not just the message you just deleted, but other deleted messages also. Click "OK".
• Using Disk Utility, erase free space with either 7 passes or 35 passes. This too will erase more than just the local copy message you deleted.

If you care this much about security, you should also think hard about how your IMAP server deletes messages, and how vulnerable you are to an attacker seeing a copy of the message on your IMAP server's disk. You should also think about whether you should be sending such messages unencrypted, where an attacker monitoring the data flowing through the public Internet could read it.

You ask, "Is there a way to pinpoint the exact file location of an email in the client?" Yes, but it's not fast and not programmatic. You already figured out that the messages are stored in

~/Library/Mail/V2/[email protected]@imap.mykolab.com/INBOX.mbox/...

My impression from looking at my own file system and thinking logically is that the local copy of your email message will be one of the files matching:

~/Library/Mail/V2/[email protected]@imap.mykolab.com/INBOX.mbox/*/Data/*/*/Messages/*.emlx

(This pattern is not the only one Mail appears to use; messages stored "on my Mac", and attachments, will have different patterns describing the file path names.

Each email message appears to be stored as a plain text file with a name like number.emlx, e.g. 55219.emlx. One way to find the appropriate file is find a distinctive phrase in the message, and to use grep from the command line to find a file containing this phrase. Thus, [linebreaks added for readability]

% grep -l 'Repair Cafe January 18' ~/Library/Mail/V2/[email protected]@imap.mykolab.com
    /INBOX.mbox/*/Data/*/*/Messages/*.emlx
/Users/myuser/Library/Mail/V2/[email protected]@imap.mykolab.com
    /INBOX.mbox/393BA6E1-145B-E29D-536F-306645CA9917/Data/3/5/Messages/53938.emlx

However, don't assume that you can safely delete these files out from under the Mail application. It might get confused by the unexpected absence of the file. It might simply recreate the file from the copy on the IMAP server.