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