parent
7ab3b7ef36
commit
f43f742fe0
@ -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! |
Loading…
Reference in new issue