diff options
Diffstat (limited to 'src/_posts')
| -rw-r--r-- | src/_posts/2021-04-01-fmail.md | 172 |
1 files changed, 172 insertions, 0 deletions
diff --git a/src/_posts/2021-04-01-fmail.md b/src/_posts/2021-04-01-fmail.md new file mode 100644 index 0000000..bdc473c --- /dev/null +++ b/src/_posts/2021-04-01-fmail.md @@ -0,0 +1,172 @@ +--- +title: >- + F-Mail +description: >- + 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. + +## Thought Exercise + +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. + +## Addresses + +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 + +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. + +## Encryption + +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 fmail + +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! |