Least Privilege Mail Client, was Re: [E-Lang] defense in depth
Fri, 26 Jan 2001 17:24:00 -0800
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
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
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?