Comment by jazzyjackson
3 days ago
email has come a long way with SPF, DKIM, and DMARC, and its cool that anyone can purchase a slice of the global namespace that is transferable between providers, but AFAIK the biggest road block to using email in a distributed self sovereign way is reputation and getting your messages delivered to google and outlook users partially because of the nonstop spam.
Do we have any new tools to prevent spam in a post-email world? Or can we just use the current email structure with some better GUI around PGP and Hashcash and force anyone who wants to send a message to burn 10 cents worth of electricity ?
I'm curious what you're looking for in an email standard ?
A quick back-of-the-envelope calculation says that USD 0.1 would be about 700 Wh, so, give or take, a high-performance desktop processor running full tilt for over four hours.
Personally, I'd prefer something like an expansion of how XMPP works. By default you only see what people in your contact list have sent you, and anything else is marked "dubious", and it's up to you to read it or not. I think it's a mistake that email servers have been given the responsibility to filter unwanted traffic. Email servers should have only ever simply passed along whatever they received (excluding excessively large messages, of course).
> By default you only see what people in your contact list have sent you, and anything else is marked "dubious", and it's up to you to read it or not.
Any email client could implement this policy. You could even prioritize mail over who sent it or whether it's a reply to a mail you sent or have already read.
Yes, but if the third server down the line didn't propagate the email, there's not much the client can do. That's what sucks about email as a protocol; it's been taken over by a handful of providers who will refuse to play ball with anyone outside their club, or who doesn't have the time to monitor the continuously-updated black lists.
There’s a fairly direct route to solving this with email. The problem that needs to be solved is that knowledge of an email address is the only thing needed to send to it. Introducing recipient consent as an additional requirement solves spam and phishing.
The first email a sender sends to a recipient has an attachment that serves as a request to email them for a specific purpose (e.g. human:human, mailing list, transactional). This email is not delivered to their inbox immediately, but to a separate “friend request” style queue. When the recipient approves, the sender receives a Biscuit token [0] and the email is delivered to the inbox.
Subsequent emails are sent by attenuating a one-time-use token from the master token, which is included in a header. Because they have verifiable authorisation, this can skip all existing spam heuristics because the receiving mail system knows for certain the recipient authorised this sender.
Biscuits can also be attenuated to reduce scope. Want the hotel you are staying at to only be able to send you email for the next 30 days? No problem. Mailing list providers can reject tokens that are scoped to transactional email. A sender can reduce blast radius of compromises by attenuating new tokens to give to third-party providers.
Authorised senders who spam can have all their historical emails quarantined at once and their ability to send in the future removed. Recipients can see who gave spammers their email address.
People who send mail are incentivised to implement this because it improves delivery rates by bypassing all existing spam filters, including IP reputation. “Ask for a token and you’ll never hit a spam filter again” is something a lot of people would jump at the chance for. No need for providers like Mailchimp, you could go back to sending mail directly from your own servers.
Recipients are incentivised to implement this because it will cut down on spam and phishing significantly.
This can be implemented independently of the other side because the fallback situation is the status quo – the initial email just has an attachment that goes ignored, and subsequent emails are sent without tokens and are subject to existing spam filters.
It’s possible for spammers to send lots of unsolicited contact requests, however separating things out into a spam-free inbox and a “this new person wants permission to email you” queue makes it far more manageable than the current ocean of potential spam in an overflowing inbox. Determining “is this new contact legitimate?” a handful of times is much easier than determining “is this email legitimate?” thousands of times more often.
What you’re essentially doing with this is bootstrapping a social graph on top of email. You can then add a bunch of other nice things on top of that, like public key cryptography, but the actual diff between current email and this system is surprisingly thin.
[0] https://www.biscuitsec.org