The initial version of email has a lot of problems that can not be addressed by making minor modification to the way that email is trasnsmitted. A new architecture needs to be developed to begin to replace our current email infrastructure.
Problems
- No guarantee or acknowledgement of delivery.
- No accountability for who sent the message (spam)
- No guarantee on latency or delivery
- No general security (email is sent as plain text)
- No standard messages for bounced, inactive accounts or full accounts
Our current system:
Greg -> [email protected] <- net -> [email protected] <- Kathy
Today Greg sends a message addressed to [email protected]. Greg's mail server releases the message onto the internet. The message is sent back and forth between servers untill it reaches host2 or untill the servers give up. Greg has no way of knowing if the message was delivered. Kathy has no way of knowing if the message recieved is legitimate.
Proposed solution :
Greg types his message and sends it to Host1. The host creates just an envelope consisting of an encrypted key for the message, Greg's name and the address of Host1. This envelope is sent across the internet in a similar fashion to our current email system. If Host2 recieves the envelope it can connect back to Host1 and retrieve the message securly using the encrypted key provided in the envelope. If Host2 never recieves the envelope host1 can automatically resend the envelope.
Send just the envelope wrapper using Email 1.0
Greg -> [email protected] <- net -> [email protected] <- Kathy
Once Kathy's server recieves the envelope it connects securly back to Greg's host and downloads the body of the email.
[email protected] <- net <- Kathy
This is better then the current system for several reasons
- This makes it much harder to spam. Currently after a message is sent the sender can disapear on the internet. The new system requires that the mail server holds outgoing mail and waits for it to be retrieved. This provides a greater level of accountability. Additionally it means that each message is recieved from the correct host. Since the reciever connects to the sender computer to retrieve the message it is no longer possible to forge email addresses unless you have control of the sending host computer.
- Once a message is sent it can be canceled or corrected before it is retrieved. Everyone who has used email has hit send and wished they could fix, correct or cancel their message. This new architecture would make it possible. When you hit send you are now just sending an empty envelope the message is only retrieved when the server wants to download it.
- The new approach allows you to tell when a message has been successfully delivered. Since each envelope is unique and has a unique key you could easily tell when the message was retrieved. This doesn't prove that the message was 'read' but at least you know it didn't get lost along the way.
- Initially the system could be made to be backward compatible with current email networks. Initially the envelope could also contain the body of the message as well as the secure key. Email software that is aware of the key could download the message securly to help authenticate the sender. Email software that is not aware of the security key would just see the message. There would be incentive to upgrade your email client since it helps ensure that messages sent are delivered. Recieving less spam would also be an insentive to upgrade. In addition many of the clients could be updated transparently by simply updating the backend server and still delivering mail to the client applications using traditional pop3 and imapi. Another way to grow adoption and still have backward compatibility is to format the message in a way that brings users to a secure location:
You have recieved a secure message from: 'Greg' who is using Email2 for secure communication.
It seems your server does not support email 2. You can read this message by installing email2 software or by clicking this link: https://host1.com/key/23232082959372 - Email communication would be more secure. Although there is no perfect way to secure email commuunications the new system would be more secure then the curent system.
Having a framework for developing a new email technology would allow for other advanced that are desperatly needed.
- Standard subscribe / unsubscribe headers
- Standard bounce messages
- Standard threading and referenceing (rather then including messages in each mail)
I think a revision to the way Email is sent and recieved is long overdue. Even if this isn't the exact solution we really need to rethink the way that Email should work.