
Re-Thinking Electronic Mail - smitty1e
https://ideas.liw.fi/rethinking-email.html
======
kazinator
Obligatory:

[https://craphound.com/spamsolutions.txt](https://craphound.com/spamsolutions.txt)

> _Every email user has one or more identities, represented by cryptographic
> keys._

Administered by whom?

> _No email is delivered unless it carries a digital stamp issued by the
> recipient_

The central premise of e-mail is that you can contact anyone if you know their
e-mail address, without any pre-arranged permission.

If a recipient has to issue something to me before I can contact them by
e-mail, that is too broken to be usable.

An intelligently designed micropayment system doesn't require anything from
the recipient. Simply knowing someone's endpoint address, you an create a
payment without their knowledge or consent, and attach it to the message.

> _In this approach, each email user can have as many email identities as they
> want [ ... ] This means misrepresenting the sender becomes much harder,
> reducing the possibility for scam._

I.e. people can create arbitrary cryptographic identities, as many as they
want (spammers can create millions of of these identities), yet somehow
misrepresentation is not possible. Right.

If you get a cryptographic message from Joe Blow offering you fake R0lex
watches, you know that must be the real Joe Blow, because, like, it is
cryptographic! Someone running a key generator would never lie about who they
are.

~~~
tomjen3
I remember how often it was posted on /. back in the day, and how it
effectively shut down any discussion about fixing the real issues with email
in any kind of open source fashion. The problem was eventually solved, but it
was solved by Google and Yahoo and Microsoft in monopolizing email, because
they were focused on the user and us nerds were focused on shutting down
(im)-perfect open source solutions instead of working to improve them.

The document is not obligatory, it is one of the most destructive ever
published on the subject; it represents the worst of nerd-dom and should not
be used.

~~~
kazinator
There is no debate-silencing coercion involved in posting a link to a humor
piece.

The debate stops spontaneously, because the participants are too stumped to
respond to the ways that the form managed to anticipate serious flaws in their
ideas.

If you can't defend your ideas in the face of some piece of net humor written
years earlier, what good are those ideas?

That piece is in fact the encoding of a requirements specification; it shuts
down the debate because it intrudes into it with some real world requirements
that e-mail has to satisfy, and continue to satisfy while it transitions to
something new. (Some of it is plain wacky, too, but not all).

A lot of programmers are very good at pretending requirements don't exist;
they think that design means inventing your own requirements and making
everyone else follow them. But a world-wide electronic mail communication
system isn't an editor, video game or toy compiler.

------
upofadown
You can do almost all of this within existing standards. The PGP identity
token (AKA public key fingerprint) would be used as the primary email
identifier. The embedded email address would then just be considered a
technical routing detail. If you physically meet someone and want to "know"
them in an email sense you just scan the QR code of their identity token
(there is a standard for this too). When you decide not to know them anymore
you just remove their identity. Knowing someone who knows you is a
standardized process and technically is just an attachment of a PGP identity
(public key). Knowing someone from their internet presence is also a
standardized process.

This would be reasonably intuitive just as long as we were willing to give
things sane names (e.g. Identity vs public key) and mail clients show clear
statuses. We get encryption and identity reputation for free and can use it
against spam as desired.

Those that do not know PGP are doomed to reinvent it...

~~~
pcr910303
Please don’t use PGP.

Quoting ‘The PGP Problem’[0]:

> PGP begs users to keep a practically-forever root key tied to their
> identity. It does this by making keys annoying to generate and exchange, by
> encouraging “key signing parties”, and by creating a “web of trust” where
> keys depend on other keys.

> Long term keys are almost never what you want. If you keep using a key, it
> eventually gets exposed. You want the blast radius of a compromise to be as
> small as possible, and, just as importantly, you don’t want users to
> hesitate even for a moment at the thought of rolling a new key if there’s
> any concern at all about the safety of their current key.

> The PGP cheering section will immediately reply “that’s why you keep keys on
> a Yubikey”. To a decent first approximation, nobody in the whole world uses
> the expensive Yubikeys that do this, and you can’t imagine a future in which
> that changes (we can barely get U2F rolled out, and those keys are
> disposable). We can’t accept bad cryptosystems just to make Unix nerds feel
> better about their toys.

[0]: [https://latacora.micro.blog/2019/07/16/the-pgp-
problem.html](https://latacora.micro.blog/2019/07/16/the-pgp-problem.html)

~~~
upofadown
>... by encouraging “key signing parties”, and by creating a “web of trust”
where keys depend on other keys.

Welcome to the 90s. Does anyone actually ever do this sort of thing? Now you
just aim your phone at a QR code on another phones screen. Times have
changed...

> Long term keys are almost never what you want.

Long term keys represent long term identities. So, yes, you do want that. PGP
has subkeys that you can revoke whenever you want thus preserving your
identity. I can't think of of any other system that supports this in such a
straightforward way. Your phone gets owned and you basically lose everything.
If you keep your master PGP key on a more secure device you are still in
business...

~~~
m-p-3
Exactly, the best practices with PGP is to generate a main key for long term
use and kept in cold storage, and generate subkeys that will be used on
specific devices and revoked whenever necessary.

The idea of a root of trust can be applied here as well.

------
andrey_utkin
The gist of one of the most important problem: zero cost of mass unsolicited
mail.

> Spam is a result of the desirable feature that anyone can email anyone,
> combined with the fact that sending an email costs approximately nothing,
> even if you send millions of emails, and aggravated by the fact that
> spamming has de facto no real financial or legal repercussions.

Good that we can discuss this.

> 2.2 Overview of solution

Has some ideas in the right direciton of __imposing the cost __on the sender,
as well as some ideas which have nothing to do with it.

The author jumps straight into implementing things, giving little attention to
formulating how we want the cost function to look like.

> 2.6 Digital stamps

Good for some use cases, but not for others.

Imagine your relative wants to write you another email about how they are
doing, or that but you haven't read their previous one, or forgot to issue
them the new token. So they may as well create a new identity in order to
email to you again?

> Alternatively, the email server could require the person sending the email
> to solve a CAPTCHA-like puzzle.

Blind and otherwise impaired people would get out of jobs at cusotmer
contacts.

> Email servers could also sell stamps for real money.

As the measure of the last resort, the author turns to the ultimate medium of
value exchange.

If the sender communicates to you, they expect to derive _some_ (not
necessarily immediately monetary) value from it, otherwise why are they
motivated for it?

If the sender communicates to you so that _you benefit_ , then you should have
either paid them in advance, or they should reasonably expect you to pay them
back.

I think it's time we recognize the economic side in everything we do, and stop
shying away from "commercialization" of aspects of our life, i think.
Otherwise we won't get out of the nonsense like "free software provides so
much value, but nobody wants to pay for it" \- valuable things are meant to be
valued, that is, exchanged for other valuable things.

~~~
smitty1e
> zero cost of mass unsolicited mail

We use "free" as in zero (immediate) cost, and also use the same word to mean
liberty.

In source code, I would expect that kind of conflation to be a source of
subtle and vexing bugs for the application.

Can someone smarter than me produce a TED talk that introduces an improvement
on this F-word?

~~~
jauco
There’s libre (freedom) and gratis (zero costs)

~~~
smitty1e
Excellent

------
jka
Since the article relates to email and mentions digital stamps, it seems worth
mentioning Microsoft's Penny Black[1] anti-spam research project which had/has
some similar goals.

In general the idea (from both the linked article and the research project) is
to make it computationally expensive to send messages, in a way that is cheap
for the recipient to verify. That reduces both the desire and the capability
for scammers to widely distribute their messages.

[1] -
[https://en.wikipedia.org/wiki/Penny_Black_(research_project)](https://en.wikipedia.org/wiki/Penny_Black_\(research_project\))

------
gandalfian
I worry big companies like the failure of free email. They want you to stick
in their giant corporate silo. Gmail to Gmail works. WhatsApp works. The death
of the smaller participant by sheer impracticality suits them. Isp's are
giving up on even providing SMTP servers. I'm beginning to think I will have
to stop using my private domain name and just use a Gmail address. Then they
will have won, locked me in and probably start charging me...

~~~
ken
Indeed. The elephant in the room that this post missed is that email was
created by researchers, not corporations. Today, a huge swath of computer
science progress is created by corporations. We're making great strides in
areas which can easily be monetized.

Email really isn't one of those. Worse, there are a lot of _almost_ -email
areas which are (Slack, Facetime, etc), which makes it nearly impossible for
non-commercial entities to produce a viable alternative. You're fighting
network effects _and_ deep pockets.

There are a lot of areas of computing that we take for granted today which
were only created because they didn't need a corporation to find a way to be
profitable. When big companies get together and try to produce the OS of the
future, we get Multics and Taligent and OS/360\. When individuals scavenge old
cheap hardware to play around with for their own personal use, we get Unix and
Linux and the Apple II.

------
jussij
I don't understand why we don't have a system whereby all e-mail clients
automatically attach a $0.001 stamp to each and every email they send
(obviously a sign in feature).

Then the e-mail readers receiving e-mails could easily filter all e-mails
based on the absence/presence of that stamp.

At that cost 1000 emails would cost about $1.00 which would be a years worth
of e-mails for a typical user.

For a million a day e-mail spammer that cost would quickly run them out of
business.

~~~
tyingq
There are, of course, legitimate reasons to send lots of email. You run these
people out of business too.

~~~
syrrim
As long as you earn more than a tenth of a cent for every email you send,
you'll be fine. I don't think it's unfair to classify anything else as spam.

~~~
boomlinde
It's not spam if it earns you money? That seems like an arbitrary distinction.

------
jlgaddis
> _2.2 Overview of solution_

> _Every email user has one or more identities, represented by cryptographic
> keys._

> _All email is digitally signed using the cryptographic keys._

> _No email is delivered unless it carries a digital stamp issued by the
> recipient, or someone authorised to issue one on behalf of the recipient._

Ahhh, yes... yet another Final Ultimate Solution to the Spam Problem (FUSSP)
[0]:

> _The FUSSP depends on spammers or mail recipients changing their behavior
> without any immediate gain._

> _The FUSSP requires that anyone wanting to send mail obtain a certificate
> that will be checked by all SMTP servers._

> _The FUSSP involves certificates, but there is no barrier to spammers buying
> many independent certificates._

> _The FUSSP assumes that your attention is so important that strangers will
> pay money to send you mail._

\---

[0]: [https://www.rhyolite.com/anti-spam/you-might-
be.html](https://www.rhyolite.com/anti-spam/you-might-be.html)

------
jedberg
The obvious solution to spam/scams are micropayments.

When you send an email, you attach a micropayment (say 1 cent's worth). When
the recipient opens the email, you get your 1 cent back.

This would make mass spam unfeasible while still allowing companies with legit
bulk email needs keep sending email, since they would get most of their money
back.

It would even create an industry for people to be the payment middleman where
they front you the cash for your bulk emailing and then assume the risk and
keep the difference as profit.

~~~
lazypenguin
Except payment is already required for traditional mail, yet I still receive
an endless stream of spam and scams.

~~~
jedberg
Do you? I get unsolicited postal mail, but it's at least well targeted and
often relevant to me. Sure I toss the credit card offers, but if I were in the
market for a credit card, the ones that I'm getting offered are probably the
ones I'd consider.

------
0DHm2CxO7Lb3
I think one of the problems with email is that you have one global email tied
to one inbox. Fastmail has the option to create multiple emails tied to one
inbox so you could potentially have a unique email per sender, then if you
start to receive spam it's easy to know who leaked it and disable the affected
address

~~~
vesinisa
This feature is supported by GMail as well FWIW. If your email is
john@gmail.com all john+X@gmail.com addresses are aliases for your primary
inbox. So you can have john+ebay@gmail.com, john+that_scammy_site@gmail.com
and so on to easily track down spam.

~~~
RedShift1
What prevents spammers from recognizing the + pattern and omit it?

~~~
voicedYoda
Most of the time they don't care. They've got 4 million email addresses,
they'll just spam all of them.

------
amelius
> each email user can have as many email identities as they want, and each
> identity is represented by a key pair for public key cryptography

I'd suggest to use a different term for "identity", because this gets
confusing. Perhaps use "appearance" or "presence".

~~~
hanche
I like “persona”.

------
bvrmn
All hard details, i.e how to implement UX for end user are not there. PGP and
friends was a complete failure for casual user.

~~~
Aeolun
Because those wouldn’t significantly differ from existing email?

I hardly think the gmail interface is the problem. All the things in the
article can be completely transparent I think?

------
zzo38computer
Some of the problems can be solved as:

\- Spam: What I do is use different email addresses for each correspondent and
service. I can then edit my /etc/aliases file to get rid of addresses which
are receiving spam. And as mentioned, some other services also support aliases
too, so if you have aliases, then you can do the same kind of things too,
perhaps.

\- HTML email: Just avoid HTML email; plain text is much better. I use email
software that doesn't even support HTML email (it will display the plain text
part if it is a multipart message, but if not, then the HTML code will be
displayed without attempting to render it).

\- No real privacy, even if you self-host: Well, there is encryption if
needed, if you know the recipient's key. However, of course some things will
need to be unencrypted in order to transfer the message, such as the
recipient's mailbox (although with SMTP over TLS, you can encrypt the username
too, even though the target server will still be known).

\- Attachments fill disks: You could use compression. You can also delete
messages you no longer need. You can also program the server to reject
messages longer than a certain length.

\- There is no good support for group discussions: Use NNTP instead. NNTP is a
superior alternative to mailing lists and web forums.

------
crispyporkbites
So technically this is DKIM, except pushing the verification down from the
domain level to the individual user level. And instead of publishing the
public key in the DNS record, you manually give individual senders one/many
time keys to send emails to you.

Wouldn't it be easier to just set up a whitelist for emails in your inbox,
that only allows senders you specify through?

~~~
Aachen
I'm not sure about your conclusion since that would violate the number one
feature of email, but yes, the author's proposals do seem very unwieldy and
ignore existing solutions.

------
gandalfian
It can't be that hard for an email client, on setup, to invisibly authenticate
that you can recieve email from the address you are using to send from. Then
it could organise all the key stuff for you automatically. Though admittedly
getting the world to do it may be impossible. Nobody wants to invest in a
dying technology. Sigh.

------
pjc50
See the canonical checklist:
[https://craphound.com/spamsolutions.txt](https://craphound.com/spamsolutions.txt)

(This is _very old_ copypasta, maybe 20 or so years. As is the failed idea of
email stamps.)

------
naasking
The problem with email is summed up in Zooko's triangle:

[https://en.m.wikipedia.org/wiki/Zooko%27s_triangle](https://en.m.wikipedia.org/wiki/Zooko%27s_triangle)

Zooko's triangle can be satisfied by a petname system:

[https://en.m.wikipedia.org/wiki/Petname](https://en.m.wikipedia.org/wiki/Petname)

This provides the security, decentralisation and human readable names needed
for something like email. You just need the right system for managing the
crypto for the secure global names, and a good user-focused process for secure
introduction, key revocation/upgrade, etc.

------
upofadown
The idea of doing email in terms of identities is a good one. That is because
doing any communication in terms of identities is a good one. That simplifies,
email, IM, video/voice and, yes, even video conferences.

What we need is a standard identity token that works with everything.
Everything could still do their own identity stuff natively but could be
automatically verified using the standard identity token.

I have recently spent some time looking at how PGP does this sort of thing in
the form of key fingerprints and how the public key stuff works. There is a
lot of wisdom in there that could be used as an example for a universal
identity scheme...

------
dsr_
Perhaps more implementable: IM2000.

[https://en.wikipedia.org/wiki/Internet_Mail_2000](https://en.wikipedia.org/wiki/Internet_Mail_2000)

TL;DR: Each sender has or subscribes to a reliable mail server. The mail
server does not deliver mail to recipients; it sends a tiny notification
(restricted set of headers + UUID) to each recipient's reliable mail server.
The recipient requests (or doesn't) the whole piece of mail via HTTPS or
similar. The basic anti-spam tactic is to reject a whole server because it has
sent you spam in the past.

~~~
Aachen
How is that different from spamhaus and similar services that tell you which
servers allegedly sent spam in the past? Except that it sounds like every
person has to reinvent the wheel by blocking servers themselves instead of
using an existing list.

Note that I don't use nor am a fan of systems like spamhaus, it just sounds
very similar.

~~~
JdeBP
It is structurally very different, because it attacks the problem by
attempting to eliminate the concept of bulk mail.

* [http://jdebp.uk./Proposals/IM2000/anti-ubm.html](http://jdebp.uk./Proposals/IM2000/anti-ubm.html)

You are using a pull-style electronic communication system _right now_.

* [https://news.ycombinator.com/item?id=10405864](https://news.ycombinator.com/item?id=10405864)

------
tomcooks
Not a silver bullet, but a default filter for addresses you haven't
whitelisted would solve the problem in my opinion.

Works fine with Instagram, where you get a notification that someone wants to
write you a message.

------
ethn
As far as I know, this is a solved problem.

[http://www.wisdom.weizmann.ac.il/~naor/PAPERS/pvp_abs.html](http://www.wisdom.weizmann.ac.il/~naor/PAPERS/pvp_abs.html)

An implementation of this is Hashcash which was used on UseNet very
successfully:
[https://en.wikipedia.org/wiki/Hashcash](https://en.wikipedia.org/wiki/Hashcash)

------
Endlessly
Following would kill 99.999% of spam:

\- All mailing addresses are linked to a persona and are impossible to guess.

\- Personas pay per address issued.

\- Senders pay per message sent with a per volume of data fee too.

~~~
stiray
Let me propose another solution, much simpler, the one that internet was made
for but looks like no one cares about. Host your own mail server. Each and
every site I register to gots its own mail address. Not only that I know when
address was sold, site was hacked,.. I also know which site. The only thing
that is left is vi /etc/mail/aliases and one '#'. No spam at all.

(That is not entirely true, i have few emails I use hidden from users just to
collect spam and feed it to bayes. But that is another story.)

It is 2020, stop using spyware sites like gmail and start using INTERNET.

~~~
sbuk
Its a wonderful idea, but I fear there are too many blocks in place _at the
moment_ to achieve this, technical literacy being the main one. The reason
that people go to GMail, Outlook.com (formerly Hotmail) and other services is
For the convenience - mainly the simplicity. It’s easy. Running a mail server
is hard (tm), well in relative terms. There is a lot that needs fixing,
especially on the ISP front. Until we can all agree to use IPv6, or another
solution that isn’t constrained in the same manner as IPv4, it’s a non
starter. I hate to be one of those that doesn’t proffer an alternative
solution...

------
ggm
Queue a nasty self fulfilling list "your email idea won't work because"
checkbox.

Sender pays would do a lot. Not popular.

~~~
brazzy
Because it's no better an idea than it was 25 years ago when Spam first became
a thing and there was another genius throwing this idea around every other
day.

First, there are some important use cases it would destroy (especially mailing
lists).

Second, it's impossible to implement gradually. Protocols and infrastructure
would have to change drastically, everywhere at once. Not feasible.

~~~
DennisP
Gradual implementation wouldn't have to be hard. Gmail already sorts your
inbox into several buckets. If you have one bucket for "paid/whitelisted" and
another for others. You can leave the rest to the user.

~~~
brazzy
So basically "pay to bypass the spam filter", is that really what we want?

And I don't think it would lead to gradual adoption; as long as people still
have to pay attention to the other bucket, there is little incentive to start
paying at all.

------
nunodonato
Even though its still "email as usual", I've since had a much better
experience since switching to Fastmail.

I'm not waiting to see Hey.com, the new project from the basecamp folks which
sounds very promising to bring email to a new level.

Both of these are paid solutions, but I guess thats fine because free brought
us here....

~~~
nunodonato
I'm now* waiting

------
someguydave
The way to fix email is to simply affix the message to a payment. Free is for
chumps.

~~~
tomcooks
Worked so well for newsgroups right? /s

~~~
someguydave
Paying to post on a newsgroup is much different than paying an individual to
read your message

------
einpoklum
Author makes the implicit assumption that the problem he experiences are the
experience of everyone. They aren't.

Specifically:

 _Spam_ : I used to get a lot more spam, today I get some, but with client
side-filtering, it's something like a message every one or two days. And my
address is very visible online, and I get dozens of legit messages per day; a
good number even excluding mailing lists.

 _centralisation_ : This _is_ a problem for me - my provider is being
swallowed by MS Outlook365. But that's not driven by spam detection IMHO. (PS
- spam did not go down significantly when this happened.) Actually, whatever
standard you use - it's extremely likely that if it's free and anybody can ran
an "email-plus" server, then Google and Yandex and GMX etc. will run those,
and web services to access them, giving you centralization again.

 _Scam_ : I feel I have this under control personally, but I recognize that
some people might fall prey to that.

 _Standards for digitally signed email ... not great_ : I dunno, seems to work
fine for me. I mean, sure, mail clients could use better integration of
encryption and signing, but other than that no serious complaints about email
as such.

 _a future where hosting email yourself makes you suspicious._ Now _that_ is a
problem. In fact, it's a problem _right now_.

 _difficult to hide who is sending email to whom._ So, me and the author may
believe this is a general problem, but many/most people don't care about this.
Unfortunately.

 _HTML email is not well standardised, and is a security and privacy risk._
It's a menace! For me, this is a serious problem. People write crap HTML and
send it to me.

 _HTML emails can embed ... from the Internet_ : Easily disabled entirely with
reasonable mail clients. The problem is in the client, not the protocol. After
all, with any messaging protocol, you could send markdown or HTML as though it
was plain text, and a client could choose to interpret it as it sees fit.

 _Attachments fill disks:_ I'm annoyed by this to no end, many people are
perfectly fine with it since for them it's just webmail, so not their disk.
Also, it's unlikely you can have your protocol prevent transferring files. At
worst it would go back to the days of binaries-over-IRC.

 _The technologies and standards for email are getting ridiculously
complicated._ This is at most a problem for programmers. Also, it's a problem
from the 1980s and early 1990s... MIME is quite complicated, and in fact, I
challenge anyone here to point to any mail client properly support complex
MIME structures, with hierarchies including multipart, alternative and so on.
But most users are none the wiser.

 _The email tech stack is getting so hard to understand that it’s difficult to
even use:_ If you're a power-user/administrator - maybe. If your' an end-user
of webmail or a mail client - not really IMHO.

never mind implement correctly. Never mind that the complexity results in more
effort to operate and keep the servers secure.

~~~
foresto
> MIME is quite complicated, and in fact, I challenge anyone here to point to
> any mail client properly support complex MIME structures, with hierarchies
> including multipart, alternative and so on.

What failures do you see most often in this area? Alternatively, what popular
software gets this wrong?

I'm not disputing your statement. It's just that one of my back burner hobby
projects includes a new MIME parser, and identifying common pitfalls might
help me feel confident that I get it right. Finding useful test data turns out
to be harder than I expected. It's doing quite well with the messages I've
thrown at it so far.

~~~
einpoklum
> What failures do you see most often in this area? Alternatively, what
> popular software gets this wrong?

They don't even try in order to fail. They drop the alternatives and flatten
consecutive parts - and that's that. You can't see the part tree, you can't
fold different parts, there's no distinct rendering for "report", there's no
representation of the "related" type, etc.

Consequently, there is no support for changing rendering settings or otherwise
manipulating different parts, nor for removal or addition of parts .

~~~
foresto
Back when I used Windows, I had a mailer (and usenet news reader) called Forté
Agent. I liked the fact that it didn't hide things from me. When a content
type was unknown or unsupported, it would still be represented (usually as an
icon) in the displayed message. The MIME structure could be examined in a pop-
up window, hierarchy intact, and individual parts could be scrolled into view
or saved as files. Even preambles and epilogues were visible in the raw
display mode.

[http://www.forteinc.com/agent/](http://www.forteinc.com/agent/)

[https://en.wikipedia.org/wiki/Fort%C3%A9_Agent](https://en.wikipedia.org/wiki/Fort%C3%A9_Agent)

How have I done with respect to your challenge? :)

I wish more mailers were so good at just presenting the data, rather than
mutating it to fit some designer's limited imagination or some programmer's
limited patience.

------
jsilence
Also: shared folders in IMAP.

------
wildsatchmo
A friend has built a client with inbox economics in mind at
[https://baemail.me](https://baemail.me)

It doesn't use email but paymail which is a protocol for email-like payment
addresses.

    
    
      - messages include some Bitcoin SV
      - inbox sorted by value
      - conditional notifications based on value threshold
      - encrypted messaging

