Home

Advanced Mail System: A More Modern Approach to Electronic Mail

Author: Raymond Rodgers

Purpose

Electronic mail has been around for more or less 46 years in its current form with little change in the fundamental data formats or protocols. While there have been attempts at supplanting it with systems that offered more features, most were proprietary and were supplanted themselves by systems based on legacy systems with more features that were more readily available. What this document (an early work in progress) and sample implementation hopes to accomplish is getting a discussion going to finally drop the old and move on to something more modern, more secure, and, most importantly, with little to no spam.

As to this last point, I hope to describe and implement a reference specification and suite that applies accountability. Not just at the account level, but at the server level as well, which should force mail server administrators and companies that intend to offer e-mail to deal proactively with those that spam. The how of this will be explained at a later time.

Encryption

One of the most important "features" in recent history is encryption, frequently "end to end" encryption is touted as the highest pinnacle of trust in the post-Snowden world. The problem with encryption is that it interferes with other things that are sometimes beneficial. In email, encryption prevents antivirus and antispam software from working, it also forces some difficult decisions for business: allow individual employees to encrypt their emails or not? How can you tell if an email is personal or business if it's encrypted? Do we use a corporate encryption system with a shared key or just forbid encryption altogether?

These are questions that even AMS cannot completely solve. As a compromise, however, encryption will be configurable at the domain level. The options will be as follows:

• Corporate Groups: The domain will have multiple sets of public and private keys that are shared with all members of individual groups; this allows private communications within the groups and to external individuals.
• Corporate-wide: A single key for all members of the domain/company.
• ISP: Every email address has its own private key.

The risks of sharing keys is that they would need to be shared somewhere. While the public keys will be shared on an unencrypted peer to peer network in this system, private keys would need to be stored in a secured location that makes it possible for authorized individuals to access and utilize them appropriately. My initial plans for this demonstration implementation was to include the "corporate" private keys on the mail server, and only make them accessible to the appropriate email address; after all, this intended to be a reference implementation, not a fully secured implementation. Instead, what I will do is work to develop an API for retrieving the keys as necessary from an undefined external location.

Private keys for the "ISP" level should only be stored in the email client, and should never be transmitted to the mail server, even in the event of a change in key policy to one of the corporate types. This prevents circumvention of privacy, including the temporary changing of policy to acquire the key(s). Should the policy shift to corporate, the private key(s) at the mail client should remain available for continued use, though new keys cannot be created for the domain at the client level, only the corporate level and shared per policy.

Currently, all encryption is being implemented using OpenSSL; the public and private keys are currently 2048 bit RSA keys, though as the design and implementation of the reference implementation and specification evolves, these aspects may change.

Protocol SMTP, POP3, and IMAP are all quite well understood protocols, though, in some cases, they're quite long in the tooth. AMs will be using JSON objects to contain and transmit email messages for easy encoding and decoding, processing, and handling; for these reasons and several others that I shall describe later, AMS will be developing its own unified protocol to be used for both server-client and server-server communications, requiring encrypted communications from the initial connection.

The peer to peer public key directory can be optionally implemented as part of the server software, or run separately. It could even be implemented in the mail client if a developer so chooses. More details on the public key directory system will be revealed later, however the basics are as follows:

• Every key will be assigned a UUID key identifier that is uploaded to the directory with the public key.
• Although personal/business identification (name, email address, company name, key description) will be supported within the public key, it is completely optional, and may be altered at any time. The email address in this field is purely textual, and should not be relied upon as the email address actually associated with the key.
• Upon publication of the public key to the directory, the important key details are signed with the private key and verified by the receiving server; if the verification fails, the key will not be accepted into the directory. Similarly, when a public key is downloaded to a client, the public key must pass verification or not be accepted.
• The association between a public key and email address is kept on the destination email server, secured by encryption. If the client updates their key for a particular address, the new key identification replaces the old on the mail server, and the new key is published while leaving the old public key in place for historical purposes.

Much more to come and to change.