Re: [Exim] Wanted: encrypted mail storage

Top Page
Delete this message
Reply to this message
Author: Walt Reed
Date:  
To: Rich Johnson
CC: exim-users
Subject: Re: [Exim] Wanted: encrypted mail storage
On Thu, Aug 07, 2003 at 10:01:30AM -0400, Rich Johnson said:
>
> On Wednesday, August 6, 2003, at 06:55 PM, Walt Reed wrote:
>
> >I don't think anything is 100% secure: unless you are using TLS, it's
> >going to be unencrypted on the wire comming in. Since so few sites use
> >TLS, TLS encryption will be minimal.
> >
> >If you decide to do file level encryption, what is it that needs to be
> >hidden? Just the message body or all the headers too?
>
> Thank you all for your insights. I know I can't expect perfect
> security. But here's a scenario to illustrate my security concerns:


<big snip>

> So to _finally_ answer your question:
> - Message body encryption is the major goal.
> - Message header encryption is desirable, but not necessary.


OK... First a couple things. Unless you turn off most logging, the
sender and recipient will be listed in the log file. Logging has so many
other benefits that I would leave it on no matter what. Since it's on,
anyone with admin / backup access can read it. What they don't get is
any subject headers, etc.

Leaving the headers unencrypted is IMHO much easier. How I would
implement this, is by each user setting up a exim userfilter that pipes
the message through a script that pgp encrypts the body, saving the
output in the users spool file / maildir. This way, when the message is
read you will at least know the subject, sender, etc and decide whether
to read it or dump it or file it without having to decrypt it first.
Each user would be responsible for creating his own public / private
key.

You can maintain a list that can be used as a conditional in your filter
- only encrypting (or NOT encrypting) if the sender is in that list.

Leave decryption up to the client MUA - there are many that can handle
this automatically.

The users that care about the encryption will use it, those that don't,
won't.