first, set up a secure-mail domain email server that upon mail receipt, applied (subscriber specified key) encryption, to the message contents and then forward that encrypted message along to whatever web mail service that subscriber wants to, or is already, use (and is supported) – – such as gmail, y-mail, hotmail. key point being, be the first leg in the journey & to secure the contents of the message before sending onto the public email service.
second, develop a browser plug-in that utilizes “screen-scraping” and decrypts secure-mail messages using the user’s private key (PGP perhaps). the plug-in could display the decrypted message contents on the fly without sending any data back to the storing server.
so, the encryption happens on receipt at the secure-mail server, which then gets forwarded to where ever. this means the only potential privacy trail is to/from secure-mail in server logs, which could be purged. the secure-mail forwarding service would not store any message contents on disk, encrypted or otherwise. the only persistent data would be # messages sent by subscriber account.
one obvious caveat is that subscribers would have to use a new email address. an inconvenience at worst.
since secure-mail controls outgoing, it could easily bill on how many encrypted messages users send per day/month/year etc.
as for sending & storing sent secure-mail, a client app such as thunderbird could be used so long as it was setup to send to the secure-mail outgoing server. then the responsibility rests with the subscriber to delete/archive as they see fit.
another enticing possibility is to further develop the secure-mail plug-in to utilize the webmail compose interface by providing a new (temporary overlay) input field that the only the secure-mail plug-in would read/write to. upon hitting “send”, the plug-in would encrypt that input and copy the new encrypted text into the webmail’s input form. the reason for the new input field is primarily to prevent web mail auto-save features, which could be implemented into the plug-in as well.
these advanced features make the browser plug-in is potentially very powerful and complicated. but certainly, it would take much less time to develop and deploy to new secure-mail users than creating new “gmail” from scratch. this approach adds advanced privacy functionality while allowing people to stay in their comfort zone.
a well-to-do & knowledgeable three person start-up with about six to 12 months could likely produce deliverable product. assuming market intrigue sales of secure-mail would be inevitable and sustainable.
this idea stemmed from an email inquiry from my buddy Abram,
“with this latest ruling: An-Inbox-Is-Not-a-Glove-Compartment
what do you think about a web-based email site that offers encrypted mail where the user is in possession of the key? That way, subpoenas on the online content would be fruitless since it’s the user himself that would have the means to decrypt it. What do you know about public-key encrypton, like PGP for email?”