Tell me more x
, there is a new speed test available. Give it a try, leave feedback!
dslreports logo
    All Forums Hot Topics Gallery


Search Topic:
share rss forum feed


Brainstorm: PGP encrypted ~/Maildir

Preface: Read entirely or assumptions will be made.

This is not the same thread that pops up time and time again on mailing lists about an encrypted ~/Maildir. I *trust* the server. Those threads are about not trusting the server. In this case client-side only encryption makes sense coupled with disk encryption. This is not that thread.

Allow me to craft the following scenario:

1) Dovecot/Postfix IMAPs/POP3s only, Dovecot SASL.
2) Apache SSL WebMail access
3) Mail-enabled limited user-account PAM authenticated to Dovecot/Postfix
4) Only console-access is SSH via RSA keypair with strong password on private key or direct physical access.
5) Strict clearly defined AppArmor rules on each daemon
6) Defense-in-depth security (chroot, AppArmor, ingress/egress firewall, auditing, etc)

Desires: Secure ~/Maildir while allowing disparate clients (Webmail, mobile devices, laptop) access.


1) Single-factor authentication for Dovecot/Postfix leading to mailbox (!SERVER) access.
a) Sensitive data stored in ~/Maildir
b) Password reset vulnerability -- if attacker owns the mailbox online sites/banking/etc passwords can be arbitrarily reset.
c) SSL MiTM allows messages/passwords to be read in cleartext. See the wonderful Dutch CA fiasco and Iran playing SSL MiTM with GMail.

2) Two-factor key-based authentication to SSH deems direct console access to ~/Maildir as reasonably secure.
a) Far more secure than single auth username/password combination.
b) Two-factor


1) Use Procmail with GPG to encrypt incoming messages with a private 4096 bit RSA key generated on the server, constrained to the limited user mail account, for the pubkey used by the client user account. The private key is separate/different from the user's private key.
a) Addresses two-factor concerns, Dovecot access to ~/Maildir does not grant access to real mail content, it is encrypted.
b) Addresses SSL MiTM concerns, private key of client or server required to decrypt messages.
c) Server being owned results in messages being read via decryption.
d) SSH private key for limited user + private key password results in likely decryption of ~/Maildir, see item c.

2) Convulated PAM/ecryptfs setup
a) Does not address MiTM situation
b) Does not address single-factor authentication.
c) Server being owned results in messages being read via decryption.

3) Come up with some multi-client two-factor out of band authentication scheme.
a) Does not address MiTM situation
b) Either pricey or convoluted.
c) Server being owned results in messages being read via decryption.

Thoughts? In this particular use-case it seems that GPG is the way to go.

Well that was an epic failure. Here, if anyone stumbles along on this, this is how far I got.

sand groper
Geneva, IL
·AT&T U-Verse
reply to CryptyBits
I am unclear on what you are trying to achieve.

On a quick read, it looks as if you are adding a lot of complexity with no obvious corresponding benefits.
AT&T Uverse; Zyxel NBG334W router (behind the 2wire gateway); openSuSE 11.4; firefox 5.0

reply to EpicFail
» looks promising from » ··· ng_Email

The author seems to have the same goals as I.

I hate Vogons
Burlington, ON

1 recommendation

How about encrypted filesystem or home directory?
TrueCrypt or native Linux filesystem encryption?'s much simpler to setup, transparent and does not need any special maintenence.

Thank you Brano for your reply but I'm not sure how to make this work with the scenario painted above. Can you elaborate? Specifically making it work with IMAPS access to Dovecot from remote clients.

I'm not worried about encrypting ~/Maildir on the server, I trust the server, I am working towards mitigating the issues associated with single-factor authentication and the concerns in #1.

Internet Janitor
reply to CryptyBits
EDIT, we posted the same link. For what it's worth, the githib project works well.

To all those that replied, thank you. I made no code changes to other than to rename it to (makes sense in my head).

Here is the procmail recipe I am using.

Caveats are you must import the pubkey on the server for the recipient, set it as trust, and locally sign it. Then the Perl is so happy. Sadly the iPhone is not very happy, the PGP client iPGMail won't handle PGP/MIME at the moment so HTML or messages with attachments are readable. Oh well ;)

Everything is working very well, so I cobbled together some BASH code in a alcohol induced stupor to encrypt the older messages since the procmail code above only affects new ingress messages. Figured I'd document the solution here so folks in the future can find it.

Better have a backup of your Maildir before you play with this

Working well. Had to flush the cache on the local IMAP clients including the wonderful iPhone (yay for SSH) and Thunderbird.

Here you go, probably could even improve the code and cron it for encrypting Sent-Items/Sent.

Here is a final summary of this thread.

As each user, you should generate a RSA certificate pair, on the server.

Select an RSA keypair, tune to your fit, and generate the certificate. Import the public key of the intended recipient, which has likely been generated on a separate computer. Import this into your GPG keyring.

Now you must set this pubkey as trusted and locally sign it.

The procmail recipe I am using for users to be PGP/GPG encrypted:

Here is the script I am using to PGP/GPG encrypt the contents of existing Maildir, it has been cleaned up. Before playing with this script or the contents of your ~/Maildir ensure you have good backups. What works for me may be catastrophic to your ~/Maildir. You are responsible for the contents of your ~/Maildir.

To encrypt User1's maildir, you would use '/usr/local/bin/ /home/user1/Maildir user1'

I am using, as-is, renamed to, and stored at /usr/local/bin/ is located at

To handle Sent and Sent-Items, which are not processed by procmail, and therefor not encrypted, I use a Cron script to call to handle Sent-Items and Sent.

I have documented this here in it's entirety for the benefit of future users who wish to do the same. This entire process is working quite well and I am fully happy with the results.

Enigmail for Thunderbird handles decryption, including attachments, multipart advanced E-mails, etc without issue.

I am also using SecuMail for the iPhone to PGP decrypt these messages and it is working great with the same functionality similar to Enigmail. One caveat is that the PGP/MIME inline body appears as 'mime-attachment' as is not viewable by the Mail Application. I have notified the developers of SecuMail and as a work-around I am using AttachmentSaver and opening 'mime-attachment' in iFile, copying the contents to clipboard, and decrypting using SecuMail. AttachmentSaver and iFile are available from Cydia for Jailbroken iPhones. SecuMail is available from the Apple App Store.

I have not tried Android PGP clients yet.

To those that have participated in this thread thank you. I hope this thread will assist someone in the future with the same goals as I.

It seems that the handling of multipart or PGP/MIME is not compatible with all PGP clients. The below patch resolves this issue and allows these clients to work as expected. I also believe this format to be closer to what traditional OpenPGP and PGP clients produce.

Here is an updated version of /usr/local/bin/ I don't plan to feature creep, just wanted to finalize a working solution.

I know this thread is mostly me replying to myself but I wanted to fully document for others down the road. Thanks for humoring me. ;)

For some reason the tab character in previous posts shows up as the HTML entity for tab. Ampersand, hash, 9, semi-colon is tab (\x09 or \t) in the above code snippets.