In my experience, one of the worst problems with email is that people trust it.  If anything looks remotely plausible to them, they'll click on it: URLs, attachments, whatever!  In fact, the issue of plausibility never really occurs to them.  I want to train my end users not to trust unsigned emails, but this has to be done in a way that is non-invasive to their day-to-day work.

What i would like to see is integrated, end-user-transparent S/MIME and OpenPGP support for Novell GroupWise and Hula.  The goal: to create a product that trains users to look for valid signatures as a matter of course and expect valid signatures when they receive messages from colleagues and other trusted sources.

Some of the features that such a product would include would be:

• Automatic generation (either on the fly, or administrator-initiated), storage, and management of user keys and certificates.  In the case of GroupWise, which has a highly-integrated client, this could be managed by the server, but actually implemented in the client.  In the case of Hula, which doesn't have ties to any particular client, it would need to be implemented in the web interface or the NMAP server.
• Automatic retrieval of public keys from Internet key servers, maintaining a local system-wide cache, and automatically checking revocation lists for known certificates.
• Plain interpretations of message signing/encryption states, and recommendations about what to do with them.
• Friendly, easy-to-understand icons representing signed, encrypted, and unsigned messages, with an appropriate interpretation displayed in text format.
• Storage of private keys on the server to enable decryption for compliance reasons, if corporate policy requires it.
• Automatic detection of remote systems which support the same standards so that opportunistic encryption can be utilised.

I know that there are security holes in such a design, but at the very least it would encourage people to view email for what it is - a relatively unreliable communication mechanism.

GroupWise already has some of the infrastructure to support a system like this, but at present its S/MIME support relies on Windows' cryptographic infrastructure, which means that it's not available in the web-based client or the cross-platform client, and it requires user intervention to enable it.

There seem to be gateway-based products in the marketplace that can do things similar to what i'm suggesting (e.g. Tumbleweed's MailGate Secure Messenger and Totemo's TrustMail Secure Email Gateway), but gateway solutions don't fix the client, and i'm convinced that the client is where the changes are required: users need to be involved in the problem of making email more secure, and that means making clients display security information better (this problem would apply to non-web-based use of Hula as well as any other system without a highly-integrated client).