Least Privilege Mail Client, was Re: [E-Lang] defense in depth

[Bill Frantz]

At 02:50 PM 1/25/01 -0700, Marc Stiegler wrote:
>I talked about refactoring Web servers so that smaller components have fewer
>powers, and Web servers as an example seem pretty clean. But I don't
>currently see how to refactor the components in a mail manager while still
>presenting a smooth user interface.

Well, there is a bunch of stuff you still have to trust, but I think we can
break things up to gain some safety.  Here is one approach:

Mail reader: Uses POP/etc. to read mail and create a "Letter" object for
each piece.  (Can not read plaintext of encrypted mail.)

Letter object: Encapsulates text of mail.  Provides methods to access
headers.  Requires an unsealer to read text.

Filter: Reads headers to sort mail into mailboxes.  Passes Letter object a
"no hole" factory for filtering on mail text.  (Response from factory
object is true, goes into the associated mail box, or false, continue
filtering.)

Mailbox: A collection of Letter objects.  Lets you do usual UI things like
sorting, changing mailbox, and opening.

Mail Viewer: Has Letter unsealer, and is used to view the text of mail.
Used the Decrypter to decypher encrypted mail.

Decrypter: Gets passphrase from user and decrypts encrypted mail for the
Mail Viewer.

Encrypter: Gets public key of recipients and encrypts mail for the Composer.

Composer: Used to edit new mail.  Has Letter unsealer for quoting.  Uses
Encrypter and Signer when requested by user.

Signer: Reads passphrase from user.  (User knows when mail is being
signed.)  Only available to composer.

AddressBook: Can send to, cc, bcc etc. headers to Composer.

Is this approach a reasonable start?