DISCLAIMER: This project is currently vaporware, but I’m sharing the concept so maybe other people can jump bandwagon and realize it. If you do so, send me a notification!”

I really like the concept of E-Mail, but I don’t like the implementation we use today. One day, I thought: What would be required to make a backward compatible modern E-Mail system.

Here, I’m presenting the results of this brainstorming.

Required features

• Send single or multiple files to a receiver
  • Files are identified by a name and a mime type
  • Compression is always used
• Send files to one or more users
• Use the email format user@host.name as account identification
  • host.name will allow querying the public key for a user on that host so we can encrypt messages to that user
    • With this method, the CA system ca be used as a trust anchor (as it is widely adopted)
• Use end-to-end encryption by default
  • Question: How to solve multiple clients? How are keys shared?
  • Question: How to do account recovery/backup? Standardised protocol
• Files can only be exchanged between identifyable servers
  • Question: How to prevent the typical spam? Signed mails by default?
  • Question: Is relaying necessary?
• Messages can be accessed via a directory service
  • Files in a message can be downloaded separately
  • Messages can be automatically sorted into folders and get tags assigned
• Message metadata
  • Sender identity
  • Send date
  • Receivers (To, CC)
  • Subject
  • “is read”, “is important”
  • user tags per message
• Users can do key migrations and do a forward key change
  • This is done by signing the new key with the old and storing the new key information on the server
    • Requires a special revocation certificate / revocation keys
  • This way, people can have a trusted way of fetching the new key without requiring any additional features
  • A key update would require the user to re-encode or delete all messages that are on the server (or keep the old key for read-only use)
• Messages without files/content are allowed and can be considered “notifications”

Missing solutions

• Proof of account
  • Prevent spam by proofing an account is actually known to the server
  • Require an account to be verified by a server through a captcha?

Project Components

• Server-To-Server protocol
  • Authenticate, open encrypted channel, transport messages
  • Query user existence and public key
    • Only metadata is user has public key string|null
    • Realistic/dynamic rate limiting on queries
• Server-To-Client protocol
  • Access and modify directories
  • Block individuals and servers
  • Send messages to a user
  • Query user public key
• Example client
  • Implement/showcase all features of the Server-To-Client protocol in an easy way
• Example server
  • Implement all features
• Example CLI tool to send a bunch of files
  • send-parcel user@host.name file_1 file_2 ...

Message encryption and packaging

• A message is composed of:
  • An unencrypted header that contains the receiver and the sender identity
  • A symmetric key encrypted with the public key of the receiver
  • A symmetrically encrypted set of metadata
    • Send date
    • “To”, “CC”
    • Subject
    • The file list
      • File name
      • Mime type
      • File encryption key
      • byte offset in the message
      • byte length
  • A set of individually encrypted files (to allow partial message downloading)

Potential Extensions

• Forward-compatibility with E-Mail:
  • Allow receiption of SMTP messages by using an SMTP server that converts and encrypts received E-Mail and forwards it to this service
  • A client can both implement this service and a regular E-Mail-Client. It queries the target server and sends a Parcel if supported, otherwise queries the client if they really want to send an unsafe E-Mail. Optionally support also PGP