Greylisting is not perfect, not even close, but it allows servers to reject huge amounts of garbage mail while allowing new mail from unexpected parties without user intervention.

1. "The recipient will not get this message until you authenticate yourself as a legitimate sender at this URL [...]" - resulted in people never getting mail from no-reply addresses they cared about (banks, e-com, etc.)

2. "This sender has sent you an email, with this subject and this first paragraph. Click here to whitelist, here to blacklist" - created a lot of churn on first setup that users didn't like as a UX

Baking it into the protocol - even now in SMTP and IMAP land - is doable, but would be resisted by email providers who, for example, make their money selling data to marketing agencies. Like, you know, Google, Microsoft, Yahoo...

I've seen other approaches proposed - even at IETF level - over the years, including digital postage stamps (sender pays to send email, your server gets paid, and may reject non-stamped/paying email), but it's the usual network effect: until it becomes widely supported it won't "stick". The stuff that has been adopted has basically been stuff that Google likes, period.

It's called threads - even Matrix has these

I feel like every one of these suggested changes to email comes with a functionally equivalent parody magic trick.

For this one, a magician has two stacks of cards: a tall stack of "spam" cards, and a small stack of "inbox" cards.

The magician moves the stacks apart to make a spot for a new "request" stack.

To start the stack, they pick up five "request" cards from the inbox stack with one hand while subtly pushing the entire stack of "spam" cards with the other hand to spot they made for the "request" stack.

They then pass the five cards they were holding behind their back, revealing them with the opposite hand and finally shuffling them into the now tall stack of "request" cards.

Ta da!

> If I was redesigning email I would think long and hard about different use cases and workflows and start with an RFC.

A magician sweeps 17 sloppy stacks of cards off the table. They then show how the first 15 cards they pick up can more easily be arranged in only three stacks. Voila! Everybody claps.

While the audience members put money in the hat, the pedants stick around and watch the magician pick up the rest of the cards and end up with 18 sloppy stacks by the time the audience for the next show arrives.

Edit: clarification

Edit 2: I forgot this part: "Protocols are far downstream of that." So imagine 8 tiny tables below the main one which somehow end up with more than 52 cards in each of their 17 sloppy stacks.

Surely only if you configure them that way. At least I can turn that off in my email client, Thunderbird.

Nina xx

Keep in mind that many people around the world already use this solution.

In my case, I give senders a mechanism to go into my inbox without my explicit approval. The server sends them an email with a URL. They follow the instructions, and their email gets whitelisted.

https://blog.nawaz.org/posts/2018/Sep/solving-my-email-probl...

When dealing with any kind of network effect and existing user behavior, though, especially one as ingrained as email, I would highly recommend being judicious about using the word "just," given that these are mutually-reinforcing effects. Imagining a solution is a world away from implementing one.

Still, I think you're on the right track: create a new protocol on top of an old one, use the same input methods and user behaviors, call attention to when someone is not using it (e.g., green bubbles), and make it extremely easy for existing services to migrate to use it (i.e., the standard/standards body, notably NOT what Apple has done). One part that's missing here is some pressure to make this happen: positive pressure (economic, product sense, persuasion) or negative (economic, social, regulatory).

And poof, we've poorly remembered Web of Trust from 20 years ago!

Overall I do love the idea of HTMP and if we could get it to easily fall back to standard old bad email, I think it could start as a niche and then upgrade towards HTMP over time as more clients adopted support for it.

Email is more than a technology its a community. There have been plenty of technical attempts at replacing it but they have failed to un-seat email because they focus only on the technology aspect which as you have found is largely a solved problem although... getting the details right might be hard. You need buy in from the community which is not just users but also businesses and organizations that use email which is everyone from CEOs to church leaders. It's not enough to fix email you have to get buy in from the community to make a meaningful change and I don't see anything here that would do that. This isn't really a criticism, just an insight I offer. I work in this field and we're trying to get out of it cause managing email sucks. I would love something new to take its place but the community has heard so many promises that never came to fruition, when that happens you either need a better promise(harder than it seems) or you need credibility which may be very difficult in the current climate. Not an unsolvable problem, those don't exist but sometimes the lever you need to solve the problem is further than you can reach alone and this is one of those times.