I've made a new version of my essay on re-thinking email, and solving the spam problem. See or

I'd be happy to hear constructive feedback.

TL;DR: I don't think the current email system can be improved enough to be worthwhile, but a new system could use digital signatures and digital stamps (tokens) to only allow recipients accept mail from specific senders.

@liw Just came across your blog post. I've been working on the exact same problem since literally last Easter and it has become my passion. It's been good to see someone has reached similar conclusions.

I'd really appreciate it if you could check my project's website and offer feedback.

@liw not only this but we need to make email more sane and accesible for the average folk. POP3 must be deprecated and JMAP put to use instead. All these ports and settings should be streamlined and configured automaticaly.

@liw I don't know if this exceeds scope, but repudiability and nonrepudiability are both characteristics which may be worth consideration. Generally these are side effects of authentication. Nonreputability-by-entity is another variant.

Ephemerality and perfect forward secrecy might also be considered.


@liw I think you problem statement is pretty good. I'll suggest there may be a common underlying concept or two.

- Spam and scam mail both principally concern trust (or abuse of trust), as does privacy -- freedom from surveillance, metadata leakage. Possibly unauthorised forwarding, though that's all but certainly inevitable.

- Finite attention and what are effectively denial-of-service attacks, in mail volume, technical administration, & vigilance, are additional threats.


@liw A possible alternative, or implementation, of "stamp" dynamics might be SLA levels afforded remote peers. The geymilter model might be a suitable starting point: set a service frequency / response rate for peers based on trust. The initial level would be modest but not impassible. Reputation vouching (similar to you "stamps on behalf of" notion) should be possible.

Trusted peers get high service levels.

Untrusted peers would see a proportionately low service level.


@liw Connection attempts, packet acks, local recipients per connection, messages permitted per day (or week, or month, or ...) would be curtailed.

Previously unknown peers could be required to acquire a reputation token, at some cost (hash, time, cash), before being permitted to connect. Again, a bar, but a surmountable one.


@liw The problem with sender/author reputation is ... most senders simply cannot be arsed. Even large & presumably technically capable ones. Some combination of PKI components, elements, cross-signatures, & trust is _probably_ where the solution lies, but in over a quarter century we've made frustratingly little progress.

At some point an authority with teeth is going to have to step in, dictate a standard, convince others to accept it, and enforce it.

I don't see that any time soon.


@liw I'd also like to se requirements for recipients demanding, and senders being required to provide, a minimally-complex message format -- plain ASCII (or minimum sufficient appropriate characterset) or equivalent. No HTML, no links, no attachments.

*Maybe* a very-tightly-defined minimal lightweight markup (e.g., Markdown). The amount of generally unreadable email I receive is ... large.


@liw DNS and its role in addressing is another huge problem. Name resolution is inextricably bound to SMTP-baseddeliveery, and was created in large part to address it. As WITHSMTP it's outliving its usefulness.

Overall I tend to share your concerns w/ SMTP email.

Where I can't settle on a conclusion is. in whether the concept of open-standards textual messaaging is salvagable with a ground-up redesign, or is simply a lost cause.


@Lars Wirzenius @Doc Edward Morbius ⭕ We tried to implement such a scheme at Netscape in the mid/late 90s and invited Eric Allman (sendmail) and a Microsoft representative to join us in stopping spam forever. Together we represented the most influential and widely used SMTP servers on earth (at the time). Eric refused because he didn't want to piss off Chinese dissidents. Microsoft refused because they didn't invent it and this didn't fit their agenda of wiping Netscape from the face of the earth. So 24 years later we're still dealing with spam. Anyway yes, you can do it, but don't expect the rest of the world to go along. They won't.

Eventually this was released as an "internal" flag in Netscape's mail system. This work was based on SSL client certs and SMTP-AUTH. If you saw the indicator, it came from a sender that was end-to-end authenticated, even through cooperating SMTP relays. Several Fortune 500 companies demanded it. I haven't even looked to see if it is still supported (doubtful after this length of time), but if it is, it might be a good place to start.

@liw Maybe some of this goes back to my anti-spam system:

It got a little coverage back on the old (ultimately useless) IETF ASRG. But, yes, authorization is the key missing ingredient. I still use my system, and don't have a spam problem.

@Andy Valencia ✅ That's actually a really interesting approach. I also have a mail system where my email address adorned with a suffix will all be routed to the inbox for the unsuffixed address. In my case any suffix will be let through, but I can identify which org sold my email address, or which website they scraped it off of. But I can see how actually disallowing emails to your unsuffixed address, and the ability to drop addresses that has been abused makes all the difference. Thanks!
Sign in to participate in the conversation

Lars and friends