mediocregopher/mediocre-blog
1
0
Fork 0
Code Pull Requests Releases Activity

fmail

Browse Source
This commit is contained in:
Brian Picciano 2021-04-01 18:46:15 -06:00
parent 7ab3b7ef36
commit f43f742fe0
1 changed files with 172 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

172
src/_posts/2021-04-01-fmail.md Normal file
View File

@ -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!