If email didn't suck.
I'm down a blog post, so I'm going to try to make up some time on this one.
Email is probably the oldest web technology which is widely recognized by the general public. It predates WWW by about 15 years, and is fundamental to the way we use the internet.
It also really fucking sucks.
Let's invent email all over again, for fun. We can take the good things from the existing email paradigm, and replace the bad. Let's not worry about marketshare and adoption strategies and all that annoying stuff either; after all, I need to finish this post in like.... 20 minutes... tops.
This new email will be called fmail.
The basic idea of email is solid. It's mail, on the internet. We all understand mail. You have a mailing address, I want to send you a thing. I pay someone else to take my thing to you, and they have some mechanism for finding you just based on your address.
We're good so far. Let's get into the weeds.
Email addresses are... ok. There's a name and a domain. If you were sending a physical package to a house with multiple residents you would include the name of the recipient on the package, in addition to the address. With email the domain part of the email corresponds to the house address, and the username corresponds to the recipient's actual name.
In this aspect, however, physical mail has email beat. If the package has a correct name it can often be routed directly to its intended recipient. But it doesn't *have* to have a correct name. In fact it can have no name. In those cases the residents of the address figure out amongst themselves what to do with it. Maybe it's obvious who it's for, maybe not. In any case it's possible to resolve these issues.
Further, in physical mail the routing steps are declared right on the mail container (box, envelope, etc). You can, generally, read the recipient address from bottom to top to understand how to deliver it. Here's an example:
Homer 123 Fakie St Springfield, IL 12345 USA
Understanding the steps is simple enough. The package first needs to get to the United States of America, then to Springfield, then to Fakie St, then to house 123 on Fakie St, and finally to the resident named "Homer" at that house.
Let's incorporate these ideas into fmail, our new mythical internet mail system.
In fmail the address isn't an inflexible `name@domain`. Instead the address is composed of a sequence of `>` separated strings, each denoting an intended hop in the route. For example:
sick-domain.com>brian>phone
The sender only needs to know how to route to the first hop in order to do its duty. In this case it's a simple domain lookup, which would tell it an IP to send the fmail message to. From there the receiving server would need to know what to do with `brian` as a piece of routing information. Maybe it knows, and can send the message along. Maybe it doesn't, in which case the mail might go to a "lost and found" directory, where anyone on the fmail server could claim it.
If the idea of a domain-wide "lost and found" sounds scary, consider that it might not be so scary in a world where fmail servers are easy to self-host, and so people actually do so. What would make it possible for fmail to be easy to self-host?
Spam has made both email and real mail almost unbearable. If I'm honest, it's the daily chore of cleaning my two mail boxes that made start thinking about writing this post in the first place. With email the spam issue is particularly egregious, because the entire email ecosystem, not just the experience of the individual, is made worse by spam.
If you want to know why it's hard to run your email server, the answer is "because spam exists". You need to block the spam destined for you server, you need to ensure someone isn't going to hack your server and send spam from it, you need to convince other email servers that you're one of the good ones and won't send spam, you need to pray your ISP even allows you to have an email server (because they don't want to be seen as enabling spam). There's actual *laws* about email spam.
The good news is, fmail has solved the spam problem completely.
In fmail, all messages are rejected by default. It's a whitelist based access control, unlike email's blacklist based one where anyone can send you anything and it's up to you to reject what you don't want.
How can this work? There's a couple different forms the whitelist can take, and they all can work together in your fmail server's configuration.
The primary one would be to check for some kind of cryptographic signature on the message, declaring who its from. If the message is from a list of configured "good senders" then it's kept. This would be for friends, family, coworkers, etc... Those you expect to hear from frequently who you actually want to hear from.
Building on this, each "good sender" could have a timeout associated with them, if desired. This could be useful when signing up for a website which wants to use fmail for authentication. You configure your fmail client (which of course integrates nicely with a web browser to make this easy) to allow messages from this sender only for a limited time, or only a limited number of messages from them. This way the user can receive their fmail confirmation message, or password reset or whatever, without being forever bothered by stupid marketing emails.
A secondary method of whitelisting might involve someone attaching some cryptocurrency to their message as a peace offering of sorts. It could be as simple as a private key or signed transaction which would allow the receiver, if they receive the message, to keep the money. It would be up to the fmail client to allow configuration of which cryptos are accepted and how much crypto is required, as well as ensuring that the money is still available to be received. Only if all these requirements are met is the message allowed to be seen by a human, otherwise it's dropped.
There's probably other interesting mechanisms I haven't thought of. It would be good for fmail servers to have a plugin system that allowed for extending functionality like this as the users desire.
One thing email sorely lacks is end-to-end encryption. This is a difficult problem for communication systems in general, because ultimately what it comes down to is a hard requirement on a safe exchange of public keys, which requires an existing trusted method of communication.
I don't think fmail needs to re-invent this wheel. We've already established that users will have some mechanism for sharing public keys (for whitelisting), so really what this comes down to is having good UI around key management from the start, and the stubbornness to establish e2e messages as the norm.
What holds email back in this area isn't so much the lack of solutions (there are many ways to do e2e encryption over email) but the need for supporting plaintext emails out of concern for backwards compatibility, as well as the need to support open mail boxes which can receive and send mail willy-nilly. If a whitelist-based system is built from scratch with e2e messages always being the default way of messaging others, and plaintext messages being something with big scary warnings around it, I don't think there'd be an issue.
That's it. There's not much to it, except you know... actually implementing it (someone else do it, I don't have time).
There's a lot more that could be said about the email protocol and server/client implementations themselves, but I think if one were to start from scratch on fmail it would be enough to say this: there's a lot of good things to take from email, and really what we need is to update the mindset around internet messaging in general.We have almost 8 billion people on earth, a double digit percentage of them have internet access, and we need to give users better mechanisms for ensuring their messages are received the way each one individually wants them to be.
My dream of finishing this post in 20 minutes did not come to pass. It was more like an hour. I'm getting faster though!
-----
Published 2021-04-01